SharePoint 2013 における OAuth とユーザーのリハイドレート – その方法と必要な情報

原文の記事の投稿日: 2012 年 8 月 16 日 (木曜日)

最初に言わせてください。私が思い付いたままに SharePoint の知られざる機能をブログに書くことについて気に入っていることの 1 つに、このブログのタイトルのように完全にくだけた言葉を使用できるという点があります。これは、次期バージョンの SharePoint を作成しているなどでない限り、なかなか許されないことです。SharePoint 2013 で楽しく交わされるメッセージが思い浮かびますか? "待たせてごめん、もうすぐ終わる" などです。これがいっそう楽しいのは、先日友人の Tom が受け取った HRESULT のようなものが入り交じっているからでしょう。うわべが変わっても、本質は変わりません。

目下のトピックに入ります。このブログで SharePoint 2013 のいくつかの新機能について説明するときに、既に oAuth について何度か触れました。また、私はまだ "oAuth とは" について徹底的に掘り下げていませんが、ライター チーム全体が oAuth に取り組んでいるため、そのいくつかの使用方法についてほんの少しだけ、もう一度話を広げたいと思います。oAuth 信頼関係の最たる例として、検索のためのリモート SharePoint インデックスが挙げられます。これは、ファーム内の人物が別の SharePoint ファームにルーティングされるクエリを発行できるようにするもので、そのリモート SharePoint ファームでは、セキュリティによる検索結果のトリミングを適切に実行できるように、ユーザーの ID を再構築することができます。oAuth は、新しいアプリ モデルなどの他のシナリオ (アプリが要求するコンテンツへのアクセス権をこのユーザーが持っているか)、SharePoint と Exchange などのサーバー アプリケーション間 (メールボックス コンテンツに対する権限をこのユーザーが持っているか)、その他多くの場面でも使用されます。それでも、リモート SharePoint インデックスは、このすべてを想定どおりに機能させるためになぜその操作を実行する必要があるのかを想像するための最適なシナリオであると思うため、私にとっては良い例です。

