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 2005Q4 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:
A service provider relies on a remote identity provider (not necessarily using Access Manager) for authentication.
An enterprise in a service-oriented architecture (SOA) environment wants to use nonproprietary mechanisms to authenticate users and web services clients before accessing a protected web 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 7, 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.
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:
A user (principal)
A service provider (acting as a WSC)
An identity provider hosted by Access Manager where the Access Manager Authentication Service is configured for Certificate and LDAP authentication and the Authentication Web Service has mapped LDAP to its own PLAIN authentication mechanism
The user's personal profile (hosted by another product)
The WSC delegates all authentication to the identity provider and prefers PLAIN authentication which accepts a user identifier and password.
The user attempts access to a service provider (not necessarily hosted by Access Manager).
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.
After inspecting its configuration, the Authentication Web Service sends back a response indicating that it supports Certificate and PLAIN authentication.
The service provider decides on PLAIN authentication and prompts the user for an identifier and password.
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.
The service provider receives the user identifier and password and sends it to the identity provider.
The identity provider passes the credentials to the locally hosted LDAP Authentication module using the proprietary Access Manager Authentication Service's Java API.
The LDAP Authentication module verifies the credentials.
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.
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 the location of an endpoint and a token), and the service provider uses that to invoke the Liberty Personal Profile Service.