If many discussions are public then you could use a boolean property to mark a discussion as public
In our application we have extended Shiro’s wildcard matcher to include constraints on permissions based on object properties e.g. you could add this permission to your role permissions: discussion: > > create,retrieve,update,delete:property_public=true and write a simple conversion function to parse the permission string and produce it from your permission object representation, and to override the ‘implies’ method. This avoids the need to add an individual permission to a user’s permissions for every public discussion. Richard > > On 13 Jun 2017, at 10:21, Abhishek P <[email protected]> wrote: > > I can think of two ways to accomplish this in an RBAC system: > 1. Your style: Associating unique role with user and adding permissions > 2. Associating unique role to each conversation , which would then be > added to each use in question. > > > > > > On Sat, Jun 10, 2017 at 2:09 AM, dfee <[email protected] > <mailto:[email protected]>> wrote: > I'm thinking through a Shiro implementation for a web application, but I'm > running into a wall when it comes to translating an Allow / Deny ACEs system > into an RBAC permission model (allow only). > > Supposed we have two database models <Discussion>, <Message (N:1 of > Discussion)>. Discussions may be private, and if so, only members of the > discussion should be aware the discussion exists when searching, view the > discussion, and post messages to it. Messages, then, should be visible to > members of the discussion (or if the discussion is public, then available to > all users). > > This seemingly requires the following permissions: > `discussion:create,retrieve,update,delete:{discussion_id}` > `message:c,r,u,d:message_id` > > Due to allowing private conversations, it seems a wildcard strategy wouldn't > work (i.e. `discussion:retrieve:*` granted to a role: `public`). But as the > system scales from 1 public conversation to N public conversations, each > user gains 2N permissions (`discussion:create,retrieve:{discussion_id}`). > > This leads me to believe I don't properly understand modeling as the cost of > retrieving permissions for a user will climb very quickly / scale poorly. > > It also seems that each private conversation needs it's own role, to which > permissions of that channel can be prescribed. > > Is there a more sane way to model this? Or is this the constraint of using a > Shiro-type RBAC system? > > Thanks, > Devin > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/RBAC-architecture-for-web-app-tp7581644.html > > <http://shiro-user.582556.n2.nabble.com/RBAC-architecture-for-web-app-tp7581644.html> > Sent from the Shiro User mailing list archive at Nabble.com. >
