[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Question on SP initiated authentication & provisioning first time user
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. The problem appears to arise for the SP to actually determine why a user fails to authenticate with a new target IDP. It could be because they haven't registered yet, or it could be because nameid's have not been properly associated. 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. When the SP redirects the user to the Target IDP, one of 3 possibilities seem to exist: 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. 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? 3. The user does not exist with the IDP at all. Should an UnknownPrincipal be returned? If UnknownPrincipal is returned for 2 or 3, is there a way for the SP to know the difference? 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. 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. 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). Comments? I know this is pretty muddled, but appears to be something the 2.0 specs are dancing around. 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. Phil phil.hunt@oracle.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]