From 343874076180facfd56a9d67fb96bdc5571285f3 Mon Sep 17 00:00:00 2001 From: g7ed6e Date: Wed, 7 Dec 2022 16:20:57 +0100 Subject: [PATCH 1/8] Add Authorization post --- ...-aspnetcore-authorization-support.markdown | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 _posts/2022-12-07-aspnetcore-authorization-support.markdown diff --git a/_posts/2022-12-07-aspnetcore-authorization-support.markdown b/_posts/2022-12-07-aspnetcore-authorization-support.markdown new file mode 100644 index 0000000..8ad2709 --- /dev/null +++ b/_posts/2022-12-07-aspnetcore-authorization-support.markdown @@ -0,0 +1,107 @@ +--- +# Layout +layout: post +title: "Introducing ASP.NET Core Authorization support and modernization of legacy WCF Authentication and Authorization APis" +date: 2022-12-07 13:00:00 +0100 +categories: release +# Author +author: Guillaume Delahaye (https://github.com/g7ed6e) +--- +### Introduction +Next release of CoreWCF will bring support of ASP.NET Core Authorization to allow developers to use ASP.NET Core builtin authentication middleware such as the `Microsoft.AspNetCore.Authentication.JwtBearer` and apply appropriate authorization policies. + +### Builtin attributes support +When working with ASP.NET Core MVC usually developers use `[Authorize]` and `[AllowAnonymous]` to decorate actions that require specific authorizations. +#### Authorize support +To enable a seamless developer experience we brought the ability to decorate `OperationContract` implementation with the ASP.NET Core Authorize attribute. However we introduced the below limitations to suggest developers to embrace the flexible [Policy-based](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-6.0) model based on `IAuthorizationRequirement`. +- `AuthenticationSchemes` property is not supported and will trigger a build warning `COREWCF_0201`. +- `Roles` property is not supported and will trigger a build warning `COREWCF_0202`. + +#### AllowAnonymous support +We did not bring support of the `[AllowAnonymous]` attribute as we believe that a strong interface segregation between anonymous and secured operations should be set. Moreover supporting this attribute would imply delaying the authentication step in the pipeline leading to potential DDoS vulnerabilities. Decorating an `OperationContract` implementation with `[AllowAnonymous]` will have no effect and will trigger a build warning `COREWCF_0200`. +### Configuration +To setup this feature in your CoreWCF application you should follow the below steps. I will assume there that we want to enforce clients are authenticating using a JWT Bearer token issued by an authorization server `https://authorization-server-uri`, the service should be protected by the audience `my-audience` and two policies should be defined, one requiring a scope `read` and another one requiring a scope `write`. +1. Register authentication infrastructure services and configure JWT Bearer authentication middleware as default `AuthenticationScheme`. (Internally CoreWCF is calling `HttpContext.AuthenticateAsync()` with the default registered authentication scheme). +```csharp +services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) +.AddJwtBearer(options => +{ + options.Authority = "https://authorization-server-uri"; + options.Audience = "my-audience"; +}); +``` +2. Register authorization infrastructure services and policies. +```csharp +services.AddAuthorization(options => +{ + options.DefaultPolicy = new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme).RequireClaim("scope", "read").Build(); + options.AddPolicy("WritePolicy", new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme).RequireClaim("scope", "write").Build()); +}) +``` +3. Configure your service to use ASP.NET Core Authentication and Authorization middlewares setting the `ClientCredentialType` to `HttpClientCredentialType.InheritedFromHost`. +```csharp +app.UseServiceModel(builder => +{ + builder.AddService(); + builder.AddServiceEndpoint(new BasicHttpBinding + { + Security = new BasicHttpSecurity + { + Mode = BasicHttpSecurityMode.Transport, + Transport = new HttpTransportSecurity + { + ClientCredentialType = HttpClientCredentialType.InheritedFromHost + } + } + }, "/BasicWcfService/basichttp.svc"); +} +``` +4. Decorate your service implementation +```csharp +[ServiceContract] +public interface ISecuredService +{ + [OperationContract] + string ReadOperation(); + [OperationContract] + void WriteOperation(string value); +} + +public class SecuredService : ISecuredService +{ + [Authorize] + public string ReadOperation() => "Hello world"; + + [Authorize(Policy = "WritePolicy")] + public void WriteOperation(string value) { } +} +``` +### Supported bindings + +ASP.NET Core Authorization policies support is implemented in http based bindings: +- `BasicHttpBinding` +- `WSHttpBinding` +- `WebHttpBinding` + +### Authorization evaluation position in CoreWCF request pipeline + +There's an important difference regarding the "when" authorization evaluation occurs between `ServiceAuthorizationManager` usage and the ASP.NET Core Authorization usage. + +When using ASP.NET Core Authorization, ths below steps will be executed **before** authorization which didn't when using `ServiceAuthorizationManager`. + +- When setup, dynamic quota throttle acquisition. +- Calls to registered `IDispatchMessageInspector.AfterReceiveRequest` +- Concurrency lock acquisition + +Another impact is that authorization will now run on a captured `SynchronizationContext`. This point can impact CoreWCF services hosted in a UI thread (WPF or WinForms app). + +### Exclusiveness of ASP.NET Core Authorization policies and `ServiceAuthorizationManager` + +Having `ClientCredentialType` set to `InheritedFromHost` disable the execution of an authorization logic implemented in `ServiceAuthorizationManager`. + +### `ServiceAuthenticationManager` and `ServiceAuthorizationManager` API modernization + +Both implementations now support asynchronous implementations. Existing synchronous implementations will still be compatible but have been deprecated and will trigger a build warning. + +### Conclusion +CoreWCF provides flexibility around authentication and authorization allowing implementation of more up to date security standards and programming patterns well known from developers. \ No newline at end of file From ed7c08d729c84feafaa0856cc9806644bb3710c5 Mon Sep 17 00:00:00 2001 From: g7ed6e Date: Fri, 16 Dec 2022 07:45:59 +0100 Subject: [PATCH 2/8] Fix text after review --- ...12-07-aspnetcore-authorization-support.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_posts/2022-12-07-aspnetcore-authorization-support.markdown b/_posts/2022-12-07-aspnetcore-authorization-support.markdown index 8ad2709..a990c33 100644 --- a/_posts/2022-12-07-aspnetcore-authorization-support.markdown +++ b/_posts/2022-12-07-aspnetcore-authorization-support.markdown @@ -2,25 +2,25 @@ # Layout layout: post title: "Introducing ASP.NET Core Authorization support and modernization of legacy WCF Authentication and Authorization APis" -date: 2022-12-07 13:00:00 +0100 +date: 2022-12-16 07:00:00 +0100 categories: release # Author author: Guillaume Delahaye (https://github.com/g7ed6e) --- ### Introduction -Next release of CoreWCF will bring support of ASP.NET Core Authorization to allow developers to use ASP.NET Core builtin authentication middleware such as the `Microsoft.AspNetCore.Authentication.JwtBearer` and apply appropriate authorization policies. +The latest release of CoreWCF will bring support of ASP.NET Core Authorization to allow developers to use ASP.NET Core builtin authentication middleware such as the `Microsoft.AspNetCore.Authentication.JwtBearer` and apply appropriate authorization policies. ### Builtin attributes support When working with ASP.NET Core MVC usually developers use `[Authorize]` and `[AllowAnonymous]` to decorate actions that require specific authorizations. #### Authorize support -To enable a seamless developer experience we brought the ability to decorate `OperationContract` implementation with the ASP.NET Core Authorize attribute. However we introduced the below limitations to suggest developers to embrace the flexible [Policy-based](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-6.0) model based on `IAuthorizationRequirement`. +To enable a seamless developer experience we brought the ability to decorate an `OperationContract` implementation with the ASP.NET Core Authorize attribute. However we introduced the below limitations to suggest developers to embrace the flexible [Policy-based](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-6.0) model based on `IAuthorizationRequirement`. - `AuthenticationSchemes` property is not supported and will trigger a build warning `COREWCF_0201`. - `Roles` property is not supported and will trigger a build warning `COREWCF_0202`. #### AllowAnonymous support -We did not bring support of the `[AllowAnonymous]` attribute as we believe that a strong interface segregation between anonymous and secured operations should be set. Moreover supporting this attribute would imply delaying the authentication step in the pipeline leading to potential DDoS vulnerabilities. Decorating an `OperationContract` implementation with `[AllowAnonymous]` will have no effect and will trigger a build warning `COREWCF_0200`. +We did not bring support of the `[AllowAnonymous]` attribute as we believe that a strong interface segregation between anonymous and secured operations should be set. Moreover supporting this attribute would imply delaying the authentication step in the pipeline leading to potential DoS vulnerabilities. Decorating an `OperationContract` implementation with `[AllowAnonymous]` will have no effect and will trigger a build warning `COREWCF_0200`. ### Configuration -To setup this feature in your CoreWCF application you should follow the below steps. I will assume there that we want to enforce clients are authenticating using a JWT Bearer token issued by an authorization server `https://authorization-server-uri`, the service should be protected by the audience `my-audience` and two policies should be defined, one requiring a scope `read` and another one requiring a scope `write`. +To setup this feature in your CoreWCF application you should follow the below steps. I'm assuming that we want to enforce clients authenticating using a JWT Bearer token issued by an authorization server `https://authorization-server-uri`, the service should be protected by the audience `my-audience` and two policies should be defined, one requiring a scope `read` and another one requiring a scope `write`. 1. Register authentication infrastructure services and configure JWT Bearer authentication middleware as default `AuthenticationScheme`. (Internally CoreWCF is calling `HttpContext.AuthenticateAsync()` with the default registered authentication scheme). ```csharp services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) @@ -97,11 +97,11 @@ Another impact is that authorization will now run on a captured `Synchronization ### Exclusiveness of ASP.NET Core Authorization policies and `ServiceAuthorizationManager` -Having `ClientCredentialType` set to `InheritedFromHost` disable the execution of an authorization logic implemented in `ServiceAuthorizationManager`. +Having `ClientCredentialType` set to `InheritedFromHost` disables the execution of an authorization logic implemented in `ServiceAuthorizationManager`. ### `ServiceAuthenticationManager` and `ServiceAuthorizationManager` API modernization -Both implementations now support asynchronous implementations. Existing synchronous implementations will still be compatible but have been deprecated and will trigger a build warning. +These two classes now have async versions of the virtual methods which you can override. The existing synchronous method have been deprecated using the `Obsolete` attribute and will cause a build warning if you override them. If you are overriding one of the existing synchronous virtual methods, your code will continue to function the same as it always has and will continue to do so for all future 1.x releases. The synchronous variations of the methods will likely be removed in a future 2.x release. You can safely suppress the build warning until you have migrated your implementation to the async methods. ### Conclusion CoreWCF provides flexibility around authentication and authorization allowing implementation of more up to date security standards and programming patterns well known from developers. \ No newline at end of file From 0ddd64a7a5afe4326d9b36c17ed1db764525a4d6 Mon Sep 17 00:00:00 2001 From: g7ed6e Date: Fri, 16 Dec 2022 17:22:34 +0100 Subject: [PATCH 3/8] Explicit secured JWT validation and authentication scheme --- ...07-aspnetcore-authorization-support.markdown | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/_posts/2022-12-07-aspnetcore-authorization-support.markdown b/_posts/2022-12-07-aspnetcore-authorization-support.markdown index a990c33..115796b 100644 --- a/_posts/2022-12-07-aspnetcore-authorization-support.markdown +++ b/_posts/2022-12-07-aspnetcore-authorization-support.markdown @@ -24,18 +24,29 @@ To setup this feature in your CoreWCF application you should follow the below st 1. Register authentication infrastructure services and configure JWT Bearer authentication middleware as default `AuthenticationScheme`. (Internally CoreWCF is calling `HttpContext.AuthenticateAsync()` with the default registered authentication scheme). ```csharp services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) -.AddJwtBearer(options => +.AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options => { options.Authority = "https://authorization-server-uri"; options.Audience = "my-audience"; + options.TokenValidationParameters = new TokenValidationParameters + { + ValidateIssuer = true, + ValidateAudience = true, + ValidateLifetime = true, + RequireSignedTokens = true, + }; }); ``` 2. Register authorization infrastructure services and policies. ```csharp services.AddAuthorization(options => { - options.DefaultPolicy = new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme).RequireClaim("scope", "read").Build(); - options.AddPolicy("WritePolicy", new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme).RequireClaim("scope", "write").Build()); + options.DefaultPolicy = new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme) + .RequireClaim("scope", "read") + .Build(); + options.AddPolicy("WritePolicy", new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme) + .RequireClaim("scope", "write") + .Build()); }) ``` 3. Configure your service to use ASP.NET Core Authentication and Authorization middlewares setting the `ClientCredentialType` to `HttpClientCredentialType.InheritedFromHost`. From 1117925dd3cacc052bfc68eed0accf329c473df3 Mon Sep 17 00:00:00 2001 From: g7ed6e Date: Wed, 28 Dec 2022 15:01:40 +0100 Subject: [PATCH 4/8] Document workaround for the issue between System.* and Microsoft.Identity.* JWT packages --- ...-aspnetcore-authorization-support.markdown | 22 +++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/_posts/2022-12-07-aspnetcore-authorization-support.markdown b/_posts/2022-12-07-aspnetcore-authorization-support.markdown index 115796b..6d9fedb 100644 --- a/_posts/2022-12-07-aspnetcore-authorization-support.markdown +++ b/_posts/2022-12-07-aspnetcore-authorization-support.markdown @@ -21,7 +21,16 @@ To enable a seamless developer experience we brought the ability to decorate an We did not bring support of the `[AllowAnonymous]` attribute as we believe that a strong interface segregation between anonymous and secured operations should be set. Moreover supporting this attribute would imply delaying the authentication step in the pipeline leading to potential DoS vulnerabilities. Decorating an `OperationContract` implementation with `[AllowAnonymous]` will have no effect and will trigger a build warning `COREWCF_0200`. ### Configuration To setup this feature in your CoreWCF application you should follow the below steps. I'm assuming that we want to enforce clients authenticating using a JWT Bearer token issued by an authorization server `https://authorization-server-uri`, the service should be protected by the audience `my-audience` and two policies should be defined, one requiring a scope `read` and another one requiring a scope `write`. -1. Register authentication infrastructure services and configure JWT Bearer authentication middleware as default `AuthenticationScheme`. (Internally CoreWCF is calling `HttpContext.AuthenticateAsync()` with the default registered authentication scheme). +1. Install JWT Bearer authentication package +```xml + +``` +*Note: Due to this [issue](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/1792), you have to explicitly reference the latest version of `Microsoft.IdentityModel.Protocols.OpenIdConnect` after installing `Microsoft.AspNetCore.Authentication.JwtBearer`*. +```xml + +``` + 2. Register authentication infrastructure services and configure JWT Bearer authentication middleware as default `AuthenticationScheme`. (Internally CoreWCF is calling `HttpContext.AuthenticateAsync()` with the default registered authentication scheme). + ```csharp services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options => @@ -36,20 +45,25 @@ services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) RequireSignedTokens = true, }; }); + ``` -2. Register authorization infrastructure services and policies. + + +3. Register authorization infrastructure services and policies. ```csharp services.AddAuthorization(options => { options.DefaultPolicy = new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme) + .RequireAuthenticatedUser() .RequireClaim("scope", "read") .Build(); options.AddPolicy("WritePolicy", new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme) + .RequireAuthenticatedUser() .RequireClaim("scope", "write") .Build()); }) ``` -3. Configure your service to use ASP.NET Core Authentication and Authorization middlewares setting the `ClientCredentialType` to `HttpClientCredentialType.InheritedFromHost`. +4. Configure your service to use ASP.NET Core Authentication and Authorization middlewares setting the `ClientCredentialType` to `HttpClientCredentialType.InheritedFromHost`. ```csharp app.UseServiceModel(builder => { @@ -67,7 +81,7 @@ app.UseServiceModel(builder => }, "/BasicWcfService/basichttp.svc"); } ``` -4. Decorate your service implementation +5. Decorate your service implementation ```csharp [ServiceContract] public interface ISecuredService From 1e637974dc26186695c170165e878fbe0d800ef7 Mon Sep 17 00:00:00 2001 From: g7ed6e Date: Sun, 19 Feb 2023 09:43:00 +0100 Subject: [PATCH 5/8] Add a few words about about middlewares's order and FallbackPolicy --- ...=> 2023-02-19-aspnetcore-authorization-support.markdown} | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) rename _posts/{2022-12-07-aspnetcore-authorization-support.markdown => 2023-02-19-aspnetcore-authorization-support.markdown} (92%) diff --git a/_posts/2022-12-07-aspnetcore-authorization-support.markdown b/_posts/2023-02-19-aspnetcore-authorization-support.markdown similarity index 92% rename from _posts/2022-12-07-aspnetcore-authorization-support.markdown rename to _posts/2023-02-19-aspnetcore-authorization-support.markdown index 6d9fedb..de837de 100644 --- a/_posts/2022-12-07-aspnetcore-authorization-support.markdown +++ b/_posts/2023-02-19-aspnetcore-authorization-support.markdown @@ -2,7 +2,7 @@ # Layout layout: post title: "Introducing ASP.NET Core Authorization support and modernization of legacy WCF Authentication and Authorization APis" -date: 2022-12-16 07:00:00 +0100 +date: 2023-02-19 07:00:00 +0100 categories: release # Author author: Guillaume Delahaye (https://github.com/g7ed6e) @@ -108,6 +108,10 @@ ASP.NET Core Authorization policies support is implemented in http based binding - `WSHttpBinding` - `WebHttpBinding` +### FallbackPolicy support + +ASP.NET Core 3.0 introduced a `FallbackPolicy`. This authorization policy is executed when no policy is configured for a given endpoint. As CoreWCF does not expose its endpoints to the endpoint routing infrastructure, this policy may be executed depending on the configured request pipeline. To avoid the FallbackPolicy being executed the call to CoreWCF middleware (i.e `UserServiceModel(...)`should occur before the call to the authorization middleware `UseAuthorization(...)`. + ### Authorization evaluation position in CoreWCF request pipeline There's an important difference regarding the "when" authorization evaluation occurs between `ServiceAuthorizationManager` usage and the ASP.NET Core Authorization usage. From 616d56d5f4dcf3638bef46b3ce82b5de4ab4108b Mon Sep 17 00:00:00 2001 From: g7ed6e Date: Sun, 19 Feb 2023 09:49:57 +0100 Subject: [PATCH 6/8] Add links to the samples --- .../2023-02-19-aspnetcore-authorization-support.markdown | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/_posts/2023-02-19-aspnetcore-authorization-support.markdown b/_posts/2023-02-19-aspnetcore-authorization-support.markdown index de837de..245f591 100644 --- a/_posts/2023-02-19-aspnetcore-authorization-support.markdown +++ b/_posts/2023-02-19-aspnetcore-authorization-support.markdown @@ -132,5 +132,12 @@ Having `ClientCredentialType` set to `InheritedFromHost` disables the execution These two classes now have async versions of the virtual methods which you can override. The existing synchronous method have been deprecated using the `Obsolete` attribute and will cause a build warning if you override them. If you are overriding one of the existing synchronous virtual methods, your code will continue to function the same as it always has and will continue to do so for all future 1.x releases. The synchronous variations of the methods will likely be removed in a future 2.x release. You can safely suppress the build warning until you have migrated your implementation to the async methods. +### Samples + +[CoreWCF\Samples repo](https://github.com/CoreWCF/samples) provides samples: + +- [Minimal machine to machine using JWT](https://github.com/CoreWCF/samples/pull/29) +- [Mixed auth JWT/Anonymous with AllowAnonymous workaround](https://github.com/CoreWCF/samples/pull/34) + ### Conclusion CoreWCF provides flexibility around authentication and authorization allowing implementation of more up to date security standards and programming patterns well known from developers. \ No newline at end of file From 19f5aec452847a3de38fa2aee40f13494e5cf8e4 Mon Sep 17 00:00:00 2001 From: g7ed6e Date: Sun, 19 Feb 2023 10:01:50 +0100 Subject: [PATCH 7/8] fix typos --- _posts/2023-02-19-aspnetcore-authorization-support.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2023-02-19-aspnetcore-authorization-support.markdown b/_posts/2023-02-19-aspnetcore-authorization-support.markdown index 245f591..79a0d07 100644 --- a/_posts/2023-02-19-aspnetcore-authorization-support.markdown +++ b/_posts/2023-02-19-aspnetcore-authorization-support.markdown @@ -110,7 +110,7 @@ ASP.NET Core Authorization policies support is implemented in http based binding ### FallbackPolicy support -ASP.NET Core 3.0 introduced a `FallbackPolicy`. This authorization policy is executed when no policy is configured for a given endpoint. As CoreWCF does not expose its endpoints to the endpoint routing infrastructure, this policy may be executed depending on the configured request pipeline. To avoid the FallbackPolicy being executed the call to CoreWCF middleware (i.e `UserServiceModel(...)`should occur before the call to the authorization middleware `UseAuthorization(...)`. +ASP.NET Core 3.0 introduced a `FallbackPolicy`. This authorization policy is executed when no policy is configured for a given endpoint. As CoreWCF does not expose its endpoints to the endpoint routing infrastructure, this policy may be executed depending on the configured request pipeline. To avoid the FallbackPolicy being executed the call to CoreWCF middleware (i.e `UseServiceModel(...)`) should occur before the call to the authorization middleware (i.e `UseAuthorization(...)`). ### Authorization evaluation position in CoreWCF request pipeline From 1168fe6fdf386aa16c871142c50c7834e724c708 Mon Sep 17 00:00:00 2001 From: Matt Connew Date: Wed, 19 Apr 2023 15:07:28 -0700 Subject: [PATCH 8/8] Remove backticks in section heading When quoting class names with back ticks in section headings it renders strange as the class name is rendered in a lot smaller font. --- _posts/2023-02-19-aspnetcore-authorization-support.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2023-02-19-aspnetcore-authorization-support.markdown b/_posts/2023-02-19-aspnetcore-authorization-support.markdown index 79a0d07..9d2aa61 100644 --- a/_posts/2023-02-19-aspnetcore-authorization-support.markdown +++ b/_posts/2023-02-19-aspnetcore-authorization-support.markdown @@ -128,7 +128,7 @@ Another impact is that authorization will now run on a captured `Synchronization Having `ClientCredentialType` set to `InheritedFromHost` disables the execution of an authorization logic implemented in `ServiceAuthorizationManager`. -### `ServiceAuthenticationManager` and `ServiceAuthorizationManager` API modernization +### ServiceAuthenticationManager and ServiceAuthorizationManager API modernization These two classes now have async versions of the virtual methods which you can override. The existing synchronous method have been deprecated using the `Obsolete` attribute and will cause a build warning if you override them. If you are overriding one of the existing synchronous virtual methods, your code will continue to function the same as it always has and will continue to do so for all future 1.x releases. The synchronous variations of the methods will likely be removed in a future 2.x release. You can safely suppress the build warning until you have migrated your implementation to the async methods. @@ -140,4 +140,4 @@ These two classes now have async versions of the virtual methods which you can o - [Mixed auth JWT/Anonymous with AllowAnonymous workaround](https://github.com/CoreWCF/samples/pull/34) ### Conclusion -CoreWCF provides flexibility around authentication and authorization allowing implementation of more up to date security standards and programming patterns well known from developers. \ No newline at end of file +CoreWCF provides flexibility around authentication and authorization allowing implementation of more up to date security standards and programming patterns well known from developers.