I am currently developing in a standalone (Not .Net Core Hosted) Blazor WebAssembly app in .Net 5.0. I have been trying to convert a couple Asp.Net MVC WebAuthn examples over into my Blazor app for Passwordless Authentication.
The issue I am experiencing now is due to this app's architecture since it is not a Blazor Server app. The Asp.Net MVC example I am following has everything including the client hosted on the server whereas my app is split Web Client/ Web API architecture.
So far however, I have managed to get most of the way through these differences but now the issue I am having is in the last functionality of registering the credential with the server within the Make Credential request of the Fido2NetLib Library. on line:
// 2. Verify and make the credentials
var success = await _lib.MakeNewCredentialAsync(attestationResponse, options, callback);
I am receiving an error saying: "Origin https://localhost:44325 not equal to original origin https://localhost:44309". Now of course this is a dev environment but it will be exactly the same in production as the API and the client are hosted in two different domains.
Any ideas would be greatly appreciated. I am hoping I can "white list" certain domains?
WebAuthn defines the origin to be the fully qualified origin. Per referenced RFC6454, this is the tuple of scheme, host, and port. You can't go breaking the rules without deviating from the standard.
WebAuthn gels very well with using a separate identity provider (e.g. something Open ID Connect/IdentityServer4-based) as the origin that deals with credentials will always be the same regardless of the relying parties involved.
Related
I have two client applications : Asp.Net MVC Core web app and an Android native mobile app, and an IdentityServer4 Server as an OpenID Server`.
I know that I have to create two client records for both of them (in the IS4's Clients table) :
a Hybrid Flow for the web app
a Hybrid/Authorization Code + PKCE for the native mobile app
But I'm wondering if I can create only one Client info for both of them or not?
I think you should create one client definition for each client, so you better can separate them and better evolve them as needed over time. Also makes it easier to separate them in the logs for example.
A question is however why/if you really need to support the hybrid flow? I think both clients only need to use the authorization code flow.
If you want to follow OAuth 2.1, then there are only two flows to use, either authorization code flow or client credentials flow. All other flows are not recommended due to various security issues. See https://oauth.net/2.1/
Tore's answer gives good reasons to keep those clients separated. If you're still not convinced, I would turn the question around - why do you want to have one logical client data used by two separate clients? This will cause some weird issues in the future. For example, at some point you might want to rate-limit one of those clients, or change client authentication method, or even block one of them completely. You will have to do it for both your apps if you don't create a separate client.
From the security point of view, there is a good reason to keep those two separated: the web client can be a confidential client with a secret assigned. The mobile client will be a public client, without a secret*. This is a solid reason not to mix those two, as you will lower the strength of your security considerably.
*In fact, best practice would be to use DCR and register a new client for each device where your app runs.
I've got 2 different .NET Core 2.2 MVC projects. I'm using IdentityServer4 for the token server, Azure B2C for the identity store.
The 1st MVC app is a normal MVC application, and I've got it working perfectly with the OIDC Hybrid flow.
The 2nd MVC app is an Angular 7 cli app, which serves up the index.html and houses the API that the app will be calling. The angular app will not call any other APIs directly (gateway pattern).
My questions are about the 2nd app - I'm trying to figure out the best way to set up the Angular app for security.
My understanding is: OIDC Implicit flow exposes exposes the access token on the browser. OIDC Hybrid flow does not expose the access token (at least when hitting the same web server - no CORS), because the web server (client) uses the back channel to obtain the access token, via the authorization code, and its never exposed to the browser.
QUESTION #1: Is my understanding of Implicit vs. Hybrid correct?
If my understanding is correct, I'd think the best way to go would be Hybrid flow even for the Angular app, but most samples I've seen for using OIDC with Angular involve the Implicit flow, and don't take advantage of the authorization code / backchannel. Avoiding having an access token on the browser seems like a big deal, like a worthy goal, but wondering why it doesn't seem to be done?
QUESTION #2: I'm serving up my Angular index.html from my MVC server - why can't I just use Hybrid flow to protect the index.html page, and keep the token on the backchannel?
Something tells me my understanding of all this isn't quite complete...
Your understanding is correct. You can protect your index.html. The only problem you will face that way is that it's not the default configuration for today. With your requirements, most likely you don't need any of oidc client libs at all, you can protect your (only) API with a (same-site, http-only) cookie (not a bearer token) and in your Angular guards just ensure that you are still logged in to your back (if not, redirect through a local MVC resource to involve server-side code into login procedure).
See this question, especially the comments and link below for further reference.
Background:
I've implemented a Web-API (.NET), now I need to do the most important thing,
Secure it.
As I investigate this topic I understand that the common way is the Bearer Token.
Now we getting to my problem.
My Problem
On one side:
Every article I saw (that explains the concept and the way to implement it over .NET) starts from a project with a Web API template that holds MVC and Web API and in the authentication field choose one option from Individual / Organizational / Windows .
On the other side:
I don't need a MVC project, I need only Web API (without any GUI) that the reason I choose the empty project and check the Web API checkbox, in that way I cant choose an authentication type, I forced to start with no authentication.
Questions:
1.Do I bound to use MVC to get authentication ? if not how can I do it from pure Web API project ?
2.Maybe I will create an Authentication Server (that only generates tokens) from that Web API template (with the possibility of choosing authentication type) ? (and use the token on the real Web API)
3.There is any benefits of implement the Authentication Server on a different project and on different server ? (Kerberos style )
P.S I want to use an out of the box solution because the security aspect is the most important one (to my opinion) and should be flawless.
I wrote a blog on this topic called 'Securing and securely calling Web API and [Authorize]': http://blogs.msdn.com/b/martinkearn/archive/2015/03/25/securing-and-working-securely-with-web-api.aspx. I think if you read this, you'll have all your answers.
The Web API template does include MVC by default so that you get the automated docs feature (which is a great feature to have). However the authentication part is related to a core ASP.net feature, not specific to MVC or Web API. You'll need to enable one of the authentication options to secure your API using .net's built in security features.
If you do not want the MVC project that comes with Web API, just delete it after the project has been created. It is contained within the 'areas' folder. If you delete that folder, you'll be running on pure web api.
To answer your specific questions:
1) No you do not need an MVC project to secure an API project. You can use the [Authorize] attribute on your API controllers and actions.
2) an authentication server gets created by default with the web api template. You can access it and get tokens via http:///Token
3) No, you need to use the api itself to serve valid tokens for secured controller/action requests
Hope that helps. If not, then please be a bit more specific with your questions.
I got a MVC web application that authorizes users through Azure ACS. Now I want my web application to make calls to my WCF services. Since these services can be called by other applications I want them to be secured through ACS also. I'm at a loss on how to set this up. Can I reuse the security tokens in my WCF service calls somehow?
Formally you can't because these are 2 different (autonomous) "apps". Tokens are issued for a specific app (or "Relying Party"). Your website should request a second token for the web service. You have 2 options:
1- Simply get a token under a service identity (that is the identity the web site is assuming) and attach it to your calls to the web service. WCF bindings support this out of the box (albeit complex, as any WCF configuration),.
2- Get a token for WCF "on behalf" of the original user. This is a delegation scenario, in which the identity of the original caller to the web app is transferred to the service.
The first option is rather simple (putting aside the WCF specifics). The second option is more complex one and not supported in ACS (as far as I know), because it requires a special endpoint that understands and issues ActAs tokens.
You could use the same token for both the web site and the service if you own both and are "the same app". This is a pragmatic shortcut and not a pure implementation, and might have other implications (e.g. the same app in ACS, the WCF can't easily distinguish that it is being called from your website or external parties, etc).
In that case, the MVC app must keep the token that was sent to it. There's a setting for that (bootstraptoken=true). The WIF API in .NET 4.5 changed a little bit, so there might be something else.
I am trying to get a SAML 2.0 token from an ADFS 2.0 ws-trust service using C#. The popular sample is this one http://leastprivilege.com/2012/11/16/wcf-and-identity-in-net-4-5-external-authentication-with-ws-trust/. However, this sample uses a UserNameWSTrustBinding which, according to this article http://msdn.microsoft.com/en-us/library/jj157091.aspx, did not make the jump to the System.IdentityModel namespace for 4.5.
I have been experimenting with this sample and some variants that I have found, but so far, the only results that I can get are a variety of error messages. I am wondering if there is any good way to debug the latest one, "The request for security token has invalid or malformed elements.". I turned on WCF logging on and determined that this message is being returned as a fault by the ADFS service.
Reviewing the AD FS 2.0/Admin events on the ADFS server, there is no indication of an error. Several posts indicate that this is common in an ADFS farm environment, but mine is a simple single server configuration.
Does anyone have a good way to diagnose this? Or, is there a good sample that comes with any configuration requirements on the ADFS server side?
This link http://social.msdn.microsoft.com/Forums/en/Geneva/thread/33fc091b-505c-481c-a61c-a8541a5ccf23 shows how to enable WCF and WIF tracing for the server side of ADFS 2.0. Modify the config file at C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config. (Change the three switchValue settings to Verbose and modify the trace listeners.) While following the instructions, make sure to change the types on the listeners. Something like
<add name="ADFSWifListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\adfs1.svclog" />
I also had to grant "Everyone" full access to the C:\Logs folder, you can refine those permissions with auditing if you like. Once the .svclog files have been created, they can be viewed with SvcTraceViewer.exe in %ProgramFiles%/Microsoft SDKs/Windows/v8.0A/bin/NETFX 4.0 Tools (or any other SDK version probably).
NOTE: Microsoft will not support the notion of logging trace data directly to a file, so you will want to turn this off or configure according to this article http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(WS.10).aspx for a production deployment.