How to implement form authentication with MVC 5 and azure autoscalling - azure

I have developed an application in MVC 5 which has form authentication. Now I am using azure autoscalling on the application. Form authentication is working fine when I use single instance but when I use autoscalling, form authentication stops working (user is not getting authenticated). I tried to give same machine key on all the instances but no success.
Any idea what changes I need to do in order to make form authentication working with azure autoscalling?

I am assuming, you must be using SQL server for the membership features. If Yes , then did you scale the SQL database too.
Also Have you added the application insight or some kind of logging in your application.
can you check the logs that which DB or source you are using to authenticate? Also if you find the source , can you run the query if your user is available in the DB or not?

Related

How to add Azure Authentication to my current web application which is using API as well?

So my project has got a two asp.net projects. One is for showing date(User Interface) and the another one is API(for background processes like login, database calls and etc.). Right now my app has Username and Password feature to login. I have setup a startup class in my API which authenticates the user and pass the user token. Now I want to add a feature to login through Azure portal.
Can anyone suggest me a good practice in this situation? Like I don't want to change my code and just add a feature. Should I make changes in API or Web or Both? Meanwhile I was reading about expose api in app registration. Will it be appropriate to use it just for login purposes?
Azure AD supports OAuth2, OIDC and SAML. See more information here. It is probably best to introduce the mechanism through the API first, since it would apply to the frontend as well (though slight modifications may be required there as well).

Share ASP.NET Core data protection between applications without breaking existing cookies and tokens

We are using ASP.NET Core Data Protection in combination with ASP.NET Identity with Cookie Authentication in an ASP.NET Core web application. We also send Reset-Password links using ASP.NET Core Identity which uses the data protection keys for that. We persist the data protection keys in our database using entity framework. By storing the keys in the database, we don't have any issues when swapping deployment slots in Azure.
services
.AddDataProtection()
.PersistKeysToDbContext<KeysContext>();
This all works as expected and we are running in production for several years already.
We now have a new feature, where the user can delay the sending of invitation links for new users. These generated invitation links use the ResetPassword token provider from ASP.NET Identity. We are using an Azure Function for that, where the invitation links are generated and sent in the Azure Function at a later point in time.
var token = await this.userManager.GeneratePasswordResetTokenAsync(user);
The problem now is, that the Azure Function needs to use the same data protection keys as the web application, since the generated ResetPassword tokens are later "consumed" and verified in the web application. This can be done using the ApplicationDescriminator when configuring the data protection. Every application (i.e our web application and our Azure Function) need to use the same ApplicationDescriminator:
services
.AddDataProtection(o => o.ApplicationDiscriminator = "Our-Application-Name")
.PersistKeysToDbContext<KeysContext>();
But when we now set the ApplicationDescriminator in our existing and running web application initially to "Our-Application-Name", all our already sent tokens (Invitations, Reset Password, Change Email, ...) will get invalid and also our ASP.NET Core Identity Cookie will get invalid and all users will get logged out.
Is there any way of telling the Azure Function to use the same data protection keys as the web application without changing or breaking the existing tokens in the web application?
We found a pretty hacky solution to not break the existing tokens and cookies in the web application: Instead of specifying the ApplicationDiscriminator in the web application and in the Azure Function explicitly, we specify the ApplicationDescriminator only in the Azure Function and set it to "D:\home\site\wwwroot".
This value is the default value in the web application when not specifying any value, since the default implementation in the ASP.NET Core data protection uses the HostingApplicationDiscriminator which uses the IHostEnvironment.ContentRootPath property. For an Azure deployment, this ContentRootPath is set to "D:\home\site\wwwroot" by default.
We are not very happy with this approach, since this seems like a hack, but it's still better than breaking all tokens and cookies by specifying the ApplicationDescriminator explicitly.

Azure AD Login/logout implementation for Spring cloud microservices

I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.

Can we use Asp.net Identity API in windows/desktop applications as well?

I have a project which has a asp.net mvc based portal which manages user authentication/authorization using Asp.net Identity API.
The project also consists of a windows service/EXE which would poll an MSMSQ queue to get new users information and would save them into the Asp.net Identity Database(used by web project mentioned above).
so my question is - "Can we use Asp.net Identity API in desktop applications too?". The requirement only arises, because user's password hash has to be created, and I am using the default one which is provided by .net framework. So if I am creating a new user into the Asp.net Identity database, then I would need to create the password hash there too.
Any ideas guys?
Identity does not take dependency directly on MVC, but it relies on OWIN to set the cookie and authentication. But if you need to check user password against stored hash, manipulate user records, etc. Why not?
You might experience a big pile of dependent packages (ASP.Net) added to your desktop project, but if you don't mind this - there is a possibility you can make it work.
On the other hand, there is Identity Server which can work with MVC project and with Desktop project - without having to add Identity directly into your desktop application - also have a look into that.

Safe to authenticate with ASP.NET MVC 3 site from Windows application?

I have a basic ASP.NET MVC 3 site using Forms authentication, which will be internet-facing.
I also want to implement a Windows application, purely for intranet usage, which will allow users to maintain various aspects of the ASP.NET user database (it has additional tables and fields beyond the stock schema).
My initial thoughts are that I could do this by having various actions in my controller classes, into which I could pass a dedicated username/password and then within each action method validate those credentials using Membership.ValidateUser() .
I realise I could use mixed-mode authentication with Windows authentication for the intranet part but this seems to me like a lot of unnecessary faffing since the intranet users won't be using a browser to do this.
The Windows application will running on the corporate intranet and will be accessing those MVC 3 actions on the website via internal HTTP requests using this dedicated username/password in the query string.
Question: Is this safe enough?
Hi we have a similar situation, we chose to build the management interface into the web application and using ASP_NET Roles to give access to it.
Otherwise (not sure how it works) but in the properties of a Windows Forms project you have the option of using forms authentication, this could possibly be a better solution.

Resources