ASP.NET MVC User Authentication - asp.net-mvc

I am using the Repository/Service pattern with a MVC 3 application.
My question is two fold:
1) Where do you manage the authentication at? In the service layer or in the MVC application itself?
2) Should I be using a custom membership provider and forms authentication?
Thanks,
Sam

In my case, I tend to create an authentication service that handles the logic for this.
In the actual application, I use Forms authentication, but calls to a custom service to handle the details. That way, I can reuse the authentication mechanism(s) for other applications, or trade them out to a different standard altogether, whatever is best.

The answer is always it depends,
Normally I delegate every tasks to Service Layer including authentication when MVC application is merely one of the many interfaces.
I think you should use it if it fits your requirement

Related

Can ITfoxtec SAML2 supprot multiple IdPs?

I am attempting to make my ASP.NET MVC web app provide SSO to multiple IdPs, and I am wondering if it is possible to support this scenario using the ITfoxtec.SAML2 library.
I have many different clients, several of whom want to have an SSO integration with my service. Each of the clients has a different sub-domain (e.g. business1.myapp.com, business2.myapp.com, etc.) and I will need to use their unique part of the name to look up their metadata and produce a configuration that will talk back to them.
The example code that I have seen seems to be supporting a more traditional one IdP to one SP scenario.
Additionally, if any one knows of a non-Core ASP.NET MVC example application, I would be profoundly grateful to know where to find it.
In your case I would implement some Saml2Configuration logic, where I can ask for a specific Saml2Configuration for the current IdP. This specific Saml2Configuration is then used in the AuthController.
After a binding.ReadSamlResponse(Request.ToGenericHttpRequest(), saml2AuthnResponse) with a generic Saml2Configuration you can read the IdP issuer in saml2AuthnResponse.Issuer. And then load the correct Saml2Configuration.
A link to a non-Core ASP.NET MVC relaying party sample application https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test/TestWebApp

ASP.Net Identity using a custom auth provider/service

I am currently developing an ASP.Net MVC web application that requires username and password authentication. I started looking into using ASP.Net Identity for this however I have a very important requirement, the requirement is that the web application itself has no direct access to any databases, all DB Access is to be exposed to the application via an internal REST service. This is due to certain security polices we follow.
I realise that ASP.Net identity is capable of supporting external authentication methods but my question is split into 2 parts.
1) How would I configure ASP.Net Identity to use my custom REST service for authentication?
2) How would I go about developing a service that can be used by Identity for authentication ? (what would need to be returned from the service to ASP.Net Identity)
Any help on this would be most appreciated.
I just did what you are asking about. First, as FPar suggested, you need to implement an IUserStore and pass that to your UserManager. Your custom IUserStore will implement the interface, I used Resharper to generate stubs, but instead of using entity framework, you will use HttpClient to make calls to your REST service.
The REST service will have one action on a controller, I called my identityController, for each of the interface methods you actually need. I implemented the userstore, userloginstore and the rolestore, with code for about 10 calls I actually used. The identitycontroller then is what actually accesses the database.
I also retained the fully async pattern, using async REST calls and Database looks, both with and without entity framework. A shortened version of my data access code is in another question here, regarding IUserLoginStore::AddLoginAsync. In that class I actually used the original entityframework implementation of the user store for part of work, and eventually settled on plain (except for async) ado.net for the parts I couldn't make work that way. The tables are simple enough, using your ORM of choice would not take a lot of time.
Good luck!
You want to implement your own IUserStore and then pass a reference to the UserManager. Look into the Startup and the IdentityConfig files in the standarad ASP.NET MVC with individual user account authentication, to see, how to use them.
You can look here for an IUserStore implementation with entity framework. This is a template, you could start from and change it to your needs. However, you don't have to implement all interfaces, just implement the interfaces, you really need. The UserManager is able to handle that (it throws an exception, if you call a method, that requires an interface, that you don't implement.)
These are two excellent articles on this subject:
http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
http://www.codeproject.com/Articles/762428/ASP-NET-MVC-and-Identity-Understanding-the-Basics

Asp.net mvc4 authentication through WCF

I have a requirement for project to build a ASP.NET MVC4 (razor engine) "Front-end" and a WCF service as "backend" (with a sql server 2012 database).
A requirement is to login, register etc. I want to put this logic in the backend, but in the front-end I would like to make use of the [AllowAnonymous] and the logic to authenticate a user with roles (for example use of formauthentication, webmatrix.WebSecurity, Membership provider?).
Is it possible to realize? Do I have to create a login and register (and roles etc.) features by myself? Or can I use a built-in features/libraries of the ASP.NET MVC or WCF? Or both?
Could you give some examples/suggestions/tutorials to realize this?
Thanks in advance
I think this should work for you:
http://msdn.microsoft.com/en-us/library/bb386582.aspx
Edit: To elaborate you can use custom logic for WCF authentication including calling the ASP.NET membership providers which should work fine with MVC and the security attributes you mentioned.
Or is the WCF service on another server and you want to call from your ASP.NET controller to your WCF service for authentication? This is a bit more complex, but you should be able to do it by implementing your own Membership provider.
Depending on the scenario you can reuse some or all of the login and register views that come with MVC.
Edit: In the second scenario here are some pointers that might help:
http://singlesignon.codeplex.com/ - Seems to be what you need, but I didn't check out the code.
Custom membership that uses web service for authentication - No code, but it confirms that it should work.

Upshot/Knockout Architectural Best Practices - What is the preferred of method of limiting user access to functions exposed through the WebAPI?

A fundamental idea in implementing a single page application with Knockout and Upshot is that most of the data will received from and sent to the server in JSON format using AJAX.
On the server, we will expose a number of endpoints (using perhaps WebAPI and the DbDataController) to respond to requests from Upshot. These endpoints may provide general queries for data such as lists of clients, previous orders, account information, etc.
Obviously, it is not desirable for one client to be able view another clients account information, previous orders, or other private data.
What strategies or approaches be used to secure queries (and data) which are being requested from upshot (or other mechanism) to the server? (In other words, how do we make sure a user only has access to his own data?)
Are the strategies the same or different than those used in a normal ASP.NET MVC application--namely use of the Authorize attribute?
This is probably a very simple question, but I am still not clear on all the differences between WebAPI controllers and normally ASP.NET MVC controllers.
Thank for your help!
A custom authorize attribute is one possible way to implement this requirement. The only difference with standard ASP.NET MVC controllers is that you derive from System.Web.Http.AuthorizeAttribute instead of System.Web.Mvc.AuthorizeAttribute.

WCF Rest Service or ASP.NET MVC Controllers/Actions?

I would appreciate if someone can provide some insight into which one is more beneficial.
RESTful service in WCF can provide the same functionaly as ASP.Net MVC Controller, i.e URLS can be formed appropriately using Controller/Action.
Is there real benefit of using one over the other.
WCF Rest service will provide..
1) Cert Authentication out of the box
2) Logging
3) Message Headers etc
MVC
1) Different Action Results out of the box
If someone has used or debated these two technologies . please let me know
UPDATE:
I went ahead with the MVC Model as it gives me lot of flexibility and I can use the same action to render different views with CustomActionInvoker, which is really cool!!!
-RN
WCF makes your service more manageable and offers more protocol options like TCP, Named Pipes, PerChannel, and MSMQ.
WCF gives you the ability to specify multiple methods of binding to the service through the web.config including restful urls, giving you greater flexibility. In conrast, mvc provides you with the ability to easily construct resful urls and output data via code in much the same way as you do a web application, which is really easy and requires minimal additional knowledge if you already know mvc.
My recommendation would be to go with wcf if the service is really important to the overall solution, likely to be called in a different or many ways or has or is likely to have special security requirements.
On the other hand I would go mvc if this is meant to be a quick and simple isolated solution or perhaps is just providing a different representation of data being output in an existing .net mvc application.
At this point in time, your best option is ASP.NET MVC. It provides cleaner access to the HTTP primitives you need to be able to design RESTful solutions.
The only significant advantages of WCF Rest is the ability to self-host the service and if you want to use ADO.NET Data Services to deliver OData/Atom services, then obviously WCF is your best choice.

Resources