UserNamePasswordValidator: When DI and Framework collide

Question

I am building a custom UserNamePasswordValidator for a WCF service. I am wiring up the service with Autofac + WCF/multitenant, all fitting neatly together. However I'm not sure what strategy to use to wire/implement this authentication class.

Ideally, I would start with

public class MyValidator : UserNamePasswordValidator {
    public MyValidator(Func<Owned<IMyUserService>> userservicefactory) {
        ...
    }
}

However, this isn't strictly possible because of the way that a UserNamePasswordValidator is consumed by WCF (the only option appears to be parameterless constructor).

So, questions:

1. Am I correct or is there some WCF config voodoo with which a UserNamePasswordValidator factory can be configured?
2. If "no", what is the most "DI-correct" fallback strategy that can be used in this scenario?

Answer 1

I configured the service host in code at startup or within a custom ServiceHostFactory.

From the XML configuration, I removed

<userNameAuthentication 
          userNamePasswordValidationMode="Custom"
          customUserNamePasswordValidatorType="Common.MyCustomUsernamePasswordValidator, Common"/ -->

And since I configured my container prior to hosting:

var auth = host.Credentials.UserNameAuthentication;
auth.UserNamePasswordValidationMode = UserNamePasswordValidationMode.Custom;
auth.CustomUserNamePasswordValidator = container.Resolve<Common.MyCustomUsernamePasswordValidator>();

Answer 2

You may take a look at UserNameSecurityTokenAuthenticator, you can do the validation in this class and skip the UsernamepasswordValidator.

And you can implement your own ServiceCredentialsSecurityTokenManager, which you can determine how to create the authenticator.