Shibboleth Developers

["Scott Cantor" <>]

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

It wasn't meant to meet that requirement. It's purpose was to expose
XML-valued attribute values that can't be serialized into a string
automatically. The authentication information is exported separately.

Exporting entire assertions is generally only useful when those assertions
can be reused in some fashion. This is not realistic with SAML 1.1 SSO
assertions because they expire in minutes to prevent misuse.

Exposing SAML 2.0 assertions is something we probably will support, but even
that isn't going to be all that useful in most cases. I'm sure that will
extend to SAML 1.1, but that doesn't mean you should create profiles to
reuse assertions that are no longer valid and were never intended to be
forwarded.

> 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

That proxy profile is at odds with the same term used in SAML 2.0, so that
seems potentially confusing. I'd at least qualify it somehow as a different
profile.

-- Scott