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.]