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.
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:
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.)
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.
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.