Rich, I tried, let me know if you have questions From: Rich.Levinson [mailto:
rich.levinson@oracle.com] Sent: Friday, February 04, 2011 4:14 PM To: Anthony Nadalin Cc: Gregory Neven; Tyson, Paul H; Franz-Stefan Preiss; XACML Subject: Re: [xacml] Attribute Assertions in request context Hi Bill, Tony, Greg, Paul, I agree w Bill that we need a precise typical use case to show what the inputs and outputs to the pep/pdp are expected to be. I also agree w Greg that this should be able to be accomplished with Obligations, except possibly in a more granular way where the Obligation contains only the attributes that are to be included in the claim and it would be up to the PEP or possibly the context handler to package them up in some specific manner. But in order to explore this approach we need more detailed requirements, specifically the inputs and outputs. That way, based on inputs, one could determine what kind of Policy/Set would need to be developed to produce the outputs. Thanks, Rich Bill Parducci wrote: Tony, Do you have a simple use case that describes what you are trying to achieve? thanks b On Feb 2, 2011, at 8:46 AM, Anthony Nadalin wrote: Correct, it would not be the basic permit or deny, we thought about the obligation but this leaves us with the permit/deny problem (what to do there). Our issue is that the PDP may not be able to actually may not be able to prove the claim and only the PEP can (application). From: Gregory Neven [ mailto:
nev@zurich.ibm.com ] Sent: Wednesday, February 02, 2011 8:26 AM To: Anthony Nadalin Cc: Tyson, Paul H; Rich.Levinson; Franz-Stefan Preiss; XACML Subject: Re: [xacml] Attribute Assertions in request context So you mean that the PDP should return the claim that the requestor needs to prove as an output, rather than returning Permit or Deny? So one approach would be to encode the claim as an Obligation in the Rule, so that it gets passed back to the PEP as part of the response? Greg On 2/2/2011 16:15, Anthony Nadalin wrote: I doubt that it’s a discussion for another thread, as we are dealing with predicates. I also did not say that the PDP no longer makes the decision, what I said was the that PDP today only produces a Boolean as a decision and for technologies like U-Prove (I can’t speak for Identity Mixer) this does not make much sense. The use case is pretty simple, which is to allow claims to be the output of the PDP as a decision. From: Tyson, Paul H [ mailto:
PTyson@bellhelicopter.textron.com ] Sent: Wednesday, February 02, 2011 6:23 AM To: Anthony Nadalin; Gregory Neven; Rich.Levinson Cc: Franz-Stefan Preiss; XACML Subject: RE: [xacml] Attribute Assertions in request context Anthony, that sounds like a discussion for another thread. It also sounds, on the surface, contrary to the XACML principle of centralized decision-making at the PDP. I’m not familiar with your use cases. Have they been presented to the TC? Regards, --Paul From: Anthony Nadalin [mailto:
tonynad@microsoft.com] Sent: Tuesday, February 01, 2011 15:40 To: Gregory Neven; Rich.Levinson Cc: Tyson, Paul H; Franz-Stefan Preiss; XACML Subject: RE: [xacml] Attribute Assertions in request context My view on this is that with this type of technology it does not make much sense to just return the normal XACML decision (Boolean) but rather return a proof/claim that can be feed back into another evaluation or have the PEP make the enforcement based upon a non boolean, this does change how XACML works today and what the PDP and PEP may produce, but in our use cases the proposed flows don’t work. From: Gregory Neven [mailto:
nev@zurich.ibm.com] Sent: Tuesday, February 01, 2011 7:38 AM To: Rich.Levinson Cc: Tyson, Paul H; Franz-Stefan Preiss; XACML Subject: Re: [xacml] Attribute Assertions in request context Hi Rich and Paul, Thanks, Rich, for the good overview of the status of this discussion. I agree with everything you wrote, in particular with the fact that the recent discussions have deviated from the "simple" solution (with a translation table between local attributeIDs and predicates over global attributeIDs) to the "complex" solution (with attribute predicates all the way down into the PDP). As much as I like the discussions with Paul on the complex solution, I think there are a couple of challenges left to make it work, so we may want to re-consider the options we have on the table: Option 1: Simple solution As described on slide 10 of
http://www.oasis-open.org/committees/document.php?document_id=39960 . Either the PEP or the ContextHandler maintains a translation table between locally meaningful boolean attributeIDs and predicates over globally meaningful attributeIDs. The policy and request context are specified in terms of the local attributes, the communication to the outside world (user or IDP) contains predicates over global attributes. The main advantage of this solution is that hardly any changes are needed to XACML at all. Mainly, one would have to specify where and how the mapping between local and predicates over global attributes is done, similarly to the mapping between saml:Attribute and xacml-context:Attribute in the SAML profile of XACML. Another advantage is that arbitrarily complex predicates can be supported without problem. More details are in one of my earlier posts (
http://lists.oasis-open.org/archives/xacml/201011/msg00025.html ). Option 2: Complex solution with simple predicates This was the last solution that Paul suggested (
http://lists.oasis-open.org/archives/xacml/201101/msg00030.html ), after we pointed out some problems with his approach for nested predicates. One could restrict the type of predicates to "attribute operator value", which would cover the "age > 18" and "birthday < 1993/01/01" examples. Probably one could also include "attribute operator attribute" predicates, which would cover the "waist > inseam" example from Paul's Short Fat Man fun run (
http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext ). As Franz-Stefan pointed out (
http://lists.oasis-open.org/archives/xacml/201101/msg00021.html ), the proposed approach gets into trouble with nested predicates, e.g., "birthdate + 18 years < today". Other use cases from my slides that would not be covered are "first 5 characters of phonenr are +4144" or "domain of email address is ibm.com". But regardless of whether the simple predicates cover the most important use cases, there are a couple of problems left to be solved still even if we restrict to simple predicates. Namely: For each function that we want to support, we would have to specify by which predicates it can be satisfied, as Paul did in Prolog notation for the greater-than function (
http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext ). Depending on how "intelligent" we want the matching to be, this may get quite complex. For example, there may be dependencies between different functions, as Paul correctly pointed out in his Prolog example between the >= and > operators. Solving this problem may take some more research, or at least literature study. We don't have the knowledge in-house to solve this on the short term, but will check again with colleagues. Reporting "missing predicates" to the user/IDP remains an open question. When the PDP encounters an attribute that is not in the context, it will only report the AttributeID of the missing attribute, not the predicate surrounding it. The user/IDP therefore can't find out which predicate it has to prove. Option 3: Complex solution with complex predicates This solution has the same problems as option 2, but in an amplified way. If checking whether predicate A implies predicate B was already non-trivial for simple predicates, it is even more so for arbitrarily nested predicates. Also, when reporting missing predicates, there is the additional challenge of deciding which "level" of the predicate to report as missing, as explained on slide 14 of
http://www.oasis-open.org/committees/document.php?document_id=39960 . Best regards, Greg On 1/29/2011 08:30, Rich.Levinson wrote: Hi Greg and Paul, I understand your comments that the context for the current discussion is the original slide set which was uploaded to the repository on this email:
http://lists.oasis-open.org/archives/xacml/201011/msg00000.html which I did on request from Bill as the original email from Bill pointed to a private location. In any event the slides are here:
http://www.oasis-open.org/committees/document.php?document_id=39960 The reason I went to the paper by Greg's group:
http://www.w3.org/2009/policy-ws/papers/Neven.pdf was that I was not able to obtain sufficient context from the slides alone to understand the motivation for the current discussions. I have gone over the slides again in the context of the paper and think that I now have a better understanding of the problem being solved. My understanding now is that the key concept is: There is an identity provider (idp) that is supplying information to the PEP about the user in some non-xacml form, which can include "attribute predicates", where these predicates are actually "assertions" about the user such as "age > 18" or "birthday < 2010/10/21". Some of these are captured on slide 7 of Greg's presentation. There are a couple of aspects of the problem that are discussed in the slide set: one aspect is how the PEP "gets" the info from the idp, and what is being considered is that it is a SAML idp, and that some kind of syntax can be developed, as indicated on slide 8. However, this is outside the scope of XACML, except for the fact that the information will be available in some specific form. the second aspect is how the PEP translates the information received from the idp and puts it in a XACML request - slide 9. finally, there are two proposed approaches for dealing with the second aspect of translating the predicates to XACML: a "simple solution" slide 10, where the result of predicate evaluation is a boolean captured in a named attribute (ex.AttributeId = "uri:local:overage" with AttributeValue=true) In some earlier discussion, Greg and I appeared to be in agreement on this:
http://lists.oasis-open.org/archives/xacml/201011/msg00024.html a "more complex solution", slide 11, which can include complex expressions like the parse tree in slide 14. What seems to have happened, imo, is that recent discussion has focused almost exclusively on developing technology to address the "more complex solution", while the "simple solution" has been more or less ignored. At least this explains to me why I was having trouble understanding the context of the current discussions. That being said, I have looked back at what triggered the current thread, and the thread that Greg and I agreed on, and some other threads as well that may not have yet been fully addressed. In particular, the following discussion is copied from the November 18 minutes:
http://lists.oasis-open.org/archives/xacml/201011/msg00015.html "Primelife proposal Next Steps Hal suggested that it would be very difficult to creature a convention that would address attributes which would represent predicates. Gregory asked if possibly uri prefixes might denote these attributes? Gregory offered that a possible update to the SAML/XACML Profile mapping between predicates and local attributes Rich agreed that a Profile is the way to address this given the initial discussions, but that much more information is needed. Hal suggested that the Profile may possibly be aimed at the Context Handler. Paul offered that whatever solution the TC comes up upon be a long range solution. Gregory suggested that the "complex solution" be pursued whereby the Context Handler is predicate aware and can perform ancillary processing and match "qualified" with "certified" condition derived results. Hal suggested that it may be very difficult to achieve since it is effectively Policy matching (heretofore intentionally avoided by the TC due to complexity). Of the 3 scenarios presented by Gregory in his first presentation, the first appears to be directly addressable and as does the second (possibly using using a Convention by using an annotation). The third case may be too complex. Paul suggested that we should explore the more complex cases before dismissing them and offered to explore the topic. Gregory volunteered to post a note to the list to initiate conversation online. " Subsequent to that meeting Greg posted a proposed approach to the simple solution that I do not think has been discussed:
http://lists.oasis-open.org/archives/xacml/201011/msg00025.html There are a number of issues that Greg raised at the end of that proposal that probably deserve some attention. One reason I think it is important to pursue this approach is that, imo, the definition of boolean attributes to represent the results of predicate evaluation may, in fact, be the better approach, as opposed to pushing the evaluation of the predicates into the PDP. A couple reasons I think this: it is desirable to define common vocabularies for attributes that the policies will use and that the PEPs will supply as parameters to the xacml request context. chances are that even if the predicates are pushed into the PDP, that the best way to process them, may be to define new functionality, which effectively pushes the solution outside the base set of core and profiles into an "extension". these "extensions" already should be able to be implemented using the "attribute finder" approach, where it is the finder itself that takes on the responsibility of evaluating the predicate and returning a result to the PDP. This started to be discussed in the emails ref'd above, but needs more work. Also, as indicated in my previous email, I recognize the need for "advertising" the policy so users will know what needs to be provided, and I want to mention again, that the unfinished spec WS-XACML may be an excellent starting point for covering that part of the overall problem, which I think is further useful context in that it shows how the AttributeId, one way or another, needs to be pushed out by the policy in order that the PEP may have the info it needs to inform users what they need to provide to access specific resources. Thanks, Rich Gregory Neven wrote: Hi Rich, Paul is right: the credential-based access control from the paper you mentioned is a different discussion that is quite orthogonal to supporting attribute predicates. I'd be happy to have that discussion too, but probably the ideas would be even more invasive in the XACML language and processing model. Best, Greg On 1/27/2011 14:59, Tyson, Paul H wrote: Rich, the topic of credentials belongs in a different thread The starting point and motivation for Attribute Assertions was the presentation (also from Greg) referenced from this post:
http://lists.oasis-open.org/archives/xacml/201010/msg00010.html My proposal for Attribute Assertions just defines a useful superset of XACML that would not affect legacy implementations. Regards, --Paul From: Rich.Levinson [ mailto:
rich.levinson@oracle.com ] Sent: Wednesday, January 26, 2011 19:56 To: Franz-Stefan Preiss Cc: XACML Subject: Re: [xacml] Attribute Assertions in request context Hi Franz-Stefan, Greg, and Paul, I have been trying to understand what this discussion is substantively about since Greg's presentations in October. The most recent discussion on Attribute Assertions, while being fairly concrete, does not seem to me on the surface to provide motivation behind the proposals, leaving me wondering what the need is to what appears to be fairly drastic modifications to the current XACML request/response paradigm by including Policy language, itself, in the form of predicates within the Attributes structure. Also, I recognize that there is a strong desire to address a problem with this technology, so I went back to the original presentation materials to re-familiarize myself with the problem being solved. The original presentation material is referenced here:
http://lists.oasis-open.org/archives/xacml/201011/msg00000.html which is an email I sent on Greg's behalf before he had access to the OASIS email in the necessary manner to send mail to the list. In any event, since I had already reviewed the presentation, I decided to look at the reference document, which is a paper Greg and Franz-Stefan and their colleagues have published and made available here:
http://www.w3.org/2009/policy-ws/papers/Neven.pdf At least for me, I think I understand better now, based on that paper what is trying to be achieved here. Let me see if I can characterize the problem based on the paper in another proposed solution type: According to the paper: "Credentials must be the basic unit for reasoning about access control. Users do not have standalone attributes, but rather own credentials that contain sets of attributes. Credentials must be of a certain credential type that determines the attributes contained in the credential. The policy specifies the credential type that must be used to satisfy the policy. For example, when a government issues birth certificates as well as ID cards, both of which contain the owner’s last name, then the service provider can specify in his policy that he wants the last name as stated on an ID card, not on a birth certificate." To me, the key takeaway here is: "Users ... own credentials that contain sets of attributes." i.e. it appears that a "credential" can be modeled as a "collection of attributes". Therefore, I suggest the following approach to address the problem: Define a new SubjectCategory (see XACML 3.0 setion B.2), for example: "urn:oasis:names:tc:xacml:3.0:subject-category:credential" Define a couple of AttributeIds, such as: "urn:oasis:namee:tc:xacml:3.0:subject:credential-type" "urn:oasis:namee:tc:xacml:3.0:subject:credential-id" Then for a given credential type, the "issuer" can send in an Attributes collection with Attribute elements containing attributes appropriate to that credential-type. Policy statements can use AttributeDesignators to find these attributes and apply appropriate constraints. Also, services can advertise the credential requirements, possibly along the lines of the "Web Services Profile of XACML":
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#CURRENT which is an unfinished spec, but well advanced and may be exactly what is needed to address one of the main objectives in the paper as stated in the abstract: "paradigm shift towards openness and user-centricity where service providers communicate to the users what information they need to provide to gain access to a given resource." Comments, suggestions? Thanks, Rich Franz-Stefan Preiss wrote: Dear Paul, All, >> I summarized my thoughts on this subject in a wiki page, >>
http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext . thanks a lot for the effort of doing so and for choosing such an entertaining example theme :-) The attribute assertion syntax that you propose seems well suited for the problem at hand. Clearly, this would involve changing the XACML language, but let's assume we don't have constraints in that respect. The concept of polymorphic XACML comparison functions is a certainly interesting approach for evaluating policies against attribute assertions. However, Greg and myself have the impression that the polymorphic functions do not work for certain policy structures. We understand that the use of polymorphic functions is intended to allow reusing the existing XACML policy evaluation algorithm, which seems to perfectly work for 'non-nested' predicates, but not for 'nested' ones. Consider the following example that expresses your 'age'-example in terms of a nested policy involving a 'dateOfBirth' attribute: -------------------------------------------- Policy: -------------------------------------------- ... <Condition> <Apply FunctionId="...:assertion-evaluation:date-less-than-or-equal"> <Apply FunctionId="...:date-add-yearMonthDuration"> <AttributeDesignator DataType="...#date" AttributeId="
http://example.org/dateOfBirth "> <AttributeValue DataType="...#yearMonthDuration">P30Y</AttributeValue> </Apply> <AttributeDesignator Category="...:environment" DataType="...#date" AttributeId="...:current-date"/> </Apply> </Condition> ... -------------------------------------------- Request: -------------------------------------------- <Attributes Category="...:access-subject"> <Attribute AttributeId="
http://example.org/dateOfBirth "> <AttributeAssertion> <Apply FunctionId="...:date-less-than-or-equal"> <Apply FunctionId="...:date-add-yearMonthDuration"> <AttributeDesignator DataType="...#date" AttributeId="...:this-attribute"> <AttributeValue DataType="...#yearMonthDuration">P30Y</AttributeValue> </Apply> <AttributeValue DataType="...#date">2011/01/25</AttributeValue> </Apply> </AttributeAssertion> </Attribute> </Attributes> -------------------------------------------- In this example the policy requires a requester to be older than 30 years (by means of the date of birth). As the requestor asserts exactly this predicate, the access should intuitively be granted. (Note: it's unclear whether the predicate in the request shall contain the environment attribute '...:current-date' rather than a concrete date, 2011/01/25 in this case). However, the default XACML evaluation algorithm would fail in this case as the '...assertion-evaluation:date-less-than-or-equal'-<Apply> would consider the whole 'dateOfBirth'-<AttributeAssertion> of the request when encountering the 'dateOfBirth'-<AttributeDesignator> in the policy. To make this example succeed, XACML's default way of evaluating functions would have to be extended. In particular, in the example this extension would have to match the content of the <Condition> "as a whole" (modulo environment attribute substitution, etc.) against the content of the <AttributeAssertion>. In general, in addition to the standard evaluation functionality the extension would have to allow boolean <Apply> elements also to evaluate to true when a corresponding attribute assertion exists in the request., i.e., when an attribute assertion is provided that "implies" the predicate expressed with the <Apply> element. While such implication test could simply be implemented as equality test, also more sophisticated and complicated implication tests based on logics are conceivable here. Another general open problem is how a requester learns what predicate she actually has to provide in the request, i.e. on what basis she shall create the attribute assertions in the request. Also, an open question is which attribute would contain the attribute assertion in cases where the assertion involves multiple attributes (cf. the Short Fat Man fun run example), i.e., which one is chosen as the '...:this-attribute'. >> I implemented a minimal policy evaluator [...] I will share it with the group if anyone is interested. Please do so, I would be curious on how it behaves for nested policies. Best Regards, Franz-Stefan Preiss ------------------------------------------------ Franz-Stefan Preiss IBM Research Zurich Säumerstrasse 4, CH-8803 Rüschlikon, Switzerland +41 44 724 8401
frp@zurich.ibm.com ------------------------------------------------ From: Paul Tyson <
phtyson@sbcglobal.net> To: XACML <
xacml@lists.oasis-open.org> Date: 01/24/2011 03:46 AM Subject: [xacml] Attribute Assertions in request context I summarized my thoughts on this subject in a wiki page,
http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext . I implemented a minimal policy evaluator in XSLT to prove the concept of polymorphic comparison functions to evaluate either attribute values or attribute predicates in the request context. When it is a little further along I will share it with the group if anyone is interested. Although this introduces a bit more complexity, and a lot more room for indeterminate policy evaluation, I think it would be useful extension to XACML. Regards, --Paul --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php