On IIS I have a login website which is used to get credentials from user and authenticate him. Authentication is done through:
FormsAuthentication.SetAuthCookie
Login application is written in asp.net webapplication.
Now there is another .NET CORE mvc web application which will sit as a child web application to this login website and needs to authenticate through login application.
By default child web application does not comes under login page.
How I can put this web application to use login from parent website?
HttpContext.User.Identity.IsAuthenticated in mvc core child application returns false and can't read logged in user.
You cannot. Traditional web-based auth and specifically FormsAuth utilizes cookies to persist the login state. Cookies are domain-bound, and auth cookies are also encrypted. You can only access the cookie in the first place if both apps are on the same domain, and even then, one can only read it if they can both encrypt and decrypt in the same way. The method of encryption has changed between ASP.NET and ASP.NET Core, so that's out of the window off the bat. ASP.NET used machine keys whereas ASP.NET Core utilizes the Data Protection API.
There's one minor exception, in an ASP.NET MVC 5 site, you can utilize the Data Protection API, through its support of OWIN. The two apps, then, can be made to encrypt/decrypt in the same way. However, by the very fact that you're using FormsAuth means that you cannot achieve this. FormsAuth can only use machine keys, so you'd have to migrate the legacy app to using ASP.NET Identity at the very least, first.
Related
I have an existing ASP.NET MVC 5 application that uses a custom authentication scheme and sessions for storing state using ASP.NET_SessionId cookie.
Now there is a requirement to put a React front-end in front of an ASP.NET Core Web API. There is an opportunity to reuse some of the service code from the API. The showstopper is the authentication.
Is it possible to reuse/share the existing cookie and authentication scheme from a React web application? JWT and IdentityServer appear to be solid options but would require a significant rewrite to the existing system.
As far as I know, if you want to share authentication cookies between ASP.NET 4.x and ASP.NET Core apps, you need to rebuild the asp.net core cookie authentication.
Since the asp.net core and asp.net use different way to encrypt the authentication cookie, so you should let them use the same way to encrypt the cookie to get the token work for both asp.net and asp.net core application and make sure there are in the same domain.
More details about how to set the application to share cookie between ASP.NET 4.x and ASP.NET Core apps I suggest you could refer to this MSFT example.
Some part of the document:
ASP.NET 4.x apps that use Katana Cookie Authentication Middleware can be configured to generate authentication cookies that are compatible with the ASP.NET Core Cookie Authentication Middleware. This allows upgrading a large site's individual apps in several steps while providing a smooth SSO experience across the site.
When an app uses Katana Cookie Authentication Middleware, it calls UseCookieAuthentication in the project's Startup.Auth.cs file. ASP.NET 4.x web app projects created with Visual Studio 2013 and later use the Katana Cookie Authentication Middleware by default. Although UseCookieAuthentication is obsolete and unsupported for ASP.NET Core apps, calling UseCookieAuthentication in an ASP.NET 4.x app that uses Katana Cookie Authentication Middleware is valid.
Katana Cookie Authentication can be used to reuse cookie among app. For more detail please find the documentation for Share Authentication Cookie among app
I have read all the stack overflow posts and other blogs regarding mixed-mode authentication. I could not find a step by step implementation anywhere.
So here is my scenario. I have developed asp.net MVC 4.5 and asp.net identity 2.0 for individual user accounts. Some of our clients use active directory to authenticate their users whereas others use individual user accounts. Also, those that use active Directory can also remotely access the web portal and in that case authentication would be from database(Form Authentication/individual user account authentication).
My findings so far
create another web application. If this client does not use "active Directory", then redirect to login screen, else, authenticate from active directory (but how?)
Some of the links show that there is no need to create another web application like
Mixed mode authentication with OWIN
ASP.NET Identity + Windows Authentication (Mix mode - Forms + Windows)
ASP.NET MVC and mixed mode authentication
Truly confused as to what to do and how to do..most solutions seem vague and general
There's no need to create a second web application.
Owin is designed to let you use all available providers (such as, Windows authentication and form-based authentication) given that you enable them in IIS.
Briefly, you have to
Enable Anonymous and Windows authentication on IIS - Authentication
(with server or site scope as it best fits to you)
Anonymous authentication - Edit - Use Application Pool Identity
I recently implemented just this kind of authentication on an MVC project and it works like a charm. I suggest you to read this post https://github.com/MohammadYounes/MVC5-MixedAuth it's been really helpful to me.
I have ASP.NET MVC and Angular2 application and I'm using Identity Server 3. Typical workflow for user is to log on MVC application which stores obtained token in a cookie.
After successful login, user can use angular2 application for specific operations and it resides on subdomain. Angular application "talks" to web api.
Is it possible to share access token stored in a cookie between mvc and angular (javascript) client. Currently, I'm extracting access token and store it in local storage for using in ng2. It is working, but in my opinion this is not elegant solution
You can implement Direct Authentication in Angular and use SSO.
User will be logged in to ASP.NET MVC, the Angular will hit the identityserver and will returns the token.
You can use the OIDC.JS library to implement implicit flow in Angular.
We have a multiple applications under one domain, and every application is built in asp.net mvc. Currently single sign on is facilitated using forms authentication, shared machine key. All applications are on same server for now.
For one our new application we considering asp.net core with framework option. We have an Accounts application which handles authentication(login/logout) for existing application. And we have build STS, using Identity Server3 into the same application.
www.mydomain/Accounts
www.mydomain/app1
www.mydomain/app2
www.mydomain/asp.netcoreApp1
The new test asp.net core application(client) using openIdConnect communicates with STS, Identity Server3 and is working fine.
Challenge: Have to facilitate single sign on between existing applications, which uses Forms Authentication, and new Asp.Net Core.
Operational/Environment Facts:
All applications are on same machine.
Access to machine key.
On navigation from app1 to asp.net core cookies are available in Request header.
Problem Scenarios:
If user successfully logins to app1 and navigates to asp.net core the user has to logon again for authorized access. No issue with anonymous access.
Similar to #1 vice versa case.
If user logout in any one of the application then user should be log out from all the applications.
Since test application built using Asp.net core with framework option, will FormsAuthentication be compatible? direct me to documentation or code snippet?
Please share your ideas.
I have a single page app that uses a standard Controller (not ApiController) for retrieving all HTML views, which is done via ajax. However, WebApi is utilized using breezejs for the client to talk to the backend database. I am implementing ASP.NET identity security - should I use MVC cookie authentication or bearer token? I need the solution to illustrate a separate login page, and need a clean server side redirect.
Disclaimer
This is a relatively trivial question because it is very specific and by understanding the difference in authentication between Web API and MVC Controllers this should be fairly straight forward.
Assumptions
Your Web API Project has it's own authentication and does not talk to the MVC project to get a session user or anything
Your ASP.NET MVC Controllers are in a project using forms authentication and storing the user in a session cookie.
When I reference MVC below you undertand these are referencing ASP.NET MVC
Recommendation
What I would do is have your MVC project use OAuth for authentication and store the user in a cookie in the session that you can set and get. Then your controller actions that serve views can be decorated with the Authorize attribute. This will redirect users to the login page when they try to access a view they are not allowed to (as long as that is set up in your web.config
For the Web API Project you can't rely on Session because it sounds like you are decoupling the two projects. This is my recommendation -
When your user is successfully authenticated in your MVC Project make a request to the Web API to an open log in method. This would do some logical test and then either store the user in the DB with a session token of some sort or automatically write the user to the DB.
Now your user that is stored in session in your MVC project you can pass that down to the client and append it to the Breeze calls to your Web API and use that for authentication. You will need to explicitly set up how long that token is for and such but it is pretty easy to append this to the Breeze.js call like such -
var query = breeze.EntityQuery.from('myService').withParameters({'tokenId': thisTokenId});
Now your queries will hit the API with a tokenId parameter that it can use for authentication.
Edit
If you want to set up your ASP.NET MVC Project to use OAuth you can following along with this link -
http://www.asp.net/mvc/tutorials/security/using-oauth-providers-with-mvc
Remember that forms based authentication just means (in a nutshell) that you will provide the user some way of logging in with a form of some sort.