I have implemented Microsoft authentication using IIS Express and everything worked as expected (like the one from https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins?view=aspnetcore-5.0).
However after I publish it to IIS, when a user tries to access the application, instead of the Microsoft login page, I get a page with the message
No webpage was found for the web address: <redirecturl>?code=...
I should mention that there is no other way to login. Only the Microsoft one has to be supported.
After further investigation I found out from where the problem was.
The server was protected and the IIS did not have access to the internet and a proxy was required. Hence the reason on IIS Express was working on the development machine but on the server IIS did not.
Related
I am implementing a WebApp in our company's intranet with Blazor WebAssembly. I need to make API-Calls to our DevOps Server hosted in our intranet and need to use Windows Authentication to access the API. In the former used WPF Client it was enough to just add the UseDefaultCredentials-Flag on the HttpClient, but that does not work in WebAssembly anymore since the App is running in the browser. The Microsoft Docs state We don't recommend using Windows Authentication with Blazor Webassembly, but not recommend does not mean not support, so it has to be possible somehow, to attach the current App-User's Windows Credentials(Token) to the API Call. Unfortunately there exists no example on the docs page on how to implement this and I have not found any code on how to tackle this, although on some forums people wrote that it is possible, but did not include the How in their comments.
I am using .NET5 for both Server and Client and need to make the Api-Call with Windows Authentication from the Client, not the Server as most examples are using it, as my Server-Project uses the same User for all Requests but I need the User of the Client-Project.
Any kind of help is appreciated.
I have two application, both running on the same Windows machine. One application is IdentityServer4, and the other is my own web application (Server side Blazor app).
Both web apps are build with .NET Core 3.1.
When I navigate to my web app, I first get redirected to my IdentityServer4 app. I login, and after that I get redirected back to my web app.
The login was successful, because there are no errors in the logs of IdentitServer. Also, I see a certain claim value on my Blazor webpage. I display this claim through CascadingAuthenticationState in my Blazor page. Through that path everything works fine.
But, whenever I try to get the logged in user through HttpContext in my "code behind" files, I get a Null reference back. For example:
public UserService(IHttpContextAccessor httpContextAccessor)
{
// HttpClient is NULL...
var httpCtx = _httpContextAccessor.HttpClient;
}
The strange thing is, that it all works fine when I run my application locally in Visual Studio. When I debug in Visual Studio I see that the HttpContext is set with all my user data.
But, for some reason HttpContext is NULL when I run the app from IIS.
How can I solve this issue?
If the HttpContext null-reference exception happens after deployment to Azure App Services or IIS, you might have forgotten to enable WebSockets.
Here is the deal:
If the app runs on Windows with IIS: WebSockets must be enabled.
See the IIS/IIS Express support section.
It seems that this is a prerequisite that you have to follow. I only recently discovered this myself after dealing with the same issue and deciding to publish my app to Azure from within Visual Studio. After I did so, Visual Studio gave me a nice warning telling me to enable WebSockets protocol on the Azure App Service.
To enable websockets in azure app service. Open app service in azure portal -> configuration -> general settings -> websockets on or off. Described here
In Server1 - (IIS hosted, Self Signed Certificate)
I hosted the IdentityServer3 named myDevIds3.com , the Url is exposed to internet, with SSL.
I hosted the ASP.Net MVC Client, which uses ids3 for login, works fine.
I hosted the Web API, which is called by the MVC Client, uses ids3 (in the same server), works fine.
In Development Server / Box.
I hosted MVC client (X), which uses client side js famework (https://github.com/IdentityModel/oidc-client-js) to connect to Server1 hosted ids3 (myDevIds3.com), works fine.
I hosted an Web API, which is called by MVC Client (X), while API uses myDevIds3.com for authorisation. [HERE is the problem]
When I try to access this Web API, I am getting an error in the Startup.cs - The remote certificate is invalid according to the validation procedure.
BUT I tried in other way.
I hosted another IdentityServer3, the MVC Client, the API also in development box, mapped to local identityserver3 with MVC client & apit, looks everything seems to be working with out any issue. If I put everything together in one box, everything seems to be working.
What is wrong in accessing the remote machine IdentityServer3 in Web API which is hosted in local development Box ? Why I am able to access from the browser, but not from development box IIS ?
Appreciate your time and inputs.
Because your ssl cert is probably home made and not trusted. Guessing Chrome also gives you warning about this (?).
CAUTION: This solution is not recommended for production, but this can be used for non production environments, where your data is not critical.
Add below code in Startup.cs (Web API)
ServicePointManager
.ServerCertificateValidationCallback +=
(sender, cert, chain, sslPolicyErrors) => true;
This can be refered in below link aswell.
C# Ignore certificate errors?
I found this solution helpful, since I want to have identityserver3 DEV hosted centralised and multiple developers need to access it. Hope it might help someone.
I am having trouble hosting a simple WCF service application in IIS 5.1 (XP SP3).
I follow this Pluralsight tutorial (https://www.youtube.com/watch?v=SVPXLF-g4Ws) but still the service won't load and shows IE blank page "You are not authorized to view this page .. HTTP Error 403 - Forbidden "
any advice? how to host WCF service in IIS 5.1.
Try changing the IIS Authentication for your IIS host website to "Anonymous" and see if that is where your problem is and if doing this makes it work.
NOTE: In reality, you will need to set your authentication in IIS based on whatever your authentication method is going to be.
Can anyone give a clear explanation of the difference between using
clientCredentialType=Windows, and
clientCredentialType=Ntlm
in a server-side Web.config when hosting a WCF service?
I have a SOAP 1.1 (basicHttpBinding) service for interop with existing clients. It uses ASP.NET roles so needs clients to be authenticated.
When I am using the VS2005 (Cassini) server to host the service, I have to specify ClientCredentialType=Ntlm as above, and check the Ntlm authentication box in the project properties in VS2005. ClientCredentialType=Windows doesn't work - clients get a:
401 Unauthorized error
However when I'm running under IIS, it's the other way around: ClientCredentialType=Windows works, and ClientCredentialType=Ntlm fails.
Can anyone explain this, and preferably suggest a way I can have the same web.config file to run the service in Cassini and IIS?
Update
I have .NET 3.5 SP1 on my dev machine, which is XP SP2 running in a domain. Cassini therefore runs under a domain account, and IIS 5.1 under a local account.
I wonder if it could be related to the breaking change in .NET 3.5SP1 described in these articles.
http://www.aspnetpro.com/newsletterarticle/2008/12/asp200812ab_l/asp200812ab_l.asp
http://msmvps.com/blogs/alvin/archive/2008/11/14/net-3-5-sp1-breaking-change-to-wcf.aspx
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=354236
The situation sounds similar as clientCredentialType=Windows fails when the server is running under a domain account (which is my situation with Cassini - running as my normal domain user account), and works when running under a local account (which is my situation with IIS).
The problem is that the suggested fixes require changes to a WCF client configuration file - but in my case I'm using SOAP 1.1 (basicHttpBinding) with non-WCF clients.
clientCredentialType=Windows uses the built in Windows authentication which can be through Active Directory and NTLM.
Obviously the NTLM type will only use NTLM for authentication.
I'm sure you've seen it already, but here is a link to WCF security:
http://msdn2.microsoft.com/en-us/library/ms734769.aspx
Some more details on your setup would help. Are the IIS and Cassini servers running on the same box? If not do you have the same accounts setup on each box? IIS6 by default supports NTLM, so you shouldn't have a problem getting it to work.