Generalize authn and authz

Bug #305702 reported by Evan Broder on 2008-12-06
2
Affects Status Importance Assigned to Milestone
Invirt Project
Medium
Unassigned

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) on 2008-12-06
Changed in invirt:
importance: Undecided → Medium
Evan Broder (broder) wrote :

I've started to do this on the authz side. In r2259-r2562 I created the invirt.authz.locker 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 invirt.authz.locker 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  Edit
Everyone can see this information.

Other bug subscribers