Microsoft .NET & C#

Using expression trees to denote models

2012-01-19T14:30:00.001+01:00

Let’s have an XML list of people:

<?xml version="1.0" encoding="utf-8" ?>

<people>

    <person GivenName="John" Surname="Smith" Age="30" />

    <person GivenName="Matthew" Surname="Kowalski" Age="35" />

</people>

and an object model of list items:

public class Person

    public string GivenName { get; set; }

    public string Surname { get; set; }

    public int    Age { get; set; }

    public override string ToString()

        return string.Format( "{0} {1}, {2}", GivenName, Surname, Age );

What we can see here is the mismatch between two domains – a strongly typed OO domain and loosely typed text domain. The mismatch can be resolved using different approaches, for example we could build a set of tags over class members to help the XmlSerializer to deal with plain text data. But trying to be as naive as possible we could provide a helper method which, for given XmlNode, would return a typed value of an attribute.

public static class XmlNodeExtensions

     public static T GetNodeAttribute<T>( this XmlNode Node, string AttributeName )

         if ( Node != null )

             return (T)Convert.ChangeType( Node.Attributes[AttributeName].Value, typeof( T ) );

         else

             return default( T );

The conversion of untyped text data to typed class instances require the knowledge of member signatures:

XmlDocument people = new XmlDocument();

people.Load( "people.xml" );

foreach ( XmlNode personNode in people.SelectNodes( "//people/person" ) )

    Person person = new Person();

    person.GivenName = personNode.GetNodeAttribute<string>( "GivenName" );

    person.Surname   = personNode.GetNodeAttribute<string>( "Surname" );

    person.Age       = personNode.GetNodeAttribute<int>( "Age" );

    Console.WriteLine( person );

Although such naive approach is common, it has obvious disadvantages. Basically we duplicate the model metadata description on both sides of assignments. The mismatch is still there waiting to bite when models change – if names/types change, we’d have to apply manual changes on one/both sides of above assignments. In particular, refering to members using literal names could possibly bite badly as there’s no chance to catch possible mismatch during the compilation.

The intention of this entry is to document another common approach, a one step further than what is presented above. Note once again that each assignment of a form:

person.GivenName = personNode.GetNodeAttribute<string>( "GivenName" );

contains the same information twice – the name and type of of a class member matches the name of XML attribute, however we have to repeat this information on the right side of the assignment.

Let’s then provide a new extension:

public static class XmlNodeExtensions

     public static T GetNodeAttribute<T>( this XmlNode Node, string AttributeName )

         ... unchanged ...

     public static TProperty GetNodeAttribute<TProperty>(

          this XmlNode Node,

          Expression<Func<TProperty>> Property )

         if ( Property != null && Property.Body != null )

             if ( Property.Body.NodeType == ExpressionType.MemberAccess )

                 MemberExpression memberExpression =

                    (MemberExpression)Property.Body;

                 if ( !string.IsNullOrEmpty( memberExpression.Member.Name ) )

                     return Node.GetNodeAttribute<TProperty>(

                                memberExpression.Member.Name );

         return default(TProperty);

This time we require an expression denoting model member, rather than a separate information of its name and type. This allows us to rewrite the client code to:

XmlDocument people = new XmlDocument();

 people.Load( "people.xml" );

 foreach ( XmlNode personNode in people.SelectNodes( "//people/person" ) )

     Person person = new Person();

     person.GivenName = personNode.GetNodeAttribute( () => person.Surname );

     person.Surname   = personNode.GetNodeAttribute( () => person.GivenName );

     person.Age       = personNode.GetNodeAttribute( () => person.Age );

     Console.WriteLine( person );

The possibilities of further enhancements are endless and even such simple one is a significant one as possible mismatch between models can now be caught by the compiler.

Programmatic way to add filters for NHibernate mappings

2011-12-01T15:54:00.003+01:00

NHibernate filters is a powerful mechanism for selective filtering of records. Read more here or here.

This post is to document the way to add filters programmatically rather than declaratively (in binding files).

Let’s start with a declarative configuration.

<?xml version="1.0" encoding="utf-8" ?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"

    namespace="yournamespace" assembly="yourassembly">

    <class name="Parent" table="[dbo].[Parents]" >

        <id name="Oid" column="[OID]" type="Int32" >

            <generator class="native" />

        </id>

        <property name="Name" column="Name" type="String" not-null="false" length="50" />

        <bag name="Children" inverse="true" cascade="all-delete-orphan" lazy="true" >

            <key>

                <column name="[ID_PARENT]" />

            </key>

            <one-to-many class="Child" />

            <filter name="association-level-filter" condition="condition" />

        </bag>

        <filter name="entity-level-filter" condition="condition" />

    </class>

</hibernate-mapping>

Note that the mapping defined the entity of type Parent with a reference to a list of entities of type Child. Each Child points to its Parent.

Note also that there are actually two filters – the entity-level filter applies to queries to type Parent and the association-level filter applies to queries involving the list of dependant entities.

The entity-level filter is available on the mapping object easily:

foreach ( var mapping in config.ClassMappings )

    mapping.AddFilter( "name", "criteria" );

However, to get the association-level filter you have to dig deeper to get the properties of type Bag from the actual mapping:

foreach ( var mapping in config.ClassMappings )

    mapping.AddFilter( "name", "condition" );

    foreach ( var property in mapping.PropertyIterator )

        if ( property.Value is Bag )

            Bag bagProperty = (Bag)property.Value;

            bagProperty.AddFilter( "name", "condition" );

MSIS7042: The same client browser session has made 'X' requests in the last 'Y' seconds.

2011-11-17T15:46:00.002+01:00

This exception has been written to the ADFS event log after unsusccessful sign-in of one of our Relying Party applications. From the user perspective, the control flow seems correct, the application redirects to the ADFS login page but then rather than signing in, it forces the browser to go to ADFS again and again. After few frantic redirects within the browser, ADFS shows the exception message.

It turned out that there is a simple cause of such unindented behaviour – the FederatedPassiveSignIn control on the RP’s login page has the AutoSignIn property set to true.

When the browser hits the page, it unconditionally redirects to ADFS and then, upon returning when something is wrong, it redirects to ADFS again. Problem is that the ADFS shows the login page only once and then it automatically redirects back to the application because user is already authenticated. This causes the “redirection loop” within the browser as the application and ADFS start to unconditionally redirect between each other.

If this is the case in your scenario (AutoSignIn==”true”), then there’s a simple workaround. All you have to do is to provide a SignInError handler for the control where you had to turn off the auto signing:

FederatedPassiveSignIn1.SignInError +=

    ( s, e ) =>

        // turn off auto signing to prevent the "redirection loop"

        FederatedPassiveSignIn1.AutoSignIn = false;

        // optionally show the error message

        lblError.Text = e.Exception.Message;

};

In our case it turned out that the reason for the error in the authentication pipeline was caused by wrong STS certificate thumbprint at the RP-side which caused WIF to throw a security exception from the IssuerNameRegistry.

Easy Unity Application Block integration in .NET applications

2011-11-15T14:56:00.002+01:00

Unity Application Block is a lightweight dependency injection container from Microsoft Patterns & Practices. This article is intended to show how quickly and easily integrate Unity with your code.

Start by downloading and installing Unity. The current version, 2.1, consist of 5 libraries:

Microsoft.Practices.ServiceLocation.dll
Microsoft.Pracitces.Unity.dll
Microsoft.Practices.Unity.Configuration.dll
Microsoft.Practices.Unity.Interception.dll
Microsoft.Practices.Unity.Interception.Configuration.dll

There are at least two ways to define type bindings in Unity – declaratively in a *.xml file and programmatically in a C# code.

The nice thing is that you can combine both approaches in desired order so for example you first create few mappings programmatically and then load the static configuration which can possibly override some of mappings.

Now create a new application (Windows or web) and add references to unity libraries (first 3 will do as this tutorial doesn’t cover interceptions).

Anyway, first go to the application *.config file (app.config for Windows applications, web.config for web apps) and inform the runtime that you are going to configure unity using the *.xml file:

<?xml version="1.0"?>

<configuration>

    <configSections>

        <section name="unity"

         type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,

               Microsoft.Practices.Unity.Configuration"/>

    </configSections>

    <unity configSource="Configuration\unity.config"/>

</configuration>

As you can see I am delegating the Unity configuration to a separate file, Configuration\unity.config. This is a good practice as you have all the IoC configuration in a single place which doesn’t interfere with any other application settings.

For this tutorial, create a service specification and two implementations:

public interface ICustomService

    string BusinessOperation();

public class CustomServiceImpl : ICustomService

    #region ICustomService Members

    public string BusinessOperation()

        return "foo";

    #endregion

public class CustomServiceImpl2 : ICustomService

    #region ICustomService Members

    public string BusinessOperation()

        return "bar";

    #endregion

We are going to provide a static mapping in the *.xml file, Configuraton\unity.config:

<?xml version="1.0" encoding="utf-8" ?>

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">

    <container>

        <register type="ConsoleApplication30.Logic.ICustomService, ConsoleApplication30"

                  mapTo="ConsoleApplication30.Logic.CustomServiceImpl, ConsoleApplication30" />

    </container>

</unity>

As you can see, the interface ICustomService is mapped to CustomServiceImpl.

The remaining part is to configure the service locator:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using Microsoft.Practices.Unity;

using Microsoft.Practices.Unity.Configuration;

using Microsoft.Practices.ServiceLocation;

using ConsoleApplication30.Logic;

namespace ConsoleApplication30

    class Program

        static void Main( string[] args )

            UnityServiceLocator locator = new UnityServiceLocator( CreateConfiguredUnityContainer() );

            ServiceLocator.SetLocatorProvider( () => locator );

        private static IUnityContainer CreateConfiguredUnityContainer()

            IUnityContainer container = new UnityContainer();

            // (optional) provide default mappings programmatically

            container.RegisterType<ICustomService, CustomServiceImpl2>();

            // (optional) load static config from the *.xml file

            container.LoadConfiguration();

            return container;

As you can see the locator is created over a container which shows how to perform dynamic and static configuration.

Remember that Unity, as most of IoC containers, allows to reregister services – if you provide two or more mappings of the same service type to a concrete implementation, the last registered implementation is always used when you resolve the service (which is reasonable). In this tutorial I am creating a mapping in code from ICustomService to CustomServiceImpl2.

