[OGSA-AUTHZ] minutes of yesterdays telecon

Wed Feb 21 13:20:34 CST 2007

Blair Dillaway wrote:
> I agree there are environments where communicating an authZ 
> decision between systems makes sense. I'm uncertain as to what 
> you mean by "AuthZ assertions that carry full AuthZ decision 
> context". Can you expand on this.
> 
Initially, we considered (and actually implemented) this functionality 
for the AuthZ session management.

Under "full AuthZ decision context" I mean (AuthZ Decision) + (all info 
from the Request) + (policy reference).

> It sounds like you're expecting the relying party at the resource 
> system to be able to 're-verify' the full policy evaluation that 
> led to access being granted. I do not believe that is generally 
> necessary or desirable.
> 
If considered in the context of the AuthZ session, this is actually not 
"re-verifying" PDP/policy decision, but simply matching AuthZ assertion 
content/data and a new request content. If they match 1:1, access is 
granted.

This is actually similar to the COPS policy dissemination and 
enforcement model.

I would be interested to discuss if this represents a special use case 
or there may be other solutions to achieve the same functionality.

Yuri

> 
> -----Original Message-----
> From: ogsa-authz-wg-bounces at ogf.org [mailto:ogsa-authz-wg-bounces at ogf.org] On Behalf Of Yuri Demchenko
> Sent: Wednesday, February 21, 2007 8:57 AM
> To: OGSA AUTHZ WG
> Subject: Re: [OGSA-AUTHZ] minutes of yesterdays telecon
> 
> 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
>>
> 
> 
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg