1 About the SAP User Management Engine Connector
Oracle Identity Governance is a centralized identity management solution that provides self service, compliance, provisioning and password management services for applications residing on-premises or on the Cloud. Oracle Identity Governance connectors are used to integrate Oracle identity Governance with the external identity-aware applications.
The SAP UME Connector is used for provisioning and reconciling accounts from SAP NetWeaver Java Application Server. This connector also supports the SoD validation feature with the help of SAP Goverance, Risk, and Compliance (GRC) Access Risk Analysis (ARA) module. The SAP AC UME 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.
The following topics provide a high-level overview of the connector:
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 one of the following:
Note: If you install an SAP application in Java stack, such as SAP Enterprise Portal, then the connector can connect to SAP User Management Engine (UME) of the application. If you install an SAP application, such as SAP Business Warehouse (BW) or SAP Supplier Relationship Management (SRM), in Advanced Business Application Programming (ABAP) stack, then you must configure SAP Enterprise Portal against SAP user Management Engine (UME) of the application. See the respective target system documentation for information about this configuration. If you install an SAP application, such as SAP Process Integration (PI), in dual stack (ABAP and Java), then the connector can connect to SAP UME of the application. However, the limitations of the ABAP data source are applicable. |
The target system can be one of the following:
Note: If you install an SAP application in Java stack, such as SAP Enterprise Portal, then the connector can connect to SAP User Management Engine (UME) of the application. If you install an SAP application, such as SAP Business Warehouse (BW) or SAP Supplier Relationship Management (SRM), in Advanced Business Application Programming (ABAP) stack, then you must configure SAP Enterprise Portal against SAP User Management Engine (UME) of the application. See the respective target system documentation for information about this configuration. If you install an SAP application, such as SAP Process Integration (PI), in dual stack (ABAP and Java), then the connector can connect to SAP UME of the application. However, the limitations of the ABAP data source are applicable. |
|
Connector Server |
11.1.2.1.0 |
11.1.2.1.0 |
|
Connector Server JDK |
JDK 1.6 update 24 or later and JDK 1.7 or later, or JRockit 1.6 or later |
JDK 1.6 update 24 or later and JDK 1.7 or later, or JRockit 1.6 or later |
|
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 the following:
|
If you want to configure and use the Access Risk Analysis or Access Request Management feature of this target system, then install the following:
|
1.2 Usage Recommendation
These are the recommendations for the SAP UME 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 Governance, you can install and configure both SAP User Management and SAP User Management Engine connectors.
You can configure the connectors with SAP GRC target system to use either Access Risk Analysis or Access Request Management feature.
-
If you are using Oracle Identity Governance releases 12c BP02 (12.2.1.3.2) or 12.2.1.4.0, then use the latest 12.2.1.x version of this connector. Deploy the connector using the Applications option on the Manage tab of Identity Self Service.
-
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 Engine 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 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.
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 UME and SAP AC UME Connectors
| Operation | Supported for SAP UME? | Supported for SAP AC UME? |
|---|---|---|
| User Management | ||
| Create a user account | Yes | Yes |
| Modify 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 |
| Assign a role to a user account | Yes | Yes |
| Assign multiple roles to a user account | Yes | Yes |
| Remove role for a user account | Yes | Yes |
| Remove multiple roles from a user account | Yes | Yes |
| Assign a group to a user account | Yes | No |
| Assign multiple groups from a user account | Yes | No |
| Remove a group for user account | Yes | No |
| Remove multiple groups 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 |
1.5 Connector Architecture
The SAP UME connector is implemented by using the Identity Connector Framework (ICF).
The connector sets up Oracle Identity Governance as the front end for sending account creation or modification requests to applications that use the data source linked with SAP User Management Engine.
The connector reconciles any account data added or modified through provisioning operations performed directly on the data source into Oracle Identity Governance through SAP User Management Engine.
Figure 1-1 shows the connector integrating SAP User Management Engine with Oracle Identity Governance.
As shown in the figure, SAP User Management Engine is configured as the management tool for user data stored on a data source, which is either the ABAP module, AS (Application Server) Java data source, or an LDAP-based solution. User data changes made through the SAP User Management Engine UI are reflected on applications that use the data source or on the UI of the LDAP-based solution.
By creating an application, you configure SAP User Management Engine as a target resource of Oracle Identity Governance.
Oracle Identity Governance sends provisioning requests which are routed through the SPML service to the application or system that uses the data source linked with SAP User Management Engines. You can view the user data changes resulting from the provisioning requests through the SAP User Management Engine UI.
You can configure the connector to run in the account management mode. Account management is also known as target resource management. In the account management mode, the target system is used as a target resource. This mode of the connector enables the following operations:
-
Provisioning
Provisioning involves creating or updating users on the target system through Oracle Identity Governance. When you allocate (or provision) an SAP User Management Engine resource to an OIG User, the operation results in the creation of an account on SAP UME for that user. In the Oracle Identity Governance context, the term provisioning is also used to mean updates made to the target system account through Oracle Identity Governance.
During provisioning, adapters carry provisioning data submitted through the process form to the target system. The SPML service in the SAP User Management Engine accepts provisioning data from the adapters, performs the necessary provisioning operation, and then returns the response to adapters in Oracle Identity Governance.
-
Reconciliation
The scheduled task provided by the connector acts as the SPML client to send SPML requests to the SPML service in this application server.
During reconciliation, a scheduled task establishes a connection with the SPML service. Reconciliation criteria are sent through SPML requests to this SPML service. The SPML service processes the requests and returns SPML responses containing user records that match the reconciliation criteria. The scheduled task brings these records to Oracle Identity Governance.
Each record fetched from the target system is compared with SAP User Management Engine resources that are already provisioned to OIG Users. If a match is found, then the update made to the record is copied to the SAP User Management Engine 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 OIG User. If a match is found, then data in the target system record is used to provision an SAP User Management Engine resource to the OIG User.
1.6 Supported Deployment Configurations
These are the list of supported deployment configurations for the connector.
You can use the connector to act as an interface with the Access Risk Analysis and Access Request Management modules of SAP GRC in addition to enabling direct integration with the target system. The target system (SAP NetWeaver Java Application Server) 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 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, the phrase configuring Access Request Management has been used to mean configuring the integration between Oracle Identity Governance and SAP GRC Access Request Management.
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-2 shows data flow in this mode of the connector.
Figure 1-2 Connector Integrating SAP GRC Access Request Management with Oracle Identity Governance and the Target System
Description of "Figure 1-2 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.
-
An SPML Create User request is run on the target system to determine one of the following:
-
For a Create User operation, if the SPML Create User request determines that the user exists on the target system, then an error message is displayed. If the user does not exist, then a request is created out of the provisioning data and sent to SAP GRC Access Request Management.
-
For a Create User operation, if the SPML Create User request determines that the user does not exist on the target system, then an error message is displayed. If the user exists, then a request is created out of the provisioning data and sent to SAP GRC Access Request Management.
The connector sends requests and receives responses through the following web services of SAP GRC:
-
GRAC_USER_ACCESS_WS: This Web service is used to submit requests.
-
GRAC_REQUEST_STATUS_WS: This Web service is used to fetch request statuses.
-
GRAC_AUDIT_LOGS_WS: 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, only the Access Request Management fields (attributes) on the process form are used.
Note:
SAP GRC Access Request Management does not process passwords. Therefore, during Create User provisioning operations, the system ignores any value that you enter in the password field.
See Guidelines on Performing Provisioning for information about setting passwords when you configure Access Request Management.
For a Modify User operation, a request is created only for attributes whose mappings are present in these lookup definitions. If you specify values for attributes that are not present in these lookup definitions, then the connector directly sends them to the target system.
Note:
In a Modify User operation, you can specify values for attributes that are mapped with SAP GRC Access Request Management and attributes that are directly updated on the target system.
-
-
When you create a request 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 UME). The status of the request is set to OK. 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. 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.
-
-
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.2 Audit Trail Details in Connector Logs
You can capture the audit trail details in the connector logs after configuring the Access Request Management.
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.3 User Management with SoD
If the Access Risk Analysis module of SAP GRC is configured to implement segregation of duties (SoD) in your SAP operating environment, the connector can be used as the interface between Oracle Identity Governance and the SoD module. You can configure the connector to first process the provisioning requests sent from Oracle Identity Governance through SoD validation 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:
-
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.
1.6.4 User Management with Both SoD and Access Request Management
If both SAP GRC Access Risk Analysis and Access Request Management are configured in your SAP operating environment, then 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 discretely configured (that is, not linked) modules in your operating environment.
Note:
If SAP GRC Access Request Management is configured to send provisioning requests to SAP GRC Access Risk Analysis for SoD validation, then you must not configure the SoD feature of the connector.
-
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.5 Guidelines on Using an Application Configuration
These are the guidelines that you must apply while using an application configuration.
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 application configurations:
Note:
There are no special guidelines for the Basic User Management configuration and the User Management Engine with SoD configuration.
1.6.5.1 User Management Engine 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 SAP GRC 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 provisioning requests on SAP GRC Access Request Management.
1.6.5.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.
-
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.6 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.
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 Connector | CI-Based Connector |
|---|---|---|
| Full reconciliation | Yes | Yes |
| Limited (filtered) reconciliation | Yes | Yes |
| Provision requests through SAP GRC access request management | Yes | Yes |
| SoD validation of entitlement requests | Yes | Yes |
| Enable and disable accounts | Yes | Yes |
| Provision and reconcile user-related data to and from multiple data sources | Yes | Yes |
| Remove role assignment in Federated Portal Network (FPN) configuration | Yes | Yes |
| Configure transformation and validation of account data | Yes | Yes |
| Specify accounts to be excluded from all reconciliation and provisioning operations | Yes | Yes |
| Test Connection | Yes | No |
1.8 Connector Features
The features of the connector include SoD validation of entitlement requests, full reconciliation, limited reconciliation and some additional features like support for multiple data sources, support for remote role assignment in federated portal network (FDN) and so on.
The following are the features of the connector:
1.8.1 Full Reconciliation
In full reconciliation, all records are fetched from the target system to Oracle Identity Governance.
Note:
The SPML UME API does not return records for which the Last Modified Date value is greater than a specified date. Therefore, the connector cannot support incremental reconciliation. This point is also mentioned in Limitations Related to Target System Features and Specific Connectors.
In full reconciliation, all records are fetched from the target system to Oracle Identity Governance. During reconciliation, an SPML request is sent to the target system to fetch user accounts with user IDs that start with valid characters allowed in SAP. See the logonNameInitialSubstring entry in the Table 3-2 for a list of all valid characters.
During full reconciliation, a single reconciliation event is generated for each target system account. For more information, see Performing Full Reconciliation.
1.8.2 Limited (Filtered) Reconciliation
You can reconcile records from the target system based on a specified filter criterion. 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.
You can set a reconciliation filter as the value of the Filter Suffix attribute of the user reconciliation scheduled job. The Filter Suffix attribute helps you to assign filters to the API based on which you get a filtered response from the target system.
See Performing Limited Reconciliation for more information.
1.8.3 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.4 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.
-
Configure the connector to work with SAP GRC as the SoD engine.
Note:
The default approval workflow and associated object form are configured for the SoD validation capabilities of SAP GRC. You can use them to develop your own approval workflows and object forms.
-
The SoD engine processes role 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 Configuring SoD (Segregation of Duties) for more information about configuring SoD.
Note:
If you are using SAP User Management with SOD, ensure to request entitlements from the Entitlements tab.1.8.5 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.6 Support for Multiple Data Sources
You can configure the SAP User Management Engine connector for provisioning and reconciling user-related data to and from multiple data sources such as Lightweight Directory Access Protocol (LDAP) directories, system database of the SAP NetWeaver Application Server Java, and user management of an Application Server ABAP. In other words, this connector can be configured for performing user management operations from user management engines irrespective of the data source configuration.
1.8.7 Support for Remote Role Assignment in Federated Portal Network
Federate Portal Network (FPN) allows organizations with multiple portals, SAP and non-SAP, to share content between independent portals. In FPN, the producers hold and run the applications. The consumer manages the redirect to producer portals. In FPN configuration, the content can be shared throughout the network using Remote Role Assignment content usage mode. It enables the consumer to assign roles offered by a producer. The SAP User Management Engine connector can be used to support Remote Role Assignment in FPN configuration.
1.8.8 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.9 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.10 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.