Building an authentication

So, what is a Liberty Authentication Service (PDF) (AS) good for? With the word 'authentication' in the title, you'd expect that it would be used for authenticating someone, and you'd be right on the money there. Because the Liberty AS uses, and is part of the Identity Web Services Framework, it uses the Liberty SOAP Binding - that means an authentication request carries the relevant SOAP header blocks to allow message correlation, message timestamps and that sort of thing. In addition to these necessary SOAP headers comes the actual SOAP body content. The SOAP body represents the application message, and the application here is an authentication service, so the body of a SOAP request contains an authentication request, and the SOAP response will similarly contain an authentication response. The AS allows what's called a challenge-response authentication to occur - the AS can challenge the requestor to do something in real-time, which is a good thing from an authentication perspective.

The Liberty AS uses the Simple Authentication and Security Layer (SASL) and binds SASL mechanisms to a SOAP message. I'm not going to go into any detail about that as there's lots of fine material available about SASL, but SASL is used to provide authentication for applications like OpenLDAP, and there are SASL mechanisms available for IMAP/POP mail and several other connection-based protocols. This means that if you already have a piece of software that provides the actual SASL authentication, the only piece missing in also providing a Liberty AS is the binding of the SASL protocol mechanisms you support to SOAP.

Here's what a SOAP-based SASL authentication looks like:

1. A client asks to be authenticated

001 <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

002   <S:Header>
003     <sb:Correlation xmlns:sb="urn:liberty:sb:2003-08"
004       messageID="C8797D0D-9020-07FC-AF0A-5622C01F4A61"
005       timestamp="2005-12-21T19:43:45Z"/>
006   </S:Header>

007   <S:Body>
008     <sa:SASLRequest xmlns:sa="urn:liberty:sa:2004-04"
009       mechanism="PLAIN ANONYMOUS CRAM-MD5"
010       advisoryAuthnID="012345678901234"/>
011   </S:Body>

012 </S:Envelope>

At line 003, you'll see a sb:Correlation SOAP header block. This is used to pass a message identifier and timestamp to the server. These are used to a) provide a bound on a message cache (a list of message identifiers recently received), to prevent a replay attack (someone sending the same message multiple times within some timeframe) and b) allow the sender of the message to correlate any reply it receives to the message that the sender originally sent. These provide a small measure of security in this insecure world. The format shown in this message is based on the Liberty ID-WSF 1.1 specification. A newer version of the specification uses WS-Addressing defined SOAP header blocks to perform these functions. For those that care about the size of their SOAP messages (including anyone sending SOAP messages over a mobile GPRS network!) the ID-WSF 1.1 Correlation header block is a fair bit more compact representation of the same information, due to the use of XML attributes to carry the timestamp and message identifier, rather than individually defined SOAP header blocks for each of those elements.

Now, to the body. At line 008 you see the SASLRequest - the thing that binds a SASL mechanism to SOAP. In line 009 you can see the mechanisms that the client says it supports, using the SASL mechanism names defined by the relevant IETF specifications for each mechanism, and in line 010 the "advisoryAuthnID" can be used to hold advisory (ie. a hint) information about the identity of the requester - so if a particular user account name were associated with some account number, this attribute could be used to send that information.

2. The server's first response - carry on authenticating

001 <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

002   <S:Header>
003     <sb:Correlation s:mustUnderstand="1" xmlns:sb="urn:liberty:sb:2003-08"
004       messageID="uuid-7062c9fe-8f38-40a8-b8d6-88e45d4d4e3e"
005       refToMessageID="C8797D0D-9020-07FC-AF0A-5622C01F4A61"
006       timestamp="2005-12-21T19:44:37Z"/>
007   </S:Header>

008   <S:Body>
009     <SASLResponse serverMechanism="CRAM-MD5" xmlns="urn:liberty:sa:2004-04">
010       <Status code="continue"/>
011       <Data>PGYzNTE3OGU1LTQ0MDEtNDA1Yi1hMzE4LWYxYWU4NjNkOTc1Nj4=</Data>
012     </SASLResponse>
013   </S:Body>
014 </S:Envelope>

As you can see in lines 003-006, this message also has a Correlation SOAP header block, but in line 005 the "refToMessageID" shows that this message is in response to the message which has the given identifier. The server indicates in line 009 that it wishes to use the CRAM-MD5 SASL mechanism, and in line 010, you see a status code indicating that the server wants the client to continue the authentication protocol (rather than failing because of some error, or succeeding because the authentication was successful). Finally, in line 011 is the data that pertains to the actual authentication. This data is a Base64-encoded piece of data chosen as a challenge by the AS. The challenge is used to help assure that the server is dealing with a current authentication request, rather than something stolen and cached by a malicious client. The client is then required by the CRAM-MD5 mechanism to send back the challenge data in a form mandated by the CRAM-MD5 SASL mechanism.

In the style of serialized thrillers, I'm going to leave it there for now. The server has issued a teasing challenge to the client's request for authentication, but the client is not authenticated. What happens next? You'll have to wait and see.