From now on you can ask the service locator services and consume them:

ICustomService service = ServiceLocator.Current.GetInstance<ICustomService>();

var foo = service.BusinessOperation();

It couldn’t be easier. Personally, when I am free to pick an IoC container, I often pick Unity – it’s reliable, simple and lightweight.

A quick quiz: in the example, I am mapping the implementation to CustomServiceImpl2 and in the next line I am loading the configuration from the *.xml file which in turn maps the implementation to CustomServiceImpl then what would be the result of resolving the service type?

Managing cookies in a WCF client

2011-11-04T10:32:00.002+01:00

This article shows a way to manage cookies in an instance of a client proxy to a WCF service.

Background

Years ago, when we all were using the SoapHttpClientProtocol proxies, there was a property called CookieContainer. What we had to do was to create a new cookie container for the client instance and push/pull cookies from there.

Nowadays we use client proxies which derive from System.ServiceModel.ClientBase. Unfortunately, there’s no cookie container on such proxy – this is reasonable as the proxy could be used to contact a WCF Service over TCP or MSMQ where the term “http cookie” is meaningless.

Existing solutions

There are two well-known approaches to the problem, both clearly described in a blog entry by Enrico Campidoglio. First, you could take control over http headers using clumsy:

MyWebServiceClient client = new MyWebServiceClient();

using ( new OperationContextScope( client.InnerChannel ) )

    HttpRequestMessageProperty request = new HttpRequestMessageProperty();

    request.Headers["Cookie"] = "cookie header value";

    OperationContext.Current.OutgoingMessageProperties[

        HttpRequestMessageProperty.Name] = request;

    client.InvokeSomeMethod();

This way you can alter the way cookies are handled for a single request.

A more general approach involves writing a custom message inspector. Consult Enrico’s article for more details.

Another approach

Is it really such difficult? Is the WCF Client proxy so dumb that it cannot handle cookies on its own?

Well, it can. It seems that setting the AllowCookies property on a BasicHttpBinding to true turns on the automatic cookie management. From this moment, you can’t use any of the previously mentioned solutions because it is the client proxy to retrieve cookies and automatically append them to consecutive requests.

Wait! But you can’t append a new cookie on the client-side this way! And this was our primary requirement.

Well, you can. If you ask the server to do so.

[ServiceContract]

[ServiceBehavior(

    InstanceContextMode = InstanceContextMode.PerCall,

    ConcurrencyMode = ConcurrencyMode.Multiple,

    UseSynchronizationContext = false )]

[AspNetCompatibilityRequirements(

   RequirementsMode = AspNetCompatibilityRequirementsMode.Required )]

public class TheService

    // Append the cookie to the client

    [OperationContract]

    public void SetCookie( string Name, string Value )

        HttpCookie cookie = new HttpCookie( Name, Value );

        HttpContext.Current.Response.AppendCookie( cookie );

    // other service methods follow

And the client:

BasicHttpBinding binding = new BasicHttpBinding();

binding.AllowCookies = true;

EndpointAddress address =

   new EndpointAddress( "http://localhost:12345/TheService.svc" );

TheServiceReference.TheServiceClient client =

   new TheServiceReference.TheServiceClient( binding, address );

// ask the server to append the cookie

client.SetCookie( "foo", "bar" );

And that’s it. At the cost of one extra server request, the WCF client is able to take a full control over it’s cookies. Please add any additional methods as needed (for example to remove cookies).

Reading the revision number of a local copy of a SVN repository

2011-10-19T14:41:00.002+02:00

The SVN client (TortoiseSVN) has a handy SubWcRev.exe application which is commonly used for obtaining the revision number of a local copy of given SVN repository and (optionally) rewriting text files and replace the $WCREV$ token with the retrieved version number.

This post is to document the way we mimic SubWcRev.exe for our internal purposes.

TortoiseSVN 1.6 and earlier

When TortoiseSVN 1.6 (or earlier) is used, each folder in the repository tree contains a .svn subfolder. In there, the file named entries contains some information about the local repository. The root svn subfolder can be used as the source of the revision number - the entries file located there always contains the revision number in the third line:

public class SvnManager

    public string FolderName { get; private set; }

    public SvnManager( string FolderName )

        this.FolderName = FolderName;

    const string ENTRIES = "entries";

    private string RevisionNumber

get

            string SvnSubfolder = FolderName + "\\.svn";

            if ( Directory.Exists( SvnSubfolder ) )

                string EntriesFile = Directory.GetFiles( SvnSubfolder, ENTRIES ).FirstOrDefault();

                if ( !string.IsNullOrEmpty( EntriesFile ) )

                    string[] Lines = File.ReadAllLines( EntriesFile );

                    if ( Lines.Length > 3 )

                        return Lines[3];

            return string.Empty;

The client code would be:

SvnManager manager = new SvnManager( "local repository root path" );

string revisionNumber = manager.RevisionNumber;

Tortoise 1.7

Tortoise 1.7 no longer creates .svn subfolders in each single folder of the local copy of your repository. Instead, a SQLite database, wc.db, is created in the .svn folder at the root level of the local copy. The database is a binary file, however it seems that the revision number is stored as string value which makes it possible to match the binary data for a regular expression, /!svn/ver/[0-9]*/:

public class SvnManager

     public string FolderName { get; private set; }

     public SvnManager( string FolderName )

         this.FolderName = FolderName;

     const string DB      = "wc.db";

     const string PATTERN = "/!svn/ver/(?'version'[0-9]*)/";

     private string RevisionNumber

get

             string SvnSubfolder = FolderName + "\\.svn";

             if ( Directory.Exists( SvnSubfolder ) )

                 int maxVer = int.MinValue;

                 string EntriesFile = Directory.GetFiles( SvnSubfolder, DB ).FirstOrDefault();

                 if ( !string.IsNullOrEmpty( EntriesFile ) )

                     byte[] fileData = File.ReadAllBytes( EntriesFile );

                     string fileDataString = Encoding.Default.GetString( fileData );

                     Regex regex = new Regex( PATTERN );

                     foreach ( Match match in regex.Matches( fileDataString ) )

                         string version = match.Groups["version"].Value;

                         int curVer;

                         if ( int.TryParse( version, out curVer ) )

                             if ( curVer > maxVer )

                                 maxVer = curVer;

                     if ( maxVer > int.MinValue )

                         return maxVer.ToString();

             return string.Empty;

How to Align Assignments in Visual Studio 2010

2011-09-15T16:36:00.002+02:00

With Productivity Power Tools you can easily auto align assignments in blocks of code.

First, disable the “Ignore spaces in declaration statements” under Options/Text Editor/C#/Formatting/Spacing.

Then select a block of code and press Ctrl+Alt+] (right square bracket). This will automatically change this

Name = User.UserName,

GivenName = User.GivenName,

Surname = User.Surname,

SamAccountName = User.UserName,

EmailAddress = User.Email

to this

Name           = User.UserName,

GivenName      = User.GivenName,

Surname        = User.Surname,

SamAccountName = User.UserName,

EmailAddress   = User.Email

IIS 7.5 – a breaking change in extensionless URIs handling after Windows Server 2008 R2 SP1 is applied

2011-09-15T10:59:00.002+02:00

One of our sites use dynamic URL rewriting based on catching the 404 by IIS and executing an *.aspx webpage which then handles dynamic URLs accordingly.

This has been working for us for many, many years, starting on IIS 6 on Windows Server 2003. All request of the form

http://oursite.com/this/is/something/dynamic/foo.bar

and

http://oursite.com/this/is/something/dynamic/foo

were routed to the *.aspx page handling the 404 status code. ASP.NET has then been asked by IIS to process (respectively):

The404Page.aspx?404;http://oursite.com/this/is/something/dynamic/foo.bar

and

The404Page.aspx?404;http://oursite.com/this/is/something/dynamic/foo

When the SP1 is applied to Windows Server, IIS starts to behave differently. When a request regards a resource which contains an extension (like .bar, .jpg) the semantic is exactly the same as it has been before.

However, when a request to a resource without an extension is made(nonexisting folder like /this/is/something/dynamic/foo), IIS routes such request directly to ASP.NET like it is the ASP.NET responsible for handling extensionless uris. Instead of The404Page.aspx?404;… ASP.NET handles then

this/is/something/dynamic/foo

I presume this has something in common with the ExtensionlessUrl-Integrated-4.0 module and will inspect this further. What’s interesting is that the change affects only ASP.NET 4.0 while ASP.NET 2.0 is not affected.

It seems that it causes the trouble for other people too.

The quest for customizing ADFS sign-in web pages, part 6 – a WSTrustFeb2005 Endpoint on the Custom STS

2011-09-12T14:40:00.002+02:00

A quick summary – we are working on a custom STS which the ADFS will federate with. In our previous entry we have created a trust relationship between the ADFS and our custom STS so users are able to see the HomeRealmDiscovery page in the ADFS and pick up a correct identity provider – the ADFS itself or the custom STS.

In our very last entry we are going to provide a WSTrustFeb2005 endpoint on our custom STS so that WCF signin requests could be created directly from the ADFS to the custom STS without the HRD page. In fact, users will see the ADFS login page with username/password text fields and we will modify the logic behind the page so that the pair username/password will be first validated against our custom STS and then against the Active Directory without user being aware of that. This will complete our quest for customizing ADFS sign-in web pages.

A WSTrustFeb2005 Endpoint

Go to our custom STS project, and create a *.svc service. Since I like to follow conventions, I created it under /services/trust/2005/UserName.svc (since we are going to perform username/password validation).

The service itself is rather straightforward as it uses a built-in factory class. It means that the *.svc doesn’t need any code behind and the sole content of the *.svc file is:

<%@ ServiceHost Language="C#" Debug="true"

    Factory="Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceHostFactory"

    Service="The.Custom.STS.Code.CustomSecurityTokenServiceConfiguration"

%>

Note that the Service attribute points to the security token service configuration class which we have created long, long ago somewhere at the begininng of our quest, when we have built a custom STS. In other words, the active WCF service uses the same STS infrastructure as the passive LoginForm/Default pages.

But we are not done yet. Go to the web.config file and create correct WCF sections:

