SAP Success Factors connector Configuration in SAP GRC Access Control.
SAP SuccessFactors Employee Central is a cloud-based solution that pulls all employee data into a single platform. SAP GRC can be integrated with the SAP SuccessFactors system. The integration can be done in two ways.
- Integrating SAP SuccessFactors system with GRC for provisioning, Risk Analysis, and Role import (Role maintenance is not supported).
- Integrating SAP SuccessFactors Trigger (Employee Central) via SAP Cloud Platform integration.
This Blog highlights the steps required to configure the connector in case the SAP SuccessFactors system is connected directly to the SAP GRC system.
Creating Connector for SAP SuccessFactors in GRC
Create an HTTP connector Type G between SAP Access Control and SAP SuccessFactors.
- In Customizing (transaction SPRO), follow the path SAP Reference IMG→ Governance, Risk, and Compliance→ Common Components→ Integration Framework→ Create Connectors.
- Choose “Create Connectors”.
- Choose the Create icon and the folder HTTP Connections to External Server.
- Fill in the data as indicated by the example data in the screenshot below.
In SM59 RFC connection of type G (HTTP connection to External Serv), please maintain the below details:
The API URL is based on the data center you are in. The KBA 2215682 contains the URLs for each data center. The below example is for Data Center 4.
Target host = apiperformancemanager4.successfactors.com
Target host = https://api4.successfactors.com
Troubleshooting the connectivity can be done via check from the browser, if you are able to login into the site and see some XML metadata about all the entities shown from SuccessFactors site, then that is the correct target host to use:
Test target host link: https://api4.successfactors.com/odata/v2/
|Path prefix = /odata/v2/|
Service no = 443
(443 is the port if you are using HTTPs)
As Basic authentication, the user should be concatenated along with company id, under “Logon & Security” in SM59, the example you can maintain user@company and password.
If you have multiple SuccessFactors instances, where to enter the company id (e.g., company1, company2, company3, company4, etc.)?
For example, if the user is ABCD and the company id is company1, then it should be maintained as ABCD@company1
Please note the user should have admin (role) privileges in SuccessFactors. The manage Role-based Permission access ” RBP_ADMIN” is required for API user.
For more extensive authorization requirements, refer to KBA:2979765.
You can configure the RFC destination SFEC using the below details:
SSL Certificate of SFEC should be installed on the GRC system via t-code STRUST:
Check ST11 (dev_icm) logs for issues with Certificates and for more information on what certificates are missing and need to be installed, the error itself will mention the missing certificate:
- SSL handshake with api4.successfactors.com failed: SSSLERR_PEER_CERT_UNTRUSTED
- Failed to verify peer certificate. Peer not trusted
Please get the missing Certificates from the respective vendor and install them. KB article 2461900 will assist you if any SSSLERR_PEER_CERT_UNTRUSTED handshake errors occur.
Following profiles need to be set on the GRC system:
|ssl/ciphersuites = 135:PFS:HIGH|
|ssl/client_ciphersuites = 150:PFS:HIGH|
Create the Connection Type Definition
- In the IMG Choose, Governance, Risk, and Compliance→ Common Components→ Integration Framework→ Maintain Connectors and Connection Types
- Create a connection type as indicated in the screenshots below. Choose Define Connectors. Enter the Target Connector and Connection Type for your connection.
3. Assign your connector to the group you just created using the same Connection type. 4. Maintain your connection settings. Choose IMG→ Governance, Risk, and Compliance→ Common Components→ Integration Framework→ Maintain Connection Settings.5.Select Work Area = PROV (Provisioning)
- Link your connector to PROV.
Select Scenario-Connector Link. Link the Target Connector SFEC to the PROV Work Area. The Connection Type is SFEC.
- Map your actions and connector groups in SAP Access Control.
- Choose IMG→ Governance, Risk, and Compliance→ Access Control→ Maintain Mapping for Actions and Connector Groups.
- Add your connector group and activate it.
Case Sensitive and Extended object configuration.
As SAP SuccessFactors is case sensitive, the created SAP SuccessFactors connector needs to be maintained for the configuration parameter 1022(Connector for which Object Ids may be maintained case sensitive) and 1046(Extended objects enabled connector) the same in the configuration parameter. Once the connector is maintained, creating Risk and generating the rules in the SAP GRC system will update the tables mentioned below.
Note: If you run Repository Object sync prior to maintaining the SAP SuccessFactors connector in the parameter 1022, the User id in the SAP GRC table GRACUSERCONN will be updated with Upper case and later on if you maintain the SAP SuccessFactors connector for the parameter 1022 an run the Repository Object sync job again, the GRACUSERCONN table will have duplicate entries for the User id’s maintained in Lower Case in the SAP SuccessFactors system.
In the customer landscape, there could be a scenario where the user id in the SAP SuccessFactors system is different from user id in other SAP systems. If the parameter 1055(Connector enabled for auto User Mapping in Repository) in the SPRO configuration is set for the SAP SuccessFactors system, Running the repository sync for the SAP SuccessFactors system will map the SF Username filed to the SAP User ID Field.
Once this is maintained, while running the repository sync, the system will map the SF field with GRC fields and update the data in the GRC table accordingly.
User Mapping to be added. Custom user mapping needs to be assigned in the connector setting.
This completes the Connector configuration for integrating the SAP SuccessFactors system with GRC.
Nicely done. Would like to see more such blogs from you. Thanks for sharing!
Nice blog with detailed information. Thanks for sharing.
Thanks for the write up, it's really nice.
Would you please, through your expertise in GRC, be able to guide/provide me with steps on how to provision SAML Identity Providers from GRC to HANA DB.
P.S: Please excuse my candor if my comment has infringed any rules of engagement.
It's a nice explanation. Keep it up dude.
One question:- What are the GRC modules that can support to successfactor and concur(ARA,ARM,EAM,BRM and UAR)
Hello Jagdeep ,
Can you please elaborate little more ?
Hi Japneet, thanks for sharing this if. But i need to understand as to how the position value can be used to trigger the Rule. Below is my understanding in sequence of steps
1. The standard HR trigger in BRF+ uses the Event/Field value/Infotype/Subtype to give a Action id(Create/Change/Terminate).
2. As an example , all these request types needs to be mapped to a request type value . Eg 34(for new joiner)
3. This request type value is then used in the Initiator rule id of process SAP_GRAC_ACCESS_REQUEST, to send the new joiner request to a specific path.
From here on, i am not clear as to how the Position to Rule decision table is being called. Can you please advise.
i am aware that 'Rule to Role mapping' is used. But how is this decision table(containing Position to Rule) called, i.e how is the associated BRF+ called
Hi Japneet Singh ,
Thanks for this blog, it is very helpful.
I would like to know can we use SF as user data source in GRC AC on-premise? And will it be possible with same connector settings? Any guidance on how it can be done?
Hi Japneet Singh and thanks for an excellent, informative blog post.
Unfortunately one of the important KBA references on the Logon/Auth section:
For more extensive authorization requirements, refer to KBA:2979765.
Has no content when accessed: 'SAP Note/KBA 2979765 is being updated.'
Do you happen to know where we might be able to now find the auths detail you had referred to?