Skip to Content

 

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.(more information).UserExperience.pngFor large 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.

 

In case you want to take advantage of native HANA XS development model for developing Extension Applications you need, to setup SAML SSO between HANA XS and SuccessFactors separately. You can take advantage of the following article:

 

 

More about SAP HANA Cloud Platform Identity and Access Management capabilities can be found on its documentation page.

 

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.SAMLSSO.pngMore information on how to secure your application with SAML can be found here:

 

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:

 

 

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. Visit http://help.sap.com/hr_api for complete API documentation. Below we focus configuring API access from SAP HANA Cloud Platform specifically.

 

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-connectioncommand. 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:

 

 

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

 

 

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. Full reference for API URLs can be found here:
HCM Suite OData API Server Hosts. 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.

 

Disclaimer! At the moment of writing this article the SuccessFactors Role Provider availability is limited only to Java applications.

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

CustomRoleProviderSFSF.pngWhen 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:

 

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.

 

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

 

 

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.

Conclusion

During the course of this article, we discussed the most important points, to be considered when  securing SuccessFactors extension applications. The flow goes from ensuring authentication against common user base, allowing applications to access system data using the most appropriate security mechanism and implementing consistent authorization and permission management.

None of this should be a challenging task, when taking advantage of SAP HANA Cloud Platform Extension Package for SuccessFactors.

As platform of choice for extending SAP, HANA Cloud Platform gives you more time to focus on solving the real business problems at hand and not waste resources in figuring out how to integrate the systems.

Useful Links:

SAP HANA Cloud Platform Documentation for Extending SuccessFactors CCu

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Chris Paine

    A fantastic resource. Thanks!

    Another thing that should be noted about OAuth rather than basic authentication (even in case where it is a technical user that you want doing the API calls ) is that it doesn’t expire. However, when coding your apps make sure you handle case wherethe tenant is dev_default separately and revert back to basic auth, or your code won’t run on a developer stack (kinda important for testing.)

    (0) 
    1. Chavdar Baikov Post author

      Thanks for the feedback!

      Password expiration is really a problem, and maintaining such user in general.

      Majority of extension application scenarions would never require such user anyway.

      I would think how to incorporate multi tenancy topic into the article. In general the default tenant can have it’s own authentication, since the authentication is tenant specific.

      Since multi-tenancy is seprate topic i was thinking about separate article with reccomendations and best practices.

      (0) 
  2. ramchandra prasad

    Dear Chavdar,

    I am trying to do an extension but not a JAVA application but a HTML5 application running on the cloud portal, do you have any document or material for this. I am able to do lots of stull but stuck on permission and access point. Also on who the destination will work for OAuth2.0.Please help me on this.

    Regards,

    Ram

     

    (0) 

Leave a Reply