Все ваши подходы основаны на системе, основанной на разрешениях, где вы получили бы разрешения при входе в систему.Их иногда называют правами рождения, поскольку они обычно предоставляются при создании пользователя или при изменении их наборов разрешений.Типичный способ переноса прав на рождение - это иметь их в виде областей / утверждений внутри токена идентификации (например, OAUth 2.0), который вы передаете от сервиса к сервису.
Вы также можете получить от своих приложений дополнительные разрешения /роли / права доступа из внутреннего хранилища (например, базы данных) на основе идентификатора пользователя, чтобы вы знали, что может или не может делать ваш пользователь.
Пока это, по сути, управление доступом на основе ролей / на основе разрешенийконтроль доступа.
Основная проблема в этом подходе - взрыв ролей / взрыв разрешений, а также раздувание токенов (слишком много разрешений в токене) и административные трудности - вам необходимо постоянно назначать роли и разрешения пользователям.,Вы должны депровизировать.Это превращается в кошмар управления и может привести к неправильным установкам разрешений для пользователей.Затем вам нужно подумать об идентификации и управлении доступом, а также о повторной сертификации.Тяжелый.
Какая альтернатива?
Вам определенно нужны некоторые роли - да - но они должны быть сведены к минимуму - по существу, бизнес-роли, которые вам нужны в ваших приложениях, например, врач, медсестра, немедицинский персонал, а не doctor_hospital1_unitA.
Затем вы должны выразить свое разрешение в виде простых английских политик, используя любое количество атрибутов - не только атрибуты пользователя, но и контекстную информацию (время, местоположение), информацию о ресурсах(какой тип объекта, кому он принадлежит, где он? Насколько он чувствителен?) и информацию о действиях (просмотр, редактирование, удаление ...).
Примеры политик
- Врач может просматривать медицинскую карту, если она назначена пациенту, которому медицинская карта принадлежит
- Медсестра может просматривать медицинскую карту, еслимедицинская карта находится в той же единице, что и медсестра
- Немедицинский персонал может просматривать финансовый раздел медицинской карты, но не медицинский раздел.
Управление доступом на основе атрибутов
Следующий подход называется управлением доступом на основе атрибутов ( abac ).В ABAC вы четко отделяете свое приложение от процесса авторизации.Авторизация выражается в виде политик, а не кода, который облегчает:
Как реализовать?
У вас есть несколько вариантов реализации ABAC (от открытого исходного кода до коммерческого).Вы можете перейти по пути XACML ( xacml ), пути ALFA alfa или другим.Все они имеют схожие архитектуры с:
- понятием точки принятия решения о политике (PDP): службой, которая оценивает запросы на авторизацию в соответствии с набором политик, которые вы определили, и вырабатывает решения (Permit / Deny), которыеможет быть дополнено дополнительной информацией, например, для выполнения двухфакторной аутентификации.
- понятие точки применения политики (PEP): перехватчик, который находится перед или внутри вашего API и отправит запрос авторизацииPDP.
Я написал об архитектуре более подробно в этом SO сообщении .
Пример ALFA
В ALFA,Пример политики будет выглядеть так:
policyset viewMedicalRecord{
target clause object == "medical record" and action == "view"
apply firstApplicable
policy allowDoctors{
target clause role == "doctor"
apply firstApplicable
rule allowAssignedPatient{
permit
condition patient.assignedDoctor == user.name
}
}
}