Dlaczego usługa Azure AD nie loguje się do użytkowników nieadministracyjnych w scenariuszu z wieloma dzierżawcami?

Question

Środowisko:

Dwa Azure ogłoszenia Spółka, Klienci

Spółka publikuje aplikację ASP.NET5 nazwie Portal, aplikacja jest ustawiony tak, aby być multi-tenant.

Klienci mieć 2 Użytkownik: użytkownikowi (który jest tylko użytkownikiem) i administratora (który jest światowym Administrator w katalogu).

Portal, jest wstępnie skonfigurowany do zapytać o pozwolenie 1 Zastosowanie: Czytaj katalogu danych

-

Nadchodzi przepływ że przeszłam i wierzę Azure misbehaves AD w wielu krokach. Proszę wskazać, czy czegoś brakuje.

1. otworzyć aplikację internetową i spróbuj najpierw zalogować się jak administratora
2. muszę wyrazić zgodę na pozwolenie danych odczytać katalogu, więc to zrobić pojawia
3. aplikacji (nie mam role przydzielone, co jest w porządku) - jak dotąd wszystko działa.
4. I ponownie otworzyć aplikację internetową w nowej sesji incognito i spróbuj zalogować się jako użytkownik
5. Teraz dostaję [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.] - admin już zgodę, więc dlaczego mam to??
6. idę Spółka AD i zmienić uprawnienia aplikacji w celu włączenia Przeczytaj & danych Zapis katalog
7. idę Klienta AD sprawdzić aplikację Portal a deska rozdzielcza już pokazuje nowe pozwolenie na liście. Nikt nie musiał się zgodzić! Administrator nie widzi żadnych zmian nawet przy następnym logowaniu. Jak to nie jest dziura w bezpieczeństwie?

Moje rozumienie https://msdn.microsoft.com/en-us/library/azure/dn132599.aspx że Uprawnienia aplikacji nie są przestarzałe.

UPDATE

Moja konfiguracja w 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

Dzięki za Ciebie informacji. Najpierw odpowiem na pytanie nr 7, ponieważ wygląda dość niepokojąco. Na pierwszy rzut oka wygląda jak luka w zabezpieczeniach, ale tak nie jest.Jest to błąd w Portalu zarządzania Azure, nad którym pracujemy. W widoku dzierżawy "klienci" UX pokazuje uprawnienia, których żąda aplikacja (zdefiniowana na dzierżawcę firmy). Powinien pokazywać uprawnienia faktycznie przyznane najemcy "klienta". W takim przypadku, jeśli Twoja aplikacja faktycznie próbuje wywołać zapis do interfejsu Graph API, otrzyma błąd odmowy dostępu. W każdym razie - nie dziura w bezpieczeństwie - ale z pewnością rozumiem, dlaczego tak to wyglądało - przepraszam za to. Postaramy się to naprawić tak szybko, jak to możliwe.

Na kilka innych pytań dotyczących zachowania przyzwolenia ... BTW jest to coś, co chcemy poprawić w naszej dokumentacji. W każdym razie spróbuję odpowiedzieć na to pytanie w kategoriach zachowania projektu, ponieważ wygląda na to, że wielokrotnie zmieniłeś konfigurację aplikacji.

Jeśli wybierzesz dowolne uprawnienia aplikacji na numer (bez uprawnień delegowanych), zgoda użytkownika UX jest domyślnie wyrażona jako "zgoda w imieniu organizacji". W tym trybie strona zgody ZAWSZE pokazuje, czy administrator wyraził uprzednio zgodę, czy nie. Możesz także wymusić to zachowanie, jeśli wysyłasz żądanie do autoryzowanego punktu końcowego za pomocą parametru QS prompt = admin_consent. Powiedzmy, że przeszedłeś tę ścieżkę ORAZ jedyne pozwolenie, jakie masz, to "tylko do odczytu katalogu" aplikacji i zgody administratora. Teraz użytkownik przychodzi, użytkownik nie ma żadnego przydziału, który pozwala im się zalogować i uzyskać identyfikator id_token dla aplikacji (tylko do odczytu aplikacja Directory nie jest do tego odpowiednia), więc okno dialogowe zgody próbuje pokazać adminowi w imieniu zgody org, ale to nie jest administrator, więc dostaniesz błąd. Teraz, jeśli dodasz uprawnienia delegowane do aplikacji "zapisz mnie i przeczytaj mój profil" i poproszę administratora, zobaczysz, że teraz użytkownik nie zostanie poproszony o zgodę. Co mogę zrobić, to wrócić do naszego zespołu i sprawdzić, czy Dowolne uprawnienie katalogu (tylko aplikacja lub delegowane) powinno zezwalać każdemu użytkownikowi na uzyskanie tokena. Można argumentować, że tak powinno być.

HTHs,