メインコンテンツへスキップ
アプリケーションがどのタイプのユーザーとして認証されるかによって、アクセスできるコンテンツと実行できる操作が決まります。また、どのユーザータイプになるかは、作成するアプリケーションの種類と選択する認証方法によって異なります。

ユーザータイプの一覧

ユーザータイプログイン資格情報の有無作成方法管理コンソールでの表示最適な用途
管理対象ユーザーあり企業によるプロビジョニングありライセンス付きBoxアカウントを使用する従業員
外部ユーザーあり既存のBoxアカウント (個人用アカウントまたは別のEnterpriseアカウント) を使用あり。[外部ユーザー] タブ ([外部ユーザー] フィルタ)企業間または無料アカウントでのコラボレーション
管理対象外ユーザーあり管理対象ドメインのメールアドレスを使用したセルフプロビジョニングあり。[外部ユーザー] タブ ([管理対象外ユーザー] フィルタ)企業の管理外のドメインユーザー
サービスアカウントなし (APIのみ)サーバー認証アプリが承認されたときに自動生成コンテンツマネージャのみサーバー間の統合、アプリによって所有されるコンテンツ
App Userなし (APIのみ)APIを使用してサービスアカウントによって作成あり ([ユーザーとグループ] + コンテンツマネージャ)Boxアカウントを使用せずユーザーごとにコンテンツを分離
管理者と共同管理者は、独立したユーザータイプではなく、管理対象ユーザーに割り当てられたロールです。以下の管理者ロールと共同管理者ロールを参照してください。

管理者ロールと共同管理者ロール

管理者と共同管理者は、独立したユーザータイプではなく、管理対象ユーザーに割り当てることができるロールです。いずれかのロールを付与する前に、ユーザーはまず管理対象ユーザーである必要があります。 管理者または共同管理者のロールを付与された管理対象ユーザーは、管理コンソールを使用してBox Enterpriseを直接管理できます。また、セキュリティポリシーの管理やレポートの実行、統合の構成など、他のユーザーには許可されていない操作を実行することができます。
アプリケーションによっては、操作に管理者レベルの権限が必要です。例えば、Enterprise Eventを監視するセキュリティアプリケーションを操作するには、レポート権限を持つ管理者または共同管理者である必要があります。

管理対象ユーザー

管理対象ユーザーは企業に所属し、標準のBoxライセンスを購入しています。企業ごとに固有のEnterprise IDがあり、そのIDをすべての管理対象ユーザーが共有します。例外もありますが、管理対象ユーザーは通常、同じメールドメインを共有します。

外部ユーザー

外部ユーザーは、組織外から参加するコラボレータです。つまり、管理コンソールで作成されていないアカウントを所有し、管理対象ドメインに関連付けられていないメールアドレスを持つBoxユーザーです。外部ユーザーは、まったく別の企業に所属している場合もあれば、企業と一切関係のない無料の個人用Boxアカウントを持っている場合もあります。 管理者は、外部ユーザーのアカウント設定や所有するコンテンツを管理できません。しかし、外部ユーザーとのコラボレーションは管理することはでき、例えば、企業のコンテンツへのアクセスをいつでも許可または取り消すことができます。外部ユーザーは管理コンソールの [ユーザーとグループ] > [外部ユーザー] タブに表示されます。外部ユーザーがまだ別のBox Enterpriseに所属していなければ、管理者はその外部ユーザーを招待して、自分の組織の管理対象ユーザーにすることができます。

管理対象外ユーザー

管理対象外ユーザーは、以下に該当するBoxユーザーです。
  • 管理者または共同管理者からは独立して取得され、お客様のBox組織に所属していない、ライセンスなしおよび無料の個人用Boxサービスアカウントを持っている。
  • お客様のドメインまたは確認済みドメイン (お客様の組織が所有または管理するドメイン) のメールアドレスを所有している。
管理対象外ユーザーは、管理コンソールの [ユーザーとグループ] > [外部ユーザー] タブで、[管理対象外ユーザー] フィルタを選択することで表示できます。管理者は管理対象外ユーザーを特定して管理対象ユーザーに変換し、組織の管理下に置くことができます。

サービスアカウント

サービスアカウントは、Box Enterprise内のアプリケーションを表すプログラム上のユーザーです。ログイン資格情報を使用せずにサーバー間の認証を行うため、バックエンドの統合や自動化ワークフローに最適です。
サービスアカウントの図

使用するタイミング

  • コンテンツの移行: オンプレミスとクラウドのシステム間でコンテンツを移行します。
  • イベントの監視: コンプライアンスの順守やワークフローのトリガーを目的としてEnterprise Eventを監視します。
  • コンテンツの配布: 認証ステータスにかかわらず、ファイルをアップロードしてユーザーと共有します。
  • システムの統合: オンプレミスのシステムとデバイスをBoxに接続します。
  • コンテンツのアーカイブ: アクセス頻度の低いコンテンツを格納します。

作成