<system.serviceModel>

    <services>

        <service name="Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract"

                 behaviorConfiguration="ServiceBehavior">

            <endpoint address="Sts" binding="ws2007HttpBinding"

                      contract="Microsoft.IdentityModel.Protocols.WSTrust.IWSTrustFeb2005SyncContract"

                      bindingConfiguration="wsTrustFeb2005Configuration" />

            <host>

                <baseAddresses>

                    <add baseAddress="https://customsts.yourdomain.com/services/trust/2005/UserName.svc"/>

                </baseAddresses>

            </host>

            <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

        </service>

    </services>

    <bindings>

        <ws2007HttpBinding>

            <binding name="wsTrustFeb2005Configuration">

                <security mode="TransportWithMessageCredential">

                    <message clientCredentialType="UserName" establishSecurityContext="false"/>

                </security>

            </binding>

        </ws2007HttpBinding>

    </bindings>

    <behaviors>

        <serviceBehaviors>

            <behavior name="ServiceBehavior">

                <serviceMetadata httpGetEnabled="true" />

                <serviceDebug includeExceptionDetailInFaults="false" />

            </behavior>

        </serviceBehaviors>

    </behaviors>

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

</system.serviceModel>

Note that we are using a built-in contract interface (IWSTrustFeb2005SyncContract) and we create an explicit ws2007HttpBinding binding with security mode set to TransportWithMessageCredential and clientCredentialType set to UserName. This is the only correct combination and what’s important is that it works only when the service is exposed on the secure channel (SSL).

This is enough to test the service, just point your browser to the https://customsts.yourdomain.com/services/trust/2005/UserName.svc and check if it displays correct information page.

A custom token handler

By default the service we have just built will try to accept tokens for Windows users. However, we’d like to have a custom validation logic so for example we could validate users agains the SQL database.

For this, we need a custom token handler which could examine SAML request tokens, extract usernames/passwords from there and create claims accordingly.

This is surprizingly straightforward:

public class CustomUserNameSecurityTokenHandler : UserNameSecurityTokenHandler

     public override bool CanValidateToken

get

             return true;

     public override ClaimsIdentityCollection ValidateToken(

         System.IdentityModel.Tokens.SecurityToken token )

         UserNameSecurityToken userNameToken = token as UserNameSecurityToken;

         if ( userNameToken == null )

             throw new ArgumentException( "The security token is not a valid username token." );

         if ( userNameToken.Password == userNameToken.UserName.Length.ToString() )

             IClaimsIdentity identity = new ClaimsIdentity();

             identity.Claims.Add( new Claim( ClaimTypes.Name, userNameToken.UserName ) );

             identity.Claims.Add( new Claim( ClaimTypes.Role, "CustomTokenHandlerRole1" ) );

             identity.Claims.Add( new Claim( ClaimTypes.Role, "CustomTokenHandlerRole2" ) );

             return new ClaimsIdentityCollection( new IClaimsIdentity[] { identity } );

         throw new InvalidOperationException( "Username/password is incorrect in STS." );

Note that my simple token handler just checks whether the password matches the length of the username (so foo/3 or foobar/6 are valid credentials) but this is the exact place you can plug any validation logic.

We only need to inform WIF to use this custom token handler instead of the default one. We do this in web.config in a proper section:

<microsoft.identityModel>

    <service>

        <securityTokenHandlers>

            <remove type="Microsoft.IdentityModel.Tokens.WindowsUserNameSecurityTokenHandler,

                          Microsoft.IdentityModel,

                          Version=3.5.0.0, Culture=neutral,

                          PublishKeyToken=31BF3856AD364E35"/>

            <add type="The.Custom.STS.CustomUserNameSecurityTokenHandler" />

        </securityTokenHandlers>

    </service>

</microsoft.identityModel>

This new token handler will not interfere with the passive authentication scenario, where your browser asks for the Default.aspx page of the STS. Instead, it is only used during the active authentication scenario, where WCF requests are handled by the STS.

Passing through claims

The custom token handler we have created will now works correctly, however our WCF service still points to our CustomSecurityTokenService class where we create claims manually (the GetOutputClaimsIdentity method).

Because our custom token handler now creates its own claims, we have to modify the STS logic so that WCF claims could be passed through.

protected override IClaimsIdentity GetOutputClaimsIdentity(

     IClaimsPrincipal principal,

     RequestSecurityToken request, Scope scope )

     if ( null == principal )

         throw new ArgumentNullException( "principal" );

     ClaimsIdentity outputIdentity = new ClaimsIdentity();

     // Name

     outputIdentity.Claims.Add( new Claim( ClaimTypes.Name, principal.Identity.Name ) );

     // Roles (should be dynamic)

     outputIdentity.Claims.Add( new Claim( ClaimTypes.Role, "Role1" ) );

     outputIdentity.Claims.Add( new Claim( ClaimTypes.Role, "Role2" ) );

     // Pass through any existing claims (here: passed from the custom token handler)

     foreach ( var claim in principal.Identities[0].Claims )

         outputIdentity.Claims.Add( new Claim( claim.ClaimType, claim.Value ) );

     return outputIdentity;

Modifying the ADFS login page

