Kerberized authorization service

Anne & Lynn Wheeler lynn at garlic.com
Tue Feb 12 15:05:00 EST 2008


Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:
> You know, I never liked the term "roles".  It's a "hot" term in the
> theoretical world, but I guess I never see a practical use of it when
> we get down to actually assigning rights to people.  To me the easier
> concept is ACL - that's something that just naturally fits into the
> sort of access control decisions we want to make.  The examples I've
> seen where they show "role" assignment always seem contrived, and
> somehow we never end up doing things like that.

part of NIST/RBAC from a decade ago was to provide some support for
separation of duties. this is somewhat trying to get back to (at least)
the early 80s when multiple party operations was being used as
countermeasure to insider fraud. the internet somewhat distracted
attention from insider fraud ... even tho during the period, it has
continued to be as much as 70percent of the problem.

fine-grain permissions would be separated into roles with a view to
supporting separation of duties ... as part of multi-party operations as
countermeasure to insider fraud.

the problem in the real word ... was that the separation of permissions
might not completely account for real business processes. Since some
amount of the institutional knowledge may have evaporated with regard to
all the work that went into exactly which permissions needed to maintain
separated ... and the sometimes mismatch between the aggregate defined
roles not matching real-world roles ... the same individual might be
assigned multiple roles ... undermining the objective of mandating
multi-party operations and separation of permissions (as insider fraud
countermeasure).

because of the typical roll-up of permissions into roles and the way the
related hierarchical information was being maintained ...  it frequently
was not possible to easily evaluate consequences of assigning the same
individual multiple roles ... aka would the aggregate set of permissions
violate multi-party mandates and negate the insider fraud
countermeasures) ... or exactly what are all the possible combinations
of fine grain permissions that will create insider fraud opportunities
(and undermine separation of duties)

part of the issue getting back to the early 80s state-of-the-art is
maintaining the separation of duties and permissions and then having to
deal with multi-party collusion as a vulnerability ... and then working
on developing collusion countermeasures.



More information about the Kerberos mailing list