OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-09-2014 09:21
    Submitter's message All,

    I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that.

    Thanks,
    Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56


  • 2.  Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-11-2014 15:33
    All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56


  • 3.  RE: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-11-2014 17:19
    The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory.   I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability.   Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and  identify areas for proprietary extension.   Hal   From: Erik Rissanen [mailto:erik@axiomatics.com] Sent: Thursday, December 11, 2014 10:33 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56  


  • 4.  Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-12-2014 08:57
    Hi Hal, Sure, I did not mean to say that there should be no work. I just meant that I don't find this work very interesting, and it might be potentially limiting on products. But I could be persuaded otherwise. :-) As of an example of metadata, let's say that you have a policy editor which allows you to browse a cohort and edit it. The last edit position and how the cohort was expanded in view to the user at last edit time is something that the editor might want to save in the cohort for the user's convenience. It would be a pity if a standard file format for a cohort would prevent a vendor to do something like this or other user enhancements. BTW, I don't like the term cohort . It is not descriptive to end users, and even if we would think of it as a technical term, these technical terms tend to trickle up to the user level one way or another in the end. I would prefer something more user friendly. Best regards, Erik On 2014-12-11 18:18, Hal Lockhart wrote: The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory.   I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability.   Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and  identify areas for proprietary extension.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, December 11, 2014 10:33 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56  


  • 5.  RE: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-12-2014 09:34
    Hi Erik,   The purpose of this discussion is not to limit products, but to make them more interoperable.   The meta-data example you gave seems like data for the policy editor, so I would think it would be stored with the editor, not in a PRP, since it doesn’t have to be available for a PDP.   Anyway, we can’t even have these kinds of discussions if we don’t agree that there is such a thing as a PRP. Currently, the core spec says: “the communications between the PDP and the PAP may be facilitated by a repository.  The XACML specification is not intended to place restrictions on the location of any such repository, or indeed to prescribe a particular communication protocol for any of the data-flows.” I don’t want to prescribe a protocol, but I do think having an optional standard communication protocol between PDP/PAP and PRP may improve interoperability.     Thanks, Ray     From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen Sent: Friday, December 12, 2014 9:56 AM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   Hi Hal, Sure, I did not mean to say that there should be no work. I just meant that I don't find this work very interesting, and it might be potentially limiting on products. But I could be persuaded otherwise. :-) As of an example of metadata, let's say that you have a policy editor which allows you to browse a "cohort" and edit it. The last edit position and how the cohort was expanded in view to the user at last edit time is something that the editor might want to save in the cohort for the user's convenience. It would be a pity if a standard file format for a cohort would prevent a vendor to do something like this or other user enhancements. BTW, I don't like the term "cohort". It is not descriptive to end users, and even if we would think of it as a technical term, these technical terms tend to trickle up to the user level one way or another in the end. I would prefer something more user friendly. Best regards, Erik On 2014-12-11 18:18, Hal Lockhart wrote: The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory.   I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability.   Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and  identify areas for proprietary extension.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, December 11, 2014 10:33 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56    


  • 6.  RE: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-15-2014 15:56
    I am open to suggestions. The obvious term is policy set, but that is too easily confused with <PolicySet> which it may or may not correspond to.   Cohort is a perfectly good English language word and is in widespread use in the social sciences to express a similar concept. (individuals of similar age as they move through time, e.g. Baby Boomers, Millennials) I actually LIKE the fact that it has no other common meaning in security or computer science. In an industry which frequently invents new terms for things which already have a perfectly good one (e.g. Claims – Attributes), I am happy to introduce a new term for a relatively new concept with no current name.   Would you prefer we invent a totally new word like “Gorp”? That doesn’t seem very user friendly to me. I don’t see how one can use XACML or ABAC in general without learning a couple of new things. Apparently you consider PDP and PEP descriptive. Along the same lines, how about PIFAST? (Policies In Force At the Same Time).   The name Cohort does not matter to me. The important thing is that in general, a group of policies intended to be used at the same time must be tested, analyzed and deployed as a unit. One cannot, for example update the currently active Cohort by changing and testing one policy. One must test the policy in combination with the rest of the Cohort and conceptually update the entire Cohort. Of course for efficiency we don’t need to transmit anything that has not changed, but that is merely an optional optimization.   The primary requirement coming from the field is to have the ability to distribute policies from a repository to PDPs which are independent implementations. I think we should also support features such as pre-staging. (These policies go in effect at midnight. The PDP receives them at 8 PM and holds them until midnight. It then begins using them for new decision requests, while still using the old Cohort for requests in progress.)   My suspicion (assumption?) is that one result of the PAP architecture exercise of will be that we leave the whole – editing, testing, analysis, version control part of the architecture a black box.   WRT to your idea of Cohort metadata, that sounds perfectly reasonable to me. Policies have comments and extension points where you can add metadata which is not defined by XACML. I don’t see why similar things can’t appear in a Cohort.   Hal   From: Erik Rissanen [mailto:erik@axiomatics.com] Sent: Friday, December 12, 2014 3:56 AM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   Hi Hal, Sure, I did not mean to say that there should be no work. I just meant that I don't find this work very interesting, and it might be potentially limiting on products. But I could be persuaded otherwise. :-) As of an example of metadata, let's say that you have a policy editor which allows you to browse a "cohort" and edit it. The last edit position and how the cohort was expanded in view to the user at last edit time is something that the editor might want to save in the cohort for the user's convenience. It would be a pity if a standard file format for a cohort would prevent a vendor to do something like this or other user enhancements. BTW, I don't like the term "cohort". It is not descriptive to end users, and even if we would think of it as a technical term, these technical terms tend to trickle up to the user level one way or another in the end. I would prefer something more user friendly. Best regards, Erik On 2014-12-11 18:18, Hal Lockhart wrote: The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory.   I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability.   Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and  identify areas for proprietary extension.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, December 11, 2014 10:33 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56    


  • 7.  Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-15-2014 20:48
    Corpus/Corpora is another option with similar heritage.  b On Dec 15, 2014, at 7:55 AM, Hal Lockhart < hal.lockhart@oracle.com > wrote: I am open to suggestions. The obvious term is policy set, but that is too easily confused with <PolicySet> which it may or may not correspond to.   Cohort is a perfectly good English language word and is in widespread use in the social sciences to express a similar concept. (individuals of similar age as they move through time, e.g. Baby Boomers, Millennials) I actually LIKE the fact that it has no other common meaning in security or computer science. In an industry which frequently invents new terms for things which already have a perfectly good one (e.g. Claims – Attributes), I am happy to introduce a new term for a relatively new concept with no current name.   Would you prefer we invent a totally new word like “Gorp”? That doesn’t seem very user friendly to me. I don’t see how one can use XACML or ABAC in general without learning a couple of new things. Apparently you consider PDP and PEP descriptive. Along the same lines, how about PIFAST? (Policies In Force At the Same Time).   The name Cohort does not matter to me. The important thing is that in general, a group of policies intended to be used at the same time must be tested, analyzed and deployed as a unit. One cannot, for example update the currently active Cohort by changing and testing one policy. One must test the policy in combination with the rest of the Cohort and conceptually update the entire Cohort. Of course for efficiency we don’t need to transmit anything that has not changed, but that is merely an optional optimization.   The primary requirement coming from the field is to have the ability to distribute policies from a repository to PDPs which are independent implementations. I think we should also support features such as pre-staging. (These policies go in effect at midnight. The PDP receives them at 8 PM and holds them until midnight. It then begins using them for new decision requests, while still using the old Cohort for requests in progress.)   My suspicion (assumption?) is that one result of the PAP architecture exercise of will be that we leave the whole – editing, testing, analysis, version control part of the architecture a black box.   WRT to your idea of Cohort metadata, that sounds perfectly reasonable to me. Policies have comments and extension points where you can add metadata which is not defined by XACML. I don’t see why similar things can’t appear in a Cohort.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Friday, December 12, 2014 3:56 AM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   Hi Hal, Sure, I did not mean to say that there should be no work. I just meant that I don't find this work very interesting, and it might be potentially limiting on products. But I could be persuaded otherwise. :-) As of an example of metadata, let's say that you have a policy editor which allows you to browse a cohort and edit it. The last edit position and how the cohort was expanded in view to the user at last edit time is something that the editor might want to save in the cohort for the user's convenience. It would be a pity if a standard file format for a cohort would prevent a vendor to do something like this or other user enhancements. BTW, I don't like the term cohort . It is not descriptive to end users, and even if we would think of it as a technical term, these technical terms tend to trickle up to the user level one way or another in the end. I would prefer something more user friendly. Best regards, Erik On 2014-12-11 18:18, Hal Lockhart wrote: The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory.   I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability.   Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and  identify areas for proprietary extension.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, December 11, 2014 10:33 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56    


  • 8.  Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 12-16-2014 07:49
    In Axiomatics product we use Policy Package for this concept. Best regards, Erik On 2014-12-15 21:47, Bill Parducci wrote: Corpus/Corpora is another option with similar heritage.  b On Dec 15, 2014, at 7:55 AM, Hal Lockhart < hal.lockhart@oracle.com > wrote: I am open to suggestions. The obvious term is policy set, but that is too easily confused with <PolicySet> which it may or may not correspond to.   Cohort is a perfectly good English language word and is in widespread use in the social sciences to express a similar concept. (individuals of similar age as they move through time, e.g. Baby Boomers, Millennials) I actually LIKE the fact that it has no other common meaning in security or computer science. In an industry which frequently invents new terms for things which already have a perfectly good one (e.g. Claims – Attributes), I am happy to introduce a new term for a relatively new concept with no current name.   Would you prefer we invent a totally new word like “Gorp”? That doesn’t seem very user friendly to me. I don’t see how one can use XACML or ABAC in general without learning a couple of new things. Apparently you consider PDP and PEP descriptive. Along the same lines, how about PIFAST? (Policies In Force At the Same Time).   The name Cohort does not matter to me. The important thing is that in general, a group of policies intended to be used at the same time must be tested, analyzed and deployed as a unit. One cannot, for example update the currently active Cohort by changing and testing one policy. One must test the policy in combination with the rest of the Cohort and conceptually update the entire Cohort. Of course for efficiency we don’t need to transmit anything that has not changed, but that is merely an optional optimization.   The primary requirement coming from the field is to have the ability to distribute policies from a repository to PDPs which are independent implementations. I think we should also support features such as pre-staging. (These policies go in effect at midnight. The PDP receives them at 8 PM and holds them until midnight. It then begins using them for new decision requests, while still using the old Cohort for requests in progress.)   My suspicion (assumption?) is that one result of the PAP architecture exercise of will be that we leave the whole – editing, testing, analysis, version control part of the architecture a black box.   WRT to your idea of Cohort metadata, that sounds perfectly reasonable to me. Policies have comments and extension points where you can add metadata which is not defined by XACML. I don’t see why similar things can’t appear in a Cohort.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Friday, December 12, 2014 3:56 AM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   Hi Hal, Sure, I did not mean to say that there should be no work. I just meant that I don't find this work very interesting, and it might be potentially limiting on products. But I could be persuaded otherwise. :-) As of an example of metadata, let's say that you have a policy editor which allows you to browse a cohort and edit it. The last edit position and how the cohort was expanded in view to the user at last edit time is something that the editor might want to save in the cohort for the user's convenience. It would be a pity if a standard file format for a cohort would prevent a vendor to do something like this or other user enhancements. BTW, I don't like the term cohort . It is not descriptive to end users, and even if we would think of it as a technical term, these technical terms tend to trickle up to the user level one way or another in the end. I would prefer something more user friendly. Best regards, Erik On 2014-12-11 18:18, Hal Lockhart wrote: The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory.   I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability.   Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and  identify areas for proprietary extension.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, December 11, 2014 10:33 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56    


  • 9.  RE: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

    Posted 01-06-2015 21:45
    Well perhaps naturally, I like my own suggestion best (containing the idea of simultaneous time) but I can live with Policy Package, Policy Corpus or Policy Cohort. (package, corpus or cohort for short)   I mostly care about the concept. The TC can decide what name we will use.   Are there other issues with the requirements, constraints and architecture proposed?   Hal   From: Erik Rissanen [mailto:erik@axiomatics.com] Sent: Tuesday, December 16, 2014 2:49 AM To: Bill Parducci; Hal Lockhart Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   In Axiomatics product we use "Policy Package" for this concept. Best regards, Erik On 2014-12-15 21:47, Bill Parducci wrote: Corpus/Corpora is another option with similar heritage.    b   On Dec 15, 2014, at 7:55 AM, Hal Lockhart < hal.lockhart@oracle.com > wrote: I am open to suggestions. The obvious term is policy set, but that is too easily confused with <PolicySet> which it may or may not correspond to.   Cohort is a perfectly good English language word and is in widespread use in the social sciences to express a similar concept. (individuals of similar age as they move through time, e.g. Baby Boomers, Millennials) I actually LIKE the fact that it has no other common meaning in security or computer science. In an industry which frequently invents new terms for things which already have a perfectly good one (e.g. Claims – Attributes), I am happy to introduce a new term for a relatively new concept with no current name.   Would you prefer we invent a totally new word like “Gorp”? That doesn’t seem very user friendly to me. I don’t see how one can use XACML or ABAC in general without learning a couple of new things. Apparently you consider PDP and PEP descriptive. Along the same lines, how about PIFAST? (Policies In Force At the Same Time).   The name Cohort does not matter to me. The important thing is that in general, a group of policies intended to be used at the same time must be tested, analyzed and deployed as a unit. One cannot, for example update the currently active Cohort by changing and testing one policy. One must test the policy in combination with the rest of the Cohort and conceptually update the entire Cohort. Of course for efficiency we don’t need to transmit anything that has not changed, but that is merely an optional optimization.   The primary requirement coming from the field is to have the ability to distribute policies from a repository to PDPs which are independent implementations. I think we should also support features such as pre-staging. (These policies go in effect at midnight. The PDP receives them at 8 PM and holds them until midnight. It then begins using them for new decision requests, while still using the old Cohort for requests in progress.)   My suspicion (assumption?) is that one result of the PAP architecture exercise of will be that we leave the whole – editing, testing, analysis, version control part of the architecture a black box.   WRT to your idea of Cohort metadata, that sounds perfectly reasonable to me. Policies have comments and extension points where you can add metadata which is not defined by XACML. I don’t see why similar things can’t appear in a Cohort.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Friday, December 12, 2014 3:56 AM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   Hi Hal, Sure, I did not mean to say that there should be no work. I just meant that I don't find this work very interesting, and it might be potentially limiting on products. But I could be persuaded otherwise. :-) As of an example of metadata, let's say that you have a policy editor which allows you to browse a "cohort" and edit it. The last edit position and how the cohort was expanded in view to the user at last edit time is something that the editor might want to save in the cohort for the user's convenience. It would be a pity if a standard file format for a cohort would prevent a vendor to do something like this or other user enhancements. BTW, I don't like the term "cohort". It is not descriptive to end users, and even if we would think of it as a technical term, these technical terms tend to trickle up to the user level one way or another in the end. I would prefer something more user friendly. Best regards, Erik On 2014-12-11 18:18, Hal Lockhart wrote: The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory.   I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability.   Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and  identify areas for proprietary extension.   Hal   From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, December 11, 2014 10:33 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded   All, There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations. Best regards, Erik On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All, I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that. Thanks, Ray -- Mr. Remon Sinnema Document Name : Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : repository Date submitted : 2014-12-09 01:20:56