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.

5
  • What do you consider as "better"?
    – TildalWave
    Feb 17, 2014 at 18:58
  • Better - more elastic and easy to maintain
    – stil
    Feb 17, 2014 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, 2014 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, 2014 at 19:32
  • Your code examples do not show RBAC, but rather hard-coded acl.
    – Jacco
    May 25, 2016 at 10:29

2 Answers 2

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.

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.

5
  • 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, 2014 at 18:49
  • RBAC per room =)
    – kiBytes
    Feb 17, 2014 at 18:55
  • Well, that's clever..
    – stil
    Feb 17, 2014 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, 2014 at 19:34
  • @AviD you are completely right, that's DAC.
    – kiBytes
    Feb 17, 2014 at 20:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .