Configurare Shibboleth per l'uso con Single Sign-On

  • Articolo

Aggiornamento: 25 giugno 2015

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

Questo argomento contiene istruzioni dettagliate su come configurare Shibboleth Identity Provider per la federazione con Azure AD per abilitare l'accesso Single Sign-On a uno o più servizi cloud Microsoft(ad esempio, Microsoft 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.

Importante

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

  • Client basati sul Web, ad esempio 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 di accesso Single Sign-On con Shibboleth Identity Provider.  Ad esempio, il client desktop lync 2010 non è supportato per accedere al servizio con Shibboleth Identity Provider configurato per l'accesso Single Sign-On.

Importante

Prima di completare una delle procedure descritte in questo argomento per configurare Shibboleth Identity Provider for Single Sign-On, è necessario esaminare e seguire le istruzioni fornite in Preparazione per l'accesso Single Sign-On.

Per informazioni generali sull'accesso Single Sign-On, vedere Roadmap per l'accesso 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 Shibboleth

  6. Riavviare Shibboleth e verificare il funzionamento

Importante

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.

Aggiungere i metadati di Azure AD

Il provider di identità Shibboleth richiede informazioni sulla relying party di Azure AD. Azure AD pubblica i metadati all'indirizzo 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.

Importante

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.

Aggiungere Azure AD come relying party

È 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 testo seguente dopo l'elemento DefaultRelyingParty e assicurarsi che il valore dell'ID RelyingParty corrisponda al valore entityID specificato in Aggiungere 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"/>

Configurare il resolver degli attributi di Shibboleth

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.

    Ad esempio, non usare user@contoso.com. Nel codice consigliato riportato di seguito il valore usato sarà la proprietà objectGUID di Active Directory con codifica base64. 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 Microsoft Azure Active Directory usa automaticamente l'objectGUID di Active Directory per il valore ImmutableID e elabora l'ImmutableID allo stesso modo dell'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>

    Importante

    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 che l'ID utente di Azure AD, ad esempio , joe@contoso.comvenga inviato usando la voce personalizzata come descritto nell'esempio seguente. 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>

Configurare il filtro degli attributi di Shibboleth

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>

Facoltativo: installare l'estensione ECP Shibboleth

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>

Riavviare Shibboleth e verificare il funzionamento

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.

Nota

Verificare che l'orologio del server Shibboleth sia sincronizzato con un'origine ora esatta. L'impostazione non corretta dell'ora può comportare un errore degli accessi federati.

Vedere anche

Concetti

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