SharePoint Server の認証の概要

適用対象:2016 2019 Subscription Edition SharePoint in Microsoft 365

SharePoint Server では、以下の組み合わせで認証を必要とします。

• 社内 SharePoint リソースにアクセスするユーザー

• 社内 SharePoint リソースにアクセスするアプリケーション

• 社内 SharePoint リソースにアクセスする社内サーバー、またはその逆

Microsoft 365 での SharePoint 認証について説明します。

SharePoint Server におけるユーザー認証

ユーザー認証は、認証プロバイダーに対するユーザーの ID の検証です。これは、ユーザーの資格情報を含み、ユーザーが正しく送信したことを確認できるディレクトリまたはデータベースです。 ユーザー認証は、ユーザーが SharePoint リソースにアクセスしようとするときに行われます。

SharePoint Server は、クレームベース認証をサポートしています。

クレームベース認証の結果は、SharePoint Security Token Service (STS) が生成するクレームベースのセキュリティ トークンとなります。

SharePoint Server では、Windows、フォーム ベース、セキュリティ アサーション マークアップ言語 (SAML) と Open ID Connect (OIDC) ベースの要求認証がサポートされています。 Windows、フォーム ベース、SAML ベースの認証方法のしくみについては、次のビデオを参照してください。 OIDC 認証のしくみについては、「OIDC セットアップ ガイド」を参照してください。

SharePoint Server 2013 および 2016 における Windows クレーム認証のビデオ

SharePoint Server 2013 および 2016 におけるフォーム ベース クレーム認証のビデオ

SharePoint Server 2013 および 2016 における SAML ベース クレーム認証のビデオ

詳細については、「SharePoint Server でユーザー認証方法を計画する」を参照してください。

SharePoint Server におけるアプリ認証

アプリ認証は、リモート SharePoint アプリの ID と、アプリの承認と、セキュリティで保護された SharePoint リソース要求の関連ユーザーの検証です。 アプリ認証は、SharePoint ストア アプリまたはアプリ カタログ アプリの外部コンポーネント (イントラネットまたはインターネットに配置された Web サーバーなど) がセキュリティで保護された SharePoint リソースに対してアクセスを試みると発生します。

たとえば、ユーザーが SharePoint アプリの IFRAME を含む SharePoint ページを開き、ページをレンダリングするために、セキュリティで保護された SharePoint リソースにアクセスするために、IFRAME にイントラネット上のサーバーやインターネットなどの外部コンポーネントが必要であるとします。 SharePoint が要求された情報を提供し、アプリがユーザーのページをレンダリングできるように、SharePoint アプリの外部コンポーネントを認証および承認する必要があります。

SharePoint アプリがユーザーのページをレンダリングするために SharePoint セキュリティで保護されたリソースを必要としない場合、アプリ認証は必要ありません。 たとえば、天気予報情報を提供し、インターネット上の気象情報サーバーにのみアクセスする必要がある SharePoint アプリでは、アプリ認証を使用する必要はありません。

アプリケーション認証は、以下の 2 つの過程の組み合わせです。

• 認証

  アプリケーションが、一般的に信頼できる ID ブローカーに適切に登録されたことを確認します

• 承認

  アプリケーションと要求について関連付けられたユーザーが、フォルダーまたはリストにアクセスする、またはクエリを実行するといった処理を実行する、適切な権限を持っていることを確認します

アプリ認証を実行するために、アプリケーションは、Microsoft Azure Access Control Service (ACS) からアクセス トークンを取得するか、SharePoint Server が信頼する証明書を使用してアクセス トークンを自己署名します。 アクセス トークンは、特定の SharePoint リソースへのアクセス要求をアサートし、ユーザーの資格情報の検証ではなく、アプリと関連付けられているユーザーを識別する情報を含みます。 アクセス トークンはサインイン トークンではありません。

SharePoint ストア アプリでの認証過程の例は、以下のようになります。

1. ユーザーは、インターネット上でホストされ、ACS を信頼ブローカーとして使用する SharePoint ストア アプリによってレンダリングする必要がある IFRAME を含む SharePoint Web ページを開きます。 ユーザーの IFRAME をレンダリングするには、SharePoint ストア アプリが SharePoint リソースにアクセスする必要があります。

2. SharePoint STS は、ACS からコンテキスト トークンを要求して、それを受信します。

3. SharePoint は、コンテキスト トークンと共に、要求された Web ページを、ユーザーの Web ブラウザーに送信します。

4. ユーザーの Web ブラウザーは、インターネット上の SharePoint ストア アプリケーション サーバーに、IFRAME のコンテンツの要求とコンテキスト トークンを送信します。

5. SharePoint ストア アプリケーション サーバーは、ACS からアクセス トークンを要求して、それを受信します。

6. SharePoint ストア アプリケーション サーバーは、SharePoint リソース要求およびアクセス トークンを SharePoint サーバーに送信します。

7. SharePoint サーバーは、アプリケーションのインストール時に指定されたアプリケーションのアクセス許可と、関連するユーザーのアクセス許可の両方を確認して、アクセスを承認します。

8. 許可された場合、SharePoint は、インターネット上の SharePoint ストア アプリケーション サーバーに、要求されたデータを送信します。

9. インターネット上の SharePoint ストア アプリケーション サーバーは、Web ブラウザーに、IFRAME 結果を送信します。Web ブラウザーは、ユーザーに対してページの IFRAME 部分を表示します。

