The MultiplexingMembershipProvider will call GetUser before it calls ValidateUser when authenticating a user. If you set the default provider to be your own provider, ValidateUser will be called first. So, a little different behaviour there, no biggie as long as you check that your user actually exist in the GetUser method.

I discovered this when implementing two providers, and wrongly assumed that GetUser would only be called for a valid user (after ValidateUser had been called first.) I did not really need to set any of the properties on the MembershipUser object except for the username, and that I got sent into the call anyway. Easy way out, just create a new (though rather empty) MembershipUser object and return it with the username set.

Worked like a charm when I tested it directly, and also when I used it as the last one of many providers "behind" the Multiplexing provider. But I needed two of these providers, which did the same in the GetUser implementation. This is where my trouble started.

If your provider returns a MembershipUser object from GetUser instead of null, the Multiplexing provider will call ValidateUser. In my case, ValidateUser failed (the user did not exist), and it seems like the Multiplexing membership provider stops the authentication at this point, and never calls the next provider in the chain. Bummer.

Conclusion: Make sure that you validate that the user exists in the GetUser method in your provider if you intend to use it with the Multiplexing provider. Also, you need to know that the Multiplexing membership provider stops trying after the first provider in the chain reports that it has a user with the given username, even if it cannot validate the user. This also means that you cannot have users with the same username in two different providers, only the first one in the chain will be checked.