SharePoint を使ったバッチ プログラムの認証/承認がなぜこんなにややこしいのか考えてみる
はじめに
SharePoint を使ったバッチ プログラムはさまざまなものがあります。簡単なものでは手元で実行するデータ投入ツールであったり、複雑なものでは Azure Functions や Azure Automation を使って実行する場合もあります。いずれの場合も、こうした無人化されたプログラムでの認証や承認は避けて通れない問題です。SharePoint はオンプレミスからクラウドへと進化し続けてきた製品であり、その過程でさまざまな試行錯誤がありました。結果として互換性の観点から複雑になってしまっています。大げさにはなりますが、歴史を振り返ることで、現在のベストな方法について考えてみます。
クラウド以前
SharePoint Online が広まる以前、オンプレミスの SharePoint が全盛期だった時代には、バッチ プログラムは SharePoint サーバー内で動かすのが基本でした。SharePoint サーバー オブジェクト モデル (Microsoft.SharePoint.dll) を使い、ファーム アカウントで動作させることで、バッチ プログラムを非常に強い権限で動作させることができました。また、SharePoint 2010 からはクライアント オブジェクト モデル (Microsoft.SharePoint.Client.dll) が登場し、外部サーバーから SharePoint を操作できるようになりましたが、ほとんどの場合は NTLM 認証で十分だったため、ファーム アカウント (またはそれに近い強い権限を持つアカウント) のユーザー名とパスワードでログインしていました。
クラウド転換期
SharePoint 2013 からは、それまでのファーム ソリューション開発やサンドボックス ソリューション開発に代わる新しい開発手法として、SharePoint アドイン (当時は SharePoint アプリと呼ばれていました) が登場しました。SharePoint アドインの特徴は、アプリを SharePoint に登録することで、アプリに必要なアクセス許可を指定できる点です。これまでは アプリ自体に何をさせることができるか を指定できなかったため、悪意のある操作も可能でした。SharePoint アドイン モデルを採用することで、アプリを制限された権限の範囲内で動作させることが可能になりました。SharePoint アドインの認証や承認には Azure ACS を使った OAuth の仕組みが取り入れられています。そのため、SharePoint Server でも SharePoint Online でも同じように動作させることができました。同じく SharePoint 2013 から導入された REST API と組み合わせることで、これまで .NET でしか開発できなかったバッチ プログラムを他の言語でも開発できるようになりました。また、ユーザーがアプリに動作を委任するのではなく、アプリそのものがサービス アカウントとして動作する仕組み (Client Credentials Grant) も登場しました。
一方でクライアント オブジェクト モデルも進化を続けました。SharePoint Online に対応するため SharePointOnlineCredentials (WS-Security) による認証が導入され、ほぼ NTLM 認証と同じ感覚で開発できるようになりました。
クラウド全盛期
Azure の発展や Office 365 によるサービスのクラウド化が進む中で、すべてがクラウドへ という動きが加速しました。SharePoint もクラウド ファーストの考え方が取り入れられます。SharePoint Server は SharePoint Online の過去バージョンをパッケージ化したものです。新しい機能は SharePoint Online のみに追加されるようになりました。Microsoft のクラウド サービス間の連携が進み、Azure AD を基盤としてすべてのサービスに接続する仕組みができました。SharePoint Online をはじめとした Microsoft のクラウド サービスの REST API は Azure AD にアプリを登録し認証する必要があります。これは後に Microsoft Graph へとつながっていきます。
SharePoint はここでまったく同じ仕組み (OAuth) を持つ異なる認証や承認方法を持つようになりました。
- SharePoint アドイン モデル
- Azure AD
| SharePoint アドイン モデル | Azure AD | |
|---|---|---|
| SharePoint Server | 動作する | 動作しない |
| SharePoint Online | 動作する | 動作する |
| 他サービス連携 | 動作しない | 動作する |
SharePoint Server が存在する以上、互換性のために SharePoint アドイン モデルによる OAuth をやめることはできません。Azure ACS は廃止されましたが、SharePoint アドイン モデルによる OAuth は残っています。SharePoint Online でバッチ プログラムを動かす場合、SharePoint アドインとしても、Azure AD のアプリとしても動作できます。現時点ではどちらも有効な方法です。
クライアント オブジェクト モデルには .NET Core の波が押し寄せました。長らくクライアント オブジェクト モデルは .NET Standard に対応していませんでしたが、ついに .NET Standard に対応したライブラリが登場しました。その際、もはや古い手法でありセキュリティにも問題がある SharePointOnlineCredentials は切り捨てられています。今後、SharePointOnlineCredentials は使えなくなる流れと考えてよいでしょう。
おわりに
現時点で、SharePoint Online のバッチ プログラムを開発する際は、SharePoint アドイン モデルと Azure AD のどちらの認証や承認を使っても問題ありません。ただし、SharePoint アドイン モデルはサポートされているものの、すでに開発方法が古く、今後予告なく無効化される可能性も否定できません。また、SharePoint Online では Azure AD のクライアント シークレットを使った Client Credentials Grant がサポートされていません。そのためクライアント証明書を使うことが必須です。クライアント シークレットを使うほうが手軽なため、上記のリスクを理解したうえで、SharePoint アドイン モデルによる OAuth を使うという選択肢も考えられます。
Discussion