OAuth・Access token と 権限の昇格[オンライン]

2017/05/07

この記事は、SharePointアドインにおけるAccess tokenのOAuthによる送受信の流れと、権限の昇格法としてApp-only Access tokenを使用する方法について記載しています。

1.権限の昇格について

 

 通常、ユーザーがSharePoint上に実装した業務アプリケーションプログラムを実行する際に、そのプログラムの実行中の権限は、プログラムを起動したユーザー、つまり、SharePointのログインユーザーの権限で実行されます。

 そのため、プログラムがリスト/ドキュメントライブラリに対してアクセスする際、ログインユーザーがその処理に必要な適切なアクセス権を持っていない場合は、処理自体が失敗します。例えば、ログインユーザーが参照不可なリストをプログラムから参照しようとすると失敗します。

 

 UI機能を改善するようなプログラムの場合には、これでも問題はないのですが、業務アプリケーションの場合には、これが問題になる場合があります。

例として、

  • 処理において、作業者ユーザーには閲覧不可としているマスターリストを参照する。

  • 作業者ユーザーには更新不可としているリスト(閲覧履歴etc)を、更新する。

  • 通常は作業者ユーザーが削除できないアイテムについて、何らかの条件をクリアした後に削除する。

などが考えられます。これらの処理は業務アプリケーションでは一般的に行われるものです。

 

 オンプレミスのSharePointで業務アプリケーションを開発した場合、プログラムの実行中は、システムアカウント等の強い権限に移行して、この様な処理を実行することが可能です。これを「権限の昇格」と呼び、SharePointにおける業務アプリケーションでは多用されています。

 

 この処理について、セキュリティ上問題があるのではないかと思われがちですが、一般的なWebアプリケーションでも、バックエンドにデータベースを使用しマスターデータ/トランザクションデータを格納している場合には、データベースへの接続は相応の権限を有する単一ユーザーで行われる場合がほとんどです。つまり、データベースへの接続に際し「権限の昇格」が行われています。そのため、特にSharePointに限った特殊な処理ではありません。

 

 この「権限の昇格」は、オンプレミスでは以下の様に、SPSecurity.RunWithElevatedPrivilegesメソッドを使用して行って来ました。

 

 これと同様なことをSharePoint Online用のアドイン(アプリ)で行うには、どうすべきかなのでしょうか。


一般的に、以下の2つの方法が利用されています。

 

①バッチ処理で対応する。

 処理プログラムとしては、弊社の「アクセス権一覧出力」ツールで行っているのと同様な実装となります。

業務アプリケーションシステムにおいて、「権限の昇格」が必要となる部分について、別処理として切り出します。そして、この切り出した処理について、バッチプログラムとして作成し、夜間バッチ等で実行します。
 夜間バッチの実行に際し、必要な権限を有したアカウントのクレデンシャルをHost Webに渡します。このアカウントの権限で実行することによって、作業者ユーザーでは権限が不足するコンテンツに対しても処理を行うことができます。

 

しかし、当然のことながら、以下の短所があります。

  • バッチ処理のため、リアルタイムの処理とならない。
    利用ユーザーへの応答時間を早くする必要があれば、これが問題となります。応答速度を改善するために、バッチの実行間隔を短くする等の対応も考えられますが、限界があります。

  • アカウントのパスワードの有効期間。
    必要な権限を有したアカウントのクレデンシャルを渡しますが、SharePoint Onlineの場合、アカウントのパスワードには有効期限があって、定期的に変更する必要があります。パスワードの変更の都度、バッチプログラムのクレデンシャルの更新が必要となり、運用負荷および運用リスクが発生します。社内のActive Directoryと連携させる方法もありますが、常にその様な対応ができるとは限りません。

この様な短所が許容できる場合は、開発効率も高いため有効な方法です。

 

②「App-only Access token」を使用する。

「App-only Access token」という特殊なアクセストークンを使用する方法です。

SharePointアドインを特権状態で実行する方法として、SharePointアドイン(アプリ)が備える正規の方法となります。

 

以降、この「App-only Access token」について説明していきます。

2.OAuthによるAccess tokenの流れ

 

 「App-only Access token」について説明する前に、Host Webにおいて認証/許可に使用される通常の「Access token」の流れを記載します。

 

①Access tokenの流れ

 業務アプリケーションが、Provider Hosted AppのSharePointアドイン(アプリ)で作成された場合を考えます。この場合、プログラムの実行中に、Provider Hosted AppのRemote Web上のWebアプリケーションが、業務データが格納されているHost Web上のドキュメントライブラリ/リストを操作します。

 

 この操作に際し、Remote Web上のWebアプリケーションから、Host Webに対して「Access token」が渡されます。この「Access token」ですが、Windows Azure上の「Windows Azure ACS」から取得して渡します。これにはOAuthプロトコルが使用されます。

 

 完全な説明ではありませんが、概要は以下となります。

 

 

  1. Host Webから、Remote WebのWebアプリケーションに「Context token」が送信されます。

  2. Webアプリケーションは、「Context token」内から「Refresh token」を抽出します。次に、これをWindows Azure ACSに渡して「Access token」を要求します。

  3. Windows Azure ACSは「Refresh token」から、渡すべき「Access token」を検索し、これをWebアプリケーションに送信します。

  4. Webアプリケーションは、Host Webに「Access token」を渡して、Host Web内のコンテンツにアクセスします。

  5. Host Webは「Access token」内のアドイン(アプリ)を識別するクレームとユーザーを識別するクレームによりコンテンツへのアクセスの許可/不許可を決定し、許可となった場合は、コンテンツの内容をWebアプリケーションに返します。

