[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 <firstname.lastname@example.org <mailto:email@example.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]