それでは、まず「FarmA が FarmB の "Steve" を参照する "Steve を作成する" 方法」から始めましょう。すべて、ユーザー プロファイル アプリケーションから始めます。仮に、Steve が FarmB に存在し、クエリを発行するとします。そのクエリは FarmA に送信され、そのクエリと共に Steve に関するいくつかの属性も送信されます。既定では、これらの属性は Steve の SMTP アドレス、SIP アドレス、アカウント名、および名前 ID です。その要求を受け取った FarmA は、まず、ローカルのユーザー プロファイル アプリケーションでルックアップを行います。送信された Steve の値と一致するプロファイルを探します。このため、SharePoint 2013 では UPA が正常で読み込み済みであることが非常に重要であり、このブログでもその操作に関する記事 (https://blogs.msdn.com/b/sharepoint_jp/archive/2012/09/20/sharepoint-2013-ad-saml.aspx) を書いています。

さて、FarmA で Steve のユーザー プロファイルが見つかったら、そのプロファイルで何を実行できるでしょうか。答えは "状況次第" なので、組織でこの点について計画することが非常に重要です。その決定要因となるのは、使用する認証の種類です。以下で説明します。

• Windows クレーム – Windows クレームを使用する際、必要なのはほとんどの場合ユーザー プロファイルだけです。このプロファイルには、アカウント名と AD グループ メンバーシップが含まれています。"ほとんどの場合" と述べた意味は後ほど説明します。手短に言うと、Windows クレームを使用する場合はほぼ問題ありません。
• フォーム ベース認証クレーム – FBA を使用する場合は、知っておかなければならないことがいくつかあります。まず第一に、UPA にデータを読み込んで最新の状態に保つ必要があります。たまたま LDAP プロバイダーで FBA を使用しており、ディレクトリが実際には Windows Active Directory である場合は、何の問題もありません。先ほどリンクを示した投稿で説明した手順と同様の方法で、Active Directory へのプロファイル接続を作成し、FBA プロバイダーに関連付けることができます。ただし、ほとんどの場合、AD がプロバイダーではないでしょう。この場合は、UPA にデータを読み込むカスタム コードを記述する必要があります。FBA ユーザーの属性のうち本当に気にする必要がある唯一の属性であるアカウント名を取得するには、それで十分でしょう。ご存じのとおり、"ほとんどの場合" (繰り返しますが、後ほど説明します)、残りのデータはロール プロバイダーから取得されます。ここで本当に素晴らしいのは、FBA ユーザーをリハイドレートするときに、関連付けられたロール プロバイダーの呼び出しも行うので、ローカルにログオンしている FBA ユーザーのようになるということです。これにより、FBA ユーザーのすべてのロール クレームを取得できます。
• SAML クレーム – このケースは、まず UPA にデータを読み込む必要があるという点で FBA と似ています。運が良ければユーザーが AD に存在し、先ほどのリンク先のブログ投稿で示したガイダンスに従ってユーザーを直接インポートすることができます。運が悪ければ、ソース ディレクトリに接続してそこからインポートする必要があります。これはもちろん、SAML クレームに関して最も複雑な状況でしょう。ディレクトリは 1 つしか存在しないことも複数存在することもあり、そのすべてを所有していない可能性さえあるためです (たとえば、パートナーがいて、ACS とフェデレーションを行って Facebook または別のプロバイダーを使用する場合など)。いずれにせよ、このすべてを機能させるには、UPA にデータを読み込む必要があります。ただし、ここでもう 1 つの重要事項があります。SAML ユーザーとしてログインするときに、ID プロバイダー (IdP) から一連のクレームを取得するという点です。このユーザー リハイドレート プロセスでは、そのログインをシミュレートできません。これは SAML の性質にすぎず、1 回または複数回リダイレクトされて、(2 要素認証のように) 認証プロンプトと認証の種類を把握できないほどいくつも指定することになる可能性があります。つまり、このユーザー リハイドレート プロセスでクレームを使用してコンテンツをセキュリティで保護し、そのコンテンツへのアクセスを承認する場合は、クレーム拡張によってクレームを追加する必要があります。クレームが必要な場合、クレームをローカルで付与する場合に、リハイドレート時に IdP からクレームを取得することはなくなります。これが前述した "ほとんどの場合" で、以下で説明します。
• "ほとんどの場合" – この意味は、そろそろはっきりしてきたでしょう。Windows ユーザーであるか FBA ユーザーであるか SAML ユーザーであるかに関係なく、認証プロバイダーから取得するクレームに加え、拡張によって追加されたクレームを取得することができます (https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx (英語))。リハイドレート プロセス時には、登録されたすべてのカスタム クレーム プロバイダーの呼び出しも行い、リハイドレートするユーザーの追加のクレームも取得できるようにします。このクレームは、ローカルにログオンしてこのプロバイダーが呼び出されたとしたら受け取ったであろうクレームです。

こういうわけで、必要な計画について説明するにはリモート SharePoint インデックスのシナリオが最適だと思います。ご想像どおり、ファーム内では、Windows グループ、FBA ロール、SAML クレーム、または拡張によって追加されたクレームに基づいてコンテンツに対する権限を付与できます。コンテンツのクエリを行うときにこれらのクレームを処理しないと、コンテンツはセキュリティによってトリミングされ、表示されません。そのため、ローカルにログインするときにすべてのクレームが付与されること、また別バージョンの自分をリハイドレートするときにすべてのクレームが取得されることが、どれだけ重要かわかるでしょう。

このすべてを機能させるために考えられる計画は多数あるので、この投稿が主要な部分の特定に役立ち、何に重点を置くべきかがわかれば幸いです。

これはローカライズされたブログ投稿です。原文の記事は、「OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know」をご覧ください。