Woo Hoo always glad to see positive responses!
First things first, in response to Dean:
As is the implementation doesn't directly impede on anyone trying to deploy without using Ldap, it merely becomes a check box and a few textboxes on the admin/SiteSettings page, that being said having some nice generic interfaces to handle any future authentication methods would indeed be preferable. For now though I'm going to get it into a much more workable state and see what Joe has to say.
And now for the boss:
Disclaimer, all your points you brought up are exactly why I decided to post my progress and questions so we could discuss how you wanted it to turn out.
Firstly I should have been more clear,
Novell.Directory.Ldap is a .net provider to communicate with any Ldap server (even AD for that matter) I chose this method over System.Directory because System.Directory from what I could tell is aimed directly at AD and isn't fully implemented under Mono (as of now). My current setup is running on OpenLdap where my accounts inherit from inetOrgPerson, posixAccount, sambaSamAccount which I think is pretty standard for many folks running ldap for pam+samba integration as these are all schemas that are usually distributed by default with their distributions. That's just so you have more clarity as to where I'm coming from, and what I mean for specific to my site.
The Ldap authentication was shoehorned directly beside the DB Authentication, that is to say in secure/SiteLogin the only change is the passing of entire SiteSettings instead of just SiteSettings.SiteID, then SiteUser.Login looks to see if UseLdapAuth is true and if so call LdapManagement.Login(LdapSettings, email, pass) and returns the cn for displaying the userName. I didn't change anything else so I presume if DB authentication is using Forms auth then Ldap is as well.
The implementation currently does populate the member list and the user profile (the attributes I can) directly from Ldap, and for at least my uses I can't see any performance hit. That being said I had also been toying with the exact same idea of checking to see if user exists in db and if not creating them and then using that to store pertinent mojoportal information. This is especially helpful when you are considering how to manage the number of forum posts, and all the other fun pieces that tie each of the modules on a site together. Moving to a pure Ldap model would certainly cause issues as depending on what attribute you pick to identify your users it could change thus breaking ownership of modules, which in general would be a BadThing(tm). But the upside to using a pure Ldap implementation is that the possibility of duplicated attributes/profile info (and thus the number of extra pieces you have to maintain across your systems) are reduced to one more central location. Another thing to consider is user deletion, for instance do you delete a user who exists in the db but whose entry doesn't exist in Ldap or do you delete when the user exists in the db but can no longer be authenticated via Ldap, or just run a maint script that checks per site per ldap server and keeps the lists in sync.
With regards to roles, I'm all for managing roles via the DB as it reduces the complexity of Ldap implementation significantly, the only reason I was considering manging them via Ldap is that it may be possible that some organizations already have seperated their users out enough via groups that they may want to map those groups to mojoPortal roles to ease the burden of manging users. This is why I was thinking of some way to map Ldap groups directly to your default mojoPortal roles.
I suppose the best plan of attack for Ldap authentication and management would be to implement the split personality version that allows sites to authenticate via ldap but manage roles and user information via the database, and then later provide modules that could pass more control to ldap for either user info, roles or both. In any event I'm sure that with enough peer review I can create an implementation that satisfies everyones needs.