Ну, не точно к 5-летнему, но, пожалуйста, избегайте модного слова и предприятий.
Проверка подлинности на основе утверждений кажется сейчас настоящей яростью, но я не мог найти простого и доводного объяснения того, что она на самом деле, как она отличается от того, что у нас есть (я предполагаю, что мы теперь "должны быть аутентифицированы на основе ролей", каковы преимущества его использования и т.д.
@Marnix имеет довольно хороший ответ, но чтобы отойти от технического аспекта:
Аутентификация на основе требований основана на определении того, кому вы доверяете, чтобы предоставить вам точную информацию о личности и только когда-либо используя эту предоставленную информацию. Мой (кстати) идет, например, в баре. Представьте себе, что вы хотите получить пиво в баре. Теоретически бармен должен просить вас о доказательстве возраста. Как вы это доказываете? Ну, один из вариантов заключается в том, чтобы бармен вырезал вас пополам и подсчитал количество колец, но с этим могут быть некоторые проблемы. Другой вариант - записать свой день рождения на листе бумаги, на который бармен одобряет или отклоняет его. Третий вариант - пойти в правительство, получить удостоверение личности, а затем представить идентификатор бармену.
Некоторые могут смеяться над идеей просто написать свой день рождения на листе бумаги, но это то, что происходит, когда вы проверяете пользователей в самом приложении, потому что для бармена (или вашего приложения) доверять лист бумаги. Однако мы доверяем утверждению правительства о том, что день рождения на удостоверении личности действителен, а идентификатор - для лица, запрашивающего напиток. Для всех целей и задач бармену (или приложению) все равно, как происходит аутентификация из-за доверия. Бармен ничего не знает о вас, кроме вашей даты рождения, потому что все бармену нужно знать. Теперь бармен может хранить информацию, которая, по их мнению, важна для них, например, ваш любимый напиток, но правительству все равно (поскольку это не авторитетный источник), поэтому бармен хранит эту информацию по-своему.
Ключом к ЦБ является "кто является авторитетным источником идентичности?"
(Это мой личный подход к этому, другие могут отличаться. Пожалуйста, отправьте другие точки зрения в виде отдельных ответов.)
Идентификация, основанная на требованиях, аутентификация/авторизация - это разделение обслуживания авторизации пользователя и входа пользователя из (веб-приложения) путем включения аутентификации/авторизации в отдельную (веб-службу).
Так, например, когда я впервые перейду на веб-приложение с поддержкой утверждений, он перенаправит мой браузер на "службу входа в систему", которому он доверяет. Я аутентифицирую эту службу (используя проверку подлинности Windows, смарт-карту или что-то еще), и в ответ он отправляет обратно "токен", который браузер отправляет обратно в веб-приложение. Теперь веб-приложение проверяет, что маркер подписывается цифровой подписью своей доверенной службой входа в систему, а затем просматривает "претензии" в токене. Основываясь исключительно на этих утверждениях, приложение решает, какие функции предлагается пользователю.
Притязания почти всегда будут включать идентификатор пользователя, часто есть также утверждения, связанные с авторизацией ( "этот пользователь может просматривать данные продаж, но не обновлять его" ), а иногда и другую информацию ( "размер обуви = 42",).
Ключевым моментом является то, что приложение не знает и не заботится о том, как пользователь был аутентифицирован, и как администрируются авторизации: он использует информацию из претензий в подписанном токене, чтобы определить, кто является пользователем и/или что пользователь может видеть или делать и/или любую другую информацию о пользователе.
(Да, я предполагаю довольно умного и хорошо информированного 5-летнего здесь.: -)
Следующий пример в реальном мире взят из Руководство по идентификации и контролю доступа (2-е издание).
Очень знакомая аналогия - это протокол аутентификации, который вы следите за каждым время, когда вы посещаете аэропорт . Вы не можете просто подойти к воротам и предъявите паспорт или водительские права. Вместо этого вы должны сначала зарегистрируйтесь на счетчике билетов. Здесь вы представляете любые учетные данные имеет смысл. Если вы едете за границу, вы показываете свой паспорт. Для внутренние рейсы, вы представляете свои водительские права. После проверки что ваш идентификатор изображения соответствует вашему лицу (аутентификация), агент ищет свой рейс и проверяет, что вы заплатили за билет ( разрешение). Предполагая, что все в порядке, вы получаете посадочный талон что вы берете к воротам.
A посадочный талон очень информативен. Ворота агенты знают ваше имя и номер часто летающих пассажиров (аутентификация и персонализация), номер вашего рейса и приоритет посадки (авторизация) и, возможно, даже больше. Агенты ворот все, что им нужно для эффективной работы.
Существует также специальная информация о посадочном талоне. Он закодирован в баре код и/или магнитную полосу на задней панели. Эта информация (например, серийный номер интервала) доказывает, что пропуск был выдан а не подделкой.
В сущности, посадочный талон подписан набор претензий, сделанных авиакомпанией о вас. В нем говорится, что вы разрешено добираться до определенного полета в определенное время и сидеть в особое место. Конечно, агенты не должны думать очень глубоко об этом. Они просто подтверждают ваш посадочный талон, читают претензии на нем, и позвольте вам сесть на самолет.
Также важно отметить, что может быть более одного способа получения подписанного набора требований это ваш посадочный талон. Вы можете пойти в счетчик билетов на аэропорта, или вы можете использовать веб-сайт авиакомпаний и распечатать посадочный талон у себя дома. Агенты ворот, вылетающие на рейс, не заботятся как был создан посадочный талон; им не важно, какой эмитент вы используется, если ему доверяет авиакомпания. Им все равно, что это является подлинным набором требований, которые дают вам разрешение на Плоскость.
В программном обеспечении этот пакет претензий называется маркером безопасности. каждый маркер безопасности подписывается эмитентом, который его создал. Основанная на заявках приложение считает, что пользователи должны быть аутентифицированы, если они представляют действительный, подписанный маркер безопасности от доверенного эмитента.
В течение 5-летнего мальчика попросите его предположить, что он присоединился к новой школе, подписав выражение его родителями. После одобрения руководства школы для его заявления он получает карточку доступа, которая содержит всю приведенную ниже информацию, которую мы можем назвать CLAIMS, чтобы войти в школу.
В первый же день своей школы, когда он входит в школу, он вытащил свою карточку доступа, и ворота открылись, значит, он был ПРОВЕРЕН КАК один из учеников школы. Таким образом, он является АУТЕНТИЧНЫМ ЧЕЛОВЕКОМ, чтобы войти в школу.
После достижения своего класса он использовал карточку доступа для входа в каждый класс, но на 8-й двери стандартного класса открылся, поскольку он утверждал, что был от 8-го стандарта.
В школе он только АВТОРИЗОВАН, чтобы войти в свой класс, когда он изучает 8-й стандарт. И если он попытается войти в шестой стандарт, школьный учитель НЕ УПОЛНОЖЕТ его.
Насколько нетехнический, насколько это возможно:
Если бы вы должны были что-то описать, кто вы есть и что вам было разрешено видеть или делать, каждая из этих вещей была бы чем-то, что вы "утверждали", чтобы быть правдой, и, таким образом, каждая "вещь" в этом списке была бы " Запрос".
Каждый раз, когда вы говорите кому-то что-то о себе или "заявляете", что вам разрешено что-то видеть или делать, вы передаете им свой список претензий. Они будут проверять с полномочиями, что ваши претензии верны, и если они верны, они поверят всему, что в этом списке претензий. Так что, если вы утверждаете, что вы Брэд Питт, в вашем списке утверждений говорится, что вы Брэд Питт, и это было подтверждено властью, что все ваши заявления верны - тогда они будут верить, что вы Брэд Питт вместе с что-нибудь еще в этом списке.
Требуйте: то, что вы утверждаете, чтобы быть правдой. Это может быть часть информации или описание разрешения, которое вы утверждаете получить. Система, в которую вы предъявляете свои претензии, должна только понимать, что такое претензия/означает, а также иметь возможность проверять ее в уполномоченном органе.
Авторитет: система, которая объединяет ваш список претензий и подписывает его, который в основном гласит: "На мой взгляд, все в этом списке верно". До тех пор, пока система, считывающая заявки, может подтвердить с полномочиями, что подпись верна, все в списке заявок будет считаться подлинным и верным.
Кроме того, давайте не будем называть это "аутентификацией на основе утверждений", а давайте называть это "идентификацией на основе утверждений".
Чуть более технический:
Итак, теперь в этом процессе вы аутентифицируетесь, используя какой-то механизм (имя пользователя/пароль, секрет клиента, сертификат и т.д.), И это дает вам маркер, который подтверждает, что вы являетесь тем, кем вы себя называете. Затем вы обмениваете этот токен доступа на идентификационный токен. Этот процесс будет использовать вашу личность для поиска и составления списка претензий, его подписи, а затем вернет вам идентификационный токен, содержащий все ваши претензии.
В качестве шага авторизации, в зависимости от того, как он реализован, ресурс будет проверять ваш идентификационный токен (заявки) и затем проверять, есть ли у вас необходимые заявки для доступа к этому ресурсу.
Так, например, если ресурс "CastleBlack/CommandersTower" говорит, что "вы должны иметь доступ к замку черных и быть командиром лорда, то он рассмотрит ваш список претензий, чтобы увидеть, истинны ли обе эти вещи.
Как видите, "претензии" могут быть чем угодно. Это может быть роль, это может быть фактом, это может быть флаг. Это просто список пар ключ-значение, а "значение" является необязательным. Иногда просто посмотреть, существует ли претензия:
claims : [
{"type": "name", "value": "Jon Snow"},
{"type": "home", "value": "Winterfell, The North, Westeros"},
{"type": "email", "value": "[email protected]"},
{"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-членстве на такое разрешение, как покровитель, которому разрешено сидеть в эксклюзивной гостиной, и подавать бесплатные напитки ".