WebSphere Portal with Tivoli Access Manager

 

+
Search Tips   |   Advanced Search

 

Introduction

Tivoli Access Manager (TAM) is a middleware product for building secure applications more efficiently. Use TAM for enhanced security and Single Sign-On (SSO) capabilities, and for development of fine-grained access control, login/password/session policies, and auditing.

Web SSO Allows a user to access a set of applications via a single login. Two basic architectures:
  1. reverse proxy
  2. plug-in
Desktop SSO SSO between Windows NT/2000 and Microsoft Internet Information Services (IIS) using Microsoft Internet Explorer. A user’s identity can be automatically propagated into browser-based applications from the desktop operating system authentication via a Kerberos exchange using the SP-NEGO protocol. Used with Intranet deployments.
Federated SSO Authentication to a number of loosely related Web sites over an untrusted network, such as the Internet. Allows users to access a collection of trusted sites in different DNS domains, and/or security domains (circle of trust), via a single login. When a user initiates a sign-off operation from a site within the circle of trust, all of the users active sessions with any of the sites within the circle of trust are closed in a synchronous fashion. Associated with WS-Security.
Portlet SSO In a portal-based architecture, an additional realm of SSO comprises access to applications from portlets hosted in a portal server. The focus here is on portlets that communicate directly with other applications or data sources, process the responses, and render a response to the user.  iFrame portlets or simple hyperlinks fall into the realm of Web SSO, as in th o ese cases, the associated HTTP requests come from the user’s browser, rather than portlet code running on appserver.

 

Web Single Sign-On

TAM for e-business includes both a reverse proxy (WebSEAL) and a set of Web server plug-ins.

Reverse-proxy provides a DMZ control point where the user authenticates directly to the reverse proxy, which then in turn authenticates the user to a collection of Web resources.

WebSEAL provides the following user authentication methods:

The WebSEAL component of Access Manager also has a range of features to provide SSO to back-end Web applications:

Access Manager provides a credential store (GSO Lockbox) for storing users credentials for registries other than the primary registry used by Access Manager. The WebSEAL component of Access Manager can use this “lockbox” in the Basic Authentication and forms-based methods of SSO to back-end Web applications. Both a command line interface and (Java and C) APIs are provided to facilitate automatic synchronization of the credential data stored in the GSO Lockbox (e.g. resource specific passwords such as SAP account password), with that in the corresponding back-end registries (e.g. SAP).

In a WebSphere Portal environment, WebSEAL can use either an identity assertion or an LTPA-based method to authenticate the user to the underlying WebSphere Application Server.  WebSphere Portal then leverages the resulting WebSphere Application Server login context.

The primary benefit of the Access Manager SSO features in this realm is the (secure) SSO between WebSphere Portal and those applications run in iFrames (e.g. Lotus iNotes) or launched in a separate window. This allows legacy applications to be readily integrated into a WebSphere Portal deployment in an efficient and secure manner.

From a security perspective, the use of WebSEAL also provides SSO to other WebSphere and Lotus Web/appservers, without the use of domain cookies  ‑  which are subject to capture and replay attacks, particularly in intranet deployments.  Other security-related benefits that come from using WebSEAL in a DMZ include:

 

Desktop Single Sign-On

Recent versions of Microsoft Internet Explorer provide the ability to propagate a Windows NT or Windows 2000 client operating system authentication to IIS. The Microsoft implementation only supports Microsoft products for the browser, the client operating system, the server operating system, and web/appserver.

TAM extends this functionality to allow a Windows NT/2000 desktop authentication to be propagated to a WebSEAL server running on any of the supported platforms.  In its simplest form, Microsoft Active Directory is used as the primary registry for TAM, but other architecture options exist that allows any of the supported registries to be used.

In a WebSphere Portal deployment, this means that (for example) a user could logon to an Active Directory domain from their Windows 2000 desktop, and be automatically authenticated, via Microsoft Internet Explorer and the WebSEAL component of Access Manager, to a WebSphere Portal Server running on AIX, and using IBM Directory Server running on Linux for z-Series.

 

