• Cloud, Guide, Sicurezza
• 10 Novembre 2022

Azure AD e tutta la Microsoft Identity Platform sono ormai da anni un valido strumento per poter gestire le identità e per filtrare l’accesso alle applicazioni. Microsoft Identity Platform esegue la gestione delle identità e degli accessi (IAM) solo per le applicazioni registrate. Sia che si tratti di un’applicazione client, come un’app Web o per dispositivi mobili, oppure di un’API Web a supporto di un’app client, la registrazione consente di stabilire una relazione di trust tra l’applicazione e il provider di identità (Microsoft Identity Platform). La relazione di trust è unidirezionale, ovvero l’app considera attendibile Microsoft Identity Platform e non viceversa.

Creare una nuova Azure App Registration

Per creare una nuova Azure App registration collegatevi al portale di Azure o al portale di Azure AD e navigate in Azure AD à App registrations. Cliccate su + New Registration per iniziare la procedura di registrazione di una nuova app.

Figura 1: Creazione di una nuova Azure App registration

Inserite le informazioni richieste e immettete un nome visualizzato per l’applicazione. Gli utenti dell’applicazione potrebbero visualizzare il nome visualizzato quando usano l’app, ad esempio durante l’accesso. È possibile modificare il nome visualizzato in qualsiasi momento e più registrazioni dell’app possono condividere lo stesso nome.

Specificate chi può usare l’applicazione scegliendo tra 4 opzioni:

• Account solo in questa directory: Selezionare questa opzione se si intende creare un’applicazione utilizzabile solo da utenti (o guest) nel tenant personale. Quest’app è un’applicazione a tenant singolo nella piattaforma Microsoft Identity Platform.
• Account in qualsiasi directory: Selezionare questa opzione se si desidera che gli utenti in qualsiasi tenant di Azure Active Directory (Azure AD) possano usare l’applicazione. Questa opzione è appropriata se, ad esempio, si sta creando un’applicazione SaaS (Software-As-A-Service) che si intende fornire a più organizzazioni. Questo tipo di app è noto come applicazione multi-tenant nella piattaforma Microsoft Identity Platform.
• Account in qualsiasi directory e account Microsoft personali: Selezionare questa opzione per includere il set più ampio possibile di clienti. Selezionando questa opzione, si sta registrando un’applicazione multi-tenant che può supportare anche gli utenti che hanno account Microsoft personali.
• Account Microsoft personali: Selezionare questa opzione se si sta creando un’applicazione solo per gli utenti con account Microsoft personali. Gli account Microsoft personali includono gli account Skype, Xbox, Live e Hotmail.

In Redirect URI inserite il percorso dove Microsoft Identity Platform reindirizzerà il client di un utente e invierà token di sicurezza dopo l’autenticazione. In un’applicazione web di produzione, ad esempio, l’URI di reindirizzamento è spesso un endpoint pubblico in cui viene eseguita l’app. Durante lo sviluppo potete invece aggiungere l’endpoint in cui l’app viene eseguita in locale.

Figura 2: Informazioni richieste per la creazione della Azure App registration

Figura 3: Azure App registration completata con successo

Configurazione dell’Azure App registration

Una volta che l’app è stata registrata in Azure AD potete iniziare le configurazioni. Per configurare le impostazioni dell’applicazione in base alla piattaforma o al dispositivo di destinazione selezionate il nodo Authentication e cliccate su + Add a platform. In Configure platforms selezionate il riquadro per il tipo di applicazione (piattaforma) per configurarne le impostazioni.

Le piattaforme supportate sono:

• Web
• Applicazione a pagina singola
• iOS/macOS
• Android
• Applicazioni per dispositivi mobili e desktop

Figura 4: Platform configurations per la Azure App registration

Completate le informazioni richieste per il rilascio del token di autenticazione e fate clic su Save.

Figura 5: modalità di autenticazione della Azure App registration

Aggiunta delle credenziali di accesso alla Azure App registration

