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

[Hiro Kishimoto]

Thanks Blair,

Your use case is now in issue tracker for AuthN use case document.

https://forge.gridforum.org/sf/go/artf5957

Duane: Please take it from here.

Thanks,
----
Hiro Kishimoto

-------- Original Message  --------
Subject: [ogsa-wg] Express AuthN - Kerberos Forwarding Use Case
From: Blair Dillaway <blaird at microsoft.com>
To: ogsa-wg at ogf.org <ogsa-wg at ogf.org>
Cc: Bill Nitzberg <nitzberg at pbspro.com>
Date: 2007/07/21 4:55

> 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
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> --
>   ogsa-wg mailing list
>   ogsa-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-wg