← Prev in month ← Prev in thread

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

From
Mohammad Jafari <>
Date
2013-05-28T04:18:05+00:00
ID
Thread
RE: [xacml] Groups - XACML v3.0 Obligation and Advice Authority (OAA) Profile Version 1.0 uploaded
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)

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}

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.

 

Regards,

Mohammad Jafari, Ph.D.

Security Architect, Edmond Scientific Company

 

 

 

From:  [mailto:]
On Behalf Of Steven Legg

Sent: Monday, May 27, 2013 7:56 PM

To: 

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

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

Public Download Link

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

 

Attachment:
OAA.pdf

Description: OAA.pdf
← Prev in month ← Prev in thread