SAP Knowledge Base Article - Public

2327203 - SSO in BIZX & LMS Knowledge Support and Tips


Click to go back to the main page



1. Overview of Single Sign On

  • Introduction
  • Quick overview of SSO
  • Login methods
  • Overview of SSO in Bizx

2. SSO configuration in provisioning

  • Switching on/off SSO
  • High level configuration requirements of SSO
  • Redirect Url’s in SSO
  • Partial Organization SSO
  • Single Sign On – Deeplink & Dynamic links

3. SAML 2

  • SAML2 Overview
  • SAML2 Provisioning tips 

4. Troubleshooting Tips & Tricks from Bizx side

5. General Issues with SSO in LMS 6. Relevant Information


1. Overview of Single Sign On

This KBA is created to give an overview of Single Sign On (SSO) in Bizx and LMS. 

Customers will NOT have access to provisioning for implementation or configuration, this has to be done by Implementation team/Partners and also it is accesible by Customer Support.

What Is Single Sign-On?
Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property, a user logs in once and gains access to all systems without being prompted to log in to each of them.

SuccessFactors offers a number of SSO options to allow users to access the application without entering their SuccessFactors username and password.

  • SSO is an ability to be able to login without entering the credentials.
  • All our SSO offerings include the same basic steps.
  • The user clicks on the customer supplied link.
  • The company authenticates the user.
  • The company generates a user specific SSO login URL.
  • After being internally authenticated, users are redirected to SuccessFactors.
  • User is logged in after successful authentication at SuccessFactors.

Login Methods?

  • Single Sign on is a way for a user to login to an instance without entering user credentials.
  • For BizX application those credentials are Company ID, Username and Password.
  • Field username is default to login as SSO and we cannot change for another field
  • When on SSO, the typical user experience is that user clicks on a link provided by their company (usually in their intranet portal) and SuccessFactors application opens up in the browser.

Overview of Single Sign On in Bizx

- SuccessFactors Generic login method
- SuccessFactors SSO portal page - Okta


2. SSO configuration in provisioningSecureIcon.JPG

Provisioning functionality ONLY available for Partners/Implementation Administrators or SAP Customer Support.

Provisioning (respective datacenter)->Select Company ID ->Edit Company Settings->Single Sign On Settings


SSO is turned OFF – Not enabled



SSO is turned ON - Enabled


Configure and Turn ON SSO
This is handled by Customer Support Platform team and is configured under Single Sign On settings in provisioning.

Understanding the terminology is necessary in cases where customers (already on SSO) request to just turn OFF their SSO switch.

We need to make sure that we don’t wipe out the fields configured based on the SSO type.

This is also important when we implement SSO for the first time, need to be sure we only fill in the fields and DO NOT set the token that enables the SSO switch.

Platform team is responsible for any configuration/troubleshooting regarding Single Sign On feature in BizX unlike the integration issues (cover bellow).


Non SAML and SAML based SSO methods

  • Non SAML Methods
    • Token Only
    • MD5
    • MD5 with Base64 Encoded username
    • SHA-1
    • DES
    • 3DES
  • SAML - Security Assertion Markup Language based Single Sign On.
    SAML V1.1
    SAML V2.0
  • If a customer decides to use SAML then SAML 2 is a preferred over SAML 1.1.
  • SAML 2 offering has more features like Single Logout and SP Initiated logins.
  • Improved SSO logs for SAML v2 as opposed to SAML v1 in SuccessFactors.


Redirect URLs in SSO
SuccessFactors provides the ability for a company to define unique landing pages (URLs) for a person to be redirected to depending on the type of login issue or logout type. Some most commonly used redirects are:

  • Logout
  • Session Timeout
  • Invalid login
  • Invalid Manger
  • Missing credentials

This greatly helps administrators support end-user login issues so they can quickly define based on the landing page, the type of issue impacting the end-user and quickly determine how best to resolve.


Partial Organization SSO
Partial SSO allows users to either login using generic method (specify company ID, Username and Password) OR via SSO, but NOT both.


Configuring partial SSO is  three step process and should be processed by PLT team:

  • Provisioning Set up – To enable the switch
  • Modify Succession Data Model – To include LoginMethod column in User Data File
  • Admin Tools set up – To set the LoginMethod for each user.


LoginMethod field will define whether a user comes in through SSO or not. The standard element will have three allowable values:
  • SSO - means the user must login through the SSO method configured for this customer.
  • PWD - means the user must login through the standard username/password login pages.
  • Null (no value specified) - means the user must login through SSO
Configurations in “Password and Login policy settings” will be applied accordingly to the users. For example, SSO users cannot change their passwords, PWD users can.
Single Sign On – Deeplink & Dynamic links


  • SuccessFactors allow customers to send their users to pages other than the home page on initial login. For example, they may want them to start on the Goals page or in SAP Jam.

Dynamic links - Links in email notification

  • If a user is already logged in to SuccessFactors and clicks on an email link, the link will open and show them their resource.
  • If the user is not logged in to SuccessFactors and clicks on an email link, their login will fail.


3. SAML 2

How Does SAML2 Work?

SSO generally takes place between two parties. The Identity Provider (IdP) has information to authenticate the users and generate SSO logins. The Service Provider (SP) offers a service that is accessible using your SSO. The SP must be able to accept customer-generated SSO logins and identify the user who you want to log in. This document covers the SAML2 SSO standard.

In general, any SAML2 SSO software should work with the SuccessFactors application. We support the following SAML2 protocols:

  • IdP-initiated where a user starts the process internally
  • SP-initiated where a user starts the process by attempting to connect to SuccessFactors


The processes look like this: Identity Provider (IdP) Initiated SAML Single Sign-On


Service Provider (SP) Initiated SAML Single Sign-On



SAML2.0 Provisioning Tips

1. What are the different sections in the SSO settings screen in provisioning ?

This section isn't a guide to the SSO setup screen, here we are merely capturing quick tips for common questions.

  • SSO Token: For SAML (1.1 and 2.0) this field is used to activate and deactivate the SSO. You can enter any value and use the save token field to activate SSO. If you want to deactivate SSO delete the value and press save token.
  • SAML Asserting Parties (or also know as IdP): To view the existing asserting parties already configured for this company, use the dropdown menu to navigate to the desired one.  To create a new asserting party, select "Add an SAML Asserting Party" from the drop down menu, and provide the required information.  To update any information in this section you need to hit the "update asserting party" button. If you hit the Save button at the top of the screen instead, this will not save the changes. This applies to saving changes to the redirection URL as well as the other related sections below such as SP initiated logout, login, etc..

Note that for SAML SSO to work, the Enable SAML flag value need to be set to "Enabled".

If your customer wants to have multiple asserting parties setup (aka. multiple IdP systems), this is supported by SuccessFactors. However you need to consider the effect it will have on the login process, due to the fact that the redirect URL's are setup independently for each asserting party.

Please consider the below if you wish to setup multiple asserting parties (two or more):
Any login attempt that triggers the use of a redirect URL (for example missing credentials), will trigger an intermediate page called "SSO Redirect landing Page "to appear before the redirect. In this page the user has to choose which asserting party (SSO IdP) they belong to. Once they do this, the application can then pick the redirect URL setup for this asserting party and continue the process. Initially the names setup in the SSO settings will be displayed, but customer admins can setup translations which make sense to the end user population via admin tools, if required.  See KBA 2150778 - SSO Redirect Landing Page Error for more details on how to setup asserting party translations

There also is an opt-out option which is provided in provisioning > SSO setting page, and it is found at SSO level.  This can be useful if all asserting parties have matching redirect URL's. The opt-out will only be visible when the company has multiple enabled asserting parties

The setting is called Disable Multiple Asserting Party Selection If enabled, it will force the user to select a default asserting party. After which, the system will use the selected default asserting party's URLs and no longer ask the end users to select their asserting party.

  • Redirection URLs: These are used to redirect the users to the different customer defined URL's if the end user runs into one of the matching scenarios. As stated above these are linked to the asserting parties. We support one set of redirection URL's per asserting party.
    Note: If you are using SP initiated login, the deeplink redirect should be blank. As stated above any changes made here need to be saved using the "update asserting party" button

  • SAML v2 : SP-initiated logout, SP-initiated login, etc.. Use these sections if you want to setup SP initiated, global IdP logout URL's etc.. Remember these are also specific to the asserting party so again any changes made here need to be saved using the "update asserting party" button Note: If you are using SP initiated login, the deeplink and continue session redirect URL's should be blank. As stated above any changes made here need to be saved using the "update asserting party" button

  • Common SSO Settings: The sections are self explanatory. Please note that if you make changes here, you should use the "SAVE" button at the top of the screen, below the save token button.


