6

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

 3 years ago
source link: https://blogs.sap.com/2021/07/10/implementation-of-principal-propagation-using-saml2-bearer-grant-type/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
Technical Articles
Posted on July 10, 2021 3 minute read

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

1 Like 97 Views 0 Comments

Hello hello experts,

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

2021-07-10-08_30_28-Window.png

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:

2021-07-10-08_43_02-Window-1.png

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

2021-07-10-08_52_17-Window.png

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

2021-07-10-08_54_51-Window.png

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

2021-07-10-08_56_00-Window.png

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 )

2021-07-10-09_05_27-Window.png

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

2021-07-10-09_06_40-Window.png

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:

2021-07-10-11_20_52-Window.png

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

2021-07-10-09_18_21-Window.png

API to consume backend service:

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

2021-07-10-09_36_16-Window.png

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

2021-07-10-09_38_12-Window.png

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

2021-07-10-09_39_48-Window.png

Get OAuth Token:

POSTMAN

2021-07-10-09_46_28-Window.pngAPIM TRACE

2021-07-10-09_45_47-Window.png

API to consume backend service:

POSTMAN

2021-07-10-09_55_04-Window.png

APIM TRACE

2021-07-10-09_50_14-Window.png

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

2021-07-10-09_53_20-Window.png

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 😉


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK