Get User Identity

[kraftDeveloper]

Hello CoreWCF Community, I am trying to get the user identity of the client consumer from the current Http context with the following code:

var userIdentity = this.httpContextAccessor.HttpContext.User.Identity.Name;

Unfortunately, the Identity.Name property is always NULL in my case.

I am using a WSHttpBinding with Transport SecurityMode. The same binding works fine in classic WCF service to get the user identity this way.

WSHttpBinding wsBinding = new WSHttpBinding(SecurityMode.Transport);
wsBinding.Security.Mode = SecurityMode.Transport;
wsBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
wsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
wsBinding.Security.Message.NegotiateServiceCredential = false;
wsBinding.Security.Message.EstablishSecurityContext = false;

The httpContextAccessor instance is injected on the CreateHostBuilder method by services.AddHttpContextAccessor(); and given to the CoreWCF service instance in constructor

services.AddSingleton(typeof(PolicyService), (serviceProvider) =>
{
    return new PolicyService(
        serviceProvider.GetRequiredService<IHttpContextAccessor>());
});

Can someone help me in this case?

[birojnayak]

generally we should be able to get from OperationContext.. looks like CoreWCF is not populating in above situation.. please create an issue for me to debug... you should be able to get it from OperationContext, if your binding is TransportWithMessageCredential and Message.ClientCredentialType is Windows.

[kraftDeveloper]

Hi Biroj, I can access the HttContext in both ways, but my issue is that the given user identity is always null. In classic WCF using Transport-Binding, we get the user or machine name of the requesting client. We can only use Transport with the following settings:

WSHttpBinding wsBinding = new WSHttpBinding(SecurityMode.Transport);
wsBinding.Security.Mode = SecurityMode.Transport;
wsBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
wsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
wsBinding.Security.Message.NegotiateServiceCredential = false;
wsBinding.Security.Message.EstablishSecurityContext = false;

[birojnayak]

@kraftDeveloper it's actually null.. @mconnew I debugged the WCF codebase and it looks like we are missing the message properties. In WCF we populate based on the HttpsTransportBinding and a listener triggering the ProcessAuth here => https://referencesource.microsoft.com/#System.ServiceModel/System/ServiceModel/Channels/HttpRequestContext.cs,353 , whereas we are missing the same here

CoreWCF/src/CoreWCF.Http/src/CoreWCF/Channels/HttpRequestContext.cs

Line 378 in ae53e52

protected override SecurityMessageProperty OnProcessAuthentication()

.... to me it looks we have to port some code into HttpsTransportBindingElement and eventually a listener to get authentication context.... @mconnew let me know if you think otherwise

[mconnew]

You can get the HttpContext from the message properties. So you can go something like this:

var httpContext = OperationContext.Current.IncomingMessageProperties["Microsoft.AspNetCore.Http.HttpContext"] as HttpContext;
var claimsPrincipal = httpContext.User;

[gulbanana]

The existing support almost works for my use case; what's missing is that although RequestDelegateHandler calls my AuthenticationHandler, it doesn't populate HttpContext.User. Here's a snippet from RequestDelegateHandler:

            if (IsAuthenticationRequired)
            {
                string scheme = _httpSettings.AuthenticationScheme.ToString();
                AuthenticateResult authenticateResult = await context.AuthenticateAsync(scheme);
                if (authenticateResult.None)
                {
                    await context.ChallengeAsync(scheme);
                    return;
                }
            }

Compare to this section from ASP.NET Core's AuthenticationMiddleware:

            var defaultAuthenticate = await Schemes.GetDefaultAuthenticateSchemeAsync();
            if (defaultAuthenticate != null)
            {
                var result = await context.AuthenticateAsync(defaultAuthenticate.Name);
                if (result?.Principal != null)
                {
                    context.User = result.Principal;
                }
                if (result?.Succeeded ?? false)
                {
                    var authFeatures = new AuthenticationFeatures(result);
                    context.Features.Set<IHttpAuthenticationFeature>(authFeatures);
                    context.Features.Set<IAuthenticateResultFeature>(authFeatures);
                }
            }

AuthenticationMiddleware, which is what you get from UseAuthentication(), only operates on the default scheme, not the scheme configured by the CoreWCF binding. But when it successfully authenticates, it populates the HttpContext's principal - which is what CreateSecurityContextAsync() reads from later.

[DanielLaberge]

@mconnew: What is now the best way of accessing the Microsoft.AspNetCore.Http.HttpContext.User from a service implementation, in light of all the work on AspNet Authorization that was shipped since this discussion? I haven't found any example in the documentation, blog or samples.

[g7ed6e]

@DanielLaberge Please have a look to PR below in CoreWCF/samples. It uses ASP.NET Core AuthN/AuthZ with JwtBearer middleware. The ServiceContract implementation is pulling HttpContext.User in OperationContract implementation using the DI injected operation parameters feature.
https://github.com/CoreWCF/samples/pull/29/files#

[lonwabogiqwa]

Hello CoreWCF community, has there been a way to achieve getting user identity? I have tried OperationContext.Current.ClaimsPrincipal; but I am still getting null and also tried casting to (WindowsIdentity) but it's always null while on .NET Framework, HttpContext.Current.User gets the information

[ngvtien]

This is basically a back door method to get the underlying HttpContext. In .NET Framework if you enabled AspNetCompatibilityMode you could get it from the Thread local static HttpContext.Current. But in ASP.NET Core, it's passed around instead which is why it needs to be put in the incoming message properties. The correct solution is to propagate this claims principal from HttpContext.User to ServiceSecurityContext. This would be done by getting HttpContext.User.Identity to get an IIdentity from the ClaimsPrincipal and have that be available to ServiceSecurityContext.PrimaryIdentity. But there's a bunch more work that needs to be done too. For example, if Windows authentication is being used, the WindowsIdentity needs to be correctly populated if possible (not on Linux though). AuthorizationPolicies and AuthorizationContext also needs to be populated so that all the other claims information is available too. For example, if using client certificate authentication, then there's an X509Certificate2ClaimsSet that needs to be populated with all the certificate information. We're focusing on things which you can't find an alternative solution to first. As you've seen, you can get the info you need from the HttpContext via the message properties, so this is a lower priority. Especially as it's not just porting code, it's writing a lot of new code and digging into some of the guts of ASP.NET Core to pull out information which isn't easily available.

I'm looking for any samples on how to use wshttpbinding with transport security set to certificate via using the AspNetCore AuthN/AuthZ