Kerberos Token Forwarding Use Case

 

This use case describes a desired operational mode supporting use of a deployed Kerberos authentication infrastructure 
for grid access control. The grid environment could be within a single organization, or span multiple organizations if 
cross-realm Kerberos trusts have been established. The requirement is to support resource access by a job (J) running on
 behalf of a user (U) based on authenticated user identity and attribute information conveyed in a Kerberos token. The 
user is assumed to only communicate directly with a scheduling service (S) (for example, a BES container service). S 
then determines a suitable computational host and communicates the information necessary to run the user's job on that 
host. It is assumed all the grid services are web services which communicate using SOAP-based protocols.

 

To support this use case, U must be able to authenticate to S using Kerberos. S is then responsible for binding the 
Kerberos authentication information to U's job request. Note that U doesn't know which execution host will eventually 
run J, and therefore can not supply a Kerberos service ticket for the execution host. When S schedules J, it 
authenticates to the execution host based on its identity, and must securely communicates U's Kerberos authentication 
information as part of the job creating request. The execution host then uses U's Kerberos authentication information (
user's account and group membership) to establish the job's security context. This could involve running the job under 
the user's account or obtaining new Kerberos service tickets on-behalf of the user for any required job resources. The 
security context provides the authenticated information that determines the job's rights to access local and/or remote 
resources.

 

Regards,

Blair Dillaway