Esporta (0) Stampa
Espandi tutto

Utilizzo del provider di identità Shibboleth per l'implementazione di Single Sign-On

Pubblicato: giugno 2012

Aggiornamento: giugno 2015

Si applica a: Azure, Office 365, Power BI, Windows Intune

Negli argomenti di questa sezione vengono fornite istruzioni per gli amministratori di un servizio cloud Microsoft che desiderano offrire agli utenti di Active Directory l'esperienza Single Sign-On utilizzando il provider di identità Shibboleth come servizio token di sicurezza preferito. Il provider di identità Shibboleth implementa lo standard ampiamente utilizzato di identità federative SAML (Security Assertion Markup Language) per fornire un accesso Single Sign-On e un framework per lo scambio di attributi.

Microsoft supporta questa esperienza di accesso Single Sign-On come integrazione di un servizio cloud Microsoft, ad esempio Windows Intune o Office 365, con il provider di identità Shibboleth già installato e operativo. Poiché Shibboleth è un prodotto di terze parti, Microsoft non fornisce alcun supporto per i problemi e le domande relativi a distribuzione, configurazione, risoluzione dei problemi o procedure consigliate per questo provider di identità. Per altre informazioni sul provider di identità Shibboleth, vedere la pagina Web all'indirizzo http://go.microsoft.com/fwlink/?LinkID=256497.

ImportantImportante
In questo scenario Single Sign-On è supportato solo il seguente insieme limitato di client:

  • Client basati sul Web come Exchange Web Access e SharePoint Online

  • Rich client di posta elettronica che utilizzano l'autenticazione di base e un metodo di accesso Exchange supportato come IMAP, POP, Active Sync, MAPI e così via (deve essere distribuito l'endpoint ECP, Enhanced Client Protocol), inclusi i seguenti:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 e 9

    • iPhone (diverse versioni iOS)

    • Windows Phone 7

Tutti gli altri client non sono supportati in questo scenario Single Sign-On con il provider di identità Shibboleth. Se ad esempio si implementa questo scenario Single Sign-On, non sarà possibile utilizzare il client desktop Lync 2010 per l'accesso a Lync Online, utilizzare le licenze di Office 365 ProPlus da una sottoscrizione Office 365, utilizzare Word, Excel e altre applicazioni desktop di Office per aprire i documenti da SharePoint Online, né utilizzare OneDrive for Business per la sincronizzazione dei file.

Per configurare un servizio token di sicurezza locale con il provider di identità Shibboleth, effettuare le seguenti operazioni.

ImportantImportante
Prima di iniziare a eseguire i passaggi descritti di seguito, è necessario prendere visione dei vantaggi, delle esperienze utente e dei requisiti di Single Sign-On in Preparazione dell'accesso Single Sign-On.

  1. Esaminare le istruzioni dettagliate in Configurare Shibboleth per l'uso con Single Sign-On.

  2. Installare Windows PowerShell per l'accesso Single Sign-On con Shibboleth

  3. Configurare una relazione di trust tra Shibboleth e Azure AD

  4. Seguire le istruzioni dettagliate contenute in Guida di orientamento per la sincronizzazione della directory per preparare l'ambiente, attivare e installare uno strumento e verificare la sincronizzazione della directory.

  5. Verificare il servizio Single Sign-On con Shibboleth

Vedere anche

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2015 Microsoft