Cách nhận mã thông báo truy cập từ ACS qua xác nhận SAML?

Question

Tôi đã có thể truy xuất, giải mã mã thông báo bảo mật (SWT) từ các nhà cung cấp nhận dạng khác nhau được định cấu hình trong ACS. Bây giờ tôi nên - theo ví dụ - có thể làm điều này:

String headerValue = string.Format("WRAP access_token=\"{0}\"", securityToken); 

WebClient client = new WebClient(); 
client.Headers.Add("Authorization", headerValue); 

using (Stream stream = client.OpenRead(@"http://xxx.cloudapp.net/xxx.svc/users")) 
using (StreamReader reader = new StreamReader(stream)) 
{ 
    String response = reader.ReadToEnd(); 
} 

Nó hoạt động theo nghĩa nó không thành công cho điểm cuối không tồn tại chẳng hạn. Vì vậy, dịch vụ có (bảo mật), mô-đun mã thông báo và trình xác thực mã thông báo ở phía máy chủ được gọi và mã thông báo chuyển qua. Vì vậy, nó không phải là điều đó. Nhưng dù sao thì vấn đề là phản hồi chứa HTML của trang đăng nhập (trang có danh sách nhà cung cấp danh tính trong đó). Dường như việc xác nhận mã thông báo là OK, nó vẫn không đủ để bảo mật.

Tôi nên làm gì bây giờ, để nhận dữ liệu của tôi từ một dịch vụ? Bất kỳ gợi ý nào?

Kịch bản: http://tinyurl.com/WcfRestSaml

Cập nhật: Tôi đã bao gồm liên kết đến một hình ảnh của kịch bản tôi đang cố gắng để đạt được.

Cập nhật 2: OK, tôi đã chuyển sang Saml2 nhưng đã xảy ra lỗi tương tự. Sau đó, tôi đã phát hiện ra tôi cần xác nhận để nhận mã thông báo truy cập. Vì vậy, tôi đã làm:

WebClient client = new WebClient { BaseAddress = string.Format("https://{namespace}.accesscontrol.windows.net") }; 
NameValueCollection parameters = new NameValueCollection 
{ 
    { "wrap_assertion_format", "SAML" }, 
    { "wrap_assertion", securityToken }, 
    { "wrap_scope", "http://{our}.cloudapp.net/" } 
}; 

Byte[] responseBytes = client.UploadValues("WRAPv0.9", parameters); 
String response = Encoding.UTF8.GetString(responseBytes); 

này trả chưa lỗi khác cũng mặc dù:

Error:Code:401:SubCode:T0:Detail:ACS50008: SAML token is invalid.:TraceID:1d3774fa-a5e6-3e3b-a5e5-5a0bde6e0771:TimeStamp:2013-06-06 16:18:05Z

Nhưng có vẻ như điều này sẽ trở lại mong muốn thẻ truy cập của tôi.

Cập nhật 3: Không có gì hữu ích, không nơi nào để thu thập thông tin, chết tiệt. Tôi đăng một mã thông báo đầy đủ trên một cơ hội mù ai đó sẽ nhận thấy một cái gì đó là sai ít nhất (tôi đã loại bỏ thông tin nhạy cảm mặc dù).

<Assertion ID="_541a71ba-1e00-478c-8d2b-0beac3a35d35" IssueInstant="2013-06-07T11:38:31.741Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> 
    <Issuer>https://{removed}.accesscontrol.windows.net/</Issuer> 
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
    <ds:SignedInfo> 
     <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
     <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> 
     <ds:Reference URI="#_541a71ba-1e00-478c-8d2b-0beac3a35d35"> 
     <ds:Transforms> 
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> 
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
     </ds:Transforms> 
     <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> 
     <ds:DigestValue>{removed}</ds:DigestValue> 
     </ds:Reference> 
    </ds:SignedInfo> 
    <ds:SignatureValue>{removed}</ds:SignatureValue> 
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     <X509Data> 
     <X509Certificate>{removed}</X509Certificate> 
     </X509Data> 
    </KeyInfo> 
    </ds:Signature> 
    <Subject> 
    <NameID>https://www.google.com/accounts/o8/id?id={removed}</NameID> 
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" /> 
    </Subject> 
    <Conditions NotBefore="2013-06-07T11:38:31.694Z" NotOnOrAfter="2013-06-07T12:38:31.694Z"> 
    <AudienceRestriction> 
     <Audience>http://{removed}.cloudapp.net/</Audience> 
    </AudienceRestriction> 
    </Conditions> 
    <AttributeStatement> 
    <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"> 
     <AttributeValue>{removed}</AttributeValue> 
     <AttributeValue>https://www.google.com/accounts/o8/id?id={removed}</AttributeValue> 
     <AttributeValue>{removed}</AttributeValue> 
    </Attribute> 
    <Attribute Name="http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider"> 
     <AttributeValue>Google</AttributeValue> 
    </Attribute> 
    </AttributeStatement> 
</Assertion> 

Answer 1

Như đã đề cập ở trên:

We've solved it with Microsoft Support, it was caused by the fact, the service was behind passive federation, and the process doesn't like obviously. I've solved it by creating a <RequestSecurityToken> envelope for the SAML2 assertion token, this way it "simulated" browser activity, and it works well and also plays well with passive federation (due to WS-TRUST envelope).

It needed to pass it first and then it connected to ACS.The problem wasn't in access token or SAML assertion at all. It was caused - as I've pointed out - by the fact that part of website was behind the custom STS federation. The WS Federation module was blocking reception of this token. When I enveloped it in RequestSecurityToken for WS Federation to chew on first. It then passed to ACS as presented in my question.