here's my setup:
I have an MVC3 site hosted with a www subdomain (e.g., www.example.com). My site is secured via SSL and forms authentication, backed by ASP.NET membership/role providers. I have HTTP handlers providing service capabilities under /services (e.g., www.example.com/services). These are secured through Basic authentication over SSL. I have mobile devices successfully accessing/consuming these services. I have also created a new site with an api subdomain (e.g., api.example.com) that will be my public-facing API. These services are exposed currently via WCF Web API preview 6 (eventually to be migrated to ASP.NET Web API). These services are also secured via Basic authentication over SSL. My ASP.NET membership implementation stores hashed passwords (i.e., they are not encrypted). All services serve JSON responses. All of this stuff works great.
Here's my dilemma:
I started to write a new view on the MVC site and realized it would be great to use Ajax. My specific case is to implement cascading drop-down lists. I wanted to implement this using jQuery and a new service under the api subdomain. At first I thought this would be a simple exercise and then I realized, I have no effective way to call into my own API. My clients (mobile devices) all store their username/passwords locally so this is easy. However, if the same user is logged into my site, I have their username but not their password so I do not have a direct way to access any services offered under the api subdomain.
As I see it, I have three solutions:
Implement services that support the MVC site directly under the /services URI, eschewing consuming my own public API.
Create a super user in my membership store (where I know the username/password) that the site uses to access services in the api subdomain.
Change my authentication strategy.
It occurs to me that I probably should not utilize my own public API and would be better served using my own private services (which is ok because the logic is all shared via a facade layer).
What is the recommended strategy here? I also assume that if I were to utilize option 2 or 3, I would have to do so using JSONP. Is this correct?
Any advice would be greatly appreciated. And if more details are needed, please post and I will update with answers.
Thanks!
If Im following this correctly, you simply need to make sure your Forms Auth cookie is written with no subdomain so it would be: .example.com and if you are using separate servers, you share your machine key across them.
Since forms auth tokens are stateless and nothing is kept on the server side, this should work fine.
For simplicity and because I decided it was not in my best interest to consume my own public API, I implemented JsonResult actions on a new controller in the existing MVC site. This allowed me to utilize the existing forms authentication and avoid the cross-domain ajax requests.
Related
I have two web apps in azure one angular 6 the other one is .net core web api. Angular app consumes the apis to get data. Some of these apis are public apis. It means authentication is not needed for them to be called.
My questions is, what the best approaches are to protect these public apis? By protecting, I mean not letting anonymous users to call these apis and abuse data.
In my mind these are what I can do:
CORS, but the problem is postman and other rest tool still can call my apis
Using azure api management? By rate limiting? Is there a better way?
Use some sort of api key but the angular app will expose them anyway.
In my c# app I get user agent, host, Origin of the call and restrict based on those?
Basically I want to restrict anonymous user from manipulating and calling my post apis and push not relevant or duplicate data to my back-end without using any sort of AD as my apis are going to be public. I want only a few authorized app can call my apis.
Please tell me which one of the above are the right one and please recommend a better approach.
P.S: my backend is .net core 2.2,
Thanks
I can recommend below solution,
Host your APIs on Azure API app and import it to APIM. Then Configure IP restriction on API APP using the IPs of APIM. That mean, only APIM can access your API host. or you can implement client certification authentication between APIM and API host.
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates
02.Next enable subscription key/API key on APIM and keep these key on Azure key vault. So you don't need to hard code these keys on frontend. I hope you host this Angular app on Azure. (I am not Angular expert...just check online for docs)
https://learn.microsoft.com/en-us/azure/key-vault/quick-create-node
03.Later based on your scenario, If need you can apply Rate policies.
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/api-management/api-management-sample-flexible-throttling.md
My question is based on ASP.net 5 and authentication. In particular, I'm trying to achieve integrating oAuth (2.0) into my solution as my logon method (the users can either logon using oAuth if this is how they registered, or directly with my own app). Using the template for an ASP.net 5 web app, I've successfully achieved the above but this isn't quite what I need.
I'm have an ASP.net 5 MVC (app1) for my front end UI and an ASP.net 5 web api application (app2) for my REST services, serving data to the UI. Nothing new to this approach.
I want my MVC front end (app1) to have no Entity Framework references and no reference to things like Sign in manager (if possible). Just keeping it as simple as possible. I have a login screen and I want to present the option to logon via facebook or google oAuth accounts. Instead of using the nice code MS kindly provides out of the box when you start a new ASP.net 5 web app (hey, why make life easy!), I want to use my web api to do as much as the work as it can (I realise somethings need to happen in app1 to make this work).
My goal is to keep my UI as simple as possible and offloading complex functionality (business logic, database access and other things such as caching) off to the web api app.
I'm having difficulties extracting the parts of the web app demo around oAuth, and moving it into the web api, to utilise from app1. Has anyone managed to do this before? Is this a bad idea? Has anyone a sample of this approach in new ASP.net 5 MVC.
Thanks for advice in advance!
We (that is ASP.NET) recommend you look at Identity Server. v4 is now built on top of .NET core. The OAuth components you see in templates for facebook, twitter et al aren't suitable for using against a WebAPI, they're there for interactive, browser based logins, not for javascript.
You would have your interactive app handle registrations as normal, then use Identity Server to issue a bearer token, pointing it to your identity database, and validate that within your WebAPI.
We don't recommend rolling your own.
You can build a WebAPI app with membership manager using ASP.NET Identity. ASP.NET Membership is now called ASP.NET Identity.
From the link you will see how you can create a WebAPI app that will support all basic ASP.NET membership functionalities (log-in, register, etc).
Once you have WebAPI setup with your (custom) ASP.NET membership storage (DB is auto-generated once you run the app.), you are set up with a RESTful web layer with data access. You can also customize the storage provider. See here: Overview of Custom Storage Providers for ASP.NET Identity.
The ASP.NET website (www.asp.net) has all the necessary information sufficient to create all that you said from scratch. For integrations with Facebook or others, you can check out this link: External Authentication Services with ASP.NET Web API (C#)
I have 2 web sites that are published on the same server.The first one was built using web forms and the second one (The CRM) was built using MVC.
In the crm I have a web api controller that adds new order. The access to the controller is only granted for crms admins. Now I need to have the ability to call this controller and add new orer from the first site. I thought about couple of ways that it can be done and I can really use some help to decide what is the best option.
1.Create a wcf communication between them and wrap the controller this controller with intenal access only (From the same computer only)
2.Pass a pre defined token from first site to the crm.
3.Check in the crm controller if the request was made from the same server
4.Create using owin a self hosted web api in the crm , that listens to some localhost port.
5.Any other idea with explanation
Kind regards,
Tal Humy
If they're on the same server, is there an exposed API to the classes themselves? Can you reference your MVC project from your web forms code? Doing this would flatten the communication layer so you wouldn't use up networking resources unnecessarily.
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 a project which uses both Web Api and MVC. The authentication is handled by FormsAuthentication, which creates a cookie containing some data regarding the user.
I have extended System.Web.Mvc.AuthorizeAttribute and added it to every MVC controller. What it does is extend AuthorizeCore and check to content of the cookie, which is my own extension of IPrinciple, for wether the user currently has limited access.
I would like to do a similar check for calls to my Web Api, so i have made an extension for System.Web.Http.AuthorizeAttribute which overrides the IsAuthorized method.
In this method i would like to make the same check as for the controller, but i don't know how to get the information from the cookie or if this is even the proper way to do this.
In general using cookie authentication in web api is not recommended.
The reason is that cookies are handled well only in browsers The whole concept of web api is to allow other clients (native clients, java script ...) to use it as well.
If you sure that your server is going to be accessed from browser only maybe you should move your api actions to MVC project (it could return json / xml as well). This way you will not have to deal with those kind of issues.
For web api I would recommend using token based authentication