More concrete explanation of identifier flow from SP -> IdP

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

Hopefully this will help clarify why I think the identifier request protocol
is really just a second case of SSO.

The goal, as I understand it, is for the mapping between a user's identity
at an IdP and their "local identity" at some SP to be stored at the IdP
instead of the SP. Simplifying the amount of data the SP needs to store, in
other words.

Today, when you do SSO from IdP to SP with a non-transient identifier, you
implicitly create a requirement for the SP to store something it gets from
the IdP if it wants to recognize the user later. In this use case, the
presumption is that the SP already has a set of identifiers assigned to its
users and it starts a federated relationship with some IdP but wants to
somehow "backfill" those identifiers into the IdP in order to avoid having
to store a new identifier.

Even with SP-initiated NameID mgmt from the 2.0 standard, the SP can only
attach an alias to the IdP's value. After that point, it can use the alias
as a key, but it still has to store the IdP's value. With this use case, the
goal is to remove that requirement.

I won't argue about the use case here, I'm just proposing how I think you
solve it. If I'm wrong about the goal, please correct me, obviously.

My claim is that to solve this, what you have to do is authenticate the user
from the SP to the IdP in order to securely communicate the SP's assigned
identifier to the IdP. Essentially you're federating the user from SP to IdP
instead of the reverse. Once you've done this step, the IdP now has an
identifier from the SP that it can use in the reverse direction when it
authenticates the user back to the SP via his/her IdP-issued account.

The specific NameID formats involved here aren't really important...this can
be profiled on top of any existing format or a new one defined. What matters
is that the IdP understands that it should use that identifier that it
received going forward, instead of manufacturing a federated ID itself. From
the SP's PoV, all it ever sees is that NameID that it passed to the IdP as
part of the setup phase.

In concrete terms, this can be done multiple ways, but could require holding
onto some state to connect the separate SSO transactions. That state can be
handled with cookies, since the sessions with the client are usually no
stronger than that anyway.

One possible use case flow that's fairly stateless looks like this:

1. User is at SP, logged in, and the SP wants to offer him/her the option to
federate with an IdP (or more than one) that it supports. The IdP offers SP
functionality by exposing SP-related endpoints (an ACS).

2. User agrees to this, so SP (acting as a pseudo-IdP) issues an unsolicited
SSO Response/Assertion to the IdP with a RelayState value signifying a
"service" the IdP supports for the purpose of this reverse flow. It's an
"application" function, in other words.

3. IdP receives and validates the assertion (e.g. it can require metadata
about the SP that includes the IDPSSODescriptor role) and locally requires
the user to login to bind the identifier from the SP to the IdP's local
account store. Same as the usual linking approach.

4. The IdP's "application" function exposing this service returns the user
to the SP by issuing its own unsolicited Response/Assertion, carrying the
identifier the SP supplied in step 3.

I don't see how that's a misuse of the SAML authentication protocol at all,
it's using it for precisely the purposes it was intended.

I'm *not* saying a typical IdP or SP would necessarily support all this out
of the box, but that's not the point. I think it's a functional application
of the existing standard that's well within the bounds of what it was
intended to be able to do.

My example above of course doesn't even use any AuthnRequest messages, it's
all handled implicitly. You could add requests to the picture simply by
creating application endpoints at each end that result in the necessary
requests being generated.

-- Scott