Authentication and Authorization

Authentication and authorization support can be provided by the following:
Consider using JEE security to protect your Rich UI application in the following cases:
Consider using custom security to protect your Rich UI application in the following cases:

Web container-managed (JEE) security

Web container-managed security transfers the responsibility of user authentication and authorization to the container, allowing the EGL developer to focus on business logic.

Two common types of JEE authentication are basic and form-based. In JEE basic authentication (also known as HTTP basic authentication), when a client, such as a browser, requests a Web page from a server without providing a user id and password, the server sends back a 401 response code. The client then prompts the user for a user id and password by displaying a default login dialog to the user. The client resends the request to the server, including the user id and password in the HTTP header. If the user is authenticated, the server returns the requested page. If the user id and password are invalid, the server returns a 401 response code and the client prompts the user again. In JEE form-based authentication, you can use a customized login screen with the look and feel of the application instead of the browser-provided login dialog. The user id and password are passed to the server in the form data instead of in the HTTP header of the request.

JEE security uses roles to manage access to resources. Certain roles are allowed access to certain resources. Users and groups are mapped to appropriate roles. For example, the user bob might be mapped to the role administrator.

JEE authorization can be declarative or programmatic. Declarative authorization is available because security information is specified in deployment descriptors. The application servers access these deployment descriptors to determine if a specific user is assigned to a role and decides whether a particular resource can be accessed by that role. While JEE security also includes programmatic authorization through the use of APIs, such as isUserInRole(), these functions are not available from within a Rich UI application. Therefore, Rich UI applications should perform authorization either declaratively or through custom, user-provided code.

User registries, such as Lightweight Directory Access Protocol (LDAP) directory servers or relational databases used with JEE security, are external to the JEE environment. A system administrator must perform administrative tasks, such as adding a new user to the repository.

While JEE security is available through Apache Tomcat, it is not available from the Workbench. You need to deploy a Rich UI application to your application server to apply and test security.

To determine if JEE security is appropriate for your situation, review the documentation in this chapter and the more detailed online documentation for your application server.

Application-managed (custom) security

If Web container-managed security is not suitable for your needs, you can build custom security into your Rich UI application. Although custom security requires that you add security-related code to your Rich UI application, you cannot avoid it if JEE security alone is not sufficient to express the security model of an application. If you prefer, you can combine both forms of security.

Custom authorization can provide a more granular level of authorization than JEE roles. You might want to use custom security to authenticate users before they can access restricted parts of your application.


Feedback