OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [security-services] Question on SP initiated authentication & provisioning first time user

My comments below...

On 29-Apr-10, at 7:29 AM, Scott Cantor wrote:

>> I am currently exploring a use case where a user, likely already  
>> known
>> to an SP, now wishes to authenticate via a new "target" IDP. The
>> scenario can also be thought of as provisioning case where a legacy
>> 'SP' user wants to switch to a federated IDP, or an existing  
>> federated
>> user wishes to use a different IDP.
> I think it's worth pointing out that identity portability is not  
> something
> any of the federated identity approaches have really tackled to  
> date. At
> this point, you really have to rely on OOB processes or manual account
> linking steps.
>> For this scenario, let's assume the user is already known to the SP
>> and may have already been authenticated through some classic means
>> (e.g. LDAP) or through a local IDP.
> Doesn't that solve the problem to the extent that you can solve it? If
> you're locally authenticated, then you have what you need to  
> accomplish a
> link, and if the user's not known to the "new" IdP, then why would  
> you be
> sending the user there to begin with?

[Phil] Your first point makes sense. I think this case starts to deal  
with the natural eb and flow as users begin to make choices and as  
enterprises decide to push old fashioned "LDAP" accounts into the  
federation world. In this large use case, the IDP and SP may be in the  
same vertical but they have no formal relationship --> this is why  
they want federation. :-)
>> 1. The user has been previously federated and the saml:Subject for  
>> the
>> SP is recognized at the IDP. --> Normal Authentication completes  Or,
>> the saml:Subject is not provided, but the IDP is able to issue back a
>> NameID that is recognized by the SP.
> It seems unlikely that you'd send a Subject in the request based on  
> the
> identity that you share with the old IdP. That's usually  
> inappropriate when
> using persistent IDs and unlikely to work with any others because of  
> the
> lack of a global identity namespace.

[Phil] I think this is up in the air. The thinking is that the SP may  
maintain or generate a new SP NameID since it already knows the user.  
It is quite reasonable that the SP NameID would be unique to the  
target IDP.
>> 2. The user has not been previously federated, but the user does have
>> an account with the IDP. What are the ramifications if the SP  
>> includes
>> a <saml:Subject> and <saml:Subject> is not recognized? Is
>> UnknownPrincipal returned?
> Second level status codes are up to the IdP in all but a few cases,  
> because
> they rarely get sent anyway (due to security posture). So it's  
> unusual to
> care much, or try to build any flows based on them unless you profile
> something further. But certainly that would be a case for using
> UnknownPrincipal, yes.
>> 3. The user does not exist with the IDP at all.  Should an
>> UnknownPrincipal be returned?
> Same answer. Probably yes, except that revealing that is usually  
> viewed as a
> privacy or security issue and is left to the IdP's discretion.

[Phil] This is what I thought. It's leading me to believe that  
provisioning will have to be accomplished in a more brute force  
approach --> where something like an ManageSubjectRequest (a potential  
new operation) is handed to the IDP by the SP. The IDP is free to  
accept/reject/map the request without having to reveal the original  
status of the user. The risk is for the SP to send across claims to a  
third party who won't accept them. Still if the SP decides they have  
permission of the user, I don't see why not.  Still it would be nice  
if the SP could have some way to do this in a less brute force way.
>> If UnknownPrincipal is returned for 2 or 3, is there a way for the SP
>> to know the difference?
> The IdP might not even know, because if you supply a Subject in the  
> request
> that can't be turned into an identity, it could fail the request  
> before it
> bothers to log the user in.
> This is why it's best not to supply the Subject in such a case. Let  
> the IdP
> do what it can, and then link the accounts.
>> If the SP includes the qualifier AllowCreate=true, does this imply  
>> the
>> generation of a temporary identifier, a permanent shell, or is  
>> totally
>> up to the IDP? Is there a way for the SP to know the difference.
> AllowCreate just lets the IdP mint something new if the SP asks for  
> a format
> that would require a new identifier, or the IdP chooses such a  
> format. It's
> orthogonal to all this. It's also never used with transients, which  
> are
> always "new".

[Phil] That helps a lot. There seems to be a lot of confusion about  
this. Apparently it is being used for temporary identifiers. Might be  
something for the TC to consider clarifying?
>> For the SP, it is useful to know whether scenario 1,2, 3 (or one of
>> the sub-conditions) has occurred. The results would then lead the SP
>> to decide whether to issue a ManageNameIDRequest to add the SP's
>> identifier for the returned saml:Subject.
> The purpose of SP-initiated NameID mgmt is really very separate from
> anything you're talking about here.
>> Or the SP may need to
>> initiate some other form of provisioning request to ensure the user
>> gets a new account set up with the target IDP based on transferred
>> claims from the SP (to be defined).
> Sure, but like I said, if the user says "I want to use this new  
> IdP", why
> would the outcome be likely to be "IdP has no account for user"?

[Phil] Correct. Ideally the user already has an account with the IDP,  
otherwise why choose it. I think the problem is to have enough  
signaling so that the UI can act gracefully. However as discussed,  
security reasons seem to block sufficient signaling.
>> Comments?  I know this is pretty muddled, but appears to be something
>> the 2.0 specs are dancing around.
> I think portability gets tricky, but not so much in the use case you  
> outline
> here. It's a problem when you have no local account, and the user  
> wants to
> move a link from an old IdP he/she can no longer make use of to a  
> new one,
> since there's no longer a way to get the link built.
>> Does anyone have any advise on
>> 'typical' handling of this kind of scenario? Or maybe, there's an
>> entirely different way to set up the exchange so this problem does  
>> not
> occur.
> In the manner you described it, I would say your mistakes are:
> - using a Subject in an AuthnRequest (the use case for that is  
> really not
> this)
> - sending the user to an IdP that the user apparently did not choose
> Of course, a user could make a dumb choice, but the logical thing to  
> me at
> that point is to say "I got an error back from your IdP, are you  
> sure that's
> the one you meant? If so, you'll need to contact it to register an  
> account
> or so forth." I will say the notion of categorizing "services" in  
> metadata
> that an IdP might offer for registering users, affecting per-SP  
> policy, etc.
> has come up.

[Phil] Thanks, those comments help a lot. It seems to me that the  
choices really are:

1. SP does bulk provisioning in an offline/backchannel
2. Invoke some other protocol or SAML extension (e.g.  
ManageSubjectRequest proposed earlier) to enable dynamic provisioning.

> HTH,
> -- 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]