OpenAM, OpenId, REST API, внутренние приложения: как мне их соединить?

Question

У меня возникли проблемы с связыванием всего этого вместе. Частично из-за непонимания и частично из-за того, что раньше я не использовал OpenAM.

Я пытаюсь реализовать Single Sign-on. Вот игроки.

1. OpenAm. https://www.forgerock.com/en-us/products/access-management/
2. Стороннее приложение, которое может использовать собственную базу данных имени пользователя/пароля или аутентифицироваться против поставщика SAML или OpenId.
3. Несколько внутренних приложений, написанных в виде угловых или .net-веб-форм.
4. Собственный API REST, написанный в nodejs.

Мне нужно иметь возможность входа/регистрации пользователя в openam, а затем они не входят в какое-либо другое приложение. Мы видим это по всему миру, поэтому прецедент довольно нормальный, но я никогда не реализовал его раньше.

Посмотрите, что я пытаюсь сделать, используя изображение ниже для начала.

Вот что я stuggling с:

для SSO целей, OpenAM кажется, хранить аутентификацией информацию пользователя в куки. Как мое приложение для приложений забирает этот файл cookie и использует его, если он может только аутентифицироваться через openid или saml? Он не может использовать API openam, проходя через конечные точки/json/*.

С собственными приложениями я предполагаю, что могу просто передать cookie вместе, и соответствующие стороны могут проверить информацию сессии или токена файла cookie, и все. Это правильно, или я смотрю на это неправильно?

Могу ли я войти в систему на страницу входа в OpenAm, а затем использовать/oauth2/* endpoints для проверки запросов пользователя? Я мог видеть, что это работает лучше, но я не уверен, что так оно и должно произойти.

В принципе, я чувствую, что на прошлой неделе я пробормотал свой мозг, пытаясь разобраться в этом. Мне нужна помощь, чтобы получить здесь какое-то направление. Как я сказал выше, хорошая часть этого нового. Я использовал front-end-> rest api-> базу данных, используя токен, но этот сценарий SSO дал мне настоящую головную боль.

Любая помощь будет оценена по достоинству.

Answer 1

Мне кажется, что вы пропустили аспект «перенаправления» SOML SSO. Я попытаюсь объяснить, как это работает в двух словах:

Шаг 1:

Когда пользователь отправляет запрос на один из ваших в домашних приложений (назовем его в SP е р в rovider, ИП, здесь), то SP обнаруживает, что это неавторизованный запрос и перенаправляет браузер на сервере OpenAM (назовем ее I dentity P rovider, IdP, отсюда).

Шаг 2:

IdP анализирует запрос переадресации и ожидает, чтобы найти "SAML authnResponse", это закодированные метаданные XML добавляемых в запросе перенаправления по SP. Он узнает, что ваш SP хочет аутентифицировать пользователя. IdP ответит на запрос, указав страницу входа. Здесь пользователь может аутентифицироваться на IdP. После успешной аутентификации пользователя в IdP он перенаправит его обратно на SP, добавив к запросу запрос «SAML authnResponse».

Шаг 3:

SP проанализирует эту "SAML authnResponse", который опять-таки просто форма метаданных XML. Если проверка подписи в порядке, выясните, какой пользователь успешно прошел аутентификацию, создайте для него сеанс и перенаправите его на ресурс, с которого он первоначально пытался получить доступ.

Примечание 1:

В Шаг 2, если пользователь уже аутентифицирован IdP, прежде чем он будет иметь активную сессию на IdP. IdP не потребует от него повторного входа в систему, но просто перенаправляет его обратно на SP с действительным «SAML authnResponse». Таким образом, пользователь едва заметит все эти переадресации, и он будет выглядеть так, как будто он «беспрепятственно» получил доступ к SP.

Примечание 2:

Так что не беспокойтесь, чтобы много о печенье, они используются IdP признать уже прошедших проверку подлинности пользовательских сессий и т.д., но вы должны беспокоить только переадресовывает и анализируя ответы SAML и Запросы. Имеет ли это смысл?

Примечание 3:

Путь, как браузер (GET 302 или JS POST) пользователя будет перенаправлен зависит от выбранного "SAML Profile".