Я внедряю сервис-провайдер SAML 2.0 SSO golang на переднем канале с Okta в качестве моего провайдера идентификации (это всего лишь POC, и в конечном итоге он должен работать с любым IdP).
Реализация процесса входа в систему была простойс saml2 пакетом. Я создал конечную точку входа в систему, которая перенаправляет на URL-адрес входа приложения SAML в заданном IdP, а также конечную точку обратного вызова POST, которая правильно получает утверждение SAML и может его проверить. После этого session со случайным cookie создается с тем же TTL, что и TTL сеанса Identity Provider. Пока все работает хорошо (я еще не реализовал Single Sign-Out, но планирую).
Однако, когда пройдет некоторое время и истечет время сеанса, я бы хотел его продлить только если пользователь все еще вошел в систему с Idp и не был удален из приложения SAML . Я хотел бы избежать перенаправления пользователя для повторного выполнения единого входа с IdP, поскольку это будет означать, что если они все еще будут в системе, они будут перенаправлены обратно на домашнюю страницу моего приложения. Я не смог найти отличных источников по своим опциям, чтобы узнать об этом в Интернете.
Вопросы:
1.1 Одно из решений, которое приходит на ум, - сохранить запрошенный URL-адрес в параметре RelayStateвсякий раз, когда сеанс истек, затем перенаправьте пользователя на URL единого входа IdP. Когда перенаправление возвращается к конечной точке POST обратного вызова SAML, проверьте параметр RelayState и, если установлено, перенаправьте обратно на этот (оригинальный) URL. Это означает, что для пользователей, которые используют систему постоянно, мне придется очень часто запрашивать утверждения. Имеет ли это смысл?
1.2 Второе решение, которое приходит на ум, - реализовать обратный канал связи напрямую от моего SP к IdP. Это позволило бы мне убедиться, что пользователь все еще вошел в систему «за спиной пользователя». Если это хорошая идея:
a. Нужно ли иметь выделенный код для каждого IdP?
b. Нужно ли загружать в IdP ключ API, который бы позволял безопасную связь?
c. Нужно ли загружать общедоступный сертификат в IdP, который сможет подтвердить, что мой SP подписал запросы?
Поможет ли
использование утверждения для получения токена доступа OAuth 2.0 помочь мне в достижении этого?
На данный момент я выбрал SAML 2.0, поскольку среда ориентирована на предприятие, и я подумал, что она хорошо согласуется с тем, что я читаю. Поможет ли использование OpenID Connect вместо этого облегчить достижение моих целей и хорошо вписаться в корпоративные продукты?