<<

. 64
( 87 .)



>>

c. Extract the new self-signed certi¬cate as a certi¬cate ¬le using
base64-encoded ASCII data as the data type and save it. The
¬lename can be a ¬lename of your choice but the extension
must be .arm.
d. Con¬gure your LDAP directory with SSL enabled using the
CMNS Key Database ¬le contained in the self-signed certi¬cate.
2. Import the certi¬cates to a WAS keystore by doing the following:
a. Open a command prompt and execute <was_root>\ikeyman
.exe.
b. Determine the keystore ¬le by going into the WebSphere
Application Server Admin Console, and click Security ➪ SSL.
c. Open the keystore ¬le. If it already exists, you will be asked for a
password, otherwise you will need to supply it.
d. Select Signer Certi¬cates from the top drop-down list and click
Add.
e. Select base64-encoded ASCII data as the data type and browse to
the certi¬cate ¬le that you exported from your LDAP server.
f. Enter the certi¬cate label that you assigned in step 1b, and click
Save.
3. Next you must import the certi¬cate into WebSphere Portal keystore
a. Open a command prompt and execute <was_root>\ikeyman
.exe.
b. Open the default keystore ¬le <was_root>\java\jre\lib\
security\cacerts. The default password is changeit.
P1: FCH
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21




382 Chapter 19


c. Select Signer Certi¬cates in the top drop-down list and click Add.
d. Select base64-encoded ASCII data as the data type and browse to
the certi¬cate ¬le that you exported from your LDAP server.
e. Enter the certi¬cate label that you assigned in step 1b and click
save.
4. Shut down the non-SSL port (389) if you want to ensure that data
exchanged between WAS and WP is con¬dential.

To con¬gure Active Directory over SSL, you need to ¬rst install Active
Directory, Internet Information Services, and then WebSphere Application
Server. Then perform the following tasks:

1. Export the root CA certi¬cate:
a. Open your Web browser and connect to http://localhost/
certsrv.
b. Select the task Retrieve the CA Certi¬cate or certi¬cate revocation
list and click Next.
c. Choose the certi¬cate you created and set the format to base 64
encoded. Click Download CA Certi¬cate.
d. Save the certi¬cate in a ¬le called certnew.cer.
e. Open a command prompt, enter mmc.exe, and click File ➪ Add/
Remove Snap-in.
f. Click Add, choose CA Snap-in, and click OK. Find the root
certi¬cate public key and save to a ¬le.
2. Import the certi¬cate to the WebSphere Application Server keystore:
a. Open a command prompt and execute <was_root>\ikeyman
.exe.
b. Open the default keystore ¬le <was_root>\java\jre\lib\
security\cacerts. The default password is changeit.
c. Select Signer Certi¬cates in the top drop-down list and click Add.
d. Select base64-encoded ASCII data as the data type and browse to
the certnew.cer ¬le.
e. Type a name for the certi¬cate and click OK.


Con¬gure WebSphere Portal to Support SSL
To con¬gure WebSphere Portal to use LDAP over SSL (excluding Active
Directory) do the following:
P1: FCH
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21




Implementing Authentication for Large Enterprises 383


1. Ensure that WebSphere Application Server has been con¬gured and
is operating with SSL support by selecting Security ➪ User
Registries ➪ LDAP and ensuring SSL is enabled and the
sslcon¬guration property ¬le has been correctly entered.
2. Con¬gure WebSphere Portal to use LDAP over SSL by modifying the
<ldapRepository...> stanza in <wp_root>/shared/app/
wmm/wmm.xml:
a. Change the LDAP port number to the SSL port number.
b. Add the following key/value pairs:
java.naming.security.protocol=“ssl”.
3. Restart WebSphere Portal.
For Active Directory do the following:
1. Ensure that WebSphere Application Server has been con¬gured and
is operating with SSL support by selecting Security ➪ User
Registries ➪ LDAP and ensuring SSL is enabled and the
sslcon¬guration property ¬le has been correctly entered.
2. Con¬gure WebSphere Portal to use LDAP over SSL by modifying the
<ldapRepository...> stanza in <wp_root>/shared/app/
wmm/wmm.xml:
a. Change the LDAP port number to the SSL port number.
b. Set wmmmGenerateExtId to false.
c. Add the following key/value pairs:
java.naming.security.protocol=“ssl”.
3. Remove all occurrences of ibm-appUUIDAux from wmm.xml.
4. Enable Active Directory to recognize a short name (as opposed to a
fully quali¬ed DN) by selecting Security ➪ User Registries ➪ LDAP ➪
Advanced LDAP Settings in the WebSphere Application Server
console and change the user ¬lter from (&(cn=%v)(objectclass=user))
to (&(sAMAccountName=%v)(objectclass=user)).
5. Restart WebSphere Portal.


Mapping of Member Manager Attributes
to Your LDAP Attributes
The con¬guration parameters that are generated by WebSphere Portal in-
stallation and WPScon¬g are stored in <wp_root>\shared\app\wmm\wmm
.xml. When you con¬gure WP for LDAP, there is an entry con¬gurationFile
P1: FCH
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21




384 Chapter 19


