Opened 9 years ago

Last modified 7 years ago

#5352 new defect

Automatically create local users on successful LDAP authentication

Reported by: Olivier Mehani Owned by:
Priority: minor Milestone:
Component: programming Keywords: auth_ldap, allow_registration, email
Cc: Parent Tickets:

Description

With the auth_ldap plugin, users can be authenticated against an LDAP directory. However, upon first logging in, the MG database does not contain information about them, and asks for their email address. Moreover, if registration is disabled, users will not be able to move any further after entering their email address, and will be presented with a message that registration is not enabled.

Two things need to be fixed:

  1. Try to get the email address from LDAP after successful authentication, and only ask the user for it if not available
  2. Don't honour the allow_registration setting when creating local users in the DB when they have been successfully authenticated from LDAP.

Change History (6)

comment:1 by Olivier Mehani, 9 years ago

Also, don't send the verification email, as this is not really an account creation.

comment:2 by Meaulnes, 7 years ago

In my opinion, the first request in the ticket seems reasonable. In fact, I was thinking about working on a patch that would only only prompt for the email address in an LDAP situation when one was not found in LDAP.

I'm somewhat confused by the rest of it though. If registration is disabled, what is the point of having anyone log in? If people aren't allowed to register, then how will they ever get an account to log in?

Lastly, I don't think that email verification should be disabled; since confirming the email address is going to be important to guarantee that GMG has a deliverable email address for a given user.

comment:3 by Olivier Mehani, 7 years ago

For point 2: I want users present in LDAP (or perhaps just one LDAP group) to be auto-registered on first login, regardless of the setting. Otherwise, for a closed instance with allow_registration = false, users will never be able to log in, as their MG account will not exist, regardless of whether they have an LDAP account or not.

The email address should be present in LDAP already. Perhaps we can ask the user to confirm it (or enter it only if missing from LDAP), but surely not to re-enter it.

Essentially, I want users to not be aware that they are registering a new account at all, as long as LDAP has all the necessary information already.

comment:4 by Meaulnes, 7 years ago

I get it, but I'm failing to see why you would set "allow_registration = false".

I have a closed configuration, with 'allow_registration = true'. Only LDAP auth is enabled (all other auth is disabled), and I have submitted a patch that will check for LDAP group membership before allowing the user to log in. In my config, only users in my LDAP group are allowed to log in, and their account is automatically created on first log in. It does exactly what I think you are looking to do.

In fact, with my patches, I think that all of the functionality that you describe works. The user is asked to confirm their email address (not enter it, unless it is missing from LDAP, and only allowed users can register). You would just have to set 'allow_registration' to be 'true'.

From a design perspective, I think that changing the behavior of a config flag in a certain case is probably bad form. I'm not a dev on the project, so I don't profess to speak for them (to be clear).

comment:5 by Olivier Mehani, 7 years ago

It sounds like your patches would work for me yeah.

That said, the underlying reason why I think ignoring allow_registration = false is for the case where you have more than one authmethod enabled (if that's even possible), where you have an LDAP directory of known users, as well as a local base of local users independent from LDAP. You may want users from LDAP to have local users created seamlessly when first login (I'm happy with the email verification), but not let non-LDAP non-local users create new accounts on the fly.

Spelled out like that, I agree it's a bit contrived.

Last edited 7 years ago by Olivier Mehani (previous) (diff)

comment:6 by Meaulnes, 7 years ago

Writing it out like that does clarify the use case a little bit. From as far as I am able to see, the LDAP auth doesn't work with other auth plugin. I know that in order for me to get LDAP auth working, I had to disable basic auth (the default).

So it could be that you've described an impossible case.

Note: See TracTickets for help on using tickets.