Take a look the doc for wildcard permissions: http://shiro.apache.org/permissions.html
There are a few different ways you could model this, I have a bias opinion for using roles that contain permissions. So in your case, you have three roles: Individual, Supervisor, and Admin. You would grant these roles to users as needed. They when new 'projects' are added to the system, you would just add new permissions to the role, the permission string could look like: 'project:<project-id-here>:read', 'project:<project-id-here>:write', etc Your table of checkboxes would represent which which permissions are added to each role. This also means you could grant your admin users 'project:*:*' to have full control of all projects, or maybe 'project:*:read' to your supervisors. On Fri, Aug 19, 2016 at 11:44 AM, chambrenoire <[email protected]> wrote: > Hello, > > I'm working on a roles/permission system for my web app and I'm unsure quite > how to structure this using Shiro (my first time). > > Briefly. Users can access a number of Projects. This is a Participation and, > amongst other things, a Participation has a Profile with a number of Rights. > So these are Rights specific to a User within a Project. A Participation > also has a Type (Admin, Support, etc.). > > A Profile is based on a Role. Roles (perhaps poorly named) are effectively > standard Profiles with default rights configurations defined in advance by > admins. When creating a new profile one selects a Role to act as a base and > then, if needed, one adjusts the rights. Profiles aren't exclusive to one > user. > > So far, so good (or not! you tell me!) > > Rights are grouped by context/subject. So for instance all rights to do with > 'Project Tasks' are grouped together. I haven't modelled this because it's > handled by the UI (not sure whether that's a bad thing). > > Now my issue is as follows. Depending on the Participation Type, certain > Rights are implicit and should not be disabled. So when creating a Role for > a 'Support' Participation, the 'See my own support tickets' Right should be > implied and either not shown, or shown disabled so that it cannot be > changed. Whereas a different Participation Type can optionally assign this > Right or not. > > I've basically got a spreadsheet with Participant Type / Right = Can't > apply, Can apply (Selected or not) & Always applies. eg : > > | RIGHT / TYPE | INV | SUP | ADM | > | G_PROJECTS_READ | I | I | Y | > | G_PROJECTS_UPDATE | Y | N | Y | > | G_PROJECTS_CREATE | N | N | Y | > | G_PROJECTS_PUBLISH | N | N | Y | > > (forgive my crappy table!) > > Where Y = Type can toggle right on/off, N = Type doesn't have right > & I = Implied i.e. Type has right and it can't be deselected > > Any ideas/pointers as to how this can be modelled using Shiro? > > Many thanks, > > CN > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Structuring-roles-and-permissions-tp7581233.html > Sent from the Shiro User mailing list archive at Nabble.com.
