Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
автор
P.S. А что если у меня приложение с сессиями и url + body ни разу не достаточны для понимания, что делает пользователь?

Пока условно пусть будет что Stateful не поддерживается.

автор
Кстати, а что будет, если я защищу что-либо вашей системой, а ее взломают? Сколько вы мне денег в таком случае заплатите?


Это надо страховую вовлекать для покрытия рисков.

автор
"Менеджер" в автосалоне может сделать 2 скидки в день, а "старший менеджер" - 10.
Одновременно с этим "менеджер" не может продать машину без одобрения "старшего менеджера".
1) Видимо кто-то из них "админ", а кто-то "юзер"?:)
2) Вы видимо предлагаете реализовать 1 ограничение минуя правовую модель, а второе - в ней? А как у вас можно проверить состояние одобрения?
3) нужно для каждого по отдельному приложению сделать?:)
P.S. Пример выше - выдуманный

Да. Это разные классы\сущности:
class Manager {...}

class SeniorManager {...}


Возможно в общей иерархии наследования, но не обязательно.
Никаких флагов "isSeniorManager" не должно быть. Это неправильное объектное моделирование.
Роль пользователя это его поведение, а не статус. Это кстати одна из основных ошибок в Spring Security - у них какой-то декларативный полиморфизм в виде hasRole(..) сделан.
20 май 20, 16:03    [22136472]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras,

dakeiras
Да. Это разные классы\сущности:

А если в другом автосалоне 5 ролей - то им нужно отдельную версию с 5 классами делать? Coolstory.
20 май 20, 16:06    [22136477]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch
dakeiras,

dakeiras
Да. Это разные классы\сущности:

А если в другом автосалоне 5 ролей - то им нужно отдельную версию с 5 классами делать? Coolstory.


Да. А что, Вам классов жалко? :)
20 май 20, 16:07    [22136478]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
dakeiras
mayton
пропущено...

Приведите пример, когда это плохо?


Вы купили Единый проездной на 1 неделю, он включает:
- Автобус
- Трамвай
- Метро

Но через 3 дня из тарифа убирают Трамвай. Ваш Единый это тоже затрагивает, т.к. он содержит только привязку к тарифу, но не указывает какие конкретно он разрешает виды транспорта.

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

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

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

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

Тоесть это не идеологическая проблема а настроечная. Настраивай срок токена так как тебе удобно.
20 май 20, 16:10    [22136481]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras
Lelouch
dakeiras,

пропущено...

А если в другом автосалоне 5 ролей - то им нужно отдельную версию с 5 классами делать? Coolstory.


Да. А что, Вам классов жалко? :)

Нет. Я коробку продавать хочу, а не допиливать классы в зависимости от того, кто к кому за подписью ходит. При том что эта структура еще и изменяться будет.
20 май 20, 16:11    [22136484]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
[quot mayton#22136481]
dakeiras

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

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

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

Согласен, текущая схема существует, это не критично. Но просто иллюстрирует продуманность решения в "Ascend", именно с точки зрения предсказуемой абстрактной модели безопасности.
20 май 20, 16:13    [22136489]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras


Это надо страховую вовлекать для покрытия рисков.


Ну так вовлекайте. Или вы предлагаете клиенту платить вам + самостоятельно страховать риски?)
20 май 20, 16:14    [22136490]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch
dakeiras
пропущено...


Да. А что, Вам классов жалко? :)

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


Можно параметризовать однотипные Identity. Это избавит от необходимости делать отдельные сущности в CRM.
И ещё сильнее сократит настройку.

Но админ это 100% другая сущность. Админ не должен иметь доступ к функционалу пользователя (например фин. трасферы).

Сообщение было отредактировано: 20 май 20, 16:18
20 май 20, 16:17    [22136493]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch
dakeiras


Это надо страховую вовлекать для покрытия рисков.


Ну так вовлекайте. Или вы предлагаете клиенту платить вам + самостоятельно страховать риски?)


Я пока инвестора не нашёл для этого проекта. И не уверен что вообще найду.
Возможно придётся самому всё доделывать своими силами. Тогда там будет отказ от отвественности в T&Cs.
20 май 20, 16:19    [22136494]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
dakeiras
Правильно делать отдельные приложения для юзеров и отдельные для админов.
Потом окажется, что у пользователей существуют функциональные и организационные роли, для которых тоже "надо делать отдельные приложения"?
Это улучшает качество кода, упрощает тестирование и внесение изменений.
Ню-ню.
20 май 20, 16:25    [22136498]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras
Lelouch
пропущено...

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


Можно параметризовать однотипные Identity. Это избавит от необходимости делать отдельные сущности в CRM.
И ещё сильнее сократит настройку.

Но админ это 100% другая сущность. Админ не должен иметь доступ к функционалу пользователя (например фин. трасферы).


Вообще-то мой вопрос был в том, как это реализовать, базируясь на вашей системе. Видимо никак.
20 май 20, 16:26    [22136499]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch
Вообще-то мой вопрос был в том, как это реализовать, базируясь на вашей системе. Видимо никак.


Там же есть в том же файле настроечном админский доступ. Всё видно как делать.

Ascend абстрактно спроектирован, он ничего не знает ни о пользователях, ни о ролях и т.д.
Он оперирует только 5 сущностями:
- Authorization
- Identity
- Authentication
- Scope
- Grant

автор
Классный пример из сторонней области. Вот вам более релевантный:
1) Злоумышленник узнал мой логин и пароль. Я срочно звоню админу с просьбой срезать мне все права. Злоумышленник продолжает спокойно работать со старым токеном. Прекрасное решение, я считаю.
2) Стажеру Васе случайно дали право на функцию "Achtung!!! Налоговая! Отправить сервер с черной бухгалтерией в космос!!!", но спохватились и через 10 секунд забрали. Но у Васи видимо доступ должен остаться :)


Сорри пропустил этот комментарий. Для этого существует опциональный механизм Refresh, он нативно поддерживается в Ascend.
20 май 20, 16:34    [22136504]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
автор
Потом окажется, что у пользователей существуют функциональные и организационные роли, для которых тоже "надо делать отдельные приложения"?


Это чрезвычайно плохая практика менять ГУЙ в зависимости от "роли пользователя".
Древнее зло бизнес анализа, до сих пор живущее - при том по всему миру.

Надо показывать все существующие опции в теории доступные юзеру в его иерархии step up авторизаций.
Даже если он не является кем-то, кто имеет доступ до этих опций.

Т.е. Менеджер видит меню Старшего Менеджера - и может позвать его чтобы тот от своего имени провёл операцию.
Это - хорошая практика.
20 май 20, 16:39    [22136508]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
В общем полиморфирующий ГУЙ это неправильно концептуально.
20 май 20, 16:50    [22136525]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras
Lelouch
Вообще-то мой вопрос был в том, как это реализовать, базируясь на вашей системе. Видимо никак.


Там же есть в том же файле настроечном админский доступ. Всё видно как делать.

Ascend абстрактно спроектирован, он ничего не знает ни о пользователях, ни о ролях и т.д.
Он оперирует только 5 сущностями:
- Authorization
- Identity
- Authentication
- Scope
- Grant


Получается, для достижения указанных целей разработчик должен
1) Иметь возможность получить объект с информацией о разрешениях пользователя (я могу сильно ошибаться, но сейчас "разрешения" это набор регулярных выражений. Работать с этим на уровне кода нереально)
2) Написать код, который будет выполнять эти проверки ( вы считаете такой код - ошибкой дизайна )

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

На тему сравнения вашего решения со Spring Security: сравнение с Keycloak было бы более релевантно
20 май 20, 16:58    [22136536]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch,

Посмотрите классы AdminValidator и UserValidator.

Всё что требуется от CRM системы - опубликовать публичный сервис валидации идентичности по GUID:

validateUser/{guid}:

2xx либо 500 в случае неспешной валидации.

validateAdmin/{guid}

Там полностью настроенный пример лежит в файле, с админом и юзером.

Proof of concept уже был сделан полностью и отлично работает.
20 май 20, 17:09    [22136541]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras
Lelouch,

Посмотрите классы AdminValidator и UserValidator.

Всё что требуется от CRM системы - опубликовать публичный сервис валидации идентичности по GUID:

validateUser/{guid}:

2xx либо 500 в случае неспешной валидации.

validateAdmin/{guid}

Там полностью настроенный пример лежит в файле, с админом и юзером.

Proof of concept уже был сделан полностью и отлично работает.


При чем тут идентичность по ID?
Каким образом эта идентичность позволит мне проверить что пользователь не может сделать 11 скидку или для текущего действия надо обратиться для подтверждения к другому пользователю?
Пример посмотрел, API ужасен (метод принимает 2 мапы и возвращает 1 мапу). Привязаться к действию там тоже нельзя.
20 май 20, 17:28    [22136554]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch,

это вы на уровне PrototypeAuthorization настраиваете.

Аутентификация сделано полностью абстрактно от её использования.

Про Мапы: принимает Public и Private credentials, возвращает Authorized credentials.

Я оч. долго перебирал как это упаковать, но лучшего варианта не нашёл, чем в просто мамы.
20 май 20, 17:32    [22136561]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras
Lelouch,

это вы на уровне PrototypeAuthorization настраиваете.

Аутентификация сделано полностью абстрактно от её использования.

Про Мапы: принимает Public и Private credentials, возвращает Authorized credentials.

Я оч. долго перебирал как это упаковать, но лучшего варианта не нашёл, чем в просто мамы.


Все еще жду примера настройки на уровне чего угодно в вашей системе.
Предупреждая дальнейшие "на уровне":
PrototypeAuthorization - содержит информацию о PrototypeIdentity и PrototypeScope.
PrototypeScope - содержит информацию о PrototypeGrant, который представляет из себя несколько регулярных выражений.
Как мне набором регулярных выражений выполнить указанные проверки. Приведите пример пожалуйста.
Естественно в запросе на скидку нет количества скидок, уже сделанных за сегодня - мы ведь не доверяем состоянию клиента.

Или вы согласны, что ваше решение позволяет только проверить есть или нет доступа к конкретному ресурсу, больши ничего не умеет и ни для чего другого не предназначено.
В таком случае хотелось бы увидеть сравнение с другими решениями, которые тоже это умеют.
Например, можете сравнить с keycloak (по-моему, он это тоже умеет)

Сообщение было отредактировано: 20 май 20, 17:46
20 май 20, 17:41    [22136566]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch,

Понял, что требуется пример.

Подготовил (ниже это PrototypeAuthorizations):


Manager (3 скидки):
{
      "name" : "managerAuthorization",
      "identities" : [ {
        "name" : "manager",
        "authentications" : [ {
          "name" : "kerberos"
        }, {
          "name" : "managerGroupMember"
        } ]
      } ],
      "scopes" : [ {
        "name" : "managerScope",
        "grants" : [ {
          "urlRegex" : "https:\\/\\/resourceserver\\.com\\/contentroot\\/secured\\/discount",
          "bodyRegex" : null,
          "httpMethod" : "POST"
        } ]
      } ],
      "durationSeconds" : 1800,
      "maxUsageCount" : 3,
      "prerequisites" : [ ],
      "refresh" : null
}


Senior Manager (10 скидок):
{
      "name" : "seniorManagerAuthorization",
      "identities" : [ {
        "name" : "seniorManager",
        "authentications" : [ {
          "name" : "kerberos"
        }, {
          "name" : "seniorManagerGroupMember"
        } ]
      } ],
      "scopes" : [ {
        "name" : "managerScope",
        "grants" : [ {
          "urlRegex" : "https:\\/\\/resourceserver\\.com\\/contentroot\\/secured\\/discount",
          "bodyRegex" : null,
          "httpMethod" : "POST"
        } ]
      } ],
      "durationSeconds" : 1800,
      "maxUsageCount" : 10,
      "prerequisites" : [ ],
      "refresh" : null
}


