test

Sun Java System Access Manager 7.1 Federation and SAML Administration Guide

Authentication Web Service Overview

The SOAP specifications define an XML-based messaging paradigm, but do not specify any particular security mechanisms. Particularly, they do not describe user authentication using SOAP messages. To rectify this, the Authentication Web Service was implemented based on the Liberty ID-WSF Authentication Service and Single Sign-On Service Specification. The specification defines a protocol that adds the Simple Authentication and Security Layer (SASL) authentication functionality to the SOAP binding described in the Liberty ID-WSF SOAP Binding Specification and, Chapter 9, SOAP Binding Service in this guide. The Authentication Web Service is for provider-to-provider authentication.

Note –

The specification also contains an XML schema that defines the authentication protocol. More information can be found in Schema Files and Service Definition Documents.

This overview contains the following sections:

XML Service File

The Authentication Web Service is configured using the XML service file amAuthnSvc.xml. This file defines the attribute for the Authentication Web Service which can be managed through the Access Manager console or the XML file.

Note –

For information about service files, see the Sun Java System Access Manager 7.1 Administration Guide.

Authentication Web Service APIs

The Access Manager Authentication Web Service includes the following Java programming packages:

The first package is a client API for external Java applications to send SASL requests and receive SASL responses. The second package defines an interface to handle different SASL mechanisms. The final package contains classes that represent the SASL request and response. Together, the packages are used to initiate the authentication process and communicate authentication credentials to the Authentication Web Service. For more information, see the Authentication Web Service API.

Which Authentication Service to Use?

The Liberty-based Authentication Web Service is not to be confused with the proprietary Authentication Service discussed in the Sun Java System Access Manager 7.1 Administration Guide. Architecturally, the Authentication Web Service sits on top of the Access Manager Authentication Service and the Liberty Alliance Project framework. You might use the Authentication Web Service if you are a service provider and want to use a standards-based mechanism to authenticate users.

Following are two use cases where the Authentication Web Service is preferable to the Access Manager Authentication Service:

In addition to providing an authentication service to verify credentials (for example, user ID and password), the Authentication Web Service provides the web services consumer (WSC) with bootstrap information that contains the endpoint and credentials needed to access the Discovery Service (as discussed in Chapter 8, Discovery Service). The WSC can ignore the bootstrap or use it to access other web services, such as the authenticated user's personal profile or calendar.

Note –

An authenticated enterprise might also use the bootstrap information to access a partner in a business-to-business environment.

Following is an example that shows how the Authentication Web Service interacts with the Access Manager Authentication Service. It assumes the following separate entities:

The WSC delegates all authentication to the identity provider and prefers PLAIN authentication which accepts a user identifier and password.

  1. The user attempts access to a service provider (not necessarily hosted by Access Manager).

  2. When the service provider finds that the user is not authenticated, it invokes the identity provider's Authentication Web Service by sending it a SOAP request.

  3. After inspecting its configuration, the Authentication Web Service sends back a response indicating that it supports Certificate and PLAIN authentication.

  4. The service provider decides on PLAIN authentication and prompts the user for an identifier and password.

  5. Interactions based on the standard PLAIN authentication mapping ensues between the service provider and identity provider (hosted on Access Manager) using the Authentication Web Service.

    1. The service provider receives the user identifier and password and sends it to the identity provider.

    2. The identity provider passes the credentials to the locally hosted LDAP Authentication module using the proprietary Access Manager Authentication Service's Java API.

    3. The LDAP Authentication module verifies the credentials.

    4. The Authentication Web Service is notified of the verification and sends a response to the service provider indicating successful authentication. If configured to do so, it also includes bootstrap information formatted using XML and containing the Discovery Service endpoint and a token to invoke it.

  6. The service provider parses the response, verifies that it is a successful authentication, and provides the service to the user.

At some point the service provider might need to access the user's personal profile. To do this, it will use the bootstrap information received during this process to contact the Discovery Service and find where the profile is stored. The Discovery Service returns a resource offering (containing a token and the location of an endpoint), and the service provider uses that to invoke the Liberty Personal Profile Service.