3658884 - [2H 2025] Improved Analysis of SSO Login Errors in SuccessFactors

Symptom

In 2H2025 release, the Login Failures Error Log page under Admin Center has been enhanced to make it easier to understand and resolve SSO login issues. Administrators can now review recent errors and see guidance for common problems.
When a SAML response is present in an error entry, a new Action column provides a View Details option, that opens a dialog showing the SAML response in a clear format.
Troubleshooting, tips and tricks, and common errors for SAML SSO login to BizX

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Environment

SAP SuccessFactors HCM Suite
SAP Cloud Identity Services – Identity Authentication IAS

Reproducing the Issue

Error Logs are shown in Admin Center > "Login Failures Error Log" feature, as per KBA 2757960 - [SSO] Login Failures Error Log feature.

Resolution

In the Login Failures Error Log page, Administrators can access the SSO Error Logs which will be used to troubleshoot SSO issues. This facilitates troubleshooting and possible resolution without having to engage Product Support.

Access can be granted upon assigning Manage Security > Manage SAML SSO Settings permission.

When accessing the tool, users can filter for date and the User affected, but only the date is a required field to start to search.

Error	Analysis and Recommended Actions
user account not exists or cannot find user account	This is likely due: corresponding user existing in IAS but not in SuccessFactors corresponding user existing in IAS and in SuccessFactors, but not in Corporate IDP user attributes mismatch indicated by SAML success code in IAS response, i.e. user attributes mismatch indicated by SAML success code in Corporate IDP response, i.e. <StatusCode Value="urn:oasis:names:t c:SAML:2.0:status:Success"/> in the View Details. `<StatusCode Value="urn:oasis:names:t c:SAML:2.0:status:Success"/>` User status is inactive User is locked Check IP restrictions if user is trying to login with an allowed IP address SAML User Column is blank - In Provisioning > Single Sign-On (SSO) Settings, "SAML User Column" field should be left blank. NameID parameter does not match between SuccessFactors and IAS and/or does not match between SuccessFactors, IAS and Corporate IDP To debug further, get the username shown in the User column, and/or attributes “mail”, “last_name”, “first_name” from the Login Error Details page. Then double check to make sure such user exists in SuccessFactors tenants with the matching login name and email information.
Invalid user account/status	This is likely due: The user displayed on the user column and/or in the SAML response does not have a valid user account or the account status is invalid. Review and update the user account if this is a valid user. In provisioning > SSO log viewer error below shows as well if there is any IP restriction set up: com.successfactors.sso2.api.SSOException: invalid user account/status@sf_loaduser
No signature present in assertions!	In View Details, there's the below message: `<StatusMessage>User attribute configured for name-id format unspecified is not supported.</StatusMessage>` This usually indicates that the user record in IAS does not have a login name value specified. Review the user record in IAS and make sure the login name field is populated for users that need to log into SF.
No signature present in assertions [login name matches]	This indicates that there is an expired certificate – either between IAS-SuccessFactors or IAS-Corporate IdP and/or IdP certificate does not match with the certificate in IAS. To validate if the SF certificate in IAS is expired, follow the steps below: IAS Admin Console > Applications & Resources > Applications. Select the SuccessFactors instance application. Then go to SAML 2.0 > Click on Certificates tab. SuccessFactors certificate expiring date will be shown. If the certificate has expired, follow KBA 3595935 - [SSO] Certificate Renewal Procedure with SF-IAS Integration to have it updated. If it’s not yet expired, then check whether the IdP have the correct and valid certificate. To validate that the certificate is the same, contact the corporate IDP to perform a metadata exchange on their side and then update the certificate on IAS side. To check the IdP certificate that is set in IAS: Login to IAS admin console > Identity Providers. Select the IDP to be checked. Go to SAML 2.0 Configuration Select certificate under Signing Certificate To update the corporate IDP certificate on IAS, follow KBA 3432984 - How to Update Signing Certificates on IAS
Logout response failed with error code: urn:oasis:names:tc:SAML:2.0:status:Requester@logout_validate	Indicates a problem with the SAML logout process, which can be due to various reasons, such as incorrect configuration or issues with the SAML metadata. Check that the SAML Single Logout Response URL in IAS and the Single Logout Redirect URLs in SF are configured correctly. Ensure that the SAML metadata is correctly set up/formatted and uploaded to the Identity Provider.
SSO is not enabled for the company company id	Enable SAML SSO flag has been disabled in Provisioning and has to be set back to enabled.
Missing SAML response of object name	The SAML response returned from IDP is null. In the majority of cases, the IDP issuer was null in the SAML response. Check IDP configurations.
Error loading IDP metadata	This indicates that there are no SAML assertion party records found or missing values in the SAML assertion party record. Double check SAML assertion party records under -SF Admin Center → Monitoring Tool for SAP Cloud Identity Service Migration Progress → SAML Assertion Parties.
No logout Request Info found in session	This means there is a mismatch of session index or Name Id; either the session has already expired or not found, or the NameID from the logout request was incorrect. Check session valid time and NameID settings on the IDP.
SAML response not expected, the original request id: null, response is for x-session-id	Means that the SAML response for SP-initiated login was received without a proper request, possibly due to server routing requests to different nodes. Ask the user to retry logging into SF again using proper login URLs. See KBA 2089448 - SuccessFactors Data Center Name, Location, URL, Domain Name, Mail Server details, SFTP details and Outbound IP addresses.
There is not related IdP Metadata found in BizX for issuer SAML_Issuer_name	The SAML Issuer Name from the response does not match the value specified in SF BizX, i.e., the SAML_issuer_name value in the error message does not match that from the details’ SAML response issuer value. See an example below: Check whether there has been a change of SAML Issuer Name in IAS. If so, either change it back or modify SF SAML Issuer and corresponding URLs to match the new SAML issuer value in IAS.
The issuer in response is not valid, expect valid IAS issuer https://<IASURL>	Root cause would be a mismatch of the SAML Issuer, Single Sign-On Endpoint, or Single Logout Endpoint between SuccessFactors and IAS. Make sure that the values match in both systems by validating the metadata.
The SP entity id is not in the audience list, sp_entity_id	Caused by wrong SP entity id in IAS. See example below of mismatch between expected entity id in error message vs that from the SAML response. In IAS, an admin has to double check the entity id in admin console and make sure it matches the expected value. By default, SF SP entity id would be in the format: `https://www.successfactors.com/companyid`
User doesn’t have login permission	The user displayed on the User column and/or in the SAML response does not have the login permission. Grant the necessary permission if this is a valid user. See KBA 2410089 - RBP Troubleshooting: How to check User Login Permission?
user account is locked, can not login	The user displayed on the User column and/or in the SAML response has a locked account. Unlock the user in SF instance via Reset User Account page if this is a valid user. See KBA : 2086751 - How to Unlock a User Who Has Been Locked Out - SuccessFactors
The digital signature of the received SAML2 message is invalid	Check that the signing certificate from IAS and the certificate for the IAS SAML Assertion Party record in SF match each other. If not, update SF with the latest SAML signing certificate from IAS.
Client ip does not fall in the permitted range	This error means that the user trying to login is using an IP address that does not fall into the range of the configured IP Restrictions. To resolve, go to Admin Center > IP Restriction Management > and add the IP address of the user trying to login. KBA 2089414 - System: How to restrict access to SuccessFactors by IP address - IP Restriction Management Help Portal - Adding an IP Restriction For Partners: Verify via provisioning Company settings Restrict access to IP range Check if IP restriction is updated Note: In provisioning \|log review. it shows: com.successfactors.sso2.api.SSOException: invalid user account/status@sf_loaduser at com.successfactors.ssosaml2.service.action.bizx.SFAudit.getLastException at com.successfactors.ssosaml2.service.action.bizx.SFAudit.doAction
Format null unknown	This error is coming from the customer’s Identity Provider (IdP) settings where an invalid name policy was selected. An example of a name ID with no policy specific which will cause the error: <NameID>I827_22</NameID> What a name ID with a supported policy will typically look like: <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">testuser</saml2:NameID>
Certificate time not valid	This means that the certificate in SSO Settings has expired AND the SAML Verifying Certificate Valid Period is set to YES. To fix this, update the certificate with a new valid certificate. If there's no certificate yet, users can temporarily update "SAML Verifying Certificate Valid Period" to NO until a new certificate is available.
Didn't get an assertion in ArtifactResponse	In SP-initiated scenarios, when the Identity Provider (IdP) can't process the Authn Request from the Service Provider (SP), the SAML Response may lack the required `<assertion>` section. To diagnose the issue, decode the Base64-encoded SSO error log string using a tool like Notepad++ or an online decoder. The decoded message will reveal the absence of the `<assertion>` section and a reason for the empty assertion response. Example: `InvalidNameIdPolicy` – which indicates a possible misconfiguration in the Name ID policy or the signature settings. Since the error originates from the IdP, engage the IdP administrator to analyze and provide the cause of the failure.
No company for sp-initiated login.@sf_login_init	If a Corporate Identity Provider configuration is setup with IAS as proxy: From Corporate Identity Provider side, check if configuration is correct. Check in IAS if Metadata and Certificate are correct for Corporate Identity Provider Set up.

