Securing SuccessFactors Extensions on SAP HANA Cloud Platform

Overview

SAP HANA Cloud Platform, extension package for SuccessFactors allows you to extend your SuccessFactors scope with applications running on the platform. The extension package makes it quick and easy for companies to adapt and integrate SuccessFactors cloud applications to their existing business processes, thus helping them maintain competitive advantage, engage their workforce and improve their bottom line.
In this article we will look into main security aspects of implementing an extension application and guide you through the typical end to end development and configuration process of these aspects. In order to be able to cover all aspects, the content is focused around Java application hosted on SAP HANA Cloud Platform. Including HTML5 front end layer into the mix does not change any of the concepts presented here.

Extension applications differentiate by offering highly integrated experience with the extended system. For SuccessFactors regular users and business administrators, using such applications should be highly transparent and not incur additional complexity and effort.

Since this article is about security, lets touch the main points of interest:

• SuccessFactors users will be using the extension applications. We should provide means for them to access the extension applications, without requiring additional credentials.
• Ensure secure data access.  Associated personal data held in the SuccessFactors system represents sensitive information. We should make sure that extension applications are accessing data using the proper authentication and authorization mechanisms
• Ensure consistent and transparent authorization management. In SuccessFactors HCM suite, authorization schemes are in place that determine whether you have certain permission or role in certain process, depending on your position in the company. Customers will expect adequate behavior in that regard also form extension applications. Business administrators would expect simple and integrated way for configuring and tracking these authorizations.

We would collectively name these qualities as ‘integrated experience‘ for using extension applications and would discuss how to achieve these qualities using SAP HANA Cloud Platform.

Single sign-on authentication in extension applications

Single sign-on overview

Single sign-on (SSO) is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session.

companies SSO allows consistent user identity and access management. All company users are managed in single place. Same user id maps to the same person in all SSO enabled applications. It is easy for administrators to on-board (enable) and off-board (disable) user access. 

Single sign-on configuration

For each SuccessFactors company as part of the SAP HANA Cloud Platform Extension Package onboarding process, a SAP HANA Cloud Platform extension account is created. The purpose of this account is to encapsulate all the integration settings and simplify the configuration landscape for extension applications.

Single sign-on configuration is performed upon extension account creation and is shared between all Java and HTML5 applications deployed or subscribed in this account. In order to provide browser based single sign-on, with the extended SuccessFactors system SAP Hana Cloud Platform employs SAML 2.0 protocol. SuccessFactors acts as Identity Provider, while in SAP HANA Cloud Platform extension account level there is Service Provider configured.The Service Provider configuration is used by all Java and HTML5 Extension Applications for authentication against the SuccessFactors Identity Provider. Since the configuration comes out of the box with SAP HANA Cloud Platform extension package, you do not have to perform additional configuration.

Application developers should protect their application resources with SAML authentication and upon application access the SAML 2.0 authentication flow will be automatically triggered. If the user is not authenticated, he is redirected to SuccessFactors Identity Provider. In case he has not already logged in SuccessFactors, a login prompt shows up, where he uses his SuccessFactors credentials. Once authenticated he gets redirected back into the extension application with the proper user context set.

Although SAML SSO is configured by default for SAP HANA Cloud Platform extension accounts, for security reasons the SuccessFactors Identity Provider will not accept authentication requests coming from all sources. If your application is not registered in SuccessFactors Identity Provider as Authorized Assertion Consumer Service, after login you will get blank screen. In order to resolve this, you need to register the application in SuccessFactors Identity Provider. Follow the documentation link below to do that application specific configuration step:

• Registering extension application as an Authorized Assertion Consumer Service

Completing the steps above should ensure you have your extension application SSO enabled for the SuccessFactors system you are extending.

SuccessFactors Data Access

Choosing OData API Authentication type

In order to implement their business scenarios the extension applications need access to the data of the extended system. SuccessFactors exposes OData APIs, that allows interacting with the system – fetching entities, getting workflow states and other operations. 

