Ladon is the serpent dragon protecting your resources. A policy based authorization library written in Go. Ships with PostgreSQL and RethinkDB storage interfaces.
Utilizes ory-am/dockertest V2 for tests. Please refer to ory-am/dockertest for more information on how to setup testing environment.
Table of Contents
- Installation
- What is this and how does it work?
- How could Ladon work in my environment?
- Usage
- Good to know
- Useful commands
Ladon utilizes ory-am/dockertest for tests. Please refer to ory-am/dockertest for more information of how to setup testing environment.
go get github.com/ory-am/ladon
We recommend to use Glide or Godep, because there might be breaking changes in the future.
Ladon is an access control library. You might also call it a policy administration and policy decision point. Ladon answers the question:
Who is able to do what on something with some context
- Who An arbitrary unique subject name, for example "ken" or "printer-service.mydomain.com".
- Able: The effect which is always "allow" or "deny".
- What: An arbitrary action name, for example "delete", "create" or "scoped:action:something".
- Something: An arbitrary unique resource name, for example "something", "resources:articles:1234" or some uniform resource name like "urn:isbn:3827370191".
- Context: The current context which may environment information like the IP Address, request date, the resource owner name, the department ken is working in and anything you like.
An access control list (ACL), with respect to a computer file system, is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. Each entry in a typical ACL specifies a subject and an operation. For instance, if a file object has an ACL that contains (Alice: read,write; Bob: read), this would give Alice permission to read and write the file and Bob to only read it. - Source
Compare this with Ladon and you get:
- Who: The ACL subject (Alice, Bob).
- What: The Operation or permission.
- Something: The object.
ACL however is a white list (Alice is granted permission read on object foo). Ladon however can be used to blacklist as well: Alice is disallowed permission read on object foo.
Without tweaking, ACL does not support departments, ip addresses, request dates and other environmental information. Ladon does.
In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. RBAC is sometimes referred to as role-based security. Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members or staff (or other system users) are assigned particular roles, and through those role assignments acquire the computer permissions to perform particular computer-system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user's account; this simplifies common operations, such as adding a user, or changing a user's department. - Source
Compare this with Ladon and you get:
- Who: The role
- What: The Operation or permission.
Again, RBAC is a white list. RBAC does not know objects (something) neither does RBAC know contexts.
Ladon does not come with a HTTP handler. We believe that it is your job to decide if you want to use Protobuf, RESTful, HTTP, AMPQ, or some other protocol. It's up to you to write handlers!
The following examples will give you a better understanding of what you can do with Ladon.
A valid access request and policy requires at least the affected subject, action and effect:
> curl \
-X POST \
-H "Content-Type: application/json" \
-d@- \
"https://ladon.myorg.com/policies" <<EOF
{
"description": "One policy to rule them all.",
"subjects": ["users:peter", "users:ken", "groups:admins"],
"actions" : ["delete"],
"resources": [
"<.*>"
],
"effect": "allow"
}
EOF
> curl \
-X POST \
-H "Content-Type: application/json" \
-d@- \
"https://ladon.myorg.com/warden" <<EOF
{
"subject": "users:peter",
"action" : "delete"
}
EOF
{
"allowed": true
}
Note: Because resources matches everything (.*), it is not required to pass a resource name to the warden.
The next example uses resources and (context) conditions to further refine access control requests.
> curl \
-X POST \
-H "Content-Type: application/json" \
-d@- \
"https://ladon.myorg.com/policies" <<EOF
{
"description": "One policy to rule them all.",
"subjects": ["users:peter", "users:ken", "groups:admins"],
"actions" : ["delete"],
"effect": "allow",
"resources": [
"resource:articles<.*>"
],
"conditions": {
"remoteIP": {
"type": "CIDRCondition",
"options": {
"cidr": "192.168.0.1/16"
}
}
}
}
EOF
> curl \
-X POST \
-H "Content-Type: application/json" \
-d@- \
"https://ladon.myorg.com/warden" <<EOF
{
"subject": "users:peter",
"action" : "delete",
"resource": "resource:articles:ladon-introduction",
"context": {
"remoteIP": "192.168.0.5"
}
}
EOF
{
"allowed": true
}
Policies are an essential part of Ladon. Policies are documents which define who is allowed to perform an action on a resource.
Policies must implement the ladon.Policy interface. A standard implementation of this interface is ladon.DefaultPolicy:
import "github.com/ory-am/ladon"
var pol = &ladon.DefaultPolicy{
// A required unique identifier. Used primarily for database retrieval.
ID: "68819e5a-738b-41ec-b03c-b58a1b19d043",
// A optional human readable description.
Description: "something humanly readable",
// A subject can be an user or a service. It is the "who" in "who is allowed to do what on something".
// As you can see here, you can use regular expressions inside < >.
Subjects: []string{"max", "peter", "<zac|ken>"},
// Which resources this policy affects.
// Again, you can put regular expressions in inside < >.
Resources: []string{"myrn:some.domain.com:resource:123", "myrn:some.domain.com:resource:345", "myrn:something:foo:<.+>"},
// Which actions this policy affects. Supports RegExp
// Again, you can put regular expressions in inside < >.
Actions: []string{"<create|delete>", "get"},
// Should access be allowed or denied?
// Note: If multiple policies match an access request, ladon.DenyAccess will always override ladon.AllowAccess
// and thus deny access.
Effect: ladon.AllowAccess,
// Under which conditions this policy is "active".
Conditions: ladon.Conditions{
// In this example, the policy is only "active" when the requested subject is the owner of the resource as well.
"resourceOwner": &ladon.EqualsSubjectCondition{},
// Additionally, the policy will only match if the requests remote ip address matches address range 127.0.0.1/32
"remoteIPAddress": &ladon.CIDRCondition{
CIDR: "127.0.0.1/32",
},
},
}Ladon comes with ladon.Manager, a policy management interface which is implemented using RethinkDB and PostgreSQL.
Storing policies.
A word on Condition creators Unmarshalling lists with multiple types is not trivial in Go. Ladon comes with creators (factories) for the different conditions. The manager receives a list of allowed condition creators who assist him in finding and creating the right condition objects.
import (
"github.com/ory-am/ladon"
"github.com/ory-am/ladon/memory"
)
func main() {
warden := &ladon.Ladon{
Manager: memory.New(),
}
err := warden.Manager.Create(pol)
// ...
}You will notice that all persistent implementations require an additional argument when setting up. This argument
is called allowedConditionCreators and must contain a list of allowed condition creators (or "factories"). Because it is
not trivial to unmarshal lists of various types (required by ladon.Conditions), we wrote some helpers to do that for you.
You can always pass ladon.DefaultConditionCreators which contains a list of all available condition creators.
import "github.com/ory-am/ladon"
import "github.com/ory-am/ladon/postgres"
import "database/sql"
import _ "github.com/lib/pq"
func main() {
db, err = sql.Open("postgres", "postgres://foo:bar@localhost/ladon")
if err != nil {
log.Fatalf("Could not connect to database: %s", err)
}
warden := ladon.Ladon{
Manager: postgres.New(db),
}
// ...
}Now that we have defined our policies, we can use the warden to check if a request is valid.
ladon.Ladon, which is the default implementation for the ladon.Warden interface defines ladon.Ladon.IsAllowed() which
will return nil if the access request can be granted and an error otherwise.
import "github.com/ory-am/ladon"
func main() {
// ...
if err := warden.IsAllowed(&ladon.Request{
Subject: "peter",
Action: "delete",
Resource: "myrn:some.domain.com:resource:123",
}); err != nil {
log.Fatal("Access denied")
}
// ...
}There are a couple of conditions available:
- CIDR Condition: Matches CIDR IP Ranges.
- String Equal Condition: Matches two strings.
- Subject Condition: Matches when the condition field is equal to the subject field.
Let's assume that we are using the policy from above for the following requests.
This request will fail, because the subject "attacker" does not match []string{"max", "peter", "<zac|ken>"} and since
no other policy is given, the request will be denied.
import "github.com/ory-am/ladon"
func main() {
// ...
if err := warden.IsAllowed(&ladon.Request{
Subject: "attacker",
Action: "delete",
Resource: "myrn:some.domain.com:resource:123",
}); err != nil { // this will be true
log.Fatal("Access denied")
}
// ...
}Although the subject "ken" matches []string{"max", "peter", "<zac|ken>"} the request will fail because
ken is not the owner of myrn:some.domain.com:resource:123 (peter is).
import "github.com/ory-am/ladon"
func main() {
// ...
if err := warden.IsAllowed(&ladon.Request{
Subject: "ken",
Action: "delete",
Resource: "myrn:some.domain.com:resource:123",
Context: &ladon.Context{
"resourceOwner": "peter",
},
}); err != nil {
log.Print("Access denied")
}
// ...
}Although the subject "peter" matches []string{"max", "peter", "<zac|ken>"} the request will fail because
the "IPMatchesCondition" is not full filled.
import "github.com/ory-am/ladon"
func main() {
// ...
if err := warden.IsAllowed(&ladon.Request{
Subject: "peter",
Action: "delete",
Resource: "myrn:some.domain.com:resource:123",
Context: &ladon.Context{
"resourceOwner": "peter",
},
}); err != nil {
log.Print("Access denied")
}
// ...
}This request will be allowed because all requirements are met.
import "github.com/ory-am/ladon"
func main() {
// ...
if err := warden.IsAllowed(&ladon.Request{
Subject: "peter",
Action: "delete",
Resource: "myrn:some.domain.com:resource:123",
Context: ladon.Context{
"resourceOwner": "peter",
"remoteIPAddress": "127.0.0.1",
},
}); err != nil {
log.Print("Access denied")
}
// ...
}To view the example's full code, click here. To run it, call go test -run=TestLadon .
- All checks are case sensitive because subject values could be case sensitive IDs.
- If
ladon.Ladonis not able to match a policy with the request, it will default to denying the request and return an error.
Ladon does not use reflection for matching conditions to their appropriate structs due to security reasons.
Create mocks
mockgen -package internal -destination internal/manager.go github.com/ory-am/ladon Manager
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent