[OGSA-AUTHZ] minutes of yesterdays telecon

[Yuri Demchenko]

David and Blair,

I want to repeat and extend on what I explained during the teleconf
regarding AuthZ assertions use and validation.

In some our projects and use cases we are developing AuthZ
infrastructure for multidomain complex resource provisioning that:

first, should allow combination and communication of individual AuthZ
decisions in multiple domains (of which some may depend on previous);
this is a long and multi-step process

and second, enforce final combined AuthZ decision (actually reservation)
in the most effective way, in sense of performance.

I don't see how we can avoid using AuthZ assertions that carry full
AuthZ decision context.

Yuri

Blair Dillaway wrote:
> I'm suggesting that is one operational model that may be desired. 
> A resource site may be designed to consume authZ assertions generated 
> by a TTP. Off-loading more complex authZ policy resolution to a TTP 
> could be done for better resource server perf, because the resource 
> server doesn't have full knowledge of its organization's federated 
> trust policy (if roles are assigned in an external org), etc.
> 
> /Blair
> 
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: Thursday, February 15, 2007 10:30 AM
> To: Blair Dillaway
> Cc: OGSA AUTHZ WG
> Subject: Re: [OGSA-AUTHZ] minutes of yesterdays telecon
> 
> Hi Blair
> 
> thanks for your comments. I have one question below
> 
> Blair Dillaway wrote:
> 
> CUT
> 
>> I may not have the complete context here, but seems to me there may
>> be an important difference in some environments. The policy for
>> controlling the assignment of permissions based on roles may not be
>> available at the site where an authorisation assertion is validated
>> and consumed. In such cases, the role needs to validated and an
>> authorisation assertion generated even if they have a 1:1 mapping.
> 
> I would like to clarify the above. The site where an authz assertion is
> validated and consumed must be the resource site. Correct? So you are
> saying that the resource site has no control over which roles give
> permissions to access it, and instead it trusts an external TTP to say
> who has permission to access it. Is this your model?
> 
> regards
> 
> David
> 
Blair Dillaway wrote:
> 
>         3.Authorisation assertion validation. Again Trust roots
>         need to be configured in, to say who is trusted to assign
>         which privileges to which groups of users. David said that
>         he thought that the only difference between 2. and 3. was
>         in the granularity, and that if a role (or attribute) only
>         gave a single permission, then 2. could be used and there
>         was no requirement for 3.
> 
> I may not have the complete context here, but seems to me there may 
> be an important difference in some environments. The policy for 
> controlling the assignment of permissions based on roles may not 
> be available at the site where an authorisation assertion is 
> validated and consumed. In such cases, the role needs to validated 
> and an authorisation assertion generated even if they have a 1:1 mapping.
> 
> 
> Regards,
> Blair
> 
> -----Original Message-----
> From: ogsa-authz-wg-bounces at ogf.org [mailto:ogsa-authz-wg-bounces at ogf.org] On Behalf Of David Chadwick
> Sent: Wednesday, February 14, 2007 4:28 AM
> To: OGSA AUTHZ WG
> Subject: [OGSA-AUTHZ] minutes of yesterdays telecon
> 
> Are now on the grid forum at
> 
> http://forge.gridforum.org/sf/go/doc14236?nav=1
> 
> regards
> 
> David
> 
> --
> 
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Skype Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
>