OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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

On 29/05/2013 05:52, 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.

This does not have the correct semantics in my opinion. Using your notation from below, you need something like

# Obligation (OnAnyResult): approval-required

Intuitively, it must
be possible to write a rule that only triggers obligations (either
OnPermit or OnDeny) with no influence on the Permit/Deny.

Agreed. Example. Securely log the request and the response



 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
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: * Permit, if
Subject.id=*Alice,* and Action.id=*read* # Rule: *
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
# 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 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
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


Mohammad Jafari, Ph.D.

Security Architect, Edmond Scientific Company

[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

/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-



*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-
8/latest/xacml-3.0-oa-authority-v1.0-wd01.doc> Public Download
Link <https://www.oasis-



*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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]