We are starting a project which will consist in:
Web project (ASP.NET MVC)
IOS app
and both will consume data from a .NET WEB API service.
The WEB API service will expose a POST Method with the url "user/create". But i don't know how can i avoid another apps for making post to this url? I know i need a security protocol, but i wanted to know which one you recommend me, and if you have, an article where is it explained.
Thanks
web api 2 provides oauth authentication. You will need to get a token from the token end point of web api and pass that token in subsequent requests.
You should find lot of online resources if you search for web api 2 oauth.
We did something similar recently using OWIN OAuth 2.0 Authorization Server
Reference this ASP.NET page for details. Sample code is included as well for several different implementations.
For our purposes, we used the Client Credentials Grant section about half-way down the page. Our implementation involved server-server OAuth (Web API to MVC), but I bet it's pretty similar to have iOS connect. The only thing I would caution is to somehow encrypt the login credentials on the iOS side, and I'm sure there is a way to do that.
So you want the WebAPI to only be used by the MVC page? The best architectural method is to separate the two rather than leave both in one project. Why? Because the MVC app is a experience layer for humans. The WebAPI is an experience layer for the MVC app. Move it back where it can't be accessed.
You can add on tokens, etc, but the MVC app sits on the server, but is accessed on the client computer. The wider the scope of the application (ie, intranet or internet or something in between?), the more difficult the problem and the harder it is for your users to access the application. Moving the WebAPI internal and leaving the MVC app exposed guarantees external users cannot use the API.
The main reason WebAPI and MVC exist together in a single project (still a mistake in most instances, IMO) is you are exposing both to the same audience. If that is not your intent, don't do it.
Related
I am developing a solution using .NET ASP Core. It's current version is monolithic, and I want to switch it to a service architecture consisting of an HTTP API which is used by the iOS/Android apps and web site. Here is a visual:
I am using .NET ASP Core on the website and service layers. I have almost finished implementing the changes, but I'm hung up on how to handle authentication on the area of the website that allows administrators to edit the content of the system. The monolithic version uses Identity Core (custom implementation, not using Entity) which works great. I could move the identity authentication code into the service, but I'm not sure how to then handle the authentication on the web site (the apps are public content only, no auth needed). How do I pass the username/password from the website to the service? How do I then track the session between the end user and service layer? Or is another option like OAUTH make more sense? I'd prefer a solution that doesn't require me to implement duplicate roles/policies on the website and service.
Any suggestions welcome, I have no experience with a setup like this so I'm not really even sure where to begin. Thanks!
OpenID Connect or OAuth makes sense because all of the claims/roles you already have will be encapsulated into the token. I presently use IdentityServer4 and it works just fine for your exact situation.
Since you are already using Identity database implementation doesn't matter as long as you have a back end. In the end the calls to the site are till http in nature, all very well documented.
http://www.identityserver.io
I currently have a web api 2 project acting as my applications middle tier. I need to secure this project as well as provide an authentication service for my MVC project and potentially iOS and Android applications.
The web api business logic requires the checking of the user permissions/roles to ensure security, the mvc project requires the same functionally to ensure the request to the controllers are valid. How do I do this using Asp.net Identity or some other means? Are there any reference projects for this sort of thing?
Some good info here:
http://www.asp.net/web-api/overview/security/authentication-filters
Another way I've seen it done is have a separate API to generate access tokens for a 'transaction' using whatever credentials you want to use...but usually done via https! This token is then passed by the client to the business layer API as a parameter. Various checks can be carried out on the token e.g. Same client that requested token? Token expired? Token already used? Etc
Let me know how you got on.
Thanks.
UPDATE
Web API Security with local accounts:
http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
As a warning, I am very new to ASP.NET Identity. I have a project I am working on, and am trying to create different projects to better organize it. I have my UI layer, which is an MVC5 project, and my WebAPI, which is the API that will get called to perform various actions.
I want to use ASP.NET Identity 2.0 to authenticate and authorize actions in both projects. What is the proper way to do this?
I have two projects in the same solution. Let's say that I run debugging for both of the projects, I want to test being able to authenticate in the UI, then try and access a protected API call and see if it works.
However, if the Identity information is configured in the UI (using the default template), how do I make sure the API properly authenticates users?
One approach is to perform all user actions via the Web API, including authentication and authorization, as well as other Identity-related tasks such as registering and confirming new user accounts. This way, your presentation layer (whether it is a web, desktop or mobile application) will be responsible only for interacting with your API and presenting the data (as it supposed to be).
Check out this series of blog posts that demonstrate how to implement this approach using ASP.NET Web API and AngularJS.
I currently have a MVC application that is using Forms Authentication. I realize that you cannot self host a MVC application. Business requirements dictate that my application has to be self hosted. I was thinking of creating either a WCF or Web API application that is self hosted, where I can expose various endpoints. However, the problem I am facing has to do with authentication. In my MVC, I used Forms Auth, and allowed the user to use a form to enter credentials. How can I do something similar in WCF or Web API. I know how to render the HTML for the login page, etc, but the part that I am not familiar with is how to code up the smarts that anyone who tries to access one of my endpoints needs to be redirected to another service, so that I can do my thing to authenticate them.
I guess I'm trying to do something similar to the Forms Authentication redirect, but, within the context of WCF or Web API. I started looking into message interceptors and route filters, but, still need to do some research.
Any ideas to point me in the right direction ?
Forms Authentication Control Flow is explained here. This is what you need to implement using a DelegatingHandler for ASP.NET Web API.
Good old Microsoft documentation at it's finest. Does anyone know of any resources that explains how to deploy Web Api with Asp.net Web Forms application. I have the web api in a separate class library and I call using jquery. I don't want anonymous users to be able to access this service only the application. Do I want to use self hosted? How do I lock the service down? Awesome examples showing how to use, tons of videos but nothing on deployment.
You don't have the right architecture for what you are describing, but what you have is right.
If you are calling web services from the client side (using jquery) then your web service must be public facing.
What you are describing is a web or WCF service in a service oriented architecture. That service would most likely live on a different server and be on an internal network, etc. Even if it's on the same server your requirement is that it is not publicly accessible - thus none of your jquery would work since that request is being initiated by the user and users can only make requests to public facing services.
The comments about using forms authentication to protect your service calls are right. jQuery will include the forms authentication cookie for you when it makes AJAX calls so you shouldn't have to change much on the client side.