Pull to refresh

Comments 110

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

… а что делать с ситуацией, когда доступ предоставляется на основании знаний, которые не являются идентифицирующими? Проще говоря, все bearer token и иже с ними?

Э-э-э, а в чем проблема с bearer token?

Он никак не идентифицирует и не аутентифицирует субъекта.

Почему? Я могу согласиться с тем, что он не дает гарантий отсутствия перехвата и нахождения субъекта онлайн, но разве это означает что он никак не идентифицирует и не аутентифицирует субъекта?

Да нет, перехват тут ни при чем.


Вот у вас есть (подписанный доверенным сервисом) токен, в котором все, что есть — это claim books:read:all. Он никак не идентифицирует владельца этого токена. Посколько субъект не идентифицирован, подтвердить его идентичность — нельзя, следовательно, и аутентификация субъекта невозможна. При этом ничто не мешает вам авторизовать этого субъекта на чтение всех книг, если у вас есть соответствующая договоренность с доверенным сервисом, выдавшим токен.


Проще говоря, сертификат "предъявителю сего дозволено блаблабла" не является удостоверением личности.

А если там есть клайм name или person:fio? Этот токен больше не считается bearer token или как?

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

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

Во-первых, не очевидно. Это личное дело доверенного сервиса, как он раздает токены.


А во-вторых, что важнее, в абзаце явно сказано "мы должны знать, кто он" — то есть, речь идет о точке зрения конкретной информационной системы, которая осуществляет авторизацию… что, как показано выше, неверно.


Очень важно проводить границы между участниками процесса.

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

Токены не выдаются в никуда, токены вяжутся с конкретными сущностями, у которых есть или нет доступа.

Не обязательно.


И когда кто то приходит с токеном, он автоматически идетифицируется и далее проверяются права доступа.

Почему?


Если же нет, значит сама система криво построена

На основании чего вы делаете это утверждение? Скажем, RFC 6749 с вами не согласен.


Если в системе есть права доступа, то токен обязан Вас идентифицировать.

Что значит "обязан"? Кто создал это обязательство? Почему вы думаете, что это обязательство распространяется на мои системы?


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

… знаете, я вот могу запустить сервис в AWS, у которого будет больше прав, чем у меня.

Не обязательно.

Что значит не обязательно? Обязательно. Если нет, значит система неправильная, небезопасная. Вы путаете конкретные реализации с тем как должно быть.


Почему?

Потому что либо эта информация зашита в токене, либо сам токен где-то на беке связан с каким то пользователем.


На основании чего вы делаете это утверждение? Скажем, RFC 6749 с вами не согласен.

Вы сами читали данный стандарт? Мне кажется нет.


Что значит "обязан"? Кто создал это обязательство? Почему вы думаете, что это обязательство распространяется на мои системы?

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


… знаете, я вот могу запустить сервис в AWS, у которого будет больше прав, чем у меня.

И? Значит Вам кто то дал токен с правами запуска сервиса. Но тот кто дал, имел эти права. Или Вы хотите сказать Я могу создать себе токен с большими правами, чем у меня имеются?
Вы себя слышите?


Почитал остальные Ваши комментарии, не вижу смысла спорить, Вы не понимаете о чем говорите и не отличаете конкретные реализации с теоретическими моделями.

Что значит не обязательно?

То и значит. Нет такого всемирного закона.


Потому что либо эта информация зашита в токене, либо сам токен где-то на беке связан с каким то пользователем.

Вам показать токен, который не содержит такой информации?


Вы сами читали данный стандарт?

Да, неоднократно.


Потому что это требование безопасности!

Кто его выдвинул? Почему оно универсально применимо?


Или Вы хотите сказать Я могу создать себе токен с большими правами, чем у меня имеются?

Я хочу сказать, что я могу создать себе токен с большими правами, чем у меня имеются.

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

Если токен не содержит информации о владельце токена, то проблема ли это? Выглядит как фича, а не баг.
А если если это проблема — то нужно просто добавить эту информацию в токен.
Если токен не содержит информации о владельце токена, то проблема ли это?

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


Однако мой оппонент утверждает, что это плохой, неправильный токен.

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

Это описание системы, в которой специально не хранят связь токена и юзера, для обеспечения полной анонимности.
Токен имеет право сделать только одно действие — проголосовать 1 раз.
Тут максимальная безопасность обеспечивается при выдаче токена.
И то, где гарантия, что они не хранят связь токен-юзер? В реальном коде то может быть совсем по другому.

Это описание системы, в которой специально не хранят связь токена и юзера, для обеспечения полной анонимности.

Что показывает, что утверждение "либо эта информация зашита в токене, либо сам токен где-то на беке связан с каким то пользователем" верно не всегда.

Верно всегда для безопасных и надёжных систем.
Если токен анонимен, конкретно в ситуации с голосованием, как Вы можете гарантировать что они были выданы разным людям? Тут либо анонимность, либо безопасность.

Верно всегда для безопасных и надёжных систем.

Как доказать (или опровергнуть) это утверждение?


Если токен анонимен, конкретно в ситуации с голосованием, как Вы можете гарантировать что они были выданы разным людям?

Простой признак "токен выдан" для конкретного человека решает эту проблему.

Как доказать (или опровергнуть) это утверждение?

Никак, это рекомендация, а конкретные реализации зависят от разрабов


Простой признак "токен выдан" для конкретного человека решает эту проблему.

Это нарушение требования об анонимности. То есть отметка в моем профиле что токен выдан уже говорит о том что Я приходил голосовать.

Никак, это рекомендация, а конкретные реализации зависят от разрабов

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


Следующий вопрос: а чья конкретно это рекомендация? Можно ссылку на авторитетный документ?


То есть отметка в моем профиле что токен выдан уже говорит о том что Я приходил голосовать.

Нет, если требование об анонимности сформулировано как "не должно быть известно, кто за кого проголосовал" (случай единогласного голосования не рассматриваем, он вырожденный). Собственно, сейчас система голосования в России так и работает, насколько мне известно.

случай единогласного голосования не рассматриваем, он вырожденный

Так и случай одноразового анонимного токена для одного действия тоже вырожденный.


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

Так и случай одноразового анонимного токена для одного действия тоже вырожденный.

То-то мы эти "токены" на каждом голосовании видим (равно как и при походах в кино, театр, музей и так далее, далее, далее).

Ну о чем Я и говорил, Вы сравниваете теплое с мягким.
1 раз в несколько лет ни в какое сравнение с тысячами сервисов которые каждый день используются.

Театр, музей, кино, концерты, некоторые виды транспорта — это все 1 раз в несколько лет?

Обоснуйте. Где Вы этот токен видите при походе в театр?

Билет. Самый простой входной билет, купленный в кассе. Он на одно действие (войти), одноразовый (оторвут корешок и больше не пустят) и полностью анонимный.


(больше того, если я его покупал за наличку, аутентификации меня как субъекта не было никогда)

Где в билете Вы увидели токен?

В словаре:


A piece of stamped metal or plastic, etc., used as a substitute for money; a voucher that can be exchanged for goods or services

Где в этом определи Вы увидели токен, в том понимании, которое мы обсуждаем?
Или Вам не в домек что одно и тоже слово может иметь совершенно разные значения?

Это словарная статья для слова token.

Ну Я так и понял, что Вам не в домек, что слово может иметь различные смыслы в зависимости от области применения и контекста.

Это никак не отменяет того факта, что поход в театр по билету, купленному в кассе — это типичный пример одноразового анонимного токена.

Ни разу не пример, Вы сравниваете совершенно разные вещи

Докажите это утверждение.

Да легко, Я в статье про значения слова "дурак" оставлю ссылку на Ваш профиль, как одно из значений.
И по Вашей логике, любое упоминание дурака, букет касаться Вас. А это не так.

То, что вы можете заниматься вандализмом в отношении словарных статей, никак не доказывает, что мой пример некорректен.

Я доказал своё утверждение...

Нет. Чтобы доказать ваше утверждение ("Ни разу не пример"), вам нужно привести (общепринятое) определение примера, и показать, что мое высказывание ему не соответствует.

Кто сказал, что Я что то должен?

Мне кажется, что из комментария, на который вы отвечаете, вполне очевидно, что это был я.

Дак Я Вам ничего не должен уважаемый.

