Esporta (0) Stampa
Espandi tutto

Aggiunta del processo di accesso nell'applicazione Web tramite Microsoft Azure AD

Aggiornamento: maggio 2014

noteNota
Questo esempio è obsoleto. La tecnologia, i metodi e/o le istruzioni dell'interfaccia utente sono stati sostituiti da nuove funzionalità. Per un esempio aggiornato che consente di creare un'applicazione simile, vedere WebApp-OpenIDConnect-DotNet.

.

Questa procedura dettagliata descrive come usare Azure AD per implementare il servizio Web Single Sign-On in un'applicazione ASP.NET. Le istruzioni mostrano in particolare come sfruttare i vantaggi del tenant di directory associato alla sottoscrizione Azure, poiché questa è la scelta del provider di identità ovvia per le applicazioni line-of-business di un'organizzazione.

Per usare una soluzione Web Single Sign-On, è necessario in genere configurare un'applicazione Web per l'outsourcing delle funzioni di autenticazione a un'entità esterna, generalmente indicata come provider di identità. In pratica questo significa che l'applicazione verrà configurata in modo da reindirizzare le richieste non autenticate al provider di identità in base al protocollo di accesso, ad esempio SAML-P, WS-Federation oppure OpenID Connect.

L'autorità o il provider di identità gestisce l'esperienza di autenticazione e in genere richiede che l'applicazione Web sia già nota mediante un processo di provisioning. Dopo che l'autenticazione ha avuto esito positivo, il browser viene reindirizzato all'applicazione Web insieme a un token di sicurezza contenente informazioni sull'utente in ingresso. L'applicazione convalida il token, generalmente tramite un middleware che supporta le identità e, se la verifica ha esito positivo, l'utente viene considerato autenticato e autorizzato ad accedere.

Questa descrizione generale si applica anche ad Azure AD. Questo documento descrive come usare le classi di Visual Studio 2012 e Windows Identity Foundation (WIF) in .NET Framework 4.5 per configurare un'applicazione MVC 4 per l'uso di un protocollo di accesso Web. Descrive inoltre come effettuare il provisioning della stessa applicazione in un tenant di Azure AD e come configurare le impostazioni di accesso dell'applicazione per la connessione al tenant. Al termine della procedura dettagliata si disporrà di un'applicazione Web funzionante configurata in modo completo per l'uso del servizio Single Sign-On aziendale.

L'obiettivo di questa procedura dettagliata è illustrare il funzionamento di Azure AD, che non si limita all'indicazione di come creare la soluzione semplificata descritta in questo documento. Oltre a fornire le istruzioni pratiche per la creazione di un esempio funzionante, il documento presenta elementi e concetti che si riveleranno utili per acquisire familiarità con Azure AD e comprendere come usare le relative funzionalità non solo per quanto riguarda lo specifico scenario descritto in questa sede. Le sezioni aggiuntive, formattate come note in riquadri, non sono strettamente necessarie per l'esecuzione della procedura dettagliata. Se tuttavia si è interessati a usare Azure AD nelle proprie soluzioni, è consigliabile leggere anche queste parti.

Nella parte di questo documento relativa all'esercitazione sono incluse le seguenti sezioni:

  • Prerequisiti: questa sezione elenca tutti i requisiti da soddisfare per completare la procedura dettagliata.

  • Architettura della soluzione: questa sezione fornisce un'introduzione generale dell'aspetto di una soluzione Web SSO per applicazioni line-of-business. Si esamineranno i componenti funzionali alla base di SSO, configurando la struttura che verrà successivamente arricchita seguendo le istruzioni contenute nel documento.

  • Uso del tenant di directory di Azure AD: questa sezione presenta i tenant di Azure AD e le funzionalità che verranno usate nello scenario. Descrive inoltre brevemente gli elementi principali della sezione Active Directory del portale di gestione di Azure.

  • Connessione dell'applicazione ad Azure AD: questa sezione mostra come usare gli strumenti di gestione delle identità e degli accessi per Visual Studio 2012 per abilitare il servizio Web Single Sign-On nell'applicazione MVC e associare le impostazioni di autenticazione allo specifico tenant di Azure AD desiderato.

  • Argomenti di approfondimento: questa sezione approfondisce i concetti di base esaminando alcuni argomenti chiave e illustrando alcune delle altre attività eventualmente necessarie in modo che l'applicazione passi al livello successivo.

Per completare l'esercitazione, verificare che siano soddisfatti i seguenti prerequisiti:

Per domande o assistenza, vedere Preparing for Azure AD Solutions and Scenarios.

Architettura dell'applicazione single-tenant

Questa procedura dettagliata si basa sul seguente scenario: uno sviluppatore ha un'applicazione Web che intende distribuire nel cloud e desidera consentire l'accesso solo agli utenti di uno specifico tenant di Azure Active Directory. A tale scopo, dovrà effettuare le seguenti operazioni:

  1. Registrare l'app Web nel tenant di Azure AD. Una volta che l'app è nota, Azure AD accetterà le richieste di autenticazione degli utenti per tale applicazione.

  2. Aggiungere una protezione per l'applicazione, in modo che:

    1. Le richieste non autenticate possano essere bloccate e reindirizzate al tenant di Azure AD corretto per l'autenticazione degli utenti

    2. Gli utenti che hanno effettuato l'autenticazione in Azure AD vengano riconosciuti e autorizzati ad accedere

Il primo passaggio verrà implementato mediante il portale di gestione di Azure. Si imparerà a effettuare il provisioning di un nuovo tenant di Azure AD nell'ambito della sottoscrizione Azure e come usare le funzionalità del portale di gestione di Azure AD per registrare un'applicazione.

Il passaggio 2 può essere implementato usando una vasta gamma di protocolli generali concepiti per consentire operazioni di autenticazione oltre i confini aziendali o addirittura su Internet.

Nella piattaforma .NET il secondo passaggio si riduce alla configurazione delle classi incorporate in .NET per l'uso dell'identità basata sulle attestazioni e dell'autenticazione federata. Questi classi sono note collettivamente come Windows Identity Foundation (WIF) e includono impostazioni di configurazione e moduli HTTP che possono essere usati per aggiungere il livello di intercettazione con le attività di reindirizzamento e autenticazione presentate al passaggio 2. In Visual Studio 2012 sono disponibili strumenti che consentono di configurare automaticamente applicazioni Web per l'uso di WIF per l'outsourcing dell'autenticazione ad autorità esterne che supportano protocolli Web SSO specifici, ad esempio WS-Federation. Questa procedura dettagliata descrive come usare questi strumenti con Azure AD.

Azure Active Directory è il servizio che fornisce la backbone di identità delle offerte Microsoft, ad esempio Office 365 e Windows Intune. Se si sottoscrivono questi servizi e si desidera riusare il tenant di directory associato al servizio, creare una nuova sottoscrizione Azure e usare la funzionalità Aggiungi utente per aggiungere un amministratore dal tenant. Questa procedura dettagliata fornisce istruzioni particolareggiate su questo processo.

Ogni sottoscrizione ha un tenant di Azure AD e una directory associata. Se il tenant è stato generato automaticamente, la directory è denominata Directory predefinita, ma è possibile cambiarne il nome. In questa parte della procedura dettagliata si aggiungerà un utente alla directory e quindi un'applicazione.

Quando viene creato, il tenant di directory è configurato per archiviare gli utenti e le credenziali nel cloud. Per istruzioni dettagliate su come integrare il tenant di directory con la distribuzione locale di Active Directory di Windows Server, vedere la pagina relativa all'integrazione di directory.

Per domande o assistenza, vedere Preparing for Azure AD Solutions and Scenarios.

