Fork me on GitHub

looking forward to upgrade yada too simple_smile in my current project


@malcolmsparks: authentication / authorization is looking good! Especially the authentication schemes are very helpful. I created some kind of ad-hoc implementation for that, but it's much easier right now


do you have an example of authorization where there's a mix of role-based authorization and ownership of resources? like 'admins can change everything' and 'users can only change their own stuff'?


i'm not sure on the terminology, is this still RBAC?


where would you check, based on the role :normal-user that he/she has access to the resource if she/he is the author?


i have to create my own defmethod for the yada.authorization/validate multimethod?


Yes. Just pushed docs to master. See manuscript dir


ok got it.


one question though: the fact that a not allowed results in 1/ 401 when no credentials are provided and 2/ 403 when credentials are provided, shouldn't that be factored out of 'validate'?


@stijn: not as I understand it. The authenticate step simply verifies the truth of any credentials that are provided. It doesn't know whether any will be needed


it's only the authorization step, if and when particular credentials/entitlements are required, that determines whether it's a 401 or a 403. I've had to read and re-read that part of the spec. over and over


@stijn: no real examples as yet I'm afraid, but note that the ctx will contain the resource's properties as returned by the :properties function, and these can be used in the determination of whether the request should have access


@stijn: in your example you're talking ABAC (attribute based access control) because the author is an attribute of the resource. Authorization cannot be determined solely by the credentials, it also needs the properties of the resource. If you take a look at the default interceptor chain (see yada.handler) you'll see i/get-properties is called before sec/authorize - that's on purpose.


For pure RBAC it's not strictly necessary to load the resource's properties (and may be a wasted trip to the database to do so). However, after a lot of thought I've decided to stick with the interceptor chain order as it is. Users who have pure RBAC (not ABAC) requirements can choose to modify the interceptor chain on such resources, switch i/get-properties and sec/authorize around such that sec/authorize comes first.