Агнец за бортомФорма аутентификации, как я понял - это механизм самого сервера, кастомизируемый (в части стилей).

Да. При чём форма может быть разной в зависимости от того, с какого приложения пришёл, а в мультитенантной системе ещё и от какого тенанта.


Агнец за бортомВообще - сервер аутентификации стремится предоставить максимум функциональности по управлению профилем пользователя, как я понял. Личный кабинет и прочая фигня.

Нет. Нет. И ещё раз нет. Сервер SSO решает только задачу авторизации и аутентификации (если не предоставляется возможность внешней аутентификации).

Никакого управления профилем пользователя.
Никакого личного кабинета.
Никакой прочей фигни.


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

Личный кабинет находится там же, где и должен. Либо в самом приложении. Либо отдельное приложение. Либо микро-сервис, размещаемый в площадке приложения.


Агнец за бортомГлавный вопрос - где надо хранить информацию о ролях/разрешениях пользователя?
На том же сервере SSO?

Нет. SSO это механизм. Он может работать с той же базой, что и ПО для выполнения аутентификации. Так как SSO выдаёт токен, авторизация происходит в приложении, который смотрит в токен, проверяет роли, клеймы и т.д. SSO только выдаёт их.

hVosttСервер SSO решает только задачу авторизации и аутентификации (если не предоставляется возможность внешней аутентификации)

Уточню про авторизацию. Речь идёт о доступе к требуемому приложению вообще, а не функциональности приложения. Это уже решается на стороне приложений.

Агнец за бортомPetro123Че так волнует личный кабинет?

Я пытаюсь понять как правильно.

Фотку меняем тут, а email - там - странна.

Всё тут. Ничего "там" делать не нужно. SSO реализует единую централизованную аутентификацию и авторизацию для множества приложений, и устройств.

Агнец за бортомhVosttВсё тут. Ничего "там" делать не нужно.

Не понимаю. Сервер SSO не предлагает загрузить фото профиля.
Но email вбить - предлагает.

Сервер SSO предлагает способы для прохождения аутентификации.
После прохождения аутентификации, SSO смотрит можно ли данному пользователю пользоваться указанным приложением. Если да, предлагает выбрать набор атрибутов безопасности (полномочий), с которым пользователь собирается заходить в приложение.

Ничего никуда там не загружается.

Агнец за бортомЯ правильно понимаю общую схему?

Пользователь запрашивает защищенный ресурс.

1.Приложение "смотрит" - is user authentic?
2.Если нет, то спрашивает у SSO - это кто?
3.SSO через свою форму проводит аутентификацию и в случае успеха...
4. Выдает токен с ролями и прочей инфой.
5. Юзер редиректирится опять в приложение уже с токеном.
6. Приложение смотрит в токен (сверяя инфу в токене с ключом)...
7. И если находит роль (если надо) - то всё ок.

Если правильно - то где прописываются роли?

Правильно. Где угодно, зависит от выбранной архитектуры.

У нас, например, всеми пользователями управляют в отдельном приложении IDM, оттуда через API приложение SSO берёт информацию, а также запрашивает пользователя по логину/паролю.

В приложение IDM тоже вход через SSO. :)

Никто не мешает тебе в приложении SSO обращаться за пользовательской информацией в одно единственное БД приложения. В общем, тут всё by design.

Агнец за бортом,

https://docs.identityblitz.ru/blitz-idp/storage/

ну вот про хранилища учётных данных

неплохое решение, кстати, взять готовый сервак, если по всем параметрам он вас устраивает
на IdentityServer4 можно запилить своё, но по сути будет тоже самое )

Petro123,

Ничего сложного )