oceanprotocol/docs
1
0
Fork 0
mirror of https://github.com/oceanprotocol/docs.git synced 2024-06-26 11:16:27 +02:00
Code Releases Activity

Removing fine-grained permissions section (#1038)

Browse Source
This commit is contained in:
Jamie Hewitt 2022-06-28 17:46:07 +03:00 committed by GitHub
parent 6f0fc86d5e
commit 0e1b256a9e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 0 additions and 215 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
content/tutorials/asset-level-permissions.md
View File

@ -1,48 +0,0 @@
---
title: Asset-Level Restrictions
description: Restrict access to individual assets
---
## Introduction
For asset-level restrictions Ocean supports allow and deny lists. Allow and deny lists are advanced features that allow publishers to control access to individual data assets. Publishers can restrict assets so that they can only be accessed by approved users (allow lists) or they can restrict assets so that they can be accessed by anyone except certain users (deny lists).
When an allow-list is in place, a consumer can only access the resource if they have a datatoken and one of the credentials in the "allow" list of the DDO. Ocean also has complementary deny functionality: if a consumer is on the "deny" list, they will not be allowed to access the resource.
Initially, the only credential supported is Ethereum public addresses. To be fair, it’s more a pointer to an individual not a credential; but it has a low-complexity implementation so makes a good starting point. For extensibility, the Ocean metadata schema enables specification of other types of credentials like W3C Verifiable Credentials and more. When this gets implemented, asset-level permissions will be properly RBAC too:)
Since asset-level permissions are in the DDO, and the DDO is controlled by the publisher, asset-level restrictions are controlled by the publisher.
## Setup
All and deny lists are not enabled by default in Ocean Market. You need to edit the environmental variables to enable this feature in your fork of Ocean Market:
- To enable allow and deny lists you need to add the following environmental variable to your .env file in your fork of Ocean Market: `GATSBY_ALLOW_ADVANCED_SETTINGS="true"`
- Publishers in your market will now have the ability to restrict who can buy their datasets.
## Usage
To use allow or deny lists you need to navigate to your data asset and click on "Advance Settings".
![Advanced Settings](images/allow-deny-lists/advanced-settings.png)
In order to add a user to a allow or deny list, you need to first know their ethereum address. You can then enter the address of the user into the input section and click the "ADD" button.
![Add address to allow list](images/allow-deny-lists/add-allow-list.png)
To remove a user from an all or deny list you can click the cross next to their ethereum address.
![Removing a user from allow or deny list](images/allow-deny-lists/removing-allow-deny.png)
Any changes you make on the advanced settings page need to be submitted and signed in a transaction. To do this, first click the "SUBMIT" button.
![Submit changes to allow or deny lists](images/allow-deny-lists/submit.png)
Next you will need to sign the transaction in Metamask, or the wallet of your choice.
![Sign Metamask transaction](images/allow-deny-lists/metamask-transaction.png)
When the process of updating the allow or deny lists is complete you will receive a success message.
![Update allow or deny list success](images/allow-deny-lists/update-success.png)

127
content/tutorials/market-level-permissions.md
View File

@ -1,127 +0,0 @@
---
title: Market-Level Permissions
description: Control who can publish, buy or browse data
---
## Introduction
For market-level permissions, Ocean implements a role-based access control server (RBAC server). It implements restrictions at the user level, based on the user’s role (credentials). The RBAC server is run & controlled by the marketplace owner. Therefore permissions at this level are at the discretion of the marketplace owner.
The RBAC server is the primary mechanism for restricting your users ability to publish, buy, or browse assets in the market.
## Roles
The RBAC server defines four different roles:
- Admin
- Publisher
- Consumer
- User
### Admin/ Publisher
Currently users with either the admin or publisher roles will be able to use the Market without any restrictions. They can publish, buy and browse datasets.
### Consumer
A user with the consumer is able to browse datasets, purchase them, trade datatokens and also contribute to datapools. However, they are not able to publish datasets.
![Viewing the market without publish permission](images/rbac/without-publish-permission.png)
### Users
Users are able to browse and search datasets but they are not able to purchase datasets, trade datatokens, or contribute to data pools. They are also not able to publish datasets.
![Viewing the market without consume permission](images/rbac/without-consume-permission.png)
### Address without a role
If a user attempts to view the data market without a role, or without a wallet connected, they will not be able to view or search any of the datasets.
![Viewing the market without browse permission](images/rbac/without-browse-permission.png)
### No wallet connected
When the RBAC server is enabled on the market, users are required to have a wallet connected to browse the datasets.
![Connect a wallet](images/rbac/connect-wallet.png)
## Mapping roles to addresses
Currently the are two ways that the RBAC server can be configured to map user roles to Ethereum addresses. The RBAC server is also built in such a way that it is easy for you to add your own authorization service. They two existing methods are:
1. Keycloak
If you already have a [Keycloak](https://www.keycloak.org/) identity and access management server running you can configure the RBAC server to use it by adding the URL of your Keycloak server to the `KEYCLOAK_URL` environmental variable in the RBAC `.enb` file.
2. JSON
Alternatively, if you are not already using Keycloak, the easiest way to map user roles to ethereum addresses is in a JSON object that is saved as the `JSON_DATA` environmental variable in the RBAC `.env` file. There is an example of the format required for this JSON object in `.example.env`
It is possible that you can configure both of these methods of mapping user roles to Ethereum Addresses. In this case the requests to your RBAC server should specify which auth service they are using e.g. `"authService": "json"` or `"authService": "keycloak"`
### Default Auth service
Additionally, you can also set an environmental variable within the RBAC server that specifies the default authorization method that will be used e.g. `DEFAULT_AUTH_SERVICE = "json"`. When this variable is specified, requests sent to your RBAC server don't need to include an `authService` and they will automatically use the default authorization method.
## Running the RBAC server locally
You can start running the RBAC server by following these steps:
1. Clone this repository:
```Bash
git clone https://github.com/oceanprotocol/RBAC-Server.git
cd RBAC-Server
```
2. Install the dependencies:
```Bash
npm install
```
3. Build the service
```Bash
npm run build
```
4. Start the server
```Bash
npm run start
```
## Running in Docker
When you are ready to deploy the RBAC server to
1. Replace the KEYCLOAK_URL in the Dockerfile with the correct URL for your hosting of [Keycloak](https://www.keycloak.org/).
2. Run the following command to build the RBAC service in a Docker container:
```Bash
npm run build:docker
```
3. Next, run the following command to start running the RBAC service in the Docker container:
```Bash
npm run start:docker
```
4. Now you are ready to send requests to the RBAC server via postman. Make sure to replace the URL to `http://localhost:49160` in your requests.
## Setting up the RBAC in the Market
To use the RBAC server with the market you need to save the URL of your RBAC server as an env within the market.
- First setup and host the Ocean role based access control (RBAC) server. Follow the instructions in the [RBAC repository](https://github.com/oceanprotocol/RBAC-Server)
- In your .env file in your fork of Ocean Market, set the value of the `GATSBY_RBAC_URL` environmental variable to the URL of the Ocean RBAC server that you have hosted, e.g. `GATSBY_RBAC_URL= "http://localhost:3000"`
- Users of your marketplace will now require the correct role ("user", "consumer", "publisher") to access features in your marketplace. The market will check the role that has been allocated to the user based on the address that they have connected to the market with.
- The following features have been wrapped in the `Permission` component and will be restricted once the `GATSBY_RBAC_URL` has been defined:
- Viewing or searching datasets requires the user to have permission to `browse`
- Purchasing or trading a datatoken, or adding liquidity to a pool require the user to have permission to `consume`
- Publishing a dataset requires the user to have permission to `publish`
- You can change the permission restrictions by either removing the `Permission` component or passing in a different eventType prop e.g. `<Permission eventType="browse">`.

31
content/tutorials/permissions.md
View File

@ -1,31 +0,0 @@
---
title: Fine-Grained Permissions
description: Control who can publish, buy or browse data
---
A large part of Ocean is about access control, which is primarily handled by datatokens. Users can access a resource (e.g. a file) by redeeming datatokens for that resource. We recognize that enterprises and other users often need more precise ways to specify and manage access, and we have introduced fine-grained permissions for these use cases.
Fine-grained permissions mean that access can be controlled precisely at two levels:
- [Marketplace-level permissions](./market-level-permissions) for browsing, downloading or publishing within a marketplace frontend.
- [Asset-level permissions](./asset-level-permissions) on downloading a specific asset.
The fine-grained permissions features are designed to work in forks of Ocean Market. We have not enabled them in Ocean Market itself, to keep Ocean Market open for everyone to use. On the front end, the permissions features are easily enabled by setting environment variables.
### Introduction
Some datasets need to be restricted to appropriately credentialed users. In this situation there is tension:
1. Datatokens on their own aren’t enough - the datatokens can be exchanged without any restrictions, which means anyone can acquire them and access the data.
2. We want to retain datatokens approach, since they enable Ocean users to leverage existing crypto infrastructure e.g. wallets, exchange etc.
We can resolve this tension by drawing on the following analogy:
> Imagine going to an age 18+ rock concert. You can only get in if you show both (a) your concert ticket and (b) an id showing that you’re old enough.
We can port this model into Ocean, where (a) is a datatoken, and (b) is a credential. The datatoken is the baseline access control. It’s fungible, and something that you’ve paid for or had shared to you. It’s independent of your identity. The credential is something that’s a function of your identity.
The credential based restrictions are implemented in two ways, at the market level and at the asset level. Access to the market is restricted on a role basis, the user's identity is attached to a role via the role based access control (RBAC) server. Access to individual assets is restricted via allow and deny lists which list the ethereum addresses of the users who can and cannot access the asset within the DDO.

9
data/sidebars/tutorials.yml
View File

@ -51,12 +51,3 @@
link: /tutorials/compute-to-data-algorithms/
- title: Setting up docker registry
link: /tutorials/compute-to-data-docker-registry/
- group: Fine-Grained Permissions
items:
- title: Overview
link: /tutorials/permissions
- title: Market-Level Permissions
link: /tutorials/market-level-permissions
- title: Asset-Level Permissions
link: /tutorials/asset-level-permissions