2016-07-08 16 views
5

Mam standardowe API internetowe działające w witrynie Azure z włączoną funkcją uwierzytelniania Azure AD, podczas przeglądania interfejsu API w przeglądarce mogę zalogować się przez przeglądarkę i uzyskać dostęp do interfejsu API.Żądanie API Azure AD 401 Nieautoryzowane

Aplikacja pulpitu WPF jednak odbiera odpowiedź Nieuprawnione przy składaniu wniosku:

var authContext = new AuthenticationContext(authority, new FileCache()); 
var accessToken = await authContext.AcquireTokenAsync(apiResourceid, clientId, redirectUri, 
        new PlatformParameters(PromptBehavior.Auto)); 
// accessToken is valid 

var apiUrl = "https://example.azurewebsites.net/api/list"; 
var request = new HttpRequestMessage(HttpMethod.Get, apiUrl); 
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken.AccessToken); 
var response = await httpClient.SendAsync(request); 

Uwierzytelnianie jest udana i widzę Informacja o użytkowniku podczas debugowania.

Nie mam dostępu do konta Azure, ale jestem pewien, że aplikacja Service AD ​​jest poprawnie skonfigurowana, aby umożliwić dostęp do aplikacji AD klienta, ponieważ podczas testowania na alternatywnym koncie (niepoprawnie skonfigurowanym) nie udała się metoda AuthenticationContext.AcquireTokenAsync.

Zauważyłem, że AuthenticationResult.ExpiresOn jest zawsze w przeszłości, ale nie widzę sposobu na przedłużenie go, czy to będzie w przyszłości? - (Czas jest UTC oczywiście)

Zapytanie:

GET https://example.azure 
websites.net/api/categorisation HTTP/1.1 
Authorization: Bearer eyJ0eXAiO... 
Host: example.azurewebsites.net 

Response:

HTTP/1.1 401 Unauthorized 
Content-Length: 58 
Content-Type: text/html 
Server: Microsoft-IIS/8.0 
WWW-Authenticate: Bearer realm="example.azurewebsites.net" 
X-Powered-By: ASP.NET 
Set-Cookie: ARRAffinity=e35f2977dba55e6708887e762940f75c2a0fcb0a9df4e1cbe0d3f10a614c59b8;Path=/;Domain=example.azurewebsites.net 
Date: Fri, 08 Jul 2016 07:51:13 GMT 

You do not have permission to view this directory or page. 

Aktualizacja:

Mam odtworzył środowisko w Azure koncie mam dostęp do i nadal otrzymujesz nieautoryzowaną odpowiedź (działa dobrze w przeglądarce).

+0

Czy możesz umieścić kod w swoich witrynach Startup.Auth.cs konfiguruje uwierzytelnianie Azure AD? A może używasz opcji "Uwierzytelnianie/autoryzacja" na stronach internetowych Azure, czy możesz udostępnić skonfigurowane wartości/ustawienia? – Saca

+0

Ponadto: "Uwierzytelnianie zakończyło się pomyślnie i widzę informacje o użytkowniku podczas debugowania.", Czy mówisz, że podczas uruchamiania aplikacji WPF w Visual Studio pomyślnie łączysz się z interfejsem API, ale podczas uruchamiania z programu exe nie działa ' t? Jeśli tak, czy pojawia się monit, gdy uruchomisz .exe? – Saca

+0

@Saca API używa uwierzytelniania witryn internetowych Azure z. Dostawca to "Azure Active Directory" skonfigurowany w trybie Express Management, aplikacja Azure AD jest ustawiona na aplikację AD Web Service. – Anth12

Odpowiedz

1

Wydaje się, że problem dotyczy opcji "Uwierzytelnianie/autoryzacja" na stronach internetowych Azure, po włączeniu Web Api nie będzie akceptował żądań za pomocą nagłówka uwierzytelniania. Wyłączenie opcji i użycie biblioteki Owin obok usługi Azure AD zapewniło wymagane rozwiązanie.

+0

To samo dla mnie Stworzyłem inny projekt bez interfejsu webowego i azutowy auth działa po wyjęciu z pudełka – KnuturO

2

Wiem, że to kilka miesięcy, ale chciałem rzucić to, co było przyczyną tego problemu, kiedy go otrzymałem, i co odkryłem, że mogę to rozwiązać.

Miałem stronę, z której zrobiłem, która wykorzystała SignalR. W miarę rozwoju nie zabezpieczyłem strony, ale kiedy poszedłem zabezpieczyć witrynę za pomocą AzureAD, otrzymałem wyżej wymieniony błąd. Problem polegał na tym, że miałem dwie klasy uruchamiania, jedną w głównym katalogu aplikacji i jedną w App_Start. Jedna z nich znajdowała się w przestrzeni nazw [applicationname] .App_Start, podczas gdy jedna była w obszarze nazw App_Start, a jedna została oznaczona jako zespół uruchamiania OWIN.

Moja rozdzielczość polegała na usunięciu tego w folderze App_Start, który znajdował się w przestrzeni nazw [appname] .App_Start i dodaniu odpowiednich atrybutów startowych SignalR i OWIN do tego w katalogu głównym aplikacji.

To rozwiązało mój problem.

Mam nadzieję, że to pomoże każdemu, kto się na to zdecyduje!

1

Otrzymywałem także nieautoryzowane błędy, a przy otrzymywaniu tokena okaziciela wszystko działało dobrze.

Mój problem był w moim identyfikatorze zasobu. Nie pasuje do "identyfikatora URI aplikacji" w usłudze Azure-AD. Miałem dodatkowy slash na końcu wywołując metodę AcquireTokenAsync i wprowadziłem ją na Azure-AD bez slasha.

// private string resourceId = "https://mywebsite.azurewebsites.net/"; // bad 
private string resourceId = "https://mywebsite.azurewebsites.net"; // good 
result = await authContext.AcquireTokenAsync(resourceId, 
    clientId, redirectUri, new PlatformParameters(PromptBehavior.Never)); 

Więc upewnij się, że Twój identyfikator zasobu pasuje do aplikacji Azure-reklamy „Identyfikator aplikacji URI” dokładnie.

Uwagi:

  • Każda usługa aplikacja, która jest związana z Azure-AD ma odpowiednią deklarację aplikacji Azure-AD typu aplikacji Web/API. Ten identyfikator zasobu to "Identyfikator URI identyfikatora aplikacji" w deklaracji aplikacji Azure-AD aplikacji.
  • Mój identyfikator zasobu to po prostu mój URL strony internetowej, ale mógł to być cokolwiek. Chodzi o to, aby dopasować "identyfikator URI identyfikatora aplikacji" aplikacji Azure-AD, do której próbujesz uzyskać dostęp.
Powiązane problemy