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

[Erik Rissanen <erik@axiomatics.com>]

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.

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?

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">
  <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.

It'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,
> 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 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
>
>
> ---------------------------------------------------------------------
> 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