以上が、利用ユーザーがWebアプリケーションを経由して、Host Webにアクセスした場合の「Access token」の流れとなります。

 

②「Access token」に格納されるIDとアクセス権

 このWindows Azure ACSから取得した「Access token」内のクレームには、

  • アドイン(アプリ)ID

  • ユーザーID

の2つのIDが含まれています。

Host Webがコンテンツへのアクセス許可/不許可を判断する際には、この2つのIDの組み合わせでアクセス権を決定します。

 

 「Access token」内の「アドイン(アプリ)ID」により、SharePointアドイン(アプリ)が識別されます。このアドイン(アプリ)がHost Webに対して実行可能なアクセス権については、開発元がアドイン(アプリ)の開発時に指定し、AppManifest.xmlに記載します。

Host Webへのアプリの登録時に、このアドイン(アプリ)が要求するアクセス権が表示され、登録を行う管理ユーザーによって許可されます。

 

 「Access token」内の「ユーザーID」により、現時点でアドイン(アプリ)を実行している利用者ユーザーが識別されます。利用者ユーザーのアクセス権は、SharePointの標準機能により、サイト内のコンテンツに対して付与されます。

 

 利用者ユーザーがSharePointアドイン(アプリ)を実行する際には、この「アドイン(アプリ)ID」で示されたアドイン(アプリ)のアクセス権と、「ユーザーID」により示されたユーザー自身の持っているアクセス権の両方が、Host Webにより使用されます。そして、プログラムが実行可能なアクセス権は、より厳しい条件のものへ決定されます。

例えば、アドイン(アプリ)が管理者により「フルコントロール」を許可されていても、ユーザー自身が「閲覧」の権限しか持っていない場合は、プログラムは「閲覧」の権限で実行されることになります。逆に、ユーザーが「フルコントロール」の権限を有していても、アドイン(アプリ)が「読み取り」しか許可されていない場合は、プログラムは「閲覧」の権限で実行されます。

 

 この様に、Host Webが、SharePointアドイン(アプリ)とユーザーの2段構えで判定してアクセス権を付与することから、SharePointアドイン(アプリ)のセキュリティは強固であると言うことができます。

(実際のところ、管理ユーザーがアプリを登録する際に、上記のダイアログからその意味を理解し)

 

 上記のOAuthによる「Access token」の取得と、Host Webへの送信をプログラムで実装するには、Visual Studio 2015が自動生成したSharePointContext.CreateUserClientContextForSPHostメソッドを使用し、Client Contextを取得することで簡単に行えます。そのため、通常は、プロトコルによるトークンの流れを意識することはありません。

3.App-only Access tokenの利用

 

①「App-only Access token」とアクセス権

 これに対し、「Acces token」を取得する際にTokenhelper.GetAppOnlyAccessTokenメソッドを使用した特殊な要求を行うと、「Windows Azure ACS」は「アドイン(アプリ)ID」のみを含み、「ユーザーID」クレームを含まない特殊な「Access token」を返してきます。

この「ユーザーID」を含まない「Access token」を、「App-only Access token」と呼んでいます。

 

「Access token」に「ユーザーID」含まない場合、Host Webはコンテンツへのアクセスを拒否するのではと思いますが、そうではなく、ユーザーのアクセス権は無視し、アドイン(アプリ)のアクセス権のみで、アクセス許可を決定します。つまり、アドイン(アプリ)が「フルコントロール」のアクセス権を要求し管理者がこれを許可すれば、アドイン(アプリ)はフルコントロールの権限で動作します。

 また、アドイン(アプリ)のアクセス権の範囲は、AppManifest.xmlにスコープとして記載しますが、これには、「テナント」「サイトコレクション」「Web」の様に、広い範囲での指定が可能となっています。このように、「App-only Access token」を使用することで権限を昇格して、作業者ユーザーより強いアクセス権、および、広い範囲でプログラムを実行することが可能となります。

 

では、具体的に「App-only Access token」の取得と、それを使用してClient Contextを取得する方法について記載したいと思います。

プログラム例として、

 Remote Event Receiver の望ましい実装 No.2[オンライン]

で記載した、リモートイベントレシーバーをもとに説明します。

 

①「App-only Access token」の使用を有効化する。

Visual Studio 2015にて、AppManifest.xmlに「App-only Access token」の使用を宣言します。

 

②「App-only Access token」を取得し、Client Contextを生成します。

「Windows Azure ACS」から「App-only Access token」を取得し、それを使用してClient Contextを生成します。

 

(1)Host Webから送信された「Context token」を取得します。

 

(2)「Context token」の有効性を検証します。

 

 

(3)「App-only Access token」を取得します。

 

(4)「App-only Access token」を使用して、Client Contextを生成します。

 

 

(5)全体としては、以下の様なコードとなります。

 

 

以上の様にして、「App-only Access token」を使用た権限の昇格を実現できます。

 

Share on Facebook
Share on Twitter
Please reload

RECENT POST
Please reload

Copyright© 2017  Aiprovide Corporation all Right Reserved.

  • Aiprovide Coroporation
  • Aiprovide Corporation