I'm using the IdentityServer3 Version (2.5.4) for the current project, everything works fine on my local machine (with IIS and IIS Express).
The customer has a Windows7 Embedded machine (without SP1!) with .NET 4.5 installed, we created a selfsigned SSL cert (with the current hostname, NOT localhost), but its not working. I'm always getting the error "Unable to get document from: https://xyz/.well-known/openid-configuration"
what is wrong with the configuration?
I found the Solution, it has nothing to do with the Configuration. The Installation of the Windows 7 SP1 has fixed it.
In a couple of cases where we had this issue, it is mostly to do with network connectivity.
Few things which helped us figure out the root cause -
Access the "https://xyz/.well-known/openid-configuration" route from a browser on the server.
If you are not able to access the url then it means that the server is unable to connect to the Idserver installation. This is a network level issue.
If you are able to access the url from the server where the relying application is hosted, but the relying application is throwing an error -> it means that, a proxy is configured on the server. The browser automatically uses the proxy, where as you have to set the proxy in the relying party application as below in the startup.cs
var request = WebRequest.Create(uri);
var myProxy = new WebProxy {Address = new Uri("proxy uri")};
request.Proxy = myProxy;
var response = request.GetResponse();
This will ensure that all the http requests originating from the code will also use the same proxy.
If the above doesnt help, Check if the IIS where Idserver is installed, allows TLS 1.0 and 1.1. THis is disabled on some servers for security purposes. If that is the case, use the below code to make ur application use tls 1.2 and the call will succeed
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Related
I'm having an issue getting Traefik to proxy applications that are secured using Integrated Windows Authentication (IWA). When the content being served is simply an IIS virtual directory secured with IWA there is no problem. However, when it is a .NET Core application or MVC application or even just a simple Default.aspx page and IWA is enabled I continually get prompted for my credentials (never being accepted). See below for my configuration:
Traefik Configuration:
# ns-ws
[frontends.ns_ws]
passHostHeader=true
entrypoints=["http","https"]
backend = "ns_ws"
[frontends.ns_ws.routes.match_all]
rule = "Host:ns-ws.example.com"
[backends.ns_ws]
# ns-ws
[backends.ns_ws.loadbalancer.stickiness]
[backends.ns_ws.servers.server1]
url = "http://x.x.x.x:80"
I've played with removing pass host headers and stickiness, but no luck.
Seems like the original request makes it through because I do not get an unauthenticated error message from IIS for the page, but most subsequent requests to the server will return a 401 (seems sporadic).
Example Image:
I've tried changing the "authPersistNonNTLM" option in IIS, as described here: https://boyan.io/kerberos-load-balancers/ (with no luck)
I realize this is a very stale issue but in case this helps others.
I can confirm that Windows Integrated authentication works successfully with Traefik 2.x using a TCP as opposed to HTTP router with successful logins proven on Windows/Mac using Safari/Chrome/IE.
Note that when testing it is important to ensure you have cleared cookie caches or you can get unpredictable results due to prior login attempts on non-working configurations you may have attempted. Indeed I experienced something similar to your described behavior with repeated unexplained login prompts until I reset my browser.
In our configuration we have a mixed-OS docker Swarm (Linux/Windows) with Traefik operating on Linux and sending requests straight to back-end Windows-containers running on Windows swarm nodes.
If you have configured your Windows app and containers correctly I can confirm that from:
A domain-joined machine you will get straight through login to Windows back-end containers using the domain-joined machine's Kerberos credentials
A non-domain-joined machine connection will downgrade to Windows NTLM authentication and prompt for Windows authentication credentials.
From a Traefik configuration perspective our docker containers have labels like this:
- "traefik.tcp.routers.dotnet-tcpexample.entrypoints=websecure"
- "traefik.tcp.routers.dotnet-tcpexample.tls=true"
- "traefik.tcp.routers.dotnet-tcpexample.tls.options=default"
- "traefik.tcp.routers.dotnet-tcpexample.rule=HostSNI(`windows.foo.bar`)"
- "traefik.tcp.routers.dotnet-tcpexample.tls.passthrough=true"
- "traefik.tcp.routers.dotnet-tcpexample.service=dotnet-tcpexample"
- "traefik.tcp.services.dotnet-tcpexample.loadbalancer.server.port=443"
Note that configuring containers for Windows integrated authentication in itself is non-trivial but documented here.
I'm using Eclipse to develop an app that consists of an Angular 2 front end and a Java REST back end.
For the front end, I'm using the Angular CLI plugin, which starts the app by issuing an ng serve command to the CLI. This command sets up an http server on port 4200.
For the back end, I'm using an in-company framework that launches in Jetty within Eclipse in port 8088.
While both these ports are configurable, by nature of the frameworks and plugins in use, they'll always be distinct.
Authentication works via an OAuth2 service that is also deployed to port 8088, as part of the framework. This service sets a cookie which certifies the browser session as authenticated. I have verified that this service works correctly by testing it against a Swagger instance of the REST API (also running in 8088 as part of the same framework).
The problem is that when the browser is aimed at the Angular 2 app on :4200, its internal REST API requests to :8088 aren't carrying the authentication cookie. Presumably, this is because of cross-site protection.
Is there any way for the app or the framework to tell the browser that these two "sites" are actually part of the same system?
Alternatively, if I have to configure the dev browser (Chrome) to work, I can live with that too. However, I've tried the --disable-web-security --user-data-dir recommendation, but the cookie still doesn't show up on the requests.
Lastly, I have Apache installed on the dev machine. If I can set up appropriate vhosts and use it as a proxy so that the browser thinks it's all the same, that would probably work too. It would just be a matter of intercepting all /swagger and /api requests and sending them to :8088, and all forwarding all other requests to :4200. However, I've been banging my head against mod_rewrite and mod_proxy and haven't been able to come up with anything that works.
I think what you're looking for is
withCredentials = true
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
I have a self-hosted owin web api service on a test environment, and to give it a better name I use a domain alias, and ARR.
My web api runs on port 8888, and uses Windows Authentication. I have configured my arr to run under testserver:80 with anonymous authentication. I want to deploy a service on the box that will pool the webapi for data. When I try to visit testserver from my web browser on my desktop it works fine. However, when I remote into that box and try to hit testserver it prompts me for credentials. Even if I type them correctly it still will issue me a 401. If I go to localhost:8888 the site will work.
Since, I'd prefer to use the pretty name for the server in my service how do I correct this issue. How do I get it to pass credentials on the same box through ARR?
You might have have an issue with LSA loopback checking.
You get the 401 because ARR forwards your Windows Authentication to localhost, which is not allowed (default setting).
Try to disable LSA loopback checking (restart most probably required). If that works you can limit the disabling of loopback checking to specific websites (to prevent security holes).
See You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version for more information on the LSA loopback check and how to disable it completely or only for specific hostnames.
I've followed the guide:
Getting Started with Authentication with Mobile Services .NET for Windows Store
I'm able to run the service locally as long as I don't need to authenticate the user. I can also authenticate the user if I publish the service to Azure. But I want to be able to test and authenticate the user locally. How can this be done?
I'm using Live ID and I have the correct ClientID and ClientSecret set in the Web.config. When I attempt to call LoginAsync from the client the call fails with The request could not be completed. (Method Not Allowed)
** Update 2014-03-20 **
Based on the comments of Carlos and Henrik, I've updated my local service to look exactly like my server instance. I followed Scot Hanselmans excellent guide and now I have my service running locally on port 80 and port 443 with a completely valid SSL certificate. It's even running on the exact same https://xxxx.azure-mabile.net hostname.
With these changes, there is now no configuration difference whatsoever between running the app against my local machine or running it against Azure. I can go to https://xxxx.azure-mabile.net in the browser, get redirected to Live login, sign in, and get redirected back to the service successfully. In the browser it all works. However it still doesn't work in the app.
I attached the debugger, set CLR errors to "break when thrown" and I managed to trap the exception in the service. Here's what I see in the immediate window:
The Response property is not helpful. It does not provide any additional information about the problem.
The only thing that stands out to me is that the app is trying to do a POST to /login/microsoftaccount while the browser would normally be doing a GET at this address (then getting redirected).
** Update #2 2014-03-20 **
After following Henriks guide for remote debugging I was able to load symbols and get a tiny bit more information:
"An existing connection was forcibly closed by the remote host"
The error code is 10054 (WSAECONNRESET) Connection reset by peer.
It appears the Live Authentication server may be forcibly terminating the connection, but only when I'm authenticating with the app. Again, authentication within the browser is fine. This, combined with the fact that /login/microsoftaccount is a POST from the app seems to suggest there is a problem with the authentication token I'm getting back from LiveClient.LoginAsync. I'll do some more digging...
At the moment, it is set up so that you don't need authentication when running locally and access the service from localhost. In this case, anonymous access is let through (this is of course disabled while running in the cloud).
We don't really have a way for your to authenticate locally as redirect URIs won't work (they can't point to localhost as there is not way that Facebook, say, can resolve "localhost").
One option is that we somehow can mock the authentication locally and give you a token without connecting with the various identity providers. I am not sure exactly what that would look like but it is something we can consider.
Henrik
Did you perhaps set Mobile client app: Yes in your Live Connect project? I think that setting is meant to be used with the Live Connect SDK (client) flow, not the browser-based (server) flow. The client flow isn't supported yet with a .NET backend.
You also want to make sure you are using LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount) on the client to trigger the server flow.
I'm facing a funny issue here.
I got a C# Webforms application running on IIS6. When the user clicks on a certain link, my app makes a REST call to a webservice hosted in the cloud. This call, made by the app running on IIS, fails. We get a WebException, with the message "no response from server".
However, if I try to connect to the same web service, from the same machine, with the same credentials, using SoapUI, the call succeeds. So I guess this means that I can rule out firewall issues, credential issues, and availability of the service.
The code has been tested on numerous other machines (dev, test, staging...), and it worked successfully, so the code itself should not be an issue. I think it's an environmental issue (a setting on web.config or machine.config which prevents outgoing requests).
Any idea as to what that could be?
Thanks!
The reason our REST calls were failing was that we were missing an SSL certificate.
We were trying to make the REST call using HTTPS. The REST service provider's SSL certificate was signed by a well-known CA. However, our server apparently had a hardened build, and the CA's certificate was missing from the certificate repository. Hence, the provider's SSL certificate was considered unsafe.
Sadly, the .Net framework exception had no useful information about this.
We installed the CA's certificate and the issue was fixed.