Аутентификация токена (Identity Server 4) с другого сервера через промежуточное ПО, но она проверяет все конечные точки, которые не нужно было авторизовать

Question

Я использую промежуточное ПО для проверки токена для аутентификации пользователя, который подключается к другому серверу для этого. Но проблема в том, что он всегда проверяет токен, даже если он не требуется, то есть при использовании Register API или любого другого, который не нуждается в проверке.

Это мой файл TokenValidationMiddleware.cs.

public async Task Invoke(HttpContext httpContext, UserManager<ApplicationUser> userManager)
    {
        _userManager = userManager;

        // **>>>>>BELOW CHECK IS MANUAL, WHICH IS ALSO NOT CORRECT.<<<<<**
        if (!httpContext.Request.Path.StartsWithSegments("/api/Authentication/Login") && !httpContext.Request.Path.StartsWithSegments("/api/Authentication/Refresh"))
        {
            var headerKeys = httpContext.Request.Headers.Keys;

            // **issue comes here**
            // **it always discard the request which does not have any token.**
            if (headerKeys.Contains("Authorization"))
            {
                // validation code, which hits another server.                       
            }
            else
            {
                httpContext.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
                await httpContext.Response.WriteAsync("Unauthorized Access");
                return;
            }
        }

        await _next.Invoke(httpContext);
    }

Это промежуточное ПО всегда проверяет проверку токена для каждого поданного запроса.

Я хочу обойти это промежуточное ПО для анонимных запросов или запросов, которые не имеют атрибута [Authorize] над контроллером или указаны c конечная точка.

Одним из решений является сохранение где-нибудь всех анонимных конечных точек и проверка промежуточного программного обеспечения, что совсем не правильно.

Другое - изменение маршрутов всех безопасных конечные точки называются «api / secure / [controller]», но для этого мне нужно изменить все конечные точки в бэкенде, а также во внешнем интерфейсе. Это тоже не очень хороший подход.

Пожалуйста, предложите решение для этого.

Заранее спасибо.

Answer 1

Вы можете проверить конечную точку по IAuthorizeData в своем промежуточном программном обеспечении:

public async Task Invoke(HttpContext httpContext, UserManager<ApplicationUser> userManager)
{
    _userManager = userManager;


    // Check if endpoint has any authorize data, like [Authorize] attribute
    var endpoint = httpContext.GetEndpoint();
    var authorizeData = endpoint?.Metadata.GetOrderedMetadata<IAuthorizeData>();
    if (authorizeData != null && authorizeData.Any())
    {

        // If you need to depend on particular scheme ("Bearer" in my example):
        var scheme = authorizeData[0].AuthenticationSchemes;
        if (scheme == JwtBearerDefaults.AuthenticationScheme)
        {
            // Code only for "Bearer" auth scheme
        }


        var headerKeys = httpContext.Request.Headers.Keys;

        // **issue comes here**
        // **it always discard the request which does not have any token.**
        if (headerKeys.Contains("Authorization"))
        {
            // validation code, which hits another server.                       
        }
        else
        {
            httpContext.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
            await httpContext.Response.WriteAsync("Unauthorized Access");
            return;
        }
    }

    await _next.Invoke(httpContext);
}

Вы также можете проверить обратное: по IAllowAnonymous, если конечная точка имеет атрибут [AllowAnonymous].

if (endpoint?.Metadata.GetMetadata<IAllowAnonymous>() != null)

Ps

Вы можете проверить ASP. NET Core Авторизация MiddleWare исходный код для вдохновения.

Answer 2

Middlewares, как. net Обработчики. Они должны использоваться, когда вам не нужны данные контроллера c: asp. net промежуточное ПО ядра против фильтров

С другой стороны, вы можете использовать пользовательские поставщики политик, подобные этому: https://docs.microsoft.com/en-us/aspnet/core/security/authorization/iauthorizationpolicyprovider?view=aspnetcore-3.1

Использование внешней службы для оценки политики.

Использование большого диапазона политик (для разных номеров или например, возраст), поэтому нет смысла добавлять каждую отдельную политику авторизации с помощью вызова AuthorizationOptions.AddPolicy.

Создание политик во время выполнения на основе информации из внешнего источника данных (например, базы данных) или динамическое определение требований авторизации с помощью другого механизма.

Таким образом, вы можете использовать атрибут типа BypassAuth, который будет вызывать неавторизацию для определенных c действий и пропустить все остальные go через другой который будет установлен по умолчанию.