About

Auhtorization for distributed systems. It provides the infrastructure to create, store and enforce access policy to resources distributed across many web services. This is the server-side component composed by an HTTP REST API and message bus consumer. There is also a client-side component written in Ruby.

This project is in alpha mode and should be not used in production yet.

Informações:

• Builds
• Análise estática
• Versão das dependências

Definitions and terminology

The policy is the set of rules that determine what is allowed in the system. The mechanism is the set of software and/or hardware components that know how to enforce the policy in the system [1].

The principle states that mechanism should be strictly separated and independent from the policy they enforce. This provides flexibility because:

1. it makes the mechanisms reusable for diferent kinds of policies
2. it allows policies to be reused for multiple systems
3. it supports the evolution and analysis of policies over time.

REST API

The main resource available in this webservice is the Rule. The policy is the set of rules that determine what is allowed in the system. In a cleaner language, a Policy is a set of rules that concern one resource.

An Rule have the following schema:

  {
    "id" : 219839028,
    "resource_id" : "core:course_1212",
    "subject_id" : "core:user_4",
    "actions" : {
      "read" : true, "foo" : false
    }
  }

There is no schema on the property actions. It depends only on the service needs.

For example, if you want to know if the subject core:user_2 is allowed to read the resource core:space_1 just issue a GET request as follows:

permit >  curl -H 'Accept: application/json' 'http://0.0.0.0:9000/rules?resource_id=core:space_1&subject_id=core:user_2&action=read' -vv

> GET /rules/resource/core:space_1/subject/core:user_2/action/read HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: 0.0.0.0:9000
> Accept: application/json
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 87
< Server: Goliath
< Date: Wed, 12 Sep 2012 10:51:14 GMT
<
[{"resource_id":"core:course_1212","subject_id":"core:user_4","actions":{"read":true}}]

Of course, in this case, the response body is useless. So you can issue a HEAD request to the same URL. If the response code is 200 the subject has read access to the resource, otherwise the status will be 404.

Here is an example which denies the access to a resource:

permit >  curl -H 'Accept: application/json' -X HEAD 'http://0.0.0.0:9000/rules?resource_id=core:space_1&subject_id=core:user_2&action=read' -vv

> HEAD /rules/resource/core:space_1/subject/core:user_2/action/manage HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: 0.0.0.0:9000
> Accept: application/json
>
< HTTP/1.1 404 Not Found
< Content-Type: application/json
< Content-Length: 3
< Server: Goliath
< Date: Wed, 12 Sep 2012 11:07:26 GMT
<

HEAD requests are slightly more performant than GET requests because there is no need to instantiate the records.

You can also get all the Rules for a given resource:

permit > curl -H 'Accept: application/json' http://0.0.0.0:9000/rules?resource_id=core:space_1 -vv

> GET /rules/resource/core:space_1 HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: 0.0.0.0:9000
> Accept: application/json
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 263
< Server: Goliath
< Date: Wed, 12 Sep 2012 11:11:47 GMT
<
* Connection #0 to host 0.0.0.0 left intact
* Closing connection #0
[{"resource_id":"core:course_1212","subject_id":"core:user_4","actions":{"read":true}},{"resource_id":"core:course_1212","subject_id":"core:user_5","actions":{"manage":true}},{"resource_id":"core:course_1212","subject_id":"core:user_8","actions":{"manage":true}}]

Running

Server

You just need to run the server with ruby server.rb -sv

AMQP Consumer

bundle exec ruby worker.rb or, as a daemon, bundle exec permitd.rb start

Deploy

In order to deploy on heroku you should enable some MongoDB addon and set environment variables:

permit > heroku config:set MONGO_HOST=<host>
permit > heroku config:set MONGO_PORT=<port>
permit > heroku config:set MONGO_DB_NAME=<db name>
permit > heroku config:set MONGO_USER=<user>
permit > heroku config:set MONGO_PASS=<passoword>

Replace <value> with the proper value given by your MongoDB host.

Internals

The REST API is build on top of Goliath, Grape and em-mongo.

TODO

• Define Rule better: it's not the correct representation of the entity. There is a schizophrenia about class vs. instance method and rule vs collection of rules.
• More consistent arguments. For instance, rule.count(:actions => { :read => true }) but the insert uses rule.insert(:action => :read).
• Use HTTP Basic Auth

This project is maintained and funded by Redu Educational Techologies.

Copyright

Copyright (c) 2012 Redu Educational Technologies

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.