I have an Azure Application Gateway sending user (HTTPS) traffic to a single backend web server, which is hosting an ASP .Net Framework 4.8 web application in IIS 10; users sign-into the web application using Windows authentication. The Application Gateway is not using cookie-based affinity (as there is only one web server). ASP .Net is using a SQL Server session state database:
<sessionState mode="SQLServer" stateNetworkTimeout="30" timeout="30" allowCustomSqlDatabase="true" sqlConnectionString="Data source=***********************;Database=ASPState;Integrated Security=SSPI;Persist Security Info=True" />
When users sign into the web application, as it is using Windows authentication, they are automatically authenticated using their Windows credentials, so they do not have to enter their user id and password. However, they will sometimes be signed in as the wrong user (someone else who is already signed-in). This only happens when using Application Gateway, and does not happen if the users go direct to the web service URL (bypassing Application Gateway).
When this bug happens, the application logs suggest that ASP .Net is getting the session id for the wrong user, i.e., the session id of the other user who is already signed-in. In Global.asax.cs, Session_OnStart the following gets logged:
Session.SessionID = sessionId for the wrong user
HttpContext.Current.User.Identity.Name = Windows userid for the wrong user
Session.IsNewSession = True
HttpContext.Current.User.Identity.IsAuthenticated = True (this is to be expected because Windows authentication is being used, so the user is already authenticated by IIS)
My guess is that Application Gateway is not persisting the user's Windows identity correctly between requests.
Related
I am looking for some guidance on how I can use an Azure B2C custom policy to federate to a legacy Authentication Server. Here is the current flow that I would like to implement in the custom policy.
This protocol looks like a hybrid Oauth1 and the "actors" involved are:
Browser based user
Application Server
Authentication Server + protected resources
The Application server is preconfigured with an application id and an application secret provided by the Authentication Server. The Authentication server is also configured with a callback URL (pointing to the Application server). - Similar setup to OAuth.
Flow:
Step 1: The user requests a resource from the Application server by performing a GET on the application server (e.g. GET /resource
Step 2: The application server calculates an attribute using the preconfigured client secret and redirects the browser to the Authentication Server.
Step 3: If the Authentication Server determines that the user needs to be authenticated and may prompt the user for a username/password. This is transparent to the application server.
Step 4: The Authentication Server verifies the application server-provided attributes sent in Step 2 and responds by redirecting the user to the preconfigured application server callback URL. This request will additionally include a number of attributes set by the authentication server.
Step 5: The browser redirects the user to the application server’s callback URL and the application server uses the attributes received in Step 4 to calculate a resource request token
Step 6: The application server uses this request token to request protected resources and responds to the user's original request.
I am looking for ways to implement the above. Do I build this using a custom policy with an Oauth1 Technical profile Or an OIDC technical profile or something else?
The only way to do this is to create some middle layer than talks OpenId Connect to AAD B2C and talks the proprietary protocol to your legacy system.
Azure AD B2C can then make an open id connect request to your web server and it can do whatever it needs. Just have it respond back to B2C in an open id connect way.
I would like to secure access to a ASP.NET Web API 2 as well as SignalR hubs both exposed using a self-hosted OWIN app hosted by a WPF desktop application. The WPF application is currently binding the OWIN HTTP listener to a TCP port on localhost for now, i.e it is not accessible from other machines.
The intention is that only my own other desktop applications as well as other third party desktop applications trusted by the end user (all running on the same end user machine as the WPF application) should be able to access the the Web API and SignalR hubs.
My current thought is to require the client application to authenticate with the WPF application, perhaps using a OWIN Authorization server (hosted by the WPF-application process) and a OAuth2 Client credentials flow where the WPF application would store the client credentials (client id and a salted password hash) in e.g., a settings file of the WPF application.
I have realised that since both the WPF application and all client desktop applications accessing it's Web API and SignalR hubs all run on the end user machine there is no point in attempting to "hide" any credentials used between the applications from the user. Since any encrypted password would need to be stored on the end user machine the desktop client applications may just as well use some security library or the underlying OS facilities to store an encrypted password knowing that the end user would be able to access it.
I have a few questions related to this.
Am I on the right track using OAuth2 Client credentials flow at all or is it inherently insecure when used for IPC on the same (end user) machine via the loopback interface?
With the realisation that the end user at least in theory have access to the credentials of a client desktop application and the end user could be a malicious user I have understood that in order to limit any damage done by a malicious end user only to that particular installation the same password for a specific client id should not be used in any two end user installations of the WPF application.
If the same password would be used a malicious end user A could install client desktop application with client ID X, reverse engineer it to retrieve the password stored by it, write his/her own malicious application Y tricking victim end user B to run the malicious application Y which would then impersonate client ID X using the same password to authenticate with the WPF application running on victim end user B machine.
Given that each client id must have a unique password for each end user installation of the WPF application I would still like to keep the establishment of trust between the applications as transparent as possible to the end user.
Any advice on this point would be very appreciated.
I.e., the less amount of steps needed by the end user to generate the password for an installed desktop client application and register the client id and password in the WPF application the better.
If OAuth2 is inappropriate for securing loopback (localhost) access to the ASP.NET Web API 2 and SignalR hubs. What would be the alternative?
Thanks
/John
I am stuck at the moment on trying to configure the Windows authentication on a web site.
The site is configured (in IIS 7.5) as follows:
Windows authentication and ASP.NET Impersonation - Enabled.
The 'Enable Kernel-mode authentication' is checked.
Providers section contain all 3 possible: Negotiate, NTLM, Negotiate:Kerberos.
The site connects to a SQL Server using Windows authentication as well.
The Web server is marked as trusted for delegation for the SQL server.
When I browse the site locally from the web server everything works; when I browse it from a client computer I get the well known error "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'"
I read I should set some SPNs - but in my case - to what\whom ?...
The access to the SQL Server is done individually to users (also, the Web server, SQL server and the users accessing the site are in the same domain; the application pool also uses a domain account)
An advice would be much appreciated ...
I think you're getting "Anonymous Logon" because you have anonymous logon enabled.
Try enabling only Windows authentication and ASP.NET Impersonation and disabling the rest
Also might help to check the internet explorer security settings for the 'zone' you're in from the client computer (i'm guessing internet) at the very end set internet explorer to prompt for user name and password
I am calling the SharePoint 2010 REST/ODATA api and by default the data context uses DefaultCredentials, which is really the logged-in user of my Asp.Net application. If I don't attach DefaultCredentials to the context, then I just get 401 Unauthorized.
I was wondering how to call SharePoint API while using the Application Pool credentials? I am trying to follow the trusted systems security approach. Otherwise the SharePoint site needs to grant ODATA access and certain lists need be writable by basically everyone (gak!).
For example, with a SQL connection, I would just set "Integrated Security=true" to use the application pool credentials.
Am I right that you are running an ASP.NET application on other than the SharePoint server? (Outside of the farm; just a machine with IIS and ASP.NET.) If your ASP.NET application pool runs under the same user as your SharePoint web application you can temporarily impersonate the code of you handler or page to the application pool user and use the default network credentials:
using (HostingEnvironment.Impersonate()) {
ICredentials credentials = CredentialCache.DefaultNetworkCredentials;
// ... use the credentials
}
If you know credentials (name and password) of the application pool user from some configuration you can make the HTTP request using them directly:
ICredentials credentials = new NetworkCredential("user_name", "password");
// ... use the credentials
--- Ferda
I have a ASP.NET application that need to access to ANOTHER application, the ANOTHER application expecting Kerberos authentication, it based on the user credential to response to the request. My ASP.NET app is running on a AD service account that is setup to allow delegate to the ANOTHER application (with proper SPN).
So the process is, user requests to the ASP.NET app, the ASP.NET app will impersonate the request to the ANOTHER application by delegation (with kerberos).
When I run the app in local machine (My ASP.NET resides), the request was successful, however, if the request is coming from remote client machine, it failed, from the ANOTHER application's log, it shows the Identity is not presented.
Any clue?
Have a look at the following which appears to be very similar to your situation:
https://serverfault.com/questions/270293/moving-my-website-to-different-server-changes-authentication-from-kerberos-to-ntl/270306#270306
There are some resources that that should help you troubleshoot.