Идентификация

У каждого пользователя может быть несколько учетных записей у различных поставщиков удостоверений, и StarVault поддерживает многих из этих поставщиков для аутентификации. StarVault Identity может привязывать аутентификацию с помощью различных методов аутентификации к единому представлению. Это представление объединенного идентификатора называется сущностью. Соответствующие учетные записи у поставщиков аутентификации могут быть сопоставлены как псевдонимы. Таким образом, каждая сущность состоит из нуля или более псевдонимов. Сущность не может иметь более одного псевдонима для определенного сервера аутентификации.

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

Когда клиент проходит аутентификацию с помощью любого сервера с учетными данными (кроме сервера с токенами), StarVault создает новую сущность. К ней присваивается новый псевдоним, если соответствующая сущность еще не существует. Идентификатор сущности будет привязан к аутентифицированному токену. Когда используются такие токены, их идентификаторы сущностей регистрируются в журнале аудита, что позволяет отслеживать действия, выполняемые конкретными пользователями.

Сущности в StarVault автоматически не извлекают идентификационную информацию из любого места. Операторы должны управлять ею в явном виде. Таким образом, это позволяет гибко управлять количеством сущностей, синхронизируемых со StarVault. В некотором смысле, StarVault будет служить кэшем идентификационных данных, а не источником идентификационных данных.

Политики хранилища могут быть назначены сущностям, которые будут предоставлять дополнительные разрешения для токена поверх существующих политик для токена. Если токен, представленный в запросе API, содержит идентификатор сущности и если для неё установлен набор политик, то токен также будет способен выполнять действия, разрешенные политиками для сущности.

Это изменение схемы с точки зрения того, когда будут оцениваться политики токена. До появления идентификации, имена политик в токене были неизменяемыми (но не содержимое этих политик). С политиками сущностей, наряду с неизменяемым набором имен политик в токене, оценка политик, применимых к токену, через его идентификатор будет выполняться во время запроса. Это добавляет гибкость в управлении поведением уже выпущенных токенов.

Важно отметить, что политики для сущности являются лишь средством предоставления дополнительных возможностей, а не заменой политик для токена. Чтобы узнать полный набор возможностей токена с соответствующим идентификатором сущности, следует учитывать политики для токена.

StarVault поддерживает несколько серверных систем аутентификации. Также позволяет использовать один и тот же тип серверной системы аутентификации на разных путях подключения. Псевдоним пользователя будет уникальным в пределах подключенных серверных систем. Но хранилище идентификаторов должно однозначно различать конфликтующие имена псевдонимов для разных подключений поставщиков идентификационных данных. Следовательно, имя псевдонима в сочетании с атрибутами для установки серверной части аутентификации служат уникальным идентификатором псевдонима.

В таблице ниже показано, какую информацию использует каждый из поддерживаемых методов аутентификации для формирования псевдонима. Это идентифицирующая информация, которая используется для сопоставления или создания сущности. Если никакие сущности явно не созданы или не объединены, то для каждого объекта в правой части таблицы будет неявно создана одна сущность, когда он используется для аутентификации в определенной точке подключения auth.

Все методы аутентификации будут генерировать сущность по умолчанию при выдаче токена, за исключением хранилища токенов. Это применимо как для подключений, которые совместно используются кластерами, так и для подключений локальной аутентификации кластера (с использованием local=true), когда используется репликация хранилища. Если целью обозначения метода аутентификации как local было соответствие руководящим принципам GDPR, то необходимо соблюдать осторожность, чтобы не указывать данные, относящиеся к локальному подключению для аутентификации, или псевдонимы для локального подключения для аутентификации в метаданных связанной сущности.

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

Обратите внимание, что токены, созданные с использованием серверной части проверки подлинности токенов, обычно не содержат никакой связанной идентификационной информации. Существующая или новая неявная сущность может быть назначена с помощью параметра entity_alias при создании токена с использованием роли токена с настроенным списком allowed_entity_aliases.

Если токен, используемый для выполнения вызовов API, имеет связанный идентификатор сущности, он также будет записан в журнал аудита. Это позволяет отслеживать действия, выполненные конкретными пользователями.

StarVault identity поддерживает группы. Группа может содержать несколько сущностей в качестве своих членов. У группы также могут быть подгруппы. Политики, установленные для группы, предоставляются всем членам группы. Во время запроса, когда идентификатор сущности токена проверяется на предмет политик, к которым у него есть доступ, политики, унаследованные из-за членства в группах, предоставляются вместе с политиками для самой сущности.

Сущности могут быть прямыми членами групп, и в этом случае они наследуют политики групп, к которым они принадлежат. Сущности также могут быть косвенными членами групп.

По умолчанию группы, созданные в identity store, называются внутренними группами. Управление членством в этих группах должно выполняться вручную.

Группа также может быть создана как внешняя группа. В этом случае членство сущности в группе управляется полуавтоматически. Внешняя группа служит для сопоставления с группой, которая находится за пределами хранилища идентификаторов. Внешние группы могут иметь один (и только один) псевдоним. Этот псевдоним должен соответствовать понятию группы, которая находится за пределами хранилища идентификаторов.

Для получения информации о механизме идентификации секретов обратитесь к механизму идентификации секретов.