Shibboleth Developers

["Tom Scavo" <>]

This has come up in a couple of separate threads, so I just wanted to
state this user requirement here for the record, as plainly as I can:

Requirement: A Shib SP exposes all valid assertions it receives from the IdP.

A few comments might help clarify this requirement:

- How the SP exposes the assertions is an implementation choice.  The
use cases that are driving this requirement (see below) may suggest a
particular implementation.

- An SP validates SAML responses, and then it validates the assertions
contained in those responses.  The response wrapper need not (and
probably should not) be exposed.

- ALL valid assertions should be exposed.  This includes the assertion
that contains the AuthenticationStatement (or AuthnStatement in SAML
V2.0).

- Regardless of how the assertions are obtained, an identical
assertion bundle should be exposed.  In particular, Browser/POST and
Browser/Artifact should result in the same assertion(s).  Likewise,
attribute pull vs. attribute push should be irrelevant.

I'll just note in passing that the Shib 1.3 SP does not meet this
requirement.  The 1.3 SP exposes the last <samlp:Response> element it
receives from the IdP.  In the presence of attribute query, this is an
attribute response.  If attributes are pushed, the SP exposes the
authentication response (containing two assertions).

This user requirement is driven by two use cases, the Shib-enabled
TeraGrid Science Gateway and the IdP Proxy:

https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/TeraGrid
https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/SAMLIdPProxy

Both of these use cases proxy an assertion to a back end SP.  In the
case of a Science Gateway, this is a Grid SP.  In the case of an IdP
Proxy, this is an ordinary Shib SP, or if the IdP Proxy has GridShib
for Shibboleth installed, this may be a Grid SP as well.

Thanks,
Tom

"A user requirement is like a human emotion.  You may choose not to
acknowledge it, but it exists nonetheless."