At my previous job I actually experimented with capability based
security for a Node powered Rest API, so it's nice to see some
validation :).  In general, it worked really well, and we never once
had to care WHO was sending the request, because the request told us
everything we needed to know about WHAT the request was authorized to
do.

One of the challenges we faced was how to structure our API such that
we didn't require a massive amount of capabilities to be created by
the server and managed by the client.  For example, given a typical
blog engine, you could assume that client's should be able to PUT
(i.e., update) against comments that the client itself created.  If
that request looked like 'PUT: /blog/:post-id/comments/:comment-id',
then the client would need a new capability for every single comment
that it POST'd.  You can work around this by instead exposing
endpoints like 'PUT: /comments/:client-id/:comment-id', and then
exposing a single capability for 'PUT: /comments/:client-id/:comment-
id/*' (or similar uri's that are scoped by the client).  This yields
further difficulties when it comes to shared resources though... also
solvable, but the approach requires a fair bit of up front design
work.

All that to say, I personally love the approach, but we weren't
successful in figuring out how to generalize it for any generic Rest
API.  We were just fortunate in that we had a very simple data model
that we were laying on top of.  Great writeup!

On Feb 21, 10:28 pm, Dan Yoder <[email protected]> wrote:
> Our Web API uses a form of capability security. It's still evolving,
> but I've written about what we've done thus far here:
>
> http://www.spire.io/posts/web-capabilities.html
>
> We'd love to hear from the Node community as to what they think of
> this approach.

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to