Sails.js access with config file, roles and permissions

[Alberto Souza]

Hi,

Someone here has opinions, examples or code something like this on sails.js?

I'm thinking of making a npm module to verify access with actions and profiles ... 

It would be: 

• Configurable with file 
  
• One function for check access: userHasAccess(req,res,ok); 
  he will get the user from req.user
• Suport to user roles 
  
• Default roles "flag" and check to isCreator, IsMember and isContact 
  
• Will be added on one sails.js policy
  

Alberto Souza

[logan...@austintexas.gov]

Hi there,

I am currently working on something similar so very interested in this topic.

However, I am using associations and storing the roles in the database. The next step is to figure out storing permissions in the database, and creating policies that look up the users, roles and permissions and allow/deny access to resources and actions accordingly. If it can all be done with one policy that would be amazing.

The idea would be to allow administrators and power users to configure roles (groups) and permissions at runtime through the application rather than making a programmer (me) do it in the code or a config file, since the organization is constantly changing.

Would love to hear what you and others think.

Thanks,

Logan

[Alberto Souza]

Hi logan,

Could you share what developed? 

I think I can help with part of the policy that in theory is simple ... 

For part of the function to check access you can do something like:  https://github.com/wejs/we/blob/develop/api/policies/PassportPolicy.js#L10 where I'm using to configure the passport.

and then create the admin pages to change the data.

Alberto Souza

[logan...@austintexas.gov]

Alberto,

Still figuring things out, but what I have so far looks a bit like this:

User.js:

module.exports = {

  attributes: {
    name: {
      type: 'string',
      required: true,
      unique: true
    },
    roles: {
      collection: 'role',
      via: 'users'
    },
    permissions: {
      collection: 'permission',
      via: 'users'
    }
};

Role.js:

module.exports = {

  attributes: {
    name: {
      type: 'string',
      required: true,
      unique: true
    },
    users: {
      collection: 'user',
      via: 'roles'
    },
    roles: {
      collection: 'role',
      via: 'roles'
    },
    permissions: {
      collection: 'permission',
      via: 'roles'
    }
  }
};

Permission.js:

module.exports = {

  attributes: {
    name: {
      type: 'string',
      required: true,
      unique: true
    },
    subject: {
      type: 'string'
    },
    action: {
      type: 'string'
    }
    users: {
      collection: 'user',
      via: 'permissions'
    },
    roles: {
      collection: 'role',
      via: 'permissions'
    }
  }
};

This is just the basic schema minus the authentication stuff. Most of the actual logic I have yet to work out, but I have an `isAuthenticated` and a stubbed `isAuthorized` policy that apply to all routes, and only allow unauthenticated access to the routes related to logging in, password reset, etc.

One issue seems to be that associations are only populated 1 level deep, so I can't easily get to a user's permissions via their roles.

Logan

[Alberto Souza]

ok, thanks for sharing. 

I'll create something for my project next week and then send a link 

I will follow this issue here: https://github.com/wejs/we/issues/32 and try to make it plugable.

[Alberto Souza]

I created a gist to mount and improve the idea of how this could work ...

If you can, help to shape this module here: https://gist.github.com/albertosouza/81bfb2bea761b7b6f5fe

[logan...@austintexas.gov]

Hi Alberto,

I've made some progress on my end as well.

I added a Conditions model that has a many-to-many association with Permissions. The purpose of this is to apply simple boolean functions to permissions as additional tests, all of which must pass in order for the permission to be honored. Sort of like mini-policies, but which can be applied to individual permissions rather than controllers. They are optional of course. A permission without any condition is considered the same as a permission whose conditions all pass.

These would be defined as functions in a service or config file that the isAuthorized policy would know how to look up and evaluate.

Logan