I hesitate to make a decision about the authentication and authorization in a new web application.
The Membership, Roles and Profile built in Asp.net 2.0 seems impressive, but there are too many things behind them, which is uneasy to find out.
I've decide use my own DB structure so I have to rewrite my own provider, but there is still some thing I can't figure out, such as session and cookie.What, when and how does it encrypt and after retrieving user info from DB, seems cookie is uesed but how about session? I make use of MSDN, .Net Reflactor and Goole but get no answer. I mean I know the configuration and result but not sure how.
I don't think I can do a good job in the later improvement and maintenance if I don't know how the things process behind the Login controls and membership components.
So help me please, what should I do? I want to know how things run behind the screen. Any suggestion is looking forward!
You can download the source code for the providers here. Learn as much as you want from it and see how Microsoft implemented it. You might even want to recycle some pieces on the FormsAuthenticationTicket.
Microsoft's also using salted hashing to store the passwords for increased security. That might also be of interest to you when you make your own providers.
You should use .NET Reflector to find out how the .NET code works. You can also actually single-step into the sources in later versions of Visual Studio.
Related
I'm building my own authentication module(to sell, hopefully) and I'm wondering what my competition is. What alternative authentication libraries exist other than Windows/Forms Authentication? I'm looking especially for frameworks that were not produced by Microsoft.
To be specific, I'm talking about authentication methods with .Net libraries that store user credentials(username/password hash) in your own database.
Well, there's openid, oauth, facebook, and whatever else you want to do.
Honestly, it sounds like you're creating a solution in search of a problem. There are already so many different, and free, authentication systems out there. Why would anyone want to pay for yours? What makes your unique? What makes your desirable over anyone elses?
EDIT:
Most people who just need a username/password stored in a database, they find the standard Membership and Role Providers to be more than adequate. They're fairly simple, and work well. That doesn't usually leave much impetus to design something new.
What does your library do that Membership/Role Provider doesn't?
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.
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).
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...
Sorry, I'm not even sure how to ask this exactly... but I wrote a website with logins. For that, I made my own users and passwords tables and hashed the passwords myself. Now, I would much rather move to Microsoft's built in membership provider with asp.net in sql server. Does anybody know a good way to migrate over?
The only real idea I've had so far is to make both systems run simultaneously, then when a user logs in, validate them in my old system, then ask them to re-enter their password and save their new stuff in the microsoft's system... then clear the record out of my old system. Eventually, I would hope that would move everybody into the new system. But that seems annoying and messy. Is there some better way?
Sorry if that doesn't make any sense.
You just use the custom membership providers.
Here is a good SO link
How to implement ASP.NET membership provider in my domain model
I am currently converting a very old, but working classic ASP site to ASP.Net.
It has a completely custom written user management system. Whilst it works fine, it really needs a refresh as I want it to be more flexible for some future projects in the works.
When I asked someone about this, they said "You need to use the Microsoft Provider" and gave a lecture on how Microsoft release all these things for free and how good they are and should be re used as much as possible.
I have done quite a bit of research on it (mainly looking at the videos on http://asp.net/learn ) and am very impressed by some of the features as there appears to be drag and drop components for items that would take me ages to write.
However, the current membership database is complicated to explain, it is a completely custom written database that has many internal relations... It is not really "compatible" with the default Microsoft Provider.
I have taken a look at How Do I: Create a Custom Membership Provider?, but I feel a little out of my comfort zone and worried it will either be slow, introduce a security hole or simply won't work.
At the end of the day, the Microsoft Membership Provider should work for me - the only customisations I really need is the login to use the username/password field in my database and the create user script which has a lot of custom code to several third party systems (needing to provision services etc.).
I was just wondering, what would you do if faced with a similar situation?
Use the Microsoft Membership Provider and somehow get it to work for you (although I would like suggestions)
Use the Microsoft Membership Provider but use custom provider that is customised around your code.
Use your own completely customised solution?
That video does complicate things :) If you're going to implement a custom provider then reflector over the existing one is a good place to start :)
As a quick and dirty option you could, of course, hack the stored procedures that the SQL Membership provider uses but the custom code to provision services is probably stretching that.
If you think about it the remote provisioning of services doesn't really belong in a membership provider, it's not really a membership function - all membership does is provide usernames and passwords and authentication around them. My own feeling is that you should move the provisioning of services out of there, and perform it on the ASP.NET site after a user has been created - even if that's just calling a stored procedure once the membership provider has done its thing. If you do this you may find that the SQL membership provider will do everything you need it to (probably with the Roles & profile providers too), and thus you have way less code to write!
I've been in similar situations in the past. In both cases we created custom implementations of the providers (MembershipProvider, RoleProvider, ProfileProvider) around the existing mechanism.
In both cases we only used the provider implementations for read-only access, e.g. to give us the easy validation gubbins in web.config and suchlike. The user administration code was left well alone as it worked just fine.
If the existing provider works (has the right fields for your data), use that to start. You can VERY easily replace that with a customer provider later (just a single config value change).
Beware there isn't an "out of the box" ASP.NET management interface for that, you'll need to roll your own or use a third party one.
Use my specialized MembershipProvider to work against my own database tables.
Fairly new to ASP.NET's membership roles and forms authentication, it would seem that this would save more time and effort for my implementation.
But, I would also like to know if it comes in all goodness or does it carry any extra baggage (cons) in terms of:
Performance
Scalability
Thanks in advance for your replies.
I have never had a problem with performance or scalability with the default providers. Here are two tips that I've picked up along the way.
If you are using the providers and hashing passwords in a load-balanced setup. You will have to specify your machine key in the web.config
By default, users roles are not cached so every time you need to check a user role, you will make a round-trip to the DB. Using the cacheRolesInCookie="true" attribute in the tag in the web.config will cache them for you.
I've used the SQL Membership providers in ASP.Net in many large scale web applications and have never had any issue with it.
In our current application we've had to add extra fields and we expose these using an extra API.
Optimize ASP.NET Membership Stored Procedures for greater speed and scalability
Short answer: no real baggage in terms of performance and scalability. If anything, the real baggage is in terms of testability and portability (gobal static singletons are bad), but you can code around that.
It will probably work just fine, you can always switch provider or write your own later on.
I've written a provider that works as a layer between the ASP.NET authentication system and POCO classes together with a repository and nHibernate, that way I can let users login and get authenticated the ASP.NET MVC out-of-the-box-way, yet have the users and roles as any other model/view/controller in my system. Also by using IoC and interfaces I can use the exact same provider in different projects that handle users in different ways. Yay. Strange though that something like that didn't come out of the box.
If you use the default providers then it can be quite difficult to do things like search or filter users or do admin-type things, since you can't (easily) query the database directly. You have to go through the API, and it's quite limited. So, if you want to produce a lot of reports on users, be aware this is not easy to to efficiently.