WebSphere Portal Security Configuration

Transcription

1 WebSphere Portal Security Configuration Introduction Using a Login Attribute Instead of the RDN Login Using Your Attribute This guide will describe to process of using the IBM LDAP (sometimes referred to as "ED" or "Enterprise Directory", but hereafter just "") as the authentication and attributes repository for IBM WebSphere Portal version 7.0.x or 8.0.x (hereafter "Portal"). This paper is also generally applicable to any customer using Portal 7 or 8 wishing to use some other attribute in the user's LDAP record as their login ID instead of using the Portal default attribute (known as the "uid" or cn in most LDAP object classes 1 ). This paper provides a check-list to aid the system administrator when configuring the Portal to use. As mentioned above, the only real issue in using as the Portal V7/8 LDAP is the corporate direction to use a person's external ID (also know as their "IBM Intranet ID") as opposed to their LDAP "uid" which is the Portal default. In, the "uid" is your "person number" concatenated with your country code. Out of the box, Portal expects that a person logs in with their LDAP uid. For example, my uid is " " which is my person number appended with my country code ("897" for USA). So, we must configure Portal so that I can log in as "alex_lang@us.ibm.com" as opposed to " ". The process outlined herein will properly configure Portal and WAS (WebSphere Application Server) to allow login via the "mail" attribute instead of the uid attribute. For more information about, check out their web page. Overview WebSphere Portal and WCM, along with WebSphere Application Server (hereafter "WAS"), require a repository in which both authentication information as well as various user attributes are maintained. This repository also contains information about groups that users may belong to. Groups are used primarily to provide access control lists (ACLs) for various Portal resources. For most production systems, this repository would be an LDAP. However, it is possible to use other types of implementations. A common one is a database. The default repository for Portal 7/8 (at install time) is an XML file. Regardless of the repository implementation, Portal and WAS now share a common interface to that repository. This common interface is implemented by a component in WAS know as WIM or VMM. VMM is an evolution of the component known as WMM in Portal 6.0 and earlier. This paper is just a set of instructions for properly configuring VMM to use as the repository 1 Properly speaking, the uid (for Tivoli Directory Server) or cn (for Active Directory) would be known as the rdn of a user. Portal, by default, uses the rdn of a user as his default login identifier.

2 implementation for Portal/WAS and allow to login to either service via the "mail" attribute in. Planning, Prerequisites and Assumptions Prior to executing the process of connecting your Portal to, there are some actions and planning decisions that need to be made. During the installation of Portal, you are required to select a Portal/WebSphere administrator ID and administrator group ID. This user id and password are store in an XML file. This ID would normally be used from the time you install Portal until the time you change these administration ID to one that exists in the LDAP. However, in the case of a read-only LDAP, such as, that requires you to change your password often (in this case, every 90 days), having an administrator ID that only changes passwords when the administrator wants it is very benefical. This is because if an administrator password changes in the LDAP and Portal or WAS is not immediately updated to reflect that password change, recovery is tedious. Therefore this guide will assume that the Portal and WAS administrator, as initially configured, will remain in the local repositories. The configuration presented will create a federated set of repositories with normal users in the LDAP and administrators in the local file repository. Users in the LDAP can be given administration authority; but the super user will remain as initially configured at install time. This guide will assume that your Portal instance is stand-alone (e.g. not federated to a DMgr as a part of the cluster). If you wish to attached a clustered Portal to, the directions are very similar. Consult the Portal InfoCenter Wiki and make the appropriate adjustments in the procedure documented below. This guide makes no assumptions about having already executed the "transfer database" operation. This process works regardless of whether the DB has been transferred or not. Comments on User and Group IDs As mentioned above, the initial IDs that you select for the Portal/WAS Admin and the Portal Admin groups will persist beyond the connection to the LDAP. Portal/WAS 7.x, via VMM, provide a very useful feature that makes using much easier than with previous versions of Portal. The feature is known as "repository federation". This feature provides the ability to connect to 2 or more repositories and provide a federated (i.e. single) view of the collection of repositories to Portal and WAS. In this case, we will federate the default file based repository (created in the initial Portal install) with the LDAP repository. The benefit of this approach is that you can define your Portal/WAS admin ID and groups in the file based repository which means that their password never changes. When the Portal Admin ID's password changes, there is a complex set of tasks that must be executed prior to the change or Portal functionality will be compromised. As requires your password be updated every 90 days, this configuration will make Portal maintenance much easier. In this tutorial, I've used my personal rdn of when I need an actual user in the LDAP. My address for that ID is alex_lang@us.ibm.com. Note that and Bluegroups will be "read-only" to the Portal.

