Shibboleth Developers

["Howard Gilbert" <>]

> > We already have magic to allow the Session object (managed by the
> > /shibboleth context), to be available upon request to the Resource
> Managers.
> 
> Can you briefly explain how you're sharing the security context across
> application contexts?

I am not sure exactly how you define "security context". In concrete terms,
there is a Session object that after the POST contains an authentication
assertion and after the AA query contains Attribute 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.

There is an internally generated UUID random key to the Session. A Resource
Manager with this session key can request Session data through what is now
called the FilterSupport interface. Although Session objects are indexed by
UUID, the requestor also supplies an applicationId (determined by running
the Resource URL through the RequestMap) which must match the applicationId
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 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.

Yes, the Session UUID is the content of the "Cookie" data, but "Cookie" is
conceptual, not explicit, as explained below.

The "API from the RM to the /shibboleth context" is where the magic comes
in. FilterSupport can be implemented in a number of ways, but probably not
in any way guaranteed to be universal across all Application Servers and
configurations. For now, the implementation uses the simplest solution (a
static field in a class loaded from the shared ClassLoader). Other options
could include the JNDI trick, EJB, Spring, RMI, or a Web Service. EJB is
supported only in a full J2EE server. JNDI is supported in J2EE and Tomcat,
but maybe not in other Web servers. Spring is an lightweight alternative to
J2EE. RMI is less efficient, but operates across servers, as does Web
Services but that is even more inefficient. That is why FilterSupport is an
interface and the implementation is pluggable.

So an RM in /part1 and another instance of the RM in /part2 (two directories
and WAR files that, although in different Tomcat "contexts" are part of the
same logical "application") can share the same Session object if they both
context are RequestMap'ed to the same applicationId and therefore are driven
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.

> Why can't the cookie be scoped to the entire server (path=/)?

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

I believe that Scott would point out there is no real hard security between
Tomcat contexts, that RMs on the same server have to be well behaved, that
an administrator should not expect real separation, and therefore there is
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.

Such pessimism is realistic in view of the recent history of security
problems in servers and operating systems. However, all that trash is
written in C, with its buffer overruns and unchecked operations. Thirty
years ago mainframe systems ran applications where thousands of users
interacted with an Application Server (CICS) that maintained data security
between uses simply by careful programming. Tomorrow, both Java and CLI
should be able to enforce data security across contexts or appdomains
automatically. So I am reluctant to design pessimism into a system as a
permanent restriction just because it would not be responsible today to
assume that security can be enforced.

> 
> I'm not sure I follow...are there now two cookies?  If the /shibboleth
> context sets this second cookie as well, don't you have the same
> problem?  Why not broaden the scope of the first cookie?

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.

The /shibboleth context does write a real Cookie of its own. It doesn't need
to. I did it because the C++ code does it and I sort of went along copying
logic line for line. There was this place in the logic where Scott added a
cookie to the Response object, so I did it too as a gesture of solidarity.
However, all the "Cookie" function can be implied through Servlet sessions.

Yes, the /shibboleth context has its own "Cookie", whether this is a real
cookie scoped to this context or what is really a property in the
HttpSession object managed by the container. If the same Browser session
comes back to /shibboleth we know he has been here. Actually, /shibboleth
may have more than one Cookie-property, one for each applicationId for which
there is a separate Session object. The RM has only one applicationId and
therefore only one property.

> 
> Seems the Resource Manager must distinguish a request that has an
> associated security context from one that doesn't.  If the request
> does not have a cookie, the client should be redirected to the IdP
> (via the WAYF).  Otherwise the cookie is resolved into the
> corresponding security context (which itself is tricky in a J2EE
> environment).

That is the question. A request arrives at the /part2 RM that has no
HttpSession and no "Cookie". However, the user has logged on to the
applicationId and has a Session. /shibboleth knows it, and /part1 knows it,
but this is the first visit to /part2. So there are two choices.

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.

2) Redirect the Browser through /shibboleth before it goes to the WAYF. When
the Browser goes to /shibboleth, it presents the /shibboleth-scoped cookie,
which maps to an HttpSession, which identifies the user. Now /shibboleth can
look at the target= that was going to be passed to the WAYF, determine the
applicationId, check for an existing Session object that can satisfy the
request, see that it already exists, and Redirect the Browser back to the RM
without going to the WAYF and AA. The /part2 RM now fetches attributes and
gets them from the Session that /shibboleth matched to it.

Actually, there is a 3), where /part2 redirects to the WAYF, which redirects
to the AA, which POSTs the data, and maybe at that point Shibboleth finally
recognizes a duplicate or maybe we just end up with two duplicate Session
objects. I think we want to avoid that.