Disable registration/users

[DirkHeinke]

It would be nice to have an option to disable the registration for users and/or to set new users to default inactive. This will give the admin control about who uses the registry.

[mssola]

This might make sense for large organizations, but for small organizations this can be a bit of a burden. So I feel like it would be a good idea if it's well implemented.

I'd make it a configurable option in the config.yml file: verify_users or something like that, and it would be false by default. Big organizations could set it to true on the installation process. As of disabling registration or default inactive, I'd go for a simpler approach. Let's imagine that verify_users is set to true, then:

1. On the "Sign up" page, instead of registering the user, it would redirect him to a page telling the user "Your petition is being processed by the administrators", or something like that.
2. The admins would receive an email, notifying them about the petition. In this email there would be a link to the "Pending users".
3. On the "Pending users" page, there would be a list of users that have filled the "Sign up" form and that the admins haven't accepted/rejected yet.
4. On accept: the user gets an email and gets registered.
5. (Maybe) On rejected: the user is added to a list of people that have tried to register, so this user doesn't try it again.

This feature wouldn't make it on the first release most probably, but a bit of discussion won't hurt :) So, @flavio, what do you think about this?

[flavio]

I agree with you. Let's see what @eotchi thinks about it.

[djdefi]

As a suggestion, this could be essentially achieved with LDAP support #150 -

If LDAP is configured, essentially make the Portus user store read-only. Permissions and access is then based off of LDAP group membership. The jabber chat server project openfire handles LDAP and registration toggle in this way.

The large organizations out there that would want to disable registration, are most likely going to have LDAP in place. Then you don't need to really re-engineer the sign up process or have a approvals queue.

[mssola]

In my first comment I said that this configurable option would only be available through the config.yml file. This is too strict, maybe. I'd say to make the config.yml option available but that the admins could have an interface to change this anyways. This would mean that admins that are really sure about this feature can set it up when installing Portus, but they could still change it afterwards without restarting the application.

[mssola]

@rtrauntvein fair point. This is why I want to think more thoroughly on LDAP support before implementing this feature. Thanks!

[kenni-shin]

fast solution can be delete line
.text-center = link_to 'or, Create a new account', new_user_registration_url
in file /srv/Portus/app/views/devise/sessions/new.html.slim

[mssola]

This is a feature that I'd like to see for the next stable release. I've come up with the following proposal: There should be the following configurable option for this (the set values would be the defaults):

signup:
  enabled: true
  verify: false

1. If signup is disabled, then it means that the only way to create users would be from a rake task. Otherwise, the creation of users won't be allowed.
2. If signup is enabled but verify is false (the default values), then everything will behave as nowadays: anyone can signup.
3. If signup is enabled and verify is set to true, then anyone that wans to register would enter in a verification process, similar to the one described in this comment.
4. This whole thing would be ignored if LDAP support is enabled. The rationale is that with LDAP people are already controlling who can and who cannot access Portus anyways.

This should be implemented in two steps. First we implement points 1 and 2, which already provide the functionality itself. Lastly we would implement the third point, which can be seen as just a UX workflow on top of the first two points. I'd like to implement the first two points before the 2nd stable release of Portus. The third point can wait, in my opinion.

/ping people that have commented on the other issue (#283): @deitch, @vitorarins.

[vitorarins]

Hi @mssola, I agree with your points, but I am not a fan of the idea of running a rake task to create users on your first point. A good solution to that would be to have a page to create users inside the Admin area, similar to Gitlab.
Of course that would take more time to implement, but with that point 3 can be delayed for longer and marked as enhancement.

[flavio]

@mssola sounds like a good plan

[mssola]

@vitorarins I like your idea. I'll do that instead.

[deitch]

Actually, I like them both. Having a "user management" area of the UI makes sense, but the ability to do so via automation also is powerful. Of course, a Web-based REST API interface is better than a rake task, but whatever is easiest to start.

[mssola]

@deitch fair enough. I'll do both then. Moreover, I'll also add an option to portusctl for it :)

[JonathonReinhart]

FWIW: Here's how GitLab handles it. They have two options: signup_enabled which en/disables user self-signup, and signin_enabled which controls whether users can sign-in (without LDAP). Enabling LDAP adds another tab on the sign-in page. So this allows you to have some LDAP and some non-LDAP users.

That said, I don't know why you would ever have that scenario, but it's something to consider.

[mssola]

@JonathonReinhart the possibility to mix LDAP users with non-LDAP users was discussed when implementing LDAP support in the very beginning, but it was finally discarded (rightfully I'd say). Therefore:

FWIW: Here's how GitLab handles it. They have two options: signup_enabled which en/disables user self-signup, and signin_enabled which controls whether users can sign-in (without LDAP)

The signup_enabled option you're talking about will be handled with the signup configuration option. The control on signing in without LDAP can be handled by disabling users, which is a feature available for admin users.

[JonathonReinhart]

That sounds good. I actually can't imagine anyone in an enterprise environment would allow non-LDAP sign-in, and especially not self sign-up.

[mssola]

Thanks to @salzig, the implementation of this feature has started. I'll draw a checklist to track better what's being done:

• Provide a rake task to create users. (See PR lib/tasks: added a task to create users #569)
• Provide a user interface in the admin page to create users. (See PR feat: simple user creation form #543)
• Provide a configuration option to enable/disable the signup form. (See PR Added the signup configurable value #568)
• Implement a verification process for users that want to sign up. (See PR config: updated the "signup" config #591)
• Add documentation on the gh-pages branch. (See PR docs: documented the signup configurable option #594)

[mssola]

I've become quite skeptical about the fourth point. The thing is, that if you want to do such a thing, in non-LDAP setups users will just mail the admin and the admin will then create the user. Therefore, I think that the fourth point tries to re-invent the wheel.

@flavio What do you think ?

[flavio]

@mssola I agree with you, let's ignore that. We can alwas resume that later on if we have a valid use case.

[mssola]

This is now implemented and documented. You can read about the feature itself here and how to configure it here.