Add default privilege settings for users added via LDAP

[gitblit]

Originally reported on Google Code with ID 196

We're happily using the built-in LDAP support for user authentication (thanks!). However,
when a "new" GitBlit user (i.e. a user visiting the GitBlit instance for the first
time) is created then it doesn't have the privilege to create new repositories. This
privilege must be manually enabled by an administrator.

I suggest adding a default privilege setting which is used when new users are created
automatially. For example,

realm.ldap.defaultUserOptions = create fork

would automatically allow new users to create and fork repositories. Similar for "admin".

Reported by torf@torfbold.com on 2013-02-01 13:35:14

[gitblit]

Sensible idea.

Reported by James.Moger on 2013-02-01 13:56:59

• Status changed: Accepted
• Labels added: Milestone-1.3.0

[gitblit]

Reported by James.Moger on 2013-07-03 14:26:44

• Status changed: New
• Labels removed: Milestone-1.3.0

[gitblit]

Couldn't this also be solved by creating a team with the wanted permissions and either
assign LDAP users to this team in LDAP or define a default team for new users instead
of default options. This way you could also define repository access for this team
and new users would immediately be able to access these repositories.

Reported by f.zschocke on 2013-10-17 18:46:47

[gitblit]

Guys, I just love Gitblit and its LDAP support OOB. Seriously, it saves me so much time,
so thanks and kudos for that. But regarding to authentication, you gotta keep it clean.
So I boldly disagree with this idea. This is like overriding your LDAP setup to some
degree.

Imagine this scenario: you set this defaultUserOptions to "create fork". Some new users
log in and get ("inherit") these rights. Later on you decide you don't want to allow
new users to fork anymore, so you change this to just "create". Okay, fine, new users
who log in will get just this, but what's with existing users? It will be completely
impossible to track user rights as time goes on and it will all come down to just when
they signed in for the first time (like they got lucky or not). This isn't exactly
a good measure for user rights. And you can't even say, fine, let's remove fork from
all users when you remove it from defaultUserOptions, because they could have gotten
that right either from

a) defaultUserOptions
b) by manually ticking the checkbox for them

Summa summarum: don't mess with multiple authentication mechanisms, focus on just one.
So instead of defaultUserOptions and somehow generating a resultant set of rights from
multiple locations, I propose a much cleaner, much more easier to track as a Gitblit
and LDAP admin, and possibly much easier to implement way of solving this:

Provide options to set all user rights based on LDAP membership. Just like it's already
possible to set the admin right via realm.ldap.admins, it should be pretty straightforward
to add the same mechanism for create, fork, and anything else (if any).

Opinions?

Reported by sundayfunday1234@outlook.com on 2013-11-10 14:39:23

[gitblit]

One more thing to add: with my proposed solution, it would be probably a good idea to
make the user right checkboxes read-only and greyed-out when the user comes from LDAP
(just like the other fields currently, like username and pw).

Otherwise it can become misleading very quickly: you check the admin box for a user,
then the user logs in later again, he gets his rights overridden from LDAP as they
get recached in the local users.conf, and then you can scratch your head why isn't
he or she getting admin rights.

Reported by sundayfunday1234@outlook.com on 2013-11-10 14:47:40

[gitblit]

What about that scenario described in comment #5 by sundayfu?
We have exactly that. When I enable a LDAP user to the admin role, it gets overwritten
as soon as he logs in again.
How can I assign the admin role to an LDAP user otherwise?

Reported by jalbersdorfer on 2013-11-12 12:18:00

[gitblit]

jalbersd, add him/her to the LDAP group you set in realm.ldap.admins?

Reported by sundayfunday1234@outlook.com on 2013-11-12 12:28:19

[gitblit]

yes, thanks - seen by myself after some reading the .properties file.

Reported by jalbersdorfer on 2013-11-12 12:37:14

[gitblit]

I think this issue can be closed. Since 1.2.0 there is "Teams can now specify the *admin*,
*create*, and *fork* roles to simplify user administration", which solves the original
issue.

I agree that #5, disabling per-user permissions might enforce a cleaner way of setting
permissions using teams.

Reported by steffen@steffen-gebert.de on 2014-09-05 07:19:50

[gitblit]

Hmm, I didn't realize that option.

But it doesn't work correctly. If I create an LDAP group and assing it the create right,
then add a user to this group, it will be able to create repos (after singing out,
then in) but if an admin tries to edit his/her permissions, the create checkbox will
not be checked. IMHO not only should it be checked, but even disabled like username
and all the other info that are fetched from LDAP.

Reported by sundayfunday1234@outlook.com on 2014-09-05 08:53:25