Shibboleth Developers

["Howard Gilbert" <>]

First:

1) I will change the UUID to a big secure random number.
2) I will scope the Cookie to the entire server.


> > it would be cleaner to generate it
> > through the API call from the RM to the /shibboleth context before
> > redirecting the user to the WAYF, and including it explicitly or
> > implicitly in the target=. Then when the POST comes back, the UUID has
> > already been assigned and the RM already knows it.
> 
> This may have potential security implications and needs very careful study
> before doing it. The round trip between servers is much less secure than a
> quick redirect and putting anything that identifies the session in a URL
> is
> just something to avoid unless you have a good reason for doing it. It
> also
> doesn't really solve any particular problem that I know of.

There is no round trip between servers here, just a call from one class to
another (at least for now). The RM (Filter) asks the /shibboleth classes
through the FilterSupport interface to generate a unique session identifier
and associated target= value passing the resource URL. The SessionManager
creates an empty Session object keyed by the ID, returns the ID, and returns
the target value. The RM then writes the ID to the Cookie and adds the
supplied target= to the WAYF redirect.

Eventually the POST comes in. The AuthenticationConsumer gets a target he
generated and looks it up (or looks in it) to find the Session ID and
Resource URL. The Assertion is stored in the Session, which now becomes a
real session, and the Browser is redirected back to the Resource.

The target= value becomes a one time use externally meaningless token. We
need some token because, having been redirected to the WAYF, a user may
abandon an attempt to access this resource and turn his attention to a
different resource, even a different URL under the control of the same RM.
The target isn't a security token, just a routing slip. By saving and
restoring the original URL on the final redirect, nothing is added or
changed that could adversely effect the application. 

The session ID is never placed in a URL. When initially selected it flows
through the same mechanism by which the RM fetches attributes (equivalent to
the ONC RPC call in the C++ code). If that is ever extended between
machines, it can be protected by SSL. 

> 
> It was no surprise to me to learn that Java session ID generation is not
> secure and can be predicted. 

OK, but I need the HttpSession to be part of the API to the application. So
the trick here will be to compare the Cookie (which now can't be predicted)
to the ID in the HttpSession block that the Application Server assigns to
the request. We require that the two match. This way, if someone guesses the
Tomcat cookie to get someone else's session, he still won't have the
Shibboleth Cookie value. The Filter runs first, the cookie-HttpSession
sanity check fails, and the Filter rejects the request without letting it
pass on to the application. There can be other sanity checks (IP address?)

Does this meet everyone's expectations?