Gli scenari e le soluzioni di Azure AD (così come gli esempi di codice e le applicazioni di esempio) richiedono un account utente nel dominio di Azure Active Directory. Se si tenta di accedere alle applicazioni con un account Microsoft, ad esempio un account Hotmail.com, Live.com oppure Outlook.com, l'accesso avrà esito negativo. Se è già presente un utente con un account nel dominio Active Directory, ad esempio l'account User@Contoso.onmicrosoft.com, è possibile usarlo per accedere a questo scenario. In caso contrario, sarà necessario creare un nuovo utente.

  1. Passare al portale di gestione di Microsoft Azure (https://manage.WindowsAzure.com), eseguire l'accesso, quindi fare clic su Active Directory. (Suggerimento per la risoluzione dei problemi: elemento "Active Directory" mancante o non disponibile)

  2. Se la propria directory è denominata "Directory predefinita", aggiungere una directory, ad esempio "ContosoEngineering". Per aggiungere una directory, nella parte inferiore della pagina Active Directory fare clic su Aggiungi e seguire le istruzioni per aggiungere una nuova directory.

  3. Fare doppio clic sulla directory e quindi fare clic su Domini. Quando si creano gli account utente, usare il nome di dominio visualizzato nella pagina. Se ad esempio il dominio è ContosoEngineering@onmicrosoft.com, creare nomi utente in tale dominio, ad esempio Test@ContosoEngineering@onmicrosoft.com.

  4. Per creare un account utente nel dominio, fare clic su Utenti. Se non è visibile una scheda Utenti, fare doppio clic sul nome della directory. Verrà visualizzata una scheda Utenti in ogni pagina specifica della directory. Nella parte inferiore della pagina fare clic su Aggiungi utente.

  5. Selezionare Nuovo utente dell'organizzazione. Aggiungere un utente nel nuovo dominio, ad esempio Test@ContosoEngineering.onmicrosoft.com, quindi fare clic sul segno di spunta nella parte inferiore della pagina.

    Immettere il nome utente e il dominio
  6. Nella pagina Profilo utente assegnare un ruolo aziendale all'utente. Per i test, è consigliabile lasciare almeno un utente con il ruolo Amministratore globale e uno con il ruolo utente.

    Immettere il ruolo utente

Nell'ultimo passaggio il portale di gestione di Azure genera una password temporanea che l'utente può usare per il primo accesso. Dopo aver completato il primo accesso, l'utente deve cambiare la password temporanea. Ricordarsi di salvare la password temporanea, perché sarà necessaria per testare lo scenario.

A questo punto si dispone di un tenant di directory con un utente valido per fornire un'autorità di autenticazione nello scenario di Web Single Sign-On.

Password temporanea

  1. Per iniziare, si parte dal codice dell'applicazione. Aprire Visual Studio, fare clic su Nuovo progetto e selezionare Applicazione Web ASP.NET MVC 4. Nella finestra Nuovo progetto ASP.NET MVC 4 selezionare Applicazione Intranet, verificare che il motore di visualizzazione sia impostato su Razor, quindi fare clic su OK. In questa procedura dettagliata verrà usato ExpenseReport come nome di progetto.

    noteNota
    Nella procedura dettagliata si presuppone che l'installazione di Visual Studio sia configurata con le impostazioni predefinite. Se si sono modificate alcune configurazioni di base, ad esempio il percorso di hosting delle applicazioni Web in fase di sviluppo, si dovranno adattare le istruzioni di conseguenza.



    Nuovo progetto in Visual Studio

    È possibile applicare le istruzioni di questa procedura dettagliata a qualsiasi applicazione Web esistente di Visual Studio 2012, MVC o Web Form, purché non sia presente una logica che modifica in modo significativo la pipeline di elaborazione delle richieste ASP.NET. Per semplicità, verrà creato un nuovo progetto da zero.

    noteNota
    In questa procedura dettagliata vengono fornite istruzioni particolareggiate su come configurare una soluzione .NET. È possibile comunque ottenere gli stessi risultati usando altre piattaforme e altri stack di programmazione. Azure AD usa protocolli aperti nelle funzionalità di accesso Web e anche tutti i principali strumenti, funzionalità e librerie della piattaforma che supportano tali protocolli. I passaggi dettagliati dovranno essere adattati alla sintassi e alle procedure di ogni stack, comunque la suddivisione generale delle attività sarà applicabile a tutte le piattaforme.

    In Visual Studio viene creato automaticamente un nuovo progetto MVC, già configurato per l'esecuzione in IIS Express. Non verranno aggiunte ulteriori funzionalità, poiché le impostazioni predefinite sono sufficienti per illustrare come aggiungere l'accesso Web. L'unica eccezione è rappresentata dall'endpoint usato dall'applicazione. Per impostazione predefinita, Visual Studio configura l'applicazione per la gestione del contenuto tramite HTTP. Questa tuttavia non è una soluzione appropriata per stabilire sessioni sicure, poiché lascia le comunicazioni non protette consentendo a possibili autori di attacchi di impadronirsi di cookie e token. Questo passaggio non è obbligatorio durante la fase di sviluppo, poiché Azure non applica in modo rigoroso il requisito d'uso del protocollo HTTPS. Si tratta comunque di una procedura consigliata.

  2. IIS Express consente di abilitare HTTPS direttamente da Visual Studio in modo estremamente semplice. Selezionare il progetto in Esplora soluzioni, quindi nel riquadro Proprietà impostare SSL abilitato su True.

    L'URL SSL, precedentemente vuoto, verrà popolato con un nuovo indirizzo. Selezionarlo e copiarlo negli Appunti.



    Copia URL SSL

  3. È ora necessario indicare a Visual Studio che si desidera usare sempre l'endpoint HTTPS durante il debug. Tornare a Esplora soluzioni, fare clic con il pulsante destro del mouse sul progetto e scegliere Proprietà. Selezionare la scheda Web sul lato sinistro, scorrere verso il basso fino all'opzione Usa server Web IIS locale e incollare l'URL HTTPS nel campo URL progetto. Salvare le impostazioni (CTRL+S) e chiudere la scheda delle proprietà.



    Modifica URL progetto

    A questo punto si dispone di un'applicazione che può essere configurata per usare Azure AD per l'accesso. Il passaggio successivo consiste nell'informare il tenant di Azure AD dell'esistenza di questa specifica app.

  1. Ridurre a icona Visual Studio e tornare alla scheda Active Directory nel portale di gestione di Azure. All'inizio di questa procedura dettagliata è stata usata l'area Utenti, mentre ora verrà usata l'area Applicazioni. Nella parte superiore della pagina fare clic su Applicazioni.



    App integrate

    Verranno elencate in quest'area le applicazioni registrate nel tenant di directory. Un'applicazione è registrata in un tenant quando vengono soddisfatte le seguenti condizioni:

    • Nella directory è contenuta una voce relativa all'applicazione che ne descrive le coordinate principali, ovvero nome, endpoint associati e così via. Per ulteriori dettagli, vedere più avanti.

    • L'applicazione dispone dell'autorizzazione per eseguire alcune operazioni nel tenant di directory corrente. Tra le operazioni sono incluse la richiesta di un token di accesso e la possibilità di eseguire query sulla directory. Anche in questo caso, per ulteriori informazioni, vedere più avanti.

    ImportantImportante
    Nessuna applicazione può usare Azure AD senza essere stata registrata. Questo requisito è dovuto sia a motivi di sicurezza (devono essere consentite solo le applicazioni approvate dall'amministratore) sia a considerazioni pratiche (l'interazione con Azure AD comporta l'uso di protocolli aperti specifici, che richiedono la conoscenza di parametri chiave di descrizione dell'applicazione).

  2. Poiché il tenant di directory è stato creato da zero, l'elenco delle applicazioni registrate è ancora vuoto. La prima voce sarà relativa all'applicazione appena creata in Visual Studio. Questa sezione sarà interamente dedicata alla registrazione come applicazione.

    Poiché questa è la prima app, avviare il processo facendo clic sul pulsante Aggiungi sulla barra dei comandi del portale di gestione di Azure nella parte inferiore dello schermo. Verrà visualizzata la schermata riportata di seguito:



    Informazioni sull'app

    Il processo di registrazione di un'app tramite il portale di gestione di Azure è strutturato come una classica procedura guidata, in cui vengono visualizzate schermate successive per la raccolta delle informazioni necessarie a seconda delle proprie scelte.

    Nella figura sopra riportata viene mostrata la prima di queste schermate. Le opzioni visualizzate sono chiare:

    • Nome visualizzato: il testo immesso in questo campo viene usato come moniker leggibile per fare riferimento all'app ogni volta che un utente effettua un'operazione correlata, che si tratti di un amministratore che gestisce l'elenco delle app registrate o di un cliente che decide di concedere all'app l'accesso alla directory. Per ulteriori informazioni, vedere il documento Sviluppo di applicazioni Web multi-tenant con Azure AD.

    • Tipo di accesso: questo insieme di pulsanti di opzione consente di specificare le operazioni che l'applicazione è autorizzata a eseguire nel tenant di directory. Ai fini di questa esercitazione, il cui obiettivo è semplicemente configurare l'accesso Web con l'applicazione, la scelta appropriata è Single Sign-On.

      noteNota
      In altri documenti verrà approfondito l'argomento relativo alle autorizzazioni delle applicazioni. Questo documento accenna brevemente i principi alla base di questo processo per fornire un'idea a grandi linee.

      Azure AD rappresenta le applicazioni usando entità chiamate ServicePrincipal. Queste entità sono simili alle più note entità utente, ma sono concepite per la descrizione delle applicazioni.

      L'atto di registrare un'applicazione consiste in pratica nel creare un'entità ServicePrincipal per l'applicazione nel tenant dell'istanza della directory per cui viene concesso l'accesso all'applicazione.

      Il livello di accesso che deve essere concesso a una specifica applicazione è determinato dai ruoli a cui appartiene l'entità ServicePrincipal corrispondente. In questa procedura dettagliata non è necessario, ma se si scegliessero livelli di accesso in lettura e scrittura, verrebbero aggiunti altri passaggi al flusso di registrazione per raccogliere altre informazioni, ad esempio le chiavi da usare per l'autenticazione quando si eseguono queste query. In tal caso, verrebbero archiviate anche le chiavi nell'entità ServicePrincipal che descrive l'applicazione. Per ulteriori informazioni, vedere l'argomento Uso dell'API Graph per effettuare query su Azure AD.

      Le autorizzazioni concesse mediante il processo di registrazione dell'applicazione hanno effetto solo quando si accede alla directory stessa. Non determinano i criteri di accesso per altre risorse di Azure come i database SQL di Azure, le sezioni del portale di gestione e così via.

  3. Dopo aver immesso il nome dell'applicazione e aver scelto il tipo di accesso Single Sign-On, fare clic sulla freccia nell'angolo inferiore destro per passare alla schermata successiva.

    Proprietà app In questa schermata il portale di gestione di Azure raccoglie importanti coordinate richieste dal servizio per il flusso del protocollo di accesso. Si devono immettere le seguenti informazioni:

    • URL APP: questo parametro rappresenta l'identificatore (address) dell'applicazione Web. In questo esempio corrisponde a https://localhost:44341/, ovvero l'indirizzo assegnato da IIS Express all'applicazione. Se le istruzioni sono state eseguite correttamente finora, l'indirizzo dovrebbe essere ancora memorizzato negli Appunti, pronto per essere incollato. Il valore immesso funzionerà per la durata della fase di sviluppo. Dopo la distribuzione dell'applicazione nell'ambiente di gestione temporanea o di produzione di destinazione, sarà necessario tornare al portale di gestione e modificare l'indirizzo in modo che corrisponda alla nuova posizione dell'applicazione. Questi passaggi saranno descritti più avanti nella procedura dettagliata.

      WarningAvviso
      Azure AD deve conoscere l'indirizzo dell'applicazione, in modo da poter reindirizzare il flusso all'applicazione dopo che un utente ha effettuato l'autenticazione nelle pagine di Azure AD.

      Questo indirizzo deve essere stato fornito precedentemente. Se Azure AD reindirizzasse i flussi di autenticazione a qualsiasi indirizzo, sarebbe più facile per gli autori di attacchi assumere il controllo dei flussi di autenticazione e impadronirsi dei token. La registrazione anticipata dell'URL dell'applicazione garantisce che i token di autenticazione specifici per l'applicazione vengano inviati solo all'applicazione.

    • URI ID APP: questo parametro rappresenta l'identificatore (identifier) dell'applicazione Web. In Azure AD questo valore viene usato in fase di accesso per determinare che la richiesta di autenticazione abbia lo scopo di consentire a un utente di accedere a questa specifica applicazione, fra tutte quelle registrate, e quindi applicare le impostazioni corrette.

    noteNota
    Il valore di URI ID APP deve essere univoco nel tenant di directory. Un valore predefinito appropriato per questo campo è il valore di URL APP, ma con questa strategia non è sempre facile rispettare il vincolo di unicità. Se si sviluppa l'app in ambienti host locali, come IIS Express e l'emulatore dell'infrastruttura di Azure, viene generato un intervallo limitato di indirizzi, disponibili per l'uso da parte di più sviluppatori o più progetti di uno stesso sviluppatore. Una possibile strategia consiste nell'aggiungere un elemento al valore di URI APP per differenziarlo.

    Si noti inoltre che il valore di URI ID APP è un URI e in quanto tale non deve corrispondere ad alcun endpoint indirizzabile di rete. Questo significa che è possibile scegliere un valore completamente diverso dal valore del campo URL APP. In realtà, anche se in questa esercitazione viene usata un'applicazione completamente nuova, può accadere di registrare applicazioni esistenti il cui campo URI ID APP è già configurato (nel protocollo di accesso usato in questo scenario, ovvero WS-Federation, il campo URI ID APP è denominato realm) e in tal caso sarà necessario usarlo in questa pagina. Nell'argomento Sviluppo di applicazioni Web multi-tenant con Azure AD verranno descritti alcuni vincoli aggiuntivi introdotti dalla multi-tenancy.

  4. Dopo aver immesso i valori per URL APP e URI ID APP, è possibile fare clic sul segno di spunta nell'angolo inferiore destro.

    Guida introduttiva In questo modo si conclude il processo di registrazione. Nel tenant di directory esiste ora una voce corrispondente all'app e Azure AD è in grado di gestire per suo conto l'autenticazione Web.

    Nella schermata in cui viene indicato che il processo di registrazione ha avuto esito positivo vengono fornite le informazioni necessarie per configurare l'applicazione Web in modo da usare Azure AD per l'accesso. In particolare, la sezione Abilita Single Sign-On con Azure AD contiene alcune impostazioni che dovranno essere incollate in Visual Studio.

    Lasciare il browser aperto su questa pagina e tornare a Visual Studio per l'attività successiva della procedura dettagliata.

Ora che Azure AD è in grado di rilasciare token di autenticazione per l'applicazione, l'ultimo passaggio per abilitare l'accesso Web consiste nel configurare l'applicazione in modo che gestisca le richieste con il protocollo di autenticazione appropriato. L'implementazione del protocollo consente all'applicazione di richiamare Azure AD, e in particolare il tenant di directory, per effettuare l'autenticazione utente all'inizio di una sessione di lavoro di un utente con l'app.

È importante comprendere alcune delle informazioni generali sulla meccanica dell'autenticazione quando si usano i protocolli di accesso Web. Per ulteriori informazioni, vedere la sezione di approfondimento.

Il modello di progetto scelto è l'applicazione Intranet MVC 4. Questo modello in genere si basa sull'autenticazione integrata di Windows per accertarsi che l'utente dell'app venga autenticato. Questo meccanismo agisce a livello di rete e viene applicato a qualsiasi servizio pubblicato nella rete Intranet, senza dover aggiungere alcuna logica di autenticazione all'applicazione stessa.

Quando si distribuisce un'applicazione all'esterno della rete Intranet, come nel caso delle applicazioni cloud, non è più possibile usare l'autenticazione a livello di rete. La strategia più comune per gestire l'autenticazione in questi casi prevede l'aggiunta di middleware a protezione dell'applicazione, in modo da ricreare la verifica dell'autenticazione necessaria a livello superiore. Questo livello aggiuntivo può essere usato per intercettare le richieste non autenticate, applicare protocolli di autenticazione, reindirizzare gli utenti per l'autenticazione all'esterno dell'applicazione, tornare alle informazioni dell'applicazione sull'utente autenticato, gestire le sessioni e in generale eseguire tutte le attività necessarie per il controllo di accesso.

Questa strategia viene applicata in modo uniforme nel settore indipendentemente dalle piattaforme, dagli stack di sviluppo e dai protocolli di accesso scelti. Quanto avviene nello specifico e il modello di programmazione possono variare, ma il modello generale resta fondamentalmente lo stesso.

In questa procedura dettagliata si stabilirà la connessione dell'applicazione con Azure AD tramite il protocollo WS-Federation. Questa è solo una delle possibili scelte per l'implementazione del servizio Web SSO. L'altra scelta più comune è SAML-P.

.NET Framework 4.5 supporta WS-Federation a livello nativo. Tutte le classi necessarie per applicare il flusso di protocollo, l'elaborazione dell'autenticazione e la gestione delle sessioni nel contesto delle applicazioni ASP.NET sono incorporate.

In pratica .NET 4.5 offre un insieme di moduli HTTP di cui deve essere creata un'istanza nella pipeline HTTP dell'applicazione. Questi moduli sono progettati per fare riferimento a sezioni di configurazione note contenenti le coordinate del protocollo sia per l'applicazione sia per l'autorità di autenticazione, in questo caso il tenant di Azure AD. Man mano che si ricevono richieste, i moduli le esaminano e applicano il protocollo di autenticazione in modo appropriato. Ad esempio, dopo aver ricevuto una richiesta non autenticata, i moduli leggono le coordinate del tenant di Azure AD dalla configurazione, le usano per comporre un messaggio di accesso WS-Federation e usano tale messaggio per reindirizzare automaticamente l'utente per l'autenticazione in Azure AD.

noteNota
Il subset di classi di .NET Framework 4.5 dedicate alle attività correlate all'identità basata sulle attestazioni è noto come Windows Identity Foundation (WIF). Anche le applicazioni basate su versioni precedenti di .NET Framework (3.5 e 4.0) possono implementare i passaggi descritti in questa procedura dettagliata, usando una versione precedente di WIF rilasciata fuori banda come libreria autonoma (per il download, fare clic qui). Si noti tuttavia che le istruzioni dettagliate sarebbero diverse, poiché le due versioni non sono completamente compatibili (le classi sono contenute in spazi dei nomi diversi) e sarebbe necessario usare strumenti per versioni di Visual Studio diverse (2008 e 2010, per il download fare clic qui).

In Visual Studio 2012 sono disponibili strumenti che consentono di puntare e fare clic per configurare le applicazioni per l'uso di WS-Federation per l'accesso Web. È possibile usare l'interfaccia utente degli strumenti per fornire alcune informazioni chiave sull'autorità che si desidera considerare attendibile per l'autenticazione e lo strumento genererà le voci di configurazione corrispondenti. In questa procedura dettagliata sarà necessario scrivere poco codice, poiché gli strumenti provvederanno a generare automaticamente la maggior parte del codice richiesto.

  1. Dopo aver illustrato come verrà implementato l'accesso Web, è possibile usare lo strumento di identità e accessi per configurare l'applicazione. In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto delle applicazioni, quindi scegliere Identity and Access… dal menu di scelta rapida.

    Identità e accesso In Visual Studio verrà visualizzata la finestra di dialogo riportata di seguito.

    Provider di accesso e identità La maggior parte delle attività verrà effettuata nella scheda Providers attualmente visualizzata. Ai fini di questa procedura dettagliata verranno ignorate tutte le opzioni che non verranno usate per l'attività in questione.

  2. Nello strumento vengono elencati diversi tipi di autorità che è possibile usare per l'outsourcing dell'autenticazione. In questo caso specifico si intende usare un provider di identitàaziendale. Fare clic sulla voce corrispondente, ovvero la seconda opzione dall'alto.

    Configurazione accesso e identità Dopo aver selezionato l'opzione, nel pannello inferiore vengono visualizzati gli elementi dell'interfaccia utente corrispondenti. Le informazioni richieste dal controllo corrispondono esattamente alle voci visualizzate alla fine del processo di registrazione dell'applicazione descritto nella sezione precedente. Di seguito sono elencate le informazioni che devono essere immesse, dal basso verso l'alto:

    • Enter the APP ID URI (realm) of your application: questo valore è l'identificatore dell'applicazione definito durante la registrazione. Tornare alla finestra del browser in cui è visualizzato il portale di gestione, copiare il valore corrispondente dal campo Aggiorna codice con URI ID app e incollarlo in questo campo.

    • Enter the path to the STS metadata document: il documento di metadati STS è un file contenente una descrizione dell'autorità a cui si desidera effettuare la connessione, leggibile dal computer. Questo file verrà usato dallo strumento per determinare il valore dei parametri essenziali per il flusso di accesso. Per ulteriori informazioni, vedere più avanti. Ogni tenant di Azure AD espone un documento di questo tipo, il cui percorso viene fornito alla fine del processo di registrazione. Passare al portale di gestione, copiare il valore corrispondente dalla pagina di registrazione dell'applicazione, tornare allo strumento e incollare il percorso in questo campo.

      noteNota
      Quando si incolla il percorso del documento di metadati nella casella di testo, verrà visualizzato un avviso relativo a un certificato non valido. Questo avviso viene generato perché il documento di metadati è firmato con un certificato autofirmato, ma questo non è un problema.

    Fare clic su OK. Lo strumento leggerà nel documento di metadati specificato le coordinate dell'autorità, ovvero l'indirizzo degli endpoint da usare per l'accesso, il certificato X.509 da usare per la verifica della firma dei token di autenticazione, il formato e la versione dei token di autenticazione rilasciati e così via. Tali informazioni verranno usate per generare e aggiungere al file web.config le voci necessarie per connettere l'applicazione ad Azure AD.

Nel seguente elenco vengono descritte le voci principali aggiunte al file web.config dallo strumento. Per una descrizione più dettagliata, fare riferimento alla sezione di approfondimento del documento.

  • Voci <section> per system.identityModel e system.identityModel.services: sono necessarie affinché la configurazione comprenda le impostazioni di configurazione specifiche delle identità.

  • Impostazioni <authorization> in <system.web>: lo strumento modifica automaticamente le impostazioni di autenticazione ASP.NET esistenti per richiedere l'autenticazione di tutte le richieste inviate all'applicazione. In questo modo viene applicato il cosiddetto comportamento di "reindirizzamento programmato", in cui ogni richiesta non autenticata viene reindirizzata all'autorità di autenticazione (in contrapposizione all'eventualità che parti dell'applicazione siano disponibili per utenti non autenticati). Questo è il comportamento predefinito nelle applicazioni line-of-business, in cui l'autenticazione è spesso invisibile all'utente, poiché è stato già effettuato l'accesso con l'autorità di autenticazione. Se desidera modificare questo comportamento per fornire requisiti di autenticazione per i singoli casi, lo sviluppatore può modificare le impostazioni di <authorization> in base alle esigenze.

  • WSFederationAuthenticationModule (FAM) e SessionAuthenticationModule (SAM) in <system.webServer/modules>: queste voci aggiungono nella pipeline HTTP dell'applicazione i moduli HTTP che si occupano di implementare l'uso di WS-Federation per l'autenticazione. FAM è il modulo responsabile dell'implementazione del protocollo. Le richieste di accesso, la convalida dei token e la gestione della disconnessione sono i flussi principali di cui è responsabile. Il modulo SAM gestisce le sessioni, in modo particolare genera cookie di sessione, li convalida e li applica per ogni richiesta, gestisce la lunghezza della sessione e così via. Il comportamento di questi moduli è determinato dall'elemento di configurazione descritto di seguito.

  • Sezione <system.identitymodel/identityConfiguration>: questo elemento determina il comportamento dell'applicazione durante la fase di autenticazione. Esempio: nel sottoelemento ValidatingIssuerNameRegistry archivia l'elenco di autorità considerate attendibili per fornire servizi di autenticazione registrandone i nomi e i certificati usati per la firma.

  • Sezione <system.identitymodel.services/federationConfiguration>: in questa sezione vengono fornite le coordinate necessarie per la gestione dei flussi WS-Federation, ovvero l'indirizzo dell'autorità da usare per le richieste di accesso, l'identificatore dell'applicazione stessa da includere nelle richieste e così via.

La configurazione generata automaticamente è sufficiente per usare Azure AD per l'accesso Web. Non è necessario scrivere codice specifico dell'autenticazione nell'applicazione stessa. Se si desidera accedere alle informazioni dell'identità utente, è sufficiente eseguire query sulle attestazioni nell'entità utente corrente. Si supponga ad esempio di voler accedere al nome e al cognome dell'utente corrente. A tale scopo, sarà possibile usare il seguente codice, senza dover necessariamente conoscere la modalità di autenticazione:

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

A partire da .NET 4.5, ogni identità in .NET è rappresentata con un elemento ClaimsPrincipal. In questo caso l'elemento ClaimsPrincipal corrente è stato costruito durante la convalida di un token di autenticazione generato da Azure AD e presentato dall'utente al momento dell'accesso.

Ogni elemento ClaimsPrincipal include una raccolta di attestazioni, ovvero attributi che descrivono l'utente corrente secondo quanto dichiarato dall'autorità che ha effettuato l'autenticazione. Nella procedura dettagliata le attestazioni nell'entità utente sono quelle rilasciate nel token da Azure Active Directory. Per un elenco completo delle attestazioni disponibili, fare riferimento alla documentazione online.

Azure AD rilascia un insieme fisso di attestazioni per gli utenti autenticati. Di seguito sono riportate informazioni di riferimento rapido per tutte le attestazioni previste provenienti da Azure AD. Per una descrizione completa, vedere la documentazione.

 

Tipo Valore nell'esempio Descrizione

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

Identificatore univoco, immutabile, non riutilizzabile e indirizzato dell'utente autenticato dell'applicazione corrente.

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

Identificatore dell'utente nella directory. Utile per query di directory sull'utente.

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

Identificatore del tenant di directory.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

Nome specificato dell'utente.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

UPN dell'utente.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

Cognome dell'utente.

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

Identificatore dell'autorità che ha autenticato l'utente, espresso nel protocollo di accesso Web, in questo caso WS_Federation.

A questo punto l'applicazione ha tutti gli elementi necessari per la dimostrazione dell'uso dell'accesso Web con Azure AD, ma non è ancora completa. Devono essere aggiunte almeno altre due importanti funzionalità: il supporto per la disconnessione e l'aggiornamento automatico delle coordinate del protocollo dell'autorità.

Nelle due sezioni successive verrà illustrato come aggiungere queste due funzionalità. È consigliabile prenderne visione prima di passare alla sezione "Eseguire l'applicazione".

I protocolli di accesso Web attualmente in uso spesso prevedono l'esecuzione di operazioni di disconnessione distribuite. Questi sono flussi in cui l'applicazione corrente non solo annulla la sessione dell'utente corrente, ma segnala anche all'autorità che deve essere propagato un comando di disconnessione a tutte le altre sessioni di applicazioni che potrebbe aver stabilito la stessa autorità. WS-Federation non costituisce un'eccezione e offre un flusso di disconnessione completo implementato interamente nel modello a oggetti di WIF. In questa sottosezione verrà illustrato come aggiungere all'applicazione di esempio funzionalità di disconnessione distribuite. Questa attività consiste semplicemente nel fornire le indicazioni corrette nell'esperienza utente per attivare il flusso di disconnessione e generare il messaggio di disconnessione appropriato da impostare nel tenant di Azure AD.

  1. Per iniziare, aggiungere un controller SignOut all'applicazione. A tale scopo, individuare la cartella Controller nel progetto in Esplora soluzioni, fare clic su di essa con il pulsante destro del mouse, scegliere Aggiungi, quindi Controller. Denominarlo SignOutController, selezionare Controller MVC vuoto (generalmente la stringa predefinita), quindi fare clic su Aggiungi.

  2. Poiché si useranno le classi di alcuni nuovi assembly, si dovranno aggiungere i relativi riferimenti. Di nuovo in Esplora soluzioni fare clic con il pulsante destro del mouse sul nodo Riferimenti, scegliere Aggiungi riferimento, digitare system.identitymodel.services nel campo Assembly di ricerca e selezionare dall'elenco principale l'assembly corrispondente. Fare clic su OK.

  3. Tornare al file SignOutController.cs appena creato. Aggiungere le seguenti voci alle direttive using:

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    Modificare ora l'implementazione della classe SignOutController come indicato di seguito:

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    Ecco una rapida spiegazione delle operazioni eseguite dal codice.

    • Il primo metodo Index() gestisce la richiesta del modulo https://localhost:44341/SignOut, ovvero l'indirizzo di una visualizzazione che verrà aggiunta in pochi passaggi più avanti nella procedura dettagliata. L'obiettivo è segnalare una disconnessione effettuata correttamente. Verrà usato nel metodo successivo.

    • Il metodo SignOut() gestisce la richiesta del modulo https://localhost:44341/SignOut/SignOut e include la logica di disconnessione principale.

    • Nella prima riga viene recuperato l'oggetto usato da WIF per tenere traccia delle impostazioni di WS-Federation nel file web.config. Verrà usato per creare un messaggio di disconnessione personalizzato in base all'applicazione corrente.

      noteNota
      Fare riferimento ai valori del file di configurazione anziché a valori impostati come hardcoded o provenienti da archivi personalizzati è in genere una procedura appropriata, poiché rende il codice adattivo e allineato al resto delle impostazioni del protocollo. La logica continuerà a funzionare indipendentemente dal numero di volte in cui verranno modificate le impostazioni nel file config, prima e dopo la distribuzione.

    • Nella seconda e nella terza riga viene creato l'indirizzo mittente che deve essere usato dall'autorità alla fine del flusso di disconnessione. Si desidera che l'indirizzo punti alla visualizzazione descritta precedentemente, pertanto il codice ottiene l'URL della richiesta corrente ed elimina l'elemento "SignOut" finale. La derivazione dell'indirizzo dalla richiesta ne garantisce la corretta risoluzione per il client. Se invece si ottiene l'indirizzo dal livello host, è possibile che si verifichino problemi sulle porte interne quando si usa il bilanciamento del carico.

    • Nella quarta riga viene usato WIF per creare un messaggio di disconnessione WS-Federation, passando l'URL e l'indirizzo mittente dell'autorità definiti nella riga precedente. Sarebbe possibile creare facilmente il messaggio direttamente nel formato di trasmissione. L'uso del modello a oggetti WIF consente tuttavia di scrivere codice più conciso e ignorare la maggior parte dei dettagli della sintassi. Se si desidera esaminare un messaggio di disconnessione, accertarsi di acquisire una traccia HTTP quando si eseguirà l'applicazione in una sezione successiva o vedere le specifiche fornite in questo documento.

    • Nella quarta riga viene aggiunto al messaggio l'identificatore dell'applicazione corrente, così come è registrato nell'attributo realm dell'elemento di configurazione <wsFederation>.

    • Nella quinta riga viene usato il modulo SAM (indicato precedentemente nella descrizione della configurazione generata automaticamente) per la pulizia della sessione locale, tra cui l'eliminazione del cookie di sessione generato al momento dell'accesso e la pulizia ritenuta necessaria di qualsiasi risorsa locale.

      noteNota
      L'applicazione di esempio qui presentata non esegue molte operazioni, mentre le applicazioni reali potrebbero allocare risorse durante la sessione di un utente. In tal caso, è possibile usare gli eventi SigningOut e SignedOut di SAM aggiungendo gestori eventi corrispondenti nel file Global.asax per la pulizia delle risorse che devono essere rimosse con la chiusura di una sessione.

La visualizzazione usata sarà molto semplice. Come indicato precedentemente, lo scopo è solo creare un punto di ritorno significativo per il flusso di disconnessione.

  1. In Esplora soluzioni fare clic con il pulsante destro del mouse sul nodo Visualizzazioni e aggiungere una cartella SignOut.

  2. In questa cartella aggiungere una visualizzazione facendo clic con il pulsante destro del mouse sulla cartella e scegliendo Aggiungi, quindi Visualizzazione. Assegnare anche alla nuova visualizzazione il nome SignOut. Inserire codice di presentazione segnaposto nel file della visualizzazione (SignOut.cshtml) per segnalare che è stata effettuata la disconnessione. Esempio:

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. Come indicato nella sezione precedente, l'applicazione è stata configurata per gestire l'autenticazione mediante reindirizzamenti programmati. Se pertanto si prova ad accedere a questa visualizzazione dopo una disconnessione che ha avuto esito positivo (come previsto), si verrà immediatamente reindirizzati ad Azure AD per ripetere l'accesso. Per evitare questo comportamento, è possibile usare l'elemento <location> nel file web.config per creare un'eccezione per i criteri di autenticazione.

    Individuare la prima occorrenza dell'elemento <system.web> e incollare al di sopra di esso il seguente frammento di codice:

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    Questo indica ad ASP.NET che il percorso SignOut è accessibile a chiunque, inclusi gli utenti non autenticati. Questa soluzione consentirà di eseguire il rendering della visualizzazione nel browser anche in caso di disconnessione effettuata con esito positivo.

  1. Ora che l'app è in grado di disconnettersi, non resta che esporre la funzionalità all'utente. Ecco un modo semplice per ottenere questo risultato: aprire _layout.cshtml dal percorso Visualizzazioni\Shared in Esplora soluzioni. Cercare la stringa "Hello" per trovare il codice per il rendering delle informazioni di accesso nella parte superiore del tipico layout MVC 4, quindi modificare la sezione di accesso come segue:

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

Questa modifica aggiunge un comando di disconnessione a destra del messaggio di saluto dell'utente connesso, per consentire di disconnettersi da qualsiasi visualizzazione.

Lo strumento di identità e accessi ha configurato l'applicazione in modo da accettare i token provenienti dal tenant di Azure AD selezionato. Per ottenere questo risultato, ha memorizzato nella cache nel file web.config le coordinate di protocollo necessarie per connettersi agli endpoint di Azure AD desiderati. Ha inoltre salvato le informazioni chiave usate al momento dell'autenticazione per verificare che il token in ingresso abbia effettivamente origine dal tenant di Azure AD, ossia il nome dell'autorità emittente che rappresenta il tenant e la chiave pubblica (nel formato del certificato X.509) che deve essere usata per verificare la firma del token.

Una procedura di sicurezza comune prevede il rinnovo periodico delle chiavi crittografiche e le chiavi di firma di Azure AD non sono un'eccezione. Le chiavi vengono ritirate a intervalli di tempo fissi per essere sostituite da nuove chiavi nella logica di firma dell'autorità emittente e nel documento di metadati del tenant. In caso di emergenza, le chiavi possono essere rinnovate al di fuori del ciclo degli intervalli di tempo determinati, senza quasi alcun preavviso.

Ogni volta che viene effettuato il rollover della chiave di firma, le impostazioni dell'applicazione devono essere modificate di conseguenza. Seguendo l'approccio illustrato finora nella procedura dettagliata, questo comporterà la riesecuzione dello strumento per leggere il nuovo documento di metadati e aggiornare le voci del file web.config.

Per ridurre al minimo i tempi di inattività, è opportuno aggiungere una logica di riparazione automatica direttamente nell'applicazione, in modo da poter usare il documento di metadati a livello di codice e reagire al rollover della chiave senza intervento dell'operatore. Ecco un esempio di come implementare questa funzionalità.

  1. Usare Esplora soluzioni, come descritto precedentemente nel documento, per aggiungere un riferimento all'assembly System.IdentityModel.

  2. Aggiungere le seguenti direttive using nel file Global.asax:

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. Aggiungere quindi il seguente metodo nel file Global.asax:

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    La logica è molto semplice. ValidatingIssuerNameRegistry è la classe usata dallo strumento di identità e accessi per registrare informazioni sulle autorità considerate attendibili e sulle chiavi da usare per verificare i token rilasciati. WriteToConfig è un metodo statico che legge le impostazioni dell'autorità emittente da un documento di metadati (in questo caso recuperato dal file config, dove è stato archiviato al primo avvio dello strumento dalla seconda riga del metodo) e le usa per creare o aggiornare la sezione di configurazione corrispondente del file nel percorso specificato (costruito dall'elemento AppDomain corrente nella prima riga del metodo).

  4. Per inserire RefreshValidationSettings() nel ciclo di vita dell'applicazione, richiamarlo da Application_Start() come illustrato di seguito.

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    Chiamando RefreshValidationSettings da Application_Start viene garantito che il file web.config verrà modificato nel momento appropriato, mentre se si procede manualmente in un momento successivo nel ciclo di vita dell'applicazione si rischia di attivare un aggiornamento.

