Re: A Filter Based Approach to ACIs

[Erik Skovgaard <eskovgaard@geotrain.com>]

Brian,

I like this idea.  I have several times had the need to distinguish
anonymous access based on whether a user was on the intranet, the extranet
or the Internet.

Some PKI products require anonymous access to the PKI certs, so it is not
always possible to provide proper authentication.  Access based on IP
Address could go a long way to fixing that problem.

Cheers and Seasons Greetings,             ....Erik.

---------------------------------
Erik Skovgaard
GeoTrain/Global Knowledge
Enterprise Directory Planning Services
LDAP & X.500 Training
http://www.geotrain.com

At 15:11 99/12/21 -0700, Brian Jarvis wrote:
>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
>
>
>Attachment Converted: "d:\Program Files\Eudora\Attach\Brian Jarvis3.vcf"
>