Настройка Shibboleth для использования с функцией единого входа

Обновлено: 25 июня 2015 г.

Область применения: Azure, Office 365, Power BI, Windows Intune

В этом разделе содержатся подробные инструкции по настройке поставщика удостоверений Shibboleth для федерации с Azure AD для включения единого входа к одной или нескольким облачным службам Майкрософт (например, Microsoft Intune или Office 365) с помощью протокола SAML 2.0. В качестве проверяющей стороны SAML 2.0 для облачной службы (Майкрософт) в этом сценарии используется Azure AD.

Чтобы настроить поставщик удостоверений Shibboleth для использования с единым входом, необходимо выполнить следующие шаги:

1. Добавление метаданных Azure AD

2. Добавление Azure AD в качестве проверяющей стороны

3. Настройка сопоставителя атрибутов Shibboleth

4. Настройка фильтра атрибутов Shibboleth

5. Необязательно. Установка расширения SHIbboleth ECP

6. Перезапуск Shibboleth и проверка функциональности

Добавление метаданных Azure AD

Поставщику удостоверений Shibboleth необходима информация о проверяющей стороне Azure AD. Azure AD публикует метаданные по адресу https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Рекомендуется всегда проверять наличие новейших метаданных Azure AD. Здесь хранится текущее значение метаданных:

<?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 в поставщик удостоверений Shibboleth, можно использовать метод поставщика метаданных файловой системы — скачать вручную и сохранить метаданные Azure AD в файле в папке IDP_HOME/metadata.

Добавление Azure AD в качестве проверяющей стороны

Необходимо обеспечить связь между поставщиком удостоверений Shibboleth и Azure AD. Сделать это можно, определив новый элемент RelyingParty в файле IDP_Home/conf/relying-party.xml. Для Azure AD необходимо внести изменения в параметры по умолчанию saml:SAML2Profile в элементе DefaultRelyingParty.

Вставьте следующий текст после элемента DefaultRelyingParty и убедитесь, что значение идентификатора RelyingParty соответствует значению entityID, указанному в параметре Add Azure AD метаданных, например urn:federation:MicrosoftOnline. Необходимо также убедиться в том, что значение provider совпадает со значением EntityID поставщика удостоверений Shibboleth, которое было определено в элементе DefaultRelyingParty, как указывается в следующем примере:

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

Кроме этого нужно указать поставщику удостоверений Shibboleth, где искать файл с метаданными Azure AD, например IDP_HOME/metadata/windows-azure-ad-metadata.xml. Сделать это можно, добавив запись в файл IDP_Home/conf/relying-party.xml в узле MetadataProvider, как показано в следующем примере:

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

Чтобы найти теневую учетную запись на платформе проверки подлинности, Azure AD требуется получить две части данных от поставщика удостоверений Shibboleth. Проинформировать поставщика удостоверений Shibboleth об этих требованиях можно, добавив следующие записи в файл IDP_HOME/conf/attribute-resolver.xml:

• ImmutableID Azure AD

  Azure AD требует выбрать уникальный идентификатор для каждого пользователя в каталоге пользователей. Необходимо также настроить Shibboleth для отправки этого атрибута в рамках каждого федеративного входа в Azure AD в утверждении SAML 2.0 NameID. Этот идентификатор для конкретного пользователя не должен изменяться в течение всего времени существования пользователя в системе. В службе Azure AD этот атрибут называется "неизменяемым идентификатором" (ImmutableID). Значение уникального идентификатора не должно содержать сведений о домене и присваивается с учетом регистра.

  Например, не используйте user@contoso.com. В приведенном ниже коде используется свойство ObjectGUID Active Directory, закодированное в кодировке Base64. При создании учетных записей необходимо таким же образом обеспечить обработку ImmutableID. В противном случае пользователь не сможет войти в облачную службу (Майкрософт). Средство синхронизации Microsoft Azure Active Directory автоматически использует объект Active Directory objectGUID для значения ImmutableID и обрабатывает ImmutableID так же, как в следующем рекомендуемом примере:

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

  Важно!

  Чтобы определить objectGUID в двоичном представлении, необходимо обновить соединитель данных LDAP в XML-файле attribute-resolver.xml.

  Не забудьте добавить эту строку в запись соединителя данных LDAP. Это обеспечит правильную обработку objectGUID и его кодировку в формат base64.

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

  Вот несколько примеров.

  <!-- ========================================== -->
  <!--      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 идентификатор пользователя

  Azure AD требуется, чтобы идентификатор пользователя Azure AD, например, отправляется с помощью пользовательской записи, joe@contoso.comкак описано в примере ниже. В этом примере значение хранится в атрибуте 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> 
  

Настройка фильтра атрибутов Shibboleth

Чтобы выпустить необходимые атрибуты для Azure AD, поставщик удостоверений Shibboleth должен быть настроен. Добавьте следующий текст в файл IDP_HOME/conf/attribute-filter.xml для выпуска атрибутов в Azure AD.

Указанные здесь параметры обеспечивают выпуск требуемых атрибутов только в Azure AD и службы Windows Live. В параметрах используются определенные идентификаторы AttributeFilterPolicy для указания на то, что атрибуты требуются для 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>

Необязательно. Установка расширения SHIbboleth ECP

Этот шаг выполнять необязательно, но рекомендуется. При использовании Shibboleth в качестве службы токенов безопасности (STS) рекомендуется установить расширение ECP поставщика удостоверений Shibboleth, чтобы единый вход работал со смартфонами, Microsoft Outlook или другими клиентами.

Улучшенное расширение "клиент-прокси" (ECP) входит в состав Shibboleth 2.3.3 и более поздних версий. В ранних версиях Shibboleth 2.x можно скачать и установить расширение ECP. Дополнительные сведения см. на странице https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Расширение ЕСР поставщика удостоверений Shibboleth обеспечивает интеграцию классических почтовых клиентов с Azure AD. Это расширение реализует спецификацию SAML 2.0 ECP. При настройке единого входа с использованием Azure AD для расширения ECР можно определить URL-адрес, например https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Проверка подлинности для расширения Shibboleth ECP в настоящее время сводится к обычной проверке подлинности.

При желании установить расширение Shibboleth ECP необходимо выполнить следующие шаги:

1. Добавьте следующий код в локальный файл метаданных Azure AD, расположенный в папке IDP_HOME/metadata:

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

2. Добавьте запись "saml:SAML2ECPProfile" в узел настройки Azure AD RelyingParty в файле relying-party.xml, расположенном в папке 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>
   

Перезапуск Shibboleth и проверка функциональности

Чтобы перезапустить поставщик удостоверений Shibboleth и обеспечить загрузку обновленных XML-файлов, необходимо остановить и снова запустить Apache Tomcat. При наличии проблем с одним или несколькими файлами конфигурации может произойти ошибка во время запуска Shibboleth. Чтобы убедиться в отсутствии ошибок, необходимо проверить файлы журналов Shibboleth. Рекомендуем также попытаться войти и получить доступ к настроенному ранее поставщику службы Shibboleth в вашей сети.

См. также:

Основные понятия

Использование поставщика удостоверений Shibboleth для реализации единого входа