Kerberos Credentials

In a Kerberos environment, clients obtain tickets that grant them access to interact with a particular server for a particular period of time. Servers are able to verify the validity of these tickets and of the user's identity. Symmetric encryption is used to secure the tickets and keys that are exchanged in a Kerberos environment.

The Web Services Security Kerberos Token Profile (available from http://www.oasis-open.org) specifies how Kerberos-based credentials can be passed in a WS-Security header.

Kerberos overview

A Kerberos environment requires the presence of one or more Kerberos Key Distribution Centers (KDCs). A KDC generates the encryption keys and tickets that are used in the environment. The next graphic illustrates the exchanges that occur in a typical Windows Kerberos-based client/server interaction (a UNIX Kerberos interaction would be conceptually identical):

Kerberos KDC generates encryption keys and tickets that are passed to the Web services listener

The following steps occur in this graphic:

1. For authentication purposes, the client logs in to the Windows domain. The operating system collects the user's name and password and sends them to a KDC.
2. The KDC works with a directory service to validate the user's credentials and returns a ticket-granting ticket (TGT) to the caller.
3. Because the client wishes to access a particular server, a ticket-granting exchange must occur. The client sends a second request to the KDC, specifying the service that it wishes to access. (Note that if the client had previously been granted a service ticket and it has not yet expired, then steps 3 and 4 would be skipped).
4. The KDC issues a service ticket, which grants the caller access to that service.
5. The client sends its request with the service ticket encoded in a WS-Security Kerberos token to the server.
6. The Web service listener on the Content Platform Engine server performs a JAAS login using credentials supplied in the incoming WS-Security header.
7. The JAAS LoginModule validates the client's ticket. No roundtrip to the KDC is necessary. The server is able to use its own key (obtained from the KDC at startup time) to validate service tickets. The LoginModule produces a valid JAAS subject, based on the successful validation of the ticket. This JAAS subject is returned to the Content Platform Engine Web service listener.
8. The Content Platform Engine Web service listener passes the call along (with valid JAAS subject) to the Content Platform Engine EJB layer.

When Kerberos tokens are sent in a WS-Security header, a secure, private channel, such as an HTTPS (SSL) connection, is not required between the client and the server, as the tickets sent in a Kerberos request are already encrypted. (Customers can use an HTTPS connection anyway to ensure privacy for information contained in the request and response bodies.)

Microsoft's use of Kerberos

Starting with Windows 2000, Microsoft embraced the Kerberos standard, and based the Windows authentication process on it. A Windows domain controller acts as a Kerberos KDC, and a Windows domain is equivalent to a Kerberos realm. Microsoft's use of Kerberos to authenticate Windows clients improved Windows scalability, and allowed interoperability with other non-Windows clients.

However, Microsoft's Kerberos implementation is not entirely compatible with the MIT implementations. Microsoft has made minor changes to the protocol that have introduced compatibility issues. With some work and some caveats, however, Windows and UNIX Kerberos clients can be made to interact.

Kerberos forms the basis for the Windows Integrated Logon capability that allows a Windows client to log in to the network and access network resources across the Windows domain (and in some cases, in other Windows domains).

Microsoft provides a Web services development toolkit called Web Services Extensions (WSE) for creating Web service-enabled client and server applications. WSE supports the use of Kerberos credentials, obtained from the client's environment, to generate WS-Security-compliant Kerberos tickets. FileNet® P8 supports the use of these tickets in FileNet P8 Web services, allowing Windows clients who have logged onto the domain to access FileNet P8 Web services without providing any additional credentials.

Through use of Kerberos tokens, Web service client applications can be developed allowing single sign-on with FileNet P8 Web services in a Windows Integrated Logon environment.

Sample Kerberos token

Kerberos tokens are encoded in a WS-Security header using the standard <wsse:BinarySecurityToken> element. The Kerberos Token Profile defines how each of the attributes within this token must be set when sending Kerberos tokens. An example of a WS-Security header containing a Kerberos token is shown below (some of the namespace values have been truncated):

<wsse:Security soap:mustUnderstand="1">
<wsu:Timestamp
wsu:Id="Timestamp-a475236f-c2c8-4c37-a280-f6ae043b09dd">
<wsu:Created>2005-04-09T00:17:53Z</wsu:Created>
<wsu:Expires>2005-04-09T00:22:53Z</wsu:Expires>
</wsu:Timestamp>
<wsse:BinarySecurityToken
ValueType ="wsse.Kerberosv5ST"
EncodingType="wsse.Base64Binary"
xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-3b4344fc-374f-4e71-9d1c-e6a356a62f6b">YYID
... pPZt
 </wsse:BinarySecurityToken>
</wsse:Security>

For information on the ValueType and EncodingType values, see the WS-Security specification.

When a Web service request containing a Kerberos token arrives at a FileNet P8 Content Platform Engine Web service, the Web service listener extracts the token from the WS-Security header, and uses it to perform a JAAS login using a FileNet P8-provided, application server specific Kerberos Login Module. Once the JAAS login has completed successfully, the FileNet P8 Web service listener is now in possession of a JAAS Subject, and can pass the call along to Content Platform Engine via the EJB transport.

See also Kerberos for Content Platform Engine for more details on using Kerberos.