Creare un'app line-of-business in Azure con l'autenticazione di AD FS

Questo articolo descrive come creare un'applicazione line-of-business ASP.NET MVC nel Servizio app di Azure usando un'istanza locale di Active Directory Federation Services come provider di identità. Questo scenario può essere usato quando si vogliono creare applicazioni line-of-business del servizio app di Azure, mentre l'organizzazione richiede che i dati della directory siano archiviati sul posto.

Nota

Per una panoramica delle diverse opzioni di autenticazione e autorizzazione aziendali per il servizio app di Azure, vedere Eseguire l'autenticazione con l'istanza locale di Active Directory nell'app Azure.

Obiettivo di compilazione

Si creerà un'applicazione ASP.NET di base nelle app Web di Servizio app di Azure con le seguenti funzionalità:

  • Autenticazione degli utenti in ADFS
  • Uso di [Authorize] per autorizzare gli utenti per diverse azioni
  • Configurazione statica per il debug in Visual Studio e pubblicazione nelle app Web di Servizio app di Azure (creazione della configurazione una sola volta, esecuzione del debug e pubblicazione in qualsiasi momento)

Elementi necessari

Nota

Per completare l'esercitazione, è necessario un account Azure:

  • È possibile aprire un account Azure gratuitamente: si riceveranno dei crediti da usare per provare i servizi di Azure a pagamento e, anche dopo avere esaurito i crediti, è possibile mantenere l'account per usare i servizi di Azure gratuiti, ad esempio Siti Web. La carta di credito non verrà mai addebitata, a meno l'utente non modifichi le impostazioni e che richieda esplicitamente di essere addebitato.
  • È possibile attivare i benefici della sottoscrizione MSDN: con la sottoscrizione MSDN ogni mese si accumulano crediti che è possibile usare per i servizi di Azure a pagamento.

Per completare questa esercitazione sarà necessario quanto segue:

  • Distribuzione locale di AD FS. Per una procedura dettagliata end-to-end del lab di test in uso, vedere il post di blog Test Lab: Standalone STS with AD FS in Azure VM (for test only) (Lab di test: Istanza autonoma del servizio token di sicurezza con AD FS in una VM di Azure - solo per test)
  • Autorizzazioni per creare una o più attendibilità della relying party nel componente di gestione di ADFS
  • Visual Studio 2013 Update 4 o versione successiva
  • Azure SDK 2.8.1 o versioni successive

Usare l'applicazione di esempio per il modello line-of-business

L'applicazione di esempio in questa esercitazione, WebApp-WSFederation-DotNet, è stata creata dal team di Azure Active Directory. Poiché AD FS supporta la specifica WS-Federation, è possibile usarla come modello per creare nuove applicazioni line-of-business in modo semplice. L'applicazione presenta le seguenti funzionalità:

  • Uso di WS-Federation per eseguire l'autenticazione con una distribuzione di ADFS locale
  • Funzionalità di accesso e di disconnessione
  • Uso di Microsoft.Owin (invece di Windows Identity Foundation), che rappresenta il futuro di ASP.NET e offre una configurazione molto più semplice per l'autenticazione e l'autorizzazione rispetto a WIF

