シングル サインオンで使用するために Shibboleth を構成する

  • [アーティクル]

更新日: 2015 年 6 月 25 日

適用対象: Azure、Office 365、Power BI、Windows Intune

このトピックでは、SAML 2.0 プロトコルを使用して 1 つ以上の Microsoft クラウド サービス (たとえば、Microsoft IntuneやOffice 365) へのシングル サインオン アクセスを有効にするために、Shibboleth Identity Provider を Azure AD とフェデレーションするように構成する方法について詳しく説明します。 このシナリオで使用される Microsoft クラウド サービスの SAML 2.0 証明書利用者は Azure AD です。

重要

このシングル サインオンのシナリオでは、次のような一連の限定的なクライアントのみがサポートされます。

  • Exchange Web Access や SharePoint Online などの Web ベースのクライアント

  • 基本認証と IMAP、POP、Active Sync、MAPI などサポート対象の Exchange のアクセス方法を使用する電子メールリッチ クライアント (展開には、Enhanced Client Protocol エンド ポイントが必要)、次のクライアントが含まれます。

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 および 9

    • iPhone (さまざまな iOS のバージョン)

    • Windows Phone 7

Shibboleth Identity Provider を使用したこのシングル サインオン シナリオでは、他のすべてのクライアントはサポートされていません。  たとえば、Lync 2010 デスクトップ クライアントは、シングル サインオン用に構成された Shibboleth Identity Provider を使用してサービスにログインすることはサポートされていません。

重要

シングル サインオン用に Shibboleth Identity Provider を構成するには、このトピックの手順を完了する前に、「シングル サインオンの 準備」に記載されている手順を確認し、従う必要があります。

シングル サインオンに関する一般的な情報については、「 シングル サインオンのロードマップ」を参照してください。

シングル サインオンで使用できるように Shibboleth ID プロバイダーを構成するには、以下の手順を実行します。

  1. Azure AD メタデータを追加する

  2. Azure AD を証明書利用者として追加する

  3. Shibboleth 属性リゾルバーを構成する

  4. Shibboleth 属性フィルターを構成する

  5. 省略可能: Shibboleth ECP 拡張機能をインストールする

  6. Shibboleth を再起動して機能を検証する

重要

このトピックでは、IDP_HOME は Shibboleth ID プロバイダーをインストールしたベース ディレクトリです (例: c:\shibboleth2idp)。 このトピックの説明に従って Shibboleth を構成するときは、IDP_HOME を実際のパスに置き換えてください。

Azure AD メタデータを追加する

Shibboleth ID プロバイダーには、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 ID プロバイダーに追加するには、Filesystem Metadata Provider メソッドを使用できます。Azure AD メタデータを手動でダウンロードし、IDP_HOME/metadata フォルダーにファイルを格納できます。

重要

このトピックでは、IDP_HOME は Shibboleth ID プロバイダーをインストールしたベース ディレクトリです (例: c:\shibboleth2idp)。 このトピックの説明に従って Shibboleth を構成するときは、IDP_HOME を実際のパスに置き換えてください。

Azure AD を証明書利用者として追加する

IDP_Home/conf/relying-party.xml ファイルで新しい RelyingParty 要素を定義することによって、Shibboleth ID プロバイダーと Azure AD の間の通信を有効にする必要があります。 Azure AD では、DefaultRelyingParty 要素の saml:SAML2Profile の既定の設定を変更する必要があります。

DefaultRelyingParty 要素の後に次のテキストを挿入し、RelyingParty id の値が、Azure AD メタデータの追加で指定した entityID 値と一致していることを確認します (例: "urn:federation:MicrosoftOnline")。 また、provider の値が、次の例で示されているように DefaultRelyingParty で指定されている Shibboleth ID プロバイダーの EntityID と一致していることを確認します。

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

また、Azure AD メタデータを含むファイルを検索する Shibboleth ID プロバイダーも指定する必要があります (例: 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 ID プロバイダーからの 2 つのデータを必要とします。 これらの要件を Shibboleth に伝えるには、次のエントリを IDP_HOME/conf/attribute-resolver.xml ファイルに追加します。

  • Azure AD ImmutableID

    Azure AD では、ユーザー ディレクトリ内の各ユーザーに対して固有の ID を選択する必要があります。 また、各フェデレーション ログインにおいて SAML 2.0 NameID アサーションで Azure AD にこの属性を送るように Shibboleth を構成する必要もあります。 この ID は、ユーザーがシステムにいる間は変更されないようにする必要があります。 Azure AD サービスではこの属性は “ImmutableID” と呼ばれます。 この一意の ID の値は、ドメイン情報を含んでいてはならず、大文字と小文字が区別されます。

    たとえば、使用しないでください user@contoso.com。 以下の推奨されるコードでは、使用される値は Base 64 でエンコードされた Active Directory objectGUID プロパティです。 アカウントを作成するときは、ImmutableID が同じ方法で処理されることを確認する必要があります。そうでないと、ユーザーは Microsoft クラウド サービスにサインインできません。 Microsoft Azure Active Directory同期ツールは、ImmutableID 値に Active Directory objectGUID を自動的に使用し、次の推奨例と同じ方法で 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>

    重要

    attribute-resolver.xml の LDAP データ コネクタを更新し、バイナリとして objectGUID を指定します。

    次の行を LDAP データ コネクタ エントリに追加します。これにより、objectGUID は正しく処理され、Base 64 エンコード形式になります。

    <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 ユーザー ID

    Azure AD では、次の例で説明するように、 joe@contoso.comカスタム エントリを使用して Azure AD ユーザー ID (たとえば) を送信する必要があります。 この例では、値は 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 ID プロバイダーを構成する必要があります。 属性を Azure AD にリリースするには、次のテキストを IDP_HOME/conf/attribute-filter.xml ファイルに追加します。

ここで示す設定は、必要な属性を Azure AD および Windows Live サービスに対してのみリリースします。 この設定では、特定の AttributeFilterPolicy ID を使用して、属性が 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 拡張機能をインストールする

省略可能ではありますが、これは推奨される手順です。 STS として Shibboleth を使用している場合、スマートフォン、Microsoft Outlook、その他のクライアントでシングル サインオンを使用できるように、Shibboleth Identity Provider ECP 拡張機能をインストールすることをお勧めします。

拡張クライアント/プロキシ (ECP) 拡張機能は、Shibboleth 2.3.3 以降に組み込まれています。 それより前のバージョンの Shibboleth 2.x については、ECP 拡張機能をダウンロードとしてインストールできます。 詳細については、「https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension」を参照してください。

Shibboleth ID プロバイダー ECP 拡張機能を使用すると、デスクトップ電子メール アプリケーションと Azure AD を統合できます。 この拡張機能は、SAML 2.0 ECP 仕様を実装します。 Azure AD でシングル サインオンを構成するときに、ECP 拡張機能の URL を指定できます (例: https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP)。 現在、Shibboleth ECP 拡張機能の認証は基本認証に制限されています。

Shibboleth ECP 拡張機能をインストールする場合は、次の手順を実行します。

  1. 以下のコードを、IDP_HOME/metadata にある Azure AD メタデータ ファイルに追加します。

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

  2. "saml:SAML2ECPProfile" エントリを、IDP_HOME/config にある relying-party.xml の Azure AD RelyingParty 構成ノードに追加します。

    <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 を再起動して機能を検証する

Apache Tomcat を起動し直して Shibboleth ID プロバイダーを再起動し、更新された XML ファイルが読み込まれることを確認します。 構成ファイルに問題があると、Shibboleth は起動しない場合があります。 再起動後に Shibboleth のログ ファイルを調べて、エラーがないことを確認します。 また、ネットワーク上の構成した Shibboleth サービス プロバイダーにサインインしてアクセスしてみることもお勧めします。

注意

Shibboleth サーバーのクロックが正しいタイム ソースと同期されていることを確認します。 不正確なクロック時間は、フェデレーション ログインの失敗の原因になる可能性があります。

参照

概念

Shibboleth ID プロバイダーを使用してシングル サインオンを実装する