Other SSO error scenarios and failures that might not appear on the Login Failures Error Logs:

Error	Analysis and Recommended Actions
AADSTS650056: Misconfigured application	Customers need to contact their IDP Team (Azure) to update the correct URL (Entity ID) on the Azure side.
AADSTS50011: The reply URL '..' specified in the request does not match the reply URLs configured for the application '..’	Customers need to contact their IDP Team (Azure) to update the correct URL (Reply URL) on the Azure side.
Errors from IdP: SSOv2 IdP configuration /Common/idp-prd-testcomp-yy does not contain SP connector with Issuer: https://www.successfactors.com/companyID SSOv2 Error: No SP Connector attached to SAML SSO from assigned SAML resources matching authentication request. If ACS URL is present in authentication request it should match ACS URL from SP Connector. If Issuer is present in authentication request it should match entity_id from SP connector. SSOv2 Error(16) Unable to find SAML SSO/SP Connector object matching SAML Authn Request	This means that we are sending the entityID as ‘https://www.successfactors.com/companyID’, while the IdP has it configured as ‘https://www.successfactors.com’ The reason is that in provisioning "Send request as Company-Wide issuer" is set to YES, which means that SF will send the companyID in the entityID as: https://www.successfactors.com/companyID To resolve this, either disable the option in Provisioning > Single Sign On Settings or have the IdP update the EntityID on their side to include the companyID
The RelayState “[#####] is invalid. It must start with ‘/’ or be a valid URL and from a safe domain	This is common using ADFS as the corporate Identity Provider for SAML 2.0 Single Sign On. This error could be quite misleading as although it is pointing to a Relay State issue, the issue is caused by the Claim Rules. In ADFS, ensure two Claim Rules in the for your Relying Party Trust in as per section 3.8 in the following blog post have been added.
Login page keeps loading	This issue could be due to following scenarios: Incorrect certificate of their IDP configured on their IAS Admin Console. This can be verified with the IAS Admin Troubleshooting Logs with the X-IDS-ID they can gather from the SAML Trace. If it is showing up with "Signature validation of SAML2Assertion failed. Signature validation of SAML2Assertion failed. Caused by: Signature not valid!".. then the customer should be in contact with their IDP team to verify the certificate. Login Name is used as a Subject Name Identifier but on IAS, the user’s Login Name is empty. Verify whether the user trying to login have a Login Name.
Active zonesession exists for user	If the feature "Disallow concurrent login sessions" is enabled, then users will not be allowed to log in with more than one session concurrently. For example: if a user has an open session using Edge browser, they will not be able to login to another session using Chrome until they have logged out of the initial session. For more details, see KBA: 2524768 - Restrict Concurrent BizX Sessions
Decrypt assertion fail	The assertion information is being encrypted with the certificate. Ensure that the customer uses the correct certificate from SuccessFactors. Use Scenario#1 from KBA 2707993 - [SSO] Metadata file for SSO \| How to generate it for either SF x IDP and Outbound SSO scenarios
Validate response fail	Check if the certificate being sent from IDP matches the certificate setup on the Asserting Party on their SSO Settings from Provisioning. Check if there’s an error message that says “The response is not signed correctly” – this means that the response is not signed or it is signed with the wrong certificate.
Validate assertion fail	Check if there’s a message saying “the assertion is not signed correctly” – this could either mean that: The assertion is not signed. It is signed with the wrong certificate.
Validate assertion fail now [<timestamp on SF at moment of the error>] is before Condition NotBefore [<timestamp sent by SSO on SAML request>]	The error is due to the time on BizX and on the SSO being more than 2 minutes with difference as SuccessFactors. SF only has a buffer that allows up to 2 minutes difference. Change the server time (SSO) to less than 2 minutes from SuccessFactors which our servers are synchronized with the following servers: clock.via.net prefer 2.timegps.net
Signature validation failed in assertion: Signature cryptographic validation not successful@versign	This indicates that the SSO certificate in BizX does not match from IAS. Customer needs to update the certificate in BizX with the certificate from IAS’s metadata file, which they can get from admin console.
“SAML response not found” when accessing another application from SuccessFactors	When analyzing SAML trace, no error can be identified as SF acts as IDP in this case. This is due to a third party implementing an SSO integration using the following cookie: sameSite="Strict" The `SameSite="Strict"` cookie policy is the direct cause of the SSO authentication failure. When `SameSite=Strict` is set, the browser will not send cookies on any cross-site request, including cross-domain redirects and POST bindings used by SSO flows. This should be changed to sameSite="None" to allow authentication work properly.

Limitations:

Currently only errors that would result in SAML response from IDP back to SuccessFactors can be shown,
Login errors due to IDP configurations and/or errors that do not result in SAML response back to SF, e.g. configuration error between IAS and corporate IDP, are not captured

Other Debug Tips:

Review error message
Inspect the decoded SAML assertion or response in the “View Details” page, and check the following parameters:

- Status Codes:

First, check if the SAML <Status> is success or an error. If there's something like <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"> or a second <StatusCode Value="...:InvalidNameIDPolicy"/>, the IdP is explicitly signaling an error (like the NameID policy issue). This means the assertion wasn’t even issued due to a policy problem.

- Issuer:

This is the tag indicating what is the <issuer> value sent by the IdP. This needs to match the value setup in the Provisioning.

- Destination:

This value should match the AssertionConsumerSrevice URL which was provided by SuccessFactors for this company and Datacenter combination. Make sure the “company=” value matches the Company ID in Provisioning.

- Timestamps:

Look at IssueInstant, NotBefore, and NotOnOrAfter. Are they within a reasonable range of the current time?

- - - If NotBefore is in the future or NotOnOrAfter is in the past relative to your SP’s clock, there's a timing issue (likely clock skew or an overly short validity window).
- Audience:

Find the <Issuer> value. Does it exactly match your SP/IDP’s entity ID/issuer? If not, that's a problem (audience mismatch).
Example: <ns2:Issuer>iastenant.accounts.ondemand.com</ns2:Issuer>

- NameID:

Check the Format and value of the <NameID>.

- - - Is the Format what was expected (e.g., an email address format vs. persistent)?
    - Does the value look correct (e.g., an actual username or email and not something unexpected)?
    - If the format is wrong, the NameID policy issue discussed earlier is likely in place.
    - If the NameID is missing or empty, that's also a problem – the SP might require a specific identifier to map the user.
      Example for IAS integrated tenant, default value should be:
      <ns2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
      Other examples: <ns2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
- Signature & Certificate:

Confirm that a <Signature> element is present if your SP requires signed assertions/responses. Inspect the Key Info or X.509 certificate data within the signature.

- - - You can copy it and compare with the certificate configured in your SP.
    - If they don't match, the SP will reject it.
    - If the signature element is completely missing (and your SP expects one), the SP will also reject it for not being signed.

</ds:X509Certificate>: This tag indicates the beginning of the SAML verifying certificate sent by the IdP. You can use this to verify if the certificates match between the IdP and what is set up in provisioning.

- Endpoints (Recipient and InResponseTo):
  - Check the Recipient attribute in the SubjectConfirmationData – it should be the URL of your SP’s ACS endpoint. If it’s pointing somewhere else or has a typo, the SP will drop the assertion.
  - Similarly, if this was an SP-initiated login, the InResponseTo should match the ID of the AuthnRequest that the SP sent initially. A mismatch there can cause the SP to ignore the response as it doesn't recognize it as the answer to its login request.

SAML 2.0 Provisioning tips when working in the SSO Settings screen:

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

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

Enable SAML SSO: radio button to signal whether SAML SSO is enabled for the current SF tenant or not

SAML Asserting Parties (or also know as IdP): SAML assertion parties are now exposed on Admin Center from the 2511 release onward, the Monitoring Tool has been enhanced to display the following newly added details for SAML assertion parties:

- - SAML Assertion Party Name
  - SAML Issuer
  - SAML Enabled (flag)
  - SAML Verifying Certificate Validity Period
  - Identity Authentication Integrated (flag)
How to add new asserting party in SSO Settings?
- This is no longer supported. Reference KBA 3422297 - Provisioning option to Add an Asserting Party in SSO Settings is removed
- To update any asserting party information in provisioning:
  - In SSO Settings asserting party page the "update asserting party" button has to be hit. If the Save button at the top of the screen is pressed 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".
  - Direct Corp IDP to SF integration will be deprecated, migrate to IAS as soon as possible. With SF to IAS integration, only 1 IAS asserting party will be supported.
  - If you want to connect multiple Corp IDPs, you can setup multiple Corp IDP within IAS, and define conditional authentication rules so different set of users could use different Corp IDP to login. Refer to KBA 2791410 - Integrating SuccessFactors with Identity Authentication IAS through the Upgrade Center
What are Redirection URLs?

- These are used to redirect the users to the different customer-defined URLs if the end user runs into one of the matching scenarios.
- If your tenant is already integrated with IAS, you can update the redirect URLs on Admin Center > Manage SAML SSO Settings page:
  - If IAS is the real IDP, click the Manage Non-SAML setting button, and update the redirect URLs
  - If IAS is proxy to a corporate IdP, click the Edit button next to the corporate IdP record, and update the redirect URLs

What are the SAML v2 : SP-initiated logout, SP-initiated login, etc..?:
- Use these sections if you want to setup SP-initiated URLs, global IdP logout URLs, etc.
- If you are integrated with IAS, these values would be set by automated process, we recommend that you leave the settings as is as default values. To view the default settings, refer to Help Portal - Default Tenant Configurations for HCM Suite and Identity Authentication
- Remember these are also specific to the asserting party, so any changes made here need to be saved using the "update asserting party" button

Note: If you are using SP-initiated logins, 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. Note that Partial Organizational SSO will be deprecated by Nov 2026
- Migrate to SAP Cloud Identity Service (IAS) for authentication, and migrate existing those users using SF username/password for login under partial SSO to use IAS username/password for login instead.
  - Note: if changes are made here, the "SAVE" button at the top of the screen below the save token button should be used.
- Refer to KBA 2791410 - Integrating SuccessFactors with Identity Authentication IAS through the Upgrade Center
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. If your tenant is already integrated with SAP Cloud Identity Services (IAS) as IdP, SAP will update IAS’s verification certificate automatically for you, so you can ignore the below steps.
- 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 currently 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.
Where to find the SSO error log in provisioning -> SSO settings page?
1. The SSO Error log is located at the bottom of the SSO Settings page.
2. Click the "SSO Log Viewer" link to access.

Additional notes:

- See the attached guide "Find SSO error log.pdf" for detailed steps with screenshots.
- In addition to the above SSO Error logs, a SAML Trace for the impacted user login should be collected to track complete SAML exchange between SuccessFactors and the SSO Provider.
- KBA on how to capture SAML Trace: 2461862 - Collecting SAML traces with Chrome, Edge or Firefox

How to locate the Stack Trace from the SSO error logs?
1. In the SSO Log Viewer screen there is a table with different elements. once you have identified an error for which you want to see details, hit the "Toggle SSO error detail..." button to see the full details.
2. Once you have the details expanded, you can view the stack trace from the corresponding section
3. Typically the important information will be at the bottom of the stack trace after the "caused by:" line.
4. See attached guide "Find Stack trace.pdf" for detailed steps with screenshots.

How to decode a SAML response if it's not showing as an XML?
1. At times the SAML Response in the Log Viewer may show as a long string of characters, rather than an XML message. In this case it is probably encoded in Base64.
2. To decode the message, copy the full line(s) of text, and use a Base64 decoder (or SAML decoder) to decode the message into a readable XML format.
3. You can do this using Notepad++ as well as some online decoding tools (you can search for SAML decoder in Google and you will find many)
4. Here's how to capture SAML trace: 2461862 - Collecting SAML traces with Chrome, Edge or Firefox

Keywords

SSO Login Errors in Successfactors , SF, Login Failures Error Log, Login ,SF, success factors, PLT, platform, biz x, bizx, SSO, logs, hints, troubleshoot, how to, response, company-wide, issuer, ACS, user has no login permission for company, Validate response fail for companyId, SSO error, single sign-on error, SSO issue, SSO troubleshooting, SAML Issuer , SSO, Error messages include "The subject (___) in SAML response does not exist in BizX", SAML response does not exist in BizX, certificate, sign certificate, third party certificate, IdP Certificate , KBA , LOD-SF-PLT-SEL , SSO Errors & Logs , LOD-SF-PLT-SAM , SAML SSO First Time Setup , How To , Login Failures, mismatch, NameID , KBA , LOD-SF-PLT-SEL , SSO Errors & Logs , LOD-SF-RMK-ICS , Internal Career Site Builder (CSB, IAS, etc ...) , LOD-SF-PLT-IAS , Identity Authentication Services (IAS) With BizX , How To

Product

SAP SuccessFactors HCM Suite all versions

Attachments

Pasted image.png
Pasted image.png
Pasted image.png
Pasted image.png
Pasted image.png
Pasted image.png
Find SSO error log.pdf
Find Stack trace.pdf
Find SAML Response.pdf
Update SAML cert SSO.pdf
Activate & deactivate SSO.pdf