Divisionz.Scaffold.WebApi.AccountService 1.0.0-rc814

Divisionz.Scaffold.WebApi.AccountService

Account Service формирует JWT токен пользователя соотвествующий rfc7519. Для формирования подписи используется асимметричное шифрование RSA с алгоритмом RS512. Account Service может аутентифицировать пользователя следующим списком возможностей:

• Пара логин, пароль. Это внутренний пользователи сервиса, которые может создавать администратор. Пароли, пользователи при этом хранятся в БД
• LDAP аутентификация. Производится при помощи вызова метода Bind протокола LDAP. Логин и пароль пользователя при этом передаётся на сервер.
• Windows SSO аутентификация. В этом случае используется схема Negotiate, котороя позволяет выбрать между клиенту выбрать между NTLM и Kerberos аутентификацией. В этом случае логин и пароль не передаётся в сторону AccountService. Адрес аккант сервиса должен быть в списке доверенных узлов корпоративной сети, в "Свойстве обозревателя". Для этой зоны должна быть включена опция "автоматическая передача данных пользователя".

В полезной нагрузке JWT токена присутствует claim с типом 'http://schemas.divisionz.ru/api/identity/claims/permissions' значением которого являются перечисленные через запятую разрешения. Например "CreateTask,DeleteTask".

Многие методы api других сервисов настроены на проверку наличия отдельных разрешений. При этом, по умолчанию, во время запуска сервиса происходит синхронизация пермишнов относящихся к этому сервису, что позволяет держать набор разрешений всегда корректным.

Для того чтобы AccountService выдал все необходимые разрешения пользователям необходимо создать следующие объекты:

• Набор разрешений (PermissionSet) и с помощью PermissionSetPermissions наполнить его разрешениями. Это просто удобная группировка разрешений.
• Создать Роли (Roles) и добавить к каждой роле набор разрешений (RolePermissionSet)
• Создать Группы (Groups) и к каждой группе назначить Роль с помощью GroupRole

Т.о. алгоритм формирования пермишнов выглядит следующим образом:

1. Определяются группы пользователя по следующим алгоритмам
   1. Для внутренних пользователей получаем группы, аналогично тому как это происходит в UserGroups
   2. Для внешинх пользователей аутентифицированных с помощью LDAP или Winodows SSO аутентификации отправляется серия запросов по протоколу LDAP в настроенные сервера
2. По полученным группам в предыдущем пункте определяются роли, аналогично тому, как это происходит в ендпойнте GroupRole. Отдельно стоит обратить внимание на то, что для внешних пользователей необходимо обеспечить наличие таких же групп в самом AccountService
3. По ролям определяются наборы разрешений
4. По наборам разрешений уже можно получить сами разрешения