I am searching for hours now. I have a C# Blazor WASM SPA which get its data from a C# WebAPI (netcore 3.1). For authentication I use JWT at the moment.
I want to switch to a SSO-Solution. Since everything is running in company network, I would like to use Windows Authentication.
I managed to set up the API on IIS for Windows Authentication. But I am really stuck with the Blazor App...
I tried to set it up on IIS with WinAuth/Anonym and to use a simple GET-Request for Login, hoping that NTLM negotiation would pass the credentials from the browser to the API. Would be fine for me, if all further requests would use JWT. Even better if everything would work with WinAuth.
But whatever I try, I won't work. Does anybody has a tutorial or a least a concept I could use for the start?
Take a look at https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-azure-active-directory?view=aspnetcore-3.1.
This article shows how to secure both a Blazor front-end and .NET Core back-end api.
Related
I've been trying to learn some C# and decided to try a Blazor app. I've been building web apps for a long time but not in the MS world. In reading the blazor docs it seems that a client side blazor app cannot be secured by role, since the user could simply change any js parameters and visit pages arbitrarily. However, am I wrong to think that you can still secure the basic app built with client side blazor as far as authenticating users via OIDC or some other auth flow?
To put it another way, it sounds like a truly secure web app would be well advised to use the client side blazor setup, but would the client side work for an intranet scenario, where we only care about making sure users should be able to login, but aren't too concerned with what they do once they're in?
I have a repo here that enables roles via Blazor WASM.
This commit shows the changes I made to the template. Its important to transform the roles with the CustomUserFactory as they are in a string array.
Let's say I have an installed app, a console app for example, not a web app, that I want to interact with the QBO API - I want to perform calls to QBO from my console app (but not from a web application). So I must authenticate from the console app, make a call and output in the console.
All QBO SDKs seem to ask for a callback URL or a redirect URL, i.e. a page on my server, that will perform the required leg of the OAuth 2.0 authentication. As my installed app is not a webserver, I don't have a place to host this logic. Yes, I can host a webserver to handle this logic, but I don't want to do it, this is a waste of resources for my use case (why leave an auth server on standby?). I just want to authenticate without a webserver with QBO API. Is this possible? Have I messed up my understanding of the API or of OAuth? I am at a total loss. In none of the sample code I can find a suitable example despite this being the use case that I have. (I am working with .NET / C#)
It appears that at the moment the QuickBooks Developer platform will not accommodate this (non web End-Point).
As per Intuit:
These URIs handle responses from the OAuth 2.0 server and are called
after the user authorizes the connection. URIs in this list are the
only ones to which the authorization response can be sent from the
OAuth 2.0 server. You must define at least one URI specifically for
your application's auth endpoint before you can use OAuth 2.0.
Additionally they add in a note:
Mobile- or desktop-based apps that implement OAuth 2.0 must provide a
separate SaaS layer for the Redirect URI to handle responses from the
OAuth 2.0 server.
I realize this is not what you had hoped for. Please understand, however, understand that the end-point must be a URL so as to securely return the authentication token.
We currently have an ASP.NET Core MVC app in combination with IdentityServer4 for authentication. The user authenticates via IdentityServer (with the HybridAndClientCredentials flow) to ADFS before it has access to the MVC application.
The SignInScheme on the MVC client is set to the values "Cookies".
We would like to extend our MVC app to host multiple Angular apps. Sometimes even more than 1 Angular app per MVC view.
The angular apps will call seperate ASP.NET Core Web API's on behalf of the user.
My question is how does the angular apps know that the user is already authenticated in the MVC application, retrieve the access token and call the API's on the user behalf?
I have been playing around with solution Scott Brady came up with but there seems no integration between the MVC app & Angular app. The Angular app will try to authenticate to identityserver and expect a callback on a particular page.
I am looking for a solution how to share the accesstokens between the MVC app and the angular apps but I am stuck. Any help is much appreciated.
If they have to sign in via the server-side hybrid flow already then the simplest way would be an endpoint in your MVC app that is cookie-secured that the client side app can call to get the access token.
Another approach is to use oidc-client-js and have the client side Angular app obtain its own token.
You could abstract this away from the client side app itself so it's easy to change the mechanism later if you need to. As it happens we use a combination of server side and client side flows and it works fine.
I am developing a solution using .NET ASP Core. It's current version is monolithic, and I want to switch it to a service architecture consisting of an HTTP API which is used by the iOS/Android apps and web site. Here is a visual:
I am using .NET ASP Core on the website and service layers. I have almost finished implementing the changes, but I'm hung up on how to handle authentication on the area of the website that allows administrators to edit the content of the system. The monolithic version uses Identity Core (custom implementation, not using Entity) which works great. I could move the identity authentication code into the service, but I'm not sure how to then handle the authentication on the web site (the apps are public content only, no auth needed). How do I pass the username/password from the website to the service? How do I then track the session between the end user and service layer? Or is another option like OAUTH make more sense? I'd prefer a solution that doesn't require me to implement duplicate roles/policies on the website and service.
Any suggestions welcome, I have no experience with a setup like this so I'm not really even sure where to begin. Thanks!
OpenID Connect or OAuth makes sense because all of the claims/roles you already have will be encapsulated into the token. I presently use IdentityServer4 and it works just fine for your exact situation.
Since you are already using Identity database implementation doesn't matter as long as you have a back end. In the end the calls to the site are till http in nature, all very well documented.
http://www.identityserver.io
I have a problem authenticating against Sharepoint Project Web App, from my ASP.Net app. One of the last tricks in my pocket that could work is taking a web browser from Windows Forms package, and performing an auth in it. This browser will be hidden from the user, will use service account to authenticate and will populate some JSON from PWA once a day. I will emulate the normal authentication you go through if you login to PWA with your browser.
This feels a bad idea to me, but if I do not have any other options, I might go with it. The problem is that I can't really explain exactly why it is bad, thus my question.
What possible problems should I expect doing this? ASP.Net app will be hosted in Azure, we also do an auth on Azure.