IBM BS029ML - WebSphere Portal Server, Self Help Manual

Page: 114 / 242

100
IBM WebSphere Portal V6 Self Help Guide
You can extend an existing standard LDAP objectclass such as inetOrgPerson to incorporate
the new attributes. This must be done using the LDAP server utility and in the LDAP server. In
the WebSphere Member Manager (WMM), you need to add this new objectclass for read or
write objectclasses in wmm.xml. For example, assume the new objectclass you defined is
called acmePerson. This objectclass should be added in wmm.xml, as shown in Example 4-1.
Example 4-1 Customized objectclass acmePerson added in wmm.xml
<supportedLdapEntryType name="Person"
rdnAttrTypes="uid"
objectClassesForRead="inetOrgPerson;
acmePerson "
objectClassesForWrite="inetOrgPerson; acmePerson "
searchBases="ou=people,ou=dept,o=acme.com"/>
The attributes introduced in this customized objectclass should be added to both
wmmAttributes.xml and wmmLDAPServerAttributes.xml.
You can also use the LookAside repository provided by WMM, with the understanding that the
LDAP server is read-only or that extending an objectclass is not feasible. To enable
LookAside, we recommend that you set “LookAside” to true in wpconfig.properties when
enabling security configuration. We also recommend that you add the new attributes into
wmmLAAttributes.xml and wmmAttributes.xml before running the security configuration task.
If you are not able to decide what attributes to add before enabling security, then you can add
the attributes to LookAside DB tables later using the utility “attributeloader” provided by
WMM. The process was documented in TechNote 1225316, which can be searched for at:
http://www-306.ibm.com/software/genservers/portal/support/
4.2.5 Integration with Tivoli Access Manager (TAM)
The most common configuration of the integration is for the portal to take advantage of TAM’s
centralized security infrastructure, use WebSEAL as its reverse proxy, and leverage the Trust
Association mechanism provided by the WebSphere Application Server. WebSphere Portal
has designed a set of configuration tasks to configure portal servers for authentication,
authorization, and vault adapter.
In order to integrate WebSphere Portal with Tivoli Access Manager and WebSEAL, you must
first configure the portal security with native WebSphere Application Server, and verify that it
is working correctly with its single sign-on mechanism.
The portal configuration tasks for TAM integration are enable-tam-all, enable-tam-tai,
enable-tam-authorization, and action-esm-tam-update-vaultservice. enable-tam-all is simply
a combination of the other three sub-tasks. These tasks are designed to work under general
configurations, and to provide a convenient interface for customers to use. If special
treatments are required, manual steps should be taken after running them.
Before the portal server can talk to the TAM Java Runtime (AMJRTE), certain conditions must
be set by the configuration task run-svrssl-config, which runs two PDadmin utilities PDJrteCfg
and SvrSslCfg sequentially. This task creates a user account and server entries that
represent the WebSphere Portal, and in addition, the file PdPerm.properties and a Java key
store file are created locally under the Java runtime directory on the portal server box. This
Important: WebSphere Portal security must be configured and tested correctly before
configuring TAM or any other external security managers.