Portlet Single Sign-On

SSO from a portlet hosted in a WebSphere Portal server is typically done using credential data stored in the credential vault.  In most deployments, this data in the credential vault needs to be kept synchronized with the credentials stored in the target user registries.  WebSphere Portal provides a facility where its credential vault data can be stored in the Access Manager “GSO lockbox”, rather than the usual location of a relational database table.  This integration is done transparently to the portlets, such that a portlet is unaware of whether the credential data is coming from the portal database or from Access Manager.

By integrating the credential vault with Access Manager, a set of credentials can be stored in one place and used by either the WebSEAL component of Access Manager or a portlet as needed.  Moreover, Access Manager provides a Command Line Interface, and (Java and C) APIs for maintaining the credential data  ‑  this allows a product such as IBM Tivoli Directory Integrator to be used to keep the credential data automatically synchronized with the back-end user registries.

From a security perspective, storing the credentials in Access Manager implies that the credentials are now transported between Access Manager and WebSphere Portal servers via a mutually authenticated (via X.509 certificates) SSL connection.

From a system availability and maintenance perspective, it is generally preferable to use an identity assertion or credential propagation style SSO, rather than storing, maintaining and using separate credentials to do a “screen-scrapping ” approach to SSO such as that provided by the WebSphere Portal APIs . An architecture option that can be used to ease the burden on portlet developers in terms of SSO to applications and the storage/synchronization of credential data, involves the use of another instance of a WebSEAL server located in the application segment of the network.  A portlet developer can simply propagate the user’s Access Manager credential (created by the DMZ WebSEAL server) from the incoming HTTP request into an outgoing request to the “inside” WebSEAL server.  The portlet can then access resources protected by this “inside” WebSEAL server without needing to deal with application specific SSO issues. Moreover, from a portlet development viewpoint, the SSO is achieved in a stateless manner. This architecture also allows a portlet to readily utilize the Federated SSO features provided by the WebSEAL component of Access Manager to securely access data from web applications in other DNS domains and/or other organizations.

 

Federated Single Sign-On

In a reverse-proxy based architecture, Federated SSO comprises SSO between the reverse proxy and other Web resources not in the protection domain of the reverse proxy.  The Access Manager reverse proxy, WebSEAL, supports an extensible model for SSO into WebSEAL from other Web resources.  The SSO features of WebSEAL in this realm include a proprietary e-community SSO solution that allows SSO across Access Manager Web components in different DNS domains.  A SAML toolkit is also available to facilitate the acceptance of SAML tokens from other SAML-complaint servers.

Further open standards based solutions addressing the area of Federated Identity Management are planned for upcoming releases of Access Manager.  As mentioned earlier, Web applications protected by the WebSEAL component of Access Manager can take advantage of these new features as they become available, without needing to change the basic architecture or the Web applications themselves.

From a portal perspective, the Federated SSO features of Access Manager allow applications in different DNS domains (and possibly from different organizations) to be displayed in iFrame style portlets, with SSO to these applications efficiently (and securely) handled by WebSEAL.  The same functionality can also provide SSO within the same DNS domain, without the use of domain cookies (and thereby avoid ing their inherit security risks).

 

Layers of Authorization

Security texts often discuss the concept of “defense in depth”, where layers of different security measures are put in place to protect resources.  In the context of e-business applications, this concept may be characterized by the phrase “authenticate once, authorize often”.

The term “authorization” is often described using the question “Can user A perform operation B on resource C?”.  In order to answer such questions, the authorization middleware compares the entitlements defined for a specific user identity with the permissions required to perform the requested action on the specific resource.  Authorization logic is essential to business applications, but it can be expensive in terms of development time and cost.  It has been estimated that up to 30% of the application development time/cost for a new applications is spent coding and testing authorization-related functionality.

In a portal deployment there are several different layers of access control (“authorization”), with each layer providing more specific (or “fine-grained”) access control than the preceding layer.  For purposes of this discussion, we will address the following layers of authorization in a portal-based system:

1)  Web URL Layer Authorization

The Web URL Layer of authorization comprises access control on particular patterns of URLs, and is often referred to “coarse-grained” authorization.  Resources protected at this layer include the portal application itself, static content viewed via portlets (e.g. PDF/Excel files), and applications/servlets run in an iFrame, or launched in a new window.  Finer grained URL authorization that incorporates the values passed via GET or POST parameters into the authorization decision is also included in this layer.

2)  Portal Presentation Layer Authorization

The Portal Presentation Layer comprises the pages, portlets, menus and other presentation artifacts that make up a portal product.  There is some debate whether “access control” at this layer is really in the domain of enterprise security, or whether it is simply an aspect of user interface design ‑ more on this issue later.

For purposes of this discussion, presentation layer logic coded in portlets, or in applications viewed in iFrames, is considered part of the Business Logic Layer;  leaving authorization in the Portal Presentation Layer to consist solely of access control enforced by the portal middleware on its own resources.

3)  Business Logic Layer Authorization

The Business Logic Layer is a broad layer that utilizes several different forms of authorization.  For purposes of this discussion, we include the application code written in custom portlets into the Business Logic Layer, even though it may not include any business logic per se.  Traditionally, business logic decisions were either hard-coded into program code or based on proprietary entitlements database tables (which also require the development of applications to administer the entitlements data).  More recently, standards have started to emerge with the goal of reducing the development and ongoing administration effort involved in the earlier proprietary designs.

Authorization mechanisms in this layer can be categorized as being either class/method level (usually used to represent some operation or function) or instance level (which has a much closer relationship to the data involved in the operation).  For example, a project manager may be authorized to view any timesheet data (class/method level), but may be restricted to update timesheet data for only those projects for which they are responsible (instance level).

An alternate categorization is based on whether the authorization checks are transparent to the code written by the application developer, or whether the application code directly invokes the authorization middleware for an access control decision or set of entitlements.  An important aspect of authorization at this layer is obtaining the necessary data items to make the decision.  Access control decisions at the instance level are often quite complex and dynamic;  consequently, there is growing use of rules-based tools in the authorization process at this level.

4)  Data Layer Authorization

Access control of data has traditionally been the domain of Data Base Management Systems (DBMS), with user-level authorization rules directly defined in the DBMS hosting the data.  As the types and volumes of users accessing data increases in an e-business scenario, an emerging alternative model that is sometimes adopted uses an application-level id to access the DBMS and moves the responsibility for determining who has access to what data back into the Business Logic Layer.

 

Web URL Layer Authorization

In its role as a reverse proxy, the WebSEAL component of Access Manager provides access control on specific URLs, or simple patterns of URLs, that pass through WebSEAL from the user’s browser to the protected web applications.

In a portal environment, access to static content, such as that displayed in the various viewer-style portlets, can therefore be easily defined and managed via Access Manager.  Access Manager provides a GUI (and CLI/APIs) to easily view and set authorization policy on static web content hosted by the set of heterogeneous set of web servers that WebSEAL is protecting.

With the recent inclusion of rules-based authorization capabilities in Access Manager, authorization performed by WebSEAL can now be extended to included fine-grained access control over the values of the GET/POST parameters associated with a particular HTTP request. WebSEAL’s ability to perform URL-based authorization on dynamic content in this manner is determined by the consistency and complexity of the URLs used by the back-end applications. This Where the URLs are suited to authorization checking by WebSEAL, GET/POST parameter validation is can defined using business rules encoded in XSL, and can include data elements from other data sources in the rule evaluation.

 

Portal Presentation Layer Authorization

Authorization in the Portal Presentation Layer comprises access control on those resources defined within the portal itself (e.g. pages, portlets).  There are two different ways to view authorization at this layer:

· access to portal resources is part of enterprise security and needs to be centrally controlled and managed;

· access control functionality in a portal is simply used to modify the user experience for different sets of users, and is therefore a component of GUI design and not part of the realm of enterprise security.