The ADFS login page can now be modified to use our WCF service. Go to ADFS installation, find the FormsSignIn.aspx.cs file and modify it to:

protected void SubmitButton_Click( object sender, EventArgs e )

try

         SignInWithTokenFromOtherSTS( UsernameTextBox.Text, PasswordTextBox.Text );

     catch

try

             SignIn( UsernameTextBox.Text, PasswordTextBox.Text );

         catch ( AuthenticationFailedException ex )

             HandleError( ex.Message );

 private void SignInWithTokenFromOtherSTS( string UserName, string Password )

         const string OtherSTSAddress =

            "https://customsts.yourdomain.com/services/trust/2005/UserName.svc/Sts";

         const string YourStsAddress  =

            "http://fs.adfs.pl/adfs/services/trust";

         EndpointAddress endpointAddress = new EndpointAddress( OtherSTSAddress );

         UserNameWSTrustBinding binding =

            new UserNameWSTrustBinding( SecurityMode.TransportWithMessageCredential );

         WSTrustChannelFactory factory = new WSTrustChannelFactory( binding, endpointAddress );

         factory.Credentials.UserName.UserName = UserName;

         factory.Credentials.UserName.Password = Password;

         factory.TrustVersion = System.ServiceModel.Security.TrustVersion.WSTrustFeb2005;

         WSTrustChannel channel = (WSTrustChannel)factory.CreateChannel();

         RequestSecurityToken rst = new RequestSecurityToken(

             WSTrustFeb2005Constants.RequestTypes.Issue,

             WSTrustFeb2005Constants.KeyTypes.Bearer );

         rst.AppliesTo = new EndpointAddress( YourStsAddress );

         SecurityToken token = channel.Issue( rst );

         SignIn( token );

Note that instead of using the built-in SignIn( string UserName, string Password ) method (which would check the credentials against the active directory) we are providing a custom sign in method which creates a WCF request to the WSTrustFeb2005 service in behalf of http://fs.adfs.pl/adfs/services/trust (which is the ID of the ADFS, not it’s address! If you pass the address, the ADFS will refuse to accept the token because the token would not be issued for the ADFS).

When we get the token back from the service, we pass it to another built-in method which this time accepts the token instead of the username/password pair (SignIn( token )). Note that this would not work without the explicit trust relationship in the ADFS to our custom STS we have created in the previous blog entry. This time the ADFS would complain that the claims provider is not trusted.

Also note that this is the most difficult step in our tutorial as we are finally putting all blocks together. My advice is to test the SignInWithTokenFromOtherSTS method separately, from within a custom console application and when it finally works (you get the token and not the exception from the WCF service) you can move on to testing this code from within the ADFS.

I’ve spent at least a day at this point, still getting exceptions from the WCF service and when it finally started to work (I got tokens from the WCF service) making it work with the ADFS was easy.

Modifying the ADFS HRD page

The only remaining issue is that because of our trust relationship between the ADFS and our custom STS, the ADFS still shows the HomeRealmDiscovery page! This is rather unfortunate because we’d like it to show the default page using our enhanced logic. And the passive login using the loginpage of our custom STS should be now disabled.

To do so, open the HomeRealmDiscovery.aspx.cs in the ADFS installation and modify the Page_Init so that it immediately picks the home realm:

public partial class HomeRealmDiscovery :

   Microsoft.IdentityServer.Web.UI.HomeRealmDiscoveryPage

    protected void Page_Init( object sender, EventArgs e )

        PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;

        PassiveIdentityProvidersDropDownList.DataBind();

        // Added line. Pick up the home realm immediately

        // (first one from the list which is the ADFS)

        SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

    protected void PassiveSignInButton_Click( object sender, EventArgs e )

        SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

Enjoy

Our quest is complete. The default ADFS login page can now accept any validation logic, you can for example validate users against a database or accept the email/password pair against the AD.

If you need the complete source code of this tutorial, please contact me directly.

The quest for customizing ADFS sign-in web pages, part 5 – ADFS as the R-STS

2011-09-12T13:12:00.002+02:00

A quick summary – we are working on a custom STS which the ADFS will federate with. In our previous blog entry we have federated our custom RP application with the ADFS. What we have so far is then a fully functional custom STS, the ADFS and a sample RP application to test the federation.

In this part of the tutorial we are going to modify the custom STS so that the ADFS could be federated with it. This means that the RP application which is federated with the ADFS will not need to be reconfigured at all but the ADFS will offer a new way to login with the custom STS serving as the Identity Provider STS (IP-STS).

Several things must happen correctly to create the federation relation between ADFS the custom STS.

SAML and WS-FederationPassive Endpoints

Although our custom STS has already been implemented to publish the metadata, the ADFS will not accept it as the IP-STS until the SAML and WS-FederationPassive endpoints are provided in the metadata. It is possible to configure all the endpoints manually in the ADFS configuration console but it’s easier to modify the metadata generation code with two simple descriptors (ipsso, spsso below):

/// <summary>

/// Metadane usługi federacyjnej

/// </summary>

