繁体   English   中英

Microsoft“身份平台”是否(轻松)与“(ASP.NET)身份框架”集成 - MVC5 和 .NET 4.7.2?

[英]Does Microsoft 'Identity Platform' (easily) integrate with the '(ASP.NET) Identity Framework' - MVC5 & .NET 4.7.2?

我们有一个 .NET 4.7.2 MVC5 应用程序,它使用 EF 添加到 Microsoft Identity Framework 的使用中,并且想知道它是否容易组合 - 以某种方式,MSAL.NET/Identity Platform?

例如,理想情况下,保留用于本地登录的身份框架,并使用用于 Azure AD 和 Azure AD B2C(外部身份/用户)登录的身份平台 OAuth v2 集成对其进行补充?

  • 这受支持吗?
  • 有重大问题吗?
  • 是否容易插拔?
  • 最好的路线是什么?

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

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

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

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

但是,我确实找到了一种手动从一个过渡到另一个的方法(-“(ASP.NET)身份框架”到“身份平台”/Azure AD B2C/MSAL),这也给我留下了以下结论:

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

因此,就解决方案的一些机制而言; 添加了以下 NuGet package (及其基础依赖项):

    <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) Identity Framework 方式让用户登录:

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

尽管如此,我还发现创建一个 cookie 以指示用户已通过身份平台登录也很有用(在注销过程中很有用)。

我最近得出了另一个结论——至少我觉得这对我来说是一个更好的选择,如果不是其他人的话; 这是为了避开微软的“身份平台”,它是 MSAL(微软身份验证库)特定/扩展的伪装,只是把它当作普通的“连接”/OIDC/OID-C 集成(与底层 Azure AD - 没有自定义工作流分支到 BC/又名“Azure AD BC”/要求)。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM