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:
https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization#customizing-user-roles-and-permissions
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):
https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/Auth/UserAuth.cs#L110
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.