OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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

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

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.



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!


    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


    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.


    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

    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

    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:

*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]