Well I am biased, because the RBAC plugin was the first plugin I wrote once joining CloudBees.
When I started using Jenkins, one of the issues I had is that the LDAP server is controlled by heavyweight processes, which can even end up being outsourced to a consulting company. For example at my former employers there was a person on site who did not work for us and who was responsible for the corporate IT helpdesk support on-site. If you wanted to get a new group in LDAP... file a change request, get it signed by 4 layers of management, and 6 weeks later your request *might* be approved and a few weeks later still it gets approved. If you wanted to change the people in the LDAP group... lather rinse repeat. My solution at the time was to use the PAM authorization strategy and plug LDAP authentication as the PAM back-end on the Unix side... thus everyone who could access Jenkins had a unix account on the Jenkins box (with no login permissions) their password was their corporate password and their group membership was controlled by using unix groups on the Jenkins server. That let me manage groups quickly without the pain of change requests... but it was a messy solution. So my dream of the ideal authorization strategy is that it would let you define local groups (which could consist of users, other local groups, special identities and external groups - if you have a reactive IT then your local groups may only have one member, i.e. the external group that contains all the users for that local group). The RBAC plugin gives you that feature. Additionally I hated having to manage permissions at the checkbox level, I wanted roles that contained all the check-boxes you would want for that *role*. So the basic model in the RBAC plugin is that you define your roles and then assign roles to local groups (which are associated with group containers - i.e. can define groups in folders, jobs, etc). Because we have roles tied to groups and groups are tied to objects, we also have the ability to filter out role assignments from higher levels... that gives you a subtractive model for permissions... allowing easy configuration of "dark" projects On the other side we have the Roles strategy... this does not give you local groups, so you will have a UI pain if there are lots of users that you want specific permission sets for and they are not exactly mapped by a security realm group... on top of that, as I understand, the permission model is additive only, so dark projects can only be created by ensuring all other projects are light. One of our customers (you know who you are... I'm humming "Devil's Haircut" right now) may be able to explain some more, but I understand there are some, IMHO rare, cases where the Role Strategy's use of regexes to identify projects to apply roles to can lead to easier configuration of role assignments... In general, however, my belief is that the RBAC model, once you get your head around it, is easier to work with... but I would say that since I came up with its model On 19 November 2013 10:04, Martin Ba <0xcdcdc...@gmx.at> wrote: > Hi everyone and esp. CloudBees! > > What are the main benefits the Jenkins Enterprise [Role-based Access > Control Plugin][1] offers over the free [Role Strategy Plugin][2] ??? > > thanks for any insight, > Martin > > > [1] : http://www.cloudbees.com/jenkins-enterprise-by- > cloudbees-features-role-based-access-control-plugin.cb > [2] : https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
