IBM WebSphere V5.0 Security - CGISecurity

In another example, a servlet in the Web container on the application server
accesses an EJB in the EJB container on the application server. The same thing
happens as in the previous example; the application server has to authenticate
the servlet’s request on behalf of the EJB, then check the authorization.
When you design an enterprise application or security for an application, you will
have a similar, but more detailed diagram for your solution. Make sure that you
have taken every connection into consideration between each element and
module. Security in this context consists of two major parts: authentication and
authorization. Make sure that the access is always authenticated or the security
credentials are propagated; also make sure that the access is authorized and
prepare with an action if authorization is not granted.
For more information, read the security related sections of the Java 2 Platform
Specification V1.3 at:
http://java.sun.com/j2ee/docs.html
3.2 Security roles
The J2EE specification defines a security role as: “A logical groupings of users
that are defined by an Application Component Provider or Assembler”. Security
roles provide a mechanism whereby application developers determine the
security policies for an application by creating named sets of users (for example:
managers, customers, employees, and so on) that will have access to secure
resources and methods. At application assembly time, these sets of users, or
security roles, are not tied to any real users or groups of users. Instead, they are
placeholders which are later mapped to real users and groups at application
deployment time, during a process called security role mapping.
Chapter 3. J2EE application security 23