Shibboleth Developers

["Scott Cantor" <>]

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

Alright, confining this to a single host, I think it's a bad idea to pretend
that multiple applications with different security requirements can coexist
on a single virtual host. Jim Fox has explained this before, and it's still
true. The fact that the software supports the illusion that this is possible
doesn't make it a good idea in practice. I'm as guilty as anyone of doing it
to save money, but that doesn't make it right. It's a big reason I think
portals are a fundamentally bad idea.

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

Using the mapping process would, I suppose, be a plausible way of
constraining/deciding when a session could be transferred. That's definitely
one of my concerns, preventing the "feature" from being supported if I think
it's a bad practice.

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

Yeah, but no cookie will be available for the "subrequest" since the browser
doesn't know about it. I don't think this works for this use case.

> 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 think the right way to do this "safely" is with a second vhost.

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

It seemed to me that a script external to Shibboleth could be written to
create a Shibboleth request (or start a lazy session) and act as the
protocol translator from another SSO system. Something SP-related, but not
part of the implementation itself. This is better to me for both sides of
the translation, more loosely coupled.

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

I didn't mean it literally, no, but I'm familiar with that approach. I used
it in my old system, which does a set-cookie, then a redirect, then creates
a link between the key and the data using a callback.

> 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 

Right...I suppose you would still have to drop a cookie from a single POST
processor if you wanted to transit sessions across the tree.

I hadn't considered trying this design, but it's something we'd have to
really think about. When you use the POST profile, there's no signature
around both the response and the "TARGET" value, so there's no secure link
between them. I'm not sure it's a real problem, but it'd be something else
to work through.

-- Scott