Okta Kentor.AuthServices IdentityServer3 SSO, инициированная IDP, запускает SSO, инициируемую SP - ошибка или дизайн?

Question

Используя IdentityServer3, Kentor.AuthServices 0.19 (с промежуточным ПО OWIN) и стандартное приложение MVC 4 WebApi 2, мы следовали инструкциям по адресу https://github.com/KentorIT/authservices/blob/master/doc/IdentityServer3Okta.md и он появился что мы добились успешного входа в систему по инициативе IDP.

Однако, когда мы внимательно посмотрели на это и, используя KentorStubIdp (где мы впервые заметили, что нас попросили предоставить ответ SAML), мы обнаружили следующее

1. IDP достигает нашей конечной точки, например, identityserver / okta / acs, статус 303
2. Успешное перенаправление на нашу конечную точку перенаправления в нашем приложении, которое закодировано, чтобы вернуть перенаправление на конечную точку авторизации сервера идентификации, таким образом var client = new AuthorizeRequest(new Uri(identityServerUrl + "connect/authorize")); var returnUrlForIdp = client.CreateAuthorizeUrl( "{client_identifier}", "id_token token", scopesForAuth, hostUrl, state, nonce, acrValues: string.Format("idp:{0}", idp), responseMode: "form_post" ); return Redirect(returnUrlForIdp);
3. Это приводит к 302 для идентификационного сервера / подключения / авторизации. Похоже, что здесь есть вся необходимая информация для входа в систему, и я бы ожидал 200 прямо в приложении, но вместо этого мы получаем 302 для identityserver/login? Signin=xxx, которое дает 401, который, кажется, срабатывает...
4. Последующий вызов к конечной точке входа в систему возвращает перенаправление 303 обратно в IDP, что отмечает начало в конечном счете успешного входа, инициированного SP. Это означает, что он возвращается к identityserver / okta / acs, затем к конечной точке / callback, затем / connect / authorize, после чего пользователь входит в систему.

Я не могу найти какой-либо значимой разницы между первым и вторым вызовами / connect / authorize, кроме

1. Успешная попытка предшествует вызовом identityserver / callback
2. Файлы cookie для idsvr и idsvr.session, по-видимому, не устанавливаются при первом вызове, но находятся во втором

Кроме того, настройки конфигурации Kentor, кажется, в порядке - например, AllowUnsolicitedAuthnResponse = true а также AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Passive хотя этот последний, казалось, не имел эффекта в любом случае

На данный момент я просто пытаюсь решить: а) так ли это должно работать под одеялом и б) если нет, где я должен сосредоточить свое внимание на диагностике проблемы.

Существует ли конкретный набор защитных обстоятельств, которые запускают authservices для инициирования SP-запроса SAML, если a, инициированному IDP, не хватает информации?

Любой совет высоко ценится.

Answer 1

Использование входа по протоколу Idp с SAML2 + OIDC немного сложнее, так как OIDC его не поддерживает. Это означает, что IdSrv3 на самом деле не создан для этого сценария.

Вот что вам нужно:

1. Idp отправляет незапрошенный ответ IdSrv3 / AuthServices.
2. AuthServices проверяет ответ
3. IdSrv3 устанавливает сеанс входа в систему на IdSrv3.
4. Пользователь перенаправлен на URL-адрес для входа в клиентское приложение
5. Клиентское приложение инициирует подписку OIDC в ​​направлении IdSrv3.
6. IdSrv3 Единый вход с сеансом, установленным в 3.
7. Пользователь перенаправляется обратно в клиентское приложение.

Похоже, шаг 2 работает, но шаг 3 не выполнен должным образом. Это означает, что на шаге 6 сеанс отсутствует, поэтому пользователь перенаправляется полностью к Idp, чтобы забрать существующий сеанс. Это работает, но несколько уродливо. И если позже вы захотите сделать единый выход, существует несоответствие количества сеансов, которое может вызвать проблемы.