Graham Laidler - 391 - Oct 21, 2014

Some advice needed (rather than purely tech).  I need to implement Role-based permissions, where Permissions are attached to Roles rather than to individual Users, which is the case out-of-the-box.

I know that there is a HasPermission method in IAuthSession, which I can override, but really want a steer on the best approach of where to store the roles/permissions mappings - there are a number of options (list below may not be exhaustive) - any advice appreciated.

1.  Store the Roles/Permissions mapping in database (and Cache), and populate the User’s Permission list as they log  in.
2. As above, but query cache each time a service method is executed.

also, any experience of the best way of storing permissions - db/cache with list of strings or an enum?

Any help appreciated!

Hi Graham, I’ve added a section on customizing Roles/Permissions on the wiki:

It outlines the different approaches in ServiceStack:
1) The default behavior where Roles/Permissions are stored/validated on UserAuth
2) The AspNetWindowsAuthProvider uses this to add additional Roles/Permissions on the Session on authentication.
3) Describing how the existing behavior can be overridden by IAuthRepository which implement IManageRoles APIs. OrmLiteAuthRepository uses this API to provide its UseDistinctRoleTables=true feature where Roles/Permissions are instead stored in a separate UserAuthRole table which stores both Roles/Permissions that gets looked up each time (i.e. doesn’t get cached with IAuthSession):

Sir Thomas:

Our current approach is to have a table that lists all available permission strings so that in our web-app, an admin can easily assign permissions to various user accounts.  Adding new permissions is easily done with 0 code changes by adding entries to that table (and obviously any code that requires that new permission).

Also use the distinct tables feature, so that any addition or removal of a permissions is done and “visible” in that extra table, instead of a joined string in the user.

Permissions are “hand loaded” (session.Permissions.Add(…)) OnAuthenticated via a custom auth provider.

Roles we haven’t tacked yet, but we will do so by having a table to map Roles with Permissions, then use our existing permission loader to include those in that user’s role.  This way, again via our web-app, an admin can create roles and decide what that role can or cannot do.

Graham Laidler:

Thanks - I opted to have permissions as an enum stored against roles as blobbed list of strings.   Permissions are populated into AuthSession on login.