Solved: SSO/SAML Token handling in Apigee

santosh_ghalsas · 03-06-2015 04:33 AM

Hi,

I want to design an API that handles SAML token handling. The API should take basic authentication and parameters required from mobile app, send the same to IDP to receive the SAML token from IDP and send that token back to the mobile app. Once the token is used to consume service then the API should send that token to backend where the token will be validated by backend and service access will be permitted.

I am not sure if the scenario works exactly the way I explained above but basic understanding is clear that the backend service should be accessed over the SSO/SAML.

Please let me know if I can use the existing SAML policies for this or is there any sample proxy that I can refer to.

Thanks,

Santosh Ghalsasi

Report Inappropriate Content

This is not the typical use case addressed by existing SAML policies. In a typical SAML/SSO use case, mobile client is authenticating with SAML IdP directly, acquiring SAML token and presenting the same to the API proxy at which point ValidateSAMLAssertion policy can be used to extract SAML attributes and verify the token. This way API proxy never gets to see the end user credential (password).

In this case, since API proxy is mediating the login on behalf of the user, one option to consider is to use OAuth between Mobile client and API proxy while using SAML between proxy and backend. i.e. simplify the interaction between Mobile client and proxy using OAuth while using the same proxy to hide all the SAML token handling complexity. In that approach, the proxy will create an OAuth token for the mobile app after authenticating to the SAML IdP using a service callout. The proxy will maintain state by storing the SAML attributes in theKey Value Map and associating the information with SAML token. Subsequent interactions from the Mobile app will result in OAuth token being presented to the API proxy and upon validation the proxy can extract the SAML token and present that to the target API.

It will be helpful to understand all the constraints you have w.r.t to IdP and the backend service that require the SAML token so we can figure out the right solution model for the problem.. It sounds like the backend will require SAML token with every interaction by the user using the mobile App.

View solution in original post

Report Inappropriate Content

This is not the typical use case addressed by existing SAML policies. In a typical SAML/SSO use case, mobile client is authenticating with SAML IdP directly, acquiring SAML token and presenting the same to the API proxy at which point ValidateSAMLAssertion policy can be used to extract SAML attributes and verify the token. This way API proxy never gets to see the end user credential (password).

In this case, since API proxy is mediating the login on behalf of the user, one option to consider is to use OAuth between Mobile client and API proxy while using SAML between proxy and backend. i.e. simplify the interaction between Mobile client and proxy using OAuth while using the same proxy to hide all the SAML token handling complexity. In that approach, the proxy will create an OAuth token for the mobile app after authenticating to the SAML IdP using a service callout. The proxy will maintain state by storing the SAML attributes in theKey Value Map and associating the information with SAML token. Subsequent interactions from the Mobile app will result in OAuth token being presented to the API proxy and upon validation the proxy can extract the SAML token and present that to the target API.

It will be helpful to understand all the constraints you have w.r.t to IdP and the backend service that require the SAML token so we can figure out the right solution model for the problem.. It sounds like the backend will require SAML token with every interaction by the user using the mobile App.

sunandita_dam

@Subrak : In the suggested approach above, if app credentials are no longer valid in IDP then how that situation be handled as at apigee layer, the stored SAML token is passed rather than going to IDP for validation at every interaction.