Security

This topic highlights some of the security features that applications and portal administrators can exploit to better protect the valuable information of the portal assets.

 

Member services

Centralized administration of user identities, credentials, and permissions is desirable in many environments. The portal server includes facilities for defining portal users and managing user access rights. The user and group subsystem includes Web pages where users can register and manage their own account information, administration portlets for managing user accounts and group information, plus a repository that stores all the information about portal 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: it is a combination of a database and a directory server. The database might be any of the databases that are supported by WebSphere Portal. Any one of several LDAP directory products are supported, including the Netscape (iPlanet) Directory Server, Microsoft Active Directory, Novell eDirectory, Lotus Domino, and IBM Directory Server.

The mapping of user profile attributes to LDAP object classes is defined using in the file wms.xml. This file specifies the names of the various data repositories and how they are navigated to retrieve user and group information. These settings are configured differently for each supported LDAP directory; if you want to try using a directory that is not supported, these values would need to be set appropriately for that directory server.

The file attributeMap.xml specifies the details of how each attribute is mapped to the LDAP directory or database. This mapping file also includes metadata about each attribute such as its data type, whether it is required, whether it can have multiple values, and so on.

 

Administration

Administration of users and groups can be performed by users themselves ("self care") or by portal administrators. The portal server includes forms for registering new users and administration portlets for updating user and group information.

The registration and self-care forms are easily 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 servlet will automatically store the new data in the corresponding user attributes. The WebSphere Portal 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 portal server uses the authentication services that are provided by WebSphere Application Server. Another option is to use a third-party authentication server (such as Tivoli Access Manager, WebSeal, or Netegrity SiteMinder) that has a trusted association with the application server.

 

Identifying the User

WebSphere Portal 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 the portal. The portal server requests the application server to validate the authentication information against a Lightweight Directory Access Protocol (LDAP) user registry.

WAS uses Lightweight Third Party Authentication (LTPA) as the authentication mechanism. A Common Object Request Broker Architecture (CORBA) credential is used to represent authenticated users and their group memberships. 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 to the portal that requests the application server to authenticate the user. If the user can be authenticated, a valid CORBA credential is created and an LTPA cookie is stored on the user's machine.

 

Third-party Authentication Servers

If the system uses another third-party authentication server, trust needs to be established between that proxy and WAS. This is done 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 the portal, 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 is vendor specific. WAS uses the TAI module (that is specific to the third-party product) to extract the necessary security information from the request header.

TAI modules for IBM Tivoli Access Manager and Netegrity SiteMinder are packaged with the portal server (all editions). The WAS InfoCenter includes information about creating custom TAI modules for other third-party reverse proxy servers.

 

Single Sign-On

The portal server provides comprehensive single signon (SSO) support. Users want to be able to log on only once, and be known to the different parts of the portal server with the same consistent user credentials. Users should not be asked to do multiple logons simply because they access
different portal applications.

The portal server supports single signon realms using WebSphere Application Server and authentication proxies. This means that the user needs to log on only once to gain access to all enterprise applications that are installed within the single signon realm.

The WAS uses Lightweight Third Party Authentication (LTPA) tokens to provide single signon. When a user is authenticated, the portal server creates an LTPA single signon cookie 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 signon experience for the user. To benefit from the LTPA method of single signon, the browser of the user must support cookies and have its support for session cookies enabled.

 

Credential Vault

Many portlets need to access remote applications that require some form of user authentication. For accessing applications outside the portal realm, portal 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 IBM 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, there are two options:

  1. 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.

  2. 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, SSL client authentication, digest authentication, or LTPA without knowing the credential values. Using active credentials means that the portal 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 the portal. The portal 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 HttpFormBasedCredential can be used for handling 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 gives an HTTP connection with these cookies already set in the header. This way, portlets can maintain persistent, secure back-end connections.

 

Java Security

The portal server implements the Java Authentication and Authorization Service (JAAS) architecture. JAAS provides a means for authenticating subjects and for providing fine-grained access control. JAAS is part of the standard Java security model; it gives applications independence from the underlying authentication and authorization mechanisms that are being used. JAAS performs login and logout operations using a modular service provider interface. Credentials that are established through the portal server JAAS login modules include CORBA credentials, user and group distinguished names, user ID and password, and LTPA tokens. In a distributed J2EE environment, portlets can use the JAAS API to access JAAS-enabled back-end applications.

 

Authorization

After determining the identity of the user, the portal server consults locally cached access control lists to determine which pages and portlets a user has permission to access.

The portal server enforces access control to portal assets, including portlets, pages, and user groups. The access control lists are stored in the portal administration database. It is also possible to manage access control for specific resources in an external security manager, such as IBM Tivoli Access Manager or Netegrity SiteMinder.

Access permissions are maintained using the Access Control administration portlet. Use this portlet to assign roles to individual users or to groups of users for specific portlets, pages, or documents. Roles are permission sets, such as the ability to view and update the corresponding item. Users can also delegate the permissions they hold to other users. When a role is assigned to a user or a group on a container (such as a page that contains portlets or other pages, or a folder that contains other folders or documents), that role is inherited downward through the hierarchy unless it is specifically blocked. This makes managing access within a document library or an area of the portal easy.

Granting view access to a page or place means that other users will see pages and places when they log in. Granting view access to a portlet means that users can add it to their pages when they customize their portal experience. Granting edit access means that a user can set the portlet settings or change the contents of a page. Manage access means that a user can perform view and edit operations, and can delete the portlet or page.

 

Delegated Administration

Granting view access to administration portlets is an effective way of delegating certain administrative tasks to other portal users. Those users can add the administration portlets to their personal pages, and then can perform whatever task the portlet is designed to do. This way, the user does not have to be given all administrative privileges or added to the portal administrator group. Their administrative abilities are limited to only those tasks that are covered by the authorized portlets.

 

See also