Skip to content

Commit 88fa82b

Browse files
jzelinskiejzelinskie
authored
Merge pull request #249 from jzelinskie/coming-from-opa
pages: add "coming from" section with opa & rails
2 parents 2376e7b + 7715ca9 commit 88fa82b

File tree

13 files changed

+4241
-3224
lines changed

13 files changed

+4241
-3224
lines changed

‎pages/spicedb/getting-started/_meta.json

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,7 @@
33
"install": "Installing SpiceDB",
44
"installing-spicedb": { "display": "hidden" },
55
"installing-zed": "Installing Zed",
6+
"coming-from": "Coming From",
67
"protecting-a-blog": "Protecting a Blog Application",
78
"faq": "FAQ"
89
}

‎pages/spicedb/getting-started/coming-from/_meta.json

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
{
2+
"opa": "Open Policy Agent",
3+
"cancancan": "Ruby on Rails"
4+
}
5+

‎pages/spicedb/getting-started/coming-from/cancancan.mdx

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
import { Callout } from 'nextra/components';
2+
import PSDLight from '@/public/images/ps-light.svg'
3+
import PSDDark from '@/public/images/ps-dark.svg'
4+
import CCCLight from '@/public/images/ps-cancancan-light.svg'
5+
import CCCDark from '@/public/images/ps-cancancan-dark.svg'
6+
import SpiceDBLight from '@/public/images/ps-spicedb-light.svg'
7+
import SpiceDBDark from '@/public/images/ps-spicedb-dark.svg'
8+
9+
# SpiceDB for Ruby on Rails CanCanCan users
10+
11+
This document is designed to cover the conceptual differences between SpiceDB and the popular Ruby on Rails gem CanCanCan.
12+
13+
<Callout type="info" emoji="ℹ️">
14+
The focus of the content below is not intended to be a competitive anlaysis, but rather a bridge to understand SpiceDB for existing Rails users.
15+
</Callout>
16+
17+
## SpiceDB vs CanCanCan
18+
19+
Every complete permissions system is made up of three major components: *models*, *data*, and an *engine*.
20+
21+
While comparing SpiceDB and CanCanCan is akin to comparing apples and oranges because they are fundamentally two different approaches, both can analyzed through the lens of these three components to understand the design of each.
22+
23+
A quick recap on the components and their purpose:
24+
25+
- **Models** define the logic and rules governing actions in the system.
26+
- **Data** provides the context for action itself (who's doing it, the object of the action, and more)
27+
- An **engine** interprets models and data in order to make an access control decision
28+
29+
<center>
30+
<PSDLight className="p-5 h-96 w-96 dark:hidden"/>
31+
<PSDDark className="p-5 h-96 w-96 hidden dark:block"/>
32+
</center>
33+
34+
CanCanCan is a *library* (gem) designed to help model authorization in Ruby on Rails projects.
35+
The fundamental idea behind most authorization libraries is that access control can be modeled by reusing as much as possible from within your existing web framework.
36+
For cancancan, developers defines their models from within an `Ability` class.
37+
Engine logic is implemented within the library such that developers can simply load the `Ability` class within their `Controller` classes to enforce their models.
38+
Data outside of the request context is left open ended, but most often is fetched from the primary database using ActiveRecord.
39+
40+
<center>
41+
<CCCLight className="p-5 h-96 w-96 dark:hidden"/>
42+
<CCCDark className="p-5 h-96 w-96 hidden dark:block"/>
43+
</center>
44+
45+
SpiceDB is a class of technology called a *database*.
46+
The fundamental idea behind databases is that they store and index data efficiently so that it can be effectively queried.
47+
While many databases are general-purpose, SpiceDB is optimized specifically for storing and querying authorization data.
48+
SpiceDB provides all three components of a permissions systems: schema provides the models, the data is stored within the database itself, and the query engine interprets the two in order to make access control decisions.
49+
50+
<center>
51+
<SpiceDBLight className="p-5 h-96 w-96 dark:hidden"/>
52+
<SpiceDBDark className="p-5 h-96 w-96 hidden dark:block"/>
53+
</center>
54+
55+
## When to use SpiceDB instead of Cancancan
56+
57+
SpiceDB provides a centralized system and, while doing so, enforces opinions about how authorization should be done.
58+
Adopting SpiceDB can be a powerful tool for enabling a shift towards centralizing authorization into one service that can be operated by a specialized team.
59+
This design is a perfect fit for when there are multiple software services in an organization that needs to share data in order to secure access to their resources.
60+
61+
## When to use Cancancan instead of SpiceDB
62+
63+
Cancancan, and authorization libraries in general, excels when a monolithic or modular monolith architecture is the best fit for your software stack.
64+
For example, there are framework utilities and reusable app libraries that your authorization models can leverage.

‎pages/spicedb/getting-started/coming-from/opa.mdx

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
import { Callout } from 'nextra/components';
2+
import PSDLight from '@/public/images/ps-light.svg'
3+
import PSDDark from '@/public/images/ps-dark.svg'
4+
import OPALight from '@/public/images/ps-opa-light.svg'
5+
import OPADark from '@/public/images/ps-opa-dark.svg'
6+
import SpiceDBLight from '@/public/images/ps-spicedb-light.svg'
7+
import SpiceDBDark from '@/public/images/ps-spicedb-dark.svg'
8+
9+
# SpiceDB for Open Policy Agent (OPA) users
10+
11+
This document is designed to cover the conceptual differences between SpiceDB and Open Policy Agent (OPA).
12+
13+
<Callout type="info" emoji="ℹ️">
14+
The focus of the content below is not intended to be a competitive anlaysis, but rather a bridge to understand SpiceDB for existing OPA users.
15+
</Callout>
16+
17+
## SpiceDB vs OPA
18+
19+
Every complete permissions system is made up of three major components: *models*, *data*, and an *engine*.
20+
21+
While comparing SpiceDB and OPA is akin to comparing apples and oranges because they are fundamentally two different approaches, both can analyzed through the lens of these three components to understand the design of each.
22+
23+
A quick recap on the components and their purpose:
24+
25+
- **Models** define the logic and rules governing actions in the system.
26+
- **Data** provides the context for action itself (who's doing it, the object of the action, and more)
27+
- An **engine** interprets models and data in order to make an access control decision
28+
29+
<center>
30+
<PSDLight className="p-5 h-96 w-96 dark:hidden"/>
31+
<PSDDark className="p-5 h-96 w-96 hidden dark:block"/>
32+
</center>
33+
34+
Open Policy Agent is a class of technology called a *policy engine*.
35+
The fundamental idea behind policy engines is that access control decisions are the result of executing a computer program.
36+
37+
Referring back to the three components of a complete permissions system, policy engines typically implement only two of the three components: models and an engine.
38+
Developers write programs, called policies, to provide the models of their system.
39+
For OPA, their models are written in a language called Rego that was inspired by Datalog.
40+
An engine, OPA itself, then executes these policies using any data usually provided at runtime with the request.
41+
For data that is not provided with a request, there exist various configurations, strategies, and software projects for providing data into OPA-based systems; this aspect of OPA is open-ended.
42+
43+
<center>
44+
<OPALight className="p-5 h-96 w-96 dark:hidden"/>
45+
<OPADark className="p-5 h-96 w-96 hidden dark:block"/>
46+
</center>
47+
48+
SpiceDB is a class of technology called a *database*.
49+
The fundamental idea behind databases is that they store and index data efficiently so that it can be effectively queried.
50+
While many databases are general-purpose, SpiceDB is optimized specifically for storing and querying authorization data.
51+
SpiceDB provides all three components of a permissions systems: schema provides the models, the data is stored within the database itself, and the query engine interprets the two in order to make access control decisions.
52+
53+
<center>
54+
<SpiceDBLight className="p-5 h-96 w-96 dark:hidden"/>
55+
<SpiceDBDark className="p-5 h-96 w-96 hidden dark:block"/>
56+
</center>
57+
58+
## When to use SpiceDB instead of OPA
59+
60+
SpiceDB provides a comprehensive system and, while doing so, enforces opinions about how authorization should be done.
61+
It encourages developers to consider data consistency upfront as they integrate applications and face other, often silent, failure domains such as the [New Enemy Problem].
62+
Adopting SpiceDB can be a powerful tool for enabling a shift towards centralizing authorization into one service that can be operated by a specialized team.
63+
64+
[New Enemy Problem]: ../../concepts/zanzibar#new-enemy-problem
65+
66+
## When to use OPA instead of SpiceDB
67+
68+
OPA excels where in scenarios where it can be easily embedded or ran alongside an existing workload.
69+
Because it is a fairly open-ended how one deals with data in OPA deployments, it shines best as a solution when access control decisions don't require much data.

0 commit comments

Comments
 (0)