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

Hi Martin,

On 17/09/2015 2:05 PM, Martin Smith wrote:
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.

I have a solution for ABAC that can support any use case where the constraint can
be expressed in an XACML condition, which is pretty much open-ended. I'm more
interested in seeing if there are any reasonable use cases that can't be expressed
in an XACML condition. I haven't seen one yet.

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)?

At the very least.

Or do we have to account for more complex situations (prevent one actor from all of, say, four actions related to some transaction)?

This isn't difficult. Using the capabilities from the entities profile and
paraphrasing, the constraint checking rule is something like:

    if (action.action-id = "Action A" or
            there exists H in resource.history such that
                H.action-id = "Action A" and H.subject-id = access-subject.subject-id) and
       (action.action-id = "Action B" or
            there exists H in resource.history such that
                H.action-id = "Action B" and H.subject-id = access-subject.subject-id) and
       (action.action-id = "Action C" or
            there exists H in resource.history such that
                H.action-id = "Action C" and H.subject-id = access-subject.subject-id) and
       (action.action-id = "Action D" or
            there exists H in resource.history such that
                H.action-id = "Action D" and H.subject-id = access-subject.subject-id)
       then deny

Or make sure each of three (or more) actions related to a transaction is take by one of three (or more) different actors?

This is the same as saying the current actor must not have performed any other
action previously. The rule is something like:

    if action.action-id in { "Action A", "Action B", "Action C" } and
        there exists H in resource.history such that
            H.subject-id = access-subject.subject-id and
                H.action-id in { "Action A", "Action B", "Action C" } then deny

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

See the answer to 4.

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

The history has to persist from the first potentially conflicting action to the
last potentially conflicting action. It is up to the deployment to ensure that
anyway it chooses. If it can't provide that guarantee then it can't use the
solution I am proposing. Since I'm giving the deployment the latitude to do
whatever it takes then I think I'm safe in saying no other solution for ABAC could
do any better.

The obligation really only requires that the history entity it provides is part
of the request context for any subsequent authorization requests. The application
with the PEP could store the history in the resource, alongside the resource or in
a completely separate database. Instead, the context handler could store the
history entity on behalf of the application in a database it has access to.
Wherever and however the history entities are stored they have to be accessible to
either the applications performing subsequent actions on the resource or the
context handler processing those requests. Either could be responsible for getting
the history into the request context. There is no presumption that it is the same
application or the same context handler/PDP for each access.

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

Ultimately, the meaning of "transaction" is up to the deployment so it is defined
to be whatever it needs to be to encompass all the potentially conflicting actions
on a resource. The better question is whether there are any important use cases
where we can't, or can't practically, encompass all the potentially conflicting

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.

This is drifting back into the realm of static separation of duty constraints.
SSD is about preventing a user being given permissions that would violate the
constraint. In an RBAC environment, permissions are indirectly given by assigning
roles to users. So SSD constraints are checked at the time roles are assigned to
users. In an ABAC environment, permissions are given to users by writing policies
in the PAP. The equivalent of SSD constraints in ABAC would have to be applied as
policies are being written. This isn't practical because in the general case it
isn't possible to tell whether two policies grant conflicting permissions by
looking at the policies alone. A request context is required in order to be
absolutely sure whether two policies grant conflicting permissions, but request
contexts only exist at the time an authorization request is being evaluated, which
is too late for static checking. I think trying to prevent users being given
conflicting permissions is a dead end for ABAC and XACML.

A driver for DSD is accommodating situations where it is reasonable for a user to
have conflicting permissions as long as they aren't exercised in the same
transaction. Hal gave the Maker/Checker example. In an RBAC environment, DSD
constraints are checked when a user attempts to activate a role, which is a
precursor for exercising a permission of that role. SoD constraints in ABAC
can't assume roles or role activation so the only place left to check for
constraint violations is during authorization request evaluation. I would contend
that any static constraint could equally well be treated as a dynamic constraint
and that any dynamic constraint could equally well be satisfied by a check at
authorization request evaluation time using the transaction history.

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.

If I understand your attributes then this would be impractical to administer.
Each subject would need an attribute for each combination of action, resource
and transaction. Each new resource and each new transaction would require more
subject attributes.

What I had in mind would work with the access policies in whatever form they
were in. The rule for checking the constraint would look something like this:

    if action.action-id in { "Action A", "Action B" } and
        there exists H in resource.history such that
            H.subject-id = access-subject.subject-id and
                H.action-id in { "Action A", "Action B" } then deny

If the access subject has performed A or B already then they can't do A or B now.


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 <mailto:bill@parducci.net>> wrote:

    Time: 4:30 PM EST (-0400 GMT)
    Tel: 1-712-775-7031 <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]