ImportantImportante
È necessario applicare alcune misure precauzionali aggiuntive quando si effettua l'aggiornamento automatico delle chiavi di convalida dall'applicazione. La minaccia principale da cui difendersi è l'hijack del DNS, in cui l'autore di un attacco usa malware per indurre a puntare a un documento di metadati dannoso in modo che l'applicazione consideri attendibili chiavi non corrette.

Se non si sostituiscono le impostazioni .NET predefinite per la gestione delle richieste HTTP, si è già protetti dallo scenario precedente poiché i documenti di metadati sono ospitati in endpoint HTTPS. Un hijack del DNS può reindirizzare le richieste a un endpoint dannoso, ma tale endpoint non può superare la convalida del server HTTPS. Poiché non è proprietario del dominio in cui sono ospitati i documenti di metadati, l'autore dell'attacco non può ottenere un certificato rilasciato per tale dominio e pertanto il client sarà in grado di rilevare un problema con il server ed evitare il reindirizzamento inappropriato.

In alcuni scenari di sviluppo a volte viene richiesto di disattivare la convalida HTTPS (in genere mediante la classe ServicePoint). Se si usa la logica di aggiornamento automatico dei metadati descritta in questa sezione, è fondamentale ripristinare le impostazioni di convalida HTTPS prima della distribuzione dell'applicazione nell'ambiente di produzione.

  1. È ora possibile finalmente osservare l'applicazione in azione. Premere F5. Si aprirà una finestra del browser che tenterà di accedere all'URL specificato nelle impostazioni del progetto nella sezione "Creare un'applicazione MVC ASP.NET".

    Verrà visualizzato innanzitutto un errore di certificato. Questo è un comportamento previsto. Fare clic su Continuare con il sito Web (scelta non consigliata). Non ignorare questo errore in un'applicazione nell'ambiente di produzione. L'errore è tuttavia accettabile ai fini di questa procedura dettagliata.

    CertificateError Tenendo sotto controllo la barra degli indirizzi, è possibile osservare per un breve istante l'URL dell'app. Tuttavia, il modulo FAM a protezione dell'app riconoscerà immediatamente la chiamata come non autenticata, leggerà nel file di configurazione come procedere e attiverà il reindirizzamento dell'accesso ad Azure AD. La barra degli indirizzi con l'URL viene sostituita da una delle autorità e l'utente visualizza la richiesta di effettuare l'autenticazione tramite l'interfaccia utente di Azure AD.

    noteNota
    Il nuovo account utente creato in precedenza non può essere usato per gestire la sottoscrizione Azure se inizialmente l'accesso al portale di gestione è stato effettuato mediante un account Microsoft. Se si prova a tornare al portale di gestione dopo aver effettuato l'accesso all'applicazione come nuovo utente, viene visualizzato un messaggio di errore. In alternativa, accedere al portale di gestione con l'account usato per creare il tenant di directory. Se invece inizialmente l'accesso al portale di gestione è stato effettuato con un account di Azure AD e al nuovo utente creato in precedenza è stato assegnato il ruolo Amministratore globale, questo nuovo utente potrà gestire la sottoscrizione Azure.

    Accedi ad AAD
  2. Immettere le credenziali dell'utente creato nel tenant di Azure nella prima sezione della procedura dettagliata. Fare clic sul pulsante Accedi.

    Quando è stato creato l'utente nel tenant di Azure AD, il portale di gestione ha assegnato una password temporanea. È necessario effettuare l'autenticazione usando questa password. Poiché tuttavia questa password deve essere temporanea, durante la prima operazione di accesso verrà chiesto di scegliere una password utente appropriata per poter procedere con il flusso di autenticazione. Al termine di questa operazione, viene ripristinato il normale flusso di accesso all'app.

    Home page dell'applicazione Dopo che l'autenticazione ha avuto esito positivo, WIF elabora le attestazioni del token di autenticazione in ingresso, che vengono usate dal semplice codice di visualizzazione aggiunto in HomeController. Da questo momento in poi sarà possibile esplorare il sito senza dover effettuare di nuovo l'autenticazione. Ogni postback trasporterà il cookie di sessione gestito dal modulo SAM.

  3. Per osservare quanto accade quando si termina la sessione, fare clic sul collegamento di disconnessione nell'angolo superiore destro. È così possibile osservare i reindirizzamenti codificati in precedenza, che consentono di accedere alla visualizzazione seguente.

    Disconnetti Per accertarsi di essere effettivamente disconnessi, fare clic su un elemento qualsiasi dell'interfaccia utente. Il ciclo di autenticazione ricomincerà dall'inizio.

