2013-04-11 19 views
5

Tôi có một không gian tên ACS với nhà cung cấp dịch vụ nhận dạng WS-Federation được thiết lập . Vì tôi đang sử dụng Visual Studio 2012, tôi đã sử dụng Công cụ nhận dạng và truy cập để tạo bên phụ thuộc. Công cụ này sử dụng các giá trị url của lĩnh vực và trả về mà tôi cung cấp khi tạo nhóm phụ thuộc (tôi sử dụng url dịch vụ đám mây Azure nơi tôi đang triển khai dự án của mình - tức là http://myapp.cloudapp.net). Chỉ có một quy tắc trong nhóm quy tắc cho bữa tiệc phụ thuộc của tôi sau khi tôi chạy công cụ - Vượt qua tất cả các xác nhận quyền sở hữu đối với [Relying Party]. Tôi đã thử nghiệm ACS cho ứng dụng của mình chỉ với một quy tắc đó và sau khi tạo tất cả các quy tắc cho nhà cung cấp danh tính WS-Federation.Dịch vụ kiểm soát truy cập Azure (ACS) - ACS50001: Cập nhật bên nhận dạng 'https: // [namespace] .accesscontrol.windows.net /' không được tìm thấy

Bất kể quy tắc nào trong nhóm quy tắc, tôi gặp lỗi trong tiêu đề câu hỏi của mình. Trình duyệt của tôi được chuyển hướng đến ACS, tuy nhiên vì lý do nào đó, trình duyệt của tôi không thể tìm thấy bên phụ thuộc chính xác. Tôi đã tạo một không gian tên ACS, nhà cung cấp danh tính và bên phụ thuộc trong hai tài khoản Azure khác nhau, với kết quả chính xác giống nhau.

Tôi cũng đã thử xuất bản dự án của mình lên dịch vụ đám mây Azure với cả điểm cuối http và https và cả hai điểm cuối đều mang lại kết quả tương tự.

Siêu dữ liệu liên kết của nhà cung cấp danh tính WS-Liên kết đến từ Windows Azure Active Directory.

CẬP NHẬT FederationConfiguration đoạn từ 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> 

UPDATE 2: Vẫn không có giải pháp. Có vẻ như vấn đề bắt nguồn từ thực tế là tôi đã thiết lập nhà cung cấp danh tính ACS của riêng mình và tải xuống siêu dữ liệu liên kết từ Windows Azure Active Directory (WAAD) cho nhà cung cấp danh tính đó. Về cơ bản, chuỗi 2 trường hợp ACS cùng nhau. Khi ứng dụng của tôi chuyển hướng đến ACS của tôi, nó chuyển url của ứng dụng của tôi dưới dạng cõi. Sau đó, ACS của tôi chuyển hướng đến nhà cung cấp danh tính, WAAD và chuyển url của chính nó làm lĩnh vực. Đó là lý do tại sao lỗi tôi nhận lại có đặc điểm lạ của một định danh bên dựa vào url của cổng quản trị ACS của chính tôi. Tôi không chắc chắn tại sao nó không đi qua cõi tất cả các cách thức thông qua từ ứng dụng của tôi để WAAD.

+1

Bạn có thể hiển thị phần web.config của bạn không? –

+1

có vẻ như bạn đặt 'https: // [không gian tên] .accesscontrol.windows.net /' trong khóa địa chỉ bên trong thay vì http://myapp.cloudapp.net –

+0

Xin chào Danila, tôi đặt phần federationConfiguration trong đó. Dường như cả hai giá trị bạn đề cập đều có ... –

Trả lời

4

Vâng, câu trả lời cho điều này là nhiều hơn nữa che khuất hơn tôi mong đợi đã - Tôi đã phải chạy các kịch bản PowerShell sau đây đối với CRM Online Waad tôi:

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 

này cho Waad nhận namespace ACS tôi, vì vậy nó sẽ không ném lỗi nói rằng không gian tên ACS không phải là một định danh bên dựa hợp lệ. Đọc toàn bộ quá trình ở đây:

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

Nhờ hỗ trợ Azure, Tôi bây giờ quá khứ lỗi.

1

Đi vào Cổng quản lý Azure ACS. Mở các ứng dụng bên của Relying và chọn bên phụ thuộc mà bạn đã định cấu hình cho ứng dụng này. Đảm bảo rằng trường "Realm" khớp chính xác với những gì bạn có cho Realm trong web.config dưới <federationConfiguration><wsFederation realm=""/>.

+0

Xin chào Nathan, cảm ơn câu trả lời. Nó có; Công cụ nhận dạng và truy cập quản lý tất cả điều đó. Câu trả lời thực sự là WAAD cần được cấu hình để nhận ra bên dựa vào ACS của tôi thông qua một số kịch bản PowerShell tối nghĩa. –

0

Tất cả bạn cần là thiết lập truy cập đến ACS trong Active thư mục Sau khi cài đặt PowerShell Azure commandlets, chạy các lệnh dưới đây như đã đề cập bởi Andrew

Connect-MsolService

Import-Module MSOnlineExtended -force $ replyUrl = New-MsolServicePrincipalAddresses -Địa chỉ "https://xxx.accesscontrol.windows.net/"

New-MsolServicePrincipal -ServicePrincipalNames @ ("https://xxx.accesscontrol.windows.net/") -DisplayName "xxx ACS Namespace" -Addresses $ replyUrl

0

Trong trường hợp bất cứ ai tình cờ khác về vấn đề này, đôi kiểm tra mã vương quốc của bạn ở đây:

wsFederation passiveRedirectEnabled = "true" phát hành = "phải phù hợp với thiết bị đầu cuối" vương = "phải phù hợp với khán giả URI" requireHttps = "true"

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

vấn đề của tôi là một/vào cuối URI của tôi mà tôi thêm vào bản năng - tức là https://somuri.com/ - trong khi thiết lập cổng thông tin là https://someuri.com

Loại bỏ/làm việc.

Các vấn đề liên quan