Равно как и я не должен верить любому вашему высказыванию или принимать за доказательство то, что им не является.

Как Я уже говорил


Вам никто ничего не советует, и ни к чему не обязывает, и доказывать Вам Я тоже ничего не собираюсь...

Это, несомненно, прекрасно сочетается с вашим же утверждением несколько выше, что вы что-то доказали.


Но, впрочем, не суть. Не собираетесь доказывать — не доказывайте. Это полностью согласуется с моим мнением, что ваши высказывания выше — не доказаны (и, if I might say so, безосновательны).

А какие различия вы видите в значениях этого слова?

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

При чем тут токен даваемый непонятно кому и токен доступа? Мне кажется Вам нужно внимательно прочитать саму статью и комментарии по порядку.

А что делать, если мы хотим в экстренном порядке этого субъекта заблокировать? Токен-то мы уже отозвать не сможем оперативно! Или нам нужно проверять уже не просто наличие claim с криптоподписью issuer, а каждый запрос отправлять в некий сервис, который будет нам говорить — валидный токен еще валиден или уже нет?

А что делать, если мы хотим в экстренном порядке этого субъекта заблокировать?

Иначе проектировать систему авторизации, очевидно. Начиная с того, что иначе делить ответственности между вашим сервисом и сервисом, поставляющим токены.


а каждый запрос отправлять в некий сервис, который будет нам говорить — валидный токен еще валиден или уже нет?

… и так тоже делают. Собственно, в OAuth 2 явно написано: "The token may denote an identifier used to retrieve the authorization information".

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

Ну то есть весь OAuth 2 — это вырожденный случай, да? И в прикладных информационных системах он не используется?


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


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


Bearer token, как правило, выдан IdP

Совершенно не обязательно. Bearer token в OAuth 2 выдается authorization server.


Формулировку уточнил.

Знаете, достаточно странно слышать это от автора поста c утверждением "В более чем 80% случаев термин употребляется неверно".

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

… и именно с этим постулатом я и спорю.


Когда я даю доступ к альбому в Google Photos "всем, у кого есть ссылка" — работает именно этот "вырожденный случай". И если он такой вырожденный, то почему аналогично работают OneDrive и просто сервисы шаринга файлов?


И когда я даю доступ к микросервису на основании api key — тоже работает этот "вырожденный случай".


И когда я создаю временные токены на выполнение внешними сервисами каких-то однократных операций — тоже работает этот "вырожденный случай".

Авторизация без аутентификации вообще не имеет смысла. В примере с доступом по ссылке вы аутентифицируете того, кому передали ссылку. Аналогично с api key.
Авторизация без аутентификации вообще не имеет смысла.

Без аутентификации кого или чего? А то это весьма общее понятие.


В примере с доступом по ссылке вы аутентифицируете того, кому передали ссылку.

Кто "вы"? Я-человек-передающий-ссылку? Может быть (может быть и нет). Но сервису, предоставляющему доступ к файлу, на это все равно, он осуществляет авторизацию без аутентификации субъекта.

Без аутентификации кого или чего? А то это весьма общее понятие.

Того, кому вы хотиту дать доступ. Хоть человеку, хоть машине.
Кто «вы»?

Тот, кто знает ссылку в этом случае. То есть может выдавать токены доступа.
он осуществляет авторизацию без аутентификации субъекта

Но в предположении, что тот, кто дал ссылку (токен доступа), не раздаёт её кому угодно, то есть провёл аутентификацию. Иначе, опять же, в авторизации смысла нет.
Того, кому вы хотиту дать доступ. Хоть человеку, хоть машине.

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


(и это мы еще на примеры из материального мира не перешли)


Тот, кто знает ссылку в этом случае.

Это не сервис, осуществляющий авторизацию. А сам сервис никого не аутентифицирует.


Но в предположении, что то тот, кто дал ссылку (токен доступа) не раздаёт её кому угодно,

Неа. Нет никаких предположений. Есть ссылка, есть доступ.


Иначе, опять же, в авторизации смысла нет.

Есть. Смысл авторизации — разрешить операцию тому, у кого есть на нее права.

когда подключаюсь к домашнему WiFi

