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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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


Subject: Re: [xacml-users] Policy question


Hi Ray, Ludwig,

Thanks Ludwig for the additional clarifications on top of my example. You read my mind :-)

Ray, the point is that you would define how a user has access to a document as a whole and then specify additional access for specific fields of that document.

Think of a building: the fact you have the right to enter the building doesn't mean you can enter the secret room on the 2nd floor but it does mean you had the right to be in the lobby. So access to the building is in fact access to the lobby and all public parts of the building. The same applies to your use case where comments are the "public parts" of your building.

Cheers,
David.


On Tue, May 13, 2014 at 9:57 AM, Ludwig Seitz <ludwig@sics.se> wrote:
On 05/13/2014 08:53 AM, Maarten Decat wrote:
Ray,

1.Anybody who can see a document is allowed to see all comments on it.

This is tricky. You can perhaps do it with the access-permitted
function (section A.3.16 of the standard), but implementation of this
function is optional and I don't expect many XACML engines to actually
implement this (it's just too tricky to get this right without open up
the PDP to denial of service)
Indeed it is tricky. I don't think you can express this as you stated it
here. I.e., I don't think XACML allows you to refer to the result of
another policy evaluation in this sense, especially not because the
object of the latter evaluation (document) would differ from the object
of the former evaluation (document).

Read section A.3.16 (the one describing the access-permitted function). It is quite clear from that section that this is indeed possible. I wouldn't recommend it though for the reasons I gave above.

David's approach seems better to me, so here's my take on it:

PolicySet CombiningAlg=DenyOverride {
  Target (high-level resource = document)

  Policy
   Target (action = "" access)
      Rule (if not read access to document deny)

  ... (other policies) ...

  Policy  (no conditions)
    Permit

}


When you try to read a comment, the PEP translates this to a hierarchical request. The higher level hierarchical resource is the document, the lower level are the comments. Therefore the evaluation goes into the PolicySet above.

Then the first policy checks if the subject has read access to the document and if not it denies access.

If all other requirements are fulfilled (the '...' each of which could deny access), the evaluation falls through to the last policy which is an unconditional permit.

This policy would control both, read access to the document and to the document comments.

/Ludwig






--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se




--
David Brossard, M.Eng, SCEA, CSTP
VP of Customer Relations
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
Support: https://support.axiomatics.com 
Web: http://www.axiomatics.com
Axiomatics for developers: http://developers.axiomatics.com
Connect with us on LinkedIn | Twitter | Google + | Facebook | YouTube


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