Aracılığıyla paylaş

Shibboleth'i çoklu oturum açma ile kullanılacak şekilde yapılandırma

  • Makale

Güncelleştirme: 25 Haziran 2015

Şunlar için geçerlidir: Azure, Office 365, Power BI Windows Intune

Bu konu, SAML 2.0 protokolunu kullanarak bir veya daha fazla Microsoft bulut hizmetine (örneğin, Microsoft Intune ve/veya Office 365) çoklu oturum açma erişimini etkinleştirmek üzere Azure AD ile federasyon sağlamak üzere Shibboleth Kimlik Sağlayıcısı'nı yapılandırma hakkında ayrıntılı yönergeler içerir. Bu senaryoda kullanılan bir Microsoft bulut hizmeti için SAML 2.0 bağlı olan taraf Azure AD.

Önemli

Bu çoklu oturum açma senaryosunda aşağıdaki gibi yalnızca sınırlı bir istemci kümesi desteklenir:

  • Exchange Web Erişimi ve SharePoint Online gibi web tabanlı istemciler

  • Temel kimlik doğrulaması ve IMAP, POP, Active Sync, MAPI gibi desteklenen bir Exchange erişim yöntemi kullanan e-posta açısından zengin istemciler (Gelişmiş istemci protokolü uç noktasının dağıtılması gerekir), örneğin:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 ve 9

    • iPhone (çeşitli iOS sürümleri)

    • Windows Phone 7

Shibboleth Kimlik Sağlayıcısı ile bu çoklu oturum açma senaryosunda diğer tüm istemciler desteklenmez.  Örneğin, Lync 2010 masaüstü istemcisinin çoklu oturum açma için yapılandırılmış Shibboleth Kimlik Sağlayıcısı ile hizmette oturum açması desteklenmez.

Önemli

Shibboleth Kimlik Sağlayıcısı'nı çoklu oturum açma için yapılandırmak üzere bu konudaki adımlardan herhangi birini tamamlayabilmeniz için önce Çoklu oturum açmaya hazırlanma bölümünde verilen yönergeleri gözden geçirmeniz ve izlemeniz gerekir.

Çoklu oturum açma hakkında genel bilgi için bkz. Çoklu oturum açma yol haritası.

Shibboleth Kimlik Sağlayıcısı'nı çoklu oturum açma ile kullanmak üzere yapılandırmak için aşağıdaki adımları tamamlayın:

  1. Azure AD meta verileri ekleme

  2. bağlı olan taraf olarak Azure AD ekleme

  3. Shibboleth öznitelik çözümleyicisini yapılandırma

  4. Shibboleth öznitelik filtresini yapılandırma

  5. İsteğe bağlı: Shibboleth ECP Uzantısını Yükleme

  6. Shibboleth'i yeniden başlatın ve işlevselliği doğrulayın

Önemli

Bu konu başlığındaki örneklerde IDP_HOME , Shibboleth Kimlik Sağlayıcısı'nı yüklediğiniz temel dizindir, örneğin, c:\shibboleth2idp. Shibboleth'i yapılandırmak için bu konudaki yönergeleri izlediğinizde, IDP_HOME kendi yolunuzla değiştirdiğinizden emin olun.

Azure AD meta verileri ekleme

Shibboleth Kimlik Sağlayıcısının Azure AD bağlı olan taraf hakkında bilgi alması gerekir. Azure AD meta verileri konumunda https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xmlyayımlar. Her zaman en son Azure AD meta verilerini denetlemeniz önerilir. Meta verilerin geçerli değeri aşağıdadır:

<?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>

Azure AD meta verilerini Shibboleth Kimlik Sağlayıcısı'na eklemek için Dosya Sistemi Meta Veri Sağlayıcısı yöntemini kullanabilirsiniz; Azure AD meta verileri IDP_HOME/meta veri klasöründeki bir dosyada el ile indirebilir ve depolayabilirsiniz.

Önemli

Bu konu başlığındaki örneklerde IDP_HOME , Shibboleth Kimlik Sağlayıcısı'nı yüklediğiniz temel dizindir, örneğin, c:\shibboleth2idp. Shibboleth'i yapılandırmak için bu konudaki yönergeleri izlediğinizde, IDP_HOME kendi yolunuzla değiştirdiğinizden emin olun.

bağlı olan taraf olarak Azure AD ekleme

IDP_Home/conf/relying-party.xmldosyasında yeni bir RelyingParty öğesi tanımlayarak Shibboleth Kimlik Sağlayıcısı ile Azure AD arasında iletişimi etkinleştirmeniz gerekir. Azure AD, DefaultRelyingParty öğesindeki varsayılan saml:SAML2Profile ayarlarında değişiklik yapılmasını gerektirir.

DefaultRelyingParty öğesinin arkasına aşağıdaki metni ekleyin ve RelyingParty kimlik değerinin Azure AD meta verileri ekle bölümünde belirttiğiniz entityID değeriyle eşleştiğinden emin olun; örneğin, "urn:federation:MicrosoftOnline". Ayrıca, sağlayıcı değerinizin aşağıdaki örnekte gösterildiği gibi DefaultRelyingParty öğesinde belirtilen Shibboleth Kimlik Sağlayıcınızın EntityID değeriyle eşleştiğinden emin olun:

<!-- 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>

Ayrıca, Azure AD meta verilerini içeren dosyanın bulunacağı Shibboleth Kimlik Sağlayıcısı'na da belirtmelisiniz, örneğin, IDP_HOME/metadata/windows-azure-ad-metadata.xml. Bunu, aşağıdaki örnekte gösterildiği gibi MetadataProvider düğümündeki IDP_Home/conf/relying-party.xml dosyasına bir giriş ekleyerek yapabilirsiniz:

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

Shibboleth öznitelik çözümleyicisini yapılandırma

Azure AD, kimlik doğrulama platformunda gölge hesabı bulmak için Shibboleth Kimlik Sağlayıcısı'ndan iki veri parçası gerektirir. Shibboleth'i bu gereksinimler hakkında bilgilendirmek için IDP_HOME/conf/attribute-resolver.xml dosyasına aşağıdaki girdileri ekleyin:

  • Azure AD SabitKimliği

    Azure AD, kullanıcı dizininizdeki her kullanıcı için benzersiz bir tanımlayıcı seçmenizi gerektirir. Ayrıca Shibboleth'i, her federasyon oturumunda bu özniteliği SAML 2.0 NameID onayında Azure AD gönderecek şekilde yapılandırmanız gerekir. Bu tanımlayıcı, sisteminizde bulunan kullanıcının ömrü boyunca bu kullanıcı için değişmemelidir. Azure AD Hizmeti bu özniteliği "ImmutableID" olarak çağırır. Benzersiz tanımlayıcının değeri etki alanı bilgilerini içermemelidir ve büyük/küçük harfe duyarlıdır.

    Örneğin, kullanmayın user@contoso.com. Aşağıdaki önerilen kodda, kullanılan değer base64 kodlamalı Active Directory objectGUID özelliği olacaktır. Hesap oluştururken, ImmutableID değerinin aynı şekilde işlendiğinden emin olmanız gerekir, aksi takdirde kullanıcı Microsoft bulut hizmetinde oturum açamaz. Microsoft Azure Active Directory Eşitleme aracı, ImmutableID değeri için Active Directory objectGUID'sini otomatik olarak kullanır ve ImmutableID'yi aşağıdaki önerilen örnekte olduğu gibi işler:

    <!-- 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>

    Önemli

    attribute-resolver.xml'de LDAP Veri Bağlayıcısı'nı, objectGUID'yi ikili olarak belirtecek şekilde güncelleştirin.

    Bu satırı LDAP Veri Bağlayıcısı girdinize eklediğinizden emin olun; bu, objectGUID'nin doğru işlendiğinden ve base64 ile kodlandığından emin olun.

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

    Örnek:

    <!-- ========================================== -->
<!--      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>

  • Azure AD Kullanıcı Kimliği

    Azure AD, Azure AD Kullanıcı Kimliğinin, örneğin, joe@contoso.comaşağıdaki örnekte açıklandığı gibi özel giriş kullanılarak gönderilmesini gerektirir. Bu örnekte, değer LDAP userPrincipalName özniteliğinde depolanır.

    <!-- 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>

Shibboleth öznitelik filtresini yapılandırma

Shibboleth Kimlik Sağlayıcısı, gerekli öznitelikleri Azure AD'a serbest bırakacak şekilde yapılandırılmalıdır. Öznitelikleri Azure AD serbest bırakmak için IDP_HOME/conf/attribute-filter.xml dosyasına aşağıdaki metni ekleyin.

Burada gösterilen ayarlar yalnızca Azure AD ve Windows Live hizmetleri için gerekli öznitelikleri yayınlar. Ayarlar, özniteliklerin Azure AD gerektirdiğini belirtmek için belirli AttributeFilterPolicy kimliklerini kullanır.

<!-- 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>

İsteğe bağlı: Shibboleth ECP Uzantısını Yükleme

İsteğe bağlı olsa da, bu önerilen bir adımdır. STS'niz olarak Shibboleth kullanıyorsanız, çoklu oturum açmanın akıllı telefon, Microsoft Outlook veya diğer istemcilerle çalışması için Shibboleth Kimlik Sağlayıcısı ECP uzantısını yüklediğinizden emin olun.

Geliştirilmiş istemci/ara sunucu (ECP) uzantısı Shibboleth 2.3.3 ve sonraki sürümlerde bulunur. Shibboleth 2.x'in önceki sürümü için ECP uzantısını indirip yükleyebilirsiniz. Daha fazla bilgi için, bkz. https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Shibboleth Kimlik Sağlayıcısı ECP uzantısı, masaüstü e-posta uygulamalarının Azure AD ile tümleştirilmesini etkinleştirmenize olanak tanır. Bu uzantı SAML 2.0 ECP belirtimini uygular. Azure AD ile çoklu oturum açmayı yapılandırırken, ECP uzantısının URL'sini belirtebilirsiniz, örneğin, https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Shibboleth ECP uzantısı kimlik doğrulaması şu anda temel kimlik doğrulamasıyla sınırlıdır.

Shibboleth ECP uzantısını yüklemeyi seçerseniz aşağıdaki adımları tamamlayın:

  1. IDP_HOME/meta veride bulunan yerel Azure AD meta veri dosyanıza aşağıdaki kodu ekleyin:

    <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf"/>

  2. IDP_HOME/config konumunda bulunan relying-party.xml'daki Azure AD RelyingParty yapılandırma düğümüne "saml:SAML2ECPProfile" girişini ekleyin:

    <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>

Shibboleth'i yeniden başlatın ve işlevselliği doğrulayın

Shibboleth Kimlik Sağlayıcısı'nı yeniden başlatmak ve güncelleştirilmiş XML dosyalarının yüklendiğinden emin olmak için Apache Tomcat'i durdurun ve başlatın. Bir veya daha fazla yapılandırma dosyasıyla ilgili bir sorun varsa Shibboleth başlatılamaz. Yeniden başlatmadan sonra hata bildirildiğinden emin olmak için Shibboleth günlük dosyalarını denetleyin. Ayrıca, ağınızda oturum açmayı ve önceden yapılandırılmış bir Shibboleth hizmet sağlayıcısına erişmeyi denemenizi öneririz.

Not

Shibboleth sunucunuzdaki saatin doğru bir zaman kaynağıyla eşitlendiğini doğrulayın. Yanlış bir saat süresi federasyon oturum açmalarının başarısız olmasına neden olabilir.

Ayrıca Bkz.

Kavramlar

Çoklu oturum açma uygulamak için Shibboleth Kimlik Sağlayıcısını kullanma