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: [xacml] More on separation of duties

It may may be helpful for us to specify in some more detail the dynamic separation of duties use case we are trying to address. 

For example: 

1.  Do we think we are trying to prevent the same individual from taking both of two actions related to some transaction (request and approve, for example)?  Or do we have to account for more complex situations (prevent one actor from all of, say, four actions related to some transaction)?  Or make sure each of three (or more) actions related to a transaction is take by one of three (or more) different actors? 

2.  Do we assume that all the actions in a transaction subject to DSD requirements are taken using the same resource (i.e., IT system) protected by one PDP and PEP?  Or do we have to account for the possibility of separate systems (ordering, funds approval, receiving, etc.) being involved in a DSD transaction? (This would make keeping a "history" more complex.) 

3.  Can we identify some specific real-world examples of a DSD requirement (perhaps from banking, perhaps, or procurement, or 2-person review of a classified cross-domain data transfer.) 

4.  Do we have to account for "long-running transactions", so that we have to keep track of changes to access provisioning over long periods of time (to make sure access to one action is not provisioned, that action taken, then the first access de-provisioned, and access to the other action provisioned in time to allow the same actor/subject to execute both parts of the transaction.) 

5.  Is the concept of a "transaction" appropriate for all/most of the DSD use cases we want to address?

Also, could DSD be implemented by something as simple as this: 

Given a two-action transaction T, with Action A and Action B required for completion, it is required that access to the control to cause action T-A cannot be given to any actor (subject, user . . )  who has access to the control to take action T-B. 

So, pseudo-code for the implementing DSD rule: 

If request is for access to resource T-A_control and Subject.Attribute_T-A = "Y" and Subject.Attribute_T-B not= "Y" then PERMIT; else DENY.

Obviously this assumes that the actor has been properly provisioned (doesn't have both Subject.Attribute_T-A and Subject.Attribute_T-B set to "Y".) This kicks responsibility for making sure no one has both attributes set to "Y" to the provisioning process and tools, which is probably where that responsibility best lies. 

On Wed, Sep 16, 2015 at 9:24 PM, Bill Parducci <bill@parducci.net> wrote:
Time: 4:30 PM EST (-0400 GMT)
Tel: 1-712-775-7031

Access Code: 620-103-760

Proposed Agenda for 17 September 2015 TC Meeting

I. Roll Call & Minutes
  Approve Minutes 3 September 2015 (updated version):

II. Administrivia

   XACML v3.0 Related and Nested Entities Profile Version 1.0

III. Issues
   No activity on list since last meeting. Current discussion:
    Ideas for new XACML profiles:

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:

Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile

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