Shibboleth Developers

Title: Re: [Shib-Dev] protocols and profiles

At 4:32 PM -0400 10/27/09, Soner Sevinc wrote:

> Hi,
> Maybe I should have checked source code first, but would like to see
> if there is a quick answer.
>
> If I would like to have such an authentication such that SP should
> allow a resource only if IdP1 AND IdP2 provides certain attributes for
> a user, where we can increase the number of IdPs, or possibly allow
> for disjunction of them, as well, then would SAML support such an
> authorization scheme, or how "easy" would it be to implement
> it as a new protocol/profile?

Shibboleth started life as an open source implementation of some of the SAML Web SSO profiles and functionality. Since then, Shibboleth has evolved to include support for other protocols.

More recently, we've started to build functionality to address "advanced" use cases; this is sometimes done using profiles composed from multiple protocols. These go far beyond basic Web SSO functionality. Scott mentioned one example in his answer -- support for "aggregated identity" -- identity composed of attribute assertions from multiple IdP sources. As he mentioned, there seems to be a lot of interest in applying this to a use case where a person authNs at their campus, but their permissions are obtained from their identity at one or more VOs.

We're also now shipping support for "delegated assertions". A person can authN to a portal using Shibboleth; a portlet/channel can then obtain a delegated assertion from the original IdP and present it to a backend service (essentially "logging in" as the original user). The backend service can validate the assertion, and see that its been delegated. The delegated assertion could contain a different set of attributes than the original assertion. More info available at: https://spaces.internet2.edu/display/ShibuPortal/Home.

The current Shib release contains support for both of these features.

As Scott mentioned, unless we have more detail, we can't really make any statements as to whether either of these features are applicable to your situation.

>
> To ask it in another way, I see that some
> protocols/profiles are not implemented yet, at https://spaces.internet2.edu/display/SHIB2/ShibProtocols . For
> example, back channel support in single logout protocol is still
> waiting to be implemented. What would you consider to be the
> problematic part that makes it more time consuming to cover all use
> cases at http://www.oasis-open.org/committees/download.php/507/draft-sstc-saml-reqs-01.pdf ?

SAML defines the over the wire protocols. Unfortunately, it doesn't define the interface between the SAML SP implementation and the application. In many cases (depending on how the application developer and the deployer implemented security), and particularly with back-channel logout, logout will only be successful if the application session is destroyed. Destroying the SAML session isn't sufficient. We can define such an interface (and Scott has done just that), but applications haven't implemented support it.

We hear a lot of requests for logout support. But, as soon as we explain some of the issues and concerns, we usually hear "I didn't realize it was so hard".

https://spaces.internet2.edu/display/SHIB2/SLOIssues