Вот ситуация:
- У нас есть устаревшая система. Использование простой аутентификации пользователя / пароля + сеансовые куки. (И не используя OpenAM)
- Мы пытаемся предоставить новые услуги другой организации и, среди прочего, мы обязаны автоматически принимать их пользователей в качестве аутентифицированных после перенаправления из их веб-приложения. Нам нужна федеративная идентичность. И мы выбрали OpenAM в качестве нашего нового IAM, но наши пользовательские данные все еще находятся в устаревшей системе, и их пользователи также будут зарегистрированы в устаревших системах. Пока что пользователи не будут объединены в базу данных OpenAM
Так что грубая идея для любого сценария федерации для нас будет такой:
Они перенаправляют своего пользователя на нашу конечную точку OpenAM, которая принимает JWT (токен OIDC?), Подписанный их IdP, которому мы «доверяем», и каким-то образом, основываясь на его содержимом, OpenAM выпускает другой токен JWT и перенаправляет пользователя снова к унаследованной системе с новым токеном на предъявителя.
Разработчики в устаревшей системе создадут некоторый пользовательский код для проверки и чтения утверждений внутри токена JWT. на основе утверждений они создают аутентифицированный, привилегированный сеанс для пользователя.
Я посмотрел и нашел два возможных решения:
JWT из их IdP используется для запуска неявного потока OAuth2.0 + с использованием их JWT для аутентификации клиента (согласно RFC -7523 ) . Тогда пользователь будет использовать токен доступа. Но:
- Я хочу поместить заявки из первого JWT (некоторые из них являются пользовательскими) в токен доступа, чтобы устаревшая система использовала эту информацию для поиска пользователя в устаревшей БД и создания сеанса. Как мне сказать OpenAM включить эти утверждения в токен доступа? Обратите внимание, что в базе данных OpenAM нет информации об их пользователях. Только претензии от токена.
- Также похоже, что мы аутентифицируем их IdP, а не пользователя. Потому что аутентификация клиента JWT использует открытый ключ IdP для проверки подписи токена. Как мне сообщить OpenAM, что этот токен предназначен для "sub" этого JWT?
Используйте Rest STS (Служба токенов безопасности) в OpenAM (OIDC -> OIDC). Это выглядит лучше для нашей ситуации, но я не знаю, как сказать OpenAM проверять их токены. Документация не содержит каких-либо мер для проверки токенов? (Может быть, где-нибудь добавить свой открытый ключ?)