Stuck using Microsoft.Web.WebPages.OAuth.OAuthWebSecurity in an MVC application

Question

I don't understand some code in the Microsoft.Web.WebPages.OAuth namespace, specifically the OAuthWebSecurity class.

It's this method here:

internal static void RequestAuthenticationCore(HttpContextBase context, 
    string provider, string returnUrl)
{
    IAuthenticationClient client = GetOAuthClient(provider);
    var securityManager = new OpenAuthSecurityManager(context, 
        client, OAuthDataProvider);
    securityManager.RequestAuthentication(returnUrl);
}

The first line is fine => grab the provider data, for this authentication request. Let's pretend this is a TwitterClient(..).

Now, we need to create a SecurityManager class .. which accepts three args. What is that 3rd arg? An OAuthDataProvider? That's defined as a static, here:

internal static IOpenAuthDataProvider OAuthDataProvider =
    new WebPagesOAuthDataProvider();

And this creates a WebPagesOAuthDataProvider. This is my problem. What is this? And why does it have to be tightly coupled to an ExtendedMembershipProvider? What is an ExtendedMembershipProvider? Why is this needed?

In my web application I'm trying to use a RavenDb database and my own custom principal and custom identity. Nothing to do with Membership or SimpleMembership that comes with ASP.NET.

What is that class and why is it used, etc? What's it's purpose? Is this something that DNOA requires? and why?

Answer 1

I didn't write the code you mention, so I could be wrong here, but I believe the ASP.NET code you refer to is indeed bound to their Membership provider.

If you aren't using the ASP.NET membership provider, I would suggest you simply use DotNetOpenAuth directly (as opposed to through the facade that Microsoft added), which has no such tight coupling.

Answer 2

If you don't need the ASP.NET Membership system to provide local login accounts (accounts stored in your local membership database) on your system I wouldn't go down the Route of using any WebMatrix based bits (WebSecurity / OAuthWebSecurity).

They actually make it harder to interact with DNOA and more or less hide all the interesting bits at the same time anyway ...

As I needed local acounts I ended up pulling all the source code for this into my source code and then editing it from there (I had other reasons for doing this as well, not just to enrich the interaction with DNOA).

If you need local accounts - use WebMatrix If you don't need local accounts - use DNOA directly.