I have a Web Client and a Web Api running on the same server which are both set up as separate applications under the common IIS default website. The website is configured with two https bindings, one for each app. The Web Client talks to the Api.
Now to my problem. I can't get https to work. When I specify that the Web Client should access the Web Api over https I get get an error while accessing the Web Api from my machine over https works fine.
Web Client (app server) -> Web Api (app server)
ok: http://"server name"/webapi/
not ok: https://"server name"/webapi/
not ok: http://"host name"/webapi/
not ok: https://"host name"/webapi/
Web Client (my machine) -> Web Api (app server)
ok: http://"server name"/webapi/
not ok: https://"server name"/webapi/
ok: http://"host name"/webapi/
ok: https://"host name"/webapi/
Also, both sites are configured to use windows authentication.
The problem seems to have been that I was using an alias as "host name" which for some reason won't work in this scenario. Calling the Web API using alias from another machine works fine but not between the Web client and Web API on the same server. Changing "host name" to full computer name together with creating a matching certificate solved it.
I think your problem might be with the Double-Hop Authentication issue. Refer to these links for information and a potential solution:
ASP.NET Web Blog about the issue
Steps to get around the issue
Without an actual error code (502, 403, etc.) it's hard to determine what the actual issue might be. One other thing might be if you are using a self-signed SSL cert you may have to manually allow the application to connect to the website with an invalid/self-signed cert, as you indicated it works without HTTPS (or so I read it as).
Related
I'm using oauth2-proxy with Keycloak to authenticate to applications.
Oauth2-proxy sits in the front, and when a request comes to port 4180 it redirects to Keycloak, once you authenticate it redirects to the upstream address (where the application lives)
This works well as long as the application is on the same server as oauth2-proxy.
When the application is on a different server, all the same process goes well with no errors, (exact same configuration except for the upstream which now points to another server:port), but instead of redirecting to the upstream app on the other server, it redirects to the same server:4180 and shows me an Nginx welcome page.
Could this be a configuration issue, or is it mandatory that the application is in the same server as oauth2-proxy?
I developed an application that uses Azure AD Authentication for a single tenant.
I would like to host it inside AKS, but it seems not to be possible, as described below:
The problem is that the application must be running as https if it is not in localhost, but my pod is running on http protocol (as usual). Even if my aks cluster service is running as Https, the callback uri seems like to be looking for the protocol on the pod where it's running, so it redirects the request to http://mydomain and not https://mydomain, returning the "Correlation Error" or "app id doesnt exists" (because the mapped uri was https://)
The redirect URI can not be mapped to http on Azure App as described here.
I've made it work using a certificate inside my pod on the application build using Kestrel Certificate. But it seems not to be a good solution.
Does anyone knows a more suitable workaround?
As of now there is no other solution available as we have restrictions in redirect URL as per the document you are following.
I am currently working on an .NET 5 & SignalR application and in localhost everything seems to be working fine. When I try to deploy it to IIS pre-production Server which doesn't have a SSL certificate configured, pages other than Login are showing the message "This site can’t provide a secure connection". In the login page from the browser console I can see that most of me javascript and css files aren't loaded with the error "Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR". Also from what I can see after user logs in, the request is redirected to Https.
I have removed app.UseHttpsRedirection(); from the Startup and disabled SSL in the Debug properties of the application. That seems to be a wired behavior because I used to deploy applications in .NET CORE before and didn't have these kind of problems. is there any way around this problem, except configuring an SSL certificate?
From the suggestions in server fault, configuring a self-signed certificate provided by IIS itself seems to be the problem solver. Still I don't get why the application was making that https redirection, but anyways in case someone else has this kind of issue.
We have a couple of back-end web applications to which we want to provide access via the public internet. To that end, we are setting up a reverse proxy (IIS 7.5) from our DMZ. At the same time, we want these web applications to be claims-enabled through ADFS 2.0.
WEB1.MYCORP.COM/WFE1 is the other back-end web application, on our internal network
WEB1.MYCORP.COM/WFE2 is the other back-end web application, on our internal network
ADFS.MYCORP.COM is the ADFS 2.0 server, on our internal network
FSPROXY.MYCORP.COM is the ADFS 2.0 proxy server, on our DMZ
RPROXY1.MYCORP.COM is the reverse proxy for WFE1, on our DMZ
RPROXY2.MYCORP.COM is the reverse proxy for WFE2, on our DMZ
In keeping with the proper configuration of ADFS, our internal DNS resolves ADFS.MYCORP.COM to the actual internal server, while external DNS points ADFS.MYCORP.COM to the ADFS proxy (FSPROXY).
So, here's the scenario:
End user browses to RPROXY.MYCORP.COM
Reverse proxy forwards request to WEB1.MYCORP.COM/WFE1
WFE1 redirects browser to ADFS.MYCORP.COM (actually FSPROXY)
ADFS Proxy prompts for credentials and authenticates against ADFS server
Upon successful authentication, browser redirected back to web app
I have a couple of questions. Do I need to configure something in the rp or the application to allow this. Also the adfs endpoint is the rp url is that an issue?
Do I need to set up something for the reverse proxy as well? (Should I/can I) set up a claims-enabled reverse proxy in IIS? How do I set up the reverse proxy rules to pass back the ADFS request unaltered? Currently, when I try to access the back-end application, it fails with a 401 authentication error. If I remove the proxy and just hit the app server it works fine.
Further,
This fails:
The path is client --> rp -->app -->adfs --> rp -->app --> rp -->client machine
this works:
The path is client -->rp -->app -->adfs -->app -->rp -->client machine
Any suggestions would be greatly appreciated!
Not familiar with how you enabled reverse proxy in IIS (ARR?). Something like this http://blogs.iis.net/carlosag/setting-up-a-reverse-proxy-using-iis-url-rewrite-and-arr
One choice for you is to use ADFS 2012R2 (if possible) because the proxy in that, the Web Application Proxy, handles both ADFS authentication and can handle app publishing for your claims enabled application. There are 2 ways you can publish your app to the internet. Once is pass-through which is kinda what you are trying to do. But it also allows pre-authentication support for a claims aware app. This way, you can have a different policy that decides whether the application can get pass your EDGE network before a packet goes to your internal application.
After doing lots of digging and fiddler traces I found the issue. In testing idp setup the token was different then stage env. The fiddler traces showed that the token was making it back to the app server. The issue was it also looked like the cookie dropped off for no reason. The issue was because the old dev ipd value disagreed with the stage value...naturally. Once I cleared the old token from the database everything worked.
We have a Web-Application that should interact with a desktop application that has a helper tool character (e.g. no setup, no need for admin privileges). The helper is listening via http/https on a simple port bound to localhost.
The Web-Application uses a SSL certificate. Every customer has a machine on its own for his data. For claryfication: The Web-Application is running on a server, serving one customer but multiple people.
The problem is, the Web-Application cannot reach the helper tool via https (using image or iframe). The main issue is, that the local webserver listening on localhost has no signed certificate. So the web browser is blocking the interaction.
Is there any way to get around this trouble? I think, I cannot get a certificate for localhost, because no one would sign it.
I know, that I cannot use XMLHttpRequest for this, but that's not the point.
The goal is to have a customer friendly - no install - just works - solution. The customer should not do ANY configuration. Just downloading and starting the tool. We'd like to have a direct communication to the tool (e.g. no outbound direction to the web server).
Is the any solution for this?
If it is Active-directory environment , you can create your own CA and sign certificates and distribute them across the domain. also you can add to trusted sites through domain policies this way client side you don't need to configure anything .