Allowing Plugins

norkakn has asked for the wisdom of the Perl Monks concerning the following question:

Greeting Monks,

I'm writing account synchronization scripts, and I'm not sure how to allow plugins.

Each account has flags stating which queries it was a part of, so someone might be part of a staff_ft query and a student query or whatever. I have a file that lists the queries and then lists the permissions granted by the queries (i.e, login, email, wireless access). I now need to write the logic to set and unset the actual LDAP permissions.

I have an idea, but it seems horribly ugly and wrong, so I'd really like a better one.

Create a package, AccountPermission with something like:
sub new {
my $class = shift();
my $self = bless( { }, $class );
return( $self );
}

To add a permission type, such as login, one would create a login.pm file that would inherit AccountPermission. One would then create two subs, run_if_permission_present and run_if_permission_absent.

All of these would be a in a local lib directory. From the main program, I'd get the directory contents to get the list of all permission plugins and put it into a Set::Scalar.

For each of them, I'd load them in an exec to catch any dies and then create a new of each and then can both function names. I _think_ that this would make sure that the files were reasonably well behaved.

And then do a:
$permissions_to_be_set = $set_of_known_permissions->intersection($permissions);
$permissions_to_be_unset = $set_of_known_permissions->difference($permissions);

Then then run the applicable methods.

I don't see any reason for it not to work. The main part that makes most of my ideas fail is that I need a complete list of plugins, as I need to be able to make sure that if login permissions are removed, the login plugin gets to know that and removes the applicable ldap flags.

Comment on Allowing Plugins

Replies are listed 'Best First'.
Re: Allowing Plugins by dragonchild (Archbishop) on Feb 25, 2008 at 18:12 UTC
To chime in on pc88mxer's comments, the point is that there should be a single authority for any given concept. I like to look at the concept of "Who cares?", as in "Which entity is the one that should be the Subject Matter Expert for this concept?". Every other entity should then defer questions to that SME. Sooo, if you have authorization as a concept, have one authz entity that does the right thing. Everyone else talks to this guy. Also, you've got code (plugins) that are really configuration items (who can login, etc). Don't conflate behaviors (code) with input (data). My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^2: Allowing Plugins by norkakn (Novice) on Feb 25, 2008 at 19:11 UTC
> Also, you've got code (plugins) that are really configuration items (who can login, etc). Don't conflate behaviors (code) with input (data). I guess I was unclear. The reconciliation program figures out that a person should be able to login (because of the import flags). The plugin is given a person and told that this person either gets to login, or doesn't. The plugins are designed not to need any knowledge of which queries guarantee the permission, just that this record needs it.	[reply]
Re^3: Allowing Plugins by dragonchild (Archbishop) on Feb 25, 2008 at 19:22 UTC
The plugin is given a person and told that this person either gets to login, or doesn't. The plugins are designed not to need any knowledge of which queries guarantee the permission, just that this record needs it. So, what exactly is the plugin doing again that a class doesn't? My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: Allowing Plugins by norkakn (Novice) on Feb 25, 2008 at 20:34 UTC
Re^5: Allowing Plugins by dragonchild (Archbishop) on Feb 25, 2008 at 21:33 UTC
Some notes below your chosen depth have not been shown here
Re: Allowing Plugins by pc88mxer (Vicar) on Feb 25, 2008 at 17:44 UTC
Just some questions... Are you trying to convert, say, a relational database to an LDAP database? Do any of the actions (`run_if_permission_present/absent`) depend on the entity they are applied to (e.g. staff vs. student)? Instead of removing individual permissions, what about just rebuilding the entire record for the person? Then you only have to add permissions (to a blank record.) Btw, with regards to LDAP, I've always thought that the strength of LDAP was as a standard protocol. It's been a while since I've looked at it, but if I were implementing an LDAP solution today I'd consider using an LDAP-to-relational DB adapter, and that would obviate the need for a synchronization process. There are other trade-offs, but having a single authority for your data can be a big win.	[reply] [d/l]
Re^2: Allowing Plugins by norkakn (Novice) on Feb 25, 2008 at 18:55 UTC
I'm trying to convert three relational databases into LDAP, which is where some of the fun comes from. (especially since one is a Win3.11 app that I have to manually export) The actions do depend on the entity, but it gets more complex than that, as someone can either be from multiple sources, or from multiple pulls in the same source. I'm doing my best to do the third point. The previous scripts tried to do everything, so the student sync script would sometimes mung an account that was both a student and a faculty member. The scripts that hit the databases just generate the account if it is missing and put down flags saying which stored procedure it is found in. There is a list of permissions granted by each stored procedure (login, email, etc). The script that I am working on now goes through each ldap user and builds a set of what actual permissions they are granted, and then makes sure that they have them (and no others). Some of them (such as an email address and application specific things) shouldn't be recreated each time.	[reply]
Re: Allowing Plugins by pc88mxer (Vicar) on Feb 26, 2008 at 00:14 UTC
Sounds like you have a very interesting problem ;-) I'm just going to shoot off some ideas. I'm making a lot of assumptions about what your schemas look like, and I've never had to do this kind of transformation, so maybe I'm way off base here, but here goes anyway... I'm thinking about splitting the problem into two parts: one to handle the various schemas and another to figure out the permissions. The schema part determines the structure of LDAP entry and the permissions part is called upon to compute whether or not a person has authorization to do various things. First the permissions part. For this I would look at using a role-base access control (RBAC) mechanism. RBAC is very useful for describing access controls where the permissions are associated with roles that can be assigned to people. A person can have more than one role, and (generally) a person only needs one of their assigned roles to grant access in order for them to have access. Note that RBAC is not a specific implementation but, rather, a general architecture of how to describe access controls. Generally RBAC systems are implemented as a rule base where each rule is of the form "role X can do Y to objects of type Z", and wildcards can be used to factor the rule base. When asked "Can person P do Y to z?", the roles of P are looked up, the type of z is determined, and the rule base is consulted to yield a yes or no answer. In an ideal world, authentication clients (i.e. programs that need to know if "P can do Y to z") would query this RBAC system directly. However, since LDAP is designed to answer queries like "what's the value of this field?" what usually happens is that we put this access control logic into the client. For the structure part, the goal would be a factory which given a person would create an object that describes the schema of the person's LDAP entry. Or. equivalently, the returned object could be something that can create the person's LDAP entry. Since schemas are hierarchical in nature (i.e. Students and Faculty are UniversitySubjects which are Persons, etc.), you might be able to use class inheritance here to factor out common behavior. Another possibility is that this object could be a composition of smaller objects which know how to create sub-parts of the schema. Calling `create_ldap_entry` on the top level object invokes the same call on its constituent objects (with different contexts, i.e. a different root), and this process builds the entire record. The way the two parts would work together is as follows: given a person the factory is consulted to produce the correct schema object. The schema object can interact with the RBAC system to compute the values of certain fields which are related to access control and need to take into account all the roles that a person has. For instance, if there is a field 'can_use_dialup' which should be true only for faculty, an RBAC system will compute this correctly if a person happens to be a student and a faculty member. Again, this is just throwing some ideas out there. Does any of them seem applicable to your situation?	[reply] [d/l]
Re^2: Allowing Plugins by Anonymous Monk on Feb 26, 2008 at 16:55 UTC
I'd vaguely heard of RBAC before, but never really looked at it much. Oddly, I think I already implemented a stripped down version of it. My past experience has shown me when I reinvent something that I didn't know had a name, I'm usually destined to do it poorly, so I'll dedicate some time reading how others have built their RBAC systems. I'm still parsing the rest of it, and I'll do some code with it later. Thank your for the info.	[reply]