Pianificare una distribuzione di Single Sign-On

Questo articolo fornisce informazioni che è possibile usare per pianificare la distribuzione dell'accesso Single Sign-On (SSO) in Azure Active Directory (Azure AD). Quando si pianifica la distribuzione SSO con le applicazioni in Azure AD, è necessario considerare queste domande:

  • Quali sono i ruoli amministrativi necessari per la gestione dell'applicazione?
  • È necessario rinnovare il certificato?
  • Chi deve ricevere una notifica delle modifiche correlate all'implementazione dell'accesso SSO?
  • Quali licenze sono necessarie per garantire una gestione efficace dell'applicazione?
  • Gli account utente condivisi vengono usati per accedere all'applicazione?
  • Sono disponibili le opzioni per la distribuzione di SSO?

Ruoli amministrativi

Usare sempre il ruolo con le autorizzazioni più poche disponibili per eseguire l'attività necessaria all'interno di Azure AD. Esaminare i diversi ruoli disponibili e scegliere quello giusto per risolvere le esigenze di ogni persona per l'applicazione. Alcuni ruoli possono essere applicati temporaneamente e rimossi dopo il completamento della distribuzione.

Utente tipo Ruoli Ruolo di Azure AD (se necessario)
Amministratore help desk Supporto di livello 1 Nessuno
Amministratore delle identità Configurare ed eseguire il debug quando i problemi comportano Azure AD Amministratore globale
Amministratore dell'applicazione Attestazione utente nell'applicazione, configurazione sugli utenti con autorizzazioni Nessuno
Amministratori dell'infrastruttura Proprietario del rollover del certificato Amministratore globale
Proprietario dell'azienda/stakeholder Attestazione utente nell'applicazione, configurazione sugli utenti con autorizzazioni Nessuno

Per altre informazioni sui ruoli amministrativi di Azure AD, vedere Ruoli predefiniti di Azure AD.

Certificati

Quando si abilita l'accesso SSO federato per l'applicazione, Azure AD crea un certificato valido per tre anni per impostazione predefinita. Se necessario, è possibile personalizzare la data di scadenza per tale certificato. Assicurarsi di disporre di processi sul posto per rinnovare i certificati prima della scadenza.

La durata del certificato viene modificata nel portale di Azure. Assicurarsi di documentare la scadenza e sapere come gestire il rinnovo del certificato. È importante identificare i ruoli e gli elenchi di distribuzione di posta elettronica corretti coinvolti nella gestione del ciclo di vita del certificato di firma. Sono consigliati i ruoli seguenti:

  • Proprietario per l'aggiornamento delle proprietà utente nell'applicazione
  • Supporto per la risoluzione dei problemi dell'applicazione per la chiamata al proprietario
  • Elenco di distribuzione della posta elettronica monitorato attentamente per le notifiche di modifica correlate al certificato

Configurare un processo per gestire una modifica del certificato tra Azure AD e l'applicazione. Grazie a questo processo, è possibile evitare o ridurre al minimo un'interruzione a causa di una scadenza di un certificato o di un rollover forzato del certificato. Per altre informazioni, vedere Gestione di certificati per accesso Single Sign-On federato in Azure Active Directory.

Comunicazioni

La comunicazione è fondamentale per il successo di un nuovo servizio. Comunicare in modo proattivo agli utenti il modo in cui l'esperienza cambierà. Comunicare quando cambierà e come ottenere supporto se riscontrano problemi. Esaminare le opzioni per come gli utenti accederanno alle applicazioni abilitate per l'accesso SSO e creare le comunicazioni in modo che corrispondano alla selezione.

Implementare il piano di comunicazione. Assicurarsi che gli utenti sappiano che una modifica è in arrivo, quando è arrivata e cosa fare ora. Assicurarsi inoltre di fornire informazioni su come cercare assistenza.

Gestione delle licenze

Assicurarsi che l'applicazione sia coperta dai requisiti di licenza seguenti:

  • Licenze di Azure AD : l'accesso SSO per le applicazioni aziendali pre-integrate è gratuito. Tuttavia, il numero di oggetti nella directory e le funzionalità da distribuire potrebbero richiedere più licenze. Per un elenco completo dei requisiti di licenza, vedere Prezzi di Azure Active Directory.

  • Licenze dell'applicazione : sono necessarie le licenze appropriate per le applicazioni in base alle esigenze aziendali. Collaborare con il proprietario dell'applicazione per determinare se gli utenti assegnati all'applicazione dispongono delle licenze appropriate per i propri ruoli all'interno dell'applicazione. Se Azure AD gestisce il provisioning automatico in base ai ruoli, i ruoli assegnati in Azure AD devono essere allineati al numero di licenze di proprietà dell'applicazione. Il numero errato di licenze di proprietà dell'applicazione può causare errori durante il provisioning o l'aggiornamento di un account utente.

Shared accounts (Account condivisi)

