Nested roles

[alvarp]

Hi,

Maybe it's a misunderstanding of this, but in theory, loopback can handle a user having a role, mapped to another role, which have an ACL allowing it to do something. This isn't working for me.

There's the role "model_read" mapped to a user through "onerole", but the user cannot make use of the ACLs assigned to "model_read".

Role Collection

{ 
    "_id" : ObjectId("571dd32a8cea6408067e8df3"), 
    "name" : "model_read", 
    "created" : ISODate("2016-04-25T08:19:54.854+0000"), 
    "modified" : ISODate("2016-04-25T08:19:54.854+0000")
}
{ 
    "_id" : ObjectId("571dd3358cea6408067e8df4"), 
    "name" : "onerole", 
    "created" : ISODate("2016-04-25T08:20:05.905+0000"), 
    "modified" : ISODate("2016-04-25T08:20:05.905+0000")
}

RoleMapping Collection

{ 
    "_id" : ObjectId("571dd99a25dea8502e5aaba4"), 
    "principalType" : "ROLE", 
    "principalId" : "571dd3358cea6408067e8df4", 
    "roleId" : ObjectId("571dd32a8cea6408067e8df3")
}
{ 
    "_id" : ObjectId("571ddbe50e0c2a84166d2c79"), 
    "principalType" : "USER", 
    "principalId" : "5718bbc2c134dce41909e74b", 
    "roleId" : ObjectId("571dd3358cea6408067e8df4")
}

And then, in the model ACLs I've this:

  "acls": [
    {
      "accessType": "*",
      "permission": "DENY",
      "principalType": "ROLE",
      "principalId": "$everyone"
    },
    {
      "accessType": "READ",
      "principalType": "ROLE",
      "principalId": "model_read",
      "permission": "ALLOW",
      "property":"findById"
    }
  ]

The user 5718bbc2c134dce41909e74b only can access to the model if I set the principalId of the ALLOW ACL to onerole, if I set to model_read as in the example, it doesn't allow me to findById. I guess that I'm doing something wrong or there is a bug, because the linked docs above explains that a role can map to a role.

[richardpringle]

Hey @alvarp, there any chance you could fork a loopback-sandbox where I could reproduce the issue? I get what you are trying to do but I need a little more detail to find either the correct implementation or to see if this is a bug.

Thanks.

[alvarp]

@richardpringle, in the next days I'll try to reproduce the issue.

[richardpringle]

@alvarp awesome, I appreciate the help. Please mention me in a comment when you have the fork up!

[alvarp]

@richardpringle, I've created the repository and the relations reproducing my issue.

• There are the default models, a user model extending User and a RandomModel model.
• There are the roles admin and randomModelFind.
• $everyone are denied to do everything at RandomModel model,
• except principalId randomModelFind, which is ALLOWed to find in RandomModel.
• The only user at the repo has the role admin.
• The role admin has the role randomModelFind.
• When executing the repo, at the boot there is a script called populate.js that will populate the default datasource (mongodb) with the Roles, user (pass 123456), RoleMappings and RandomModels.

I think that's everything, this is the fork of the loopback-sandbox repository.

[richardpringle]

Hey @alvarp, not only is the documentation incomplete, but you also found a bug!

The problem is that that the principalType is defaulting to Principal.USER right here, so the role is not fulfilled.

What you can do instead is create a custom resolver like in the access-control example. You need your child role to be resolved beforehand.

You should also make sure that each Role instance is being populated with the correct principals (Role-mapping instances). You can do this with the following line role.principals.create(roleMappingData[i]) where role is an instance of the Role model and i is the index of the correct principal.

You're going to have to play around with this a little to get it to work properly. I suggest that you set the following in the model-config.json:

  "Role": {
    "dataSource": "db",
    "public": true
  }

You can then query GET /api/roles with the filter {"include": "principals"} to see if your Role data is being populated properly. Change public back to false once you have figured everything out.

In the meantime we will try to get this fixed.

Good luck and keep posting in here if you need any more help.

[realprabs]

Any update on this?