WebSphere Portal Collaboration Security Handbook

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 user’s 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