Techie.notepad

Dependency Injection into custom ClaimsAuthenticationManager and ClaimsAuthorizationManager

How do you do Dependency Injection on a custom ClaimsAuthenticationManager and ClaimsAuthorizationManager when you use Windows Identity Foundation and Claims Based Authentication? What you want to do is set a Factory or some kind of instance Resolver for the instance creation of the two manager instances. Can this be done? (Concept page for WIF managers and OriginalIssuer)

According to The Man himself Mr. Vittorio Bertocci it was not a scenario that made the cut on the feature list for the current version of WIF:

If @vibronet says to try to do it who am I to say no? ;~)

Actually I’ve not done it fully the right way; I’ve cheated but in a way that mitigates the cheat and brings the power of Dependency Injection to the WIF ClaimsAuthenticationManager and ClaimsAuthorizationManager!

The challenge

The two Manager instances are created by your ASP.NET pipeline or WCF pipeline and not by you. When you get power over the instances it is too late. Dependency Injection can’t happen. Or can it? Constructor Injection can’t happen because the instance is already created. Then again all of the IoC container libraries out there have the ability to do Property Injection on already created instances. This is the approach I will use.

The Cheat

In order to do this Property Injection we have to come to a point where we can get to our instances of the managers. Since this happens when you get a request to your WIF enabled service we have to cheat. Avert your eyes! Throw salt over your shoulder and spit etc. ;~)

Note: The code and artifacts for this post are available on the AzureContrib site or with your friendly call to the NuGet package manager: PM> Install-Package AzureContrib.

using System;
using AzureContrib.WindowsAzure.Diagnostics;
using AzureContrib.WindowsAzure.Properties;
using AzureContrib.WindowsAzure.ServiceLocation;
using AzureContrib.WindowsAzure.Utils;
using Microsoft.IdentityModel.Claims;

namespace AzureContrib.WindowsAzure.AppFabric.ACS
{
    /// <summary>
    /// Simple authentication manager which delegates to the real <see cref="IAuthenticationService"/>
    /// </summary>
    public class InjectedClaimsAuthenticationManager : ClaimsAuthenticationManager
    {
        private static IBuilder builder;

        /// <summary>
        /// A hook to access the <see cref="IBuilder"/>.
        /// </summary>
        /// <remarks>Please do no abuse this power!</remarks>
        /// <remarks>The purpose is to enable Dependency Injection on classes that are not createable through a factory!</remarks>
        public static IBuilder Builder
        {
            set { builder = value; }
            internal get
            {
                if (builder == null)
                {
                    throw new Exception(Strings.BuilderIsMissing.F(typeof(InjectedClaimsAuthenticationManager)));
                }
                return builder;
            }
        }

        /// <summary>
        /// <see cref="IAuthenticationService"/>
        /// </summary>
        public IAuthenticationService AuthenticationService { protected get; set; }

        /// <summary>
        /// ctor that uses <see cref="Builder"/> to Dependency Inject this resource.
        /// </summary>
        public InjectedClaimsAuthenticationManager()
        {
            // Perhaps not the prettiest of solutions but this little module is not created through the container.
            Builder.BuildUp(this);
        }

        /// <summary>
        /// <see cref="ClaimsAuthenticationManager.Authenticate"/>
        /// </summary>
        public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal)
        {
            return AuthenticationService.Authenticate(resourceName, incomingPrincipal);
        }
    }
}

And the same for authorization.

namespaceAzureContrib.WindowsAzure.AppFabric.ACS
{
    /// <summary>
    ///Simple authorization manager which delegates to the real<see cref="IAuthorizationService"/>
    /// </summary>
   public classInjectedClaimsAuthorizationManager : ClaimsAuthorizationManager
   {
        private staticIBuilder builder;

        /// <summary>
        ///A hook to access the<see cref="IBuilder"/>.
       /// </summary>
        /// <remarks>Please do no abuse this power!</remarks>
        /// <remarks>The purpose is to enable Dependency Injection on classes that are not createable through a factory!</remarks>
       public staticIBuilder Builder
        {
            set{ builder = value; }
            internal get
           {
                if(builder == null)
                {
                    throw newException(Strings.BuilderIsMissing.F(typeof(InjectedClaimsAuthenticationManager)));
                }
                returnbuilder;
            }
        }

        /// <summary>
        /// <see cref="IAuthorizationService"/>
        /// </summary>
       publicIAuthorizationService AuthorizationService { get; set; }

        /// <summary>
        ///ctor that uses<see cref="Builder"/>to Dependency Inject this resource.
       /// </summary>
       publicInjectedClaimsAuthorizationManager()
        {
            // Perhaps not the prettiest of solutions but this little module is not created through the container.
           Builder.BuildUp(this);
        }

       /// <summary>
        /// <see cref="ClaimsAuthorizationManager.CheckAccess"/>
        /// </summary>
       public override bool CheckAccess(AuthorizationContext context)
        {
            returnAuthorizationService.CheckAccess(context);
        }
    }
}

As you can see when the instances of the two Manager classes are created they grab the Builder of the static. While I detest this type of code this is a means to an end. The Builder must be set in place during application start up so that it is available when the WIF pipeline is activated.

InjectedClaimsAuthenticationManager.Builder = applicationBuilder;
InjectedClaimsAuthorizationManager.Builder = applicationBuilder;

Now it seems there has to be some kind of IBuilder? What this will do is perform Dependency, or in this case Property, Injection on the Manager classes effectively resolving and injecting live instances of, IAuthenticationService and IAuthorizationService. So what about those contracts? Here they are:

The Magic contracts

The following contracts are used to enable Property Injection and Inversion of Control on the Manager classes.

namespace AzureContrib.WindowsAzure.ServiceLocation
{
    public interface IBuilder
    {
        void BuildUp(object o);
    }
}

namespace AzureContrib.WindowsAzure.AppFabric.ACS
{
    public interface IAuthenticationService
    {
        IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal);
    }

    public interface IAuthorizationService
    {
        bool CheckAccess(AuthorizationContext context);
    }
}