rights management

[Mark H. Wood]

"Michael Fair" <michael at daclubhouse.net> wrote:
[snip]
> The point I'm driving at is that is that while I see no
> problem for Kerberos being just an authentication platform,
> some standardized methodology for creating an entire IAAA
> environment that utilizes Kerberos should be developed.

I doubt there could be a drop-in package for such a thing, if that's
what you mean.  The best you could do is a reference framework to give
some shape to customized solutions, so that people from different
sites could talk about their solutions using a common set of ideas.

> For instance, if the KDC is only going to provide Authentication
> information, then perhaps the KDC should not be treated as
> the authoritative source for principals.  Perhaps instead
> some other system should be used as the authoritative source
> and Kerberos is an authentication service within that
> other system (perhaps not all principals need authentication,
> they just need identification) and the KDC should actually
> query this other system to verify a principal exists and
> is authorized to be authenticated (AKA the account is active
> and not disabled).  Further, the Kerberos standard should be
> extended and presented in such a way that it expects to be
> subordinated to some other larger authorization system.

I don't understand the need here.  If principal X is known to the KDC,
then he can be authenticated; otherwise, not.  Just because he's got
an authenticated identity doesn't mean that he's authorized to do
anything.  The services know what they will and will not allow various
principals to do.

There's no need for the KDC to query some other service in realtime.
When it's told to create a pricipal, it either does so or explains why
it can't.  When it's told to destroy a principal, it either does so or
explains why it can't.  In between, the principal exists and services
can decide whether or not to serve it.

You can have some "superior" mechanism which creates and destroys both
Kerberos principals and directory objects.  We do something like that
here.  But Kerberos doesn't have to know about that, or support it in
any special way, and neither does the directory.

> It seems to me that Authentication is merely the first step
> in an Authorization scheme.  I cannot think of a time where I
> would care about the identity of a principal outside of the
> case where I am trying to authorize them for something.  It
> seems to always be the case that before you go checking whether
> or not this principal is authorized, you need to find out if
> this principal is who they claim to be and the only time you
> care about this person being who they claim to be is when you
> are about to go find out if they are authorized.
> 
>> > For instance, I have IMAP email, file servers, printers,
>> > ftp servers, LDAP servers, and client workstations.
>> > Each of these systems could benefit from associating
>> > Access Controls to Kerberos Principals, but from
>> > what I can tell Kerberos provides no standardized
>> > way for those services to get help in managing those
>> > ACLs from the Kerberos system.
>>
>> Directory services play very well with Kerberos, and are designed to
>> provide storage for groups, access control, etc.  If you have LDAP
>> running, you have a directory server and that is one good place to
>> centralize authorization.
> 
> But for this to be effective all my other applications would
> need to use an agreed upon authorization method for storing
> data into authorization backend wouldn't they?

Why do the authorization data all have to be in one place?

> I mean I suppose each app could just roll their own, but
> then we've each application having to make their own storage
> formats, no standardized way for creating easy admin tools
> where users/groups can be listed and shuffled around.

Oh, I see the problem:  you want One Tool to Rule Them All.  The usual
solution to this is snap-ins.  NDS is like that, and it stores
authentication data in the directory itself.  Novell provides a nice
tools which lets the admin. rummage around in the directory, but it
can't keep up with all of the things that various vendors and users
are adding to the schema.  So they defined a snapin API which allows
others to write code which knows how to display and manipulate object
types that Novell wot not.

Even so, Netware servers have a distinct authorization database in the
filesystem, which uses directory objects as identifiers but is not
stored in the directory.  The filesystem takes care of its own
authorization needs, as does the directory.  Other services may have
their own notions of authorization, or they can piggyback on the
directory's built-in mechanism.

> You get the potential for separate identifiers since one
> app decides it's going to use the UID of the principal
> where another app decides it's going to use the fully
> qualified kerberos ID DOMAIN/principal and yet another
> app decides just to use the local principal name, and
> yet some other app developed by a guy who really hasn't
> figured it all out yet decides to use his own principal
> names requiring a mapping scheme to be set up because
> he had no tools for testing existence/status of principals.

Well, then, if you don't like that then don't allow them to do it.