Сообщение было отредактировано: 20 май 20, 18:07
20 май 20, 18:03    [22136579]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
В ServerAuthorizationValidationService проверяется maxUsageCount.
20 май 20, 18:06    [22136583]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
dakeiras
Это чрезвычайно плохая практика менять ГУЙ в зависимости от "роли пользователя".
Когда я работал на терминале OS/400, то некоторое время удивлялся пустому пространству в менюшках. Пока не увидел эти же менюшки на терминале коллеги с ролью QSECOFR. Там были действия, недоступные для меня.
Ещё можно было получить пронумерованный список команд. И тоже с дырками в нумерации.
Если хоть чуть-чуть подумать, то это очень удобно: если вы помните, что у команды номер 231, то этот номер не будет зависеть от уровня ваших полномочий, хотя вы можете никогда не узнать, какие команды "скрыты" под номерами 230 или 232.
С терминалом тоже самое - вы можете быть уверены, что F16 это всегда одно и тоже действие и даже можете "тыкать мышкой" в одно и тоже место экрана, не опасаясь "неожиданной реакции".
Древнее зло бизнес анализа, до сих пор живущее - при том по всему миру.
Это вы ничего слаще морковки не пробовали.
Надо показывать все существующие опции в теории доступные юзеру в его иерархии step up авторизаций.
Даже если он не является кем-то, кто имеет доступ до этих опций.
"Да за это убивать надо!" (ц) судья из анекдота про преферансиста.
20 май 20, 19:36    [22136657]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1849
dakeiras,

Это ни разу не решение. Скидка считается применённой после формирования заказа, а не просто от нажатия кнопки на фронте.
То есть условный вызов выглядит примерно так:
POST /order { ..., discount: true, ... }
Кстати, заказ может быть отменён после формирования. Ваш maxUsage от этого тоже обратно не увеличится.

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

P.S. Ваш подход теоретически возможен, но потребует передачи идентификатора заказа в url и сессии на be.

Сообщение было отредактировано: 20 май 20, 19:51
20 май 20, 19:44    [22136662]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Lelouch
dakeiras,

Это ни разу не решение. Скидка считается применённой после формирования заказа, а не просто от нажатия кнопки на фронте.
То есть условный вызов выглядит примерно так:
POST /order { ..., discount: true, ... }
Кстати, заказ может быть отменён после формирования. Ваш maxUsage от этого тоже обратно не увеличится.

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

P.S. Ваш подход теоретически возможен, но потребует передачи идентификатора заказа в url и сессии на be.


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

{
      "name" : "managerAuthorization",
      "identities" : [ {
        "name" : "manager",
        "authentications" : [ {
          "name" : "kerberos"
        }, {
          "name" : "managerGroupMember"
        }, {
          "name" : "discountDailyLimitCounter"
        } ]
      } ],
      "scopes" : [ {
        "name" : "managerScope",
        "grants" : [ {
          "urlRegex" : "https:\\/\\/resourceserver\\.com\\/contentroot\\/secured\\/order\\?discount=true",
          "bodyRegex" : null,
          "httpMethod" : "POST"
        } ]
      } ],
      "durationSeconds" : 1800,
      "maxUsageCount" : 1,
      "prerequisites" : [ ],
      "refresh" : null
}


автор
Кстати, заказ может быть отменён после формирования. Ваш maxUsage от этого тоже обратно не увеличится.

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

Это классический пример счётчиков\лимитов\доступного остатка\баланса. Это то для чего в первую очередь эта система создавалась - чтобы гарантировать отработку функционального API при валидной авторизации.
20 май 20, 20:04    [22136677]     Ответить | Цитировать Сообщить модератору
 Re: Spring Security имеет неверную архитектуру  [new]
dakeiras
Member

Откуда:
Сообщений: 444
Basil A. Sidorov,

Раз вы работали на мейнфрейме, Вам понравится мой транспилятор Кобола:

https://github.com/INFINITE-TECHNOLOGY/COBOL
20 май 20, 20:25    [22136688]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Java Ответить