Esporta (0) Stampa
Espandi tutto

Utilizzo di Shibboleth Identity Provider per implementare Single Sign-On

Pubblicato: giugno 2012

Aggiornamento: giugno 2014

Si applica a: Azure, Office 365, 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 usare i client desktop Lync 2010 o Lync 2013 per l'accesso a Lync Online, usare le licenze di Office 365 ProPlus da una sottoscrizione Office 365, usare Word, Excel e altre applicazioni desktop di Office per aprire i documenti da SharePoint Online, né usare 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 Configurazione di Shibboleth per l'utilizzo con Single Sign-On.

  2. Installazione di Windows PowerShell per Single Sign-On con Shibboleth

  3. Configurazione di un trust tra Shibboleth e Windows Azure AD

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

  5. Verifica dell'accesso Single Sign-On con Shibboleth

Vedere anche

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.

Aggiunte alla community

AGGIUNGI
Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft