How to use Edge in combination with SAML tokens

When Apigee is in between the client and the back-end, receiving a SAML token from the client and forwarding this the the back-end. When the back-end then validates the SAML token, it will probably see Apigee as a ‘man-in-the-middle’ and thus disallow the API call… Since the SAML token was generated for a specific client to call the service directly, not for the Apigee Edge domain.

Do you have any advice on how to work with SAML tokens in Apigee?

Solved Solved
0 4 1,480
1 ACCEPTED SOLUTION

Former Community Member
Not applicable

Hi @kbouwmeester looks like in your example your are trying to simply use Apigee as a pass-through proxy and having the back-end or the Service Provider (SP) handle the assertion. In that case you could potentially run into issues with the proxy layer being considered as a MITM attack scenario. To avoid that there are some things to keep in mind:

  1. Its important that you preserve the value of the "RelayState"
  2. Make sure that the resource paths (of the protected resource on the SP) are mapped in a 1:1 fashion at the proxy tier. For eg: if the resource is @ someserver.sp.net/protectme, then a similar resource path demo-test.apigee.net/protectme routes to the back-end SP

Unless absolutely required its a best practice to have Apigee Edge act as the SP and handle the SAML assertion validation on the protected resource's behalf. This has the benefit of abstracting SAML validation at the Apigee layer "one-time" vs having each back-end endpoint implement them individually.

View solution in original post

4 REPLIES 4

Not applicable

@kbouwmeester

To use SAML terminology, API Services can function as a service provider (SP) or an Identity Provider (IP). When API Services validates SAML tokens on inbound requests from apps, it acts in the role of SP. (API Services can also act in the IP role, when generating SAML tokens to be used when communicating with backend services)

Read more here and what is supported by Apigee : http://apigee.com/docs/api-services/content/saml and answer by @Subrak for a similar question herehttp://community.apigee.com/questions/1815/ssosaml-token-handling-in-apigee.html

Refer this if you want Apigee as Idp http://community.apigee.com/articles/2253/apigee-as-a-saml-identity-provider.html but looks like you don't want Apigee to neither be a SP or an IP but just proxy the API calls ? What do you want Apigee to do in the flow ?

@kbouwmeester, I think the SAML token is not generated specific to a SP.

It is just signed by IDP. SP can verify the signature and make sure its indeed coming from the IDP.

The case you are describing - I think the backend should just trust Apigee and accept the assertions sent by Apigee - [Both Backend and Apigee are both SPs to the same IDP]. So no need to worry about man in the middle.

@mukundha@apigee.com, When you say 'Both Backend and Apigee are both SPs to the same IDP' Are you saying that Apigee doesn't need to validate or generate the tokens as the BE and IDP will take care of that and just proxy the API calls ?

Former Community Member
Not applicable

Hi @kbouwmeester looks like in your example your are trying to simply use Apigee as a pass-through proxy and having the back-end or the Service Provider (SP) handle the assertion. In that case you could potentially run into issues with the proxy layer being considered as a MITM attack scenario. To avoid that there are some things to keep in mind:

  1. Its important that you preserve the value of the "RelayState"
  2. Make sure that the resource paths (of the protected resource on the SP) are mapped in a 1:1 fashion at the proxy tier. For eg: if the resource is @ someserver.sp.net/protectme, then a similar resource path demo-test.apigee.net/protectme routes to the back-end SP

Unless absolutely required its a best practice to have Apigee Edge act as the SP and handle the SAML assertion validation on the protected resource's behalf. This has the benefit of abstracting SAML validation at the Apigee layer "one-time" vs having each back-end endpoint implement them individually.