Nella parte del documento relativa alla procedura dettagliata sono stati illustrati i passaggi principali da eseguire per aggiungere l'accesso Web a un'applicazione Web. Nel resto del documento vengono approfonditi i concetti di base esaminando alcuni argomenti chiave e illustrando alcune delle altre attività eventualmente necessarie in modo che l'applicazione passi al livello successivo.

In questa sezione si imparerà a modificare le impostazioni dell'applicazione per la distribuzione e l'esecuzione in Siti Web di Azure. L'applicazione resta sostanzialmente invariata. L'unico aspetto che richiede attenzione è l'adattamento al nuovo indirizzo e alla gestione della sessione dell'app.

Questa parte del documento richiede la disponibilità di un sito Web di Azure come destinazione della distribuzione dell'applicazione. Se è già disponibile un sito Web, è possibile usarlo, altrimenti vedere questo documento per informazioni su come creare e pubblicare un sito Web di Azure. Se si segue l'esercitazione contenuta in tale documento, fermarsi subito dopo aver scaricato il profilo di pubblicazione. È necessario infatti modificare alcuni aspetti prima di distribuire l'applicazione.

Modificare le impostazioni dell'applicazione nel portale di gestione di Azure

Nella sezione relativa alla registrazione dell'applicazione uno dei parametri chiave per la definizione dell'applicazione nell'interfaccia utente di Azure AD è costituito dall'URL dell'applicazione stessa. Nei passaggi della procedura dettagliata eseguiti finora è stato usato IIS Express locale come posizione dell'app, ma per una distribuzione in Siti Web di Azure l'URL dell'applicazione cambia e le impostazioni in Azure AD devono riflettere questa modifica.

  1. Tornare al portale di gestione, selezionare la scheda Active Directory sul lato sinistro, fare clic sul tenant di directory, selezionare l'intestazione Applicazioni e fare clic sulla voce corrispondente all'applicazione usata. Fare clic sull'intestazione Configura. Verrà visualizzata una schermata che consentirà di modificare le impostazioni dell'applicazione immesse al momento della creazione. Ai fini di questa esercitazione, ignorare le aree superiori della schermata e scorrere verso il basso fino alla sezione relativa al servizio Single Sign-On.

    Single Sign-On
  2. Cercare la casella di testo URL RISPOSTA e immettere l'indirizzo del sito Web di Azure di destinazione, ad esempio https://aadga.windowsazure.net/. In questo modo Azure AD potrà restituire i token nel percorso del sito Web di Azure dopo che l'autenticazione ha avuto esito positivo (in contrapposizione al percorso usato in precedenza nel thread durante la fase di sviluppo). Dopo aver aggiornato il valore, fare clic su SALVA sulla barra dei comandi nella parte inferiore della schermata.

