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 *****************************************************************
My apologies for missing the call. I was on a GFSG call. I had planned to use Skype, so perhaps I wouldn't have been successful calling in. A couple of comments on the proposed AVS for Globus: 1.Validation of Identity assertion. Checking that a DN belongs to a public key and is trusted up to CA trust root. David said this code should already exist in the PKI world .... Certainly, in open source and commercial products. You should think about if you need to support things like cross-certification; bridge CAs; or special EKUs, before picking a tool. How these things are handled can vary. 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. Finally we discussed the implications of carrying attributes and credentials within the same protocol.... The group did not see a problem in this. Thus it is left to Blair to raise his concerns on the list, since he raised the issue originally. My earlier comments were made to encourage discussion of the potential impact of these design decisions on implementers. I still believe its healthy to have that discussion during the design process. I am not arguing that the approach of carrying credentials as attribute types is wrong or can't be implemented, just that it has some impacts that should be considered. For example: - There is an already standardized, and implemented, approach to encoding credentials in SOAP messages as security tokens (UsernameToken, BinarySecurityToken, saml:Assertion, ...). I believe the proposal is to standardize a new set of SAML attribute type identifiers that define yet another way of encoding these credential types in XML. That means if we're sending an authenticated SOAP message using this mechanism, the implementation must support two code paths for serializing/de-serializing each possible credential type. Perhaps not a big deal, but it adds some complexity and long-term support costs. - If real attributes and credentials are both passed as an 'attribute' encoding, it impacts error handling. The code responsible for attribute decoding will need to handle both errors in initial attribute decoding as well as problems that may arise in trying to decode and validate a received credential. - Compliant implementations would need to properly handle all legal attribute types (real attributes or credentials), even if the service doesn't accept and process credentials. Again, some impact on potential failure modes and error handling. Perhaps others that are actually thinking about implementations can add to these. Its good to make a conscious decision that the benefits of the proposed design outweigh such considerations. I should also point out that while I am interested in this subject, my work and broader OGF commitments are leaving me little time to actually think about it. So, not sure how much I can contribute in the near term. 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
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
***************************************************************** 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 *****************************************************************
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
***************************************************************** 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 *****************************************************************
Thanks for the clarification David 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
***************************************************************** 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
*****************************************************************
-- ***************************************************************** 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 *****************************************************************
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
Yuri, 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. 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. Regards, Blair Dillaway -----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
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
participants (3)
-
Blair Dillaway -
David Chadwick -
Yuri Demchenko