OneDrive と SharePoint で選択したアクセス許可の概要

SharePoint と OneDrive には、スコープ モデルに正確に適合しない、長い確立されたアクセス許可モデルがあります。 たとえば、テナント内の 1 つのリストへの ReadWrite アクセスを提供するグローバル スコープは存在しません。 代わりに、選択されたスコープでこれらのシナリオがサポートされます。 最初は、アプリケーションのアクセスを 1 つのサイト コレクションに制限するために、Sites.Selected が存在しました。 これで、リスト、リストアイテム、フォルダー、ファイルもサポートされ、選択したすべてのスコープで委任モードとアプリケーション モードがサポートされるようになりました。

Scopes

次の表に、選択したアクセス許可スコープの一覧を示します。

選択したスコープが SharePoint および OneDrive のアクセス許可と連携する方法

管理者がアプリケーションの選択されたスコープに同意すると、ワークロード内のそのリソースの所有者に対するリソースアクセス許可の管理が委任されます。 Files.Read.All などの他のスコープの場合、スコープが同意されるとすぐに、アプリケーションは表すリソースにアクセスできます。 選択したスコープには、明示的な割り当てアクションが必要です。アプリケーションがListsに同意した。SelectedOperations.Selected は、最初はアクセスできなくなります。

選択したスコープを機能させるには、一連の手順が必要です。これにより、管理者にいくつかの制御手段が提供されます。 次の例では、 Lists.SelectedOperations.Selected スコープを使用しますが、手順はすべて * に適用されます。選択したスコープ。

1. アプリケーションまたは委任されたLists.SelectedOperations.Selectedスコープを持つには、Entra IDでアプリケーションに同意する必要があります。
2. 特定のロールを持つ POST /sites/{siteid}/lists/{listid}/permissions の呼び出しを介して、アプリケーションにリストへのアクセス許可を付与する必要があります。
3. アプリケーションは、アクセス許可リストの呼び出しの Lists.SelectedOperations.Selected スコープを含む有効なトークンを取得する必要があります。

3 つの手順のいずれかが見つからない場合、アプリケーションにはアクセスできません。 管理者は、次の 2 つの制御ポイントを制御します。

• DELETE /sites/{siteid}/lists/{listid}/permissions/{id}を呼び出して特定のリストのアクセス許可を削除します。これにより、そのアプリケーションのリストへのアクセスが削除されます。
• Entra IDでLists.SelectedOperations.Selectedスコープの同意を取り消します。これにより、以前にアクセス許可が付与されていたリストへのアプリケーションのアクセスがブロックされます。

これに基づいて、アプリケーションにEntra IDのLists.SelectedOperations.Selectedスコープに同意できますが、どのリストにもアクセス許可を付与することはできません。これは、アプリケーションにアクセス権がないことを意味します。 同様に、任意のアプリケーションの POST /sites/{siteid}/lists/{listid}/permissions を呼び出すことができますが、トークンに適切なスコープが表示されないと、アプリケーションにはアクセスできません。 期待されるアクセスを確保するには、3 つの手順をすべて完了する必要があります。 これは、他の * にも適用されます。選択したスコープとそれぞれのレベル。

サイトのアクセス許可の設定の例を示します。このロジックは、リスト、リスト アイテム、ファイル、またはフォルダーに似ています。

ファイルスコープと listItems スコープの違いは何ですか?

SharePoint 内では、すべてのファイルはリスト アイテムですが、すべてのリスト アイテムはファイルではありません。 その結果、 ListItems.SelectedOperations.Selected スコープを持つアプリケーションは、許可されたロールまで、すべてのリスト アイテムとファイルにアクセスして操作できます。 Files.SelectedOperations.Selectedを持つアプリケーションは、ドキュメント ライブラリ内のファイル (リスト アイテム) や、ドキュメントを含むとしてマークされたその他のリストでのみ動作できます。 これは、現在存在するが、1 つのファイルに分離されている Files.Read.All と Files.ReadWrite.All の動作を模倣します。 この動作は、 /drives/{driveid}/items/{itemid} や /sites/{siteid}/lists/{listid}/items/{itemid}などで使用される Microsoft Graph パスに基づいて変更されることはありません。アクセスする宛先によって動作が制御されます。

役割

次の表に、特定のリソースのアプリケーションに割り当てることができる 4 つのロールを示します。

要求

POST https://graph.microsoft.com/v1.0/sites/{siteId}/permissions
Content-Type: application/json

