Share via

SharePoint 2010 と Azure Access Control Service によるフェデレーション SAML 認証 (パート 1)

  • Article

原文の記事の投稿日: 2011 年 5 月 6 日 (金曜日)

メモ: いつもながら、このサイトの書式設定は最悪です。この投稿に添付されている Word 文書をダウンロードして参照することをお勧めします。

最近、私は Windows Azure Access Control Service (ACS)
を興味深い目で観察し、さまざまな統合オプションについて考えました。SharePoint 2010 によるクレーム認証や、ADFS、Windows
Live、Facebookなどの統合方法についてのチャットは常に盛んです。ACS (Azure 純粋主義者/マーケティング担当者にとっては AppFabric
ACS としても知られています) には、これらの一般的な ID プロバイダー用の “コネクタ”
がすぐに使用できるように組み込まれているため、かなり好評です。ACS の名前空間 (コネクタと構成設定を持つアカウントのようなものと考えてください)
を設定すれば、ADFS 2.0、Windows Live、Yahoo、Google、Facebook
への簡単で合理的な接続が使用できます。私の中にいる怠け者のプログラマはそこに何かあるに違いないと考え、そこで私はいくつかの異なる角度からこの点を調べることにしました。この投稿では、1
つ目について説明します。

 

このシナリオで、私が本当にしたかったことは、SharePoint 2010 と ACS の間に信頼関係を直接確立することでした。ADFS、Windows Live、Yahoo、および Google の各アカウントを使用して認証を行い、SharePoint サイトに入ることができたら、と思っていました。ソーシャル コンピューティグは実は得意でないので (このブログではほとんど説明しません) Facebook は取り入れませんでした。無意味な情報 (“Puffy が子猫を 3 匹生んだのよ、かわいい!!”) を世界全体と頻繁に共有することには興味がないので、私は Facebook のアカウントも Twitter のアカウントも持っていません。Windows Azure のアカウントを取得する方法、Access Control Service の名前空間を作成する方法、ACS を管理する方法などについては説明しません。Windows Azure ユーザーの外側にある情報は膨大なので、ここでは試したり、作り変えたりしません。

 

ここで説明することは、このすべてを連携させるために必要なさまざまな信頼関係、証明書、および構成を設定するプロセスです。最後に、各プロバイダーの ID を使用してログインしたときのスクリーンショットを示します。接続するための手順は、次のとおりです。

  1. [Access Control Management] ページを開く

    1. Windows Azure 管理ポータルにログインします。左側のウィンドウの [Service Bus, Access Control and Caching] メニューをクリックします。左側のウィンドウの最上部にある [AppFabric] の下の [Access Control] をクリックし、右側のウィンドウで目的の名前空間をクリックします。次に、リボンの [Management] にある [Access Control Service] をクリックします。[Access Control Management] ページが表示されます。

  2. ADFS の ID プロバイダーを追加する

    1. 左側のウィンドウの [Trust relationships] メニューの [Identity providers] をクリックします。
    2. [Add link] をクリックします。
    3. 既定で [WS-Federation identity provider] ラジオ ボタンがオンになっています。オンになっていない場合はオンにします。これは ADFS 2.0 に使用する ID プロバイダーです。[Next] ボタンをクリックします。
    4. [Identity Provider Settings] セクションに入力します。
      1. [Display name] に “My ADFS Server” などを入力します。
      2. WS-Federation メタデータの場合は、ADFS サーバーがインターネットを介して公開されていれば、フェデレーション メタデータ エンドポイントの URL に入ります。既定の場所は、https://yourAdfsServer.com/FederationMetadata/2007-06/FederationMetadata.xml です。ADFS サーバーがインターネットに公開されていない場合は、ローカル ブラウザーにエンドポイントの URL を開きます。ブラウザーに移動し、ページを .XML ファイルとしてローカル ファイル システムに保存します。次に、ACS の [Identity Provider Settings] で、[File] 編集ボックスの横のラジオ ボタンをオンにし、[Browse] ボタンを使用して、保存したフェデレーション メタデータの XML ファイルを見つけます。

ACS で ID プロバイダーを作成するために必要なことは、これでほぼ終わりです。

3.        SharePoint の証明書利用者を追加する

  1.  
    1. 次に、SharePoint と ADFS を一緒に構成する場合と同じように、ACS の証明書利用者として SharePoint を追加する必要があります。まず、左側のウィンドウの [Trust relationships] の下の [Relying party applications] リンクをクリックします。
    2. [Add link] をクリックします。
    3. [Relying Party Application Settings] セクションの項目を入力します。
      1. “SharePoint 2010” のように、表示名を入力します。
      2. [Mode] には、既定の [Enter settings manually] を使用します。
      3. [Realm] 編集ボックスに、領域を入力して保存します。この領域は、SharePoint で SPTrustedIdentityTokenIssuer を作成するときに再使用します。この例では、領域名を “urn:sharepoint:acs” とします。
      4. 戻り先 URL には、ADFS で SharePoint を証明書利用者として設定する場合と同じ形式 https://yourSiteName/_trust/を使用します。
      5. [Token format] ボックスでは [SAML 1.1] を選択します。
      6. [Token lifetime (secs)] には任意の値を設定できます。既定では 10 分です。ここでは 1 時間に相当する "3600" に設定しました。
    4. [Authentication Settings] セクションの項目を入力します。
      1. [Identity providers] の下の各チェック ボックスをオンにします。前述のステップで作成した ADFS ID プロバイダーが表示されます。
      2. [Rule groups] では、既定の [Create new rule group] チェック ボックスをオンにしておきます。
    5. [Token Signing Settings] では、既定のオプションである [Use service namespace certificate (standard)] が選択されたままにします。
    6. [Save] ボタンをクリックして変更を保存し、証明書利用者を作成します。

4.        証明書利用者のルールを作成する

  1.  
    1. ここでは、事前に ACS で一連のルールを作成していないものとして、新しいルール グループを作成します。再使用したいグループがある場合は、前述のステップで、既定の [Create new rule group] をオンにせずに、証明書利用者に使用するグループの横のチェック ボックスをオンにします。ただし、ここでは新しいルール グループを作成するので、左側のウィンドウの [Trust relationships] メニューで [Rule groups] リンクをクリックします。
    2. "Default Rule Group for whatever your relying party name was" というような名前を持つルール グループが表示されます。そのルール グループ名のリンクをクリックします。
    3. 実は、この時点で最も簡単な方法は、単に [Generate] リンクをクリックすることです。このリンクをクリックすると、各 ID プロバイダーから取得する要求を基本的にすべて列挙する一連のルールが自動的に作成された後、要求ごとにルールが作成され、そのルールに沿って要求の種類が同一であるその要求の値が証明書利用者に渡されます。
    4. [Generate Rules] ページで、各 ID プロバイダーの横のチェック ボックスをオンにして、[Generate] ボタンをクリックするだけです。これで、前述のとおりにルールが作成されます。完了すると、[Edit Rule Group] ページが自動的に表示され、そこにすべてのルールが示されます。ほとんどの場合は、これで十分ですが、ここでは説明する必要がある例外的なことが 1 つあります。SharePoint では、電子メール アドレスを ID 要求として使用します。皮肉にも、Windows Live を除くすべての ID プロバイダーが電子メール アドレスを送信します (そのために作成されたルールがあります)。そのため、さしあたり、この例では Windows Live の部分に修正を加えています。つまり、提供される 1 つの要求 nameidentifier を取得して、それを再び渡すルールを作成します。ただし、電子メール要求としてこの要求を再び渡します。Steve に文句を言っているわけではありません。これは、このデモ環境を最小限の可動パーツ (既にいくつかあります) で実行させる方法というだけのことです。では、この最後のルールを追加します。
    5. [Add link] をクリックします。
    6. [Identity Provider] ボックスで、[Windows Live ID] を選択します。
    7. [Input claim type] セクションで、[Select type] の横のラジオ ボタンをオンにします。Windows Live ID がサポートする要求の種類は 1 つのみなので、既に選択されています (nameidentifier)。
    8. [Output claim type] セクションまで下にスクロールして、[Select type] の横のラジオ ボタンをオンにします。
    9. ボックスで https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress を見つけて、選択します。
    10. 必要に応じて、説明を入力します。[Save] ボタンをクリックして変更を保存し、ルールを作成します。
    11. [Edit Rule Group] ページが自動的に表示されます。[Save] ボタンをクリックして、すべての変更を保存します。これで ACS の構成は終わりです。ただし、まだブラウザーを閉じないでください。他のコンポーネントを作成および構成する場合には、そこから追加情報を取得する必要があります。

