Skip to Content

Part 2 : Single sign on from Fiori Application to SAP Gateway via SAP Cloud Platform API Management

Single sign on or principal propagation is the ability of a system to securely forward or propagate the identity of the user or principal from a sender to a receiver, in a way that the forwarded user information is kept confidential and is not changed during transit. Based on pre established trust relationship to the sender, the receiver uses this information to logon the user without asking for the user credentials or logon again.

The diagram below shows the user principal flow from Fiori Applications to the on-premise SAP Gateway or Backend system for APIs protected via SAP Cloud Platform API Management.


In SAP Cloud Platform, API Management Generate SAML Assertion Policy can be used to generate a short lived SAML assertion which can then be passed to the SAP Backend to establish an SAML IdP Initiated flow. At a high level, a SAML IdP Initiated flow would consist of the following steps: –

  1. Set fields like SAML Issuers, SAML Audience, Recipient that can be used in SAML assertion using JavaScript.
  2. Generate SAML Assertion using SAML Assertion Policy
  3. Remove xml root tags <?xml …> from the generated SAML Assertion
  4. Generate SAML Response which embeds generated SAML Assertion
  5. Generate base 64 bin encoded value of generated SAML Response
  6. Set Authorization header to outgoing request to target endpoint.

In Security Best Practices package of SAP API Business Hub policy templates for API security best practices has been published which includes the policy template for validation of SAML assertion.

In Part 1 blog we have described how the user’s principal passed from the Fiori application to the on-premise APIs protected is validated on the SAP Cloud Platform API Management and user’s identity passed in the SAML assertion is read.

In this blog, we have covered the steps to on board SAP Cloud Platform API Management as a trusted SAML Identity Provider in SAP Gateway and generate a short lived SAML Assertion from SAP Cloud Platform API Management which is used for passing user’s identity to SAP Gateway.

Generate Certificate for Signing SAML Assertion

Note: - This is an optional step, in case you already a X509 certificate with private key which can be used for SAML assertion signing, then this step can be skipped. For the certificate generation, in the blog we have used Open SSL.
  • Create a new folder in your file system to place the x509 certificate.
  • In the cmd prompt navigate to the certificate folder and then use the openssl commands to generate the certificates
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 730
  • Enter the password when prompted say abcd. This password should be used in section Upload JAR to SAP Cloud Platform, API Management


Generate JAR containing Certificate

  • In the folder in which certificate is generated create folder named META-INF
  • Create a file named with the following content
  • In the cmd prompt enter the following command to generate the jar file with the certificate
jar -cf idpKeystore.jar cert.pem key.pem
  • Add in the descriptors file to the generated jar using the command
jar -uf idpKeystore.jar META-INF/


Generate SAML IdP Metadata

Note: - This is an optional step for SAP Gateway based Backend because in SAP NetWeaver the SAML IdP can be manually configured however creation of the SAML IdP Metadata eases the no of configurations required.
For the SAML IdP metadata generation, in the document we have used an online SAML Metadata generation tool.

The following fields are important and the samlHelper.js file of the UserPropagationWithSAML policy template would have to be modified based on this values: –

  • EntityId: – This would map to the issuer field of the SAML policy ( sapapim.issuer context variable in samlHelper.js file of the API Proxy) template. Provide a url say api.gateway
  • NameId: – from the drop down select the option per your flow. In this example, we had used the default flow of urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
  • SP x509 certificate field paste the content of the cert.pem file which was generated in Section Certificate Generation for Signing SAML Assertion.
Copy only the base64 encoded certificate content minus the header -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----
  • Provide HTTP redirect url to (https://apimgmtproxy/saml/sso ), Single Logout Url (optionally) and then click on the option BUILD SP METDATA (which would appear after scrolling to the end of the website)


Configuration on the SAP Backend (SAP Gateway) Side

Note: - The screenshot might vary based on the NetWeaver version, in this document the configuration was done on a NetWeaver 7.40 system.

Activation of the SAML Service Provider

Note: - This configuration can be skipped if SAML has been already activated in the SAP Gateway.
  • Logon to the SAP Gateway system and then execute transaction saml2
  • Enable SAML 2.0 authentication on the SAP Gateway client


  • In the next screen provide the Provider Name say GatewayS. This name should be mapped to Audience field in the SAML Assertion (audience context variable of samlHelper.js file in the API Proxy).



  • Set the Skew Tolerance (default configuration is 120 seconds and its kept as is)


  • Select Identity Provider Discovery: Common Domain Cookie (set the selection mode to Automation)

Adding SAP Cloud Platform, API Management as the Trusted SAML IdP

  • Click on the Tab Trusted Providers and then click on Add button from the drop down select the option of Upload Metadata file


  • Click on Choose file button and then select the SAML IdP Metadata generated in section Generate SAML IdP Metadata for API Gateway and then click on Next


  • In the next screen, the name of the Trusted IdP Provider is shown, just click on Next


  • Follow the wizard till Finish button is enabled, generally no major modification is required in this wizard as most of the information is read from the SAML IdP Metadata


  • Click Edit and then Navigate to the Identity Federation and then click on Add to provide the details of the name mapping to be used in the SAML assertion. In this case we had selected Unspecified and then click on Ok


  • For the User ID Mapping Mode of the configuration Details of Name Id format, select option Mapping in USREXTID table, type SA and then click on Save


Note: - In this case user mapping between the external user Id as per the SAML assertion to the SAP Backend user would have to be done via the VUSREXTID table for type SA
  • Click on Enable to Activate the API Gateway SAML IdP


User mapping between External User (from SAML Assertion) to SAP Gateway

Note: - This is an optional configuration and required in case user id mapping mode is set to Mapping in USREXTID table, type SA
  • Logon to the SAP Gateway system and then enter the transaction sm30
  • Provide the table/view name as VUSREXTID and then click on Maintain


  • In the Popup, Set the External ID type to SA ( which the code for SAML Assertion based authentication) and then click on


  • Click on New Entries to add in new user mapping.


  • For SAML based authentication, the external Id is typically in the formation {IdPProvidername}::{SAMLSubjectValue}. The IdP Provider Name is the value provided in the section Adding SAP API Gateway as the Trusted SAML IdP (which in this blog is set to apimgmt.api.gateway). Therefore the External User Id would be apimgmt.api.gateway::{SCN User Id} for SAP Cloud Platform based user ids. In the User field provide the SAP Gateway user Id. Check the Activated check box and then click Save.



Note: - These steps can be repeated to maintain mapping between the external users and the SAP Gateway users.

Configuration on the SAP Cloud Platform API Management

Upload Certificate JAR to SAP Cloud Platform API Management


  • Click on the link Access API Portal to open API Portal.


  • Select the option Certificate and click on the option Create



  • In the Create Certificate dialog, from the drop down select Key Store and select the option New Store. Enter the store name and name details as provided in the table below.

Store Name





  • Using the Browse button upload the JAR file generated in section Generate JAR containing Certificate. In the password field provide the value of the X509 Certificate private key say abcd (or the value provided in section Generate Certificate for Signing SAML Assertion)


Policy Changes for SAML Flows

  • Open the API & navigate to the policy designer, from the scripts section, select the samlHelper.js file and then modify the following context variables provided in the table below based on your configurations.

Context Variable

Configuration Value

Default Values


This would have to set to the Identity Provider Name given to the SAP API Gateway in the SAML 2.0 flow

ref section Generate SAML IdP Metadata for API Gateway



This would have to be set to the SAML service provider name of the SAML 2.0 configuration on the SAP Backend.

ref section Activation of the SAML Service Provider



This would have to be set to the API Proxy target Url including the API Provider host and port

In Part 1 document, ref section Configuration on SAP Cloud Connector for On-Premise Connectivity & Create an API Proxy to connect to the SAP Gateway


For the initial testing of the API Proxy, this can be set to a value of the user, which has been already mapped in section User mapping between External User (from SAML Assertion) to SAP Gateway User.

For the user principal propagation flow, then this value should be set to the variable saml.subject which is filled with the SAML assertion subject value received from the Fiori application. This would ensure that user’s identity is passed to the SAP Gateway



This would have to be set to the Store Name field of the Certificate Screen in section Upload Certificate JAR to SAP Cloud Platform API Management



This would have to be set to the Name field of the Certificate Screen in section Upload Certificate JAR to SAP Cloud Platform API Management




  • Click on Update and then in the next screen click on Save to persist the API Proxy changes.


Testing the Flow from Fiori Application

In this blog the details of building applications using SAP Cloud Platform Web IDE is not covered as there are lot of articles available on how to consume OData services to build Fiori like applications. At the end you will have a Fiori Application which talks to the OData service from SAP Gateway. In this section we capture the steps required to connect the Fiori application to SAP Gateway OData API managed via SAP Cloud Platform API Management using user principal propagation.

  • Logon to the SAP Cloud Platform account of the Fiori application ( say )
  • Navigate to the Connectivity and then click on Destinations and then click on the destination file used is used in the Fiori application to connect to the SAP Gateway OData API .

  • Change the URL field of the import destination to point to your SAP Cloud Platform API Management Proxy host, set the Authentication type to AppToAppSSO and then click on the Save button


  • Launch the fiori application and If all the configurations step are proper then user would be logged in using the SAP ID and this credential would then be used to fetch data from SAP Gateway


Further Reads

Enhanced features of SAP Cloud Platform API Management  

Monitoring and Governing 3rd Party APIs

API Security Best Practices

Accelerate digital application development

For more blogs on SAP Cloud Platform API Management visit us at SAP Community

You must be Logged on to comment or reply to a post.
  • Hi Divya,


    At step  Generate SAML IdP Metadata i am trying to generate the Metadata file but everytime i am getting error ""

    Below is the configuration which i am doing. Can you please suggest what i am missing here.

    • Hi Ashwin,

      This error looks more like an issue with the certificate content. Can you re-try by providing the root certificate binary content ( without the private key)  and without -- BEGIN CERTIFICATE -- and -- END CERTIFICATE -- tags.



  • Hi Divya,

    Now i am able to generate the IdP and completed next steps. Issue was Single Sign On Service Endpoint.

    I am at Configuration on the SAP Cloud Platform API Management and getting error while setting KeyStore.

    • Hi Ashwin,

      In the help documentation we have captured steps for uploading certificate in key store.

      Based on the error, it looks like there might some issue with the way jar has been created. If you continue to face issue kindly raise an incident on the component OPU-API-DT .

      Thanks and Best Regards,



  • Hi Divya

    My scenario is as follow:

    PORTAL(subaccount CEN_PORTAL) –> APIM((subaccount CEN_APIM) –> JavaService using REST(subaccount(CEN_PERS) and using ApptoAppSSO.

    I am using the policies and steps described in the blog, ignoring the steps related to gateway, I included the key and certificates of CEN_PERS in trust of CEN_APIM and updated it in my keyinfo.js.

    But testing from portal, I am getting the error 401- Unauthorized when connecting from CEN_APIM to CEN_PERS and could not figure out the issue yet.

    Is there any other configuration required when connecting to a subaccount? It cannot be basic authentication.

    Thanks in advance,


    • Hi Maicon,

      In case you are interested in authenticating to a Java based REST service running on SAP Cloud Platform using then you would have to establish trust between SAP Cloud Platform API Gateway and SAP Cloud Platform sub account where your service is running. For this following would have to be done:-

      a) In sub account where your service is running you would have to on-board SAP Cloud Platform API Management as an identity provider ( for IdP initiated flow ).

      b) Create SAML IdP metadata as described in this blog and then navigate to SAP Cloud Platform sub account Trust configuration and import in SAML Identity Provider xml.

      c) Adjust Audience field in SAML javascript policy for SAP Cloud Platform. In case you are using Default Service provider then this would be  and in case you are using custom identity provider then it would be the Local Provider Settings value as you would see in your trust configuration for Local Service Provider.

      Thanks and Best Regards,


  • Hi Divya,

    starting from your interesting blog we are trying to apply all of this to our scenario. We want to protect our API with SAML and provide access only to users recognized by our IDP. We have completed the first part of this blog. If we call our API Proxy from the browser, the username and password are requested, but when logged in, the following error message is returned:

    {"fault":{"faultstring":"GenerateSAMLAssertion[generatesamlassertion]: Unable to find configured keystore saml","detail":{"errorcode":"steps.saml.generate.InvalidKeyStore"}}}

    I suppose this happens because the part concerning the generation of saml has not been configured. How can we configure everything so that the authorization is based on the IDP trust already configured on our subaccount (such as the access to the webide based on the trust part of the subaccount)?

    We would like to access to the created API Proxy using the same IDP of our subaccount.


    • Hi Rossano,

      Looking at the error message looks the private key certificate required to generate the SAML assertoin either is not imported or has been imported using a different name. The steps to generate and upload the required certificate has been captured in this blog under section named "Upload Certificate JAR to SAP Cloud Platform API Management"

      Can you share more information about your scenario? Would the API be consumed from a Fiori application and is the target endpoint an OnPremise SAP Gateway or SAP Backend system?

      Thanks and Best Regards,


      • Hi Divya,

        so for the first part we have to create the JAR starting from the key and the certificate in the Trust part of our subaccount? About the samlHelper.js configuration what should I do?

        Our real scenario provides the consumption of the API from an HTML5 app. The real target is a SAP Backend system but at the moment we are test it with Northwind API.


        • Hi Rossano,

          The samlHelper.js application would have to adjusted to provide the details of your Java application.  The adjusted values are shared below.

          If in real scenario you are connect to a SAP Backend system then you can connect directly from SAP Cloud Platform API Management as well. Refer the blog here 

          Thanks and Best Regards,


          Audience ( for and in case you are using Default Service provider
          Audience and in case you are using Custom Service provider Local service provider name

          Issuer The SAP APIM Identity Provider name that you have set in the saml IdP metadata (apimgmt.api.gateway)


          Receipent  Your Java application end points
          • Hi Divya,

            thanks for your usefull blogs. I'm also interested to the scenario described by Rossano using not SAP backend system but the Northwind API.

            My scenario is the following:

            SAPUI5 APP deployed on SCP -> API Proxy -> Northwind API

            In the API Proxy's policies i would like to authenticate user using SAML (the same SAML of the SAPUI5 app, so same IDP, same certifiicate). How can achieve it? I have already followed the whole first part of your blog, but I don't know how proceede with the second part, using the same SAML auth of web app.



          • Hi Luca,

            The Northwind API doesn't require any authentication to connect. Therefore in your flow from the API Proxy to Northwind you can connect without passing any SAML assertions.

            From the Fiori application you can connect to the API Proxy and using the first part of the blog series validate the SAML assertion from Fiori application. After that you can connect to the target end point ( Northwind API ) without any authentication.

            In case you would be attending our TechEd sessions then feel free to join our mini code JAM session on API Securities where these approaches would be covered in detail.

            Thanks and Best Regards,


          • Hi Divya,

            thanks a lot for your answer. We have implemented the SAPUI5 web app deployed on SCP that calls API Proxy (using destination AppToAppSSO) and we have followed the first part of the blog, but like Rossano, I receive this error executing the ajax call:

            {“fault”:{“faultstring”:”GenerateSAMLAssertion[generatesamlassertion]: Unable to find configured keystore saml”,”detail”:{“errorcode”:”steps.saml.generate.InvalidKeyStore”}}}




          • Hi Luca,

            In the policy template that we had both the parts of SAML Assertion validation and SAML assertion generation combined. If you are only integrating with say NorthWind API, where no authentication is required, you can remove/delete the policies associated with SAML assertion generations. The list of policies associated with the SAML assertion generation would be the following :-

            a) SetSAMLAssertion

            b) Generate SAML Assertion

            c) Remove XML Root

            d) Encode SAML Assertion/Response

            e) Set encoded SAML response.


            Thanks and Best Regards,



  • Great information, thanks a lot Divya. By the way, do you know if there are plans for SAP Gateway to support also Token Introspection,

  • Hello Divya Mary,


    I’m trying to implement the scenario of your blog.

    Except that my Fiori app is not hosted in the same subaccount than the API Management, but the connexion is working and I already used before but without SAML SSO connection.

    So when I try with your scenario I’m facing an issue with Validate SAML Assertion Policy.

    Please find my issue in attachment.

    Can you help me on this please ?

    Best regards,

  • Divya Mary Very nice content, congratulations.

    I have two scenarios:

    Third-Party (Out of SCP a postman request for example) -> SAP API Management -> SAP OData Provisioning -> Cloud Connector -> ECC

    Third-Party (Out of SCP a postman request for example) -> SAP API Management -> Cloud Connector -> HANA (XSOData)

    Both the connections are Trusted (SAML), I understand that SAML Assertion Generation could be used to generate a SAML Request to propagate principal to HANA and ECC, does the SAML Assertion Generation intercept original request coming from Postman request and create another one properly that will be interpreted by backend?

    The certificate used in the SAML Assertion Generation can be got from Metadata if it already is configured?


    Best regards



    • Hi Isaias,

      A short live SAML assertion is generated on SAP API Management side and passed on to the target endpoint.  For signing of SAML assertion , private key of the certificate is required and this is typically not passed in incoming SAML assertions. The incoming SAML assertion only contains root certificate ( without any private keys) with which the assertion was signed.  In scenario where you already have a certificate with private key which can be leveraged for signing purposes , then you can simply import the same on the SAP API Management side as well.

      Thanks and Best Regards,


  • Hi Divya, how are you doing? I have a doubt regarding the right procedure for:

    => Generate JAR containing Certificate

    The certificate in this case is not the same one we had created in the part one of this post in step "Certificate download from SAP Cloud Platform account", Is it correct? I mean, should I create another one through openssl or get it through another method right? The certificate created in step above, is to be imported at API Management but as type Trusted Store with name saml at samlroot and the other one would be of type Key Store through the .jar file procedure, had I got the right path?

    Warm Regards.

  • Hi Divya,


    We are currently trying the same scenario in our landscape. However, there is a bit of a difference. In our case, the APIs are being called by a third party without any user logging on to any application.

    Thus achieve the above, we have created a technical user and we generating a SAML assertion for the technical user. Thus, the part 1, of your blog is not relevant for us.

    In the part 2, we tried to do this and following are our queries:

    1. Is this architecture or development possible for our scenario, where we do not have a external user logging in, but we use a technical user in APIM to generate a SAML token and send this to our On-Premise system.
    2. Could you please let us know if this is successfully tested with the Gateway system. That would be of great help for us.
    3. In our case, we are also connecting to our On-Premise PI system. Please let us know if the above is also possible to achieve when the backend system is a PI system.

    Looking forward for your reply on the above. Let me know if you need any further information from my side.


    Sagar Nawathe