Configurare l'applicazione di esempio

  1. Clonare o scaricare la soluzione di esempio da WebApp-WSFederation-DotNet nella directory locale.

    Nota

    Le istruzioni disponibili in README.md illustrano come configurare l'applicazione con Azure Active Directory. Tuttavia, in questa esercitazione la configurazione viene eseguita senza AD FS, quindi seguire i passaggi descritti qui.

  2. Aprire la soluzione e quindi aprire Controllers\AccountController.cs in Esplora soluzioni.

    Si noterà che il codice genera semplicemente una richiesta di autenticazione per l'utente mediante WS-Federation. Tutte le autenticazioni sono configurate in App_Start\Startup.Auth.cs.

  3. Aprire App_Start\Startup.Auth.cs. Nel metodo ConfigureAuth notare la riga seguente:

    app.UseWsFederationAuthentication(
        new WsFederationAuthenticationOptions
        {
            Wtrealm = realm,
            MetadataAddress = metadata                                      
        });
    

    In ambito OWIN questo frammento di codice è il minimo indispensabile per configurare l'autenticazione con WS-Federation. Si tratta di un metodo più semplice ed elegante rispetto a WIF, in cui XML viene inserito in Web.config un po' ovunque. Le uniche informazioni realmente necessarie sono l'identificatore della relying party e l'URL del file di metadati del servizio ADFS. Ad esempio:

    • Identificatore della relying party: https://contoso.com/MyLOBApp
    • Indirizzo dei metadati: http://adfs.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
  4. In App_Start\Startup.Auth.cs modificare le definizioni delle stringhe statiche seguenti:

    private static string realm = ConfigurationManager.AppSettings["ida:RPIdentifier"];
    private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"];
    private static string tenant = ConfigurationManager.AppSettings["ida:Tenant"];
    private static string metadata = string.Format("{0}/{1}/federationmetadata/2007-06/federationmetadata.xml", aadInstance, tenant);
    private static string metadata = string.Format("https://{0}/federationmetadata/2007-06/federationmetadata.xml", ConfigurationManager.AppSettings["ida:ADFS"]);
    
    string authority = String.Format(CultureInfo.InvariantCulture, aadInstance, tenant);
    
  5. Ora apportare le modifiche corrispondenti nel file Web.config. Aprire Web.config e modificare le impostazioni dell'app seguenti:

    <appSettings>
    <add key="webpages:Version" value="3.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
    <add key="ida:Wtrealm" value="[Enter the App ID URI of WebApp-WSFederation-DotNet https://contoso.onmicrosoft.com/WebApp-WSFederation-DotNet]" />
    <add key="ida:AADInstance" value="https://login.microsoftonline.com" />
    <add key="ida:Tenant" value="[Enter tenant name, e.g. contoso.onmicrosoft.com]" />
    <add key="ida:RPIdentifier" value="[Enter the relying party identifier as configured in AD FS, e.g. https://localhost:44320/]" />
    <add key="ida:ADFS" value="[Enter the FQDN of AD FS service, e.g. adfs.contoso.com]" />
    
    </appSettings>
    

    Compilare i valori delle chiavi in base a quanto previsto per l'ambiente in uso.

  6. Compilare l'applicazione e verificare che non siano presenti errori.

È tutto. Ora l'applicazione di esempio è pronta per l'uso con ADFS. In seguito sarà comunque necessario configurare un trust della relying party con questa applicazione in AD FS.

Distribuire l'applicazione di esempio nelle app Web di Servizio app di Azure

Qui si pubblicherà l'applicazione in un'app Web nelle app Web del servizio app di Azure mantenendo l'ambiente di debug. Si noti che si pubblicherà l'applicazione prima che questa disponga di un'attendibilità della relying party con ADFS, pertanto l'autenticazione non sarà ancora funzionante. Se tuttavia si esegue questa operazione adesso, è possibile ottenere l'URL dell'app Web da usare per la configurazione del trust della relying party in un secondo tempo.

  1. Fare clic con il pulsante destro del mouse sul progetto e scegliere Pubblica.

  2. Selezionare Servizio app di Microsoft Azure.
  3. Se non è stato eseguito l'accesso ad Azure, fare clic su Accedi e usare l'account Microsoft relativo alla sottoscrizione di Azure per accedere.
  4. Dopo l'accesso, fare clic su Nuovo per creare un'app Web.
  5. Compilare tutti i campi obbligatori. Poiché in un secondo tempo si stabilirà la connessione ai dati locali, non occorre creare un database per questa app Web.

  6. Fare clic su Crea. Dopo la creazione dell'app Web, verrà aperta la finestra di dialogo Pubblica sito Web.
  7. In URL di destinazione sostituire http con https. Copiare l'intero URL in un editor di testo per un uso successivo. Fare quindi clic su Pubblica.

  8. In Visual Studio aprire Web.Release.config nel progetto. Inserire il seguente codice XML nel tag <configuration> e sostituire il valore della chiave con l'URL dell'app Web di pubblicazione.

    <appSettings>
    <add key="ida:RPIdentifier" value="[e.g. https://mylobapp.azurewebsites.net/]" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
    </appSettings>

