Mailing List Archive

Fine-grained access control with REST
In our aging Music application where we have the familiar hierarchy Label ->
CD -> Track -> Note. We also have an extra table for access control that
joins CDs with a User: cd_user. The action "PUT /note/*" is allowed if the
Note object can be joined to the current user via the cd_user table.

Now we want to extend this to have fine-grained access control. So, we
might have roles "owner" with full read/write access, "reader" with only
read access, and "editor" with read/write access but can only update a
subset of a Note's columns compared to the "owner".

Essentially, the "owner" and "editor" can both PUT a Note object but the
action would use different forms to validate the request and update the
database.

So, my question is what makes for a good URL scheme? One option is to use
"PUT /note/123" and before updating determine the type of access and select
that correct form object. So, both editors and and owners PUT to the same
URL but supplying different columns to update.

Another option is separate URLs such as "PUT /owner/note/123" and "PUT
/editor/note/123" making it very explicit.

What's your opinion about these options? Is there a better approach?


I suppose it's not always a boolean access question: a given user might
have multiple roles and may wish to pick which role to act as using
different URLs.


--
Bill Moseley
moseley@hank.org
Re: Fine-grained access control with REST [ In reply to ]
I would use the same URL for everyone, just use http basic access
authentication to send the users credentials and if the user does not
have the correct privileges just send back a 401 Unauthorized or
perhaps a 403 Forbidden. Let the client side handle the rest.

Kyle

http://www.kylehall.info
Mill Run Technology Solutions ( http://millruntech.com )
Crawford County Federated Library System ( http://www.ccfls.org )
Meadville Public Library ( http://www.meadvillelibrary.org )




On Tue, Apr 12, 2011 at 2:29 PM, Bill Moseley <moseley@hank.org> wrote:
> In our aging Music application where we have the familiar hierarchy Label ->
> CD -> Track -> Note.  We also have an extra table for access control that
> joins CDs with a User: cd_user.  The action "PUT /note/*" is allowed if the
> Note object can be joined to the current user via the cd_user table.
> Now we want to extend this to have fine-grained access control.  So, we
> might have roles "owner" with full read/write access, "reader" with only
> read access, and "editor" with read/write access but can only update a
> subset of a Note's columns compared to the "owner".
> Essentially, the "owner" and "editor" can both PUT a Note object but the
> action would use different forms to validate the request and update the
> database.
> So, my question is what makes for a good URL scheme?  One option is to use
> "PUT /note/123" and before updating determine the type of access and select
> that correct form object.  So, both editors and and owners PUT to the same
> URL but supplying different columns to update.
> Another option is separate URLs such as "PUT /owner/note/123" and "PUT
> /editor/note/123" making it very explicit.
> What's your opinion about these options?  Is there a better approach?
>
> I suppose it's not always a boolean access question:  a given user might
> have multiple roles and may wish to pick which role to act as using
> different URLs.
>
> --
> Bill Moseley
> moseley@hank.org
>
> _______________________________________________
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/