. 61
( 87 .)


As these technologies continue to develop, we might see support in Struts
Portlet Framework in the JSF environment. A new request processor would
be needed that could receive JSF events and send them to a struts action
within Struts Portlet Framework. However, the direction of struts and JSF
and the implementation support through Struts Portlet Framework was not
known at the time of writing this chapter.

This chapter examined the implementation of the example portlet using
Struts Portlet Framework. As you did for the JSR 168 API portlet imple-
mentation, you took the Poll portlet developed using the IBM Portlet API
and converted it to use Struts in the portal environment.
WY009-18 WY009-BenNatan-v1.cls May 11, 2004 14:51

362 Chapter 18

Also discussed was the current state of the portlet APIs, and suggestions
were offered why you might choose one or the other. The struts framework
insulates you to some degree from the portlet API, but as we have seen
when converting the Poll portlet, the API is still exposed and used in the
struts implementation.
This chapter completes the discussion on portlet development. The next
chapter begins the topic of WebSphere Portal within the enterprise env-
iornment and starts with a discussion on implementing WebSphere Portal
identity manager. The chapter focuses on WebSphere Portal™s use of LDAP
user registries in the enterprise environment.
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

WebSphere Portal
within the Enterprise

WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21


Implementing Authentication
for Large Enterprises

Authentication is the process where users are challenged to identify them-
selves to gain access to a system. The challenge can be immediate or upon
trying to access a protected resource. It is usually encountered by the user
as requesting for a user id and password but it can also be authenticating
through a biometric device or a digital certi¬cate. Information required for
authentication is stored in user registries while information relating to the
user™s pro¬le and preferences is stored in the user repository.
If you have a few users, WebSphere Portal authentication is pretty simple
and easy to con¬gure. However, if yours is a large enterprise with many
users accessing the site from both your global intranet and extranet, then
this subject gets a lot more complex. In this chapter we are going to discuss
issues relating to enterprise identity management for WebSphere Portal.

Enterprise Identity Management
WebSphere Portal performs identity management though Member Man-
ager. When a user authenticates, Member Manager validates the informa-
tion in both the authentication registry and the member database.
WebSphere Portal supports four types of identity management con¬gu-
rations, as seen in Figure 19-1. The ¬rst is where the user registry and pro-
¬le information for WebSphere Portal and WebSphere Application Server is
stored on the same LDAP server, which is usually remote. Member Manager
maintains and updates all user information in the LDAP server. The second
con¬guration is where Member Manager uses a look-aside repository (that
is, a database) to store user pro¬le attributes not supported in the LDAP.

WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

366 Chapter 19

Figure 19-1 Different LDAP con¬gurations.

The split is based on Member Manager con¬guration XML ¬les. The third
identity management con¬guration is where Member Manager and Web-
Sphere Application Server create and maintain the user identity and pro¬le
information in the same database For the third identity management con¬g-
uration, WebSphere Application Server poses the actual challenge using the
data from WebSphere Portal Custom User Registry. For all the con¬gura-
tions, the user registry is shared by both WebSphere Portal and WebSphere
Application Server.
The last identity management con¬guration is using third-party authen-
tication using Trust Association Interceptors. Chapter 20 goes into great
detail on this con¬guration.

LDAP or Database
So the ¬rst question you ask yourself when you design the identity man-
agement infrastructure is whether to use an LDAP server or an enterprise
database. This, of course, leads to the next question: what is LDAP?
LDAP or Lightweight Directory Access Protocol is an open industry stan-
dard that de¬nes a standard method for accessing and updating informa-
tion in a directory. A directory is a database variety that stores typed and
ordered information about objects. An LDAP directory is designed for read
performance, which means it assumes that the user data will be read far
more than it will be changed.
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

Implementing Authentication for Large Enterprises 367

If your company already stores its user registries on an LDAP, then the
answer is a “no-brainer.” But if it doesn™t, then you have to consider the
following factors:

1. Does your enterprise have any skill set in con¬guring and running
an LDAP server in production? While some people say that LDAP is
simple to install and maintain, this is not true for large directories. It
experiences the same operational issues as any database and you
need to have the knowledge within your IT area to support it. If they
have no experience with an LDAP server but have expertise in DB2
or Oracle, then go with the database.
2. How often is the user data being updated or created versus being
read. If the ratio of read to updates for the user data is high, then an
LDAP server is well suited. Usually the pro¬le and authentication
information such as user ID, password, name, title, address, e-mail,
and demographical information does not change that often and is
well suited for an LDAP while privilege information such as roles
and access control groups can change more frequently and is better
suited for a database.
3. Is the management of the users decentralized? LDAP servers usually
have a more ef¬cient replication process than databases.
4. Does any of the data have transactional dependencies? That is, if the
name and address are being updated, they must both successfully
update and if not, they should rollback to their original values. Most
LDAP servers do not support transactionality.
5. Do you need to perform sophisticated queries against the directory?
LDAP directories use a simple access protocol that cannot match the
power of an enterprise database™s Structured Query Language for
complex update and query functions.

Rules of Thumb for Designing and Maintaining
Your LDAP Server
After answering the above questions, you have probably decided that for a
large enterprise it is better to go with an LDAP server. So the next steps are
as follows:

Determine Directory Tree by designing the schema and arranging the
entries in the tree structure.
De¬ne the replication and partitioning strategies.
Create an infrastructure plan.
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

368 Chapter 19

Designing the Information Model
One of the biggest factors affecting the performance and maintainability of
the LDAP server (and thus the Identity Management component of Web-
Sphere Portal) is implementation of the information model correctly.
The information model describes how information is stored in an LDAP
directory. Information is represented in an LDAP directory by an entry.
An entry is equivalent to an object such as employees, servers, and so on.
Entries consist of a collection of attributes that contain information about
the object. Each attribute has a type and one or more values associated with
it. Associated with a type is a syntax that speci¬es what values can be stored
and how a value behaves during searches and other operations. Attributes
can also have an alias name that can be used instead of the attribute name.
For instance, the common LDAP attribute surname has an alias sn and an
LDAP syntax cis associated with it. cis stands for case ignore string, which
means case is not signi¬cant during comparisons. An attribute can also have
a constraint associated with it to limit the number of values or the total size
of the value.
The LDAP Schema de¬nes the object classes and attribute types. Ob-
ject class describes the types of objects each entry can represent and at-
tribute type de¬nes the attributes of each object type, and whether these
attributes are optional or mandatory. In order to facilitate interoperability,
the schemas have been standardized by Internet Society. Two standards
that were adopted by manufacturers are RFC 2252, LDAP (V3); Attribute
Syntax De¬nitions and RFC 2256, A summary of X.500(96) User Schema
for use with LDAP V3. For instance in the RFC 2256 standard schema, sn is
X.500 surname attribute, which contains the family name of a person. An
example of an objectclass is person, which must have the objectclass value
on top and either the attribute type surname or commonName and may
have the attribute types userPassword, telephoneNumber, seeAlso,
and description.
Most of the LDAP servers will have default schema and directory tree
layout for the user registries. You should basically not change the structure
or elements since this will obviously cause interoperability problems be-
tween other directory services and LDAP clients. De¬nitely do not delete
standard schema elements. If you need to add an object class then extend
the default schema. Objects added to the LDAP directory should be ac-
cessed by more than one user or client. If they are not, then they should be
placed in a database.
You need to de¬ne who owns the identity management data and who
is responsible for keeping it up-to-date. An operations manual should be
created that identi¬es this information. Programs may also need to be cre-
ated to allow the help desk to administer the data. Insure that there is no
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

Implementing Authentication for Large Enterprises 369

inconsistency in the schema; that is, two different attributes with the same
If the identity management data is being imported from other sources,
develop a strategy for bulk imports and incremental updates. Insure that
the data is being imported from the main identity management database
and not from another mirror site.

Designing the Directory Information Tree
Data is stored hierarchically in a directory information tree (DIT) over one
or more LDAP server(s). The top level of the LDAP directory tree is called
the base distinguished name (DN) or a suf¬x. Each directory record has a
unique DN and is read backward through the tree from the individual entry
to the top level. The DN is used as a key to the directory record.
For example in Figure 19-2, Ken Chow™s entry would be accessed using
cn=Ken Chow, ou=Marketing,dc=rigorconsultants,dc=com.
If the DIT is split over multiple servers, then referrals are used to link the
servers. This is done by creating an entry of objectClass referral with an
attribute ref and assigning the value an LDAP URL, which points to the
entry on another LDAP server.

Figure 19-2 A sample directory naming structure.
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21


. 61
( 87 .)