CODEWITHSUNDEEP
salesforcesamlf5
thebiglebowski11
thebiglebowski11

Reputation: 1461

Reusing SAML assertion

I am implementing single sign on with multiple SPs. Here is my basic understanding:

1) Browser(User) requests resource from Service Provider (SP).
2) SP Redirects (with SAML Request) to Identity Provider (IdP).
3) Since it is first login, User gives the (IdP) his/her valid credentials.
4) IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.

Now let's say I have Service Provider A and Service Provider B. A user has completed the step about for Service Provider A. From service provider A (salesforce.com in my scenario), I have written a server-side method which instantiates a callout to an endpoint on Service Provider B. Is it possible to re-use the SAML assertion in this case? I.e. will service provider B trust the backend method?

Upvotes: 2

Views: 2427

Answers (2)

vap78
vap78

Reputation: 1061

The short answer - no if Service Provider B is implemented as a standard SAML 2.0 SP.

SAML 2.0 assertions are "targeted" and signed. They have a specified audience and a recipient URL. You cannot change them without breaking the signature. The assertion received by SP A contains the name of SP A as audience and the ACS end point of SP A as recipient URL. Such an assertion will not be accepted by SP B.

What prevents you from just calling SP B in a standard way and let it initiate its own SAML 2.0 flow? Another option would be to perform an IDP-initiated SSO flow for SP B. Not all IDP implementations support it though.

Upvotes: 1

Vladimír Schäfer
Vladimír Schäfer

Reputation: 15533

You would have to customize Service Provider B in order for it to accept, understand and interpret the Assertion obtained by Service Provider A. It would certainly not work out-of-the-box.

The SAML Assertion included in the SAML Response to Service Provider A contains pieces of data which correlate it with the original SAML Request and define recipients of the message (for example using elements SubjectConfirmationData and Audience). The Service Provider B would need to ignore values in these fields, as it is actually not the indented recipient of the Assertion.

The problem of how to broker trust between two machines where user's identity is asserted by an identity provider can be solved with multiple standard approaches. One is to use a Session Token Service (based on WS-Trust) which defines how to request and issue tokens to 3rd party services. Another is to use OAuth 2.0. You could of course also simply authenticate Service Provider A to Service Provider B using a custom scheme with a password, HMAC, ...

Upvotes: 2

Related Questions