We all know the following limitations about Windows Identity Foundation (WIF) and passive (browser) federation protocols, right?

• WIF does not support SAML2.0 protocol (SAML2P)
• There is a WIF extension out there to support SAML2P but it is a technology preview
• WIF does support SAML2.0 (SAML2) tokens
• WS-Federation conveys SAML1.1 tokens

Therefore, unless you use the WIF extension there is no way of getting a SAML2 token into a Relying Party (RP) application.

Well, did you know the following?

• WS-Federation responses convey WS-Trust RequestSecurityTokenResponse (RSTR) elements containing security tokens
• The RSTR element is not tied into a particular token format
• i.e. – it is a <xs:any> element in the schema

This means that it is perfectly valid for a WS-Federation response to convey a SAML2.0 token and it is only because WS-Federation existed before SAML2P that it became a de facto convention for WS-Federation to convey SAML1.1 tokens.

So, it IS possible to get a SAML2 token into a RP application as long as it is possible to get a SAML2 token into a WS-Federation response.

Here’s how.

Methodology

To achieve this I am using Active Directory Federation Services (ADFS 2.0) as it is simple to integrate with WIF and it understands SAML2P, and therefore SAML2 tokens.

The setup is a Windows Server 2012 domain controller with the ADFS 2.1 role installed. All code was written using Visual Studio 2012 and .NET framework 4.5 although the same could be achieved with Windows Server 2008 R2, Visual Studio 2010 and .NET framework 4.0.

As discussed, this won’t work:

But this should:

The strategy is to place an intermediary RP-STS between RP and ADFS which performs protocol transition from SAML2P to WS-Federation.

To make things a little simpler, I have applied the following restrictions to the RP-STS:

• It is not a signing authority
• That is, it cannot create authoritative tokens itself but simply passes on tokens received from other providers
• It does not validate either the protocol wrapper or token itself
• This would involve a lot of extra code and the RP is going to do it anyway
• The SAMLResponse wrapper element received from ADFS containing a SAML2 token is not digitally signed
• The SAML2P specification does allow for a digital signature though
• The RP-STS only recognises messages transmitted using the SAML 2.0 HTTP redirect and POST bindings

The RP-STS itself is simply a ASP.NET HTTP module hosted in IIS. The first event in the ASP.NET pipeline, BeginRequest, is handled as there is nothing more for the module to do than parse tokens.

The flow of events is as follows:

The actual code is shown below:

namespace RelyingPartySTS
{
    using System;
    using System.Configuration;
    using System.IdentityModel.Protocols.WSTrust;
    using System.IdentityModel.Services;
    using System.IdentityModel.Tokens;
    using System.IO;
    using System.Web;
    using System.Xml;

    public class TranslatorModule : IHttpModule
    {
        private const string SamlRequestTemplate = "<samlp:AuthnRequest ID=\"id-{0}\" Version=\"2.0\" IssueInstant=\"{1}\" Destination=\"https://www.bradsts.com/adfs/ls/\" Consent=\"urn:oasis:names:tc:SAML:2.0:consent:unspecified\" xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\"><Issuer xmlns=\"urn:oasis:names:tc:SAML:2.0:assertion\">{2}</Issuer><samlp:NameIDPolicy Format=\"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified\" AllowCreate=\"true\" /></samlp:AuthnRequest>";

        private const string SamlHandlerContent = "<html><head><title>Working...</title></head><body><form method='POST' name='hiddenform' action='{0}'><input type='hidden' name='SAMLRequest' value='{1}' /><noscript><p>Script is disabled. Click Submit to continue.</p><input type='submit' value='Submit' /></noscript></form><script language='javascript'>window.setTimeout('document.forms[0].submit()', 0);</script></body></html>";

        public void Dispose()
        {
            //clean-up code here.
        }

        public void Init(HttpApplication context)
        {
            context.BeginRequest += new EventHandler(OnBeginRequest);
        }

        public void OnBeginRequest(Object source, EventArgs e)
        {
            try
            {
                WSFederationMessage mess = WSFederationMessage.CreateFromUri(HttpContext.Current.Request.Url);

                if (mess is SignInRequestMessage)
                {
                    SignInRequestMessage messIn = mess as SignInRequestMessage;

                    // Convert the WS-Fed request into a SAML2 request
                    string parsedRequest = System.Web.HttpUtility.HtmlEncode(
                        System.Convert.ToBase64String(
                        System.Text.Encoding.UTF8.GetBytes(
                        string.Format(
                            SamlRequestTemplate, 
                            Guid.NewGuid().ToString(), 
                            DateTime.UtcNow.ToString("yyyy-MM-ddTHH:MM:ss.fffZ"), 
                            messIn.Realm))));

                    // Redirect the request to ADFS
                    string finalisedRedirectString = string.Format(
                        SamlHandlerContent,
                        ConfigurationManager.AppSettings["stsUrl"],
                        parsedRequest);

                    HttpContext.Current.Response.Write(finalisedRedirectString);
                    HttpContext.Current.ApplicationInstance.CompleteRequest();
                }
            }
            catch (WSFederationMessageException)
            {
                // Parse the SAMLResponse
                if (HttpContext.Current.Request.Form.HasKeys())
                {
                    if (HttpContext.Current.Request.Form["SAMLResponse"] != null)
                    {
                        // Decode the response
                        string samlResponse = HttpContext.Current.Request.Form["SAMLResponse"];
                        string responseDecoded = System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(System.Web.HttpUtility.HtmlDecode(samlResponse)));

                        Saml2SecurityToken token = null;

                        // Pick out the token
                        using (StringReader sr = new StringReader(responseDecoded))
                        {
                            using (XmlReader reader = XmlReader.Create(sr))
                            {
                                reader.ReadToFollowing("Assertion", "urn:oasis:names:tc:SAML:2.0:assertion");
                                
                                // Deserialize the token so that data can be taken from it and plugged into the RSTR
                                SecurityTokenHandlerCollection coll = SecurityTokenHandlerCollection.CreateDefaultSecurityTokenHandlerCollection();
                                token = (Saml2SecurityToken)coll.ReadToken(reader.ReadSubtree());
                            }
                        }

                        // Create a WS-Fed sign in response
                        RequestSecurityTokenResponse rstr = new RequestSecurityTokenResponse();
                        rstr.TokenType = "urn:oasis:names:tc:SAML:2.0:assertion";
                        rstr.RequestType = "https://schemas.xmlsoap.org/ws/2005/02/trust/Issue";
                        rstr.KeyType = "https://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey";
                        rstr.Lifetime = new Lifetime(token.Assertion.IssueInstant, token.Assertion.Conditions.NotOnOrAfter);
                        rstr.AppliesTo = new EndpointReference(token.Assertion.Conditions.AudienceRestrictions[0].Audiences[0].OriginalString);
                        rstr.RequestedSecurityToken = new RequestedSecurityToken(token);
                        WSTrustFeb2005ResponseSerializer ser = new WSTrustFeb2005ResponseSerializer();
                        MemoryStream ms = new MemoryStream();

                        SignInResponseMessage messOut = null;

                        using (StreamReader sr = new StreamReader(ms))
                        {
                            using (XmlWriter writer = XmlWriter.Create(ms))
                            {
                                ser.WriteXml(rstr, writer, new WSTrustSerializationContext());
                            }

                            ms.Position = 0;

                            messOut = new SignInResponseMessage(new Uri(ConfigurationManager.AppSettings["rpUrl"]), sr.ReadToEnd());
                        }                    

                        // Redirect the browser to RP
                        messOut.WriteFormPost();
                        HttpContext.Current.Response.Write(messOut.WriteFormPost());
                        HttpContext.Current.ApplicationInstance.CompleteRequest();
                    }
                }
            }
        }
    }
}

This ‘almost’ works in that the SAML2 token is successfully extracted from the ADFS response and plugged into a WS-Federation response which is forwarded to the RP website.

However, it turns out that WIF takes exception to the token! You will get the following error message:

“ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.”

If, as the error suggests, a custom SecurityTokenHandler implementation is created that derives from the default Saml2SecurityTokenHandler implementation, and the ValidateConfirmationData method is overridden, this error can be avoided.

An aside:

In fact, upon inspection of the SAML2 token, the InResponseTo attribute referred to above is actually inappropriate for the RP website as it contains the URL for the RP-STS website. However, as WIF appears to block tokens containing this attribute anyway, there can’t very well be much meaningful code beyond the error that would worry about it.

I believe that this inaccuracy in the URL could be circumvented by combining the RP and RP-STS websites together so that they exist under a common domain name. The conversion from WS-Federation request to SAMLRequest could take place in the OnRedirectingToIdentityProvider event handler and conversely, the conversion from ADFS SAMLResponse to WS-Federation response could take place in a HTTP module which fires before the default WIF pipeline takes over.

Conclusion

I have shown that it is possible to use relatively few lines of code to facilitate the transmission of SAML2 tokens into a standard WIF protected website by transitioning to/from WS-Federation to SAML2P federation protocols.

I believe that in the absence of proper SAML2P support in Windows Identity Foundation this approach, with a bit of work to bring the code up to production standards, is a viable one.

[BradleyCotier]

Is it possible to secure a website using Windows Identity Foundation (WIF) without interfering with an existing authentication method? e.g. – Could a website secured using an ASP.NET membership provider, with all the code and configuration that entails, be layered with additional code and configuration to allow a precursory authentication with a trusted Identity Provider (IdP). In a more extreme case, would it be possible to force a user to authenticate with a trusted IdP of choice before also forcing them to authenticate with another trusted IdP? In both cases surely there would be too much overlap such that one would interfere with the other, making the combination untenable.

Well, before answering the question, why might you want to do this?

A recent project was concerned with providing Windows Azure hosting capabilities for customer websites. The product enables creation of customisable boiler plate websites and automated deployment and management/monitoring of said websites into Azure. As all websites in Azure are publicly available (ok you would have to know the cloudapp.net URL) the customer had no opportunity to test the finished website before it was available to a public audience. Therefore, a specific functional requirement was for the production website to be up and running in ‘preview’ mode and for only the preview audience to have access to it; the preview audience being a limited number of website developers/stakeholders. Once the website passed muster, a switch could be flicked and the public audience would gain access.

(It should be mentioned that securing the site by client ip address was untenable as the preview audience could range from tablet owners sitting in internet cafes to desktop based developers working either at home or in the office.)

Instead, the customer exposes their corporate Active Directory to the internet using Active Directory Federation Services (ADFS 2.0) and so this was potentially an authoritative source for authenticating the preview audience. The problem was how to use this resource without fundamentally modifying the existing authentication mechanism for the website.

Essentially:

“I want authN method X in production but in preview I want authN method Y followed by authN method X”

So, in the production configuration (i.e – authN method X only), the website may utilise an ASP.NET membership provider or perhaps federate with an external identity provider such as Live, Facebook etc. In fact it could employ any flavour of authentication/authorisation. An example is shown below where WIF is used to federate with Live, via the Azure Access Control Service (ACS):

In the preview configuration, there would be an additional authentication step so that the preview audience would have to log in with their corporate credentials against ADFS 2.0 and then also have to log in to Live, via ACS. An example is shown below:

In the methodology that follows I have used Visual Studio 2012, .NET4.5 (WIF is baked into .NET4.5 whereas previously it was a separate download), IIS8 and Windows Server 2012. However, the general methodology will also apply to Visual Studio 2010, .NET4, IIS7.5 and Windows Server 2008 R2.

Methodology

Ordinarily, WIF is enforced by two HTTP modules which are injected into the web.config file for the website (I have abbreviated the assembly names for formatting purposes):

<system.webServer>
  <modules>
    <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services" />
    <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services" />
  </modules>
</system.webServer>

These modules implement event handlers that are raised in the ASP.NET pipeline for each HTTP request. Using the source code decompiler of your choice, we find that the earliest event handler for each module is the AuthenticateRequest event.

To layer ADFS authentication on top of this I am going to implement a custom HTTP module and similarly handle the AuthenticateRequest event. Crucially though, the custom module is first in the module list so that it fires before the WIF modules:

<system.webServer>
  <modules>
    <add name="BouncerModule" type="RelyingParty.BouncerModule, RelyingParty" />
    <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services" />
    <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services" />
  </modules>
