Как перейти от решения для домашней аутентификации к использованию стандартного OpenID Identity Provider

Question

У нас есть собственное решение для аутентификации и авторизации, и мы хотели бы перейти к стандартному провайдеру идентификации, например, Keycloak. Существует ли какая-либо документация и / или носители, в которых обсуждаются лучшие подходы для интеграции поставщика идентификации, такие как Keycloak, например, такая среда, с существующими пользователями и паролями и т. Д.? Заранее благодарим за любую помощь и / или направление, которое вы можете предоставить.

Answer 1

Для вас также может быть разумным попросить всех пользователей создать новый пароль - поскольку это произойдет только один раз для каждого пользователя - если это работает для вас, мой пост может помочь вам понять варианты:

https://authguidance.com/2017/10/02/user-data/

Answer 2

Этот вопрос немного широк, но я могу затронуть одну из областей, которые я делал в прошлом. Я преобразовал решение, в котором пароли в виде открытого текста были сохранены в базе данных (!), Чтобы использовать Keycloak. Открытые текстовые пароли упрощали создание новых пользователей. Я использовал среду на основе ролей и после создания области я создал роли и пользователей с помощью командной строки kcadm.sh. Мой скрипт выглядел примерно так:

#!/bin/bash

kcadm.sh config credentials --server http://localhost:8180/auth --realm master --user admin --password the-admin-password

kcadm.sh create realms -s realm=therealm -s enabled=true -o

kcadm.sh create roles -r therealm -s name=employee -s 'description=Role to that is used by employees'

kcadm.sh create users -r therealm -s username=somebody@domain.tld -s email=somebody@domain.tld -s lastName=Body -s firstName=Some -s 'credentia
ls=[{"type":"password", "value": "the-user-password"}]' -s 'enabled=true' -s 'emailVerified=true'    

kcadm.sh add-roles --uusername somebody@domain.tld --rolename employee -r therealm

Это позволило мне создать базовый набор пользователей. Эти пользователи находились в «локальной» базе данных, а не в третьих сторонах, таких как Google или Microsoft. Конечно, если у вас нет пользовательских паролей, вы можете создать скрипт, который генерирует временный пароль, и отправлять его по электронной почте пользователям. Затем вы захотите настроить пользователей на принудительное изменение пароля.

Это преобразование представляло собой набор веб-сервисов JAX-RS в веб-приложении Java и в конечном итоге использовало пользовательский ContainerRequestFilter, который позволял мне извлекатьJWT и создать пользовательский Principal для пользователя. Я уверен, что "нормальный" фильтр сервлетов тоже может быть использован.