2013-06-05 60 views
5

我能够从ACS中配置的各种身份提供程序中检索,解码安全令牌(SWT)。现在我应该是 - 根据示例 - 能够做到这一点:如何通过SAML断言从ACS获取访问令牌?

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(); 
} 

它可以在失败例如用于非现有的端点感。所以服务在那里(安全),服务器端的令牌模块和令牌验证器被调用,并且令牌通过。所以不是这样。但无论如何,问题是响应包含登录页面(其中一个身份提供商列表中的一个)的HTML。看起来好像令牌验证是可以的,但对安全性来说还是不够的。

现在我该怎么做,从服务中接收我的数据?任何提示?

场景:http://tinyurl.com/WcfRestSaml

更新:我已经包含链接的场景的照片,我想要的目的。

更新2:好的,我已切换到Saml2,但出现了同样的错误。然后我发现我需要断言来接收访问令牌。所以我做:

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); 

这又返回另一个错误,以及虽:

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

但似乎这应该返回我想要的访问令牌。

更新3:没有任何帮助,无处收集信息,该死的。我在一个盲人机会上发布了完整的令牌,至少有人会注意到有什么不对(我已经删除了敏感信息)。

<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> 
+0

我们与微软的支持解决了这个问题,它是由这样的事实造成的,服务是超越被动联邦和过程不明明喜欢。我已经通过为SAML2断言标记创建信封解决了这个问题,这样就可以“模拟”浏览器活动,而且它运行良好,并且在被动联合(由于WS-TRUST信封)下也可以很好地发挥作用。 – SmartK8

+0

下面是另一个答案,显示有效载荷应该看起来像什么http://stackoverflow.com/a/17174563/31299 – Josh

+0

是的,但我的格式是正确的。正如我所说的,我的问题在于被动联合背后。它需要先传递它,然后连接到ACS。这一切都解决了,现在工作正常。 – SmartK8

回答

0

如上所述:

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.