I have an existing MVC application that I inherited from someone else.
I am now trying to take some of the API calls from the old application and move them into a new application.
The problem is, when the MVC application tries to call the API calls in the new application, it gets a 401.2 (unauthorised) response.
I have read that 401.2 means that the front end and the back end are using different authentication protocols, which would make sense to me.
Here is a snip of the response headers for the account call in the new application:
and here is a snip of the same response headers when calling the same API from the old application:
This looks to me like they are using different protocols - am I correct? The main difference seems to be the 'WWW-Authenticate:Negotiate' on the failed request - but I do not know how I can fix this?
If so, can anyone advise what I need to change in my MVC project to make it use the Auth type of the first project?
Both aps use the same database if that is any help?
I know this question is a bit vague, but I have no idea where to look to fix this.
Any help would be greatly appreciated...
You would need a Single Sign-on to maintain your credentials through different apps, you could:
Use Identity Server 4 or Identity Server 3 To generate token credentials for you WEB API Projects.
MVC
JS
User Forms authentication on your mvc Projects:
Example
Use cookie based Authorization:
Cookie authorization with OWIN
I recommend Using Identity Server.
Related
I have an existing CRM built in ASP.NET MVC 5 using a razorhtml front end. I would like to break off part of the project into an Angular front end with .Net Core web api backend.
Essentially when a customer hits a "next" button on a certain page, the web api would be called and return a page in angular. The customer then completes a couple pages in the angular front end, sends info to the DB via the web api, which then returns the user to the old MVC project.
The issue I'm worried about is security. How can I authenticate the customer between the two applications?
Assuming your WebAPI is hosted on the same domain as your existing MVC solution you could opt for good old cookies (mind the HttpOnly and Path properties though). Given difference in technologies this might require some sort of reverse proxying to be put in place.
Alternatively you can generate a token on MVC application side and make your angular app pass it along through request headers to your API. On server side you would either write a custom middleware to handle opaque tokens or leverage existing .Net Core Identity that supports JWT out of the box.
Given you didn't share any specifics of your environment - it's hard to say if JWT would be an overkill for your use case but hopefully this gives you some context for further exploration.
I am working on an existing ASP.NET MVC 5.2.7 project and now trying to build a mobile application around it. For this purpose I introduced a new ApiController class to handle all logic needed by the mobile app. My intention was initially to just use the same login method which is used by the MVC part of the project which turned out not to be working as expected (the login succeeds but on further requests, the application returns the default Login page). So now my approach would be to use Token authorization for just one ApiController. Did anyone ever have a similar scenario and could help me out with an example on how to do so, maybe?
I'm guessing I could keep my currently working login method and just return some kind of token which is then kept by the client to be sent with all further requests.
Any help is appreciated. Thanks in advance.
I am trying to develop a single page application.
I have built a RESTful web service using ASP.NET Web API. I have implemented authentication using OAuth 2.0 and Bearer access tokens.
This web service uses memcached and HTTP cache headers (Cache-Control and ETag) for caching the resources and responses.
Now, I really like ASP.NET MVC technology and maybe that love is making me use it when I shouldn't.
I'm thinking of builidng an MVC intermediate server between my JavaScript application and my Web service.
The MVC site would redirect (or delegate) its requests, to the Web Service.
I see many advantages using this approach:
I can store my consumer key (used for authentication) in a secure location, as opposed to storing it in the JavaScript application directly.
I can provide cookies to my JavaScript application, something that my REST web service does not support (because I think it ruins the whole "stateless" and "Pure HTTP" concept.
It would be very easy for me to provide globalization (localization) to my views. I really like ASP.NET MVC globalization framework and I would not know how to add this feature if I plan to create a standalone site.
I can encrypt my access token cookie, and decrypt it on the server, forcing my user to use my MVC proxy to access the web service, as he will not know his access token.
Having stated these advantages, would it be worth it to implement this?
Adding a proxy server will made me replicate the HTTP cache logic, and will also end up creating 2 requests (Client -> MVC -> Web API) instead of 1 (Client -> Web API).
What is the best approach?
It looks like you've built a good RESTful web service, but need to address Auth and Globalization:
Auth
Having this kind of proxy or support cookie authentication on the Web API will make you vulnerable to CSRF attacks, so you would also need to implement Synchronizer Token Pattern or some other technique to prevent this. However you should only use this approach if you have no other options, but you have!
Assuming javascript application requires user to enter credentials, there are different ways to deal with auth for it:
OAuth2 Resource Owner Password Credentials Grant
JSON Web Tokens - see accompanying website and a specification
Both ways provide your JS app with an encrypted token that it should pass with each call to protected API. Your application would need to keep this token in a local storage and refresh it when token expires.
Globalization
Even having most of the things on MVC side, eventually you would still require Web API to deliver translated content. So I'm not sure what are the requirements here, but generally speaking you should be able to get your translated resources on Web API the same way. See here for example.
For the HTML part - leave it to ASP.NET MVC, no need to put every label translation into API.
Another points to consider
Performance - ASP.NET MVC is good, but it's not a proxy solution and it's simply not intended to build things like that
Do you really need an HTTP API?
Don't forget that transferring data over HTTP is another point of overhead, and it becomes especially useless if you proxy it with and MVC.
At the end of the day - why would you build an API if you are hiding it from your own application?
My answer is: don't hide it - make full use of it!
I have coded a C# MVC5 Internet application and I have a Web API 2 web service that returns JSON data. I am retrieving this JSON data in an android application.
How can I add a feature to the web service such that only my android application can retrieve the JSON data? I am wanting to do this so that other web users cannot hammer the url and the web service will not send my data to unwanted applications and/or users.
Is this possible? If so, how should I do this?
Thanks in advance.
You have various ways to achieve this in fact.
For example, you can store a key in your android application and use send this key together with the request to your WebAPI. Your webAPI will than check if they key is valid and if it is, it will return the JSon.
However, there's no way to ensure that nobody else can request and get your data. For example by reverse engineering your android application and extracting the key, or by monitoring the network traffic and find the key in there.
You need to understand that there isn't anthing that guarantuees you 100% security.
See it as the following:
You have an open door right now, you can close it little by little, but closing and locking down is not possible. There will always be gap. A house also can't by made burglar proof, but you can make it very hard for a buglar to enter.
Go to this link Web Api. I have used the individual authentication for my web api. When you will register the user the response you will get is access token and use that access token as Authentication header in your ajax call if you are using Jquery ajax to call your Web Api. Refer this The OAuth 2.0 Authorization Framework. Hope this help you.
Are you looking for something like this?
http://httpd.apache.org/docs/2.2/howto/access.html
If you have other web server, there should be appropriate means to support such.
Hey SO, in the past few hours I was trying to get my head around RESTful services that can be served via asp.net MVC. Authentication is still something that doesn't seem to be covered in all those tutorials and guides i was finding in the interwebs.
Currently we are using Forms Based Authentication in our existing MVC Application. As far as I understand we need to add Basic HTTP Authentication to be able to handle REST requests and user permissions connected to the user context. Is there any way to "mix" these two Authentication Modes in one Application?
I'm not sure if there's anything built in, but you can write your own. Something like:
var authHeader = Request.ServerVariables["HTTP_AUTHORIZATION"];
if (authHeader.StartsWith("Basic ", StringComparison.InvariantCultureIgnoreCase))
{
var authParams = Encoding.Default.GetString(Convert.FromBase64String(authHeader.Substring("Basic ".Length)));
var arr = authParams.Split(':');
var username = arr[0];
var password = arr[1];
}
If you're writing your own REST framework in MVC, you could have a base Controller class, and have a method similar to this that runs before each action to authenticate the caller.
Dave,
I understand your point. Membership framework uses cookie extensively for authentication. You pass your credentials to server, server validates them against user database and issue you an authentication cookie. Next time every call of urs contains this authentication cookie which server uses to authenticate and authorise the user. Now whole this workflow works seamlessly when you use browsers.
Now in your scenario, you can create an Action in a controller which validates credentials. You can pass credentials to this Action in either post/get data. You will have to save the authentication cookie in your code and include that each time when making a call to the server . You can override HttpWebRequest class to perform these steps and you can use same class in your code.
In case this is much of an overhead and you are looking for something like Web-Services sort of functionality, I will advice you to look into WCF Services / Ado.NET Data Services. These integrate with Membership framework more seamlessly and may be better suited to your results.
I hope this helps, thanks.
You can easily use ASP.NET membership framework with ASP.NET MVC RESTful services. See the following link for its implementation with MVC RESTful services.
http://msdn.microsoft.com/en-us/magazine/dd943053.aspx
In case you are not aware of membership framework use following link
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
I hope it helps, thanks