A Filter Based Approach to ACIs

[Brian Jarvis <BJARVIS@novell.com>]

I recently had a conversation with some marketing types who lamented the fact that they had difficulty selling to the military because we could not grant rights based on login-location (IOW subnet)  *AND* userID.  It seems that it is desirable to give rights to a user, but only allow him to exercise them from privileged locations (with secure wiring).

In most highly secure systems this would be handled by giving the userID discretionary rights (ACIs) and then limiting access to the same resources by using mandatory access controls (labels) based on login location.  This works because the combining of mandatory and discretionary access controls is an AND (minimizing) operation.

In the current ACL draft-04, there is support for login location support but no ANDing operation:

    "The subjectDN may be a DN or another string such as IPAddress (dotted-decimal string representation) on which access control is get/set." (section 8)

<Waxing Philosophical>

But what is an ACI really?

An ACI is a set of privileges granted (or denied) for a set of subject objects to act upon a set of target objects.
How we define the "set of subjects" and "set of targets" is interesting.  Right now we are defining them as a single object, as a subtree, as members of a group, as occupants of a role, or as an ip-address.

Generalizing, we really want to define these sets by using filters (as used by search).  Thus the set of subject objects is defined by a "subject filter" and the set or target objects is defined by a "target filter".

<UnWaxed Reality Restored>

Access control needs to be fast.  Generalized filters are too slow.  So lets limit the generalized filters to limited filters that we can perform quickly.  Filters are arbitrary nested expressions of ANDs and ORs of AVAs (attribute value assertions).  They can all be simplified to a "sum of products" or a "product or sums".  The product of sums seems more useful to me.  I fact lets limit it futher to a "product of terms" and limit the terms to what we can evaluate quickly.

The current draft is more limiting.  The filters are a single term out of small set of choices.  

Subject Terms
   single DN (currently supported)
   subtree (currently supported)
   member of a group (currently supported)
   occupant of a role (currently supported)
   any (currently supported, "public")
   subject and target are same object (currently supported, "this")
   ip-address (currently supported)
   ip-subnet (new)
   NOT <any of the above terms> (new)

Target Terms
   single DN (currently supported)
   subtree (currently supported)
   any (currently supported, on root of tree)
   subject and target are same object (currently supported, "this")
   object class (new)
   NOT <any of the above terms> (new)

<Blue Sky mode>
If we get ambitious, we can also do

Subject Terms
   arbitrary AVA on subject object
   special kind or level of authentication
   secure connection

Target Terms
   arbitrary AVA on target object
   time of day

<Back to gray sky reality--it looks like snow, here>

If each ACI has a list of subject terms and list of target terms (from the above lists) and ALL of the terms must evaluate true for the ACI to apply we have a very powerful system that is still quick to compute.  We will be able to do all of the following (actual requests from customers):

subjects = subtree - particular user = subtree and not dn
subjects = subtree - group = subtree and not group
subjects = subtree - (smaller) subtree = subtree and not subtree
subjects = groupA and groupB (intersection of groups) = group and group
targets = printer objects only = object class printer
subjects = admin logged in on special terminal = dn and ip-address
subjects = admin logged in on subnet (such as a military base) = dn and ip-subnet

Although I have thought about it, I have intentionally not discussed how to implement this in our ACI format or how vendors may extend the available filters.  The collective must be at least interested in this approach first.

I believe this "product of limited terms" approach will be similar in computational difficulty to what we currently have while the power of the ACI will go up dramatically.

I look forward to your comments.

--the walrus

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Brian Jarvis - Novell
TEL;WORK:801-861-3856
ORG:;NDS Administration
TEL;PREF;FAX:801-861-2292
EMAIL;WORK;PREF;NGW:BJARVIS@novell.com
N:Jarvis;Brian
TITLE:Engineer
X-GWUSERID:BJARVIS
END:VCARD