Esporta (0) Stampa
Espandi tutto

Configurare Shibboleth per l'uso con Single Sign-On

Pubblicato: giugno 2012

Aggiornamento: febbraio 2015

Si applica a: Azure, Office 365, Windows Intune

Questo argomento contiene istruzioni dettagliate su come configurare il provider di identità Shibboleth per attuare la federazione con Azure AD in modo da abilitare l'accesso Single Sign-On a uno o più servizi cloud Microsoft (ad esempio Windows Intune e/o Office 365) usando il protocollo SAML 2.0. La relying party SAML 2.0 per un servizio cloud Microsoft in uso in questo scenario è Azure AD.

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. Ad esempio, il client desktop Lync 2010 non è supportato per l'accesso al servizio con il provider di identità Shibboleth configurato per Single Sign-On.

ImportantImportante
Prima di effettuare le operazioni descritte in questo argomento per configurare il provider di identità Shibboleth per Single Sign-On, è necessario leggere e seguire le istruzioni fornite in Preparazione dell'accesso Single Sign-On.

Per informazioni generali su Single Sign-On, vedere Guida di orientamento per Single Sign-On.

Per configurare il provider di identità Shibboleth per l'uso con Single Sign-On, effettuare le seguenti operazioni:

  1. Aggiungere i metadati di Azure AD

  2. Aggiungere Azure AD come relying party

  3. Configurare il resolver degli attributi di Shibboleth

  4. Configurare il filtro degli attributi di Shibboleth

  5. Facoltativo: Installare l'estensione ECP di Shibboleth

  6. Riavviare Shibboleth e verificare il funzionamento

ImportantImportante
Negli esempi forniti in questo argomento IDP_HOME è la directory base in cui è stato installato il provider di identità Shibboleth, ad esempio c:\shibboleth2idp. Seguendo le istruzioni per la configurazione di Shibboleth contenute nell'argomento, sostituire IDP_HOME con il proprio percorso specifico.

Il provider di identità Shibboleth richiede informazioni sulla relying party di Azure AD. Azure AD pubblica i metadati in https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. È consigliabile ricercare sempre i metadati di Azure AD più recenti. Il valore corrente dei metadati è il seguente:


<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="urn:federation:MicrosoftOnline">
  <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0" isDefault="true"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://login.microsoftonline.com/login.srf" index="1"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf" index="2" />
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    </NameIDFormat>
    <NameIDFormat>
      urn:mace:shibboleth:1.0:nameIdentifier
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    </NameIDFormat>
  </SPSSODescriptor>
</EntityDescriptor>

Per aggiungere i metadati di Azure AD al provider di identità Shibboleth, è possibile usare il metodo The Filesystem Metadata Provider (Provider di metadati del file system). È possibile scaricare e archiviare manualmente i metadati di Azure AD in un file nella cartella IDP_HOME/metadata.

ImportantImportante
Negli esempi forniti in questo argomento IDP_HOME è la directory base in cui è stato installato il provider di identità Shibboleth, ad esempio c:\shibboleth2idp. Seguendo le istruzioni per la configurazione di Shibboleth contenute nell'argomento, sostituire IDP_HOME con il proprio percorso specifico.

È necessario abilitare la comunicazione tra il provider di identità Shibboleth e Azure AD definendo un nuovo elemento RelyingParty nel file IDP_Home/conf/relying-party.xml. Azure AD richiede di apportare modifiche alle impostazioni saml:SAML2Profile predefinite nell'elemento DefaultRelyingParty.

Inserire il seguente testo dopo l'elemento DefaultRelyingParty e assicurarsi che il valore di RelyingParty id corrisponda al valore di entityID specificato in Aggiungere i metadati di Azure AD, ad esempio "urn:federation:MicrosoftOnline". Verificare inoltre che il valore di provider corrisponda al valore di EntityID del provider di identità Shibboleth specificato nell'elemento DefaultRelyingParty, come mostrato nel seguente esempio:

<!-- Azure AD -->
<rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.com/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">
         
     <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
signAssertions="conditional"
encryptAssertions="never"
encryptNameIds="never" />
             
</rp:RelyingParty>

È necessario inoltre specificare al provider di identità Shibboleth dove trovare il file contenente i metadati di Azure AD, ad esempio IDP_HOME/metadata/windows-azure-ad-metadata.xml. A tale scopo, aggiungere una voce nel file IDP_Home/conf/relying-party.xml nel nodo MetadataProvider, come mostrato nel seguente esempio:

<!—- Azure AD Metadata -->
<metadata:MetadataProvider id="OrgID" xsi:type="metadata:ResourceBackedMetadataProvider">
<metadata:MetadataResource xsi:type="resource:FilesystemResource" file="C:\opt\shibboleth-idp/metadata/WindowsAzureAD-metadata.xml"/>

