How do I configure SignalR to Authenticate/Authorize to a server that is must be protected by Windows Authentication. There appears to be no way to make the JavaScript Client send Credentials with the request.
Windows authentication should be handled by the browser and you should not have to do anything special. The problem is that Chrome does not seem to handle Windows Authentication correctly. There is a thread on github that contains more details.
Also, SignalR MVC 5 Websocket no valid Credentials seems still to apply as the issue is browser related (i.e. external to SignalR).
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 a couple of projects:
Chat - SignalR backend (ChatHub)
Web - MVC project that hosts clientside scripts, including those that make calls to the Chat project
I'm in the process of migrating from .NET Framework to .NET Core and am moving to SignalR for Core as part of this work. Cookie authentication is working correctly on the old version, but upon migrating to SignalR for Core, I appear to be having problems.
Cookie authentication is enabled in both projects. The Web project works fine and the Auth cookie is correctly recognised and used for authentication. The Chat project, however, is not correctly authenticated against the cookie, despite the cookie being included at least in the negotiate request:
When I make a call to the ChatHub, Context.User.Identity.Name is empty. The same call returns a populated name when run on the Web project. If I decorate the ChatHub with [Authorize], the call fails with a 401.
Here's a minimalistic repro project showing the issue.
I assume the problem is related to the Authentication I have configured, or perhaps the cross-domain nature of the call?
This documentation is pretty unhelpful, and only says the following:
In a browser-based app, cookie authentication allows your existing user credentials to automatically flow to SignalR connections. When using the browser client, no additional configuration is needed. If the user is logged in to your app, the SignalR connection automatically inherits this authentication.
This appears under some very basic configuration, which basically only calls app.UseAuthentication(). Alas, that configuration does not work for me.
How do I set Cookies authentication in SignalR for Core so it works across two projects?
The issue is that by default, the Data Protection system that ASP.NET Core uses to encrypt the auth ticket isolates apps from one another.
You need to configure data protection on each project you wish to share protected payloads to use the same key ring and app identifier:
services.AddDataProtection()
.SetApplicationName("<appName>")
// as well as the following calls if your projects are to be deployed on different machines
.PersistKeysToAzureBlobStorage(new Uri("<blobUriWithSasToken>"))
.ProtectKeysWithAzureKeyVault(new Uri("<keyIdentifier>"), new DefaultAzureCredential());
I've got Azure ServiceFabric web-app (AspNetCore 3) hosted over reverse proxy (NGinx). The app use AzureAD (in company) authentication. I've Registered App for the AD and setup Redirect Urls mannually in manifest. After publishing the APP and configuring DNS and reverse proxy I tried to authorize to my app but failed with AADSTS500117: The reply uri specified in the request isn't using a secure scheme.
Is it possible to configure client to allow http redirects?
P.S. As I know Identity Server allows it by configuring DiscoveryPolicy.
P.P.S. You can find more information in my origianl question (see. How to change redirect_uri for Azure AD)
What happens?
when you deploy web apps with a reverse proxy, as is, for instance the case with App Services as Linux containers, your application will be called on an HTTP address, whereas its registered redirect URI in the app registration will be HTTPS.
This means that when a user browses to the web app, they will be redirected to login.microsoftonline.com as expected, but with redirect_uri=http://<your app service name>.azurewebsites.net/signin-oidc instead of redirect_uri=https://<your app service name>.azurewebsites.net/signin-oidc.
How to fix it?
In order to get the right result, the guidance from the ASP.NET Core team for working with proxies is in Configure ASP.NET Core to work with proxy servers and load balancers. You should address the issue centrally by using UseForwardedHeaders to fix the request fields, like scheme.
The container scenario should have been addressed by default in .NET Core 3.0. See Forwarded Headers Middleware Updates in .NET Core 3.0 preview 6. If there are issues with this for you, please contact the ASP .NET Core team https://github.com/dotnet/aspnetcore, as they will be the right team to assist with this.
I'm looking for a complete step-by-step guide or a sample project about implementing a RESTful Service using .NET 4.0 using Custom Basic Authentication over HTTPS hosted in IIS.
I've been googling about it for 3 days and I could only find either an implementation with WCF 3.5 which is very different, or without Custom Basic Authentication, or without SSL.
Basically I implemented my REST service on WCF 4, and added SSL, but I can't use a custom authentication using my custom users database.
Any references would be really appreciated.
It's not currently possible using the available WCF extension points.
It is possible with custom HTTP module allowing basic authentication against custom credential store. Built-in module in IIS supports only windows accounts.
I wrestled with this for a while and ended up just implementing basic auth in my service. Check WebOperationContext.Current.IncomingRequest.Headers for an 'Authorization' header. If it's missing or the credentials don't match set the challenge header and return a 401 status:
WebOperationContext.Current.OutgoingResponse.Headers.Add("WWW-Authenticate: Basic realm=\"myrealm\"");
throw new WebFaultException<string>("Username and password needed", HttpStatus.Unauthorized);
That's enough to trigger a browser to prompt the user for credentials. See https://www.rfc-editor.org/rfc/rfc2617 for more on basic auth, http://ithoughthecamewithyou.com/post/Basic-HTTP-auth-for-an-IIS-hosted-WCF-4-RESTful-service.aspx for more on this frustrating missing capability.
I have created and tested a WCF REST service that is protected with SSL and Windows Authentication through IIS 7. I have also created and tested a pure html/javascript web client that is hosted in IIS 7 that is protected with SSL and Windows Authentication -- same server, different "site" within IIS. The REST service is not public, but the web client is.
Without security, everything works beautifully, but now we are ready for field testing and security must be implemented.
My end goal is to have the user visit mywebclient.com and authenticate using their Active Directory accounts. Initially I thought it would be safe to leave the service calls from the client to the REST service unprotected (since the traffic from the web client to the web service would be internal), but this does not protect us from an internal attacker. Also, in the future, the REST services will be available to handhelds through native applications.
I've tried to gain as much information on this subject as possible, but every piece of Microsoft documentation contains client examples written in .NET.
How can I share the security context between these sites without converting the web client to a .NET-based application? Could this be accomplished by combining the web client and service into one IIS "site"?
Edit: If the client and service exist in the same app pool, does that mean they could share authentication information between client and server processes?