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.

  • 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

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.


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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.