noteNota
Come è possibile osservare, per il campo URI ID APP continua a essere usato il valore basato su localhost creato precedentemente nel documento.

Finché l'identificatore è nel formato URI ed è univoco in tutte le applicazioni del tenant di directory corrente, tecnicamente per il tipo di applicazioni descritte in questo documento funzionerà qualsiasi valore. Per questo motivo nelle istruzioni principali non è previsto l'aggiornamento di tale valore.

Per facilità di gestione potrebbe essere necessario tuttavia modificare il campo URI ID APP impostandolo su un valore che rappresenti maggiormente l'applicazione. Un esempio tipico può essere un valore derivato dal valore dell'URL di risposta.

Si noti che se si modifica il valore di URI ID APP, sarà necessario applicare modifiche più estese all'applicazione prima della distribuzione. Per ulteriori dettagli, vedere più avanti.

Preparare l'applicazione per l'esecuzione in Siti Web di Azure

La configurazione dell'accesso Web è già quasi interamente compatibile con il cloud: è necessario applicare una sola modifica, dovuta principalmente alle funzionalità di Siti Web di Azure.

Il processo di accesso Web risulta nella creazione di un cookie di sessione, che viene inviato a ogni richiesta dal momento dell'autenticazione in poi. Il cookie di sessione viene creato dal middleware WIF e per impostazione predefinita viene firmato e crittografato tramite DPAPI (per informazioni generali, vedere questo documento) per evitare usi impropri dal client (ad esempio la modifica dell'elenco delle attestazioni per innalzare i privilegi). Tuttavia, le impostazioni IIS in Siti Web di Azure impediscono l'uso di DPAPI per la protezione delle sessioni ed è pertanto necessario modificare il modo in cui WIF protegge il cookie associato. In .NET Framework 4.5 è disponibile una soluzione alternativa incorporata basata su MachineKey (vedere la documentazione qui) che funziona senza problemi in Siti Web di Azure.

Lo strumento di identità e accessi consente di effettuare questa modifica in modo molto semplice.

  1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni, scegliere Identity and Access… e selezionare la scheda Configuration. Verrà visualizzata una schermata simile alla seguente:

    Identità e accesso Siti Web Windows Azure
  2. Selezionare semplicemente la casella di controllo Enable web farm ready cookies e fare clic su OK. Lo strumento aggiungerà gli elementi necessari nel file web.config (sostituendo in pratica la classe predefinita SessionSecurityTokenHandler con MachineKeySessionSecurityTokenHandler) per passare a MachineKey come metodo di protezione dei cookie.

    noteNota
    Se nel passaggio precedente è stato modificato il valore di URI ID APP nel portale di gestione di Azure, è possibile usare questa interfaccia utente per applicare facilmente queste modifiche al progetto. È sufficiente incollare il valore di URI ID APP nei due campi di testo superiori e fare clic su OK. Le modifiche verranno applicate dallo strumento nei punti appropriati nel file config.

    Facoltativamente, è possibile considerare l'eventualità di disattivare temporaneamente i messaggi di errore personalizzati ASP.NET aggiungendo la voce <customErrors mode="Off" /> nella sezione <system.web> del file web.config. In questo modo sarà più semplice risolvere eventuali problemi in fase di distribuzione. Ricordarsi tuttavia di riattivarli prima di passare all'ambiente di produzione. È possibile infatti che gli autori di attacchi usino i messaggi di errore dettagliati per ricercare eventuali aperture nell'applicazione e customError impedirà che questo si verifichi.

