如何通过SAML断言从ACS获取访问令牌？(How to get access token from ACS via SAML assertion?)

如何通过SAML断言从ACS获取访问令牌？(How to get access token from ACS via SAML assertion?)

我能够检索，解码来自ACS中配置的各种身份提供者的安全令牌（SWT）。 现在我应该 - 例如 - 能够做到这一点：

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

尽管如此，这还会返回另一个错误：

错误：代码：401：SubCode：T0：详细信息：ACS50008：SAML令牌无效.: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>

I was able to retrieve, decode the security token (SWT) from various identity providers configured in ACS. Now I should be - according to example - able to do this:

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

It works in a sense it fails for a non-existing endpoint for example. So service is there (secured), token module and token validator on the server side are called, and token passes through. So it's not that. But anyway the problem is that the response contains HTML of a login page (that one with identity provider list in it). It seem like as though the token validation was OK, it still isn't enough for security.

What should I do now, to receive my data from a service? Any hints?

Scenario: http://tinyurl.com/WcfRestSaml

Update: I've included link to a picture of scenario I'm trying to achieve.

Update 2: OK, I've switched to Saml2, but same error has occured. Then I've found out I need assertion to receive access token. So I did:

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

This returns yet another error as well though:

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

But it seems that this should return my desired access token.

Update 3: Nothing helps, nowhere to gather the information, damn. I'm posting a full token on a blind chance somebody will notice something is wrong at least (I've removed sensitive informations though).

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

最满意答案

如上所述：

我们已经通过微软支持解决了这个问题，这是由于这个事实造成的，该服务是在被动联合之后进行的，而且这个过程并不是很明显。 我已经通过为SAML2断言标记创建一个<RequestSecurityToken>信封解决了这个问题，这样就可以“模拟”浏览器活动，并且它运行良好，并且在被动联合（由于WS-TRUST信封）下也可以很好地发挥作用。

它需要先传递它，然后连接到ACS。问题根本不在访问令牌或SAML断言中。 正如我指出的那样，这是由于部分网站位于STS自定义联盟背后。 WS Federation模块阻止接收此令牌。 当我将它封装在WS联合的RequestSecurityToken中时，首先咀嚼。 然后按照我的问题提交给ACS。

As noted above:

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.