Shibboleth Developers

["Scott Cantor" <>]

Something I wanted to note is that I don't use UUIDs as session keys. I use
random numbers from OpenSSL, which can be configured to use a secure source.
UUIDs make very bad session keys, they have almost no randomness.

> Assertion trimmed by the AAP. The Session is "scoped" to an applicationId
> because that is the configuration unit that determines the requested
> attributes and sets the AAP and therefore determines what attributes
> remain in the Session after filtering.

Actually, another relevant property is that the timeout/lifetime of the
session is based on the application. The real purpose of application
scoping, so to speak, was to protect the application, not the user's
privacy.

> for the Session. This is a sanity check, not a security mechanism. Access
> to the information in a Session object is only restricted by 
> limiting knowledge of the UUID.

I think of it as a security mechanism for the app. The app is protecting
itself, so there's no motivation for it to "lie" about what its
applicationId is.

> I have been a bit less precise about the UUID handling because the details
> are subject to adjustment. Originally it was generated by the POST and
> passed on to the RM through the Redirect. However, during earlier
> exchanges in this thread I realized 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.

> by the same attributes and policy. However, security against a rogue
> application running on the same server getting the attributes of a
> different applicationId than he is mapped to exists really only by 
> keeping the UUID obscure.

Absolutely, that was never a goal.

> I can write the UUID in an explicit Cookie scoped to the entire server
> qualified by its association with "shibboleth" and by the applicationId.
> This has two downsides. First, the cookie has to be explicit, not implied
> as would be true if the data is really a property in the HttpSession
> object and we let the Application Server generate its internal Cookie to
> ID the HttpSession.

It was no surprise to me to learn that Java session ID generation is not
secure and can be predicted. There's a presenter at RSA's conference with a
paper about it. I don't know if this is all Java, a specific containers, or
what. But I have a rule...I *never* rely on application server session
mechanisms for security context tracking. If I screw up the process, it's my
fault, but I don't rely on anybody else to get it right.

http://2005.rsaconference.com/us/general/presentation_info.aspx?id=3743

> That's really no big deal. The other problem is that any RM on
> the server can get the attributes associated with any applicationId on the
> server because now the UUID is no longer local to specific contexts. 

As Jim said, there is no privacy to be implied anytime data is shared in a
process, and in general not on a server period (even vhosting in this regard
is just a fiction unless you know how the system is managed).

> no reason not to scope the UUID cookie to the entire server. Scott
> believes that the only meaningful unit of integrity is the SP, and any 
> separations within the SP are based on good behavior.

It's more complex than that because of the arbitrary distinctions the
software can make. I could have two SPs on the same box, and from a user's
perspective, they basically can only be trusted not to share data if I
choose to trust them. Technically, they may as well be one entity to me, I
don't know who's running the box.

But at least the SP is something public. It's got metadata, a contact,
somebody I can call and interrogate or audit, etc. It's important that this
not be undermined by the software itself. That's why I don't like
architecting explicit support for cookie spoofing across SPs that might be
colocated using vhosting. I can't stop people from doing it, but I don't
have to make it easy by building it into the software.

So, I think cookie scoping within vhost is mostly not the point, and
spoofing/chaining cookies across vhosts is just frankly wrong (within the
context of the software's architecture).

> Tomorrow, both Java and CLI
> should be able to enforce data security across contexts or appdomains
> automatically.

Because I should trust Microsoft? ;-)

> First, if you enable HttpSession objects then there is an automatic
> implied cookie generated by Tomcat (or another Application Server) 
> mapping to the HttpSession object for each application context. Strictly 
> speaking, there is no need for any explicit cookie from anyone. The "UUID 
> Cookie" function can be achieved by storing a property in the HttpSession
> Map in the /shibboleth context and in the RM context. Now we have done
> everything very Java-like. This is actually how the RM Filter works.

I think that's a mistake, for the reason I mentioned. Somebody has already
cracked the generation algorithm. I don't know the details, but it's
something I avoid.

> 1) Write an explict Cookie scoped to the entire server. Now /part2 can
> find the Session UUID for its applicationID, and for every other 
> applicationId on the server. It can get its attributes, and any other 
> attributes available to any other context on the server. Any separation
> between contexts is strictly on the honor system.

It already is, as Jim noted.

-- Scott