Контроль доступу на основі ролей у службі екологічного кредитування (підготовча версія)

Стаття
08/01/2024

Важливо

Деякі або всі ці функції доступні в рамках підготовчого версії. Вміст і функції можуть змінитися. Ви можете отримати доступ до середовища пісочниці Environmental Credit Service (підготовча версія) для 30-денного пробного періоду. Щоб використовувати Послугу екологічного кредитування (підготовча версія) у виробничому середовищі, заповніть форму реєстрації Служби екологічного кредитування (підготовча версія).

Керування доступом на основі ролей дає змогу керувати доступом до різних операцій у програмі на основі дозволів, наявних у ролях, призначених користувачам в організації. Він дозволяє надавати та видаляти ролі, призначені користувачам в організації, для точного контролю.

Кожна добровільна екосистемна організація екологічного ринку відіграє певну роль, яка називається ринковою роллю в службі екологічного кредитування (підготовча версія). Кожна організація буде залучати користувачів до Служби екологічного кредитування (підготовча версія) і призначати ролі користувачів. Такі ресурси, як екологічні проєкти чи програми, модульні проєкти бенефітів, вимоги та токени, належать організації, а не користувачу.

Призначення ролей користувачів

Роль користувача визначається як колекція дозволів, що дозволяють виконувати певні дії в програмі. Ви можете призначати ці ролі користувачів на рівні організації або на рівні активів у контексті конкретної ринкової ролі. Служба екологічного кредитування (підготовча версія) підтримує такі ролі користувачів:

Роль користувача	Дозволи
Район	Адміністратор може виконувати всі підтримувані операції на площині даних на пов’язаних ресурсах, такі як створення, оновлення, читання та видалення. Вони також можуть виконувати операції на рівні керування, такі як адаптація користувачів в організації та створення або оновлення призначень ролей для них.
Співавтор	Учасник може виконувати всі підтримувані операції на площині даних на пов’язаних ресурсах, такі як створення, оновлення, читання та видалення. Вони також отримують доступ для читання на рівні площини управління.
Читач	Зчитувач може виконувати операції зчитування на пов’язаному рівні площини даних і на рівні ресурсів площини керування.

Управління ролями на рівні організації в контексті ринкової ролі

Для керування доступом на основі ролей на рівні організації в контексті конкретного рівня ринкової ролі підтримуються такі можливості. Наприклад, якщо організація виступає в якості покупця, то у неї одна ринкова роль (покупець). На рівні організації користувач цієї організації може мати ролі адміністратора покупця, постачальника покупця або користувача читача покупця.

Одна організація може мати кілька ролей на ринку. Наприклад, якщо інша організація діє і як реєстр емітентів, і як маркетплейс, вона має дві ринкові ролі. Користувач цієї організації може мати роль адміністратора постачальника в контексті ролі постачальника на ринку та роль читача реєстру видачі в контексті ролі реєстру видачі.

Керуйте ролями на рівні активів

Ви можете керувати привілеями користувачів на рівні активів в організації. Адміністратор або учасник на рівні організації може створювати нові активи. Адміністратор на рівні організації також може додавати користувачів до об’єкта та призначати їм ролі.

Адміністратор на рівні активів: адміністратору на рівні активу надається роль адміністратора в певному деталізованому обсязі активу в організації. Наприклад, користувачу призначається роль адміністратора постачальника в рамках проекту модульної вигоди в ролі постачальника на ринку постачальників організації. Вони можуть виконувати всі підтримувані операції на площині даних над активом, такі як читання та запис. Вони також можуть виконувати операції на рівні керування, наприклад залучати користувачів в організації до конкретного активу, адміністратором якого вони є.
Учасник на рівні активу: учасник на рівні активу може виконувати всі підтримувані операції на площині даних з ресурсом, наприклад читати та оновлювати ресурс. Вони можуть зчитувати призначення ролей інших користувачів або груп у межах цього об’єкта.
Зчитувач на рівні активу: читач на рівні активу може виконувати операції зчитування ресурсу. Вони можуть зчитувати призначення ролей інших користувачів або груп у межах цього об’єкта.

Нотатка

Ієрархія доступу зверху вниз буде збережена. Наприклад, якщо користувач має роль адміністратора в ролі ринку постачальників у масштабі організації, то він автоматично матиме доступ на рівні адміністратора до всіх активів (таких як екологічні проекти та модульні пільгові проекти) для цього постачальника. Якщо інший користувач має адміністративний доступ на рівні активу (наприклад, на екологічному проєкті), то він матиме доступ до всіх активів під ним.

