SAP BusinessObjects Access Control provides two interfaces for integration with Waveset. It provides a set of web services that Waveset can use to send and receive instructions needed to ensure a user has access to SAP applications. In addition, SAP Access Control can use SPML to send provisioning requests to Waveset so that SAP Access Control can enforce compliance and other features on resources that it does not directly support.
This document describes three options you can use to integrate SAP Access Control with Waveset.
External Policy Check Integration. Waveset submits requests using web services to SAP Access Control for Segregation of Duties (SoD) compliance. This option uses Waveset as the front-end interface and initiates requests into SAP Access Control for risk analysis, and if the risk analysis returns no violations or those violations are approved in Waveset, the request is provisioned using the SAP connector. This integration requires an SAP Access Control adapter to handle all web service requests and an SAP connector for provisioning.
External Resource Integration. Waveset submits provisioning requests using web services to SAP Access Control. This option uses Waveset to initiate the workflow processes configured in SAP Access Control. SAP Access Control will then perform the provisioning operations after its workflow processes and approvals are complete. This integration requires an SAP Access Control adapter to handle all web service requests and an external resource for provisioning.
SPML 1.0 Integration. SAP Access Control submits requests to Waveset for provisioning on non-SAP systems.
The external policy check integration allows an external policy product, such as SAP BusinessObjects Access Control, to perform a risk analysis when a user account is created or updated. Waveset gathers the relevant data and submits it to SAP Access Control. If risk analysis or SoD violations are returned, then the Waveset administrator determines whether to approve the violations or to reject the request entirely. If the administrator wants to change the SAP role assignments in a compliance violation, the request must be rejected and submitted again.
The following diagram illustrates the interaction between Waveset and SAP Access Control in this integration.
Waveset uses web services to communicate with the SAP Access Control resource. When Waveset receives a request to create or update a user, the Create User or Update User workflow launches the Check External Policy workflow.
The user view is queried for an accounts[Lighthouse].properties.externalPolicy[ResourceName] object. Each ResourceName in the list specifies a resource on which to execute the external policy check. If objects for a resource do not exist, control is returned to the Create User or Update User workflow, respectively.
If objects exist, the Check External Policy workflow starts a deferred task that executes the external policy check on each resource. For SAP Access Control, this deferred task executes the risk analysis web service. While the risk analysis is executing, the workflow generates a temporary work item that suspends the create or update request until the external policy check is complete. The task runs synchronously, therefore the task monitors for the completion of the policy check and returns the risk analysis results to the workflow.
If the SAP Access Control resource returns one or more violations, the policy check creates a compliance violation work item. The Compliance Violation Owner rule determines who the owner of the work item and therefore who it is assigned to. By default, the rule assigns the work item to the manager defined in Waveset. If the rule cannot determine who to assign the rule to, it assigns it to the requestor.
Once the compliance violation has been assigned an owner, the owner can process the work item in the following ways:
Approve the policy check. In this case, any violations are ignored, and Waveset continues to provision the user.
Reject the request. The account is not provisioned on the SAP resource.
If a previously-provisioned user has had a compliance violation check, any roles added in the future will generate compliance violation work items, regardless if the items would cause a compliance violation. If the request is rejected, only the requested roles will be rejected. The previous roles and provisioned users remain intact. This is because Waveset does not make any decisions or assumptions regarding the external policy service.
The $WSHOME/sample/rules/SAPAccessControlRules.xml file defines the SAPAccessControl rule library, which is used in the SAP Access Control and External SAP Access Control user forms and through a FormRef in the SAP Connector User Form. You may need to customize the following rules:
Aggregate Roles
Compliance Violation Owner
Process Policy Result
Risk Analysis Status
If you change the name of these rules, you must modify the prototype XML in the SAP Access Control adapter to match the renamed rule.
The SAP Access Control Check Status rule is not used in an external policy check integration.
The forms used in this integration are defined in the SAPAccessControlUserForm.xml and the SAPAccessControlCompViolForm.xml files. The SAP Access Control user form aggregates the data required for performing a risk analysis. This data is placed in the accounts[Lighthouse].properties.externalPolicies[ResourceName] property in the User view. Also refer to the Javadocs for the classes in the com.sun.idm.ws package for detailed information about the SAP Access Control web services.
The SAP Access Control Compliance Violation Form controls the display of the compliance violation details on the Compliance Violations page. If you change the name of this form, you must modify the prototype XML in the SAP Access Control adapter to match the renamed form.
An SAP connector handles all provisioning requests. You must create an SAP connector for each SAP Access Control application name (SAP system) that SAP Access Control manages. SAP Access Control performs the risk analysis for all these systems, but the SAP connector performs the provisioning. Refer to the SAP connector documentation for detailed information.
You cannot use an SAP adapter to provision. If you have an existing SAP adapter, you must migrate to the adapter to an SAP connector. Refer to Chapter 57, Identity Connectors Overview, in Oracle Waveset 8.1.1 Resources Reference for information about migrating.
For information on this connector, and the Identity Connector project, refer to the https://identityconnectors.dev.java.net website.
The SAP Access Control AuditLog Report can be used to return information that is contained in the SAP Access Control audit log. This report is not installed by default, but is provided in the $WSHOME/sample/sapreports.xml file.
The external policy check integration supports the following web services for Risk Analysis and Remediation (RAR):
SAPGRC_AC_IDM_SUBMITREQUEST
SAPGRC_AC_IDM_RISKANALYSIS
In addition, the SAP Access Control AuditLog Report uses the SAPGRC_AC_IDM_AUDITTRAIL web service.
Use the following guidelines to implement the external policy check integration in an environment in which you have not integrated Access Enforcer 5.2 or earlier. Before beginning this procedure, you must set up SAP Access Control as described in the “Access Control and Identity Manager” Integration chapter in the SAP GRC Access Control Configuring SAP with Release 5.3 guide, which is available from SAP. If you have previously integrated Access Enforcer, see “Migrating from Access Enforcer Version 5.1 or 5.2” in this document.
Disable the autoprovisioning feature within SAP Access Control for the external policy check integration. Otherwise, the user will be provisioned by Access Control, and not by Waveset. If you want autoprovisioning, then implement the external resource integration.
Create an SAP Access Control adapter.
Create an SAP connector. Be sure to configure the following parameters.
Select the Configure Policy Resource check box.
Select the SAP Access Control resource from the Policy Resource menu.
Select the SAP Access Control application associated with this connector from the Instance ID menu.
Repeat this step for each SAP Access Control application.
Copy the following files and make any required modifications. Be sure to save the original files.
$WSHOME/sample/rules/SAPAccessControlRules.xml
$WSHOME/sample/forms/SAPAccessControlUserForm.xml
$WSHOME/sample/forms/SAPAccessControlCompViolForm.xml
Then import the modified files.
The SAP connector glue code contains a sample SAP Connector User Form (SAPUserForm.xml). This file contains commented code that needs to be enabled. Delete the comment marks around the Include statement near the top of the file. Then delete the comment marks around the Field that contains the FormRef to the SAP Access Control User Form. Then import this file.
Configure the User Deferred Task Scanner to run periodically. The default interval is 1 hour. To obtain the risk analysis results as quickly as possible, the interval for the deferred task should be set as low as possible.
View compliance violations from the Work Items area of the administrator interface. Selecting the Compliance Violations tab in the Work Items area lists all the violations requiring approval or rejection for the current administrator. From this page, you can also list compliance violations for all of your direct reports and for specified users for which you have direct or indirect control.
The following are possible responses to a compliance violation:
Approve. Accepts the risk displayed in the compliance violation. This will probably generate a risk violation on the external system.
Reject. Does not accept the risk. The provisioning operation ends.
Refresh. Updates the list of compliance violations.
Forward. Enables you to specify another recipient to review the compliance violation.
Click the Request link to view detailed information about the compliance violation. The risk code, SAP application, description, severity level, violation count, and violation details are displayed. Refer to the SAP Access Control documentation for more information about these fields.
The external resource integration is provided to accommodate customers who already have an investment in an SAP Access Enforcer 5.1 or 5.2 custom workflow. The external resource provides the best way to integrate with this type of asynchronous functionality because in this configuration, SAP Access Control is considered a black box and as disconnected until the pending provisioning operation has been performed.
SAP Access Control can be considered a write-only resource because it has no user store of any kind. The external resource data store contains the user data sent to SAP Access Control on each request. This data store provides a way for Waveset to read the data that was last sent to Access Control. However, the data is not necessarily synchronized with SAP Access Control back-end systems. It only provisions the users to its configured SAP systems (applications).
This integration does not perform an external policy check or generate compliance violations.
The following diagram illustrates the interaction between Waveset and SAP Access Control in this integration.
The external resource must be configured with a database user store (not LDAP) that contains the attribute values being provisioned. In addition, it must be configured to perform notifications by web services. To do this, set the Provisioner Notification Type parameter to Web Service. When the external resource is configured in this way, you must specify a rule to determine the status of web service requests. The $WSHOME/sample/rules/SAPAccessControlRules.xml file provides the SAP Access Control Check Status rule to fulfill this requirement.
The User Deferred Task Scanner polls SAP Access Control for the status of the provisioning request sent to SAP Access Control. When the request is complete, Waveset updates the workitem to indicate that the provisioning request is no longer pending, setting the status of the associated provisioning request work item to either completed or not complete.
The SAP Access Control AuditLog Report can be used to return information that is contained in the SAP Access Control audit log. This report is not installed by default, but is provided in the $WSHOME/sample/sapreports.xml file.
The external resource integration supports the following web services for Compliant User Provisioning (CUP):
SAPGRC_AC_IDM_REQUESTSTATUS
SAPGRC_AC_IDM_ROLEDETAILS
SAPGRC_AC_IDM_SEARCHROLES
SAPGRC_AC_IDM_SELECTAPPLICATION
SAPGRC_AC_IDM_SUBMITREQUEST
In addition, the SAP Access Control AuditLog Report uses the SAPGRC_AC_IDM_AUDITTRAIL web service.
Use the following procedure to integrate Waveset with SAP Access Control using an external resource.
Create an SAP Access Control Web Service adapter.
Import the following files:
$WSHOME/sample/rules/SAPAccessControlRules.xml
$WSHOME/sample/forms/ExternalSAPAccessControlUserForm.xml
Create an external resource. Refer to Understanding and Managing External Resources in Oracle Waveset 8.1.1 Business Administrator’s Guide for more information. The resource must have a database data source with Web Service notification. Be sure to follow these steps:
Select Web Service as the Provisioner Notification Type.
Select the desired SAP Access Control resource.
Select either the SAP Access Control Check Status Rule or your customized rule to perform the status check. The SAP Access Control Check Status Rule is provided in the SAPAccessControlRules.xml file.
Select the Provisioning Request form for SAP Access Control. The recommended form is the SAP Access Control Provisioning Request Form, but you may also select a customized form.
The account attributes page will be populated with attributes from the SAP Access Control resource, but they cannot be edited. If you make any changes to the attributes on the SAP Access Control resource, load the external resource account attributes page and click the Save button. Refer to the SAP Access Control adapter documentation for a list of default attributes.
Merge the External SAP Access Control User Form with your version of the Tabbed User Form.
Configure the User Deferred Task Scanner to run periodically. The interval for this task will determine how often the status of the provisioning request will be checked. The default interval is 1 hour.
Upgrading from an SAP Access Enforcer resource to an external resource that connects to SAP Access Control 5.3 requires multiple tasks. Read the following procedure carefully.
Waveset provides a sample workflow, InstallDir/sample/wfexternalmigration.xml, for the purpose of migrating users from SAP Access Enforcer to SAP Access Control 5.3. It must be customized according to your environment and configuration.
The workflow requires the following account attributes:
acRequestorId
acRequestorFirstname
acRequestorLastname
acRequestorEmail
acManagerId
acManagerFirstname
acManagerLastname
acManagerEmail
acPriority
acUserId
acApplications
acRole
You may add attributes as needed.
This workflow currently displays the result of each user update. The current way around this is to modify the taskLaunch.jsp so that instead of displaying the results, the page is redirected back to the taskList.jsp page.
Determine the attributes that need to be migrated and update the workflow defined in the InstallDir/sample/wfexternalmigration.xml file.
Import the updated workflow.
Create an external resource for the SAP Access Control 5.3 integration. Ensure that the External Resource user store is configured properly. Refer to Understanding and Managing External Resources in Oracle Waveset 8.1.1 Business Administrator’s Guide for more information.
The SAP Access Control adapter, which uses Metro for Web Service communication, can not be instantiated in some application servers together with the Access Enforcer resource adapter, which uses Apache Axis for Web Service Communication.
Run the Sample SAP Access Enforcer To Access Control Migration server task. The system should not be in use by anyone else during this process..
Remove Apache Axis from application server.
Download and install Glassfish Metro 1.5 from the following location: https://metro.dev.java.net/1.5/
Remove the Access Enforcer resource from Waveset.
Create the SAP Access Control resource.
Modify the external resource to use SAP Access Control web services.
The integration scenario in which SAP BusinessObjects Access Control is used as the leading provisioning system and Waveset is used for provisioning to non-ERP systems requires specific configuration on both SAP Access Control and Waveset. The SAP Access Control configuration steps are part of the SAP GRC Access Control 5.3 Configuration Guide, chapter “Sending Provisioning Request to an IdM System“.
Waveset provides an SPML schema that defines the object class and extended request information needed to configure SAP Access Control integration. The schema is defined in InstallDir/sample/spml.xml. You must edit this file before loading it into Waveset. Specifically, you must uncomment the IDMperson object. This object includes a change to the standard person object, as described in the comments contained in the file.
After this task has been performed, the file must be imported and the configuration finished following the steps in Oracle Waveset 8.1.1 Web Services.
SAP Access Control tries to use HTTP basic authentication when it creates a connection to the Waveset system. If the container in which the Waveset server runs does not support basic authentication, a connection will be established without authentication. The user name and password specified in SAP Access Control as part of the connector cannot be used to create an Waveset session. No request will be processed by Waveset without a valid session. This means that you must configure the proxy user and password for the SPML interface as described in Editing the Waveset.properties File in Oracle Waveset 8.1.1 Web Services. The proxy user will allow anyone access to the SPML interface and care should be taken to shield the URL from misuse.
The following table lists actions and their corresponding parameter names and values. These must be set in the SAP Access Control connector configuration.
Action |
Parameter Name |
Parameter Value |
---|---|---|
Create User |
SCHEMA_ID |
standard |
CREATE_USER:OC |
IDMperson |
|
CREATE_USER:options.AllowPasswordGeneration |
true |
|
CREATE_USER:options.onlyResourcesUserPasswordRequired |
true |
|
Change User |
CHANGE_USER:OC |
IDMperson |
Delete User |
DELETE_USER:OC |
IDMperson |
Assign Roles |
ASSIGN_ROLES:OC |
IDMperson |
ROLE |
roles |
|
Lock User |
LOCK_USER:EXT |
disableUser |
Unlock User |
UNLOCK_USER:EXT |
enableUser |
Audit Logs |
not configurable |
not applicable |
AUDIT_TYPE |
statusrequest |
|
Reset Password |
RESET_PASSWORD:EXT |
resetUserPassword |
Search Password |
SEARCH_PASSWORD:EXT |
launchProcess |
SEARCH_PASSWORD:process |
SPML Decrypt Password |
|
SEARCH_PASSWORD:taskName |
Decrypt Password |
|
Search |
SEARCH_CRITERIA |
identifier |
SAP Access Control currently does not support filtering the SPML attributes defined in the schema based on the object class. When you create the mapping for the SAP Access Control connector, all attributes are displayed, even the attributes that are not part of the object class used. During the fields mapping SAP Access Control sends a SchemaRequest to Waveset to allow you to map the attributes for the connector in SAP Access Control. By default, the Waveset schema contains multiple object classes, and you will see attributes that are not valid for the object class you have configured. There are two possible workarounds for this:
Reduce the SPML schema on the Waveset server temporarily to use just the object class and attributes needed. When the SAP Access Control server is configured you should reload the original schema again. Changes to the SPML schema require a restart of the server.
Use a printout of the schema and mark the available attributes for the object class used and do not rely on the attributes presented in the drop down of the SAP Access Control user interface.
The following table lists field mappings for the SAP Access Control connector. This is not a complete list of all the fields which could be mapped.
Access Control Field |
Application Field |
---|---|
Email Address - STANDARD |
|
User FName - STANDARD |
gn |
User ID - STANDARD |
accountId |
User LName - STANDARD |
sn |
These application fields are the SPML schema attribute names. These names do not have to correspond with internal Waveset attribute names. In the SPML configuration, these names can be mapped using a form to internal Waveset attribute names.
The SAP Access Control connector must not be configured to run over HTTPS.
An action on a user is a request SAP Access Control sends to Waveset using SPML. The SPML request is a batch request type. One request in SAP Access Control can consist of multiple steps, each an individual SPML request inside the batch, that Waveset must process. This behavior is not configurable on the SAP Access Control side, but it has implications for processing the request on both systems.
Waveset processes the individual requests inside the batch in the order that they are received. A status is returned for each of the requests processed: success, failure, or pending. A failure will show up as an error in SAP Access Control, marking the action appropriately. Any request that requires an approval or other manual action in Waveset creates a background process. The status that is returned for these requests will be pending. Any pending requests will be interpreted as a failed request by SAP Access Control. Processing of the request on the Waveset side is not impacted by this.
SAP Access Control does not maintain state of the individual requests sent inside the batch and marks the whole request as a failure if at least one request returns a status of failure. The approval or manual action on Waveset should complete as normal. If the changes were approved in Waveset, the request must then be resubmitted or reapproved in SAP Access Control. This action will generated a new batch request which will retry each individual request. In this case, the audit log entries in SAP Access Control could show inconsistent information about the user state on Waveset. The final state in SAP Access Control should be correct after the batch request is resubmitted.
When a user is created in Waveset using SPML from SAP Access Control, Waveset generates the password. SAP Access Control does not provide a password in the initial create request, but it tries to retrieve the password from Waveset in clear text after the user has been created. To satisfy SAP Access Control process requirements, the Create User workflow generates the password and informs the user by sending an email notification. The workflow sends a notification only if the user has no password and if the AllowPasswordGeneration parameter is set to true.
Waveset uses the Generated Password Notice email template to send out this notification.
SAP Access Control can request audit log entries from the Waveset system, but these entries are not automatically enabled. The default requests rely on audit entries that have the SPML request ID as part of the attributes. Normal audit log entries neither contain nor have access to the SPML request ID.
To enable this feature, add the following attribute to the Waveset.properties file:
soap.auditlog=true
With this setting, Waveset adds request IDs to all subsequent audit events. It does not change any of the currently logged entries. The number of logged audit events will not increase or decrease as a result of this change. However, the same audit entry can be logged twice: once with the request ID, and once without.
SPML requests that contain one request ID and multiple actions are called batch requests. SAP Access Control often uses them during updates of user objects. These batch requests cause multiple audit log entries to be generated with the same SPML request ID. The Waveset Administrator interface displays these log entries as separate entries. If the extended SPML request auditlog is used to retrieve the audit log entries, only one entry will be returned. This behavior might change in future releases.