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@ogf.org [mailto:ogsa-authz-wg-bounces@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@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@ogf.org [mailto:ogsa-authz-wg-bounces@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@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg