Shibboleth Developers

[Scott Cantor <>]

Tom Scavo wrote:
> Thanks for asking.  I'd like to better understand the sequence of
> steps a 1.3 SP follows to consume a SAML 1.1 assertion (including
> attribute push).  I've looked at the current alpha version of the Java
> SP but I reckon there has to be more to it than that.

Well, I'll have to dig back into the 1.3 code a little to answer that 
better, but most of the actual SAML processing is inside the 
SAMLBrowserProfile class in OpenSAML.

The API in 1.1 is "packet-oriented", meaning the actual handler just 
grabs the blob that makes up the POST and hands it (indirectly) off to 
the SAML profile class to parse the parameters out. The code in HEAD 
that will eventually be in 2.0 is a pre-parsed API, meaning the handler 
extracts the CGI parameters itself and hands them to the 
profile-specific methods in the library to process.

Artifact processing is hidden behind an ArtifactMapper interface defined 
in OpenSAML but implemented by Shibboleth in libshib-target because the 
code that can map from an artifact to the right IdP is metadata-driven, 
which means it was left outside of libsaml. That will all be replaced in 
2.0.

The rest of the design is mostly one of "wrapping" the OpenSAML classes 
with subclasses that implement Shib-specific processing steps like 
metadata and trust checking.

The part I'll have to review before I can answer is the actual split 
between in-process and shibd because it's very different now. But most 
of the code is running in the shibd half and then relies on the session 
cache API to do a lot of the work that comes after processing the response.

So the nuts and bolts are in SAMLBrowserProfile.cpp (libsaml), 
ShibBrowserProfile.cpp (in libshib), and for artifact/query handling, 
SAMLSOAPHTTPBinding.cpp (libsaml) and ShibHTTPHook.cpp and 
ArtifactMapper.cpp (libshib-target).

The details that contextualize the work are in the code I'll have to go 
refresh my memory on. And if you're talking about attributes, there's 
nothing outside of the session cache and the parts of the in-process 
code that actually push them into headers, which is in shib-target.cpp. 
There are no attribute bits in any of the browser profile code.

Push is implemented today by pushing the SAML response into the cache 
during session creation. If that happens, it assumes push and 
short-circuits the query. If no response is pushed in, no attributes 
were pushed, so it queries (or tries) when the cache entry is "looked up".

-- Scott