Re: [saml-dev] SAML & establishing an SSO connection

[Will Hartung <willh@mirthcorp.com>]

You're talking about fundamental provisioning problems, which aren't
really covered by SAML use cases.

There's certainly no reason that you can't have the SP ask the user
for additional information the first time it sees a new identifier,
but then you have issues about how to keep John Smith from saying that
he's Mary Johnson.

You could ask for (during initial configuration, out of band)
additional demographics from IdP perhaps to facilitate matching, but
this is all something between you and your IdP.

In our case, we have our SP auto provision based on minimal
demographics from the AuthnResponse. The IdP is considered a trusted
source of truth, and so can use that information to self-deploy an new
user when it first shows up.

We also add extended identifiers in the IdP that the apps can use.
Finally, we have Alias Domains in our IdP so that while the IdP has a
single identifier domain, each app can have their own. But much of
that is managed through external integration workflows.


On Tue, Dec 9, 2014 at 10:05 AM, Lucas, Mike <Mike.Lucas@gwl.ca> wrote:
> Imagine we want to have SSO between Site A and Site B, and the normal usage
> is for Site A to be the IdP, and Site B to be the SP.
>
>
>
> However, before the “connection” is established between these sites for a
> particular principal, Site A and B don’t have any common information about
> the principal to agree upon. They don’t want to use a back-channel, so they
> need a use case to establish a common identifier.
>
>
>
> 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).
>
> Now the SP can always figure out the user/principal based on the IdP’s
> identifying info, so future SSO logins can skip the above.
>
>
>
> Would that be considered a “normal” way of establishing connection?
>
>
>
> 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?
>
>
>
> Thanks
>
> michael lucas  |  Senior Software Developer  |  Great-West Life

-- 
This message, and any documents attached hereto, may contain confidential 
or proprietary information intended only for the use of the addressee(s) 
named above or may contain information that is legally  privileged. If you 
are not the intended addressee, or the person responsible for delivering it 
to the intended addressee, you are hereby notified that reading, 
disseminating, distributing or copying this message is strictly prohibited. 
If you have received this message by mistake, please immediately notify us 
by replying to the message and delete the original message and any copies 
immediately thereafter.  Thank you for your cooperation.