RE: [xacml] Groups - XACML v3.0 Obligation and Advice Authority (OAA) Profile Version 1.0 uploaded

[Mohammad Jafari <mjafari@edmondsci.com>]

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. 

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 the
> following 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* }, and
> Resource.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 combing
> algorithm 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 other
> obligation 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,
> Steven
> 
> >
> > Regards,
> >
> > 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?docu
> > ment_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/4934
> > 8/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
> >