On 02/04/15 21:54, arjan tijms wrote:
> Hi,
>
> On Thu, Apr 2, 2015 at 8:52 PM, David Blevins <dblevins_at_tomitribe.com
> <mailto:dblevins_at_tomitribe.com>> wrote:
>
> > And I would certainly like to tell you how I think about that:)
> >
> > Well, the default examples that are presented in the specs and
> tutorials are most of the time roles like „monitor“, „administrator“
> and „operator“ or sth like that.
> > I find that it does not really match the reality that I work with
> everyday.
>
>
> First of all, thanks for the feedback.
>
> I have to say that though I typically use roles like "administrator" in
> my articles (because it's such an established practice), as an
> application developer I don't often use roles that way.
>
> At zeef.com <http://zeef.com> for example we're using fine grained roles
> that control if the user is allowed to do a specific operation. Made up
> examples that could however be real role names in our software are:
> VIEW_OWN_ACCOUNT, CLOSE_OWN_ACCOUNT, VIEW_BALANCE, EDIT_BALANCE,
> VIEW_NEW_USERS, etc.
>
> Jan (Cc'ed) had similar feedback. Basically saying "roles are not
> useful" and "permissions are king".
>
>
> It depends on which semantic you attach to it.
>
> If you think "roles" are only allowed to be high level things like
> "administrator", then I agree they are not useful. If you think that if
> you want something like "VIEW_OWN_ACCOUNT" you can only call that
> "permission", then I agree again that permissions are king.
>
> However, Java EE does not mandate that a role is only allowed to be
> something like "administrator". At the end of the day, it's just a
> collection of attributes attached to a user that you test for. The names
> of those attributes as well as the semantic value your application
> assigns to them is yours to decide.
>
> There is often a wish though to group the finer grained roles into a
> more coarse grained thing. At zeef.com <http://zeef.com> we use the term
> "group" for this (as Java EE uses too, just not in a standardized way).
> A group in our system is something like "administrator", "manager",
> "customer", etc. Every such group maps to multiple roles. And multiple
> groups can map to the same role.
In an example like this it make me think there may be room for groups,
roles, and permissions.
i.e. in the identity store of accounts an account could be in the group
'systemX_customers', in the case of this specific application that maps
to the role 'Customer' which in tern say has permissions
'VIEW_OWN_ACCOUNT' etc...
> E.g.
>
> group "customer" can map to roles: VIEW_OWN_ACCOUNT, CLOSE_OWN_ACCOUNT,
> VIEW_BALANCE
> group "manager" can map to roles: VIEW_BALANCE, EDIT_BALANCE, VIEW_NEW_USERS
>
> I found that there's somewhat of the misconception that a "group" like
> "administrator" needs to have a 1:1 mapping to a name that's application
> specific, but has the exact same meaning. E.g. people think that
> "administrator" is only allowed to be mapped to "admin". But this is not
> the case in any of the proprietary group-to-role mapping systems in any
> server that I've used. It's always a many:many mapping and the semantics
> are again yours to decide.
>
> Kind regards,
> Arjan Tijms
>