Skip to Content
Technical Articles
Author's profile photo Maximiliano Colman

Implementation of Principal Propagation using “saml2-bearer” grant type

Hello hello experts,

Today I want to share one of our common scenarios for principal propagation using Microsoft Azure AD as IDP:

Details:

1.User Authentication:

  • Request:
    • The application performs a SAML request to Azure AD to authenticate the user
  • Response:
    • Azure AD sends a SAML response( it contains the UPN )

2.Application Authorization:

  • Request:
    • The application performs a OAuth Token request to SAP API Management including:
    • SAML response from Azure AD encoded in base64
    • SAP APIM application key
    • SAP APIM application secret
    • Grant type
  • Response:
    • SAP API Management sends a access_token to be used in API calls

3.API calls:

  • Request:
    • The application performs API calls using the access_token
  • Response:
    • SAP API Management performs:
    • Access token validation
    • Call backend system using the UPN from the token
    • Send the backend API response to the application

IMPLEMENTATION

As you may know the “OAuth v2.0 Policies” support only the following grant_types out of the box:

  • client_credentials
  • authorization_code
  • implicit

So you need to implement it manually in your policies using condition flows based on the grant_type “urn:ietf:params:oauth:grant-type:saml2-bearer”( link ), let’s see in details how to do it:

API to get OAuth Token:

1-setSAMLFlag: Check if the “grant_type” requested is “saml2-bearer”

2-replaceClientType: As mentioned before this grant type is not supported so we need to change it

3-getToken: Get OAuth Token( in another words checking if the client_id & client_secret are correct )

4-Validate SAML response: Just validating the SAML response attached in the “assertion” field, for more details of the policies check thisย 

5-Get Principal Configuration Name: At this point we know that the client_id ( the application registered in API Business Hub Enterprise ) is valid so we read the “Custom Attributes” of the application to retrieve the “Principal Propagation Configuration Name”

getPPConfiguration: it gets the application details ( more info )

extractIDPSKeys: it extracts the PP configuration name using a xpath condition

6-Get PP Configuration details: here is where using the PP configuration name we retrieve the IDP issuer & audience allowed for this application via KVMs, and finally we check if the SAML atributes matches with the allowed ones:

7-setUPN: And finally if we reached this point we attach the UPN from the SAML assertion to the generated token

API to consume backend service:

Two simple steps need to added to all those APIs where you need “principal propagation” :

 

1-Verify Token: Policy OOB to verify the bearer token provided by the apps and if it is successful then the policy put the “attributes” of the token as variables in runtime

2-UPN_MISSING: In those APIs where you need the “principal propagation” you must check if the UPN is there

TEST

Get OAuth Token:

POSTMAN

APIM TRACE

API to consume backend service:

POSTMAN

APIM TRACE

As you can see below the UPN is in runtime after the “Verify Token” policy is successfully executed

The rest of the principal propagation flow is defined here

CONCLUSION

Principal Propagation is a must for all those APIs where user context is necessary, and it is very important to have a concept in place to be able to standardize the consumption of them, as you can see it’s a pretty easy task using SAP API Management ๐Ÿ˜‰

Notes:It can be extended for:

  • jwt2-bearer
  • X5092-bearer

Max.

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sebastian Seiler
      Sebastian Seiler

      Hi Maximiliano Colman,

      do you have your policy template available for customer purposes in Neo environment? We have a similar scenario where we need to provide Principal Propagation from an external Fiori Application via API Management to the Backend but we still want to secure the API proxy with OAuth.

      Our requirement is as follows:

      • A Fiori Application is hosted on an external subaccount
      • We link that subaccount with our SAP IAS for user authentication (it acts as a proxy for Azure AD)
      • Due to security reasons we don't want to link that external subaccount directly with our Cloud Connector
      • As a result, we plan to expose the Backend OData services via API Management and usually have a OAuth mechanism in place where at the end a technical user accesses the respective Backend
      • Now the requirement extends in a way where Principal Propagation from that external Fiori Application is necessary

      Your blog seems to be the right solution for that and it would be great if you could share your policy template.

      Thanks & best regards,
      Sebastian

      Best regards,
      Sebastian

      Author's profile photo Dinu PAVITHRAN
      Dinu PAVITHRAN

      Sharing a thought..

      Wouldn't it be better to use Verify JWT policy in your use case? It is only the question of trusting the JWT from the external subaccount, is it not?

      Regards,

      Dinu

      Author's profile photo Sebastian Seiler
      Sebastian Seiler

      Hi Dinu PAVITHRAN,

      the external Fiori application will delegate a SAML assertion (based on the response of the Azure AD) to the endpoint. If the respective application would be part of our subaccount, the connection would be established directly with our Cloud Connector and then would be verified there (in terms of trust).

      In our situation, it is an external subaccount and therefore we need to bypass the connection via API Management due to security reasons.

      In addition, we don't want to create multiple API proxies for one single Back-End API. Instead, we want to have one API proxy which can handle App2App (Technical User) and OnBehalfOf (Individual Person) communication. Both scenarios need to be protected with the same mechanism (OAuth).

      I hope this clarifies our problem . ๐Ÿ™‚

      Best regards,
      Sebastian

      Author's profile photo Dinu PAVITHRAN
      Dinu PAVITHRAN

      Dear Sebastian,

      I missed the fact that the Fiori application is in Neo in your scenario.

      I meant to suggest what is described in Part 4: Configuring JWT token verification flow for SAP Cloud Platform XS UAA | SAP Blogs. But that is only for SAP BTP, Cloud Foundry environment.

      Regards,

      Dinu