Identify which Identity Provider sent the response - OneLogin SAML Java

Question

I have OneLogin's SAML plugin in Java. While trying to process the login response, the API requires the same settings used during the login request. However, I have multiple instances of my web server running, so the response could go to a different server than the request. If the response is not encrypted, I can use the InResponseTo attribute to track the settings between instances of the web server. But if the response is encrypted, there is no way for me to track the settings.

 InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"

How is it possible to identify the Identity Provider's configuration on receiving the response? Any help would be appreciated.

Auth auth = new Auth(settings, request, response); 
// This settings object is needed to decrypt the response
auth.processResponse();
if (!auth.isAuthenticated()) {
   out.println("Not authenticated");
}

Answer 1

If the whole SAML response is encrypted there is no way to find out the issuer. Otherwise the 'Issuer' element of the SAML response would tell you the entity ID of the SAML IdP.

Answer 2

If I understand correctly, when handling the response you need to be able to identify where the request came from?

I think you should be able to do this with RelayState. In their docs (at https://github.com/onelogin/java-saml ) they how the login() method can take RelayState info:

We can set a 'returnTo' url parameter to the login function and that will be converted as a 'RelayState' parameter

String targetUrl = 'https://example.com';
auth.login(returnTo=targetUrl)

Calling the parameter returnTo is misleading in my opinion because it's implying behavior that isn't there. It should have just been called "relayState."

When that comes back in the response, it's just an additional request parameter. In the docs, they show an example of using the RelayState value to route the response, but you can do anything you want with that information:

String relayState = request.getParameter("RelayState");
//do whatever you want based on this request parameter

Answer 3

Question : If the response is not encrypted, I can use the InResponseTo attribute to track the settings between instances of the web server.

But if the response is encrypted, there is no way for me to track the settings.

How is it possible to identify the Identity Provider's configuration on receiving the response?

And I need to find a way to track which IDP the request is going to without the use of session.

Answer :

(1) Each IdP needs to post the SAML response to AttributeConsumingService endpoint such as https://sp.example.org/Shibboleth.sso/SAML2/POST

(2) Different IdP should have different entityID.

(3) SAML 2 supports the encryption of assertions, NameIDs, and attributes.

(4) Quote "How is it possible to identify the Identity Provider's configuration on receiving the response?"

Whether IdP encrypts assertions, NameIDs, or/and attributes is determined by SP. Diffferent SAML SP may have different requirements, such as sign assertion or sign response or encrypt assertions, NameIDs, or/and attributes.

SAML IdP needs to provide the corresponding configuration to meet the requirement of SAML SP. Relying party/SP configuration of Shibboleth IdP at GitHub repository provides a configuration example for selected SAML SPs.

SP uses the entityID of IdP to identify the Identity Provider's configuration on receiving the response if SP have different requirements for different IdPs.

(5) Multiple IdPs can send the response to the same ACS. Usually for each time SP login, only one IdP sends the SAML response to the ACS. Then SP uses its own private key to decrypt assertions, NameIDs, or attributes.

Resolution (Some commercial SAML SPs adopt this solution):

Create different AttributeConsumingService endpoints for different IdPs, that is,

https://your-sp.com/SAML2/POST/idp1

https://your-sp.com/SAML2/POST/idp2

https://your-sp.com/SAML2/POST/idp3

Then different IdP posts the SAML response to different AttributeConsumingService endpoints.

SP uses its own private key/cert to decrypt assertions, NameIDs, or attributes, and then tracks which IDP the request is going to without the use of session.

Note that SP needs to provide different SP metadata with different ACS URL to different IdPs.