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
- In this scenario, the proxy is publicly accessible. If possible,
do not implement this scenario. Secure the proxy with JEE basic authentication
(scenario 3).
- 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).
- In this scenario, the proxy is secured with JEE basic
authentication.
This scenario is safer than the first two.
- In this scenario,
the proxy is publicly accessible. If possible,
do not implement this scenario. Secure the proxy with JEE authentication
(scenario 6).
- 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.
- 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.
- In
this scenario, the proxy is publicly accessible. If possible,
do not implement this scenario. Secure the proxy with JEE authentication
(scenario 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.