5.        ADFS で ACS の証明書利用者を作成する

  1.  
    1. ADFS は ACS の ID プロバイダーである一方、ACS は ADFS の証明書利用者です。つまり、ACS が ADFS に認証要求をリダイレクトしたときに、信頼関係が確立されていて ADFS が応答できるように、ADFS で証明書利用者を構成する必要があります。まず、ADFS サーバーに移動し、AD FS 2.0 管理コンソールを開きます。
    2. [AD FS 2.0] … [Trust Relationships] … [Relying Party Trusts] ノードに移動し、右側のウィンドウで [Add Relying Party Trust…] リンクをクリックします。
    3. [Start] ボタンをクリックしてウィザードを開始します。
    4. オンラインで公開されている証明書利用者に関するデータをインポートする、という既定のオプションを使用します。使用する URL は、ACS 管理ポータルにあります。ポータルを表示しているブラウザーに戻り、左側のウィンドウの [Trust relationships] メニューの [Application Integration] リンクをクリックします。
    5. WS-Federation メタデータ用として表示される URL をコピーし、ADFS ウィザードの [Federation metadata address (host name or URL)] ボックスに貼り付けてから、[Next] ボタンをクリックします。
    6. [Display name] を入力し、必要に応じて [Notes] を入力してから、[Next] ボタンをクリックします。
    7. すべてのユーザーに証明書利用者へのアクセスを許可する、という既定のオプションのままにして、[Next] ボタンをクリックします。
    8. [Next] ボタンをクリックすると、証明書利用者が作成されます。
    9. 証明書利用者が作成されたら、ADFS でルール エディターを開き、要求の値を ACS に渡すための新しいルールを作成します。
    10. [Issuance Transform Rules] タブを選択し、[Add Rule…] ボタンをクリックします。
    11. [Send LDAP Attributes as Claims] の既定のテンプレートを選択したままにし、[Next] ボタンをクリックします。
    12. ルールの詳細のその他の情報を入力します。
      1. 要求ルールの名前を入力します。
      2. [Attribute store] ボックスで、[Active Directory] を選択します。
      3. [Mapping of LDAP attributes] セクションで、次のマッピングを指定します。
        1. [LDAP attribute] の [E-Mail-Addresses] から [Outgoing Claim Type] の [E-Mail-Addresses]
        2. [LDAP attribute] の [Token-Groups – Unqualified Names] から [Outgoing Claim Type] の [Role]
      4. [完了] (Finish) ボタンをクリックしてルールを保存します。これで、ADFS の構成は完了です。

6.        SharePoint と ACS との信頼関係を構成する

  1.  
    1. これは、ACS からトークン署名証明書を取得することから始めるマルチステップ プロセスです。幸い、この証明書は FederationMetadata.xml ファイルに含まれているので、そこから取得して、ローカルの SharePoint Server に保存します。SharePoint Server で、ブラウザーを開き、前述のとおりに [Access Control Management] ページを表示します。
    2. 左側のウィンドウの [Trust relationships] メニューの下の [Application Integration] リンクをクリックし、WS-Federation メタデータ用に表示される URL をコピーし、ブラウザーに貼り付けます。ACS の FederationMetadata.xml ファイルがブラウザーに表示されます。
    3. 次のようなセクションを見つけます (ページの上から 2 つ目の大きなセクションのあたりです)。

<RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="https://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:fed="https://docs.oasis-open.org/wsfed/federation/200706">

<KeyDescriptor use="signing">

<KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">

<X509Data>

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

 

X509Certificate 要素からデータをコピーし、メモ帳に貼り付けます。これを .CER ファイル拡張子で保存します (文字コードには ANSI を指定します)。この投稿では、このファイルを C:\AcsTokenSigning.cer と呼ぶことにします。これが、ACS のトークン署名証明書です。

  1.  
    1. ACS トークン署名証明書を SharePoint の信頼されたルート機関の一覧に追加します。この追加は、https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx (英語) の説明に従って行うか、次のような PowerShell を使用して行うことができます。

 

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")

New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert

 

  1.  
    1. 次に、新しい SPTrustedIdentityTokenIssuer を作成します。これについては、さまざまな場所で説明してきました。最初に https://blogs.msdn.com/b/sharepoint_jp/archive/2010/11/26/sharepoint-2010-adfs-v2.aspxを参照してください (ADFS の設定に関する説明の後の情報まで下にスクロールしてください)。覚えておくべき点は、次のとおりです。
      1. SharePoint では、name と nameidentifier の両方が予約された要求の種類です。そのため、ACS で nameidentifier が標準 ID プロバイダー間の唯一の共通する要求であっても、これは ID 要求のオプションではありません。今のところは、前述のように、電子メール アドレスに頼って、ACS で適切なルールを追加することをお勧めします。
      2. New-SPTrustedIdentityTokenIssuer の SignInUrl パラメーターは ACS インスタンスを指す必要があります。たとえば、https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation です。これを見つけるには、ADFS で ACS に設定した証明書利用者を調べます。[Relying Party properties] ダイアログ ボックスを開き、[エンドポイント] (Endpoints) タブをクリックして、[WS-Federation Passive Endpoint] に対して表示される URL を POST バインディングに使用します (1 つしか表示されません)。
    2. 最後に、Web アプリケーションを作成し、クレーム認証と、ACS に作成した SPTrustedIdentityTokenIssuer を使用するように構成して、Web アプリケーションにサイト コレクションを作成し、テストを開始します。

 

これで、サイトにアクセスし、試してみる準備ができました。ID プロバイダーのいずれかが返す電子メール アドレスの 1 つになるようにサイト コレクションの管理者を構成し、サイトにログインできるようにする必要があります。ログインすれば、通常のように、プロバイダーから SharePoint グループに電子メール アドレスまたはロール クレームを追加できます。

 

繰り返しますが、覚えておくべき重要な点は、さしあたり Windows Live ID です。この投稿で既に説明したように、実は Windows Live 用の有効な電子メール アドレスはないので、PUID というものを SharePoint グループに追加する必要があります。テストのために、これを取得する最も簡単な方法は、Windows Live ID を使用してログインすることです。SharePoint に、"foo" としてログインしていることを示すページが表示され、アクセスが拒否されます。ここから、PUID をコピーし、管理者ユーザーとしてログインして、PUID を SharePoint グループに追加できます。これで、準備完了です。どのような種類のディレクトリ オプションが Windows Live ID に使用可能かについては調べませんでした (おそらくディレクトリ オプションはないと思います)。しかし、まだこれからなので、この概念実証は進めることができます。では、完了したので、これらの各 ID プロバイダーを使用して私のサイトにログインするとどのように表示されるかを示します。

 

ログイン ページ

ADFS

 

Google

 

Yahoo

 

Windows Live ID

 

 

これはローカライズされたブログ投稿です。原文の記事は、「Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1」をご覧ください。