SAML and back-end REST service authentication

Question

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 [email protected]? (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?

Answer 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.

Answer 2

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 "[email protected] 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. [email protected] is authenticated by IdP X to use SP C
2. [email protected] 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.