The focus of this instalment is to describe how to fully automate the implementation and the deployment of the OAuth2SAMLBearerAssertion flow with SAP BTP Destination service APIs, including when using your own x.509 trust with the destination.
Please note all the code snippets below are provided “as is”.
All the x509 certificates, bearer access and refresh tokens and the likes have been redacted.
Using the generic (default) Destination Service trust
The above statement is, to some extent, no longer true as SAP BTP destination service has added a new REST API endpoint allowing you to download the generic SAML IdP metadata (that precisely contains the x.509 certificate) , namely /saml2Metadata.
Let's see what it takes to use a custom X509 certificate key pair with the destination service.
Using the SuccessFactors generated X.509 key pair
Indeed, Destination Service certificate APIs allow to manage your own key-stores with certificates and have them assigned to destinations programmatically.
Let's see how this can be done with a custom trust (certificate) generated by a SFSF tenant (Admin Center/Manage OAuth2 Client Applications)
Generate x509 certificate. Only the CN field is mandatory. The value you enter as CN will become the name of the issuer in the signed saml assertion
Download the generated key pair into a local text file. You will need it later.
Register the application.
Good to know:
the SFSF-generated key pair is in PKCS8 format and base64 encoded
both the encrypted private key and the public x509 certificate of the key pair are already flattened into single line strings
PKCS8 format allows for adding proprietary attributes at a tail of of a key. And this is the case with both keys generated by SFSF. Thus, after base64 decoding, please consider removing the trailing tags (###xxxxxxxx) from the either key of the pair.
b. Next step is to convert the key pair into a keystore file format that will be accepted by the DestinationService.
Good to know:
I have only tested either .pfx and .p12 PKCS12 keystore formats so far. These are the most popular containers of the certificate key pairs (private+public keys).
Supported certificate file extensions are: ".jks", ".crt", ".cer", ".der", ".p12", and ".pfx". However please note regardless of the keystore format you must provide both the private and the public x.509 certificate in the key pair container.
Destination service certificates API requires the name of the keystore with one of the above extensions and the content of keystore file encoded into a base64-encoded string.
The name of the keystore file is important as it is used as a hint towards the base64-encoded content.
I did not find it very intuitive and was initially expecting to be able to pass my private and public keys [as base64-encoded single line strings] into the API without the need of creating a keystore file. Nonetheless, despite this caveat, the API allows you to fully automate the process of uploading/updating/removing of the certificates and not having to do it manually from the Destination Service GUI.
Steps to create a key pair container :
prepare the private and public keys in a normalised PEM format.
base64-decode the PKCS8 private key into a string and then format the string into a Private Key PEM format (not exceeding 64 characters per single line),
Save it locally into a file:
here goes a truncated private key content.
please note each line does not exceed 64 characters