What is the best approach to take for user profiles in my web application?

Question

I'm currently building an ASP.NET MVC web application. My site security is (currently) built atop an extension of the System.Web.Security Membership model where I've extended:

• AuthorizeAttribute
• MembershipProvider
• RoleProvider

This has sufficed for the security mechanism - although it has complicated a lot of things I could probably have done more simply. However, it's done and it was a very useful learning experience. Although at a later point, I may still rip it all out and replace it with a model that is more specific to the site - I'd like to keep all my user profile information in a single table indexed and built specifically for the site.

Now I've moved onto development of the user personal profiles. I need to store a lot more user information than for the basic user log-in system. I've checked out the ProfileProvider which seems like it's a whole different can of worms. I like that it's flexible enough that I can configure user profiles right from the web.config without having to rebuild my objects and the ProfileProvider handles the rest. What horrifies me though is the PITA this causes to run queries or reporting on my database. This fact is probably clouding my judgment against the ProfileProvider. Is the ProfileProvider even the right model to be using for this?

Should I go down the same road I did with the customization of the existing system or custom build my own system?

On one side, it going down the customization of the ProfileProvider could be a useful learning experience but on the other hand, I can see this rapidly becoming a reporting and querying nightmare. But coding my own is going to make querying/reporting very simple but I'm not going to learn much less.

If anyone has any experience with use of or customization of the ProfileProvider model (if that indeed is what I should be using) and can either point me in the direction of useful reading material or can steer me in a more useful direction I would really appreciate it.

Thanks in advance.

Answer 1

I use tables in the database to implement security. A table-based approach is simple to implement, easy to understand, and provides for security trimming by simply joining the table to the table of items to be trimmed. Reporting is straightforward, and table-based security can be used for roles as well.

I just found the existing security model in ASP.NET MVC to be cumbersome, and it didn't do some of the things I needed it to do. In particular, it's difficult to apply attributes on things like document records that require access to an ID from the database, because you wind up looking the record up twice; once in the attribute class, and once in the repository for the controller method.

All other things being equal, I would rather maintain one security system than two. So I use the built-in security to authenticate the users, but after that I switch to table-based security.

Answer 2

I read in some books and many blogs that the way to go was to implement your own MembershipProvider, RoleProvider and ProfileProvider based on the base class that Microsoft provides, and that's what I did. But at the end, I ended up changing all that code to my own custom-based security schema, which gives me all the flexibility I require.

The problem is that those providers make a lot of assumptions that might not accommodate to your system. For example, the create method of the MembershipProvider requires question and answer as parameters (which I didn't require) or if you need another attribute, it starts becoming cumbersome to code and maintain.. And let's not talk about testing it...

Like you said, the learning experience is always good, but the amount of code that I had to maintain to make it fit my needs was not worth it.

As for the AuthorizeAttributte, what I did was I created my own filters that fit my own security schema.

My advise? If your requirements fit what Microsoft thinks a ProfileProvider should look like, go for it. If not, build your own. You can copy some of the practices they execute, but it gives you the freedom to change wherever you have to.