</system.webServer>

Apologies for the name ‘BouncerModule’. It just kind of stuck amongst the team and it does sort of act in the role of a nightclub doorman.

So, what are the important characteristics of the module?

To achieve most of these aims I will make use of named WIF configuration.

What do I mean by named configuration?

For a standard WIF protected website in .NET 4.5 (in this case the website federates with Azure Access Control Service (ACS)), the configuration looks like the following:

<system.identityModel>
  <identityConfiguration>
    <audienceUris>
      <add value="urn:relyingpartyacs.com" />
    </audienceUris>
    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel">
      <trustedIssuers>
        <add thumbprint="4AC4CB9A11C9EEDA95DA3B65295BD56F365E65FF" name="https://bradcot.accesscontrol.windows.net/" />
      </trustedIssuers>
    </issuerNameRegistry>
    <certificateValidation certificateValidationMode="None" />
  </identityConfiguration>
</system.identityModel>
<system.identityModel.services>
  <federationConfiguration>
    <cookieHandler requireSsl="true" />
    <wsFederation passiveRedirectEnabled="true" issuer="https://bradcot.accesscontrol.windows.net/v2/wsfederation" realm="urn:relyingpartyacs.com" requireHttps="true" />
  </federationConfiguration>
</system.identityModel.services>

For this configuration, when the website is browsed, the user is asked to authenticate at Live, via Azure ACS, as is desired in production.

Below the configuration is extended to include sections that are explicitly named. A new <identityConfiguration> element named ‘adfs’ is added (the name chosen is not important) which in turn is referenced by a similarly named <federationConfiguration> element.

<system.identityModel>
  <identityConfiguration>
    <audienceUris>
      <add value="urn:relyingpartyacs.com" />
    </audienceUris>
    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel">
      <trustedIssuers>
        <add thumbprint="4AC4CB9A11C9EEDA95DA3B65295BD56F365E65FF" name="https://bradcot.accesscontrol.windows.net/" />
      </trustedIssuers>
    </issuerNameRegistry>
    <certificateValidation certificateValidationMode="None" />
  </identityConfiguration>
  <identityConfiguration name="adfs">
    <audienceUris>
      <add value="urn:relyingpartyadfs.com" />
    </audienceUris>
    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel">
      <trustedIssuers>
        <add thumbprint="416565b7d2193df7cc82de7981df59a600b7af67" name="https://www.bradsts.com/adfs/services/trust/" />
      </trustedIssuers>
    </issuerNameRegistry>
    <certificateValidation certificateValidationMode="None" />
  </identityConfiguration>
</system.identityModel>
<system.identityModel.services>
  <federationConfiguration>
    <cookieHandler requireSsl="true" />
    <wsFederation passiveRedirectEnabled="true" issuer="https://bradcot.accesscontrol.windows.net/v2/wsfederation" realm="urn:relyingpartyacs.com" requireHttps="true" />
  </federationConfiguration>
  <federationConfiguration name="adfs" identityConfigurationName="adfs">
    <cookieHandler requireSsl="true" />
    <wsFederation passiveRedirectEnabled="true" issuer="https://www.bradsts.com/adfs/ls/" realm="urn:relyingpartyadfs.com" requireHttps="true" />
  </federationConfiguration>
</system.identityModel.services>

The WIF pipeline will only use the unnamed sections. However, with the bouncer module in place, the named configuration can be used as follows:

N.B. – I have not included the code but would be happy to discuss any aspect of it if you have specific questions.

Some steps need a bit of explanation:

4 & 12 – It is crucial that the session cookie created by the bouncer module has a different name to that used by the WIF pipeline, ‘FedAuth’. In this way the ADFS token that is contained within the cookie does not overlap with the ACS token.

6 – If the ADFS token passes validation there is nothing more to be done. End and allow the WIF pipeline to process the session cookie containing the ACS token. Otherwise, redirect the browser to ADFS for re-authentication.

11 – The reply address is stored within the ‘ru’ query string parameter of the redirect received from ADFS. The reply address is either the root of the website or a relative URI to a location within the website. If these checks are not performed it might be possible for a nefarious query string to cause the browser to be redirected to a malicious website.

Conclusion

In this article I have shown that it is possible to add an extra authentication step into a website, on top of the existing authentication method. In the example a website which, in production, would federate with Live via Azure ACS, was altered so that a precursory authentication against ADFS was mandated.

This was all achieved using named WIF configuration and a standalone ASP.NET HTTP module that very deliberately leaves no trace in the pipeline after execution is complete.

[BradleyCotier]

Reproducing the problem

The problem is easily reproduced using the following steps:

• Create an empty ASP.NET website and set up federation with ADFS
• Ensure that a UPN claim is emitted by ADFS
• Modify C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config to allow access to authenticated users

• Start the C2WTS service via start-run-services.msc
• Modify the ASP.NET web.config file to enable identity impersonation

• Modify the ASP.NET web.config file to enable communication with the C2WTS service

• Log in via ADFS
• Perform an IIS reset
• Refresh the page

The following error will occur:

Either a required impersonation level was not provided, or the provided impersonation level is invalid. (Exception from HRESULT: 0x80070542)

This error is fairly catastrophic as the entire app pool is compromised until it is recycled. i.e. – it is not the currently logged in user that no longer has access, it is all users!

The solution

As stated previously, recycling the app pool resolves the issue but this is not a satisfactory solution.

To understand the solution it is necessary to go under the covers of Windows Identity Foundation and look at the innards of the Microsoft.IdentityModel.Tokens.Saml11.SAML11SecurityTokenHandler class.

Within the ValidateToken method the following code is executed:

As you can see, the code is conditional on the mapToWindows and useWindowsTokenService flags present in the microsoft.identityModel configuration section. This means that if both flags are true, the C2WTS service will be called every time the handler is invoked.

The problem though is that this handler is only invoked once when the SAML assertion from ADFS is first presented to the ASP.NET website. Every subsequent page hit instead invokes the Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler class which deserialises the claims collection held within a cookie. This handler does not, in the out of the box implementation, call the C2WTS service and so, after an IIS reset, even though the user still has access to the website based upon the cookie contents, all impersonation detail is lost and so the error occurs.

Some investigation of the SessionSecurityTokenHandler class reveals that it also uses a flag called useWindowsTokenService but it is false in the default implementation.

The solution is to remove the default SessionSecurityTokenHandler implementation and add in a new one where the useWindowsTokenService flag is set to true, as shown below:

The logged in session will now survive an IIS reset.

Hope this helps.

Brad

This worked fine but I kept seeing an intermittent error in the MVC site stating:

“The pipe endpoint 'net.pipe://localhost/s4u/022694f3-9fbd-422b-b4b2-312e25dae2a2' could not be found on your local machine.”

I tracked this down to the C2WTS service which was shutting down, with the following informational message written to the System event log:

“The Claims to Windows Token Service service entered the stopped state.”

and:

“The start type of the Claims to Windows Token Service service was changed from auto start to disabled.”

Note, there were no obviously related error messages, just these two statements.

I looked around the event logs and found this for the same timestamp:

“The SharePoint Health Analyzer found and fixed the following problem: One or more services have started or stopped unexpectedly.”

Sorry, I probably hadn’t mentioned until now that SharePoint 2010 was installed … anyway, it appeared that SharePoint was ‘fixing’ a problem for me. This kept me on the path of thinking that there was something wrong with the C2WTS service itself.

However, it transpired that SharePoint was in fact disabling the service because SharePoint configuration dictated that the service be stopped. When monitoring showed this not to be the case (because I re-enabled it), SharePoint would shut the service down again!

Therefore, the ‘Central Administration – Services on Server’ page within SharePoint that describes the state of services that SharePoint is dependent on not only describes the current state of the service but also the state that SharePoint would like it to be in.

I therefore changed the expected state of the C2WTS service to started within SharePoint, and SharePoint duly started it up.

Finally, there was one more curveball thrown at me. When SharePoint started the service it also modified the C2WTS configuration file so that ONLY users of the WSS_WPG group could use it. As the MVC site in question was entirely separate from SharePoint, the C2WTS call still failed.

I therefore had to modify the C2WTS configuration file located at ‘C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config’ so that the <allowedCallers> element went from:

<allowedCallers>
    <clear />
    <add value="WSS_WPG" />
</allowedCallers>

to:

<allowedCallers>
    <clear />
    <!--<add value="NT AUTHORITY\Network Service" /> 
    <add value="NT AUTHORITY\Local Service" /> 
    <add value="NT AUTHORITY\System" />--> 
    <add value="NT AUTHORITY\Authenticated Users" />
</allowedCallers>

Hope this helps.

Brad

• The token type is pre-existing and needs to be federated
• The new token type is an extension to a token type already supported by WIF

However, the purpose of this article is to demonstrate one of the extensibility points of WIF and so the reasons for creating a new token type are not so important.

Before continuing I should point out that I am not creating a new wire protocol for conveying tokens but instead using an existing wire protocol (WS-Federation) to pass a new token type. WS-Federation is well suited to this because it is a means of conveying WS-Trust tokens using browser redirects. In turn, WS-Trust is essentially a container for …. well, any token type you like and that is why we can create a new token type without risk of breaking any standards.

I am going to take a trial and error approach to this so that you can see some of the common pitfalls. I will simply fire a new token, wrapped within a WS-Trust 1.3 envelope and conveyed by the WS-Federation Passive Requestor Profile, as a sign-in response message to the Relying Party (RP) application. Then, I will fix the RP application by reacting to the errors that occur. Using this methodology you may get a fuller understanding of how to implement a new token handler and token.

First I need an STS to send a custom token to the RP. To do this I have captured a sign in response using Http Watch (a really good and easy to use HTTP sniffer), changed the token within the  WS-Federation wresult parameter, and hardcoded it as the STS response; this was achieved using a ASP.NET website with a HttpHandler implementation.

The custom token to be consumed by the RP looks like the following:

<m:MyCustomToken 
    xmlns:m="urn:mycustomtoken" 
    m:Id="D416881A-130B-4AFF-8091-F412D7440E39" 
    m:Issuer="urn:mycustomtokenhandlersts" 
    m:Audience="https://mycustomtokenhandlerwebsite/" 
    m:ValidFrom="2011-01-01" 
    m:ValidTo="2099-12-31">
    <m:Claim Name="GivenName" Namespace="urn:givenname">John</m:Claim>
    <m:Claim Name="Surname" Namespace="urn:surname">Doe</m:Claim>
    <m:Claim Name="Role" Namespace="urn:role">Manager</m:Claim>
    <Signature xmlns="https://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
            <CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
            <SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <Reference URI="">
                <Transforms>
                    <Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
                </Transforms>
                <DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
                <DigestValue>gK8K+94DbXsVHxE8X3ulh45WcEM=</DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue>… removed for brevity …</SignatureValue>
        <KeyInfo>
            <X509Data>
                <X509Certificate>… removed for brevity …</X509Certificate>
            </X509Data>
        </KeyInfo>
    </Signature>
</m:MyCustomToken>

• Id – a unique identifier for the token (can be used to detect replay attacks)
• Namespace – the namespace for the token
• Issuer – the entity that issued the token to the RP
• ValidFrom/ValidTo – the validity period of the token
• Audience – the entity that the token is intended for
• Claims – a set of authoritative statements about the identity described by the token
• Digital signature – ensures that the message cannot be tampered with and also enforces the authoritative nature of the message

and the <microsoft.identityModel> configuration section of the RP config file currently has no awareness of the new token type:

<microsoft.identityModel>
    <service>
        <audienceUris>
            <add value="https://mycustomtokenhandlerwebsite/" />
        </audienceUris>
        <federatedAuthentication>
            <wsFederation 
                passiveRedirectEnabled="true" 
                issuer="https://localhost:29460/MyCustomTokenHandlerSTS/STSHandler.ashx" 
                realm="https://mcthw" 
                requireHttps="false" />
            <cookieHandler requireSsl="false" />
        </federatedAuthentication>
        <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry">
            <trustedIssuers />
        </issuerNameRegistry>
    </service>
</microsoft.identityModel>

“ID4014: A SecurityTokenHandler is not registered to read security token ('MyCustomToken', 'urn:mycustomtoken')”

