Database authenticatable compatibility

[clyfe]

I am interested to have database authentication with LDAP fall back (if database auth fails try LDAP).

Currently, from the README, simultaneous usage is not supported.

Anyone else interested in making it work? Is it feasible to try and push this feature? Any major impediments that had made it not supported in the first place? I am willing to contribute work on this, with a little help.

How should this be approached better?

1. Shove code from database_authenticatable in ldap_authenticatable and use only the later strategy.
2. Have database_authenticatable cascade to ldap_authenticatable somehow. I would prefer the latter.

[r00k]

I'd be interested in this too, but don't think I have the time to code it up.

[cschiewek]

I don't have a use for this at the moment, nor do I have the spare time, but by all means fork and get started. I'd look at some of the other devise plugins that already do something similar for guidance.

[r00k]

I worked my way around the lack of support for this today. Kinda.

I created a custom authentication strategy and added it to Warden's list of strategies. Now, it first tries my custom strategy, and if it fails, will then try authenticating through LDAP.

It's not as easy as just adding :database_authenticatable, but it works with no code changes to this gem.

Here's a gist, in case it's helpful: https://gist.github.com/906356

I found reading the following code helpful for getting this written: https://github.com/cschiewek/devise_ldap_authenticatable/blob/master/lib/devise_ldap_authenticatable/strategy.rb

https://github.com/hassox/warden/blob/master/lib/warden/strategies/base.rb

Also, this general guide to how Devise/Warden work: http://ewout.name/2010/04/http-basic-authentication-with-devise/

[clyfe]

I started to update ldap_auth to devise 1.2.1 first.

Other than that, main issues upto now are:

• if database_authenticatable halts or passes on failure, meaning if the other strategies get tried out
• make ldap_authenticatable keep the user identity in LDAP (don't import the password into db because I don't want to update it in case it changes in LDAP, I need this, other people might not), relevent code in LdapAuthenticatable#authenticate_with_ldap

More tomorrow.

[clyfe]

Is anyone familiar with devise's (warden's) strategy try order? It seems that no matter in witch order I put them in the user model the LDAP one always runs first :/ I would like database_authenticatable to be tried first and then ldap_authenticatable.

[r00k]

Check my gist posted earlier. See where I'm using unshift? That sticks the new strategy on the front of the array. That's what determines the order warden tries.

Sent from my iPhone

On Apr 8, 2011, at 9:20 AM, [email protected] wrote:

Is anyone familiar with devise's (warden's) strategy try order? It seems that no matter in witch order I put them in the user model the LDAP one always runs first :/ I would like database_authenticatable to be tried first and then ldap_authenticatable.

Reply to this email directly or view it on GitHub: https://github.com/cschiewek/devise_ldap_authenticatable/issues/24#comment_973631

[clyfe]

Thanks. I mostly got it, should release in a couple of days.

[clyfe]

My branch pretty much works with both DB and LDAP at the same time.

https://github.com/clyfe/devise_ldap_authenticatable

I updated to devise 1.2.1, removed change ldap password feature, added is_ldap field. Check readme.

[jmacdonald]

Any plans to merge this feature? This is a pretty common use case for apps that blend internal and external users.

[stevenyxu]

Thanks for the bump. There has been some recent work that brings this closer to a possibility in the main line. I'll have a look at it.

[jmacdonald]

So, I've had some success using this gem with database_authenticatable. If the user exists in LDAP, I can login using either password (I define a different password in LDAP than I do in the database). However, if the user isn't in LDAP, neither password works.

The initial problem seemed to be that this gem isn't passing/cascading to other authentication methods when it fails, but if that were the case, I wouldn't be able to login using the database password, even if the user did exist in LDAP. There must be a difference in how these cases are handled; having the fallback that happens when the user exists in LDAP but the passwords do not match apply when the user doesn't exist at all would solve this issue.

[jmacdonald]

When trying to authenticate a user that does not exist in LDAP (but that does have a database password), I get a deprecation warning:

DEPRECATION WARNING: an empty resource was given to Devise::Strategies::LdapAuthenticatable#validate. Please ensure the resource is not nil.

At some point, this gem must not be instantiating the authentication resource devise requires if the user isn't found in LDAP. Can this resource be passed even if it's not authenticated, so that the database_authenticatable strategy can take over? This is exactly what happens when the user exists in LDAP but the bind fails (as a result of password mismatch).

[kjeremy]

I'm interested in this as well. I'm trying to use LDAP to authenticate and then fall back to the database if need be.

[peelman]

This is a must-have feature for me too.

Been attempting to merge @clyfe's code with the latest edition of @cschiewek's all morning, but that hasn't went well. Along the way, somehow, it has started auth'ing LDAP users, even when their passwords are blank or invalid. So I guess I'm rolling back for the time being. But damn is this ever important, if for no other reason than to make a project using the ldap_authenticatable gem distributable and not as hard-coded to AD.

[peelman]

Filing this away under weird things...rolling back to 0.8.1, but forgetting to take :database_authenticatable out of my user model, and now everything works...perhaps @cairo140 was right and progress has fixed this serendipitously?

[ryoqun]

I hope this should be fixed by somehow, or maybe I'll create a small pull request...

[ryoqun]

bump!

I'll handle this this week hopefully. I investigated that calling validate inside this strategy is the culprit of preventing fallback.

Are you still around? :) @cairo140

[ryoqun]

@cschiewek ping! If I create a pull request for this, could you review and merge?

(also, I really hope other already-existing pull requests are handled too...)

[cschiewek]

Yes to the first, and "it depends" on the second :+1:

[floriann93]

Hi! How about the state of this feature today? Is this already possible? Is also possible to decide which strategy first? - I would need to try first LDAP (Active Directory) and database as fallback. As @jmacdonald mentioned with internal and external users