The extensibility foundation provided by SAP Cloud Platform is a differentiating feature of the platform. Its value resides in reducing overall development time of extension applications by automating many of the processes required to integrate SAP Cloud Platform and the solution being extended. One of these layers is Security and within the concept of Security resides the property of single sign-on (SSO). SSO is essential to the end user experience of any extension application that is not built natively on the solution being extended so that users do not have to maintain and input separate credentials to access the extension.
This blog is a technical memo intended to frame the value of the extensibility foundation in the context of what it provides for the enablement of SSO for extension applications when SAP SuccessFactors is the solution being extended on SAP Cloud Platform.
Note : This blog is not a tutorial. For tutorials on SAML SSO configuration please consult :
- This tutorial by Alper Akbal when SAP Cloud Platform is the service provider and an external vendor is the identity provider.
- This tutorial by Chavdar Baikov when SAP HANA is the service provider and SAP SuccessFactors is the identity provider.
The extensibility foundation
The extensibility foundation, within the context of SAP SuccessFactors, refers to the layers between SuccessFactors and SAP Cloud Platform that must be integrated to ensure a smooth user experience when using an extension application. These layers are Infrastructure, Security, Connectivity, and the User Interface and include various properties that need to be developed within each layer.
A key service that SAP provides as a part of the extensibility foundation is the automated technical onboarding of a subaccount on SAP Cloud Platform that is automatically integrated with your SAP SuccessFactors company instance and pre-configured with the necessary settings so that the extension application development team can focus on building the extension and not on configuration details. We refer to this subaccount as an “extension account”.
A key tool that SAP provides and maintains is the SAP Cloud Platform Neo Environment SDK which facilitates the development of components within the extensibility foundation. This SDK is available for the various Java-based runtime containers available for SAP Cloud Platform and includes commands specific to developing extension applications for SAP SuccessFactors. These commands are documented in the SAP Help Portal for extending SAP SuccessFactors.
Image 1. Integration layers between SAP SuccessFactors and SAP Cloud Platform
Establishing trust between SAP Cloud Platform and SAP SuccessFactors
With regards to single sign-on, the first step to configuring single sign-on (SSO) is to identify the service provider. In the SAML 2.0 communication, each SAP Cloud Platform subaccount will act as a service provider. In our case, the extension subaccount will act as the service provider as the extension applications deployed to this account will be the consumers of the SAML assertion packets sent from SAP SuccessFactors. By default, subaccounts are configured as the service provider using the SAP ID Service as the identity provider (IdP). It will require a custom configuration of the service provider settings to establish trust on the SAP Cloud Platform side and enable SSO.
On SAP Cloud Platform, configuring service providers is done within the Trust Management settings of the Security tab within the SAP Cloud Platform Cockpit. Looking at the Trust Management settings of a newly generated subaccount (one that is created when an SAP Cloud Platform administrator clicks the “New Subaccount” button within the SAP Cloud Platform Cockpit), the configuration of the service provider is set to Default meaning that SAML authentication is active and the SAP ID Service is being used as the IdP. The SAP ID Service is the IdP with which we registered to get initial access to SAP Cloud Platform. However, the SAP ID Service only contains SAP users. For SuccessFactors extensions, we will need to use the SuccessFactors IdP. To delegate identity management to SuccessFactors requires our extension account to generate information that will be used in the authentication request and in validating the assertion sent from the IdP. As stated above, this can be achieved through performing some custom configurations within the Trust Management settings in SAP Cloud Platform.
But we are in luck! During the automated technical onboarding of the extension account, this custom configuration was taken care of for us. This part of the onboarding included :
- Publishing a unique identity for the SAP Cloud Platform account as the service provider. This is the identity used in the Issuer element of the authentication request that will be sent to the SuccessFactors IdP
- Generating a signing key and signing certificate for the service provider. These will be used in the Certificate element of the authentication request that will be sent to the SuccessFactors IdP
- Enabling principal propagation
Image 2. Trust Management settings of the service provider within a newly generated SAP Cloud Platform subaccount
Image 3. Trust Management settings of the service provider within an SAP Cloud Platform extension account
Configuring SAP SuccessFactors as the identity provider
Once we have configured SAP Cloud Platform as the service provider, we need to configure SAP SuccessFactors as the identity provider.
Looking again at the Trust Management settings of a newly generated subaccount, the IdP that the subaccount trusts by default is the SAP ID Service. To change this, the SuccessFactors IdP will need to exchange security information with SAP Cloud Platform. The first step to achieving this is to make an API call to fetch the required SAML metadata for the SuccessFactors IdP. The user would then need to go into the Trust Management settings of their SAP Cloud Platform extension account to add a new trusted identity provider, upload the metadata document, and configure the properties accordingly.
But we are in luck again! During the automated technical onboarding of the extension account, this configuration was also taken care of for us. This part of the onboarding included :
- Importing the SAML metadata describing the SuccessFactors IdP to our SAP Cloud Platform extension account
- Filling in the SSO properties within our extension account to the values described in the SAML metadata file e.g. sign-on URL, sign-out URL, user ID source, signing certificate, etc.
Image 4. Trust Management settings of the identity provider within a newly generated SAP Cloud Platform subaccount
Image 5. Trust Management settings of the service provider within an SAP Cloud Platform extension account for SAP SuccessFactors
Image 6. Automated configuration of the SAP SuccessFactors identity provider through the technical onboarding of the SAP Cloud Platform extension account
Establishing trust between SAP SuccessFactors and the extension application
There is one final step to complete the Trust configurations and enable SSO between SAP SuccessFactors and the extension application on SAP Cloud Platform. This step is to register the extension application as an authorized Assertion Consumer Service in SuccessFactors.
At this stage, our extension application trusts the SuccessFactors identity provider to verify the credentials of the SuccessFactors user requesting access to the extension application. This ensures that when the user clicks to launch the extension application an authentication request is issued from SAP Cloud Platform, as the service provider, to the SuccessFactors IdP. The IdP is expected to respond to the request with an assertion containing an authentication statement and redirect the user to the extension application.
However, SuccessFactors does not trust our extension application in return. This is because SuccessFactors differentiates between authorized and unauthorized assertion consuming services. Our extension application must be explicitly registered as an “Authorized Service Provider Assertion Consumer Service” in order to receive the desired authentication assertion. To achieve this requires a SuccessFactors user with access to SuccessFactors BizX Provisioning to manually input :
- The location of the extension application
- The logout URL of the extension application which is included in the SAML metadata of the service provider and is used to log the user out of their SAP Cloud Platform session when they log out of SuccessFactors
- The ID of the SAP Cloud Platform global account which is also included in the SAML metadata of the service provider and is used to identify who is the consumer of the assertion
But it seems that we are in luck once again! This configuration has also been automated and added to the commands included in the SAP Cloud Platform Neo Environment SDK. By executing the hcmcloud-enable-application-access command, the required entry in SuccessFactors BizX Provisioning is created with the necessary properties automatically inserted.
Now the trust configurations between SuccessFactors and SAP Cloud Platform are complete so when a SuccessFactors user clicks on the extension application their identity will be authenticated by the SuccessFactors IdP and they will be granted access to the extension application.
Image 7. Registering the extension application as an authorized assertion consumer service in the provisioning tenant of SAP SuccessFactors company instance
Circling back on the intention of this blog, the value of the extensibility foundation of SAP Cloud Platform and the services/tools that SAP provides as a part of this foundation become apparent when we look at each integration layer individually and break down the steps required to achieve our ultimate goal of creating a seamless experience between the SuccessFactors user and the extension application.
An integral part of this seamless user experience is that the SuccessFactors user does not have to maintain an identity and credentials separate from those that they have for SuccessFactors – this is the inherent benefit of SAML single sign-on. As we have just seen, there are a number of requirements just to enable SSO between the extension application and SAP SuccessFactors. One approach is to perform each step manually. There are several issues with this approach :
- This is a time-consuming process which will increase overall development time
- Performing each step manually makes them susceptible to human error and will create bugs if a single character is inputted incorrectly
- This would require either one user to act as an administrator for both the SAP SuccessFactors company instance and the SAP Cloud Platform extension account or for multiple users to exchange sensitive information with each other and increase security concerns
The extensibility foundation and the corresponding services/tools provided eliminate these issues and simplify the development process.
On the SAP Cloud Platform side, the development team is set up from the beginning with a dedicated extension account pre-configured to use and trust SuccessFactors as the identity provider. This means that they can immediately get started building, and, once the extension application is deployed, all that they need to do is execute a single SDK command and SSO is established.
On the SAP SuccessFactors side, all of the work has been taken care of. This relieves the administrator of the company instance from generating metadata documents, performing configurations in the Provisioning tenant, and spending time in a long communication thread with the development team every time a SuccessFactors artifact is needed.
Ultimately, separation of concerns are maintained and development (who may not have access to the SuccessFactors API and most likely do not have access to the Provisioning tenant) can focus on development while SuccessFactors administrators (who most likely aren’t familiar with development’s requirements) can focus on administrative tasks. And this simplifies the extension application project for everyone.
About the author
Colin Kraczkowsky is on the Product Management team for SAP Cloud Platform. His domain expertise includes SAP SuccessFactors extension development on the platform. He also actively supports SAP Cloud Platform events and production of assets to enable the external community.
Colin’s professional history includes enablement and extension development for SAP’s analytic portfolio and front-end design and business development for a digital media startup in Washington, D.C.
In his spare time, Colin likes to explore new areas, watch scary movies, try weird foods and participate in Turkey Trots. Colin is currently located in Palo Alto, California.
Connect with Colin – https://www.linkedin.com/in/colinkraczkowsky
The series of images below provide a visual representation of what the SAP SuccessFactors user experiences when they go to access an extension application on SAP Cloud Platform.
In a typical scenario, the user starts by logging in to their SuccessFactors account. They navigate to their Home page to locate the tile of the extension application that they want to use and click on it. This triggers the SAML single sign-on authentication process. In the background, the extension application calls the SAP Cloud Platform Security services to post an authentication request to the SuccessFactors identity provider, SuccessFactors authenticates the user and checks it’s database of authorized assertion consumer services for the information of the requesting extension application, and, if the registration is found, SuccessFactors issues an assertion to SAP Cloud Platform containing an authentication statement and the user is redirected to the extension application with the proper user context set.
Image 8. User clicks on the Home page tile for the extension application in SAP SuccessFactors
Image 9. Browser is directed to SAP Cloud Platform as the service provider
Image 10. SAP Cloud Platform issues an authentication request to SAP SuccessFactors as the identity provider
Image 11. SAP SuccessFactors authenticates the user and redirects them back to the extension application as the authorized assertion consumer service
Note : For further resources, check out the following :