AuraPlayer ServiceManager Deployment and Security Options Follow
AuraPlayer is a tool to automate and mobilize Oracle technologies towards digital transformation. AuraPlayer supports many technologies and supplies many modules to adjust your exact needs. This document describes AuraPlayer's deployment options. All deployment options are suitable to all modules and technologies.
AuraPlayer contains the following modules:
- Robotic Process Automation (RPA)
- Mobile applications
- APIs to your Oracle technologies. Can be integrated to any API consumer, including chatbot, APEX, web, etc.
- Testing as part of your QA/DevOps cycles
- Monitoring your system 24*7
AuraPlayer supports the following technologies:
- Oracle EBS
- Oracle Forms
- HTML Web Pages
AuraPlayer Server - ServiceManager
AuraPlayer’s patented technology acts as a proxy between the modern world and the Oracle applications. The AuraPlayer ServiceManager is a java server that is installed in your internal or external network and is used to communicate between any end user application and the back-office Oracle application. Meaning, your users reach the AuraPlayer ServiceManager through their client app and only AuraPlayer has access to your Oracle Applications. The same is done for RPA, for Tester, for Monitoring, or for any API call that will be integrated to any other software.
The AuraPlayer ServiceManager can be installed in variety of architectures depending on your security and platform needs. It can can also be installed with or without Load Balancer.
Architecture - Deployment Options
Intranet: The new mobile/web application will be used internally only
This is the most simple deployment. As your application is used internally, it is not exposed to the internet. Therefore, the AuraPlayer ServiceManager is deployed in your LAN, and you do not need any further configurations to secure it further. Any security configuration you have for your LAN, will be inherited by AuraPlayer as well.
AuraPlayer supports the following deployment options:
- One Machine Deployment - AuraPlayer ServiceManager is installed on the same server as your Oracle middleware. Either in the WebLogic server (Forms 11 and up, EBS 12.2.X and up) or on a Tomcat server (For Forms 10g, EBS 12.1.X), depending on your Oracle Forms / EBS version.
- Dedicated Machine Deployment - This machine will be accessed by your users and it will in turn access the Oracle servers in the back end. This dedicated machine will only need either Tomcat or WebLogic installed to run AuraPlayer.
Internet: The newly developed application is to be used externally
AuraPlayer supports the following deployment options to support external web and mobile systems:
- Standard DMZ secured deployment - This option is being used by most of the deployments these days. The AuraPlayer ServiceManager is installed in your DMZ network and accessible to the external internet while your Oracle applications and DB are behind the firewall and are opened only to the DMZ.
In this option, your servers are available to the DMZ server via only one port through the firewall. However, the application and the DB are accessible by the DMZ machine.
- DMZ extended Mirroring Secured deployment - Using this option, only the services that are being used by your external application are made accessible to the internet - not the entire Oracle application and DB.
This deployment option is based on utilizing 2 AuraPlayer ServiceManager machines:
1. ServiceManager in the DMZ - similar to the previous standard DMZ option
2. Internal ServiceManager in your LAN behind the firewall
In this option, only the services in the internal AuraPlayer ServiceManager are available to the DMZ. The Oracle application and the DB are not accessible by the DMZ.
There are a few options to deal with authentication when using AuraPlayer:
Inherit the authentication mechanism that is used by your Oracle application
AuraPlayer will use the authentication mechanism you are already using, whether it is done in Oracle Forms, Oracle EBS, or directly via the DB. It would basically mimics the Login screen that your users currently use on EBS/Forms.
- The credentials would remain the same, there’s no need to change/set any new authentication mechanisms.
- The implication would be, that any login request would directly access your Oracle layer.
Using AuraPlayer Tomcat or WebLogic authentication mechanisms
Setting AuraPlayer to use the middleware server’s authentication mechanisms, for example, Basic Authentication, SAML, NTLM, Kerberos, etc. You can initiate it for user login purposes and for all services authentication. There are several advantages to use Tomcat or WebLogic for authentication:
- When your application is not being authenticated by Oracle, you can easily gain authentication via Tomcat or WebLogic.
- The authentication is moved from the Oracle layer to the AuraPlayer layer shielding your back office for authentication purposes, thus creating more security.
Using internal Identity Management system (IDM)
Many organizations are using a SSO architecture with products such as OAM, Microsoft Access Manager, LDAP, etc. We can employ this authentication mechanism through AuraPlayer as well. When working with your internal IDM, you can gain:
- SSO for all applications including access to your Oracle Application via AuraPlayer.
- There are situations where there is only one user in the DB, whereas many users would like to get specific information according to their customer/user ID responsibilities. In order to do this, first you would need to work with the IDM to identify the specific end user, then once authenticated, the login to the DB will be done via sole DB login, but the query will be done with the ID of the authenticated user.
Using cloud Identity Management system (IDM)
Many cloud providers like Amazon, Azure, Google, Okta, and Oracle provide external IDM as a service. You can still apply these IDM systems with AuraPlayer.
There are several advantages using cloud IDM:
- Similar to the previous solution, when your application is not being authenticated using Oracle you can gain authentication easily via the IDM Services.
- DDoS attacks, as part of the login, does not reach your network at all - the login is done via an external system, even before reaching your AuraPlayer and Oracle servers.
- Single Sign-On (SSO) - You may use the external IDM for several applications, and not only for your Oracle applications.
- A standard and modern IDM includes advanced features such as Two Factor Authentication (2FA).
Please note that with this option, if you are not using cloud IDM yet, it requires the procurement of cloud services, and some additional configurations.
Note, if you’re using both IDM, and Oracle’s credentials, you can end up with 2 authentication mechanisms - One in the Oracle on-premise world, and the second in the AuraPlayer layer or in the IDM Layer. In order to avoid it, there are technical ways to map the two logins, so that it will be done only once.
Services authentication and security
Firstly, we recommend to use HTTPS to call the AuraPlayer services to secure all traffic.
When calling the AuraPlayer services, you usually need to pass the login credentials in addition to the standard in/out parameters of the services. In order to secure the services, AuraPlayer supports the following security options:
Basic Authentication is managed by Tomcat or WebLogic servers which are employed by AuraPlayer ServiceManager. Users are configured on the middleware server itself.
Passing specific encrypted fields to the Service as basic authentication. Consider it when you want some fields to be encrypted when calling the service such as password or ID credentials.
LDAP is used when you use Single Sign-On (SSO) internally in your organization, and the services are being called from within your LAN. Read more here.
OAuth2 gives you the ability to authenticate via the IDM and call the services with a token. You would want to use it if you have a corporate IDM system. You will need to authenticate the login with the IDM, and then each service would identify the user via the token. OAuth2 requires additional configurations of the IDM, and AuraPlayer system. Read more here.
This is a secure way to use your services with the AuraPlayer ServiceManager. A Ticket is an AuraPlayer object that secures your login and all services calls. When using a ticket, you first, create a ticket that encrypts your credentials and/or your login response and IDs. Later on, when calling a service, the ticket is sent instead of the login credentials and the service decrypts the ticket, and validates it. Read more here.
When using ticket service, there are several significant advantages:
1. Your credentials and your IDs are encrypted.
2. You can add any other value to your ticket and encrypt it as well. This way you can move any encrypted data easily between the client and the server.
1. The ticket is validated on any service request. Therefore, any malicious activity will be denied.
2. The validation is done in AuraPlayer ServiceManager by blocking the request at the early stages before reaching the Oracle back-end servers.
- Expiration Timer
1. You can define your own expiration timer to a ticket. It means that once the timer goes off , you would need to login again. This way you can invalidate sessions based on time, and sessions are never left opened.
To summarize, AuraPlayer gives you the flexibility to use any architecture that suits your needs. You can use any combination of the described capabilities. As a rule of thumb, when your system is used internally in your LAN, you might continue using your current authentication mechanisms. When exposing the activity and business processes of your Oracle application to the internet, you might want to move to OAuth2 or Ticket authentication which are more secured.
AuraPlayer consultants would be happy to help you architect a security and deployment environment to meet your own business needs to achieve a successful move to the mobile world. Feel free to contact us at firstname.lastname@example.org for further information.