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:
- The application performs a SAML request to Azure AD to authenticate the user
- Azure AD sends a SAML response( it contains the UPN )
- 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
- SAP API Management sends a access_token to be used in API calls
- The application performs API calls using the access_token
- SAP API Management performs:
- Access token validation
- Call backend system using the UPN from the token
- Send the backend API response to the application
As you may know the “OAuth v2.0 Policies” support only the following grant_types out of the box:
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
Get OAuth Token:
API to consume backend service:
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
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:
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:
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,
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?
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 . 🙂
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.