CODEWITHSUNDEEP
single-sign-onsamlopenid-connect
Steve Rukuts
Steve Rukuts

Reputation: 9367

Is there a standard for two Relying Parties with a common Identity Provider to share information?

Here's a situation that I have been considering recently:

  1. A client has their own Identity Provider (i.e. ADFS)
  2. My company's web application (Application A) supports SAML and OpenID Conect
  3. Another company's application (Application B) also supporting SAML and OpenID Connect
  4. Both Application A and B are associated with the Identity Provider
  5. It is possible to ask the authors of Application B to change it

Application A and B have links between each other. In order to get from Application A to B, the workflow looks like this:

  1. User is logged in to Application A
  2. User clicks on a link to Application B
  3. User is now at the Application B sign-in screen
  4. E-mail address is entered
  5. User is bounced to ADFS or similar system
  6. User is now logged in to Application B and can see the resource

We would like to streamline the user experience:

  1. User is logged in to application A
  2. User clicks on a link to Application B
  3. Application B somehow detects that the user is using SSO and redirects them to the appropriate page
  4. User is bounced to ADFS or similar system. Hopefully if the last login wasn't too long ago, the user should be automatically authenticated.
  5. User is now logged into Application B and can see the resource.

Right now, we're thinking that we rewrite our outbound links to Application B like so: https://example.com/[email protected]&url=/the-resource

This would allow Application B to detect if SSO was required, and I guess we'll do this if there's no other option. I would however like it if there was an already established standard for doing this, so we could just ask other companies to implement the same standard.

I know that detection of the SSO system is left up to the Relying Party, so perhaps this is just something that we have to work out with the authors of Application B.

Is there a standard for RP to RP data interchange where both RPs have a common Identity Provider?

Upvotes: 1

Views: 121

Answers (4)

codebrane
codebrane

Reputation: 4620

Sounds like you need a 'WAYF-less' URL entry point for Application B. WAYF = Where Are You From? and was the old way of finding out which IdP a user was associated with. If the user is already authenticated at Application A, then Application A knows the entityID of the IdP for that user. The user's IdP will also have an authentication session for them as they have already logged in to Application A.

So you could have in Application B:

https://applicationb.com/sso?entityID=https://some.idp.com/shibboleth

Application B then loads the SAML metadata for the entityID and automatically redirects the browser to the SSO URL associated with the entityID and the IdP will redirect the user back to Application B's SAML consumer endpoint. The user will not see another login screen (unless their IdP session has expired) and Application B will get its own set of SAML attributes.

Sharing attributes in the URL isn't ideal as Application A might be entitled to see the user's email (as released by the IdP) but Application B might not. So it's best to follow protocol and let the IdP release the attributes to Application B, separate from anything Application A knows about the user.

The only thing A is sharing with B is the entityID of the user's IdP. That allows B to begin the SAML flow and get the attributes for itself.

Upvotes: 1

judielaine
judielaine

Reputation: 197

If by "share information" you mean "Provide a hint as to the user's IDP" there is a standard being developed, https://ra21.org/ . Before RA21 started, i had a similar thought that i shared at IIW 22 (https://www.internetidentityworkshop.com/proceedings.html). It was essentially what you are proposing: put an IDP hint in the URL. The response was positive, but few folks had a use case where they could use it.

I note that the proposal (see Tuesday 5G, p 45 of the proceedings) the hint we discussed for OpenIDConnect would be the issuer ...redirect?issuer=[issuer]... See the notes for the specification justification.

If you are sharing a SAML IDP, you could take a look at http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/cs01/sstc-saml-metadata-ui-v1.0-cs01.pdf §2.2 Discovery Hinting Information . If your SAML IDPs included the child element in their metadata, that would be a straightforward way for the IDP to establish how RPs could hint to each other, and the value in the URL could be ...redirect?DomainHint=[whatever].... It's been some years and i can't remember

As a final note, sending the email address in the URL would violate so many privacy expectations. Do not put PII in your URL!

Upvotes: 1

ComponentSpace
ComponentSpace

Reputation: 1367

I'm afraid there is no standard for SAML relying parties/service providers to exchange information. All protocol messages are between the claims provider/identity provider and relying party/service provider.

In lieu of a standard, what you're proposing looks reasonable.

Upvotes: 1

mackie
mackie

Reputation: 5264

I think you're on the right track. It's entirely up to the RP whether it thinks it should use the IDP or not so you just need to pass enough context when you navigate to app B so it can make that decision. So in this case the "standard" would be front channel navigation to a known endpoint with the information you require in the query string or hash.

Upvotes: 0

Related Questions