owner role
Nina Jansen
This is a very basic question, but I'm new to RBAC so I hope you will
indulge me. I have the following situation: each user in my
application has a profile with some basic information. A user should
be allowed to see other users' profiles and edit his/her own profile.
I could define a role for each profile, like owner_of_profile_1 and
assign user number one to that role, but is this the correct way of
doing it, i.e. create a role for each user, or is there a shortcut?
Sincerely
Nina Jansen
Manuel Holtgrewe
For most applications, your role set keeps the same "all the time".
You should rather think of a role as of a group you would create on
UNIX or Windows systems.
What I would do is:
if "user is admin" or "profile is the profile of the current user"
then allow
else do not allow
end
This means, that the "role" owner is not not mapped to a role in the
database but is rather informally derived in code. You could think of
"contextual roles", i.e. roles that are assigned to a user within a
certain context.
This would allow for an "owner" role. [1] has a shallow outline of
this concept but I have not thought about how to really formalize this.
The way you propose -- if I undrstand you correctly -- would basically
create a role for each entity and then assign permissions to the role.
This would not differ from having an ACL entry for each entity. The
idea of RBAC is to assign permissions to roles and then grant roles to
users.
Depending on your application, you might just settle for users and
roles which gives you a lightweight but easy-to-use framework for
authorization. It would be used as above. "Static permissions" sure
could come in handy if you want to uncouple permissions from roles. I
have implemented applications in both ways.
Settling for users and roles only removes the "complexity" of simple
permissions which make it a bit easier to write applications. Adding
static permissions gives you the flexibility to define permissions
independently (plus they can be migrated!). For example, you could
just add another role without having to touch the code.
It's basically the difference between:
if current_user.has_permission?("perms.article.edit_if_owner")
and article.owner == current_user or
current_user.has_permission?("perms.article.edit") then
end
and
if current_user.has_role?("roles.admin") or
(current_user.has_role?("roles.user", "roles.supervisor")
and article.owner == current_user) then
end
In a nutshell, the first one scales better to a larger number of roles
while the second removes the layer of indirection related to
permissions.
You could also think of contextual permissions which are tied to
objects instead of classes (i.e. to article #3 instead of all
articles). However, I have not had use for this. Although some people
offered to contribute their ARBAC extensions, seemingly none found the
time to wrap it up with tests and documentation and send it to me or
the list.
I know that all this is not outlined very well in ARBAC's
documentation and the last time I looked, literature on this topic is
pretty academic or consultant-speak. [2] could give you a good
introduction or you might just try Wikipedia or Google.
Bests,
Manuel
[1] http://groups.google.com/group/active-rbac/browse_thread/thread/d8d435705c305627
[2] http://csrc.nist.gov/groups/SNS/rbac/faq.html