SharePoint Server でアプリ認証を計画する
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
アプリ認証とは、セキュリティで保護されている SharePoint リソースに対してアプリからアクセスが要求されたときに、外部 SharePoint 用アプリの ID を検証し、アプリとそのアプリに関連付けられているユーザーを認証する処理です。 アプリ認証は、SharePoint ストア アプリまたはアプリ カタログ アプリの外部コンポーネント (イントラネットまたはインターネットに配置された Web サーバーなど) がセキュリティで保護された SharePoint リソースに対してアクセスを試みると発生します。 たとえば、Microsoft Azure で実行されるコンポーネントを含む SharePoint 用アプリは外部アプリです。 アプリ認証では、アプリが処理してユーザーに表示する結果に SharePoint リソースからのデータを取り込めるようにして、一連の新しい機能と達成可能なシナリオが有効になります。
SharePoint 用アプリ から要求されたリソースを提供するために、SharePoint Server を実行するサーバーは、次の操作を行う必要があります。
要求元アプリが信頼できるアプリであることを確認します。
要求元アプリを認証するには、SharePoint Server を実行するサーバーに要求を送信しているアプリを信頼するようにそのサーバーを構成する必要があります。 これは一方向の信頼関係です。
アプリが要求しているアクセスの種類が承認されていることを確認します。
SharePoint Server はアクセスを承認するうえで、アプリの一連のアクセス許可 (アプリのインストール時にアプリ マニフェスト ファイルに指定されたアクセス許可) と、アプリが代わりになっているユーザーに関連付けられているアクセス許可に依存します。 SharePoint Server は、 Set-SPAppPrincipalPermission PowerShell コマンドレットを使用して信頼が確立されたときに SPAppPrincipal に付与されたアクセス許可にも依存します。
SharePoint Server のアプリ認証はユーザー認証とは異なり、サインイン認証プロトコルとして SharePoint ユーザーに使用されることはありません。 アプリ認証で使用するのは 「OAuth 2.0」で、一連のユーザー認証またはサインオン プロトコル (WS-Federation など) に追加されません。 SharePoint Server には新しいユーザー認証プロトコルはありません。 アプリ認証と OAuth は ID プロバイダーのリストに表示されません。
概要
アプリ認証の計画では、次の作業を行います。
SharePoint リソースを要求する外部アプリに相当する SharePoint Server を実行するファームに構成する必要がある一連の信頼関係を識別します。
インターネットでホストされる外部アプリケーションからの受信アクセスを提供します。
重要
アプリ認証エンドポイント (SharePoint 用アプリによる受信要求用) を含む Web アプリケーションは、Secure Sockets Layer (SSL) を使用するように構成する必要があります。 SharePoint Server で OAuth を構成して、SSL を必要としないようにすることができます。 ただし、これは、構成を容易にするため、またはアプリ開発環境を作成するために、評価にのみお勧めします。
注:
SharePoint リソースを要求する外部 SharePoint 用アプリを複数使用する場合に限り、SharePoint ファームでのアプリ認証を計画する必要があります。
信頼関係のセットを特定する
次の種類の外部アプリが送信するリソース要求に相当するアクセス トークンを信頼するように SharePoint ファームを構成する必要があります。
プロバイダーによってホストされるアプリは、インターネットまたはイントラネットの独自のサーバーで実行され、Microsoft Azure に登録され、ACS を使用してアクセス トークンを取得します。
プロバイダーによってホストされるアプリの場合、プロバイダーによってホストされるアプリの ACS インスタンスを信頼するように SharePoint ファームを構成する必要があります。
高信頼アプリは、イントラネットのスタンドアロン サーバーで実行され、アプリが生成するセキュリティ トークンに署名証明書を使用してデジタル署名します。
高信頼アプリは、サーバー間プロトコルを使用して、ユーザーの代理としてリソースを要求します。 高信頼アプリの場合、SharePoint ファームは、アプリをホストするサーバーの JavaScript Object Notation (JSON) メタデータ エンドポイントで構成します。 また、信頼を手動で構成することもできます。 詳細については、「SharePoint Server でアプリ認証を構成する」を参照してください。
高信頼アプリの詳細については、「[方法] サーバー間プロトコルを使用して SharePoint 2013 の高信頼性アプリを作成する」を参照してください。
社内アプリ用のユーザー認証を選択する
オンプレミスのアプリは、オンプレミスのサーバーでプロバイダーによってホストされているアプリか、SharePoint でホストされているアプリのどちらかです。 表 1 は、SharePoint Server のユーザー認証の方法と、その方法を SharePoint Server のオンプレミス アプリで使用できるかどうかを示しています。
表 1. ユーザー認証方法と、社内アプリによるサポート状況
| 認証方法 | SharePoint にホストされているアプリによってサポートされるかどうか | プロバイダーによってホストされるアプリのサポート |
|---|---|---|
| NTLM |
はい |
はい |
| Kerberos |
はい。ただし、フォールバック認証方法として NTLM を使用するように構成されている場合のみです。 Kerberos のみはサポートされていません。 |
はい |
| 基本 |
はい |
はい |
| 匿名 |
はい |
はい |
| 既定の ASP.NET プロバイダーを使用したフォームベース認証 |
はい |
はい |
| ライトウェイト ディレクトリ アクセス プロトコル (LDAP) を使用したフォームベース認証 |
はい |
はい |
| Security Assertion Markup Language (SAML) 認証 |
はい。ID プロバイダーがワイルドカード戻り均一リソース ロケーター (URL) 登録をサポートし、 wreply パラメーターを 受け取る場合。 . wreply パラメーターを使用するように SharePoint Server を構成するには、Microsoft PowerShell コマンド プロンプトで次のコマンドを使用します。 $p = Get-SPTrustedIdentityTokenIssuer$p.UseWReplyParameter = $true$p.Update()>[!注]> Active Directory フェデレーション サービス (AD FS) (AD FS) 2.0 バージョンでは、戻り URL 登録のワイルドカードはサポートされていません。 |
はい |
SharePoint Server でのユーザー認証方法の詳細については、「SharePoint Server でユーザー認証方法を計画する」を参照してください。
インターネットでホストされる外部アプリケーションからの受信アクセスを提供する
プロバイダーによってホストされる外部のアプリがインターネットに配置されている場合は、アプリ認証を実行してイントラネットの SharePoint ファームにリソースを要求するようにリバース Web プロキシを構成する必要があります。 ネットワークのエッジでそのように構成されたリバース Web プロキシは、アプリから SharePoint ファームへの受信 HTTP over SSL (HTTPS) 接続を許可する必要があります。 通常、外部アプリケーションがアクセスする HTTPS ベースの URL を識別し、これらの URL を公開するようにリバース プロキシを構成して、適切なセキュリティを提供します。
ユーザー プロファイル アプリケーション サービスの課題に対処する
信頼の高いアプリは、独自のアクセス トークンを生成します。これには、ユーザーの代わりに動作しているユーザーの ID のアサーションが含まれます。 SharePoint Server を実行し、受信リソース要求を処理するサーバーは、特定の SharePoint ユーザー (ユーザーの ID のリハイドレートと呼ばれるプロセス) に要求を解決できる必要があります。 これは、プロバイダーでホストされているアプリのアプリ認証とは異なり、ユーザーは識別されますが、アサートされていないことに注意してください。
ユーザーの ID をリハイドレートするために、SharePoint Server が実行されるサーバーが受信アクセス トークンから要求を取得して、その要求を特定の SharePoint ユーザーに解決します。 SharePoint Server では、既定で組み込みの User Profile Service アプリケーションを ID リゾルバーとして使用します。
ユーザー ID のリハイドレートの主要なユーザー属性は、次のとおりです。
Windows セキュリティ識別子 (SID)
Active Directory ドメイン サービス (AD DS) ユーザー プリンシパル名 (UPN)
簡易メール転送プロトコル (SMTP) アドレス
セッション開始プロトコル (SIP) アドレス
したがって、アプリには上記のユーザー属性が少なくとも 1 つ含まれている必要があり、その属性はユーザー プロファイルで最新のものである必要があります。 ID ストアから User Profile Service アプリケーションへの定期的な同期をお勧めします。
さらに、SharePoint Server では、これらの 4 つの属性のうちの 1 つ以上に基づく特定の参照クエリに対して、ユーザー プロファイル サービス アプリケーション内のエントリが 1 つだけ必要です。 そうでない場合、複数のユーザー プロファイルが検出されたというエラー状態を返します。 そのため、複数のユーザー プロファイルを回避するには、ユーザー プロファイル サービス アプリケーションで古いユーザー プロファイルを定期的に削除する必要があります。
ユーザーのユーザー プロファイルが存在し、関連するグループ メンバーシップが同期されていない場合、そのユーザーに特定のリソースへのアクセスを付与する必要があるにもかかわらず、アクセスが拒否されることがあります。 したがって、グループ メンバーシップが User Profile Service アプリケーションと同期していることを確認してください。