| Oracle® Identity Manager Connector Guide for CA Top Secret Advanced Release 9.0.4 Part Number E10424-13 |
|
|
PDF · Mobi · ePub |
Oracle Identity Manager automates access rights management, security, and provisioning of IT resources. Oracle Identity Manager connectors are used to integrate Oracle Identity Manager with external, identity-aware applications. This guide discusses the connector that enables you to use CA Top Secret either as a managed (target) resource or as an authoritative (trusted) source of identity data for Oracle Identity Manager.
The advanced connector for CA Top Secret provides a native interface between CA Top Secret installed on an IBM z/OS mainframe and Oracle Identity Manager. The connector functions as a trusted virtual administrator on the target system, performing tasks related to creating and managing users.
In the account management (target resource) mode of the connector, information about users (ACIDs) created or modified directly on the target system can be reconciled into Oracle Identity Manager. In addition, you can use Oracle Identity Manager to perform provisioning operations on the target system.
In the identity reconciliation (trusted source) configuration of the connector, users are created or modified only on the target system and information about these users is reconciled into Oracle Identity Manager.
If CA Top Secret is configured as a target resource, then users on CA Top Secret correspond to accounts or resources assigned to OIM Users. In contrast, if CA Top Secret is configured as a trusted source, then users on CA Top Secret correspond to OIM Users.
This chapter contains the following topics:
Table 1 lists the certified components.
| Item | Requirement |
|---|---|
|
|
|
JDK |
The JDK version can be one of the following:
|
|
CA Top Secret r8, r9, r12, or r14 |
|
|
Infrastructure Requirements: Message transport layer between the Oracle Identity Manager and the mainframe environment |
TCP/IP with Advanced Encryption Standard (AES) encryption |
|
Target system user account for reconciliation and provisioning operations |
IBM Authorized Program Facility (APF) authorized account with SystemAdministrators privileges See Creating a CA Top Secret Account for Connector Operations for more information about this account. |
The connector supports the following languages:
Arabic
Chinese (Simplified)
Chinese (Traditional)
Danish
English
French
German
Italian
Japanese
Korean
Portuguese (Brazilian)
Spanish
See Also:
On Oracle Identity Manager release 9.1.0.x, see Oracle Identity Manager Globalization Guide.On Oracle Identity Manager release 11.1.1, see Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.This section contains the following topics:
The CA Top Secret Advanced connector contains the following components:
LDAP Gateway: The LDAP Gateway receives instructions from Oracle Identity Manager in the same way as any LDAP version 3 identity store. These LDAP commands are then converted into native commands for CA Top Secret and sent to the Provisioning Agent. The response, which is also native to CA Top Secret, is parsed into an LDAP-format response and returned to Oracle Identity Manager.
During reconciliation, the LDAP Gateway receives event notification, converts the events to LDAP format, and then forwards them to Oracle Identity Manager.
Provisioning Agent (Pioneer): The Pioneer Provisioning Agent is a mainframe component. It receives native mainframe CA Top Secret provisioning commands from the LDAP Gateway. These requests are processed against the CA Top Secret authentication repository. The response is parsed and returned to the LDAP Gateway.
Note:
At some places in this guide, the Provisioning Agent is referred to as Pioneer.Reconciliation Agent (Voyager): The Reconciliation Agent captures mainframe events by using exits, which are programs run after events in CA Top Secret are processed. These events include the ones generated at TSO logins, the command prompt, batch jobs, and other native events. The Reconciliation Agent captures these events, transforms them into notification messages, and then sends them to Oracle Identity Manager through the LDAP Gateway.
Note:
At some places in this guide, the Reconciliation Agent is referred to as Voyager.Message Transport Layer: The message transport layer enables the exchange of messages between the LDAP Gateway and the Reconciliation Agent and Provisioning Agent. You can use the TCP/IP messaging protocol for the message transport layer.
TCP/IP with Advanced Encryption Standard (AES) encryption using 128-bit cryptographic keys. The connector supports a message transport layer by using the TCP/IP protocol, which is functionally similar to proprietary message transport layer protocols.
This section provides an overview of the following processes:
Full reconciliation involves fetching existing user data from the mainframe to Oracle Identity Manager. If you configure the target system as a target resource, then this user data is converted into accounts or resources for OIM Users. If you configure the target system as a trusted source, then the user data is used to create OIM Users.
The following is a summary of the full reconciliation process:
Note:
The detailed procedure is explained later in this guide.You set values for the properties defined in the TSS Reconcile All Users scheduled task. You also specify whether you want to configure CA Top Secret as a target resource or trusted source of Oracle Identity Manager.
You run the scheduled task. The task sends a search request to the LDAP Gateway.
The LDAP Gateway encrypts the search request and then sends it to the Provisioning Agent on the mainframe.
The Provisioning Agent encrypts user profile data received from CA Top Secret and then passes this data to the LDAP Gateway.
The LDAP Gateway decrypts the user profile data and passes it to Oracle Identity Manager.
The next step depends on the setting in the scheduled task:
If you configure the target system as a target resource, then this user profile data is converted into accounts or resources for OIM Users.
If you configure the target system as a trusted source, then the user profile data is used to create OIM Users.
Incremental or real-time reconciliation is initiated by the exit that works in conjunction with the Reconciliation Agent. Figure 1 shows the flow of data during this form of reconciliation.
The following is a summary of the reconciliation process:
Incremental reconciliation begins when a user is created, updated, or deleted on CA Top Secret. This event might take place either directly on the mainframe or in response to a provisioning operation on Oracle Identity Manager.
TSSINSTX is a standard CA Top Secret exit. This exit is used in conjunction with the Reconciliation Agent. The exit detects the event and sends a message containing user data to Subpool 231 (cache). This message contains the minimum number of data items, such as the user ID and password, required to reconcile the event.
The Reconciliation Agent polls Subpool 231. When it finds the message in the subpool, it reads the message into its buffer. This frees up the subpool.
The Reconciliation Agent opens up a connection with the LDAP Gateway, and then sends the message to the gateway over TCP/IP.
Note:
Messages sent to the LDAP Gateway are encrypted using AES-128 encryption.The LDAP Gateway decrypts the message. If it is a Create User or Change User Status event, then the LDAP Gateway checks the source of the event by comparing the user ID against the user IDs stored in the internal meta-store:
For a Create User event, if the user ID exists in the internal meta-store, then the message is not forwarded to Oracle Identity Manager.
For a Change User Status event, if the user status from the event is the same as the user status in the internal meta-store, then the message is not forwarded to Oracle Identity Manager.
If the event does not meet either of these two conditions, then the LDAP Gateway determines that the source of the event is not Oracle Identity Manager. It then sends the message to Oracle Identity Manager.
Note:
As mentioned in Step 2, the message sent by the Reconciliation Agent contains only a minimum amount of data. The LDAP Gateway sends a request to the Provisioning Agent to fetch the remaining user data from the target system.Oracle Identity Manager processes the message and creates or updates either the corresponding CA Top Secret resource or the OIM User.
Figure 2 shows the flow of data during provisioning.
The following is a summary of the provisioning process:
Provisioning data submitted from the Administrative and User Console is sent to the LDAP Gateway.
The LDAP Gateway converts the provisioning data into mainframe commands, encrypts the commands, and then sends them to the mainframe computer over TCP/IP.
The Provisioning Agent installed on the mainframe computer decrypts the commands and then runs them on the mainframe.
The Provisioning Agent sends the output of the commands back to the LDAP Gateway.
The outcome of the operation on the mainframe is displayed on the Oracle Identity Manager console. A more detailed message is recorded in the connector log file.
The following are features of the connector:
You can use the connector to configure CA Top Secret as either a target resource or trusted source of Oracle Identity Manager.
After you deploy the connector, you can perform full reconciliation to bring all existing user data from the target system to Oracle Identity Manager. After the first full reconciliation run, change-based or incremental reconciliation is automatically enabled and active. Incremental reconciliation is a real-time process. User changes on the target system are directly sent to Oracle Identity Manager.
You can perform a full reconciliation run at any time.
AES-128 encryption is used to encrypt data that is exchanged between the LDAP Gateway and the Reconciliation Agent and Provisioning Agent on the mainframe.
The following are component-failure scenarios and the response of the connector to each scenario:
Scenario 1: The Reconciliation Agent is running and the LDAP Gateway stops responding
The Reconciliation Agent stops sending messages (event data) to the LDAP Gateway.
Messages that are not sent are stored in the subpool cache.
When the LDAP Gateway is brought back online, the Reconciliation Agent reads data from the subpool cache and then sends messages to the LDAP Gateway.
Scenario 2: The LDAP Gateway is running and the Reconciliation Agent stops responding
Event data is sent to the subpool cache.
When the Reconciliation Agent is brought back online, it reads data from the subpool cache and then sends messages to the LDAP Gateway.
Scenario 3: The LDAP Gateway is running and the mainframe stops responding
Messages that are in the subpool cache are written to disk.
When the mainframe is brought back online, event data written to disk is again stored in the subpool cache.
The Reconciliation Agent reads data from the subpool cache and then sends messages to the LDAP Gateway.
Scenario 4: The LDAP Gateway is running and the Provisioning Agent or mainframe stops responding
The process task that sends provisioning data to the LDAP Gateway retries the task.
Scenario 5: The subpool is stopped by an administrator
If the subpool is stopped by an administrator, then it shuts down the Reconciliation Agent, thereby destroying any messages that are not transmitted. However, the messages in the AES-encrypted file are not affected and can be recovered.
The following sections provide information about connector objects used during reconciliation and provisioning:
Supported Functions for Target Resource and Trusted Source Reconciliation
User Attributes for Target Resource Reconciliation and Provisioning
PROFILE Attributes for Target Resource Reconciliation and Provisioning
SOURCE Attributes for Target Resource Reconciliation and Provisioning
FACILITY Attributes for Target Resource Reconciliation and Provisioning
DATASET Attributes for Target Resource Reconciliation and Provisioning
The connector supports reconciliation of user data from the following events:
Create user
Modify user
Change password
Reset password
Suspend user
Suspend user until
Delete user
Unsuspend user
Unsuspend user until
Table 2 lists the provisioning functions supported by the connector.
Table 2 Supported Functions for Provisioning
| Function | Description | Mainframe Command |
|---|---|---|
|
Create user |
Adds new users on CA Top Secret |
TSS CREATE |
|
Modify user |
Modifies user information on CA Top Secret |
TSS REPLACE |
|
Change password |
Changes user passwords on CA Top Secret in response to password changes made on Oracle Identity Manager through user self-service |
TSS REPLACE |
|
Reset password |
Resets user passwords on CA Top Secret The passwords are reset by the administrator. |
TSS REPLACE |
|
Suspend user |
Disables users on CA Top Secret |
TSS ADDTO |
|
Suspend user until |
Disables users up to the specified date on CA Top Secret |
TSS ADDTO |
|
Unsuspend user |
Enables users on CA Top Secret |
TSS REMOVE |
|
Delete users |
Removes users from CA Top Secret |
TSS DELETE |
|
Grant user access to data sets |
Adds users to data set and assigns the specified access rights |
TSS PERMIT |
|
Grant user access to privileges (TSO) |
Provides TSO login access to users |
TSS REPLACE |
|
Removes user access to data sets |
Removes users from data sets |
TSS REVOKE |
|
Grant user access to facilities |
Adds users to facilities and assigns the specified access rights |
TSS ADDTO |
|
Removes user access to facilities |
Removes users from facilities |
TSS REMOVE |
|
Grant user access to groups |
Adds users to groups |
TSS ADDTO |
|
Remove user access to groups |
Removes users from groups |
TSS REMOVE |
|
Grant user access to sources |
Adds users to sources |
TSS ADDTO |
|
Remove user access to sources |
Removes users from sources |
TSS REMOVE |
Table 3 lists attribute mappings between CA Top Secret and Oracle Identity Manager. The OnBoardUser and ModifyTopsUser adapters are used for Create User and Modify User provisioning operations, respectively.
Table 3 User Attributes for Target Resource Reconciliation and Provisioning
| Process Form Field | CA Top Secret Attribute | Description |
|---|---|---|
|
uid |
USER |
Login ID of the user |
|
cn |
NAME |
Full name of the user You can specify the format in which Full Name values are stored on the target system. Step 3 of Installing and Configuring the LDAP Gateway describes the procedure. |
|
userPassword |
PASSWORD |
Password |
|
attributes |
SPECIAL, AUDITOR, GPRACC, OPERATIONS |
Attributes of the user |
|
deptacid |
DEPARTMENT |
Default department of the user |
|
instdata |
DATA |
Installation-defined data of the user |
|
createdate |
CREATED |
Date user was created |
|
passwordExpireDate |
EXPIRES |
Date the user's password expires |
|
passwordExpireInterval |
INTERVAL |
Number of days the user's password remains valid |
|
suspendUntilDate |
SUSPENDED DATE |
Future date on which the user will be prevented from accessing the system |
|
memberOf |
PROFILE |
Profile information for the user |
|
facilities |
FACILITY |
Facility information for the user |
|
divacid |
DIVISION |
Default division for the user |
|
lastmoddate |
LAST MOD |
Last time the user connected |
|
tsocommand |
COMMAND |
Command to be run during TSO/E logon |
|
tsodest |
DEST |
Default SYSOUT destination |
|
tsounit |
UNIT |
Default unit name for allocations |
|
tsoudata |
USERDATA |
Site-defined data field for a TSO user |
|
tsolacct |
ACCTNUM |
Default TSO account number on the TSO/E logon panel |
|
tsohclass |
HOLDCLASS |
Default hold class |
|
tsojclass |
JOBCLASS |
Default job class |
|
tsomaxsize |
MAXSIZE |
Maximum region size the user can request at logon |
|
tsomclass |
MSGCLASS |
Default message class |
|
tsolproc |
PROC |
Default logon procedure on the TSO/E logon panel |
|
tsolsize |
SIZE |
Minimum region size if not requested at logon |
|
tsolopt |
OPT |
TSO options, such as MAIL and NOTICES |
|
tsosclass |
SYSOUTCLASS |
Default SYSOUT class |
|
revoke |
NA |
Value 'Y' if user is revoked or 'N' if user is not revoked |
The connector supports reconciliation and provisioning of the PROFILE multivalued attribute. Table 4 lists PROFILE attribute mappings between CA Top Secret and Oracle Identity Manager. For any particular user, a child form is used to hold values of the PROFILE attributes listed in the table. The AddUserToGroup and RemoveUserFromGroup adapters are used for PROFILE provisioning operations.
The connector supports reconciliation and provisioning of the SOURCE multivalued attribute. Table 5 lists SOURCE attribute mappings between CA Top Secret and Oracle Identity Manager. For any particular user, a child form is used to hold values of the SOURCE attributes listed in the table. The AddUserToSource and RemoveUserFromSource adapters are used for SOURCE provisioning operations.
The connector supports reconciliation and provisioning of the FACILITY multivalued attribute. Table 6 lists FACILITY attribute mappings between CA Top Secret and Oracle Identity Manager. For any particular user, a child form is used to hold values of the FACILITY attributes listed in the table. The AddUserToFacility and RemoveUserFromFacility adapters are used for FACILITY provisioning operations.
The connector supports provisioning of the DATASET multivalued attribute. Table 7 lists DATASET attribute mappings between CA Top Secret and Oracle Identity Manager. For any particular user, a child form is used to hold values of the DATASET attributes listed in the table. The AddUserToDataset and RemoveUserFromDataset adapters are used for DATASET provisioning operations.
Table 8 lists attribute mappings between CA Top Secret and Oracle Identity Manager for trusted source reconciliation.
See Also:
Oracle Identity Manager Connector Concepts for generic information about reconciliation matching and action rulesDuring target resource reconciliation, Oracle Identity Manager tries to match each user fetched from CA Top Secret with existing CA Top Secret resources provisioned to OIM Users. This is known as process matching. A reconciliation rule is applied for process matching. If a process match is found, then changes made to the user on the target system are copied to the resource on Oracle Identity Manager. If no match is found, then Oracle Identity Manager tries to match the user against existing OIM Users. This is known as entity matching. The reconciliation rule is applied during this process. If an entity match is found, then a CA Top Secret resource is provisioned to the OIM User. Data for the newly provisioned resource is copied from the user.
During trusted reconciliation, the same reconciliation rule is applied for entity matching. If an entity match is found, then an OIM User is created out of the data in the reconciliation event.
The following is the reconciliation rule for both target resource and trusted source reconciliation:
Rule name: IdfReconUserRule
Rule element: User Login Equals uid
In this rule element:
User Login is the User ID field on the process form and the OIM User form.
uid is the USER attribute on CA Top Secret.
After you deploy the connector, you can view this reconciliation rule by performing the following steps:
On the Design Console, expand Development Tools and then double-click Reconciliation Rules.
Search for and open the IdfReconUserRule rule. Figure 3 shows this rule.
Reconciliation action rules specify actions that must be taken depending on whether or not matching CA Top Secret resources or OIM Users are found when the reconciliation rule is applied. Table 9 lists the reconciliation action rules.
Table 9 Reconciliation Action Rules
| Rule Condition | Action |
|---|---|
|
No Matches Found |
Assign to Administrator With Least Load |
|
One Entity Match Found |
Establish Link |
|
One Process Match Found |
Establish Link |
Note:
No action is performed for rule conditions that are not predefined for this connector. You can define your own action rule for such rule conditions. See Oracle Identity Manager Design Console Guide for information about modifying or creating reconciliation action rules.After you deploy the connector, you can view the reconciliation action rules for target resource reconciliation by performing the following steps:
On the Design Console, expand Resource Management and then double-click Resource Objects.
Search for and open the OIMTopSecretResourceObject resource object.
Click the Object Reconciliation tab, and then click the Reconciliation Action Rules tab. The Reconciliation Action Rules tab displays the action rules defined for this connector. Figure 4 shows the reconciliation action rule for target resource reconciliation.