In many real-world environments, the real answer is likely to be some combination of these two alternatives.  It is unlikely that access control for all portal resources falls in the realm of enterprise security (e.g. Welcome page, World Clock portlet, private pages);  however, there may be mission-critical or other sensitive pages/portlets that are considered part of the enterprise security domain within an organization.  This latter case typically arises where portlets dealing with sensitive data have been designed such that access to the portlet automatically implies access to the full function of the portlet (without any further authorization based on individual user identity), or where a defense-in-depth approach is required.

WebSphere Portal provides built-in access control functionality for managing access to the portal resources it is hosting.  The entitlement data is stored in the portal database (e.g. DB2) and managed via administration portlets.

WebSphere Portal also provides the ability to move access control for specific portal resources to TAM.  WebSphere Portal invokes the Access Manager authorization APIs for authorization decisions relating to these resources.  This allows an organization to manage access control for sensitive pages and portlets using the same semantics and utilities as that used for the other enterprise security resources managed via Access Manager.

 

Business Logic Layer Authorization

For purposes of this discussion, we will use the term Business Logic layer to include both the application code invoked by the portal, and any application logic coded into custom portlets.  As discussed earlier, authorization at this layer often includes both class/method level and instance level requirements. 

Under the J2EE model, class/method level authorization is enforced by the J2EE container.  Authorization decisions are based on the mappings of users/groups to J2EE Roles, and the mappings of J2EE Roles to specific web/EJB methods.  For both WebSphere and WebLogic appservers, TAM provides functionality that allows it to participate in the policy management and enforcement of the J2EE container-managed security implemented within the appservers.   This allows J2EE role membership to be managed using the same semantics and utilities as other enterprise security resources managed by Access Manager.  Today this is achieved using proprietary interfaces into each of the appservers.  With the recent adoption of the JACC (Java Authorization Contract for Containers) standard, Access Manager will in the future be able to provide more functional management of J2EE security across a wider set of appserver platforms.

Class/method level security is typically not sufficient to meet the security requirements of an e-business application.  Real-world applications typically include some requirements that restrict access to specific instances of objects to specific sets of users  ‑  for example, insurance brokers might be restricted to access only those policies for which they are identified as the responsible broker.

One of the key ingredients in implementing instance-level access control is obtaining sufficient data about a user’s identity and entitlements, along with sufficient detail about the function being requested to make the decision whether to grant access.  The WebSEAL component of Access Manager provides functionality to extract user-related data elements from LDAP and/or other data sources and provide them to back-end applications via HTTP headers.  This allows provides an additional implementation option for application developers in cases to where they need to obtain identity and entitlement data for the current user in an efficient and stateless manner.

TAM provides sets of Java and C APIs for implementing instance-level access control within an application.  These APIs allow a developer to use the security middleware to make authorization decisions and store/manage the policy for making those decisions, thereby dramatically reducing the amount of code that needs to be written, tested, documented and supported.  The Java APIs include an implementation of the JAAS (Java Authentication and Authorization Service) standard.   The C APIs implement an authorization standard developed by The Open Group.  These APIs allow fine-grained authorization policy for both Java and non-Java applications to be managed using the same semantics and utilities as those used for managing other enterprise security resources controlled by Access Manager.

The latest release of Access Manager includes a rules-based engine, in addition to its traditional Access Control List (ACL) based model .   This rules engine is a powerful tool for defining and enforcing instance-level requirements in a succinct and efficient manner.  The rules engine can utilize the identity/entitlement data obtained (and cached) from various data sources by the WebSEAL component of Access Manager, as well as providing a means whereby more volatile data elements (e.g. account balance) can be obtained on an as-needed basis in order to evaluate a specific rule.

 

Data Layer Authorization

Access control of data has traditionally been the domain of Data Base Management Systems (DBMS), with user-level authorization rules directly defined in the DBMS hosting the data.  As the types and volumes of users accessing data increases in an e-business scenario, an emerging alternative model that is sometime s adopted uses an application-level id to access the DBMS and moves the responsibility for determining who has access to what data back into the Business Logic Layer.  Motivations for this new model include access to rules-based tools to simply the management of authorization data and increased flexibility.

In cases where application level ids are used to authenticate to the DBMS and the business logic takes over responsibility for data-level access control, the earlier discussion on the features of Tivoli Access Manager that support instance-level authorization is directly applicable.  In particular, the Access Manager rules engine can often be used to simplify the management of data-level access control policy.

 

Getting To A Production Deployment

This section deals with some of those aspects of a portal environment that often need to be addressed in order to be ready for a production deployment, over and above the development and testing of the applications hosted by the portal.

 

Authentication/Session/Password Policies

In an integrated WebSphere Portal and TAM environment, the WebSEAL component of Access Manager takes on the responsibility for authenticating the user and controlling the user’s view of session management.  WebSphere Portal deployments can therefore take advantage of the out-of-the-box features provided by WebSEAL for authentication, session and password policy management.

These features include:

· expired password handling;

· password reset and password strength policy management;

· delegated security administration;

· temporary accounts (i.e. user accounts with an expiration date);

· session duration and/or inactivity timeout (without loss of session context after re-authentication); and

· account lockout (possibly for a specified time period) after a specific number of unsuccessful authentication attempts;

 

Audit Logging

As a security middleware product, TAM provides comprehensive audit logging capabilities, with audit log collection functionality that will securely collect logs at a central point.  This facilitates the use of intrusion detection and related tools on the audit log data produced by the various components of Access Manager.

In an integrated WebSphere Portal and TAM environment , the audit information logged will include all authentication attempts, ac c ount/password policy changes, and authorization policy changes for those resources that have been moved under Access Manager access control.   Access attempts will also be logged for resources protected directly by WebSEAL , along with any calls made to the Access Manager authorization APIs.

 

Switch User

In a portal environment, where users are presented with differing user interface designs ‑ depending on their group membership ‑ a useful feature for Help Desk personnel and those designing the portal user interfaces is to see what a specific user’s view of the portal will be, without needing to know the other user’s password.

The WebSEAL component of TAM provides a “switch user” feature that allows an appropriately authorized user to temporarily become another user without needing to know the other user’s password.  Sensitive userids can be excluded from the set of users that can be “switched” to.  In an integrated system, this feature allows support staff to more readily determine presentation layer access control problems in a WebSphere Portal environment, without requiring the other user to divulge their password  ‑  which may be the same password used for access to other systems/resources.

 

Handling Multiple User Registries

In a environment where the definitive source of user identity information is spread across a number of different physical registries, tools such as IBM Tivoli Directory Integrator can be used to create and maintain the single user registry required for WebSphere Portal.  As with any registry synchronization, the difficult data element to synchronize is often the users password (due to the use of one-way encryption and the need for real-time synchronization).

The WebSEAL component of Tivoli Access Manager provides an authentication plug-in interface that allows the password entered by the user to be checked against the actual registry containing the user's password, thereby avoiding the need to synchronize passwords between the real user registries and the composite shadow registry used by WebSphere Portal and Tivoli Access Manager. WebSEAL also supports the propagation of password changes made by the user when using WebSEAL (e.g. when a user's password expires) back to the real user registry for that user.

For cases where the applications being accessed from WebSphere Portal use different registries to that used by the portal server, the Access Manager APIs and/or Command Line Interface (CLI) can be used to implement an automatic synchronization solution between the back-end registries and the GSO Lockbox component of Access Manager.  Through the integration of the Credential Vault of WebSphere Portal and the GSO Lockbox of Access Manager, portlets can utilize this synchronized credential data to connect to the back-end systems.

 

Stable Architecture

The use of a reverse-proxy based architecture, such as that provided by Access Manager, allows Web applications to be added, replicated and/or removed without changing the basic system architecture. It hides details of the implementation behind the reverse-proxy, which in turn, allows platform changes to be made without impacting the external URLs.

An Access Manager based architecture also allows authentication mechanisms to be modified or augmented with new options, without any modification to the basic architecture or the back-end applications.

Additional transparent authorization mechanisms, such as rules-based validation of GET/POST parameter values by WebSEAL, can also be added without modification to the basic architecture or back-end applications.