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

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

> 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?

> 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.
 
> 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.

> 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".

> 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"?

> 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.

HTH,
-- Scott