TAMeb and portals: Single sign-on concepts and considerations

The prevalence of portal products introduces interesting challenges to IT architects requiring a single sign-on (SSO) solution that incorporates their enterprise portal and the enterprise applications. One such challenge is determining the method of sign-on to both the portal and the portal-managed content where access to enterprise applications is via an authenticating reverse proxy, such as Tivoli Access Manager WebSEAL. This article outlines the architecture and concepts involved in performing single sign-on from the browser, through the portal to the enterprise applications.

Peter Tuton (ptuton@au1.ibm.com), Software Engineer, IBM

Peter TutonPeter Tuton is a Software Engineer in the Tivoli Security Integration Factory Team based on the Gold Coast, Australia. In this role, Peter is the Technical Lead for the team developing integration solutions for Tivoli Access Manager and Tivoli Federated Identity Manager. Peter has been involved in the certification of a number of IBM integration solutions with leading software companies, including Siebel, PeopleSoft and SAP.



Simon Canning (scanning@au1.ibm.com), Software Engineer, IBM

Simon CanningSimon Canning is a Software Engineer in the Tivoli Security Integration Factory Team based on the Gold Coast, Australia. In this role, Simon is part of the Tivoli Access Manager Integration development team and has been involved in developing and maintaining IBM integration solutions with leading software companies, including Microsoft, Oracle, Siebel and PeopleSoft. Simon holds a Bachelor of Computer Systems Engineering from the Queensland University of Technology.



03 December 2007

Introduction

Enterprise portals provide centralised access to enterprise applications, documents sources, collaboration tools and search and navigation services. Portals can be customized based on user requirements as well as display specific content based on user preferences. Portals can provide a gateway to all Web-based applications and services within an organization. Enterprise portals can also include authentication to these resources, allowing single sign-on between the portal and the portal content provider.

Tivoli Access Manager for e-business (TAMeb) provides single sign-on solutions to many vendors' enterprise portal software. This allows an end-user to login to Tivoli Access Manager (TAM) WebSEAL, for example, and access to the portal without requiring an additional login. If WebSEAL can provide single sign-on solutions to portals and if portals themselves can authenticate users to portal content providers, what is the problem?

This article outlines the architectural differences, which can affect how WebSEAL can be used with portal software, in order to allow single sign-on from the browser, through the portal to the content provider.


Portal content delivery patterns

Content displayed within a portal can come from a variety of sources. These sources include the portal server itself or a number of portal content providers. Content delivered from a content provider can be delivered in one of two ways: the portal proxy delivery pattern and the portal redirection delivery pattern. Each of these patterns is outlined below.

The portal proxy method involves the proxying of content from the content provider through the portal to the browser. The browser only makes a connection to the portal server and does not directly connect to the content provider. The portal server acts as a proxy for requests made to the content provider. It should be noted that in this pattern, the traffic between the portal server and the content provider does not necessarily have to be HTTP(S) but be through a variety of protocols, for example, WSRP. The protocol used between the portal server and the content provider is not necessarily relevant.

Figure 1. Portal proxy content delivery pattern
Portal proxy content delivery pattern
  1. The browser makes a request for content.
  2. The portal server requests the content from the content provider.
  3. The content provider returns the content to the portal server.
  4. The portal server returns the content to the browser.

Portal redirection pattern

The portal redirection pattern involves redirecting the browser to the content provider to receive content. The browser makes a direct connection to both the portal server and the content provider. Content from the content provider can be displayed within the portal page using an iframe, for example. To the user, the connection to the content provider is transparent. In this pattern, the traffic between the browser and the content provider is HTTP(S).

Figure 2. Portal redirection content delivery pattern
Portal redirection content delivery pattern
  1. The browser makes a request for content.
  2. The portal server redirects the user to the content provider.
  3. The browser requests the content from the content provider.
  4. The content provider returns the content to the browser.

Single sign-on realms

Multiple sign-on realms can be identified within a portal environment involving WebSEAL. These realms are the Desktop SSO realm, the Web SSO realm and the Portlet SSO realm. Each of these realms is illustrated in the figure below.

Figure 3. Sign-on realms
Sign-on realms

Desktop SSO realm

The Desktop SSO realm involves the single sign-on from a desktop to the WebSEAL server. In the case of a Microsoft® desktop operating system, this could involve authentication to WebSEAL using SPNEGO. Whilst the Desktop SSO realm is an important realm within a single sign-on solution, Desktop SSO is not required in a portal environment. This realm is shown to merely highlight the number of SSO realms that can be involved in a portal SSO solution.

Web SSO Realm

The Web SSO realm provides single sign-on to Web servers, services and applications within an organization. As shown in Figure 3, this can include the portal server and content providers. WebSEAL supports a number of authentication options to perform SSO to back-end servers. These include:

  1. Basic authentication
  2. HTTP header authentication
  3. Forms single sign-on
  4. LTPA token authentication

Portlet SSO realm

The Portlet SSO realm involves managing single sign-on from the portal to the content provider. The portal is responsible for handling all content provider requests and sending them back to the user. Depending on the portal product used, the portlet SSO realm might or might not exist but could provide a further opportunity for integration.

As seen in Figure 3, the content provider can exist in either the Portlet SSO realm or the Web SSO realm on a per-context provider basis. This is an important point that needs to be considered when architecting a portal SSO solution.


Portal single sign-on patterns

The portal single sign-on patterns are based on the portal content delivery patterns. These patterns show how single sign-on can be performed depending on the delivery pattern that a portal product might use. There is one single sign-on pattern for the portal proxy delivery pattern and two single sign-on patterns for the portal redirection content delivery pattern. Each of these is outlined below.

Portal proxy SSO pattern

The portal proxy SSO pattern is derived directly from the portal proxy content delivery pattern. The following describes the flow of content within this portal SSO pattern.

Figure 4. Portal proxy SSO pattern
Portal proxy SSO pattern
  1. The browser authenticates to WebSEAL.
  2. WebSEAL signs the user onto the portal using SSO techniques.
  3. The portal server proxies the request to the content provider.
  4. The content provider returns the content to the portal server.
  5. The portal server returns the content to WebSEAL.
  6. WebSEAL returns the content to the browser.

From the Figure above, it can be seen that this pattern can involve three single sign-on realms. These are:

  • Desktop SSO realm
  • Web SSO realm
  • Portlet SSO realm

In this case, the portal server is contained within the Web SSO realm and the content provider is contained within the portlet SSO realm. This means that the browser is responsible for authenticating the user to WebSEAL; WebSEAL is responsible for authenticating the user to the portal; and the portal is responsible for authenticating the user to the content provider. WebSEAL provides the user identity to the portal server and it is the portal server's responsibility to ensure that the correct identity is passed to the content provider. An example of the use of this pattern is utilizing WebSEAL with the IBM WebSphere® Portal Server, where IBM WebSphere Portal Server uses its Credential Vault.

Figure 5. Portal proxy SSO pattern - IBM WebSphere example
Portal proxy SSO pattern - IBM WebSphere example
  1. A user makes a request to the portal through WebSEAL.
  2. WebSEAL authenticates the user, issues an LTPA token and sends the token plus the request to the IBM WebSphere Portal Server.
  3. The portal server authenticates the user using the LTPA token, examines the request and makes a Credential Vault lookup to determine the credentials for the content provider requested (for example, a WebSphere Application Server application). The credentials plus the content request are sent to the WebSphere Application Server application.
  4. The WebSphere Application Server application authenticates the user using the credentials presented by the portal server and returns the content.
  5. The WebSphere Portal Server sends the content to WebSEAL.
  6. WebSEAL sends the content to the browser.

Proprietary token SSO pattern

The proprietary token SSO pattern is derived from the portal redirection content delivery pattern. This pattern uses a proprietary token, which is delivered to and used by the content provider to authenticate the user. The token contains identity information provided by the portal server for use by the content provider. The portal server fulfills the token provider role, and the content provider fulfills the token consumer role.

Figure 6. Proprietary token SSO pattern
Proprietary token SSO pattern
  1. A user authenticates to WebSEAL.
  2. WebSEAL signs the user onto the portal using SSO techniques.
  3. The portal returns a redirect to the browser as well as a proprietary token which can be used to access the content provider.
  4. The browser follows the redirect and includes the proprietary token in the request.
  5. The proprietary token is used to authenticate the user to the content provider.
  6. The content from the content provider is returned to the browser.

