【问题标题】:Enabling multiple tenants using OWIN Active Directory bearer tokens使用 OWIN Active Directory 不记名令牌启用多个租户
【发布时间】:2016-01-01 15:22:44
【问题描述】:

我最近开始使用 Azure Active Directory 来针对基于 AngularJS 构建的网站对用户进行身份验证。

使用博客和sample code on GitHub,我已经使用ADAL.js 和Katana 的Bearer Token AD integration 组合使用单租户。

但是,我现在在支持多个租户方面遇到了一些问题。

我设置了一个页面,显示 ADAL 看到的用户(通过根范围的 userInfo 找到),并调用 OWIN 获取的我的服务器,并序列化 @987654325 @。

客户端,一切似乎都运行正常。我可以使用我的任何租户登录,它为我提供了我期望的对象(填充了isAuthenticated: trueusername,以及profile 上描述用户、登录名和租户的各种属性)。

这是通过在我的 adalAuthenticationServiceProvider.init 调用中省略 tenant 参数来在客户端完成的,如文档中所述。

但是,在服务器端,UseWindowsAzureActiveDirectoryBearerAuthentication 方法不喜欢 Tenant 没有值(因为它会引发异常)。我为此尝试了一些值,包括我的应用程序最初注册的租户,以及我逻辑上最喜欢的“common”,但无论我在那里输入什么(除非它是我试图登录的租户并且如果我的 ADAL 是与该租户一起设置的),它似乎只是跳过了这一点。

不管怎样,实际的 API 调用在 [Authorize] 过滤器上失败并返回 401,这告诉我这不是我的 OWIN 拦截器的问题。

如何告诉UseWindowsAzureActiveDirectoryBearerAuthentication 支持多租户身份验证?

【问题讨论】:

    标签: active-directory owin adal


    【解决方案1】:

    我在写这个问题的时候发现了这一点。我想。但是我花了一整天的时间发现几乎没有关于此事的文档,所以我想我还是会发布它。

    我的解决方案(通过yet another blog post 找到)是包含ValidateIssuer = false 作为参数。这是有道理的,因为我们不再想验证给我们令牌的租户是否就是我们列出的那个。

    这是我解决问题的代码。

    app.UseWindowsAzureActiveDirectoryBearerAuthentication(
                new WindowsAzureActiveDirectoryBearerAuthenticationOptions
                {
                    TokenValidationParameters = new TokenValidationParameters
                    {
                        ValidAudience = ConfigurationManager.AppSettings["ida:Audience"],
                        ValidateIssuer = false // This line made it work
                    },
                    AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Active,
                    Tenant = "common" // I don't know whether this has any impact,
                                      // but it's a required parameter regardless.
                });
    

    如果有任何不可预见的情况,如果其他人想纠正我,我会很高兴——当您进行身份验证时,将“验证”开关切换到关闭有点令人生畏。但我认为这一切都说得通。

    【讨论】:

    • 这里有一个关于该配置的评论:而不是使用默认验证(验证单个颁发者值,就像我们在业务线应用程序中所做的那样), // 我们注入我们自己的多租户验证逻辑跨度>
    • @ken 感谢您将我指向此 URL...我正在寻找该代码。我过去曾看过它,但无法使用 Google 找到它。
    【解决方案2】:

    当您开发多租户应用程序时,您不能再 100% 依赖默认身份验证逻辑。默认身份验证逻辑假定您声明了要在其中接收令牌的 azure AD 租户表单,并且将强制执行接受该租户的令牌表单。这是通过检查与每个租户关联的元数据文档来完成的,其中包含(除其他外)租户本身的标识符 - 该标识符必须存在于您收到的令牌中,在 iss 声明中:任何其他值都意味着令牌来自另一个租户,因此必须拒绝。 根据定义,多租户应用程序必须接受来自多个租户的令牌。这是通过使用参数端点(通用端点,请参阅this post)来完成的,它允许您“后期绑定”哪个租户将用于发布令牌。但是,公共端点将提供一个通用元数据文档,该文档不能包含特定的 iss 值:相反,它包含一个占位符,在运行时将始终替换为您实际从中获取令牌的租户的颁发者标识符。 这意味着在多租户应用程序中,您必须接管租户验证逻辑。如果您只是在调试,则可以将其关闭,就像您似乎所做的那样 - 这将阻止默认颁发者验证逻辑启动并拒绝传入令牌,因为它的 iss 值不对应于常见的占位符。然而,在更实际的情况下,您将在 TokenValidationParameters.IssuerValidator 委托中编写自己的逻辑。例如,您可能希望将传入令牌中的 iss 值与购买每月订阅您的服务的租户列表进行比较。高温

    【讨论】:

    • 是的,这是有道理的。我的问题与其说是关于这一切的理论,不如说是关于该课程如何完成它的实际机制。但感谢您提供的信息。说到实际的机制,你知道 OWIN 逻辑可以处理多少吗?我对设置 ValidateIssuer = false 的担忧只是在 authentication 方面,我已经处理了授权。只要我能确定 set issuer 实际上是发出请求的租户,我就是金子。
    猜你喜欢
    • 2014-01-04
    • 1970-01-01
    • 1970-01-01
    • 2016-08-04
    • 2017-10-10
    • 2021-06-02
    • 1970-01-01
    • 1970-01-01
    • 2023-03-05
    相关资源
    最近更新 更多