in reply to Allowing Plugins

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.

Replies are listed 'Best First'.
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]

In Section Seekers of Perl Wisdom