Single Sign on : SAP to Successfactors : Change Case

[rajasekar98]

We have recently implemented ESS / MSS for a client.

As part of this , we had a SSO link betweeen SAP and Successfactors.

Context :

SAP Portal Login happens using ldap . (e.g: User id : Rthan01  - Mixed case )

LDAP User credentials are maintained through Active Directory. And Active Directory is the User master for over 100+ Applications.

Daily interface between Active Directory and SAP HCM  updates IT105 Subtype 0001 in Upper Case (RTHAN01)

And Interface between SAP and Successfactors picks up the User name from IT105 Subtype 0001 and sends it across to Successfactors.

Issue :

Portal user logins into the SAP portal using Rthan01 - Mixed case.

When the portal user clicks on the link for Successfactors.

Ideally SSO connection needs to be established.

But the ldap user id (Rthan01) is being compared with Successfactors login id (RTHAN01).

Since the ids are different , the login abends, and we get a user error. 

Solution Required:

a) Any option to change case of the LogID in SSO Configuration.

b) Any option in SSO Configuration which can be used to address Misaligned User Attributes.

c) Any other option that can be used to address this requirement.

[rajasekar98 · Accepted solution]

Wanted to share the possible options and how we had resolved it.

Option 1:

Use PERNR instead of the Login id to validate in the SSO.

Why we did not use it: The Client was not comfortable with this change.

Since they had been using Successfactors for over 4 years now.

And they were not sure if this will cause a change in the Successfactors user Ids and the effort involved in the SF end.

Option 2:

Add an attribute in Active Directory to hold the User id in CAPS. And use this User ID in UME (LDAP).

Why we did not use it: The Client Active Directory team was not comfortable with this change.

They have around 100,000 Users in Active Directory and since this will involve adding a attribute for all 100,000.

And they have more than 200+ applications which use Active Directory services.

And since this would also involve creating a VBS script to be triggered in AD on User creation to update the new attribute with the Upper case values.

Option 3:

Add another Subtype in IT0105 and store the mixed case User Id.

Why we did not use it: This the most feasible solution from day1.

But this involved changes in the Active directory to SAP interface.

SAP to Successfactors interface.

And then we need to get a confirmation from Successfactors that by changing some ids to Mixed case , we will not have any impact.

How we resolved it:

After going through the multiple options.

We decided to do something at the SSO end only.

We had implemented a User Attibute setting in the SAML configuration (as given in Section 4 ) of this document.

https://scn.sap.com/docs/DOC-29737

But catch here is, this User Attribute needs to be available in the UME and this attribute should hold the value of the User ID in CAPS.

To achieve this , we had used an existing Webservice (designed by us to update Portal Groups in the UME everyday).

Using this Webservice, we updated the Upper Case User Id , in a UME Attribute (we used the City field , which was not mapped to any LDAP field).

Once this was done, the SAML configuration automatically picked up the Uppercase from the UME and sent it over to Successfactors.

[siddharthrajora · Accepted solution]

This is good information, But the document you referenced is not shared, even I have seen similar issues at customer. Please share the document if you can 🙂