RE: [security-services] Minutes: SSTC Conference Call (September 22nd, 2009)

["Scott Cantor" <cantor.2@osu.edu>]

> Solution 2: The SP does the federation / the IDP creates an ID_SAML for
the
> User
> 
> Disadvantages:
> - SP has to do the federation.
> - Delegation (eg, vacation replacement): having to set up a delegation in
> each different SP separately is similar inconvenient as not having a SSO.
> Hence, a central point of policy management and enforcement is important.

Not knowing what you mean by delegation, I'm not prepared to say anything
for certain, but as a general matter delegation can be scoped to particular
services from the IdP end.

> Solution 3: The IDP does the federation
> 
> Advantage:
> - There is a central point of policy management and enforcement, namely,
the
> IDP, who does the federation.

I imagine this is related to the delegation point you made that I don't
really understand.

> - The User can have more than one account at the SP. The IDP stores these
> multiple accounts and offers a selection to the User. This is not
possible,
> in case the SP does the federation.

If you login and supply an identifier to the SP, and the SP wants to link
that to multiple local identities, it's free to do that and can offer the
user a choice as to which one to use. An IdP could also offer user's control
over the creation and use of multiple pairwise identifiers with an SP and
select among them on the IdP side. None of that requires the SP to control
the identifier assignment at the IdP.

> If, in case of Solution 3, the IDP does not know the User's ID_SP, then
the
> IDP needs to send a corresponding request to the SP, who then sends ID_SP
> back to the IDP. This is exactly what the SAML Name Identifier protocol
aims
> to provide.

Your sequence diagram doesn't provide me with an indication that you have a
secure protocol for doing this. Perhaps it's just a mistake, but you have
this shown as a backchannel exchange between the IdP and SP, and that won't
be correlated to a particular user. There's no "handle" to use to reference
"the guy in front of me at the browser" in other words.

If you instead mean for this to be front channel, I still think it's
difficult to pull off safely because the ability to assign the identifier in
reverse is really just reversing the role of the IdP and SP in the flow. The
"SP" has to become an IdP and issue what amounts to an assertion in order
for the IdP to be able to validate the user's right to "be" that identifier.

> SC: (re second bullet on slide 3) Not clear why you need anything more
> than Web Browser SSO. Why does the SP send an identifier in this case?
> 
> <CG>
> Web SSO is and was an important contribution of the SAML standard.
However,
> the service and IDP landscape has changed so that no longer one IDP
provides
> SSO for different (dependent) SPs, but SPs may select the IDP on a per
user
> basis.

That's possible now. Nothing's new about that.
 
> To phrase it stronger: the privacy-conscious user may want to choose
> to be federated or not to be included in a potential federation.
> Furthermore, we are not going to restrict SSO to Web applications.

Doesn't matter whether it's web-based or not. My point was that the model is
for the IdP to assign the identifier, because if you turn it around, the SP
just becomes an IdP anyway.

-- Scott