Тогда либо ваш роутер без пароля, либо вы всё-таки аутентифицируетесь, вводя пароль.

Это не сервис, осуществляющий авторизацию

Никто не говорит, что аутентификацию и авторизацию должен делать один и тот же сервис, человек и т.п. Но не может быть разграничения доступа, в котором нет аутентификации.
Тогда либо ваш роутер без пароля, либо вы всё-таки аутентифицируетесь, вводя пароль.

Я не аутентифицируюсь. Моя сеть не знает, кто к ней подключился — я, мой партнер, родители, доверенный робот — к ней подключилось нечто, знающее пароль. Это авторизация в чистом виде, но не аутентификация субъекта.


Никто не говорит, что аутентификацию и авторизацию должен делать один и тот же сервис, человек и т.п.

Но все, что за границами разрабатываемого и контролируемого ПО, нас мало волнует. Разделение ответственностей, вот это вот всё.


Но не может быть разграничения доступа, в котором нет аутентификации.

Если мы говорим об аутентификации субъекта — легко может.

нечто, знающее пароль

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

Вы можете вынести вопрос аутентификации за рамки своего ПО и переложить на кого-то ещё. Но совсем исключить из процесса разграничения доступа — нет.
Это называется аутентифицированное нечто

Почему? Аутентификация — это подтверждение чего-то. Что вы подтверждаете?


Или даже на шаг раньше: что именно вы понимаете под аутентификацией, каким конкретно определением вы пользуетесь?


Но совсем исключить из процесса разграничения доступа — нет.

Из процесса разграничения доступа в разрабатываемой системе — могу. И уже сделал, что характерно.


Впрочем, могу и вообще, но придется начать с примера из материального мира. Вы в театры или музеи ходите?

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

С точки зрения моей домашней сети это утверждение неверно: в ней 12 пользователей (вот ровно по отчету ее контроллера).


Понимаете, то, что вы делаете — это подмена понятий: вы из нескольких фактических субъектов разграничения доступа делаете одного вымышленного "пользователя", и потом утверждаете, что этот "пользователь" аутентифицируется — хотя его не существует.

Я просто показываю, где в вашем примере аутентификация, и куда делся логин. Смотреть на 12 пользователей, о которых вы говорите, как на разных, никто не запрещает, но так не делают, и пользы от этого нет. Например, вы ни пароль не можете изменить для одного независимо от других, ни как-то ограничить доступ. Наконец, 1 пользователь или 12 — им всё равно нужно как-то подтверждать свою личность, а это аутентификация, независимо от того, один у них пароль или нет.
Я просто показываю, где в вашем примере аутентификация, и куда делся логин.

Нет там аутентификации субъекта. Потому что субъектов — 12, а пароль, внезапно, один.


Смотреть на 12 пользователей, о которых вы говорите, как на разных, никто не запрещает, но так не делают, и пользы от этого нет.

Что значит "не делают", если мой контроллер ровно так и делает?


Наконец, 1 пользователь или 12 — им всё равно нужно как-то подтверждать свою личность,

Нет, не нужно (даже без учета того, что эти 12 пользователей — это устройства, у них нет личности).

Нет там аутентификации субъекта.

Там и авторизации субъекта нету, если разобраться...

Почему? Субъект (устройство) пришло в сеть. Его пустили. Это разве не авторизация?

Я не очень понимаю, что имеете в виду под субъектом. С точки зрения контроля доступа субъект это хоть устройство, хоть человек. К тому же, я вообще определения субъекта не касался, это не так важно. Важно, что аутентификация обязательно есть.
Я не очень понимаю, что имеете в виду под субъектом.

То, чему предоставляется доступ.


Важно, что аутентификация обязательно есть.

Аутентификация субъекта? Или вообще какая-то аутентификация?

Я согласен с этим определением, и в этом случае аутентификация просто и аутентификация субъекта это одно и тоже.
в этом случае аутентификация просто и аутентификация субъекта это одно и тоже.

Но нет же:


the act of proving an assertion

Аутентификация субъекта — это аутентификация (подтверждение) того факта, что субъект — это тот, кем мы его идентифицировали.


Аутентификация "просто" — это проверка какого-то факта (например, что у субъекта есть сумка).

