I have an ASP.NET MVC application into which I have just integrated the RPX third-party federated identity system. The integration is working ok, but I'm having some difficulty wrapping my head around what to do with it at the ASP.NET level.
I'm pretty new to ASP.NET (I'm learning it with MVC), and I've discovered a little bit about the provider model for membership and profile data, and it seems incredibly complex (but equally powerful). The specific thing I'm struggling with is the persistence of the user to the database. I have so far been using the standard SqlMembershipProvider implementation, which has worked fine. However, I now want to do things like storing and checking a verification code in the database for email verification (in case the user's email address is listed as unverified by the RPX result), and persisting the returned data. Some of this is essential to authentication, such as the email address, whilst some of it is simply profile information (like the user's age, gender, etc.).
In the ASP.NET database, I have a bunch of other app-specific tables which I interact with via NHibernate. My understanding of the Membership/Profile stuff in ASP.NET is that it handles the persistence, and so I don't need to do anything with NHibernate to get this going.
My aim is for the sign-on experience to be similar to StackOverflow's, but with a few extra bits (such as email verification). Do I need to build a full-on custom provider to be doing this, or can I bend the default SqlMembershipProvider to my will in an effective way?
[Please also see my other question, regarding passwords in such an application.]
I've done similar work in the past just by creating a new provider class that inherits from SqlMembershipProvider, then overriding the methods I need to.
You can still call the base method implementation to do most of the work first, then execute whatever additional logic you need to in your derived class. Building a provider from scratch is a LOT of work, and should be your last resort only.
You can add a new table to the database with a key reference to aspnet_Membership - then you add your own stored procedures that you call from your derived provider methods to do whatever you need to this new table. This is better than adding columns to the membership schema, as it keeps your custom stuff decoupled.
You'll still need to investigate the SqlMembershipProvider class, in terms of what you need to override, but I think this approach will work for you, based on what you've described.