Dal punto di vista dell'accesso, le applicazioni con account condivisi non sono diverse dalle applicazioni aziendali che usano l'accesso SSO password per singoli utenti. Tuttavia, sono necessari altri passaggi durante la pianificazione e la configurazione di un'applicazione per l'uso degli account condivisi.

  • Usare gli utenti per documentare le informazioni seguenti:
    • Set di utenti dell'organizzazione che useranno l'applicazione.
    • Set esistente di credenziali nell'applicazione associata al set di utenti.
  • Per ogni combinazione di set di utenti e credenziali, creare un gruppo di sicurezza nel cloud o in locale in base ai requisiti.
  • Reimpostare le credenziali condivise. Dopo la distribuzione dell'applicazione in Azure AD, i singoli utenti non necessitano della password dell'account condiviso. Azure AD archivia la password e è consigliabile impostarla per essere lunga e complessa.
  • Configurare il rollover automatico della password se l'applicazione lo supporta. In questo modo, non nemmeno l'amministratore che ha eseguito l'installazione iniziale conosce la password dell'account condiviso.

Opzioni di accesso Single Sign-On

È possibile configurare un'applicazione per l'accesso Single Sign-On in vari modi. La scelta di un metodo di accesso Single Sign-On dipende dal modo in cui l'applicazione è configurata per l'autenticazione.

  • Le applicazioni cloud possono usare OpenID Connect, OAuth, SAML, l'accesso SSO basato su password o basato su collegamento. L'accesso Single Sign-On può anche essere disabilitato.
  • Le applicazioni locali possono usare il metodo basato su password o intestazione, collegato oppure l'autenticazione integrata di Windows per l'accesso Single Sign-On. Le scelte locali sono valide se le applicazioni sono configurate per Application Proxy.

Questo diagramma di flusso consente di decidere quale metodo SSO è più adatto alle proprie situazioni.

Decision flowchart for single sign-on method

I protocolli SSO seguenti sono disponibili per l'uso:

  • OpenID Connect e OAuth: scegliere OpenID Connect e OAuth 2.0 se l'applicazione a cui ci si connette. Per altre informazioni, vedere Protocolli OAuth 2.0 e OpenID Connect nella piattaforma Microsoft Identity. Per la procedura per implementare l'accesso Single Sign-On di OpenID Connect, vedere Configurare l'accesso Single Sign-On basato su OIDC per un'applicazione in Azure Active Directory.

  • SAML: scegliere SAML ogni volta che è possibile per le applicazioni esistenti che non usano OpenID Connect o OAuth. Per altre informazioni, vedere Single Sign-On SAML Protocol.

  • Basato su password : scegliere la password basata su password quando l'applicazione dispone di una pagina di accesso HTML. L'accesso SSO basato su password è noto anche come insieme di credenziali delle password. L'accesso SSO basato su password consente di gestire l'accesso utente e le password alle applicazioni Web che non supportano la federazione delle identità. È anche utile dove diversi utenti devono condividere un singolo account, ad esempio gli account dell'app per i social media dell'organizzazione.

    L'accesso SSO basato su password supporta applicazioni che richiedono più campi di accesso per le applicazioni che richiedono più campi nome utente e password per l'accesso. È possibile personalizzare le etichette dei campi nome utente e password visualizzati negli utenti nelle app personali quando immettono le proprie credenziali. Per la procedura per implementare l'accesso Single Sign-On basato su password, vedere Single Sign-On basato su password.

  • Collegato: scegliere collegato quando l'applicazione è configurata per l'accesso SSO in un altro servizio provider di identità. L'opzione Collegato consente di configurare il percorso di destinazione quando un utente seleziona l'applicazione nei portali dell'organizzazione. È possibile aggiungere un collegamento a un'applicazione Web personalizzata che attualmente usa una federazione, ad esempio Active Directory Federation Services (AD FS).

    È anche possibile aggiungere i collegamenti a pagine Web specifiche da visualizzare nei pannelli di accesso dell'utente e a un'app che non richiede l'autenticazione. L'opzione Collegato non fornisce funzionalità di accesso tramite le credenziali di Azure AD. Per la procedura per implementare l'accesso Single Sign-On collegato, vedere Single Sign-On collegato.

  • Disabilitato : scegliere l'accesso SSO disabilitato quando l'applicazione non è pronta per essere configurata per l'accesso SSO.

  • Autenticazione integrata di Windows ( IWA) - Scegliere Single Sign-On IWA per le applicazioni che usano IWA o per le applicazioni con riconoscimento delle attestazioni. Per altre informazioni, vedere Delega vincolata Kerberos per l'accesso Single Sign-On alle applicazioni con Application Proxy.

  • Basato sull'intestazione : scegliere l'accesso Single Sign-On basato su intestazione quando l'applicazione usa le intestazioni per l'autenticazione. Per altre informazioni, vedere SSO basato su intestazione.

Passaggi successivi