Cantara Network Architecture FAQ
Refer to Cantara Recommended Network Architectures. Please discuss any alternatives with your Rinami consultant.
No, a Cantara Agent may be deployed to isolate the Cantara Access Server from the corporate network.
Load balancers can be replaced with simple reverse proxies to provide the necessary SSL end point. This does mean that only a single Cantara Agent can be deployed per endpoint, so HA functionality is reduced.
For high availability deployments, Cantara Agent must be accessed through load balancers rather than a simple reverse proxy. The load balancers must be configured for sticky web sessions using cookies to minimize traffic and authentication overhead.
Yes. The latency between the Cantara Agent and the JDE Enterprise servers should be minimized for optimal performance of the solution.
Yes, however, access to the JDE Enterprise servers, printers and media object storage will need to be configured.
Cantara Agent can be deployed either as a standalone daemon service, or as a WAR deployed on a Java Application Server that supports Servlet specification 3.0 or higher.
Cantara Access is a java web application installed in on-premises deployments only. Multiple Access instances may be deployed to provide high availability. Instances require a common database to be deployed for storage of service definitions, client authentication tokens and scheduled jobs.
Cantara Admin Console is a java web application installed in on-premises deployments only. It requires direct communication with the Cantara Access application instances. Multiple Admin Console instances may be deployed to provide high availability.
Cantara supports a range of standard authentication options from external authentication providers. Deployments can also accommodate the custom arrangements of an existing security solution.
Currently supported standard methods include:
- Cantara
- JDE
- OAuth2 (including Azure AD and Firebase)
- LDAP
- SAML
- Everest SSO
- Steltix TLX10
- Trust