Прежде всего мои извинения за поздний ответ.Вот мои комментарии.
ACL, RBAC, ABAC
Я изучаю различные типы моделей контроля доступа и узнал, что abac и rbac являются популярными.
Исторически управление доступом осуществлялось через списки управления доступом (ACL), затем управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC).Списки ACL стали громоздкими и сложными в управлении, поэтому NIST разработал RBAC в 1992 году (да, он такой старый).RBAC хорошо известен, зрел и встроен в большинство продуктов и приложений IAM.Например, пользовательский каталог (LDAP, AD ...) поддерживает назначения пользователей и ролей и предоставляет приложениям те роли, которые приложение затем может использовать для определения необходимости предоставления доступа.С RBAC более детальный доступ (например, доступ, основанный на отношениях, как в вашем случае, когда пользователь может видеть только свои собственные данные) невозможен, поэтому либо (а) разработчик приложения пишет собственный код для получения правильного доступа, либо (б) выиспользуйте ABAC.
Почему ABAC?
ABAC дает вам возможность определять детальный доступ на основе любого типа атрибута (не только роли и не только пользовательских атрибутов), используя политики для описаниячто может (или не может) случиться.ABAC иногда называют PBAC (управление доступом на основе политик).Вы ссылаетесь на XACML, который является языком, на котором реализуются политики ABAC.Вы также можете взглянуть на alfa ( Wikipedia ), более простой язык, который отображается непосредственно в XACML.
ABAC также определяет архитектуру с идеей точки принятия решения о политике(PDP), который обрабатывает ваши запросы авторизации в соответствии с политиками, с которыми он настроен.PDP (в вашем случае WSO2 Balana часть WSO2 IS) вызывается из точки реализации политики (PEP), такой как ваше приложение или что-то, находящееся перед вашим приложением (например, шлюз API или перехватчик в вашем случае WSO2 API Manager).
Ваш вариант использования
У меня есть базовый сценарий для одного из моих проектов, и я не мог понятья должен пойти с RBAC или ABAC.Очевидно, что RBAC является подмножеством ABAC, так что определенно я должен пойти на ABAC, но ABAC требуется некоторый опыт для написания политик в xacml.Мы используем WSO IS и APIM.
Я бы не сказал, что RBAC является подмножеством ABAC.Это действительно с точки зрения функциональности.Но это не одно против другого.ABAC расширит RBAC, добавив больше атрибутов, политик и вышеупомянутой архитектуры.
У меня есть роли администратора, владельца и члена на моем сервере идентификации (IS).
- Администратор может просматривать, удалять и обновлять пользователей.
- Владельцы могут просматривать и обновлять.
- Пользователи могут просматривать только.
Это здорово.То, что вы делаете, это определение ваших требований авторизации.Они будут отображаться непосредственно в ваши политики ALFA / XACML.
В настоящее время я использую HTTP-глаголы для достижения желаемых результатов, то есть владельцы не могут получить доступ к запросам DELETE, а участники не могут получить доступ к PUT & DELETE.
В ABAC мы также используем действия.Это могут быть обычные старые человеческие действия (просмотр, редактирование, удаление, утверждение ...), которые затем могут быть сопоставлены с глаголами HTTP.
Ваша задача
В приведенном ниже тексте я отметилжирным шрифтом то, что я считаю вашими дополнительными требованиями к авторизации.
У меня есть панель инструментов, на которой отображаются различные разделы, такие как топ-пользователи, биллинг, сервисы, топ-потребители и т. д.
Мне нужно заполнить панель навигации на основе роли пользователя и атрибутов с сервера, например, участники не должны иметь доступа к другим пользователям (Добавить, Список) в панели навигации .Элементы навигационной панели зависят от роли пользователя, поэтому мы можем управлять ими через RBAC?
Это будет выполняться с помощью политики ABAC.Смотри ниже
У нас есть план по добавлению ролей, таких как ops, маркетинг, поддержка и т. Д. Означает ли это, что нам нужно создать отдельную db-схему для поддержки прав доступа для каждой роли?
Нет!Вам не нужно создавать новые схемы БД, не говоря уже о том, чтобы поддерживать права доступа в пользовательских системах.Для этого используйте политики.
В панели управления мне нужно скрыть / показать кнопки просмотра, обновления и удаления в пользователях, службах и т. Д. Теперь участники могут видеть пользователей, но не имеют разрешения на обновление.или удалите их .Они не могут просматривать статистику, счета и другую личную информацию.
Владельцы могут видеть всех пользователей, связанных с их отделами / организацией , но Администратор может видеть всех пользователей для всех отделов / организаций .Здесь нам нужно использовать один и тот же API для всех потребителей, но API должен по-разному реагировать на разные роли.Роли могут быть 10 и 100, поэтому они не могут создавать разные API для каждой роли.Вопрос
Мы можем реализовать все эти сценарии через RBAC, но для управления панелью навигации и просмотра связанной реализации нам нужно добавить бизнес-логику на нашем сервере вместо использования WSO2-IS и WSO2-APIM.Есть ли способ управлять разрешениями на просмотр, такими как кнопки и секции скрытия / показа, и даже использовать один и тот же API, но он должен возвращать разные результаты для разных потребителей API.
Да, определенно.Это цель использования ABAC и политик.Учитывая, что вы используете WSO2 IS, посмотрите на Balana, PDP внутри этого продукта.Существуют и другие решения, например, AuthZForce (с открытым исходным кодом) или Axiomatics (там, где я работаю)
Решение
Вот пример политики, написанной на языке ALFA, и перевод XACML ниже
namespace haris {
/**
* User Records
*/
policyset users {
target clause axiomatics.objectType == "user record"
apply firstApplicable
/**
* View user record
*/
policy viewUser {
target clause axiomatics.actionId == "view" // This can be the HTTP verb
apply firstApplicable
/**
* Administrators can view all users
*/
rule administrator{
target clause axiomatics.user.role == "administrator"
permit
}
/**
* Owners can view users in their department
*/
rule owners{
target clause axiomatics.user.role == "owner"
permit
condition axiomatics.user.department == axiomatics.record.department
}
/**
* Members can view their own user record only
*/
rule member{
permit
condition axiomatics.user.username == axiomatics.record.owner
}
}
/**
* Update user
*/
policy updateUser {
target clause axiomatics.actionId == "update" // This can be the HTTP verb
apply firstApplicable
/**
* Administrator can update any user
*/
rule administrator{
target clause axiomatics.user.role == "administrator"
permit
}
/**
* Owner can update any user
*/
rule owner{
target clause axiomatics.user.role == "owner"
permit
// TODO: determine what an owner can update
}
}
/**
* Delete user
*/
policy deleteUser {
target clause axiomatics.actionId == "delete" // This can be the HTTP verb
apply firstApplicable
/**
* Administrator can delete any user
*/
rule administrator{
target clause axiomatics.user.role == "administrator"
permit
}
}
}
}
И версия XML
<?xml version="1.0" encoding="UTF-8"?><!--This file was generated by the
ALFA Plugin for Eclipse from Axiomatics AB (http://www.axiomatics.com). --><!--Any modification to this file will
be lost upon recompilation of the source ALFA file -->
<xacml3:PolicySet
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable"
PolicySetId="http://axiomatics.com/alfa/identifier/haris.users"
Version="1.0"
xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<xacml3:Description>User Records</xacml3:Description>
<xacml3:PolicySetDefaults>
<xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116
</xacml3:XPathVersion>
</xacml3:PolicySetDefaults>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">user record</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.objectType"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
<xacml3:Policy
PolicyId="http://axiomatics.com/alfa/identifier/haris.users.viewUser"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
Version="1.0">
<xacml3:Description>View user record</xacml3:Description>
<xacml3:PolicyDefaults>
<xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116
</xacml3:XPathVersion>
</xacml3:PolicyDefaults>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">view</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.actionId"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
<xacml3:Rule Effect="Permit"
RuleId="haris.users.viewUser.administrator">
<xacml3:Description>Administrators can view all users
</xacml3:Description>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">administrator</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.user.role"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
</xacml3:Rule>
<xacml3:Rule Effect="Permit"
RuleId="haris.users.viewUser.owners">
<xacml3:Description>Owners can view users in their department
</xacml3:Description>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">owner</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.user.role"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
<xacml3:Condition>
<xacml3:Apply
FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of-any">
<xacml3:Function
FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />
<xacml3:AttributeDesignator
AttributeId="axiomatics.user.department"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
<xacml3:AttributeDesignator
AttributeId="axiomatics.record.department"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Apply>
</xacml3:Condition>
</xacml3:Rule>
<xacml3:Rule Effect="Permit"
RuleId="haris.users.viewUser.member">
<xacml3:Description>Members can view their own user record only
</xacml3:Description>
<xacml3:Target />
<xacml3:Condition>
<xacml3:Apply
FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of-any">
<xacml3:Function
FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />
<xacml3:AttributeDesignator
AttributeId="axiomatics.user.username"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
<xacml3:AttributeDesignator
AttributeId="axiomatics.record.owner"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Apply>
</xacml3:Condition>
</xacml3:Rule>
</xacml3:Policy>
<xacml3:Policy
PolicyId="http://axiomatics.com/alfa/identifier/haris.users.updateUser"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
Version="1.0">
<xacml3:Description>Update user</xacml3:Description>
<xacml3:PolicyDefaults>
<xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116
</xacml3:XPathVersion>
</xacml3:PolicyDefaults>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">update</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.actionId"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
<xacml3:Rule Effect="Permit"
RuleId="haris.users.updateUser.administrator">
<xacml3:Description>Administrator can update any user
</xacml3:Description>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">administrator</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.user.role"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
</xacml3:Rule>
<xacml3:Rule Effect="Permit"
RuleId="haris.users.updateUser.owner">
<xacml3:Description>Owner can update any user</xacml3:Description>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">owner</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.user.role"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
</xacml3:Rule>
</xacml3:Policy>
<xacml3:Policy
PolicyId="http://axiomatics.com/alfa/identifier/haris.users.deleteUser"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
Version="1.0">
<xacml3:Description>Delete user</xacml3:Description>
<xacml3:PolicyDefaults>
<xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116
</xacml3:XPathVersion>
</xacml3:PolicyDefaults>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">delete</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.actionId"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
<xacml3:Rule Effect="Permit"
RuleId="haris.users.deleteUser.administrator">
<xacml3:Description>Administrator can delete any user
</xacml3:Description>
<xacml3:Target>
<xacml3:AnyOf>
<xacml3:AllOf>
<xacml3:Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<xacml3:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">administrator</xacml3:AttributeValue>
<xacml3:AttributeDesignator
AttributeId="axiomatics.user.role"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="false" />
</xacml3:Match>
</xacml3:AllOf>
</xacml3:AnyOf>
</xacml3:Target>
</xacml3:Rule>
</xacml3:Policy>
</xacml3:PolicySet>
Применение политик
Как я буду возвращать разные данные для одного API, но для разных ролей / пользователей.
Предположим, у вас есть API, например /api/profiles/{profileID}.Вы можете использовать API двумя способами:
- GET / api / profile возвращает все профили, на которые пользователь имеет право,
- GET / api / profile / 123 возвращает профиль123, если пользователь имеет право или HTTP 403 в противном случае (или 404 - можно утверждать, что вы не хотите даже сообщать, что указанный профиль существует).
Для этого вам необходимо реализоватьпункт реализации политики (PEP).Это может быть API-менеджер WSO2.PEP отвечает за
- разбор входящего вызова API (GET / api / profile / 123)
- , преобразующий его в запрос авторизации, например, может ли Алиса просматривать профиль 123?
- отправка запроса в PDP
- обработка ответа, полученного обратно от PDP, и, в частности, извлечение решения (например, разрешения).
Если решение является разрешением, товызов перенаправляется на ваш бэкэнд API.Если это не так, вы можете вернуть HTTP 403/404, как обсуждалось.
Если это 403, то вызов переходит на бэкэнд, и в конечном итоге ответ поворачивается с вашего бэкенда и проходит через PEP, гдеон может снова вызвать PDP, например, чтобы отредактировать данные.
Нужно ли включать в мой бизнес-логику, такую как получение элементов навигационной панели, получение статистики использования API, полный доступ к данным дляадминистраторы и организация / отдел для владельцев и ограниченные данные для членов.Как выполнить эти основные операции?
Нет, вы не делаете.При создании меню или элементов навигации вы также можете вызвать PDP и спросить, может ли данный пользователь получить доступ к заданному набору функций, например, «Может ли Алиса просмотреть элемент панели навигации № 123?».Вам нужна минимальная бизнес-логика для вызова PDP.