Shibboleth Developers

["Howard Gilbert" <>]

> In a typical situation, why would an application session need to spread
> itself across multiple vhosts? And if it did, why would it be a problem to
> just do SAML and set up concurrent sessions given that the WAYF/etc. logic
> would be bypassed and usually the login would be invisible?

It's not spread across multiple vhosts. It's spread across multiple contexts
(virtual directories). In Java, each application is a .war file that expands
to create a directory. The session (HttpSession object) is scoped to the
application, not to the entire Web Server. Applications in different
directories get entirely separate environments unless they are explicitly
set up as cross-context. Meanwhile, many applications (portals, Sakai, ...)
are distributed as multiple WAR files that expand to multiple directories
but are really one application.

An explict cookie (as to be distinguished from the implicit cookie vended by
the Web Server to manage the HttpSession) can be scoped to the entire server
or to the application context. In the former case, it runs the risk of being
picked up by independent applications running in the same server. In the
latter, it is only picked up by applications in the one directory and not
related context directories.

So now consider a logical application split into http://dummy.yale.edu/part1
and http://dummy.yale.edu/part2. Part 1 is the main entry point written by
one group to perform the main control functions, and part2 is a secondary
war file packaged by a second group to perform supplementary functions. So
the user comes into Part1 and logs on. In fact, there is a RequestMap
definition for host, port, and directory mapped to applicationID=xxx
requiring authentication. Some URL, however, directs the user from Part1 to
Part2, maybe to pick up a JPG file. This is a separate context, separate
instance of the Filter, separate HttpSession object, and probably separate
cookie scope (because we don't want to confuse
http://dummy.yale.edu/completelydifferentapplication). Since the Filter
(Resource Manager) has no history for this user, he thinks he has to logon
again. If the WAYF has a cookie, then it is certainly true we could Redirect
to the WAYF, AA, Post back to the SHIRE, and then come back to Part2. Or, we
could redirect to http://dummy.yale.edu/shibboleth/something and let it
decide if there is already a ShibSession (for Part1) that is scoped to be
useable (say by being mapped by the RequestMap to the same applicationID) to
Part2. If so, then we go back to Part2 immediately and it can pick up the
attributes just as if there had been a new Shire POST.

Note that in some (maybe most) Application Servers you don't have to
redirect the browser between contexts on the same machine. Unless there is a
restriction in the Security manager, you can get a RequestDispatcher for the
/shibboleth context and make the transfer internally through the Web Server.
However, if you try this and the Web Server returns null instead of
providing a Dispatcher object, then you have to do a real Redirect through
the Browser.

So the real question is whether it is likely that more than one context on a
Web Server would share the same ShibSession without all applications on the
Web Server sharing that ShibSession? Sure, if two or more directories vend
normal content and one directory is the administrative part of the app which
has a different ARP/AAP profile (it needs to know more stuff before you can
use it).

 
> I take it the CAS/etc. issue fits in here somewhere, but I guess I'm not
> seeing the connection to that.

If a CAS API Resource wants to accept Shibboleth authentication, then "on
the way out" it has to route the request through CAS to convert from CAS to
Shib protocol, then on the way back in it has to go through CAS to convert
from Shib back to CAS. This isn't directly related, but it points to the
idea of redirecting out through an SP-related entity that caches,
transforms, or substitutes URL elements before they are forwarded to the
WAYF or HS.

 
> For clarification, I was just proposing that the target parameter would be
> a
> session key that was generated and stored before the initial redirect away
> and then recoverable into the original target value (and whatever other
> SAML
> request state) by the assertion consumer service. So there's shared data
> internally between the filter and the "SHIRE", but they already do.

Yes they do, and it is certainly possible. However, I am suddenly struck by
your use of the term "session key". In all previous cases (in my Java code
and, I believe, in your C++ code) the actual Session key is generated during
the processing of the POST'ed authentication assertion, and at that point
the Session control block is created to host the Authentication (and for me
Attribute) data. However, an alternative strategy is to create the Session
key, and maybe even an empty Session block, before the Resource Manager
redirects the initial request to the WAYF. If the user never logs on
successfully, the Session times out. Otherwise, the Session is prespecified
with the POST and the RM already knows the Session Key when the user comes
back. Of course, you may not have meant to use "session key" literally, but
this is an alternate strategy.

An interesting sidelight of this strategy is that the RM writes the
SessionID cookie to the Browser in the initial Redirect rather than writing
it after fetching Attributes after the POST. Of course, if the user fails to
logon but returns somehow to the RM, he will be dragging a cooking and a
SessionID. But when the RM asks the SHAR for Attributes, the Session will be
empty and the return code can indicate that there is no authentication for
the Session identified by that ID. This creates a new error condition that I
have to handle, but it actually simplifies the post-POST processing.