ANCM should forward the mapped Identity instead of the client certificate after IIS Client Cert Mapping Auth

[mertozturk80]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

We are trying to use IIS Client Certificate mapping authentication together with ASP.NET Out of process handler. We see that ANCM module add MS-ASPNETCORE-CLIENTCERT header to pass the certificate blob to the core process, but this prevent the target asp.net core process to lose the mapped user context.

In other words: with IIS Client cert mapping(authmap.dll), IIS maps the certificate into a Windows identity. For the mapping to work IIS should forward the identity handle, not the certificate. The certificate no longer matters at that point, and aspnet core doesn’t know about or have the ability to take a client certificate and map it to a user. That doesn’t appear to be happening in ANCM, the IIS integration piece.

I know that after a successful certificate mapping , the User Context and the cached token is at the same place (HTTP Context), so hopefully it wont be a difficult change:

aspnetcore/src/Servers/IIS/AspNetCoreModuleV2/OutOfProcessRequestHandler/forwardinghandler.cpp

Line 814 in 52eff90

if (fForwardWindowsAuthToken &&

Thanks,
Mert

Describe the solution you'd like

We would like to add IIS Certificate Mapping Authentication Integration to ANCM, via forwarding the identity handled instead of cert blob.

Additional context

No response

[blowdart]

I think we might want to do both, pass the certificate and the windows identity. It'd be unexpected to not have access to the certificate as well.

[adityamandaleeka]

@mertozturk80 Does using in-process hosting avoid this issue?

[mertozturk80]

@adityamandaleeka , no it does not avoid the issue.

[mertozturk80]

@blowdart, yes, but from the IIS integration perspective: passing the client cert i think have lower priority (nice to have), since its more important to pass the mapped identity. If we make sure that there is a IIS certificate mapped "user context", certificate have not much importance from that point on. Can be good for proxy scenarios may be?

[maras28]

I did the testing in my environment with an API app (.NET 6.0) hosted in IIS with both in-process and out-of-process cases. I was really hoping that in-process would work. However, even with in-process, the request results in 401 Unauthorized. I have the FREP logs. Client cert mapping auth maps the incoming cert to a Windows user but still the security context does not appear to be set on the application side. See the screenshot below.

[blowdart]

@maras28 Yea it's not a supported configuration yet. Usually this setup has been for impersonation purposes, and we've moved on from inpersonation because more folks got it wrong than right, and with more modern auth it's not been needed.

@adityamandaleeka I think it's too late to get this in 7, but could come as a new feature somewhere between 7 & 8, as ancm is stand alone?

[adityamandaleeka]

@blowdart Any reason why it shouldn't just happen in 8?

[blowdart]

It's stand alone like ancm, so 🤷‍♂️ If folks are happen to wait then sure

[halter73]

What do you mean by "it's stand alone"?

[maras28]

If this, ANCM with this feature, could be released sooner, it would really help with a customer scenario in a hybrid Azure scenario where Azure API Management Self Hosted Gateway could authenticate against an existing on-prem API secured with Windows Authentication without code changes but with only IIS side configuration change (Client Certificate Authentication mapping).

[blowdart]

@halter73 in theory it shouldn't need any extra work in asp.net middleware. In theory :)

[Tratcher]

@blowdart The affected in-proc code is probably in the part of ANCM that ships with AspNetCore, not in the stand-alone shim. The shim is mainly responsible for finding the runtime, not processing requests. Out-of-proc doesn't have that separation and could apply to earlier versions, but we still only ship new ANCMs with new versions of AspNetCore.