Обзор архитектуры Проверенных учетных данных Microsoft Entra
Важно спланировать решение проверяемого удостоверения, чтобы помимо возможности выдачи и проверки удостоверений вы имели полное представление о влиянии вашего решения на архитектуру и бизнес. Если вы еще не ознакомились с общими сведениями о Проверенных учетных данных Microsoft Entra и разделом Часто задаваемые вопросы, сделайте это, а затем выполните инструкции из руководства по началу работы.
В этом обзоре архитектуры описываются возможности и компоненты службы Проверенные учетные данные Microsoft Entra. Более подробные сведения об их выдаче и проверке см. в статьях
Подходы к удостоверениям
В настоящее время для предоставления учетных данных сотрудников в большинстве организаций используются централизованные системы идентификации. Там также используют различные методы для переноса клиентов, партнеров, поставщиков и проверяющих сторон в границы доверия организации. Эти методы включают федерацию, создание гостевых учетных записей и управление ими с такими системами, как Microsoft Entra B2B, и создание явных доверий с проверяющими сторонами. Большинство деловых отношений обладает цифровой составляющей. Поэтому формирование определенного доверия организаций друг к другу требует значительных усилий.
Централизованные системы идентификации
Централизованные подходы все-таки эффективны во многих случаях. Например, когда приложения, службы и устройства полагаются на механизмы доверия, используемые в пределах домена или границы доверия.
В централизованных системах идентификации жизненным циклом и использованием учетных данных управляет поставщик удостоверений (IDP).
Однако существуют сценарии, где использование децентрализованной архитектуры с проверяемыми удостоверениями может представлять ценность за счет дополнения таких ключевых сценариев, как
безопасное подключение удостоверений сотрудников и других пользователей, включая удаленные сценарии;
доступ к ресурсам в пределах границы доверия организации исходя из определенных критериев;
доступ к ресурсам за пределами границы доверия (например, доступ к ресурсам партнеров с помощью выпущенного организацией переносимого удостоверения).
Децентрализованные системы идентификации
В децентрализованных системах идентификации управление жизненным циклом и использованием учетных данных осуществляются совместно издателем, держателем и проверяющей стороной, использующей удостоверение.
Рассмотрим сценарий на схеме, где Proseware, веб-сайт электронной коммерции, хочет предложить сотрудникам Woodgrove корпоративные скидки.
Терминология, связанная с проверяемыми удостоверениями (VC) может вводить в замешательство, если вы не знакомы с VC. Следующие определения взяты из раздела о терминологии Модель данных проверяемых удостоверений 1.0. Рассмотрев каждое из них, мы будем связывать их с сущностями на предыдущей схеме.
"Издатель — это роль, которую сущность может выполнять, утверждая утверждения о одном или нескольких субъектах, создавая проверяемые учетные данные из этих утверждений и передавая проверяемые учетные данные держателю".
- Компания Woodgrove на предыдущей схеме — это издатель проверяемых удостоверений для своих сотрудников.
"Владелец — это роль, которую сущность может выполнять, обладая одним или несколькими проверяемыми учетными данными и создавая презентации из них. Владелец обычно, но не всегда, предмет проверяемых учетных данных, которые они держат. Владельцы хранят свои учетные данные в репозиториях учетных данных".
- На предыдущей схеме Алиса является сотрудником компании Woodgrove. Она получила проверяемое удостоверение от издателя, компании Woodgrove, и является его держателем.
"Проверяющий — это роль, которую сущность выполняет, получая одну или несколько проверяемых учетных данных, при необходимости в проверяемой презентации для обработки. Другие спецификации могут ссылаться на эту концепцию как проверяющую сторону".
- На предыдущей схеме компания Proseware является проверяющей выданных компанией Woodgrove удостоверений.
"Учетные данные — это набор одного или нескольких утверждений, сделанных издателем. Проверяемое удостоверение является удостоверением с контролем вскрытия, авторство которого может быть проверено методами криптографии. Проверяемые удостоверения можно использовать для создания проверяемых презентаций, которые также можно проверять криптографическим путем. Утверждения в учетных данных могут быть о различных субъектах".
"Децентрализованный идентификатор — это переносимый URI-идентификатор, также известный как DID, связанный с сущностью. Эти идентификаторы часто используются в проверяемых учетных данных и связаны с субъектами, издателями и проверятелями".
"Децентрализованный документ идентификатора, также называемый документом DID, является документом, который доступен с помощью проверяемого реестра данных и содержит сведения, связанные с определенным децентрализованным идентификатором, таким как связанный репозиторий и информация о открытом ключе".
В сценарии у издателя и проверяющего есть ДОКУМЕНТ DID, а также документ DID. В документе DID содержится открытый ключ, а также список веб-доменов DNS, связанных с DID (так называемых связанных доменов).
Компания Woodgrove (издатель) подписывает проверяемые удостоверения своих сотрудников с помощью закрытого ключа; аналогичным образом, компания Proseware (проверяющий) подписывает запросы на представление проверяемого удостоверения, используя свой ключ, который также связан с его DID.
Система доверия является основой для установления доверия между децентрализованными системами. Это может быть распределенный реестр или даже что-то централизованное, например DID Web.
"Распределенное реестра — это нецентрализованная система для записи событий. Такие системы позволяют участникам достаточно уверенно полагаться на данные, записанные другими пользователями, при принятии оперативных решений. Обычно они используют распределенные базы данных, где разные узлы используют протокол консенсуса для подтверждения порядка транзакций с криптографическими подписями. Связывание цифровых подписываемых транзакций с течением времени часто делает историю реестра фактически неизменяемым».
Сочетание централизованных и децентрализованных архитектур идентификации
При изучении решения на базе проверяемого удостоверения полезно понимать, как децентрализованные архитектуры идентификации можно сочетать с централизованными архитектурами идентификации, чтобы создать решение, уменьшающее риск и обладающее значительными эксплуатационными преимуществами.
Путь взаимодействия пользователя
Эти основные сведения об архитектуре изучаются кандидатом на должность и сотрудником, который подает заявку на вакансию и трудоустраивается в организации. Затем здесь приводятся изменения, касающиеся сотрудника и организации, когда применение проверяемых удостоверений способно дополнить централизованные процессы.
Субъекты в этих вариантах использования
Алиса, лицо, подающее заявку на вакансию и трудоустраивающееся в компанию Woodgrove, Inc.
Фиктивная компания Woodgrove, Inc.
Компания Adatum, фиктивный партнер компании Woodgrove по проверке личности.
Компания Proseware, фиктивная организация, состоящая в партнерстве с компанией Woodgrove.
В Woodgrove применяются как централизованные, так и децентрализованные архитектуры идентификации.
Этапы пути взаимодействия пользователя
Алиса подает заявку на вакансию, принимает предложение и устраивается на работу в компанию Woodgrove, Inc.
Доступ к цифровым ресурсам в пределах границы доверия компании Woodgrove.
Доступ к цифровым ресурсам за пределами границы доверия компании Woodgrove без расширения границ доверия компании Woodgrove или ее партнеров.
Так как компания Woodgrove продолжает вести деятельность, она должна постоянно управлять удостоверениями. Варианты использования в этом руководстве содержат описания того, как Алиса может использовать функции самообслуживания для получения и обслуживания своих идентификаторов и как компания Woodgrove может заводить, изменять и завершать деловые отношения с различными требованиями к доверию.
В этих вариантах использования демонстрируется комбинирование централизованных удостоверений и децентрализованных удостоверений для повышения надежности и эффективности идентификации, стратегии доверия, а также жизненного цикла.
Путь взаимодействия пользователя: трудоустройство в компании Woodgrove
Осведомленность: Алиса интересуется работой в компании Woodgrove, Inc. и посещает веб-сайт с вакансиями компании.
Активация: на сайте компании Woodgrove есть метод подтверждения личности Алисы, основанный на запросе QR-кода или применении прямой ссылки для посещения сайта ее доверенного партнера по проверке личности, компании Adatum.
Запрос и отправка: компания Adatum запрашивает у Алисы подтверждение личности. Алиса делает селфи, берет фотографию из водительских прав и отправляет снимки в Adatum.
Издание: после того, как в Adatum проверят личность Алисы, Adatum выдает Алисе проверяемое удостоверение (VC) для идентификации ее личности.
Предъявление: Алиса (держатель и субъект удостоверения) может затем получить доступ к порталу вакансий компании Woodgrove, чтобы завершить процедуру подачи заявки. Когда Алиса использует VC для доступа к порталу, Woodgrove играет роли проверяющего и проверяющей стороны, которые доверяют проведенной Adatum аттестации.
Предоставление начальных учетных данных
Алиса устраивается на работу в компанию Woodgrove. В рамках процесса подключения учетная запись Microsoft Entra создается для Алисы для использования внутри границы доверия Woodgrove. Менеджер Алисы должен понять, как дать удаленно работающей Алисе возможность безопасно получить информацию для первоначального входа. В прошлом ИТ-отдел мог предоставить эти учетные данные ее менеджеру, который мог бы распечатать и передать их Алисе. Печать учетных данных не работает с удаленными сотрудниками.
VC способны повысить ценность централизованных систем за счет расширения возможностей при предоставлении учетных данных. Менеджеру больше не нужно предоставлять учетные данные. Вместо этого Алиса может воспользоваться своим VC как удостоверением личности для получения исходного имени пользователя и учетных данных для доступа к централизованным системам. Алиса предъявляет удостоверение личности, которое было добавлено к ее кошельку в ходе подготовки к работе.
Когда речь идет о варианте использования при подготовке к работе, роли отношений доверия распределяются между издателем, проверяющим и держателем.
Издатель отвечает за проверку утверждений, относящихся к издаваемому им VC. Компания Adatum проверяет удостоверение Алисы, чтобы издать VC. В этом случае проверяемые удостоверения выдаются без учета проверяющего или проверяющей стороны.
Держатель владеет VC и инициирует предъявление VC для проверки. Только Алиса может предъявлять проверяемые удостоверения.
Проверяющий соглашается с утверждениями в VC, сделанными издателями, которым он доверяет, и проверяет VC, используя децентрализованную возможность реестра, описанную в модели данных проверяемых удостоверений. Woodgrove доверяет утверждениям Adatum о личности Алисы.
За счет комбинирования централизованных и децентрализованных архитектур идентификации при подготовке к работе конфиденциальные сведения об Алисе, необходимые для проверки личности, (например, ее государственный идентификационный номер) не нужно хранить в компании Woodgrove. Ведь она полагает, что VC, изданное партнером по проверке личности (компанией Adatum), подтверждает ее личность. Дублирование усилий сводится к минимуму. При этом можно реализовать программный прогнозируемый подход к начальным задачам подготовки к работе.
Путь взаимодействия пользователя: доступ к ресурсам внутри границы доверия
Будучи сотрудником, Алиса работает в пределах границы доверия компании Woodgrove. Woodgrove выступает в качестве поставщика удостоверений (IDP) и обеспечивает полный контроль над удостоверением и конфигурацией приложений, которые Алиса использует для взаимодействия в пределах границы доверия Woodgrove. Чтобы использовать ресурсы в границе доверия идентификатора Microsoft Entra, Алиса предоставляет потенциально несколько форм проверки идентификации для входа в границу доверия Woodgrove и доступа к ресурсам внутри технологической среды Woodgrove. Несколько доказательств — это типичный сценарий, который хорошо обслуживается с помощью централизованной архитектуры удостоверений.
Woodgrove управляет границей доверия и использует эффективные методы обеспечения безопасности, обеспечивая наименее привилегированный уровень доступа к Алисе в зависимости от выполняемого задания. Чтобы меры в сфере безопасности были эффективны, а также, возможно, для обеспечения соответствия требованиям, у компании Woodgrove также должна быть возможность отслеживания разрешений сотрудников и их доступа к ресурсам, а также отзыва разрешений после завершения периода трудоустройства.
Алиса использует только удостоверение, которое в Woodgrove служит для доступа к ресурсам Woodgrove. Алиса не должна отслеживать, когда учетные данные используются, так как Woodgrove управляет учетными данными и которая используется только с ресурсами Woodgrove. Этот идентификатор допустим только внутри границы доверия Woodgrove, когда необходим доступ к ресурсам Woodgrove. Поэтому Алисе не требуется владеть удостоверением.
Использование VC внутри границы доверия
Потребности отдельных сотрудников в идентификации изменчивы, и проверяемые удостоверения способны расширить возможности централизованных систем в целях учета этих изменений.
Когда Алиса работает в компании Woodgrove, ей может требоваться получить доступ к ресурсам в зависимости от конкретных требований. Например, после прохождения Алисой тренинга по конфиденциальности, ей может быть выдано новое проверяемое удостоверение сотрудника, где будет соответствующее утверждение об этом, и это удостоверение можно будет использовать для доступа к ограниченным ресурсам.
VC можно использовать в пределах границы доверия в целях восстановления учетной записи. Например, если сотрудник потерял свой телефон и компьютер, он может восстановить доступ, получив новый VC из службы проверки подлинности, доверенный Woodgrove, а затем использовать этот VC для получения новых учетных данных.
Путь взаимодействия пользователя: доступ к внешним ресурсам
Woodgrove согласует скидку на покупку продукта с компанией Proseware. Все сотрудники Woodgrove имеют право на эту скидку. Компания Woodgrove хочет предоставить Алисе способ доступа к веб-сайту Proseware и получения скидки при приобретении продуктов. Если в Woodgrove используется централизованная архитектура идентификации, существует два подхода к предоставлению Алисе скидки.
Алиса может предоставить персональные данные для создания учетной записи с помощью Proseware, а затем компания Proseware проверит трудоустройство Алисы в Woodgrove.
Woodgrove может расширить свою границу доверия, чтобы включить Proseware в качестве проверяющей стороны, и для получения скидки Алиса может использовать расширенную границу доверия.
При использовании децентрализованных идентификаторов Woodgrove может предоставить Алисе проверяемое удостоверение (VC), которое Алиса может использовать для доступа к веб-сайту Proseware и другим внешним ресурсам.
Предоставляя Алисе VC, компания Woodgrove подтверждает, что Алиса является ее сотрудником. Woodgrove является доверенным издателем проверяемых удостоверений в решении для проверки компании Proseware. Такое доверие к процессу издания в Woodgrove позволяет Proseware принимать VC в электронном виде в качестве доказательства того, что Алиса является сотрудником компании Woodgrove, и предоставить Алисе скидку. В ходе проверки предъявленного Алисой VC Proseware удостоверяется в допустимости VC с помощью системы доверия. В этом решении:
Woodgrove позволяет Алисе предоставлять Proseware доказательство трудоустройства, и от компании Woodgrove не требуется расширять свою границу доверия.
Proseware не требуется расширять границу доверия для проверки того, что Алиса является сотрудником компании Woodgrove. Вместо этого Proseware может использовать VC, предоставляемое Woodgrove. Так как граница доверия не расширяется, управление отношением доверия упрощается, и Proseware может легко завершить отношения, перестав принимать проверяемые удостоверения.
Алиса не обязана предоставлять Proseware персональные данные, такие как адрес электронной почты. VC Алисы хранится в приложении кошелька на личном устройстве. Единственное лицо, которое может использовать VC, — это Алиса, и Алиса должна инициировать использование удостоверения. Каждое использование VC записывается приложением кошелька, поэтому Алиса имеет запись о том, когда и где используется VC.
Объединяя централизованные и децентрализованные архитектуры удостоверений для работы внутри и вне границ доверия в Woodgrove, сложность и риск могут быть сокращены, а ограниченные связи становятся проще управлять.
Изменения с течением времени
Woodgrove добавляет новые и заканчивает текущие деловые отношения с другими организациями и должен определить, когда используются централизованные и децентрализованные архитектуры удостоверений.
Объединяя централизованные и децентрализованные архитектуры удостоверений, ответственность и усилия, связанные с удостоверением и подтверждением идентификации, распределяются и риск снижается. Пользователь не рискует освободить частную информацию как часто или столько неизвестных проверяющих. В частности:
- В централизованных архитектурах идентификации поставщик удостоверений (IDP) издает удостоверения и выполняет проверку этих изданных удостоверений. IdP обрабатывает сведения обо всех удостоверениях. Он либо сохраняет их в каталоге, либо извлекает их из каталога. При необходимости поставщики удостоверений могут принимать маркеры безопасности из других систем поставщика удостоверений, таких как социальные входы или деловые партнеры. Чтобы проверяющая сторона использовала удостоверения в пределах границы доверия IDP, они должны быть настроены на прием издаваемых IDP маркеров.
Как работают децентрализованные системы идентификации
В децентрализованных архитектурах идентификации издатель, пользователь и проверяющая сторона играют свои роли в налаживании и обеспечении постоянного доверенного обмена учетными данными друг друга. Открытые ключи для DID субъектов разрешаются в системе доверия, что позволяет проверить подпись и настроить доверие любому артефакту, включая проверяемое удостоверение. Проверяющие стороны могут применять проверяемые удостоверения, не вступая в отношения доверия с издателем. Вместо этого издатель предоставляет субъекту удостоверение для предъявления в качестве доказательства проверяющим сторонам. Все сообщения между субъектами подписываются с помощью DID субъекта. Децентрализованные идентификаторы издателей и проверяющих также должны владеть доменами DNS, создавшими запросы.
Например, если держателям VC требуется доступ к ресурсу, они должны предъявить проверяющей стороне VC. Это делается с помощью приложения кошелька для чтения запроса проверяющей стороны на предъявление VC. В рамках чтения запроса приложение кошелька использует RP DID для поиска открытых ключей RP с помощью системы доверия, проверяя, что запрос на представление VC не был изменен. Чтобы доказать владение доменом, кошелек также проверяет, что СЛУЖБА DID ссылается в документе метаданных, размещенном в домене DNS RP.
Поток 1: издание проверяемого удостоверения
Здесь держатель удостоверения взаимодействует с издателем, запрашивая проверяемое удостоверение, как показано на следующей схеме.
Держатель запускает поток, используя браузер или собственное приложение для доступа к внешнему веб-интерфейсу издателя. Там веб-сайт издателя позволяет пользователю собирать данные и выполнять логику, связанную с издателем, чтобы определить, можно ли выдавать учетные данные и его содержимое.
Веб-интерфейс издателя вызывает службу Проверенные учетные данные Microsoft Entra для создания запроса на выдачу VC.
Внешний веб-интерфейс отображает ссылку на запрос в виде QR-кода или прямой ссылки для устройства (в зависимости от устройства).
Держатель сканирует QR-код или переходит по прямой ссылке, описанной в шаге 3, с помощью приложения кошелька, такого как Microsoft Authenticator.
Кошелек скачивает запрос по ссылке. Запрос включает следующее:
DID издателя. DID издателя используется приложением кошелька для разрешения через систему доверия для поиска открытых ключей и связанных доменов.
URL-адрес с манифестом VC, который указывает требования договора для издания VC. Требование контракта может включать id_token, самозаверяемые атрибуты, которые должны быть предоставлены, или презентацию другого VC.
внешний вид VC (URL-адрес файла логотипа, цвета и т. д.).
Кошелек проверяет запросы на издание и обрабатывает требования договора.
Проверяет, подписан ли сообщение запроса на выдачу ключами издателя, найденными в документе DID, разрешенном через систему доверия. Проверка подписи гарантирует, что сообщение не было изменено.
Проверяет, принадлежит ли издатель домен DNS, на который ссылается документ DID издателя.
В зависимости от требований договора о VC кошелек может потребовать от держателя выполнить сбор дополнительных сведений. Например, запросить самостоятельно выдаваемые атрибуты или навигацию по потоку OIDC для получения id_token.
Отправляет артефакты, необходимые контракту, в службу Проверенные учетные данные Microsoft Entra. Служба Проверенные учетные данные Microsoft Entra возвращает VC, подписанную ключом DID издателя, и кошелек безопасно сохраняет VC.
Подробные сведения о том, как создать решение для издания и рекомендации по архитектуре, см. в статье Планирование решения для издания Проверенных учетных данных Microsoft Entra.
Процедура 2: предъявление проверяемого удостоверения
В этом потоке держатель взаимодействует с проверяющей стороной для предъявления VC в рамках требований к авторизации.
Держатель запускает поток, используя браузер или собственное приложение для доступа к внешнему веб-интерфейсу проверяющей стороны.
Веб-интерфейс вызывает службу Проверенные учетные данные Microsoft Entra для создания запроса презентации VC.
Внешний веб-интерфейс отображает ссылку на запрос в виде QR-кода или прямой ссылки для устройства (в зависимости от устройства).
Держатель сканирует QR-код или переходит по прямой ссылке, описанной в шаге 3, с помощью приложения кошелька, такого как Microsoft Authenticator.
Кошелек скачивает запрос по ссылке. Запрос включает следующее:
запрос на основе стандартов удостоверений схемы или типа удостоверения;
DID проверяющей стороны, который кошелек ищет в системе доверия.
Кошелек проверяет наличие запроса на предъявление и находит сохраненные VC, которые соответствуют запросу. Исходя из требуемых проверяемых удостоверений кошелек дает субъекту возможность выбрать VC и согласиться на его использование.
- Субъект соглашается предоставить общий доступ к VC с помощью RP
Затем кошелек отправляет полезные данные ответа презентации в службу Проверенные учетные данные Microsoft Entra, подписанную темой. Она содержит:
VC, на применение которых согласился субъект;
Тема DID.
RP DID в качестве "аудитории" полезных данных.
Служба Проверенные учетные данные Microsoft Entra проверяет ответ, отправленный кошельком. В некоторых случаях издатель VC может отозвать VC. Чтобы убедиться, что VC по-прежнему действителен, проверяющий должен проверить наличие издателя VC. Это зависит от того, как проверятель попросил VC на шаге 2.
После проверки служба Проверенные учетные данные Microsoft Entra вызывает RP с результатом.
Подробные сведения о том, как создать решение для проверки и рекомендации по архитектуре, см. в статье Планирование решения для проверки Проверенных учетных данных Microsoft Entra.
Общие выводы
Децентрализованные архитектуры можно использовать для расширения функционала существующих решений и предоставления новых возможностей.
Чтобы обеспечить стремление Децентрализованного фонда удостоверений (DIF) и W3C Design, при создании проверяемого решения учетных данных следует учитывать следующие элементы:
между субъектами в системе нет центральных точек, позволяющих установить доверительные отношения. Это значит, что границы доверия не расширяются за счет федерации, так как субъекты доверяют конкретным VC.
- Система доверия позволяет обнаружить децентрализованный идентификатор (DID) любого субъекта.
Это решение позволяет проверяющим верифицировать любые проверяемые удостоверения (VC) любого издателя.
Оно не дает издателю возможность управлять авторизацией субъекта или проверяющего (проверяющей стороны).
Субъекты работают несвязанно, и каждый из них способен выполнять задачи для своих ролей.
Издатели обрабатывают каждый запрос на выдачу VC и не различают обслуживаемые запросы.
После издания VC субъекты начинают владеть ими и могут предъявлять свое VC любому проверяющему.
Проверяющие могут проверить любое VC от любого субъекта или издателя.
Следующие шаги
Знакомство с дополнительными сведениями об архитектуре для проверяемых удостоверений