Shibboleth Developers

["Howard Gilbert" <>]

> The thing I think you're missing is that one of the "settings" bound to
> the
> application is the name of the session cookie. 

I missed that and now see that I have to generate the cookie name to include
the applicationId.

> Secondly, there's a semi-security check involved. Once a session is
> created,
> it's bound to a given applicationId. Part of the processing in the request
> map is to independently establish the applicationId for a request and then
> make sure it's the same as the one bound to the session. That makes it a
> little harder for a session to be misapplied to requests that are part of
> a different application.

Let me try this step by step.

First, I separate the Resource (typically a Filter) from the
AuthenticationAssertionConsumerServlet (formerly the SHIRE).

The user requests http://server/resource/thing.
The Resource Management Filter decides to protect this resource. 
Typically the Filter redirects the request to the Servlet.
The Servlet does a check [described later] and decides it has no Session and
the request should be redirected to the WAYF and eventually AA with three
parameters:

target= the URL of the Resource (as protected by the filter)
shire= the URL of the AuthenticationAssertionConsumerServlet
providerId = the Id of the ServiceProvider's EntityDescriptor (TargetSite)
in Metadata.

The HS generates a POST to the shire= URL.

Now at this point, it looks like the code unconditionally turns the shire
URL over to the RequestMapper plugin for analysis. Effectively, the
RequestMapper is going to choose an applicationId from its configuration.

At this point there is no Session to sanity check. So we look this proposed
applicationId up in the <Application> table and maybe we get a direct hit on
an <Application>

Question: if RequestMapper generates an applicationId that does not map to
the ID of an <Application>, do we (as I expected) associate this
applicationId with the "default" application configuration of the
<Applications>. The alternative, where the <RequestMap> has ids that do not
match up to any <Application> is to reject the POST with an error message
(although we should notice and log this error when the configuration file is
first parsed).

Then we process the POST data, create the Session, and (now I see) store the
original applicationId proposed by RequestMapper in the Session block and in
part of the name of the Session Cookie returned to the Browser.

Now there are only two places for a further check of the ID:

A subsequent redirect to the Servlet from a ResourceManager would be first
processed by the RequestMapper to establish an applicationId. The Servlet
would then check for a Cookie containing that ID indicating that a Session
already exists with this mapping. If the Cookie exists, then the Session
object probably exists under the key determined by the Cookie value. A final
sanity check [that you describe in your mail] is that the Session object
fetched by using the Cookie value has an applicationId that matches the
applicationId that is part of the Cookie name (and the applicationId
generated by the RequestMapper). However, I would not imagine this to be a
"security check" since the real security is provided by the obscurity of the
large Cookie value.

This brings up one last case for completeness -

A (second) POST appears. We process it through RequestMapper, get an
applicationID, and notice that the Browser has also sent a Cookie with that
applicationID associated with an existing Session created by a previous
POST. This probably should not occur, but I have to do something. Since the
Cookie can't point to two different sessions (right?), I assume that the
best thing to do is to abandon the old session (not delete it, but let it
timeout), generate a new Session with the new POSTed Assertion, generate a
new UUID, and rewrite the Cookie with this new value.
[Note: this is not the ReplayCache issue. I am not suggesting that someone
has sent the same POST twice. Here, someone has redirected to the AA a
second time and got a new POST with (presumably) a new handle bypassing any
of the checks that should have noticed there was an existing session].