Al termine, saranno disponibili due identificatori della relying party configurati nel progetto, uno per l'ambiente di debug in Visual Studio e uno per l'app Web pubblicata in Azure. Si procederà all'impostazione di un'attendibilità della relying Party per ciascuno dei due ambienti in ADFS. Durante il debug le impostazioni dell'app in Web.config vengono usate per consentire il funzionamento della configurazione di Debug con AD FS. In caso di pubblicazione (per impostazione predefinita viene pubblicata la configurazione di Release ), viene caricato un file Web.config trasformato che incorpora le modifiche alle impostazioni dell'app nel file Web.Release.config.

Se si desidera collegare l'app Web pubblicata di Azure al debugger (ad esempio se è necessario caricare i simboli di debug del codice nell'app Web pubblicata), è possibile creare un clone della configurazione Debug per il debug di Azure, ma con una trasformazione Web.config personalizzata (ad esempio Web.AzureDebug.config) che usa le impostazioni dell'app disponibili in Web.Release.config. Ciò permette di mantenere una configurazione statica in ambienti diversi.

Configurare l'attendibilità della relying party nel componente di gestione di ADFS

Prima di poter usare l'applicazione di esempio e autenticarla effettivamente con AD FS, è necessario configurare un trust della relying party in Gestione AD FS. Sarà necessario impostare due attendibilità della relying party separate, una per l'ambiente di debug e una per l'app Web pubblicata.

Nota

Assicurarsi di ripetere i passaggi seguenti per entrambi gli ambienti.

  1. Accedere al server ADFS con le credenziali dotate di diritti di gestione per ADFS.
  2. Aprire il componente di gestione di ADFS. Fare clic con il pulsante destro del mouse su AD FS\Relazioni di attendibilità\Attendibilità componente e selezionare Aggiungi attendibilità componente.

  3. Nella pagina Seleziona origine dati selezionare Immetti dati sul componente manualmente.

  4. Nella pagina Specifica nome visualizzato digitare un nome visualizzato per l'applicazione e fare clic su Avanti.
  5. Nella pagina Choose Protocol (Scegli protocollo) fare clic su Avanti.
  6. Nella pagina Configura certificato fare clic su Avanti.

    Nota

    Poiché dovrebbe essere già in uso HTTPS, i token crittografati sono facoltativi. Se si vogliono comunque crittografare i token di ADFS in questa pagina, è anche necessario aggiungere della logica di decrittografia di token nel codice. Per altre informazioni, vedere il post sulla configurazione manuale di middleware WS-Federation OWIN e sull'accettazione di token crittografati.

  7. Prima di passare al prossimo passaggio, è necessario ottenere delle informazioni dal progetto di Visual Studio. Nelle proprietà del progetto prendere nota dell' URL SSL dell'applicazione.

  8. Nuovamente in Gestione AD FS, nella pagina Configura URL di Aggiunta guidata attendibilità componente selezionare Abilita supporto del protocollo passivo WS-Federation e digitare l'URL SSL del progetto di Visual Studio di cui si è preso nota nel passaggio precedente. Quindi fare clic su Next.

    Nota

    L'URL specifica dove inviare il client dopo la riuscita dell'autenticazione. Per l'ambiente di debug, l'URL dovrebbe essere https://localhost:<port>/. Per l'app Web pubblicata, deve corrispondere all'URL dell'app Web.

  9. Nella pagina Configura identificatori verificare che l'URL SSL del progetto sia già elencato, quindi fare clic su Avanti. Fare clic su Next fino al termine della procedura guidata, accettando le impostazioni predefinite.

    Nota

    In App_Start\Startup.Auth.cs del progetto di Visual Studio questo identificatore viene confrontato con il valore di WsFederationAuthenticationOptions.Wtrealm durante l'autenticazione federata. Per impostazione predefinita, l'URL dell'applicazione nel passaggio precedente viene aggiunto come identificatore della relying party.

  10. A questo punto la configurazione dell'applicazione relying party per il progetto in ADFS è completa. Si procederà quindi alla configurazione di questa applicazione per l'invio delle attestazioni richieste dalla propria applicazione. La finestra di dialogo Edit Claim Rules si apre per impostazione predefinita al termine della procedura guidata e sarà pertanto possibile iniziare immediatamente. Configurare almeno le attestazioni seguenti (con gli schemi tra parentesi):

    Nota

    I tipi di attestazione da configurare per la propria applicazione sono determinati dai requisiti dell'applicazione stessa. Per un elenco delle attestazioni supportate dalle applicazioni Azure Active Directory (ovvero le attendibilità della relying party), vedere ad esempio Token e tipi di attestazioni supportati.

  11. Nella finestra di dialogo Edit Claim Rules fare clic su Add Rule.
  12. Configurare il nome, l'UPN e le attestazioni di ruolo come illustrato nello screenshot seguente e quindi fare clic su Fine.

    In seguito si creerà un'attestazione ID nome temporanea usando i passaggi descritti nel post di blog Name Identifiers in SAML assertions(Identificatori di nome nelle asserzioni SAML).

  13. Fare nuovamente clic su Add Rule .
  14. Selezionare Inviare attestazioni mediante una regola personalizzata e fare clic su Avanti.
  15. Incollare la seguente lingua delle regole nella casella Regola personalizzata, assegnare il nome di identificazione per sessione alla regola e fare clic su Fine.

    c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] &&
    c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant"]
     => add(
         store = "_OpaqueIdStore",
         types = ("http://contoso.com/internal/sessionid"),
         query = "{0};{1};{2};{3};{4}",
         param = "useEntropy",
         param = c1.Value,
         param = c1.OriginalIssuer,
         param = "",
         param = c2.Value);
    

    La regola personalizzata sarà simile allo screenshot seguente:

  16. Fare nuovamente clic su Add Rule .
  17. Selezionare Trasformare un'attestazione in ingresso e fare clic su Avanti.
  18. Configurare la regola come illustrato nello screenshot seguente, usando il tipo di attestazione creato nella regola personalizzata e fare clic su Fine.

    Per informazioni dettagliate sui passaggi da eseguire per l'attestazione ID nome temporanea, vedere il post di blog Name Identifiers in SAML assertions(Identificatori di nome nelle asserzioni SAML).

  19. Fare clic su Applica nella finestra di dialogo Modifica regole attestazione, che ora sarà simile allo screenshot seguente:

    Nota

    Assicurarsi di ripetere questi passaggi sia per l'ambiente di debug che per l'app Web pubblicata.

