1 About the SAP User Management Connector
Oracle Identity Governance is a centralized identity management solution that provides self service, compliance, provisioning and password management services for applications residing on-premise or on the Cloud. Oracle Identity Governance connectors are used to integrate Oracle identity Governance with the external identity-aware applications.
The SAP UM connector can be integrated with two flavors of SAP target systems (SAP Netweaver ABAP Application Server and SAP GRC Access Request Management).
The SAP UM connector is used for provisioning and reconciling accounts from SAP NetWeaver ABAP Application Server. This connector also supports SoD validation feature with the help of SAP GRC Access Risk Analysis (ARA) module. The SAP AC UM Connector can be configured with SAP GRC Access Request Managent (ARM) module for user provisioning through web services.
Note:
In this guide, the connector that is deployed using the Applications option on the Manage tab of Identity Self Service is referred to as an AOB application. The connector that is deployed using the Manage Connector option in Oracle Identity System Administration is referred to as a CI-based connector (Connector Installer-based connector).Application onboarding is the process of registering or associating an application with Oracle Identity Governance and making that application available for provisioning and reconciliation of user information.
This following topics provide a high-level overview of the SAP UM connector:
Note:
In this guide, the term UM target system collectively refers to both SAP ERP and SAP CUA. Where information is specific to either SAP ERP or SAP CUA, the name of the target system has been used.1.1 Certified Components
These are the software components and their versions required for installing and using the connector.
Table 1-1 Certified Components
| Component | Requirement for AOB Application | Requirement for CI-Based connector |
|---|---|---|
|
Oracle Identity Governance or Oracle Identity Manager |
You can use one of the following releases of Oracle Identity Manager or Oracle Identity Governance:
|
You can use one of the following releases of Oracle Identity Manager or Oracle Identity Governance:
|
|
Target systems |
The target system can be any one of the following:
|
The target system can be any one of the following:
|
|
Connector Server |
11.1.2.1.0 or 12.2.1.3.0 |
11.1.2.1.0 or 12.2.1.3.0 |
|
Connector Server JDK |
JDK 1.6 Update 24 or later and JKD1.7 or later, or JRockit 1.6 or later |
JDK 1.6 Update 24 or later and JKD1.7 or later, or JRockit 1.6 or later |
|
External Code |
The connector works with SAP JCo 3.0.2 or later. The following SAP custom code files are required:
Note: There are different distribution packages (JCo) 3.0 available for various supported platforms and processors. See, JCo documentation for more information about using JCo 3.0 packages as per your environment. |
The connector works with SAP JCo 3.0.2 or later. The following SAP custom code files are required:
Note: There are different distribution packages (JCo) 3.0 available for various supported platforms and processors. See, JCo documentation for more information about using JCo 3.0 packages as per your environment. |
|
SAP Governance, Risk and Compliance Access Control (GRC AC) |
If you want to configure and use the Access Risk Analysis or Access Request Management feature of this target system, then install one of the following:
|
If you want to configure and use the Access Risk Analysis or Access Request Management feature of this target system, then install one of the following:
|
Note:
In general:
-
SAP applications installed on the ABAP stack are supported.
-
Applications installed on the JAVA stack are not supported.
-
Some SAP application can be installed on the ABAP+JAVA stack. While installing such an application, you specify ABAP or JAVA as the data source. The connector supports SAP applications that use the ABAP data source.
1.2 Usage Recommendation
These are the recommendations for the SAP UM connector versions that you can deploy and use depending on the Oracle Identity Governance or Oracle Identity Manager version that you are using.
Note:
In Oracle Identity Manager, you can install and configure both SAP UM and SAP UM Engine connectors.
You can configure the connectors with SAP GRC AC target system to use either the Access Risk Analysis or the Access Request Management feature.
-
If you are using Oracle Identity Governance 12cPS4 (12.2.1.4.0), 12cPS3 Release BP02 (12.2.1.3.2) and any later BP in this release track, SAP NetWeaver 7.51 SPS 00 with SAP S/4HANA 1610 and SAP BusinessObjects AC 10.1 or a later version, then use the latest 12.2.1.x version of this connector.
Deploy the connector using the Applications option from the Manage tab of Oracle Identity Self Service console.
-
If you are using Oracle Identity Manager release 11.1.2.x, as listed in the “Requirement for CI-Based Connector” column of Table 1-1, then use the 11.1.x version of the SAP User Management connector. If you want to use the 12.2.1.x version of this connector with Oracle Identity Manager release 11.1.2.x, then you can install and use the it only in the CI-based mode. If you want to use the AOB application, then you must upgrade to Oracle Identity Governance release 12.2.1.3.0. If you are using the latest 12.2.1.x version of the SAP UM connector in the CI-based mode, then see Oracle Identity Manager Connector Guide for SAP User Management, Release 11.1.1 for complete details on connector deployment, usage, and customization.
- SAP S/4HANA On-Premise: The traditional upgraded release of SAP ERP 6.0, to which the customers are mostly migrating, has SAP GUI-based access to the system with access to Fiori launchpad as well. It is a fully customer-controlled environment with respect to administration/support/maintenance. Recommendation - use Oracle Identity Governance - SAP User Management Connector. For more information about it, see About the SAP User Management Connector.
- SAP S/4HANA Cloud Private Edition: Everything is similar to SAP S/4HANA On-Premise, but the entire system control/administration/maintenance is with SAP. It is offered under the “Rise with SAP” program only as a Service with SAP GUI access given to the end/business users, who have access to Fiori Launchpad as well. Recommendation - use Oracle Identity Governance - SAP User Management Connector. For more information about it, see About the SAP User Management Connector.
- SAP S/4HANA Cloud Public Edition/Essential Edition: Core SaaS offering for S/4HANA, where the instance is provisioned, which has browser-based access only to the end/business users; No SAP GUI access is valid/exposed for this cloud instance. Recommendation - use Oracle Identity Governance - SAP S/4 HANA Cloud Connector. For more information about it, see Introduction to the Connector.
1.3 Certified Languages
These are the languages that the connector supports.
-
Arabic
-
Chinese (Simplified)
-
Chinese (Traditional)
-
Czech
-
Danish
-
Dutch
-
English
-
Finnish
-
French
-
French (Canadian)
-
German
-
Greek
-
Hebrew
-
Hungarian
-
Italian
-
Japanese
-
Korean
-
Norwegian
-
Polish
-
Portuguese
-
Portuguese (Brazilian)
-
Romanian
-
Russian
-
Slovak
-
Spanish
-
Swedish
-
Thai
-
Turkish
1.4 Supported Connector Operations
These are the list of operations that the connector supports for your target system.
Table 1-2 Connector Operations Supported by the SAP UM and SAP AC UM Connectors
| Operation | Supported for SAP UM? | Supported for SAP AC UM? |
|---|---|---|
|
User Management |
||
|
Create a user account |
Yes |
Yes |
|
Update a user account |
Yes |
Yes |
|
Delete a user account |
Yes |
Yes |
|
Enable a user account |
Yes |
Yes |
|
Disable a user account |
Yes |
Yes |
|
Lock a user account |
Yes |
Yes |
|
Unlock a user account |
Yes |
Yes |
|
Reset password |
Yes |
No |
|
Assign a role to a user account |
Yes |
Yes |
|
Assign multiple roles to a user account |
Yes |
Yes |
|
Remove a role from a user account |
Yes |
Yes |
|
Remove multiple roles from a user account |
Yes |
Yes |
|
Assign a profile to a user account |
Yes |
Yes |
|
Assign multiple profiles to a user account |
Yes | Yes |
|
Remove a profile from a user account |
Yes |
Yes |
|
Remove multiple profiles from a user account |
Yes | Yes |
|
Assign a group to a user account |
Yes |
No |
|
Assign multiple Groups to a user account |
Yes | No |
|
Remove a group to a user account |
Yes |
No |
|
Remove multiple groups from a user account |
Yes | No |
|
Assign a parameter to a user account |
Yes |
No |
|
Assign multiple parameters to a user account |
Yes | No |
|
Remove a parameter to a user account |
Yes |
No |
|
Remove multiple parameters from a user account |
Yes |
No |
|
Entitlements |
||
|
Add Role |
Yes |
Yes |
|
Add Multiple Roles |
Yes |
Yes |
|
Remove Role |
Yes |
Yes |
|
Remove Multiple Roles |
Yes |
Yes |
|
Add Profile |
Yes |
Yes |
|
Add Multiple Profiles |
Yes |
Yes |
|
Remove Profile |
Yes |
Yes |
|
Remove Multiple Profiles |
Yes |
Yes |
1.5 Connector Architecture
The SAP UM connector is implemented by using the Identity Connector Framework (ICF).
In its basic mode of operation, the connector sets up Oracle Identity Governance as the front end for sending account creation or modification provisioning requests to either SAP ERP or SAP CUA. While creating an application, you can opt for enabling either direct provisioning or request-based provisioning in Oracle Identity Governance. In direct provisioning, only Oracle Identity Governanc administrators can create and manage target system resources. In request-based provisioning, users can raise requests for creating and managing their accounts. Other users designated as administrators or approvers act upon these requests.
An access policy change is the third form of provisioning operation supported by the connector. If a change in an access policy requires corresponding changes in resources provisioned to a set of users, then the required provisioning operations on the target system are automatically initiated from Oracle Identity Governance.
Account data added or modified through provisioning operations performed directly on the target system can be reconciled into Oracle Identity Governance.
Figure 1-1 shows the connector integrating SAP ERP with Oracle Identity Governance.
Figure 1-1 Connector Integrating SAP ERP with Oracle Identity Governance
Description of "Figure 1-1 Connector Integrating SAP ERP with Oracle Identity Governance"
Figure 1-2 shows the connector integrating SAP CUA with Oracle Identity Governance.
Figure 1-2 Connector Integrating SAP CUA with Oracle Identity Governance
Description of "Figure 1-2 Connector Integrating SAP CUA with Oracle Identity Governance"
As shown in these figures, either SAP ERP or SAP CUA is configured as a target resource of Oracle Identity Governance. Through provisioning operations performed on Oracle Identity Governance, accounts are created and updated on the target system for OIM Users. Through reconciliation, account data that is created and updated directly on the target system is fetched into Oracle Identity Governance and stored against the corresponding OIM Users.
Note:
The connector does not support direct administration of accounts on child systems in SAP CUA. As shown in Figure 1-2, all connector operations are performed between Oracle Identity Governance and the SAP ERP parent system. When required, user data changes resulting from these connector operations are propagated from the parent system to the child system.
During provisioning, adapters carry provisioning data submitted through the process form to the target system. Standard BAPIs on the target system accept provisioning data from the adapters, carry out the required operation on the target system, and return the response from the target system to the adapters. The adapters return the response to Oracle Identity Governance.
During reconciliation, a scheduled task establishes a connection with the target system and sends reconciliation criteria to the BAPIs. The BAPIs extract user records that match the reconciliation criteria and hand them over to the scheduled task, which brings the records to Oracle Identity Governance.
Each record fetched from the target system is compared with SAP UM resources that are already provisioned to OIM Users. If a match is found, then the update made to the SAP record from the target system is copied to the SAP UM resource in Oracle Identity Governance. If no match is found, then the user ID of the record is compared with the user ID of each OIM User. If a match is found, then data in the target system record is used to provision an SAP UM resource to the OIM User.
1.6 Supported Deployment Configurations
These are the list of supported deployment configurations of the connector.
Besides enabling direct integration with the target system, the connector can also be used to act as an interface with the Access Risk Analysis and Access Request Management modules of SAP GRC. The target system (SAP ERP or SAP CUA) and these two modules of SAP GRC together provide various deployment configurations. The following sections provide information about the supported deployment configurations of the connector:
1.6.1 Basic User Management
When you configure the connector for basic user management, the connector accepts provisioning data submitted through Oracle Identity Governance and propagates this data to the target system. For example, when a Create User provisioning operation is performed on Oracle Identity Governance, the outcome is the creation of an account on the target system.
Account data added or modified through provisioning operations performed directly on the target system can be reconciled into Oracle Identity Governance.
Figure 1-1 and Figure 1-2show the architecture of the connector in this deployment configuration.
The steps performed during a provisioning operation can be summarized as follows:
-
The provisioning operation is initiated through direct provisioning, request-based provisioning, or an access policy change.
-
Provisioning data is sent to the target system.
-
The required change is made on the target system, and the outcome of the operation is sent back to and stored in Oracle Identity Governance.
1.6.2 User Management with SoD
You might have the Access Risk Analysis module of SAP GRC configured to implement segregation of duties (SoD) in your SAP operating environment. In this scenario, the connector can be used as the interface between Oracle Identity Governance and the SoD module. You can configure the connector so that provisioning requests sent from Oracle Identity Governance are first run through the SoD validation process of SAP GRC Access Risk Analysis. Provisioning requests that clear this validation process are then propagated from Oracle Identity Governance to the target system.
Reconciliation does not involve SAP GRC Access Risk Analysis. Account data added or modified through provisioning operations performed directly on the target system can be reconciled into Oracle Identity Governance.
In this guide, the phrase configuring SoD is used to mean configuring the integration between Oracle Identity Governance and SAP GRC Access Risk Analysis.
Figure 1-3 shows data flow in this mode of the connector.
Figure 1-3 Data Flow During the SoD Validation Process
Description of "Figure 1-3 Data Flow During the SoD Validation Process"
The steps performed during a provisioning operation can be summarized as follows:
See Also:
Using Segregation of Duties (SoD) in Oracle Fusion Middleware Developer’s Guide for Oracle Identity Manager 11g Release 2 (11.1.2.2) for detailed information about the provisioning process flow
-
The provisioning operation is initiated through direct provisioning, request-based provisioning, or an access policy change.
-
The resource approval workflow of Oracle Identity Governance sends this request to the SoD engine (SAP GRC Access Risk Analysis).
-
The SoD engine uses predefined rules to check if the entitlement assignment would lead to SoD violations. The outcome of this check is then sent back to Oracle Identity Governance.
-
If the request fails SoD validation, then the approval workflow can be configured to take remediation steps. If the request passes SoD validation and if the approver in Oracle Identity Governance approves the request, then the resource provisioning workflow is initiated.
-
This resource provisioning workflow can be configured to perform the SoD validation again. This is to ensure SoD compliance of the entitlement assignment immediately before the entitlement assignment is provisioned to the target system. You can also configure the SoD validation check in the resource provisioning workflow to be bypassed if this validation has been passed in the resource approval workflow.
-
The resource provisioning workflow performs the required change on the target system, and the outcome of the operation is sent back to and stored in Oracle Identity Governance.
Summary of the account management process:
-
Data from a provisioning operation on Oracle Identity Governance is first sent to the SAP GRC Access Risk Analysis module for SoD validation.
-
After the SoD validation checks are cleared, the provisioning request is sent to SAP GRC Access Request Management.
-
After the SAP GRC Access Request Management workflow clears the request, the provisioning request is implemented on the target system.
-
Scheduled tasks run from Oracle Identity Governance reconcile the outcome of the operation from the target system into Oracle Identity Governance.
1.6.3 Audit Trail Details in Connector Logs
The audit trail details can be captured in the connector logs when Access Request Management is configured.
Here are a few samples of Audit trail in the connector logs:
-
Create User
logAuditTrial : Audit Trial: {Result=[Createdate:20130409,Priority:HIGH,Requestedby:,johndoe (JOHNDOE),Requestnumber:9000001341,Status:Decision pending,Submittedby:,johndoe (JOHNDOE),auditlogData:{,ID:000C290FC2851ED2A899DA29DAA1B1E2,Description:,Display String:Request 9000001341 of type New Account Submitted by johndoe ( JOHNDOE ) for JK1APRIL9 JK1APRIL9 ( JK1APRIL9 ) with Priority HIGH}], Status=0_Data Populated successfully} -
Request Status Schedule Job
logAuditTrial : Audit Trial: {Result=[Createdate:20130409,Priority:HIGH,Requestedby:,johndoe (JOHNDOE),Requestnumber:9000001341,Status:Approved,Submittedby:,johndoe (JOHNDOE),auditlogData:{,ID:000C290FC2851ED2A899DA29DAA1B1E2,Description:,Display String:Request 9000001341 of type New Account Submitted by johndoe ( JOHNDOE ) for JK1APRIL9 JK1APRIL9 ( JK1APRIL9 ) with Priority HIGH,ID:000C290FC2851ED2A899DAF9961C91E2,Description:,Display String:Request is pending for approval at path GRAC_DEFAULT_PATH stage GRAC_MANAGER,ID:000C290FC2851ED2A89A1400B60631E2,Description:,Display String:Approved by JOHNDOE at Path GRAC_DEFAULT_PATH and Stage GRAC_MANAGER,ID:000C290FC2851ED2A89A150972D091E2,Description:,Display String:Auto provisioning activity at end of request at Path GRAC_DEFAULT_PATH and Stage GRAC_MANAGER,ID:000C290FC2851ED2A89A150972D111E2,Description:,Display String:Approval path processing is finished, end of path reached,ID:000C290FC2851ED2A89A150972D151E2,Description:,Display String:Request is closed}], Status=0_Data Populated successfully} -
Modify User
logAuditTrial : Audit Trial: {Result=[Createdate:20130409,Priority:HIGH,Requestedby:,johndoe (JOHNDOE),Requestnumber:9000001342,Status:Decision pending,Submittedby:,johndoe (JOHNDOE),auditlogData:{,ID:000C290FC2851ED2A89A3ED3B1D7B1E2,Description:,Display String:Request 9000001342 of type Change Account Submitted by johndoe ( JOHNDOE ) for JK1FirstName JK1APRIL9 ( JK1APRIL9 ) with Priority HIGH}], Status=0_Data Populated successfully}
1.6.4 User Management with Access Request Management
Access Request Management is a module in the SAP GRC suite. In an SAP environment, you can set up Access Request Management as the front end for receiving account creation and modification provisioning requests. In Access Request Management, workflows for processing these requests can be configured and users designated as approvers act upon these requests.
Note:
In this guide, (for the SAP UM AC Connector that uses the SAPUM-AC-Connector-CI.xml file) the phrase configuring Access Request Management has been used to mean configuring the integration between Oracle Identity Governance and SAP GRC Access Request Management.
This connector works as a normal SAP UM connector as there is no interaction with GRC target.
In your operating environment, the Access Request Management module might be directly linked with the Access Risk Analysis module. In other words, provisioning requests are first sent from Access Request Management to Access Risk Analysis for SoD validation. Only requests that clear the validation process are implemented on the target system. In this scenario, it is recommended that you do not configure the SoD feature of the connector.
Reconciliation does not involve SAP GRC Access Request Management. Scheduled tasks on Oracle Identity Governance fetch data from the target system to Oracle Identity Governance.
Figure 1-4 shows data flow in this mode of the connector.
Figure 1-4 Connector Integrating SAP GRC Access Request Management with Oracle Identity Governance and the Target System
Description of "Figure 1-4 Connector Integrating SAP GRC Access Request Management with Oracle Identity Governance and the Target System"
The following is the detailed sequence of steps performed during a provisioning operation:
-
The provisioning operation is initiated through direct provisioning, request-based provisioning, or an access policy change.
Figure 1-5 IT Resource Configuration Showing GRC in the SAP AC UM Flow
Description of "Figure 1-5 IT Resource Configuration Showing GRC in the SAP AC UM Flow" -
The connector sends requests and receives responses through the following Web services of SAP GRC:
-
SAPGRC_AC_IDM_SUBMITREQUEST: This Web service is used to submit requests.
-
SAPGRC_AC_IDM_REQUESTSTATUS: This Web service is used to fetch request statuses.
-
SAPGRC_AC_IDM_AUDITTRAIL: This Web service is used to check if there are error messages in the SAP GRC Access Request Management logs.
The process form holds fields for both basic user management and Access Request Management. However, for a Create User operation, Access Request Management fields (attributes) on the process form are also used. Mappings for these fields are stored in the Lookup.SAPAC10ABAP.UM.ProvAttrMap lookup definition based on GRC target version.
If you specify values for any attribute that is not present in these lookup definitions, then the connector ignores those attributes during the Create User operation.
Note:
SAP GRC Access Request Management does not process passwords. Therefore, any value entered in the Password field is ignored during Create User provisioning operations.
See Guidelines on Performing Provisioning for information about setting passwords when you configure Access Request Management.
In a Modify User operation, you can specify values for attributes that are mapped with SAP GRC Access Request Management.
-
-
When the request is created on SAP GRC Access Request Management, data sent back by Access Request Management is stored in the following read-only fields in Oracle Identity Governance:
-
AC Request ID: This field holds the request ID that is generated on SAP GRC Access Request Management. The AC Request ID does not change during the lifetime of the request.
-
AC Request Status: This field holds the status of the request on SAP GRC Access Request Management. You configure and run the SAP AC Request Status scheduled job to fetch the latest status of the request from the target system.
-
AC Request Type: This field holds the type of request, such as New Account, Change Account, Delete Account, New, and Change.
-
-
The request is passed through the workflow defined in SAP GRC Access Request Management. The outcome is one of the following:
-
If Access Request Management clears the request, then the outcome is the creation or modification of a user's account on the target system (SAP R/3 or SAP CUA). The status of the request is set to OK in case of SAP GRC 10. Then, a message is recorded in the Oracle Identity Governance logs.
-
If Access Request Management rejects the provisioning request, then the status of the request is set to Failed in case of SAP GRC 10. Then, a message is recorded in the Oracle Identity Governance logs.
-
If an error occurs during communication between Access Request Management and the target system, then the request remains in the Open state. A message stating that the operation has failed is recorded in the audit log associated with the request. An error message is displayed on the console.
-
Summary of the account management process:
-
Data from a provisioning operation on Oracle Identity Governance is sent to SAP GRC Access Request Management.
-
The workflow defined in SAP GRC Access Request Management sends the request to the SAP GRC Access Risk Analysis module for SoD validation.
-
After the SoD validation checks are cleared, the provisioning request is implemented on the target system.
-
Scheduled tasks run from Oracle Identity Governance reconcile the outcome of the operation from the target system into Oracle Identity Governance.
1.6.5 User Management with Both SoD and Access Request Management
You might have both SAP GRC Access Risk Analysis and Access Request Management configured in your SAP operating environment. You should configure the connector features for both SoD and Access Request Management at the same time only if the Access Risk Analysis and Access Request Management modules are separately configured, such as User Management with SoD and Access Request Management (that is, not linked) modules are separately configured in your operating environment.
Note:
If SAP GRC Access Request Management is configured to send provisioning requests to GRC Access Risk Analysis for SoD validation, then you must not configure the SoD feature of the connector.
1.6.6 Guidelines on Using a Deployment Configuration
These are the guidelines that you must apply while using any of the supported deployment configurations.
When you integrate Oracle Identity Governance with your SAP operating environment, you might have one of the following requirements in mind:
-
Use Oracle Identity Governance as the provisioning source for account management on SAP resources.
-
Leverage workflows and access policies configured in SAP GRC Access Request Management, with Oracle Identity Governance as the provisioning source for account management on SAP resources.
-
Use SAP GRC Access Risk Analysis for SoD enforcement and SAP GRC Access Request Management for user approval of provisioning requests sent through Oracle Identity Governance. Overall account management on SAP resources is performed through Oracle Identity Governance.
The following sections describe guidelines on the supported deployment configurations:
Note:
You must separately configure User Management with SoD, and Access Request Management.
1.6.6.1 User Management with SoD and Access Request Management
The following are deployment guidelines that you must apply for a scenario in which SAP GRC Access Risk Analysis and GRC AC Access Request Management are enabled and discretely configured modules:
-
Configure both SoD and Access Request Management features of the connector.
-
On SAP GRC Access Request Management, configure the no-stage approval for account creation. In other words, account creation requests must be auto-approved on Access Request Management.
If a role or profile is provisioned on Oracle Identity Governance but rejected on SAP GRC Access Request Management, then the role or profile is revoked from Oracle Identity Governance at the end of the next user reconciliation run. Therefore, you can have approval workflows defined for role and profile provisioning requests on SAP GRC Access Request Management.
1.6.6.2 User Management with Access Request Management
The following are deployment guidelines that you must apply for a scenario in which SAP GRC Access Request Management is configured and enabled in your SAP operating environment:
Note:
SAP GRC Access Risk Analysis is either configured as a linked module of SAP GRC Access Request Management or it is not used at all.
You must separately configure User Management with SoD, and Access Request Management.
-
On SAP GRC Access Request Management, configure the no-stage approval for account creation. In other words, account creation requests must be auto-approved on Access Request Management.
The scenario described earlier in this section explains this guideline.
-
Configure the Access Request Management feature of the connector.
-
Do not configure the SoD feature of the connector.
1.6.7 Considerations to Be Addressed When You Enable Access Request Management
These are the considerations you must keep in mind when you enable the Access Request Management feature of the connector.
-
Multiple requests are generated from Oracle Identity Governance in response to some provisioning operations. For example, if you assign multiple roles to a user in a particular provisioning operation, then one request is created and sent to Access Request Management for each role.
-
For a particular account, Oracle Identity Governance keeps track of the latest request only. This means, for example, if more than one attribute of an account has been modified in separate provisioning operations, then Oracle Identity Governance keeps track of data related to the last operation only.
-
A Modify User operation can involve changes to multiple process form fields or child form fields. For each field that is modified, one request is created and sent to SAP GRC Access Request Management. Only information about the last request sent to Access Request Management is stored in Oracle Identity Governance.
-
Only parent or child form requests can be submitted in a single operation. You cannot submit both parent and child form requests at the same time.
-
Enable linking of SAP HRMS and SAP R/3 or SAP CUA accounts only if a no-stage workflow has been defined for the Create User provisioning operations.
Linking of SAP HRMS and SAP ERP or SAP CUA Accounts describes the feature of the connector that stores the link between an SAP HRMS account created for an individual and the corresponding SAP R/3 or SAP CUA account created for the same individual. When you configure the Access Request Management feature, you should enable linking only if a no-stage approval has been defined for the Create User request type in SAP GRC Access Request Management. A no-stage approval is one in which no approvers are involved. All requests sent through a no-stage approval are automatically approved.
1.6.8 Guidelines on Configuring Security
These are the guidelines that you must apply while configuring security.
-
Secure communication
It is important to protect sensitive data by securing the communication between Oracle Identity Governance and the SAP system.
If you are using SAP User Management as the target system, then you must configure SNC (Secure Network Communication). See Configuring SNC to Secure Communication Between Oracle Identity Governance and the Target System for more information.
If you are using SAP GRC as the target system, then you must enable SSL between Oracle Identity Governance and SAP GRC. See Using an Identity Connector Server in Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Governance for the instructions.
-
Password management
For accounts created through Oracle Identity Governance, you can configure the connector so that users with newly created accounts are prompted to change their passwords at first logon or the password set while creating the account on Oracle Identity Governance is set as the new password on the target system.
See Configuring Password Changes for Newly Created Accounts for more information.
1.7 Supported Connector Features Matrix
Provides the list of features supported by the AOB application and CI-based connector.
Table 1-3 Supported Connector Features Matrix
| Feature | AOB Application | CI-Based Application |
|---|---|---|
| Support for SAP GRC Version 10 | Yes | Yes |
| Support for Connector Server | Yes | Yes |
| Support for Standard and Custom Single-Valued Attributes for Reconciliation and Provisioning | Yes | Yes |
| SoD Validation of Entitlement Requests | Yes | Yes |
| Routing of Provisioning Requests Through SAP GRC Access Request Management | Yes | Yes |
| Full and Incremental Reconciliation | Yes | Yes |
| Limited (Filtered) Reconciliation | Yes | Yes |
| Batched Reconciliation | Yes | Yes |
| Linking of SAP HRMS and SAP R/3 or SAP CUA Accounts | Yes | Yes |
| SNC Communication Between the Target System and Oracle Identity Governance | Yes | Yes |
| Configuring Password Changes for Newly Created Accounts | Yes | Yes |
| Specifying a SAP JCo Trace Level | Yes | Yes |
| Connection Pooling | Yes | Yes |
| Specifying the Use of a Logon Group on the Target System for Connector Operations | Yes | Yes |
| Transformation and Validation of Account Data | Yes | Yes |
| Support for Resource Exclusion Lists | Yes | Yes |
| Support for Both Unicode and Non-Unicode Modes | Yes | Yes |
1.8 Connector Features
The features of the connector include support for connector server, full reconciliation, incremental reconciliation, limited reconciliation, reconciliation of updates to account data, and so on.
The following are the features of the connector:
-
Support for SAP Governance, Risk, and Compliance Version 10 or Later
-
Support for Standard and Custom Single-Valued Attributes for Reconciliation and Provisioning
-
Routing of Provisioning Requests Through SAP GRC Access Request Management
-
SNC Communication Between the Target System and Oracle Identity Governance
-
Specifying the Use of a Logon Group on the Target System for Connector Operations
1.8.1 Support for SAP Governance, Risk, and Compliance Version 10 or Later
You can use this connector for risk analysis and remdiation and for provisioning and managing users.
The connector supports the following new components:
-
Risk Analysis and Remediation, also known as Access Risk Analysis (ARA)
-
Compliant User Provisioning, also known as Access Request Management (ARM)
Throughout this guide, SAP GRC Access Risk Analysis refers to Risk Analysis and Remediation and SAP GRC Access Request Management refers to Compliant User Provisioning.
1.8.2 Support for the Connector Server
Connector Server is one of the features provided by ICF. By using one or more connector servers, the connector architecture permits your application to communicate with externally deployed bundles.
A Java connector server is useful when you do not wish to execute a Java connector bundle in the same VM as your application. It can be beneficial to run a Java connector on a different host for performance improvements.
For information about installing, configuring, and running the Connector Server, and then installing the connector in a Connector Server, see Using an Identity Connector Server in Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Governance.
1.8.3 SoD Validation of Entitlement Requests
You can validate an entitlement request in Oracle Identity Governance with an SoD Engine.
The connector supports the SoD feature in Oracle Identity Governance and the following updates have been made in this feature:
-
The SoD Invocation Library (SIL) is bundled with Oracle Identity Governance. The SIL acts as a pluggable integration interface with any SoD engine.
-
The SAP User Management connector can be configured to work with SAP GRC as the SoD engine. To enable this, changes have been made in the approval and provisioning workflows of the connector.
-
The SoD engine processes role and profile entitlement requests that are sent through the connector. This preventive simulation approach helps identify and correct potentially conflicting assignment of entitlements to a user, before the requested entitlements are granted to users.
See Also:
Configuring SoD (Segregation of Duties) in this guide.
Note:
If you are using SAP User Management with SOD, ensure to request entitlements from the Entitlements tab.
1.8.4 Support for Standard and Custom Single-Valued Attributes for Reconciliation and Provisioning
The connector provides a default set of attribute mappings for provisioning and reconciliation between Oracle Identity Governance and the target system. If required, you can add new user or group attributes for provisioning and reconciliation.
You can create mappings for attributes that are not included in the list of default attribute mappings. These attributes can be part of the standard set of attributes provided by the target system or custom attributes that you add on the target system.
See Extending the Functionality of the SAP User Management Connector for more information.
1.8.5 Routing of Provisioning Requests Through SAP GRC Access Request Management
You can configure the connector to work with SAP GRC Access Request Management.
See User Management with Access Request Management for detailed information about this feature.
1.8.6 Full and Incremental Reconciliation
In full reconciliation, all records are fetched from the target system to Oracle Identity Governance. In incremental reconciliation, only records that are added or modified after the last reconciliation run are fetched into Oracle Identity Governance.
At the end of a reconciliation run, an attribute of the scheduled task holds the time stamp at which the reconciliation run began.
You can switch from incremental to full reconciliation at any time after you deploy the connector. See Performing Full and Incremental Reconciliation for more information.
1.8.7 Limited (Filtered) Reconciliation
To limit or filter the records that are fetched into Oracle Identity Governance during a reconciliation run, you can specify the subset of added or modified target system records that must be reconciled.
See Performing Limited Reconciliation for more information.
1.8.8 Batched Reconciliation
You can break down a reconciliation run into batches by specifying the number of records that must be included in each batch.
See the description of the Batch Size attribute in Performing Batched Reconciliation for more information.
1.8.9 Enabled and Disabled Accounts
Valid From and Valid Through are two user attributes on the target system. For a particular user in SAP, if the Valid Through date is less than the current date, then the account is in the Disabled state. Otherwise, the account is in the Enabled state. The same behavior is duplicated in Oracle Identity Governance through reconciliation. In addition, you can set the value of the Valid Through date to a current date or a date in the past through a provisioning operation.
Note:
The Enabled or Disabled state of an account is not related to the Locked or Unlocked status of the account.
1.8.10 Linking of SAP HRMS and SAP ERP or SAP CUA Accounts
An SAP HRMS account created for an individual can be linked with the SAP ERP or SAP CUA account created for the same user. For a particular user, an attribute of SAP HRMS holds the user ID of the corresponding SAP ERP or SAP CUA account.
You can duplicate this link in Oracle Identity Governance by using the following entries of the Lookup.SAPABAP.Configuration lookup definition:
-
validatePERNR
-
overwriteLink
See Linking of SAP HRMS and SAP ERP or SAP CUA Accounts for more information.
1.8.11 SNC Communication Between the Target System and Oracle Identity Governance
You can configure Secure Network Communication (SNC) to secure communication between Oracle Identity Governance and the target system.
See Configuring SNC to Secure Communication Between Oracle Identity Governance and the Target System for more information.
1.8.12 Configuring Password Changes for Newly Created Accounts
When you log in to SAP by using a newly created account, you are prompted to change your password at first logon. For accounts created through Oracle Identity Governance, password management can be configured by using the changePasswordAtNextLogon parameter of the Configuration Lookup. If you are using the AOB implementation, see the Advanced Configuration section. You can apply one of the following approaches:
-
Configure the connector so that users with newly created accounts are prompted to change their passwords at first logon. To achieve this, set the changePasswordAtNextLogon parameter to yes. With this setting, the password entered on the process form for a new user account is used to set the password for the new account on the target system. When the user logs in to the target system, the user is prompted to change the password.
-
Configure the connector so that the password set while creating the account on Oracle Identity Governance is set as the new password on the target system. The user is not prompted to change the password at first logon. To achieve this, set the value of changePasswordAtNextLogon parameter to no and enter a string in the dummyPassword parameter of the IT Resource. If you are using the AOB implementation, see the Basic Configuration section.
With these settings, when you create a user account through Oracle Identity Governance, the user is first created with the dummy password. Immediately after that, the connector changes the password of the user to the one entered on the process form. When the user logs in to the target system, the user is not prompted to change the password.
1.8.13 Specifying a SAP JCo Trace Level
The connector uses the SAP JCo for reconciliation and provisioning operations. The JCo trace level is a numeric specification of the level of trace data that must be logged when the SAP JCo is used. You can specify the trace level as a parameter of the IT resource.
1.8.14 Connection Pooling
A connection pool is a cache of objects that represent physical connections to the target system. Oracle Identity Governance connectors can use these connections to communicate with target systems.
At run time, the application requests a connection from the pool. If a connection is available, then the connector uses it and then returns it to the pool. A connection returned to the pool can again be requested for and used by the connector for another operation. By enabling the reuse of connections, the connection pool helps reduce connection creation overheads like network latency, memory allocation, and authentication.
One connection pool is created for each set of basic configuration parameters that you provide while creating an application. For example, if you have three applications for three installations of the target system, then three connection pools are created, one for each target system installation. For more information about the parameters that you can configure for connection pooling, see Table 3-3.
1.8.15 Specifying the Use of a Logon Group on the Target System for Connector Operations
In SAP, a logon group is used as a load-sharing mechanism. When a user logs in to a logon group, the system internally routes the connection request to the logon group member with the least load. You can configure the connector to use a logon group for logging in to the target system for reconciliation and provisioning operations.
1.8.16 Transformation and Validation of Account Data
You can configure transformation and validation of account data that is brought into or sent from Oracle Identity Governance during reconciliation and provisioning operations by writing Groovy scripts while creating your application.
For more information, see Validation and Transformation of Provisioning and Reconciliation Attributes in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
1.8.17 Support for Resource Exclusion Lists
You can specify a list of accounts that must be excluded from reconciliation and provisioning operations. Accounts whose user IDs you specify in the exclusion list are not affected by reconciliation and provisioning operations.
See Validation Groovy Script for Resource Exclusion in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance for more information about configuring resource exclusion lists.