SharePoint アドインの 3 つの承認システムThree authorization systems for SharePoint Add-ins

SharePointでは、SharePoint アドインはユーザーと同様のIDプリンシパルであり、SharePointリソースを使用するために認証され、承認されている必要があります。In SharePoint, a SharePoint Add-in is an identity principal just like a user and it must be authenticated and authorized to use SharePoint resources. There are three authorization systems that an add-in can use. They are not mutually exclusive. アドインで使用できる認証システムは3つあります。There are three authorization systems that an add-in can use. これらは相互に排他的ではありません。They are not mutually exclusive.

3 つの認証システムとそれらを使用するタイミングについてUnderstand the three authorization systems and when to use them

低信頼Low-trust authorization

プロバイダ向けのホスト型 SharePoint アドインは、アドインがインストールされる SharePoint テナンシーまたはファームのリソースへアドインがアクセスできるようにするため、アドインに対してアクセス トークンを発行するMicrosoft Azure Access Control Service(ACS)に登録できます。Low-Trust: A provider-hosted SharePoint Add-in can register with Microsoft Azure Access Control Service (ACS) which issues an access token to the add-in that allows the add-in access to the resources in the SharePoint tenancy or farm on which the add-in is installed. Azure ACS is the trusted token issuer in an OAuth 2.0 Framework "flow" that includes SharePoint and the remote components of the add-in. Add-ins that use this system can be sold in the Office Store. The low-trust system is primarily intended for add-ins whose remote components are hosted in the cloud. Azure ACSは、SharePointとアドインのリモートコンポーネントを含むOAuth 2.0 Frameworkの「フロー」における信頼できるトークン発行者です。Azure ACS is the trusted token issuer in an OAuth 2.0 Framework "flow" that includes SharePoint and the remote components of the add-in. このシステムを使用するアドインは、Officeストアで販売することができます。Add-ins that use this system can be sold in the Office Store. 低信頼のシステムは主に、クラウド内でリモートコンポーネントがホストされているアドインを対象としています。The low-trust system is primarily intended for add-ins whose remote components are hosted in the cloud.

重要

Azure Active Directory (Azure AD) のサービスである Azure Access Control (ACS) は、2018 年 11 月 7 日に廃止されます。Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. SharePoint アドイン モデルでは、(この廃止の影響を受けない) https://accounts.accesscontrol.windows.net ホスト名を使用しているため、この廃止による影響はありません。This retirement does not impact the SharePoint Add-in model, which uses the https://accounts.accesscontrol.windows.net hostname (which is not impacted by this retirement). 詳細については、「SharePoint アドインに対する Azure Access Control 終了の影響」を参照してください。For more information, see Impact of Azure Access Control retirement for SharePoint Add-ins.

低信頼システムを使用する SharePoint アドイン の作成の詳細については、「 低信頼承認を使用する SharePoint アドインの作成」を参照してください。For more information about creating a SharePoint Add-in that uses the low-trust system, see the SDK node Creating SharePoint Add-ins that use low-trust authorization.

注意

アドインをインストールする顧客は、Office 365 アカウントを持っている必要があります。The customer who installs the add-in must have an Office 365 account. これは、Azure ACSへのアドイン アクセス権を与えるために必要です。This is needed to give the add-in access to Azure ACS. ただし、顧客は他の目的でアカウントを使用する必要はなく、ファーム上の簡単な構成タスクの後にアドインを内部設置型の SharePoint ファームにインストールすることもできます。Note The customer who installs the add-in must have an Office 365 account. This is needed to give the add-in access to the Azure ACS. However, the customer need not use the account for any other purpose, and the add-in can be installed to an on-premise SharePoint farm after some simple configuration tasks on the farm.

高信頼High-trust authorization

プロバイダ向けホスト型アドインは、デジタル証明書を使用してSharePointとの信頼関係を確立できます。A provider-hosted add-in can establish trust with SharePoint by using digital certificates. 高信頼システムは主に、リモートコンポーネントが内部設置型でホストされるアドインを対象としています。The high-trust system is primarily intended for add-ins whose remote components are hosted on-premises. アドインは、インターネットに接続されていない SharePoint ファームにインストールできます。The add-in can be installed to a SharePoint farm that is not connected to the Internet. アドインは、SharePoint Online にインストールすることも、Office ストアで販売することもできません。The add-in cannot be installed on SharePoint Online or sold in the Office Store.

高信頼システムを使用する SharePoint アドイン の作成の詳細については、「 高信頼認証システムを使用する SharePoint アドインを作成する」を参照してください。For more information about creating a SharePoint Add-in that uses the high-trust system, see the SDK node Creating SharePoint Add-ins that use high-trust authorization.

クロスドメイン ライブラリCross-domain library