="<wp_root>/wmm/wmmLDAPServerAttributes_XXX.xml under the
LDAPRepository tag in the wmm.xml ¬le. This entry refers to an xml that
maps the pro¬le attributes to the LDAP object classes and attributes. The
last three letters refer to the LDAP directory being mapped. For instance:
wmmLDAPServerAttributes IDS contains the maps for IBM
Directory Server
wmmLDAPServerAttributes SO contains the maps for Sun One
Directory
wmmLDAPServerAttributes IDS contains the maps for Active
Directory
In each ¬le, the names of the various repositories, their Member Managers
adapter implementation classes, and the mapping between the Member
Manager attribute and the repository are de¬ned. Mapping of the user
attributes to the LDAP directory is based on the inetOrgPerson schema.
By modifying the wmmLDAPServerAttributes_XXX ¬le, you can expose
new LDAP attributes to Member Manager.
For instance look at this entry in wmmLDAPServerAttributes IDS:
<attributeMap wmmAttributeName="uid"
pluginAttributeName="uid"
applicableMemberTypes="Person"
requiredMemberTypes="Person"
dataType="String"
valueLength="256"
multiValued="false" />

You see that the LDAP attribute (wmmAttrributeName) uid is mapped
to the Member Manager attribute (pluginAttributeName) uid where the
member type is Person and it is required. The data type is string of length
256 bytes and it cannot have more than one value assigned.
What is more important is that this is the process to de¬ne which attributes
will be stored in a look-aside database.


Summary
In this chapter we focused in great detail on implementing WebSphere
Portal Identity Manager. We speci¬cally focused on using LDAP servers
due to their suitability in handling large user registries that are dispersed
over multiple locations. In the next chapter we will discuss the logical next
topic: implementing WebSphere Portal with Single Sign-on.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




CHAPTER

20
Integrating Security and
Identity Management Tools
with WebSphere Portal

In this chapter you will learn to integrate security and identity management
tools with WebSphere Portal. Because of the complexity involved with se-
curity features such as authentication and authorization in environments
including many applications and information sources, a new category of
products has emerged in the past few years. These products manage repos-
itories of users and their pro¬les and implement security policies for au-
thenticating and authorizing access based on identifying users and map-
ping them to static or dynamic roles. These tools allow you to manage a
complex entitlement model that spans multiple applications and sources.
Because portals are in many ways the ultimate integrated environment,
knowing how to use these tools in the context of WP is increasingly im-
portant and many portal initiatives succeed or fail depending on identity
management and security. Perhaps the most well-known issue that must
be addressed in the context of a portal is that of single sign-on (SSO). A
good SSO environment means that once a user has authenticated with the
system (and normally this is during the initial log-on to the portal), he or
she will not be asked to authenticate again even when they traverse appli-
cation boundaries. A bad SSO implementation (or no SSO implementation)
will constantly ask the user for a user name and a password”every time
the user accesses a separate application. Because portals often integrate a
large number of back-end applications as portlets, a bad SSO implemen-
tation will create a horrendous user experience and can potentially create
a usability issue that will cause limited user adoption. This is the basic
reason that security and identity management tools have been highly suc-
cessful in the past few years and the reason that a new category of products
has emerged.

385
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




386 Chapter 20


Two approaches to SSO can be used. In Chapter 23 we discuss back-
end SSO within WP using the Credential Vault. This approach makes use
of built-in WP functionality that allows you to store back-end application
credentials within WP and associate them with WP users. In this chapter,
the focus is the use of external security managers to perform SSO.
Many products address this need for using external security managers
to perform SSO. Among them are market-share leaders such as Netegrity
SiteMinder and Tivoli Access Manager (TAM). At a conceptual level most
of these products provide similar functionality. In this chapter you will
learn how to integrate both products into a WP environment. We will not
review all functions in both products”from a functional perspective all
features described are available in both products. Our choice to provide a
description using TAM or SiteMinder is somewhat arbitrary and we will
keep this discussion somewhat generic so as not to have to duplicate this
description for both products (or others in this category).


Isn™t J2EE Security Enough?
The ¬rst questions you should be asking yourself are: Why you even need to
consider additional security products? and Why are WP and its underlying
WAS platform not enough? The answers depend on your portal implemen-
tation. If you have a simple portal focused on a single function and are not
integrating many applications within the portal or are integrating only J2EE
applications developed for WAS, then you might be able to get away with
using WAS and WP security. You can use the WAS J2EE security model
to manage both authentication and authorization so long as the elements
you manage are servlets, EJBs, JSPs, Java clients, and the like. When you
also have portlets, the same model can be applied using WP security. These
models include the following:

Declarative security expressed in various deployment descriptors
managed by application assemblers or administrators, and
Programmatic security coded into the application by developers.

In addition, if you need to implement highly specialized security features
(such as dynamic roles) you need to delve deep into the underlying JAAS
layers. All of these options do not provide you with a full solution when the
protected entities are more complex, when the resources are not all running
within WP/WAS, and in some cases even when everything is completely
within WP/WAS. As an example, WAS has a different model for protect-
ing EJBs than Web applications making the administration process harder.
Access control is limited in terms of granularity”forcing you to use either
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-20 WY009-BenNatan-v1.cls May 17, 2004 18:56




Integrating Security and Identity Management Tools 387


¬ne-grained method level access control or course-grained package level
access control.
These issues have created a category of products focused on identity
and security management. With these tools you implement a better and

<<

. 64
( 87 .)



>>