> Further, everyone of them either uses the local Unix
> group ID or ends up rolling their own group methodology
> so none of the applications can take advantage of a
> centralized set of groups.

You just found one of the best applications for a directory.  Define
your groups there.  You can create service objects in the directory
and let the services probe for access to them as proxies for the
users, or build local authorization mechanisms which just use the
member lists of directory group objects if that makes more sense.
Again NDS demonstrates the former approach, by defining e.g. printer
objects in the directory and using a printer's ACL to grant or deny
various kinds of access by users.  (Sorry to keep going back to NDS,
but it's not terribly clear where MS Windows keeps this stuff for any
given service type.)

> I really hope I'm completely wrong here and have misunderstood
> something really basic and important that makes none of
> the above true.  I've seen people say "just use LDAP" but
> I don't think any of them have actually set up fine grained
> controls where their Kerberos principals can be put into
> groups and where the same set of principals/groups can be
> granted/denied permissions to print to specific printers,
> access certain directories on filesystems, access certain
> network file shares, access certain folders in the IMAP
> mail store, and access other services (web/ftp/etc) in a
> centralized way where if a principal is added/removed from
> the system (or even just added/removed from a group (if the
> service even supports groups)), the administrator doesn't
> have to go to every single service and tell it that the user
> now exists, or no longer exists.

But why should he do that?  If the KDC says "no such principal" then
the user doesn't exist.  Ditto for the directory -- if you can't
identify a user then he doesn't exist, so far as the service is
concerned.  Fine-grained permissions should be considered exceptions
to the default policy for a service (grant, deny, fire scuttling
charges, whatever).

In most cases you will only need to coordinate two authorities:  the
authentication service and the directory.  Two is not difficult at all
and can (and should) be automated.

> Sure if you remove the user from the KDC they can no longer
> get a ticket for the services, but the ACL information
> (aka cruft) is still there.

NDS has a periodic garbage collection thread for this very reason.
Netware servers have a manually-triggered process to sweep unknown
object IDs out of the filesystem.  Meanwhile a few dangling entries
don't cost enough to bother anyone.  Any system with so much diversity
of information in it is going to need a way to recover from partial
deletions anyway, so why not make it a feature?

>                              God forbid a well ACLed employee
> should get married and change their principal name.
> It'd be great if the administrator could just go in and
> say "principal X is now known as principal Y and principal Y
> principal X is now an alias for principal Y" - but those
> kinds of semantics don't seem to exist in the current schemes...
> (Granted that in my example simply adding an alias to the
>  existing principal would be easier,  but that's not always
>  the case.)

This does seem to be a problem for pure Kerberos since (if I
understand it correctly) the principal name is the most basic
identifier rather than being mapped to some abstract quantity as in
most systems.  ADS has to graft NT SIDs onto its Kerberos principals
since the SID is the primary identifier they want to work with.  ADS
and NDS can handle renaming of a principal fairly easily since they
have this additional abstraction.  But then just about *any* service
(Unix logon, for example) needs to map Kerberos principals into its
own identifier space, so Kerberos *in practice* doesn't really have to
deal with the problem.  Again: rename in Kerberos; rename in
directory; mappings are in some TDATA or directory object attribute
that didn't change, so everybody's happy.

[snip]
>> Notice how Microsoft's AD does it:  authentication is done using
>> Kerberos, attributes of principals are kept in a directory and served
>> up via LDAP, and authorization is the responsibility of each object
>> type (with the OS providing a general access-control framework).  (The
>> accounting bit is kind of mysterious and haphazard but can be made
>> useful.)
> 
> Right, it's that "(with the OS providing a general access-control
> framework)" piece that I can't find an Open Source equivalent of.

Which of the various OSes in a typical enterprise network will be
acclaimed king, and how will you get the makers of the other OSes to
accept its dominion?  Include your print servers, CDROM servers,
SAN/NAS nodes, wireless access points, terminal servers, routers and
bridges and firewalls, network-accessible environmental sensors,
remote-power-off switches, PABX, etc. in your catalog of OSes.

> Some people have suggessted that a system _possibly could_ be
> implemented using PAM, but no one seems to really know exactly how.

Again, I'm assuming that you have a directory to serve as the central
dumping ground for attributes, etc.  Here you go:

foreach SERVICE
{
  define an object TYPE to represent SERVICE;
  create an instance INSTANCE of TYPE for each copy of SERVICE;
  add ACEs to INSTANCE, to taste;
}

and let the code implementing each SERVICE ask for the requested type
of access to the appropriate INSTANCE while posing as the user.  But
read on for some objections.

PAM could make it easy to do this without having to worry about how the
object store is implemented, or about changing it out from under the
services.
 
>> > Are there any Open Source solutions for implementing
>> > a total package solution (where total package is both
>> > Authentication and Authorization - I'll figure out
>> > the others later)?
>>
>> A number of people are using Kerberos+OpenLDAP.
> <snip>
>> Of course the service needs code which can do this.
> 
> And it still doesn't seem to do anything other than
> a Boolean yes/no (as opposed to read/write/execute
> for instance), or it has to provide it's own principal
> tree and manage yet another independent copy of each
> principal that it has a special ACL for (making
> adding/removing/modifying principals a major PITA).

No, an ACE just needs to have some way to relate back to the proven
identity already provided by the authentication service.  The service
doesn't need a list of every principal in the system; it only needs
small lists of principals authorized to access objects under its
control.  If Fred never uses file server Jupiter, then Jupiter doesn't
need to know whether Fred exists.  When Fred requests authority to
access files on Jupiter, some sysadmin creates ACEs which identify
Fred, attached to particular filesystem objects, and that's all that
Jupiter ever needs to know about Fred.

And since Jupiter may have to touch several dozen protected objects to
satisfy a single request from Fred, we don't want it to have to go
talk to a central authorization server every time it steps down a path
to the next inferior node.  We want Jupiter to handle its own
authorization locally, given that it knows this is Fred.

When Fred leaves the organization, we'll clean out these ACEs with a
periodic background job.  To do it otherwise is just too costly.  Fred
may have left his fingerprints on 100,000 files.  (Most of the
filesystem references to Fred will evaporate when we archive and
delete his "personal" storage, and wipe his workstation for reissue.)

Now, if Saturn is a print server, it doesn't make nearly as many trips
to the authorization well per unit time and we don't care if they take
a little longer, so it makes sense for Saturn to hit a centralized
directory service to see whether Fred is allowed to print to it,
adjust it, destroy it, etc.  If we're smart, when Fred leaves we'll
just unlink him from the dozen or so groups which we used to control
access to print servers and similar gear.  In fact, *that* is probably
cheap enough that we can do it synchronously.

> I suppose this also reinforces my earlier semi-conclusion
> that Kerberos should really just be viewed as an authentication
> service within the domain but that even it is a subordinate
> part to a larger authorization system.

I believe this is precisely what was always envisioned.  Notice that
many services have an extremely simple authorization scheme:
principal X may access data owned by principal X.  A mail server only
need know who the user is in order to locate his mail, and should not
be giving him anybody else's mail.

A print server is more complex.  It only needs an authenticated
identity in order to account for use of the resources it provides.  It
may need to execute some form of access control on its own, if the
client sends the job directly to the printer; however, it may only
need to be able to impersonate the user to a spool service and receive
success/failure in return.  It may place access controls on the
ability to manage its internal settings.  But how is any generalized
authorization service going to be able to cope with the varying needs
of dozens of different types of services, some of them not invented by
the people who provided the authorization service?

I think you want to finish the design too quickly.  WE DON'T KNOW all
of the ways that these fundamental services will be used, or the types
of access we'll want to control tomorrow.  By keeping some space
between authentication and authorization, and by *allowing* services
to implement authorization as needed (if they can't or won't use a
central, generic form) we maintain some flexibility as the system
grows and we think of new ways to use it.

You might want to take a look at the larger context in (and for) which
Kerberos was developed.  You can find technical documents for Athena
components at:

  http://web.mit.edu/olh/technical.html

A quick look suggests that, in Athena, some operational information is
centralized, some is replicated from a central authority, and some is
distributed.  I think you're going to see that pattern pretty much
wherever you find networked services.  (Here it comes again)
Netware+NDS is like that, for example.  So is Windows+ADS.  Some
subsystems really are the best places to manage their own operational
data, even though it causes some minor code duplication.  If we
centralize *everything*, we lose the ability to take advantage of
that.

-- 
Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".