From the figure above, it can be seen that this pattern can involve two single sign-on realms. These are:

  • Desktop SSO realm
  • Web SSO Realm

In this case, the portal server and the content provider are contained within the Web SSO realm. It should be noted that no portlet SSO realm exists in this pattern. This means that the browser is responsible for authenticating the user to WebSEAL, and WebSEAL is responsible for authenticating the user to the portal and the content provider. This is performed through the use of a token, issued by the portal, and subsequently consumed by the content provider. The user identity provided to WebSEAL is captured by the portal server and placed into the proprietary token. The user is authenticated at the content provider by presenting the token issued by the portal. In order for the content provider to use the portal-issued token, trust must be established between the portal server and the content provider. An example of the use of this pattern is utilizing WebSEAL with the SAP NetWeaver Portal Server.

Figure 7. Proprietary token SSO pattern - SAP example
Proprietary token SSO pattern - SAP example
  1. A user makes a request to the portal through WebSEAL.
  2. WebSEAL authenticates the user and sends the request plus some authentication information (header) to the SAP NetWeaver Portal server.
  3. The portal server issues a MYSAPSSO2 token in the form of a cookie and returns this, as well as the content, to WebSEAL.
  4. WebSEAL forwards the content and the MYSAPSSO2 token to the browser.
  5. The browser follows a redirect (iframe or src request) for content from the SAP content provider (for example, SAP ERP) and includes the MYSAPSSO2 token in the request.
  6. WebSEAL sends the content request plus the MYSAPSSO2 token to the SAP ERP server.
  7. The SAP content provider trusts the MYSAPSSO2 token issued by the SAP NetWeaver portal server, authenticates the user and sends the SAP ERP content to WebSEAL.
  8. WebSEAL sends the content providers content to the browser.

Standard WebSEAL single sign-on pattern

The standard WebSEAL single sign-on pattern leverages WebSEAL single sign-on mechanisms to perform SSO to both the portal and the content provider. This pattern is derived from the portal redirection content delivery pattern. Standard WebSEAL techniques such as basic authentication, HTTP header authentication or forms single sign-on are used to perform SSO to the portal and the content provider.

Figure 8. Standard WebSEAL SSO pattern
Standard WebSEAL SSO pattern
  1. A user authenticates to WebSEAL.
  2. WebSEAL signs the user onto the portal using SSO techniques.
  3. The portal returns a redirect to the browser.
  4. The browser follows the redirect to the content provider via WebSEAL.
  5. WebSEAL uses standard SSO techniques to perform single sign-on to the content provider.
  6. The content from the content provider is returned to the browser.

From the figure above, it can be seen that this pattern involves only two realms of sign-on. These are:

  • Desktop SSO realm
  • Web SSO realm

In this case, the portal server and the content provider are contained within the Web SSO realm. Note that no portlet SSO realm exists in this pattern. This means that the browser is responsible for authenticating the user to WebSEAL, and WebSEAL is responsible for authenticating the user to both the portal and the content provider. As opposed to the previous two methods where it was the responsibility of the portal server to ensure the user identity is passed to the content provider, in this case it is the responsibility of WebSEAL. This method can be used with a number of portal products. A specific example containing PeopleSoft Portal using PeopleSoft Financials as a content provider is shown below.

Figure 9. Standard WebSEAL SSO pattern - PeopleSoft example
Standard WebSEAL SSO pattern - PeopleSoft example
  1. A user makes a request to the portal through WebSEAL.
  2. WebSEAL authenticates the user and sends the request plus some authentication information (header) to the PeopleSoft Portal server.
  3. The portal server issues a PeopleSoft PS_TOKEN cookie and returns this, as well as the content, to WebSEAL.
  4. WebSEAL mangles the PS_TOKEN cookie to include the junction point (for example, /portal/PS_TOKEN) and sends the mangled cookie and the PeopleSoft Portal server content to the browser.
  5. The browser follows a redirect (iframe or src request) for content from the PeopleSoft Financials content provider.
  6. WebSEAL authenticates the user and sends the content request plus some authentication information (header) to the PeopleSoft Financials content provider.
  7. The PeopleSoft Financials content provider issues a PeopleSoft PS_TOKEN cookie and returns this, as well as, the content to WebSEAL.
  8. WebSEAL mangles the PS_TOKEN cookie to include the junction point (for example, /financials/PS_TOKEN) and sends the mangled cookie and the PeopleSoft Financials content to the browser.

The example above highlights a number of complexities within this pattern. It shows that in some cases, multiple cookies with the same name mightneed to be managed by WebSEAL and the browser.


WebSEAL considerations

Generic considerations

For each of the portal SSO patterns described above, a consideration is common to each; that is, determining how SSO can be achieved from WebSEAL to the portal server. IBM has developed many integration solutions outlining how SSO can be achieved for a variety of portal products. These solutions include, but are not limited to, the following:

Considerations specific to each of the portal SSO patterns are outlined in the following sections.

Portal proxy SSO pattern

For the Portal proxy SSO pattern, only one WebSEAL junction is required. This junction is created to the portal server, and standard SSO techniques are used to authenticate the TAM user to the portal. The portal handles the requested content from content provider and therefore, a WebSEAL junction is not required to the content providers.

The primary consideration for this pattern is determining how the user's identity makes its way from the Web SSO realm to the Portal SSO realm, that is, how the portal product maps the user's portal identity to the content provider identity. This consideration is outside the scope of this article; however, a possible solution can make use of the TAM Global Sign-On (GSO) Lockbox. The TAM GSO Lockbox allows for the secure storage of resource credentials to be programmatically retrieved using the TAM Admin API. Therefore, a portal product could use the TAM GSO Lockbox to store a user's content provider credentials to be used for authentication in the Portal SSO realm. The use of the TAM GSO Lockbox is available for IBM WebSphere Portal Server.

Proprietary token SSO pattern

This pattern requires the use of multiple WebSEAL junctions. A junction is required to the portal server and each of the content providers. In its most simple form, this pattern requires two junctions.

In order to perform SSO to the portal, the junction to the portal server needs to utilize the WebSEAL SSO techniques. Depending on the portal server, many integration scenarios exist. These can make use of SSO techniques such as basic authentication, HTTP header authentication and forms single sign-on, just to name a few.

Due to the nature of this pattern, the junction to the content providers does not need additional SSO parameters. The token issued by the portal server for the content providers is used to authenticate to the content provider, through the WebSEAL junction. This means that a junction with no additional SSO setup will be sufficient, provided the token issued by the portal server, usually in the form of a cookie, is maintained. More specifically, WebSEAL must be configured to allow the cookie that is generated by the portal to pass from the portal junction through the content provider junction.

Because this pattern involves WebSEAL handling requests to and from the portal server and the content providers, some consideration must be given to the links to the content providers that are supplied by the portal. Specifically, if the links are specified in a fashion that can be handled by the WebSEAL standard URL filtering techniques, the link can simply be the direct URL of the content provider (that is, not the WebSEAL junction version); alleviating the need for the portal administrator to have knowledge of WebSEAL. If, on the other hand, the link cannot be handled by the WebSEAL standard URL filtering techniques - using dynamic client-side Javascript™ for example - the portal administrator must specify the WebSEAL aware version of the URL, that is,. the link must contain the WebSEAL hostname and the appropriate junction to the relevant content provider.

Standard WebSEAL single sign-on pattern

This pattern is similar to the Proprietary Token SSO pattern in that it requires the use of multiple WebSEAL junctions; a junction is required to the portal server, and a junction is required to each of the content providers. As per the Proprietary Token SSO pattern, in order to perform SSO to the portal, the junction to the portal server needs to utilize the WebSEAL SSO techniques. Additionally, consideration of links to content providers must be given, as outlined in the Proprietary Token SSO pattern.

The most significant difference between this pattern and the Proprietary Token SSO pattern is the requirement for WebSEAL to utilize Web SSO techniques to the content providers. The content provider has no knowledge of the portal server and therefore WebSEAL is responsible for providing the user's credentials. This is typically done using the WebSEAL SSO techniques, and is dependant on the content provider's authentication functionality. IBM has developed a number of integration solutions for popular content providers, such as SAP, Siebel, PeopleSoft and Oracle. Refer to the Resources section for a link to the integration solutions.

