i'm new to asp.net web api, owin, and everything related to it.
I'm trying to find the best way to do this scenario:
1 - Web api to have all the connections and rest service
2 - Web site to show data to user on a browser using the restful service
3 - An mobile app that have some functionalities like the web site and access the restful service to get all the information
My doubt is: what's the best practice related to the login? I'll use owin/oath2 with Identity to login, but since it's going to be implemented on the web api, the login/register/forgot password should be on the web api directly (like the project template does) or should i move most of the functionality to the web site? Of course its easier to leave in the web api, but if i do it, i must duplicate my razor templates just to call the login part. Can someone give me a path to follow?
Thanks!
the answer is not, your web api should not have any html or js or css file, only the services that your need, the web api exposes the functions to register the user, next when you have to do request, you must Send a token, you can obtain the token using the URL that you have configure in owin, the URL is like /token and Send the username and pass.
Regards,
Related
or must it be on the same server as the app calling it? I am new to web api so i am going through some tutorials, but they all assume the web api is part of the mvc app. Also, they show the calls to the api being done with javascript, but I want to make the calls in my MVC app controller. Is this possible?
You can host a Web API anywhere.
The only special thing to have into account when the Web API isn't in the same server that a web site that uses it, is that, by default, the Web API doesn't accept requests from a different domain. For example, if the web site is in "server1.com" and the Web API in "server2.com", then the calls to the Web API from the web server will be rejected.
If this is the case, you need to configure the Web API server to enable CORS (cross origin resource sharing), so that it accepts requests from a different domain. If you want more info about this, please look at this document:
Enabling Cross-Origin Requests in ASP.NET Web API 2
The Web Api can live wherever you want it to. Is typical to see a limited API used mostly to handle AJAX for the MVC application live with the MVC application, mostly because it makes it simpler to construct URLs to the endpoints. If you host the Web Api externally, then you'll have to hardcode the API endpoint URLs, as there's no way to use something like Url.Action to generate them automatically, any more. Regardless, it's a perfectly acceptable way to handle things.
You will probably at least want to add the base URL for the Web Api as an app setting in your Web.config, though. That way, you don't end up with hardcoded references to a particular domain strewn all about your app. That makes moving your Web Api to a different domain much easier, especially when talking about going from development to production.
It is also entirely possible to use a Web Api within your actual controller actions. You'll just need to use something like HttpClient to connect to it and issue requests.
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.
These are Application Types and Scenarios that Azure AD supports:
Web Browser to Web Application
Native Application to Web API
Web Application to Web API
Daemon or Server Application to Web API
I have two questions:
I would like to understand where my scenario below fits.
I think I need to use JWT tokens and it seems that Native Application to Web API is the closest,
but I still need Asp.Net MVC application to deliver Client side Angular MVC resources (html templates, controllers and Rest services)
Which Azure Active Directory Code Samples are the closest to my scenario below:
I would like to create a multi-tenant Angularjs (delivered using Asp.Net MVC 5) and Rest Web API 2 secured with Azure AD. I would like to have tenants choose their domain names like firstTenant.com,
smt.firstTenant.com or to have subdomains like firstTenant.MySaaS.com, secondTenant.MySaaS.com
or MySaaS.com/firstTenant, MySaaS.com/secondTenant or similar domain naming scheme.
I would use some kind of IoC container to add customization to my SaaS application or similar to deliver specific functionality to each tenant (GUI and business logic and DB).
I would use and Asp.Net MVC application that will custom tailor SPA resources (html templates, .js controllers, .js services, .css, images etc) to each tenant and use some partitioning techniquest to retrieve tenant and user specific content from DB called from Rest API controllers.
Thanks,
Rad
I am also facing the same 'i dont know' issue :)
But far as i have researched the authorization flow from SPA aplication to the web api.
You still need webserver(mvc) project that will privide redirecting to the Identity provider (azure AD) login page and on the IP callback you will need to inject baerer token to Angular auth service that will send token to the api or deal with the refresh token.
So for me I think that, Web Application to Web API, is the right direction programming.
pls comment if i'm wrong
Currently i'm investigating link
http://code.msdn.microsoft.com/windowsazure/MyCompany-demo-applications-eedab900
update 2:
http://www.cloudidentity.com/blog/2014/04/22/AUTHENTICATION-PROTOCOLS-WEB-UX-AND-WEB-API/
Maybe it will be helpful to us.
I have two servers - web and app. The web server (IIS) serves only static files - HTML/CSS/JS. On executing the JS, the client gets the data from the app server (HTTP service using Web API, self hosted with OWIN). I need to bring in authentication so that my data as well as the content is restricted.
I can use SSL, I can pass username / password to the web api, have it authenticated and get back a token. I can pass this token for future web api requests. In my client app javascript (done using AngularJS), I can also maintain info whether the user is authenticated, what roles she has etc. (for user experience). But for security, I need to be able to ensure the html content requested (in the web server) is also having authentication and authorization done. How can I achieve this?
Should I change my app to make the web server call the app server internally rather than from the client? I can use MVC controllers or ASP.NET, but since I was using AngularJS, I thought it is not required, and is kind of a duplicate. Should I ditch pure .html files and move to .cshtml?
How is this done in the Angular + .NET world, when you data comes from a different server than your htmls?
We've been using JSONP with REST type api to do cross domain AJAX calls, but our Angular client code is within .cshtml files in a .NET project. Sounds like the simplest solution is to use the app server internally- I would go with that
I'm developing a service that has two components - a web interface and a REST API. I use ASP.NET MVC and ASP.NET Web API, respectively. The two components are hosted on different subdomains of the same domain.
I want the REST API to be used by both external users and the web interface, and I want to simplify authentication as much as possible.
The REST API currently only supports basic authentication.
The web interface uses forms authentication and thus generates an ASPXAUTH cookie. The web interface interacts with the REST API using AJAX calls.
My question to the community is:
How do I authenticate the AJAX calls from the web interface to the
REST API, using the most elegant and secure method?
Some ideas:
Send the ASPXAUTH cookie in the ajax calls (by changing the cookie domain to ".myservice.com" to allow cross-subdomain read) and adding an authentication method in the API that reads the ASPXAUTH. Not sure if this is a great idea, or how to implement this.
Storing the user name and API key in separate cookies. Not really safe unless the values are encrypted/hashed.
Using OAuth in the web interface and rest api, instead of forms + basic authentication?
Ok, I've come up with the following solution:
I've added form authentication to the REST API and made sure not to use IsolateApps in the <machinekey>section of machine.config. This ensures that the REST API can use the same ASPXAUTH cookie. I'm making sure to fall back to basic authentication if no ASPXAUTH cookie is present.
Since there's no way to include the ASPXAUTH cookie in ajax requests to a different subdomain due to the Same-origin policy (even though the cookie's domain is ".myservice.com"), the solution I chose was to add an application (through IIS) to the web interface with the name "api".
The ajax calls now point to "/app.myservice.com/api/..." instead of "https://api.myservice.com/...", and the ASPXAUTH cookie is included and works.
Not sure if this is the best solution, but it's both clean and secure. Only tweak is the sharing of machine keys. If running in a web farm you would need to set the same machine key to all machines.