[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Ideas for New XACML Profiles
Hi Martin, On 3/09/2015 12:56 AM, Martin Smith wrote:
Steven--sounds like a good list of candidates for attention. An initial comment on two of them: Redaction: your description reminded me of the "query re-write" approach that I believe some vendors have implemented. If we think of the target resource as a result set from a structured database (vs a "document") and think in terms of a SQL query that generates that result-set, then a query like SELECT * from PASSENGERLIST might be modified by the PDP to SELECT * FROM PASSENGERLIST WHERE CITIZENSHIP EQ 'US' (since the requestor does not have attributes that allow access to records of non-US citizens.) I suppose the same type of thing might be done with an XML Query if a document were structured and portion-marked with resource attributes.
The one example of query rewriting I know of actually got it badly wrong. It just seems like a difficult approach to me because there are so many possibilities. The PDP could return advice that contained the redacted document or the SQL expression to do the redaction, but it has to be expressed in just one attribute assignment expression in one policy. That would be really hard to achieve. The PEPs aren't so constrained. They can apply a whole series of separate redaction obligations spat out by different policies.
Separation of duties: Out of scope that we can address, perhaps, but someone has to consider the possibility of a person being able to acquire two different identities (subject identifiers.)
Different identities are a problem but not necessarily different identifiers. For example, working with LDAP, a single LDAP identity (an entry) can have a number of subject-id values: a DN in subject-id/x500Name, a user name in subject-id/string and an email address in subject-id/rfc822Name. I can configure the context handler to accept any of them as identifying the subject (an entry). Whichever one is used in the request, the context handler can fill in the request context with the others. It doesn't matter which one the policies refer to because all of them are in the request context for the access subject. A context handler is allowed to augment any entity so I would treat the history entity in much the same way. It wouldn't matter which identifier appeared in the history because the request context would be filled in with the others. What goes into the history from the request context is also entirely up to the policy writer so he/she could choose to always use, say, email address. A person that manages to get two completely separate and unrelated identities is going to be a problem for any electronic system for enforcing SoD, not just the one I'm proposing. However, I've only ever heard of SoD being discussed in an organizational setting and natural forces within organizations drive towards uniquely identifying the employees. If it isn't an email address it might be some kind of employee number, which would then be the obvious candidate for the history entity. In situations where users are fairly anonymous and/or self-register, and can therefore easily set up multiple identities, I don't see any need for SoD constraints anyway. Solving the problem of multiple identities is out of scope, but discussing it is something that should go in the Security Considerations. > Also, can we assume that a situation that requires DSD also requires comprehensive access logging? Quite possibly. The obligation insists that the action is recorded. It doesn't say how and a PEP might not actually have to do anything to satisfy the obligation. > So the access history should be available. More broadly, a DSD use case is also one where users are acting as legal agents for an organization (and not in their capacity as private citizen.) Thus the perspective on privacy is reversed--from requirement to protect privacy of users' actions (as agents) to requirement for complete accountability. So probably the log is permanent and immutable (though still a protected resource itself, of course.) There isn't normally an expectation of privacy with respect to employees carrying out the duties for which they are employed and SoD constraints tend to be applied to activities that are somewhat visible anyway. > So, the magical context handler can look up the access history of a DSD resource set as an "environmental attribute." The history could appear in an environment attribute but it would also need to include a resource-id to account for requests with multiple resources. Attaching the history for each resource to that resource is a more direct association. Regards, Steven
Martin
On Wed, Sep 2, 2015 at 3:48 AM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:
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
--
*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]