Підтримувані можливості керування доступом на основі ролей

Передумови для використання колекції Postman для API

Ви можете встановити колекцію Postman з конфігурацією оточення організацій та їх адміністраторів наступним чином:

Встановіть дані користувача в різних змінних (наприклад: < marketRole>_admin_username) колекція листоноші для різних ринкових ролей, які ви хочете використовувати, разом з відповідними паролями.
Створіть нове середовище Postman і перейдіть до нього перед виконанням будь-яких API у колекції.
Запустіть папку «Установлення організацій» для конкретної ролі ринку, яку ви хочете використовувати, щоб налаштувати властивості організації (та її відповідних адміністраторів) у середовищі Postman.
Запустіть API «Отримати всі визначення > ролей », щоб отримати детальну інформацію про всі вбудовані визначення ролей користувачів у середовищі Postman. відповідь з API визначення ролей може бути використана для вивчення призначених областей видимості, які можна призначити користувачам.

Додати користувачів

Ви можете додавати користувачів і керувати їхніми ролями в організації, перейшовши до меню «Налаштування» на панелі навігації ліворуч.

Нотатка

Ви не можете додати користувача, якого вже було додано.

На екрані Доступ користувача виберіть Додати користувача.
В області Додати користувача введіть Користувач , виберіть рівень доступу , а потім натисніть кнопкуЗберегти .

Через API:

Нотатка

Папка «Onboard Users » колекції Postman підтримує виконання в один клік. Однак ми рекомендуємо вам використовувати окремі API, щоб спробувати онбординг користувачів і ознайомитися з API.

Для будь-якої організаційної папки, наприклад «Постачальник», у папці «Onboard Users » колекції Postman налаштуйте організацію та її адміністратора, викликавши API «Отримати відомості про організацію» та «Отримати дані користувача адміністратора».
Щоб приєднати користувача-співавтора, ви можете переконатися, що авторизація, необхідна для API, відповідає користувачу адміністратора. Набір корисних даних запиту намагається додати нового користувача з вбудованою роллю користувача-учасника, наприклад роллю користувача постачальника-постачальника. Надсилання запиту на борт дописувача.
Аналогічно, ви можете впровадити користувача читача в організації з відповідною роллю читача, наприклад роллю користувача читача постачальника.

Зміна призначень ролей

Додавши користувачів, ви можете змінити призначену їм роль.

Нотатка

Ви не можете редагувати власний доступ.

На екрані Доступ користувача натисніть три крапки поруч із користувачем, а потім натисніть Редагувати.
В області Редагування доступу виберіть нову роль у розкривному списку Рівень доступу, а потім натисніть кнопку Зберегти.

Через API:

Перейдіть до папки «Призначення ролей» у колекції.
Використовуйте функцію Створити призначення ролей в API об’єкта . За замовчуванням роль учасника постачальника призначається користувачеві-читачу постачальника за допомогою маркера доступу адміністратора постачальника.

Нотатка

Цей приклад показує, як працює API для призначення ролей. Ви можете призначити різні ролі користувача користувачам із різних організацій за допомогою відповідних облікових записів адміністраторів. Ви можете змінити URI ресурсу області на URI дійсного ресурсу для визначення ролі. Замініть змінні середовища в наборі корисних даних запиту (roleDefinitionId і userId), змініть параметр тіла запиту resourceUri та змініть змінну середовища маркера доступу адміністратора, щоб вона відповідала відповідному обліковому запису користувача адміністратора.

Ви можете надіслати API створення призначення ролей із різними значеннями ідентифікатора визначення ролі (roleDefinitionId) для призначення різним користувачам в організації (userId) у різній області (resourceUri). Ви можете змінити заголовок авторизації, щоб він відповідав токену доступу відповідного адміністратора.

Адміністратори організації не можуть призначати ролі користувачів за межами своєї організації, а також не можуть призначати ролі користувачам за межами своєї організації.
Використовуйте API призначення ролей оновлення, щоб оновити доступ користувача. Наприклад, можна підвищити користувача до посади адміністратора постачальника. Обов’язково перевірте roleassignment_id в параметрі API.

Як видалити призначення ролей

Користувач із правами адміністратора може за потреби видаляти наявні призначення ролей для учасників.

Нотатка

Ви не можете видалити власний доступ.

На екрані Доступ користувача натисніть три крапки поруч із користувачем, а потім натисніть Редагувати.
В області Редагування доступу виберіть пункт Немає в розкривному списку Рівень доступу, а потім натисніть кнопку Зберегти.

Через API:

Налаштуйте роль адміністратора, що відповідає організації користувача, призначення ролей якого потрібно видалити.
Перейдіть до папки «Призначення ролей» і виберіть API «Видалити призначення ролей ».
Введіть правильний roleassignment_id у параметрі API.
Викличте DELETE /roleAssignments/{{roleassignment_id}} , встановивши заголовок авторизації з відповідним маркером доступу адміністратора (змінні з оточення Postman можна використовувати для спроб користувачів з різними ролями з різних організацій).

Перегляд і зміна даних профілю

Щоб переглянути дані свого профілю, виберіть Мій обліковий запис на панелі навігації ліворуч.

Щоб змінити свої налаштування, виберіть піктограму «Редагувати » в розділі «Налаштування » та виберіть домашню сторінку, яку ви хочете використовувати. У списку буде вказано різні ринкові ролі, до яких має доступ користувач, що ввійшов у обліковий запис.

Через API:

Використовуйте API POST /organizations/{organizationId}/users/{userId}/setMyDefaultMarketRole , щоб переключити роль користувача на ринку за замовчуванням. Заголовок авторизації повинен використовувати маркер доступу того ж користувача, який передано в параметрі userId URL. Користувач повинен мати певний доступ до нової ролі ринку, яка встановлена за замовчуванням.

Переглянути визначення ролей

Користувач із будь-якою роллю може переглядати різні визначення ролей.

Щоб переглянути всі визначення ролей через API:

Перейдіть до папки «Визначення ролей» і виберіть API «Отримати всі визначення ролей».
Викличте GET /roleDefinitions , встановивши заголовок авторизації з відповідним маркером доступу користувача (змінні з оточення Postman можуть бути використані для спроби користувачів з різними ролями з різних організацій).

Щоб переглянути визначення ролей за ідентифікатором:

Перейдіть до папки «Визначення ролей» і виберіть «Отримати визначення ролі за API ідентифікатора ».
Викличте GET /roleDefinitions/{{id}} , встановивши ідентифікатор визначення ролі в URL запиту та заголовок авторизації з відповідним токеном доступу користувачів (змінні з оточення Postman можуть використовуватися для спроби користувачів з різними ролями з різних організацій).

Перегляд користувачів і призначених ролей

Користувач із будь-якою роллю може переглядати користувачів організації разом із призначеними ними ролями.

Перейдіть на екран Доступ користувачів і перегляньте користувачів, які мають доступ.

Через API:

Перейдіть до папки Користувачі .
Дзвінок: Отримати всіх користувачів у моїй організації , встановивши заголовок авторизації з маркером доступу користувачів з відповідної організації (змінні з оточення Postman можуть використовуватися для спроби користувачів з різними ролями з різних організацій).
Перейдіть до папки Призначення ролей.
Дзвінок Отримати всі призначення ролей у моїй ролі ринку за замовчуванням, щоб отримати призначення ролей у ролі ринку за замовчуванням ідентифікатора абонента на основі параметра запиту resourceUri .

Керуйте елементами керування доступом до ресурсів між організаціями

Користувач із правами адміністратора може керувати доступом до активів у різних організаціях. Це може використовуватися в різних сценаріях, наприклад, якщо постачальник заздалегідь надав кредит покупцю, і він не хоче, щоб інші покупці переглядали кредит. Іншим прикладом є вставки, які мають використовуватися в межах одного ланцюжка створення вартості.

Для підтримки цих сценаріїв Служба екологічного кредитування (підготовча версія) має такі можливості:

Адміністратор може керувати, чи хоче він, щоб актив був видимим для всіх ролей на ринку чи ні. Наприклад, постачальник, який хоче використовувати кредити для вставок, може вирішити приховати видимість кредитів від усіх покупців. За замовчуванням актив буде видимий для всіх ролей на ринку, які адміністратор може перемикати.
Адміністратор може вирішувати, чи хоче він, щоб актив був видимим для всіх організацій, які займають ринкову роль, чи ні. Наприклад, постачальник може мати заздалегідь зобов’язані кредити покупцеві. Адміністратор може керувати видимістю таким чином, щоб кредити не були видимими для інших покупців, крім передбачуваного.

За замовчуванням такі активи, як екологічні проекти, модульні пільгові проекти та кредити, будуть видимі для всіх організацій, які адміністратор може перемкнути. Адміністратор може встановити політику міжорганізаційного доступу для цього на різних рівнях, від найнижчого до найвищого пріоритету, як показано нижче:

