Ask HN: What are the best practices for web authorization at the moment?

Claims based authentication and authorization is all the rage.

Attribute/Claims based access control seem to be the most recommended these days. Legacy apps will tend to stick with the role based approach.

Defining authorisation rules as part of your application sounds fine to me. Aim for making compilation and deployment of your application trivial.

Sounds like you want a linear hierarchy of roles. Attaching a number to each role and making rules based on that number might be all you need. For example:

  Superadmin : 100
  Admin      : 90
  Manager    : 80

  if (a.number > b.number) a can delete b

Cancancan is one best tools to do this in Ruby. Maybe its DSL-like syntax will give you better ideas.

https://github.com/CanCanCommunity/cancancan

In my application I do this using tables in the database. The database has a roles table, a permissions table, a roles_permissions table and a roles_users table. When a user it looked up, a JOIN is done to pull in all the permissions assigned to all the roles, then there's a configuration that specifies with permission is required to access each API call.

This allows us the flexibility of adding additional roles and permission combinations without making any code changes.

Definitely checkout https://en.wikipedia.org/wiki/Two-factor_authentication .

If a password is compromised, data is protected.

I do authentication in terms of operations a.k.a. claims a.k.a. attributes, such as "Can Create User".

These are simple, easy to understand, and provide good flexibility.

If you enjoy using roles that's fine too: for example you can create an "Admin" role that grants permissions to do many operations. In other words the Admin role has many claims.

In your authorization code, you check the operation, not the user nor the role.

In your database or ORM, you can create these tables: users, users-roles, roles, roles-operations, operations.

We have a detailed writeup here: https://github.com/SixArm/sixarm_ruby_rbac

I think most people answered your question without reading it. They must be mind-readers.

In my opinion there's only one way to do this. Admins who are all powerful, and non-admins. None of this complexity of super-admins, etc.

Admins have access to everything. Groups have access to things given to them. Users in more than one group have access to the set of all things their groups have access to. Users without a group are really just users in a group of 1. They have access to things given to them.

People who ask for more complicated permissions than this are asking for foot shooting abilities, where people have access to things they don't mean to.

The rest is up to UX. Notify other admins when one behaves badly. Confirm admins really did mean to remove themselves from the admin group.

  >In my opinion there's only one way to do this. Admins who are all powerful, and non-admins

The last part of your question looks more like business rules for the management of users.

A complex scheme such as AWS IAM policies increases the chance of definition errors.

The business rules don't seem like they would change much over time so coding them in your user management module might be a good compromise.

I smell over-engineering. It sounds like you would like to keep your authorisation logic nicely decoupled from your code, stored away in a database. As you are starting to notice, you can only get so far with that approach and as you try to make your configuration more powerful to handle more and more edge cases, you will inevitably end up with some sort of Turing complete configuration system. My advice is to stick with something simple and just hard code the edge cases in your code. It may feel dirty but at least you won't end up with a monster like AWS IAM in your side project.

If you're really looking to overengineer this, look at SAML. ;-)

One way you can do that is by architecting something like chmod. Basically a point based system. 7 gives all, 1 gives read. You can then have your actual implementation compiled away, but can change points for a user as and when you like. The code that checks won't need to be recompiled.

You can model most security requirements with either decision matrixes and/or decision trees. These matrices and/or trees can be retrieved or calculated dynamically avoiding you from having code like: user.hasRole("Superadmin") || snip...

The two primary models are Access Control Lists or Role based security. You can google lots of info on these two security models.

In the past for enterprise/b2b I usually build ACL security with a Role based security on top (that is the RBAC underneath is ACLs). Obviously for consumer based products this is massive overkill.

Where I'm currently working we have quite complicated roles which are based upon the position a member of staff holds. Positions may change, and the permissions follows the position not an individual user. We have many applications, and each is free to implement their own roles but we have an open source gem which forms the basis of it:

https://github.com/ifad/eaco

At an application level there is a simple DSL that lets us define abilities on a resource (e.g. a document can be viewed, edited, approved and deleted) and roles (e.g. editor, reviewer, auditor), and to link those two.

On the actor (a user / member of staff) we define a set of designators such as what department they belong to, what position they hold in that department, what projects they are responsible for, etc.

When we then create resources, we link the actor and the designator which is ACL definition. For example, to say everyone that is a manager of department 5 can review a given document we do this:

   document.grant :reviewer, :department_manager, 5

Permissions can be added and removed to the resource's ACL on the fly - so for example we could grant temporary access to a member of staff to review a document, then revoke their access once they've given the ok.

