Esporta (0) Stampa
Espandi tutto

Configurazione di Shibboleth per l'utilizzo con Single Sign-On

Pubblicato: giugno 2012

Aggiornamento: febbraio 2013

Si applica a: Office 365, Windows Azure Active Directory, Windows Intune

noteNota
In questo argomento viene fornito contenuto della Guida online applicabile a più servizi cloud Microsoft, tra cui Windows Intune e Office 365.

In questo argomento vengono fornite le istruzioni dettagliate su come configurare Shibboleth Identity Provider per attuare la federazione con Windows 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) utilizzando il protocollo SAML 2.0. La relying party di SAML 2.0 per un servizio cloud Microsoft utilizzata in questo scenario è Windows Azure AD.

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

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

  • Client di posta elettronica che utilizzano l'autenticazione di base e il metodo di accesso Exchange supportato, come IMAP, POP, Active Sync, MAPI e così via (il punto finale del protocollo client avanzato deve essere distribuito), incluso:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 e 9

    • iPhone (varie versioni iOS)

    • Windows Phone 7

Tutti gli altri client non sono supportati in questo scenario Single Sign-On con Shibboleth Identity Provider. Ad esempio, il client desktop Lync 2010 non è supportato per l'accesso al servizio con Shibboleth Identity Provider configurato per Single Sign-On.

ImportantImportante
Prima di poter completare qualsiasi operazione di questo argomento che consente di configurare Shibboleth Identity Provider 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 Single Sign-On: roadmap.

Per configurare Shibboleth Identity Provider per l'utilizzo con Single Sign-On, completare i seguenti passaggi:

  1. Aggiunta di metadati di Windows Azure AD

  2. Aggiunta di Windows Azure AD come una relying party

  3. Configurazione della risoluzione degli attributi di Shibboleth

  4. Configurazione del filtro degli attributi di Shibboleth

  5. Facoltativo: Installazione dell'estensione ECP di Shibboleth

  6. Riavviare Shibboleth e verificare la funzionalità

ImportantImportante
Negli esempi forniti nell'argomento, IDP_HOME è la directory base dove è stato installato Shibboleth Identity Provider, ad esempio, c:\shibboleth2idp. Seguendo le istruzioni dell'argomento per la configurazione di Shibboleth, assicurarsi di sostituire IDP_HOME con il proprio percorso specifico.

Aggiunta di metadati di Windows Azure AD

Shibboleth Identity Provider richiede informazioni sulla relying party di Windows Azure AD. Windows Azure AD pubblica i metadati all'indirizzo https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Si consiglia di verificare sempre i metadati di Windows Azure AD più recenti. Il valore attuale dei metadati è:


<?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 Windows Azure AD a Shibboleth Identity Provider, è possibile utilizzare il metodo The Filesystem Metadata Provider (Provider di metadati del file system). Inoltre è possibile scaricare e archiviare manualmente i metadati di Windows Azure AD in un file nella cartella IDP_HOME/metadata.

ImportantImportante
Negli esempi forniti nell'argomento, IDP_HOME è la directory base dove è stato installato Shibboleth Identity Provider, ad esempio, c:\shibboleth2idp. Seguendo le istruzioni dell'argomento per la configurazione di Shibboleth, assicurarsi di sostituire IDP_HOME con il proprio percorso specifico.

Aggiunta di Windows Azure AD come una relying party

Abilitare la comunicazione tra Shibboleth Identity Provider e Windows Azure AD definendo un nuovo elemento RelyingParty nel file IDP_Home/conf/relying-party.xml. In Windows Azure AD sono necessarie modifiche alle impostazioni saml:SAML2Profile predefinite nell'elemento DefaultRelyingParty.

Inserire il testo riportato di seguito dopo l'elemento DefaultRelyingParty e assicurarsi che il valore di RelyingParty id corrisponda al valore di entityID specificato in Aggiunta di metadati di Windows Azure AD, ad esempio "urn:federation:MicrosoftOnline". Verificare inoltre che il valore provider corrisponda all'EntityID di Shibboleth Identity Provider specificato nell'elemento DefaultRelyingParty come mostrato nel seguente esempio:

