|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Привет хабр! Для всех тех кто свято верит в авторитет массы, вот пример когда такой массовый (а следовательно авторитетный) фреймворк имеет модуль с концептуально неверной архитектурой. Итак - Spring Security. В нём мы определям правила доступа на уровне ресурса. Это противоречит здравому смыслу: откуда конкретному ресурсу знать кому разрешено им пользоваться? Пример ресурса: товар в магазине. Товар не знает какую цену за него назначил магазин. И не может сам себе проверить цену. Как должно быть правильно (а не как в Spring Security)? - Цену проверяет кассир по ценнику, и он же определяет достаточно ли денег у покупателя на данный товар Подход в Spring Security вызывает целую массу явных и неявных проблем: - Платформозависимость (работает только с ресурсами реализованными в Spring) - Правила доступа захардкожены в коде (это просто пипец, дожили) - Децентрализация правил авторизации - правила аутентификации настраиваются отдельно от правил доступа (и возможно разными людьми в разных серверах) - Сама сущность User Role противоречит естественной объектной модели - по факту это как делать доп. поле "type" в каком-то классе: получается декларативный полиморфизм. Правильно было бы выделять каждую отдельную роль в свой класс (например User, Admin) - потому что Роль - это поведение объекта, а не его данные. - Токены проверяются ресурсном сервере, что нагружает его и базу (особенно в случае хакерских атак) В результате имеем следующее: - Authorization хедер по факту является аутентификационным - Все REST API становятся stateful из-за этого (берётся роль юзера из базы каждый раз) - что противоречит само себе - Полный хаос в терминологии и реализации - а значит риск потенциальных уязвимостей - Техническая отсталость функциональности контроля доступа - Фактическое отсутствие общепринятных решений для Step-up авторизации Выводы: 1) Не надо доверять авторитету массы 2) Концепции заложенные в WWW ещё далеки от технологически совершенной реализации на практике Ваши мысли? PS: я тут уже сделал платформонезависимый протокол авторизации который всё это исправляет. Кому интересно: https://github.com/INFINITE-TECHNOLOGY/ASCEND (технически доделано на 100%, но документации нет - и возвожно и не будет никогда, т.к. никому это походу не интересно, а сил и времени не хватает) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 08:41 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Вот так например выглядит Ascend JWT: Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
Тут и в явном виде ресурсы разрешённые, и поле prerequisite для step up, и поле refresh, и приципалы в структурированном виде... Это нормальный формат. А не то, что нам предлагает OAuth2. Там вообще отбито напрочь, expiry date это "claim". CLAIM, Карл!!! У того кто это придумывал явно были нелады с Англ. языком, потому что ни в одном из значений слова Claim, оно не подходит по смыслу того как его используют в OAuth2. И тоже самое с другой терминологией там... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 08:49 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Ну и чтобы добить, всё это stateless и поддерживает discoverability. Просто перейдите по ссылке: https://ascend-secaas.herokuapp.com/ascend/public/granting/inquire?scopeName=registeredUserScope&serverNamespace=OrbitSaaS Чтобы узнать как нужно юзеру авторизоваться, чтобы получить доступ к scope "registeredUserScope" на сервере ресурсов "OrbitSaas". Ссылка выше рабочая, смелее - нажмите. Там интересно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 08:52 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras В нём мы определям правила доступа на уровне ресурса. Это противоречит здравому смыслу: откуда конкретному ресурсу знать кому разрешено им пользоваться? Пример ресурса: товар в магазине. Товар не знает какую цену за него назначил магазин. И не может сам себе проверить цену. Вот с этого момента сразу непонятно. При чем здесь Spring Security и товар. Очевидно что автор пропустил целый слой абстракций и сразу прыгнул в предметную область. Это странно и для читающих совершенно неочевидно. Это - твоя предметная область. И бизнес устанавливает на нее свои правила. И если у тебя сыр знает сколько он стоит - то значит это выгодно для бизнеса и это ничего не нарушает. А если ты не смог SpringSec абстракции притянуть к этому умному сыру то скорее всего тебе либо SpringSec не нужен либо ты чего-то сам неверно спроектировал. В инфо-безопасности есть принцип Role-Based-Control когда следующий сет рулов управляет объектными привилениями всей системы. Типа Код: java 1. 2. 3.
Есть еще развитие с сессиями и т.д и есть бумажные версии этого стандарта которые детализируют этот куб свойств. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 10:59 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras - Децентрализация правил авторизации - правила аутентификации настраиваются отдельно от правил доступа (и возможно разными людьми в разных серверах) Это нормально. Так и работают современные системы. Яркий пример - многофакторная аутентификация проверяет кто - ты. И назначает тебе токен (или тикет). Далее ты ходишь с этим токеном и заходишь в разные интерфейсы и интерфейсы уже зная тебя и твою роль в токене авторизуют - проверяют можешь ли ты делать какое-то действие. Или еще пример. Ты приехал на конференцию. Прошел в здание через проходную. Офицер тебя проверил и выдал бейджик на котором написано "dakeiras/member". Аутентификация. Далее ты поднимаешься в конферец-холл и следующий офицер проверяет что ты участник конфы (докладчик) и пропускает тебя в рум для докладчиков. Это авторизация. Ты авторизован чтобы докладывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 11:04 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras - Правила доступа захардкожены в коде (это просто пипец, дожили) Тем хардкода в Spring - это отдельная и сложная тема. И можно топик создавать. Но если у тебя рулы безопасности определены через роли - то такой хардкод я-бы одобрил. Тоесть если сыр входит в роль "price-readers" тогда правило разрешения может выглядеть так. Код: java 1.
И такой role-based-access-contol (RBAC) можно спокойно хардкодить в код. Он не будет меняться десятки лет. Или если изменится то только с изменениями самого кода. Что само по себе нормально. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 11:10 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras - Все REST API становятся stateful из-за этого (берётся роль юзера из базы каждый раз) - что противоречит само себе Если рассматривать хедеры Rest и сам смысл Request отдельно то никакого противоречия нет. Если ты правильно проектировал Rest API как stateless то он таковым и остался. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 11:25 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Мне кажется ТС плохо читал документацию. Spring Security вполне может работать c jwt (к примеру keycloak). Если его мало, то вполне можно реализовать свой spring-security-провайдер, который будет работать с твоим токеном. Плюс даже без завязки на базу данных/хардкод чего-либо в коде/без обращений на сервер авторизации и всех этих страшных вещей P.S. не особо понял, что в твоем jwt-токене такого особенного, чтобы к примеру такую же функциональность нельзя было бы реализовать в keycloak или т.п. ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 12:37 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Я не вижу в сорцах чтобы автор использовал аннотации @Secured, @RolesAllowed. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 12:59 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Ну пока вообще не ясно, что есть кроме токена. Как с этим должен работать человек, который захочет прикрутить эту штуку себе? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 13:05 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Непонянто. Автору я предлагаю добавить в README.md краткий пример на 5-10 строчек. Как подключить в свой проект его штуку. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 13:08 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
всем спасибо за комментарии, на свежую голову отвечу сегодня чуть позже подробно. По использованию - тоже покажу. Интерес есть, это оч. радует - значит буду делать документацию и рассказывать тут. Из особенностей - в токене есть регулярные выражения для валидаци доступа к URL (с %подстановками%), т.е. токен самовалидируемый. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 13:21 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Я кстати обнаружил вредноносный код у тебя. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 13:36 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
mayton Я кстати обнаружил вредноносный код у тебя. какой из: Class.forName или context.getBean? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 20:15 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Вот этот. Надо срочно убрать из кода. Код: java 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 20:20 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
авторИ если у тебя сыр знает сколько он стоит - то значит это выгодно для бизнеса и это ничего не нарушает. Правильно пишете, с точки зрения традиционного понимания Web безопасности. Но что мы тут предлагаем - поменять это понимимание: вынести безопасность в отдельный инфраструктурный слой, прозрачный для приложений. Т.е. то, как это и было задумано изначально при проектировании Веба (но к сожалению не было осилено до сих пор). авторЭто нормально. Так и работают современные системы. Яркий пример - многофакторная аутентификация проверяет кто - ты. И назначает тебе токен (или тикет). Далее ты ходишь с этим токеном и заходишь в разные интерфейсы и интерфейсы уже зная тебя и твою роль в токене авторизуют - проверяют можешь ли ты делать какое-то действие. Или еще пример. Ты приехал на конференцию. Прошел в здание через проходную. Офицер тебя проверил и выдал бейджик на котором написано "dakeiras/member". Аутентификация. Далее ты поднимаешься в конферец-холл и следующий офицер проверяет что ты участник конфы (докладчик) и пропускает тебя в рум для докладчиков. Это авторизация. Ты авторизован чтобы докладывать. Да, но и в реальном мире это уязвимость в JWT. Вот пример сценария из платёжного мира: Как сделано в EMV (правильно): 1) Криптограмма (авторизационный токен) транзакции атомарна и содержит в себе аутентификационные данные (PVV или PIN Offset - проверочные значения ПИНа), и сумму покупки. При этом сумма показывается на терминале в момент ввода ПИНа. Как это было бы сделано в JWT (неправильно): 1) Всё тоже самое, но Вы не видите для какой суммы Вы вводите ПИН. И эта информация (авторизационная) не включается в JWT токен (аутентификационный). В итоге с Вас списывают больше денег чем нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 21:13 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
del ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 21:13 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
авторЯ не вижу в сорцах чтобы автор использовал аннотации @Secured, @RolesAllowed. Потому что они как раз и замещаются. См. ниже ссылки. авторЕсли рассматривать хедеры Rest и сам смысл Request отдельно то никакого противоречия нет. Если ты правильно проектировал Rest API как stateless то он таковым и остался. В широком смысле: если используется контекст, это уже не Stateless. Роль пользователя в контексте хранится. В общем, это неидеальная ситуация. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 21:22 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
авторМне кажется ТС плохо читал документацию. Spring Security вполне может работать c jwt (к примеру keycloak). Если его мало, то вполне можно реализовать свой spring-security-провайдер, который будет работать с твоим токеном. Плюс даже без завязки на базу данных/хардкод чего-либо в коде/без обращений на сервер авторизации и всех этих страшных вещей P.S. не особо понял, что в твоем jwt-токене такого особенного, чтобы к примеру такую же функциональность нельзя было бы реализовать в keycloak или т.п. ? И всё это остаётся узко связанным с кодом приложения. авторНу пока вообще не ясно, что есть кроме токена. Как с этим должен работать человек, который захочет прикрутить эту штуку себе? авторНепонянто. Автору я предлагаю добавить в README.md краткий пример на 5-10 строчек. Как подключить в свой проект его штуку. Очень просто, и максимально отвязанно от самих приложений. Клиентская часть (Ascend Granting Client Java SDK): Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Вот всё, что требуется. Такой код сделает следующее внутри: 1) Спросит у Авторизационного сервера, какие есть варианты для авторизации для scope "OrbitSaas" 2) Автоматически даст юзеру выбрать желаемый вариант аутентификации и авторизации (интерактивно) 3) Поищет в клиентском хранилище, есть ли уже такие активные (non-expired, not exceeded usage count) авторизации (или Refresh к ним) 4) Если нет - Соберёт данные для аутентификации (включая пользовательский ввод) 5) Пошлёт авторизационный запрос на Authorization Granting Server. 6) Получит авторизационный токен, сохранит его в пользовательское хранилище 7) Включит его в запрос к защищённому ресурсу (и увеличит счётчик использований в клиентском хранилище) Сейчас делается клиентский SDK для JavaScript. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 21:37 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
На сервере (защищённом ресурсе): https://github.com/INFINITE-TECHNOLOGY/ORBIT/tree/master/orbit-sdk/src/main/groovy/io/infinite/orbit/configurations/security Т.е. фильтр: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
Но по факту это может быть платформонезависимый реверс прокси. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 21:43 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
И таких картинок много, документация готова на 70%. Не хватает времени добить :( ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 21:52 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Сорри, sql.ru не даёт картинку изменить в редактировании сообщения. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 22:00 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras И всё это остаётся узко связанным с кодом приложения. Права довольно часто и есть часть логики приложения. Как быть с правами, которые даются пользователю не напрямую? К примеру: пользователь может видеть/редактировать все объекты у подчиненных ему других пользователей. Или на объекты из определенных регионов и т.п. Довольно много систем, которые не могут быть завязаны только на урлы ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 22:21 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras авторЯ не вижу в сорцах чтобы автор использовал аннотации @Secured, @RolesAllowed. Потому что они как раз и замещаются. См. ниже ссылки. Где конкретнее смотреть? На что они замещаются? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 22:34 |
|
|
start [/forum/topic.php?fid=59&fpage=15&tid=2120795]: |
0ms |
get settings: |
8ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
76ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
527ms |
get tp. blocked users: |
2ms |
others: | 307ms |
total: | 935ms |
0 / 0 |