Single sign-on

 

+
Search Tips   |   Advanced Search

 

Overview

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.

  • Client-to-web application SSO
    • Application server built-in SSO support (LTPA)
    • Authentication proxy SSO support (WAS Trust Association Interceptors)
    • WAS (therefore Portal) support for Federated Identity (Liberty/SAML) via WebSEAL or other front-end security service, brought in to WAS via TAI or other mechanism

  • Portal-to-back end SSO
    • Portal Credential Vault
      • Credential Vault Portlet Service and Active and Passive Credential objects
      • Credential Vault Adapter SPI
      • Default simple DB storage vault implementation
    • ConnectionFactories provided via JCA / WAS

In the context of WebSphere Portal, there are two single sign-on realms:

client Portal and other web applications

Single sign-on established via...

portal Backend applications

Single sign-on can be established with the LTPA token functionality if accepted by the backend application either via one of the following....

Credential vault provides mechanism for a portlet to retrieve representations of a user's authenticated identity, which the portlet can pass to a backend application. WebSphere Portal and the portlet act as an authentication proxy to the backend application.

Using single sign-on, a user can authenticate once when logging in to WebSphere Portal, and the user's identity is passed on to applications without requiring additional identity verification from the user.

The Credential vault features two levels of single sign-on:

Active Credentials Encapsulates the functionality of single sign-on for the portlet writer in an object provided by the Service.
Passive Credentials More flexible but requires portlet writers to manage their own connections and authentication to backend applications with the Credentials (i.e. userid and password) they retrieved from the Credential Vault.

 

 

WebSphere Portal and JAAS

The single sign-on functions of WebSphere Portal use the authentication subset of...

Java Authentication and Authorization Services (JAAS)

WebSphere Portal does not support true JAAS authorization.

WebSphere Portal builds a JAAS Subject for each logged on user, which consists of...

A Principal is a piece of data, such as the user ID or user's DN that gives the identity of the Subject.

A Credential is a piece of data, such as a password or a CORBA Credential that can be used to authenticate a subject.

The Subject carries around the Principals and Credentials that can be used by the portlet directly or through the credential service.

 

Windows Desktop to Portal Front-End SSO

Supported out-of-the-box today by Tivoli Access Manager

  • WebSEAL supports SPNEGO, id passed to WAS via standard TAI
  • SiteMinder can do this too

Supported out-of-the-box by WAS 6.1

  • Portal runs on WAS 6.0.x
  • Well known how to do this via ISSW services. SPNEGO TAI++ implementation already built by ISSW.

Kerberos Authentication Technology Preview in WAS 6

May be used with Portal 5.1.0.x for Windows SSO -> not tested so far.

http://www-106.ibm.com/developerworks/websphere/downloads/kerberos.html

 

Portal to Backend SSO: WP Credential Vault

A Portlet Service for storing and retrieving SSO Credentials including the users JAAS Subject that was built during login.

A vault adapter interface to integrate vault implementations like the Tivoli Access Manager Global Sign-On Lockbox

A basic default vault implementation

  • base64 encoding
  • public encryption exit
  • migration challenge

 

Single Sign-On Models

Use of delegatable tokens

  • LTPA, iv_creds, WAS Credential Propagation, sm_session,...
  • Best Choice

Establish trust and assert end user identity

  • WASs TAI model is an example
  • Only 1 secret to manage per endpoint pair to establish the trust rather than per-user secrets
  • May still require an identity mapping but no per-user password mapping
  • Back end apps must be able to accept this
  • Next Best Choice

ID/PW passed to back end and re-authenticated

  • Requires vault store creation/maintenance
  • Last choice other than no SSO, but sometimes (often?) theres no other choice

 

Portal to Backend SSO: WP Credential Vault

Portal's framework* for back-end SSO. Much more than just a store for mapped IDs/PWs. Thats just the bottom layer the default storage vault implementation

 

Related information

 

Parent topic:

Authentication

 

Related concepts

Planning for collaborative servers and portlets

 

Related reference

Planning for using the Domino and Extended Products portlets