Skip to content

Commit ff33cc3

Browse files
author
Tom Kirkpatrick
committed
Upate documentation
1 parent f1e8716 commit ff33cc3

File tree

1 file changed

+72
-26
lines changed

1 file changed

+72
-26
lines changed

README.md

Lines changed: 72 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,24 @@
22

33
[![Circle CI](https://circleci.com/gh/fullcube/loopback-component-access-groups.svg?style=svg)](https://circleci.com/gh/fullcube/loopback-component-access-groups) [![Dependencies](http://img.shields.io/david/fullcube/loopback-component-access-groups.svg?style=flat)](https://david-dm.org/fullcube/loopback-component-access-groups) [![Coverage Status](https://coveralls.io/repos/github/fullcube/loopback-component-access-groups/badge.svg?branch=master)](https://coveralls.io/github/fullcube/loopback-component-access-groups?branch=master)
44

5-
This loopback component enables you to add multi-tenant style access controls to a loopback application. It enables you to restrict access to model data based on a users roles within a specific context.
5+
This loopback component enables you to add multi-tenant style access controls to a loopback application. It enables you to restrict access to model data based on a user's roles within a specific context.
6+
7+
There are two types of access restrictions implemented in this component:
8+
9+
**1) Role Resolvers**
10+
11+
For each *Group Role* that you define, a dynamic [Role Resolver](https://docs.strongloop.com/display/public/LB/Defining+and+using+roles#Definingandusingroles-Dynamicroles) is attached to the application. These Role Resolvers are responsible for determining wether or not a user has the relevant roles required to access data that belongs to a group context.
12+
13+
14+
**2) Query Filters**
15+
16+
An 'access' [Operation Hook](https://docs.strongloop.com/display/public/LB/Operation+hooks) is injected into each Group Content model. This is used to filter search results to ensure that only items that a user has access to (based on their Group Roles) are returned.
617

718
### Installation
819

920
1. Install in you loopback project:
1021

11-
`npm install --save loopback-component-access`
22+
`npm install --save loopback-component-access-groups`
1223

1324
2. Create a component-config.json file in your server folder (if you don't already have one)
1425

@@ -24,7 +35,7 @@ This loopback component enables you to add multi-tenant style access controls to
2435

2536
4. Create a middleware.json file in your server folder (if you don't already have one).
2637

27-
5. Enable the `loopback#context`, `loopback#token` and `user-context` middleware.
38+
5. Enable the `loopback#context`, `loopback#token` and `loopback-component-group-access#user-context` middleware.
2839

2940
```json
3041
{
@@ -38,30 +49,54 @@ This loopback component enables you to add multi-tenant style access controls to
3849

3950
### Usage
4051

41-
In order to use this component you will need to create group access model that can be used to link users to groups and assign group roles. A user can have have multiple roles within the context of a group and each role can define different access grants to REST resources. The *Group Access Model* must have the following three properties:
52+
**Group Model**
53+
54+
You will need to designate one of your models as the *Group Model*. This model will act as parent or container for related group specific data.
55+
56+
All models that have a belongsTo relationship to your *Group Model* will be considered as Group Content. Access grants for Group Content are determined by a user's roles within the context of its group as defined in the *Group Access Model*.
4257

43-
- userId
44-
- groupId (configurable foreign key)
45-
- role
58+
**Group Roles**
4659

47-
Additionally you will need to designate one of your models the *Group Model*. This model will act as parent or container for related group content.
60+
*Group Roles* can be used in ACL definitions to grant or restrict access to api endpoints to specific group roles.
4861

49-
Any other models that have a belongsTo relationship to your Group Model will be considered as Group Content. Access grants for Group Content is determined by the user's roles within the context of the group as defined in the Group Access Model.
62+
```
63+
{
64+
"accessType": "READ",
65+
"principalType": "ROLE",
66+
"principalId": "$group:member",
67+
"permission": "ALLOW"
68+
}
69+
```
5070

51-
For example:
71+
The above configuration would grant READ access to all users that have the 'member' role within the context of the group that a model instance belongs to.
5272

53-
- **Group Model:** Store (id, name, desxription)
73+
*Group Roles* can be defined in the component configuration using the `groupRoles` key. *Group Role* names must be prefixed with `$group:` (eg `$group:admin`).
74+
75+
**Group Access Model**
76+
77+
In order to use this component you will need to create *Group Access Model* that can be used to assign roles to users of a Group. A user can have have multiple roles within the context of a group and each role can be associated with different access grants to REST resources. The default schema for the *Group Access Model* is as follows, although this can be overridden through the component configuration options.
78+
79+
- User -> hasMany -> Groups (through GroupAccess)
80+
- Group -> hasMany -> Users (through GroupAccess)
81+
- GroupAccess
82+
- userId -> belongsTo -> User
83+
- groupId -> belongsTo -> Group
84+
- role
85+
86+
### Example
87+
88+
- **Group Model:** Store (id, name, description)
5489
- **Group Access Model:** StoreUsers (userid, storeId, role)
5590
- **Group Content Models:** Product, Invoice, Transaction, etc.
91+
- **Group Roles:** Store Manager, Store Administrator
5692

57-
You can have multiple stores.
58-
Each store can have multiple StoreUsers.
59-
Each StoreUser can have one or more Store Roles (eg, store manager, store administrator).
60-
Only Store Managers of Store A can create and edit products for Store A.
61-
Only Store Managers of Store B can create and edit products for Store B.
62-
Only Store Administrators of Store A can download transaction details for Store A.
63-
Only Store Administrators of Store B can download transaction details for Store B.
64-
etc.
93+
- You have multiple stores.
94+
- Each store can have multiple Store Users.
95+
- Each Store User can have one or more Store Roles (eg, Store Manager, Store Administrator).
96+
- Only Store Managers of Store A can create and edit products for Store A.
97+
- Only Store Managers of Store B can create and edit products for Store B.
98+
- Only Store Administrators of Store A can download transaction details for Store A.
99+
- Only Store Administrators of Store B can download transaction details for Store B.
65100

66101
### Configuration
67102

@@ -93,16 +128,10 @@ Options:
93128

94129
## Tests
95130

96-
### Roles
131+
A sample application is provided in the test directory. This demonstrates how you can integrate the component with a loopback application.
97132

98133
The following group roles roles are configured in the test data.
99134

100-
- **everyone**
101-
none
102-
103-
- **authenticated**
104-
none
105-
106135
- **$group:member**
107136
read
108137

@@ -111,3 +140,20 @@ create, read, update
111140

112141
- **$group:admin**
113142
create, read, update, delete
143+
144+
There are a number of test user accounts in the sample application.
145+
146+
- generalUser
147+
- (no group roles)
148+
- storeAdminA
149+
- ($group:admin of Store A)
150+
- storeManagerA
151+
- ($group:manager of Store A)
152+
- storeMemberA
153+
- ($group:member of Store A)
154+
- storeAdminB
155+
- ($group:admin of Store B)
156+
- storeManagerB
157+
- ($group:manager of Store B)
158+
- storeMemberB
159+
- ($group:member of Store B)

0 commit comments

Comments
 (0)