Идентификация на основе утверждений - Claims-based identity

Идентификация на основе утверждений - это распространенный способ получения приложениями необходимой им идентификационной информации о пользователях внутри своей организации, в других организациях и в Интернете.[1] Он также обеспечивает согласованный подход к приложениям, работающим локально или в облако. Идентичность, основанная на утверждениях, абстрагирует отдельные элементы идентичности и контроль доступа на две части: понятие требований и понятие эмитента или органа.[2]

Личность и претензии

Утверждение - это заявление, которое один субъект, например, человек или организация, делает о себе или о другом субъекте. Например, утверждение может касаться имени, группы, предпочтений при покупке, этническая принадлежность, привилегия, ассоциация или возможность. Субъектом претензии или претензий является поставщик. Заявки упаковываются в один или несколько токенов, которые затем выдаются эмитентом (поставщиком), обычно известным как служба токенов безопасности (СТС).[2]

Название «удостоверение на основе утверждений» поначалу может сбивать с толку, потому что оно кажется неправильным. Присоединение концепции утверждений к концепции идентичности, по-видимому, объединяет аутентификацию (определение идентичности) с авторизацией (что может и что не может делать идентифицированный субъект). Однако более внимательное изучение показывает, что это не так. Претензии - это не то, что субъект может и не может делать. Они то, чем является предмет или нет. Приложение, получающее входящую заявку, должно сопоставить претензии "есть / не" с правилами приложения "может / не может". В традиционных системах часто возникает путаница в отношении различий и сходств между тем, чем является / не является пользователь, и тем, что пользователь может / не может делать. Идентичность на основе утверждений делает это различие очевидным.

Сервис токенов безопасности

Основная статья: Сервис токенов безопасности

Как только будет прояснено различие между тем, чем пользователь является / не является, и тем, что пользователь может / не может делать, возможно, что аутентификация того, чем пользователь является / не является (претензии), может быть обработана третьей стороной. Эта третья сторона называется службой токенов безопасности. Чтобы лучше понять концепцию службы токенов безопасности, рассмотрим аналогию с ночным клубом со швейцаром. Швейцар хочет помешать проникновению несовершеннолетних посетителей. Чтобы облегчить это, он просит покровителя предъявить водительские права, карту медицинского страхования или другое удостоверение личности (жетон), выданное доверенным третьим лицом (служба токенов безопасности), например, провинциальным или государственным отделом лицензирования транспортных средств, отделом здравоохранения. или страховая компания. Таким образом, ночной клуб снимает с себя ответственность за определение возраста посетителя. Он должен только доверять органу-эмитенту (и, конечно, самостоятельно оценивать подлинность представленного токена). После выполнения этих двух шагов ночной клуб успешно подтвердил личность посетителя в отношении утверждения о том, что он или она достигли совершеннолетия для употребления алкоголя.

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

Обратите внимание, что не все случаи использования термина «аутентификация» включают получение требований.[3] Единственное отличие состоит в том, что аутентификация ограничивается привязкой пользователя к информации, содержащейся о пользователе на целевом сайте, поскольку для завершения аутентификации не требуются данные атрибута (утверждение). По мере того, как вопросы конфиденциальности становятся все более важными, способность цифровых объектов аутентифицировать пользователей без доступа к личным атрибутам становится все более важной.

Преимущества

Удостоверение на основе утверждений может упростить логику аутентификации для отдельных программных приложений, поскольку эти приложения не должны предоставлять механизмы для создания учетной записи, создания пароля, сброса и т. Д. Кроме того, идентификация на основе утверждений позволяет приложениям знать определенные вещи о пользователе, не допрашивая пользователя для выяснения этих фактов. Факты или утверждения хранятся в «конверте», который называется защищенным токеном.

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

Смотрите также

Рекомендации

  1. ^ Дэвид Чаппелл (февраль 2011 г.). «Удостоверение на основе утверждений для Windows» (PDF). Корпорация Майкрософт. Получено 28 июля 2011.
  2. ^ а б Microsoft (3 июня 2011 г.). «Документация к Руководству по идентификации и контролю доступа на основе утверждений». Корпорация Майкрософт. Получено 28 июля 2011.
  3. ^ IDESG. «Модель идентичности». Получено 5 мая 2017.