За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.
Что же это такое?
Процитируем Википедию:
Авториза?ция (англ. authorization «разрешение; уполномочивание») — предоставление определенному лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий. |
Реализация авторизации при разработке корпоративной информационной системы или продукта, ориентированного на корпоративный сектор — очень сложная и ответственная задача, которой часто уделяется недостаточное внимание на этапе проектирования и первичном этапе разработки, что в будущем ведет к «костыльной» реализации.
Проблематика
Давайте разберемся, какие требования к авторизации встречаются, и почему их крайне важно учитывать изначально при проектировании системы, а не откладывать на будущее. Источников требований к авторизации в корпоративной информационной системе, как правило, два — это бизнес и информационная безопасность. В общем случае бизнес хочет хранить секреты в тайне и предоставлять полномочия пользователям в соответствии с их функцией в бизнес-процессе, а безопасность хочет обеспечить минимальную достаточность полномочий каждому пользователю и аудировать доступ.
Возьмем для примера гипотетическую систему согласования договоров крупной компании, типовой кровавый энтерпрайз. Практически наверняка возникнут следующие требования к авторизации от бизнеса:
- Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе
- Автор договора должен видеть его на всех этапах.
- Создавать договор имеет право пользователь с грейдом не ниже 10.
- Визирующий должен видеть договор, начиная с поступления к нему на этап и далее.
- Руководители подразделений должны видеть договоры своих подразделений вверх по иерархии.
- Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования.
- Руководство и секретариат головного офиса должны видеть документы всех филиалов.
- Пользователь, создавший договор, не должен иметь права его завизировать.
От безопасности мы могли бы получить следующие требования:
- Знать, кто имеет доступ к конкретному договору.
- Знать, кто имел доступ к конкретному договору в заданный момент времени.
- Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей.
Думаю, разработчикам уже стало страшно :). Дополнительную боль доставляет высокая изменчивость этих требований. Кстати, по статистике одного большого франча 1С – дополнительные требования по авторизации — одна из самых частых задач по кастомизации типовых конфигураций.
Итак, обозначим, почему эти требования проблемные:
- Они не стабильны. Вероятность их изменения, даже в краткосрочной перспективе, стремится к 1.
- Они сквозные. Их реализация влияет на все слои, от дизайна БД до UI.
- Они лежат в плоскости предметной области. Это ведет к сильной связности механизма авторизации со слоем бизнес-логики.
- Они влияют на производительность.
Пути решения
Решить данную задачу нам помогают разработанные модели управления доступом:
MAC — мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.
DAC — прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL) объекта.
RBAC — ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.
АВАС — атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC, с некоторыми нюансами (шикарный обзор от CUSTIS).
Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.
Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:
| Требование от бизнеса |
Решение |
|
|---|---|---|
| 1 |
Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе |
Тут напрашивается ACL, поскольку определить отношение пользователя к бизнес-процессу достаточно сложно, не записывая его в какой-то список в момент вовлечения. Это будет оптимальным решением с точки зрения производительности чтения относительно реализации с помощью политик. |
| 2 |
Автор договора должен видеть его на всех этапах |
Требование может быть реализовано обоими механизмами, но оптимальным я считаю ACL, поскольку в этом случае будет проще реализовать требование №3 от ИБ. |
| 3 |
Создавать договор имеет право пользователь с грейдом не ниже 10 |
Это политика (PBAC), без вариантов |
| 4 |
Визирующий должен видеть договор начиная с поступления к нему на этап и далее |
ACL будет оптимален |
| 5 |
Руководители подразделений должны видеть договоры своих подразделений вниз по иерархии |
Замечательная задача для PBAC, но его применение может снизить производительность чтения, а требования 1 и 2 от ИБ потребуют дополнительных усилий, поэтому стоит подумать над реализацией. |
| 6 |
Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования |
PBAC справится отлично |
| 7 |
Руководство и секретариат головного офиса должны видеть документы всех филиалов |
PBAC, с теми же ограничениями что и в п. 5 |
| 8 |
Пользователь, создавший договор, не должен иметь права его завизировать |
Это требование можно было бы закрыть с помощью PBAC, однако так делать не стоит. Это то самое место, где авторизация вступает в конфликт с бизнес-логикой, и если происходит такая ситуация, ответственность стоит отдать бизнес-логике. |
Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:
| Требование от ИБ |
Решение |
|
|---|---|---|
| 1 |
Знать, кто имеет доступ к конкретному договору |
Общий журнал для ACL и PBAC |
| 2 |
Знать, кто имел доступ к конкретному договору в заданный момент времени |
Общий журнал для ACL и PBAC |
| 3 |
Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей |
ACL |
Итого
Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований.
Мы планируем серию статей, посвященных моделям авторизации и предмету в целом. Будем рады вопросам и предложениям по темам для рассмотрения.
Комментарии (104)
questor
18.12.2019 18:46+1Ну, так уж никто… Вот я себе положил в закладки ещё в 2015 году набор статей https://habr.com/en/company/custis/blog/248649/ https://habr.com/en/company/custis/blog/258861/
AvanpostID Автор
17.12.2019 23:38+1Да, статьи классные. С первой мы еще хотим поспорить, а вторая ссылка в тексте у меня изначально была. Но прошло 4,5 года, а ничего столь же стоящего не появилось. Нужно исправлять!
GraiT
18.12.2019 19:37По моему личному мнению, так происходит из-за принципа «нужно еще вчера». Все начинается с MVP (минимально работающего прототипа) и никто этим просто не занимается, а потом все и обрастает «костылями», а как доберутся до авторизации, костылями начинает обрастать и другая часть проекта. Информации по этой теме мало не только здесь и зарубежные источники слабы. Спасибо за начало, надеюсь получится хорошая серия статей!
Bladimir
18.12.2019 12:01Есть еще одно частое требование — пользователь должен видеть в какой-нибудь папке только те договора, к которым он имеет доступ. Какие есть варианты реализовать быструю фильтрацию?
AvanpostID Автор
18.12.2019 14:16Тут вопрос в правилах, по которым доступ предоставляется. Если эти правила определены заранее, и на каком-то этапе процесса становится понятно, что пользователь получает доступ, то его (лично, его группу, или роль) можно внести в список доступа документа и тогда при чтении папки нужно будет просто добавить фильтр на уровне запроса в хранилище (БД).
lair
… а что делать с ситуацией, когда доступ предоставляется на основании знаний, которые не являются идентифицирующими? Проще говоря, все bearer token и иже с ними?
mayorovp
Э-э-э, а в чем проблема с bearer token?
lair
Он никак не идентифицирует и не аутентифицирует субъекта.
mayorovp
Почему? Я могу согласиться с тем, что он не дает гарантий отсутствия перехвата и нахождения субъекта онлайн, но разве это означает что он никак не идентифицирует и не аутентифицирует субъекта?
lair
Да нет, перехват тут ни при чем.
Вот у вас есть (подписанный доверенным сервисом) токен, в котором все, что есть — это claim
books:read:all. Он никак не идентифицирует владельца этого токена. Посколько субъект не идентифицирован, подтвердить его идентичность — нельзя, следовательно, и аутентификация субъекта невозможна. При этом ничто не мешает вам авторизовать этого субъекта на чтение всех книг, если у вас есть соответствующая договоренность с доверенным сервисом, выдавшим токен.Проще говоря, сертификат "предъявителю сего дозволено блаблабла" не является удостоверением личности.
mayorovp
А если там есть клайм
nameилиperson:fio? Этот токен больше не считается bearer token или как?lair
Хорошо, поправлюсь: он не обязан идентифицировать или аутентифицировать субъекта, но все равно позволит его авторизовать. Мой изначальный коммент остается валидным.
amphasis
В этом случае, очевидно, процесс идентификации и аутентификации был выполнен вашим доверенным сервисом. По-моему, вполне вписывается в изначально процитированный вами абзац.
lair
Во-первых, не очевидно. Это личное дело доверенного сервиса, как он раздает токены.
А во-вторых, что важнее, в абзаце явно сказано "мы должны знать, кто он" — то есть, речь идет о точке зрения конкретной информационной системы, которая осуществляет авторизацию… что, как показано выше, неверно.
Очень важно проводить границы между участниками процесса.
kolkoni
Токены не выдаются в никуда, токены вяжутся с конкретными сущностями, у которых есть или нет доступа. И когда кто то приходит с токеном, он автоматически идетифицируется и далее проверяются права доступа.
Если же нет, значит сама система криво построена и приводить её в пример неправильно.
Если в системе есть права доступа, то токен обязан Вас идентифицировать. И выдаваться он может только на то, на что у сущности которая его выдала, есть права.
lair
Не обязательно.
Почему?
На основании чего вы делаете это утверждение? Скажем, RFC 6749 с вами не согласен.
Что значит "обязан"? Кто создал это обязательство? Почему вы думаете, что это обязательство распространяется на мои системы?
… знаете, я вот могу запустить сервис в AWS, у которого будет больше прав, чем у меня.
kolkoni
Что значит не обязательно? Обязательно. Если нет, значит система неправильная, небезопасная. Вы путаете конкретные реализации с тем как должно быть.
Потому что либо эта информация зашита в токене, либо сам токен где-то на беке связан с каким то пользователем.
Вы сами читали данный стандарт? Мне кажется нет.
Потому что это требование безопасности! То что Вы там у себя велосипед придумали, не значит что так оно должно быть. В своей системе конечно можно что угодно сделать.
И? Значит Вам кто то дал токен с правами запуска сервиса. Но тот кто дал, имел эти права. Или Вы хотите сказать Я могу создать себе токен с большими правами, чем у меня имеются?
Вы себя слышите?
Почитал остальные Ваши комментарии, не вижу смысла спорить, Вы не понимаете о чем говорите и не отличаете конкретные реализации с теоретическими моделями.
lair
То и значит. Нет такого всемирного закона.
Вам показать токен, который не содержит такой информации?
Да, неоднократно.
Кто его выдвинул? Почему оно универсально применимо?
Я хочу сказать, что я могу создать себе токен с большими правами, чем у меня имеются.
kolkoni
Ну удачи Вам с системами где можно сделать токен с большими правами, чем имеются у выдающего.
darthslider
Если токен не содержит информации о владельце токена, то проблема ли это? Выглядит как фича, а не баг.
А если если это проблема — то нужно просто добавить эту информацию в токен.
lair
Смотря как мы собираемся его использовать, но в моей жизни есть множество случаев, когда это не проблема.
Однако мой оппонент утверждает, что это плохой, неправильный токен.
MIKEk8
При голосовании пользователь (голосующий) получает токен (билютень) которая не содержит его идентификатора, но она предоставляет ему право на выбор из кандидатов. Да пользователь аутентифицируется при выдачи токена, но само действие (отдача голоса) происходит анонимно.
kolkoni
Это описание системы, в которой специально не хранят связь токена и юзера, для обеспечения полной анонимности.
Токен имеет право сделать только одно действие — проголосовать 1 раз.
Тут максимальная безопасность обеспечивается при выдаче токена.
И то, где гарантия, что они не хранят связь токен-юзер? В реальном коде то может быть совсем по другому.
lair
Что показывает, что утверждение "либо эта информация зашита в токене, либо сам токен где-то на беке связан с каким то пользователем" верно не всегда.
kolkoni
Верно всегда для безопасных и надёжных систем.
Если токен анонимен, конкретно в ситуации с голосованием, как Вы можете гарантировать что они были выданы разным людям? Тут либо анонимность, либо безопасность.
lair
Как доказать (или опровергнуть) это утверждение?
Простой признак "токен выдан" для конкретного человека решает эту проблему.
kolkoni
Никак, это рекомендация, а конкретные реализации зависят от разрабов
Это нарушение требования об анонимности. То есть отметка в моем профиле что токен выдан уже говорит о том что Я приходил голосовать.
lair
Если это рекомендация, значит, как утверждение это верно не всегда. Потому что рекомендациям следовать не обязательно.
Следующий вопрос: а чья конкретно это рекомендация? Можно ссылку на авторитетный документ?
Нет, если требование об анонимности сформулировано как "не должно быть известно, кто за кого проголосовал" (случай единогласного голосования не рассматриваем, он вырожденный). Собственно, сейчас система голосования в России так и работает, насколько мне известно.
kolkoni
Так и случай одноразового анонимного токена для одного действия тоже вырожденный.
Повторюсь, с Вами диалог Я вести не хочу, Вы неадекватно интерпретируете информацию. Вам никто ничего не советует, и ни к чему не обязывает, и доказывать Вам Я тоже ничего не собираюсь...
lair
То-то мы эти "токены" на каждом голосовании видим (равно как и при походах в кино, театр, музей и так далее, далее, далее).
kolkoni
Ну о чем Я и говорил, Вы сравниваете теплое с мягким.
1 раз в несколько лет ни в какое сравнение с тысячами сервисов которые каждый день используются.
lair
Театр, музей, кино, концерты, некоторые виды транспорта — это все 1 раз в несколько лет?
kolkoni
Обоснуйте. Где Вы этот токен видите при походе в театр?
lair
Билет. Самый простой входной билет, купленный в кассе. Он на одно действие (войти), одноразовый (оторвут корешок и больше не пустят) и полностью анонимный.
(больше того, если я его покупал за наличку, аутентификации меня как субъекта не было никогда)
kolkoni
Где в билете Вы увидели токен?
lair
В словаре:
kolkoni
Где в этом определи Вы увидели токен, в том понимании, которое мы обсуждаем?
Или Вам не в домек что одно и тоже слово может иметь совершенно разные значения?
lair
Это словарная статья для слова token.
kolkoni
Ну Я так и понял, что Вам не в домек, что слово может иметь различные смыслы в зависимости от области применения и контекста.
lair
Это никак не отменяет того факта, что поход в театр по билету, купленному в кассе — это типичный пример одноразового анонимного токена.
kolkoni
Ни разу не пример, Вы сравниваете совершенно разные вещи
lair
Докажите это утверждение.
kolkoni
Да легко, Я в статье про значения слова "дурак" оставлю ссылку на Ваш профиль, как одно из значений.
И по Вашей логике, любое упоминание дурака, букет касаться Вас. А это не так.
lair
То, что вы можете заниматься вандализмом в отношении словарных статей, никак не доказывает, что мой пример некорректен.
kolkoni
Я доказал своё утверждение...
lair
Нет. Чтобы доказать ваше утверждение ("Ни разу не пример"), вам нужно привести (общепринятое) определение примера, и показать, что мое высказывание ему не соответствует.
kolkoni
Кто сказал, что Я что то должен?
lair
Мне кажется, что из комментария, на который вы отвечаете, вполне очевидно, что это был я.
kolkoni
Дак Я Вам ничего не должен уважаемый.
lair
Равно как и я не должен верить любому вашему высказыванию или принимать за доказательство то, что им не является.
kolkoni
Как Я уже говорил
lair
Это, несомненно, прекрасно сочетается с вашим же утверждением несколько выше, что вы что-то доказали.
Но, впрочем, не суть. Не собираетесь доказывать — не доказывайте. Это полностью согласуется с моим мнением, что ваши высказывания выше — не доказаны (и, if I might say so, безосновательны).
mayorovp
А какие различия вы видите в значениях этого слова?
pulsatrix
Ну вам, мне кажется, просто нужен пример токена даваемого непонятно кому. Пожалуйста. Рекламная акция — первые двадцать зашедших на мой сайт не будут видеть рекламу год. При этом я о них ничего не знаю и знать не хочу, кроме того, что у них есть этот токен.
kolkoni
При чем тут токен даваемый непонятно кому и токен доступа? Мне кажется Вам нужно внимательно прочитать саму статью и комментарии по порядку.
pulsatrix
Возможно.
gecube
А что делать, если мы хотим в экстренном порядке этого субъекта заблокировать? Токен-то мы уже отозвать не сможем оперативно! Или нам нужно проверять уже не просто наличие claim с криптоподписью issuer, а каждый запрос отправлять в некий сервис, который будет нам говорить — валидный токен еще валиден или уже нет?
lair
Иначе проектировать систему авторизации, очевидно. Начиная с того, что иначе делить ответственности между вашим сервисом и сервисом, поставляющим токены.
… и так тоже делают. Собственно, в OAuth 2 явно написано: "The token may denote an identifier used to retrieve the authorization information".
AvanpostID Автор
Соглашусь, данная формулировка не совсем точна, поскольку авторизация без идентификации возможна, к примеру, на сетевом уровне. Однако это скорее вырожденные случаи, не относящиеся к прикладным информационным системам о которых я в первую очередь говорю. Bearer token, как правило, выдан IdP, который все за вас сделал. Формулировку уточнил.
lair
Ну то есть весь OAuth 2 — это вырожденный случай, да? И в прикладных информационных системах он не используется?
Или, скажем, отправка уведомлений (в простонародье — вебхуки) — это вырожденный случай, который в прикладных информационных системах не используется?
Особенно занятно, что ряд требований в вашем примере можно прекрасно реализовать на этот самом "вырожденном случае", просто включив в токен соответствующие утверждения (и, собственно, это будет работать для того подмножества ABAC, где не нужны идентифицирующие атрибуты субъекта, а так же для всего RBAC, потому что роль является таким признаком).
Совершенно не обязательно. Bearer token в OAuth 2 выдается authorization server.
Знаете, достаточно странно слышать это от автора поста c утверждением "В более чем 80% случаев термин употребляется неверно".
amphasis
Вы докопались до одной формулировки вводного абзаца статьи, еще и с несколько сомнительными аргументами, поскольку, я склонен согласиться с автором, авторизация без аутентификации это действительно вырожденный случай. Какая-то более конструктивная критика по поводу изложенного в статье у вас есть?
lair
… и именно с этим постулатом я и спорю.
Когда я даю доступ к альбому в Google Photos "всем, у кого есть ссылка" — работает именно этот "вырожденный случай". И если он такой вырожденный, то почему аналогично работают OneDrive и просто сервисы шаринга файлов?
И когда я даю доступ к микросервису на основании api key — тоже работает этот "вырожденный случай".
И когда я создаю временные токены на выполнение внешними сервисами каких-то однократных операций — тоже работает этот "вырожденный случай".
DriverEntry
Авторизация без аутентификации вообще не имеет смысла. В примере с доступом по ссылке вы аутентифицируете того, кому передали ссылку. Аналогично с api key.
lair
Без аутентификации кого или чего? А то это весьма общее понятие.
Кто "вы"? Я-человек-передающий-ссылку? Может быть (может быть и нет). Но сервису, предоставляющему доступ к файлу, на это все равно, он осуществляет авторизацию без аутентификации субъекта.
DriverEntry
Того, кому вы хотиту дать доступ. Хоть человеку, хоть машине.
Тот, кто знает ссылку в этом случае. То есть может выдавать токены доступа.
Но в предположении, что тот, кто дал ссылку (токен доступа), не раздаёт её кому угодно, то есть провёл аутентификацию. Иначе, опять же, в авторизации смысла нет.
lair
Не, тогда авторизация без аутентификации прекрасно имеет смысл. Я ей каждый день пользуюсь, когда подключаюсь к домашнему WiFi.
(и это мы еще на примеры из материального мира не перешли)
Это не сервис, осуществляющий авторизацию. А сам сервис никого не аутентифицирует.
Неа. Нет никаких предположений. Есть ссылка, есть доступ.
Есть. Смысл авторизации — разрешить операцию тому, у кого есть на нее права.
DriverEntry
Тогда либо ваш роутер без пароля, либо вы всё-таки аутентифицируетесь, вводя пароль.
Никто не говорит, что аутентификацию и авторизацию должен делать один и тот же сервис, человек и т.п. Но не может быть разграничения доступа, в котором нет аутентификации.
lair
Я не аутентифицируюсь. Моя сеть не знает, кто к ней подключился — я, мой партнер, родители, доверенный робот — к ней подключилось нечто, знающее пароль. Это авторизация в чистом виде, но не аутентификация субъекта.
Но все, что за границами разрабатываемого и контролируемого ПО, нас мало волнует.
Если мы говорим об аутентификации субъекта — легко может.
DriverEntry
Это называется аутентифицированное нечто. В отношении подключения к сети все пользователи одинаковы, поэтому логин и не требуется, но это не значит, что нет аутентификации.
Вы можете вынести вопрос аутентификации за рамки своего ПО и переложить на кого-то ещё. Но совсем исключить из процесса разграничения доступа — нет.
lair
Почему? Аутентификация — это подтверждение чего-то. Что вы подтверждаете?
Или даже на шаг раньше: что именно вы понимаете под аутентификацией, каким конкретно определением вы пользуетесь?
Из процесса разграничения доступа в разрабатываемой системе — могу. И уже сделал, что характерно.
Впрочем, могу и вообще, но придется начать с примера из материального мира. Вы в театры или музеи ходите?
DriverEntry
Подтверждаю, что я тот единственный пользователь сети, о котором знает роутер. Так как других пользователей нет и не может быть, имя не имеет смысла.
lair
С точки зрения моей домашней сети это утверждение неверно: в ней 12 пользователей (вот ровно по отчету ее контроллера).
Понимаете, то, что вы делаете — это подмена понятий: вы из нескольких фактических субъектов разграничения доступа делаете одного вымышленного "пользователя", и потом утверждаете, что этот "пользователь" аутентифицируется — хотя его не существует.
DriverEntry
Я просто показываю, где в вашем примере аутентификация, и куда делся логин. Смотреть на 12 пользователей, о которых вы говорите, как на разных, никто не запрещает, но так не делают, и пользы от этого нет. Например, вы ни пароль не можете изменить для одного независимо от других, ни как-то ограничить доступ. Наконец, 1 пользователь или 12 — им всё равно нужно как-то подтверждать свою личность, а это аутентификация, независимо от того, один у них пароль или нет.
lair
Нет там аутентификации субъекта. Потому что субъектов — 12, а пароль, внезапно, один.
Что значит "не делают", если мой контроллер ровно так и делает?
Нет, не нужно (даже без учета того, что эти 12 пользователей — это устройства, у них нет личности).
mayorovp
Там и авторизации субъекта нету, если разобраться...
lair
Почему? Субъект (устройство) пришло в сеть. Его пустили. Это разве не авторизация?
DriverEntry
Я не очень понимаю, что имеете в виду под субъектом. С точки зрения контроля доступа субъект это хоть устройство, хоть человек. К тому же, я вообще определения субъекта не касался, это не так важно. Важно, что аутентификация обязательно есть.
lair
То, чему предоставляется доступ.
Аутентификация субъекта? Или вообще какая-то аутентификация?
DriverEntry
Я согласен с этим определением, и в этом случае аутентификация просто и аутентификация субъекта это одно и тоже.
lair
Но нет же:
Аутентификация субъекта — это аутентификация (подтверждение) того факта, что субъект — это тот, кем мы его идентифицировали.
Аутентификация "просто" — это проверка какого-то факта (например, что у субъекта есть сумка).
DriverEntry
Я придерживаюсь контекста примера. Но ладно, в том, что аутентификация требуется, нет противоречий, и хорошо.
lair
Вот как раз в контексте примера аутентификации субъекта не происходит. Потому что моя домашняя сеть идентифицировала 12 субъектов, но не аутентифицировала ни одного.
А я, вроде, и не спорил с этим. Я специально сразу спросил, аутентификация чего, и когда вы сказали, что субъекта — с этим я спорю.
AvanpostID Автор
Согласитесь, нельзя авторизовать на доступ к объектам или операциям о которых не знаешь? А если сервер авторизации знает о сущностях системы, то он входит в границы этой системы. Правильно?
Тут, как правило, два варианта, либо без авторизации совсем (на прикладном уровне), либо с идентификацией, хотя бы по api-ключу.
lair
Странно называть его тогда вырожденным случаем.
"The interaction between the authorization server and resource server is beyond the scope of this specification."
Сервер авторизации может не знать о сущностях системы, которая будет пользоваться токеном. Им достаточно контракта о scope — или и вовсе факта "я считаю, что владельцу этого токена можно".
В том-то и дело, что нет. Если у меня где-то есть сервис хранения бэкапов, а где-то в другом месте есть авторизационный сервис, который дает третьим системам токены на заливку бэкапов, этот сервис не обязан быть частью сервиса хранения. Вся их связь выражена в контракте на авторизационный токен — и это, заметим, гигантское достоинство, сильно упрощающее и поддержку и развитие обоих сервисов (а так же еще десятка других сервисов, которым тоже нужна авторизация, но не нужна идентификация).
Вот только api-ключи совершенно не обязательно являются идентификационными. Вполне в ходу вебхуки, которые имеют общее назначение ("любая авторизованная система может слать сюда уведомления в заданном формате"), и доступ к которым ограничивается одним (на всех; ну или двумя, если мы хотим ротацию) ключом.
mayorovp
А любой пользователь имеет доступ к любым бэкапам или как? Если это не так, то токену таки придётся содержать какую-то идентифицирующую информацию...
lair
Не польователь, а сервис. Любой сервис (из белого списка) может залить новый бэкап.
mayorovp
Залить в общую кучу? Или всё-таки есть разделение какой бэкап от какого сервиса?
lair
В общую кучу. Каждый сервис получает глобальный идентификатор залитого бэкапа.
mayorovp
А как потом искать бэкап если сервис накроется?
lair
А вот это уже вопрос за рамками проблемы разделения доступа.
mayorovp
Формально — да, другой. Но реально я не вижу применения подобной сферической системе бэкапов в вакууме.
lair
Скажем так, вопрос применения решается тем, что там есть еще другие сервисы, которые отслеживают связи.
(я бы привел другой, более подходящий пример для write-only-задач, но у меня на него NDA)
AvanpostID Автор
Микросервисы принадлежат одной системе. Если ваш пример переложить на монолит, то можно сказать что репозиторию (я имею ввиду паттерн) не нужно знать какой пользователь внес те изменения, которые он записывает в БД. Естественно не нужно, он предполагает что работает в доверенной среде.
lair
А как верно?
Я говорил о сервисах, а не о микросервисах.
dth_apostle
мне кажется (с), что вы исходите из того, что:
— все этапы процесса должны выполняться одной системой, хотя это не так (как дальнейший пример — RADIUS)
— факт выдачи токена неидентифицированному пользователю не может являться идентификацией. Хотя даже идентификация персоны, как анонима, вполне себе является _идентификацией_.
lair
Ну так этапы процесса, которые я не контролирую, меня не интересуют. Меня интересуют те этапы, которые напрямую явно затрагивают систему, которую я разрабатываю и поддерживаю.
Гм. Я боюсь, что у нас с вами разное понимание идентификации. Для меня "это — аноним" — это не идентификация, а утверждение (assertion или claim).
dth_apostle
Для меня «данный пользователь — anonymous» — вполне себе идентификация в рамках систем, где такой пользователь предусмотрен.
ну так ваша система либо сама идентифицирует/аутентифицирует (и тут ваша озабоченность понятна), либо делегирует это другим системам — и тогда это не ваша головная боль.
lair
Это и показывает разницу в наших подходах. У вас есть пользователь, как сущность, и есть некий конкретный пользователь anonymous, к которому вы привязываете подобные операции. У меня нет такой сущности, вообще. У меня есть привязанное к операции утверждение "пользователь не определен", на основании которого я принимаю решения.
Именно. И очень часто я нахожусь в ситуации "моя система только авторизует".
flancer
Идентификацию и аутентификацию провёл доверенный сервис.
lair
Во-первых, я про это ничего не знаю.
Во-вторых, меня это не волнует.
Разделение ответственностей.
flancer
И как разделение ответственностей отменяет этапы идентификации и аутентификации? То, что это делаете не вы, не отменяет того факта, что
Вы вывели за рамки своей системы доверенный сервис и утверждаете, что авторизация может работать без аутентификации и идентификации. Вот только ваша система (авторизация) теперь не может корректно работать без доверенного сервиса (аутентификация и идентификация).
Отдельную функцию тоже ничего не волнует, кроме входных параметров (как и её разраба).
lair
Очень просто: в моей системе этих этапов нет. Что характерно, и в другой системе их может не быть.
Да, может. Я же понятия не имею, как доверенный сервис выдает токены.
(и я приводил примеры, когда токены можно выдавать без аутентификации и идентификации)
… без доверенного сервиса (токены). А еще точнее — без способа проверить токен (можно и без сервиса обойтись иногда).
Понимаете ли, когда в моем сервисе нет авторизации, потому что авторизация сделана на периметре — мы не говорим, что мой сервис невозможен без авторизации, равно как и мы не говорим, что он ее делает; мы говорим, что она ему не нужна. Аналогично, когда он делает авторизацию на основании каких-то данных — мы говорим, что ему нужны эти данные, но не более того.
И еще раз повторюсь: безотносительно внешнего сервиса, авторизация субъекта без аутентификации субъекта — возможна. Самый простой пример — неименной билет в театр.
flancer
Ссылка на доступ к Google Photo более убедительный пример, чем билет. Вынужден с вами согласиться (хотя я обычно спорю не для того, чтобы потом с кем-либо соглашаться).