{
  "roles": ["write"],
  "grantedTo": {
    "application": {
      "id": "89ea5c94-7736-4e25-95ad-3fa95f62b66e"
    }
  }
}

// Code snippets are only available for the latest version. Current version is 5.x

// Dependencies
using Microsoft.Graph.Models;

var requestBody = new Permission
{
	Roles = new List<string>
	{
		"write",
	},
	GrantedTo = new IdentitySet
	{
		Application = new Identity
		{
			Id = "89ea5c94-7736-4e25-95ad-3fa95f62b66e",
		},
	},
};

// To initialize your graphClient, see https://learn.microsoft.com/en-us/graph/sdks/create-client?from=snippets&tabs=csharp
var result = await graphClient.Sites["{site-id}"].Permissions.PostAsync(requestBody);

// Code snippets are only available for the latest major version. Current major version is $v1.*

// Dependencies
import (
	  "context"
	  msgraphsdk "github.com/microsoftgraph/msgraph-sdk-go"
	  graphmodels "github.com/microsoftgraph/msgraph-sdk-go/models"
	  //other-imports
)

requestBody := graphmodels.NewPermission()
roles := []string {
	"write",
}
requestBody.SetRoles(roles)
grantedTo := graphmodels.NewIdentitySet()
application := graphmodels.NewIdentity()
id := "89ea5c94-7736-4e25-95ad-3fa95f62b66e"
application.SetId(&id) 
grantedTo.SetApplication(application)
requestBody.SetGrantedTo(grantedTo)

// To initialize your graphClient, see https://learn.microsoft.com/en-us/graph/sdks/create-client?from=snippets&tabs=go
permissions, err := graphClient.Sites().BySiteId("site-id").Permissions().Post(context.Background(), requestBody, nil)

// Code snippets are only available for the latest version. Current version is 6.x

GraphServiceClient graphClient = new GraphServiceClient(requestAdapter);

Permission permission = new Permission();
LinkedList<String> roles = new LinkedList<String>();
roles.add("write");
permission.setRoles(roles);
IdentitySet grantedTo = new IdentitySet();
Identity application = new Identity();
application.setId("89ea5c94-7736-4e25-95ad-3fa95f62b66e");
grantedTo.setApplication(application);
permission.setGrantedTo(grantedTo);
Permission result = graphClient.sites().bySiteId("{site-id}").permissions().post(permission);

const options = {
	authProvider,
};

const client = Client.init(options);

const permission = {
  roles: ['write'],
  grantedTo: {
    application: {
      id: '89ea5c94-7736-4e25-95ad-3fa95f62b66e'
    }
  }
};

await client.api('/sites/{siteId}/permissions')
	.post(permission);

<?php
use Microsoft\Graph\GraphServiceClient;
use Microsoft\Graph\Generated\Models\Permission;
use Microsoft\Graph\Generated\Models\IdentitySet;
use Microsoft\Graph\Generated\Models\Identity;


$graphServiceClient = new GraphServiceClient($tokenRequestContext, $scopes);

$requestBody = new Permission();
$requestBody->setRoles(['write', 	]);
$grantedTo = new IdentitySet();
$grantedToApplication = new Identity();
$grantedToApplication->setId('89ea5c94-7736-4e25-95ad-3fa95f62b66e');
$grantedTo->setApplication($grantedToApplication);
$requestBody->setGrantedTo($grantedTo);

$result = $graphServiceClient->sites()->bySiteId('site-id')->permissions()->post($requestBody)->wait();

Import-Module Microsoft.Graph.Sites

$params = @{
	roles = @(
	"write"
)
grantedTo = @{
	application = @{
		id = "89ea5c94-7736-4e25-95ad-3fa95f62b66e"
	}
}
}

New-MgSitePermission -SiteId $siteId -BodyParameter $params

# Code snippets are only available for the latest version. Current version is 1.x
from msgraph import GraphServiceClient
from msgraph.generated.models.permission import Permission
from msgraph.generated.models.identity_set import IdentitySet
from msgraph.generated.models.identity import Identity
# To initialize your graph_client, see https://learn.microsoft.com/en-us/graph/sdks/create-client?from=snippets&tabs=python
request_body = Permission(
	roles = [
		"write",
	],
	granted_to = IdentitySet(
		application = Identity(
			id = "89ea5c94-7736-4e25-95ad-3fa95f62b66e",
		),
	),
)

result = await graph_client.sites.by_site_id('site-id').permissions.post(request_body)