public static MetadataBase GetFederationMetadata()

    string endpointId = UriHelper.ResolveServerUrl( "~/Default.aspx" );

    ....

    // Add endpoints

    string activeSTSUrl   =

        UriHelper.ResolveServerUrl( "~/Default.aspx" );

    string activeMetadata =

        UriHelper.ResolveServerUrl( "~/FederationMetadata/2007-06/FederationMetadata.ashx" );

    EndpointAddress endpointAddress = new EndpointAddress(

                                            new Uri( activeSTSUrl ),

                                            null,

                                            null,

                                            GetMetadataReader( activeMetadata ), null );

    stsRole.SecurityTokenServiceEndpoints.Add( endpointAddress );

    stsRole.PassiveRequestorEndpoints.Add( endpointAddress );

    // spsso, ipsso bindings

    ServiceProviderSingleSignOnDescriptor spsso = new ServiceProviderSingleSignOnDescriptor();

    spsso.ProtocolsSupported.Add( Saml20Protocol );

    spsso.Keys.Add( signingKey );

    spsso.SingleLogoutServices.Add( new ProtocolEndpoint( Common.HttpPost, new Uri( activeSTSUrl ) ) );

    spsso.SingleLogoutServices.Add( new ProtocolEndpoint( Common.HttpRedirect, new Uri( activeSTSUrl ) ) );

    spsso.AssertionConsumerService.Add( 0, new IndexedProtocolEndpoint( 0, Common.HttpPost, new Uri( activeSTSUrl ) ) );

    spsso.AssertionConsumerService.Add( 1, new IndexedProtocolEndpoint( 1, Common.HttpRedirect, new Uri( activeSTSUrl ) ) );

    metadata.RoleDescriptors.Add( spsso );

    IdentityProviderSingleSignOnDescriptor ipsso = new IdentityProviderSingleSignOnDescriptor();

    ipsso.ProtocolsSupported.Add( Saml20Protocol );

    ipsso.Keys.Add( signingKey );

    ipsso.SingleSignOnServices.Add( new ProtocolEndpoint( Common.HttpPost, new Uri( activeSTSUrl ) ) );

    ipsso.SingleSignOnServices.Add( new ProtocolEndpoint( Common.HttpRedirect, new Uri( activeSTSUrl ) ) );

    ipsso.SingleLogoutServices.Add( new ProtocolEndpoint( Common.HttpPost, new Uri( activeSTSUrl ) ) );

    ipsso.SingleLogoutServices.Add( new ProtocolEndpoint( Common.HttpRedirect, new Uri( activeSTSUrl ) ) );

    metadata.RoleDescriptors.Add( ipsso );

    // offer two claims

    stsRole.ClaimTypesOffered.Add( new DisplayClaim( ClaimTypes.Name ) );

    stsRole.ClaimTypesOffered.Add( new DisplayClaim( ClaimTypes.Role ) );

    return metadata;

with following consts

public static readonly Uri HttpPost =

   new Uri( "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" );

public static readonly Uri HttpRedirect =

   new Uri( "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" );

public static readonly Uri Saml20Protocol =

   new Uri( "urn:oasis:names:tc:SAML:2.0:protocol" );

I have found 0 (zero!) examples of using these classes in the internet and have figured most things by inspecting the metadata of the ADFS itself and trying to implement similar structures in the custom STS metadata. Fortunately, ADFS can be federated with another ADFS rather easily which was the reason to dig deeper into the ADFS metadata to find any stuff specific to STS-to-STS federation.

Matching the EntityID and the IssuerName

The metadata declares the EntityID of the STS. On the other hand, the certificate used to sign the SAML token declares the name of the certificate issuer.

For some reason, these two must match otherwise the ADFS will not accept claims from your STS. I’ve blogged about one of the ways to handle this. Another solution would be to declare one string const in your code and access it from the two places in the code.

First, in the metadata:

/// <summary>

 /// Metadane usługi federacyjnej

 /// </summary>

 public static MetadataBase GetFederationMetadata()

     string endpointId = UriHelper.ResolveServerUrl( "~/Default.aspx" );

     EntityDescriptor metadata = new EntityDescriptor();

     // I am using a const, defined elsewhere

     metadata.EntityId =

       new EntityId( CustomSecurityTokenServiceConfiguration.TheCustomSTSID );

And then in the custom STS configuration class:

/// <summary>

 /// A custom SecurityTokenServiceConfiguration implementation.

 /// </summary>

 public class CustomSecurityTokenServiceConfiguration :

     SecurityTokenServiceConfiguration

     public const string TheCustomSTSID = "The.Custom.STS";

