[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Ideas for New XACML Profiles
The XACML TC conference call agendas have become rather sparse of late, which
might give the impression that the TC has run out of things to do. Surely not.
I know I have a bunch of topics bouncing around inside my skull that would seem
worthy of XACML profiles.
Here are some topics for which I already have a well-formed solution in mind that
I can readily roll out into a profile, if there is interest!
ROLE ENABLEMENT / DYNAMIC ATTRIBUTE AUTHORITY
First up, because I have an upcoming need for it, is a better way to do role
enablement. Role enablement was stripped out of the final XACML RBAC profile,
mostly because I made it contentious. Quite apart from the issues I had with it is
the problem that the way role enablement was defined was conceptually inefficient.
It required the client of the role enablement authority (which is likely to be a
context handler) to send a request for each role that effectively asked the
question "is this role enabled for this access subject?" The client would also
need a complete list of roles to ask about. If there were 1,000 roles then there
would be 1,000 role enablement requests. Now that this approach is gone there is
an opportunity to come up with something better.
What we really want to ask is "what roles are enabled for the access subject (in
this request context)?" and to do so with a single request. I know a way to do
that with a pair of obligations that carry a list of role values. One obligation
specifies roles that are enabled (inclusions) and the other obligation specifies
exclusions that override the first obligation. The policies mostly contain permit
rules that, if applicable, return either a list of roles to include or a list of
roles to exclude. The rules that return exclusions take the place of deny rules.
An actual deny rule would kill off the whole request when we only want to deny
specific role values. The client unions the role lists of the inclusion
obligations and subtracts the role lists of the exclusion obligations to get the
final list of enabled roles for the subject-role attribute.
I've talked about this in the context of role enablement for the subject-role
attribute, but the technique can be applied to any XACML attribute, in which
case we are talking about a generic rules engine (call it a Dynamic Attribute
Authority) that takes a bunch of attributes in a request context and runs through
its rules to generate a collection of attribute values for an attribute type or
types (it could do more that one attribute type simultaneously).
The Obligation and Advice Authority is also a rules engine that operates on
similar principles though its output of interest is more the obligations and
advice themselves rather than the attribute values they contain. At ViewDS we are
also using XACML policies in a rules engine to generate notifications from a
request context to feed into workflow. The common thread in all these engines is
that we are not interested in an access control decision. The permits, denies and
combining algorithms are just a means to an end. The normal policy framework could
be boiled down into something simpler that uses XACML conditions to express rules
for a rules engine that outputs interesting things (that aren't access control
decisions) using a request context as input. I'm sure others will have ideas for
rules engines where this might be useful.
I could write a profile for a Dynamic Attribute Authority using the normal policy
framework, or take the idea further into the land of generic rules engines, or do
both.
REDACTION
The approach above for role enablement is adapted from a solution I have for
document redaction. In that, the inclusion obligations specify parts of the
document that the access subject is allowed to see, by classification or other
metadata tags, and the exclusion obligations specify parts of the document that
the access subject is not allowed to see despite the inclusions. The redacted
document retains only the explicit inclusions minus the explicit exclusions. The
role enablement authority can be thought of as redacting the list of roles.
The necessary obligations are more conveniently used in conjunction with the
Obligation and Advice Authority.
SEPARATION OF DUTIES CONSTRAINTS
The ANSI RBAC specification defines a couple of ways of enforcing separation of
duties (SoD) constraints in RBAC.
With Static Separation of Duty (SSD) relations, a user's roles are statically
assigned and the relations describe sets of roles that have permissions that are
in conflict. A user cannot be assigned a role if there is an SSD relation over the
user's existing roles and the new role.
Dynamic Separation of Duty (DSD) relations are more flexible. The basic principle
behind DSD is that users can choose which of their eligible roles to activate at
any time. However, a user cannot activate a role if there is a DSD relation over
the currently active roles and the new role. Activation of roles occurs within a
session, but the ANSI specification is vague about what constitutes a session.
In order for DSD to work, certain properties have to hold:
(a) once a user activates a role in a session it cannot be deactivated until the
session terminates and
(b) the actions that are potentially subject to an SoD constraint have to all
occur within the same session.
We need (a) in the general case where conflicting actions are not performed
simultaneously, but spread out in time. We want to prevent a user activating
role A, performing an action, deactivating role A, then activating a conflicting
role B and performing an action. Leaving role A activated, or at least remembering
that it has been activated by the user within the session, allows the DSD
relations to block the activation of role B by that user.
We need (b) to prevent a user activating role A in one session and activating
role B in a separate session to perform the conflicting action. The ANSI
specification doesn't go into any detail about what a session is, but it isn't
(or rather, can't be) what we would typically imagine a session to be. For
instance, it isn't a login session. When I boil it down I reach the conclusion
that "session" effectively has to mean "resource". For each protected resource
we need to remember who activated what roles to perform actions on the resource
so that DSD relations can be checked.
Now this is all in the context of RBAC. We could create an SoD profile as an
adjunct to the XACML RBAC profile and it would work as long as all user
permissions were obtained only via roles. However, XACML is much more than RBAC
and SoD constraints don't go away just because we decide to use ABAC. Fortunately,
we can generalize a solution because we aren't actually interested in preventing a
user having conflicting roles. Roles are a proxy for actions. What we are really
interested in doing is preventing a user from performing conflicting actions. We
don't care how a user came by permission to perform any action, we only care what
actions they previously performed on a resource so that we can check that the
current action isn't an SoD violation. We can readily express the checks for SoD
violations as XACML policies that have the effect of denying access if there is a
violation.
Some resources, by their nature (e.g., a product order), may have fields
containing the history of who did what with the document (e.g., createdBy,
approvedBy, paidBy), so we could describe a solution that assumed resources were
XML documents operated on by attribute selectors, but I'd rather use the entities
profile.
I imagine the history of actions performed on a resource would be a defined
"history" resource attribute containing nested entities. Each nested entity
would have, as a minimum, the subject-id of the user that accessed the resource
and the action-id of that access. An implementation of the profile could add in
whatever other attributes it wanted or needed, like date and time of access,
other subject attributes, other action attributes, phase of the moon, etc.
I would define an obligation that would require the PEP (or some intermediary if
the PEP isn't up to it) to save the attributes in the obligation, associate them
with the resource, and return them as an entity value of the "history" resource
attribute in subsequent authorization requests, along with any previous entity
values. The obligation allows us to be selective about which actions we want to
keep history about and to enforce history-keeping on the PEPs. An obligation to
clear the history may be desirable as well. Potentially conflicting actions are
likely to be steps in a workflow and when we get to the end of the workflow the
history can be discarded.
The normative part of an SoD profile for XACML would be quite short; a resource
attribute and one or two obligations. The bulk of the profile would be examples
showing how to use them. If there's interest in pursuing this then I would like
to hear people's favorite examples, especially if they are curly ones.
So, any takers ?
Regards,
Steven
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]