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

発行: 2012年6月

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

このトピックでは、SAML 2.0 プロトコルを使用する Microsoft クラウド サービス (Microsoft Intune や Office 365 など) にサインオンできるよう、Azure AD とフェデレーションするように Shibboleth ID プロバイダーを構成するための詳細な方法を示します。このシナリオで、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 ID プロバイダーでのサービスへのログインをサポートされていません。

重要

シングル サインオン対応に Shibboleth ID プロバイダーを構成するこのトピックの手順を実行する前に、「シングル サインオンを準備する」の指示を読んで従う必要があります。

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

シングル サインオンで使用できるように 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 では、Azure AD ユーザー ID (例: 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 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 プロバイダーを使用してシングル サインオンを実装する