Simplesamlphp behind reverse proxy - drupal-7

I have configured my application and simplesamlphp behind reverse proxy. I have created a test SP But when I am going to test the SP, it redirects to https://web-server-ip/adfs/ls/?SAMLRequest=nZL instead of redirecting to ADFS server url https://adfs.server.com/adfs/ls/?SAMLRequest=nZL
I have changed the baseurlpath in config.php to "https://web-server-ip/simplesaml/". But still same error.
SP is working with App server. If I am trying to test the SP using https://app-server-ip/simplesaml, it redirects to ADFS server login.
But no luck via web server.
Please suggest any solution.

In my case it was the the problem of reverse proxy. It is fixed now.

Related

How to I view email using gmail API within a server environment? (Python)

I want to be able to retrieve emails from a gmail inbox but I cant find a way to properly authenticate in a server environment. Traditional authentication uses this: https://developers.google.com/identity/protocols/oauth2 however I don't have access to a web browser with javascript within a server environment so I cant authenticate. A service account wont work because I wont be able to access inbox of my main email address through it. Thanks.
The best solution I could find is to create the authentication tokens on computer then use a shell script to automate the transfer of the files over ssh onto the server.
If you have the permission to temporarily open a port on the server, then you can use the built-in authentication server:
flow = InstalledAppFlow.from_client_secrets_file(client_secret_file, scopes)
cred = flow.run_local_server(open_browser=False, port=port)
By setting open_browser to False the script is going to print the url to the command line, you can then open the link locally in your web browser and after the successful authentication you Google is going to redirect you with your token to the websever running on your server. You can see this functionality in action in a script I use to sort my email using machine learning.

Azure AD App Registration error: The reply URL specified in the request does not match the reply URLs configured for the application

Sorry that my question might be repetitive but none of the solutions provided in other links have resolved my issue. Below is my situation
We have ASP.NET Core 3.1 Web application to which we are trying to use Azure AD so that users can login with our Enterprise Credentials. We started with ASP.CRORE MVC default template and enabled to Use Organization credentials and Authentication is working in our Local environment. We are now trying to deploy this app to other internal environments. So we have deployed this to two of our internal servers and configured IIS to refer this website with http IP's assigned. I was able to create Azure App registry for this application and was able to add the http IP's through Manifest, added the clientId to the appsettings.json file and the authentication is working if we refer the website using the http IP's. I have also tried by assigning https IP's assigned to the same websites and added them to Azure App Registry and again the authentication is still working if we refer the website with either of the 2 https IP's.
Now we have decided to create URL something like https://ourwebsitename.companyname.com which resolves to either of the http IP's using F5 Load balancer. I was able to add the URL to the azure app registry and using the same clientId in appsettings.json in the same way how the app is working with http or https IPs. But somehow when we refer the website URL
https://ourwebsitename.companyname.com we are getting the error as mentioned in the title of the question and I did observed after I hit the URL, its getting redirected as redirect_uri=httpXXXX instead of https which I thought may be the reason of the issue but unable to resolve. I have googled it and tried with various solutions but none resolved and so I am posing it again hoping for a luck if someone can provide me a solution.
Following are the links which appeared close to my situation but didn't work for me
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-5.0
https://github.com/AzureAD/microsoft-identity-web/issues/115
Thanks in advance.
I looked at the sample you provided, and it does not provide the redirect_ url key in appsettings.json. So, based on my experience, it should have a built-in redirect_ url. Otherwise, the aadsts50011 error will not be reported.
To deal with this kind of problem, you can try a general solution:
When you visit the application url , you will be redirected to the login page. Decode the authorization request url, you will find redirect_url, copy the value of redirect_url and paste it into the azure portal, and try again.
For the redirect URL, it should start with https, if you need to start with http, you must configure it as http://localhost.

How do you configure a Blazor Server application using Azure AD in a load balanced environment?

