I try to get all my authentication connected to my central LDAP server. Since Silverstripe doesn't have LDAP support I cobbled something together. It is a loose coupling to the LDAP. First try to authenticate against the LDAP, if that fails, authenticate against the password stored in the SilverStripe database.

With this in place I can set my Silverstripe password to some incredibly complex string that can't be brute forced and at the same time allow me to use my normal password, which I cycle monthly, with SilverStripe (and this password is not stored cleartext either). The account must be created in Silverstripe first before anyone can authenticate succesfully (it's authentication only, not authorization)

The attached patch shows what I have done (it's quite simple really). I have a few questions about what I have done:
1) Is there any interest in including this kind of functionality? If so, maybe I can develop this further.
2) Did I violate any security model already in place? I did some tricking with the error handler, to prevent an error screen when bind failed

The attached patch doesn't want to apply on a clean install. New try. Now authentication also fails if the user is found in the ldap dir and the bind doesn't succeed

Thanks for this Lancer,

There is a very real interest in developing this further - Hayden (@ silverstripe.com) is the man to talk to at our end, as he has the experience with LDAP and the SilverStripe security model.

Is Hayden on holiday or too busy with the impeding 2.1 release? He didn't react to my mail. Anyways I'll post the mail here

---------------

a) is there any other working going on in this area? Not only LDAP specific, but e.g.
making a driver model for authentication (or even authorization). This would allow additional authentication sources like AD, SMB, Shadow etc.

b) What is the best way to continue with it?

c) need any help with it? At the moment I have no professional interest in SilverStripe.
I'm using it on my home server, which has a Fedora Directory server for authentication.
Winter is approaching, so I'll probably have some spare time to do some coding. I have
also written part of the LDAP authentication driver for the Horde (http://www.horde.org)
project (though I was always too modest to add my name to the sourcecode).

Hayden's only working part-time at the moment - he may not have seen your email yet.

It's a pretty interesting idea, your implementation is very clean. We haven't done any work in the past with this, but it would definitely be something to think about. If you wanted to continue working on it, that'd be great - I would suggest looking at using the DataObjectDecorator to abstract it out of the core, if only because it keeps the core lean and also saves a lot of checking whether or not to auth via LDAP.

That way, it can be provided as a module for those who want to use it.

> a) is there any other working going on in this area? Not only LDAP specific, but e.g.
making a driver model for authentication (or even authorization). This would allow additional authentication sources like AD, SMB, Shadow etc.

markus from gsoc has done some work in this area, which i've merged into trunk yesterday:
http://open.silverstripe.com/browser/modules/sapphire/trunk/security/Authenticator.php
careful though, merging is still in process, so trunk will be most likely broken for the next days (as announced in another post). just have a look at the code for now :)

Sorry, been a bit tied up recently.

As Ingo has pointed out, Markus has included an authentication backend for SilverStripe. Have a look at the OpenIDAuthenticatedRole for an example of how the decorator can be used to safely tack on extra functionality and database fields.

We are implementing LDAP authentication shortly, so this is a great time for your patch to come through. We could probably look at collaborating on this using the new security model.

Without actually trying the code, but only reading it:
1) From 2.1 you can register more than one authenticator with Silverstripe and use them concurrently
2) Each authenticator adds its own form to the authentication page.
3) The mapping (in case of OpenID) of the remote ID is done with extra parameters stored with the user object (in this case the OpenID URL)
4) For OpenID you'd still need a database entry but as far as I can see this is not mandatory
5) Authorization still takes place within SilverStripe

I would like (to write) an Authenticator which uses a LDAP server with a posix scheme (also used for normal system logons), including account expiration support etc. If this driver uses the success of a bind as authentication criterion, then authentication against an Active Directory is almost only the changing of some constants. I would even like the move some of the authorization to the LDAP. If SilverStripe groups are mapped to LDAP posix groups, the users don't even need to be recorded in the SilverStripe database (for large sites this would reduce the clutter in the user table significantly)

If I have to start from scratch, I'd start after the release of SilverStripe 2.1, since the mechanisms to add LDAP are already in place and are debugged. If you need anything from me sooner, just point me to the work.

Just a remark; I'm missing some headers in the source files, like license type and version numbers.