Queste sono tutte le operazioni necessarie per preparare l'applicazione per l'esecuzione come sito Web di Azure. Usare le impostazioni di pubblicazione per distribuire l'applicazione, quindi aprire un browser, passare all'indirizzo azurewebsite.net dell'applicazione e seguire lo stesso flusso illustrato nella sezione della procedura dettagliata relativa alla verifica dell'applicazione. Poiché la logica personalizzata è stata progettata in modo da essere indipendente dalla posizione, sarà possibile effettuare le stesse operazioni eseguite in locale.

Lo strumento di identità e accessi genera automaticamente le impostazioni di configurazione necessarie per l'integrazione dell'app con il tenant di Azure AD tramite WS-Federation. Nel migliore dei casi, non sarà mai necessario visualizzare tali impostazioni. Esistono tuttavia alcune situazioni in cui è necessario modificare il comportamento predefinito o risolvere un problema. In questi casi, la conoscenza delle impostazioni di configurazione di WIF può rivelarsi utile.

Il metodo e le classi WIF usati nel flusso di accesso Web sono documentati in modo completo in MSDN. In questo documento verrà presentata una versione del file web.config con annotazioni dopo le modifiche apportate dallo strumento di identità e accessi. Per comodità, sono state incluse anche le modifiche che derivano dalla sezione sulla pubblicazione in Siti Web di Azure.

noteNota
Per chiarezza il documento include l'origine completa del file Web.config. Le annotazioni tuttavia sono state incluse solo nelle sezioni pertinenti per WIF.

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

Non sono necessari commenti per la configurazione precedente.

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

Nella configurazione precedente quest'area carica le classi necessarie per ASP.NET per leggere e interpretare le sezioni del file config usate da WIF per modellare il flusso di WS-Federation e le impostazioni di autenticazione.

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

