|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
авторP.S. А что если у меня приложение с сессиями и url + body ни разу не достаточны для понимания, что делает пользователь? Пока условно пусть будет что Stateful не поддерживается. авторКстати, а что будет, если я защищу что-либо вашей системой, а ее взломают? Сколько вы мне денег в таком случае заплатите? Это надо страховую вовлекать для покрытия рисков. автор"Менеджер" в автосалоне может сделать 2 скидки в день, а "старший менеджер" - 10. Одновременно с этим "менеджер" не может продать машину без одобрения "старшего менеджера". 1) Видимо кто-то из них "админ", а кто-то "юзер"?:) 2) Вы видимо предлагаете реализовать 1 ограничение минуя правовую модель, а второе - в ней? А как у вас можно проверить состояние одобрения? 3) нужно для каждого по отдельному приложению сделать?:) P.S. Пример выше - выдуманный Да. Это разные классы\сущности: Код: java 1. 2. 3.
Возможно в общей иерархии наследования, но не обязательно. Никаких флагов "isSeniorManager" не должно быть. Это неправильное объектное моделирование. Роль пользователя это его поведение, а не статус. Это кстати одна из основных ошибок в Spring Security - у них какой-то декларативный полиморфизм в виде hasRole(..) сделан. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:03 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras, dakeirasДа. Это разные классы\сущности: А если в другом автосалоне 5 ролей - то им нужно отдельную версию с 5 классами делать? Coolstory. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:06 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch dakeiras, dakeirasДа. Это разные классы\сущности: А если в другом автосалоне 5 ролей - то им нужно отдельную версию с 5 классами делать? Coolstory. Да. А что, Вам классов жалко? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:07 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras mayton пропущено... Приведите пример, когда это плохо? Вы купили Единый проездной на 1 неделю, он включает: - Автобус - Трамвай - Метро Но через 3 дня из тарифа убирают Трамвай. Ваш Единый это тоже затрагивает, т.к. он содержит только привязку к тарифу, но не указывает какие конкретно он разрешает виды транспорта. А по хорошему, должно было затронуть только билеты выпущенные после изменения правил доступа. Можно добавить проверку на дату\время конечно, но это костыль в данном случае. Я не вижу тут особой проблемы. Уменьшай действие токена до 1 суток или до 1 часа и получишь безопасность управляемую с нужной филегранностью. Искать перфекционизма здесь невозможно т.к. все алгоритмы криптографии и инфо-безопасности являются компромиссом между нагрузкой на вычисления и полезным эффектом. Вряд-ли законы меняются чаще чем 1 раз в сутки. И если человек уволен сегодня то через сутки его токен экспарится (чел к тому времени подписал обходной лист и получил на руки расчет) и все доступы для него уже закрыты. Тоесть это не идеологическая проблема а настроечная. Настраивай срок токена так как тебе удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:10 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Lelouch dakeiras, пропущено... А если в другом автосалоне 5 ролей - то им нужно отдельную версию с 5 классами делать? Coolstory. Да. А что, Вам классов жалко? :) Нет. Я коробку продавать хочу, а не допиливать классы в зависимости от того, кто к кому за подписью ходит. При том что эта структура еще и изменяться будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:11 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
[quot mayton#22136481] dakeiras Я не вижу тут особой проблемы. Уменьшай действие токена до 1 суток или до 1 часа и получишь безопасность управляемую с нужной филегранностью. Искать перфекционизма здесь невозможно т.к. все алгоритмы криптографии и инфо-безопасности являются компромиссом между нагрузкой на вычисления и полезным эффектом. Вряд-ли законы меняются чаще чем 1 раз в сутки. И если человек уволен сегодня то через сутки его токен экспарится (чел к тому времени подписал обходной лист и получил на руки расчет) и все доступы для него уже закрыты. Тоесть это не идеологическая проблема а настроечная. Настраивай срок токена так как тебе удобно. Согласен, текущая схема существует, это не критично. Но просто иллюстрирует продуманность решения в "Ascend", именно с точки зрения предсказуемой абстрактной модели безопасности. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:13 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Это надо страховую вовлекать для покрытия рисков. Ну так вовлекайте. Или вы предлагаете клиенту платить вам + самостоятельно страховать риски?) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:14 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch dakeiras пропущено... Да. А что, Вам классов жалко? :) Нет. Я коробку продавать хочу, а не допиливать классы в зависимости от того, кто к кому за подписью ходит. При том что эта структура еще и изменяться будет. Можно параметризовать однотипные Identity. Это избавит от необходимости делать отдельные сущности в CRM. И ещё сильнее сократит настройку. Но админ это 100% другая сущность. Админ не должен иметь доступ к функционалу пользователя (например фин. трасферы). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:17 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch dakeiras Это надо страховую вовлекать для покрытия рисков. Ну так вовлекайте. Или вы предлагаете клиенту платить вам + самостоятельно страховать риски?) Я пока инвестора не нашёл для этого проекта. И не уверен что вообще найду. Возможно придётся самому всё доделывать своими силами. Тогда там будет отказ от отвественности в T&Cs. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:19 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Правильно делать отдельные приложения для юзеров и отдельные для админов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:25 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Lelouch пропущено... Нет. Я коробку продавать хочу, а не допиливать классы в зависимости от того, кто к кому за подписью ходит. При том что эта структура еще и изменяться будет. Можно параметризовать однотипные Identity. Это избавит от необходимости делать отдельные сущности в CRM. И ещё сильнее сократит настройку. Но админ это 100% другая сущность. Админ не должен иметь доступ к функционалу пользователя (например фин. трасферы). Вообще-то мой вопрос был в том, как это реализовать, базируясь на вашей системе. Видимо никак. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:26 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch Вообще-то мой вопрос был в том, как это реализовать, базируясь на вашей системе. Видимо никак. Там же есть в том же файле настроечном админский доступ. Всё видно как делать. Ascend абстрактно спроектирован, он ничего не знает ни о пользователях, ни о ролях и т.д. Он оперирует только 5 сущностями: - Authorization - Identity - Authentication - Scope - Grant авторКлассный пример из сторонней области. Вот вам более релевантный: 1) Злоумышленник узнал мой логин и пароль. Я срочно звоню админу с просьбой срезать мне все права. Злоумышленник продолжает спокойно работать со старым токеном. Прекрасное решение, я считаю. 2) Стажеру Васе случайно дали право на функцию "Achtung!!! Налоговая! Отправить сервер с черной бухгалтерией в космос!!!", но спохватились и через 10 секунд забрали. Но у Васи видимо доступ должен остаться :) Сорри пропустил этот комментарий. Для этого существует опциональный механизм Refresh, он нативно поддерживается в Ascend. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:34 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
авторПотом окажется, что у пользователей существуют функциональные и организационные роли, для которых тоже "надо делать отдельные приложения"? Это чрезвычайно плохая практика менять ГУЙ в зависимости от "роли пользователя". Древнее зло бизнес анализа, до сих пор живущее - при том по всему миру. Надо показывать все существующие опции в теории доступные юзеру в его иерархии step up авторизаций. Даже если он не является кем-то, кто имеет доступ до этих опций. Т.е. Менеджер видит меню Старшего Менеджера - и может позвать его чтобы тот от своего имени провёл операцию. Это - хорошая практика. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:39 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
В общем полиморфирующий ГУЙ это неправильно концептуально. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:50 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Lelouch Вообще-то мой вопрос был в том, как это реализовать, базируясь на вашей системе. Видимо никак. Там же есть в том же файле настроечном админский доступ. Всё видно как делать. Ascend абстрактно спроектирован, он ничего не знает ни о пользователях, ни о ролях и т.д. Он оперирует только 5 сущностями: - Authorization - Identity - Authentication - Scope - Grant Получается, для достижения указанных целей разработчик должен 1) Иметь возможность получить объект с информацией о разрешениях пользователя (я могу сильно ошибаться, но сейчас "разрешения" это набор регулярных выражений. Работать с этим на уровне кода нереально) 2) Написать код, который будет выполнять эти проверки ( вы считаете такой код - ошибкой дизайна ) P.S. Я все таки хочу получить ответ, как с помощью вашего решения реализовать указанный сценарий. Причем, без кода на уровне защищаемого приложения. На данный момент я считаю что это невозможно. На тему сравнения вашего решения со Spring Security: сравнение с Keycloak было бы более релевантно ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:58 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch, Посмотрите классы AdminValidator и UserValidator. Всё что требуется от CRM системы - опубликовать публичный сервис валидации идентичности по GUID: validateUser/{guid}: 2xx либо 500 в случае неспешной валидации. validateAdmin/{guid} Там полностью настроенный пример лежит в файле, с админом и юзером. Proof of concept уже был сделан полностью и отлично работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:09 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Lelouch, Посмотрите классы AdminValidator и UserValidator. Всё что требуется от CRM системы - опубликовать публичный сервис валидации идентичности по GUID: validateUser/{guid}: 2xx либо 500 в случае неспешной валидации. validateAdmin/{guid} Там полностью настроенный пример лежит в файле, с админом и юзером. Proof of concept уже был сделан полностью и отлично работает. При чем тут идентичность по ID? Каким образом эта идентичность позволит мне проверить что пользователь не может сделать 11 скидку или для текущего действия надо обратиться для подтверждения к другому пользователю? Пример посмотрел, API ужасен (метод принимает 2 мапы и возвращает 1 мапу). Привязаться к действию там тоже нельзя. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:28 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch, это вы на уровне PrototypeAuthorization настраиваете. Аутентификация сделано полностью абстрактно от её использования. Про Мапы: принимает Public и Private credentials, возвращает Authorized credentials. Я оч. долго перебирал как это упаковать, но лучшего варианта не нашёл, чем в просто мамы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:32 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Lelouch, это вы на уровне PrototypeAuthorization настраиваете. Аутентификация сделано полностью абстрактно от её использования. Про Мапы: принимает Public и Private credentials, возвращает Authorized credentials. Я оч. долго перебирал как это упаковать, но лучшего варианта не нашёл, чем в просто мамы. Все еще жду примера настройки на уровне чего угодно в вашей системе. Предупреждая дальнейшие "на уровне": PrototypeAuthorization - содержит информацию о PrototypeIdentity и PrototypeScope. PrototypeScope - содержит информацию о PrototypeGrant, который представляет из себя несколько регулярных выражений. Как мне набором регулярных выражений выполнить указанные проверки. Приведите пример пожалуйста. Естественно в запросе на скидку нет количества скидок, уже сделанных за сегодня - мы ведь не доверяем состоянию клиента. Или вы согласны, что ваше решение позволяет только проверить есть или нет доступа к конкретному ресурсу, больши ничего не умеет и ни для чего другого не предназначено. В таком случае хотелось бы увидеть сравнение с другими решениями, которые тоже это умеют. Например, можете сравнить с keycloak (по-моему, он это тоже умеет) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:41 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch, Понял, что требуется пример. Подготовил (ниже это PrototypeAuthorizations): Manager (3 скидки): Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Senior Manager (10 скидок): Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 18:03 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
В ServerAuthorizationValidationService проверяется maxUsageCount. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 18:06 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras Это чрезвычайно плохая практика менять ГУЙ в зависимости от "роли пользователя". Ещё можно было получить пронумерованный список команд. И тоже с дырками в нумерации. Если хоть чуть-чуть подумать, то это очень удобно: если вы помните, что у команды номер 231, то этот номер не будет зависеть от уровня ваших полномочий, хотя вы можете никогда не узнать, какие команды "скрыты" под номерами 230 или 232. С терминалом тоже самое - вы можете быть уверены, что F16 это всегда одно и тоже действие и даже можете "тыкать мышкой" в одно и тоже место экрана, не опасаясь "неожиданной реакции".Древнее зло бизнес анализа, до сих пор живущее - при том по всему миру.Это вы ничего слаще морковки не пробовали.Надо показывать все существующие опции в теории доступные юзеру в его иерархии step up авторизаций. Даже если он не является кем-то, кто имеет доступ до этих опций."Да за это убивать надо!" (ц) судья из анекдота про преферансиста. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 19:36 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
dakeiras, Это ни разу не решение. Скидка считается применённой после формирования заказа, а не просто от нажатия кнопки на фронте. То есть условный вызов выглядит примерно так: POST /order { ..., discount: true, ... } Кстати, заказ может быть отменён после формирования. Ваш maxUsage от этого тоже обратно не увеличится. Итого пока что ваше решение позволяет только защищать ресурсы и для реализации более менее простой логики вне этого сценария не расширяемо. P.S. Ваш подход теоретически возможен, но потребует передачи идентификатора заказа в url и сессии на be. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 19:44 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Lelouch dakeiras, Это ни разу не решение. Скидка считается применённой после формирования заказа, а не просто от нажатия кнопки на фронте. То есть условный вызов выглядит примерно так: POST /order { ..., discount: true, ... } Кстати, заказ может быть отменён после формирования. Ваш maxUsage от этого тоже обратно не увеличится. Итого пока что ваше решение позволяет только защищать ресурсы и для реализации более менее простой логики вне этого сценария не расширяемо. P.S. Ваш подход теоретически возможен, но потребует передачи идентификатора заказа в url и сессии на be. В данном случае количество скидок - конечный ресурс. Поэтому его надо располагать на стороне ресурсного сервера, а не в авторизационном сервере. Доступ к ресурсам даётся по идентичности, но наличие ресурсов контролируется в ресурсном сервере - что логично. Код: 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.
авторКстати, заказ может быть отменён после формирования. Ваш maxUsage от этого тоже обратно не увеличится. Это уже есть в плане на доработку, для неиспользованных expired авторизаций вызывать откат аутентификаций. Пока только начинаю продумывать как это сделать правильно концептуально. Это классический пример счётчиков\лимитов\доступного остатка\баланса. Это то для чего в первую очередь эта система создавалась - чтобы гарантировать отработку функционального API при валидной авторизации. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 20:04 |
|
Spring Security имеет неверную архитектуру
|
|||
---|---|---|---|
#18+
Basil A. Sidorov, Раз вы работали на мейнфрейме, Вам понравится мой транспилятор Кобола: https://github.com/INFINITE-TECHNOLOGY/COBOL ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 20:25 |
|
|
start [/forum/topic.php?fid=59&msg=39959979&tid=2120795]: |
0ms |
get settings: |
26ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
456ms |
get tp. blocked users: |
1ms |
others: | 307ms |
total: | 871ms |
0 / 0 |