This is an example application based on GitHub that's meant to model GitHub's
permissions system. The app uses the oso-oso
library to model,
manage, and enforce authorization.
The Oso documentation is a good reference for more information on Oso's Ruby integration.
This app also uses Oso's built-in roles functionality, which you can read about here.
Install dependencies, migrate and seed the database, and start the server:
$ cd backends/rails
$ bundle install
$ bundle exec rails db:migrate
$ bundle exec rails db:seed
$ bundle exec rails s
- Rails / ActiveRecord
- SQLite for persistence
initializers/oso.rb
: Defines theOSO
constant, registers the necessary models, and loads the policy.application_controller.rb
: Defines a small controller helperauthorize! :action, resource
that usesOSO.authorize
under the hood to enforce the authorization policy. Check outrepos_controller.rb
to see it in action.authorization.polar
: The policy itself! Defines the roles used by the application, what each role is allowed to do, and how to fetch roles from a user during an authorization request.
The app has the following models:
Org
- the top-level grouping of users and resources in the app. As with GitHub, users can be in multiple orgs and may have different permission levels in each.User
- identified by email address, users can have roles within orgs and repos.Repo
- mimicking repos on GitHub — but without the backing Git data — each belongs to a single org.Issue
- mimicking GitHub issues, each is associated with a single repo.
In addition to the "domain" models listed above, there are also the following "Roles" models:
OrgRole
, which grant users either amember
orowner
role orgs.RepoRole
, which grant users aadmin
,maintainer
, orreader
role on repos.
The roles models are used by the Oso policy to determine which orgs, repos, and
issues users can access. Those permissions are defined in
app/authorization.polar
.