Le credenziali vengono usate dalle applicazioni client che accedono a un’API Web e consentono all’applicazione di eseguire l’autenticazione in modo autonomo, senza richiedere alcuna interazione utente in fase di esecuzione.

È possibile scegliere per l’autenticazione sia certificati digitali che client secrets (spesso chiamai password dell’applicazione). I client secret sono considerati meno sicuri dei certificati.

Per aggiungere un nuovo client secret fate clic su + New Client Secret e scegliete nome e durata. La durata del client secret è limitata a due anni (24 mesi) o meno. Non è possibile specificare una durata personalizzata più lunga di 24 mesi. Microsoft consiglia di impostare un valore di scadenza inferiore a 12 mesi.

Figura 6: Creazione di un nuovo client secret per la Azure App registration

Figura 7: Client secret creato

API permissions

Tramite le API permissions è possibile autorizzare l’app ad accedere ai dati contenuti in Azure AD, in lettura e in scrittura. Per impostazione predefinita le Azure AD app registrations hanno i permessi di User.Read da Microsoft Graph API.

È possibile modificare questi permessi in modo tale da delegare a Microsoft Graph la possibilità che la vostra applicazione effettui delle operazioni per conto dell’utente.

Per modificare questi permessi cliccate API permissions à Add a permission à Microsoft Graph

Figura 8: Aggiunta di permessi per utilizzo delle Microsoft Graph API

Microsoft Graph espone numerose autorizzazioni. Quella usata più di frequente è visualizzata all’inizio dell’elenco. Scegliete le autorizzazionic he ritenete opportune e aggiungetele alle API Permissions.

Figura 9: Autorizzazioni di Microsoft Graph API

Quando si configurano le autorizzazioni, agli utenti dell’app che eseguono l’accesso viene richiesto di fornire il consenso per consentire all’app di accedere all’API di risorse per conto dell’utente.

Gli amministratori possono anche concedere il consenso per conto di tutti gli utenti in modo che non venga visualizzata alcuna richiesta di consenso.

Il pulsante Grant admin consent for {il vostro tenant} permette ad un amministratore di permettere l’admin consent per il permesso configurato per l’applicazione, in modo tale che non venga chiesto agli utenti del tenant le volte successive che uno di loro utilizzerà l’applicazione.

Figura 10: Admin consent per il permesso richiesto

Figura 11: Admin consent permesso per la specifica permission

Test di funzionamento

Per testare la nostra applicazione voglio mostrarvi come effettuare il Single Sign-ON (SSO) tra Azure AD e WordPress. Utilizzando il plugin Login with Azure (Azure SSO) – WordPress plugin | WordPress.org l’operazione di login nel portale amministrativo utilizzerà gli utenti del vostro tenant.

Figura 12: WordPress Login with Azure ( Azure SSO ) plugin

Aggiungete il plugin al vostro sito WordPress e attivatelo.

Figura 13: Installazione del WordPress Login with Azure ( Azure SSO ) plugin

Figura 14: Installazione del WordPress Login with Azure ( Azure SSO ) plugin completata

Seguite le indicazioni contenute nel video Azure AD Single Sign-On (SAML) | Login into WordPress using Azure AD | WordPress Azure AD SSO – YouTube per creare la Azure AD App registration e per configurare il plugin di WordPress.

Dopo la registrazione dell’Azure AD app e la configurazione del plugin potrete accedere al vostro sito WordPress utilizzando le vostre credenziali di Azure AD, come mostrato nelle figure sotto.

Figura 15: Pulsante per il login a WordPress utilizzando le credenziali di Azure AD

Figura 16: Scelta della credenziale di Azure AD da utilizzare per il plugin

Figura 17: Autenticazione al sito WordPress completata con successo

Conclusioni

Le Azure App registrations rappresentano un modo semplice e potente per configurare i flussi di lavoro di autenticazione e autorizzazione per diversi tipi di client, da Android fino ad un’applicazione SAML. Con la possibilità aggiuntiva di limitare le API e gli endpoint protetti si può creare rapidamente una registrazione che consente solo le autorizzazioni necessarie al funzionamento dell’applicazione e all’accesso dei dati consentiti.