This seems reasonable as I have not yet made any effort to recognise the token. I therefore need the bare bones of a custom SecurityTokenHandler implementation:

using System;
using Microsoft.IdentityModel.Tokens;

/// <summary>
/// Summary description for MyCustomTokenHandler
/// </summary>
public class MyCustomTokenHandler : SecurityTokenHandler
{
    public MyCustomTokenHandler()
    {
    }

    public override string[] GetTokenTypeIdentifiers()
    {
        throw new NotImplementedException();
    }

    public override Type TokenType
    {
        get { throw new NotImplementedException(); }
    }
}

using System;
using System.IdentityModel.Tokens;

/// <summary>
/// Summary description for MyCustomToken
/// </summary>
public class MyCustomToken : SecurityToken
{
    public MyCustomToken()
    {
    }

    public override string Id
    {
        get { throw new NotImplementedException(); }
    }

    public override ReadOnlyCollection<SecurityKey> SecurityKeys
    {
        get { throw new NotImplementedException(); }
    }

    public override DateTime ValidFrom
    {
        get { throw new NotImplementedException(); }
    }

    public override DateTime ValidTo
    {
        get { throw new NotImplementedException(); }
    }
}

<securityTokenHandlers>
    <add type="MyCustomTokenHandler" />
</securityTokenHandlers>

public override string[] GetTokenTypeIdentifiers()
{
    return new string[] { "urn:mycustomtoken" };
}

public override Type TokenType
{
    get { return typeof(MyCustomToken); }
}

public virtual bool CanReadToken(XmlReader reader)
{
    return false;
}

public override bool CanReadToken(XmlReader reader)
{
    if (reader.LocalName.Equals("MyCustomToken") &&
        reader.NamespaceURI.Equals("urn:mycustomtoken"))
    {
        return true;
    }

    return false;
}

using System;
using System.Collections.Generic;
using Microsoft.IdentityModel.Claims;

/// <summary>
/// Summary description for MyCustomTokenInternal
/// </summary>
public class MyCustomTokenInternal
{
    public string Id
    {
        get;
        set;
    }

    public DateTime ValidFrom
    {
        get;
        set;
    }

    public DateTime ValidTo
    {
        get;
        set;
    }

    public string Audience
    {
        get;
        set;
    }

    public string Issuer
    {
        get;
        set;
    }

    public IEnumerable<Claim> Claims
    {
        get;
        set;
    }
}

public override SecurityToken ReadToken(XmlReader reader)
{
    // Check token signature using EnvelopedSignatureReader (more performant but more complex to use)
    // or SignedXml (easier to use but less performant)

    MyCustomToken token = new MyCustomToken(
        new MyCustomTokenInternal()
        {
            Id = reader.GetAttribute("Id", TokenNamespace),
            ValidFrom = XmlConvert.ToDateTime(reader.GetAttribute("ValidFrom", TokenNamespace)),
            ValidTo = XmlConvert.ToDateTime(reader.GetAttribute("ValidTo", TokenNamespace)),
            Audience = reader.GetAttribute("Audience", TokenNamespace),
            Issuer = reader.GetAttribute("Issuer", TokenNamespace),
            Claims = from el in XElement.Load(reader).Elements(XName.Get("Claim", TokenNamespace)) select new Claim(el.Attribute("Namespace").Value, el.Value)
        });

    return token;
}

public override bool CanValidateToken
{
    get
    {
        return true;
    }
}

public override ClaimsIdentityCollection ValidateToken(SecurityToken token)
{
    ClaimsIdentityCollection idColl = new ClaimsIdentityCollection();

    IClaimsIdentity id = new ClaimsIdentity((token as MyCustomToken).Claims);

    idColl.Add(id);

    return idColl;
}

using System;
using System.IdentityModel.Tokens;
using System.Linq;
using System.Xml;
using System.Xml.Linq;
using Microsoft.IdentityModel.Claims;
using Microsoft.IdentityModel.Tokens;

/// <summary>
/// Summary description for MyCustomTokenHandler
/// </summary>
public class MyCustomTokenHandler : SecurityTokenHandler
{
    private const string TokenNamespace = "urn:mycustomtoken";

    public MyCustomTokenHandler()
    {
    }

    public override string[] GetTokenTypeIdentifiers()
    {
        return new string[] { TokenNamespace };
    }

    public override Type TokenType
    {
        get { return typeof(MyCustomToken); }
    }

    public override bool CanReadKeyIdentifierClause(XmlReader reader)
    {
        if (reader.LocalName.Equals("X509Data"))
        {
            return true;
        }

        return false;
    }

    public override bool CanReadToken(XmlReader reader)
    {
        if (reader.LocalName.Equals("MyCustomToken") &&
            reader.NamespaceURI.Equals("urn:mycustomtoken"))
        {
            return true;
        }

        return false;
    }

    public override SecurityToken ReadToken(XmlReader reader)
    {
        // Check token signature using EnvelopedSignatureReader (more performant but more complex to use)
        // or SignedXml (easier to use but less performant)

        MyCustomToken token = new MyCustomToken(
            new MyCustomTokenInternal()
            {
                Id = reader.GetAttribute("Id", TokenNamespace),
                ValidFrom = XmlConvert.ToDateTime(reader.GetAttribute("ValidFrom", TokenNamespace)),
                ValidTo = XmlConvert.ToDateTime(reader.GetAttribute("ValidTo", TokenNamespace)),
                Audience = reader.GetAttribute("Audience", TokenNamespace),
                Issuer = reader.GetAttribute("Issuer", TokenNamespace),
                Claims = from el in XElement.Load(reader).Elements(XName.Get("Claim", TokenNamespace)) select new Claim(el.Attribute("Namespace").Value, el.Value)
            });

        return token;
    }

    public override bool CanValidateToken
    {
        get
        {
            return true;
        }
    }

    public override ClaimsIdentityCollection ValidateToken(SecurityToken token)
    {
        ClaimsIdentityCollection idColl = new ClaimsIdentityCollection();

        IClaimsIdentity id = new ClaimsIdentity((token as MyCustomToken).Claims);

        idColl.Add(id);

        return idColl;
    }
}

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IdentityModel.Tokens;
using Microsoft.IdentityModel.Claims;

/// <summary>
/// Summary description for MyCustomToken
/// </summary>
public class MyCustomToken : SecurityToken
{
    private MyCustomTokenInternal tokenInt;

    public MyCustomToken(MyCustomTokenInternal tokenInt)
    {
        this.tokenInt = tokenInt;
    }

    public override string Id
    {
        get { return this.tokenInt.Id; }
    }

    public override ReadOnlyCollection<SecurityKey> SecurityKeys
    {
        get { return null; }
    }

    public override DateTime ValidFrom
    {
        get { return this.tokenInt.ValidFrom; }
    }

    public override DateTime ValidTo
    {
        get { return this.tokenInt.ValidTo; }
    }

    public IEnumerable<Claim> Claims
    {
        get { return this.tokenInt.Claims; }
    }
}

using System;
using System.Collections.Generic;
using Microsoft.IdentityModel.Claims;

/// <summary>
/// Summary description for MyCustomTokenInternal
/// </summary>
public class MyCustomTokenInternal
{
    public string Id
    {
        get;
        set;
    }

    public DateTime ValidFrom
    {
        get;
        set;
    }

    public DateTime ValidTo
    {
        get;
        set;
    }

    public string Audience
    {
        get;
        set;
    }

    public string Issuer
    {
        get;
        set;
    }

    public IEnumerable<Claim> Claims
    {
        get;
        set;
    }
}

<microsoft.identityModel>
    <service>
        <audienceUris>
            <add value="https://mycustomtokenhandlerwebsite/" />
        </audienceUris>
        <federatedAuthentication>
            <wsFederation 
                passiveRedirectEnabled="true" 
                issuer="https://localhost:29460/MyCustomTokenHandlerSTS/STSHandler.ashx" 
                realm="https://localhost:58724/MyCustomTokenHandlerWebsite/" 
                requireHttps="false" />
            <cookieHandler requireSsl="false" />
        </federatedAuthentication>
        <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry">
            <trustedIssuers />
        </issuerNameRegistry>
        <securityTokenHandlers>
            <add type="MyCustomTokenHandler" />
        </securityTokenHandlers>
    </service>
</microsoft.identityModel>

• https://www.contoso.com/claims/givenname
• https://www.contoso.com/claims/surname

and optionally the claim:

• https://www.contoso.com/claims/dateofbirth

The ADFS Claims Rule Language is designed to allow claims from incoming tokens to be used to query data stores for additional claims.

At first glance it seems easy enough to construct claim rules that would execute for both the case where only the mandatory claims are present, and also the case where the optional claim is included.

The first rule handles the case where all three claims are present:

c:[Type == "https://www.contoso.com/claims/givenname"]
&& c1:[Type == "https://www.contoso.com/claims/surname"]
&& c2:[Type == "https://www.contoso.com/claims/dateofbirth"]

=> ISSUE(store = "Contoso Attribute Store", 
TYPES = ("https://www.contoso.com/claims/privatepersonalidentifier"),
QUERY = "Name={0},Surname={1},DateOfBirth={2}",
PARAM = c.Value, PARAM = c1.Value, PARAM = c2.Value);

and the second rule handles the case where only the mandatory claims are present:

c:[Type == "https://www.contoso.com/claims/givenname"]
&& c1:[Type == "https://www.contoso.com/claims/surname"]

=> ISSUE(store = "Contoso Attribute Store", 
TYPES = (“https://www.contoso.com/claims/privatepersonalidentifier"),
QUERY = "Name={0},Surname={1}",
PARAM = c.Value, PARAM = c1.Value);

So that the rules as viewed through the ADFS GUI look like the following:

Unfortunately, this does not work as expected because of the principle that states:

“All claim rules will fire whose query parameters are satisfied by the claims in the pipeline”

This is fine for the mandatory claim case as only the second rule fires.

However, if the optional claim is also present, both rules fire because the full set of input claims satisfy each set of search criteria. This is still ok if both rules return the same result because ADFS will condense any claims with identical namespace AND value into a single claim. But, it may be the case that the less specific rule, containing only the mandatory claims, will return multiple results (i.e - there are two people with the same name but different dates of birth). As previously stated, ADFS will condense any identical claims but there could still be additional results left over; clearly not ideal as it is possible, using the full set of input claims, to uniquely identify a single user.

This problem has no solution without knowledge of the little documented '”NOT EXISTS” function, in conjunction with the better known ADD function.

The trick is to create three rules.

The first rule checks for the non-presence of the optional claim and adds a dummy claim into the claims pipeline, as follows:

NOT EXISTS([Type == "https://www.contoso.com/claims/dateofbirth"])
=> ADD(Type = "https://dummy", Value = "dummy");

The second rule checks for the existence of the dummy rule and, if present, queries on the mandatory claims only:

c:[Type == "https://www.contoso.com/claims/givenname"]
&& c1:[Type == "https://www.contoso.com/claims/surname”]
&& c2:[Type == "https://dummy", Value == "dummy"]
=> ISSUE(store = "Contoso Attribute Store",
TYPES = ("https://www.contoso.com/claims/privatepersonalidentifier"),
QUERY = "Forename={0},Surname={1}",
PARAM = c.Value, PARAM = c1.Value);

The third rule simply queries on all three input claims:

c:[Type == "https://www.contoso.com/claims/givenname"]
&& c1:[Type == "https://www.contoso.com/claims/surname"]
&& c2:[Type == "https://www.contoso.com/claims/dateofbirth"]
=> ISSUE(store = "Contoso Attribute Store",
TYPES = ("https://www.contoso.com/claims/privatepersonalidentifier"),
QUERY = "Forename={0},Surname={1},DateOfBirth={2}",
PARAM = c.Value, PARAM = c1.Value, PARAM = c2.Value);

The combination works because the two rules that query the Contoso Attribute Store are orthogonal to each other and so only one will fire for a given set of input claims.

Finally, it is worth noting that the ADD function in the first rule only adds a claim to the claims pipeline that will not be present in the resulting token.

I hope you find this useful.

written by [bradleycotier]

The client/service topology is depicted below:

Both the client and server run on a Windows Server 2008 R2 virtual machine with Windows SDK 7.1, Visual Studio 2010, SQL Server Express 2008 R2 and .NET framework 4.0.

Mutual authentication explained

A detailed discussion of public key cryptography is outside the scope of this article. However, I highly recommend that you read more here to get a better understanding of the underlying principles, so that you can better understand the ‘How-To’ steps that follow.

In essence the client possesses a public key certificate (hereafter known as a client certificate) with associated private key. Similarly, the service has possession of another public key certificate (hereafter known as a service certificate) with associated private key. For a given pair of keys, either the public or private key can be used to encrypt data but ONLY the corresponding key can decrypt the data. The public key is available to the world at large but the private key MUST remain with the owner alone. In this way the owner is able to encrypt data using the private key and a party in receipt of encrypted data can decrypt it using the public key. The fact that the receiving party can successfully decrypt the data using the public key means that the data MUST have been encrypted by the corresponding private key and, as only the owner has access to the private key, the data MUST have originated from the owner; this is known as nonrepudiation as the owner cannot claim that encrypted data did not originate from them (of course, the private key may have been stolen but that is a different matter).

Translating this to the current scenario, in order for the client and service to successfully converse using certificates, the WCF client application must have access to the client’s private key and IIS (the receiving party) must have access to the client’s public key. Conversely, IIS must have access to the service private key and the client must have access to the service public key.

In an Active Directory domain, the public key certificate is ordinarily assigned to a domain account such that IIS can locate the certificate using Active Directory Domain Services (ADDS). However, ADDS does not exist in a workgroup environment and so the client certificate public key list must be maintained within IIS itself.

Methodology

1) Create a trusted root certificate

The certificates in this article are issued by a certificate authority, in this case a trusted root certificate created using the makecert tool that ships with the Windows SDK.

• Create a folder somewhere on the file system and, in a command window, change the directory to match the newly created folder  
• Run the following command to create a root certificate (do not define a password)
  • "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\makecert" -r -pe -n "CN=Test Root Authority" -ss CA -sr CurrentUser -a sha1 -sky signature -cy authority -sv TestRoot.pvk TestRoot.cer

   

2) Install the client certificate with private key

The client application, as owner of the client certificate, needs access to the private key at runtime. We are going to create an interactive client (e.g. – Console, WinForm, Silverlight, Internet Explorer etc.), and so the certificate will be installed in the Current User – Personal store. If the client was non-interactive (e.g. – NT service) the certificate would be installed in the Local Machine – Personal store.

Additionally, as the client certificate has been issued from a trusted certificate authority (CA), the root certificate created in 1) must also be installed.

• From the folder where TestRoot.cer is located, create and install a client certificate by running the following in a command window
  • "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\makecert" -n "CN=Test Client" -ic "TestRoot.cer" -iv "TestRoot.pvk" -a sha1 -sky exchange -pe -sr currentuser -ss my "TestClient.cer"
• Open a snap-in window
  • Start – Run – mmc
  • Add/Remove snap-in
  • Ctrl-M
  • Add a Certificates snap-in for ‘My user account’
• Expand the (Trusted Root Certification Authorities)/Certificates node
• Right click the Certificates folder and choose All Tasks – Import
• Browse to TestRoot.cer
• Click through the remaining windows and finish

3) Install the service certificate with private key

The service, as owner of a service certificate, needs access to the private key at runtime. As the service is non-interactive (i.e. – it is not running under the context of a logged-on user), the certificate will be installed in the Local Machine – Personal store.

Additionally, as the service certificate has been issued from a trusted certificate authority (CA), the root certificate for the CA must also be installed so that the chain of trust can be verified.

• From the folder where TestRoot.cer is located, install the service certificate by running the following in a command window
  • "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\makecert" -n "CN=www.mydataservice.com" -ic "TestRoot.cer" -iv "TestRoot.pvk" -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -pe -sr LocalMachine -ss my TestDataService.cer
• Open a snap-in window
  • Start – Run – mmc
  • Add/Remove snap-in
  • Ctrl-M
  • Add a Certificates snap-in for ‘Computer account’
• Expand the (Trusted Root Certification Authorities)/Certificates node
• Right click the Certificates folder and choose All Tasks – Import
• Browse to TestRoot.cer
• Click through the remaining windows and finish

4) Export the client public key certificate

IIS needs access to the client’s public key certificate. In this section the certificate is exported for later use.

• Open a snap-in window (or use the same window as 2))
  • Start – Run – mmc
  • Add/Remove snap-in
  • Ctrl-M
  • Add a Certificates snap-in for ‘My user account’
• Expand the (Certificates – Current User)/Personal/Certificates node
• Right click the Test Client certificate and choose All Tasks – Export (Do not export the primary key)
  • N.B. - Exporting the private key will not cause problems but remember that the private key is for the client ALONE
• Save the certificate as TestClient_Public.cer (Base-64 encoded X.509)

5) Export the service public key certificate

The WCF client needs access to the service public key certificate. In this section the certificate is exported for later use.

• Open a snap-in window (or use the same window as 3))
• Start – Run – mmc
• Add/Remove snap-in
• Ctrl-M
• Add a Certificates snap-in for ‘Computer account’
• Expand the (Certificates – Local Computer)/Personal/Certificates node
• Right click the www.testdataservice.com certificate and choose All Tasks – Export (Do not export the primary key)
  • Exporting the private key will not cause problems but remember that the private key is for the service ALONE
• Save the certificate as TestDataService_Public.cer (Base-64 encoded X.509)

6) Create a WCF data service

In this section a basic WCF data service is created in order to secure it using mutual authentication.

• In Visual Studio 2010, create a new empty solution called MyDataServices

• Add a new ASP.NET empty web application called MyDataService

• Add a new empty ADO.NET Entity Data Model item to MyDataService called MyDataServiceModel.edmx (empty model)

• Add a new WCF Data Service item to MyDataService called MyDataServiceImp.svc

• Open the code behind file for MyDataServiceImp.svc and add MyDataServiceModelContainer into the class definition

• Open MyDataServiceModel.edmx
• Right click anywhere on the screen and choose to Generate Database from Model
• Create a new data connection to SQL Server if one does not already exist
• Build the solution

7) Host the data service in IIS

• Open IIS manager
• Start – Administrative Tools – Internet Information Services (IIS) Manager
• Create a new website called ‘My Data Service’
• Point the physical path to the data service created in 6)
• Choose a binding type of https and select the www.mydataservice.com SSL certificate

• Modify the app pool under which the website is running so that the .NET framework version is v4.0.30319

• Add a hosts file entry for ‘127.0.0.1 www.mydataservice.com’
• Via Windows Explorer, give ‘Everyone’ full control of the MyDataService folder
  • N.B. – this is a shortcut for keeping the blog post succinct. Such permissions should not be an option for a production deployment

8) Create a WCF client

In order to make life a little easier, we will create and configure the WCF client before locking down the service.

• Add a new Console Application project called MyDataServiceClient to MyDataServices
• Right click the project and choose to ‘Add Service Reference’
• Enter an address of https://www.mydataservice.com/mydataserviceimp.svc
• Click Go
• Once the service has been discovered give it the namespace MyDataServiceEntities

9) Enable client certificate authentication in IIS

Both IIS and the WCF data service must be configured for client certificate authentication, otherwise there is a mismatch and a service activation failure similar to ‘The SSL settings for the service 'SslRequireCert' does not match those of the IIS 'Ssl'’ will occur.

• Open IIS manager
  • Start – Administrative Tools – Internet Information Services (IIS) Manager
• Highlight the WCF data service website and double click ‘SSL Settings’

• Configure IIS as below

10) Register the client public key certificate with the service

In this section the public key certificate from 4) is registered with the data service website.

Client certificates can be mapped in a ‘one to one’ or ‘many to one’ relationship with Windows accounts. ‘one to one’ means that a client certificate is linked to a single Windows account. ‘many to one’ means that many client certificates are assigned to a single Windows account.

In this post we will use the ‘one to one’ relationship but the ‘many to one’ relationship does not differ greatly

• Highlight the MyDataService website and double click ‘Configuration Editor’

• Choose the ‘oneToOneMappings’ section

• Click Add
• Set the entry as ‘enabled’ = true
• Set the username with associated password as that of the local administrator
• In production this would most likely be a service account with reduced privileges
• Right click the TestClient_Public.cer file from 4) and choose to edit in Notepad
• Ensure that the block between, but not including, ‘-----BEGIN CERTIFICATE-----‘ and ‘-----END CERTIFICATE-----‘, is all on a single line (it is not by default)
• Copy and paste the block into the ‘certificate’ field so that the resulting entry is as below

• Close the window
• Click Apply

11) Mandate client certificate authentication for the data service

The data service must also be configured to mandate client certificate authentication.

In web.config, overwrite the <system.serviceModel> element with the following

The contents of the <webHttpBinding> element mandate that client certificate authentication at the transport level is required for the binding. The <services>/<service>/<endpoint> element describes the contract that all WCF data services must adhere to.

12) Register the service public key certificate with the client

As this article is concerned with mutual authentication then it is not sufficient for only the service to authenticate the client. In addition, the client must be certain that it is calling the right endpoint. One way to achieve this is to store the service public key certificate with the client so that during runtime, the SSL certificate presented by the service can be compared against the locally stored version. In this way the client can be sure that it is calling the correct SSL endpoint located at www.mydataservice.com and that it has not been phished into calling another endpoint with the same URL but different SSL certificate.

• Open a snap-in window
  • Start – Run – mmc
  • Add/Remove snap-in
  • Ctrl-M
  • Add a Certificates snap-in for ‘My user account’
• Expand the (Certificates – Current User)/Personal/Certificates node
• Right click the Certificates folder and choose All Tasks – Import
• Browse to TestDataService_Public.cer that was created in 6)
• Click through the remaining windows and finish

13) Update the WCF client to verify the service certificate

As the service is now locked down, the client will not be able to use it without undergoing some modification.

• Overwrite Program.cs with the following

Note that the ClientCertificate property of the proxy is not recognised; this represents the last piece of the puzzle. As there is no declarative configuration for the WCF client (i.e. - no <system.serviceModel> element was created in the client config file, unlike for, say, a standard SOAP based web service), the client certificate is hooked in programmatically by intercepting the underlying HttpWebRequest instance.

• Overwrite Reference.cs contained within the MyDataServiceEntities service reference, with the following

 
• Set MyDataServiceClient as the startup project
• Press F5

Conclusion

In this article I have demonstrated a methodology for securing communication between a WCF client and a IIS hosted WCF data service, installed on a workgroup server, using mutual certificate authentication. While in many ways similar to mutual authentication scenarios described elsewhere, securing a WCF data service exhibits some unique characteristics that warranted documenting.

I hope you find this useful.

Written by [BradleyCotier]

I am having great fun playing with this toolkit to see how WP7 apps can be properly secured using the Azure Access Control Service (ACS).

I hit a couple of problems while trying to create a new 'Windows Phone Cloud Application' project in Visual Studio though, at the following screen:

1) Make sure the ACS namespace is just the <namespace> bit of https://<namespace>.accesscontrol.windows.net. Fairly obvious I guess but I have been using appfabriclabs.com and assumed that the domain name part of the namespace would resolve the Azure environment I needed. Also, it follows from this that you MUST use the production Azure environment.

2) Make sure you don't use an old ACS namespace which is still at ACS V1. The toolkit will only work with V2 because only V2 supports the required federation protocols.

Later.

Brad

<ns1:Root xmlns:ns1="urn:myrootnamespace">
    <ns2:child xmlns:ns2="urn:mychildnamespace">
        <ns2:elementInChildNS />
        <ns1:elementInRootNS />
        <elementInNoNS />
    </ns2:child>
</ns1:Root>

I couldn’t do it

However, before you get bogged down in the complexities of WCF bindings and IIS metadata, there ‘may’ be a simple fix. If the client and service are on the same machine and you experience the aforementioned error, check out this article:

https://blogs.msdn.com/b/distributedservices/archive/2009/11/10/wcf-calling-wcf-service-hosted-in-iis-on-the-same-machine-as-client-throws-an-authentication-error.aspx

This was infuriatingly difficult to track down but once found, I couldn’t understand why it wasn’t top of the search engine results.

Hopefully this will give the matter a little more press.

Later.

Brad