The SAML 2.0 Bearer Assertion Flow typically comes into play when we want to give a client application's users an automated access to remote resources or assets which are protected with the OAuth2.0 protocol.
A common assumption is that the user's remote resource access scope will be determined by the user's identity as it is known on the client application side.
Assuming you have the right level of access to your target SFSF system you may now create there your own OAuth2.0 client application. Let's call it Quovadis-SFSF.
One piece of information you will need from the Destination service created on SAP BTP sub-account level is the trust's public key that you will need to insert into the Quovadis-SFSF OAuth2.0 client application as depicted below:
Assuming you will be rehearsing the access to the destination
service APIs with the SAP Business API Hub sandbox environment
you do not need to write a single line of code.
All you need to do is create a definition of your destination
Your destination will be called by the destination
service find api any time you need to procure a bearer access token
to authorize access to remote resource.
You can create a destination definition using the GUI of the SAP BTP sub-account or programmatically calling the destination service APIs.
Let's rather do it programmatically as follows:
Post (=create) a new destination:
Put (=update) an existing destination:
Reference the URL value please refer to the following SAP note
2215682 - Successfactors API URLs for different Data Centers
Most of the values will need to come from the OAUTH2.0 service
which is used to protect the remote resource you are trying
to have your user get access to.
For the sake of simplicity and for sandboxing purposes only
we may use a technical user, a user that must exist in
both the client application and the target backed end system.
In a productive scenario you would rather be using
a user's JWT token instead! This user's JWT token would need
to be passed in the X-user-token header of the destination
service find destination API call.
Then, the destination service will internally generate a saml assertion
for user's authentication with the:
- destination service x509 trust as the assertion issuer,
- audience as the assertion audience (service provider),
- tokenServiceURL as the assertion's recipient (ACS=Assertion Consumer Service)
- and both the apiKey and companyId properties.
This assertion will be used on the IDP-initiated flow with the
recipient acting as ACS (Assertion Consumer Service).
The resulting idpMetadata string is a base64-encoded generic IDP XML metadata. It does contain the x509 certificate but is not configured for any specific scenario (i.e. CF to CF, CF to Neo etc.) which might require additional properties.
For convenience, it the can be decoded into plain XML with any saml assertion decoder and then formatted with pretty print as follows: