Software Solutions: enterpriseConnector

Tony Amies says, "We worked with a large bank that had multiple Sysplexes and LPARs and was using Oracle Identity Manager to create users, remove users, change passwords, and so on, in a Role Based Access Control (RBAC) type environment." In this organization, Oracle Identity Manager comes into enterpriseConnector over a REST API with transactions in JSON format.

"enterpriseConnector gateways are mirrored on multiple LPARs within the main Sysplex, exploiting DVIPA technology to allow multiple gateways to run as a hot standby. Transactions are mirrored within the enterpriseConnector gateways so requests can be routed to one gateway and, subsequently, if that gateway is not available due to an LPAR going into maintenance, another gateway picks up those transactions without any loss of data."

In this example, the REST API handling user requests from Oracle routes the requests to other Sysplexes depending on which environment a user provisioning request needs to be created on. The enterpriseConnector gateway forwards the request to the enterpriseConnector agent running in that remote environment, executes the request, then returns it to Oracle via the enterpriseConnector gateways. Tony says, "We can also build REST API requests out to other systems. And with this implementation, as part of the processing of Oracle data, we have to go back to CyberArk to get passwords encrypted and decrypted. So enterpriseConnector is also making REST API calls out to CyberArk before it handles the Oracle request."

In this example, a large retail client is using the Zendesk product to allow employees to self-reset their own passwords. Employees log on to Zendesk, authenticate themselves to Zendesk, then request a password reset on one or more systems within the mainframe estate. "Again, the Zendesk application is linked to enterpriseConnector and its bespoke logic in the primary Sysplex," says Tony. "The enterprise application works off employee IDs as opposed to RACF user IDs, so the enterpriseConnector must translate the employee ID coming from Zendesk into an RACF userid using CSDATA fields. Once it's determined the RACF ID, it issues the password change requests to RACF, and also forwards those change requests to other RACF databases running in other Sysplexes. Each Sysplex is updated with the RACF password and the answer is given back to Zendesk that the userâs password has been reset, and all databases and systems on which they've been permitted to reset their password.

"The key aspect is that Zendesk users only have to provide their employee ID and the systems they want their password reset on, and enterpriseConnector does the 'employee ID to user ID' translation. The solution is also fully audited, so the retailer can see who's been changing their passwords, on which systems and for whose employee IDs."

Tony's third use case also features Oracle-based identity management, in this case with a large enterpriseConnector implementation for a permanently available environment in a very large system, with 30-40 RACF databases. 10 or 12 transaction types from Oracle come into enterpriseConnector gateways. "Here, we use IBM's Sysplex Distributor technology, running the enterpriseConnector gateway on multiple LPARs within the primary Sysplex. The REST API requests from Oracle can be routed to any of the gateways, again with enterpriseConnector mirroring transactions between gateways to ensure status is maintained across all gateway instances. This allows the customer to move the gateways across LPARs and bring LPARs down or up without any loss of service or data."

Incoming requests to the enterpriseConnector gateway are fully validated and verified against RACF RBAC rules. As with other implementations, enterpriseConnector translates employee ID into RACF user ID, which can be different in each remote environment. "In many cases, the employee ID actually involves multiple RACF IDs and different environments," Tony adds. "This is all handled by RBAC rules and RACF database, so in this situation enterpriseConnector goes to RACF to work out which systems that employee ID is available on, and then it knows the systems in which to execute the request from Oracle. Once again, those requests are issued through enterpriseConnector agents running in each remote RACF environment, with communication via TCP/IP over REST API between gateways and agents, and TSO Rexx running in each environment to implement the business logic for the Oracle requests. This can be tailored for each specific environment, including custom data fields, and can be modified easily if rules or business policies change."