1 About the Connector

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 ACF2 either as a managed (target) resource or as an authoritative (trusted) source of identity data for Oracle Identity Manager.

The advanced connector for CA ACF2 provides a native interface between Oracle Identity Manager and CA ACF2 installed on an IBM z/OS mainframe. The connector functions as a trusted virtual administrator on the target system, performing tasks related to creating and managing user profiles.

In the account management (target resource) mode of the connector, information about users 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 you configure CA ACF2 as a target resource, then user profiles on CA ACF2 correspond to accounts or resources assigned to OIM Users. In contrast, if you configure CA ACF2 as a trusted source, then user profiles on CA ACF2 correspond to OIM Users.

This chapter is divided into the following sections:

• Section 1.1, "Certified Components"

• Section 1.2, "Certified Languages"

• Section 1.3, "Connector Architecture"

• Section 1.4, "Features of the Connector"

• Section 1.5, "Connector Objects Used During Reconciliation and Provisioning"

1.1 Certified Components

Table 1-1 lists the certified components.

Table 1-1 Certified Components

Item	Requirement
Oracle Identity Manager	Oracle Identity Manager Release 9.1.0.1 or later Note: In this guide, Oracle Identity Manager Release 9.1.0.x has been used to denote Oracle Identity Manager Release 9.1.0.1 and future releases in the 9.1.0.x series that the connector will support. Oracle Identity Manager 11g Release 1 (11.1.1) or later Note: In this guide, Oracle Identity Manager Release 11.1.1 has been used to denote Oracle Identity Manager 11g Release 1 (11.1.1).
Target system	CA ACF2 r6.2, r8.0 SP4 or later, r9.0 SP1 or later, r12, r14, r15
JDK	The JDK version can be one of the following: For Oracle Identity Manager Release 9.1.0.x, use JDK 1.5 or later. For Oracle Identity Manager Release 11.1.1, use JDK 1.6 update 18 or later.
Infrastructure Requirements: Message transport layer between the Oracle Identity Manager and the mainframe environment	TCP/IP with Advanced Encryption Standard (AES) encryption

1.2 Certified Languages

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 Fusion Middleware Developer's Guide for Oracle Identity Manager. On Oracle Identity Manager Release 11.1.1, see Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

1.3 Connector Architecture

The connector architecture is described in the following sections:

• Section 1.3.1, "Connector Components"

• Section 1.3.2, "Connector Operations"

1.3.1 Connector Components

The CA ACF2 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 converted into native commands for CA ACF2, encrypted using AES-128 encryption, and then sent to the Provisioning Agent. The response, which is also native to CA ACF2, 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 Provisioning Agent, running as an IBM z/OS STC (Started Task), is a mainframe component. It receives native mainframe CA ACF2 provisioning commands from the LDAP Gateway. These requests are decrypted, converted from ASCII to EBCDIC, passed to CA ACF2 through the standard RACF Sub System Interface API, and then posted to the CA ACF2 database. 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 ACF2 are processed. These events include the ones generated at the 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 is supported by the connector.

1.3.2 Connector Operations

This section provides an overview of the following processes:

• Section 1.3.2.1, "Full Reconciliation Process"

• Section 1.3.2.2, "Incremental (Real-Time) Reconciliation Process"

• Section 1.3.2.3, "Provisioning Process"

1.3.2.1 Full Reconciliation Process

Full reconciliation involves fetching all existing user profile data from the mainframe to Oracle Identity Manager. 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.

The following is a summary of the full reconciliation process:

Note:

Detailed instructions are provided later in this guide.

1. You specify the full reconciliation configuration in the ACF2 Reconcile All Users scheduled task.

2. In the scheduled task form UsersList property, you enter a list of user IDs of the user profiles that you want to reconcile. If no users are specified, then all existing users on the target system will be reconciled.

3. You specify whether you want to configure ACF2 as a target resource or trusted source of Oracle Identity Manager.

4. You set a start time for the task and run the scheduled task. The task sends the list of user IDs to the LDAP Gateway.

5. The LDAP Gateway encrypts the list of user IDs and then sends it to the Provisioning Agent on the mainframe.

6. You run the scheduled task. The task sends a search request to the LDAP Gateway.

7. The LDAP Gateway encrypts the search request and then sends it to the Provisioning Agent on the mainframe.

8. The Provisioning Agent encrypts the user profile data received from ACF2 and then passes this data to the LDAP Gateway.

9. The LDAP Gateway decrypts the user profile data and passes it to Oracle Identity Manager.

10. 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.

1.3.2.2 Incremental (Real-Time) Reconciliation Process

Incremental or real-time reconciliation is initiated by one of the exits that work in conjunction with the Reconciliation Agent. Figure 1-1 shows the flow of data during this form of reconciliation.

Figure 1-1 Incremental Reconciliation Process

Description of ''Figure 1-1 Incremental Reconciliation Process''

The following is a summary of the incremental or real-time reconciliation process:

1. Incremental reconciliation begins when a user is created, updated, or deleted on CA ACF2. This event might take place either directly on the mainframe or in response to a provisioning operation on Oracle Identity Manager.

2. The Reconciliation Agent gathers data captured by one of three CA ACF2 exits: LIDPOST, NEWPXIT, or EXPPXIT. 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.

3. The Reconciliation Agent polls Subpool 231. When it finds a message in the subpool, it reads the message into its buffer. This frees up the subpool entry.

4. 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.

5. The LDAP Gateway decrypts the message, if it is a Create User or Change User event, or if the STC ID matches the Pioneer STC it will ignore events and not send them to Oracle Identity Manager.

   If the event does not meet conditions, then the LDAP Gateway determines that the source of the event is not Oracle Identity Manager. The gateway 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.

6. Oracle Identity Manager processes the message and creates or updates either the corresponding CA ACF2 resource or the OIM User.

1.3.2.3 Provisioning Process

Figure 1-2 shows the flow of data during provisioning.

Figure 1-2 Provisioning Process

Description of ''Figure 1-2 Provisioning Process''

The following is a summary of the provisioning process:

1. Provisioning data is sent from Oracle Identity Manager to the LDAP Gateway.

2. The LDAP Gateway converts the provisioning data into mainframe commands, encrypts the commands, and then sends them to the mainframe over TCP/IP.

3. The Provisioning Agent installed on the mainframe decrypts the commands and then runs them on the mainframe.

4. The Provisioning Agent sends the output of the commands back to the LDAP Gateway.

5. 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.

1.4 Features of the Connector

The following are features of the connector:

• Section 1.4.1, "Target Resource and Trusted Source Reconciliation"

• Section 1.4.2, "Full and Incremental Reconciliation"

• Section 1.4.3, "Encrypted Communication Between the Target System and Oracle Identity Manager"

• Section 1.4.4, "High Availability Feature of the Connector"

1.4.1 Target Resource and Trusted Source Reconciliation

You can use the connector to configure CA ACF2 as either a target resource or trusted source of Oracle Identity Manager.

1.4.2 Full and Incremental Reconciliation

After you deploy the connector, you 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.

1.4.3 Encrypted Communication Between the Target System and Oracle Identity Manager

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.

1.4.4 High Availability Feature of the Connector

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

  1. The Reconciliation Agent stops sending messages (event data) to the LDAP Gateway.

  2. Messages that are not sent are stored in the subpool cache.

     Note:

     The subpool cache cannot grow beyond the allocated limit. If the LDAP Gateway does not start responding before the allocated limit is reached, then new messages that come in are lost.

  3. 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

  1. Event data is sent to the subpool cache.

  2. 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

  1. Messages that are in the subpool cache are written to disk.

  2. When the mainframe is brought back online, event data written to disk is again stored in the subpool cache.

  3. 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, messages in the AES-encrypted file are not affected and can be recovered.

1.5 Connector Objects Used During Reconciliation and Provisioning

The following sections provide information about connector objects used during reconciliation and provisioning:

• Section 1.5.1, "Supported Functions for Reconciliation"

• Section 1.5.2, "Supported Functions for Provisioning"

• Section 1.5.3, "User Attributes for Target Resource Reconciliation and Provisioning"

• Section 1.5.4, "User Attributes for Trusted Source Reconciliation"

• Section 1.5.5, "Reconciliation Rule"

• Section 1.5.6, "Reconciliation Action Rules"

1.5.1 Supported Functions for Reconciliation

The connector supports reconciliation of user profile data from the following events:

• Create user

• Modify user

• Change password

• Reset password

• Reset password no expire

• Disable user

• Delete user

• Enable user

1.5.2 Supported Functions for Provisioning

Table 1-2 lists the provisioning functions supported by the connector.

Table 1-2 Supported Functions for Provisioning

Function	Description	Mainframe Command
Create user	Adds new login ID record on CA ACF2	INSERT
Modify user	Modifies login ID record information on CA ACF2	CHANGE
Change password	Changes user password on CA ACF2 in response to password changes made on Oracle Identity Manager through user self-service.	CHANGE
Reset password	Resets user password on CA ACF2 The passwords are reset by the administrator.	CHANGE
Disable user	Disables user on CA ACF2	CHANGE
Enable user	Enables user on CA ACF2	CHANGE
Delete user	Removes user from CA ACF2	DELETE
Grant user access to rule	Creates a CA ACF2 resource or access rule for the CA ACF2 user	SET RULE
Grant user access to privileges (TSO)	Provides user access to CA ACF2 security fields (including custom fields)	CHANGE
Grant user access to privileges (CICS)	Provides user access to CA ACF2 CICS login ID record fields	CHANGE

1.5.3 User Attributes for Target Resource Reconciliation and Provisioning

Table 1-3 lists attribute mappings between CA ACF2 and Oracle Identity Manager for target resource reconciliation and provisioning. The OnBoardAcf2User and ModifyAcf2User adapters are used for the Create User and Modify User provisioning operations, respectively.

Table 1-3 User Attributes for Target Resource Reconciliation and Provisioning

Process Form Field	CA ACF2 Attribute	Description
accessCnt	ACC-CNT	Count of number of times the user accessed the system
accessDate	ACC-DATE	Date when the user last accessed the system
activeDate	ACTIVE	Privilege to allow or deny access based on a date
accessSrce	ACC-SRCE	System component accessed by the user
accessTime	ACC-TIME	Time when the user last accessed the system
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 Section 3.9, "Installing and Configuring the LDAP Gateway" describes the procedure.
sn	NAME	Last name of the user
expire	EXPIRE	Privilege to allow or deny access based on a date
givenName	NAME	First name of the user
defaultGroup	GROUP	Default group for the user
cicsid	CICSID	Indicates the CICS operator ID (3 characters)
cicsPri	CICSPRI	Indicates the CICS operator priority (1-byte binary)
cicsIdle	IDLE	Maximum number of minutes permitted between terminal transactions for this user (1-byte binary)
cicsCl	CICSCL	Indicates the CICS operator class (3 hexadecimal bytes)
cicsRsl	CICSRLS	Indicates the CICS resource access key (3 hexadecimal bytes)
cicsOpt	CICSOPT	Specifies the SYSID of the C-CIC records to use at initialization time (8-characters)
cicsAcf2Cics	ACF2CICS	ACF2CICS or NOACF2CICS Indicates that CA ACF2 CICS security is to be initialized in any CTS 1.2 or later region running with this address space logonid (bit field)
kerbVio	KERB-VIO	Number of Kerberos key violations
kerbCurv	KERBCURV	Kerberos key version
minDays	MINDAYS	Minimum number of days that must elapse before a user can change the password 0 indicates no limit.
maxDays	MAXDAYS	Maximum number of days (based on the date specified in the PSWD-TOD field) that the user is permitted to change password before the password expires 0 indicates no limit.
passwordExpire	PSWD-EXP|NOPSWD-EXP	Indicates that a user's password has been manually expired This field lets a security administrator force this user to change the password.
privileges	SECURITY fields	Privileges assigned to the user Note: This is a multivalued attribute. All standard SECURITY fields are mapped by default. You can also map custom fields.
prefix	PREFIX	0- to 8-character key of the rule used to validate access to a data set.
pswdDate	PSWD-DAT	Date of last invalid password attempt The date is displayed in the mm/dd/yy, dd/mm/yy, or yy/mm/dd formats depending on the DATE field of the GSO OPTS record. Year designations of 70-99 assume a date in the 20th century (1970-1999). Year designations of 00-69 assume a date in the 21st century (2000-2069). Note: See the target system documentation for detailed information about GSO.
pswdInv	PWSD-INV	Number of password violations that occurred since the last successful logon This field can be reset to 0 by a security administrator.
pswdTod	PWSD-TOD	Date and time when a user changed the password The date is displayed in the mm/dd/yy, dd/mm/yy, or yy/mm/dd formats depending on the DATE field of the GSO OPTS record. You cannot set this field. CA ACF2 maintains and displays it. Year designations of 70-99 assume a date in the twentieth century (1970-1999). Year designations of 00-69 assume a date in the 21st century (2000-2069).
pswdVio	PWSD-VIO	Number of password violations that occurred on PSWD-DAT
revoke	NA	Value is Y if user is revoked or N if user is resumed
secVio	SEC-VIO	Indicates the number of cumulative security violations for a user
tsoDest	DFT-DEST	Default SYSOUT destination
tsoDftPfx	DFT-PFX	0- to 8-character default TSO prefix that is set in the user's profile at logon time
tsoUnit	TSOUNIT	Default UNIT name for allocations.
tsoRba	TSORBA	Mail Index Record Pointer (MIRP) for the user
tsoAcctnum	TSOACCT	Default TSO account number on the TSO/E logon panel
tsoHoldclass	DFT-SUBH	Default hold class
tsoSubmitclass	DFT-SUBC	Default submit class
tsoMaxSize	TSOSIZE	Maximum region size the user can request at logon
tsoMsgclass	DFT-SUBM	Default message class
tsoProc	TSOPROC	Default login procedure on the TSO/E logon panel
tsoSize	TSORGN	Minimum region size if not requested at logon
tsoSysoutclass	DFT-SOUT	Default SYSOUT class
tsoPerf	TSOPERF	User's default TSO performance group
tsoMail	MAIL	Indicates that a user can receive mail messages from TSO at logon time
tsoAcctPriv	ACCTPRIV	Indicates that the user has TSO accounting privileges
tsoAllCmds	ALLCMDS	Indicates the ability to bypass the CA ACF2 restricted command lists by entering a special prefix character
tsoJcl	JCL	Indicates the ability to submit batch jobs from TSO and to use SUBMIT, STATUS, CANCEL, and OUTPUT commands
tsoWtp	WTP	Indicates that CA ACF2 displays write-to-programmer messages
tsoFscrn	TSOFSCRN	Indicates that a user can use the full-screen logon display
tsoMount	MOUNT	Indicates permission to issue mounts for devices
tsoOperator	OPERATOR	Indicates that a user has TSO operator privileges
tsoNotices	NOTICES	Indicates that a user can receive TSO notices at logon time
tsoPrompt	PROMPT	Indicates that CA ACF2 prompts a user if parameters are missing or incorrect
tsoLgnAcct	LGN-ACCT	Indicates the permission to specify an account number at logon time
tsoLgnMsg	LGN-MSG	Indicates that the user has permission to specify a message class at logon time
tsoLgnPerf	LGN-PERF	Indicates the permission to specify a performance group at logon time
tsoLgnProc	LGN-PROC	Indicates the permission to specify a TSO procedure name at logon time
tsoLgnTime	LGN-TIME	Indicates the permission to specify a TSO session time limit at logon time
tsoLgnRcvr	LGN-RCVR	Indicates the permission to use the recover option of the TSO or TSO/E command package
tsoLgnSize	LGN-SIZE	Indicates that the user is authorized to specify a region size at logon time by overriding TSOSIZE
tsoLgnUnit	LGN-UNIT	Indicates the permission to specify a TSO unit name at logon time
tsoIntercom	INTERCOM	Indicates that the user is willing to accept messages from other users through the TSO SEND command
uid	USER	Login ID of the user
updTod	UPD-TOD	Indicates the date and time when a login ID record was last updated
userPassword	PASSWORD	Password

1.5.3.1 Resource Rule Attributes for Target Resource Reconciliation and Provisioning

Table 1-4 lists resource rule attribute mappings between CA ACF2 and Oracle Identity Manager. The AssignUserToResourceRule and RemoveUserFromResourceRule adapters are used for resource rule provisioning operations.

Table 1-4 Resource Rule Attribute Mappings

Child Form Field	CA ACF2 Attribute	Description
RULE KEY	KEY	The high-level index of the data set name for which this rule is being written
TYPE	TYPE	The type of resource rule
ACCESS	ACESS	System mode CA ACF2 should take when it validates access for this rule

1.5.3.2 Access Rule Attributes for Target Resource Reconciliation and Provisioning

Table 1-5 lists access rule attribute mappings between CA ACF2 and Oracle Identity Manager. The AssignUserToAccessRule and RemoveUserFromAccessRule adapters are used for access rule provisioning operations.

Table 1-5 Access Rule Attribute Mappings

Child Form Field	CA ACF2 Attribute	Description
DATASET ID	dsnmask	The name of the data set or a mask
RULE KEY	$KEY	The high-level index of the data set name for which this rule is being written, or the VSM key of the rule set.
ACCESS READ	Read	Specifies read access and the action CA ACF2 should take when the environment matches
ACCESS WRITE	Write	Specifies write access and the action CA ACF2 should take when the environment matches
ACCESS EXECUTE	Execute	Specifies execute access and the action CA ACF2 should take when the environment matches
ACCESS ALLOCATE	Allocate	Specifies allocate access and the action CA ACF2 should take when the environment matches

1.5.4 User Attributes for Trusted Source Reconciliation

Table 1-6 lists attribute mappings between CA ACF2 and Oracle Identity Manager for trusted source reconciliation.

Table 1-6 User Attributes for Trusted Source Reconciliation

OIM User Field	CA ACF2 Attribute	Description
uid	USER	Login ID of the user
cn	NAME	Full name of the user
sn	NAME	Last name of the user
givenName	NAME	First name of the user
userPassword	PASSWORD	Password

1.5.5 Reconciliation Rule

See Also:

Oracle Fusion Middleware User's Guide for Oracle Identity Manager for generic information about reconciliation matching and action rules

During target resource reconciliation, Oracle Identity Manager tries to match each user profile fetched from CA ACF2 with existing CA ACF2 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 profile 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 profile against existing OIM Users. This is known as entity matching. The same reconciliation rule is applied during this process. If an entity match is found, then a CA ACF2 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 ACF2.

After you deploy the connector, you can view this reconciliation rule by performing the following steps:

1. On the Design Console, expand Development Tools and then double-click Reconciliation Rules.

2. Search for and open the IdfReconUserRule rule.

1.5.6 Reconciliation Action Rules

Reconciliation action rules specify actions that must be taken depending on whether or not matching CA ACF2 resources or OIM Users are found on Oracle Identity Manager when the reconciliation rule is applied. Table 1-7 lists the reconciliation action rules.

Table 1-7 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 Fusion Middleware User's Guide for Oracle Identity Manager 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:

1. On the Design Console, expand Resource Management and then double-click Resource Objects.

2. Search for and open the OIMAcf2ResourceObject resource object.

3. 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.