Authentication summary

During the design phase of your Rich UI application, determine the type of security that you need and integrate that security with the rest of your application. If your entire Rich UI application needs to be secured and you do not need to access security credentials from within the application, consider using JEE authentication. Otherwise, you might need to implement custom security.

To secure the EGL Rich UI Proxy, use JEE security. If you use JEE form-based authentication for your HTML file, include the URL pattern of the proxy in your security constraint. Otherwise, use JEE basic authentication to secure the proxy. If your application requires custom security or calls secure Web services, consider using EGL single sign-on to eliminate the need for a user to log in more than once.

You can secure Web services using by JEE basic authentication and set a user id and password in the HTTP header before invoking them by using the ServiceLib.setHTTPBasicAuthentication system function.

Use SSL, described in Overview of SSL, to secure data transmitted to and from your Rich UI application. Securing data is vital to keeping your passwords from being compromised.

The following table summarizes the combinations of resources that you can secure with JEE or custom authentication. For each of the eight scenarios (columns), an "X" represents a secure resource. These scenarios assume that the HTML file is calling Web services. Otherwise, remove access to the EGL Rich UI Proxy by deleting its URL mapping from the deployment descriptor. The safer scenarios are identified with an "*".
Table 1. Authentication scenario
  1 2 3* 4 5* 6* 7 8*
HTML file   x     x   x x
EGL Rich UI Proxy     x   x x   x
Web service       x   x x x

Scenario descriptions

  1. In this scenario, the proxy is publicly accessible. If possible, do not implement this scenario. Secure the proxy with JEE basic authentication (scenario 3).
  2. Although the HTML file is secured with either JEE or custom security, the proxy is still publicly accessible. If possible, do not implement this scenario. Secure the proxy with JEE authentication (scenario 5).
  3. In this scenario, the proxy is secured with JEE basic authentication. This scenario is safer than the first two.
  4. In this scenario, the proxy is publicly accessible. If possible, do not implement this scenario. Secure the proxy with JEE authentication (scenario 6).
  5. If Web service does not require security, this scenario can be safe. If both the HTML file and proxy are secured with JEE security, use form-based authentication to require the user to log in only once. If the HTML file is secured with custom security and the credentials to log in to the HTML file match those used to log in to the proxy, use EGL single sign-on to combine application authentication with JEE authentication to the proxy.
  6. Although the Rich UI application does not require authentication, a user-defined login screen is required to obtain Web service credentials, which should never be hardcoded into the application. If the credentials that are used to log in to the Web service match those that are used to log in to the proxy, use EGL single sign-on to combine Web service authentication with JEE basic authentication to the proxy.
  7. In this scenario, the proxy is publicly accessible. If possible, do not implement this scenario. Secure the proxy with JEE authentication (scenario 8).
  8. If both the HTML file and proxy are secured with JEE security, use form-based authentication. A user-defined login screen is required in the application to authenticate to the secure Web services. Thus, the user must log in twice. If the credentials to authenticate to the HTML file, the proxy, and Web services match, consider securing the HTML file with custom authentication. Then use EGL single sign-on to capture credentials for all three types of resources.

Feedback