You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bouncer is a [JWT]-based authentication and authorization service.
@@ -31,8 +31,8 @@ As an example, [this blog post](https://engineering.etermax.com/api-authorizatio
31
31
- It aims to be out-of-the-box compatible with **nginx**, **traefik** and **envoy** without any development effort.
32
32
33
33
#### How it works
34
-
- The **API gateway** receives an HTTP request from the client and it forwards the request (usually without including the body) to **Bouncer**.
35
-
-**Bouncer** matches the request method and path to configured **route policies**.
34
+
- The **API gateway** receives an HTTP request from the client and forwards it (usually without including the body) to **Bouncer**.
35
+
-**Bouncer** matches the request method and path (i.e. GET /stuff/) to configured **route policies**.
36
36
- If the most specific<sup>1</sup> **route policy** that matches the request explicitly allows anonymous requests, a response with status code **200(OK)** is returned.
37
37
-**Bouncer** extracts the [Bearer] token and validates it for authentication. If authentication fails, a response with status code **401(Unauthorized)** is returned.
38
38
-**Bouncer** extracts claims from the validated token and checks if all **claim policies** corresponding to the matched **route policies** are fulfilled. If not, a response with status code **403(Forbidden)** is returned.
@@ -54,37 +54,10 @@ When given an **upstream URL**, **Bouncer** performs the same checks as in the A
54
54
-**Bouncer** is more flexible in route configuration, because it uses standard wildcard patterns to match paths.
55
55
-**Bouncer** is less flexible in claim policy configuration, because claim requirements can only be expressed in equality comparisons (and "contains" checks in case of array claims).
56
56
57
-
#### Employee example
58
-
The following configuration example is loosely based on the example provided in the above .NET Core documentation:
59
-
60
-
```yaml
61
-
claimPolicies:
62
-
EmployeeOnly:
63
-
- claim: employee_number
64
-
Founders:
65
-
- claim: employee_number
66
-
values: [1,2,3,4,5]
67
-
HumanResources:
68
-
- claim: department
69
-
values: [HumanResources]
70
-
71
-
routePolicies:
72
-
- path: /vacation/**
73
-
policyName: EmployeeOnly
74
-
- path: /vacation/policy
75
-
allowAnonymous: true
76
-
- path: /vacation/*/
77
-
methods: [PUT, PATCH]
78
-
policyName: Founders
79
-
- path: /salary/**
80
-
policyName: EmployeeOnly
81
-
- path: /salary/*/
82
-
methods: [PUT, PATCH]
83
-
policyName: HumanResources
84
-
```
85
-
57
+
### Examples
86
58
#### Allow anonymous example
87
59
The following configuration depicts a system in which all requests are allowed in without any authentication, except DELETEs and the ones with intentions to destroy the server.
60
+
88
61
```yaml
89
62
claimPolicies: {}
90
63
@@ -121,8 +94,82 @@ routePolicies:
121
94
allowAnonymous: true
122
95
```
123
96
97
+
#### Employee example
98
+
The following configuration example is loosely based on the example provided in the [.NET Core docs](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims?view=aspnetcore-3.1):
99
+
100
+
```yaml
101
+
claimPolicies:
102
+
EmployeeOnly:
103
+
- claim: employee_number
104
+
Founders:
105
+
- claim: employee_number
106
+
values: [1,2,3,4,5]
107
+
HumanResources:
108
+
- claim: department
109
+
values: [HumanResources]
110
+
111
+
routePolicies:
112
+
- path: /vacation/**
113
+
policyName: EmployeeOnly
114
+
- path: /vacation/policy
115
+
allowAnonymous: true
116
+
- path: /vacation/*/
117
+
methods: [PUT, PATCH]
118
+
policyName: Founders
119
+
- path: /salary/**
120
+
policyName: EmployeeOnly
121
+
- path: /salary/*/
122
+
methods: [PUT, PATCH]
123
+
policyName: HumanResources
124
+
```
125
+
124
126
## Current status
125
-
The project is in its infancy, does not have MVP features yet and is far from being production-grade.
127
+
First version has been released! 🎉 It's not battle-tested yet, but it's a start.
128
+
129
+
#### Current functionality in a nutshell:
130
+
- Static signing key configuration w/ HMAC, RSA and EC support
131
+
- Single valid issuer and audience configuration
132
+
- Token expiration, "not before" and "issued at" checks with clock skew tolerance
Every startup setting has an environment variable and a CLI flag counterpart.
160
+
161
+
| Environment Variable | CLI Flag | Description |
162
+
| -------------------- | -------- | ----------- |
163
+
| BOUNCER_SIGNING_KEY | -k | Signing key to be used to validate tokens. Consider setting this variable through a file for multiline keys. e.g. `BOUNCER_SIGNING_KEY=$(cat rsa.pub)`|
0 commit comments