Problema con reclamos personalizados cuando se utiliza autenticación de Windows

Estoy tratando de implementar la autenticación de Windows para Identity Server 4.

En mi código, utilizo soluciones similares a la descrita en https://stackoverflow.com/questions/57517535/identity-server-4-windows-authentication-using-extension-grant-not-working

En primer lugar, utilizo el servidor HttpSys con un esquema adecuado:



builder.WebHost.UseHttpSys(options =>

{

    options.Authentication.Schemes = AuthenticationSchemes.Negotiate | AuthenticationSchemes.NTLM;

    options.Authentication.AllowAnonymous = false;

});

Luego agrego Negotiate para la autenticación:



builder.Services.AddAuthentication(IdentityServerConstants.LocalApi.AuthenticationScheme)

    .AddIdentityServerAuthentication(options =>

    {

        options.Authority = "http://localhost:5000";

        options.ApiName = "server.api";

    })

    .AddNegotiate()

    .AddLocalApi();

También extiendo Identity Server con este código:



.AddExtensionGrantValidator<WinAuthGrantValidator>()

(el código de WinAuthGrantValidator se puede encontrar en esta respuesta https://stackoverflow.com/questions/57517535/identity-server-4-windows-authentication-using-extension-grant-not-working)

Esto parece funcionar y el usuario está autenticado. WindowsIdentity está en HttpContext.User.Identity – hasta aquí todo bien.

Ahora bien, aquí está mi problema, también he registrado el ProfileService en Identity Server 4 de la siguiente manera:



.AddProfileService<ProfileService>()

que agrega algunos datos al usuario conectado (como una reclamación adicional) – esto funciona si el usuario se ha conectado con nombre de usuario y contraseña.

Desafortunadamente, cuando utilizo la autenticación de Windows para iniciar sesión, entonces se invoca el ProfileService y agrega algunas reclamaciones a IssuedClaims, pero más tarde (en el código de la aplicación) cuando intento leer esas reclamaciones desde HttpContext.User, no las tiene. ¿Me podría ayudar a entender por qué está sucediendo esto?

¡Muchas gracias!

davy.ai

July 16, 2023 at 8:22 am

Parece que el problema radica en el orden de ejecución del middleware en tu canalización de procesamiento. Dado que la autenticación de Windows ocurre antes del middleware ProfileService, las afirmaciones agregadas por ProfileService no se incluyen en el token de usuario autenticado.

Para resolver esto, es posible que debas ajustar el orden de ejecución del middleware en tu canalización. Un enfoque sería mover la llamada a AddIdentityServer después de la configuración de la autenticación de Windows:

builder.WebHost.UseHttpSys(options =>
{
    options.Authentication.Schemes = AuthenticationSchemes.Negotiate | AuthenticationSchemes.NTLM;
    options.Authentication.AllowAnonymous = false;
});

// Agregar autenticación de Windows
builder.Services.AddAuthentication(HttpSysDefaults.AuthenticationScheme)
    .AddNegotiate();

// Agregar IdentityServer con ProfileService
builder.Services.AddIdentityServer()
    .AddAspNetIdentity<applicationuser>()
    .AddProfileService<profileservice>()
    .AddConfigurationStore(options =>
    {
        // ...
    })
    .AddOperationalStore(options =>
    {
        // ...
    })
    .AddDeveloperSigningCredential()
    .AddLocalApi();

builder.Services.AddAuthorization();

// Usar IdentityServer
builder.UseIdentityServer();

Al llamar a UseIdentityServer() después de AddAuthentication(), el orden de ejecución del middleware se ajusta en consecuencia, y las afirmaciones agregadas por ProfileService deberían incluirse en el token de usuario autenticado.

Answer

davy.ai

July 16, 2023 at 8:22 am
Parece que el problema radica en el orden de ejecución del middleware en tu canalización de procesamiento. Dado que la autenticación de Windows ocurre antes del middleware ProfileService, las afirmaciones agregadas por ProfileService no se incluyen en el token de usuario autenticado.

Para resolver esto, es posible que debas ajustar el orden de ejecución del middleware en tu canalización. Un enfoque sería mover la llamada a AddIdentityServer después de la configuración de la autenticación de Windows:
```
builder.WebHost.UseHttpSys(options =>
{
    options.Authentication.Schemes = AuthenticationSchemes.Negotiate | AuthenticationSchemes.NTLM;
    options.Authentication.AllowAnonymous = false;
});

// Agregar autenticación de Windows
builder.Services.AddAuthentication(HttpSysDefaults.AuthenticationScheme)
    .AddNegotiate();

// Agregar IdentityServer con ProfileService
builder.Services.AddIdentityServer()
    .AddAspNetIdentity<applicationuser>()
    .AddProfileService<profileservice>()
    .AddConfigurationStore(options =>
    {
        // ...
    })
    .AddOperationalStore(options =>
    {
        // ...
    })
    .AddDeveloperSigningCredential()
    .AddLocalApi();

builder.Services.AddAuthorization();

// Usar IdentityServer
builder.UseIdentityServer();
```
Al llamar a UseIdentityServer() después de AddAuthentication(), el orden de ejecución del middleware se ajusta en consecuencia, y las afirmaciones agregadas por ProfileService deberían incluirse en el token de usuario autenticado.

Comments are closed.

es.davy.ai

¿Tienes una pregunta?

Problema con reclamos personalizados cuando se utiliza autenticación de Windows

Answer

davy.ai