R – Thinking about abandoning the idea of writing a custom membership and roles provider. Opinions

authenticationauthorizationcookiesmembershiproles

I've got a web app I'm building in ASP.NET that has the following security requirements:

  1. Must be able to integrate with a master authentication scheme that passes back a unique key to the application to indicate a user has logged in via a third-party site.
  2. Must be able to use existing user/roles tables.
  3. May use forms authentication and allow users to log in via a separate login page if they aren't members of the third-party site.

I've tried customizing the SQL Role and Membership Providers, but I run into issues, particularly that there is a strongly-typed MembershipUser object that has a uniqueIdentifier (providerKey) and doesn't have room for my own custom set of keys (there will be two) that identify users.

Should I abandon my custom membership provider implementation and just go with cookies/session instead? I'd really like to use the built-in functionality but it doesn't seem doable.

Best Answer

What you might want to do is to build your item 1 over the top of the existing functionality, try that first. With the information returned, automatically log the user in. If the first process fails, do the standard authentication using the built in code.

I have built this type of system on top of the ASP.NET membership provider many times for clients using DotNetNuke, it works very well.

Related Topic