Configuring MS ADFS 3.0 as Identity Provider for SuccesFactors
A few days ago I helped some colleagues in order to configure the MS ADFS connection with SuccessFactors cloud service. So I’ve decided to prepare this blog with the steps for ADFS configuration, as well as some advice about the tasks and responsibilities.
The picture below is a basic scenario for MS ADFS integration with SuccessFactors:
Due to the nature of the integration between two or more systems, it’s necessary some explanation about the tasks and responsibilities. The table below is a responsibility matrix, keep in your mind that’s a basic suggestion and the idea is to identify the tasks of each team or person.
Please see the responsibility matrix on my site.
Step 1 – MS ADFS 3.0 Version and Patches
I really recommend you to check on the Microsoft site if there are patches to be applied in your environment.
Step 2 – Metadata and certificates from SAP/SuccessFactors
In order to configure the MS ADFS you need to request some files from SuccessFactors. These files will provide a metadata and certificates to be used in ADFS.
Also you need to send the metatada from ADFS to SuccessFactors. It’s quite simple, just open your browser and use the following URL https://<SERVER>/FederationMetadata/2007-06/FederationMetadata.xml. Do not forget to repalce <SERVER> with your server address. Below you’ll find an example of metadata.xml file.
Export certificates used by ADFS to communicate, sign and encrpyt is not mandatory, but you can save some time doing it. To export them, open your ADFS Management from Server Manager and follow the sequence below:
2.1 In the left side of the ADFS Management has a tree view, click on Service node.
2.2 Go to Certificates, all certificates will appear in the right side of the ADFS Management.
2.3 Perform and right click on the commnication certificate and choose “view certificate”.
2.4 In a new window select the folder “Details” and click on button labeled as “Copy to File…”
2.5 In the certificate export wizard window click on “Next” button.
2.6 Select the option “No, do not export the private key” in order to export only the Public key. Click on “Next” button.
2.7 Select BASE-64 encoded X.509 in order to export the certificate as BASE64. Click on “Next” button.
2.8 Select the path and the file name which will be created.
2.9 Repeat the process for Encryption and Signature certificates, do not forget to give a unique file name for each certificate.
These files will be sent to SAP/SFSF together with the metadata xml file.
Step 3 – Configure MS ADFS
3.1 Open ADFS Management (Start the ADFS Management in the server) and start the wizard to add a Relying Party Trust for SFSF Cloud Service.
3.2 Select option “Import data about the relying party from a file”.
3.3 Add the configuration from Metadata.xml file.
3.4 Specify the display name of the Claim.
3.5 Check the option “Permit all user to access this relying party”.
3.6 Confirm the certificate for Encryption.
3.7 Flag this option in order to configure the Claim Rules.
3.8 Click on the “Add Rule” button to create new rules. Two new rules must be configured in Claim Rules.
3.9 The new rule is related to LDAP attributes; Therefore choose “Send LDAP Attributes as Claims” and click on “Next”.
3.10 Define the rule name as you want, choose Active Directory in the attribute store. In the mapping select SAM-Account-Name for LDAP Attribute and choose Given Name for Outgoing Claim. Click on the “Finish” button.
3.11 Create another rule.
3.12 Choose the option “Transform an Incoming Claim” and click on “Next”.
3.13 Give some name for the rule. Incoming type is “Given Name” and outgoing type is “Name ID”. Outgoing name ID forma must be “Unspecified”. Finish this configuration.
3.14 Close this window clicking on OK button.
It will work only after the SuccessFactors team have configured their environment.
In the same way MS ADFS can be configured to provide identity for SAP NW GATEWAY and SAP PORTAL.
If you want to see the screenshots and more details, please visit my site.
Nice one..thanks for sharing brother
Thanks Alex for this documentation. so many customer want to do this and very less have clarity on what all needs to be done.
This would be a great help.
Thanks bro! Really useful!
first of all great work on this very helpful Blog (Y)
now i have a question : the last point 3.15 was : It will work only after the SuccessFactors team have configured their environment
what do you mean by this point. shouldn't we also perform the Configuration for the Success Factors Side.
if yes : is there a guide for the steps ?
If No: should we create an incident to request the configuration done ?
Many Thanks For your Help.
Sorry to my late answer.
If you have access to provisioning you can perform the configuration. But if you have no access or you don't know how to do it, hence you can open an incident requesting the configuration.
Thank you Alex for the document. Very informative.
But can you include further instructions if I want to use email address as login?
Hope to hear from you soon. Thanks!
Sorry for my late answer.
I'm very busy, but I'll try to get some time to publish something related to your question.
I read many post in Successfactor Portal community talking about "Single Sign-on Implementation with SAML2.0 " (but no actual instruction/guide found....). Is the approach described in this blog the same thing?
Yes, it is the same thing with focus on MS ADFS 3.0.
Please keep in your mind that the SFSF provisioning configuration is not covered here.
Good afternoon Alex,
Great post, that is really clarifying to me. I work on the configuration of the SuccessFactors side but the customers constantly ask about AD configuration steps needed.
Nevertheless, can I ask you about the step 3.3 you describe (Add the configuration from Metadata.xml file). How can I provide the customer with the details to establish the relying party relationship via file?
Thanks and Kind Regards,
The customer can raise a ticket to SFSF Support in order to get the Metadata.xml file for SAML 2.0 Configuration.
I have a client looking where connecting SAP SF to ADFS might be a good solution. At this point in time they prefer to have a possibility to use the SAP SF personnel number as the logon name since both employees as well as people in the recruitment process should be able to access success factors. When choosing for Adfs the AD logon credentials will be used, but for the people still in the recruitment process an account might not be allowed. Is a hybrid solution feasible (most log on using Adfs, and some with a personnel number authenticated by sap success factors)?
I would like to ask on how to generate the login URL?
Hi Irineo Antonio,
I am using this URL model to perform login on MS ADFS:
https://<YOUR-MS-ADFS-URL>/adfs/ls/idpinitiatedSignon.aspx?loginToRp=<<relaying party identifier>>
But, you can start with:
Thanks a lot for this guide.
One question. As you said
"In order to configure the MS ADFS you need to request some files from SuccessFactors. These files will provide a metadata and certificates to be used in ADFS"
I wonder where the certificates are used in ADFS? I read in your steps how to use the MetadaFile sent from SuccessFactors but I did not understand how to use the certificates from SF.
Thanks a lot!
You need to contact the SFSF support, partner or consultant in order to request the metadata, after that you can import into ADFS (Step 3).
The MS ADFS certificate should be loaded into SFSF provisioning by a Partner or authorized consultant.
Thank you so much for your guide!
In our SFSF installation we had to perform these two additional steps:
And all worked fine.
We've successfully configured the SSO with ADFS and users clicking on a link over the intranet goes directly to Successfactors.
But we have another scenario where some workers need to access Successfactors from an HR Kiosk (Windows with generic user).
How we can configure an URL/ADFS that allows the worker to enter his windows user & pass an be redirect to Successfactors?
Kind regards and thanks
that you can handle in udf file.
Regarding retaining both the logins, through SSO and PWD, I would like to inform that login would follow
the setting in UDF file.
If the "login method" is blank or set to "SSO" in the UDF, then user will be able to login only SSO.
If the "login method" is set to "PWD" in the UDF, then user will be able to login only by password
Hi Matias, Do you have a paper with the steps to follow in order to configure the SSO with ADFS, but in successFactors side ? (basically the task to be done in provisioning)
I wondered if you ever figured out how to do this?
we have subscription for SCP, SF and Concur. We wanted to achieve SSO for our users through ADFS and IAS implementation in SCP. from SCP other SAP cloud products should authenticate. Please provide information in this regard.
SSO is activated for success factors.
After entering id/pwd its going into loop and from Success factors side they see below log.
SAML login response with Failed status from customer.
Let me know how can i fix this, please help .
I am Kyohei from Japan.
I am facing same issue. Can you solve your issue?
I think that the issue is due to IdP setting. Would you take SMAL Trace log when logging SuccessFactors via SSO?
You can know how to use SMAL Tracer with following KBA.
I may identify the cause of your issue.
We are going to migrate ADFS to Azure AD.
To do that, we suppose we need disable ADFS authentication for SuccessFactors to avoid unexpected access.
Can we do anything on SuccessFactors side to disable ADFS authentication?
>Also you need to send the metatada from ADFS to SuccessFactors. It’s quite simple, just open your browser and use the following URL https://<SERVER>/FederationMetadata/2007-06/FederationMetadata.xml.
I’m guessing we can delete this metadata sent from ADFS, but I’m not sure where the metadata saved in SuccessFactors.
Can anyone advise me, is this a right way to disabling ADFS authentication from SuccessFactors side?