要求ヘッダー

応答

HTTP/1.1 201 Created
Content-Type: application/json

{
    "id": "1",
    "@deprecated.GrantedToIdentities": "GrantedToIdentities has been deprecated. Refer to GrantedToIdentitiesV2",
    "roles": ["write"],
    "grantedToIdentities": [{
      "application": {
        "id": "89ea5c94-7736-4e25-95ad-3fa95f62b66e",
        "displayName": "Contoso Time Manager App"
      }
    }],
    "grantedToIdentitiesV2": [{
      "application": {
        "id": "89ea5c94-7736-4e25-95ad-3fa95f62b66e",
        "displayName": "Contoso Time Manager App"
      }
    }]
}

アクセス許可を管理する方法を示す例については、サイト、list、listItem、driveItem の/permissions API トピックを参照してください。

アクセス許可を管理するには、どのようなアクセス許可が必要ですか?

アクセス許可の要件はレベルによって異なります。 委任されたすべてのケースでは、現在のユーザーも API を呼び出してアクセスを管理するための十分なアクセス許可が必要です。 次の表には、スコープとスコープと、親リソースに割り当てられたロールが含まれています。 たとえば、Sites.Selected スコープと FullControl ロール (Sites.Selected+ FullControl) がある場合は、そのサイト コレクション内のリソースを管理できます。

アクセスの計算方法

トークンには、アプリケーションのみと委任の 2 種類があります。 アプリケーションのみのシナリオでは、ユーザーが存在せず、リスクが高いと見なされます。 委任されると、アプリケーションは現在のユーザーの既存のアクセス許可を超えることはなく、多くのシナリオではリスクが低いと見なすことができます。 可能な場合は委任することをお勧めしますが、どちらのモードもニーズに合わせて使用できます。

アプリケーション ID、リソース ID、ロールのタプルが格納されます。 そのため、[アプリケーション] には [リソース] への [ロール] アクセス権があります。 API を使用してアクセス許可を作成するときにアプリケーションとロールを指定し、解決されたパスによってリソースが提供されます。 たとえば、アプリケーション Z には、/sites/dev/lists/list1 にあるリストへの読み取りアクセス権があります。

アクセスを計算するには、トークンで指定された値を使用して、おおよそこのフローに従います。

1. トークンの種類 (アプリケーションまたは委任) を確認します。

2. リソース上の指定されたアプリケーション ID のアプリケーション レコード、またはセキュリティ保護可能な階層親 (継承) を検索します。

3. 次のいずれかが発生します。

   • アプリケーション アクセスの場合、アプリケーションのレコードが見つかり、ロールによって要求された操作 (アイテムの読み取り、リストの更新) が許可されている場合、アクセス権が付与されます。
   • 委任されたシナリオでは、アプリケーションとユーザーの両方のアクセス許可が計算されて交差します。つまり、アプリケーションはユーザーのアクセス許可を超えることはなく、ユーザーは同意されたアプリケーションのアクセス許可を (アプリケーションを介して) 超えることはできません。

同意の動作に関するメモ

同意の動作には、次の注意事項が適用されます。

• アプリケーションには複数の選択した同意を含めることができます。これらの同意はテナント全体のさまざまなレベルで適用できます。
• スコープが取り消されるとすぐにアプリケーション アクセスが失われます。 アプリケーションに Lists.* と Sites.* があり、サイト コレクションとそのサイト コレクション内の特定のリストへのアクセス権が付与された後、Sites.* の同意が取り消された場合、アプリケーションは、Lists.* 同意と以前のlist/permissionsの呼び出しを介して、特定のアクセス権が付与されたリストへのアクセスを維持します。
• アプリケーションが list/permissionsの呼び出しを介してリストに対するアクセス許可を持っていて、 DELETE lists/permissions/idの呼び出しによってアクセス権が削除された場合、そのリストアイテムに設定されている明示的なアクセス許可に関係なく、そのリストとそのリスト内のすべてのアイテムへのアクセス権が失われます。 必要に応じて、後で特定の項目のアクセス許可を再付与できます。
• Sites.* などの上位レベルのスコープを使用してファイル固有のアクセス許可を付与できますが、スコープが低いほど上位レベルのリソースにアクセスすることはできません。 これにより、アプリケーションは特定のレベルでアクセスできます。
• 同意は外部の概念であり、指定されたトークンを介して OneDrive と SharePoint によって使用され、トークンに表示されるすべてのスコープが適用されます。