Enterprise application integration (EAI) is a prime objective driving the decision to implement a portal. Portals are often used to integrate data and applications from remote systems and present them in a unified manner to users through a Web-based workspace. Because these back-end systems can contain sensitive business information and functionality (for example, a company's order control system) or private data (e-mail or employee records), access should be well controlled.
The basis of access control is authentication, which ensures that the person or program requesting access is identified beyond doubt. It's recommended that back-end systems don't relinquish control of their application security to the portal server, but continue to do their own authentication and authorization. However, users shouldn't be repeatedly prompted to authenticate. This is where single sign-on (SSO) comes into play.
SSO isn't an entirely new idea. However, it raises quite a few problems, and many attempts to develop a general SSO solution have failed. Users are typically known by a variety of identities - one per system in the worst case. The identity a user proves at one system must be mapped securely to an identity that a second system can handle. In addition, in companies that have grown their back-end systems over the years, there are many systems that no one dares to touch. Therefore, it's a common requirement that they're integrated into an SSO realm without any modification to the system itself.
This is a difficult problem. However, using a portal to realize EAI gives you an advantage: the portal becomes a single entry point for all user requests. At this central instance, it's possible to map the user identities transparently to the back-end systems. All you need is a registry for those mappings and a service that leverages this feature to the portlets. WebSphere Portal calls this component the credential vault.
This article explores authentication in the context of WebSphere Portal 4.1 and demonstrates how to provide a full SSO experience to portal users.
Authentication Setups
Portal server authentication is like the front door of a building with all room doors unlocked - the key to the portal is the master key to all applications and information within it. WebSphere Portal leverages the application server's authentication subsystem, which provides support for the following authentication setups:
- Use of native WebSphere Application Server authentication: A custom login form posts the user's authentication data to the portal servlet that requests WebSphere Application Server security to validate the user's authentication data. This setup exploits the integration of WebSphere Portal with WebSphere Application Server and the fact that the portal can be configured as a secure Web application.
- Use of an authentication proxy or HTTP server plug-in: WebSphere Application Server provides the Trust Association Interceptor (TAI) interface, which allows it to establish trust with authentication proxies and authentication plug-ins.
Authentication Through WebSphere Application Server Security
To use WebSphere Application Server security, the portal is configured as a secure Web application. When WebSphere Application Server receives a request for the portal application, its security component redirects the client to a login form that prompts the user to provide authentication credentials. The form posts the credentials to WebSphere Portal's servlet, which makes the required calls to WebSphere Application Server's security functions to log the user in to WebSphere Application Server's security context. WebSphere Application Server authenticates the user by checking the provided credentials against the user registry, which can be an LDAP directory or a custom user registry.
Authentication Through Proxy or HTTP Plug-In
An external authentication component can protect the portal by intercepting all requests targeted to WebSphere Portal destinations. Such an authentication component can be a proxy server like Tivoli Access Manager's WebSEAL or a plug-in to the IBM Edge Server, like WebSEAL Lite from Tivoli, SiteMinder from Netegrity, or GetAccess from Entrust.
Such an external authentication component works by checking the provided credentials against a user registry (in most cases an LDAP directory). TAIs registered with WebSphere Application Server establish trust between the server and the authentication component protecting it. This is a common scenario in production environments.
Trust Association Interceptor
With a TAI registered, WebSphere Application Server relies on an external authentication component for authenticating requests rather than performing authentication itself. The interface that WebSphere Application Server defines for a TAI has functions with which the TAI indicates that it can handle a request and that the request is already authenticated.
After a request for a portal destination passes the external authentication component, it's received by WebSphere Application Server and sequentially passed to the registered TAIs until one TAI indicates that it's responsible for authentication and either accepts or rejects the request.
If no TAI can handle the incoming request, WebSphere Application Server falls back to its native authentication, just as if there were no TAIs. In the case of WebSphere Portal, the client would be redirected to the custom login form. However, this should occur only with requests that bypassed the external authentication component.
Single Sign-On
The goal of SSO is to authenticate a user one time within an environment and use that single authentication (for the duration of the session) as a basis for access to other applications, systems, and networks.
In the context of the portal server, there are two SSO realms, the Client-to-WebApp SSO realm and the Portal-to-BackEnd SSO realm (see Figure 1).
With Client-to-WebApp SSO, a client logs in to one Web application one time and is then able to access all other applications that are part of the same SSO realm without a second authentication challenge. It doesn't matter whether the portal server or one of the other trusting Web applications is the authenticating Web application.
Portal-to-BackEnd SSO allows a portal client to log in to the portal once and then access a number of back-end applications without having to authenticate at each application.
Client-to-WebApp SSO
Client-to-WebApp SSO can be provided through a variety of mechanisms, namely:
1. Application server built-in SSO support (LTPA)
2. Authentication proxy SSO support (WebSEAL, Netegrity SiteMinder, etc.)
3. Other third-party SSO frameworks/environments, such as GetAccess from Entrust
The functional principle of these SSO solutions is essentially the same. Upon successful authentication the client gets a security token that entitles it to get through the policy enforcement point(s) (PEP) with subsequent requests. It's not important in this context whether this is a number of distributed PEPs, such as several application servers (mechanism 1); a single PEP, such as one central authentication proxy (mechanism 2); or a mixture of both (mechanism 3).
Portal-to-BackEnd SSO
Starting with Version 4.1, WebSphere Portal offers a credential vault as a portlet service. This service provides a mechanism to portlets (and to the portal itself) for mapping from a user identity (usually a user ID) to another user identity and usually a credential (such as a password) for that user ID.
Portlets no longer need to store user credentials as part of the user-specific portlet data. In fact, it's recommended that such portlets be migrated so that they make use of the credential vault.
The Credential Vault Service is composed of three levels. At the lowest level are vault adapters. A vault adapter is the SPI-specific plug-in between the vault service and a specific vault implementation. WebSphere Portal provides a default implementation; you can also use the vault implementation provided by IBM Tivoli Access Manager.
At the next level are vault segments, which correspond to a section of a vault that's either user or administrator managed.
At the top level are vault slots. A vault slot corresponds to a particular resource in a vault segment that a user may apply a secret to. It's through a vault slot that user secrets are created, retrieved, modified, and deleted.
Credential Vault Concepts
WebSphere Portal's credential vault (see Figure 2) is
organized as follows:
- The portal administratorcan partition the vault
into several vault segments. Each vault segment is associated with a certain vault implementation (the actual store) that allows different credentials to be kept in different physical stores. The segments can be created and configured only by portal administrators. - A vault segment contains one or more credential slots, the "drawers" where portlets store and retrieve the credentials. Each slot holds one credential (or one per user if it's an admin-defined slot).
- A credential slot is linked to a resource in a vault implementation, where the credential secrets are actually stored. Examples for vault implementations are the portal server's default database vault or Tivoli Access Manager.
A vault segment is flagged to be either admin managed or user managed. While portlets (on behalf of a portal user) can set and retrieve credentials in both types of segments, they're permitted to create credential slots only in user-managed vault segments. Therefore, portlets that need a credential to complete their service have basically two options:
1. Use an existing credential slot that's been defined by the portal administrator in an admin-managed vault segment.
2. Create an "own" credential slot in a user-managed vault segment.
Which variant to choose depends on the use of the portlets in the portal installation.
The credential vault distinguishes between three different types of credential slots:
- Shared-system credential slot: Stores system credentials, i.e., credentials where the actual secret is shared among all users and portlets
- Portlet-shared credential slot: Stores a user credential that's shared among a user's portlets, i.e., the secret is user specific but the same for all the user's portlets.
- Portlet-private slot: Stores a user credential that's not shared among portlets, i.e., the credential secret is user specific as well as specific to a certain concrete portlet instance.
Credential Vault Function
The Credential Vault Service maps a requested credential slot, a user ID, and a portlet ID to a resource in the vault; portlets can only retrieve a credential if a respective mapping rule exists. Some credentials (secrets) will be stored and managed by the portal (local default vault store); secrets that aren't stored locally will be acquired from the respective external vault.
If a credential isn't available, a respective exception is thrown. The portlet service passes this exception to the portlet to allow appropriate error-handling (e.g., ask the user to set the credential through the portlet's edit mode). The credential vault won't allow any person other than the credential owner to manage and/or use the credentials - not even a portal administrator. Portal administrators can configure the credential services that aren't controlled by the user. This includes the management of the vault segments, admin-defined slots, and system (shared) credentials. An administrator may not administer the user-defined credential slots. (Of course, all user-defined slots will be deleted if the respective user is deleted.)
The portal end user manages credentials directly in the portlet's edit mode. With WebSphere Portal 4, it's the portlet's responsibility to provide all necessary functions that allow the user to manage the slots used by this portlet. IBM provides framework sample code that supports portlet developers implementing these credential-management functions.
The portal engine, however, provides all the interfaces necessary to write a general credential management portlet for portal end users. Future versions of WebSphere Portal might ship with such a portlet.
Usually, a portlet binds the credentials it needs to certain credential slots only at runtime, not during deployment. However, it may predefine default values in its PortletSettings to ease the administrator's work or to support a staged development/test environment.
Active Credentials
Just like real valuables, credentials are perfectly safe as long as they're stored in the vault. However, when they're taken out, the owner might worry about their safety: What if the portlet developer didn't pay enough attention and violated security rules? WebSphere Portal's answer to this problem is active credentials.
The Credential Vault Service returns credentials as credential objects. An active credential object hides the credential's secret from the portlet; there's no method to extract it. In return, active credential objects offer business methods that take care of the authentication at the back-end system. That way, a portlet can trigger remote authentication without even knowing the credential's secret; the credential object provides the portlet with an already-authenticated connection. From a security point of view the portlets never get in touch with the credential secrets, and a portlet developer can't accidentally violate security rules (see Figure 3).
All credential types available within the portal are registered in a credential-type registry. WebSphere Portal Server 4.1 provides a small set of credential types out of the box; additional credential objects can easily be added. The active credential classes shipped with WebSphere Portal provide support for standard authentication mechanisms such as HttpBasicAuth, HttpFormBasedAuth, or POP3 authentication. Furthermore, there are credentials that integrate with common SSO solutions, namely LTPA, WebSEAL, and SiteMinder.
Programming Example
Scenario: A company's buying department runs a portal that integrates different legacy applications. One is an ordering-server application with a simple Web front end. Several employees use the ordering portlet, but the application is secured by a system ID - it doesn't support multiple user accounts.
Design solution: The portlet needs to access the legacy application under a system ID. The portal administrator therefore creates a credential slot, "StockManagementSystem", in an admin-managed vault segment; marks it as a shared system credential; and stores the ordering system ID and password in this slot (see Figure 4).
The portlet allows the credential slot ID to be set during deployment, so the buying department's employees don't have to care about credentials at all; they can enjoy an SSO experience right from the start. In the portlet's code, the credential service is used as follows:
1. Get the Credential Vault Service.
PortletContext context = this.getPortlet
Config().getContext();
CredentialVaultService service =
(CredentialVaultService)
context.getService(CredentialVault
Service.class);
2. Retrieve the configured slot ID.
String slotId = (String) request.get
Data().getAttribute("credential slot id");
3. Set the credential object configuration.
HashMap config = new HashMap();
config.put(HttpFormBasedAuthCredential
.KEY_USERID_ATTRIBUTE_NAME, "userid");
config.put(HttpFormBasedAuthCredential
.KEY_PASSWORD_ATTRIBUTE_NAME, "password");
config.put( HttpFormBasedAuthCredential
.KEY_LOGIN_URL, "OrderApp.yourco.com/login.jsp");
config.put(HttpFormBasedAuthCredential.KEY_
LOGOUT_URL,"OrderApp.yourco.com/quit.jsp");
config.put( HttpFormBasedAuthCredential
.KEY_USE_AUTH_COOKIES, Boolean.TRUE);
4. Retrieve the credential object from the credential vault.
HttpFormBasedAuthCredential credential =
(HttpFormBaseduthCredential)
service.getCredential(slotId,
"HttpFormBasedAuth",config,request);
5. Use the credential object to log in at the server application, get a connection, and send the request.
credential.login();
connection = credential.getAuthenticated
Connection("OrderApp.yourco.com/request.jsp");
// Work with the connection: send an HTTP GET or POST and
evaluate the response
6. Use the credential object to log out at the back-end application.
credential.logout();
Summary
Authentication and single sign-on are important issues for portals. WebSphere Portal Server can be set up to rely on the application server's authentication or to use an external authentication component. Existing mechanisms for client-to-Web application single sign-on are leveraged, and the portal server's credential vault creates new possibilities for seamless integration with back-end systems.
1 comments:
Good information about Credentialing services.
Post a Comment