36 WebSphere Portal Collaboration Security Handbook
򐂰 validateEstablishedTrust
Having decided that this class is to process the request, this method
determines if the request is valid. Rather than having WebSphere perform its
own authentication, WebSphere relies on this method to verify that the
request it is processing comes from a trusted source, where authentication
was successful. This method can also use the HTTPServletRequest object.
How it does this depends on how authentication has been done by the remote
authenticating process. Typically, the remote authentication process will need
to add some HTTP header tag to the request after it completes
authentication. This method would then know to look for that HTTP header
tag and validate it.
򐂰 getAuthenticatedUserName
Having decided that the request is valid, the purpose of this method is to
return a user ID that will then be used by WebSphere. The user ID needs to
be a valid user ID in the security system.
2.4 Authorization topics
Authorization in WebSphere Application Server is based on the Java 2 Platform,
Enterprise Edition (J2EE) security infrastructure. We discuss authorization in the
WebSphere environment for the following topics:
򐂰 Java 2 Platform, Enterprise Edition security
򐂰 IBM Tivoli Access Manager for e-business
2.4.1 Java 2 Platform, Enterprise Edition security
The Java 2 Platform, Enterprise Edition (J2EE) specification defines the building
blocks and elements of a J2EE application that build an enterprise application.
The specification also provides details about security related to the different
elements.
The J2EE application consists of multiple modules and components; these
elements are in connection with each other, and they communicate through
certain protocols. This section only discusses the connection on the application
level, without going into details about the protocols.
For example, a user accesses a JSP on the application server. This JSP is a
secured resource. In this situation, the application server has to authenticate the
user and decide whether the user is authorized to access the page or not. In this
case, the connection between the users browser and the JSP page requires
security.
Chapter 2. Portal security concepts 37
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, and 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. In addition, ensure that the access is authorized and
prepare 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
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, and employees) 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
that are later mapped to real users and groups at application deployment time,
during a process called
security role mapping.
38 WebSphere Portal Collaboration Security Handbook
Figure 2-13 Security roles
This two-phase security administration approach allows for a great deal of
flexibility and portability. Deployers of an application have full control over how
their local users and groups are mapped to the application’s security roles, and
over what authorization and authentication mechanisms are used to determine
role membership.
At deployment time, security roles can be mapped to users, groups of users, or
special subjects. There are two special subjects in WebSphere Portal Version 5:
򐂰 All Authenticated Users
򐂰 Everyone
Web Component Resources
JSPs
Servlets
Static
Content
EJB Methods
Consultant
Manager
Accountant
Clerk
Security Roles
Principals and Groups
Fred
Mary
Department XYZ
Security Role
Mapping

Get WebSphere Portal Collaboration Security Handbook now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.