2. How to Activate / deactivate SSO ?
Use the SSO token at the top of the SSO Settings screen in provisioning. You can enter any value and use the save token field to activate SSO.
If you want to deactivate SSO delete the value and press save token.
See the attached Guide "Activate & deactivate SSO.pdf" for step by step activate and deactivation.

3. How to Update the SAML verifying certificate?
If the IdP SAML verification certificate is expiring, or if the certificate being sent is not correct, you may need to amend the values in provisioning.

  • Make sure the new certificate is in Base64 format
  • To check, open the certificate in a text editor and verify that you can see "BEGIN CERTIFICATE" and "END CERTIFICATE" tags in it.
  • Make sure the correct asserting party is selected from the "SAML Asserting Parties" drop down menu.
  • Make a backup from the existing certificate by copying and pasting currenty values from provisioning into a new text file.
  • Copy and paste the full text from the new certificate into the provisioning settings. 
  • Click "Update the asserting party" button to save the changes.
    If the certificate was saved successfully then you should that the values above the certificate field are showing the valid period and status of the certificate you just updated.

    See the attached guide "Update SAML cert SSO.pdf" for detailed steps with screenshots on the relevant information section.

4. How to Update redirection URL's?
You can follow the same logical steps as for updating the certificate.

  • Make sure that you backup any existing values before you change.
  • Makes sure you are changing the values for the correct asserting party by using the drop down menu.
  • After entering changes, use the ""Update the asserting party"" button to save the changes


4. Troubleshooting Tips & Tricks from Bizx side

  • SAML 2.0 Provisioning tips when working in the SSO Settings screen.
  • Troubleshooting tips and tricks
  • Common errors and resolution 


5. General Issues with SSO in LMS

A. Renew Certificate or Certificate it is going to Expire.

They need to provide the certificate to us and we need to provide certificate to them.We can easily get the metadata by going to the site:


-They will get it from us in the implementation process
It is in xml format, it has the certificate inside and the redirections.  The certificate it is what we get from the Customer.

KBA 2120972 - What is the process for updating Shibboleth Single Sign On Certificates for Learning customers?

Why is it that customers only want to provide the cert on cert change when Operations wants the full metadata file? - We ask for full metadata files because other changes could have occurred besides the certificate.

Technically if a customer just provides the cert and has no idea what metadata is you can update the old metadata with the new cert text.  This is not recommended because as above other changes may have taken place and the customer needs to know what metadata is.  They have provided it when SSO was implemented so it shouldn’t be a difficult ask.

Other Notes on Shibboleth:

This is the standard SSO extension for LMS only customers.  It’s a SAML2 implementation.  Although customers are moving to Bizx and becoming integrated some of our most important and quick to escalate customers are still using this implementation.   LMS Customer Support DON'T DO installations/Implementations, but we do handle metadata changes and cert updates.

If you want to view our metadata you can go to here: https://<customer> - This is usually not needed because SSO is likely already implemented.  This is what the customer needs to import on their side.  Sometimes ops mistakenly give us this file instead of the customer’s current metadata file.

Points to Note:

The SSL certificate updates for SSO are usually standard with customers, however we do need the customer to track this activity and ideally start this process or submit the ticket 3-4 weeks before expiration. The change should then be implemented in the Staging environment first and then in the Production environment

The onus of providing the complete IDP metadata file is on the customer as we cannot really tell from looking at the file contents if the file is correct or not and there is no way to test this without deploying this in the environment

Also the process of deploying this new SSO certificate is quite invasive for Operations. In the BizX environment, this can be done through the Provisioning UI, however for Standalone LMS customers this file has to be deployed on the SSO servers and then those servers need to be restarted potentially impacting other customer transactions as well. This is why this activity is reserved for the maintenance windows only.


B. For standalone LMS instances the SSO normally Shibboleth SSO is used:

ie. typical error shown in LMS:


-Check in google shibsp: error message can give you an idea of what the issue could be.
-Use fiddler to get what we are sending to the LMS server and what we are receiving from the LMS server (example issue in customer side or we are not redirecting correctly (wrong configuration))


C. Integration Issues involving SSO:

·SSO issues for logging into Bizx should be forwarded to that team.  When it becomes an issue of accessing LMS then an Integration Customer Support should take a look.

·There is SSO between LMS and Bizx, but this is happening behind the scenes and issues related to this are integrated settings related.
·The SSO page in Provisioning** can be important to us in two ways:
       o Check to see if Partial SSO is enabled.
       o Check to see where users are redirected after an issue occurs in the LMS, like timeout.
** Only Partners/Implementation Services and Customer Support have access to Provisioning of the Customer.
·Common issue when coming to LMS from Bizx from customers moving from LMS SSO:


-This is normally caused due LMS was standalone and had SSO Extension and now it is an integrated customer and LMS SSO extension was not removed.
i.e.: Jira:

D. LMS LDAP not may companies used in LMS, that can be configure in System Admin->Configuration->LDAP


Users login through normal login LMS User page and they use other credentials (example windows credentials) and LMS instance contact their LDAP server, provides usernames and password and then logins in as successful.  The configuration it is done during IMPLEMENTATION services.

-Checks Firewall is open
-LDAP server is correct
-Way of searching the users

E. Deeplinks are links that can be sent to users to go directly to a particular part of the application.

These are generated on the Admin side (System Admin -> Tools -> Direct Links)

When integrated the deeplink is wrapped in the Bizx url.  Customer should try it when the Implementation is made.

If a customer is complaining about deep links not working with SSO:

  • Confirm that the link works when a user already has a session with the LMS.  In this case no authentication is needed.
  • Confirm with fiddler that the redirects are going to the right place.  The link should go to the customer’s portal with a cookie with the direct link information.  Wherever it stalls is typically where the problem is.  You might see that the issue is on the Bizx side for example, but typically it’s that the customer’s portal is not passing the deeplink information to the Bizx server during authentication. 
  • Even if customer is using Bizx SSO or LMS standalone SSO customer should be able to use this links, should redirect to their portal and there is a deeplink cookie that they need to make sure that it goes along so when the users are authenticate it gets provided to the LMS when the user is in the system and then it gets redirect to the correct place.

When user is logout or don’t have the authentication session and then try direct link, it doesn’t work then normally is a problem with the redirect, cookie are not active or not sending to the correct place, this is out of scope due it needs to be tested during the implementation.  We can check with Fiddler.

-Company ID not match
-302 Result it is redirecting and it goes to the login not in other side (issue with the configuration normally at customer side) will have to review with their IT department or go to Managed Services.


 6. Relevant Information

–   KBA 2317944 BizX Platform - Partner resources : SAML 2.0 Provisioning guide - Troubleshooting tips and tricks - Common errors and resolution

 –   KBA Search: SAML

–   Guides (attached to the KBA):
  • SSO Update Certificate.pdf
  • Active and Deactive SSO.pdf
  • Find SSO Error Log.pdf
  • Find SAML response.pdf 
  • Find Stack Trace.pdf

–   Implementation Guide (attached to the KBA): SuccessFactors SAML2 Single Sign On





  • Learning Management System (LMS)
  • Bizx Platform (Provisioning)


Bizx Integration, Provisioning and LMS Integration, LMS Integration with BIZX, Bizx and LMS, SAML, Shibboleth, field username, , KBA , LOD-SF-LMS , SuccessFactors Learning , LOD-SF-PLT , Foundational Capabilities & Tools , LOD-SF-LMS-ADM , Admin Tools , How To


SAP SuccessFactors Learning all versions


Activate & deactivate SSO.pdf
Find SSO error log.pdf
Find Stack trace.pdf
Update SAML cert SSO.pdf
Q3 2015 - SuccessFactors SAML2 Single Sign-On (SSO).pdf
Find SAML Response.pdf