<!-- Windows 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 a Shibboleth Identity Provider dove trovare il file che contiene i metadati di Windows Azure AD, ad esempio, IDP_HOME/metadata/wlid-metadata.xml. È possibile eseguire questa operazione aggiungendo una voce al file IDP_Home/conf/relying-party.xml nel nodo MetadataProvider come mostrato nel seguente esempio:

<!—- Windows 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"/>

Configurazione della risoluzione degli attributi di Shibboleth

Windows Azure AD richiede due tipi di dati da Shibboleth Identity Provider per individuare 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 Windows Azure AD

    Windows 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 su ogni accesso federato per Windows Azure AD nell'asserzione NameID di SAML 2.0. Non si deve modificare questo identificatore per questo utente per tutta la sua durata nel sistema. Il servizio Windows Azure AD definisce questo attributo "ImmutableID". Il valore dell'identificatore univoco non deve contenere le informazioni sul dominio e maiuscole/minuscole.

    Ad esempio, non utilizzare utente@contoso.com. Nel codice consigliato più avanti, il valore utilizzato sarà la proprietà objectGUID di Active Directory con codifica Base64. Quando si creano degli account, è necessario assicurarsi che ImmutableID venga elaborato nello stesso modo. In caso contrario l'utente non potrà accedere al servizio cloud Microsoft. Lo strumento di sincronizzazione della directory dei Microsoft Online Services utilizza automaticamente l'objectGUID di Active Directory per il valore 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 binario.

    Assicurarsi di aggiungere questa riga alla voce del connettore dati LDAP in modo che objectGUID sia gestito correttamente e disponga della codifica Base64.

    <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 Windows Azure AD

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

    <!-- UserPrincipalName for Windows 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> 
    
    

Configurazione del filtro degli attributi di Shibboleth

Shibboleth Identity Provider deve essere configurato per rilasciare gli attributi necessari a Windows Azure AD. Aggiungere il testo seguente al file IDP_HOME/conf/attribute-filter.xml per rilasciare gli attributi a Windows Azure AD.

Le impostazioni mostrate rilasciano gli attributi necessari solo a Windows Azure AD e ai servizi Windows Live. Le impostazioni utilizzano degli ID AttributeFilterPolicy specifici per indicare gli attributi necessari a Windows Azure AD.

<!-- Release userPrincipalName as Windows Azure AD User ID -->
<afp:AttributeFilterPolicy id="UserId">
   <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline"/>

      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

</afp:AttributeFilterPolicy>


<!-- Release Immutable ID to Windows Azure AD -->
<afp:AttributeFilterPolicy id="ImmutableID">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline"/>

      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

 </afp:AttributeFilterPolicy>

Facoltativo: Installazione dell'estensione ECP di Shibboleth

Sebbene sia un passaggio facoltativo, si consiglia di eseguirlo. Se si utilizza Shibboleth come STS, assicurarsi di installare l'estensione ECP di Shibboleth Identity Provider per consentire il funzionamento di Single Sign-On con uno smartphone, Microsoft Outlook o altri client.

L'estensione ECP (enhanced client/proxy) viene incluso in Shibboleth 2.3.3 e versioni successive. Per le versioni precedenti di Shibboleth 2.x, è possibile scaricare e installare l'estensione ECP. Per ulteriori informazioni, vedere: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

L'estensione ECP di Shibboleth Identity Provider consente di abilitare l'integrazione delle applicazioni di posta elettronica sul desktop con Windows Azure AD. Questa estensione implementa la specifica ECP di SAML 2.0. Quando si configura Single Sign-On con Windows 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.

Riavviare Shibboleth e verificare la funzionalità

Arrestare e riavviare Apache Tomcat per riavviare Shibboleth Identity Provider e assicurarsi che i file XML aggiornati siano stati caricati. È possibile che Shibboleth non venga riavviato qualora ci fosse un problema con uno o più file di configurazione. Dopo il riavvio, verificare i file di registro di Shibboleth per assicurarsi che non siano stati rilevati errori. Si consiglia inoltre di tentare l'accesso a un provider di servizi Shibboleth precedentemente configurato sulla rete.

noteNota
Verificare che l'orologio del server Shibboleth venga sincronizzato con un'origine ora esatta. Se l'orologio non è preciso, è possibile che gli accessi federati non vengano eseguiti.

Vedere anche

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

Aggiunte alla community

AGGIUNGI
Mostra:
© 2014 Microsoft