[ogsa-wg] Express AuthN - Kerberos Forwarding Use Case

[Blair Dillaway]

A brief description of the Kerberos forwarding use-case is provided below so we have it recorded. This use-case was identified by Chris and Bill in response to discussion about whether the Express AuthN profiles should include Kerberos mechanisms. They have reviewed the text below and confirmed it describes the use-case they are concerned about.



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070720/c4138775/attachment.htm