It's easy to check if a user can perform a given action on a single resource, but we also want to see what actions a user can perform against a collection of resources, for example to present a list of Documents they have access to. The ACL is stored using PostgreSQLs JSONB columns, which can be efficiently queried against:

    { "department_manager:5" => :reviewer, "department:3" => :editor }

    SELECT * FROM documents WHERE documents.acl ?| array['department_manager:5']

This is not a programming problem, this is a Roles design problem. Admin is not a role, its a type of user. You might call it a container if you want... but roles are more fine grained, and should be a hierarchy.

You can put a hierarchy of Roles in a database, but the actual role check can (and I think should) be hard-coded.

In your API you might have a method "public void NewProduct()" That individual method should have the ProductWrite permission (role), and you can give that permission to higher level "containers" or "roles". So Admin has ProductWrite, and ContentManager might also have ProductWrite. In your code it's just one check has("ProductWrite").

Does that make sense?

You can stuff the logic of "who can do what" somewhere else. eg:

var permissions = { "Superadmin": ["selfdestruct",...], "Admin": ["ban",...], "Plebe": ["post",...] };

function roleCanDo(action, role) { return permissions[role].indexOf(action) > -1; }

Your check would look like: if (roleCanDo("someaction", user.getRole()))

Sorry if JS isn't your thing.

It is always amusing to see people trying to re-invent a wheel making it square.

What you are looking for is the MAC system under the merge down rules.

I'm working on an open source MEAN stack permissions framework that does some of what you're talking about. Its not fully baked yet, but feel free to give it a look: https://github.com/zekenie/dmv

It let's you say, "Moderators can delete posts", "Users can create posts", etc

Can't you do some simple inheritance stuff instead? Like User has_one Admin has_one SuperAdmin. Then join across your models.

Users have roles, roles provide permissions, some permissions are parameterized: http://shiro.apache.org/permissions.html

The way we allow developers to model this sort of thing out at Stormpath (https://stormpath.com/) is via Applications, Organizations, Directories, Groups, Accounts, and CustomData.

Those are the top-level resources we make available for 'modeling' authorization stuff.

Here's how it works (you can replicate this sort of setup in your own systems if you want):

A Directory is a 'bucket' of Accounts, that is unique by email / username. This way, you can segment users into Directories however you wish. If you were running 3 sites with entirely separate user bases, for instance, you might have 3 separate Directories, one for each underlying website. This way each site has its own unique group of users.

An Application is a collection of mapped Resources. So, let's say you have an Application for each website you run. You could choose to:

* Map a single Directory to each Application. This way, when a user authenticates against your Application, their credentials will be checked against a single Directory of Accounts.

* Map multiple Directories to each Application. This way, when a user authenticates against your Application, their credentials will be checked against multiple Directories of Accounts.

* Map other resources Directly (Groups / Organizations).

You've also got the Organization Resource, which is basically a 'Tenant' -- used for designing multi-tenant systems. Each Organization can have multiple Directories / Groups mapped to it directly, and Authentication / Authorization checks can be done against the Organization endpoint directly to control behaviors.

Then, you've got the Group Resource. This basically is a label that you can use to form Many-to-Many relationships between Accounts and Directories.

So, let's say you have a Directory with all your website users inside of it. You could create the Groups:

* Admins

* Super-Admins

* Developers

And assign Accounts to those Groups as needed. When a user is retrieved, you can then pull from their Groups, or vice-versa, to control Group-level information.

Finally -- you've got this big blob of JSON we call 'CustomData'. This is a Resource that is attached to every other Resource in Stormpath.

In CustomData, you can store things like claims / permissions. For instance, if you have an Account object, you might store some permissions like so in your Account's CustomData store:

{ "can_read": true, "can_write": false, "can_delete": false }

By doing a union of CustomData, Groups, Accounts, Directories, and Organizations (each of which have their own CustomData), you can essentially model out very complicated User Authorization patterns across your code base in a pretty dynamic way.

If you'd like to chat about this at all, or would like to just email me some suggestions or whatever, I'm totally open to feedback! randall@stormapth.com

Pyramid has a very flexible security system http://docs.pylonsproject.org/projects/pyramid/en/latest/nar...

You can define access control policies on a resource by resource basis. These can, where necessary, allow or deny permissions to individuals or roles based on the resource and request data.

There's a nice demo / walk through of capabilities here https://github.com/mmerickel/pyramid_auth_demo

As one of the contributors to Microauth[1] I have to say file-based auth using a dedicated auth server behind the scenes.

1. https://github.com/LukeB42/Microauth

You implemented what is known as a flat Role Based Access Control (RBAC) model. It is the simplest form of RBAC, which gets much more complex and powerful from there!