MIT KDC & multiple admins for subsets of principals

[greg@enjellic.com]

On Mar 6,  9:12pm, Russ Allbery wrote:
} Subject: Re: MIT KDC & multiple admins for subsets of principals

Good day, hope the end of the week is going well for everyone.

> "Matthew J Smith" <matt.smith at uconn.edu> writes:
>
> >> I wrote a plug-in architecture for the MIT krb5kdc/kadmind system
> >> which allow them to be functionally extended with shared library
> >> plug-ins.  The kadmind plug-in currently implements storage of raw
> >> passwords, ala AD, within the database.  It wouldn't be a stretch to
> >> implement a hook within this framework to poll LDAP for a list of the
> >> identities which a principal with administrative rights could execute
> >> changes against.

> > Is there any chance that the main MIT codebase would ever include
> > such a plugin architecture, to facilitate extended functionality
> > such as my complex ACL use case?

> Count Stanford University as another group interested in such a
> thing.  We have our own policy and authorization layer sitting in
> front of kadmin right now, but it would be really nice to replace
> that with hooks inside kadmind so that users could follow standard
> web documentation for downloading keytabs without having to use
> Stanford-specific programs.

Clackety, clack, clack, click, clack, click....

Ok that was reasonably straight forward.

Hooks were added to the plug-in architecture to allow functional
extension of the kadmind authorization check functions
(kadm5int_acl_check, kadm5int_acl_impose_restrictions).  A bit more
testing and clean up is needed but it should be straight forward to
implement customized authorization checks to kadmind through this
infra-structure.

A proof of concept shared library plug-in was also developed to test
the framework.  It doesn't implement any authorization checks but does
print out the administrative principal, target principal and the
action/ACL mode being requested.  A person should be able to go
hog-wild from that point.

Currently the outcall from kadm5int_acl_check is the most useful.  The
kadm5int_acl_impose_restrictions extension was added for completness.

To do all this properly requires a discussion of how to extend the
restriction_t structure to allow information to be passed between the
two functions.  As things currently stand
kadm5int_acl_impose_restrictions really only makes sense with respect
to the restrictive convenants which can be appended to ACL directives
in the kadmin.acl file.  A void * private pointer in restriction_t
would certainly suffice.

We are currently developing against 1.4.3 under Linux only.  The
plug-in infra-structure is bog standard and only needs dlopen et.al.
Anything which implements that should work.  Depending on platform
selection you might need to tell the build how to do the equivalent of
-ldl.

> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

Anyone who thinks this stuff might be useful can feel free to holler.

I apologize for the delay in responding.  I was skiing on a glacier
for a few days.

Best wishes for a pleasant weekend to everyone.

Greg

}-- End of excerpt from Russ Allbery

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"Our attitude with TCP/IP is, `Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks -- nobody can.'"

"TCP/IP is OK if you've got a little informal club, and it doesn't make
any difference if it takes a while to fix it."
                                -- Ken Olson
                                   Digital News, 1988