Microsoft 'Identity Platform' 是不是（轻松）与'(ASP.NET) Identity Framework' - MVC5 & .NET 4.7.2 集成？

Posted 2023-03-27

【中文标题】Microsoft \'Identity Platform\' 是不是（轻松）与\'(ASP.NET) Identity Framework\' - MVC5 & .NET 4.7.2 集成？

【英文标题】：Does Microsoft 'Identity Platform' (easily) integrate with the '(ASP.NET) Identity Framework' - MVC5 & .NET 4.7.2?Microsoft 'Identity Platform' 是否（轻松）与'(ASP.NET) Identity Framework' - MVC5 & .NET 4.7.2 集成？

【发布时间】：2020-08-08 08:17:10

【问题描述】：

我们有一个 .NET 4.7.2 MVC5 应用程序，它使用 EF 添加到 Microsoft 身份框架的使用，并且想知道它是否易于组合 - 以某种方式，MSAL.NET/Identity 平台？

例如理想情况下，为本地登录保留 Identity Framework，并通过 Azure AD 和 Azure AD B2C（外部身份/用户）登录的 Identity Platform OAuth v2 集成对其进行补充？

支持吗？ 是否存在重大问题？ 插入方便吗？ 最好的路线是什么？

我似乎无法在任何地方找到答案。

更新：忽略需要 .NET Core 3.1 或特定版本 (# 27) 的 android 的演示（-当“Android SDK 管理器”工具由于它试图修改它正在处理的枚举而无法工作时）枚举:() 我设法对 ASP.NET 'Quickstart' 应用程序进行了一些更改以使其正常工作，但是当我尝试通过替换我们现有的 (ASP.NET) 身份框架代码中的位来缩小目标时使用快速入门示例的身份平台代码中的代码的应用程序，我似乎陷入了即时登录圈。

【问题讨论】：

"什么是最好的路线" 你在这里要求教程/最佳实践，到目前为止你做了什么，你在哪里卡住了？

【参考方案1】：

这可能不是最好的答案，但为了他人的利益，这是我所学到的，也是我个人的想法。

目前，似乎没有明确/辅助的过渡路径。

但是，我确实找到了一种手动从一个转换到另一个的方法（-“（ASP.NET）身份框架”到“身份平台”/Azure AD B2C/MSAL），这也给我留下了以下结论：

而不是对不同的 IdP/AS（身份提供程序/身份验证服务器）供应商的 OID-C/OIDC（OpenID 连接）和/或 OAuth 管道提供固有支持 - 可能他们的所有管道都可能相互之间/彼此绊倒（作为更内在的接线的一部分），并且还必须在添加新的 IdP/AS 供应商后为所有供应商重新测试整个应用程序，我认为最好的方法是翻译供应商的 id-令牌到我们自己的访问令牌，或者更直接地是我们现有的 ClaimsPrincipal。

因此，就解决方案的一些机制而言；添加了以下 NuGet 包（及其底层依赖项）：

    <package id="Microsoft.IdentityModel.Protocols.OpenIdConnect" version="6.7.1" targetFramework="net472" />

（...虽然版本“6.8.0”现在可用。）

然后我可以使用如下代码来验证“id_token”，然后返回一个“ClaimsPrincipal”；然后，我可以使用“电子邮件”声明的值来检查我们系统中的现有用户 - 如果没有创建新用户（使用随机且安全的密码以及名字和姓氏，希望他们的手机也是如此） ):

    var viewModel =
        new
        
            IdToken =
                idToken
        ;

    // Application (client) ID
    var msIdPfClientId =
        @"...";

    // Application (client) URI
    var msIdPfClientUri =
        @"...";

    // Directory (tenant) ID
    var msIdPfTenantId =
        @"...";

    // Valid Issuer
    var msIdPfValidIssuer =
        @"...";

    var identityModelConfigManager =
        new ConfigurationManager<OpenIdConnectConfiguration>(
            $"msIdPfValidIssuer/.well-known/openid-configuration",
            new OpenIdConnectConfigurationRetriever());

    var oidcConfig =
        await identityModelConfigManager.GetConfigurationAsync();

    ISecurityTokenValidator securityTokenValidator =
        new JwtSecurityTokenHandler();

    // Initialize the token validation parameters
    var tokenValidationParameters =
        new TokenValidationParameters
        
            // App Id URI and AppId of this service application are both valid audiences.
            ValidAudiences =
                new[]
                
                    msIdPfClientId,
                    msIdPfClientUri
                ,
            ValidIssuer =
                msIdPfValidIssuer,
            //// Support Azure AD V1 and V2 endpoints
            //ValidIssuers =
            //    validIssuers,
            // ValidateIssuer = true,
            IssuerSigningKeys =
                oidcConfig.SigningKeys
        ;

    var claimsPrincipal =
        securityTokenValidator.ValidateToken(
            viewModel.IdToken,
            tokenValidationParameters,
            out var validatedSecurityToken);

然后在不久之后的适当时刻，我可以继续使用/以传统 (ASP.NET) 身份框架方式登录用户：

    await SignInManager.SignInAsync(
                            user,
                            isPersistent: false,
                            rememberBrowser: false);

尽管如此，我还发现创建一个 cookie 来指示用户已通过身份平台登录（- 在注销过程中很有用）也很有用。

我最近得出了另一个结论——至少我觉得这对我来说是一个更好的选择，如果不是其他人的话；这是为了回避微软“身份平台”的 MSAL（微软身份验证库）特定/扩展伪装，而只是将其视为/使用普通的“连接”/OIDC/OID-C 集成（与底层 Azure AD - 没有自定义工作流分支到/要求 BC/aka 'Azure AD BC'）。