Looking to get a sense of what various co-maintainers are looking to contribute. As an API, this will need to be very stable, have well thought out public functions, and good unit testing. As an API it will also need to have modules that leverage it, even if they are proof of concept modules. As it will be leveraged by authentication and authorization modules it should be fairly well tested for security.
So what roles are people intereted in playing?
- writing simple tests
- specing out the api itself. I already have an alpha but it needs a good look
- documentation
- getting other ldap modules to leverage it.
- exportables and patterns support
- ...oh and coding the api module itself
Late next week I'd like to skype or irc with whomever is interested in contributing or being co-maintainers to get things going. I have a deadline coming up middle of this week, but may get code cleaned up and posted before then.
Please be sure to take a look at the scope of the api module itself on the project page (6 points). I'm flexible on this, but am not interested in large amounts of philosophical/scope discussion. That is I would like to have a good discussion about the functionality and architecture of the module, then get to work on the unit tests and write the module.
Comments
Comment #1
retsamedoc commentedI'm up for coding\specing out the API. Probably something that needs to be done aside the documentation. Otherwise, I am perfectly happy writing some additional modules to leverage the LDAP API (I'm currently working on LDAP Content Profile to fill in a gap the previous LDAP Integration module is lacking).
I would really like to see what functions have already been written for the API and what remains to be written. I feel that there are plenty of good OSS examples of LDAP<->PHP interaction that we can leverage. No reason to reinvent the wheel.
Comment #2
johnbarclay commentedI paged through the adLDAP.php library for a lot of functions. Please add and comment on them. I don't do much with writing to the LDAP so am unclear on the utility of those functions. I think a wiki would be better for hashing out the functions and methods of the api, but am not sure where on drupal to put one. I'll look into that. I committed the code I had. I haven't really looked at in 6 months, so not sure what state its in.
I see 2 sets of functions:
1. ones that were about configuring or querying ldap instances. These I put in the .module file: (first code set below)
2. ones that only make sense in the context of a particular ldap connection. I made these methods and properties on an ldap class which would be instantiated based on an ldap configuration. (second code set below)
I'm generally looking at a stored ldap configuration as a given server and service account such that a single LDAP server might be used in different ldap configurations for different purposes.
Comment #3
retsamedoc commentedOverall I think we are on the same page. No reason to rebuild the wheel. The only concerns I have are:
I think this is generally what @johnbarclay had in mind. I've been working on a reformat and standardization of the above code that I should have ready in another day or so (including a skeleton module to build upon). I hope I'm not over stepping, I just want to get a good start.
I fully agree about a wiki to further collaborate/solidify the API. If we can't get a wiki on drupal.org, perhaps we should create a Mediawiki on either your or my domain. I can get one going pretty quick if needed.
Just for openness, here is part of my ldap_server class:
Comment #4
retsamedoc commentedAdditional thoughts on what our final result should be is a series of modules and sub-modules that use LDAP API but remain separated in order to keep it maintainable. We do not want to fall in the trap that so many others have with monolithic codebases.
What I see/hope/wish is to someday see this in admin/build/modules:
The Lightweight Directory Access Protocol Package (and sub-modules)
I figure that LDAP Authentication and Authorization should remain as sub-modules to LDAP API (without them, LDAP API is not very useful on it's own). The others should be separate projects.
Comment #5
ebeyrent commentedI'll be happy to work on the Groups integration. The work I did on the extended_ldapgroups module is a good start, but I'd love to get it working as part of this effort. The interesting part of this is that the Authentication and Authorization are really tied together, and the challenge there is to do it in a decoupled way.
Any thoughts regarding how you think we should tackle this?
Comment #6
retsamedoc commentedI don't think it would be that difficult. The authentication would only touch the 'users' table while authorization would touch the 'roles' table. Both have been done before in LDAP Integration (LDAP Auth and LDAP Groups).
I'm currently reading up on how to properly handle external authentication (apparently you need to use hook_user, user_external_login, and a handful of other functions; using the builtin OpenID module as an example). I suppose it would be worthwhile for you to open a new issue involving the authorization and post some code. It would be useful to know which functions you need and what each one does so that we can determine if they make sense to include in the API. Does that sound good?
Comment #7
ebeyrent commentedI guess what I am getting at is that if Authentication handles sync of users, part of that is the user's groups/roles. When the user authenticates, we need to make sure that no new groups have been added to the user account in LDAP. If they have, we need to grant the matching role in Drupal. I think that all of that functionality, as you mentioned in #4, should happen in the Authorization module. I can pull a list of ldap functions that I use in the ldap_extendedgroups module so that we can include them in the API, but might it be a good idea to include all of the ldap functions in the API?
If you want to look at another example of remote authentication, you can take a look at the Crowd SSO module (http://drupal.org/project/crowd).
Comment #8
retsamedoc commentedNot entirely true. Both modules can tie in to Drupal's login system and run when appropriate. The point would be to allow for somebody to use LDAP for roles but have another method handle login (like using Kerberos 5 with HTTPAuth + mod_krb5 + SPNEGO). That is my classic example since plenty of site use a combination of Kerberos and LDAP. I'm sure there are plenty of other examples that make me seem a little less crazy.
Thanks for the heads up about Crowd SSO, I'll definitely take a look.
Comment #9
retsamedoc commentedI've committed all my work done thus far. It is mostly a skeleton but I really wanted to get some code somewhere. I was attempting to make the whole API very object oriented, using the phpLDAPadmin project as an example. I will continue to hash out how the different object should interact, but in general: 'servers'->array('server'->array('entry'->array('attribute'($key=>$value))))
This along with a few generic helper functions for each object type should provide the bulk of the API. I've even gone so far as to extend the attribute classes for special types. The hope is to be able to provide some input sanitation and syntax handling BEFORE we attempt to modify LDAP. Should also provide enough abstraction that our API can handle any particulars between OpenLDAP, Netscape Directory, Active Directory, etc without any future Drupal modules having to care.
Comment #10
johnbarclay commentedMy initial code is in head. I'm converting it to D7 also. I'm definately on board with focus on the api. I tried to even separate out the server from the api, but no luck. Do you both agree on these points:
- the ldap server configuration interface should be in the ldap api module
- an ldap server instance should be represented as an object/class in our code
- authentication, authorization, etc. should be in sub or other modules
- a functional requirement of the api is for authorization and authentication to be separateable.
Are you also in agreement on these design principles?
I think a wiki is in order since its time to flush out functions and structure. I'm going to create a wiki page in the ldap integration group on gdo. I just found the group and joined it. (http://groups.drupal.org/ldap-integration-development-and-modules)
Comment #11
johnbarclay commentedNot my favorite wiki ui, but I think its good that its on the drupal site. http://groups.drupal.org/node/68688
Comment #12
ebeyrent commentedI agree with all your points. I would definitely like to spend more time flushing out the functions and structure before doing too much coding.
Comment #13
johnbarclay commentedThere is a middle ground between authorization and authentication. There are often feature requests in ldapauth for the ability to filter which ous can authenticate, or some other filter disallowing authentication by valid ldap user, who just don't have the correct characteristics.
Thus an ldap authn and an ldap authz module could use some of the same functions, but would end up with different mapping/filtering interfaces.
This will sort itself out when we have the ldap authn and an ldap authz modules.
Comment #14
myxelf commentedSubscribing...
Comment #15
johnbarclay commentedthis module moved to the project/ldap namespace. closing issue.