2013-05-07 4 views
0

Я реализую свой собственный поставщик удостоверений на основе кода Thinktecture. Вот странное поведение Azure ACS при использовании единой функции выхода, оно отличается для google/live и для моего собственного поставщика удостоверений.Azure ACS custom Identity Provider Single SignOut

URL для аккаунта (сфера действительно совпадает с именем сайта):

mysite.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0 & wreply = HTTP% 3A% 2f% 2flocalhost% 2fAdministration.Frontend.Web% 2f & wtrealm = HTTP% 3a% 2f% 2flocalhost% 2fAdministration.Frontend.Web% 2f

Вот псевдо-код выхода из системы:

//clear FedAuth cookies 
FormsAuthentication.SignOut(); 
FederatedAuthentication.WSFederationAuthenticationModule.SignOut(true); 

//call Single SignOut 
var signoutRequestMessage = new SignOutRequestMessage(new Uri(signOutUrl)); 
return Redirect(signoutRequestMessage.WriteQueryString()); 

Вот пример потока (я использую частный просмотр плюс Fiddler, чтобы увидеть все):

1) Я вхожу в мое приложение с учетной записью google.

2) нажмите выход из системы, в результате я получаю страницу на ОКС с этим кодом:

function on_completion() 
    {window.location = 'http://localhost/Administration.Frontend.Web/';} 

<iframe src="https://www.google.com/accounts/Logout" style="visibility: hidden"">/iframe> 
<iframe src="http://localhost/Administration.Frontend.Web/?wa=wsignoutcleanup1.0" style="visibility: hidden"></iframe> 

Результат: Я логаут из моего приложения и Google.

3) Вход для моего провайдера идентичности, нажмите выход из системы, перенаправляются на тот же URL на АГСЕ, как на предыдущем шаге, но теперь я получаю 302 результата с перенаправлением

https://localhost/IdentityProvider/issue/wsfed?wa=wsignout1.0&amp;wreply=https%3a%2f%2fmysite.accesscontrol.windows.net%2fv2%2fwsfederation%3fredirectUrl%3dhttp%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f 

Результата: Я логау из моих приложения и моего поставщика удостоверений.

4) попробуйте снова использовать Google, успешно войдите, введя учетные данные, но выйдите из системы, если не удалось. Я вышел из приложения, но не зашел в Google. А также я вижу, что я не получаю страницу с IFRAME, но вместо того, чтобы ACS снова попытаться перенаправить меня

https://localhost/IdentityProvider/issue/wsfed?wa=wsignout1.0 

(а затем обратно в mysite.accesscontrol.windows.net и, наконец, к моему заявлению)

Два основных вопроса:

  1. Почему вызова ACS выход из системы, дайте мне IFrame страницу с дополнительной ва = wsignoutcleanup1.0 для Google/жить, но 302 перенаправление на мой провайдера идентификации, может быть я скучаю someth in FederationMetadata.xml?
  2. Похоже, что ACS после шага 3 не понимает, что я успешно вышел из своего провайдера идентификации и с этого момента попытаюсь сделать это снова и снова, как рассказать им , чтобы остановить его?
+0

Вы можете предоставить страницу ACS (только путь, после .accesscontrol.windows.net/???), который вы перенаправляете и который действует неоднозначно - тот, который сначала отображает некоторые JS + -фрагмы, а затем только отображает 302 ответы. – astaykov

+0

также, вы используете страницу входа в систему, открытую в режиме ACS, или свою собственную страницу входа? Я предполагаю, что это ACS-хостинг. Перейдите на страницу самостоятельной регистрации и повторите попытку. – astaykov

+0

Ответы, представленные здесь http://stackoverflow.com/questions/14932241/logout-from-access-control-service-with-custom-sts/19002310#19002310, дают более точную информацию –

ответ

3

Вот что вам нужно сделать.

Прежде всего, при работе с федеративной аутентификацией всегда используйте HTTPS! Когда-то переговоры по протоколу будут сбой только потому, что это простой HTTP. Иногда браузеры блокируют небезопасный трафик, что имеет решающее значение для процесса выхода. Поэтому всегда используйте HTTPS!

Теперь, чтобы реализовать форму единого входа, вы хотите, чтобы у вас была еще работа.

Ваш URL для знака отказа:

mysite.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0&wreply=http%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f&wtrealm=http%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f

Не используйте его в качестве параметра для построения SignOutRequestMessage. Используйте его непосредственно return Redirect(signOutUrl)!

Вы должны реализовать выключение в двух основных местах!

Первое место ваш общий метод LOGOFF действия (при использовании MVC) Что-то похожее на то, что у вас уже есть, но с важным изменением:

FormsAuthentication.SignOut(); 
var signoutProtocolLocation = "https://[your_acs_namespace].accesscontrol.windows.net:443/v2/wsfederation?wa=wsignout1.0&wtrealm=[realm]&wreply=[reply]"; 
FederatedAuthentication.WSFederationAuthenticationModule.SignOut(signoutProtocolLocation); 

Заметим, что здесь я использую перегрузку с string paramer` перенаправить результат в местоположение SSO в ACS!

Теперь, когда очень ACS SSO местоположение будет генерировать вышеупомянутую HTML-страницу с JS и пару iframe элементов. Один из них будет что-то вроде:

<iframe src="http://localhost/Administration.Frontend.Web/?wa=wsignoutcleanup1.0" style="visibility: hidden"></iframe> 

Теперь, когда конкретное место http://localhost/Administration.Frontend.Web/?wa=wsignoutcleanup1.0 является вторым местом в вашем коде, где вы должны реализовать SSO. Этот запрос должен не перенаправить на страницу входа, но должен обработать правильно и вернуть ответ 200 или 301 (что в свою очередь вернет 200!)! Для простоты я буду только вставить код, используемый здесь:

if(Request.QueryString.AllKeys.Contains("wa") 
       && Request.QueryString["wa"].Equals("wsignoutcleanup1.0")) 
      { 
       FederatedAuthentication.WSFederationAuthenticationModule.SignOut(true); 
       return RedirectToAction("Index"); 
      } 

Это действительно важно, что вы только вызвать перегрузку SignOut(true) с истинной когда запрос wsignoutcleanup действия. И не тогда, когда вы вообще отключаете пользователей.

Пожалуйста, попробуйте все упомянутые изменения и дайте мне знать, если он решит вашу проблему!