Redpaper
Alex Louwe Kooijmans
Dinkar Tiwari
Security with IBM Tivoli Access
Manager V6 and IBM WebSphere
Application Server V6 on IBM z/OS
Introduction
This Redpaper describes how to integrate Tivoli® Access Manager for
e-business Version 6 (TAMeb) and WebSphere® Application Server Version 6
on z/OS®. It primarily focuses on the following areas:
򐂰 Junctions to back-end servers
– Creating and administering junctions
– Public and private content
򐂰 Single Sign On (SSO) options
– Global Sign On (GSO)
– Lightweight Third Party Authentication (LTPA)
– Trust Association Interceptor (TAI)
򐂰 Integration architecture
The paper presents integration scenarios and shows how to configure them,
discussing the pros and cons for each case. In addition, it covers associated
J2EE security functions that can be used to complement a true end-to-end
security solution with Tivoli Access Manager and WebSphere Application Server.
© Copyright IBM Corp. 2006. All rights reserved.
ibm.com/redbooks
1
Junctions to back-end servers
The following sections discuss how to create junctions in Tivoli Access Manager
(TAM)/WebSEAL.
Overview
Junctions are HTTP(s) connections, over TCP/IP, between a front-end
WebSEAL server and a back-end Web server. The back-end server’s Web
resources are connected to the WebSEAL server at a specially designated
junction (mount) point in the WebSEAL Web space. Users are able to access the
back-end server resource through WebSEAL. Figure 1 illustrates the use of
junctions in the architecture.
Figure 1 WebSEAL junctions
In a typical scenario, WebSEAL fronts numerous back-end Web application
servers; WebSEAL receives requests meant for the back-end servers and, via
junctions, dispatches the request to the appropriate back-end server.
In an ideal architecture, WebSEAL serves as the single point of entry into the
enterprise systems, thereby creating a front line of defense and shielding the
back-end systems by limiting their exposure to the external systems.
Additionally, all access to the systems can be centrally controlled.
2
Security with TAM V6 and WebSphere Application Server V6 on z/OS
Creating junctions
You can create WebSEAL junctions with the pdadmin command line interface
(CLI) or with the Web Portal Manager. The general format of the pdadmin
command to create remote junctions is as follows:
server task instance_name-webseald-host_name create –t type –h
host_name [options] junction_point
This creates a junction between the WebSEAL and WebSphere Application
Server system, allowing users to access WebSphere Application Server Web
resources through WebSEAL. Client browsers send requests to WebSEAL in the
following pre-determined format:
http(s)://<webseal>/<junction>/<path>/resource
Upon receiving the request WebSEAL isolates the junction name, and sends the
request to the corresponding back-end server as a usual request:
http(s)://<back-end server>/<path>/resource
At this point, the back-end server processes the request in its normal manner,
and the result is sent back to the user through WebSEAL.
Many options are available for creating and configuring the junction as dictated
by requirements; this is presented in a later section. For more detailed
information about the options, refer to IBM Tivoli Access Manager for e-business
WebSEAL Administration Guide.
In our environment, we used the following pdadmin command to create the
junction to our back-end zWAS server on host wtsc61.itso.ibm.com and
port 19080:
pdadmin> server task default-webseald-m10df4ff.itso.ral.ibm.com
create -t tcp -h wtsc61.itso.ibm.com -p 19080 /wtsc61
This created a junction at /wtsc61, and allowed us to access the WebSphere
Application Server system through WebSEAL. Figure 2 on page 4 illustrates our
scenario.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
3
Figure 2 WebSEAL dispatching requests
Public and private content
A junction allows WebSEAL to provide protective services on behalf of the
back-end server. WebSEAL can perform authentication and authorization checks
on all requests for resources before passing those requests across a junction to
the back-end server. While we can easily apply a security policy to only the
junction object, this results in a coarse-grained security solution - access is either
permitted or denied to all the resources on that junction.
Clearly, this may not be practical since back-end servers may have static content
that may have different security requirements. WebSEAL provides a
“query_contents” script that can be used to map a third party Web server’s static
content into WebSEAL’s object space. After this is done, individual security
policies can be implemented for the individual resources. The query_contents
script works only for static content, and is unable to map dynamic content such
as servlets, JSPs and so on.
Securing dynamic URLs
It is possible that a dynamic back-end application may have both public and
private content. Users should be able to access the public resources without
logging on, but any private content should require authentication. With dynamic
applications, it is not always possible to map the content into WebSEAL’s object
space.
WebSEAL provides a way to protect dynamic Web application resources based
on their URL pattern. Via the dynamic URL configuration, URL patterns are
4
Security with TAM V6 and WebSphere Application Server V6 on z/OS
mapped to objects within the WebSEAL object space. Attaching a security policy
to these objects protects the URLs as per the security policy.
In our environment, we set up our application in the following format:
򐂰 Public content
This was accessible by all users, without any need for authentication. Users
could view all the public resources without any prompts to authenticate. All
public content was set up to match the http://<host name>/public/*
pattern.
򐂰 Private content
This was accessible only by authenticated users. If users were not already
logged in, they were prompted to authenticate when a private resource was
requested. All private content was set up to match the http://<host
name>/secure/* pattern.
Figure 3 illustrates the flow in our environment when a user requests public
content.
Browser
1
WebSEAL
3
2
WebSphere
Application
Server
Figure 3 Accessing public content with dynamic URLs in WebSEAL
The activities taking place in Figure 3 are described here:
1. A user requests a public resource.
2. WebSEAL determines the resource to be public content.
3. WebSEAL forwards the request to the back-end server.
Figure 4 on page 6 illustrates the flow in our environment when a user requests
public content.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
5
1
Browser
2
3
4
WebSEAL
6
WebSphere
Application
Server
5
Figure 4 Accessing private content with dynamic URLs in WebSEAL
The activities taking place in Figure 4 are described here:
1. A user requests a secure resource.
2. WebSEAL determines the resource to be private content.
3. WebSEAL challenges the user for authentication.
4. User supplies the user ID/password.
5. WebSEAL authenticates the user.
6. WebSEAL forwards the request to the back-end server.
Securing the dynamic URLs is done via a multi-step process that requires us to
do the following:
򐂰 Set up the mapping of the dynamic URLs to protected objects.
򐂰 Update WebSEAL to pick up the changes in the dynamic URL configuration.
򐂰 Attach an appropriate ACL to the protected objects.
These steps are discussed in more detail in the following sections.
Setting up dynamic URLs in WebSEAL
Each request to WebSEAL is resolved to a specific object as the first step in the
authorization process. The ACL or POP applied to the object dictates the
required protection on any dynamic URL mapped to that object.
Because dynamic URLs exist only temporarily, it is not possible to have entries
for them in a pre-configured authorization policy database. TAMeb solves this
problem by providing a mechanism where dynamic URL patterns can be mapped
to a protected object. A many-to-one relationship is possible where many
dynamic URL patterns are mapped to a single protected object.
Mappings from objects to patterns are kept in a plain text configuration file. The
location of this file (relative to the server-root) is defined by the dynurl-map
6
Security with TAM V6 and WebSphere Application Server V6 on z/OS
stanza entry in the [server] stanza in the WebSEAL configuration file. Example 1
illustrates the appropriate lines from the WebSEAL configuration file.
Example 1 Location of dynamic URL configuration file
[server]
dynurl-map = lib/dynurl.conf
By default, this file does not exist, and must be created. The existence of this file
(with entries) enables the dynamic URL capability. Edit this file to modify these
mappings.
Entries in the file are of the format:
object template
The object is the protected object in the TAMeb object space, while the template
is a pattern that needs to map to the protected object. Any dynamic URL that
matches the template is mapped to the corresponding protected object. An
appropriate ACL can be attached to the protected object, thereby protecting the
relevant dynamic URLs.
TAMeb uses a subset of UNIX™ shell pattern matching (including wildcards) to
define the set of parameters that constitute the template. For a list of supported
wildcard pattern matching characters, see “Supported wildcard pattern matching
characters” in IBM Tivoli Access Manager for e-business WebSEAL
Administration Guide.
You can use the TAMeb Web Portal Manager to edit this file remotely. In Web
Portal Manager, go to the WebSEAL menu and select the link Dynamic URL
Files. The Dynamic URL page allows you to select a WebSEAL server and then
view, edit, and save the dynurl.conf configuration file located on that server.
Updating WebSEAL for dynamic URLs
Use the dynurl update command to update the WebSEAL protected object
space with entries made in the dynurl.conf configuration file, as described here:
1. Create, edit, or delete a dynamic URL entry in the dynurl.conf configuration
file.
2. After making your changes, use the dynurl update command to update the
server:
server task instance_name-webseald-host_name dynurl update
WebSEAL updates its protected object space with the latest information in the
dynurl.conf file. As a result of this command, there may be newer entries in
Security with TAM V6 and WebSphere Application Server V6 on z/OS
7
WebSEAL’s object space, and you can attach appropriate ACLs to these
protected objects.
Resolving dynamic URLs
The resolving of a dynamic URL to an object is dependent on the ordering of the
entries in the dynurl.conf configuration file.
When attempting to map a dynamic URL to an object entry, the list of mappings
in the dynurl.conf file is scanned from top to bottom until the first matching
pattern is found. When the first match is found, the corresponding object entry is
used for the subsequent authorization check.
Tip: Keep the mappings that correspond to the most restrictive ACLs higher
up in the list.
Summary
To configure WebSEAL to securely handle dynamic URLs:
򐂰 Set up the dynurl-map entry in the [server] stanza in the WebSEAL
configuration file:
[server]
dynurl-map = lib/dynurl.conf
򐂰 Create the dynurl.conf file at an appropriate location, such as:
/opt/pdweb/www-default/lib/dynurl.conf
򐂰 The file must contain one or more lines of the format:
object template
򐂰 If the file does not exist, or is empty, dynamic URL capability is not enabled.
򐂰 After the file has been processed, the object name appears as a child
resource in the WebSEAL object space.
򐂰 The template can contain a subset of the standard pattern matching
characters. The template can also be an exact string with no pattern matching
characters.
Single Sign On (SSO) options
As previously mentioned, WebSEAL is able to perform the initial authentication
and authorization to determine who can access the back-end WebSphere
Application Server resources. However, it is not practical for WebSphere
Application Server to rely solely on the security provided by reverse proxy
8
Security with TAM V6 and WebSphere Application Server V6 on z/OS
servers like WebSEAL, which controls the initial access into the enterprise
network.
In a typical scenario, the WebSphere Application Server systems will also be
secured. Therefore, whenever protected back-end resources are requested, the
user may be required to go through multiple logins, once at WebSEAL and once
at each WebSphere Application Server. It is also possible that each login uses
different user names. Figure 5 illustrates this scenario.
Figure 5 Multiple logins
As expected, the need for multiple logins, possibly with different user names,
negatively affects the user experience. Furthermore, the administration and
maintenance with multiple user accounts can become cumbersome and
expensive for the system administrators.
Security integration solutions such as Single Sign On (SSO) between WebSEAL
and the back-end WebSphere Application Server systems can improve these
problems of administration, maintenance, and negative user experiences.
A Single Sign On solution allows the user to access any back-end resource,
regardless of the resource’s location, using only one initial login. Any further login
requirements from back-end WebSphere Application Servers are handled by
WebSEAL transparently to the user.
WebSEAL offers a few options to perform SSO onto WebSphere Application
Server, including WebSphere Application Server on z/OS.
򐂰 Basic authentication
򐂰 Lightweight Third Party Authentication (LTPA)
򐂰 Trust Association Interceptor (TAI)
In the following sections, we explain these options in greater detail.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
9
Basic authentication
When the back-end WebSphere Application Server prompts the user for
authentication, the WebSEAL junction can supply WebSphere Application Server
with the client identity. The client identity is sent in the HTTP Basic Authentication
(BA) headers. Figure 6 illustrates this option.
Figure 6 Supplying authentication information to back-end application servers
After the client authenticates to WebSEAL, WebSEAL can build a new Basic
Authentication (BA) header, which it sends with the request to the back-end
servers. Even with the basic authentication option, there are a few ways to
transmit the client identity, depending on the need. You use the –b flag on the
junction to dictate what specific authentication information is supplied in this new
header.
The following options to transmit client identity are supported with the -b flag:
򐂰 No user name, no password
򐂰 Original user name, generic password
򐂰 Original user name, original password
򐂰 Global Sign On (GSO)
Each of these options are discussed briefly in the following sections.
Note: Because sensitive information (user names and passwords) is being
transmitted over the junctions, creating SSL junctions is highly recommended
to avoid security exposures.
No user name, no password
The –b filter option instructs WebSEAL to remove all Basic Authentication
header information from any client request before forwarding the requests to the
10
Security with TAM V6 and WebSphere Application Server V6 on z/OS
back-end server. In this scenario, the back-end server does not require any user
authentication, and WebSEAL becomes the only security provider. Figure 7
illustrates this option.
Figure 7 The -b filter option: remove client information
If necessary, it is still possible to configure WebSEAL to send some client
information via the HTTP headers. This can be accomplished by using the
-c flag when creating the junction.
Pros
򐂰 This scenario is simple to set up.
򐂰 It offers easy administration and maintenances.
Cons
򐂰 It offers only a single line of defense (WebSEAL).
򐂰 There is no security at back-end systems.
򐂰 With the location information, internal employees or hackers can easily
access the system.
򐂰 If set up to receive client information from WebSEAL, applications may need
to be highly customized rather than written to general standards.
Recommendation
This scenario is not practical for most enterprises. However, if the requirements
dictate the use of this solution, then the back-end systems should be secured to
avoid any exposure. One possible implementation may be to use firewalls to limit
communication to the back-end only through WebSEAL.
Original user name, generic password
The –b supply option instructs WebSEAL to supply the authenticated TAMeb
user name (client’s original identity) with a static, generic password. The
back-end server authenticates the supplied user name with the generic
Security with TAM V6 and WebSphere Application Server V6 on z/OS
11
password; the original client password is not used by the back-end server.
Figure 8 illustrates this option.
Figure 8 The -b supply option: original identity, dummy password
The user names in the TAMeb registry and back-end server registry must be in
sync, in order for the back-end server to recognize the supplied TAMeb identity.
Because all requests are sent with the same generic “dummy” password, all
users going through WebSEAL must have the same password in the back-end
server registry.
Pros
򐂰 This scenario permits access to the back-end on a per-user basis.
򐂰 There is no password administration on the back-end server.
Cons
򐂰 The back-end server cannot truly authenticate a client.
򐂰 The back-end server must implicitly trust WebSEAL.
򐂰 There is a possible security exposure, if any traffic bypasses WebSEAL.
Recommendation
This scenario is not practical for most enterprises. However, if the requirements
dictate the use of this solution, then the back-end systems should be secured to
avoid any exposure. One possible implementation may be to use firewalls to limit
communication to the back-end only through WebSEAL.
12
Security with TAM V6 and WebSphere Application Server V6 on z/OS
Original user name, original password
The –b ignore option instructs WebSEAL to pass the original client Basic
Authentication (BA) header straight to the back-end server. The back-end server
directly authenticates the user, regardless of whether WebSEAL has already
authenticated or not. Figure 9 illustrates this option.
Figure 9 “-b ignore” option: original identity, original password
It should be noted that this is not a true SSO solution, but rather a direct login to
the third-party server, transparent to the user and WebSEAL. If WebSEAL is
authenticating the user, then both the TAMeb registry and back-end server
registry need to be in sync, in order for the back-end server to accept the passed
identity.
Pros
򐂰 This scenario provides security at back-end server even if users bypass
WebSEAL.
Cons
򐂰 You need to maintain two separate user registries (TAMeb and the back-end
server).
򐂰 You need to ensure that both the TAMeb registry and back-end server
registry are synchronized for users going through WebSEAL.
Recommendation
This scenario provides an adequate level of security. While the setup is easy, it is
important to ensure that processes are in place to synchronize the two registries.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
13
Global Sign On (GSO)
The –b gso option instructs WebSEAL to supply the back-end server with
authentication information (user name and password) obtained from a server that
is set up to handle Global Sign On (GSO). The back-end servers require user
names and passwords that are different from the TAMeb names.
When a user accesses a junction configured with GSO, WebSEAL contacts the
GSO database to retrieve the authentication information for that user, for that
junction, and uses it to build the Basic Authentication header. Figure 10
illustrates this option.
Figure 10 The -b gso option: global signon
When WebSEAL receives a request for a resource located on the junctioned
server, WebSEAL asks the user registry server for the appropriate authentication
information. This process, illustrated in Figure 10, is described in these steps:
1. A client authenticates to WebSEAL with a request for access to a back-end
server requiring “specific” authentication information.
2. WebSEAL requests the back-end-specific user name and password for the
TAMeb user from the user registry server.
3. The registry returns the user name and password appropriate for the user and
the requested back-end server.
14
Security with TAM V6 and WebSphere Application Server V6 on z/OS
4. WebSEAL inserts the back-end-specific user name and password information
in the HTTP Basic Authentication header of the request, and transmits it to
the back-end server.
The user registry server contains a database of mappings, for each registered
user, that provides alternative user names and passwords for specific resources
and applications. With TAMeb, the LDAP server stores the GSO database
containing the authentication information for the back-end servers.
Pros
򐂰 This scenario accommodates large enterprises consisting of multiple systems
within heterogeneous, distributed computing environments.
򐂰 It eliminates the need for end users to manage multiple user names and
passwords.
򐂰 There is no need to synchronize various user registries.
Cons
򐂰 You need to maintain a user registry for each separate system.
򐂰 It involves complex and time-consuming administration and maintenance,
which increases with the number of users.
Recommendation
This scenario provides an adequate level of security, and may be simple enough
for a limited number of systems. However, it can easily spiral out of control as the
number of systems increases. Thus, it might be worthwhile to look into
centralizing the user registry and explore one of the other SSO options such as
Lightweight Third Party Authentication (LTPA) or Trust Association Interceptor
(TAI). These options are explained more fully in the following section.
Lightweight Third Party Authentication
WebSEAL supports the cookie-based LTPA mechanism to perform SSO onto
WebSphere Application Server. Both WebSEAL and WebSphere Application
Server must be configured accordingly to participate successfully in the SSO
relationship.
When a user makes a request for a WebSphere resource, the user must first
authenticate to WebSEAL. After successful authentication, WebSEAL generates
an LTPA cookie on behalf of the user. The LTPA cookie, which serves as an
authentication token for WebSphere, contains the user identity, key and token
data, buffer length, and expiration information. This information is encrypted
using a password-protected secret key shared between WebSEAL and the
WebSphere server.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
15
WebSEAL inserts the cookie in the HTTP header of the request that is sent
across the junction to WebSphere. The back-end WebSphere server receives
the request, decrypts the cookie, and authenticates the user based on the
identity information supplied in the cookie. Figure 11 illustrates the SSO solution
using the LTPA mechanism.
Figure 11 SSO with LTPA
The authentication flow for LTPA is as follows:
1. The user provides authentication information to log on to WebSEAL.
2. WebSEAL authenticates the user against the user registry.
3. WebSEAL encrypts credentials using the shared password-protected secret
key to generate the LTPA cookie.
4. WebSEAL inserts the LTPA cookie in the HTTP header of the request and
sends the resulting HTTP request to WebSphere Application Server.
5. The back-end WebSphere Application Server receives the request, decrypts
the cookie, and authenticates the user based on the identity information
supplied in the cookie.
6. The authenticated user request is transferred to the Web Container for
execution.
Note: For the LTPA option, both TAMeb and WebSphere Application Server
must share the same user registry.
Pros
򐂰 In this scenario, there is no need to synchronize various user registries.
16
Security with TAM V6 and WebSphere Application Server V6 on z/OS
򐂰 The user password is not sent to the back-end systems, thereby reducing the
possibility of “sniffing”.
Cons
򐂰 All systems participating in the LTPA SSO relationship must share the same
user registry.
򐂰 There could be performance implications due to the encryption/decryption of
the LTPA token.
Recommendation
This scenario provides an adequate level of security, but does require regular
work to maintain a secure environment. It should be noted that it is the secret key
that creates the secure environment. If the key is compromised, then there is a
breach in security. Thus, processes need to be established to ensure a secure
exchange of keys. Additionally, a process needs to be in place to change keys
periodically.
Trust Association Interceptor
WebSEAL supports the use of Trust Association Interceptor (TAI) to perform
SSO onto WebSphere Application Server. Both WebSEAL and WebSphere
Application Server must be configured accordingly to participate successfully in
the SSO relationship.
When a user makes a request for a WebSphere resource, the user must first
authenticate to WebSEAL. After successful authentication, WebSEAL inserts
user name in the “iv-user” HTTP header of the request that is sent across the
junction to WebSphere.
The back-end WebSphere server receives the request, confirms that it received
the request from WebSEAL, and authenticates the user based on the identity
supplied in the HTTP header. Figure 12 on page 18 illustrates the SSO solution
using the TAI mechanism.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
17
Figure 12 SSO with TAI
Here is the authentication flow for the TAI:
1. A user requests a secured resource.
2. WebSEAL prompts the user to authenticate.
3. The user provides authentication information.
4. WebSEAL authenticates the user against the user registry.
5. WebSEAL inserts the user name in the “iv-user” HTTP header of the request
and sends the resulting HTTP request to WebSphere Application Server.
6. The plug-in TAI establishes trust between WebSEAL and WebSphere
Application Server by using the negotiateAndValidateEstablishedTrust
method. It uses the password from the incoming request and the user ID
specified in the com.ibm.websphere.security.webseal.loginId variable.
7. The plug-in extracts the user name from the iv-user header field and passes it
to WebSphere Application Server for authorization.
TAMeb provides default implementations for TAI that can be used out of the box,
but these default TAI implementations require a shared registry. Custom TAI
implementations can be written to handle organization-specific situations.
Pros
򐂰 With this scenario, default implementations may be available by third party
vendors.
򐂰 It is possible to write a custom TAI as the interface offering:
– the freedom to either share user registries or use a different one
– the ability to do identity mapping at the TAI
18
Security with TAM V6 and WebSphere Application Server V6 on z/OS
Cons
򐂰 You may need to synchronize various user registries.
򐂰 To handle specific situations, you may need to maintain custom code
in-house.
򐂰 You need to explicitly set up a way of establishing trust between WebSEAL
and WebSphere Application Server.
Recommendation
This scenario provides an adequate level of security, but may not provide a
working, out-of-the-box solution for certain organizations. In such a case, it is
possible to write a custom TAI to handle specific situations. The custom TAI can
handle various things ranging from simply Single Sign On to identity mapping or
adding user attributes into the credential.
Authorizations in WebSphere Application Server
In the preceding section, we discussed problems pertaining to authentication at
multiple systems, and the potential solutions to these problems. While
authentication gets the users onto the system, it is the authorization portion that
determines the actions they may or may not take.
In the past, the typical setup was for each system to do its own authorizations. As
the same user may access multiple systems, each system had to administer,
maintain, and update its own authorization policy. Any changes to users or roles
resulted in changes to the authorization policies at every system. Authorization at
multiple systems presents us with similar problems.
The J2EE specification defines the building blocks and elements of a J2EE
application that build an enterprise application. The specification also provides
details on security related to the different elements.
WebSphere Application Server is a J2EE-compliant Java™ application server; it
implements the required security services as they are specified. The security
components are essential parts of the application server architecture.
A typical J2EE application consists of multiple modules and components; these
elements are in connection with each other, and they communicate via certain
protocols. Figure 13 on page 20 illustrates most of the elements in a J2EE
application and their relationships with one another.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
19
S e rvle t
E n tity E JB
U se r
D a ta b a se
B ro w se r
C lie n t
U se r
HTM L Page
S e ssio n E JB
M e ssa g e E JB
JS P P a g e
A p p lica tion
C lie n t
G ro u p
M e ssa g in g
M e d ia file s
W e b S e rvice
A p p lica tio n
LEGACY
A P P L IC A T IO N
www
Figure 13 J2EE application components
Figure 13 displays several arrows, indicating connections between elements;
these are the connections and connection groups that have to be secured in a
J2EE application. J2EE uses security roles to secure these components.
There are multiple options available for authorizations in WebSphere Application
Server:
򐂰 Programmatic authorizations
– Standard J2EE API
– Custom API
򐂰 Declarative authorizations
– Internal WebSphere Application Server authorizations
– External authorizations
Although using declarative authorizations is the recommended method, it may be
beneficial and sometimes necessary to use both options as required. Each of
these options is discussed in more detail in the following sections.
Programmatic authorizations
Applications can be developed to be security-aware by using programmatic
authorizations to enforce the security policy. It is possible to use the
programmatic APIs to implement security for the whole application without using
the application server security functions at all. The security logic is written into
20
Security with TAM V6 and WebSphere Application Server V6 on z/OS
the application code itself, and needs to be updated to reflect ongoing changes.
Figure 14 illustrates the programmatic authorization scenario.
WebSphere V6 Runtime
Client
Authentication
HTTP/
HTTPS
Internal
Transport
Web
Container
EJB
Container
Bean
Servlet
Web App
Authentication
User
Registry
EJB App
Programmatic Authorization
Authorization
database
Figure 14 Programmatic authorizations
The user authenticates as usual to gain access to the application, but the
application code may conducts checks at various points to determine the level of
access for the user.
Using programmatic authorizations also allows the option of implementing
dynamic security rules for your applications. Using programmatic authorizations
is useful when the application server-provided security infrastructure cannot
provide all the functionality needed for the application.
You can use various types of APIs (standard J2EE, third party, or custom) to
make programmatic authorization calls.
Standard J2EE API
For situations that require programmatic authorization, the J2EE specification
defines APIs to use within the program logic. An API is available with two
methods each for the Web container and the EJB container.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
21
For Web applications, the methods defined in the J2EE APIs are:
򐂰 getUserPrincipal
The getUserPrincipal method allows the developer to get the name of the
current caller. To do this, you need to call getName() on the
java.security.Principal object returned.
Principal principal=request.getUserPrincipal();
String username=principal.getName();
Important: getUserPrincipal() returns null as a result even if the
user is logged in, unless the servlet or the JSP itself is secured.
򐂰 isUserInRole
The isUserInRole method allows the developer to perform additional checks
on the authorization rights of a user which are not possible, or more difficult,
to perform through the deployment descriptor of the servlet.
if
{
//
//
//
}
(request.isUserInRole(“Manager”))
the user is in the manager role
do something that requires Manager role
...
For EJB applications, the methods defined in the J2EE APIs are:
򐂰 getCallerPrincipal
The getCallerPrincipal method allows the developer to get the name of the
current caller. To do this, you need to call getName() on the
java.security.Principal object returned.
EJBContext ejbContext;
...
// get the caller principal
java.security.Principal callerPrincipal =
ejbContext.getCallerPrincipal();
// get the caller’s name
String callerName = callerPrincipal.getName();
The Principal.getName() method returns the login name of the user.
򐂰 isCallerInRole
The isCallerInRole method allows the developer to make additional checks
on the authorization rights of a user which are not possible, or more difficult,
to perform through the deployment descriptor of the EJB.
EJBContext ejbContext;
22
Security with TAM V6 and WebSphere Application Server V6 on z/OS
...
if (ejbContext.isCallerInRole(“restricted role“))
// Perform some function
else
// Throw a security exception
The isCallerInRole(String role) method returns true if the user is in the
specified role, and false if the user is not. The role name specified in the
method is really a security role reference, not a role. If the security role
reference is not defined for the EJB, the method will return null.
The getUserPrincipal and getCallerPrincipal methods can be used to retrieve
the user ID associated with the current Web application (servlet or Java Server
Page) or EJB, respectively.
The isUserInRole and isCallerInRole methods can be used to check if the
current user has been given access to a certain role. Based on the result, the
program can make decisions in its processing path. Calls to these methods result
in a query either to the local bindings file, or to an external provider, if the security
has been set up as such.
Pros
򐂰 This scenario offers fine-grained access control.
򐂰 Easy integration with existing systems is possible.
򐂰 It is easy to migrate/port applications between J2EE application servers.
򐂰 Documented upgrade paths are available when standard APIs change.
Cons
򐂰 Application developers need to handle security, in addition to business logic.
򐂰 You have to trust application developers with security.
򐂰 There is a risk of having malicious application developers.
򐂰 Frequent changes to security policy will force recoding and redeployment of
application.
򐂰 There is higher administration overhead due to decentralized security.
Recommendations
Although this solution offers easy migrations and upgrade paths, maintenance is
the biggest drawback; thus, it may not be the ideal solution, mainly due to the
maintenance requirements. However, this could complement the declarative
security solution quite well, when used specifically for finer-grained authorization
decisions.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
23
Third party API
Many organizations use a third party security provider, such as TAMeb, to store
their authorization information. Often, third party security providers may provide a
set of APIs that allow applications to communicate with their corresponding
security product to make authorization decisions. Application developers invoke
these classes directly in the application code to retrieve authorization information
to make access control decisions.
TAMeb provides two simple Java classes to assist in authorization checks:
PDPrincipal
This class represents the identity of a TAMeb user. It is
possible to create a PDPrincipal.
PDPermission
This class represents an authorization permission for
accessing a protected resource object in a secure domain
defined by TAMeb.
Both PDPrincipal and PDPermission have an implies method to determine
whether the user has access to a protected resource. Example 2 illustrates
usage of the TAMeb authorization Java API to perform authorization checks.
Example 2 TAMeb Java authorization API
PDPrincipal whoIsIt = new PDPrincipal("testUser")
PDPermission whatTheyWant = new PDPermission("/resource", "abT");
boolean haveAccess = whoIsIt.implies(whatTheyWant);
if (haveAccess)
{
// permit access
// take appropriate action...
}
else
{
// deny access
// take alternate action...
}
In the example, we simply create a PDPrincipal object for a user based on the
username, and a PDPermission object based on the resource and the desired
actions. We can use the implies method of either object with the relevant
PDPermission or PDPrincipal to get a true or false response. Subsequently, we
use the true or false response to make the authorization decision.
Pros
򐂰 This scenario offers fine-grained access control.
򐂰 There is easy integration with existing systems.
24
Security with TAM V6 and WebSphere Application Server V6 on z/OS
򐂰 It may be used in a centralized security solution.
Cons
򐂰 Application developers need to handle security in addition to business logic.
򐂰 You have to trust application developers with security.
򐂰 You risk having malicious application developers.
򐂰 Frequent changes to security policy will force recoding and redeployment of
application.
Recommendations
Although this solution may offer centralized security, it does not leverage
standard J2EE APIs. Therefore, it may not be the ideal solution, mainly due to
the support and maintenance requirements. However, this solution could
complement the declarative security solution quite well, when used specifically
for finer-grained authorization decisions.
Custom API
In certain situations, organizations may have created their own in-house
authorization system, either from scratch or by leveraging existing products such
as an LDAP server. As an example, organizations using LDAP may authorize
users based on their group memberships. Of course, this requires the LDAP
administration team to add the users to the necessary groups.
There may be custom-written APIs to conduct authorizations. Typically, such an
authorization system would be widely used in the enterprise to maintain a central
security policy, and most applications would be coded to leverage these APIs.
Pros
򐂰 This scenario offers fine-grained access control.
򐂰 It provides easy integration with existing systems.
򐂰 It may be used in a centralized security solution.
Cons
򐂰 Application developers need to handle security in addition to business logic.
򐂰 You need to trust application developers with security.
򐂰 You face the risk of having malicious application developers.
򐂰 Frequent changes to security policy will force recoding and redeployment of
application.
򐂰 Organizations need to provide support themselves, because a standardized
product is not being used.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
25
Recommendations
Although this solution may offer centralized security, it does not leverage
standard J2EE APIs or third party APIs. Thus, instead of relying on application
server vendors or third party security server vendors, the organization will have
to establish a department and help desk to provide support internally. Therefore,
it may not be the ideal solution, mainly due to the added support and
maintenance requirements. However, this solution could complement the
declarative security solution quite well, when used specifically for finer-grained
authorization decisions.
Declarative authorizations
Declarative security is the means by which an application’s security policies can
be expressed externally to the application code. At application assembly time,
security policies are defined in an application’s deployment descriptor. A
deployment descriptor is an XML file which includes a representation of an
application’s security requirements, including the application’s security roles,
access control, and authentication requirements.
When using declarative security, application developers are free to write
component methods that are completely unaware of security. By making
changes to the deployment descriptor, an application’s security environment can
be radically changed without requiring any changes in application code.
Declarative security involves two phases:
Role-to-resource mapping
Resources are secured based on the roles
authorized to access that resource.
User/group-to-role mapping Users and groups are mapped to specific roles
based on their position.
Authorization information is set up in the application deployment descriptor, and
used during runtime. At runtime, when a resource is requested, WebSphere
Application Server determines the required roles to access that resource, and
then determines whether the user is in the required role.
Table 1 on page 27 lists the two deployment descriptor files used for
authorizations within WebSphere Application Server.
26
Security with TAM V6 and WebSphere Application Server V6 on z/OS
Table 1 Deployment descriptor files
File names
Purpose
Mandatory
application.xml
Role-to-resource mapping
Yes
ibm-application-bnd.xmi
User/group-to-role
mapping
No.
User/group-to-role
mappings can be done
externally to WebSphere
Application Server.
Role-to-resource mappings
In the application.xml file, all security roles used in the application must be
named, with an optional description. Example 3 illustrates the XML elements
required to define six security roles: manager, consultant, clerk, accountant,
allauthenticated, and everyone.
Example 3 Security role definitions in application.xml
<security-role id="SecurityRole_1">
<description>ITSOBank manager</description>
<role-name>manager</role-name>
<security-role>
<security-role id="SecurityRole_2">
<description>ITSOBank consultant</description>
<role-name>consultant</role-name>
</security-role>
<security-role id="SecurityRole_3">
<description>ITSOBank clerk</description>
<role-name>clerk</role-name>
</security-role>
<security-role id="SecurityRole_4">
<description>ITSOBank accountant</description>
<role-name>accountant</role-name>
</security-role>
<security-role id="SecurityRole_5">
<description>All authenticated users</description>
<role-name>allauthenticated</role-name>
</security-role>
<security-role id="SecurityRole_6">
<description></description>
<role-name>everyone</role-name>
</security-role>
Security with TAM V6 and WebSphere Application Server V6 on z/OS
27
User/group-to-role mappings
WebSphere on z/OS always maintains the role-to-resource mappings locally, but
provides three options for the user/group-to-role mapping:
WebSphere Application Server for z/OS bindings
WebSphere Application Server for z/OS
(WAS/z) maintains user/group-to-role
mappings in a bindings file, and makes
access control decisions locally
SAF EJBROLE profiles
RACF® maintains user/group-to-role
mappings, and WebSphere Application
Server for z/OS queries RACF.
External authorization provider
An external provider maintains
user/group-to-role mappings, and
WebSphere Application Server for z/OS
queries the external provider’s authorization
service.
Each of these options is discussed in more detail in the following section.
WebSphere Application Server for z/OS bindings
In this scenario, WebSphere Application Server maintains all the authorization
information (including the role-to-resource and user/group-to-role mappings)
locally, in the deployment descriptor files. The authorization information can be
modified via the WebSphere Application Server admin console or scripts, which
update the necessary configuration files.
The application deployer performs user-to-role mappings by selecting users and
groups in a registry and indicating that they are in that role for that application.
The authorization is actually built into the .ear file. This can be done using
WebSphere Studio Application Developer or RAD.
The selection for how role-to-user mapping is done is at a cell level. It is
dependent on the com.ibm.SAF.Authorization property. This can be set either to
customization dialog or the administrative console.
In the ibm-application-bnd.xmi file, security roles are mapped to users or groups
in the User Registry. Table 2 on page 29 shows how the security roles would be
mapped.
28
Security with TAM V6 and WebSphere Application Server V6 on z/OS
Table 2 Role mappings
Security role
Mapped to
manager
managergrp
consultant
consultantgrp
clerk
clerkgrp
accountant
accountantgrp
allauthenticated
All authenticated users (special subject)
everyone
Everyone (special subject)
Example 4 displays an extract from the ibm-application-bnd.xml file that holds the
binding information for the J2EE roles.
Example 4 Security role mappings in the ibm-application-bnd.xmi file
<authorizationTable xmi:id="AuthorizationTable_1">
<authorizations xmi:id="RoleAssignment_1">
<role href="META-INF/application.xml#SecurityRole_1"/>
<groups xmi:id="Group_1" name="managergrp"/>
</authorizations>
<authorizations xmi:id="RoleAssignment_2">
<role href="META-INF/application.xml#SecurityRole_2"/>
<groups xmi:id="Group_2" name="consultantgrp"/>
</authorizations>
<authorizations xmi:id="RoleAssignment_3">
<role href="META-INF/application.xml#SecurityRole_3"/>
<groups xmi:id="Group_3" name="clerkgrp"/>
</authorizations>
<authorizations xmi:id="RoleAssignment_4">
<role href="META-INF/application.xml#SecurityRole_4"/>
<groups xmi:id="Group_4" name="accountantgrp"/>
</authorizations>
<authorizations xmi:id="RoleAssignment_5">
<specialSubjects xmi:type="applicationbnd:AllAuthenticatedUsers"
xmi:id="AllAuthenticatedUsers_1" name="AllAuthenticatedUsers"/>
<role href="META-INF/application.xml#SecurityRole_5"/>
</authorizations>
<authorizations xmi:id="RoleAssignment_6">
<specialSubjects xmi:type="applicationbnd:Everyone" xmi:id="Everyone_1"
name="Everyone"/>
<role href="META-INF/application.xml#SecurityRole_6"/>
</authorizations>
</authorizationTable>
Security with TAM V6 and WebSphere Application Server V6 on z/OS
29
At application startup, WebSphere Application Server reads the authorization
information and loads it in memory to use when a protected resource is
accessed.
Pros
򐂰 This scenario offers better performance, because authorization information is
kept in memory.
Cons
򐂰 There is a decentralized security policy, because each application maintains
its own security policy.
򐂰 Any changes to the security role mapping requires redeployment of the
application.
Recommendations
This standardized J2EE solution offers the benefit of declarative security, thereby
shielding application development from security issues, so it is ideal for a low
number of applications. However, because each application maintains its own
security policy, the application assemblers and deployers need to synchronize
the security policy in the various applications. Therefore, with a higher number of
applications, maintenance and administration become issues.
SAF EJBROLE profiles
In this scenario, WebSphere Application Server maintains the role-to-resource
mappings, but retrieves the user/group-to-role mappings from RACF.
Using this mechanism, authorization is placed in the control of the security
administrator. The security administrator defines an EJBROLE profile for each
J2EE role defined in an application. A user is considered to be “in role” if the user
is given READ permission to that EJBROLE profile. This support is only provided
if the local OS registry is configured. This support was provided in WebSphere
Application Server for z/OS V4.01. It is unique to WebSphere for z/OS.
Pros
򐂰 This scenario offers easier administration because of the centralized security
policy.
Cons
򐂰 Its use is limited to applications running on the zSeries platform.
Recommendations
Although this standardized J2EE solution offers the benefit of declarative
security, thereby shielding application development from security issues, it only
30
Security with TAM V6 and WebSphere Application Server V6 on z/OS
supports applications running on WebSphere Application Server for z/OS. This
solution is ideal if most or all of the applications are deployed on WebSphere
Application Server for z/OS. Because all of the user/group-to-role mapping can
be maintained in one place, the administration and maintenance becomes much
easier.
However, it should be noted that this solution does not support applications on
distributed systems. Applications on distributed systems need to maintain their
security information separately, thereby decentralizing security and increasing
administration.
External Authorization Provider
In this scenario, WebSphere Application Server maintains the role-to-resource
mappings, but retrieves the user/group-to-role mappings from a third party
authorization provider such as TAMeb.
WebSphere Application Server for z/OS supports both a default authorization
provider, which was supported in previous releases, and an authorization
provider that is based on the Java Authorization Contract for Containers (JACC)
specification. The JACC-based authorization provider enables third-party
security providers to handle the J2EE authorization.
The JACC specification requires that both the containers in the application server
and the provider satisfy some requirements. Specifically, the containers are
required to propagate the security policy information to the provider during the
application deployment and to call the provider for all authorization decisions.
The providers are required to store the policy information in their repository
during application deployment. The providers then use this information to make
authorization decisions when called by the container.
Using this mechanism, WebSphere Application Server for z/OS is configured to
use TAMeb as the external authorization provider. When an application is
deployed to WebSphere Application Server for z/OS, the roles are created as
protected objects in TAMeb's object space. Based on the security policy, the
TAMeb administrators must give users access to the protected role objects. A
user is considered to be “in role” if the user has permission to the role object.
Pros
򐂰 This scenario offers easier administration due to a centralized security policy.
򐂰 It offers centralized security across the enterprise, including zSeries and
distributed systems.
Security with TAM V6 and WebSphere Application Server V6 on z/OS
31
Cons
򐂰 It relies on the availability of an external authorization provider.
Recommendation
This standardized J2EE solution offers the benefit of declarative security, thereby
shielding application development from security issues. Because all the
user/group-to-role mapping can be maintained in one place, it can support
applications on both zSeries and distributed systems, thus making the
administration and maintenance much easier. For an enterprise with various
applications on both zWAS and distributed systems, this is an ideal solution.
The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Poughkeepsie
Center.
Alex Louwe Kooijmans is a Project Leader at the International Technical
Support Organization, Poughkeepsie Center. He joined IBM® in 1986, and his
areas of expertise include Java and WebSphere on z/OS, and integration of
WebSphere with DB2®, MQ, CICS® and IMS™. Alex leads residencies to create
IBM Redbooks™ about Java and WebSphere on z/OS, and also teaches
workshops on these topics. This is the second ITSO assignment for Alex. Prior to
joining the ITSO, he worked as an IT Specialist supporting customers in Europe
who were getting started with WebSphere on various platforms. He was also a
Client IT Architect in the Financial Services Sector in The Netherlands.
Dinkar Tiwari is a Senior Consultant at Ariba, Inc., where he focuses on design
and implementation of Spend Management solutions. For the past year, he has
worked with clients to implement solutions for various business needs including
Supplier Performance Management, Spend Analysis Data Warehousing, and
Contract Management. Prior to that, Dinkar was involved with technical sales,
design, development, and project management of IT solutions including
e-business, security, access management, identity management, and Web
applications. He holds a Master's degree in Computer Information Systems, and
a Bachelor's degree in Computer Science. He can be reached at
dtiwari_work@yahoo.com.
Thanks to Jeff Simon, IBM Systems & Technology Group, infrastructure
solutions, for his contribution to this project.
32
Security with TAM V6 and WebSphere Application Server V6 on z/OS
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright International Business Machines Corporation 2006. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
33
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
®
Redpaper
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
CICS®
DB2®
IBM®
IMS™
RACF®
Redbooks™
Redbooks (logo)
Tivoli®
WebSphere®
z/OS®
™
The following terms are trademarks of other companies:
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel
SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
34
Security with TAM V6 and WebSphere Application Server V6 on z/OS