ここでは、ユーザーの資格情報を入手する必要なしに、SharePoint ストア アプリケーションが、SharePoint サーバー リソースにアクセスできたことに注意してください。 アクセスは、SharePoint Server を実行中のサーバーに信頼された ACS により認証され、アプリケーションとユーザー権限のセットにより承認されました。

SharePoint アプリ カタログ アプリでの認証過程の例は、以下のようになります。

1. ユーザーは、イントラネットでホストされ、アクセス トークンに自己署名証明書を使用するアプリ カタログ アプリによってレンダリングされる必要がある IFRAME を含む SharePoint Web ページを開きます。 ユーザーの IFRAME をレンダリングするには、アプリ カタログ アプリが SharePoint リソースにアクセスする必要があります。

2. SharePoint は、ユーザーの Web ブラウザーに、IFRAME と共に要求されたページを送信します。

3. ユーザーの Web ブラウザーは、イントラネット上のアプリ カタログ アプリケーション サーバーに、IFRAME のコンテンツの要求を送信します。

4. アプリ カタログ アプリケーション サーバーはユーザーを認証して、その自己署名証明書で署名済みのアクセス トークンを生成します。

5. アプリ カタログ アプリケーション サーバーは、SharePoint リソース要求およびアクセス トークンを SharePoint サーバーに送信します。

6. SharePoint サーバーは、アプリケーションのインストール時に指定されたアプリケーションのアクセス許可と、関連するユーザーのアクセス許可の両方を確認して、アクセスを承認します。

7. 許可された場合、SharePoint サーバーは、イントラネット上のアプリ カタログ アプリケーション サーバーに、要求されたデータを送信します。

8. アプリ カタログ アプリケーション サーバーは、Web ブラウザーに、IFRAME 結果を送信します。Web ブラウザーは、ユーザーに対してページの IFRAME 部分を表示します。

詳細については、「SharePoint Server でアプリ認証を計画する」を参照してください。

SharePoint Server におけるサーバー間認証

サーバー間認証とは、SharePoint Server を実行するサーバーの STS と、SharePoint Server、Exchange Server 2016、Skype for Business 2016、Azure Workflow Service を実行するオンプレミスなどの OAuth サーバー間プロトコルをサポートする別のサーバーの STS との間に確立された信頼関係に基づく、サーバーのリソースに対する要求の検証です。 Microsoft 365 で実行されている SharePoint Server。 この信頼関係に基づいて、要求元サーバーは、サーバーとユーザーのアクセス許可に従って、指定されたユーザー アカウントに代わって SharePoint サーバー上のセキュリティで保護されたリソースにアクセスできます。

たとえば、Exchange Server 2016を実行中のサーバーは、特定のユーザー アカウントについて SharePoint Server を実行中のサーバー リソースを要求できます。 このプロビジョニングは、アプリがユーザー アカウントの資格情報にアクセスできないアプリ認証とは対照的です。 サービスと要求によって、そのサーバーがリソース要求をしているかどうかにかかわらず、ユーザーはそのサーバーにサインインできます。

SharePoint Server を実行しているサーバーがサーバー上のリソースにアクセスしようとするとき、またはサーバーが SharePoint Server を実行しているサーバー上のリソースにアクセスしようとすると、受信アクセス要求が認証され、サーバーが受信アクセス要求とその後のデータを受け入れるようにする必要があります。 サーバー間認証では、SharePoint Server を実行しているサーバーと、それを表すユーザーが信頼されていることを確認します。

サーバー間認証に使用されるトークンは、サインイン トークンではなく、サーバー間トークンです。 サーバー間トークンには、アクセスを要求しているサーバーと、サーバーを操作しているユーザー アカウントの情報が含まれます。

社内サーバーでは、基本的な過程の例は以下のとおりです。

1. 他のサーバーからの情報を必要とする SharePoint Web ページをユーザーが開きます (たとえば、SharePoint Server および Exchange Server 2016 の両方のタスクの一覧を表示)。

2. SharePoint Server が、サーバー間トークンを生成します。

3. SharePoint Server が、別のサーバーにサーバー間トークンを送信します。

4. 別のサーバーが SharePoint サーバー間トークンを検証します。

5. 別のサーバーは、送信されたサーバー間トークンが有効であったことを示す目的で、SharePoint Server にメッセージを送信します。

6. SharePoint Server を実行中のサーバー上のサービスは、サーバー上のデータにアクセスします。

7. SharePoint Server を実行中のサーバー上のサービスは、ユーザーにページを表示します。

両方のサーバーが Microsoft 365 を実行中の場合、過程の例は以下のようになります。

1. ユーザーが別のサーバーからの情報を必要とするSharePoint Webページを開きます（たとえば、SharePointとExchange Onlineの両方からのタスクのリストの表示）。

2. SharePoin tは、ACS からサーバー間トークンを要求して受信します。

3. SharePoint はサーバー間トークンを Microsoft 365 サーバーに送信します。

4. Microsoft 365 サーバーは、ACS によりサーバー間トークンでユーザー ID を確認します。

5. Microsoft 365 サーバーはメッセージを SharePoint に送信して、送信されたサーバー間トークンが有効であることを示します。

6. SharePoint のサービスは、Microsoft 365 サーバーのデータにアクセスします。

7. SharePoint のサービスは、ユーザーにページを表示します。

詳細については、「SharePoint Server でサーバー間認証を計画する」を参照してください。