为什么Azure AD无法在多租户方案中登录非管理员？

Question

环境:

两个Azure AD:公司,客户

公司发布了一个名为Portal的ASP.NET5 Web应用程序,该应用程序设置为多租户.

客户有2个用户:user(只是用户)和admin(目录中是全局管理员).

Portal,最初设置为要求1个应用程序权限:读取目录数据

-

这是我经历的流程,我相信Azure AD在多个步骤中行为不端.请指出我是否遗漏了什么.

1. 我打开网络应用,首先尝试以管理员身份登录
2. 我必须同意读取目录数据权限,所以我这样做
3. 应用程序出现(我还没有分配任何角色,这很好) - 到目前为止一切正常.
4. 我在新的隐身会话中重新打开了网络应用,并尝试以用户身份登录
5. 现在,我得到[ AADSTS90093: This operation can only be performed by an administrator. Sign out and sign in as an administrator or contact one of your organization's administrators.] - 管理员已经同意了,为什么我得到这个？
6. 我转到公司 AD并更改应用程序权限以包括读取和写入目录数据
7. 我转到客户 AD检查应用程序门户,仪表板已显示列出的新权限.没有人必须同意!该管理员没有看到甚至在下次登录时的任何变化.这怎么不是安全漏洞？

我的理解https://msdn.microsoft.com/en-us/library/azure/dn132599.aspx是应用程序的权限都没有过时.

UPDATE

我在WebApp中的配置:

app.UseOpenIdConnectAuthentication(options =>
{
   options.ClientId = Configuration.Get("ActiveDirectory:ClientId");
   options.Authority = String.Format(Configuration.Get("ActiveDirectory:AadInstance"), "common/");   //"AadInstance": "https://login.windows.net/{0}"
   options.PostLogoutRedirectUri = Configuration.Get("ActiveDirectory:PostLogoutRedirectUri");    //"PostLogoutRedirectUri": "https://localhost:44300/"

   options.TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters
   {
       // The following commented-out line should work according to
       // http://stackoverflow.com/questions/29317910/why-does-the-role-claim-have-incorrect-type
       // But, it does not work in ASP.NET5 (currently), so see the "Hack." down below
       // RoleClaimType = "roles",

       ValidIssuers = new[] { "https://sts.windows.net/a1028d9b-bd77-4544-8127-d3d42b9baebb/", "https://sts.windows.net/47b68455-a2e6-4114-90d6-df89d8468abc/" }
   };

   options.Notifications = new OpenIdConnectAuthenticationNotifications
   {
       RedirectToIdentityProvider = (context) =>
       {
           // This ensures that the address used for sign in and sign out is picked up dynamically from the request,
           // which is neccessary if we want to deploy the app to different URLs (eg. localhost/immerciti-dev, immerciti.azurewebsites.net/www.immerciti.com)
           string appBaseUrl = context.Request.Scheme + "://" + context.Request.Host + context.Request.PathBase;
           context.ProtocolMessage.RedirectUri = appBaseUrl;
           context.ProtocolMessage.PostLogoutRedirectUri = appBaseUrl;
           return Task.FromResult(0);
       },

       AuthorizationCodeReceived = async context =>
       {
           // Get Access Token for User's Directory
           try
           {
               var identity = (ClaimsIdentity)context.AuthenticationTicket.Principal.Identity;

               // Hack. TODO: keep an eye on developments around here
               foreach (var claim in identity.FindAll("roles"))
               {
                   // Readd each role with the proper claim type
                   identity.AddClaim(new Claim(identity.RoleClaimType, claim.Value, claim.ValueType, claim.Issuer, claim.OriginalIssuer));
               }
           }
           catch (AdalException)
           {
               context.HandleResponse();
               context.Response.Redirect("/Error/ShowError?errorMessage=Were having trouble signing you in&signIn=true");
           }
       }
   }; 
};

Answer 1

感谢您提供的信息。我首先要回答#7，因为它看起来非常令人担忧。乍一看它确实像是一个安全漏洞，但事实并非如此。这是 Azure 管理门户中的一个错误，我们正在努力修复。在“客户”租户视图中，UX 显示应用程序（在公司租户中定义）请求的权限。它应该显示“客户”租户中实际授予的权限。在这种情况下，如果您的应用实际上尝试调用写入图形 API，它将收到访问被拒绝错误。无论如何 - 不是一个安全漏洞 - 但可以肯定理解为什么它看起来像这样 - 对此感到非常抱歉。我们将尽力尽快修复此问题。

关于您关于同意行为的其他一些问题...顺便说一句，这是我们希望在文档中改进的内容。无论如何，我将尝试从设计行为方面广泛回答这个问题，因为看起来您已经多次更改了应用程序配置。

如果你选择任何一个应用程序权限（不是委派权限），同意用户体验将默认为“代表组织同意”体验。在此模式下，无论管理员之前是否同意，同意页面始终显示。如果您使用 QS 参数提示 = admin_consent 向授权端点发出请求，您也可以强制执行此行为。因此，假设您走了这条路，并且您拥有的唯一权限是仅应用程序的“读取目录”并且管理员同意。现在，用户来了，用户没有任何授权来允许他们登录并获取应用程序的 id_token（仅读取目录应用程序目前对此不适用），因此同意对话框尝试代表管理员显示组织同意，但这是非管理员，因此您会收到错误。现在，如果您为应用程序添加委派的“登录并阅读我的个人资料”权限，并获得管理员的重新同意，您将看到现在不会提示用户同意。我要做的是返回我们的团队，查看任何目录权限（仅限应用程序或委派）是否应允许任何用户获取登录令牌。有人可能会说情况应该如此。

HTH，