Hi,
On Thu, Apr 9, 2015 at 3:39 PM, Darran Lofthouse
<darran.lofthouse_at_redhat.com> wrote:
> 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...
Maybe this can be incorporated into the existing role to permission
mapping by just having optional names for permissions?
E.g. right now we may have a role "Customer" that (via a constraint in
web.xml) maps to the permission "WebResourcePermission
"/protected/*"".
If we could only refer to this permission via a name as well, e.g.
"ACCESS_PROTECTED" then we might be half way there. If we then
additionally introduce a new permission type, say "NamedPermission"
for which only the name has a real meaning, haven't we solved the
problem then?
Kind regards,
Arjan
>
>
>> 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
>>
>