Generalize authn and authz

Bug #305702 reported by Evan Broder
Affects Status Importance Assigned to Milestone
Invirt Project

Bug Description

We currently bake certificate and Kerberos authn and AFS authz pretty deeply into various parts of the code base, in spite of the fact that /etc/invirt/master.yaml claims to support a list of authn and authz mechanisms.

We should figure out how to generalize the authn and authz code, reduce it to the minimal set of necessary calls, and implement some kind of library interface so people can provide their own authn/authz modules.

We should probably be sure that this new interface can do things like generate the Apache config.

Evan Broder (broder)
Changed in invirt:
importance: Undecided → Medium
Revision history for this message
Evan Broder (broder) wrote :

I've started to do this on the authz side. In r2259-r2562 I created the module, which encodes our conventions for authorization, as well as invirt.authz.mech, which is automatically loaded as which module to use based on our config file.

I ended up giving the authz API a very simple interface: expandOwner(owner) and expandAdmin(admin, owner). Based on a preliminary scan through our code, I'm pretty sure I can replace all of our uses of getafsgroups and cache_acls with those two functions, although I'll have to be sure.

The module also handles acquiring tokens as necessary, so we can probably punt a lot of code structured around getting or keeping tokens (the cache_acls cron job, the wrapper around /etc/init.d/apache2, etc). We should do some tests to make sure it's not having an unacceptable effect on performance, although in my mind the impact would have to be pretty high, given the overhead of other operations, especially in the web interface.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.