Зачем структуру то?

Просто балете в шапке ссылки:
/manager
/seniorManager

И т.д.

При нажатии проверяется доступ к этому функционалу. Если нет - не пускает и всё.

А делать кашу в общей вьюшке меняющуюся и скачущую - вот за это надо убивать.

Transpiler никогда не слышали? Babel там?

Да что там знать то, при нормально спроектированном API всё что требуется:

- User:
\/secured\/user\/%username\/.*

- Admin:
\/secured\/admin\/%adminname%\/.*

автор1) каким образом ресурсный сервис узнаёт роль пользователя, если ваша система ее не предоставляет. И в том числе не предоставляет api для ее получения?
2) то есть вы наконец признаёте, что «защитить» что-либо кроме «ресурсов» ваша система не может. И в сложную логику тоже не может. Из чего вытекает не «защитите своё приложение легко и бесплатно без регистрации и смс» а «слелайте так, чтобы обойти ограничения моего решения и может быть будет вам счастье (только не забудьте закинуть денег)»
3) сравнения с keycloak ждать?
Конечно признаю, я этого не отрицал а наоборот подчёркивал.
Система для контроля доступа к веб ресурсам (HTTP->REST, SOAP, HTML (?)).
Она простая как топор сама по себе.

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

Да, почитал, это не мейнфрейм, другой тип компьютера. Кобол в нём кстати тоже поддерживался.

авторСравнения с keycloak то ждать или нет?:) Или понимайте, что там без шансов?)
оно очень похоже. ОЧЕНЬ похоже.

Но у меня более продуманно.

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

авторКстати, тупой вопрос - как в вашем решении вообще корректно перенаправить пользователя после входа на "правильный" url (пусть будет ваш любимый /user или /admin) ?:)
Это REST URLы.

Веб сайты с ГУЁм будут отдельные:

https://mycoolsystem.com

https://admin.mycoolsystem.com или https://mycoolsystem.com/admin (без автоматической переадресации и без доступа к юзерскому бизнес функционалу)

И пара абстрактных моментов:
- keycloak и ascend одновременно примерно начали делать в ~2016
- keycloak делает вроде redhat, по идее нормальная организация - поэтому вроде неплохо у них получилось
- OAuth2, IETF/RFC - это шизофазийный лингвистический ужас.
- Всё это вместе (Okta, Keycloak, Auth0, etc) разрозненно, плохо кореллируется с Spring Security и OAuth2 и Openidconnect.
В результате возникает каша.

Я о keycloak узнал только от вас. Хотя темой занимаюсь с 2016 года, по мере своих сил делал исследования решений.
Надо сказать отдельное спасибо stackoverflow который засрал выборки в поисковиках.

Вы считаете индусы осилят это всё? Или они осилят RFC? А кто должен кодить тогда за копейки?

Если это такой хороший формат, почему он не общепринятый? (а если он общепринятый, где об этом инфа везде?)

Это кризис веб безопасности. REST существует уже 15 лет. А безопасность до сих пор не стандартизированна на инфраструктурном уровне. Где RESTS (REST Secured), я вас спрашиваю?

Какова стоимость внедрения и поддержки этих решений? Каковы риски уязвимостей из-за неправильной настройки и не полноценной модели безопасности?

И вишенка на торте: 99% людей уверены что всё заебись и всё чётко, надо лишь зайти на stackoverflow - там за 5 минут будет рецепт как сделать безопасность :)
Индусы свято верят в то что Спринг умеет вообще всё на свете.

Страшно подумать сколько уязвимостей на этом уровне существует. Хакеры просто пока не дошли до этих атак.

PS: только безопасникам это не говорите, пусть будут блаженны в своём неведении.

Ну и кому организации должны доверять веб безопасность? Чтобы философски осмыслить всё это, требуется годы.
Вы посадите человека реального эксперта по Яве, думаете он будет вникать в тонкости создания модели безопасности?
Любой человек поскорее накидает что-то в настройках, лишь бы QA прошло, и всё. И спит спокойно.

авторТо есть если у меня пара десятков функциональных ролей я должен 20 интерфейсов нарисовать?
Да. При этом это хорошая практика.
Видите, Ascend вас заставляет следовать конвенции правильной.

Но конечно 20 маппингов не надо делать. Делаете такой просто:




Т.е. предиката безопасности должна присутствовать на ифраструктурном уровне (на транспортном уровне - в URL).
Это именно то как задумывался изначально REST, и я вам более того скажу - это было специально изначально заложено в HTTP его создателями.

авторКстати, keycloak был выпущен в 2014 году
Это они пусть не лечат. Может где-то в недрах Red Hat (который платный вполне себе).

авторПока эта "конвенция" правильна только с ваших слов. Можно ссылки на что-то поавторитетнее?
Нету. Но согласитесь конвенция правильная?

авторА если у пользователя несколько ролей? В том числе зависящих, откуда он в систему заходит? (Да, такое бывает, в одном филиале ты менеджер, в другом - старший менеджер. Где находится АРМ в который входит пользователь - известно).
Хотя о чем я спрашиваю, вы опять будете что-то веселое рассказывать вместо ответов.
Основной юскейс Ascend - единственная роль пользователя + Step Up (многоуровневый: T&Cs + Privacy Policy + Login +SMS OTP + ...)

То о чём Вы говорите - наверное лучше какие-то другие решения использовать (возможно тот же Spring Security). Я никогда не говорил что Ascend универсален в чистом виде.

Всё что я говорил - что Spring Security для наиболее частого юскейса веб приложений и мобильных приложений - неправилен.
Keycloak только подтвердил это.

Наверное Вы хотите сказать:

Веб безопасность: Keycloak
+ одновременно
Функциональный доступ: Spring Security

Наверное соглашусь.

Ascend здесь альтернатива Keycloak.