Testare l'autenticazione federata per la propria applicazione

Si è ora pronti per testare la logica di autenticazione dell'applicazione in ADFS. Nell'ambiente di laboratorio usato in questo esempio è presente un utente test che appartiene a un gruppo di test in Active Directory.

Per testare l'autenticazione nel debugger, sarà sufficiente premere F5. Se si desidera testare l'autenticazione nell'app Web pubblicata, passare all'URL dell'app.

Dopo il caricamento dell'applicazione Web, fare clic su Accedi. Dovrebbe ora venire visualizzata una finestra di dialogo di accesso o la pagina di accesso presentata da ADFS, a seconda del metodo di autenticazione scelto da ADFS. Di seguito è riportato ciò che viene visualizzato in Internet Explorer 11.

Dopo l'accesso come utente nel dominio AD della distribuzione di AD FS, verrà ora nuovamente visualizzata la home page con Hello, !. nell'angolo. Questo è quanto viene visualizzato nell'ambiente di questo esempio.

Finora, sono stati raggiunti gli obiettivi seguenti:

  • L'applicazione ha raggiunto correttamente ADFS e il corrispondente identificatore della relying party è presente nel database di ADFS
  • ADFS ha correttamente autenticato un utente AD e ha reindirizzato l'utente alla home page dell'applicazione
  • AD FS ha correttamente inviato l'attestazione basata su nome (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name) all'applicazione, come indicato dalla visualizzazione del nome utente in alto a destra.

In caso di assenza dell'attestazione basata su nome, verrebbe visualizzato solo Hello, !. Se si esamina il file Views\Shared\_LoginPartial.cshtml, si noterà che viene usato User.Identity.Name per visualizzare il nome utente. Come già accennato, ASP.NET attiva questa proprietà con l'attestazione nome dell'utente autenticato, se questa è disponibile nel token SAML. Per visualizzare tutte le attestazioni inviate da ADFS, inserire un punto di interruzione in Controllers\HomeController.cs, nel metodo di azione Index. Dopo l'autenticazione dell'utente, controllare la raccolta System.Security.Claims.Current.Claims .

Autorizzare utenti per controller o azioni specifiche

