WebSphere Portal v6 Security Planning
Authentication
Authentication allows users identify themselves to gain access to the portal. User ID/password challenges are the most common method of identifying a user. After a user has been authenticated, the system can determine if that user is authorized to access the resources that are requested.
WebSphere Portal does not support simultaneous, multiple logins using the same login id.
WebSphere Portal is a custom Form Login application to WAS and relies on WAS to...
- Intercept requests to protected portal area
- Do the authentication
- Provide the security context
Global Security in WAS is active. Portal picks up whatever user identity established by WAS. All WAS authentication customization options also apply to portal:
- Authentication Proxies and Trust Association Interceptors (e.g. TAM / WebSeal)
- Custom JAAS Login Modules
User registries and repositories
IBM WAS and IBM WebSphere Portal support three types of user registries:
- LDAP
- Custom
- Database
If security is enabled, WebSphere Portal shares the same authentication registry as WAS. Except in very rare circumstances, WAS and WP should always use the same user registry
A user registry and a user repository can be based on the same underlying datastore. For example, an LDAP directory typically contains user ID and password information but can also store additional profile information such as e-mail addresses and telephone numbers of users. Therefore, the LDAP directory is both a user registry and a user repository.
Supported LDAPs
We can use one of the following software products as an LDAP directory to store user information.
LDAP server Notes IBM Tivoli Directory Server V6.0 Add APAR IO002714 6.0.0.1-TIV-ITDS-IF0001 IBM Tivoli Directory Server V5.2 For 5.2.0.3-TIV-ITDS-IF0001 or earlier, add APAR IO02697. This will update Tivoli Directory Server to Fix Pack 3 For 5.2.0.3-TIV-ITDS-IF0007, add APAR IO02697
For 5.2.0.3-TIV-ITDS-LA0011, add APAR IO02697.
SuSE SLES for S/390 8 is not supported.
IBM Lotus Domino 7.0.1 Apply SPR KLIN6LRTHJ to be able to return Groups and Users by direct lookup IBM Lotus Domino 6.5.5 Apply SPR LORN6FKK9Q to make Group Lookup full functional BM Lotus Domino 6.5.4 Apply SPR LORN6FKK9Q to make Group Lookup full functional Novell eDirectory 8.7.3
Sun Java System Directory Server V5.2
Microsoft Active Directory 2003
Microsoft Active Directory 2000 Microsoft Active Directory Application Mode (ADAM) 2003 Using an LDAP server is optional for WebSphere Portal.
Not all LDAP servers that are listed run on all operating systems supported by WebSphere Portal. The LDAP server provided with WebSphere Portal runs on all the operating systems that are supported by WebSphere Portal.
If you intend to use Domino Extended Products, such as...
- IBM Lotus QuickPlace
- IBM Lotus Sametime
...the IBM Domino Enterprise Server LDAP directory is recommended.
We can install the LDAP server on an operating system that is different than the operating system on the portal machine.
Support for LDAP servers spans two categories:
- Fully tested and supported LDAP servers:
The list of fully tested LDAP servers for each release of WebSphere Portal is documented in the information center and in the Supported Hardware and Software document for each release.
WebSphere Portal support accepts problem reports for the appropriate WebSphere Portal releases using the tested directory servers. These problem reports receive high-priority attention. Features that are tested with these directories include relatively simple search and retrieval functions for user and group objects.
Functions outside this scope, such as...
- dynamic groups
- referrals
- Active Directory Global Catalog
...are considered advanced features and have not been tested with WebSphere Portal.
- Untested and partially supported LDAP servers:
In general, WebSphere Portal support makes a best effort to support directory servers that have not been tested with WebSphere Portal. WebSphere Portal support accepts problem reports for the appropriate WebSphere Portal releases using untested directory servers.
If WebSphere Portal support can recreate the reported problem using a tested LDAP server, staff will attempt to fix the problem.
If the support team is not able to recreate the problem on a tested LDAP server, customers are referred to the LDAP provider for further assistance.
Realm support
A Realm allows one to group users from one or more LDAP trees and expose them as a coherent user population to a WebSphere Portal virtual portal. This is also referred to as horizontal partitioning.
A realm must be mapped to a Virtual Portal to allow the realm's defined user population to login to the Virtual Portal.
Realm membership is validated during authentication to ensure that a virtual portal can only be accessed by members of the corresponding realm. Users from one realm cannot access another realm unless they are also members of that group. For example, a wpsadmin will not be able to log in to a virtual portal unless the wpsadmin is a member of the corresponding realm.
Multiple virtual portals can share the same user population by specifying the same realm relationship.
Realms can overlap, which allows users to be members of more than one realm.
Application groups
Application groups are user groups within a database user registry with members (users or groups) contained in the LDAP user registry. We can create application groups that are only used in IBM WebSphere Portal.
We can use application groups in the following scenarios:
- Read-only LDAP
- If you have a read-only LDAP, we cannot change the group membership of users and groups. If we need to define access rights for certain users that are in different groups, we can create an Application group for these users with the required access rights.
- Special group setup for WebSphere Portal
- In this scenario we need to setup a special group hierarchy that is only used by WebSphere Portal and not by other applications that access the LDAP. This can help us apply special access control rules just for WebSphere Portal as the roles apply to all members of the group as well.
Application groups only apply to WebSphere Portal; it does not apply to external security managers.
Single sign-on
The goal of Single sign-on 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 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 backend applications.
SSL
Configuring WebSphere Portal for SSL adds security to the client-portal exchange. It encrypts all traffic between the client browser and the portal server, so that no one can "eavesdrop" on the information that is exchanged over the network between the client browser and the portal. In addition, assuming that the WAS on which portal is running is also configured to accept (or even require) SSL connections, the LTPA Token and other security and session information can be completely protected against hijack and replay attacks.
Federal Information Processing Standards
Federal Information Processing Standards (FIPS) are standards and guidelines issued by the United States National Institute of Standards and Technology (NIST) for federal government computer systems. FIPS are developed when there are compelling federal government requirements for standards, such as for security and interoperability, but acceptable industry standards or solutions do not exist.
WebSphere Portal provides toleration for WAS 's support of FIPS 140-2. WAS V6.0 and later integrates cryptographic modules such as...
...which are FIPS 140-2 certified.
Throughout the documentation and the product, the FIPS 140-2 certified IBM JSSE and JCE modules are referred to as IBM JSSEFIPS and IBM JCEFIPS, which distinguishes the FIPS-certified modules from the prior, non-certified IBM JSSE and IBM JCE modules.
Parent topic:
Configuring security