[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Groups - XACML v3.0 Obligation and Advice Authority (OAA) Profile Version 1.0 uploaded
Hi Erik, On 14/06/2013 4:57 PM, Erik Rissanen wrote:
Hi Steven, I think that looks pretty neat. I am not sure about the other use cases. You should know more. There was discussion about obligations on N/A or Indeterminate a few years back. I had a customer who wanted it for some reason so I brought it up as a suggestion here in the TC, but we very quickly concluded that it is some sort of contradiction in terms to have obligations on N/A or Indeterminate.
One does not have to look far to find weirdness as far as obligations are concerned. Take Deny, for example. If a Deny decision has obligations that the PEP cannot perform, then it's supposed to deny access and perform no obligations, i.e., not perform any of the obligations for the very outcome for which the obligations were intended. If a PEP is permit-biased or the outermost combining algorithm is permit-unless deny, then any Indeterminate decision becomes a Permit, necessarily without obligations, possibly by-passing obligations that would have applied had the decision actually been Permit. If a Permit decision has obligations that the PEP cannot perform, then access is denied, possibly by-passing obligations that would have applied had the decision been a natural Deny. Only advice makes complete sense.
The meaning of N/A is that there is no applicable policy, so it appears strange to add an obligation to the decision, since no policy applied, so where did the obligation come from?
Customer requirements :-). > That of course changes slightly if
the policies which contain obligations are separate. But it still appears a bit contradictory to me from the PEP's point of view and I am afraid that there are all sort of subtle issues around those which we don't realize. Similarly, Indeterminate means that there was some kind of error and the decision could not be calculated. Again, if the decision is not known, how would we know what obligations apply?
I imagine that the ability to return obligations on Indeterminate and NotApplicable decisions is useful when the actual decision doesn't matter to the applicability of the obligation. If an obligation was going to be returned for a particular request context whether the decision was Permit, Deny or NotApplicable (which typically defaults to Deny anyway), then it makes perfect sense to return it if the decision turned out to be Indeterminate instead. Regards, Steven
So if those are the benefits of the OAA, then I don't think they are reasons for going for the OAA solution if conditional obligations are a better solution in other respects. Best regards, Erik On 2013-06-14 03:48, Steven Legg wrote:Hi Erik, On 13/06/2013 5:07 PM, Erik Rissanen wrote:Hi Steven, I agree that conditionals on obligations would be the proper solution to this, rather than the OAA. Obligations are very much coupled to the access decision making since they are to be enforced with the access decision. But as your examples show, they are not always 100% congruent with the access decision making, leading to redundancy in policy expressions. If you had conditionals in obligations, I suspect that you could do all you want to by means of setting the right conditionals and putting the obligations at the right depth in the access decision tree.Conditions on obligations would address my immediate requirements. One thing that the OAA can do that conditions on obligations couldn't is return obligations on NotApplicable and Indeterminate decisions. That isn't a particular requirement for me, but others may find it useful.What I don't like with the OAA policies is that there is an access decision being used to select the obligations and advice. This works, but it's a bit clumsy since the way in most cases you want to correlate the obligation policies with your access decision policies, you need to partially mirror the access policies, leading to redundancy. Also, I suspect that it will also be a bit tricky to use the decision combining algorithms to select among the obligations. I understand that you are trying to avoid to change the core schema, but what is your opinion? Would conditional obligations be a better solution ideally?I don't think it's universally the case that one is better than the other. For instance, one could use the first-applicable combining algorithm in an OA policy to do overrides between obligations more easily than with conditions on obligations. On balance, conditions on obligations are probably better, and easier for users to get their heads around if they are modifying policies at a low level (a good PAP interface can, of course, hide the gory details).If so, and since we are modifying the PDP behavior anyway to support this profile, we could define a separate schema which links obligations with conditionals into the access policy set through policy identifiers. Something like this: <ObligationExpression location="some-policy-identifiers">That would have to be a list of policy (set) identifier and version pairs, and a separate list of rule identifiers since they are strings rather than URIs.<Condition>....</Condition> <AttributeAssignmentExpression>....</AttributeAssignmentExpression> </ObligationExpression> A PDP which implements this profile would be required to accept files with augmented obligations like these and reference them during policy evaluation.A reason why I didn't go with a separate schema was to avoid having to define additional protocol support for fetching the separate stuff from a PAP. A deployment could also make use of stock standard, off-the-shelf PDPs and PAPs by building a simple front-end that sends the original request to the access PDP, forms the OA request to send to a second PDP acting as the OAA and combines the results to send to the PEP. If there is wide support from PDP vendors to do something more intrusive, then the latter point is no longer important. The additional protocol support is still relevant, so I would rather than we use XML Schema extensibility to actually add conditions to obligation expressions. That way the extra "stuff" just gets piggy-backed around with the policies and policy sets. I was thinking of substitution groups used like so: <xs:element name="ConditionalObligationExpression" type="ConditionObligationExpressionType" substitutionGroup="xacml:ObligationExpression"/> <xs:complexType name="ConditionalObligationExpressionType"> <xs:complexContent> <xs:extension base = "xacml:ObligationExpressionType"> <xs:sequence> <xs:element ref="xacml:Condition" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> Similarly for AdviceExpression. The attachment is what my example policy from the profile would look like using ConditionalObligationExpression. In practice, the obligation expressions would be pushed to an outer policy set to expand the scope. While we're about it we could add conditions to targets in the same way. Regards, StevenIt's a bit more intrusive to implement than a separate OAA, but not by much I think. And tooling could easily give a fully transparent view of this so it appears as if you had conditionals in obligations in the XACML policy. Best regards, Erik On 2013-05-30 09:40, Steven Legg wrote:Hi Mohammad, On 29/05/2013 2:52 PM, Mohammad Jafari wrote:I see. I think the root of this problem is that the schema does not allow writing a pure obligation rule without making any authorization decision, i.e. once more, there is a forced coupling between authorizations and obligations. I think if we allow an explicit Indeterminate in rules (i.e. <Rule RuleId=... Effect="Indeterminate">), this will allow pure obligation rules which are agnostic w.r.t. authorization. Intuitively, it must be possible to write a rule that only triggers obligations (either OnPermit or OnDeny) with no influence on the Permit/Deny. I think this solves the problem in the case of your use-case as well.We already have a way to trigger obligations without influencing the decision. That's what obligation expressions on policies and policy sets do, but they trigger on the full scope of the target of the policy or policy set. I've said previously that what's needed is a condition in an obligation expression so that we can be more selective. On OA policy with deny-overrides and a bunch of OA rules with obligations is acting much the same as having those same obligations embedded in the outermost access policy set and the conditions from the OA rules attached directly to the obligation expressions instead. Regards, StevenThis requires a small change to the core schema though. Regards, Mohammad-----Original Message----- From: Steven Legg [mailto:steven.legg@viewds.com] Sent: Tuesday, May 28, 2013 6:27 PM To: Mohammad Jafari Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - XACML v3.0 Obligation and Advice Authority (OAA) Profile Version 1.0 uploaded Hi Mohammad, On 28/05/2013 2:17 PM, Mohammad Jafari wrote:Thanks Steven for posting this. In Section 2 there is a use-case which motivates the profile. To summarize,your use-case requires:-Bob can "create", "read", "update" and "destroy" documents. -Alice can only "read" document. -"Create", "update" and "destroy" by anyone must be logged. -Any operation on sensitive resources must take approval. You have argued that adding the obligations requires splitting the authorization rules, but I don't see why this is necessary. Correct me if I am wrong but I think these requirements can be formulated by thefollowing PolicySet without splitting the rules:(I have attached a PDF if you are reading in plain text): ================================================= * PolicySet 1 (deny-overrides) o PolicySet 1.1 (deny-unless-permit) + Policy: 1.1.1 (deny-overrides) # If Resource.type=*document:* # Rule: 1.1.1.1: * Permit, if Subject.id=*Alice,* and Action.id=*read* # Rule: 1.1.1.2: * Permit, if**Subject.id=*Bob* and Action.id in {*create*, *read*,*update*, *destroy*}o Policy: 1.2 (deny-overrides) + Rule 1.2.1: CUP-log # Permit if Action.id in {*create*, *update*, *destroy* }, andResource.type=*document:*# Obligation (OnPermit): log + Rule 1.2.2: Sensitive-docs # Permit if Resource.approval-required*=true *and**Action.id in{*create*, *read*, *update*,*destroy*}: # Obligation (OnPermit): approval-required ================================================= Suppose Bob wants to update a sensitive document. This will match policyset 1, 1.1, and 1.1.1 and causes rule 1.1.1.2 to evaluate, permitting the access. But since the overarching combining algorithm is deny-overrides, policy 1.2 is also evaluated. Again since the combingalgorithm is deny-override, both rules are evaluated triggering both obligations to log and take approval.Any other authorization rule can go under policyset 1.1 and any otherobligation rule can go under policy 1.2. PolicySet 1 isn't entirely equivalent to my example because it turns NotApplicable and Indeterminate decisions into Deny decisions, so it depends on an assumption that the PEPs were deny-biased. However, it isn't a general solution because it doesn't support deny obligations (and it would suppress any useful missing-attribute errors). I tried a range of variations on the same theme to support both permit and deny obligations, but the best I could come up with was an arrangment that had the unfortunate side-effect of turning NotApplicable and Indeterminate decisions into Deny decisions with obligations. Ouch! Regards, StevenRegards, Mohammad Jafari, Ph.D. Security Architect, Edmond Scientific Company *From:*xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] *On Behalf Of *Steven Legg *Sent:* Monday, May 27, 2013 7:56 PM *To:* xacml@lists.oasis-open.org *Subject:* [xacml] Groups - XACML v3.0 Obligation and Advice Authority (OAA) Profile Version 1.0 uploaded /Submitter's message/ This is the initial draft for the Obligation and Advice Authority Profile. -- Dr. Steven Legg *Document Name*: XACML v3.0 Obligation and Advice Authority (OAA) Profile Version 1.0 <https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=49348> ---------------------------------------------------------------------- -------------------------------------- *Description* This specification defines a new XACML system entity, the Obligation and Advice Authority (OAA), which makes obligations and advice easier to manage by separating the determination of applicable obligations and advice from the determination of the access decision by the PDP. Download Latest Revision <https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/49348/latest/xacml-3.0-oa-authority-v1.0-wd01.doc> Public Download Link <https://www.oasis-open.org/committees/document.php?document_id=49348&wg_abbrev=xacml> ---------------------------------------------------------------------- -------------------------------------- *Submitter*: Dr. Steven Legg *Group*: OASIS eXtensible Access Control Markup Language (XACML) TC *Folder*: Specifications and Working Drafts *Date submitted*: 2013-05-27 18:56:15--------------------------------------------------------------------- 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--------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]