We're building a Windows-authenticated ASP.NET MVC app. This will then call into an ASP.NET WebAPI layer sat on a different server.
We don't have Kerberos enabled so assume authentication with this will be via some form of Basic auth. We're also looking to use ASP.NET Membership/Identity for role management. All communication with the Membership database will be via the WebAPI.
Can anyone give guidance on how best to handle issuing authentication tokens for communication between the MVC and WebAPI apps, and how Authorize attributes may be used across both layers?
I've blogged detailed series of posts about Token based authentication in Web API using ASP.NET Identity, it should answer part of your questions, check it here
Related
I am going to create an web app using Dot Net Core. In future, i will also create mobile application for the same application. Now, i am in thinking the architecture of the project. I want to use WEB API core using Asp.net Identity Core. Also, i will consume WEB API in MVC Core application. But the question i have in mind that how i can handle ASP.net identity with MVC and WEB API? Do i need to include in MVC as well or only in WEB API?
I tried to think hard but still confuse. Need suggestions.
You can use token based authentication .
In a resource owner flow scenario , your client app( mvc application/native application) will consume your web api by providing user's credential , web api will validate the credential(using ASP.NET Core Identity) in database , If the username and password are correct then a JWT authentication token and the user details are returned. Your client app could validate the token and sign in user :
ASP.NET Core 2.2 - JWT Authentication Tutorial with Example API
Tutorial built with
Token Authentication in ASP.NET Core 2.0 - A Complete Guide
In addition, IdentityServer4 is a good choice when you want to roll your own full-fledged OpenID Connect authorization server that can handle complex use cases like federation and single sign-on.
So your question is maybe a bit open-ended for Stackoverflow and you don't really show what you have tried so far.
I will try to answer though. First you just need to start out with a template for your project. Start an MVC project in which you can easily have API endpoints as well. I would suggest splitting those in two projects for clarity - but if it is just a small personal project then you probably are fine having them in the same project. Microsoft have a pretty good resource on MVC:
Microsoft MVC walkthrough
For the Identity part. You would need some kind of authority for it to work. I suggest you take a look at IdentityServer4. Which offers an excellent walk-through of how to set it up and how to integrate it with Asp.NET Core Identity:
IdentityServer4
I am building an AngularJS MVC application, I need some guidance in terms of authentication. I am thinking of building the Authentication using the MVC authentication pipeline. AngularJS code will reside in the MVC application and the root SPA view would be a Razor cshtml. Here is my scenario -
Login page will call a Authenticate API that would return a token
AngularJS has the logic to get the bearer and pass to each of the API requests
There will be multiple ASP.NET WebAPI projects that will be hosted as subdomains.
I also need to call complex dynamic razor templates, this would need the authentication for the MVC controller that will return the razor views. Since MVC follows cookie based authentication, the token gives a 401 status code. How would this work wherein the authentication is shared between MVC and WEB API apps.
I think you would need to get your token from the API project, not the MVC in order to be able to securely call the API.
If you want to share identities across both the API and MVC projects, have them use the same database.
When getting the token from the API, you can get the identity details of the current user from your MVC application. At least, that is how I have done it in the past.
I blogged something along these lines here: http://blogs.msdn.com/b/martinkearn/archive/2015/03/25/securing-and-working-securely-with-web-api.aspx however this does not cover the step of using the creds from your MVC login and passing that to the API to get the token.
Hope that helps.
We are going to start a new solution for both "desktop/mobile responsive web site" and "mobile app". Both projects (web site and mobile app) need to access same business/data layer.
The tier structure for web site is going to be something like the following:
Browser -> ASP.NET MVC Web Site -> Business Layer -> Data Layer -> Database
The tier structure for mobile app is going to be as follows:
Smart Device -> ASP.NET Web Api Service layer -> Business Layer -> Data Layer -> Database
We don't want web site to consume web api.
We also don't need to integrate with any social identity in our scenario. I heard that ASP.NET MVC discourages token approach for security (authentication and authorization) and encourages the cookie approach. However, consuming Web Api will be lot easier, if we employe token approach and cookies are obviously discouraged in REST services.
While we are fine to start with new ASP.NET Identity system, we are not quite sure on how to deal with both scenarios without rewriting and supporting code for both scenarios.
Based on the above grounds, how can we design a common security pattern which works for both of our scenarios i.e., ASP.NET MVC Web site and ASP.NET Web API.
If you self-host using OWIN, you can look at creating an OWIN middleware. If you web-host using IIS, you can create an Http module to authenticate and establish the identity by handling authenticate event. Http module can be written in such a way to look for a token and if not present, fall back to cookie. By cookie approach with MVC, I believe you mean Forms Authentication. With that, FormsAuthenticationModule comes into play. So, your module just need to be aware of this and play along nicely. Ultimately, identity is established on Http context and you can use Authorize attribute in both MVC and API controllers. Here is an example of how to create an Http module for authentication. Basic authentication is implemented here but you can modify it for tokens.
I am building a website using ASP.NET MVC 3 and have forms authetication setup correctly (user is able to register and login). I want to setup an OData WCF Data Services service so a Windows Phone 7 (Mango Beta 2 Refresh) client can authenticate and query the Odata service, with CRUD actions. This idea comes from the FullStack episodes here. They use OAuth login, but I wanted to use the user setup I already have, instead of an OAuth solution.
I do have this all working without auth currently (MVC app with Odata client on wp7), but am looking to make the Odata service secure. I guess I am looking for some articles or walkthroughs on how to get this working.
If forms authentication is not the correct choice, please let me know.
UPDATE
So lots of research done on this. There is an official how-to series on the blog for the WCF team here. Since forms auth is already configured on the web app, adding a check inside the QueryInterceptor provides the auth. However it uses a 'standard authentication endpoint' for client apps to actually 'login' that seems to use the base Membership providers, which I don't use. Is there a way to override this?
You could turn your custom forms authentication setup into a Claims based Federated Authentication Provider (STS) using Windows Identity Foundation. Then use that to authenticate your wp7 app with the STS provider and then send that claim (token) to your Odata service which will verify its an authentic claim. There is an example of this in the WIF training kit
May be my question is crazy.
1) ASP.net MVC is stateless, so there is no session involved in here.
How does the authentication module work and do you have any articles which you can point me to understand the Authentication basics.
What are the authentication information stored in.
[Novice MVC]
The web is stateless. Both ASP.NET and ASP.NET MVC have mechanisms for creating an application state. Advocates of MVC like that it provides the developer with more control over how state is managed and how requests affect the managed state than Web Forms. Web Forms encapsulates state with ViewState which is not part of MVC. The MVC pattern allows you to control every action (including managing the application state) on a much more granular level. This is probably where you got the idea that MVC is stateless.
As a side note, you should favor using the TempDataDictionary over HttpSessionState for storing state-related data, because the default implementation the TempDataProvider is a wrapper of the HttpSessionState). The pattern is a little different but a good article can be found at http://www.gregshackles.com/2010/07/asp-net-mvc-do-you-know-where-your-tempdata-is/
ASP.NET (and MVC) authentication usually works by leveraging Forms Authentication. It can be configured in your web.config. ASP.NET Authentication Configuration.
If your client's browser supports cookies, the default behavior is for your authentication ticket to be stored in a cookie.
Who told you ASP.net MVC was stateless? In any case, authentication info is usually stored in an encrypted cookie. It's exactly the same as webforms in this regard.
UPDATE
Regarding ASP.NET MVC, see here for plenty to get you started: http://www.asp.net/mvc
For ASP.NET forms authentication, see MSDN
Technically, you could go stateless if you sent HTTP header authorization with every request.