Lotus Domino and WebSphere Portal are a perfect combination for creating collaborative e-business environments. But, as with any collaborative application or portal that enables access to corporate data over the Internet, security considerations becomes a serious concern.
There are many guidelines for creating a more secure WebSphere Domino system, available in documentation on the IBM Web site. The most recent IBM Redbook on the topic, WebSphere Portal Collaboration Security Handbook, offers advice on implementing three major security requirements specifically for a WebSphere Portal server connecting to Lotus Team Workplace and Lotus Instant Messaging and Web Conferencing.
To prevent sensitive data from being intercepted as it travels over the wire, traffic must be encrypted. Secure Sockets Layer (SSL) has become the most common method for creating an encrypted connection between client and server, and for authenticating both the server and client machines.
There are three communication protocols between the WebSphere Portal Collaborative Services and back-end Lotus Domino servers that need to be configured for SSL: HTTP, DIIOP and LDAP. Both Domino and WebSphere Portal must be configured for SSL.
Obviously, you want to know that only authorized people are accessing your systems. Standard authentication methods include user ID and password, SSL certificates exchanged between client and server, and a user's listing in a corporate directory using LDAP, the industry standard for Internet and intranet-based directories.
SSL in Domino products can be implemented via signed certificates from a certificate authority such as VeriSign. To enable SSL in WebSphere Portal, you have to configure SSL for the IBM HTTP server, as well as the WebSphere Application Server plug-in for the Web server, and, finally the WebSphere Portal (as described in the IBM Redbook Chapter 5.4.1 to 5.4.3). SSL also must be enabled for the LDAP connections in WebSphere.
There are additional authentication mechanisms that WebSphere uses. The Lightweight Third Party Authentication (LTPA) token, for example, enables secure communication between Portal and Lotus collaborative applications.
When a user logs on to the Portal to access a Lotus application, the LDAP directory server creates an LTPA token that resides on the user's Web browser as a session cookie that can be passed to, and read by, multiple back-end Domino servers.
WebSphere has additional authentication tools, including the Credential Vault for use by portlets that need to access back-end system. The Credential Vault provides a place for portlets to access user credentials such as password and SSL certificate after the user has logged on, providing single sign-on for the user.
Not every user should have access to every resource or function. Good security requires that different user groups be granted different levels of access to corporate systems. WebSphere Application Server accomplishes this via the J2EE security mechanisms, which include security roles.
Developers can create generic security roles for various departments or types of employees, and provide those roles with access to the specific resources and functions they require. For instance, accounting and human resources employees may be given the ability to run a payroll query, whereas the marketing group cannot. Generic roles can then be mapped to actual users later.
Another option is to use IBM's Tivoli Access Manager, which can provide front-end authentication and authorization for the Web server. The Access Manager provides additional security for the Web and application servers by using a reverse proxy in the DMZ, outside the firewall, to receive traffic from the Internet and forward them to the Access Manager for authentication and authorization.
About the author: Sue Hildreth is a freelance technology writer based in Waltham, MA. She can be reached at Sue.Hildreth@comcast.net.
Do you have comments on this tip? Let us know.
Related information from SearchDomino.com: