Re: PatternConflict exception

[Bob Burt <bburt@2ab.com>]

Bob,

OK, the way I understand it (and I did not hear your discussions in Austin)
an implementation would have someone register a pattern (I am also thinking
that a resource name with no GRE characters is a pattern and that's another
issue).  They would do this only once, the registration would be persistent.

Now someone comes along, calls access_allowed, which eventually calls
get_policy_evaluators.  The PolicyEvaluatorLocator is going to have to
maintain some data structure (hopefully one that isn't on external storage)
that contains a collection of resource_name_pattern -
vector<policy_evaluators> associations.  It must then search this
collection to find a pattern that matches the input resource name.
Hopefully it has some nice fast algorithm to do this.  Assuming it already
knows there are no conflicts, it can return the collection of evaluators.
If it cannot assume that it has no conflicts, I thinks it has to examine
each and every entry in the rname-evaluators association collection to
ensure that it does not have any more matches.  If there are a million
patterns, then it would have to attempt to match each of the million, not
just the first match found.  Unlike register_pattern, which is done only
once per pattern ever (it's persistent), this search algorithm must be do
for each and every call to access_allowed.  Just off the top of my head, I
don't see any neat ways to accomplish this without burning lots of cycles.
Any suggestions?

I may mumble about performance issues, but from my experience building an
access-control system for BellSouth, they were extremely interested in the
fact that the access-control (in fact the entire security mechanism)
mechanism imposed minimal overhead.

Bob
At 04:11 PM 2/25/99 -0600, blakley@us.ibm.com wrote:
>
>
>Bob,
>
>You're making me worry :-)
>
>What issues do you think will arise?
>
>My mental model of a naive implementation is:
>
>     Find all matching patterns (you'd have to do this anyway)
>     Concatenate lists for each evaluator
>     Eliminate duplicates.
>
>Only the last step seems to have any interesting performance implications,
>and I there's clearly
>a log(n) algorithm for it (where n is the total number of evaluators in the
>concatenated list).
>
>I think it's also not a common case that a name will match multiple
>patterns
>
>
>
>--bob
>
>Bob Blakley
>IBM Lead Security Architect
>Voice: +1 (512) 838-8133
>Fax:    +1 (512) 838-0156
>Post:    11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
>Internet: blakley@us.ibm.com
>
>
>
>Bob Burt <bburt@2ab.com> on 02/25/99 02:58:54 PM
>
>To:   Bob Blakley/Austin/IBM, Konstantin Beznosov
>      <beznosov@baptisthealth.net>
>cc:   hrac-rfp@cs.fiu.edu
>Subject:  Re: PatternConflict exception
>
>
>
>
>
>Bob,
>
>I assume that you have evaluated the runtime performance costs that might
>be associated with the implementation technique described below.
>
>Bob B.
>
>At 11:31 AM 2/25/99 -0600, blakley@us.ibm.com wrote:
>>
>>
>>Konstantin's view is correct.  I've provided Carol with text which says
>>that the list of evaluators returned
>>when more than one pattern matches the name provided via input argument is
>>the union of the evaluators
>>on the lists of all the matched patterns.
>>
>
>
>----------------
>Broadcast message to hrac-rfp from Bob Burt <bburt@2ab.com>.
>Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.
> 

----------------
Broadcast message to hrac-rfp from Bob Burt <bburt@2ab.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.