Я придерживаюсь контекста примера. Но ладно, в том, что аутентификация требуется, нет противоречий, и хорошо.
Я придерживаюсь контекста примера.

Вот как раз в контексте примера аутентификации субъекта не происходит. Потому что моя домашняя сеть идентифицировала 12 субъектов, но не аутентифицировала ни одного.


Но ладно, в том, что аутентификация требуется, нет противоречий, и хорошо.

А я, вроде, и не спорил с этим. Я специально сразу спросил, аутентификация чего, и когда вы сказали, что субъекта — с этим я спорю.

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

Так нет же. Пароль от вайфая — это такой же токен доступа. И я рискну предположить, что вы всё-таки сделали какую-то аутентификацию перед тем, как пароль выдать остальным членам вашей семьи, да и вообще кому угодно, кто пароль получил.

И я рискну предположить, что вы всё-таки сделали какую-то аутентификацию перед тем, как пароль выдать остальным членам вашей семьи, да и вообще кому угодно, кто пароль получил.

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


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


И именно поэтому авторизация с токеном доступа — хороший пример авторизации, не требующей аутентификации.

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

То, о чём выговорите — это пример разделения ответственности частей системы.

Нет, это пример разделения ответственностей систем. Но дело даже не в этом. Давайте внимательно посмотрим на происходящее.


Есть субъект авторизации — то, кто получает доступ к WiFi (для простоты — конкретный человек, чтобы не задаваться вопросами, авторизуем мы человека или устройство, а то будет еще сложнее).


Идентификация этого субъекта — это получение информации о его identity, то есть то, что позволяет отличить его от любого другого субъекта. Это важно, потому что из этого следует, что "это наш посетитель" — это не идентификация субъекта. Для идентификации должно быть "это наш посетитель А, это наш посетитель Б" и так далее. "Это наш посетитель" — это утверждение (claim или assertion, как хотите).


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


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


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

Нет, это пример разделения ответственностей систем

Не вижу причины так выделять. В большинстве примеров мы рассуждали о композитных системах, состоящих из других менее сложных систем, связанных по принципу loose coupling.


Идентификация этого субъекта — это получение информации о его identity

Верно. И этот процесс напрямую зависит от определения, что такое Identity. И здесь есть очень простое правило, на самом деле — если с точки зрения системы "наш посетитель А" ничем не отличается от "наш посетитель Б", то их Identity совпадают, "А" и "Б" является избыточной информацией и может быть отброшен, оставив нам истинный Identity — "наш посетитель". С точки зрения принципа получения пароля от wifi два человека не отличаются друг от друга, таки образом см. выше. Заметьте, я не говорю, что два человека не отличаются вообще — это будет неправда. Они отличаются с точки зрения платежной системы, с которой работает кафе, как минимум. Но подсистему выдачи токенов от wifi это отличие не волнует, потому абсолютно правильным будет не навязывать ей чужеродный для неё избыточный Identity агентов.


еще более веселый пример с театром

Да абсолютно такой же пример, как с wifi. Идентификацией занимается касса, сам театр после этого только подтверждает авторизацию. Для неименных билетов с точки зрения театра Identity посетителя составляет максимум объединение Identity спектакля и Identity места в зале (причём второе — опционально в части случаев), и в получении и подтверждении этого Identity по билету у театров как-то проблем не возникало пока что.


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

Не вижу причины так выделять.

А я — вижу. Потому что иначе невозможно провести границы моей ответственности, как проектировщика.


И этот процесс напрямую зависит от определения, что такое Identity.

… каковое определение — сложный философский вопрос.


И здесь есть очень простое правило, на самом деле

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


И здесь есть очень простое правило, на самом деле — если с точки зрения системы "наш посетитель А" ничем не отличается от "наш посетитель Б", то их Identity совпадают, "А" и "Б" является избыточной информацией и может быть отброшен, оставив нам истинный Identity — "наш посетитель".

… и вот тут начинается следующая проблема: идентификацию и авторизацию проводили две разных системы (продавец кафе и wifi-точка), и, внезапно, у них были разные точки зрения.


оставив нам истинный Identity — "наш посетитель"

Неа, это не identity, это assertion. И грусть состоит в том, что ни у вас, ни у меня нет способа доказать (или опровергнуть) свою правоту.


потому абсолютно правильным будет не навязывать ей чужеродный для неё избыточный Identity агентов.

… или же будет "абсолютно правильным" не навязывать системе авторизации никакой identity, потому что он ей не нужен.


Оба случая кажутся сложными

Да нет, ровно наоборот. Они очень простые. Если не пытаться втянуть требование обязательной идентификации перед авторизацией.


И таким образом, требуете от некой системы знать больше, чем ей необходимо для функционирования

Да нет, ровно наоборот: я предлагаю системе знать только об авторизации, полностью избавив ее от необходимости знать о существовании каких-то identity.

Ну то есть весь OAuth 2 — это вырожденный случай, да? И в прикладных информационных системах он не используется?
Достаточно часто используется, особенно спецификация OpenID Connect, в последнее время.
Bearer token в OAuth 2 выдается authorization server.
Ключевое слово authorization. Выше вы говорите:
Очень важно проводить границы между участниками процесса.
Согласитесь, нельзя авторизовать на доступ к объектам или операциям о которых не знаешь? А если сервер авторизации знает о сущностях системы, то он входит в границы этой системы. Правильно?
Или, скажем, отправка уведомлений (в простонародье — вебхуки) — это вырожденный случай, который в прикладных информационных системах не используется?

Тут, как правило, два варианта, либо без авторизации совсем (на прикладном уровне), либо с идентификацией, хотя бы по api-ключу.
Достаточно часто используется

Странно называть его тогда вырожденным случаем.


Согласитесь, нельзя авторизовать на доступ к объектам или операциям о которых не знаешь?

"The interaction between the authorization server and resource server is beyond the scope of this specification."


Сервер авторизации может не знать о сущностях системы, которая будет пользоваться токеном. Им достаточно контракта о scope — или и вовсе факта "я считаю, что владельцу этого токена можно".


А если сервер авторизации знает о сущностях системы, то он входит в границы этой системы. Правильно?

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


Тут, как правило, два варианта, либо без авторизации совсем (на прикладном уровне), либо с идентификацией, хотя бы по api-ключу.

Вот только api-ключи совершенно не обязательно являются идентификационными. Вполне в ходу вебхуки, которые имеют общее назначение ("любая авторизованная система может слать сюда уведомления в заданном формате"), и доступ к которым ограничивается одним (на всех; ну или двумя, если мы хотим ротацию) ключом.

А любой пользователь имеет доступ к любым бэкапам или как? Если это не так, то токену таки придётся содержать какую-то идентифицирующую информацию...

А любой пользователь имеет доступ к любым бэкапам или как?

Не польователь, а сервис. Любой сервис (из белого списка) может залить новый бэкап.

Залить в общую кучу? Или всё-таки есть разделение какой бэкап от какого сервиса?

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

А как потом искать бэкап если сервис накроется?

А вот это уже вопрос за рамками проблемы разделения доступа.

Формально — да, другой. Но реально я не вижу применения подобной сферической системе бэкапов в вакууме.

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


(я бы привел другой, более подходящий пример для write-only-задач, но у меня на него NDA)

Странно называть его тогда вырожденным случаем.
OAuth 2 я вырожденным случаем не называл. Относительно него я говорю, что вы не верно определяете границы системы и подменяете понятия.

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

А как верно?


Микросервисы принадлежат одной системе

Я говорил о сервисах, а не о микросервисах.

мне кажется (с), что вы исходите из того, что:
— все этапы процесса должны выполняться одной системой, хотя это не так (как дальнейший пример — RADIUS)
— факт выдачи токена неидентифицированному пользователю не может являться идентификацией. Хотя даже идентификация персоны, как анонима, вполне себе является _идентификацией_.
все этапы процесса должны выполняться одной системой, хотя это не так

Ну так этапы процесса, которые я не контролирую, меня не интересуют. Меня интересуют те этапы, которые напрямую явно затрагивают систему, которую я разрабатываю и поддерживаю.


Хотя даже идентификация персоны, как анонима, вполне себе является идентификацией.

