enterpriseConnector is a highly flexible product that enables a wide range of enterprise solutions to be fully and securely integrated with mainframe systems and infrastructure
Enterprise solutions aim to provide the business with a single infrastructure across all operational platforms. They typically address areas such as access and identity management; password management; system monitoring; and analytics. However, to be truly enterprise wide, these solutions must also include any mainframe systems. In practice though, mainframe integration is often compromised by these enterprise solutions not having full knowledge of mainframe infrastructures, associated data formats and protocols. Each mainframe LPAR is seen as an isolated system, rather than part of a shared Sysplex environment.
There are also security concerns, as these enterprise solutions often require privileged access rights to various mainframe resources. This results in highly privileged mainframe account information being stored off of the mainframe, providing an attack vector for penetrating the mainframe.
Typically, enterprise wide functionality is either reduced for mainframe systems or alternative solutions end up being adopted to cater for the mainframe, driving up costs and somewhat negating the benefit being sought in investing in an enterprise wide solution.
RSM's enterpriseConnector addresses these concerns by providing a secure, auditable and flexible way for enterprise solutions to cleanly integrate with the mainframe infrastructure.
RSM Partners Solution
enterpriseConnector provides a secure protection layer between the enterprise solution and the mainframe, negating the need for the enterprise solution to understand the mainframe Sysplex architecture, command/data formats or to require privileged access rights.
A range of common communication interfaces are supported, such as RESTful APIs, https, SSH, together with data handling for JSON, XML and HTTP.
The key feature of enterpriseConnector is the ability to fully customise the solution to support internal data formats and company policies.
To request a download of this software or to raise a question, please complete the following details:
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."