サービスアカウントは、管理者が管理コンソールでJWTまたはCCGアプリケーションを承認したときに自動的に生成されます。お客様が手動で作成することはありません。 Boxはサービスアカウントに次の形式のメールアドレスを割り当てます。AutomationUser_AppServiceID_RandomString@boxdevedition.com 例: AutomationUser_123456_6jCo6Pqwo@boxdevedition.com。アンダースコアの間の数字はサービスIDで、アプリの開発者コンソールのURL (例: https://example.app.box.com/developers/console/app/123456) にあるIDと一致します。 サービスアカウントのメールアドレスは、開発者コンソール内のアプリの [一般] タブで確認できます。
サービスアカウントのメールアドレス
アプリが承認される前にサービスアカウントトークンを使用してAPIコールを試行すると、unauthorized_clientエラーが表示されます ("This app is not authorized by the enterprise")。

コンテンツの表示

プライマリ管理者のみがサービスアカウントのコンテンツを表示できます。手順は次のとおりです。
  1. 管理コンソールでコンテンツマネージャを開きます。
  2. アプリケーション名を検索します。
  3. 検索結果を右クリックし、[ユーザーのアカウントにログインする] を選択します。
サービスアカウントは [ユーザーとグループ] タブには表示されません。このアカウントはコンテンツマネージャにのみ表示されます。
共同管理者はサービスアカウントとしてログインできません。これは共同管理者がお互いに管理できないことを反映しています。

権限とコラボレーション

サービスアカウントが呼び出せるAPIエンドポイントは、開発者コンソールで構成されたスコープによって決まります。適切なスコープが構成されていると、サービスアカウントは管理者レベルのアクションを実行できます。
サービスアカウントには高度な権限を付与できるため、JWTおよびCCGアプリケーションは企業で使用する前に、明示的な管理者の承認が必要です。
サービスアカウントには独自のフォルダツリーがあり、最初は空になっています。既存のコンテンツにアクセスできるようにするには、以下の方法を使用します。
サービスアカウントにメールエイリアスを割り当てて、コラボレーション招待を覚えやすくすることができます。
デフォルトでは、管理コンソールの [新規ユーザーの初期設定] に基づいて、サービスアカウントには10 GBのストレージが与えられます。これを変更するには、space_amountパラメータを指定してユーザーを更新エンドポイントを呼び出します。

App User

App Userは、サービスアカウントがAPI経由で作成するプログラム上のユーザーです。サービスアカウントと同様、App Userはログイン資格情報を持たず、アプリケーションを通じたBoxとのやり取りのみ可能です。それぞれのApp Userに独自のフォルダツリーが用意されるため、ユーザーごとにコンテンツを分離できます。 App Userは自身が作成したアプリケーションと関連付けられており、別のアプリケーションに転送することはできません。

使用するタイミング

  • 顧客ポータル: Boxアカウントがなくても機密ドキュメントにアクセスしたり機密ドキュメントを保存したりできる場所を顧客や患者に提供します。
  • ベンダーポータル: 価格表、契約書、マーケティング資料などのコンテンツをベンダーのレベル別に整理してパートナーに配布します。
  • ブランド設定されたアプリケーション: ユーザーごとの権限、監査、レポートを備えた顧客向け機能を開発します。レポートは、金融サービスや医療など規制の厳しい業界で特に価値を発揮します。
  • IDのマッピング: 独自のIDプロバイダ (Auth0やOktaなど) から個々のBoxユーザーアカウントにユーザーをマッピングします。

作成

前提条件: JWTまたはCCGアプリケーションが管理コンソールで承認される必要があります。これにより、サービスアカウントが用意されます。 App Userを作成するには、サービスアカウントのアクセストークンを使用して、ユーザーを作成エンドポイントを呼び出します。is_platform_access_only本文パラメータをtrueに設定してください。そうしないと、代わりに管理対象ユーザーが作成されます。 Boxは各App Userに次の形式のメールアドレスを割り当てます。AppUser_AppServiceID_RandomString@boxdevedition.com 一連の手順とコードサンプルについては、App Userの作成を参照してください。

コンテンツの表示

App Userは管理コンソールの次の2か所に表示されます。
  1. [ユーザーとグループ] タブ: 表示オプションボタンを使用し、[ロール] > [App User] でフィルタをかけます。
App Userのフィルタ
  1. コンテンツマネージャ: 名前またはメールでApp Userを検索して、フォルダツリーを閲覧します。

権限とコラボレーション

App Userは、コラボレータとして明示的に追加しない限り、サービスアカウントのフォルダツリーや他のコンテンツを見ることができません App Userにはそれぞれ独自のフォルダツリーがあり、最初は空になっています。App Userがコンテンツにアクセスできるようにするには、以下の方法を使用します。
  • メールを使用: 割り当てられたメールアドレスを使用して、App Userを招待します。
  • APIを使用: ターゲットコンテンツへのアクセス権限をすでに持っているユーザーのアクセストークンとApp UserのIDを指定して、コラボレーションを作成エンドポイントを使用します。

サービスアカウントとApp Userのどちらが必要か

この決定ガイドを参考にして、アプリケーションに適した手法を選択してください。
質問回答がはいの場合
アプリを個々のユーザーに関連付けることなく、そのアプリでコンテンツを所有、管理する必要がありますか?サービスアカウントをコンテンツ所有者として使用します。
ユーザーごとにコンテンツを分離する (各ユーザーが自分のファイルを持つ) 必要がありますか?ユーザーごとにApp Userを作成します。
ユーザーが一時的なユーザーでもコンテンツは保持する必要がある状況ですか?サービスアカウントを使用してコンテンツを所有します。
独自のIDプロバイダからBoxにユーザーをマッピングしようと考えていますか?IDごとにApp Userを作成します。
それはエンドユーザーによる操作が行われないシステム間の統合ですか?サービスアカウントを直接使用します。
より詳細なアーキテクチャの決定については、ユーザーモデルを参照してください。

As-User

OAuth 2.0、JWT、またはCCG認証を使用する場合は、as-userコールを実行して、別のユーザーの代理になることができます。アプリケーションが当初、自分自身またはサービスアカウントとして認証されたものだとしても、後続のコールで別のユーザーに成り代わることができます。 これは、フォルダの再編成や従業員のプロビジョニングなどの管理タスクを自動化する場合に便利です。as-userコールを有効にするには、開発者コンソールで適切なスコープをオンにします。
As User