WebSphere Portal Security
Contents
- Overview
- 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
Overview
Security is Authentication, Access Control, Auditability, Confidentiality. WP Security focuses in the following areas:
- Authentication: Login; Id & Password validation; Who are you?
- Single Sign On: Only login once, access many applications
- Authorization: What are you allowed to see and do?
- Audit: Who did or tried to do what at which time?
WP leverages WebSphere Application Server authentication & SSO
- WAS security must be active in production setups.
- Authentication process can be customized (JAAS, WP Login Actions)
- WAS & Portal require a user registry, w/LDAP the easiest
WP leverages inbound SSL/TLS support provided by WebSphere Application Server (or HTTP Server, really)
WP does its own access control on portal resources for its instance-level authorization
WP supports Java 2 Security to be enabled (New with V 5.1)
WP features protection of WSRP connections through WebSphere Application Server WS-Security support
WP allows audit of certain security events (New with V 5.1.0.1)
Portal integrates with authentication proxies, authorization systems, and credential vaults to provide single sign-on access to multiple types of applications, resources, and content.
In general, HTTP requests for pages pass through an authentication component, such as IBM WAS Security, TAM, or third-party security products such as Netegrity SiteMinder. Once authenticated, the request is routed to a portal servlet, which calls the authorization component to determine whether access can be granted. For the most part, authorization is maintained within the portal, but for some resources, access control can be externalized to systems such as TAM or SiteMinder.
If access to a page is granted, the portal system next determines access rights to the subset of portlets referenced on the page and then, based on that determination, uses an aggregation module to render the page by calling the referenced portlets using the Portlet API, enriching the request information with user profile information from the Member Services component and with portlet instance data from the Portal data store.
WAS and Portal Authentication Flow
WAS and Portal and TAI Authentication Flow
Portlets are special servlets which, unlike other servlets, participate in the portal's event model and exploit the portal infrastructure.
To support SSO, WebSphere Portal provides a Credential Vault portlet service, which portlets use to obtain and forward credentials to back-end systems, transparently authenticating the user. The credential vault service is backed by a credential vault, which can either be the portal's built-in vault or TAM's secure vault.
Member services
The portal server includes...
- 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
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 server
- 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 Sun ONE Directory Server, Microsoft Active Directory, Novell eDirectory, Lotus Domino, and IBM Tivoli Directory Server.
Realms allow you to aggregate users from one or more user registries and expose them as a coherent user population to WebSphere Portal; this is also referred to as horizontal partitioning. 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
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. You can also use the XML configuration interface to perform user management.
The registration and self-care forms can be 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 process 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 WAS. 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 appserver.
WP is a custom Form Login application to WAS, and relies on WAS to provide the security context including user identity. WAS either does the authentication, or accepts assertion via TAI. Mutually authenticated SSL is also supported
WP, ike all Form apps, depends on WAS LTPA Token functionality. Cookies must be accepted and returned by the browser (or a proxy). WP works with Authentication Proxies and WAS Trust Association Interceptors
- Tivoli Access Manager, WebSEAL
- Netegrity SiteMinder
- RSA ClearTrust
- Entrust GetAccess
The underlying appserver 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 Application Programming Interface (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 appserver 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 appserver 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.
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 appserver. 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 appserver. 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.
TAI modules for Tivoli Access Manager and Netegrity SiteMinder are packaged with the portal server (all editions). 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 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 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 signon 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 appservers 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, 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. You can also manage access control for specific resources in an external security manager, such as Tivoli Access Manager or Netegrity 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 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 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 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 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.
See Set up SSL for more information.
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 v5.0.2. WAS integrates cryptographic modules including JSSE and 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.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.