Організації: Політика міжорганізаційного доступу на рівні організації передбачає, що контроль доступу між організаціями застосовується до всіх активів в організаціях.
Екологічні проекти: Міжорганізаційна політика на рівні екологічних проектів має вищий пріоритет, ніж попередній шар. Він передбачає міжорганізаційний контроль доступу до конкретного екологічного проекту та всіх активів у його межах. Якщо на цьому рівні встановлено міжорганізаційну політику, то вона має пріоритет над будь-якою політикою, встановленою на рівні організації. Це може встановити користувач з доступом адміністратора на рівні екологічного проекту.
Модульні бенефітні проекти: Міжорганізаційна політика на рівні модульних пільгових проектів має вищий пріоритет, ніж попередні рівні. Він має на увазі міжорганізаційний контроль доступу до конкретного модульного бенефітного проекту та всіх активів у ньому. Якщо на цьому рівні встановлено міжорганізаційну політику, то вона має пріоритет над будь-якою політикою, встановленою на одному з вищезазначених рівнів. Це може встановити користувач із правами адміністратора, які мають право на виконання проекту з модульною вигодою.
Кредити: Міжорганізаційна політика на рівні кредитування має вищий пріоритет, ніж попередні рівні. Він має на увазі міжорганізаційний контроль доступу до конкретного кредиту. Якщо на цьому рівні встановлено міжорганізаційну політику, то вона має пріоритет над будь-якою політикою, встановленою на одному з вищезазначених рівнів. Це може встановити користувач із правами адміністратора, які мають право на виконання проекту з модульною вигодою.

Нотатка

Адміністратори можуть встановлювати міжорганізаційну політику для об’єктів, якими вони володіють. Постачальник і покупець - це дві ринкові ролі, які можуть встановлювати міжорганізаційну політику. Постачальник може встановити його на свої екологічні проекти, модульні пільгові проекти та кредити. Покупець може встановити його на власні кредити. При виклику API заголовок x-ms-marketRole вказує службі про контекст ролі ринку, в якому їх викликає користувач адміністратора.

Через UX:

Наразі, з UX, адміністратор організаційного рівня може встановлювати політику крос-організації на рівні організації.

Виберіть Доступ до організації на панелі навігації ліворуч.
Виберіть Редагувати для організації, яку потрібно змінити, і оновіть за потреби.

Через API:

Перейдіть до папки «Організації » в Postman і скористайтеся політикою міжорганізаційного доступу API Set на рівні організації, щоб встановити політику на рівні організації під роллю ринку за замовчуванням.
Перейдіть до папки створення екологічного проекту в Postman і використовуйте політику міжорганізаційного доступу API Set для екологічного проекту , щоб встановити політику на рівні конкретного екологічного проекту.
Перейдіть до папки створення екологічного проекту в Postman і скористайтеся політикою крос-організаційного доступу API Set на MBP , щоб встановити політику на рівні конкретного модульного проекту вигоди.
Перейдіть до папки «Кредити » в Postman і скористайтеся політикою міжорганізаційного доступу API Set для кредитування, щоб встановити політику на конкретному рівні кредитування.

Використовуйте групи для керування доступом

Адміністратор може створювати групи, керувати користувачами в групі та призначати групам ролі. Наразі ця функція підтримується лише через API.

Створіть групу користувачів та додайте до неї користувачів:
```
POST /organizations/{{organization_id}}/groups  
```
Отримайте всі групи користувачів в організації:
```
GET /organizations/{{organization_id}}/groups
```
Отримати групу користувачів можна за id:
```
GET /organizations/{{organization_id}}/groups/{{group_id}} 
```
Об’єднання користувачів у групу користувачів:
```
GET /organizations/{{organization_id}}/groups/{{group_id}}/users  
```
Додавання користувачів до групи користувачів:
```
POST /organizations/{{organization_id}}/groups/{{group_id}}/addUsers  
```
Щоб видалити користувача з групи користувачів:
```
DELETE /organizations/{{organization_id}}/groups/{{group_id}}/users/{{user_id}}  
```
Приєднання користувачів до групи користувачів:
```
POST /organizations/{{organization_id}}/groups/{{group_id}}/addNewUsers  
```
Створіть призначення ролей для групи користувачів:
```
POST /roleAssignments  
```
Видаліть призначення ролей групи користувачів:
```
DELETE /roleAssignments/{{roleAssignmentId}}  
```