I really like the concepts behind Hot Towel, and have viewed the course on Pluralsight a few times now to really get a good idea of what's going on.
One aspect of Hot Towel really eludes me - how can it be used for an application that demands different user roles? The topics of authentication and personalization aren't dealt with in the course, and don't seem to have any easy way to accomplish this with modifying the framework itself.
I had the same question when I first watched the Pluralsight courses and started working on my application which needs to perform Authentication and Authorization.
It seems the problem is not specific to Hot Towel Template but in general a problem when using Web API. A quick look at the ASP.NET overview for Web API provided much information (http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api). If you plug in your custom RoleProvider and ProfileProvider, that should allow you to re-use the Authorize() attribute.
Note that when working with REST & Web API, the API has to be stateless and hence no Session is present. I found articles providing workarounds for getting the Session[] variable active but decided against using it. You can use an object cache to achieve the same results.
If the Authorize() attribute doesn't cut it for you, you can write your own Authorization Filter. This SO question can provide more information (though it focuses on preventing Cross Site Request Forgery, the basic structure and how to use the filter is same when doing custom AuthZ).
Since Javascript code can be altered by the attacker on the browser end, relying on any protections provided in the application's JS is not sufficient and providing the protection on the Web API layer is mandatory. The authentication and authorization boils down to protecting the Web API and there are tons of information available for protecting external facing web services that can be adapted for your scenario.
Related
I have two projects. One is an ASP.NET Mvc, and the other is a Web API.
The main project is the Mvc one. But I need to redirect the request to the Web API. All posts about it make clear that in order to redirect to another project, it should be a Redirect to an URL:
return Redirect("http://localhost:54270/"); //This calls the Get action in the Web API
But the problem is that I'm using an Authentication in Mvc that I would like to be validated in the called Web Api Action. Is it possible?
The session is not the same, so I cannot retrieve this information. Is there any way to share the same Context between both running sites? Or is it the wrong approach?
Yes, it can be done. In webforms, you can set the keys to hash values to the same key in multiple applications. As long as they are in the same domain, that is all you have to do. I have not tried it in MVC, but the internals are very similar. This is a bit of a kludge, but it works nicely.
In this simple way of doing it, you cannot share information, just the high level session information. As I have not played with this in MVC, you may have to set MAC settings or similar to get it to work. I don't have time to look this up. When I found this worked, the developers were still thinking in the ASP world, so they had a boatload of crap in the Session object which we had to sync up. You should not have this issue.
This method will not share the contents of session, but that should not be an issue if you are using MVC correctly.
If you want to go beyond this, there are ways to set up a single sign on mechanism. Anything that works for ASP.NET webforms should work in MVC, although you may have to add some code for items that would not normally be set in MVC that are required for webforms.
If you want a deeper understanding of the way it works, I would look up how people shared state in ASP and ASP.NET, as these pages generally have more information.
I am a little confused as to how the identity framework works. For example in VS 2013 we can create an MVC application that the authentication is individual user accounts. Once we create it we can register with a username and password. But what if we wanted to have also a DOB in the registration or some other fields such as email or phone etc? Can we do this with the identity framework? What about the way the data base is structured, can we have a custom structure? Or if I want this should I be using forms authentication? Also what is the difference between the Identity framework and Forms authentication in terms of authentication?
Although your post has already been marked as answered, I’d like to add a little more info for future readers.
The first thing we need to understand with VS and Microsoft is that they’ve always tried to provide us with Templates to help us get started. There are many Pros and Cons to using Templates but the idea is that it gets you started quickly without having to manually include stuff yourself.
The idea of Templates is great but to the untrained eye, it provides Microsoft an opportunity to include stuff that THEY think you’ll need or better yet, what your application will need.
This opportunity includes promoting products such as Identity, Knockout.js etc...
In short, Microsoft is not wrong in doing that since the majority of the people do not second guess what is included in their project and because they…well…trust Microsoft.
A great analogy is when you purchase a new computer from a major retailer. When you arrive home and start your computer, you quickly notice that you have a bunch of pre-installed software running in the background (that you never asked for).
To the untrained eye, they will never realize that these are running in the background and their computer will work regardless. But for someone that is aware, he will most likely uninstall all of them and have a cleaner plate.
So Templates are similar to this...
As for the rest of your questioning, I’m sure by now you’ve found the answers.
Even though Microsoft sells ASP Identity as a single solution, Forms Authentication and Identity (Membership) are two distinct frameworks that work together, but serve different purposes:
Forms Authentication manages authentication session/cookies.
Membership/Identity is the store for user information (credentials, user demographics, etc.)
Look here for some additional information and links.
I have a question. I am looking at the newly implemented Simple Membership Provider and it suits my needs out of the box. I am however a little concerned about this provider as I am looking at creating a custom web application for myself and would like to know the security pros and cons of using it and if there is any best practices to go about building a secure web application. Is simple membership secure ? I am a noob when it comes to security.
I recommend not writing your own authentication and session management routines. Security is difficult and any flaws in your design or code could lead to exposure or breaches.
We have used Simple Membership in several web portals that handle PHI (protected health information). Our clients routinely audit our development methods and none so far have considered this a risk. Had we developed our own, they would raise a red flag.
You probably can get further by creating a library class of helper functions to add the features you feel are missing from existing providers, or subclass an existing provider (I don't think they are sealed/final).
In any case, your first step would be to draw up a list of features you want, check to see if an existing provider already does that (for example if you want an XML file provider, one exists on CodePlex), and if none do, either extend or write your own. If you write your own, you would want to make sure that there is another layer of security, like being on an intranet, or local access only or some other layer of defense.
I have a usermanagement table into my sql server 2008 i want to check each user with their particular role frm my database & not from asp.net predefined database. please help me with the code for the same. also what i need to change into my web config file.
You probably want to implement (roll your own) version of the membership provider to make this job easier, more secure and less error prone - it will also save you writing tons of additional plumbing code.
In essence it means implementing the IIdentity and IPrincipal interfaces (Sounds scary but its really not that bad). See this blog here http://www.bradygaster.com/custom-authentication-with-mvc-3.0 for a step by step guide. Additionally it is worth reading the comments and links to enable proper Forms Authentication via Auth Cookie rather than the basic session management referenced directly in the post!.
Also note this example on the blog is for MVC 3 BUT its equally applicable to Web Forms projects too.
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...