How to get from ADFS a non-empty Recipient attribute in SAML Assertion

Question

I'm trying to get a SAML Assertion from ADFS using WIF 4.5, and WS-Trust, so that I can send that Assertion to a Service Provider and obtain an OAuth ticket.

In fact, I've been able to get the SAML Assertion, but it's not a valid one, because the Recipient attribute from SubjectConfirmationData is not received. And it is a mandatory datum.

I'm doing my test in a Console Application (so it's executing with my credentials, as I have checked using Fiddler, it performs a Kerberos negotiation before receiving the Assertion). I'm obtaining the token doing so (based on RequestSecurityToken using windows credentials and .net 4.5 WIF ):

public static string GetStsToken()
{
    try
    {
        EndpointReference appliesToEp = new EndpointReference(ENDPOINT_REFERENCE_URI);

        EndpointAddress stsEp = new EndpointAddress(
                new Uri("https://<ADFS-SERVER>/adfs/services/trust/2005/windowstransport"),
                EndpointIdentity.CreateSpnIdentity(ADFS_SPN));

        WS2007HttpBinding msgBinding = new WS2007HttpBinding(SecurityMode.Transport, false);
        msgBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
        msgBinding.Security.Message.EstablishSecurityContext = false;
        msgBinding.Security.Message.NegotiateServiceCredential = false;
        msgBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;

        using (WSTrustChannelFactory factory = new WSTrustChannelFactory(msgBinding, stsEp))
        {
            factory.Credentials.SupportInteractive = false;
            factory.TrustVersion = TrustVersion.WSTrustFeb2005;

            RequestSecurityToken myRst = 
                new RequestSecurityToken(RequestTypes.Issue, KeyTypes.Bearer)
                {
                    AppliesTo = appliesToEp,
                    TokenType = "urn:oasis:names:tc:SAML:2.0:assertion"
                };
            IWSTrustChannelContract channel = factory.CreateChannel();
            GenericXmlSecurityToken stsToken = channel.Issue(myRst) as GenericXmlSecurityToken;

            if (stsToken != null)
            {
                return stsToken.TokenXml.OuterXml;
            }
            else
            {
                // SOME WARNING IS ISSUED
            }
        }
    }
    catch (Exception ex)
    {
        // THE EXCEPTION IS REGISTERED
    }

    return null;
}

With this code, the request sent is the following:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
    <a:MessageID>urn:uuid:8c221169-52b2-42bf-87f8-7089b6feb0a9</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
    <a:To s:mustUnderstand="1">https://ADFS-SERVER/adfs/services/trust/2005/windowstransport</a:To>
  </s:Header>
  <s:Body>
    <t:RequestSecurityToken xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
      <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
          <wsa:Address>ENDPOINT_REFERENCE</wsa:Address>
        </wsa:EndpointReference>
      </wsp:AppliesTo>
      <t:KeySize>0</t:KeySize>
      <t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</t:KeyType>
      <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType>
      <t:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</t:TokenType>
    </t:RequestSecurityToken>
  </s:Body>
</s:Envelope>

The Assertion I receive seems a valid one, but the Recipient is missing from the SubjectConfirmationData, and so, when I send that Assertion to the Service Provider, the Authentication fails.

If I use the Web IdP Initiated Login, which sends a samlp:AuthnRequest to the server, and decode the obtained SAML Assertion that ADFS emits in that case (again, using Fiddler), the Recipient attribute is received, and the SSO works. I can see the method used to obtain the assertion is different (Web-SSO is used in this case), but in both cases the Relying Party is the same, and so the emitted Assertion should be similar.

Is there any way I can receive the proper Recipient when obtaining the Token using WS-Trust from ADFS?

Answer 1

In the end, I've ended obtaining the SAML Assertion using the IdP Initiated Sign On page.

public static string GetStsToken(string relyingPartyUri)
{
    string result = null;

    string samlHttpPostUri = string.Format(
        "https://<ADFS-SERVER>/adfs/ls/idpinitiatedsignon.aspx?loginToRp={0}",
        relyingPartyUri
    );

    WebRequest req = WebRequest.Create(samlHttpPostUri);
    req.Method = WebRequestMethods.Http.Get;
    req.Credentials = CredentialCache.DefaultNetworkCredentials;

    XDocument xDoc = null;
    try
    {
        using (WebResponse resp = req.GetResponse())
        {
            using (StreamReader reader = new StreamReader(resp.GetResponseStream()))
            {
                string htmlResult = reader.ReadToEnd();
                xDoc = XDocument.Parse(htmlResult);
                string samlResponseBase64 = (from xElement in xDoc.Descendants()
                                             where xElement.Name == "input" &&
                                                   xElement.Attribute("name").Value == "SAMLResponse"
                                             select xElement.Attribute("value").Value).FirstOrDefault();

                result = System.Text.Encoding.UTF8.GetString(
                    Convert.FromBase64String(samlResponseBase64)
                );
            }
        }
    }
    catch (WebException webExc)
    {
        using (StreamReader reader = new StreamReader(webExc.Response.GetResponseStream()))
        {
            // THE EXCEPTION IS REGISTERED
        }
    }

    return result;

}

The SAML Response is correct, and I can use it to obtain the OAuth Token from the Relying Party.

BUT, of course, I'm not using WS-Trust in this case . This is not a solution, but a Workaround.