Shibboleth Developers

[Scott Cantor <>]

> More specifically, the SAML assertion consumed by the SHIRE 
> is in the form of an HTTP POST to a specific URL. I tend to 
> regard everything before the POST (any previous URLs, WAYF 
> stops, redirections, and institution specific Web Signon 
> procedures) as implementation details. Shibboleth 
> specifically leaves these issues vague and up to the code in 
> question. The first concrete protocol element is the format 
> of the POST. Even here, however, there is uncertainty about 
> the URL to which the POST is directed, and the question of 
> redirection after the POST.

Part of establishing a target is assigning and publishing that POST URL.
That is the assertion consumer service and it is a known/fixed location.
Right now we don't have target metadata, but that's changing shortly, at
which point the SHIRE URL will be part of that target definition process.

As far as the redirect after, I don't suppose Shib cares much about it, but
the user obviously does. For the time being, we insist that the TARGET
parameter in the form is the URL to go to. I think that will change in the
future, to prevent that info from being known by the origin when it doesn't
need to be, but that's a future enhancement.

> The user makes a request to the application URL.
> The Shibboleth filter processes the request and redirects it 
> as needed to the WAYF, HS, ..., until the HS eventually POSTs 
> the architected assertion containing the SAML handle 
> assertion. This POST can go back to the same application URL 
> where it again is processed by the filter.

Well, it sort of could today because SAML leaves some things open to
implementations, but that's not going to continue. Liberty really, really
needs a stable assertion consumer URL and SAML 2.0 probably will too by
inheritance of that work. Not 100% for sure, but I strongly suspect it.

> 1) What does the getUserAttribute() method look like and how 
> is it chained to the extended Request object? Do we need any 
> other methods to force session termination or other lifecycle things?

In such a model the filter would presumably make that determination before
forwarding the request. Since we currently can't determine whether a
session/handle is valid w/o fetching attributes, you actually have to get
the attributes ahead of time, as we do now. Timeouts are a different matter,
that might be locally enforced by the filter, yes.

> 2) What does the Web Service look like and what gets passed 
> when the SHIRE redirects the request to the application so 
> that the application can find the Web Service and present the 
> Session identifier to obtain attributes?

Well, Walter and I were, I think, hoping that the J2EE session model would
save us here, and avoid the need for both a physical session handle separate
from that, and from any web service stuff. It occurs to me that maybe
sessions in Tomcat are confined to a single context. I can see how that
creates a problem for the "single SHIRE URL" model I want, but seems like
there should be a way around that. Something simpler than a web service
anyway. That creates a lot of nasty questions about securing that query.

If we absolutely *had* to remote the query right off the bat, the obvious
choice would be to simply use SAML protocol again, with the local web
service acting as a proxy AA forwarding the same assertion it got from the
real AA.

> These are the local and remote versions of the same 
> operation. Now strictly speaking, a version 2) operation will 
> be hidden behind the filter as the implementation of a 
> version 1) call, so the application doesn't care what the Web 
> Service looks like, but I think we should standardize it as a 
> potential public API for situations (like .NET) where the 
> Java Filter isn't sufficient.

As I said, if we have to do this immediately, we shouldn't invent a new
protocol. SAML Request/Response would do the job.

> Filters get initialization parameters from the context 
> configuration. Global stuff gets initialization parameters 
> from the global server configuration. This is just a case of 
> deciding what to carry over.

Yes, but as we found with Apache, it's turned out to be a bad idea to rely
on target-environment-specific configuration when possible. We used to put a
lot of stuff in httpd.conf, but it's much better to consolidate things
outside the web server's config, and I think the same goes for Tomcat,
personally. It's always a trade-off, but I think we got this part right.

-- Scott