IBM BS029ML Self Help Guide - Page 51

2.6 Security Security within the enterprise has become increasingly more important and complex as distributed systems and Internet technology have merged. The issue can hardly be ignored, as security breaches are announced in the news on a daily basis. While security is becoming increasingly more complex, technology has also provided us with better ways to implement and maintain security within an organization. 2.6.1 WebSphere Portal Server security WebSphere Portal Server leverages the underlying security mechanisms of WebSphere Application Server for authenticating users. That is, when a user logs into the Portal, it is actually the underlying WebSphere Application Server that performs the authentication task (assuming that no Reverse Authenticating Proxy Server, such as Tivoli WebSEAL or CA SiteMinder are being used). WebSphere Portal Server then goes on to retrieve the security context from WebSphere Application Server and processes the login. Then, the integrated WebSphere Member Manager component of WebSphere Portal Server must perform an additional LDAP query to retrieve a further number of user attributes and to determine the group membership for the concerned user. Successfully authenticated users also receive a Lightweight Third-Party Authentication (LTPA) token, containing a delegable credential in the form of an encrypted transient cookie, from the underlying WebSphere Application Server instance. This cookie is only valid for the duration of a user's browser session and is used by way of the embedded LTPA token, to honor subsequent requests which would otherwise require re-authentication. However, the LTPA token is in itself subject to expiry even if a user's browser session is maintained. The LTPA token effectively starts to time out immediately upon creation. WebSphere Portal Server also includes all the functionality for controlling access to resources based on a number of predefined roles. This involves the process of both determining if the identified requester has permission to access the requested resource and the ability to make fine-grained authorization decisions. 2.6.2 Using External Security Managers Although not a mandatory requirement for a WebSphere Portal Server solution, the use of an External Security Manager remains a fully supported option. In most cases, the decision to include such a component is based not only on the security of the immediate system, but on the value of deploying an "enterprise wide" calibre security solution. WebSphere Portal Server and the underlying WebSphere Application Server are secure in their own right and benefit less than one might expect from an External Security Manager. However, when many systems are consolidated within an organization, enterprise security adds significant value. A maximum security policy would, however, dictate that additional security software adds to a solution by providing another layer that must be cracked; if not for anything else, then for fending off DoS (Denial of Service) attacks. The implications of not architecting an External Security Manager, such as Tivoli Access Manager (TAM), should be fully understood. Most notably, without TAM, WebSphere Portal Server user accounts cannot be automatically locked after a certain number of invalid password attempts (three times) and concurrent logins using the same user account cannot be prevented. Unless, that is, a custom coding effort is undertaken to develop a Custom User Registry (CUR) for fulfilling such a purpose. Chapter 2. Architecture and planning 37