[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Ideas for New XACML Profiles
Sorry I am a little late to this party. This thread started just as I was leaving town and I didn't notice it until today.
1) Thanks Steven for starting this. As usual the "reward" for good work is being asked to do more work. History has shown that after a couple of months emails like this get lost in the list. I wonder if you could cut & paste at least the initial comments into the wiki. I think you will need to start a new page with a new issue id, but if there is prior discussion it can be combined.
2) General comment on using ANSI RBAC as a basis for RBAC requirements. IMO, the NIST/ANSI RBAC spec was based on limited use of simple RBAC types which were then extrapolated into uses the authors felt might be useful, but without a firm basis in real usecases. This was quite appropriate at the time (1980's) when even POSIX ACLs were very new.
When XACML was new we defined the RBAC profile to make conversion easier for organizations currently using RBAC and as a proof of concept that XACML could do the things that RBAC can do. However that was 10+ years ago.
The two conclusions I draw from this are A) (as Martin has suggested) we should look for real world requirements from the field and be at least skeptical of requirements developed over 30 years ago, mostly within NIST and B) once we are agreed on a requirement, even if it is formulated as an RBAC requirement, we should look at it from the perspective of "what is the best way for XACML to address this?" whether the solution involves RBAC or not.
3) Dynamic SoD in the financial world is often referred to as maker/checker. Generally you have a pool of employees with the same job and for any given transaction any of them can be the Maker and any of them other than the Maker can be the Checker for that transaction. These transactions can and do overlap in time, thus one is not merely a Maker, but a Maker for some transaction on some account. Needless to say such functionality is usually coded into the financial application rather than enforced by the Access Control System. This is not to say I do not think XACML should tackle the problem.
4) Query re-writing is a technical approach, which can be sued to solve different kinds of problems. One successful use I am familiar with is in the OGC (geospatial) demonstration systems. They used a gateway architecture which intercepts SQL queries.
They found sometimes the policy required them to evaluate a Resource Attribute which was in fact a database field, but was not included in the query because the client was not interested in that data. The approach chosen was to add the additional field to the query, use the data to make the access decision and assuming "Permit" drop the field from what is returned to the application.
The alternative to this is a distinct query against the Resource Attribute and shows potential advantages in performance (fewer queries) and perhaps when database access is not being done as a "superuser". My point is that this has nothing to do with the cases being discussed by Steven and Martin.
> -----Original Message-----
> From: Steven Legg [mailto:firstname.lastname@example.org]
> Sent: Wednesday, September 02, 2015 3:49 AM
> To: email@example.com
> Subject: [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
> 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
> 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.
> 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
> 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 ?
> 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:
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: