Shibboleth Developers

["Howard Gilbert" <>]

> I'm a little unclear on some of what you're trying to propose,
> particularly
> anything that tries to introduce a finer-grained policy distinction
> externally than "Service Provider". I think that way lies further madness.

That is a perfectly reasonable response. However, from an algorithmic point
of view having two policies that key off two providerIds is not dramatically
different from one providerId and two subthingies. So I will leave it on the
table, but I am not pushing it.

> That's fine, but it glosses over the most important reason for multiple
> SHIREs. Cookies *cannot* span arbitrary vhosts. So there are technical
> reasons why it's necessary to support multiple locations and it seemed to
> me
> that (this being the case) there wasn't a compelling reason to bother
> making
> the whole mess NxN instead of leaving it Nx1. In other words, it seemed
> more
> manageable to insist that a given set of endpoints map to one "thing"
> (application) than to deal with multiplexing many endpoints into many
> applications.

I don't seen any NxN. There are two models:

1) The SHIRE is in the Resource context. The POST is received by the Filter,
passed to the main /shibboleth files through the Filter Support interface
just as the C++ code passes it through the RPC mechanism. A Session is
generated and its ID is passed back through the call mechanism. Any cookies
generated come from the Resource context (through a Java Filter has access
to the HttpSession object shared with the actual Servlet application code,
so its Cookie could be implied and managed by the Application Server). This
code is not currently in the Java SP, but I could add it in a few hours to
achieve closer optional compatibility to the C++ approach.

2) The SHIRE is in the /shibboleth context. It gets the post and then hands
a session identification off to the Resource Manager with a generated
Session ID UUID appended to the URL and then stripped by the Filter. In this
case there are two session cookies, one from the /shibboleth context and one
from the Resource context. If more than one Resource context shares the same
SHIRE (and therefore authentication, attributes, etc.) then the second one
avoids a trip to the Origin, but only if it checks for an existing Session
object before redirecting a new request off to the WAYF.

There is an intermediate solution that doesn't require a cookie that spans
all the Resources. The alternative is to go through the /shibboleth context
on your way to the WAYF. If the WAYF is /shibboleth/WAYF then you kill two
birds with one stone. Otherwise, you add an extra Browser redirect, but that
gives the SP a chance to check for an existing SHIRE cookie before sending
the user back to the Origin. 

So if you have N resources, then 1) generates N application cookie-session
values and 2) generates N+1 cookie-session values (adding one SHIRE cookie).
If the SHIRE has two alternate bindings (http and https), maybe it is N+2.