Poiché sono state incluse le appartenenze a gruppi come attestazioni di tipo ruolo nella configurazione del trust della relying party, è possibile usarle direttamente nell'effetto [Authorize(Roles="...")] per controller e azioni. In un'applicazione line-of-business in cui si usa il modello Create-Read-Update-Delete (CRUD) è possibile autorizzare ruoli specifici per accedere a ogni azione. Per il momento, si sperimenterà questa funzionalità nel controller Home esistente.

  1. Aprire Controllers\HomeController.cs.
  2. Assegnare i metodi di azione About e Contact in modo simile al codice seguente, usando le appartenenze ai gruppi di sicurezza disponibili per l'utente autenticato.

     [Authorize(Roles="Test Group")]
     public ActionResult About()
     {
         ViewBag.Message = "Your application description page.";
    
         return View();
     }
    
     [Authorize(Roles="Domain Admins")]
     public ActionResult Contact()
     {
         ViewBag.Message = "Your contact page.";
    
         return View();
     }
     

    Poiché nell'ambiente lab AD FS è stato aggiunto Test User a Test Group, si userà Test Group per il test dell'autorizzazione in About. Per Contact, si testerà il caso negativo di Domain Admins, a cui Test User non appartiene.

  3. Avviare il debugger premendo F5 e accedere, quindi fare clic su About. Dovrebbe ora essere possibile visualizzare la pagina ~/About/Index , se l'utente autenticato è autorizzato per tale azione.
  4. Ora fare clic su Contact, che nel caso di questo esempio non autorizza Test User per l'azione. Tuttavia, il browser viene reindirizzato ad ADFS, che visualizzerà un messaggio analogo al seguente:

    Se si esamina l'errore nel Visualizzatore eventi del server AD FS, verrà visualizzato questo messaggio di eccezione:

     Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '11' seconds. Contact your administrator for details.
        at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateLoopDetectionCookie(WrappedHttpListenerContext context)
        at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.SendSignInResponse(WSFederationContext context, MSISSignInResponse response)
        at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
        at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
     

    Il motivo di questo errore è che, per impostazione predefinita, MVC restituisce un codice 401 Unauthorized quando i ruoli di un utente non sono autorizzati. Questo attiva una richiesta di ri-autenticazione al provider di identità (ovvero ADFS). Poiché l'utente è già autenticato, ADFS torna alla stessa pagina, che a sua volta invia un nuovo codice 401, creando un ciclo di reindirizzamento. Verrà eseguito l'override del metodo HandleUnauthorizedRequest di AuthorizeAttribute con una logica semplice per visualizzare qualcosa di sensato anziché continuare il ciclo di reindirizzamento.

  5. Creare un file denominato AuthorizeAttribute.cs nel progetto e incollare il codice seguente nel file.

     using System;
     using System.Web.Mvc;
     using System.Web.Routing;
    
     namespace WebApp_WSFederation_DotNet
     {
         [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
         public class AuthorizeAttribute : System.Web.Mvc.AuthorizeAttribute
         {
             protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
             {
                 if (filterContext.HttpContext.Request.IsAuthenticated)
                 {
                     filterContext.Result = new System.Web.Mvc.HttpStatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);
                 }
                 else
                 {
                     base.HandleUnauthorizedRequest(filterContext);
                 }
             }
         }
     }
    

    Il codice di override invia un messaggio HTTP 403 (accesso negato) invece di HTTP 401 (non autorizzato) per i casi autenticati ma non autorizzati.

  6. Eseguire nuovamente il debug con F5. Facendo clic su Contact verrà visualizzato un messaggio di errore più informativo (anche se graficamente meno elegante):

  7. Pubblicare nuovamente l'applicazione nelle app Web di Servizio app di Azure, quindi testare il comportamento dell'applicazione attiva.

Connettersi ai dati locali

Un motivo per cui si potrebbe voler implementare la propria applicazione line-of-business in ADFS anziché in Azure Active Directory potrebbe essere correlato a questioni di conformità nella conservazione dei dati dell'organizzazione all'esterno dell'organizzazione stessa. Questo può anche significare che il sito Web di Azure deve accedere a database locali, poiché non si è autorizzati a usare il database SQL come livello dati per le app Web.

App Web del servizio app di Azure supporta l'accesso ai database locali tramite due approcci: connessioni ibride e reti virtuali. Per altre informazioni, vedere il post relativo all' uso dell'integrazione con una rete virtuale e delle connessioni ibride con App Web del servizio app di Azure.

Altre risorse