Resource Authorizations

[jrmce]

I'm looking for some suggestions and/or examples on how to best handle authorizations for individual resources. For example, say we have a Post resource, only the Author should be able to view the /posts/{id}/edit route.

Obviously, I could just do a quick check at the top of the handler to make sure the current user is the posts author, but are scopes more appropriate for this? If so, I've only been able to find examples using high level scopes (i.e. Admin, User), but what I'm looking to do is have a scope per resource route, for example, only users with scope X maybe edit post 123.

Can anyone provide any examples or direction? Or, perhaps I'm going about this the wrong way?

[devinivy]

It would not be terribly difficult to write ACLs like this using policies via the plugin mrhorse. I would suggest exploring that route, as it keeps your handlers nice and simple. If you're interested in writing a github-style API backed by Waterline ORM, I have a plugin called bedwetter that deals with enforcing record-level ownership. I have also seen route prerequisites used to enforce ACLs, though I don't think I would ever opt to use them that way.

[jrmce]

Thanks for the suggestions @devinivy. Interesting you say you wouldn't use route prerequisites in this way, and I wonder why? After doing some more research I think I'm actually leaning towards using them. Can you elaborate at all on why you wouldn't want to use them?

[johnbrett]

Hi @jrmce,

I've been using route prehandlers for this type of thing with a large application I have been working on and it's worked fine so far.

The one downside is the prerequisite needs to be added where this is necessary, meaning if it's forgotten or a new developer didn't know it was needed, those pages are left incorrectly secured. This is not quite 'the hapi way' where by usually the defaults are the most secure options, meaning you don't trip up by forgetting something. However as I understand it mrhorse has the same downside. Just my two cents on it.

Curious to know what path you take on this :)

[devinivy]

The reply interface is a little more complicated in route prerequisites, and its behavior depends on its failAction configuration. For simplicity's sake, I think most of these complications can be avoided by using prerequisites to perform async operations that you don't want to see in your handler, but whose results you intend to use in your handler. That's just me, though! The best way to think of route prerequisites are as being effectively part of the handler, so I don't think it's unreasonable to deal with ACLs in this way. I've just started to prefer mrhorse because it's more flexible for my uses, and it allows me to use route prerequisites for a more specific purpose.

[ldesplat]

In a previous job, I handled it by checking everything in onPostAuth extension point. Like this, every route is handled even if you forget. The implementation created a XACML request and sent it to a PDP (Policy Decision Point). If you want to go crazy enterprise route! :)

[adrianblynch]

Interesting that you (@Idelsplat) went down the ABAC route. How did you find having to use XML within the wonderful world of JSON?

I'm of the mind that pre is the way to go for checking access to a resource.

Maybe... may... be... looking at the route string, /resourceId/subResourceId and having the pre methods pick up on the fact that a couple of resources need to be accessed.

Like you @jrmce we have roles on a resource type, which lead to permissions and it has got fairly complex. So anything to move that logic into a more generic pre handler is welcome.

[ldesplat]

@adrianblynch I love you question :) You know XML is such a joy! The garbage collector of nodejs loved it so much, it worked extra hard! The existing nodejs libraries for handling SOAP calls are such high quality and it's not like you have to go around them for any critical stuff.

There is a JSON profile for XACML 3.0 but none of my supporting tooling handled it.

Anyways, in the end, it was the goal to move that authorization logic to our proxies. Let them decide if the request should even reach our app servers, and decorate the request with more information depending on the request. It would look at not just the URL, but the POST bodies and query params and cookie state and handle a lot of the business logic authorization issues in a central manner where it can easily be audited, use HSMs in the right places, ...