IBM BS029ML Self Help Guide - Page 104

For accessing the user profile and group information, WMM provides the Custom Member Repository (CMR) module. The two classes are: com.ibm.websphere.wmm.registry.WMMUserRegistry (CUR) com.ibm.ws.wmm.db.DatabaseRepository (CMR) and can be respectively found in the WebSphere Application Server security configuration and WMM configuration (wmm.xml). When a customer user registry (CUR) is developed by the customer, a corresponding custom member repository (CMR) must be coded for configuring WMM. The CMR API is private and unpublished. To obtain this API, IBM support must be contacted and an non-disclosure agreement must be signed. The security of an out-of-box installation of WebSphere Portal Version 6 is enabled with the WMMUR DB option based on the embedded version of IBM Cloudscape Database. The idea is for the administrator to have a working system right after the installation. This configuration is suitable to a system for a fairly small scale experimental environment, like individual development or unit testing. In general, it is not recommended for a production environment. If the system will be put into production, the future growth and performance impact should warrant a better enterprise solution, based on a commercial database system and a directory server. Attention: We do not recommend the default out-of-box database configuration in a production environment, mainly for performance and management considerations. 4.1.4 Single sign-on (SSO) The power of WebSphere Portal is its capability of integrating and aggregating the applications running on the server and other enterprise information systems to present a single user interface. In most cases, the back-end enterprise applications require their own authentication and authorization to the users. Most implementations of the portal solution avoid the requirement of repeating authentication of the users. This is where SSO comes into play. The goal of single sign-on is to provide a secure method of authenticating a user one time within an environment and using that single authentication (for the duration of the session) as a basis for access to other applications, systems, and networks. In the context of IBM WebSphere Portal, there are two single sign-on realms: the realm from the client to portal and other Web applications and the realm from the portal to the back-end applications. WebSphere Application Server adopted an authentication mechanism called the Lightweight Third Party Authentication (LTPA) for single sign-on support. The LTPA protocol is intended to work in a distributed environment through cryptography. This support permits LTPA to encrypt, digitally sign, and securely transmit authentication-related data, and later decrypt and verify the signature. The LTPA protocol uses cryptographic keys to encrypt and decrypt user data that passes between servers. These keys must be shared between the different servers. The participant servers of the LTPA SSO must be configured to use the same LDAP or custom user registry. With LTPA enabled, a token is created with the user information and an expiration time, and it is signed by the keys. The LTPA token is time sensitive. All servers that participate in the single sign-on must have their time, date, and time zone synchronized. The LTPA token is passed in the HTTP header as a cookie, called LtpaToken. At the receiving end, the token is decrypted to obtain the user information. Due to the nature of sharing keys, it is important to guard the key files and WebSphere Application Server configuration files. 90 IBM WebSphere Portal V6 Self Help Guide