An additional consideration is managing the cookies created by the portal and the content providers. A new cookie can be generated by every content provider to hold specific identity information for that provider. The browser will store cookies for each of the content providers as well as WebSEAL and the portal server cookies. If there are a large number of content providers or the browser’s cookie jar can only store a few cookies, cookie jar blow-out can occur. Also, as seen in the PeopleSoft example above, cookies might need to be mangled using WebSEAL, so that they are not overwritten in the browser.


Determining which approach to use

An important question in architecting a portal single sign-on solution using a reverse proxy such as WebSEAL is, "What is the best approach to use". Unfortunately, there is no single approach that is compatible with all portal servers and all content providers. A series of guidelines, outlined below, should help determine which approach to use.

Determine the available portal content delivery patterns

The first step is to determine which portal content delivery patterns apply to the portal server being used in the solution. Doing so will likely require in-depth knowledge of the portal server's capabilities. It is recommended that relevant documentation be researched as well as contacting the portal server provider. Most portal servers will, at least, support the portal redirection pattern.

If the portal server provides the portal proxy pattern, it is likely that it will also provide the Portal proxy SSO pattern through the use of a Credential Vault (or some other technology providing similar functionality). However, you should not restrict the options to this pattern.

If the portal server provides only the portal redirection pattern, you will be restricted to either the proprietary token SSO pattern or standard WebSEAL single sign-on pattern.

Determine the available portal SSO patterns

As indicated in the above section, the portal content delivery pattern will likely impact the availability of portal SSO patterns. Then the set of available Portal SSO Patterns is determined, the method of authentication of each of the content providers should be determined.

If the content provider cannot accept a proprietary token from the portal, then the proprietary token SSO pattern is not an option.

Additionally, if there is not a WebSEAL SSO solution developed for the content provider, it might be challenging to determine if the Standard WebSEAL SSO pattern is an option. Note that if no WebSEAL SSO solution exists, this does not imply there is not an option for the Standard WebSEAL SSO Pattern. It may simply impact the complexity of the implementation (as outlined below).

Determine the WebSEAL considerations

Most portal implementations will involve more than one content provider, and thus more than one method of SSO pattern will be required. As outlined in the WebSEAL considerations section, each SSO pattern has an impact on the configuration of WebSEAL. The available SSO patterns should be examined to determine if there is a conflict with the WebSEAL configuration requirements of another SSO pattern that is required by another content provider. Patterns that conflict should be eliminated as an option.

Determine the complexity of implementation

When the set of portal SSO patterns are determined, the final determining factor will be the complexity of implementing each solution. However, determining the complexity is usually subjective. That is, a decision will likely be persuaded by the implementer's capability and skill with the software, and that should be taken into account when designing any Portal SSO solution.

For example, you might find that both the proprietary token SSO pattern and standard WebSEAL single sign-on pattern are available - as is the case with PeopleSoft applications. For PeopleSoft, it is the authors' opinion that configuring the proprietary token SSO pattern is cumbersome and time-consuming when compared to the requirements of the Standard WebSEAL single sign-on pattern. However, this could be because the authors are well versed in the WebSEAL SSO method for PeopleSoft.

Another aspect of the implementation complexity is the impact on performance. No research has been conducted on the impact of the various options; however, it is likely that any solution that requires the decryption of tokens will impact on performance more than a WebSEAL SSO solution.


Conclusion

This article shows that architecting a single sign-on solution that incorporates an enterprise portal, enterprise applications and an authenticating reverse proxy, such as WebSEAL can be more complicated that it would first appear. However, by identifying the portal single sign-on patterns, via a discussion of portal content delivery patterns and single sign-on realms, the complexity of such a solution is reduced. The apparent complexity can be further reduced by the considerations for a solution that is based upon WebSEAL.


Acknowledgements

We would like to acknowledge Ray Neucom for his input towards the single sign-on realms section of this article.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Tivoli (service management), Tivoli
ArticleID=265510
ArticleTitle=TAMeb and portals: Single sign-on concepts and considerations
publish-date=12032007