[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 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, Steven
This 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]