Zulfiqar's weblog

Architecture, security & random .Net

Archive for the ‘.NET Services’ Category

Live ID Authentication for Rich Clients

Posted by zamd on March 18, 2009

Disclaimer: Please note following approach works but is totally unsupported.

Active version of Live ID STS is available at: https://dev.login.live.com/wstlogin.srf and we can get a SAML token by using standard WS-Security username token as input.

 

            var issuer = https://dev.login.live.com/wstlogin.srf;

            var binding = new WSHttpBinding();

            binding.Security.Mode = SecurityMode.TransportWithMessageCredential;

            binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;

            binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;

            binding.Security.Message.EstablishSecurityContext = false;

            binding.Security.Message.NegotiateServiceCredential = false;

 

 

            WSTrustClient client = new WSTrustClient(binding, new EndpointAddress(issuer),

                TrustVersion.WSTrustFeb2005, new ClientCredentials());

            client.ClientCredentials.UserName.UserName = zamd@liveid.com;

            client.ClientCredentials.UserName.Password = “password “;

 

            var rst = new RequestSecurityToken(RequestTypeConstants.Issue);

            rst.AppliesTo = new EndpointAddress(http://zamd.net);

 

            RequestSecurityTokenResponse rstr;

            var token = client.Issue(rst, out rstr) as GenericXmlSecurityToken;

Posted in .NET Services | 1 Comment »

Part5: ACS Federation with LiveID

Posted by zamd on February 13, 2009

Out of box ACS supports live.com as a trusted identity issuer which means we can use a token issued by live.com to login into ACS. Here I will show how can you achieve this using passive (browser based) federation.

Inside Application AuthenticateRequest method of Global.asax I added following code redirect my web app to ACS to get a new token.

protected void Application AuthenticateRequest(object sender, EventArgs e)

{

    var fam = HttpContext.Current.ApplicationInstance.Modules["WSFederationAuthenticationModule"] as WSFederationAuthenticationModule;

    fam.SignedIn += new EventHandler(fam SignedIn);

 

    var identity = Thread.CurrentPrincipal.Identity as ClaimsIdentity;

    if (identity != null)

        return;

 

    fam.Realm = "http://zamd.net/";

    fam.Reply = "http://localhost:50037/WebForm1.aspx";

    fam.Issuer = @"https://accesscontrol.windows.net/passivests/Eval01/livefederation.aspx";

    string homeRealmSts = @"http://login.live.com";

 

    String uniqueId = Guid.NewGuid().ToString();

    SignInRequestMessage signInMsg = fam.CreateSignInRequest(uniqueId, fam.Realm, false);

    signInMsg.Parameters.Add("whr", homeRealmSts);

 

    // Redirect to the ACS passive STS for token issuance

    Response.Redirect(signInMsg.RequestUrl);

}

Because here I specified live.com as my home realm, ACS will redirect me to live.com and actual login will take place there. After the succesful login, live.com will redirect me back to ACS with a token (issued by live.com). As ACS trusts this token, issued by live.com. It then runs it’s claims transformation logic (based on the claims issued by live.com) to generate a final token (issued by ACS). ACS then redirects the browser back to the Reply URI (my web app) along with final SAML token. Once back in my app, WSFederationAuthenticationModule, will see this new token and after verifying the issuer etc, it will use it to log me into my application.

Inside Application Start method, I [mis]configured various bits to make it work on test environment.

protected void Application Start(object sender, EventArgs e)

{

    FederatedAuthentication.ServiceCertificate = GetACSCert();

 

    FederatedAuthentication.IssuerNameRegistry = new TrustAllRegistry();

 

    var saml11Handler = FederatedAuthentication.SecurityTokenHandlers[typeof(SamlSecurityToken)] as Saml11SecurityTokenHandler;

    if (saml11Handler != null)

        saml11Handler.SamlSecurityTokenRequirement.AudienceUriMode = System.IdentityModel.Selectors.AudienceUriMode.Never;

}

 

Posted in .NET Services | Leave a Comment »

Part4: ACS Federation with Sql Server Data Services

Posted by zamd on February 11, 2009

Today I will show you how use a token issued by ACS to login into SDS using it’s SOAP API. Again two step process:

Step 1: Get a token from ACS (using UserName/Passoword) for SDS.

 var binding = new WSHttpBinding(“userNameForCert”);

 //ACS(STS) signing certificate…       

var certData = GetACSCertificate();

//only public key cert. use to secure communication.

var acsCert = new X509Certificate2(certData);

var identity = new X509CertificateEndpointIdentity(acsCert);

var epa = new EndpointAddress(new Uri(http://accesscontrol.windows.net/sts/mssds.com/username for certificate feb2005″), identity); 

var trustVersion = TrustVersion.WSTrustFeb2005;

var clientCredentials = new ClientCredentials();

clientCredentials.UserName.UserName = SolutionUserName;

clientCredentials.UserName.Password = SolutionPassword;

 

WSTrustClient client = new WSTrustClient(binding, epa, trustVersion, clientCredentials);

RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue, KeyTypeConstants.Symmetric);

rst.AppliesTo = new EndpointAddress(https://data.database.windows.net/v1″);

RequestSecurityTokenResponse rstr;

var samltok = client.Issue(rst, out rstr);

Here is the binding configuration I used for talking to ACS:

  <binding name=userNameForCert>

    <security mode=Message>

      <message clientCredentialType=UserName negotiateServiceCredential=false

        establishSecurityContext=false />

    </security>

  </binding>

 

Step 2: Forward this token to SDS when creating a new container.

I have generated the SDS proxy (and other classes) by simply doing an “Add Service Reference” from inside visual studio. SDS metadata is exposed at: https://database.windows.net/soap/v1/

 

var sdsBinding = new CustomBinding(“sitka”);

var sdsClient = new SDS.SitkaSoapServiceClient(sdsBinding,

    new EndpointAddress(https://data.database.windows.net/soap/v1/zurich&#8221;));

FederatedClientCredentials.ConfigureChannelFactory(sdsClient.ChannelFactory);

var sdsProxy = sdsClient.ChannelFactory.CreateChannelWithIssuedToken(samltok);

var authorityScope = new SDS.Scope();

authorityScope.AuthorityId = “zamd01″;

 

var c1 = new SDS.Container();

c1.Id = “NewContainerId”;

sdsProxy.Create(authorityScope, c1);

Console.WriteLine(“New container is created…”);

 

SDS binding looks like this:

  <binding name=sitka>

    <security authenticationMode=IssuedTokenOverTransport>

      <issuedTokenParameters>

        <issuer address=http://dummy binding=basicHttpBinding/>

      </issuedTokenParameters>

    </security>

    <httpsTransport/>

  </binding>

And here is a snapshot of my SDS account highlighting the newly created container.

 

Posted in .NET Services | Leave a Comment »

Part3: Explicit ACS federation

Posted by zamd on February 4, 2009

In last post, I have shown you how to federate ACS with a custom STS. All the token acquisition (from my local STS) and forwarding (to ACS) magic was done by WSFederationHttpBinding and you never see the intermediate token (issued by your local STS). There are scenarios where you want more explicit control over this intermediate token. In this post I will show some techniques to get hold of this intermediate token and thus control its lifetime & forwarding etc.

Step 1: Get the token from our local STS.

private static SecurityToken GetTokenFromLocalSTS()

{

    var localSTSBinding = new WSHttpBinding("AnnonyForCertificate");

 

    //only public key cert. use to secure communication.

    var localSTSCert = new X509Certificate2(@"MyCustomSTSPublicKey.cer");

    var localSTSIdentity = new X509CertificateEndpointIdentity(localSTSCert);

    var localSTSAddress = new EndpointAddress(new Uri("http://localhost:9000/STS&quot;), localSTSIdentity);

 

    WSTrustClient client = new WSTrustClient(localSTSBinding, localSTSAddress,TrustVersion.WSTrustFeb2005, new ClientCredentials());

    RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);

    rst.AppliesTo = new EndpointAddress("http://accesscontrol.windows.net/sts/eval01/saml for certificate/");

 

   

    RequestSecurityTokenResponse rstr;

    var token = client.Issue(rst, out rstr);

    client.Close();

    return token;

}

My local STS is configured to issue token to all annonymous callers. Here is the binding:

<binding name="AnnonyForCertificate">

  <security mode="Message">

    <message clientCredentialType="None" negotiateServiceCredential="false" establishSecurityContext="false"/>

  </security>

</binding>

Step 2: Forward this token to ACS along with Issue request.

 

private static void FederateMyCustomSTS With ACS()

{

    var intermediateToken = GetTokenFromLocalSTS();

 

    // we got token from my our local STS. Forward this token to ACS with Issue request

    var acsCert = GetACSCertificate();

    var acsIdentity = new X509CertificateEndpointIdentity(acsCert);

    var acsAddress = new EndpointAddress(new Uri("http://accesscontrol.windows.net/sts/eval01/saml for certificate"), acsIdentity);

 

    var acsBinding = new CustomBinding("AnySamlForCertificate");

 

    var acsClient = new WSTrustClient(acsBinding, acsAddress, TrustVersion.WSTrust13, new ClientCredentials());

    acsClient = acsClient.SetIssuedToken(intermediateToken);

 

    RequestSecurityToken rstACS = new RequestSecurityToken(RequestTypeConstants.Issue);

    rstACS.AppliesTo = new EndpointAddress("http://zamd.net/&quot;);

 

    var finalToken = acsClient.Issue(rstACS) as GenericXmlSecurityToken;

 

    // dump SAML.

    var rpCert = new X509Certificate2(@"zamdnetprivatekeycert.pfx", "a");

    var saml = ExtractSAMLAssertion(finalToken, rpCert);

}

The ACS binding is as follows:

<binding name="AnySamlForCertificate">

  <security authenticationMode="IssuedTokenForCertificate"

    messageSecurityVersion="WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10"

    requireSignatureConfirmation="false">

    <issuedTokenParameters>

      <issuer address="http://dummy" binding="basicHttpBinding"/>

    </issuedTokenParameters>

  </security>

  <httpTransport/>

</binding>

With the above code I get back following SAML assertion (containing only one claim).

<saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

  <saml:Subject>

    <saml:SubjectConfirmation>

      <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>

      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

        <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">

          <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">

            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

          </e:EncryptionMethod>

          <KeyInfo>

            <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

              <X509Data>

                <X509IssuerSerial>

                  <X509IssuerName>CN=Root Agency</X509IssuerName>

                  <X509SerialNumber>53391460269745460375752793295988585963</X509SerialNumber>

                </X509IssuerSerial>

              </X509Data>

            </o:SecurityTokenReference>

          </KeyInfo>

          <e:CipherData>

            <e:CipherValue>laW9NYJ3NHh+M3c6U1Nq/FADoAWsVc2/JZHYIHJ/qWF536ecpA12NI5orlyvzJ9D+gAK98ZsyouHm1rvQPrttpATQtilrkkyvwKK6JRQb4Ji9th8QGxA+9Yc8yKXlS+rn+lQhdGjYwH8PVxb38IlyJFydtJDMtsJID1OiXagp/w=</e:CipherValue>

          </e:CipherData>

        </e:EncryptedKey>

      </KeyInfo>

    </saml:SubjectConfirmation>

  </saml:Subject>

  <saml:Attribute AttributeName="action" AttributeNamespace="http://docs.oasis-open.org/wsfed/authorization/200706/claims">

    <saml:AttributeValue>that’s done</saml:AttributeValue>

  </saml:Attribute>

</saml:AttributeStatement>

 

I hope you will find this post useful. In the next post, I will show how to federate ACS with Geneva Server.  Stay tuned…

Posted in .NET Services | Leave a Comment »

Part2: ACS Federation with Custom STS

Posted by zamd on January 23, 2009

In yesterday’s post I talked about ACS and how to interact with it as a standard web service, providing claims transformation functionality. Today I will show how we can federate ACS with our custom STS written using Geneva Framework. This architecture opens up many interesting scenarios. Here are the major steps involved in this architecture.

  • We need to establish a trust relationship between our local STS and Access Control Service (ACS). We can do this using ACS web portal. This is essentially just exchange of certificate(s)
  •  I have already created a simple STS, which runs on the same machine as my client, so it will issue tokens to any caller (anonymous or authenticated).
  • Once I got token from my local STS, I will pass this token to ACS, which will use the claims contained in this token to derive its transformation logic and will return a new token with different claims.
  • I can now present this new token to any web service or web site (which trust ACS) and get my job done.

Here is simple code, which first gets token from local STS and then uses it to get a new token from ACS.

private static void GetTokenFromACS Using SAMLToken GeneratedBy MyCustomSTS()

{

    // This is using WSFed binding – so WCF is doing it’s magic of intermediate token acquistion.

    var binding = new CustomBinding(“IssuedTokenForCertificate”);

   

    var acsCert = GetACSCertificate();

    var identity = new X509CertificateEndpointIdentity(acsCert);

 

    var epa = new EndpointAddress(new Uri(http://accesscontrol.windows.net/sts/eval01/saml for certificate), identity);

    var trustVersion = TrustVersion.WSTrust13;

    var clientCredentials = new ClientCredentials();

 

    WSTrustClient client = new WSTrustClient(binding, epa, trustVersion, clientCredentials);

    RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue, KeyTypeConstants.Symmetric);

 

    try

    {

        RequestSecurityTokenResponse rstr;

        var token = client.Issue(rst, out rstr) as GenericXmlSecurityToken;

        var rpCert = new X509Certificate2(“zamdnetprivatekeycert.pfx”, “a”);

 

        var txtStat = ExtractSAMLAssertion(token, rpCert);

    }

    catch (Exception exp)

    {

        Console.WriteLine(exp.ToString());

    }

}

One important difference from yesterday’s post is: we are not using ACS solution credentials here at all (solution userId, password etc). Why? Because we are authenticating with our local STS, and ACS simply trust the token issued by our local STS. With the architecture, we can easily go and change our authentication mechansim with our local STS (go from Annonymous to kerberos) without effecting ACS.

This is how the binding configuration look like:

        <binding name=IssuedTokenForCertificate>

          <security authenticationMode=IssuedTokenForCertificate

            messageSecurityVersion=WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10

            requireSignatureConfirmation=false>

            <issuedTokenParameters keyType=SymmetricKey tokenType=http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1>

              <claimTypeRequirements>

                <add claimType=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name />

              </claimTypeRequirements>

              <issuer address=http://localhost:9000/STS binding=wsHttpBinding

                bindingConfiguration=AnnonyForCertificate>

                <identity>

                  <certificate encodedValue= +7y1Gj9Ta2w== />

                </identity>

              </issuer>

              <issuerMetadata address=http://localhost:9000/STS/mex />

            </issuedTokenParameters>

            <secureConversationBootstrap />

          </security>

          <httpTransport />

        </binding>

So you can see from the above that we are talking to our local STS using wsHttpBinding configured to allow anonymous access.

    <binding name=AnnonyForCertificate>

      <security mode=Message>

        <message clientCredentialType=None negotiateServiceCredential=false

          establishSecurityContext=false />

      </security>

    </binding>

By decrypting the token I can see following assertions returned by ACS.

<saml:AttributeStatement xmlns:saml=urn:oasis:names:tc:SAML:1.0:assertion>

  <saml:Subject>

    <saml:SubjectConfirmation>

      <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>

      <KeyInfo xmlns=http://www.w3.org/2000/09/xmldsig#>

        <e:EncryptedKey xmlns:e=http://www.w3.org/2001/04/xmlenc#>

          <e:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p>

            <DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1 />

          </e:EncryptionMethod>

          <KeyInfo>

            <o:SecurityTokenReference xmlns:o=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd>

              <X509Data>

                <X509IssuerSerial>

                  <X509IssuerName>CN=Root Agency</X509IssuerName>

                  <X509SerialNumber>53391460269745460375752793295988585963</X509SerialNumber>

                </X509IssuerSerial>

              </X509Data>

            </o:SecurityTokenReference>

          </KeyInfo>

          <e:CipherData>

            <e:CipherValue>mhZrKiIRoUyuwy8yXCMWq/xe3H8YyZOh4wMSMh3FknjIamC7QLBhiQAfV1DvQXNJhlY=</e:CipherValue>

          </e:CipherData>

        </e:EncryptedKey>

      </KeyInfo>

    </saml:SubjectConfirmation>

  </saml:Subject>

  <saml:Attribute AttributeName=action AttributeNamespace=http://docs.oasis-open.org/wsfed/authorization/200706/claims>

    <saml:AttributeValue>that’s done</saml:AttributeValue>

  </saml:Attribute>

</saml:AttributeStatement>

Now let me show you how I have established the trust relationship between my STS & ACS and how I configured ACS to return single claim in returned SAML token.

 

So the above rule says: If you get a token issued by zamd.net (which is my local STS) and it contains a Name claim with the value of Zulfiqar. Please send back an Action claim with the value of “that’s done”.  Because that’s the only rule dealing with my local STS that’s why the returned token has only one claim in it.

And finally this is how I established a trust relationship between my STS and ACS. I added a new issuer using the Portal, uploading my STSs public key certifcate to ACS and that’s it.

Now with this certificate, ACS can correctly validate that incomming token is indeed issued by my local STS(because STS signs the issued token), and then runs the transformation logic to choose correct set of claims to return back.

In this post, all the funcationality of going to the local STS, getting token and attaching it to the Issue call made to ACS is done by WSFederationHttpBinding. In the next post,I will show a more explicit way of achieving the same result, so that you can  have control over the token issued by your local STS, you can cache etc, and then forward it to ACS on your will.  Stay tuned…

Posted in .NET Services | Leave a Comment »

Access Control Service – Part1

Posted by zamd on January 22, 2009

.Net Services include a service known as “Access Control Service”, which is a cloud based Security Token Service (STS). 

ACS supports both active (WS-Trust) and passive (WS-Federation) clients.  In this post I will talk about WS-Trust support in ACS. 

Basic function of any STS is to accepts a token and return a different token essentially doing claims transformation. This claims transformation is also at the core of ACS. It use a very flexible rule based transformation engine to map input claims into output claims.  I have already signed up for .NET Services account and also downloaded & installed the SDK which includes some useful end-2-end samples. I will start with individual pieces and then try to connect them together in step by step manner. 

Ok let’s see how we can talk to ACS just like another web service? ACS token issuance functionality is available using many different bindings (you can easily get this list by using “Add Service Reference” command or svcutil.exe). 

Now thinking in terms of WCF: we already got a service, which is accessible over internet, so we need a WCF proxy to call it. 

Geneva Framework introduced a new class known as WSTrustClient – As the name suggest, this class is a WCF proxy for WS-Trust contract. If you can’t use Geneva Framework then this same functionality is also provided by WCF. Please see my other post on IssuedSecurityTokenProvider.  In this post – I’m going to use Geneva Framework because that’s the recommended approach for this scenario. Here is the code we can use to invoke ACS. 

private static void AcquireTokenFromACSUsingUserName() 

{ 

    var binding = new WS2007HttpBinding(“userNameForCert”); 

  

    //ACS(STS) signing certificate…        

    //Replace following string with actual ACS cert string 

    var certData = Convert.FromBase64String(“AwAAAAEOoik=”); 

    var acsCert = new X509Certificate2(certData); 

    var identity = new X509CertificateEndpointIdentity(acsCert); 

  

    var epa = new EndpointAddress(new Uri(http://accesscontrol.windows.net/sts/eval01/username for certificate”), identity); 

  

    var trustVersion = TrustVersion.WSTrust13; 

    var clientCredentials = new ClientCredentials(); 

  

    clientCredentials.UserName.UserName = “your solution userName”; 

    clientCredentials.UserName.Password = “your solution password”; 

  

    WSTrustClient client = new WSTrustClient(binding, epa, trustVersion, clientCredentials); 

    RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue, KeyTypeConstants.Symmetric); 

    rst.AppliesTo = new EndpointAddress(http://zamd.net&#8221;); 

  

    RequestSecurityTokenResponse rstr; 

     

    // Send token issuance request to ACS. 

    var samltok = client.Issue(rst, out rstr); 

} 

By running above – I get a token back from ACS.  

  

  

Now Because I own the certificate for relying part (zamd.net) – I have written some code to decrypt the issued token to see the returned claims. Here is that code:  

    var rpCert = new X509Certificate2(“zamdnetprivatekeycert.pfx”, “a”); 

    var token = samltoken as GenericXmlSecurityToken; 

    var txtStat = ExtractSAMLAssertion(token, rpCert);  

Following SAML assertion is returned in the response token. 

<saml:AttributeStatement xmlns:saml=urn:oasis:names:tc:SAML:1.0:assertion> 

  <saml:Subject> 

    <saml:SubjectConfirmation> 

      <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod> 

      <KeyInfo xmlns=http://www.w3.org/2000/09/xmldsig#> 

        <e:EncryptedKey xmlns:e=http://www.w3.org/2001/04/xmlenc#> 

          <e:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p> 

            <DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1 /> 

          </e:EncryptionMethod> 

          <KeyInfo> 

            <o:SecurityTokenReference xmlns:o=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd> 

              <X509Data> 

                <X509IssuerSerial> 

                  <X509IssuerName>CN=Root Agency</X509IssuerName> 

                  <X509SerialNumber>53391460269745460375752793295988585963</X509SerialNumber> 

                </X509IssuerSerial> 

              </X509Data> 

            </o:SecurityTokenReference> 

          </KeyInfo> 

          <e:CipherData> 

            <e:CipherValue>m7738wsrTe1GVNHl3wl1QEq4AJBERZY7GI7MMlWqRZBjM8T2UbrtK7M40+2JEm0JpgDMnVoq8Zhc8V5ui20lHKhAw2fOYSUBU529ZBzqKbYqDvIGApTXlp9ZVTvqS+Xo2kM315XtURkPHqmWvMA2eUUdZjA9tC+pvulWcuG2N4E=</e:CipherValue> 

          </e:CipherData> 

        </e:EncryptedKey> 

      </KeyInfo> 

    </saml:SubjectConfirmation> 

  </saml:Subject> 

  <saml:Attribute AttributeName=username AttributeNamespace=http://schemas.microsoft.com/strata/2008/09/accesscontrol/claims> 

    <saml:AttributeValue>Eval01</saml:AttributeValue> 

  </saml:Attribute> 

  <saml:Attribute AttributeName=action AttributeNamespace=http://docs.oasis-open.org/wsfed/authorization/200706/claims> 

    <saml:AttributeValue>Eval01Confirmed</saml:AttributeValue> 

  </saml:Attribute> 

  <saml:Attribute AttributeName=name AttributeNamespace=http://schemas.xmlsoap.org/ws/2005/05/identity/claims> 

    <saml:AttributeValue>Zulfiqar Ahmed (Orignal)</saml:AttributeValue> 

  </saml:Attribute> 

  <saml:Attribute AttributeName=upn AttributeNamespace=http://schemas.xmlsoap.org/ws/2005/05/identity/claims> 

    <saml:AttributeValue>Eval01</saml:AttributeValue> 

  </saml:Attribute> 

  <saml:Attribute AttributeName=name AttributeNamespace=http://schemas.xmlsoap.org/ws/2005/05/identity/claims> 

    <saml:AttributeValue>Eval01</saml:AttributeValue> 

  </saml:Attribute> 

</saml:AttributeStatement>  

  

So how does ACS decided to include these and only these claims in the returned token? Becase I have configured it using the portal- my portal configuration looks like following: 

  

  

Finally here is WCF binding used to talk to ACS.  

    <bindings> 

      <ws2007HttpBinding> 

        <binding name=userNameForCert> 

          <security mode=Message> 

            <message clientCredentialType=UserName negotiateServiceCredential=false 

              establishSecurityContext=false /> 

          </security> 

        </binding> 

      </ws2007HttpBinding> 

    </bindings> 

Posted in .NET Services | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.