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

Question

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

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

1. IDP попадает на нашу конечную точку, например, identityserver/окта/ОКС статус 303
2. Успешное Перенаправление нашей Перенаправление конечной точки в нашем приложении, который кодируется для возврата перенаправлении в конечную точку авторизации identityserver, таким образом 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 к identityserver/подключения/санкционировать. Похоже, что у него есть вся необходимая информация для входа в систему, и я ожидал бы 200 прямо в приложении, но вместо этого мы получаем 302 для идентификатора/входа в систему? Signin = xxx, который дает 401, который, как представляется, запускает ...
4. Последующий вызов конечной точке входа получает перенаправление 303 обратно в IDP, что знаменует начало в конечном счете успешного входа в систему с инициативой SP. Значение возвращается к identityserver/окта/ОКС, то/обратного вызова конечная точка, то/подключения/авторизовать, то пользователь вошел в систему.

Я не могу найти каких-либо значимых различий между первым и вторым вызовами/подключить/авторизовать кроме

1. успешная попытка предваряется вызовом identityserver/обратного вызова
2. Печенье idsvr и idsvr.session как представляется, не быть установлен по первому зову, но во втором

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

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

Есть ли определенный набор циркуляций, которые запускают authservices, чтобы инициировать запрос SAML, инициированный SP, если у ID, инициированного ID, нет информации?

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

Answer 1

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

Контуры, что вам нужно будет это:

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

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