6

I have an application workflow like this

(A) User-Agent (browser) <-----> (B) App Server <------> (C) REST service

Suppose the app server (B) is a SAML service provider and user@domain authenticates from the browser (A) to the app server (B) using the Web Browser SSO profile.

How can an application running on (B) authenticate to a REST service (C) as user@domain.com? (Assuming B and C are both SAML SP's on the same IdP.)

If the browser were just making AJAX calls to both B and C, it would be straightforward. But if the REST service is invoked directly from the application, what do you do?

What I'm struggling with: If the application itself is not the SAML SP, but integrated with one (say, using Shibboleth SP and the REMOTE_USER header) your application may never see a SAML assertion. You know the user is logged in and authenticated against an IdP but have no way to get a SAML assertion to hand off to the backend service.

Is there a solution or am I out of luck?

wrschneider
  • 17,913
  • 16
  • 96
  • 176
  • FWIW, this is much more straightforward with OIDC + OAuth2, which explicitly supports the concept of API access token as byproduct of authentication process. Also, simpler protocol means more likely to support directly in the app itself, vs. offloading SSO to a proxy – wrschneider May 05 '21 at 13:44

2 Answers2

1

Yes, there is nothing preventing your App Server (B) to both act as a service provider accepting the incoming assertions from A and acting as an identity provider, issuing its own SAML ticket that it forwards to C.

If you don't have access to the original assertion you will have to issue a new assertion in B. If you do have access to the original assertion you could forward it to C, if C is configured to ignore audience restrictions that limits the assertion to only be valid for B.

Anders Abel
  • 67,989
  • 17
  • 150
  • 217
  • I don't think it's possible to validate the same SAML assertion against single IdP twice – Oleg Mikheev Nov 14 '13 at 07:16
  • Why not? Once you've received the assertion you never contact the Idp for validation. The validation procedure is entirely done by the SP, by checking the cryptographic signature and the id:s of the response and assertion.. – Anders Abel Nov 14 '13 at 07:17
  • so _If you do have access to the original assertion you could forward it to C_ implies that the assertion is forwarded to C without being validated on B? – Oleg Mikheev Nov 14 '13 at 07:25
  • B could validate first or just forward the assertion to C without validating. Depending on if an audience restrictions was applied by A there might be issues validating it on C, unless the audience restriction is ignored by C. – Anders Abel Nov 14 '13 at 07:27
  • to validate assertion SP needs to send it to IdP, right? so even if C ignores audience restrictions, won't IdP be surprised to see the same assertion coming from C (after it received one from B?) – Oleg Mikheev Nov 14 '13 at 07:31
  • No, the SP validates the assertion without contacting the Idp. The only thing the SP needs to know is what certificate the Idp uses to sign the response/assertion. – Anders Abel Nov 14 '13 at 07:35
1

Since you're saying App Server B and REST service C are both SAML SPs with the same SAML IdP, you must already have a mechanism in place which allows a web client to authenticate against C directly (independently of B) via the SAML Web Browser SSO Profile, right? And when this "login workflow" has been completed, the API client has an auth token which represents the fact that "user@domain.com is authenticated by IdP X to use SP C", and can be used to authenticate calls to C for some period of time (until the auth token expires).

But B and C are separate services. And if they have different SAML Service Provider entityIDs registered with the same IdP X, then IdP X will not consider these statements to be equivalent:

  1. user@domain.com is authenticated by IdP X to use SP C
  2. user@domain.com is authenticated by IdP X to use SP B

So there should be no way for service B to use an auth token representing statement 2 above (which it may get from its own SAML SSO login workflow) to get hold of an auth token representing statement 1 above (which can only come from the SAML SSO login workflow for C). Nor should it be possible for service B to "pass through" the API client to the service C SAML SSO login workflow without then losing control over the workflow.

On the other hand, if B and C have the same SAML Service Provider entityID registered with the IdP, then statement 1 above is logically-and-security-wise equivalent to statement 2 above. In this case, the most straightforward solution would be for services B and C to use the same auth token system. Which is really the only way this could work anyway, since if B and C have the same SAML SP entityID then the IdP would have only a single ACS URL configured for both B and C, which means that again as far as the IdP is concerned they are really one and the same SAML SP.

Peter
  • 2,526
  • 1
  • 23
  • 32