Controlling Access to Cantara and related Services
Cantara as an integration platform provides the ability to quickly define and publish REST services for a number of back-office systems. The primary focus of the product is to provide an integration connector for the Oracle JD Edwards EnterpriseOne ERP. These systems generally contain sensitive information and access to this information, as well as the ability to create or process it, should be tightly controlled. This paper discusses the components used within Cantara to secure the solution as well as deployment options for enabling secure access.
This content is general information only. Any organization that is looking to deploy Cantara should conduct their own security assessment taking into account things such as:
- existing network configuration
- operating environment
- specific security risks and potential attack vectors for their organization
Access to Oracle JD Edwards EnterpriseOne
Cantara utilizes two methods for accessing and processing information within a JD Edwards system. The first, and primary method, is via the XML Dispatch kernel that runs on the Logic/Batch Enterprise Servers within the JD Edwards environment. The second is via the Application Interface Services (AIS) server which is only available on later JD Edwards tools releases.
XML Dispatch Kernel
The XML Dispatch Kernel will run on the enterprise server along will all other JD Edwards Enterprise Kernels. Therefore, access to this kernel is through the JDENet Communication Middleware. Please refer to the Oracle documentation for your release on the setup required for this communication protocol, including the configuration of an encrypted messages. For reference, the 9.2 tools documentation is found at JD Edwards EnterpriseOne Tools Security Administration Guide.
To deploy an on-premises instance of Cantara, you can choose to use either an Agent or Access component for communications. Communication between the Agent or Access server and the JD Edwards Enterprise server will include a significant amount of chatter which means that network latency should be kept to an absolute minimum. If there is network separation between the Cantara component and the JD Edwards enterprise server then the Cantara component will need to be able to access the JDENet port on the enterprise server to establish a new connection. This port is defined within the JDE.INI configuration file on the enterprise server. It will be the same port that is utilized by other JD Edwards components such as the HTML servers and deployment server.
AIS Server
The AIS server makes use of a REST API and is therefore standard HTTP/1.1 protocol communications. Access to this server from either the Cantara Agent (on-premises) or Cantara Access server (on-premises) can either be direct to the AIS server url/port or alternatively can be through either load balancers or a reverse proxy. SSL communications is fully supported as part of this deployment if communications between the Cantara component and the AIS server need to be encrypted.
JD Edwards User Access Controls
Access into the JD Edwards system, through either the enterprise server kernels or AIS server, is controlled by the JD Edwards Security Server. Cantara currently provides two options with regards to user access into JD Edwards. You can use direct access which means that the credentials supplied to Cantara via a REST client will be passed through to the JD Edwards system. As Cantara is utilizing the JD Edwards Security Server, it will support both the internal JD Edwards user directory or an LDAP directory if this has been configured within the JD Edwards system.
The second option is to select Cantara as the user directory and authentication provider. This enable users to be created and maintained within the Cantara Administration Console through Cantara Proxy Users. For each user or user group, you can define the JD Edwards User Credentials that will be used to access the JD Edwards system. You can also override user metadata that may impact client application functionality, such as their JD Edwards address book number of default approval route. In the event that the JD Edwards account that is being utilized is disabled then all users that are using that proxy account will be unable to access the JD Edwards system. The roadmap for the Cantara Integration Platform is to provide additional security providers, such as LDAP and Microsoft Active Directory, in future releases.
The recommended method is to utilize the JD Edwards system for user authentication and authorization. The primary reason for this is that all transaction audit stamps within JD Edwards will identify the user that actually performed the transaction. The option of using Cantara Users is best suited to situations where users do not have general corporate network access or access to JD Edwards is temporary.
Media Object File Storage
In many instances, media object referenced with the JD Edwards system are provisioned via network storage. Depending on the deployed tools release of the JD Edwards EnterpriseOne system that has been deployed, there will be different methods utilized. For older tools releases the only options made available were either SMB (Microsoft Windows Shares) or FTP. With later tools releases the option to utilize SFTP and subsequently the AIS server were introduced. Cantara supports all of these methods. Access to the files will be completed using a service account which is defined either with the Cantara environment definition (see Defining an Environment) or, in the case of SMB access, as the user that is running the Cantara service.
Cantara Cloud Network Architecture
Please refer to Cantara Network Architecture Options for further details and options on Cantara network configuration. In the case of a Cantara Cloud deployment it is critical that communications between the Cantara Cloud instances and the Cantara Agent are secure. Communications should be encrypted using SSL certificates signed by a trusted certificate authority. Cantara Cloud does not currently support customers using self-signed certificates. As all Cantara components communicate through REST API's all communications will be standard HTTP/1.1 traffic. It is not a requirement to utilize well-known ports for these services so you can choose to deploy on any available port.
Customers can choose to place the Cantara Agent either within their DMZ or within the corporate network. The benefit of deploying the Agent within the corporate network means that access to services such as print or file storage are automatically available. This downside to this approach is that if the Cantara Agent host is compromised then it will have unfettered access to all corporate network assets. Placing the Agent within the DMZ will provide additional controls to ensure that a compromised host cannot access all corporate network hosts. It should be noted however that in this instance it is still important to ensure that latency between the Agent and the JD Edwards enterprise server is kept as low as possible. You must also add access from the DMZ to other services, such as network printing or media object file storage, if those services are required.
You may wish to limit network access to your Cantara Agent from only Cantara Cloud IP addresses. The following is the list of source IP addresses to allow:
|
Cantara On-Premises Network Architecture
Please refer to Cantara On-Premises Network Architecture Options for further details and options on Cantara network configuration. Depending on the particular use case for Cantara in your organization, in the case of an on-premises deployment you may not need to provide any external network access. In the event that this is a requirement, external access should only be granted to the Cantara Access component as this will handle communications with the clients. As all communications within the Cantara platform is via REST API's all traffic will be HTTP/1.1 protocol. Well known ports are not mandatory and in the case of purely internal network traffic, the use of SSL is optional although recommended. Mobile or web applications built on utilizing the Cantara client SDKs can make use of client certificate authentication and can also support self-signed SSL/TLS certificates.
Cantara Client Verification
In addition to standard user authentication through username and password, Cantara also requires that all communications from clients to the Access server or between the Access server and Agent include the API Key. This key is available through the Cantara Portal for your account and license. If this key is not included in the communications then all REST service calls will be rejected.