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. 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 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.)
Martin
On Sun, Sep 20, 2015 at 10:42 PM, Steven Legg <> 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
actions.
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.
Regards,
Steven
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 < <mailto:>> 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):
https://lists.oasis-open.org/archives/xacml/201509/msg00006.html
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:
https://lists.oasis-open.org/archives/xacml/201509/msg00000.html
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
*Martin F Smith, Principal*
*BFC Consulting, LLC*
McLean, Va 22102
703 506-0159
703 389-3224 mobile
--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile
