Skip to Content.
Sympa Menu

shibboleth-dev - RE: [Shib-Dev] protocols and profiles

Subject: Shibboleth Developers

List archive

RE: [Shib-Dev] protocols and profiles


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: [Shib-Dev] protocols and profiles
  • Date: Tue, 27 Oct 2009 19:19:03 -0400
  • Organization: The Ohio State University

> 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?

Not in isolation, and very difficult depending on the specific flows
involved. That's an extremely non-specific and high level description that
doesn't capture the necessary kinds of details.

Assumptions not limited to the following all have huge impact on the degree
of complexity, the pieces that would have to be built, and the liklihood of
building a user experience that any normal person could use:

- Role of authentication vs. stand-alone attribute sources
- Required discovery and security models and proofs required to locate and
obtain attributes
- Privacy and ability to correlate/link identities with or without user
involvement
- Role of user consent vs. out of band policy
- Specific application flows and protocol assumptions

I built a plugin for aggregating attributes using shared/public identifiers
and an extremely basic security model that just emulates the ideas
originally represented by networking LDAP servers together. It seemed to
interest a lot of people at the last member meeting, because it avoids most
of the harder problems that come up when privacy and user consent have to be
dealt with. But that doesn't mean it solves those problems, nor am I
claiming those problems shouldn't be worked on.

> 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 ?

Offhand, in no particular order:

- extremely limited resources
- lack of consensus on approaches
- lack of evidence that solutions are likely to be adopted

In a world where OpenID, and to a different degree OAuth, reinvent the most
simple uses of SAML routinely, it's not much of a stretch to argue that the
world isn't ready or willing to embrace much else.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page