I've used Role Strategy for about two years before switching to RBAC in spring this year, on a medium-sized instance (100 or so users from LDAP, 10+ project teams, 15 slaves). We have fairly complex permissions setup for some users, so I feel like I reached the limits of both plugins fairly quickly.
--- Role Strategy has centralized configuration, where you configure roles that assign a set of permissions based on a regex applied to job names. These roles can then separately be applied to users and/or groups from your security realm. Since configuration is centralized, you cannot delegate this to non-admins. And permission assignment is based on job names, so renaming jobs can completely alter who has what kind of permissions -- renaming is possible with job config privilege, so be sure to teach your job configurers not to rename things (and vote for JENKINS-18649). If you copy a job, its name must match the pattern, otherwise you'll lose assigned permissions, etc. It's somewhat easy to have an overview of assigned permissions at first, but once your regular expressions become longer than 100 chars or so, that quickly becomes a PITA. Additionally, the grids are pretty unusable without userscripts like Daniel Petisme's UI enhancer (https://github.com/danielpetisme/jenkins-role-strategy-ui-enhancer) or scripts I wrote that rotate table title row labels to take up less horizontal space (similar to RBAC's role configuration). It's relatively easy to write a Groovy script to generate a report on who has what permissions on which objects through which roles. This plugin excels at quickly adding the same kind of permissions to a lot of items (or changing them, or adding another job to a permission set, ...). What's missing IMO is the ability for roles to have multiple sets of permissions, each with a different regular expression, for those more complex roles that need very different kinds of access to different jobs. Since I haven't used this plugin in a while, I have not used the 'macros' feature at all. --- RBAC has a distributed configuration that works well with the Folders plugin. You define global roles that each have a set of permissions. You assign these roles by defining local groups that can have users and groups (both local and from the security realm) as members. Each such group can have one or more roles, and each of those can be inheriting or non-inheriting (useful when you want to give read access to a folder, but keep jobs in that folder hidden by default). Assignment of permissions is distributed and independent from job configuration, so if you run a multi-group, multi-project Jenkins, you can teach your project managers how to do this themselves. OTOH, getting an overview over who can do what is pretty much impossible without helper scripts. RBAC cannot really be restricted to certain items like Role Strategy's roles can: While you assign roles to groups, you can only decide to inherit or not inherit to descendent items. Additionally, roles are defined globally, which requires you to use pretty basic roles (see examples in manual) or to basically replace the role model with individual permission sets you can mix and match (e.g. 'builder' + 'artifact downloader' + 'job configurer') or a mix of both. Here, delegation breaks down if your project manager wants his own role with a specific set of permissions). And complex roles, that require different kinds of access to different objects, cannot currently be modeled at all. You'll quickly need to decide whether you want 'group overflow', or can deal with some of your users having more access than you'd like. A weakness is the special, unique user that for some insane reason requires very specific permissions on a bunch of different items, but is not allowed to access, build, or configure the rest. While for each set of permissions you could define a role in Role Strategy ('snowflake can build', 'snowflake can configure'), here you'll define at least one group per item you want to assign permissions on. While some of the limitations are disappointing, RBAC still has obvious strengths: Homogeneous permission sets, delegation of configuration, and locally defined groups. For example, to assign permissions on a project to several users, project-based-matrix requires one row in the table per user/external group, each with their own permissions set. RBAC allows you to define a few groups locally, each with one set of roles/permissions (hence no redundancy, provided you can identify logical 'groups' among your users). This doesn't even require your LDAP admins to be unhelpful and/or slow (like Stephen's); some groups simply might make no sense modeled in the external auth realm. On 19.11.2013, at 11: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.