I have an intranet Blazor Server application created using the Visual Studio template with the Work or School Accounts authentication option. Everything was working beautifully when running on my local machine and when the app was published to our development environment. However, once I moved the app to our staging environment, the application would sometimes crash after authenticating the user in Azure.
After troubleshooting the issue, I believe the problem to be that our on-premises staging environment is load balanced (mimicking production). Our dev environment is not load balanced. I think what was occurring was that once authenticated in Azure and redirected back to the application, the user doesn't always land on the same server due to the load balancer. This breaks the Signal-R circuit and caused the application to crash. This also explains why the error was random; happening maybe 2 out of every 10 logon attempts. To test this, I removed Azure AD authentication from the application and allowed anonymous access to every page. The crashes stopped.
My question is if anyone knows of any workaround to get Blazor Server with Azure AD authentication working with an on-premises load balancer. I searched all over the web and the only workaround I found was to use sticky sessions with Azure Signal R service. We are not hosting apps on the cloud yet. Is switching to Blazor Webassembly the only option if I want to use Blazor with authentication in my environment? Someone at work suggested switching the application to use our on premises ADFS server. However, wouldn't that encounter the same issue?
For reference, here is the code in startup.cs ConfigureServices method that sets up the Azure authentication in the application:
services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => Configuration.Bind("AzureAd", options));
services.AddControllersWithViews(options =>
{
var policy = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();
options.Filters.Add(new AuthorizeFilter(policy));
});
I found the solution to this and am posting it here in case anyone else is facing a similar issue.
It turns out the problem wasn't SignalR or anything specific to Blazor Server. After enabling the developer exception page on the load balanced environment, I saw that the error was "Unable to unprotect the message.State". The application state is encrypted by middleware before the user is authenticated by Azure AD. When Azure AD posts back, it includes that encrypted state which is then in turn decrypted on the client side by the middleware.
The key needed to decrypt is by stored on the web server. When in a load balanced environment, if you land on a different server than where you started, the middleware will then be attempting to decrypt state with the wrong key. This of course results in an error.
To fix this you have to store the keys on a central location like a file share instead of on the server itself. Implementing the fix is actually simple. Include the following line in ConfigureServices in startup.cs:
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(#"\\server\share\directory\"));
There are also options to store keys on Azure if that is preferred.
This post by Kevin Dockx is what finally gave me the answer:
Solving Correlation Failed: State Property Not Found Errors (OpenID Connect Middleware / ASP.NET Core)

Suppress WWW-Authenticate header in Azure IIS

I am dealing with a third party REST API server which uses Basic Authentication. We don't have control over that server and in case of a 401 chrome pops up a dialog for username and password which is essentially because of the WWW-Authenticate header which is present in the response in case of a 401. We have a reverse proxy setup on Azure through which all the requests are being made to the API server. I am wondering if there is a way we can suppress/remove the WWW-Authenticate header in the reverse proxy IIS webconfig somehow. Or is there any other way to suppress this dialog without the help from the API server itself. The front-end is an Angular application. Thanks in Advance!
Update: We are able to achieve the same in our local dev environment where we are using nginx by just adding proxy_hide_header WWW-Authenticate; to the server.conf file. Does IIS has something similar that can be used to strip that header from the response?

ADFS 2.0 - How can I Debug "401 - Unauthorized"

I setup a test Server 2008 box with Active Directory and ADFS 2.0. I have an ASP.NET app which uses WIF to federate identity. ADFS is configured to use Active Directory for identity info. I used WIF to configure the client app to use the ADFS endpoint.
When I attempt to load the ASP.NET app as a user from the browser I am redirected to the ADFS endpoint and am prompted for credentials. I have attempted to login with several users accounts, even resetting passwords but the credentials never seem to be correct and a 401 Unauthorized is returned. I can login to other systems successfully with the same credentials.
I have enabled debug trace in verbose mode and enabled auditing in verbose mode but I can't find any errors or info to help me figure out the issue.
How can I get more info to narrow down the problem?
UPDATE:
I found that this issue is caused by my testing environment. My dev machine is on our corporate domain (acme.com). I created two 2008R2 VMs for a test Domain Controller (notacme.com) and Web Server.
If I attempt to access the website from a computer on the acme.com domain the error described above occurs. If I attempt to access the website from a computer on the notacme.com domain it works.
What can I do to access the website from a computer on the acme.com domain?
Apparently this was caused by the Extended Protection feature built into ADFS. In trying to troubleshoot this issue I had Fiddler running to track the requests/responses but at one point I swear I turned it off to test as well but it still didn't work. Apparently I didn't fully remove the Fiddler proxy because after a IE reboot and with Fiddler not running it worked in IE but found it still didn't work in Firefox or Chrome. This led me to a TechNet article which described the behavior I've been seeing in conjuction with using Fiddler.
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
In my experience, every sign-in failure in IIS (including AD FS) is logged in the 'Security' event log as an 'Audit Failure' event, which contains more details. So I would search in the event viewer on the AD FS system, and see what those events have to say. Also in the event viewer, check the 'Applications and Services Logs' -> 'AD FS 2.0' -> Admin event log.
It looks like you did try to look at the HTTP traffic, e.g., using Fiddler. That's good. I presume the problem also occurs when Fiddler is not used?
(Do you perhaps have the problem of a repeated sign-in form, after you entered correct user name and password? Then look at the following answer: ADFS authentication - IE8 works, Chrome fails.)
(I have also seen a case where the initial authentication was successful, resulting in 'Audit Success' events, and then a 401 resulted from a later redirect. Also in this case the event logs on the AD FS system helped.)

Resources