3 Debugging LDAP Problems Using a tool like "ldapsearch" is invaluable when trying to solve problems with an LDAP. It is included in all Linux distributions and also comes with the IBM Tivoli Directory Server product. It allows you to insure that you have the correct DN for particular entries and to verify an entry's attributes. As an example, here is an ldapsearch command for my personal DN on : ldapsearch -x -b ou=bluepages,o=ibm.com -h bluepages.ibm.com uid=" " The partial results of that command are: version: 2 # # filter: uid= # requesting: ALL # # , us, bluepages, ibm.com dn: uid= ,c=us,ou=bluepages,o=ibm.com objectclass: person objectclass: organizationalperson objectclass: ibmperson objectclass: eperson objectclass: top ou: bluepages o: ibm.com ibmserialnumber: employeecountrycode: 897 The actual record is much longer. But being able to access your record from ldapsearch will help insure that your search filters are correct. Installation Checklist 1. Following the instructions in the Portal 7/8 InfoCenter, install a fresh Portal. Note that at this point, security is enabled and the DN of the Portal and WAS admin is "uid=wpsadmin,o=defaultwimfilebasedrealm" if you chose "wpsadmin" as the administration ID on the Portal install screen. Please choose a userid and password that is non-trivial during installation. 2. If you also install the WAS Deployment manager (DMgr), make the name of the WAS administrator is the same as the one you used installing Portal. In my case, this was "wpsadmin". Note there is a well hidden instruction in the Portal InfoCenter that requires you to also create a group called "wpsadmins" via the DMgr console (prior to federation and clustering or Portal). This is done using the "Users and Groups" function found in the left hand navigator of the DMgr. 3. Insure you are able to start and log into your Portal using your chosen Portal Admin User ID. 4. Make a backup of and modify the wkplc.properties file. This file is located in the "wp_profile/configengine/properties" sub-directory. The procedure for changing the file depends on whether your Portal is stand-alone or cluster. Using the Portal InfoCenter as a guide, refer to the section entitled "Configuring WebSphere Portal to use a user registry". This can be

4 found at the Adding_an_LDAP_user_registry. Note that there are several section in the Wiki depending on which OS you are using, whether you are clustered or stand-alone as well as the type of LDAP. You will be using a "federated" LDAP set-up. The following table contains the updates to wkplc.properties file: Parameter Updated Value for IBM Comment federated.ldap.id federated.ldap.host bluepages.ibm.com federated.ldap.port 389 federated.ldap.binddn federated.ldap.bindpassword federated.ldap.ldapservertype federated.ldap.basedn federated.ldap.et.group.searchbases uid= ,c=us,ou =bluepages,o=ibm.com Your personal IBM Intranet Password IDS o=ibm.com federated.ldap.et.personaccount.objectclasses ibmperson federated.ldap.et.personaccount.searchbases ou=memberlist,ou=ibmgr oups,o=ibm.com c=us,ou=bluepages,o=ib m.com This will eventually be removed, however it is needed for the initial configuration. This is only temporary as well. This is the root of all LDAP searches in This is where group information is found in The default LDAP class for persons in is "ibmperson" This is where People are found in. Note the "c=us". This will isolate this Portal to USA users. Remove "c=us" for a world-wide Portal. federated.ldap.gc.name ibm-allgroups This will speed up group look-up information in

5 federated.realm federated.ldap.attributes.nonsupported countryname, c, viewidentifiers, identifier, changetype, parent, localityname, stateorprovincename, realm, ibm-jobtitle, groups, kerberosid, certificate, partyroles, principalname, createtimestamp, entitlementinfo, modifytimestamp, children We will name the realm associate with Blueplages to be "" These attributes exist in the LDAP but are not used by Portal federated.ldap.attributes.mapping.ldapname mail This is the LDAP Attribute federated.ldap.attributes.mapping.portalname ibm-primary This is the Portal Attribute federated.ldap.loginproperties mail This is the LDAP Attribute which will be used for login to the Portal 5. As per the Portal 7.0.x InfoCenter, execute the following tasks, in order. Do not attempt the next one if the previous one fails../configengine.sh validate-federated-ldap./configengine.sh wp-create-ldap./configengine.sh wp-update-attribute-config 6. For completeness, please consult this page: 10.lotus.com/ldd/portalwiki.nsf/dx/AIX_standalone_Adding_an_LDAP_user_registry_without_ SSL_wp7 as most everything here should be done above. 7. The previous 3 tasks should run with no error. You should get the message "Build Successful" at the end of each. If you get "Build Failed", view the complete output of the step to see the error condition. The tasks are all re-runnable if there is a failure. 8. Restart the Portal instance 9. After the restart, insure you can still login to the Portal as "wpsadmin" (or whatever your Admin UserID is). If that is successful, you should be able to logout and then log back in as your IBM Intranet userid and password.