2016-07-08 57 views
5

Ho un'API Web standard in esecuzione su un sito Web di Azure con l'autenticazione di Azure AD abilitata, durante la navigazione nell'API in un browser Sono in grado di accedere tramite il browser e accedere all'API.Richiesta API di Azure AD 401 non autorizzata

L'applicazione desktop WPF tuttavia sta ricevendo una risposta non autorizzato al momento della presentazione della richiesta:

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); 

L'autenticazione è successo e posso vedere le informazioni per l'utente durante il debug.

Non ho accesso all'account di Azure ma sono sicuro che l'applicazione di servizio AD sia configurata correttamente per consentire l'accesso all'applicazione Client AD come quando si esegue il test su un account alternativo (non configurato correttamente) il metodo AuthenticationContext.AcquireTokenAsync non funzionava.

Ho notato che lo AuthenticationResult.ExpiresOn è sempre nel passato ma non vedo alcun modo di estenderlo, dovrebbe essere una data futura? - (il tempo è ovviamente UTC)

Richiesta:

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

Risposta:

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. 

Aggiornamento:

ho ricreato l'ambiente in un conto Azure ho accesso a e ancora ricevere una risposta non autorizzata (funziona bene in un browser).

+0

È possibile inserire il codice nei siti Web Startup.Auth.cs impostando l'autenticazione di Azure AD? Oppure, se si utilizza l'opzione "Autenticazione/Autorizzazione" nei siti Web di Azure, è possibile condividere i valori/le impostazioni configurate? – Saca

+0

Inoltre, su questo: "L'autenticazione ha esito positivo e posso vedere le informazioni utente durante il debug.", Stai dicendo che quando si esegue l'applicazione WPF con Visual Studio ci si connette all'API, ma quando si esegue da exe non lo fa t? Se sì, ti viene richiesto quando esegui l'exe? – Saca

+0

@Saca l'API utilizza l'autenticazione dei siti Web di Azure con. Il provider è "Directory attiva di Azure" che viene configurata utilizzando la modalità di gestione rapida, l'app di Azure AD è impostata sull'applicazione Servizio Web di Active Directory. – Anth12

risposta

1

Il problema sembra essere con l'opzione "Autenticazione/Autorizzazione" nei siti Web di Azure, se abilitato, Web Api non accetterà richieste utilizzando l'intestazione di autenticazione. Disabilitare l'opzione e utilizzare la libreria Owin insieme ad Azure AD ha fornito la soluzione richiesta.

+0

Era lo stesso per me. Ho creato un altro progetto senza web api e l'autenticazione azure funziona fuori dalla scatola – KnuturO

2

So che questo ha pochi mesi, ma volevo buttare là fuori ciò che stava causando questo problema quando l'ho preso, e quello che ho scoperto che avrei potuto fare lo risolveva.

Avevo un sito che ho usato per usare SignalR. Mentre stavo sviluppando non ho protetto il sito, ma quando sono andato a proteggere il sito con AzureAD ho ottenuto l'errore di cui sopra. Il problema era che avevo due classi di avvio, una nella root dell'applicazione e una in App_Start. Uno era nello spazio dei nomi [applicationname] .App_Start, mentre uno era nello spazio dei nomi App_Start e uno era contrassegnato come assembly di avvio OWIN.

La mia risoluzione era quella di rimuovere quella nella cartella App_Start, che si trovava nello spazio dei nomi [appname] .App_Start, e aggiungere gli attributi di avvio SignalR e OWIN corretti a quello nella root dell'applicazione.

Questo ha risolto il mio problema.

Spero che questo aiuti chiunque altro che si imbatte in questo!

1

Anche io ricevevo errori non autorizzati e quando ottenevo un token al portatore tutto sembrava funzionare perfettamente.

Il mio problema era nel mio ID risorsa. Non corrispondeva all'URL di ID dell'app della mia applicazione di Azure-AD. Ho avuto una barra in più alla fine quando ho chiamato il metodo AcquireTokenAsync e l'ho inserito in Azure-AD senza una barra.

// 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)); 

Quindi, assicurarsi che l'ID risorsa corrisponda esattamente all'URI dell'ID di app di Azure-AD dell'applicazione.

Note:

  • Ogni servizio app che è associato con Azure-AD ha una corrispondente dichiarazione di applicazione Azure-AD di tipo Web app/API. Questo ID risorsa è l '"URI ID app" nella dichiarazione dell'applicazione Azure-AD del servizio app.
  • Il mio ID risorsa sembra essere l'URL del mio sito Web, ma avrebbe potuto essere qualsiasi cosa. Il punto è far coincidere il tuo "URI ID APP" dell'applicazione Azure-AD a cui stai tentando di accedere.