Этот документ содержит информацию о Identity, а также обзор различных терминов и концепций. Идея Identity состоит в том, чтобы обслуживать клиентов, которые получили доступ в Stronghold. Таким образом, Stronghold предоставляет решение для управления идентификацией с помощью механизма Identity secrets engine. Для получения дополнительной информации о механизме секретов Identity и о том, как он используется, обратитесь к документации Identity Secrets Engine.
Термины
Термины “Identity” и “Entity” связаны, но они обозначают разные концепции
Identity (Идентичность)
Это более широкая концепция, предполагающая управление идентификацией пользователей и приложений. Identity в позволяет централизованно управлять связанными аккаунтами и методами аутентификации. Система Identity позволяет объединить несколько методов аутентификации для одного пользователя или приложения, обеспечивая гибкость и удобство при использовании различных способов входа. Управление идентичностями также неразрывно связано с назначением политик и контролем доступа на основе идентичности.
Entity (Сущность)
Entity является конкретной реализацией концепции Identity. Это единичное представление пользователя или приложения, для которого могут быть задействованы различные методы аутентификации. У каждой Entity может быть несколько алиасов, которые связывают эту сущность с разными способами аутентификации. Entity позволяет объединять все данные о идентичности, аутентификациях и связанных политик в одном месте, обеспечивая целостное управление доступами.
Сущности и псевдонимы
Каждый пользователь может иметь несколько учетных записей у различных поставщиков идентификационных данных, и Stronghold поддерживает множество таких поставщиков для аутентификации. Stronghold Identity может связать аутентификацию от различных методов аутентификации в единое представление. Такое представление консолидированной идентификации называется Entity (сущность), а соответствующие учетные записи у провайдеров аутентификации могут быть отображены как Aliases (псевдонимы). По сути, каждая сущность состоит из нуля или более псевдонимов. Сущность не может иметь более одного псевдонима для определенного бэкенда аутентификации.
Например, пользователь, имеющий учетные записи Userpass и LDAP, может быть сопоставлен с одной сущностью в Stronghold с помощью двух псевдонимов, одного типа Userpass и одного типа LDAP.
Однако если оба псевдонима созданы на одном auth path, например на Userpass, оба псевдонима не могут быть сопоставлены с одной и той же сущностью. Псевдонимы могут иметь один и тот же тип аутентификации, если используются разные аутентификации, и все равно будут связаны с одной и той же сущностью. Приведенные ниже диаграммы иллюстрируют как допустимые, так и недопустимые сценарии.
Когда клиент проходит аутентификацию через любой бэкенд (кроме бэкенда Token), Stronghold создает новую сущность. Он прикрепляет к ней новый псевдоним, если соответствующая сущность еще не существует. Идентификатор сущности будет привязан к аутентифицированному токену. При использовании таких токенов их идентификаторы сущностей регистрируются в журнале аудита, что позволяет отследить действия, совершенные конкретными пользователями.
Управление сущностями
Сущности в Stronghold извлекают информацию об идентификации откуда-либо не автоматически. Она должна явно управляться операторами. Таким образом, обеспечивается гибкость в плане административного управления количеством сущностей, которые будут синхронизированы со Stronghold. В некотором смысле Stronghold будет служить кэшем идентификационных данных, а не источником идентификационных данных.
Политики для сущностей
Сущностям могут быть назначены политики, которые обеспечат токен дополнительными разрешениями, дополняющими текущие политики токена. Если токен, использованный в API-запросе, связан с идентификатором сущности, и у этой сущности есть назначенные политики, то токен сможет выполнять действия, разрешенные этими политиками.
Это изменение парадигмы в отношении того, когда происходит оценка политик токена. До появления системы идентификации названия политик на токене были неизменяемыми (при этом содержание самих политик могло меняться). Однако с введением политик для сущностей, помимо неизменяемого набора названий политик на токене, оценка политик, применяемых к токену через его идентичность, будет осуществляться в момент выполнения запроса. Это также значительно увеличивает гибкость управления поведением уже выданных токенов.
Важно отметить, что политики на сущности являются лишь средством предоставления дополнительных возможностей, а не заменой политик на токене. Чтобы знать полный набор возможностей токена со связанным с ним идентификатором сущности, необходимо учитывать политики токена.
Будьте осторожны при предоставлении разрешений к эдпоинтам идентификации, доступным для изменения. Если пользователь может изменять сущность, он может предоставить ей дополнительные привилегии с помощью политик. Если пользователь может изменить псевдоним, с которым он может войти в систему, он может привязать его к сущности с более высокими привилегиями. Если пользователь может изменять членство в группе, он может добавить свою сущность в группу с более высокими привилегиями.
Псевдонимы, привязанные к точкам монтирования
Stronghold поддерживает несколько бэкендов аутентификации, а также позволяет использовать один и тот же тип бэкенда аутентификации на разных путях монтирования. Псевдоним пользователя будет уникальным в пределах монтирования бэкенда. Но хранилищу идентификационных данных необходимо однозначно различать конфликтующие псевдонимы в разных монтированиях этих поставщиков идентификационных данных. Таким образом, имя псевдонима в сочетании с аксессором монтирования бэкенда аутентификации служит уникальным идентификатором псевдонима.
В таблице ниже показано, какую информацию использует каждый из поддерживаемых методов аутентификации для формирования имени псевдонима. Это идентификационная информация, которая используется для сопоставления или создания сущности. Если сущности не создаются или не объединяются явно, то для каждого объекта в правой части таблицы будет неявно создана одна entity, когда она будет использоваться для аутентификации на определенной точке монтирования auth.
| Метод аутентификаии | Name reported by auth method |
|---|---|
| AppRole | Role ID |
| JWT/OIDC | Настраивается через user_claim на одно из представленных claim (нет значения по умолчанию) |
| Kerberos | Имя польльзователя (Username) |
| Kubernetes | Настраивается через alias_name_source: Service account UID (умолчение) или Service account name |
| LDAP | Имя польльзователя (Username) |
| TLS Certificate | Subject CommonName |
| Token | entity_alias, если присутствует |
| Username (userpass) | Имя польльзователя (Username) |
Неявные сущности
Операторы могут заранее создать сущности для всех пользователей auth mount и назначить им политики, чтобы при входе пользователей в систему нужные возможности токенов через сущности уже были назначены. Но если этого не сделать, то при успешном входе пользователя с любого из бэкендов аутентификации Stronghold создаст новую сущность и назначит псевдоним.
Обратите внимание, что токены, созданные с помощью бэкенда аутентификации токенов, обычно не содержат никакой связанной с ними информации об идентификации. Существующая или новая неявная сущность может быть назначена с помощью параметра entity_alias при создании токена с использованием роли токена с настроенным списком allowed_entity_aliases.
Аудит сущностей
Если токен, используемый для выполнения вызовов API, имеет связанный с ним идентификатор сущности, он также будет занесен в журнал аудита. Таким образом, остается след действий, совершенных конкретными пользователями.
Группы сущностей
В Stronghold identity есть поддержка групп. Группа может содержать несколько сущностей в качестве своих членов. Группа также может иметь подгруппы. Политики, установленные для группы, предоставляются всем ее членам. Во время запроса, когда идентификатор сущности токена оценивается на предмет политик, к которым он имеет доступ, политики, унаследованные от членства в группе, предоставляются вместе с политиками самой сущности.
Иерархия групп
Объекты могут быть прямыми членами групп, в этом случае они наследуют политики групп, в которых состоят. Сущности также могут быть косвенными членами групп. Например, если группа А имеет в качестве подгруппы группу В, то члены группы В являются косвенными членами группы А. Следовательно, члены группы B будут иметь доступ к политикам как группы A, так и группы B.
Внешние и внутренние группы
По умолчанию группы, созданные в хранилище идентификационных данных, называются внутренними группами. Управление членством в этих группах должно осуществляться вручную. Группа также может быть создана как внешняя. В этом случае управление членством сущности в группе осуществляется полуавтоматически. Внешняя группа служит для сопоставления с группой, которая находится вне хранилища идентификационных данных. У внешних групп может быть один (и только один) псевдоним. Этот псевдоним должен соответствовать понятию группы, находящейся вне хранилища идентификационных данных.
Например, группы в LDAP или DEX. Имя пользователя в LDAP, принадлежащее группе в LDAP, может получить свой идентификатор сущности, добавленный как член группы в Stronghold автоматически во время входа в систему и обновления токена. Это работает только в том случае, если группа в Stronghold является внешней группой и имеет псевдоним, сопоставленный с группой в LDAP. Если пользователь удален из группы в LDAP, это изменение будет отражено в Stronghold только при последующем входе или обновлении.
Информацию о Identity Secrets Engine см. в разделе Identity Secrets Engine.