アドインのビジネスロジックが JavaScript にある場合、低信頼システムおよび高信頼システムの代わりに、またはその補足として SharePoint クロスドメイン ライブラリを使用するオプションがあります。When the add-in's business logic is in JavaScript, you have the option of using the SharePoint cross-domain library either in place of, or as a supplement to, the low-trust and high-trust systems. ライブラリは、アドインにクラウド ホスト型コンポーネントがあるものの、お客様の企業ファイアーウォールが低信頼システムの使用を困難にしているようなシナリオも対象としています。The library is also intended for scenarios where the add-in has cloud-hosted components, but the customer's corporate firewall makes it difficult to use the low-trust system. ユーザーのブラウザは他のドメインからのスクリプトをブロックしますが、JavaScriptライブラリはこの制限を回避するための安全なシステムをカプセル化します。The user's browser blocks scripts from other domains, but the library encapsulates a secure system for working around this restriction. ライブラリを使用するアドインは Office ストアで販売することができますし、SharePoint Online または内部設置型のSharePoint にインストールすることもできます。Add-ins that use the library can be sold in the Office Store and can be installed to either SharePoint Online or on-premises SharePoint.

クロスドメイン ライブラリを使用する SharePoint アドインの作成の詳細については、以下を参照してください。For more information about creating a SharePoint Add-in that uses the cross-domain library, see:

OAuth 2.0 フレームワークとその SharePoint 実装に関する背景情報Background information about the OAuth 2.0 Framework and the SharePoint implementation of it

3つの認証システムのうち2つがOAuth 2.0 Frameworkを使用しています。Two of the three authorization systems use the OAuth 2.0 Framework. OAuth 2.0は 承認用のオープン フレームワークです。OAuth 2.0 is an open framework for authorization. OAuthはを使用することで、デスクトップ アプリケーション、デバイス アプリケーション、および Web アプリケーションから、セキュリティーで保護された認証を標準的な方法で行うことができるようになります。OAuth enables secure authorization from desktop, device, and web applications in a standard way. またOAuthを使用することで、ユーザーはユーザ名とパスワードを共有しなくても、アプリケーションがユーザーの代わりに動作することを承認できます。OAuth enables a user to approve an application to act on his or her behalf without sharing his or her user name and password.

たとえば、** ユーザーは他のサイトへ自分の資格情報(通常はユーザー名とパスワード)を提供する必要なしに** 、自分のプライベート リソースやデータ(連絡先リスト、ドキュメント、写真、動画など)をあるサイトと別のあるサイトで** 共有することができます** 。Two of the three authorization systems, use the OAuth 2.0 Framework. OAuth 2.0 is an open framework for authorization. OAuth enables secure authorization from desktop, device, and web applications in a standard way. OAuth enables a user to approve an application to act on his or her behalf without sharing his or her user name and password. For example, it enables a user to share his or her private resources or data (contact list, documents, photos, videos and so on) on one site with another site, without requiring the user to provide his or her credentials (typically user name and password) to the other site.

OAuthを使用すると、ユーザーは特定のサービス プロバイダ(SharePointなど)によってホストされているデータに、アクセストークンを提供できます。OAuth enables users to provide access tokens to data that is hosted by a given service provider (such as SharePoint). 各トークンは、特定のリソースプロバイダ(SharePoint Webサイトなど)に対し、特定のリソース(たとえば、SharePoint ドキュメントライブラリ内のドキュメント)に、定められた期間(たとえば12時間)アクセスすることを許可します。Each token grants access to a specific resource provider (such as a SharePoint website), for specific resources (for example, documents in a SharePoint document library), and for a defined duration (for example, 12 hours). これにより、ユーザーはサードパーティの Web アプリケーションやデスクトップ アプリケーションが、他のリソースやサービス プロバイダー(SharePointなど)に保存された情報にアクセスできるようにし、またこれによって自分のユーザー名やパスワードを共有したり、またプロバイダーに提供している* すべての* 情報を共有することもありません。OAuth enables users to provide access tokens to data that is hosted by a given service provider (such as SharePoint). Each token grants access to a specific resource provider (such as a SharePoint website), for specific resources (for example, documents in a SharePoint document library), and for a defined duration (for example, 12 hours). This enables a user to grant a third-party web or desktop application access to information that is stored with another resource or service provider (such as SharePoint), and to do so without sharing his or her user name and password and without sharing all the data that he or she has with the provider.

SharePointは ** OAuth 2.0 ** フレームワーク ** トークン 受け渡し”フロー” ** を使用して、次の処理を行います。SharePoint uses the OAuth 2.0 framework uses token passing "flows" to:

  • SharePoint リソースにアクセスするための SharePoint アドインによる要求を承認します。Authorize requests by a SharePoint Add-in to access SharePoint resources.

  • Office ストア、アドイン カタログ、または開発者テナントでアドインを認証します。Authenticate add-ins in the Office Store, an add-in catalog, or a developer tenant.

OAuthとOAuthの用語の詳細と背景については、 OAuth.net および Web 認証プロトコル(OAuth)を参照してください。For more information and background about OAuth and OAuth terminology, see OAuth.net and Web Authorization Protocol (oauth).

要約すると、保護されたリソースをホストするリソース サーバー、リソースの所有者、リソースへのアクセスを求めるクライアント アプリケーション、そしてリソース所有者から指示されたときにリソースへのアクセス トークンを発行する承認サーバーが存在します。In sum, there is a resource server that hosts a protected resource, an owner of the resource, a client application that seeks access to the resource, and an authorization server that issues access tokens to the resource when instructed to by the resource owner.

OAuthの公式ドキュメントでは、クライアントアプリケーションが実行されるたびに、クライアントアプリケーションからリソースへのアクセスを許可する単一のリソース所有者が存在するというシナリオが想定される傾向があります。The official OAuth documentation tends to assume a scenario in which there is a single resource owner who grants access to the resource from the client application each time the client application is run. また、クライアントアプリケーションを使用する人物がリソース所有者であるという想定がなされることもあります。It also assumes that the person using the client application is the resource owner.

SharePointの実装では、リストなどのSharePointリソースを複数のユーザーが共有するという事実を考慮します。The SharePoint implementation takes account of the fact that a SharePoint resource, such as a list, is shared among multiple users. また、SharePointの実装では、SharePoint アドインは、実行されるたびではなく、インストールされたときにアクセスが許可され、インストールした人物やアクセスを許可した人物ではないユーザーによって実行されることもあります。Also, in the SharePoint implementation, the SharePoint Add-in is granted access when it is installed, not each time it is run, and it can be run by users other than the person who installed it and granted it access. (SharePoint にインストールされずに SharePoint リソースにアクセスするアドインの場合(したがってこれらは広義の場合にのみ「SharePoint アドイン」であると言えます)、アドインを実行しているユーザーはアドインが実行されるたびに毎回アクセス許可を与える必要があります。)(In the case of add-ins that are not installed on SharePoint, but access SharePoint resources (so they are "SharePoint Add-ins" only in an extended sense), the user running the add-in does have to grant permissions each time the add-in is run.)

そのため、SharePoint 実装では、OAuth の役割を次のコンポーネントが担います。So, in the SharePoint implementation, the OAuth roles are played by the following components:

  • SharePoint アドイン のリモート コンポーネントは、クライアント アプリケーションの役割を果たします。The remote component of a SharePoint Add-in plays the role of the client application.

  • SharePoint ユーザーは、リソース所有者の役割を果たします。SharePoint users play the role of resource owner.

  • SharePoint は、リソース サーバーの役割を果たします。SharePoint plays the role of the resource server.

  • 低信頼承認システムが使用される場合は、Azure ACS が承認サーバーの役割を果たします。Azure ACS plays the role of the authorization server when the low-trust authorization system is used. 高信頼システムが使用される場合は、アドインそのものが (デジタル証明書と併用されることにより) 承認サーバーになります。When the the high-trust system is used, the add-in itself (along with a digitial certificate.md) becomes the authorization server.

アクセス トークンはサインイン トークンではないAccess tokens are not sign-in tokens

これまで説明したように、リソースにアクセスするために、アドインは、リソース所有者からそ信頼されたセキュリティー トークン発行者として事前に指定されたOAuth 承認サーバーからのアクセス トークンを要求する必要があります。As described earlier, to access resources, an add-in has to request an access token from an OAuth authorization server that has previously been designated as a trusted security token issuer (STS) by the resource owner. これに対して、WS-Federation STSと Security Assertion Markup Language (SAML) パッシブ サインイン STSは、主にサインイントークンを発行することを目的としています。In contrast, the WS-Federation STS and the Security Assertion Markup Language (SAML) passive sign-in STS are primarily intended to issue sign-in tokens.

SharePoint では、OAuth STSはサインイン トークンの発行には使用されません。つまり、ID プロバイダとしては使用されません。In SharePoint, an OAuth STS is not used for issuing sign-in tokens; that is, they are not used as identity providers. そのため、中央管理の 認証プロバイダー セクション、またはSharePointのユーザー選択ウィンドウのユーザー サインイン ページには OAuth STS は一覧表示されません。Note The STS isn't intended for user authentication. So, you won't see the STS listed on the user sign-in page, in the Authentication Provider section in Central Administration, or in the People Picker in SharePoint.

SharePoint 管理者は、Windows PowerShell コマンドを使用して OAuth STS を有効または無効にすることができます。これは、SharePoint 2010 で信頼済みログイン プロバイダーを有効または無効にする方法と同様です。SharePoint administrators can use Windows PowerShell commands to enable or disable an OAuth STS, similar to how they can enable or disable trusted login providers in SharePoint 2010.

関連項目See also