Introduction to WebSphere Application Server SAML Trust Association Interceptor

Brief introduction

IBM WebSphere Application Server (and a bunch of products running on top of the WebSphere Application server platform) has been based on a trust association since V5.1 Intercepto The customizable authentication framework for the R (TAI) interface. This interface has a variety of product implementations. The WebSphere application Server Full Profile version of 2012 provides a new SAML (Security assertion Markup Language, secure Assertion Markup Language) TAI, which is available for WebSphere Application Server 7.0, 8.0, and 8.5. (While writing this article, the IBM WebSphere application Server Liberty configuration file does not support SAML.) This Tai is currently the most comprehensive Tai. This article will introduce:

How to use the SAML TAI.

When it is appropriate to use the SAML TAI.

How the various SAML TAI properties work together.

The intricate path used by the SAML TAI shuttle in the WebSphere application Server licensing process.

This article assumes that you have a firm grasp of the WebSphere Application Server authentication process (described in advanced authentication in the article WebSphere Application Server), and that you understand:

Digital signatures

Encryption

Identity Assertion

The general knowledge of TAI.

Basics: Web Single sign-on use case

The SAML TAI introduces support for the new Web single sign-on (SSO) Form. As we said in the WebSphere application Server security class, the term "SSO" is heavily overused in the industry, so our SSO use cases will be very stringent.

SAML has evolved over the years. The SAML 2.0 specification defines some configuration files and bindings:

The SAML configuration file describes the different message exchange sequences between the various parties in the SSO interaction.

The SAML binding describes how to bind a particular message to a protocol. In any step in the message exchange sequence of a configuration file, a configuration file can refer to one or more bindings as a way to forward a message.

The SAML configuration file includes:

SSO configuration file

Web Browser SSO Profile

Enhanced Client or Proxy profile

Identity Provider Discovery Profile

Single Logout profile

Name Identity Management Profile

Artifact Resolution profile

Assertion Query/request Profile

Name Identifier Mapping Profile

SAML Attribute Profiles

The SAML bindings include:

SAML SOAP Binding

Reverse SOAP Binding

HTTP Redirect Binding

HTTP Post Binding

HTTP Artifact Binding

SAML URI Binding

WebSphere application Server supports soap through the SAML soap Binding, starting with the Fix pack 7.0.0.7. The SAML TAI is introduced in the repair pack 7.0.0.23, 8.0.0.5, and 8.5.0.0 of the base product. The SAML TAI supports only the use of the Web Browser SSO profile and the HTTP Post Binding.

As you can see, this is just one of a number of possible use cases. In fact, there are actually two variants. Before we introduce them, let's start by introducing the roles involved:

Identity provider (IdP)

A service provider (SP) is sometimes called a repeater (relying party) or an RP.

The IDP effort is to verify that the end user (the exact way the IDP completes this operation is irrelevant) and generate some assertions or statements about the user. These assertions are digitally signed by the IdP. The SAML specification defines the format of these assertions. The SP receives the assertion and, if it is satisfied with the assertion from the trusted IdP, lets the user log on based on certain portions of the assertion.

We will also look at an example based on a real use case. Unified Assurance Company (UAC) has many corporate customers, for example, Gamma Business Machine (GBM), Omicron Lumber, and Purple Maple C Ompany. We consider these 4 (fictitious) companies to be located in an SSO chain. In this example, unified Assurance Company understands the employees of these 3 chain members (UAC LDAP has user entries for employees with external chain members). However, there is no password for a chain member in UAC LDAP.

In this case, unified Assurance wants to provide an IBM WebSphere Portal system to its external and internal users. Users from GBM will authenticate to a system in GBM, Omicron Lumber users to a system in the Omicron Lumber network, and Purple Maple the user to authenticate to a system hosted by Google. (In this case, the use of the WebSphere Portal system is accidental.) ）

Figure 1. SSO Chain Example