2

I'd like to ask which authorization flow is considered better or standard.

First approach (has role AND assertion is valid):

if (!isGranted(roles, permission) {
    return false;
}

if (hasAssertion(permission)) {
    return assert(getAssertion(permission), context);
}

return true;

Second approach (has role OR assertion is valid)

if (isGranted(roles, permission) {
    return true;
}

if (hasAssertion(permission)) {
    return assert(getAssertion(permission), context);
}

return false;

Edit: I'm designing the chat application, with users having different permissions in different chat rooms.

stil
  • 121
  • 2
  • What do you consider as "better"? – TildalWave Feb 17 '14 at 18:58
  • Better - more elastic and easy to maintain – stil Feb 17 '14 at 19:01
  • There is no right answer here - it really depends on the specific set of permissions you are modeling here. Does belonging to a specific role allow the user to bypass the granular contextual authorization checks, or not? Which makes sense? Which fits the security policy? – AviD Feb 17 '14 at 19:31
  • As for which is "standard", or rather "common", sadly I would say - neither. Usually these models are not combined, it is most often one or the other... – AviD Feb 17 '14 at 19:32
  • Your code examples do not show RBAC, but rather hard-coded acl. – Jacco May 25 '16 at 10:29

2 Answers2

1

You're suffering from the lack of richness in RBAC. What you really want to consider is attribute-based access control. For instance in this case, you could define rules such as:

  • a user can post in a room he/she is assigned to
  • a user with the role moderator can edit messages in a room he/she is a moderator in
  • a user can edit their own messages...

All these are examples of attribute-based policies / rules.

NIST has had an ongoing project on attribute-based access control. You can read more on this model here.

You can also check this YouTube video for the basics of attribute-based access control.

To implement ABAC, have a look at XACML, the eXtensible Access Control Markup Language defined by OASIS.

David Brossard
  • 1,360
  • 7
  • 16
0

Whenever I use a control access model I use the "AND" approach. This way you minimize errors when grating permissions so, in this case I would use the first approach.

If your really have the problem of having to grant access some users with different roles then, almost for sure, your Roles scheme need a redesign. Meanwhile working in redesigning your roles, you can use the second approach.

kiBytes
  • 3,450
  • 15
  • 26
  • I'm designing a chat application. RBAC is rather difficult here, because different people in the room should have different permissions (which are not granted on the other rooms though). – stil Feb 17 '14 at 18:49
  • RBAC per room =) – kiBytes Feb 17 '14 at 18:55
  • Well, that's clever.. – stil Feb 17 '14 at 18:58
  • 2
    @kiBytes "RBAC per room" is not "RBAC" - assuming a room is a securable resource. It does sound like you are referring to role-based DAC - e.g. like granting access to a group in an NTFS file share. This would be a good fit, not sure how scalable it is though, and it depends on a few other factors. – AviD Feb 17 '14 at 19:34
  • @AviD you are completely right, that's DAC. – kiBytes Feb 17 '14 at 20:14