Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows
Portal Security
- Member services
- Administration
- Authentication
- Identifying the user
- Third-party authentication servers
- Single sign-on
- Credential Vault
- Persistent connections
- Authorization
- Delegated administration
- Java 2 Security
- Secure Socket Layer
- Federal Information Processing Standards
Member services
Many environments require centralized administration of user identities, credentials, and permissions.
The WebSphere Portal Express server includes facilities for defining users and managing user access rights. The user and group subsystem includes the following:
- Web pages where users can register and manage their own account information
- Administration portlets and XML Configuration Interface for managing user accounts and group information
- A repository that stores all the information about users
It provides services to create, read, update, and delete users or groups in the repository. User profile information includes general information such as the name of the user and user ID, plus preference information such as news topics of interest, preferred language, and so on. A user might be a member of one or more groups, and groups can contain other groups.
The default set of user profile attributes is based on the inetOrgPerson schema, which is supported by most LDAP directories. The user repository might consist of multiple data sources.
By default, the repository consists of two data sources:
- Database
- Directory server
The database might be any of the databases that are supported by IBM® WebSphere® Portal Express. Any one of several LDAP directory products are supported, including,
- Sun Java System Directory Server
- Microsoft® Active Directory,
- Novell eDirectory
- IBM Lotus® Domino®,
- IBM Tivoli® Directory Server
The new concept of a Realm allows you to aggregate users from one or more user registries and expose them as a coherent user population to WebSphere Portal Express; this is also referred to as horizontal partitioning.
Realms allow a flexible user management with various configuration options; for example, you can combine principals of one or more corporate LDAP with users in a database user registry and a custom user registry. A realm must be mapped to a Virtual Portal to allow the realm's defined user population to login to the Virtual Portal.
Administration
Administrators or users (self-care) can create, delete, and modify users and groups. The server includes forms for registering new users and administration portlets for updating user and group information. You can also use the XML configuration interface to perform user management.
The registration and self-care forms can be modified to accommodate new attributes. You can add new data entry fields to the form, matching the field identifiers with the new attribute names. The enrollment process will automatically store the new data in the corresponding user attributes. This information center includes more information about customizing the implementation of the user repository, registration and self-care pages, and data validation classes.
Authentication
Authentication is the process of establishing the identity of a user. Usually, the server uses the authentication services that are provided by IBM WebSphere Application Server.
Another option is to use a third-party authentication server (such as IBM Tivoli Access Manager for e-business, WebSeal, or Computer Associates eTrust SiteMinder) that has a trusted association with the application server.
The underlying application server implements the JAAS architecture. JAAS provides a way to authenticate subjects and provides fine-grained access control. JAAS is part of the standard Java security model; it provides applications independence from underlying authentication and authorization mechanisms. JAAS performs login and logout operations using a modular service provider interface. Credentials that are established through the server JAAS login modules include user and group distinguished names, user ID and password, and single sign-on tokens like LTPA.
In a distributed J2EE environment, portlets can use the JAAS API to access JAAS-enabled back-end applications.
Identifying the user
WebSphere Portal Express uses form-based authentication. Form-based authentication means that a user is prompted through an HTML form for the user ID and password for authentication when trying to access WebSphere Portal Express.
The server requests the application server to validate the authentication information against an LDAP user registry.
WebSphere Application Server uses LTPA as the authentication mechanism. When a user tries to access a protected resource, the application server intercepts the request and redirects the request to the login form. This form posts the user ID and password that requests the application server to authenticate the user. If the user can be authenticated, a valid credential is created and an LTPA cookie is stored on the user's machine.
Third-party authentication servers
If your system uses another third-party authentication server, trust needs to be established between that proxy and WebSphere Application Server.
Trust can be established using a Trust Association Interceptor (TAI) module, which converts security information that is specific to the authentication proxy into a format that can be handled by the application server. The supported authentication mechanism depends on the capabilities of the third-party product.
When a user tries to access WebSphere Portal Express, the third-party authentication proxy intercepts the request and challenges the user to authenticate. After a successful login, the original user request, along with additional security information in the request header, is passed to the application server. The format and content of this information are vendor specific. WebSphere Application Server uses the TAI module (that is specific to the third-party product) to extract the necessary security information from the request header.
The TAI module for Tivoli Access Manager is packaged with the base WebSphere Application Server.
The TAI module for eTrust SiteMinder is available from the Computer Associates Web site. The WebSphere Application Server information center includes information about creating custom TAI modules for other third-party reverse proxy servers.
Single sign-on
The server provides comprehensive single sign-on (SSO) support. Users want to be able to log in only once and be known to the different parts of the WebSphere Portal Express server with the same consistent user credentials. Users should not be asked to do multiple logins simply because they access different applications.
The server supports single sign-on realms using WebSphere Application Server and authentication proxies. This means that the user needs to log in only once to gain access to all enterprise applications that are installed within the single sign-on realm.
WebSphere Application Server uses credentials and single sign-on tokens like LTPA to provide single sign-on.
When a user is authenticated, the server creates a single sign-on cookie (the default is an LTPA token) containing the authenticated user credential. This encrypted cookie conforms to the format that is used by WebSphere Application Server and can be decrypted by all application servers in the shared domain, provided they all have the same cipher key. This cookie enables all servers in the cluster to access the user credentials without additional prompting, resulting in a seamless single sign-on experience for the user. To benefit from the single sign-on cookie method, the user's browser must support cookies and have cookies enabled.
Credential Vault
Many portlets need to access remote applications that require some form of user authentication.
For accessing applications outside the realm, server provides a credential vault service that portlets can use to store user ID and password (or other credentials) for a user login to an application. Portlets can use these on behalf of the user to access remote systems. The credential vault supports either local database storage or Tivoli Access Manager for secure storage and retrieval of credentials. Portlets obtain credentials by obtaining a CredentialVaultPortletService object and calling its getCredential method. With the returned credential, two options exist:
- Use passwords or keys from a passive credential, passing them in application-specific calls. Portlets that use passive credentials need to extract the secret out of the credential and do all the authentication communication with the back-end application.
- Call the authenticate method of an active credential. Active credential objects hide the credential secret from the portlet, with no way to extract it out of the credential. Active credentials provide additional methods to perform the authentication.
The latter case allows portlets to trigger authentication to remote servers using basic authorization, Secure Socket Layer (SSL) client authentication, digest authentication, or LTPA without knowing the credential values. Using active credentials means that WebSphere Portal Express authenticates on behalf of the portlet, and the portlet can simply use the open connection.
While this might not be possible for all cases, it is the preferred technique.
For secure transmission of data, portlets can request a secure session (HTTPS) for accessing Web applications.
Persistent connections
Portlets that depend on remote connections require some way of maintaining that connection as users navigate through WebSphere Portal Express. WebSphere Portal Express provides a persistent back-end connection service that maintains TCP/IP connections across page changes. Some remote applications use forms-based logins and store cookies during the login form processing. The HttpFormBasedAuthCredential, in the Credential Vault, can be used to handle these form-based logins and will store all the cookies that are returned as a result. For subsequent calls, the portlet can then ask the credential for an authenticated connection.
This provides an HTTP connection with these cookies already set in the header.
This way, portlets can maintain persistent, secure back-end connections.
Authorization
After determining the identity of the user, the server consults the Access Control component to determine what resources (for example, pages and portlets) a user has permission to access. The Access Control component stores the information in the WebSphere Portal Express database by default. Use the User Group Permissions and Resource Permissions portlets as well as the XML Configuration Interface and Portal Scripting Interface to manage the access control settings.
The server enforces access control to assets, including portlets, pages, and user groups. You can also manage access control for specific resources in an external security manager, such as Tivoli Access Manager or eTrust SiteMinder.
WebSphere Portal Express uses a role-based approach to manage user authorization for accessing resources. A role combines a set of permissions with a specific resource. This set of permissions is called a role type. By assigning the role to a user or a group, the user or users in the group are assigned permissions on the resource. WebSphere Portal Express resources are part of a hierarchy (for example, a page can contain other pages or a folder that contains other folders or documents). Each resource in the hierarchy inherits the role assignments of its parent resource unless a role block exists.
This inheritance reduces the administration overhead. When you assign a user or a group the user is a member of to a role on a parent resource, the user automatically acquires that same role for all child resources.
The following role types exist:
- User: Can view resources
- Privilege User: Can view resources, personalized portlets, and pages and can create new private pages
- Editor: Can create new resources and configure existing resources that are used by multiple users
- Manager: Can create new resources, configure existing resources that are used by multiple users, and delete a resource
- Delegator and Security Administrator: Required for modifying the access control configuration
- Administrator: Contains all permissions
Delegated administration
WebSphere Portal Express supports delegated access control administration. An administrator is a user who is authorized to modify the access control configuration by changing role assignments and creating or deleting role blocks. Administrators can delegate specific subsets of their administrative privileges to other users or groups. These users or groups can in turn delegate subsets of their privileges to additional users and groups.
Java 2 Security
Java 2 (J2SE)™ security provides a policy-based, fine-grain access control mechanism that increases overall system integrity by checking for permissions before allowing access to certain protected system resources. J2SE security allows you to set up individual policy files that control the privileges assigned to individual code sources.
If the code does not have the required permissions and still tries to execute a protected operation, a corresponding security exception will be thrown by the Java Access Controller. WebSphere Portal Express supports an enabled Java 2 Security although by default it is disabled. By enabling it, you can increase the server's security by only allowing certain operations in the policy files for your applications like portlets.
Secure Socket Layer
Configuring WebSphere Portal Express for SSL adds security to the client-portal exchange. It encrypts all traffic between the client browser and the server so no one can eavesdrop on the information that is exchanged over the network between the client browser and WebSphere Portal Express.
In addition, assuming that the WebSphere Application Server on which WebSphere Portal Express 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 National Institute of Standards and Technology (NIST) for federal 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 Express provides support for FIPS 140-2 through WebSphere Application Server. WebSphere Application Server integrates cryptographic modules including Java Secure Socket Extension (JSSE) and Java Cryptography Extension (JCE), which are undergoing FIPS 140-2 certification. Throughout the documentation and the product, the IBM JSSE and JCE modules undergoing FIPS certification are referred to as IBMJSSEFIPS and IBMJCEFIPS, which distinguishes the FIPS modules from the IBM JSSE and IBM JCE modules.