Служба управления доступом Azure (ACS) — ACS50001: проверяющая сторона с идентификатором «https://[namespace].accesscontrol.windows.net/» не найдена

У меня есть пространство имен ACS с настроенным поставщиком удостоверений WS-Federation. Поскольку я использую Visual Studio 2012, я использовал средство идентификации и доступа для создания проверяющей стороны. Инструмент использует область и возвращаемые значения URL-адреса, которые я даю ему при создании проверяющей стороны (я использую URL-адрес облачной службы Azure, где развертываю свой проект, т.е. http://myapp.cloudapp.net).). После запуска инструмента в группе правил для моей проверяющей стороны есть только одно правило — Пропустить все утверждения для [проверяющей стороны]. Я протестировал ACS для своего приложения только с одним этим правилом, а также после создания всех правил для поставщика удостоверений WS-Federation.

Независимо от правил в группе правил, я получаю ошибку в заголовке своего вопроса. Мой браузер перенаправляется на ACS, однако по какой-то причине он не может найти нужную проверяющую сторону. Я создал пространство имен ACS, поставщика удостоверений и проверяющую сторону в двух разных учетных записях Azure с точно таким же результатом.

Я также попытался опубликовать свой проект в облачной службе Azure с конечными точками http и https, и обе конечные точки дают одинаковый результат.

Метаданные федерации поставщика удостоверений WS-Federation поступают из Windows Azure Active Directory.

Раздел UPDATE FederationConfiguration из web.config:

<federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://[MyNamespace].accesscontrol.windows.net/v2/wsfederation" realm="http://[MyApp].cloudapp.net/" requireHttps="false" />
</federationConfiguration>

ОБНОВЛЕНИЕ 2: до сих пор нет решения. Похоже, проблема связана с тем, что я настроил свой собственный поставщик удостоверений ACS и загрузил метаданные федерации из Windows Azure Active Directory (WAAD) для этого провайдера удостоверений. По сути, это объединяет 2 экземпляра ACS. Когда мое приложение перенаправляется на мой ACS, оно передает URL-адрес моего приложения в качестве области. Затем мой ACS перенаправляется к поставщику удостоверений, WAAD, и передает свой собственный URL-адрес в качестве области. Вот почему ошибка, которую я получаю, имеет странную характеристику идентификатора проверяющей стороны = URL-адрес моего собственного портала администрирования ACS. Я не уверен, почему он не проходит весь путь от моего приложения до WAAD.


acs ws-federation
person Andrew B Schultz    schedule 11.04.2013    source источник
comment
Можете ли вы показать свой раздел web.config ‹federationConfiguration›?   -  person Danila Polevshikov    schedule 11.04.2013
comment
похоже, вы поместили «https://[namespace].accesscontrol.windows.net/» в ключ области внутри ‹federationConfiguration› вместо myapp.cloudapp.net   -  person Danila Polevshikov    schedule 11.04.2013
comment
Привет Данила, я добавил туда раздел federationConfiguration. Похоже, оба значения, которые вы упомянули, есть...   -  person Andrew B Schultz    schedule 11.04.2013
comment
С локальной ADFS вы можете войти и увидеть идентификаторы проверяющих сторон, что помогло мне в устранении неполадок в прошлом. Но, похоже, нет никакого способа увидеть фактический идентификатор в настройках ACS.   -  person Andrew B Schultz    schedule 11.04.2013
comment
Вы можете использовать портал управления ACS (namespace.accesscontrol.windows.net), чтобы просмотреть зарегистрированные идентификаторы. Еще одна вещь, на которую стоит обратить внимание, — это сам запрос. Какой URL-адрес запроса к ACS, который вызывает эту ошибку?   -  person Oren Melzer    schedule 12.04.2013
comment
@OrenMelzer Я не уверен, правильно это или нет, но идентификатор, на который он ссылается, ЯВЛЯЕТСЯ порталом управления — ошибка говорит, что доверяющая сторона с идентификатором «https://[namespace].accesscontrol.windows.net/» не была нашел.   -  person Andrew B Schultz    schedule 12.04.2013
comment
URL-адрес запроса к ACS — тот же URL-адрес — [namespace].accesscontrol.windows.net. Кажется, это перенаправляет на login.windows.net, а затем на login.microsoftonline.com, страницу входа в Office 365, где пользователи управляются с помощью CRM Online. Мое приложение в основном использует CRM Online (Windows Azure Active Directory для CRM Online) в качестве поставщика удостоверений.   -  person Andrew B Schultz    schedule 13.04.2013

Ответы (4)


arrow_upward
4
arrow_downward

Что ж, ответ на этот вопрос оказался гораздо более неясным, чем я ожидал — мне пришлось запустить следующий скрипт powershell против моей CRM Online WAAD:

Connect-MsolService
Import-Module MSOnlineExtended -Force
$replyUrl = New-MsolServicePrincipalAddresses –Address "https://lefederateur.accesscontrol.windows.net/"
New-MsolServicePrincipal –ServicePrincipalNames @(“https://lefederateur.accesscontrol.windows.net/”) -DisplayName “LeFederateur ACS Namespace” -Addresses $replyUrl

Это сказало WAAD распознать мое пространство имен ACS, чтобы не выдавать ошибку о том, что пространство имен ACS не является действительным идентификатором проверяющей стороны. Весь процесс читайте здесь:

http://www.cloudidentity.com/blog/2012/11/07/provisioning-a-directory-tenant-as-an-identity-provider-in-an-acs-namespace/

Благодаря поддержке Azure я избавился от этой ошибки.

person Andrew B Schultz    schedule 17.04.2013

arrow_upward
1
arrow_downward

Перейдите на портал управления Azure ACS. Откройте Приложения проверяющей стороны и выберите проверяющую сторону, которую вы настроили для этого приложения. Убедитесь, что поле «Область» точно соответствует тому, что у вас есть для области в web.config в разделе <federationConfiguration><wsFederation realm=""/>.

person Nathan    schedule 17.04.2013
comment
Привет, Натан, спасибо за ответ. Оно делает; Инструмент Identity and Access управляет всем этим. На самом деле ответ заключался в том, что WAAD нужно было настроить для распознавания моей проверяющей стороны ACS с помощью какого-то неясного сценария PowerShell. - person Andrew B Schultz; 18.04.2013

arrow_upward
0
arrow_downward

Все, что вам нужно, это настроить доступ к ACS в Active Directory. После установки командлетов Powershell Azure выполните приведенные ниже команды, как указано Эндрю.

Connect-MsolService

Import-Module MSOnlineExtended -Force $replyUrl = New-MsolServicePrincipalAddresses –Address "https://xxx.accesscontrol.windows.net /"

New-MsolServicePrincipal –ServicePrincipalNames @("https://xxx.accesscontrol.windows.net/") -DisplayName "пространство имен ACS xxx" -Addresses $replyUrl

person abhijoseph    schedule 23.04.2014

arrow_upward
0
arrow_downward

В случае, если кто-то еще наткнется на это, дважды проверьте код вашей области здесь:

wsFederationpassiveRedirectEnabled="true" issuer="должен совпадать с конечной точкой" realm="должен совпадать с URI аудитории" requireHttps="true"

И

<add key="ida:Realm" value="must match audience uri" />
<add key="ida:AudienceUri" value="must match audience uri" />

моей проблемой был / в конце моего URI, который я добавил инстинктивно, т.е. https://somuri.com/ - тогда как настройка портала была https://someuri.com

веришь/раб.

person Tyler Davey    schedule 29.04.2014