-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add authorization component #1205
Changes from all commits
d91f362
f9b9469
4ed12d3
b9baef4
15c64ce
5675415
d90bfeb
b86072c
3c7ae65
756bacf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
package-lock=true |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
Copyright (c) IBM Corp. 2018. All Rights Reserved. | ||
Node module: @loopback/authorization | ||
This project is licensed under the MIT License, full text below. | ||
|
||
-------- | ||
|
||
MIT license | ||
|
||
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. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,118 @@ | ||
# @loopback/authorization | ||
|
||
A LoopBack 4 component for authorization support. | ||
|
||
## Overview | ||
|
||
Authorization decides if a **subject** can perform specific **action** on an | ||
**object**. | ||
|
||
![Authorization](authorization.png) | ||
|
||
### Role based | ||
|
||
### Permission based | ||
|
||
### Vote based | ||
|
||
### Key building blocks | ||
|
||
1. Decorate a method to describe: | ||
|
||
- Permission (maps the method to an action on the protected resource) | ||
|
||
- Type of the protected resource (such as `customer` or `order`) | ||
- What action does the method represent (such as `changeEmail`, `createOrder`, | ||
or `cancelOrder`) | ||
|
||
- ACL (provides role based rules) | ||
|
||
- allowedRoles | ||
- deniedRoles | ||
|
||
- Voters (supplies a list of function to vote on the decision) | ||
|
||
2. Intercept a method invocation | ||
|
||
- Build authorization context | ||
|
||
- Subject (who) - from authentication | ||
- Map principals to roles | ||
- Inspect the target method for metadata - Permission, ACL, voters | ||
|
||
- Run through voters/enforcers to make decisions | ||
|
||
## Installation | ||
|
||
```shell | ||
npm install --save @loopback/authorization | ||
``` | ||
|
||
## Basic use | ||
|
||
Start by decorating your controller methods with `@authorize` to require the | ||
request to be authorized. | ||
|
||
In this example, we make the user profile available via dependency injection | ||
using a key available from `@loopback/authorization` package. | ||
|
||
```ts | ||
import {inject} from '@loopback/context'; | ||
import {authorize} from '@loopback/authorization'; | ||
import {get} from '@loopback/rest'; | ||
|
||
export class MyController { | ||
@authorize({allow: ['ADMIN']}) | ||
@get('/number-of-views') | ||
numOfViews(): number { | ||
return 100; | ||
} | ||
} | ||
``` | ||
|
||
## Extract common layer(TBD) | ||
|
||
`@loopback/authentication` and `@loopback/authorization` shares the client | ||
information from the request. Therefore we need another module with | ||
types/interfaces that describe the client, like `principles`, `userProfile`, | ||
etc... A draft PR is created for this module: see branch | ||
https://github.com/strongloop/loopback-next/tree/security/packages/security | ||
|
||
Since the common module is still in progress, as the first release of | ||
`@loopback/authorization`, we have two choices to inject a user in the | ||
interceptor: | ||
|
||
- `@loopback/authorization` requires `@loopback/authentication` as a dependency. | ||
The interceptor injects the current user using | ||
`AuthenticationBindings.CURRENT_USER`. Then we remove this dependency in the | ||
common layer PR, two auth modules will depend on `@loopback/security`. | ||
|
||
- This is what's been done in my refactor PR, `Principle` and `UserProfile` | ||
are still decoupled, I added a convertor function to turn a user profile | ||
into a principle. | ||
|
||
- The interceptor injects the user using another key not related to | ||
`@loopback/authentication`.(_Which means the code that injects the user stays | ||
as it is in https://github.com/strongloop/loopback-next/pull/1205_). Then we | ||
unify the user set and injection in the common layer PR: same as the 1st | ||
choice, two auth modules will depend on `@loopback/security`. | ||
|
||
## Related resources | ||
|
||
## Contributions | ||
|
||
- [Guidelines](https://github.com/strongloop/loopback-next/blob/master/docs/CONTRIBUTING.md) | ||
- [Join the team](https://github.com/strongloop/loopback-next/issues/110) | ||
|
||
## Tests | ||
|
||
run `npm test` from the root folder. | ||
|
||
## Contributors | ||
|
||
See | ||
[all contributors](https://github.com/strongloop/loopback-next/graphs/contributors). | ||
|
||
## License | ||
|
||
MIT |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
[request_definition] | ||
r = sub, obj, act | ||
|
||
[policy_definition] | ||
p = sub, obj, act | ||
|
||
[role_definition] | ||
g = _, _ | ||
|
||
[policy_effect] | ||
e = some(where (p.eft == allow)) | ||
|
||
[matchers] | ||
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @bajtos My understanding is, the authorizers are like authentication strategies, they are plugable, and the casbin fixtures are just consumed by an authorizer provider in the test case: https://github.com/strongloop/loopback-next/blob/3c7ae65f2a0ea5763f57263f85aa9db6c94986d5/packages/authorization/src/__tests__/acceptance/authorization-casbin.acceptance.ts#L128 I have another authorizer in the shopping cart example, which might be simpler to understand. It just compares the order's owner id with the current user's id. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
p, bob, order, create | ||
p, alice, order, create | ||
p, customer_service, order, read | ||
p, customer_service, order, create | ||
p, customer_service, order, delete | ||
p, customer_service, order, update | ||
g, alice, customer_service |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
// Copyright IBM Corp. 2017,2018. All Rights Reserved. | ||
// Node module: @loopback/authorization | ||
// This file is licensed under the MIT License. | ||
// License text available at https://opensource.org/licenses/MIT | ||
|
||
export * from './dist'; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
// Copyright IBM Corp. 2017,2018. All Rights Reserved. | ||
// Node module: @loopback/authorization | ||
// This file is licensed under the MIT License. | ||
// License text available at https://opensource.org/licenses/MIT | ||
|
||
module.exports = require('./dist'); |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
// Copyright IBM Corp. 2017,2018. All Rights Reserved. | ||
// Node module: @loopback/authorization | ||
// This file is licensed under the MIT License. | ||
// License text available at https://opensource.org/licenses/MIT | ||
|
||
// DO NOT EDIT THIS FILE | ||
// Add any additional (re)exports to src/index.ts instead. | ||
export * from './src'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is
ADMIN
- is it a role or user name? Can we use a more descriptive property name please, e.g.allowRoles
orallowedRoles
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice write up 👍
Can we make the example more clear? Like in naming, use cases.. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bajtos @agnes512 The
ADMIN
here is a role, not user name. The user name(or say principle name) will be inferred from the current user passed from@loopback/authentication
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this saying
user profile
will be available for this user as a role ofADMIN
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and also see my comment in #1205 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@agnes512
userProfile
is restored from the request's token, and every request contains that information, which means any user has its profile no matter what role it is.Hmm, I think you misunderstand the concept of "role" and "current user":
role
,id
,name
, etc...