Introduction to Trust Association Interceptor

You can use an external authentication proxy to protect the portal by intercepting all requests targeted for portal destinations. An authentication proxy can be implemented as a proxy server such as WebSeal in ITCAM Or it can be implemented as a plug-in to the web server or to the IBM Edge server. Ex Webagent in Netegrity siteminder.

An external authentication component authenticates users by whatever means the external authentication component considers apporpriate. You will have to use Trust Association interceptor (TAI) registered with WAS to establish a trust relationship between WAS and authentication proxy. The authentication proxy passes authenticated users ID based on establish trust.

A Trust Association Interceptor (TAI) is a mechanism by which WebSphere Application Server enables an external component to authenticate the user and to assert the identity to the WebSphere Application Server Web container.

WebSphere Application Server provides functions which the TAI uses to indicate that it is able to handle a request and that the request is already authenticated. You could think of a TAI as an adapter, which communicates with the authentication component in an unspecified way and makes the authentication decisions accessible to WebSphere Application Server through the specified TAI interface.

Whenever a request attempts to access a secured resource, WebSphere Application Server invokes the TAI, which validates that the request comes from a legitimate third-party authentication proxy and returns the user's authenticated identity to WebSphere Application Server. The TAI should return either a distinguished name (DN) or a short name. WebSphere Application Server performs a registry lookup to verify the distinguished name or convert the short name to a distinguished name before searching for group memberships for that user. If the registry lookup fails, WebSphere Application Server refuses to trust the user. If the registry lookup succeeds, WebSphere Application Server generates a Lightweight Third-Party Authentication (LTPA) token for the user and stores it as a cookie for subsequent authentication during the user's session.



Figure shows the detailed flow of control for a request that passes through an external authentication proxy. The interactions shown are the same for authentication proxies implemented as separate servers, or for proxies implemented as plug-ins for the Web server or the Edge component.

A TAI is not necessary if the third-party authentication proxy provides native WebSphere Application Server identity tokens, such as a LTPA tokens. Currently, only Tivoli Access Manager WebSEAL and Tivoli Access Manager Plugin for Edge Server provide native WebSphere Application Server identity tokens.

The authentication proxy determines the challenge mechanism, and WebSphere Portal relies on the authentication proxy to relay success or failure of the user identifier through the TAI or LTPA token. WebSphere Application Server sees all requests from the TAI as authenticated, but WebSphere Application Server and WebSphere Portal still perform a user and group lookup on each request. Even if the authentication proxy has successfully authenticated, WebSphere Application Server and WebSphere Portal deny access if they cannot query the user in the registry. For example, it is possible to have a user in an External Security Manager (ESM) who is not accessible from WebSphere Portal because WebSphere Portal is configured to one user registry, which may not be the same registry or have the same registry configuration properties as the ESM has

Introduction to Lightweight Third-Party Authentication(LTPA)

Light Weight Third Party Authentication (LTPA) protocol is IBM's implementation of Single Sign on. IBM WebSPhere and Domino products use LTPA to allow single sign on. When LTPA is enable you can login into one WebSPhere Server and when you go to some other WebSPhere or Domino server it wont ask you for credential. Same thing you can login into a Domino first and when you go to other WebSPhere or DOmino servers that are participating in SSO, it wont prompt you for login.

To enable single sign-on, a common set of server encryption keys are created and exported across all servers that run the application. When users first access the site, they are challenged to log in with user ID and password, this information is verified against user registry Ex. LDAP, . Server will creates a security credential token with the LTPA service, and a cookie(this cookie wont be written to the browsers file system i.e. it is non-persistent) is written back to the browser. When the user later accesses another LTPA server in the same domain, information in the shared cookie is used to re-establish the user security context with LTPA. Hence, a second login prompt is unnecessary.

Important Note: One of the restrictions on using LTPA is that all the Servers participating in SSO should use same user registry


If in the future you change the LTPA key on one server then you will have to export it from that server and import it on all other servers participating in SSO
The LTPA cookie contains the following pieces of information:

• Cookie name: Always set to LtpaToken.


• Domain: Set to the Internet domain shared by all servers participating in single sign-on (example: mycompany.com).


• Cookie expiration: Set to delete this cookie at the end of the browser's lifetime.


• Secure: Set to on to force the use of Secure Sockets Layer (SSL). There is an LTPA configuration setting that creates cookies that are sent only through SSL.
  Cookie value: This is set to the LTPA token as described below.

The LTPA token is an encrypted string that contains the following pieces of information:

• User data: Typically set to the user ID but can be any user information used to uniquely identify the user.


• Expiration time: Different from the Cookie expiration, this field is used to enforce a time limit that starts from the moment of login and is unaffected by browser activity or inactivity. The time limit is a configurable LTPA setting that defaults to 30 minutes.


• Digital signature: Used to validate the token.

This is how the request is handled when user is logged in and he has valid LTPA cookie

How credentail Vaults works

The credential vault is a portlet service that allows users/portlets to store credentials, that portlet can retrieve for logging into back end application

There are two kinds of Credentials; Active and Passive. Active Credentials allow you to establish connections via Basic Authentication, Lightweight Third Party Authentication (LTPA) token authentication or simple form-based user ID/password login challenges. Passive Credentials allow the retrieval of stored secret data such as, but not limited to, user ID and password or certificates


WPS provides one simple database vault implementation. By default the Credential vault is divided into two parts

1. Administrator managed vault segment: This information is stored in release database. The administer managed vault segment is divided into slots(Each slot holds one credential i.e. user name and password pair). Each slot allows each user to store different password. ONly administrators can create slot in this segment


2. User-managed vault segment. This information is stored in customization database. This segment is also divided into slots with difference that only one user can store one credential per slot. Portlets(acting on behalf of a portal user) can create in user slot in this segment.

Irrespective of how the slot is managed portlets can retrieve credentials from it.

WebSphere Portal’s Credential Vault defines four types of credential slots:

1. Vault Slots in administrator-managed vault segments:
   
   
   
   • A system slot stores system credentials where the actual secret is shared among all users and portlets. It is a shared slot that belongs to an administrative segment.
   
   
   • An administrative slot allows each user to store a secret for an administrator-defined resource (for example, Lotus Notes). It is an unshared slot that belongs to anadministrative segment.
   
   
   
   


2. Vault Slots in user-managed vault segments:
   
   
   
   • A shared user slot stores user credentials that are shared among the user's portlets. It is a shared slot that belongs to the user segment.
   
   
   • A portlet private slot stores user credentials that are not shared among the user's portlets. It is an unshared slot that belongs to the user segment.
   
   
   
   

Portal to back-end SSO

There are two different options for SSO between portal to back end system.

1. 
   Some back-end systems can be accessed using standard technologies such as J2EE technologies(Datasources for RDBMS or J2C adapter) or web services. if portlet needs to inter operate with one of these back-end systems and do not need any sophisticated principal mapping mechanism, it is recommended that you use these technologies
   


2. 
   For communication with other back-end systems that require proprietary or non-J2EE protocols WPS offers credential vautl as portlet service.
   

SSO from client to web application

You can provide SSO from the client to Web applications and portal two these two mechanism

1. Light weight thrid party authentication(LTPA):


2. Authentication proxy:

The functional principal of these single sign-on solutions is essentially the same. Upon successful authentication the client gets a security token in the form of cookie(This is not persistent cookie, instead this cookie is deleted when clients browser session is closed) and the browser forwards this cookie to the servers web applications in that domain. The application server or Authentication proxies read authentication information from the cookie and let user in without reprompting for password

Introduction to Single Sign-on(SSO)

The goal of single sign-on is to provide a secure method of authenticating a user one time within an environment and using that single authentication(for the duration of the session) as a basis for access to other applications, systems and networks. In case of WPS there are two single sign-on realms;
1) the realm from the client to portal and other web applications- With this client can login into one web application/portal once and can access all other web applications that are part of the SSO realm.
2) from the portal to the backend applications: This enables a portal client to log into the portal once and then to access a number of back-end applications through respective portlets without having to authenticat at each of these applications.