Hi,
On Fri, Apr 3, 2015 at 2:51 AM, David Blevins <dblevins_at_tomitribe.com> wrote:
> On Apr 2, 2015, at 1:54 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>> 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.
>
> I've explained that same concept to numerous people and seems there's no end in site
I hear you. I've certainly been in the same situation. Explaining over
and over again what I did above, and people just not believing it.
Just as some of the other terms that we have discussed, "group",
"role" and "permission" are not universally agreed upon though. There
is a surprisingly amount of literature available on the topic. Just
one of many:
http://profsandhu.com/workshop/role-group.pdf
Operating Systems use the term as well, and don't use it in any strict
way either. On my machine (using the groups command) I'm in the
"arjan", "adm", and "cdrom" groups. Talking about consistency.
> I've become disenchanted with "role" and wonder if we wouldn't be better served with a name that doesn't require people to be enlightened to think "outside" its implied use.
Perhaps indeed.
But technically, Java EE already has the group -> role -> permission
hierarchy. It's just that the permission isn't explicitly named, but
directly assigned.
E.g. taking the example from
http://arjan-tijms.omnifaces.org/2015/04/how-java-ee-translates-webxml.html
You could imagine that there's a group "seniors", that has as one if
its roles "administrator", which has as one of its permissions
"WebResourcePermission /protected/*".
So maybe it's just a question of introducing "named permissions"? Or
is it a question of renaming "role" to "permission"?
In the first case we'd have:
group -> role -> permission (name)
So just like with CDI beans, you can have the CDI bean type itself,
and optionally introduce a (flat) name for that. I'm omitting the
"role ref" that Servlets use here. but including that it would
actually be:
group -> role -> role ref -> permission (name)
In the second case we'd have:
group -> permission -> permission
In that case we'd rename things like @RolesAllowed to
@PermissionAllowed, which is made somewhat easier by the fact that we
need a new CDI based annotation anyway.
HttpServletRequest.isUserInRole will have to be renamed to
HttpServletRequest.isUserInPermission (or something that sounds less
weird), but this too is made easier since we wanted an overarching
security context anyway and can use the new name there straight away.
In web.xml we'd have to rename some tags. <security-role> would become
<security-permission> and <role-name> would become <permission-name>.
With role ref included, it would be:
group -> permission -> permission ref -> permission
We would have to deal with the massive amount of existing code though,
and keep explaining for years to come that "role" is now called
"permission". Just as with J2EE I think there will be a group (no pun
;)) of people who'll be calling it "role" indefinitely.
Finally, we might have to explain somehow what the difference is
between "permission", "permission ref" and "permission".
Another term to consider here would be "right", which is one that pops
up quite often as well.
Well, just thinking out loud here.
Thoughts?
Kind regards,
Arjan Tijms
>
> It's easy to see where people get the idea to effectively hard-code groups into their code. Here's what wikipedia says in their RBAC page:
>
> - "Role = Job function or title which defines an authority level"
> http://en.wikipedia.org/wiki/Role-based_access_control
>
> For the record I'm also quite sick of explaining away the assumptions people inject into "Stateless" EJBs. :) "Actually, they're pooled beans...."
>
>
> -David
>