Security

 

+
Search Tips   |   Advanced Search

 

  1. Member services
  2. Administration
  3. Authentication
  4. Identifying the user
  5. Third-party authentication servers
  6. Single sign-on
  7. Credential Vault
  8. Persistent connections
  9. Authorization
  10. Delegated administration
  11. Java 2 Security
  12. Secure Socket Layer
  13. Federal Information Processing Standards

 

Member services

The portal server includes facilities for defining portal 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 portal users

WebSphere Portal provides services to manipulate 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.

The following LDAP directories are supported...

 

Realms

Realms allow aggregation of users from one or more user registries and expose them as a coherent user population to WebSphere Portal (horizontal partitioning).

Realms allow one to 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

Portal administrators or users (self-care) can create, delete, and modify users and groups. The portal server includes forms for registering new users and administration portlets for updating user and group information. We can also use the XML configuration interface to perform user management.

The registration and self-care forms can be modified to accommodate new attributes. We 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 portal server uses the authentication services that are provided by IBM WAS. 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 Java Authentication and Authorization Service (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 portal server JAAS login modules include user and group distinguished names, user ID and password, and single sign-on tokens like Lightweight Third Party Authentication (LTPA). In a distributed J2EE environment, portlets can use the JAAS API to access JAAS-enabled back-end applications.

 

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 an LDAP user registry.

WAS 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 to the portal 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.

Starting with WebSphere Portal version 5.1, the form can either be a portlet (default) or a screen. The portlet can be customized per Virtual Portal.

 

Third-party authentication servers

If your system uses another third-party authentication server, trust needs to be established between that proxy and WAS. 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 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 are 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.

The TAI module for Tivoli Access Manager is packaged with the base WAS. The TAI module for eTrust SiteMinder is available from the Computer Associates Web site. The WAS information center includes information about creating custom TAI modules for other third-party reverse proxy servers.

 

Single sign-on

The portal server provides single sign-on support. Users want to be able to log in 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 logins simply because they access different portal applications.

The portal server supports single sign-on realms using WAS 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.

WAS uses credentials and single sign-on tokens like LTPA to provide single sign-on. When a user is authenticated, the portal 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 WAS 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 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 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 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 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 portal server consults the Portal Access Control component to determine what resources (for example, pages and portlets) a user has permission to access. The Portal Access Control component stores the information in the WebSphere Portal 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 portal server enforces access control to portal assets, including portlets, pages, and user groups. We can also manage access control for specific resources in an external security manager, such as Tivoli Access Manager or eTrust SiteMinder.

WebSphere Portal uses a role-based approach to manage user authorization for accessing portal resources. A role combines a set of permissions with a specific WebSphere Portal 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 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
Privileged 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 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 security (J2SE) 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 supports an enabled Java 2 Security although by default it is disabled. By enabling it, we can increase the server's security by only allowing certain operations in the policy files for the applications like portlets.

 

Secure Socket Layer

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 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 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 provides support for FIPS 140-2 through WAS. WAS 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 IBM JSSEFIPS and IBM JCEFIPS, which distinguishes the FIPS modules from the IBM JSSE and IBM JCE modules.

 

Parent topic:

Key features