Oracle® Identity Manager Connector Guide for CA-Top Secret Advanced Release 9.0.3 Part Number B32350-01 |
|
|
View PDF |
After you deploy the connector, you must test it to ensure that it functions as expected. This chapter contains information on the following types of testing:
Connectivity testing: All message transport layers have a dependency on open ports, allowing application data to be to be passed between applications and between systems. This test checks for open ports on the mainframe system from the Oracle Identity Manager system. Both IBM MQ Series and TCP/IP systems depend on open ports to communicate.
Provisioning Testing: This type of test involves using Oracle Identity Manager for provisioning or de-provisioning one of its users or organizations with a target resource. In other words, Oracle Identity Manager is the starting point of the connector, and the target resource is the end point.
Reconciliation Testing: In this type of test, you reconcile Oracle Identity Manager with the target resource. In other words, the target resource is the starting point of the connector, and Oracle Identity Manager is the end point.
This chapter contains the following sections:
This section discusses open port testing for the connector. Testing of open ports is done on the Oracle Identity Manager server system.
The following tests assume that the test will be conducted on the Oracle Identity Manager server, with required ports open to the mainframe.
For IBM MQ Series messaging, the standard port is 1414. Connectivity to this port is tested from the Oracle Identity Manager server.
The TCP/IP message transport layer relies on several different ports. The ports should be checked from the Oracle Identity Manager server to the mainframe. For provisioning to CA-Top Secret, check for open ports between the two systems for port 5791. The reconciliation agent uses port 5190.
Note:
Check your specific setup configuration files for the actual provisioning and reconciliation agent port numbers used in your deployment.
It is common for the mainframe TCP/IP configuration and the CA-Top Secret Advanced Connector Adapter JCLs to have the same code set, even if multiple LPARs and connectors are used. As the port traffic passes through a router, the public IP address then becomes different from the private locally assigned system IP address. This conversion of the private and public IP address can also extend to remapping to the ports.
This section focuses on the functional and performance test cases that are associated with this connector. The following table includes information on running test cases on the CA-Top Secret Advanced connector:
Test Case | Test Type | Description/Comment |
---|---|---|
Test to change CA-Top Secret Advanced Password | Provisioning | A user password is changed, with the change posted to the mainframe through the connector. |
Test to reset CA-Top Secret Advanced Password | Provisioning | A user password is reset, with the change posted to the mainframe through the connector. |
Test to create CA-Top Secret Advanced User | Provisioning | A user is created, with the change posted to the mainframe through the connector. |
Test to revoke/disable CA-Top Secret Advanced User Account | Provisioning | A user account is revoked, with the change posted to the mainframe through the connector. |
Test to resume CA-Top Secret Advanced User Account | Provisioning | A user account is resumed from a revoked status, with the change posted to the mainframe through the connector. |
Test to List CA-Top Secret Advanced Users | Provisioning | A list of users is retrieved from the mainframe repository. |
Test to Permit CA-Top Secret Advanced User Access to Resource Profile | Provisioning | A user is authorized to access mainframe resources, with change posted to the mainframe through the connector. |
Test to permit CA-Top Secret Advanced User Access to TSO | Provisioning | A user is provisioned to log on to the mainframe through TSO, with the change posted to the mainframe through the connector. |
Test to remove CA-Top Secret Advanced User Access to Dataset | Provisioning | A user is removed from access to a mainframe dataset, with the change posted to the mainframe through the connector. |
Test to remove CA-Top Secret Advanced User Access to Resource Profile | Provisioning | A user is removed from access to a mainframe resource, with the change posted to the mainframe through the connector. |
Test to detect and report Native CA-Top Secret Advanced Password Change Event | Reconciliation | A native password change is made on the mainframe and subsequently detected by the connector. |
Test to detect and report Native CA-Top Secret Advanced Password Reset Event | Reconciliation | A native password reset is made on the mainframe and subsequently detected by the connector. |
Test to detect and report Native CA-Top Secret Advanced Create User Data Event | Reconciliation | User creation is done by an administrator natively on the mainframe and subsequently detected by the connector. |
Test to detect and report Native CA-Top Secret Advanced Revoke User Event | Reconciliation | A user account password is revoked through native mainframe events, which is subsequently detected by the connector. |
Test to detect and report Native CA-Top Secret Advanced Delete User Event | Reconciliation | A user account is deleted through native mainframe events, which is subsequently detected by the connector. |
Test to detect and report Native CA-Top Secret Advanced Resume User Event | Reconciliation | A user account is resumed from a revoke status through native mainframe events, which is subsequently detected by the connector. |
The following table lists solutions to some commonly encountered issues associated with the CA-Top Secret Advanced Connector.
Problem Description | Solution |
---|---|
Oracle Identity Manager cannot establish a connection to the CA-Top Secret Advanced Server. |
|
The mainframe does not appear to respond. |
|
A particular use case does not appear to be functioning. |
|
The CA-Top Secret Advanced connector architecture has been engineered for enterprise-level performance. When an identity event passes through an exit, the Reconciliation Agent analyzes the event, and then creates a message, allowing the command to complete its routine without loss of time.
A given event will typically fire multiple exits at the same time. For example, a batch job that generates a password change identity event will fire both a batch exit and a password change exit. The Reconciliation Agent captures both events, filters duplicate entries, and passes the result to the Oracle Identity Manager LDAP Gateway.
A batch job to change 50,000 passwords has been tested on a single LPAR to complete within 10 minutes. Because two exits were involved, 100,000 messages were created, filtered, and transformed into MQ messages. The LDAP Gateway then took 30 minutes to retrieve and update the Oracle Identity Manager identity store, with most of that time consumed by the LDAP database.
The LDAP Gateway is engineered to detect when a given event originates from Oracle Identity Manager, when it passes through the Reconciliation Agent. Provisioning Agent events also create a native exit event that is detected. To prevent a feedback loop, events that originate from the LDAP Gateway are logged, but are not reported again to Oracle Identity Manager. By contrast, events that originate outside Oracle Identity Manager are treated as native events, and recorded for future auditing.
The LDAP Gateway and Reconciliation securely capture, filter, and log the identity events from the host system, publishing them for use by Oracle Identity Manager.