Shibboleth Developers

["Scott Cantor" <>]

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

I chose to, anyway. Note that I had no choice...there's no established
cookie to rely on such as JSESSIONID, but then again, I think it's better to
enable a more isolated session cookie anyway.

> 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.

Couldn't it just generate the redirect itself? I use a redirect to the SHIRE
"handler" as a way of generating a redirect only to support lazy sessions,
but since it's an extra redirect, it's best avoided if you can, I would
think.

The language you use later makes me think I just don't fully grok the
architecture of how things are set up re: the filter vs. the servlet and
such. I will read your note on the web page however before asking dumb
questions.

> 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.

And a time value (I just run a time() call and append the number in
seconds). Also, I'd note that the providerId doesn't come from metadata
specifically...it can be set per-application so as to enable a deployment to
advertise itself as whatever providerId it needs to for a given app. It of
course corresponds to metadata that exists for the origin to consume.

> 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.

Right, it treats the shire URL just like a normal request so as to locate
the needed configuration bits that should apply during session creation.
Thus, the acceptance URL must be "within" the URL scope of the application
for which it is firing up sessions. Since driving off of hostname is the
common case anyway, it's not usually a tricky thing.

> 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>

Right, exactly.

> 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).

We currently in both mod_shib and isapi_shib generate an error as a signal
that something is fishy. I viewed it as a sign that the configuration isn't
right, rather than just default the behavior. It simply won't happen in a
correctly configured environment.

> 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.

Right, though it is possible to override the cookiename and not include the
appid in the name. But I autogen the name when not told what the name should
be (this was Noah's suggestion).

> 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.

It's not a security check in that sense, no, it's just a way of confirming
that the configuration is "intact" and consistent between the original
session creation and now. As I said, it's a conservative assumption, but I
preferred to be conservative in a security filter.

> 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.

I believe that's what I'm doing, but I'm probably a bit sloppy with it. Like
if the new POST is an error, I probably don't clear the old cookie value, so
in effect the old session is still there.

-- Scott