In SAP SuccessFactors, Single Sign On (SSO) provides a secure and seamless method for a user to access the system without having to enter their credentials. The SSO methods supported by SAP SuccessFactors fall into two main groups. The first is token based SSO and the second is Security Assertion Markup Language (SAML). SAML is based on a pre-defined standard for exchanging authentication information between systems. If your company is already using SAML for SSO with other applications, then that’s what you should use for SAP SuccessFactors as well.
If your company does not use SAML, then your technical team can look at one of the token based options currently supported by SAP SuccessFactors, including:
- Token Only
- MD5
- MD5 with Base64 Encoded user name
- SHA-1
- DES
- 3DES
If your organization doesn’t use SSO yet, then you may want to consider addressing SSO after the initial launch of the SAP SuccessFactors system. The reason for this is that it will take some time to decide which type of SSO to use and then to build out and test the infrastructure to support it. Depending on your implementation timeline, it may be best to implement SSO after the launch so you don’t jeopardize the go-live date.
The setup of SSO will depend on which SSO method you use. If it is one of the token based methods, you will typically modify and use an existing program or application to submit the required parameters to SAP SuccessFactors. If it is SAML, then you will use an existing SAML identity provider. Many of our clients currently use a cloud based identify provider that supports SAML. It is fairly easy to request a trial version from one of these cloud based providers if you want to set up and test SSO with your test or Sales demo instance from SAP SuccessFactors.
Often, our clients ask if an integration is needed with the client directory system and the answer is no. There is no direct integration required for SSO, and none of the SSO options supported by SAP SuccessFactors require an integration between your company directory system and the application. The two systems do not directly interact with each other. Your internet browser is the medium that carries the information from one system to the other as reflected in the diagram below.
The process illustrated above shows the connection to SAP SuccessFactors from your company network. However, if you are in the SuccessFactors HCM suite and want to use SSO to connect to a third party system, SAP has built SSO capabilities from their system to products from vendors such as ADP, BenefitFocus, and Kronos. If your third party application is not supported by SAP, you can still set up custom SSO, although there may be some limitations on the SSO methods and access points that can be used.
The configuration for custom SSO will depend on the type of SSO method being used for connecting to the third party system. If you are using the token only option, there is a feature called “Custom Navigation Links with Dynamic Parameters” that can be used. If SAML is used, then SSO to a third party system from SuccessFactors is still possible, but the request will need to be routed through your internal identity provider so the user can be authenticated before the request is sent to the third party system.
Partial SSO
There is an additional feature called Partial SSO that is supported by SAP SuccessFactors. This feature allows some users to log in with passwords while everyone else uses SSO only. A user is classified as either an SSO user or a password user. It does not allow a user to log in both ways, meaning that you can’t use SSO in the office and a password at home. This does not include mobile device access for which SAP SuccessFactors has a separate security protocol that is used to control access.
The Partial SSO feature comes in handy for organizations that want to give access to SAP SuccessFactors users who are not in their corporate directory system. Typically, we find that companies that use this feature generally have contract and temporary workers that need access to SuccessFactors. It is also used in organizations that make their Learning modules accessible to vendors and clients, since these individuals will also likely not be in the directory system.
Conclusion
SSO can be a fairly complex and technical topic. It is one of the areas in the deployment of SAP SuccessFactors that you should definitely involve your technical team, not only for implementation purposes, but also because your organization may have security protocols and a Chief Security Officer who might want to review and approve the use of SSO for any external system. It is better to engage the right personnel from your internal team early in the project so they can complete all their reviews and approvals before you are ready to complete testing or launching of the system to your end users.
- SAP Managed Tags:
1 Comment
