Объясните «аутентификацию на основе утверждений» 5-летнему

Ну, не совсем для 5-летнего, но, пожалуйста, избегайте модных слов и предприятий, если возможно.

Аутентификация на основе утверждений, кажется, сейчас в моде, но я не смог найти простого и практичного объяснения того, что это на самом деле, как оно отличается от того, что мы имеем сейчас (я предполагаю, «что мы имеем сейчас») быть аутентификацией на основе ролей), каковы преимущества ее использования и т. д.

У @Marnix есть довольно хороший ответ, но отойти от технического аспекта:

Аутентификация на основе утверждений заключается в определении того, кому вы доверяете, чтобы предоставить вам точную информацию о личности, и только когда она использует предоставленную информацию. Мой пример перехода в баре. Представьте на мгновение, что вы хотите получить пиво в баре. Теоретически, бармен должен попросить вас подтвердить возраст. Как ты это докажешь? Ну, один из вариантов - попросить бармена разрезать вас пополам и посчитать количество колец, но с этим могут быть некоторые проблемы. Другой вариант - записать свой день рождения на листе бумаги, который бармен одобряет или не одобряет. Третий вариант - пойти в правительство, получить удостоверение личности, а затем предъявить удостоверение бармену.

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

Ключ к CBA - "кто является авторитетным источником идентичности?"

(Это мое личное мнение, другие могут отличаться. Пожалуйста, оставьте другие точки зрения в качестве отдельных ответов.)

Идентификация / аутентификация / авторизация на основе утверждений - это разделение поддержки авторизации пользователей и входа пользователя из (веб-приложения) путем преобразования аутентификации / авторизации в отдельный (веб-сервис).

Так, например, когда я в первый раз обращаюсь к веб-приложению с поддержкой утверждений, оно перенаправляет мой браузер на «службу входа», которой он доверяет. Я буду аутентифицироваться в этой службе (используя аутентификацию Windows, смарт-карту или что-то еще), и в ответ она отправляет обратно «токен», который браузер отправляет обратно в веб-приложение. Теперь веб-приложение проверяет, что токен имеет цифровую подпись его доверенной службы входа в систему, а затем просматривает «утверждения» в токене. Основываясь исключительно на этих утверждениях, приложение решает, какие функциональные возможности предлагаются пользователю.

Претензии почти всегда будут включать в себя идентификацию пользователя, часто есть также претензии, связанные с авторизацией («этот пользователь может просматривать данные о продажах, но не обновлять их»), а иногда и другую информацию («размер обуви = 42»).

Ключевым моментом является то, что приложение не знает и не заботится о том, как аутентифицировался пользователь, и как администрируются авторизации: оно использует только информацию из утверждений в подписанном токене, чтобы определить, кто пользователь и / или что пользователь может видеть или делать и / или любую другую информацию о пользователе.

(Да, я предполагаю, что довольно умный и хорошо информированный 5-летний здесь. :-)

Следующий пример из реальной жизни взят из Руководства по идентификации и управлению доступом на основе утверждений (2-е издание) .

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

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

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

По сути, посадочный талон - это подписанная авиакомпанией претензия к вам . В нем говорится, что вам разрешено сесть на определенный рейс в определенное время и сесть на определенное место. Конечно, агентам не нужно думать об этом очень глубоко. Они просто проверяют ваш посадочный талон, читают требования к нему и позволяют вам сесть на самолет.

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

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

5-летний мальчик попросил его предположить, что он перешел в новую школу, подписав заявление от родителей. После одобрения со стороны руководства школы для его заявления, он получает карту доступа, которая содержит всю нижеприведенную информацию, которую мы можем называть ПРЕТЕНЗИЯМИ, чтобы войти в школу.

1. ИМЯ МАЛЬЧИКА - ЛПП.
2. ШКОЛА ИМЯ МОНТИССОРИ ВЫСШАЯ ШКОЛА
3. Класс 8-й сорт

В первый день своей школы, когда он шел в школу, он сильно ударил свою карточку доступа, и ворота открылись, значит, он был ЗАЯВЛЕН как один из людей из школы. Таким образом, он является Аутентифицированным человеком, чтобы войти в школу.

Добравшись до своего класса, он использовал карточку доступа для входа в каждый класс, но в 8-м стандарте двери открылись, как он утверждал, что из 8-го стандарта.

В школе он только уполномочен входить в свой класс, так как он сейчас изучает 8-й стандарт. И если он попытается войти в 6-ой Стандарт, школьный учитель НЕ РАЗРЕШИТ его.

Насколько нетехнический, насколько это возможно:

Если бы вы должны были что-то описать, кто вы есть, и что вам было разрешено видеть или делать, каждая из этих вещей была бы чем-то, что вы «утверждали» как истинное, и, таким образом, каждая «вещь» в этом списке была бы « Запрос".

Каждый раз, когда вы говорите кому-то что-то о себе или «утверждаете», что вам разрешено видеть или делать что-то, вы передаете им свой список требований. Они будут проверять с полномочиями, что ваши претензии верны, и если они верны, они будут верить чему-либо в этом списке претензий. Так что, если вы утверждаете, что вы Брэд Питт, в вашем списке утверждений говорится, что вы Брэд Питт, и это было подтверждено властью, что все ваши утверждения верны - тогда они будут верить, что вы Брэд Питт вместе с что-нибудь еще в этом списке.

Требуйте : то, что вы утверждаете, чтобы быть правдой. Это может быть фрагмент информации или описание разрешения, которое вы утверждаете получить. Система, в которую вы предъявляете свои претензии, должна только понимать, что такое претензия / означает, а также иметь возможность проверять ее в уполномоченном органе.

Авторитет : система, которая объединяет ваш список претензий и подписывает его, который в основном гласит: «На мой взгляд, все в этом списке верно». До тех пор, пока система, считывающая заявки, может подтвердить полномочиями, что подпись верна, все в списке заявок будет считаться подлинным и верным.

Кроме того, давайте не будем называть это «аутентификацией на основе утверждений», а давайте называть это «идентификацией на основе утверждений».

Чуть более технический:

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

Как разрешение шага , в зависимости от того, как он реализован, ресурс будет проверять ваш идентификационный токен (заявки) и затем проверять, есть ли у вас необходимые заявки для доступа к этому ресурсу.

Так, например, если ресурс «CastleBlack / CommandersTower» говорит, что «вы должны иметь доступ к замку черного и быть командиром лорда, то он рассмотрит ваш список претензий, чтобы проверить, верны ли обе эти вещи.

Как видите, «претензии» могут быть чем угодно. Это может быть роль, это может быть фактом, это может быть флаг. Это просто список пар ключ-значение, а «значение» является необязательным. Иногда просто посмотреть, существует ли претензия:

claims : [
    {"type": "name", "value": "Jon Snow"},
    {"type": "home", "value": "Winterfell, The North, Westeros"},   
    {"type": "email", "value": "jon@nightswatch-veterans.org"},
    {"type": "role", "value": "veteran;deserter;"},
    {"type": "department", "value": "none"},    
    {"type": "allowEntry", "value": "true"},
    {"type": "access", "value": "castleblack;eastwatch;"}
]

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

В частности, «CastleBlack», вероятно, будет [большей] областью, и для каждой области будет определенное разрешение, но это другое обсуждение.

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

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

Следующий отрывок взят из Википедии ( http://en.wikipedia.org/wiki/Claims-based_identity ), и это лучшая аналогия, которую я нашел до сих пор.

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

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