Azure AD richiede due tipi di dati del provider di identità Shibboleth per trovare l'account shadow nella piattaforma di autenticazione. Per informare Shibboleth di tali requisiti, aggiungere le seguenti voci al file IDP_HOME/conf/attribute-resolver.xml:

  • ImmutableID di Azure AD

    Azure AD richiede di selezionare un identificatore univoco per ogni utente nella directory degli utenti. È necessario inoltre configurare Shibboleth per l'invio di questo attributo a ogni accesso federato ad Azure AD nell'asserzione NameID di SAML 2.0. Non modificare questo identificatore per questo utente per tutta la durata della validità dell'utente nel sistema. Il servizio Azure AD definisce questo attributo "ImmutableID". Il valore dell'identificatore univoco non deve contenere le informazioni sul dominio e applica la distinzione tra maiuscole e minuscole.

    Non usare ad esempio utente@contoso.com. Nel codice consigliato più avanti il valore usato sarà la proprietà objectGUID di Active Directory con codifica Base 64. Quando si creano gli account, è necessario assicurarsi che ImmutableID venga elaborato nello stesso modo, altrimenti l'utente non potrà accedere al servizio cloud Microsoft. Lo Strumento di sincronizzazione di Microsoft Azure Active Directory usa automaticamente la proprietà objectGUID di Active Directory per il valore di ImmutableID e lo elabora come mostrato nell'esempio consigliato seguente:

    <!-- Use AD objectGUID for ImmutableID -->
    <resolver:AttributeDefinition id="ImmutableID" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
              sourceAttributeID="objectGUID">
       <resolver:Dependency ref="myLDAP" />
        
       <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
       nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
      </resolver:AttributeDefinition> 
    
    
    ImportantImportante
    Aggiornare il connettore dati LDAP nel file attribute-resolver.xml per specificare objectGUID come valore binario.

    Assicurarsi di aggiungere questa riga alla voce del connettore dati LDAP in modo che objectGUID sia gestito correttamente e sia codificato con Base 64.

    <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>
    
    
    Ad esempio:

    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->
    <!-- Live@edu LDAP Connector -->
    <resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                       ldapURL="ldap://MyADServer:389"
                       baseDN="CN=Users,DC=MyDomain,DC=ORG"
                       principal="CN=Administrator,CN=Users,DC=MyDomain,DC=ORG"
                       principalCredential="A.useful.p!w.d">
      <FilterTemplate>
        <![CDATA[
                    (uid=$requestContext.principalName)
                ]]>
      </FilterTemplate>
    
      <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>
    
    </resolver:DataConnector>
    
    
  • ID utente di Azure AD

    Azure AD richiede l'invio dell'ID utente di Azure AD, ad esempio, paolo@contoso.com, usando una voce personalizzata come descritto nell'esempio più avanti. In questo esempio il valore viene archiviato nell'attributo LDAP userPrincipalName.

    <!-- UserPrincipalName for Azure AD User ID -->
    <resolver:AttributeDefinition id="UserId" xsi:type="ad:Simple" sourceAttributeID="userPrincipalName">
          <resolver:Dependency ref="myLDAP" />
          <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="IDPEmail" friendlyName="UserId" />
    </resolver:AttributeDefinition> 
    
    

Il provider di identità Shibboleth deve essere configurato per rilasciare gli attributi necessari ad Azure AD. Aggiungere il testo seguente al file IDP_HOME/conf/attribute-filter.xml per rilasciare gli attributi ad Azure AD.

Le impostazioni mostrate rilasciano gli attributi necessari solo ad Azure AD e ai servizi Windows Live. Le impostazioni usano ID AttributeFilterPolicy specifici per indicare gli attributi obbligatori per Azure AD.


<!-- Attribute Filter Policy for Azure AD -->
<afp:AttributeFilterPolicy id="PolicyForWindowsAzureAD">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline" />

<!-- Release userPrincipalName as Azure AD User ID -->
      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Release Immutable ID to Azure AD -->
      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Note: it is not recommended to send transientId to Azure AD -->
<afp:AttributeRule attributeID="transientId">
   <afp:DenyValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>

</afp:AttributeFilterPolicy>

Sebbene sia un passaggio facoltativo, è consigliabile eseguirlo. Se si utilizza Shibboleth come servizio token di sicurezza, assicurarsi di installare l'estensione ECP del provider di identità Shibboleth per garantire il funzionamento di Single Sign-On con smartphone, Microsoft Outlook o altri client.

L'estensione ECP (Enhanced Client/Proxy) è inclusa in Shibboleth 2.3.3 e versioni successive. Per le versioni antecedenti a Shibboleth 2.x, è possibile scaricare e installare l'estensione ECP. Per altre informazioni, vedere: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

L'estensione ECP del provider di identità Shibboleth permette di abilitare l'integrazione delle applicazioni e-mail desktop con Azure AD. Questa estensione implementa la specifica ECP di SAML 2.0. Quando si configura l'accesso Single Sign-On con Azure AD, è possibile specificare l'URL per l'estensione ECP, ad esempio https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. L'autenticazione dell'estensione ECP di Shibboleth è attualmente limitata all'autenticazione di base.

Effettuare le seguenti operazioni se si è scelto di installare l'estensione ECP di Shibboleth:

  1. Aggiungere il seguente codice nel file dei metadati di Azure AD locale contenuto in IDP_HOME/metadata:

    <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf"/>
    
  2. Aggiungere la voce "saml:SAML2ECPProfile" al nodo di configurazione RelyingParty di Azure AD nel file relying-party.xml contenuto in IDP_HOME/config:

    <rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.edu/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">  
                    <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
                                    signAssertions="conditional" 
                                    encryptAssertions="never"                          
                                    encryptNameIds="never" />                                                      
                    <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile"                                                           
                                    signAssertions="always"                  
                                    encryptAssertions="never"                  
                                    encryptNameIds="never"/>                                                             
    </rp:RelyingParty>
    

Arrestare e avviare Apache Tomcat per riavviare il provider di identità Shibboleth e verificare che siano stati caricati i file XML aggiornati. È possibile che Shibboleth non venga riavviato in caso di problemi con uno o più file di configurazione. Dopo il riavvio, verificare i file di log di Shibboleth per assicurarsi che non siano segnalati errori. È consigliabile inoltre tentare di accedere a un provider di servizi Shibboleth precedentemente configurato nella rete.

noteNota
Verificare che l'orologio del server Shibboleth sia sincronizzato con un'origine ora esatta. Se l'ora non è corretta, gli accessi federati possono avere esito negativo.

Vedere anche

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
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:
© 2015 Microsoft