SuccessFactors OData API  supports two authentication methods:

• HTTP Basic
• OAuth 2.0

HTTP Basic authentication requires API access with technical user, which is being given all the required data access permissions. There are two major drawbacks associated with this approach:

• elevation of permissions – When SuccessFactors data is accessed on behalf of technical user, it is up to the extension application implementation logic to ensure that user triggering the action is really authorized to access or change that data. There are chances, that the extension application gives access to data that usually the user should not be able to access or modify.
• lack of data access transparency in extended system – When changes are done in the system through technical user, information is lacking for the real user that triggered the action from the extension application.

These concerns given along, with the hassle of having to maintain the credentials for the technical user, makes the OAuth 2.0 option, the preferred way of API authentication for extension applications. It does not have the drawbacks given above and provides additional benefits, namely:

• allows extension applications to access OData APIs on behalf of the logged in user. This allows having correct audit log in SuccessFactors and enforcing the proper authorization checks server side during API access
• each application uses dedicated OAuth client, which gives additional transparency for administrators upon which application is accessing the data
• no user passwords are exchanged between parties
• fully supported by SAP HANA Cloud Platform Connectivity service, makes it easy for developers to use

OData API Access Configuration

In order to have proper principal propagation, when making API calls, it is required that single sign-on is configured for the extension application. As discussed, this feature is already configured in extension accounts, so it is assumed this is already available.

In order to configure the OAuth connectivity from your Extension Application to the extended SuccessFactors system OData API, you can use the convenient SDK ‘hcmcloud-create-connection‘ command. After correct command execution you would have ‘sap_hcmcloud_core_odata‘ destination created for your application and corresponding OAuth client registered in the extended SuccessFactors Instance. More information about configuring connectivity can be found on the link below:

• Configuring connectivity to the extended SuccessFactors system

How to use the configured connectivity in you applications you can find in

• SAP HANA Cloud Platform Connectivity and Destination API documentation.

Behind the scene configuring the OAuth API Access for SAP HANA Cloud Platform extension applications consists of the following two steps:

• OData API OAuth Client application is registered in SuccessFactors for your extension: As “X.509 Certificate” for the application registration, uses your extension account Local Service Provider Signing Certificate (Account->Trust->Local Service Provider->Signing Certificate)
• SAML Bearer Assertion Destination is created in SAP HANA Cloud Platform for your application. The following template is used, when creating the destination:

Name	sap_hcmcloud_core_odata
Type	HTTP
URL	<SuccessFactors API URL>
Proxy Type	Internet
Authentication	OAuth2SAMLBearerAssertion
Audience	www.successfactors.com
Client Key	<OAuth Client Key>
Token Service URL	<SuccessFactors Token Service URL>
assertionIssuer	<OAuth Client Key>
companyId	<SuccessFactors Company ID>
nameQualifier	www.successfactors.com

The correct ‘SuccessFactors API URL’ depends on what Data Center is hosting your SuccessFactors company. The ‘Token Service URL’ is derived from API URL host and ‘/oauth/token’ path. Since the extension account is bound to known SuccessFactors system, the required properties are filled automatically during command execution.

You could find this information useful if at some point you have to troubleshoot the connectivity of your application.

Consistent Authorization Management

Role Management in Extension Applications

When developing SAP HANA Cloud Platform Extension Application for SuccessFactors, we come to a point, where we have to decide the application authorization model. We have to define, the roles of the application users and the associated permissions needed for those roles.

• SAP HANA Cloud Platform allows Java application developers to use the traditional Java EE web roles in their applications. The role management is performed in SAP HANA Cloud Platform cloud cockpit. Checking for role assignment for logged in used can be done using standard Java EE Servlet API.
• SuccessFactors employs powerful Role Based Permission (RBP) system for managing authorizations. It allows grouping relevant permissions into RBP roles and perform Role assignments to groups of users based on advanced rules. OData API for accessing the RBP Model is also available.

Having to manage role assignments for SAP HANA Cloud Platform Extension Applications separately, would increase customer TCO and moreover keeping a consistent role assignments between SuccessFactors and SAP HANA Cloud Platform would be challenging. That is why SAP HANA Cloud Platform offers optimized solution for the extension application use cases by introducing the Role Provider concept.

Role Providers in SAP HANA Cloud Platform

Role Provider is a SAP HANA Cloud Platform service that determines the roles for specific user in the system. The service is integrated into Java runtimes, and provides the java applications, with the user role assignments, when calling Java EE ‘isUserInRole’ API. Behind the scene it is a pluggable framework, that allows switching between different permission management source systems. The ‘Default’ one maintains the application role assignments in SAP HANA Cloud Platform. Configuring different Role Provider would allow to use role assignments maintained in external system.

As part of SAP HANA Cloud Platform Extension package for SuccessFactors, SAP is providing SuccessFactors Role Provider implementation, that allows you to integrate extension applications with SuccessFactors role management.

SuccessFactors Role Provider Configuration

In order to be able to use SuccessFactors Role Provider your application needs:

• to be served from SuccessFactors extension account
• to have configured OAuth 2.0 connectivity to the extended SuccessFactors system

When using SuccessFactors Role Provider, the user role assignments will be fetched, from the extended SuccessFactors system. No additional coding is required in the application.You should be aware of the following specifics of its usage:

• Checking user roles in application triggers API call to the extended SuccessFactors system. If the API access is impossible at the moment  or connectivity is not configured the application resources protected by roles might be inaccessible.
• You should take care to create the required application roles in SuccessFactors RBP System. The roles names used should exactly match, with the roles the application requires.
• There is no application isolation in SuccessFactors RBP System, if you want your application roles to not get mixed with other RBP roles avoid using generic role names like ‘Administrator’ and ‘Manager” and be more specific like ‘ACME Benefits Administrator’.

By default the SuccessFactors Role Provider is not enabled. In order to configure it you can do the following:

• Changing default role provider from cloud cockpit
• Enabling SuccessFactors role provider using SDK command line tool

After switching to SuccessFactors Role Provider, application role assignments should be performed from SuccessFactors administration.

SuccessFactors Permission Configuration

As mentioned, when we discussed SuccessFactors Role Based Permission system, roles in SuccessFactors serve as containers of permissions. There are thousands of permissions in SuccessFactors and you can put any set of permissions on a role you create.

Making SuccessFactors API calls on behalf of the logged in SuccessFactors user ensures that the API layer will check for user RBP roles and enforce the permissions contained in the roles. Requesting data, for which the user does not have permission, might either result in authorization error or return empty/incomplete entities. In theory extension user not having all the required permissions, should not have that extension application role at all. That is why it is suggested, that extension applications use roles for authorization along with SuccessFactors role provider. When developing and shipping application to customers, the only thing to do is to ensure each RBP Role used by extension application, has all the required permissions defined inside. How do you do that?

You have two options:

• Handout application documentation of all required SuccessFactors roles and permissions, so administrators can create the roles and add the permissions
• Define the roles during development and deliver them along with the application, so they can be imported into the target system

Since the first option, although obvious is much error prone and requires manual effort, we would focus on the second option. Let’s assume you have created and tested the RBP roles required for your application and want to install it on another system. Unfortunately, there is no convenient tooling to export RBP Roles from SuccessFactors, however we can use the public OData Role Based Permission API and some REST client for that purpose.

• Creating RBP Role resource definitions

When installing the application on another SuccessFactos system, you can import the RBP Role Definitions using the guide below:

• Importing RBP Role definitions into target system

Executing the import will ensure all the extension application roles are imported into the target system, containing the same permissions that were modeled during development. This makes for the extension application logic to check role assignment rather than permission assignment and be sure there are no run time errors upon SuccessFactors API calls.

Importing a Role into the system does not grant any user the permissions from the role. After installation the SuccessFactors administrator can review the RBP Roles delivered along, with the application and grant them to the proper groups of users in the target system.

Source: go.sap.com