Wie bekomme ich Zugangstoken von ACS über SAML Assertion?

Question

Ich konnte das Sicherheitstoken (SWT) von verschiedenen Identitätsanbietern, die in ACS konfiguriert wurden, abrufen, dekodieren. Jetzt soll ich sein - nach Beispiel - in der Lage, dies zu tun:

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

Es ist in gewissem Sinne arbeitet sie für einen nicht existierenden Endpunkt beispielsweise ausfällt. Service ist da (gesichert), Token-Modul und Token-Validator auf der Serverseite werden aufgerufen, Token durchläuft. So ist es nicht. Aber das Problem ist, dass die Antwort HTML einer Login-Seite enthält (das eine mit Identity-Provider-Liste darin). Es sieht so aus, als sei die Token-Validierung in Ordnung, aber für die Sicherheit reicht es nicht aus.

Was soll ich jetzt tun, um meine Daten von einem Dienst zu erhalten? Irgendwelche Hinweise?

Szenario: http://tinyurl.com/WcfRestSaml

aktualisieren: Ich habe Link zu einem Bild von Szenarium ich zu erreichen bin versucht.

Update 2: OK, ich habe zu SAML2 geschaltet, aber den gleichen Fehler aufgetreten. Dann habe ich herausgefunden, dass ich Assertion benötigen, um Zugriffstoken zu erhalten. Also habe ich:

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

Dies gibt noch einen weiteren Fehler auch wenn:

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

Aber es scheint, dass dies mein gewünschten Zugriffstoken zurückgeben sollte.

Update 3: Nichts hilft, nirgendwo die Informationen zu sammeln, verdammt. Ich poste einen vollen Token für eine blinde Chance, dass jemand merkt, dass etwas nicht in Ordnung ist (ich habe jedoch sensible Informationen entfernt).

<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

Wie oben erwähnt:

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.