在 ASP.NET Core 中重新质询经过身份验证的用户 [英] Re-challenge authenticated users in ASP.NET Core

问题描述

我在 ASP.NET Core 中的身份验证管道遇到了一些问题.我的场景是我想向已经使用 OpenID Connect 和 Azure AD 进行身份验证的用户发出质询.您希望在多种情况下执行此操作，例如在 AAD v2 端点场景中请求其他范围时.

I'm running into some issues with the authentication pipeline in ASP.NET Core. My scenario is that I want to issue a challenge to a user who is already authenticated using OpenID Connect and Azure AD. There are multiple scenarios where you'd want to do that, for example when requesting additional scopes in a AAD v2 endpoint scenario.

这在 ASP.NET MVC 中就像一个魅力，但在 ASP.NET Core MVC 中，用户被重定向到在 cookie 身份验证中间件中配置的拒绝访问页面.(当用户未登录时，发出挑战会按预期工作.)

This works like a charm in ASP.NET MVC, but in ASP.NET Core MVC the user is being redirected to the Access Denied-page as configured in the cookie authentication middleware. (When the user is not logged in, issuing a challenge works as expected.)

在网上搜索了几个小时并为我的中间件选项尝试了不同的参数后，我开始怀疑我遗漏了一些明显的东西，或者这种行为是设计使然，我需要解决我的其他要求大大地.有人对此有任何想法吗?

After a couple of hours searching the web and trying different parameters for my middleware options, I'm beginning to suspect that either I'm missing something obvious, or this behavior is by design and I need to solve my requirement some other way. Anyone any ideas on this?

我的 Startup.cs 的相关部分如下所示:

the relevant parts of my Startup.cs look like this:

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();

        services.AddAuthentication(
            SharedOptions => SharedOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme);
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        // <snip...>

        app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationScheme = CookieAuthenticationDefaults.AuthenticationScheme });

        var options = new OpenIdConnectOptions
        {
            AuthenticationScheme = OpenIdConnectDefaults.AuthenticationScheme,
            ClientId = ClientId,
            Authority = Authority,
            CallbackPath = Configuration["Authentication:AzureAd:CallbackPath"],
            ResponseType = OpenIdConnectResponseType.CodeIdToken,
            PostLogoutRedirectUri = "https://localhost:44374/",
            TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
            {
                ValidateIssuer = false
            }
        };
        options.Scope.Add("email");
        options.Scope.Add("offline_access");

        app.UseOpenIdConnectAuthentication(options);
    }

动作看起来像这样:

    public void RefreshSession()
    {
        HttpContext.Authentication.ChallengeAsync(OpenIdConnectDefaults.AuthenticationScheme, new AuthenticationProperties { RedirectUri = "/" });
    }

推荐答案

我在这里找到了提示和解决方案:https://github.com/aspnet/Security/issues/912.ChallengeBehavior.Unauthorized 是关键".

I found a hint and the solution here: https://github.com/aspnet/Security/issues/912. ChallengeBehavior.Unauthorized is the "key".

这篇文章给出了当前(2016 年 11 月 - ASPNet 1.0.1)的解决方法:https://joonasw.net/view/azure-ad-b2c-with-aspnet-core

This post gives the current (november 2016 - ASPNet 1.0.1) workaround: https://joonasw.net/view/azure-ad-b2c-with-aspnet-core

您需要一个新的 ActionResult 才能使用 ChallengeBehavior.Unauthorized 行为调用 AuthauticationManager.ChallengeAsync.

You'll need a new ActionResult to be able to call the AuthauticationManager.ChallengeAsync with the ChallengeBehavior.Unauthorized behavior.

一旦问题https://github.com/aspnet/Mvc/issues/5187 将成功关闭，这应该被集成.

Once the issue https://github.com/aspnet/Mvc/issues/5187 will be sucessfully closed, this should be integrated.

我对其进行了测试，它运行良好(我的目标只是根据每个用户扩展 Google 范围).

I tested it and it worked perfectly well (my goal was simply to extend Google scopes on a per user basis).

这篇关于在 ASP.NET Core 中重新质询经过身份验证的用户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！