Question on SP initiated authentication & provisioning first time user

[Phil Hunt <phil.hunt@oracle.com>]

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