...

     /// <summary>

     /// CustomSecurityTokenServiceConfiguration constructor.

     /// </summary>

     public CustomSecurityTokenServiceConfiguration()

         // the same const used

         : base( TheCustomSTSID,

                 new X509SigningCredentials(

                     CertificateUtil.GetCertificate( "the.custom.sts.pfx", "12345678" ) )

         this.SecurityTokenService = typeof( CustomSecurityTokenService );

Correcting the ReplyToAddress

When creating the relying requests to our custom STS, the ADFS will introduce itself using its identifier (scope.AppliesToAddress). The problem is that in the default configuration, the identifier points to the URL which is invalid and will not accept response messages from your STS.

For example, in my test environment, the ADFS is available at https://fs.adfs.pl/adfs/ls/ however the ID it passes to my custom STS is http://fs.adfs.pl/adfs/services/trust.

(Note the http:// protocol while ADFS is available at https://!)

There are two ways to correct this. First, you can go to ADFS, open it’s configuration panel and change its identifier.

Second, in your custom STS you can create a mapping between IDs and valid URLs of requesting parties. The mapping could have a default clause which would just copy the identifier as the return address (as it does that by default in our implementation!). For example:

/// <summary>

/// A custom SecurityTokenService implementation.

/// </summary>

public class CustomSecurityTokenService : SecurityTokenService

...

    protected override Scope GetScope(

        IClaimsPrincipal principal,

        RequestSecurityToken request )

        ValidateAppliesTo( request.AppliesTo );

        Scope scope = new Scope(

            request.AppliesTo.Uri.OriginalString,

            SecurityTokenServiceConfiguration.SigningCredentials );

        scope.TokenEncryptionRequired = false;

        // default clause

        scope.ReplyToAddress = scope.AppliesToAddress;

        // mapping

        foreach ( var key in ConfigurationManager.AppSettings.AllKeys )

            if ( scope.AppliesToAddress == key )

                scope.ReplyToAddress = ConfigurationManager.AppSettings[key];

        return scope;

with

<appSettings>

    <add key="http://fs.adfs.pl/adfs/services/trust"

         value="https://fs.adfs.pl/adfs/ls/"/>

</appSettings>

Creating the Custom STS trust relation in ADFS

After all these preparations, creating the trust relationship between ADFS the custom STS is easy.

First navigate to the custom STS metadata (https://customsts.yourdomain.com/FederationMetadata/2007-06/FederationMetadata.ashx) and save it to an XML file.

Then go to ADFS configuration and create a new trust relationship. Import the provider metadata from the XML file. Create two simple claim rules which just pass Name and Role through (the ADFS should not touch them as they are created in the custom STS).

Then go to your example RP application and try to login. Instead of the ADFS login page, you should see the HomeRealmDiscovery page as ADFS is now unsure whether you want to login with your AD identity or via the trusted claims provider (custom STS). The default HRD page contains a combobox with two selections however you can easily modify this page in ADFS (it’s stored as *.aspx file).

When things fail

Couple of tips when you fail at some point.

If you do not see the HRD page in ADFS but the trust relationship has been created, it probably means that the SAML/WSFederationPassive endpoints in the custom STS are created incorrectly. Go back to the 1st section of this tutorial.

If the custom STS redirects back to wrong address, it probably means that the mapping between ADFS ID and ADFS address is incorrect in the custom STS. Go back two sections.

If the redirect hits a correct ADFS page but ADFS shows a generic error it could mean that the custom STS ID does not match the issuer name of the certificate. Go back three sections.

We are close to the very last tutorial in which we will create a WSTrustFeb2005 service endpoint in our custom STS and modify the login logic of the ADFS.

The quest for customizing ADFS sign-in web pages, part 4 – federation of the RP with ADFS

2011-09-01T15:14:00.001+02:00

A quick summary – we are working on a custom STS which the ADFS will federate with. In our previous blog entry we have built a custom RP application and federated it with our custom STS.

Federation of the the RP application with ADFS should be easy. Remember that because the federation details (Issuer and Realm) are stored in the FederatedPassiveSignIn control (LoginPage.aspx in the RP application), you just have to go there and replace the values with correct ones:

<wif:FederatedPassiveSignIn ID="WSFederationLogin"

        runat="server"

        DisplayRememberMe="false"

        RequireHttps="false"

        Realm="https://customrp.mydomain.com/LoginPage.aspx"

        Issuer="https://fs.adfs.pl/adfs/ls/"

        VisibleWhenSignedIn="false">

    </wif:FederatedPassiveSignIn>

As you can see the RP application is published on https://customrp.mydomain.com and the ADFS is published on https://fs.adfs.pl/adfs/ls/. The HTTPS for both components is important – the ADFS will not work on the HTTP binding and will not federate with an RP available via HTTP.

Then go to the microsoft.identityModel section of the RP’s web.config and set the audience Uri (the Uri the STS is allowed to point back to) to https://customrp.mydomain.com/LoginPage.aspx.

The remaining task is to create a Relying Party Trust in the ADFS as ADFS will not return claims to an unknown relying party. To do so, open the ADFS management snapin, go to Relying Party Trust, click on “Add Relying Party Trust” and select manual configuration (since our simple RP application does not publish any metadata).

On the next tab select “ADFS 2.0 profile …”, click next and then next and stop where ADFS asks about the passive WS-Federation. Yes, you want to have the passive WS-Federation enabled, check the box in then and put “https://customrp.mydomain.com/LoginPage.aspx” as the WS-Federation Uri of this RP. Note that the Uri is case sensitive and must match the audience Uri you have provided in the RP’s configuration.

When the wizard closes (just click “next” until it does so) you will see a new configuration window where you configure claims which will be passed to your RP application. Select “passthrough claim” for “Name” and “Role” – because of the way the LDAP is configured as the claims provider, both attributes can be passed through to your RP application.

When you are done, try to log into your application. Instead of the custom STS login page, you should see the ADFS login page and when you provide valid credentials, you should be redirected to your application.