Shibboleth Developers

[Tom Scavo <>]

Your detailed explanations are very helpful, Howard.  (Please see below.)

On Sat, 18 Dec 2004 12:03:16 -0500, Howard Gilbert
<>
 wrote:
> 
> ...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.

Is there a Java class representation for the SAML assertions?

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

So essentially a webapp accesses the session of another context?

> ... 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, this is a nice way to handle SP-first profiles, but what about an
IdP-first profile such as SAML1?  In that case, what does the IdP set
the TARGET parameter to?

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

In my experience, a "two-part app" shares data via a persistence
mechanism (such as a relational DB).  Also, since security of the SP
is a concern, might we implement the /shibboleth context on a separate
vhost?  (Please read on.)

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

Right, and this suggests (to me anyway) we consider running the
/shibboleth context on a separate host.

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

Basically, I agree, which is why I'm suggesting a separate vhost for the SP.

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

If the webapp context is accessing the session of the /shibboleth
context, this doesn't seem very "Java-like" to me.  Moreover, the
design assumes that the entire server is supporting a single app,
which is not generally true.  For instance, I've built a J2EE server
environment consisting of many individual applications.  (Yes, they
did share code, but each webapp had its own security requirements.)  I
don't think this is so uncommon.

> The /shibboleth context does write a real Cookie of its own.

What are the attributes of this cookie?

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

So the /shibboleth context has two cookies?  If the "security context"
is stored in the session (which gives rise to one cookie), what is
stored in the other cookie?

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

I don't think Shibboleth should be concerned with "two-part apps".  If
the RM is installed in a webapp context, it should do the "right
thing".  If there is no RM installed, there is no protection or the
application provides its own.  How closely two webapp contexts
interact is of no concern to Shibboleth.

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

This is most likely the preferred path, but I would consider taking it
even further (see below).

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

No, this adds unnecessary steps to the profile, I think.

What if we totally separate the /shibboleth context (the SP) from the
RM?  The SP runs on its own vhost.  There are two endpoints, one for
Browser/POST and another for Browser/Artifact (and perhaps others). 
Let's stick with Browser/POST for the sake of discussion.

The Browser/POST endpoint at the SP receives a POST request with the
requisite parameters.  It validates the request and creates a security
context (i.e., it processes and stores the authn assertion).  If
necessary, it queries the AA and adds the resulting attributes to the
security context.

Let's not worry for the moment how the "security context" is
maintained.  Now suppose that the /shibboleth context creates a
domain-wide cookie on the client, whose value is a random session ID. 
Thereafter the client is redirected to the original resource (by
virtue of the TARGET parameter).

The RM looks at this request, sees it has the required cookie,
extracts the session ID, passes the session ID to the SP, and receives
the corresponding security context (assertions) in return.  Since the
SP and the RM are running on different vhosts, there aren't too many
choices...suppose the RM makes a back-channel HTTP request to the SP
to retrieve the security context.  This could be as simple as a GET
request (with session ID as parameter) but more likely it would be a
SAML request.  In any event, the RM retrieves the security context
from the SP and subsequently makes an access control decision.

In this way, a security domain has only one SP.  This SP accepts
requests from browser users and creates/manages security contexts,
which are later handed to various applications protected by the RM
(although the RM is not strictly required).  Of course access to the
security context is restricted but we leave that as an open question
for the moment.

There are obvious advantages and disadvantages to this approach.  It
is efficient in one sense because there is only one execution of a
Shibboleth SSO profile per browser session per user.  At the same
time, it is somewhat inefficient since each application makes an
(intra-domain) HTTP request to the SP to retrieve the security
context.  It seems like a reasonable trade-off though.

In terms of maintenance and other technical requirements, one SP is
clearly preferred to multiple SPs scattered throughout the security
domain.  Of course multiple SPs are still possible if the situation
warrants.

This architecture also solves a nagging problem, that is, local SSO. 
A security domain simply deploys both an IdP and an SP (of the kind
described above) to achieve global SSO.  In the eyes of such a
Shibboleth SP, a local user and a remote user go through the same
sequence of steps.

I'm sure this has been considered before but I didn't find anything
along these lines in the archives so I thought I'd bring it up now. 
It doesn't really have much to do with J2EE vs. C++ implementations of
Shibboleth SPs, rather it suggests there might be some benefit of
separating the RM from the rest of the SP.  Is there any value to
that, do you think?

Tom