.Net 4.6.1
I am still very new to .Net and MVC. Trying my hand at creating an API and then what will really be a javascript app that will consume the API. I've got a thousand questions but I will focus on one area for this. In the API code I see the methods that support the CRUD operations. I will want the read-only API methods open to the world but the editing methods need authorization.
Is there a best practice here? Should I create two APIs? One for the "public" read actions and another for the admin operations? Can I keep one API and force the edit actions to require auth? I've seen a discussion of using API keys -- perhaps have API keys for the admin methods?
I would recommend reading these articles as a starting point (and some of the other articles in the same section!):
Authentication Filters in ASP.NET Web API 2
Authentication and Authorization in ASP.NET Web API
You can turn on or off authentication for web API at virtually any level.
Globally, per controller, or per action method.
You can also override something, so if you turn it on globally, you can turn it off for a particular controller or method.
So to answer part of your question, I can't see that there is a need to create two APIs, but the articles linked will help.
Related
Background:
I've implemented a Web-API (.NET), now I need to do the most important thing,
Secure it.
As I investigate this topic I understand that the common way is the Bearer Token.
Now we getting to my problem.
My Problem
On one side:
Every article I saw (that explains the concept and the way to implement it over .NET) starts from a project with a Web API template that holds MVC and Web API and in the authentication field choose one option from Individual / Organizational / Windows .
On the other side:
I don't need a MVC project, I need only Web API (without any GUI) that the reason I choose the empty project and check the Web API checkbox, in that way I cant choose an authentication type, I forced to start with no authentication.
Questions:
1.Do I bound to use MVC to get authentication ? if not how can I do it from pure Web API project ?
2.Maybe I will create an Authentication Server (that only generates tokens) from that Web API template (with the possibility of choosing authentication type) ? (and use the token on the real Web API)
3.There is any benefits of implement the Authentication Server on a different project and on different server ? (Kerberos style )
P.S I want to use an out of the box solution because the security aspect is the most important one (to my opinion) and should be flawless.
I wrote a blog on this topic called 'Securing and securely calling Web API and [Authorize]': http://blogs.msdn.com/b/martinkearn/archive/2015/03/25/securing-and-working-securely-with-web-api.aspx. I think if you read this, you'll have all your answers.
The Web API template does include MVC by default so that you get the automated docs feature (which is a great feature to have). However the authentication part is related to a core ASP.net feature, not specific to MVC or Web API. You'll need to enable one of the authentication options to secure your API using .net's built in security features.
If you do not want the MVC project that comes with Web API, just delete it after the project has been created. It is contained within the 'areas' folder. If you delete that folder, you'll be running on pure web api.
To answer your specific questions:
1) No you do not need an MVC project to secure an API project. You can use the [Authorize] attribute on your API controllers and actions.
2) an authentication server gets created by default with the web api template. You can access it and get tokens via http:///Token
3) No, you need to use the api itself to serve valid tokens for secured controller/action requests
Hope that helps. If not, then please be a bit more specific with your questions.
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
I have a rather complex solution which I implemented using ASP Web API, among others. I have 3 projects in my solution worth mentinoing right now. One is a WebAPI containing only api methods. Other two are are the backend and frontend for my application. The backend uses a SPA approach loading mostly empty shells for views and filling everything with ajax acessing the API. The frontend on the other hand because of SEO concerns was decided to be implemented by more traditional means, aka most stuff is rendered server side. My question is, is it possible and good practice to simply call the web api methods from the frontend controlllers and send the results to the view? I don't see a point in duplicating most code in the regular controllers since it's all done with the api.
Any samples on this? I've been searching but couldn't find much.
If you need to call Web API service from C# code (MVC controllers or elsewhere), HttpClient or WebClient can be used to call the services over HTTP.
If you need to simply reuse code, it should be abstracted into a class library (DLL) and referenced from the Web API and MVC projects.
I've run into this same situation and have used the Web API controllers from MVC controllers for a little while at least. You can do this simply by creating new objects of the Web API controllers then calling the appropriate methods off of them. I found this method works fine initially but creates the dependency that means your Web API can't change without also changing the MVC controllers as well.
My advice is to put as much functionality on your models that makes sense with partial classes, and if that is still inadequate then create another logic tier that contains all the shared business logic. You should not have duplicated logic in your MVC and Web API controllers, they should just serve as the glue to get the data served.
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.
I have a website developed using ASP.NET MVC3.
I now want to expose a REST API for others to use which will expose the same features as the website.
In the website, once a user has logged in and credentials validated against a DB, the session manages the logged-in state of the user.
How would I do the equivalent with the REST API, where many of the methods exposed require the user to be logged in (or at least have valid username and password)?
In addition to this, would the best approach for the website be to use the REST API also (presuming the API covers all the functionality required by the site)?
How well is ASP.NET MVC3 suited for this - of course taking into account that the site already exists using this framework?
I wrote up a blog post on how to [Build a RESTful API architecture within an ASP.NET MVC 3 application] years ago and ended up having to let the site go. :( It might be a good start if you want to take on building the REST API into your MVC application.
See answer by #tugberk on using WebAPI for a good solution.
ASP.NET MVC is very well suited for this. Although you can use other approaches (like WCF) I would stick with MVC since you already have a working site that needs to be exposed for other consumers.
See also my other answer:
Which is better for building an API for my website: MVC or Ado.net data services?
Note:
WCF Web API is now ASP.NET Web API and has changed a lot. The beta
version is now available. For more information: Getting Started With
ASP.NET Web API - Tutorials, Videos, Samples
I would go with WCF Web Api to do that. ASP.NET MVC is also nice and capable of exposing your data but WCF Web Api is more capable if you consider exposing your data to your users. It is easy to use and integrate REST Web APIs to your system.
For the authentication, API Key is always the best way for this type of scenario. Here is a good example on how you can implement API Auth with WCF Web API :
http://weblogs.asp.net/cibrax/archive/2011/04/15/http-message-channels-in-wcf-web-apis-preview-4.aspx
Note:
They just released the preview version 5 couple of weeks ago and
Message Channels has been changed to Message Handlers as far as I
know. But the above article should give you an idea.
For security implementations, the below might help as well :
wcf Authentication Token Implementation - How to do
ASP .NET MVC is a great choice for this. I have created several ASP MVC that act as RESTful services as well as websites.
To summarize the design paradigm I use, each controller has an action that emits a JSON representation of the requested data. Said data is loaded in a view model on the server, and the built in JSON serializer takes care of the server side, while a jQuery view nicely loads the data back in for my actual webpages to consume.
The site itself has index actions on each controller that emit that necessary markup, but not the data. jQuery document.ready methods on the pages load in the data from what is essentially my rest api, but build right into the site.
Checkout Nerd Dinner for great sample code. http://nerddinner.com/
Concerning security, I think my experience will differ from yours. ASP MVC integrates very nicely with active directory if your users are all in the same domain and have AD credentials. This is the only method I have used, and with ease, success, and satisfaction.
I have had coworkers interact with other APIs that hand out a token upon calling an authorize method. The received token would then be the clients responsibility to store and hand back on each request, but I cannot talk you through implementation details, as I have not person experience on that front.
I would go with a WCF web service based implementation as follows.
Wrap all your business logic into a separate dll project named as yourproject.businessservices for example
Create a authentication webservice which will generate a non-repeatable token per user login
This login stores the essential details of the user along with the token in a Cache like MemCache which should have a sliding expiration
If the user has not accessed the cache for let's say an hour, the cache expires and the user is logged out
If the user is using it the cache keeps getting extended.
On the wcf services side,
Create APIs to return the token on authentication
All the wcf methods will have this session id which needs to be validated
The advantage is that the wcf methods can be exposed to return xml or json format and can also be used as normal web services.
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare, UriTemplate = "/MyModule/XML/GetData/{customerSessionId}")]
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "/MyModule/JSON/GetData/{customerSessionId}")]