OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
Expand all | Collapse all

REST Profile - PAP Issues

  • 1.  REST Profile - PAP Issues

    Posted 05-16-2012 22:30
    I have a number of different kinds of comments about the REST Profile and Media types which will post separately to allow the discussion to take place in distinct threads. As I said on the last call, whereas the Access Decision functionality has an existing model (the SOAP-SAML protocol) which we may take as a point of departure to replicate or simplify, the policy management features break new ground. The previous work I have done in this area appears in the wiki item #62 here: http://wiki.oasis-open.org/xacml/IssuesList The focus of my prior work was on policy distribution (provisioning). The REST Profile tackles the Policy Editor to PAP interface, so they may be completely independent problems. However I would like to survey the entire landscape and decide what to provide in the REST Profile in light of that. Here is a brief summary. I have defined the concept of a Policy Cohort, which is a set of policies (and/or policy sets) which are intended to be in force at a given time at one or more PDP. A cohort is the unit of testing and distribution of policies. When a PDP evaluates its policies, they consist of a single <PolicySet>, however the top level <PolicySet> may be virtual. Further the use of Admin policies means that there may be holes in the tree which will be filled by policies provided at decision time for the duration of that decision and thus are not part of the cohort. (Although probably part of the testing) It seems to me that Policy management has two general phases: creation and distribution. Creation involves creating, modifying and testing policies and Cohorts. Distribution involves creating schedules for every PDP identifying what Cohorts will be in effect at what times and physically distributing the Cohorts to the deployed PDPs in advance of them becoming in force. It seems to me that policy creation is similar to software development and probably should involve similar tools. For example, it seems useful to be able to check out, edit, fork, merge, compare, define Cohorts, unit test (one policy), system test (a Cohort), check in and stage to be distributed. (We need to decide as a matter of terminology whether to consider the staging point to be apart of the PAP or a distinct architectural entity.) In particular, one aspect of XACML policies which creation tools should support is Policy ID and Policy ID Reference. XACML Core says that policies visible to a PDP must have unique IDs. In my terminology, no Cohort can contain policies with the same id. XACML also supports a versioning and sub versioning scheme which allows references to be to a specific (minor) version or the latest (minor) version. Given that, it seems like when you change a policy, particularly one which has previously been in effect, you might want to increase its version number and keep the old version around, rather than deleting it. It might also be useful for the policy creation tools to generate policy IDs according to some organizational template and prevent race conditions between users simultaneously creating different policies. Given this background, I am not sure how useful the functionality proposed in the REST Profile will be. I grant that having a central point where policies can be collected and inspected and compared could have value, but it seems to me to be somewhat apart from the core tasks of creating and distributing policies. Specific comments on wd 03: Section 2.2.3 says creating policies with duplicate ids gets a 409. I see a few issues here. First as I mentioned, the constraint is on a Cohort. There might be convenient to have duplicate policy IDs in a PAP. Further, having to scan a list of 100 or so policies to determine what a unique ID would be seems inefficient and error prone. Then there is the issue that policies have an ID and a URI. What if I have policy 22 at URI X and policy 23 at URI Y and I update URI X with a new policy 23? The next sentence says that creating a reference to a non-existent policy also gets a 409. I can see at least 3 problems with this. 1) It is often inconvenient when doing things of this type to be constrained to create things in a certain order. 2) Dangling references are explicitly allowed when Admin policies are supported. 3) The PAP will have to understand the XACML reference semantics (exact vs. newest) in order to enforce this. Overall, I don't see that much benefit from the proposed PAP functionality, but I won't oppose it if others do see value. However, I would object if the implication is that what is being managed is the policies currently in force at some PDP. Updating policies on the fly seems like a recipe for disaster, but if the polices in the PAP are not the ones currently in force, then I see little probability that the PAP functions and PDP functions would be implemented in the same software component. As a final note, I am still interested in the policy distribution problem and would like to specify something there, whether REST or SOAP based (or both). Hal


  • 2.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-17-2012 06:44
    Hal, >


  • 3.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-17-2012 15:01
    > > Section 2.2.3 says creating policies with duplicate ids gets a 409. I > > see a few issues here. First as I mentioned, the constraint is on a > > Cohort. > > It is in your cohort proposal. It's not in the current core spec, since > that doesn't even contain the concept of a cohort. Yes it is. In Core section 5.14 under [PolicyId] it says: It is the responsibility of the PAP to ensure that no two policies visible to the PDP have the same identifier. The Cohort is nothing more or less than the policies visible to the PDP. > > > There might be convenient to have duplicate policy IDs in a PAP. > > Only as an intermediate step, since the core spec forbids duplicate > policy IDs to be in effect at the same time. So if we're not including > any intermediate steps (like policy distribution), then having > duplicate policy IDs is simply forbidden by the core spec, right? > Only if you consider the PAP to contain the active policies being used by a PDP. My impression was that you saw it as a kind of repository for policies under development. This is not a huge point and I could live with the restriction, I just wanted to clarify what the restriction in XACM Core is. > > > Further, having to scan a list of 100 or so policies to determine > what > > a unique ID would be seems inefficient and error prone. > > I don't see why it would be error prone. > As for inefficient, that's an implementation detail. Also, it is a well > understood problem, with well understood solutions. And 100, well, > that's just not a lot at all. I am saying that if the only way I have to find a unique id is to scan the list it will be easy to miss one or misread the value. If I use an algorithm to select an unused one, what about a race condition with other policy editors using the same algorithm? > > > Then there is the issue that policies have an ID and a URI. What if I > > have policy > > 22 at URI X and policy 23 at URI Y and I update URI X with a new > policy 23? > > In a RESTful system, URIs are opaque, one should not care what they > look like (as long as they are in fact unique). There need be no > relation between policy IDs and URIs, so I don't see any problem here. In the case I mention, is does the PAP require that a policy being updated retain the same ID? Is the PAP required to check for duplicates in all the other policies? I don't necessarily see a problem, I just want the behavior of the PAP to be completely specified. > > > > The next sentence says that creating a reference to a non-existent > > policy also gets a 409. I can see at least 3 problems with this. 1) > It > > is often inconvenient when doing things of this type to be > constrained > > to create things in a certain order. > > I'm starting to think that with your cohort idea, we have two kinds of > administrative interface. One where you build up your cohort, which may > be temporarily in an invalid state, and one where the PDP gets its > policies from, which must not be in an invalid state. I'm talking about > the latter, but I have a feeling that you're talking about the former. > Since the former is not part of the XACML architecture as shown in the > core spec, I propose we give it a different name, so that it's always > clear what we're talking about. > > > > 2) Dangling references are > > explicitly allowed when Admin policies are supported. > > I'll have to look into that. > > > > 3) The PAP will > > have to understand the XACML reference semantics (exact vs. newest) > in > > order to enforce this. > > Why is that a problem? Just needs to be spelled out. > > > > Overall, I don't see that much benefit from the proposed PAP > > functionality, but I won't oppose it if others do see value. However, > > I would object if the implication is that what is being managed is > the > > policies currently in force at some PDP. Updating policies on the fly > > seems like a recipe for disaster > > That's a bit strongly worded. Every application I know of (incl. > operating systems and databases) does things this way, so it can't be > that bad. > That's not to say that I don't see value in a staged approach; I do. Perhaps you are right, but I cannot imagine updating a policy in production without regression testing it as a part of a Cohort. Perhaps I am miss interpreting the document, but the idea of creating a new policy, testing it in isolation and putting it directly in production seems very risky. > > As a final note, I am still interested in the policy distribution > > problem and would like to specify something there, whether REST or > > SOAP based (or both). > > I don't think it should be part of the REST profile, since, like you > mentioned, there could be a SOAP interface as well. > Also, I don't think the REST profile should be stalled because of it, > since there is functionality in the core spec available now, that the > REST profile addresses and that is valuable. > > Having said that, I'm interested in pursuing the policy distribution > topic as well. I agree with splitting the up and I welcome your interest. Hal


  • 4.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-17-2012 19:45
    >>>>>>>>> > > There might be convenient to have duplicate policy IDs in a PAP. > > Only as an intermediate step, since the core spec forbids duplicate > policy IDs to be in effect at the same time. So if we're not including > any intermediate steps (like policy distribution), then having > duplicate policy IDs is simply forbidden by the core spec, right? > Only if you consider the PAP to contain the active policies being used by a PDP. My impression was that you saw it as a kind of repository for policies under development. This is not a huge point and I could live with the restriction, I just wanted to clarify what the restriction in XACM Core is. <<<<<<<<<<< Yes, there will be multiple documents in the repository associated with the same policy ID. The policy ID alone is not the complete identity of a policy document. The policy ID + the policy version is the complete identity. You will have multiple versions of the same policy ID running around in the same repository that are distinguished and unique by version number. In database terms, your policy repository primary key is not PolicyID. It's PolicyID + PolicyVersion. >>>>>>>>> > > Further, having to scan a list of 100 or so policies to determine > what > > a unique ID would be seems inefficient and error prone. > > I don't see why it would be error prone. > As for inefficient, that's an implementation detail. Also, it is a > well understood problem, with well understood solutions. And 100, > well, that's just not a lot at all. I am saying that if the only way I have to find a unique id is to scan the list it will be easy to miss one or misread the value. If I use an algorithm to select an unused one, what about a race condition with other policy editors using the same algorithm? <<<<<<<<<<<<<< If the only way you have to find a unique id is to scan a list, you have much larger problems. ;> I agree with Remon - generating unique ids at cloud scale is a well understood problem with a variety of different solutions. I think it's sufficient to say that a POST of a policy document to the REST API will generate a unique (implementation defined) ID at the server and return the unique ID in the response. How the unique ID is created or procured or communicated to the rest of the data center is beyond the scope of this discussion. Since a policy is not fully identified by its ID alone, we may need to distinguish between creating an entirely new policy from scratch versus creating a revision of an existing policy (same policy ID, different version number). I'll take this up in a separate email. > > > > The next sentence says that creating a reference to a non-existent > > policy also gets a 409. I can see at least 3 problems with this. 1) > It > > is often inconvenient when doing things of this type to be > constrained > > to create things in a certain order. > This shouldn't present a serious order-of-creation problem since Xacml already requires that the policy reference tree be strictly acyclic. Persist all the referenced policies before the referee (recursively) and the order should be fine. > I'm starting to think that with your cohort idea, we have two kinds of > administrative interface. One where you build up your cohort, which > may be temporarily in an invalid state, and one where the PDP gets its > policies from, which must not be in an invalid state. I'm talking > about the latter, but I have a feeling that you're talking about the former. > Since the former is not part of the XACML architecture as shown in the > core spec, I propose we give it a different name, so that it's always > clear what we're talking about. > I agree that the first priority of the REST API should be to operate on coherent data. We can always add entropy later. :> > > > 2) Dangling references are > > explicitly allowed when Admin policies are supported. > > I'll have to look into that. > True. Late binding. Always entertaining. :> >>>>>>>>>> > > Overall, I don't see that much benefit from the proposed PAP > > functionality, but I won't oppose it if others do see value. > > However, I would object if the implication is that what is being > > managed is > the > > policies currently in force at some PDP. Updating policies on the > > fly seems like a recipe for disaster > > That's a bit strongly worded. Every application I know of (incl. > operating systems and databases) does things this way, so it can't be > that bad. > That's not to say that I don't see value in a staged approach; I do. Perhaps you are right, but I cannot imagine updating a policy in production without regression testing it as a part of a Cohort. Perhaps I am miss interpreting the document, but the idea of creating a new policy, testing it in isolation and putting it directly in production seems very risky. <<<<<<<<<< The REST API should allow for an implementation to express a staging or process workflow around policy creation, revision, testing, approval, deployment, and retirement, but I don't think that workflow definition should be part of the REST API. I would expect that such a workflow would use the REST API, not the other way around. One way to express such a workflow would be to set up a different independent PAP for each distinct stage in the workflow. Policy development and testing happens on PAP.Staging. PAP.Staging is only accessible to PDPs used for testing, not accessible to production PDPs. After the workflow for policy revision, testing, and approval has been completed, the policy/policyset/cohort are copied to PAP.Production, where they are accessible to the production PDPs. PAP.Production is very restricted in who can post changes to that repository - PAP.Staging less so. How and when the PDPs discover and begin to enforce the revised policies is also beyond the scope of the REST API. All of that can be done using the simple "PDP production oriented" REST API as sketched out. (subject to version management in the next email) -Danny


  • 5.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-29-2012 19:54
    How would you model operations like check in and check out? BTW, I am starting to think it would be best to separate the policy management stuff from the much simpler decision request. Hal >


  • 6.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-29-2012 22:21
    I would use an optimistic concurrency model over an exclusive lock revision model. IOW, submit an indicator of what version your revision is based on (eg, HTTP entity tag), and if the current "tip" revision at the server does not match your base then the client needs to reconcile differences with the new tip revision and resubmit. Accessing policies via REST is pretty straightforward. The tricky part is the semantics behind POST for policy revision. If we can't find an abstraction that we can be confident will be compatible with an as yet undefined policy management policy/semantic, perhaps the best step for moving the REST profile along is to remove policy POST from the REST spec for the moment? -Danny Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com


  • 7.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-31-2012 14:52
    > Accessing policies via REST is pretty straightforward. The tricky part > is the semantics behind POST for policy revision. If we can't find an > abstraction that we can be confident will be compatible with an as yet > undefined policy management policy/semantic, perhaps the best step for > moving the REST profile along is to remove policy POST from the REST > spec for the moment? I think XACML has benefitted from having a relatively clear model of the relationship between the PEP and the PDP. In particular it has guided decisions about what aspects to standardize and what to leave unspecified. Currently the PAP concept is pretty vague. I think we need to break it up into subcomponents and define their relationships. This will give us the ability to decide what aspects should be standardized, what properties the components are required to implement and where the opportunities for unstandardized value add are. I therefore agree with Danny that we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. I am uncertain whether this should wait on the JSON representation or that should be put off to a later version. An additional possible advantage of this approach is that it may be prove much simpler to specify the Request in JSON than the policy language. Hal


  • 8.  Re: [xacml] REST Profile - PAP Issues

    Posted 05-31-2012 14:55
    I agree with your last point, Hal. Representing the request / response alone in JSON will be much easier. As a matter of fact, I realized the spec probably lacks a class diagram of the request / response much like there is one for policies. The class diagram can help formally drive the JSON definition, and ultimately why not an IDL for Thrift? On Thu, May 31, 2012 at 4:51 PM, Hal Lockhart < hal.lockhart@oracle.com > wrote: > Accessing policies via REST is pretty straightforward.  The tricky part > is the semantics behind POST for policy revision. If we can't find an > abstraction that we can be confident will be compatible with an as yet > undefined policy management policy/semantic, perhaps the best step for > moving the REST profile along is to remove policy POST from the REST > spec for the moment? I think XACML has benefitted from having a relatively clear model of the relationship between the PEP and the PDP. In particular it has guided decisions about what aspects to standardize and what to leave unspecified. Currently the PAP concept is pretty vague. I think we need to break it up into subcomponents and define their relationships. This will give us the ability to decide what aspects should be standardized, what properties the components are required to implement and where the opportunities for unstandardized value add are. I therefore agree with Danny that we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. I am uncertain whether this should wait on the JSON representation or that should be put off to a later version. An additional possible advantage of this approach is that it may be prove much simpler to specify the Request in JSON than the policy language. Hal --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org -- David Brossard, M.Eng, SCEA, CSTP VP Product Marketing & Customer Relations +46(0)760 25 85 75 Axiomatics AB Skeppsbron 40 S-111 30 Stockholm, Sweden http://www.linkedin.com/companies/536082 http://www.axiomatics.com http://twitter.com/axiomatics


  • 9.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-31-2012 22:49
    Hal, >


  • 10.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-31-2012 23:12
    >> we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. Without the policy administration, there's nothing left that is "REST". All we have is a HTTP POST binding for XACML requests and responses, with perhaps a JSON representation. Calling this a "REST profile" wouldn't be accurate. Regards, Craig ------- craig forster technical lead, tivoli security policy manager cforster@us.ibm.com ------- Hal Lockhart ---05/31/2012 09:55:49 AM---> Accessing policies via REST is pretty straightforward. The tricky part > is the semantics behind From: Hal Lockhart <hal.lockhart@oracle.com> To: Danny Thorpe <Danny.Thorpe@quest.com>, remon.sinnema@emc.com, Cc: xacml@lists.oasis-open.org Date: 05/31/2012 09:55 AM Subject: RE: [xacml] REST Profile - PAP Issues Sent by: <xacml@lists.oasis-open.org> > Accessing policies via REST is pretty straightforward.  The tricky part > is the semantics behind POST for policy revision. If we can't find an > abstraction that we can be confident will be compatible with an as yet > undefined policy management policy/semantic, perhaps the best step for > moving the REST profile along is to remove policy POST from the REST > spec for the moment? I think XACML has benefitted from having a relatively clear model of the relationship between the PEP and the PDP. In particular it has guided decisions about what aspects to standardize and what to leave unspecified. Currently the PAP concept is pretty vague. I think we need to break it up into subcomponents and define their relationships. This will give us the ability to decide what aspects should be standardized, what properties the components are required to implement and where the opportunities for unstandardized value add are. I therefore agree with Danny that we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. I am uncertain whether this should wait on the JSON representation or that should be put off to a later version. An additional possible advantage of this approach is that it may be prove much simpler to specify the Request in JSON than the policy language. Hal --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org


  • 11.  Re: [xacml] REST Profile - PAP Issues

    Posted 06-01-2012 14:14
    Craig, As I understand it, the task of creating a REST/JSON binding for XACML request/response is a well understood task which could be accomplished in a short period of time. It is also something the we have received a fair bit of interest from the community, customers and from within our organization. It could perhaps even be the basis of a public demonstration in the next six to nine months. The policy management work is an altogether different animal. I am no expert in this area, but I understand that a fair bit of research is required in this space. There is no reason to believe that consensus could be achieved in a short period of time. I am also not personally aware of the same level of interest in this work from the larger community. Just my two cents, - prateek >> we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. Without the policy administration, there's nothing left that is REST . All we have is a HTTP POST binding for XACML requests and responses, with perhaps a JSON representation. Calling this a REST profile wouldn't be accurate. Regards, Craig ------- craig forster technical lead, tivoli security policy manager cforster@us.ibm.com ------- Hal Lockhart ---05/31/2012 09:55:49 AM---> Accessing policies via REST is pretty straightforward. The tricky part > is the semantics behind From: Hal Lockhart <hal.lockhart@oracle.com> To: Danny Thorpe <Danny.Thorpe@quest.com> , remon.sinnema@emc.com , Cc: xacml@lists.oasis-open.org Date: 05/31/2012 09:55 AM Subject: RE: [xacml] REST Profile - PAP Issues Sent by: <xacml@lists.oasis-open.org> > Accessing policies via REST is pretty straightforward.  The tricky part > is the semantics behind POST for policy revision. If we can't find an > abstraction that we can be confident will be compatible with an as yet > undefined policy management policy/semantic, perhaps the best step for > moving the REST profile along is to remove policy POST from the REST > spec for the moment? I think XACML has benefitted from having a relatively clear model of the relationship between the PEP and the PDP. In particular it has guided decisions about what aspects to standardize and what to leave unspecified. Currently the PAP concept is pretty vague. I think we need to break it up into subcomponents and define their relationships. This will give us the ability to decide what aspects should be standardized, what properties the components are required to implement and where the opportunities for unstandardized value add are. I therefore agree with Danny that we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. I am uncertain whether this should wait on the JSON representation or that should be put off to a later version. An additional possible advantage of this approach is that it may be prove much simpler to specify the Request in JSON than the policy language. Hal --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org


  • 12.  Re: [xacml] REST Profile - PAP Issues

    Posted 06-01-2012 15:25
    Can we just move the policy management (with versioning) out into a separate profile of its own?  This will only delay execution of the REST bindings for request/response.  The policy management versioning topic is wsdl/webservices all over again, which the world is trying to run away from (via json). :) On 06/01/2012 09:14 AM, prateek mishra wrote: Craig, As I understand it, the task of creating a REST/JSON binding for XACML request/response is a well understood task which could be accomplished in a short period of time. It is also something the we have received a fair bit of interest from the community, customers and from within our organization. It could perhaps even be the basis of a public demonstration in the next six to nine months. The policy management work is an altogether different animal. I am no expert in this area, but I understand that a fair bit of research is required in this space. There is no reason to believe that consensus could be achieved in a short period of time. I am also not personally aware of the same level of interest in this work from the larger community. Just my two cents, - prateek >> we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. Without the policy administration, there's nothing left that is REST . All we have is a HTTP POST binding for XACML requests and responses, with perhaps a JSON representation. Calling this a REST profile wouldn't be accurate. Regards, Craig ------- craig forster technical lead, tivoli security policy manager cforster@us.ibm.com ------- Hal Lockhart ---05/31/2012 09:55:49 AM---> Accessing policies via REST is pretty straightforward. The tricky part > is the semantics behind From: Hal Lockhart <hal.lockhart@oracle.com> To: Danny Thorpe <Danny.Thorpe@quest.com> , remon.sinnema@emc.com , Cc: xacml@lists.oasis-open.org Date: 05/31/2012 09:55 AM Subject: RE: [xacml] REST Profile - PAP Issues Sent by: <xacml@lists.oasis-open.org> > Accessing policies via REST is pretty straightforward.  The tricky part > is the semantics behind POST for policy revision. If we can't find an > abstraction that we can be confident will be compatible with an as yet > undefined policy management policy/semantic, perhaps the best step for > moving the REST profile along is to remove policy POST from the REST > spec for the moment? I think XACML has benefitted from having a relatively clear model of the relationship between the PEP and the PDP. In particular it has guided decisions about what aspects to standardize and what to leave unspecified. Currently the PAP concept is pretty vague. I think we need to break it up into subcomponents and define their relationships. This will give us the ability to decide what aspects should be standardized, what properties the components are required to implement and where the opportunities for unstandardized value add are. I therefore agree with Danny that we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. I am uncertain whether this should wait on the JSON representation or that should be put off to a later version. An additional possible advantage of this approach is that it may be prove much simpler to specify the Request in JSON than the policy language. Hal  


  • 13.  Re: [xacml] REST Profile - PAP Issues

    Posted 06-01-2012 15:29
    Prateek, I didn't mean to suggest that the runtime and administration pieces couldn't be tackled separately, just that calling an XACML over HTTP POST (using XML or JSON) a "REST" protocol is a misnomer (IMO). I completely agree that a runtime profile could be knocked out fairly quickly. However, how does this differ from previous suggestions that we standardize an XACML over SOAP protocol? This wasn't something the TC was keen to pursue (ie the SAML binding is the official runtime protocol), so how is XACML over HTTP POST different? If we're going to standardize runtime bindings then both SOAP and HTTP POST are valid candidates. Regards, Craig ------- craig forster technical lead, tivoli security policy manager cforster@us.ibm.com ------- prateek mishra ---06/01/2012 09:15:03 AM---Craig, As I understand it, the task of creating a REST/JSON binding for XACML From: prateek mishra <prateek.mishra@oracle.com> To: xacml@lists.oasis-open.org, Craig R Forster/Austin/IBM@IBMUS, Date: 06/01/2012 09:15 AM Subject: Re: [xacml] REST Profile - PAP Issues Craig, As I understand it, the task of creating a REST/JSON binding for XACML request/response is a well understood task which could be accomplished in a short period of time. It is also something the we have received a fair bit of interest from the community, customers and from within our organization. It could perhaps even be the basis of a public demonstration in the next six to nine months. The policy management work is an altogether different animal. I am no expert in this area, but I understand that a fair bit of research is required in this space. There is no reason to believe that consensus could be achieved in a short period of time. I am also not personally aware of the same level of interest in this work from the larger community. Just my two cents, - prateek >> we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. Without the policy administration, there's nothing left that is "REST". All we have is a HTTP POST binding for XACML requests and responses, with perhaps a JSON representation. Calling this a "REST profile" wouldn't be accurate. Regards, Craig ------- craig forster technical lead, tivoli security policy manager cforster@us.ibm.com ------- Hal Lockhart ---05/31/2012 09:55:49 AM---> Accessing policies via REST is pretty straightforward. The tricky part > is the semantics behind From: Hal Lockhart <hal.lockhart@oracle.com> To: Danny Thorpe <Danny.Thorpe@quest.com> , remon.sinnema@emc.com , Cc: xacml@lists.oasis-open.org Date: 05/31/2012 09:55 AM Subject: RE: [xacml] REST Profile - PAP Issues Sent by: <xacml@lists.oasis-open.org> > Accessing policies via REST is pretty straightforward.  The tricky part > is the semantics behind POST for policy revision. If we can't find an > abstraction that we can be confident will be compatible with an as yet > undefined policy management policy/semantic, perhaps the best step for > moving the REST profile along is to remove policy POST from the REST > spec for the moment? I think XACML has benefitted from having a relatively clear model of the relationship between the PEP and the PDP. In particular it has guided decisions about what aspects to standardize and what to leave unspecified. Currently the PAP concept is pretty vague. I think we need to break it up into subcomponents and define their relationships. This will give us the ability to decide what aspects should be standardized, what properties the components are required to implement and where the opportunities for unstandardized value add are. I therefore agree with Danny that we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. I am uncertain whether this should wait on the JSON representation or that should be put off to a later version. An additional possible advantage of this approach is that it may be prove much simpler to specify the Request in JSON than the policy language. Hal --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org


  • 14.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-29-2012 19:59
    > The REST API should allow for an implementation to express a staging or > process workflow around policy creation, revision, testing, approval, > deployment, and retirement, but I don't think that workflow definition > should be part of the REST API. I would expect that such a workflow > would use the REST API, not the other way around. > > One way to express such a workflow would be to set up a different > independent PAP for each distinct stage in the workflow. Policy > development and testing happens on PAP.Staging. PAP.Staging is only > accessible to PDPs used for testing, not accessible to production PDPs. > After the workflow for policy revision, testing, and approval has been > completed, the policy/policyset/cohort are copied to PAP.Production, > where they are accessible to the production PDPs. PAP.Production is > very restricted in who can post changes to that repository - > PAP.Staging less so. How and when the PDPs discover and begin to > enforce the revised policies is also beyond the scope of the REST API. > > All of that can be done using the simple "PDP production oriented" REST > API as sketched out. (subject to version management in the next email) This sounds reasonable, but I would have to see the details to really judge. It does seem like it would make sense to have a separate profile dealing with all the policy management issues. Hal


  • 15.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-17-2012 21:30
    Hal, >


  • 16.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-17-2012 18:36
    Hal, How is a cohort of policies not a policyset? Your statements read perfectly well if you replace "cohort" with "policyset". The only difference I can think of is a cohort does not appear to define a combining algorithm, but if a PDP is evaluating requests against a cohort of multiple policies, there must be some sort of default combining algorithm in play for the cohort. So why not just say policyset? -Danny Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com


  • 17.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-29-2012 19:50
    > How is a cohort of policies not a policyset? Your statements read > perfectly well if you replace "cohort" with "policyset". The only > difference I can think of is a cohort does not appear to define a > combining algorithm, but if a PDP is evaluating requests against a > cohort of multiple policies, there must be some sort of default > combining algorithm in play for the cohort. So why not just say > policyset? First of all, in a environment with only Access Policies (no Admin Policies) the Cohort is allowed to contain a bunch of Policies and PolicySets which do not have a common root PolicySet. In this case the PDP is required to treat each tree (free standing policy or top level PolicySet and its children) as a member of a virtual top level policy set. The Policy Combining Algorithm for this virtual Policy Set is a PDP-wide parameter which can be advertized via Metadata (once we do the Metadata Profile). With Admin policies, things get a good bit more complex. First, the Admin policies themselves form an actual or virtual tree of policies separate from Access Policies. (Or are the multiple trees for multiple issuers? Erik can you help me here?) Also, Admin policies enable the use of per-decision policies which are provided at decision time and combined with the Cohort for the duration of that particular decision. When we developed the Admin profile, there was discussion of use cases where the per-decision policies could sensibly be leaf policies, higher level policy sets or even Admin policies. Therefore there can be gaps in the tree at various points. Hal


  • 18.  RE: [xacml] REST Profile - PAP Issues

    Posted 05-31-2012 22:16
    Hal, >


  • 19.  Metadata Profile (was RE: [xacml] REST Profile - PAP Issues)

    Posted 06-07-2012 15:27
    > > > > The Policy Combining Algorithm for this virtual Policy Set is a > > PDP-wide parameter which can be advertized via Metadata (once we do > > the Metadata Profile). > > I'm getting more and more interested in completing the Metadata > Profile. What's the current status? Erik did a partial draft and scheme which can be found here: https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/27316/xacml-3.0-metadata-v1-wd-01.zip Nobody has worked on it since 2008. If you are interested in working on it, you might take a quick look at the SAML 2.0 Metadata Profile: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf The XACML one is intended to have a similar scope. That is, it will define symbols and their semantics, but remain silent on how Metadata is published or otherwise communicated, as long as the method provides at a minimum Authentication of the Metadata Producer and integrity protection of the contents. Hal