Re: [security-services] Comments on proposed NameID protocol

[George Fletcher <george.fletcher@corp.aol.com>]

 From my read of the slides, the issue is that if an SP with an existing 
user base joins a CoT, then how does the IdP know about all the existing 
SPs users? Options are...
1. Do some OOB provisioning process
2. Do something on the fly. In the proposal, the IdP asks the SP for the 
user's identifier.
3. others?

Where I'm confused with the proposal is how does the IdP authenticate a 
user for which it has no credentials? It seems like if an SP joins a CoT 
it has to provide a legacy auth mechanism for its existing users. It can 
also support and upgrade path that allows it's existing users to 
associate/link/bind their IdP identifier to their existing SP "account".

This binding process is sort of the inverse of this proposed protocol. 
Namely that the user is redirected by the SP to the IdP and 
authenticates. When the IdP redirects the user back to the SP, the SP 
looks up the IdP specified identifier in a mapping table to see if it 
"knows" about the user. If it doesn't, the SP gives the user a choice of 
either creating a new "account" or associating/linking/binding it to an 
existing SP account. If the association path is chosen, then the user 
must authenticate to the SP (using the legacy SP identifier) to prove 
ownership of the existing account. At this point the SP updates the 
mapping table so that the user only has to go through this process one time.

Thanks,
George

Scott Cantor wrote:
>
> Regarding the proposal here:
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/34221/SAM
> L%20Name%20Identifier%20Protocol.ppt
>
> As I expressed on the last TC call, I don't really understand the 
> intention
> of this proposal or the claims in the PPT slides about its necessity to
> avoid certain requirements when introducing new SPs into a federation.
>
> Specifically, what is the use case for an IdP caring what an SP's
> identifiers are? We have a particular case of that in SAML, such that 
> an SP
> can attach its own aliases to a federated identity for later use, but that
> doesn't require a new protocol (and is a questionable feature in its own
> right IMHO).
>
> By definition, an IdP knows its users, and it knows their identifiers both
> internally and the ones it creates/issues for use externally. When a 
> new SP
> "appears", there isn't any need that I can see for loading the IdP 
> with new
> information from the SP during the SSO/federation process.
>
> I do understand the use case for "bulk" or OOB federation, but this 
> proposal
> seems to be something different. It's stated purpose is to "free the 
> SP from
> the need to import all of their Users into IdP databases as soon as they
> have become part of an IdP's circle of trust". But that's not a need.
> Instead you simply federate users to the SP as they show up in the IdP->SP
> direction.
>
> So, I think I'm probably missing the point on this.
>
> -- Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>