Гм. Я боюсь, что у нас с вами разное понимание идентификации. Для меня "это — аноним" — это не идентификация, а утверждение (assertion или claim).

Для меня «это — аноним» — это не идентификация, а утверждение (assertion или claim).

Для меня «данный пользователь — anonymous» — вполне себе идентификация в рамках систем, где такой пользователь предусмотрен.
Ну так этапы процесса, которые я не контролирую, меня не интересуют. Меня интересуют те этапы, которые напрямую явно затрагивают систему, которую я разрабатываю и поддерживаю.

ну так ваша система либо сама идентифицирует/аутентифицирует (и тут ваша озабоченность понятна), либо делегирует это другим системам — и тогда это не ваша головная боль.
Для меня «данный пользователь — anonymous» — вполне себе идентификация в рамках систем, где такой пользователь предусмотрен.

Это и показывает разницу в наших подходах. У вас есть пользователь, как сущность, и есть некий конкретный пользователь anonymous, к которому вы привязываете подобные операции. У меня нет такой сущности, вообще. У меня есть привязанное к операции утверждение "пользователь не определен", на основании которого я принимаю решения.


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

Именно. И очень часто я нахожусь в ситуации "моя система только авторизует".

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

Идентификацию и аутентификацию провёл доверенный сервис.

Во-первых, я про это ничего не знаю.
Во-вторых, меня это не волнует.


Разделение ответственностей.

И как разделение ответственностей отменяет этапы идентификации и аутентификации? То, что это делаете не вы, не отменяет того факта, что


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

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


Отдельную функцию тоже ничего не волнует, кроме входных параметров (как и её разраба).

И как разделение ответственностей отменяет этапы идентификации и аутентификации?

Очень просто: в моей системе этих этапов нет. Что характерно, и в другой системе их может не быть.


Вы вывели за рамки своей системы доверенный сервис и утверждаете, что авторизация может работать без аутентификации и идентификации.

Да, может. Я же понятия не имею, как доверенный сервис выдает токены.


(и я приводил примеры, когда токены можно выдавать без аутентификации и идентификации)


Вот только ваша система (авторизация) теперь не может корректно работать без доверенного сервиса (аутентификация и идентификация).

… без доверенного сервиса (токены). А еще точнее — без способа проверить токен (можно и без сервиса обойтись иногда).


Понимаете ли, когда в моем сервисе нет авторизации, потому что авторизация сделана на периметре — мы не говорим, что мой сервис невозможен без авторизации, равно как и мы не говорим, что он ее делает; мы говорим, что она ему не нужна. Аналогично, когда он делает авторизацию на основании каких-то данных — мы говорим, что ему нужны эти данные, но не более того.


И еще раз повторюсь: безотносительно внешнего сервиса, авторизация субъекта без аутентификации субъекта — возможна. Самый простой пример — неименной билет в театр.

Ссылка на доступ к Google Photo более убедительный пример, чем билет. Вынужден с вами согласиться (хотя я обычно спорю не для того, чтобы потом с кем-либо соглашаться).

Да, статьи классные. С первой мы еще хотим поспорить, а вторая ссылка в тексте у меня изначально была. Но прошло 4,5 года, а ничего столь же стоящего не появилось. Нужно исправлять!

О, спасибо за ссылочки. Положил к себе в закладки.

По моему личному мнению, так происходит из-за принципа «нужно еще вчера». Все начинается с MVP (минимально работающего прототипа) и никто этим просто не занимается, а потом все и обрастает «костылями», а как доберутся до авторизации, костылями начинает обрастать и другая часть проекта. Информации по этой теме мало не только здесь и зарубежные источники слабы. Спасибо за начало, надеюсь получится хорошая серия статей!
Есть еще одно частое требование — пользователь должен видеть в какой-нибудь папке только те договора, к которым он имеет доступ. Какие есть варианты реализовать быструю фильтрацию?
Тут вопрос в правилах, по которым доступ предоставляется. Если эти правила определены заранее, и на каком-то этапе процесса становится понятно, что пользователь получает доступ, то его (лично, его группу, или роль) можно внести в список доступа документа и тогда при чтении папки нужно будет просто добавить фильтр на уровне запроса в хранилище (БД).
Sign up to leave a comment.