SAML 어설 션을 통해 ACS에서 액세스 토큰을 얻는 방법은 무엇입니까?

Question

ACS에 구성된 다양한 ID 공급자에서 보안 토큰 (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(); 
} 

예를 들어 존재하지 않는 엔드 포인트의 경우 실패합니다. 그래서 서비스가 거기 (보안), 토큰 모듈 및 토큰 유효성 검사기가 호출되고 토큰이 전달됩니다. 그래서 그것은 아닙니다. 그러나 어쨌든 문제는 응답에 로그인 페이지 (해당 ID 제공자 목록이있는 로그인 페이지)의 HTML이 포함되어 있다는 것입니다. 마치 토큰 유효성 검사가 OK 인 것처럼 보이지만 여전히 보안을 위해서는 충분하지 않습니다.

서비스에서 데이터를 수신하려면 어떻게해야합니까? 어떤 힌트?

시나리오 : http://tinyurl.com/WcfRestSaml

업데이트 : 내가 달성하기 위해 노력하고있어 시나리오의 사진에 대한 링크를 포함 시켰습니다.

업데이트 2 : 좋아, Saml2로 전환했지만 동일한 오류가 발생했습니다. 그런 다음 액세스 토큰을 받기 위해 어설 션이 필요하다는 것을 알았습니다. 그래서 내가 그랬어 :이 내 원하는 액세스 토큰을 반환해야 함을 보인다

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

그러나 :하지만

이

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

이뿐만 아니라 또 다른 오류를 반환합니다.

업데이트 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> 

Answer 1

는 위에서 언급 한 바와 같이 :

우리는 Microsoft 지원으로 해결 한

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.