Kerberos is an authentication system developed at the Massachusetts Institute of Technology. It uses passwords and symmetric cryptography (DES) to implement a ticket-based, peer-entity authentication service and an access control service distributed in a client-server network environment. The Kerberos authentication server is a central system that knows about every principal and its secret key. It issues tickets to principals who successfully authenticate themselves. These tickets can be used to authenticate one principal (for example, a user) to another (for example, a server application). Moreover, Kerberos sets up a session key for the principals that can be used to protect the privacy and the integrity of the communication.
The following Kerberos Provider Preferences can be set by the user: privateState (yes/no), serviceIdentities, and serviceRealm. These are set in the Server Preferences tab in the Administration Console. For details, please see Server Preferences Management.
The system requirements for Kerberos are located at Sun's Kerberos Requirements page.
On the server side:
Create an account in the KDC. Name it after the path of the service, but without the first and last slash. For example, if the service will be published at http://myserver.com:6060/wasp/hello/kerberos/, the name of the account would be wasp/hello/kerberos.
Set security provider to Kerberos.
Service authentication: Using the ProvidersManager tool, associate the account name and password to the service.
On the client side:
Set the security provider to Kerberos.
Authenticate with the username, password, and Kerberos security provider.
Example 5 demonstrates Kerberos authentication on the client side.
Example 5. Kerberos Authentication on the Client Side
// Copyright 2002 Systinet Corp. All rights reserved. // Use is subject to license terms. package example.security; import org.idoox.security.Credentials; import org.idoox.wasp.WaspSecurity; import org.systinet.wasp.webservice.ServiceClient; public class Client3 { public static void main(String[] args) throws Exception { // create a service client ServiceClient serviceClient = ServiceClient.create("http://localhost:6060/Service3"); // acquire credentials suitable for Kerberos auuthentication mechanism // using WaspSecurity Credentials credentials = WaspSecurity.acquireClientCredentials ("wasp/hello/kerberos", "test", "Kerberos"); // set credentials on the service client WaspSecurity.setCredentials(serviceClient, new Credentials[]{credentials}); // set Kerberos as a initiating security provider WaspSecurity.setInitiatingProvider(serviceClient, "Kerberos"); // create a service proxy ServiceIface service = (ServiceIface) serviceClient.createProxy(ServiceIface.class); // do a call System.out.println(service.doIt("hello")); } }
Authentication on the client side, using a cached ticket (a ticket created during login to workstation) is shown in Example 6
Example 6. Kerberos Authentication on the Client Side Using a Cached Ticket
// Copyright 2002 Systinet Corp. All rights reserved. // Use is subject to license terms. package example.security; import org.idoox.security.Credentials; import org.idoox.wasp.WaspSecurity; import org.systinet.wasp.webservice.ServiceClient; public class Client3 { public static void main(String[] args) throws Exception { // create a service client ServiceClient serviceClient = ServiceClient.create("http://localhost:6060/Service3"); // acquire credentials suitable for Kerberos auuthentication mechanism // using WaspSecurity Credentials credentials = WaspSecurity.acquireClientCredentials("", "", "Kerberos"); // set credentials on the service client WaspSecurity.setCredentials(serviceClient, new Credentials[]{credentials}); // set Kerberos as a initiating security provider WaspSecurity.setInitiatingProvider(serviceClient, "Kerberos"); // create a service proxy ServiceIface service = (ServiceIface) serviceClient.createProxy(ServiceIface.class); // invoke the service System.out.println(service.doIt("hello")); } }
The following are the steps needed to run cross-domain authentication, that is authentication when client and server do not use the same KDC.
First, you must configure the KDCs to trust each other (for information on this configuration, see Microsoft's Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability.
Nothing more needs to be done on the server side.
On the client side, determine the realm used by the service that you are looking up using org.idoox.wasp.security.kerberos.KerberosConfig.
As described above, the service's principal name is derived from the URI of the service by default. If you want to have only one Kerberos principal for the whole server, or the principal name is different from the service endpoint path, you must map the service endpoint or server URI to the principal name (identity) as shown in the org.idoox.wasp.security.kerberos.KerberosConfig Javadoc.