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 を基盤としてすべてのサービスに繋がる仕組みができます。これはのちに Microsoft Graph へと繋がっていきますが、SharePoint Online をはじめとした Microsoft のクラウド サービスの REST API は Azure AD にアプリを登録して、OAuth による認証/承認のプロセスを経ることになります。SharePoint はここにきてまったく同じ仕組み (OAuth) を持つ異なる認証/承認方法を持つようになってしまいます。
| 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