mPower™ Blog Series

SAP Fiori SSO : Single Sign On using SSL + SAML 2.0

SSO with SAML 2.0 and SSO2 provides the possibility of authenticating users between different systems navigation without repeat logon. It enables identity provider to authenticate the user information or attributes from service provider. SSO with X.509 is to enable servers in the landscape to use single sign-on (SSO) authentication with X.509 certificates to confirm the logon credentials of a user from client.

This blog explains the usage of SSO in a typical landscape of Fiori with simple process in which a user wants to verify the configured SSO settings in Fiori landscape. It describes the processes of how to verify SSO with SAML 2.0, how to verify SSO with SSO2 and how to verify SSO with X.509.

SAP Fiori Apps Typical Use Case for SSL + SAML 2.0

Now, let’s consider a typical use case wherein access need to be granted from the public internet. In this scenario, SSO can be implemented using SAML 2.0 based authentication in sync with IdP (Identity Provider) software such as SAP IDP, Ping Federate or Microsoft’s Active Directory Federation Service (ADFS). This type of authentication process is referred as Service Provider based authentication.

Now let’s have a brief overview of how this can be implemented:

  • The client sends a request (external URL for the SAP Fiori app that is specific to a particular customer’s scenario) to SAP NW Gateway via a proxy server, wherein the request could be either unauthenticated or expired (due to possible timeout).

  • The proxy rewrites this URL to its internal equivalent and forwards the request to the SAP NW Gateway.

  •  In this case, the HTTP 3.2 redirect is used. SAP NW Gateway recognizes that the request is unauthenticated and could respond in either of the two ways (HTTP 302 redirect or HTTP Post). In this case, the HTTP 302 redirect is used. Either way, the Gateway server prompts the user to talk to the SAML 2.0 IdPserver. Now, all URLs passing through the proxy server (in either direction) are rewritten, as applicable.

  •  The client follows the HTTP 302 redirect URL and sends the request to the SAML 2.0 IdPserver. There are two scenarios here. If the SAML 2.0 IdPserver is located behind the firewall, the IdPrequest goes through the proxy., else if the SAML IdPserver is cloud based, it would be a direct request.

  • With the SAML 2.0 IdPserver posing a challenge to identify itself, the SAML 2.0 IdPserver can be configured to accept whatever form of authentication is required as per the customer’s security standards such as basic authentication form or an X.509 certificate.

  • Subsequently, the client responds by providing the required credentials – for example, an X.509 certificate.

  •  If the SAML 2.0 IdPserver proves that the user credentials are valid, it responds with another HTTP 302 request to revert the client to the Gateway server with the response now additionally carrying a SAML artifact.

  • The client follows the HTTP 302 redirect URL and to ensure that, reverts the SAML artifact to the Gateway server.

  •  In order to double check the validity of the SAML artifact, the Gateway server reverts it to the SAML 2.0 IdPserver for resolution as a back-channel web service (SOAP) request. The Gateway server sends a request to confirm whether the SAML 2.0 IdPserver request had really come from it. This type of double-check prevents 3rd parties from spoofing SAML artifacts.

  •  The SAML 2.0 IdPServer resolves the artifact and asserts that the artifact had come from it and it identifies the user. SAP NW Gateway then validates the user name in the assertion and in case it is successful, the user’s request is considered authentic and an ABAP session is created. All URLs passing through the proxy server (in either direction) are rewritten as required.

Request a Demo If you would like a demo of Innovapptive’s portfolio of Native or Web based mobile solutions, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at or you can reach a sales representative at (713) 275-1804.

Share this post

Comments (3)

  • AletheaMcClemans Reply

    Hurrah, that’s what I was exploring for, what a stuff! present here at this blog, thanks admin of this website.

    December 22, 2014 at 7:30 am
  • Divya Reply

    I have a requirement to configure Fiori App with Microsoft Active Directory. The Fiori Sign in Credentials needs to be validated with active directory.

    1) I read that SMP 3.0 supports Ldap Configuration. And we have to configure fiori apps in SMP Server.

    2) Also i read we have to enable SAML2.0 in SAP Gateway to enable SSO to Active Directory.

    Should i do all the above steps? What are the recommended steps in a productive Environment. Also should i use Fiori Client or FLP Url is enough?

    Please guide me with the procedures.



    June 18, 2015 at 6:28 am
    • Umamaheswar Godavarthy Reply

      Hi Divya,

      Thanks for your mail. We have noted down all your queries. We will soon get back to you with the right answers after consulting the technical team.



      September 4, 2015 at 9:54 am

Leave a comment

Your email address will not be published.