How do I inject dependencies into a custom RoleProvider with Windsor?

Question

I'm using Windsor with ASP.NET MVC4 and I've written a custom RoleProvider around a legacy security framework. I need to inject a connection string and file path into the provider so I can provide these to the legacy framework, but when I come to use the AuthorizeAttribute, I realise that I have no idea how to intercept the construction of the provider in order to inject these values.

If it helps to include code, my role provider has this kind of constructor :

public class CustomRoleProvider : RoleProvider
{
    public CustomRoleProvider(string connectionString, string logPath)
    {
        LegacySecurity.ConnectionString = connectionString;
        LegacySecurity.LogPath = logPath;
    }

    [Method overrides go here...]
}

My AppSettingsConvention looks like this :

public class AppSettingsConvention : ISubDependencyResolver
{
    public bool CanResolve(CreationContext context,
                           ISubDependencyResolver contextHandlerResolver,
                           ComponentModel model,
                           DependencyModel dependency)
    {
        return ConfigurationManager.AppSettings.AllKeys.Contains(dependency.DependencyKey)
               && TypeDescriptor.GetConverter(dependency.TargetType).CanConvertFrom(typeof (string));
    }

    public object Resolve(CreationContext context,
                          ISubDependencyResolver contextHandlerResolver,
                          ComponentModel model,
                          DependencyModel dependency)
    {
        return TypeDescriptor.GetConverter(dependency.TargetType)
                             .ConvertFrom(ConfigurationManager.AppSettings[dependency.DependencyKey]);
    }
}

(originally from here : http://blog.ploeh.dk/2012/07/02/PrimitiveDependencies/ )

I'm hoping that I can replace one of the services somehow the same way I'm replacing the HttpControllerActivator to use dependency injection with the ApiControllers.

Is this possible? Or do I need to look at another way of providing these dependencies?

Take a look at this related question: https://stackoverflow.com/questions/15410575/custom-membership-provider-and-unity-injection — Steven, Feb 10 '14 at 16:32
Sorry, I'm really not sure how that helps me directly. It has given me the idea to implement my own `IDependencyResolver` though, which might work, I guess? — adhocgeek, Feb 10 '14 at 16:40
The thing is, you can't do dependency injection on your `CustomRoleProvider` (just as you can't do with a membership provider), since it's the .NET framework that's creating that type based on some XML configuration. So the trick is to create a facade that you configure in XML that resolves the 'real' provider from the container. That's basically what that related question describes. — Steven, Feb 10 '14 at 16:48
Ok, I understand what your approach is, but it doesn't seem any better than making the container static and using that as a kind of service locator in the `RoleProvider` constructor. Perhaps a better approach might be to override the `AuthorizeAttribute`? — adhocgeek, Feb 10 '14 at 17:11
Well, if you make the 'real' provider a proxy to the provider that is resolved, you allow that provider to be built-up by the container and allow all that code to be tested. By resolving the provider on each call you also prevent any dependencies from living too long, since the 'real' provider is a singleton. If this is all not any concern and the provider only has one static dependency, there's indeed little reason not to go with the Service Locator-constructor approach. — Steven, Feb 10 '14 at 21:05

score 1 · Accepted Answer · edited May 23 '17 at 11:58

The results of my research :

Windsor (unlike StructureMap) does not have a way of injecting properties into existing objects
The AuthorizeAttribute does not call into the RoleProvider implementation directly, it calls into Thread.CurrentPrincipal which returns an IPrincipal implementation...
Basically it's impossible to provide a resolved RoleProvider to the AuthorizeAttribute, even though you can get hold if it before it calls the provider by writing your own implementation of IFilterProvider (cf. IFilterProvider and separation of concerns)

What I ended up doing was providing a method on the CustomRoleProvider which set the connection string and log path, then just setting it up in Application_Start :

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    WebApiConfig.Register(GlobalConfiguration.Configuration);
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);

    var provider = Roles.Provider as CustomRoleProvider;
    if (provider != null) provider.Initialize(ConfigurationManager.AppSettings[ConnectionKey], ConfigurationManager.AppSettings[LogPathKey]);
    GlobalConfiguration.Configuration.Services.Replace(typeof(IHttpControllerActivator), _container.Resolve<IHttpControllerActivator>());
    ControllerBuilder.Current.SetControllerFactory(_container.Resolve<IControllerFactory>());
}

There might be a better way to do this, but for the moment I went with the pragmatic solution.

Update 2014-02-12

I found another way to replace the provider in the Roles class via refelection. All you need in your web config file is <roleManager enabled="true" /> and to override Name in your CustomRoleProvider to return "CustomRoleProvider" and then in the Application_Start method add this :

if (!(Roles.Provider is CustomRoleProvider))
{
    var rolesType = typeof (Roles);
    var flags = BindingFlags.Static | BindingFlags.NonPublic;
    var provider = _container.Resolve<CustomRoleProvider>();
    rolesType.GetField("s_Provider", flags).SetValue(null, provider);
    var providers = new RoleProviderCollection();
    providers.Add(provider);
    rolesType.GetField("s_Providers", flags).SetValue(null, providers);
}

The call to Roles.Provider forces the Roles class to do its initialisation magic (otherwise we'd have to set a ton of other private fields) and we need to replace the collection because consumers of the Roles class call into that looking for the appropriate provider.

However, I'm not sure that I'd necessarily recommend this and I'm not sure if this is entirely sufficient, but it seems to be working for me so far.

Update 2014-02-20

There's a different way to do this which doesn't involve magical reflection - http://bugsquash.blogspot.co.uk/2010/11/windsor-managed-membershipproviders.html

Although this blog post is talking about the MembershipProvider, it's fairly trivial to change the code for a RoleProvider instead. Essentially this is using a kind of adapter pattern leaving the resolution of the actual role provider up to the adapter. It does involve making the container static and using it in a kind of service locator way, but that's a small trade-off I think.

Michael K · Answer 2 · 2019-08-25T20:59:46.457

Old question, but this works well for me in an Asp.Net RoleProvider in 2019.

In your DI Container Configuration

{
    ... Type registrations
    GlobalConfiguration.Configuration.DependencyResolver = 
        new UnityDependencyResolver(container);
}

in your RoleProvider...

private IYourType _yourType;
public override void Initialize(string name, NameValueCollection config)
{
    ...
     _yourType = GlobalConfiguration
                 .Configuration
                 .DependencyResolver
                 .GetService(typeof(IYourType)) as IYourType;

How do I inject dependencies into a custom RoleProvider with Windsor?

2 Answers2