Shibboleth Developers

["Howard Gilbert" <>]

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

No. 

Interface FilterSupport is packaged with the RM Filter in a separate JAR
file that is loaded by the global ClassLoader. In Tomcat, it is in the
/shared directory.

Because the Servlet Filter that provides RM support is global, one copy of
the Class object is loaded, and one instance of the class is created for
every context that defines the Filter in its WEB-INF and supports protected
resources.

A reference to a class implementing FilterSupport is supplied (somehow) to
the Filter class. It is stored in a private static field. It happens to
point to a FilterSupportImpl that was loaded by the /shibboleth context.
Because it was loaded from the /shibboleth/WEB-INF/classes (inside the
context) FilterSupportImpl has access to the services and objects of the
/shibboleth context, including the SessionManager and the Session object
cache. However, it only exposes the specific services that the FilterSupport
interface defines. The Filter can present a Session ID and applicationId and
get attributes for that Session object. If it doesn't know the Session ID,
it can't get anything.

The application can only get data that the filter leaves for it in the
application's own HttpSession object for this request. It has no access to
FilterSupport (which is private inside the Filter class).

This can now be redesigned several different ways. It remains true that the
RM only has access to a set of services, and those services give access to
copies of the data provided that the RM already has the magic token to
identify them.

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

There are an increasing number of Web applications that spread themselves
across multiple directories and then communicate through some in-memory
backdoor. This was what EJB was supposed to be for. If J2EE had been fully
embraced or could be assumed everywhere, then what I am calling the
/shibboleth context (SHAR) would be an EJB, the FilterSupport would be one
of its remote interfaces, and the only thing in the /shibboleth directory
would be a Web Service interface to it. However, the existence of
cross-context communication doesn't mean that things are insecure, any more
than the presence of kernel calls in the OS means that the system is
insecure. You get information from the kernel, but only information that you
are allowed to see.

There is no security threat to the /shibboleth context unless you believe
that the JVM has failed in all of its basic security responsibilities. If
you don't trust the JVM, then yes you have to run in another JVM. This may
mean running two Tomcats behind an Apache, but you have to say that. "vhost"
doesn't necessarily mean two JVMs. 
 
> > The /shibboleth context does write a real Cookie of its own.
> 
> What are the attributes of this cookie?

What do you want them to be? Right now it is an in memory persistence
cookie. I suppose I might expire it, but it is really the Session object
that it indexes that I want to expire, and if I do I will generate better
human factors if I "tombstone" the Session object so I can distinguish a
session that expired from one that is invalid or never completely created.
But the final details are subject to discussion between now and, well as
long as we want to debate it.


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

I write a Shibboleth cookie that has the Session object ID. Tomcat writes
its own cookie to find the HttpSession object for this Browser in the
/shibboleth context. I don't put any security data in the HttpSession object
in the /shibboleth context. However, I do put trace data there, if you use
the Log4J appender I provide. That way if you try to access a resource, and
something screws up, the entire POST processing and Attribute processing
trace for your request are in a buffer chained to your HttpSession. There is
a diagnostic servlet in the /shibboleth application that will send this back
to you. If this trick is added to the HS and AA, then a programmer can
determine exactly what went wrong in any failure, without having to dig
through a ton of log records for other requests.

Since Scott points out that the HttpSession cookie values is not fully
secure, I may change the diagnostic servlet to require both cookies. This
will certainly, however, require a tombstoned Session object if the POST is
rejected and the Session object remains but is not valid.

> 
> 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 design is supposed to allow this, although FilterSupport is now an RMI
or WS service.

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

Right, that is what is being done now.

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

If the cookie is domain wide (yale.edu) then it gets presented to every Web
Server at Yale. That may be broadcasting things a bit too widely. If it is
scoped to securesubnet.its.yale.edu its probably not a bad thing. But again
that is a particular deployment of the current design.

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

RMI, CORBA, EJB (remoting handled by the container), HTTP, Web Service, if
pressed I could probably come up with 10 more brand names. You remote the
FilterSupport interface. If you insist on supporting 20 remoting protocols,
then I am definitely going to wire them up with Spring and/or HiveMind. I am
not going to try and do this just with the configuration file architecture.

Also, although RMI or EJB is the easiest to use, I feel strongly that you
should support some Web Service interface so a .NET RM can use the Java SP
(although a couple of commercial Java versions of .NET Remoting are in my
safe list if anyone really pressed me to fill in that list of 10 more
options I so recklessly promised I could do in the previous paragraph).

Note also, that the RM (the Filter if you don't write your own RM) will
still be talking to the /shibboleth context in his JVM. You want to do this
thing, you don't want to rewrite the Filter for each remoting protocol. Its
just that when the SP and RM are split, the /shibboleth context on the RM
machine is a proxy that only supports the FilterSupport interface and
forwards it across machines.

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

This is my original design, but Scott believes in a "one SP per application"
view for real security. You can deploy my code either way.

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

Any inefficiency is inevitable given the deployment pattern. If you want to
put the SP and RM on two different machines, they have to communicate
somehow. I think the cost of such communication is trivial, but if it
matters, then put both in the same JVM if you want. That is, the design of
the code doesn't force the deployment to be any less efficient than it has
to be given the choices you make.

> 
> 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 is a choice. Different people have different views. Design in the
option and let the customer choose. Don't spend time arguing about what is
the best SP configuration cause, even if you could find it, the requirements
many change next week.

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

See my papers on CAS and Shibboleth. The question isn't whether Shibboleth
can create a local SSO. It can if that's how you start. The question is,
given an existing SSO can you "globalize" it by adding Shibboleth for
off-campus authentication. Without requiring anybody to change anything to
continue to get local service.