Haven't done security in ASP.NET before. Need to secure an MVC site - simple username/password access for admin access to the site's logs and admin areas, not for general users.
Looked into Identity/OWIN, and it is, as of this writing, half-baked. There are multiple ways to do things, the docs are few or non-existent, and blogs dicuss deprecated or alpha versions. The samples don't correspond to anything in the docs or blogs. In short, it's a mess.
Security is hard, so I want to use something that was written by an expert, works and is tried-and-tested. Must be from Microsoft, not some third-party stuff.
So what security API came before Identity/OWIN, which works well and hasn't been compromised? They've released many, so I don't know which to use?
Forms Authentication with custom Membership and Role Providers were used for years and still can be used. The SimpleMembership is something that tries to simplify the original provider model but sacrifices too much, in my opinion plus it us still not that simple.
There are thousands of tutorials on Forms Authentication and you should be able to start immediately. The Membership/Role Provider model is also extremely well documented.
In terms of correspondence
Membership/Role Providers correspond to the Identity api
Forms Authentication corresponds to the owin security api
The predecessor to Identity/OWIN was SimpleMembership.
However, according to my question "What is MVC4 security all about?", SimpleMembership is an oxymoron.
Related
My organisation has several web facing ASP.NET Web Forms Apps. They currently use Windows Authentication with impersonation enabled. The web apps are hosted internally but are exposed publicly via different domains e.g. www.abc.com & www.xyz.org.
A new requirement, is that a single log on page will be provided for all users of these apps to log in via.
Some of the solutions proposed are:
Implement an OpenId Provider backed by Active Directory (DotNetOpenAuth), modify existing apps to become relying parties of this OP.
Implement SSO through MS Forefront Threat Management Gateway.
I don't have experience with either of these. Are the proposed solutions feasible? What are the pros and cons of each? Are there other solutions that might be more appropriate?
OpenId Provider is a fairly good idea. It will be an easier route and there are some good details around the web.
You may also want to look into Active Directory Federation Services.
http://msdn.microsoft.com/en-us/library/bb897402.aspx
It is not uncommon for businesses moving to hosted solutions look to implement federated services and this is something Microsoft anticipated when setting up and creating Azure - to be corporate friendly.
They have put together a comprehensive guide here, which while not directly related to your question, does have extensive details about the technology behind federated services.
http://msdn.microsoft.com/en-us/library/windowsazure/hh127796.aspx
For more thoughts and information on, specifically the pros and cons, take a look at these articles which answer it in more depth:
http://technet.microsoft.com/en-us/magazine/ff721824.aspx
http://windowsitpro.com/active-directory/ease-cloud-security-concerns-federated-identity
http://www.csoonline.com/article/221034/the-truth-about-federated-identity-management
Some DotNetOpenAuth thoughts:
http://www.codeproject.com/Articles/325228/Choosing-technologies-for-NET-project
http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/7a1c4e0c-346c-4008-9e5c-87ba1273b2aa/
Finally, we have personally gone with OpenAuth for one of my teams solutions. The implementation was fairly painless once we took time to really understand the RFCs (which was no easy feet, but worth taking the time to do). There are also a ton of resources on the web to get a hang of the implementation.
I'm implementing my frist web application on asp.net mvc 4 and I need to differentiate my users according to roles ( show certain menus to some roles and hide them from others) basically what i want is to manage my users and roles. I understand that security is quite an important part of my application so I don't want to risk it by implementing something not secure while there are other options for doing this.
My question is, is there something already built on MVC 4? is it apropiate for my a small site? ( I don't expect more than 50 concurrent users) is it better to implement my own user administrator? if so, where can I start? so far what I've found is the membership provider but it seems quite big for what i need, there will be no user registration instead the new users will be added by system admins.
Thanks for taking the time for reading this, any feedback will be appreciated!
I would have recommended the default membership provider as it makes use of security industry best practices (i.e. salted hash). However, if that seems overkill, there is a simpler membership provider called SimpleMembership Provider
You can use New ASP.NET Universal Providers (updated version of legacy Membership Provider).
It can be used in small application as well as large application (if you application continues to grow).
Password is encrypted with salt, so it cannot be compromise easily.
Follow the Scott Hanselman's link and see the demo. You will see how easy to set up.
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 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.
What do large websites built in .NET use for their login components?
I will be implementing the login and membership features of a large .NET web application. As I see it, there are 4 options:
Leverage the default Microsoft Membership Provider
Build a custom Membership Provider
Use a different 3rd Party Component
Build an entirely custom login/authentication framework
I am trying to optimize for reliability, so I would like to know if sites like MySpace or PlentyOfFish have already established a best practice in this area. The real motivation for this question is I want to validate that the MS Membership Provider strategy will scale well.
I know StackOverflow uses OpenID, but I don't think that would be a good solution for what I am working on as a lot of my prospective users will be non-technical. Feel free to pitch why OpenID should be considered if you believe strongly in it.
Always rely as much as possible on platform-provided tools for security tasks such as authentication.
In this case, that likely means inheriting from one of the stock MembershipProviders. That will let you re-use all the existing code for the provider, plus any tweaks you need to make it work with your existing system. It's possible you can find a 3rd party component that works well for you that already does this.