На этой странице представлена информация об идентичности (identity), а также обзор связанных терминов и понятий. Концепция идентичности направлена на учёт клиентов с доступом в Stronghold. Для этого Stronghold предоставляет решение для управления идентичностями с помощью механизма секретов Identity. За дополнительной информацией о работе механизма секретов Identity обратитесь в соответствующий раздел документации.
Термины
Термины «идентичность» (identity) и «сущность» (entity) связаны, но обозначают разные концепции.
Идентичность
Идентичность — это более широкая концепция, предполагающая управление идентификацией пользователей и приложений. Идентичность в Stronghold позволяет централизованно управлять связанными аккаунтами и методами аутентификации. Система идентичности позволяет объединить несколько методов аутентификации для одного пользователя или приложения, обеспечивая гибкость и удобство при использовании различных способов аутентификации. Управление идентичностями также неразрывно связано с назначением политик и контролем доступа на основе идентичности.
Сущность
Сущность является конкретной реализацией концепции идентичности. Это единичное представление пользователя или приложения, для которого могут быть задействованы различные методы аутентификации. У каждой сущности может быть несколько псевдонимов, которые связывают её с разными способами аутентификации. Сущность позволяет объединять все данные об идентичности, аутентификациях и связанных политиках в одном месте, обеспечивая целостное управление доступами.
Сущности и псевдонимы
Каждый пользователь может иметь несколько учетных записей у различных поставщиков идентификационных данных, и Stronghold поддерживает множество таких поставщиков для аутентификации. Stronghold Identity может связать параметры аутентификации различных методов аутентификации в единое представление. Такое представление консолидированной идентификации называется сущностью (entity), а соответствующие учетные записи у провайдеров аутентификации могут быть отображены как псевдонимы (aliases). По сути, каждая сущность содержит от нуля до множества псевдонимов. У сущности не может быть более одного псевдонима для определенного бэкенда аутентификации.
Например, пользователь, имеющий учетные записи Userpass и LDAP, может быть сопоставлен с одной сущностью в Stronghold с помощью двух псевдонимов: одного с типом Userpass и другого с типом LDAP.
Однако если оба псевдонима созданы по одному и тому же пути аутентификации, например на Userpass, оба псевдонима не могут быть сопоставлены с одной и той же сущностью. У псевдонимов может быть один и тот же тип аутентификации, при условии что используются разные идентификаторы бэкенда аутентификации — и всё равно в таком случае псевдонимы будут связаны с одной и той же сущностью. Приведенные ниже схемы иллюстрируют как допустимые, так и недопустимые сценарии.
Когда клиент проходит аутентификацию через любой бэкенд (кроме бэкенда Token), Stronghold создаёт новую сущность. Он прикрепляет к сущности новый псевдоним, если соответствующая сущность еще не существует. Идентификатор сущности будет привязан к токену аутентификации. При использовании таких токенов их идентификаторы сущностей регистрируются в журнале аудита, что позволяет отследить действия, совершённые конкретными пользователями.
Управление сущностями
Сущности в Stronghold не извлекают информацию об идентификации откуда-либо автоматически. Она должна явно управляться операторами. Таким образом, обеспечивается гибкость в плане административного управления количеством сущностей, которые будут синхронизированы со Stronghold. В некотором смысле Stronghold служит кэшем идентификационных данных, а не их источником.
Политики сущностей
Сущностям могут быть назначены политики, которые обеспечат токен дополнительными разрешениями, дополняющими текущие политики токена. Если токен, использованный в API-запросе, содержит идентификатор сущности, и у этой сущности есть назначенные политики, такой токен сможет выполнять действия, разрешенные этими политиками.
Это изменение парадигмы в отношении того, когда происходит оценка политик токена. До появления системы идентичности названия политик токена были неизменяемыми (при этом содержание самих политик могло меняться). Однако с введением политик для сущностей, помимо неизменяемого набора названий политик токена, оценка политик, применяемых к токену через его идентичность, будет осуществляться в момент выполнения запроса. Это также значительно увеличивает гибкость управления поведением уже выпущенных токенов.
Важно отметить, что политики сущностей являются лишь средством предоставления дополнительных возможностей, а не заменой политик токена. Чтобы знать полный набор возможностей токена со связанным с ним идентификатором сущности, необходимо учитывать политики токена.
Будьте осторожны при предоставлении разрешений к эндпоинтам идентификации, доступным для изменения. Если пользователь может изменять сущность, он может предоставить ей дополнительные привилегии с помощью политик. Если пользователь может изменить псевдоним, с которым он входит в систему, он может привязать его к сущности с более высокими привилегиями. Если пользователь может изменять членство в группе, он может добавить свою сущность в группу с более высокими привилегиями.
Псевдонимы, привязанные к точкам монтирования
Stronghold поддерживает несколько бэкендов аутентификации, а также позволяет использовать один и тот же тип бэкенда аутентификации на разных путях монтирования. Псевдоним пользователя будет уникальным в пределах монтирования бэкенда. Но хранилищу идентификационных данных необходимо однозначно различать конфликтующие псевдонимы в разных монтированиях этих поставщиков идентификационных данных. Таким образом, имя псевдонима в сочетании с идентификатором бэкенда аутентификации служит уникальным идентификатором псевдонима.
В таблице ниже показано, какую информацию использует каждый из поддерживаемых методов аутентификации для формирования имени псевдонима. Это идентификационная информация, которая используется для сопоставления или создания сущности. Если сущности не создаются или не объединяются явно, то для каждого объекта в правой части таблицы будет неявно создана одна сущность, когда она будет использоваться для аутентификации на определенной точке монтирования аутентификации.
| Метод аутентификации | Имя, сообщаемое методом аутентификации |
|---|---|
| AppRole | Role ID |
| JWT/OIDC | Настраивается через user_claim на одно из представленных claim (значение по умолчанию отсутствует) |
| Kerberos | Имя пользователя (Username) |
| Kubernetes | Настраивается через alias_name_source: UID сервисного аккаунта (по умолчанию) или Имя сервисного аккаунта |
| LDAP | Имя пользователя (Username) |
| TLS Certificate | Subject CommonName |
| Token | entity_alias (если присутствует) |
| Username (userpass) | Имя пользователя (Username) |
Неявные сущности
Операторы могут заранее создать сущности для всех пользователей бэкенда аутентификации и назначить им политики, чтобы при входе пользователей в систему уже были назначены необходимые возможности токенов через сущности. Если этого не сделать, то при успешном входе пользователя через любой из бэкендов аутентификации Stronghold создаст новую сущность и назначит псевдоним пользователю, прошедшему аутентификацию.
Обратите внимание, что токены, созданные с помощью бэкенда аутентификации токенов, обычно не содержат никакой связанной информации об идентификации. Существующая или новая неявная сущность может быть назначена с помощью параметра entity_alias при создании токена с использованием роли токена с настроенным списком allowed_entity_aliases.
Аудит идентичностей
Если у токена, используемого для API-запросов, есть связанный с ним идентификатор сущности, он также будет занесен в журнал аудита. Таким образом, остается история действий, совершенных конкретными пользователями.
Группы сущностей
В Stronghold Identity есть поддержка групп. Группа может содержать несколько сущностей. Группа также может иметь подгруппы. Политики, установленные для группы, предоставляются всем её членам. Во время выполнения запроса, когда идентификатор сущности токена оценивается на предмет политик, к которым у него есть доступ, политики, унаследованные по причине членства в группе, предоставляются вместе с политиками самой сущности.
Иерархия групп
Сущности могут быть прямыми членами групп — в этом случае они наследуют политики групп, в которых состоят. Сущности также могут быть косвенными членами групп. Например, если у группы «А» есть подгруппа в виде группы «В», члены группы «В» выступают косвенными членами группы «А». Следовательно, у членов группы «B» будет доступ к политикам как группы «A», так и группы «B».
Внешние и внутренние группы
По умолчанию группы, созданные в хранилище идентификационных данных, называются внутренними группами. Управление членством в этих группах должно осуществляться вручную. Группа также может быть создана как внешняя. В этом случае управление членством сущностей в группе осуществляется полуавтоматически. Внешняя группа выступает средством сопоставления с группой, которая находится вне хранилища идентификационных данных. У внешних групп может быть только один псевдоним. Этот псевдоним должен соответствовать группе, находящейся вне хранилища идентификационных данных.
Для примера рассмотрим группы в LDAP или DEX. Имя пользователя в LDAP, принадлежащее группе в LDAP, может получить свой идентификатор сущности, добавленный как член группы в Stronghold автоматически во время входа в систему и обновления токена. Это работает только в том случае, если группа в Stronghold является внешней группой и у неё есть псевдоним, сопоставленный с группой в LDAP. Если происходит удаление пользователя из группы в LDAP, это изменение отразится в Stronghold только во время следующей операции по аутентификации или продлению.
За дополнительной информацией о работе механизма секретов Identity обратитесь в соответствующий раздел документации.