Is it worth using the ASP.Net built in profile system?

Question

I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.

Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.

My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.

The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.

But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.

Answer 1

You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...

Answer 2

The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.

My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.

Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.

Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.

With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).