Non sono necessari commenti per la configurazione precedente.

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

Per la configurazione precedente, le voci appSettings vengono acquisite dallo strumento di identità e accessi per tenere traccia di impostazioni importanti (ad esempio l'indirizzo del documento di metadati usato nella sezione di rollover della chiave) che non verrebbero salvate in altre posizioni.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Per la configurazione precedente, i due elementi <location> creano due aree nell'applicazione Web accessibili senza requisiti di autenticazione (vedere più avanti). La sezione FederationMetadata viene creata dallo strumento di identità e accessi, che crea un documento di metadati per la descrizione dell'applicazione e che può essere usato dalle autorità per il provisioning dell'applicazione. La sezione SignOut è stata aggiunta manualmente seguendo le istruzioni relative all'implementazione della disconnessione Web.

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

Per la configurazione precedente, per impostazione predefinita lo strumento di identità e accessi definisce le impostazioni di autenticazione e autorizzazione ASP.NET in modo che ogni parte dell'applicazione Web (a parte le eccezioni descritte precedentemente) richieda l'autenticazione degli utenti prima della gestione delle richieste. Benché questa configurazione sia in genere appropriata per le applicazioni line-of-business, a volte gli sviluppatori desiderano mantenere alcune aree per l'accesso anonimo. In tal caso, sarà necessario modificare queste impostazioni a seconda delle esigenze.

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

Non sono necessari commenti per la configurazione precedente.

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

Per la configurazione precedente, le voci di questa sezione inseriscono nella pipeline ASP.NET i moduli HTTP che implementano le funzionalità di base di gestione della sessione e del protocollo. Il modulo WSFederationAuthenticationModule (FAM) applica WS-Federation, convalidando i token in ingresso e generando messaggi di accesso per l'autorità in conformità alle specifiche del protocollo. Il modulo SessionAuthenticationModule (SAM) crea e convalida i cookie di sessione, insieme al modulo FAM.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

Non sono necessari commenti per la configurazione precedente.

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

Per la configurazione precedente, <system.identityModel> esegue il wrapping di tutte le impostazioni specifiche delle classi WIF. Il primo elemento figlio, IdentityConfiguration, fornisce una descrizione indipendente dal protocollo per il comportamento dell'applicazione. Nell'elenco AudienceUris sono contenuti tutti i valori che verranno considerati come ambiti accettabili da WIF nei token in ingresso per le applicazioni correnti. Questi valori corrispondono in genere all'area di autenticazione dell'applicazione o al valore di URI ID APP per Azure AD. Un token in ingresso deve dichiarare che il destinatario previsto è uno dei valori elencati. In caso contrario, WIF presumerà che si tratti di un token rubato e rifiuterà la chiamata.

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

Per la configurazione precedente, l'elemento ValidatingIssuerNameRegistry contiene l'elenco delle tuple di chiavi nome autorità emittente-verifica della firma accettabili. In questa procedura dettagliata le impostazioni rifletteranno i valori associati al tenant di Azure AD. Questo elemento garantisce che nessun'altra autorità emittente, inclusi altri tenant di Azure AD di proprietà di altre società, potrà accedere all'applicazione.

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

Per la configurazione precedente, questo elemento disattiva la convalida del certificato nella pipeline WIF. Questa misura è necessaria nel caso di Azure AD, poiché viene usato un certificato autofirmato. Se non si installa il certificato nell'archivio certificati locale, una convalida di una catena di certificati o peer avrà esito negativo. Si noti che questo non comporta un'effettiva riduzione della sicurezza per l'autenticazione di Azure AD, poiché ValidatingIssuerNameRegistry garantisce l'uso del certificato corretto. Se tuttavia si usa WIF nella stessa applicazione per considerare attendibili altre autorità emittenti, considerare che queste impostazioni si estenderanno anche a esse.

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

Questa sezione consente di modificare la raccolta di classi usate da WIF per l'elaborazione dei token di sicurezza in ingresso (noti come gestori di token). Può essere usata per influenzare il comportamento dei singoli gestori o per aggiungere e rimuovere tipi di gestori. In questo caso, lo strumento ha rimosso il gestore di sessione predefinito (basato su DPAPI e che non può funzionare in Siti Web di Azure) per sostituirlo con uno che funziona con MachineKey.

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

Per la configurazione precedente, viene usato l'elemento <system.identityModel.services> per archiviare le coordinate specifiche di WS-Federation.

In particolare, viene usato l'elemento wsFederation per registrare l'endpoint di accesso di WS-Federation del tenant di Azure AD, l'area di autenticazione (URI ID APP) dell'app da inviare come identificatore al momento dell'accesso, nonché altri flag che influenzano il comportamento locale di WIF, ad esempio se gli errori 401 provenienti dall'applicazione devono sempre attivare un messaggio di accesso per l'autorità (passiveRedirectEnabled) o se devono essere consentite le transazioni su HTTP non crittografato.

Questo elemento può essere usato per specificare molti altri parametri di protocollo. Queste sono sole le impostazioni minime per il funzionamento del flusso di accesso.

Questo documento si concentra principalmente su un'attività piuttosto limitata, ossia la connessione di un'applicazione .NET ad Azure AD per l'accesso Web tramite WS-Federation. Esistono molti altri scenari che è possibile affrontare, usando una vasta gamma di altri protocolli aperti, usufruendo di qualsiasi stack di programmazione di una piattaforma moderna o intervenendo direttamente a livello di protocollo a seconda delle esigenze.

Nella sezione relativa alla distribuzione dell'app in Azure è stato possibile osservare come il portale di gestione offra la possibilità di modificare molti altri aspetti delle impostazioni di registrazione dell'applicazione. Nelle successive procedure dettagliate della serie sarà possibile acquisire familiarità con questi controlli aggiuntivi. In questo documento verrà solo indicato brevemente come ottenere le informazioni necessarie se si decide di interagire con Azure AD a livello di protocollo per l'accesso Web o qualsiasi altro flusso supportato.

  1. Aprire il portale di gestione di Azure in una finestra del browser e passare all'intestazione Applicazioni nella sezione Azure AD. Sulla barra dei comandi nella parte inferiore della schermata è contenuta una sola voce: Visualizza endpoint. Fare clic su questa opzione.

    Endpoint dell'app La finestra di dialogo elenca tutti gli endpoint che è possibile usare per interagire con il tenant di Azure AD a livello di codice. Ecco una breve spiegazione di tutte le voci:

    • Documento di metadati di federazione: il percorso del documento di metadati che descrive il tenant di Azure AD come autorità di accesso Web. Come è possibile osservare nella procedura dettagliata nella sezione relativa all'aggiornamento automatico delle chiavi, questo documento include le coordinate dei metadati di WS-Federation e i metadati del protocollo SAML nello stesso pacchetto. Per altre informazioni, vedere Federation Metadata.

    • Endpoint di accesso WS-Federation: il punto di ingresso per tutte le transazioni WS-Federation. Questo è l'endpoint usato nella procedura dettagliata per i flussi sia di accesso sia di disconnessione. Per altre informazioni, vedere WS-Federation Endpoint URL.

    • Endpoint di accesso SAML-P: l'endpoint usato per l'implementazione dei flussi di accesso nel protocollo SAML. Per altre informazioni, vedere SAML Protocol Metadata and Endpoints.

    • Endpoint di disconnessione SAML-P: l'endpoint usato per l'implementazione dei flussi di disconnessione nel protocollo SAML. Per altre informazioni, vedere SAML Protocol Metadata and Endpoints.

    • Endpoint di Azure AD Graph: le query per recuperare le informazioni di directory archiviate nel tenant di Azure AD corrente devono essere indirizzate a questo endpoint, usando la sintassi dell'API Graph. Per informazioni dettagliate, vedere Uso dell'API Graph per effettuare query su Azure AD.

    • Endpoint token OAuth2: questo endpoint viene usato per i flussi di autenticazione da server a server. Può essere usato, ad esempio, per ottenere token di accesso per richiamare l'endpoint Graph. Per altre informazioni, vedere OAuth 2.0 (Preview Version).

Aggiunte alla community

Mostra:
© 2014 Microsoft