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 22/09/2015 12:42 AM, Martin Smith wrote:
Steven-- Good point about not being able to solve DSD in policies. But perhaps there is another possibility, using resource tagging. It seems likely one could identify the need for separation of duties (and the specific actions that are required to be separated) at the time a DSD transaction is established/defined, or a risk analysis is conducted.

The SoD constraints are inherent in the actions one chooses to support. You
wouldn't choose separate Maker and Checker actions (or request & approve, etc.)
unless you meant them to be done by different people. So it's part of the design
of the access control system.

> Then perhaps the different resources/actions that had to be separated could be tagged as being involved in a DSD group. The  IDs of the other members of the DSD resource group would have to be made available to the PDP so it could check whether the requestor had user attributes allowing access to more than one DSD-group member resource (and so DENY..)

The entities profile has the expressive power to reference history from different
members of a resource group if that sort of thing is required.

What agent would be putting these user attributes into access subjects ? These
attributes look and act like permissions, that something must be explicitly
assigning to users. Explicitly assigning permissions is kind of denying the point
of policy-based access control. In the extreme, PAPs, policies and PDPs aren't
required. The PEP can just ask the PIP for the permission attributes if it wants
an access control decision.


The other member resources of the DSD group could be identified as part of each tag (bulky, perhaps) or perhaps in a separate dataset that contained identifiers for all DSD-linked resources.

For the use case where members of a group of users could do either of the actions in a DSD resource group, as long as they didn't do both/all of the actions, this approach would require modification of the attribute of a user who accessed one of the DSD-group's resources so that he/she no longer had access to the remaining resources in the group. (This user attribute modification could be handled via XACML obligation.)


On Sun, Sep 20, 2015 at 10:42 PM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:

    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> <mailto: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> <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 <tel:703%20506-0159>
        703 389-3224 <tel:703%20389-3224> mobile

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