On 12/9/14, 6:05 PM, "Lucas, Mike" <> wrote:
>Could this type of “establishing connection” be done as a regular SSO
>login (either unsolicited Response from IdP, or AuthnRequest from SP to
>IdP and then Response back to SP), except that:
>-
>When the SP realizes it doesn’t recognize the identifying info in the
>Assertion, it prompts for authentication (e.g. login form).
>-
>Then, assuming authentication was successful, the SP stores the
>identifying info from the Assertion ( it could simply be random
>persistent name identifier that was generated by the IdP).
Yes, that's the original Liberty "federation" use case idea back when
account linking between vendors was a dominant use case. Much of the
policy signaling in the SAML spec that rarely if ever gets used was put
there because of that use case.
>Would that be considered a “normal” way of establishing connection?
It's not terribly common in practice because federation has tended to be
among organizations operating in more clearly defined roles, and not a
consumer thing.
>
>What about switching it around? i.e. for the purpose of establishing
>connection, Site B could act as the IdP and send its identifying info
>(such as Site B-generated persistent name identifier)
> to Site A in a Response. Site A would then store this info so that it
>can use it in future SSO logins, when it is acting as the IdP. Is this
>reasonable?
Not in my opinion, but that's what SPProvidedID is for.
-- Scott
