管理

管理アプリケーションを使用すると、アカウント管理者はユーザー、ロール、テナント、アプリケーション、およびビジネスルールを管理し、アカウントに関する多数の構成設定を行うことができます。

概要

ここでは、管理アプリケーションのすべての機能について詳しく説明します。このドキュメントの内容の概要については、以下をご覧ください。

セクション コンテンツ
ホーム画面 容量使用状況と登録済みアプリケーションに関する情報の表示
テナントの管理 サブテナントの管理方法
使用状況の統計 サブテナントの使用状況統計の確認方法
ユーザーの管理 ユーザーの追加、編集、無効化、または削除する方法
権限の管理 グローバルロールインベントリロールの追加および編集方法、ユーザーへの割り当て方法、アプリケーションへのアクセスを許可する方法
アプリケーションの管理 Things Cloudアカウントでの登録済みアプリケーションの管理方法、および、カスタム アプリケーションの構成設定
ビジネスルールの管理 アラームマッピングによってアラームの優先順位を変更する方法
データ保持の管理 データの保持ルールの管理と設定方法、およびファイルリポジトリでの保存ファイルの管理
二要素認証 ユーザーの二要素認証をアクティブ/非アクティブにする方法
設定の変更 アプリケーション設定認証設定などのアカウント設定の変更方法、プロパティライブラリの管理方法、 シングルサインオンの構成方法

ホーム画面

管理アプリケーションのホーム画面には、以下が表示されます。

Home screen

使用状況には以下の情報が表示されます。

テナントの管理

Things Cloud では、サブテナントの作成と管理ができるテナント機能を利用することができます。

重要
複数のテナントを提供することと、単一のテナント内で複数のユーザーに異なる権限を提供することには大きな違いがあります。テナントは物理的に分離されたデータスペースであり、個別のURL、独自のユーザー、個別のアプリケーション管理を持ち、デフォルトとしてデータを共有しません。また、同じテナント内にいるユーザーは、デフォルトで、同じURLと同じデータスペースを共有します。例えば、ユーザーが別々の顧客であり、競合他社である可能性があるため厳密に分離する必要がある場合は、個別テナントとして設定することを強くお勧めします。ロールベースのアクセスアプローチとマルチテナントのアプローチの詳細については、RBAC VS マルチテナント をご覧ください。

テナント機能を使用するには、ユーザーに適切な権限が必要です。権限の編集の詳細については、 グローバルロールの追加をご覧ください。テナントの編集は機密性の高い操作であるため、テナントの編集権限はより細かくなります。

サブテナントの表示

テナントメニューのサブテナントをクリックすると、アカウントで使用可能なすべてのサブテナントがグリッドまたは一覧で表示されます。

テナントページには、各サブテナントに関する次の情報が表示されます。

サブテナントの作成

  1. トップメニューバーの右にあるテナントを作成をクリックします。

    Create subtenant

  2. 次のプロパティを指定します。

フィールド 説明
ドメイン/ URL 「acme」のように、任意のサブドメインを入力します。テナントのURLは je1.thingscloud.ntt.com 上の「acme.je1.thingscloud.ntt.com」になります。使用できるサブドメインレベルは1つだけです。例えば、「acme.je1.thingscloud.ntt.com」のみ je1.thingscloud.ntt.com で使用できます。「mycustomer.acme.je1.thingscloud.ntt.com」は使用できません。これはTLS標準では許可されていません。
テナントドメインには、小文字、数字、またはハイフン( - )を使用でき、文字で始まる必要があります。ハイフン( - )は途中でのみ使用できます。最小は2文字です。
名前 テナントの名前。会社名など
管理者のEメールアドレス ユーザーがパスワードをリセットできるようにするには、有効なメールアドレスを指定する必要があります。
管理者のユーザー名 このテナントの管理者のユーザー名
連絡先名 連絡先名(任意)
連絡先電話番号 連絡先の電話番号(任意)
パスワードリセットのリンクを Eメールで送信 デフォルトで選択されています。このオプションの選択を解除する場合は、パスワードを入力し、パスワードを確認する必要があります(パスワードの強度についての詳細は、はじめに > Things Cloudへのログイン方法をご覧ください)。
テナントポリシー ドロップダウンリストから、テナントに適用するテナントポリシーを選択できます。
  1. 保存をクリックして設定を適用します。

サブテナントが作成されると、自動生成されたIDが取得されます。このIDは変更できません。また、最初の管理ユーザー(管理者のユーザー名)が自動的に表示されます。この管理者は、他のユーザーを作成し、権限を設定できます。ロックアウトを防ぐため、最初のユーザーは削除することができません。

サブテナントのプロパティの表示または編集

目的のサブテナントをクリックするか、サブテナントの右側にあるメニューアイコンをクリックして、編集をクリックします。

プロパティタブでは、IDドメイン/ URL管理者のユーザー名以外のすべてのフィールドを編集できます。フィールドの詳細については、サブテナントの作成をご覧ください。

テナントのパスワードを変更するには、パスワードの変更をクリックし、次のフィールドに新しいパスワードを入力して、保存をクリックします。

サブテナントの一時停止

テナントを一時停止すると、このテナントへのアクセスは、デバイス、ユーザー、またはその他のアプリケーションからのアクセスに関係なく、すべてブロックされます。 さらに、すべてのマイクロサービスがデプロイ解除され、テナントが再有効化されると、すべてのマイクロサービスが再デプロイされます。

テナントが停止された場合、テナントのデータはデータベースに残ったままになるので、有効化をクリックすることで再度使用可能になります。

サブテナントの一時停止

  1. 各サブテナントの右側にあるメニューアイコンをクリックして、一時停止をクリックします。

    Suspend tenant

  2. 表示されるダイアログボックスで、一時停止をクリックしてパスワードを入力し、停止を確認します。

停止されるテナント管理者の構成設定でメールアドレスが指定されている場合は、一時停止の一環として、そのテナント管理者にメールが送信されます。

重要

テナントの管理者は、アクティブなサブテナントを一時停止することはできますが、削除することはできません。

アプリケーション

アプリケーションタブでは、登録しているすべてのアプリケーションを表示したり、テナントをアプリケーションに登録したり、テナントからアプリケーションを削除したりできます。テナントは、デフォルトで標準 Things Cloud アプリケーションが登録されます。

Subscribe tenant

アプリケーションの登録

右側の利用可能なアプリケーションの下のアプリケーションにカーソルを合わせ、目的のアプリケーションで登録をクリックします。

アプリケーションの登録解除

左側の登録済みアプリケーションの下にあるアプリケーションの上にカーソルを合わせ、登録解除をクリックします。

マイクロサービスの監視

Things Cloudによってマイクロサービスとしてホストされているすべてのアプリケーションは、名前の横に表示される記号でそのステータスを確認することができます。

Application details
マイクロサービスは、次のいずれかの状態になります。

各エントリを展開すると、ステータスの詳細を表示できます。

Application details
次の情報が表示されます。

詳細については、各アプリケーションの プロパティを参照してください。アプリケーションの管理をご覧ください。

カスタム プロパティ

カスタム プロパティタブでは、定義済みプロパティ(「外部参照」など)または プロパティライブラリ で定義されているカスタム プロパティの値を表示および編集できます。これらのプロパティは、使用状況の統計ページの列としても表示されます。

Custom properties

サブテナント リクエスト頻度の制限

プラットフォーム管理者は、次のカスタム プロパティより、各サブテナントのリクエスト頻度を制限できます。

リクエスト調整メカニズムは、両方のHTTPプロパティ(「HTTPキューを制限」と「HTTPリクエストを制限」)が構成されている場合にのみ有効になります。値の1つが省略されていると機能しません。

重要
リクエスト頻度の制限は、総当たり攻撃のログイン試行、APIの悪用、リクエスト フラッディングなどの脅威に対して効果的な対策となり、悪意のある、または不要なトラフィックの数を減らすことができます。これは、DoS(サービス拒否)攻撃から保護し、正当なリクエストのための利用可能な帯域幅の節約に役立ちます。

また、特定のテナントのCEPキューおよびデータブローカキューのバッファサイズをカスタマイズすることもできます。これは、次のサブテナントカスタムフラグメントを使用して、管理テナントから実行できます。

テナントおよびシステムレベルで制限がない場合、制限機能は無効とみなされ、テナントは無制限にアクセスできます。制限を付けた後に、リクエスト頻度の制限をオフにする場合は、値を「-1」に設定してください。

サブテナントのデバイス数の制限

プラットフォーム管理者は「デバイスの数を制限」というカスタム プロパティから、同時に登録されるルートデバイスまたはすべてのデバイス(子デバイスを含む)の数を制限できます。

同時に登録されているデバイスの最大数、ルートデバイス、およびストレージ使用量の最大値は、使用状況の統計ページに表示されます。

テナントポリシー

テナントポリシーとは、テナントオプションとデータ保持ルールのセットです。テナントオプションと保持ルールは、テナントの作成時に指定できます。

Assign tenant policy
特定のオプションとルールのセットを使用してテナントポリシーを作成すると、同じ設定で複数のテナントを作成する場合に時間を節約できます。

備考
オプションとルールはテナント内へコピーされます。ポリシーを編集しても、すでに作成されたテナントに対して影響はなく、変更は反映されません。
重要
テナントポリシーで指定されたテナント オプションは 暗号化されていません。 ここでテナントオプションを指定したり、「資格情報」で上書きしたりしないでください。プラットフォームは、これらのオプションがテナントの作成後に表示されるデータで暗号化されることを想定しているためです。

テナント ポリシーの表示

テナントメニューのテナントポリシーをクリックすると、利用可能なテナントポリシーがすべて表示されます。

Tenant policies
テナント ポリシーごとに、名前、テナントオプションの説明、オプションとデータ保持ルールの数が、一覧またはグリッドで表示されます。

テナント ポリシーの作成

  1. トップメニューバーのポリシーの追加をクリックします。

    Add new policy
  2. 表示されるウィンドウでテナント ポリシーの「名前」と「説明」を入力します。
  3. 少なくとも1つの保存ルールを追加します。保存ルールの作成の詳細については、管理 > データ管理 > データ保持ルールをご覧ください。
  4. 必要に応じて、テナントオプションを追加します。
  5. 保存をクリックします。

テナント ポリシーがテナント ポリシー一覧に追加されます。

重要
保持ルールとオプションを定義するときに、サブテナントがこれらのルールまたはオプションの定義を変更できるようにするチェックボックスを選択できます。既定では、このチェックボックスは有効になっていません。サブテナントの作成後にこのチェックボックスを選択しない場合、ルールとオプションを編集するには、管理テナントから更新を実行する必要があることに注意してください。

テナント ポリシーの編集

該当するポリシーをクリックするか、ポリシーの右側にあるメニューアイコンをクリックして、編集をクリックします。

表示されるウィンドウで編集を行い、保存をクリックして設定を保存します。

ポリシーからデータ保持ルールまたはテナントオプションを削除するには、その上にカーソルを合わせ、削除アイコンをクリックします。

テナント ポリシーの複製

複製するテナントポリシーのメニューアイコンをクリックし、複製をクリックします。

テナント ポリシーの削除

削除するテナントポリシーのメニューアイコンをクリックし、削除をクリックします。

使用状況の統計

使用状況の統計の表示

使用状況の統計ページには、各サブテナントの統計情報が表示されます。

サブテナント統計

サブテナントごとに次の情報が提供されます(スペースが限られているため、上のスクリーンショットではすべての項目は表示されていません)。

フィールド 説明
ID サブテナントのID
テナント サブテナント名
APIリクエスト デバイスおよびアプリケーションからのリクエストを含む、APIリクエスト総数
デバイスからのAPIリクエスト デバイスからのAPIリクエスト数
ストレージ(MB) アカウントに保存されているデータ量
ピークストレージ(MB) ストレージのピーク値
ルートデバイス 子デバイスを除くルートデバイス数
ルートデバイスのピーク数 子デバイスを除くルートデバイスのピーク数
デバイス 子デバイスを含む、サブテナントに接続されたデバイスの合計数
デバイスのピーク 子デバイスを含むデバイスのピーク数
エンドポイントのデバイス ゲートウェイやエッジを除くリーフデバイス
登録済みアプリケーション サブテナントにサブスクライブされているアプリケーション数
作成日時 サブテナントの作成日時
アラームが作成されました 作成されたアラーム数
アラームが更新されました 更新されたアラーム数
インベントリが作成されました 作成されたマネージドオブジェクト数
インベントリが更新されました 更新されたマネージドオブジェクト数
イベントが作成されました 作成されたイベント数
イベント更新済み 更新されたイベント数
作成された計測値 作成されたメジャーメント数
受信転送合計 すべての受信転送の合計(アラームの作成、アラームの更新、作成イベント、更新イベント、インベントリの作成、インベントリの更新、メジャーメントの作成)
CPU (M) マイクロサービスのCPU使用率(CPUミリ秒で指定)
メモリ (MB) マイクロサービスのメモリ使用量
外部参照 例えば、CRM システムへのリンクをここに追加したり、内部顧客番号を追加するなど、個別の用途に使用します

さらに、カスタム プロパティが設定されている場合は表示されます。

カスタムプロパティは、プロパティ ライブラリで定義し、テナントのカスタム プロパティタブで値を設定できます。

上部のメニューバーに開始日と終了日を追加して 適用 をクリックすると、ある期間の使用統計リストをフィルター処理できます。使用状況の統計ページには、この期間のすべてのサブテナントの数値が表示されます。

備考
選択した期間の後にテナントが作成された場合、そのテナントは表示されますが、数字は「0」です。

列名の横にあるフィルターアイコンをクリックし、フィルター条件を指定して、任意の列のリストをフィルター処理したり、並べ替えることもできます。はじめに > UIの機能と特長 > 絞り込み(フィルタリング)をご覧ください。

重要
ここで使用される日付/時刻の範囲は、タイムゾーンが異なるためにサーバーの時刻と異なる場合があります。

使用状況統計をエクスポートするには

  1. 上部のメニューバーの右側にある CSVをエクスポート をクリックして、統計テーブルの現在のビューをCSVファイルにエクスポートします。

  2. 表示されるダイアログボックスで、フィールド区切り記号、小数点記号、および文字セットを指定して、CSV出力をカスタマイズできます。

  3. ダウンロード をクリックしてエクスポートを開始します。

CSV ファイルがダウンロードされます。

毎日の処理

使用統計は、リクエスト数のような進行する値と、特定の期間における状態のスナップショットである値で構成されます。後者のタイプのデータの場合、値は毎日数回更新されますが、EOD (End of the Day - 1日の終わり) からの値は特定の日に割り当てられた値です。

値のタイプ 更新
リクエスト数フラッシュ 5分ごと
使用済みストレージ 9、17およびEOD
デバイス数 9、17およびEOD
登録されたアプリケーション 9、17およびEOD

ライフサイクル

テナント

Things Cloudプラットフォームテナントには、いくつかの状態があります。

 

ユーザーの管理

ユーザー管理機能を使用すると、テナント内のユーザーを管理でき、次の機能が提供されます。

備考
この操作を行うには、ユーザー管理権限の「管理者」または「作成」を持つロールが必要です。
備考
シングルサインオンを使用しているユーザーは、プラットフォームが管理しているユーザーのパスワードを変更できません。

ユーザーの表示

テナント内のすべてのユーザーを表示するには、ナビゲータの アカウント メニューで ユーザー をクリックします。

Expanded view

ユーザーリストが表示され、ユーザーごとに次の情報が提供されます。

リストをユーザー名で絞り込むには、トップメニューバーの左側にあるフィルター フィールドを使用します。ドロップダウン リストを使用すると、グローバルロールで絞り込みができます。フィルタリングの詳細については、はじめに > UI の機能と特長 > 絞り込み(フィルタリング) をご覧ください。

選択したフィルターを適用するには、適用 をクリックします。

ユーザーの追加

  1. トップメニューバーの右側にあるユーザーを追加をクリックします。

    備考
    テナントのシングル サインオンが有効になっている場合、シングル サインオン経由でログインできないローカルユーザーが作成されていることを通知するメッセージが表示されます。

  2. 新しいユーザーウィンドウの左側から、ユーザーを識別するために次の情報を入力してください。

フィールド 説明
ユーザー名 システム内でユーザーを識別するための一意のユーザーIDです。ユーザーの作成後にユーザー名を変更することはできません。このフィールドは必須です。ユーザー名に日本語を用いることはできません
ログイン エイリアス ユーザー名に加えて、ログオンに使用するエイリアスをオプションで指定できます。このエイリアスは必要に応じて変更できます
ステータス ユーザーアカウントを有効/無効にします。ユーザーアカウントが無効になっている場合、ユーザーはログインできません
Eメール 有効なメールアドレスです。これは、ユーザーがパスワードをリセットできるようにするために必要です。このフィールドは必須です
ユーザーの名前。ユーザーがログインすると、この名前がユーザーボタンのトップバーの右側に表示されます
ユーザーの姓
電話番号 有効な電話番号です。ユーザーが二要素認証を使用する場合は必須項目となります
  1. ユーザーのログインオプションを選択します。 

    • 次回ログイン時にパスワード リセットを強制する:選択した場合、ユーザーは次回ログイン時にリセットする必要があるパスワードを指定してください。パスワードを入力して確認します。パスワードを入力すると、パスワードの強度が表示されます。パスワードのリセットと強度の詳細については、パスワードの変更 をご覧ください。
    • パスワード リセットのリンクを Eメールで送信:選択した場合、ユーザーはパスワードを設定するためのリンク先を含んだメールを受信します。上記で設定したメールアドレスへメールが送信されます。
  2. ページの右側から、ユーザーのグローバルロールを選択します。グローバルロールの詳細については、権限の管理をご覧ください。

  3. 保存をクリックして設定を保存します。

新規ユーザーがユーザーリストへ追加されます。

備考
手動で作成したユーザーは、デフォルトで、「Own_User_Management」権限を有効に設定されています。

ユーザーの編集

  1. 編集したい列の右側にあるメニューアイコンをクリックし、編集をクリックします。 ユーザー名およびパスワードリセットのリンクをEメールで送信を除く、すべてのフィールドを変更できます。各フィールドの詳細については、ユーザーの追加をご覧ください。
  2. パスワードを変更をクリックして、パスワードを変更します。
  3. 編集後、保存をクリックして設定を適用します。
備考
これらのオプションを実行するには、ユーザー管理権限のあるロールが必要です。

インベントリロールのコピー

  1. 変更したい列の右側にあるメニューアイコンをクリックし、インベントリロールをコピーをクリックします。
  2. 次のウィンドウで、ロールを既存のユーザーロールにマージするか(デフォルト)、既存のユーザーロールを置き換えるかを選択します。
  3. ドロップダウンリストからコピーしたいロールを持つユーザーを選択します。
  4. コピーをクリックします。

選択されたユーザーのインベントリロールをコピーします。

備考
これらのオプションを実行するには、ユーザー管理権限のあるロールが必要です。

ユーザーの有効化/無効化

変更したい列の右側にあるメニューアイコンをクリックし、無効化をクリックします。無効化されているユーザーを有効にするには、有効化をクリックします。

備考
これらのオプションを実行するには、ユーザー管理権限のあるロールが必要です。

ユーザーの削除

削除したいユーザの列の右側にあるメニューアイコンをクリックし、削除をクリックします。

備考
これらのオプションを実行するには、ユーザー管理権限のあるロールが必要です。

権限の管理

権限では、ユーザーが Things Cloud アプリケーションで実行を許可される内容を定義します。権限をより簡単に管理するために、「ロール」と呼ばれるグループにまとめられています。すべてのユーザーは、権限を追加しながら複数のロールに関連付けることができます。

次のタイプのロールをユーザーに関連付けることができます。

さらに、ユーザーがアプリケーションを使用できるようアプリケーションアクセスを付与することができます。

グローバルロール

アカウントメニューのロールをクリックして、構成設定済みのロールの一覧を表示します。

Context menu

グローバルロールタブには、システムレベルで権限を付与するロールがあります。既定でグローバルロールがいくつか定義されていますが、必要に応じて独自のロールを定義できます。

備考

定義済みロールは、特定の目的のためのサンプルとして構成されています。これらを出発点として使用し、個々のニーズにおいて、さらに適合させることができます。

新しいユーザーを作成するとき、割り当てられた各ロールによって、ユーザーに割り当てるグローバルロールに特定ユーザー関連の必要なすべての権限が含まれていることを確認します。 異なるロールの権限は、同じユーザーに割り当てられるとマージされます。 例えば、ユーザーが「コックピット ユーザー」ロール(以下参照)しか持っていない場合、ユーザーはコックピット アプリケーションのみアクセスでき、それ以上はアクセスできません。ただし、利用可能なロールの一部を介してインベントリのアクセス許可を割り当てると、ユーザーはデバイス、グループ、構成などのインベントリ全体にアクセスできるようになります。

「admins」と「devices」のロールには特別なステータスがあります。

ロール    説明
admins 管理者権限が有効になっています。テナントで最初に作成された初期管理者がこのロールを持ちます
devices デバイスの一般的な権限の設定。登録後、デバイスは自動的にこのロールを持ちます。デバイスが必要とするアクセス許可が既定より少ないか多い場合に、このロールを編集するか、デバイスに他のロールを割り当てます

さらに、次のロールがデフォルトで設定されています。

ロール 説明
CEPマネジャー すべてのスマートルールおよびイベント処理ルールにアクセスできます
コックピットユーザー コックピットアプリケーションにアクセスできます。さらに、デバイスへのアクセスを許可するロールを追加する必要があります
デバイス管理ユーザー デバイス管理アプリケーションにアクセスできます。ユーザーはシミュレーターを使用して、一括操作を実行できます。さらに、デバイスへのアクセスを許可するロールを追加する必要があります
グローバルマネージャー すべてのデバイスに対し、閲覧、書き込みができます
グローバルリーダー すべてのデバイスを閲覧できます
グローバルユーザーマネージャー すべてのユーザーを管理できます
共有ユーザーマネージャー サブユーザーを管理できます。サブスクライブしているプランには、サブユーザーを管理できるようにユーザー階層を含める必要があります
テナントマネージャー 所有アプリケーション、データブローカー、データ保持、オプション、テナント統計など、テナント全体の設定を管理できます

次のレガシーロールも表示される場合があります。

ロール 説明
business すべてのデバイスとそのデータにアクセスできますが、テナントでの管理権限がありません
readers すべてのデータを閲覧できます(「グローバルリーダー」とは違い、ユーザー管理を含みます)

グローバルロールの追加

グローバルロールタブでグローバルロールの追加をクリックします。

新しいグローバルロールページではアクセス権限タイプの一覧が左側に表示され、アクセス可能なアプリケーションの一覧が右側に表示されます。

次のスクリーンショットは、「admins」ロールの設定を示しています。

Admin example

権限レベル

タイプごとに、次の権限レベルを選択できます。

備考
「作成」アクセス権限は、Things Cloudにおける所有権の概念に関連しています。オブジェクトを作成した場合、そのオブジェクトの所有者となり、それ以上の権限を必要とせずにオブジェクトを管理できます。例えば、「インベントリ」の「作成」権限を持つユーザーは、デバイス/グループを作成し、それらのデバイス/グループを完全に管理できます。自分で作成しなかったデバイス/グループは、「更新」権限または追加のインベントリロール(下記参照)を持っていない限り、管理できません。この概念は、デバイスに最小限の権限を割り当てるのに役立ちます。

それぞれのレベルをすべての権限タイプに設定するには、列の最上部にあるチェックボックスを選択します。

権限のカテゴリ

次の権限カテゴリは、デフォルトで使用可能です。

カテゴリ 説明
アラーム アラームを閲覧、または編集
アプリケーション管理 アカウントで使用可能なアプリケーションの閲覧と編集
監査 監査ログを閲覧、作成
一括操作 一括操作を閲覧、作成
CEP管理 CEPルールの閲覧、編集
データブローカー 他のテナントへデータを送信、または他のテナントからデータを受信
デバイス制御 デバイスに送信するコマンドを表示、編集。デバイスにコマンドを送信。またデバイス登録にも使用されます
イベント イベントを閲覧、作成
グローバルスマートルール グローバルスマートルールの構成設定
識別子 デバイスの識別IDを閲覧、編集
インベントリ インベントリデータの閲覧、編集
計測値(メジャーメント) メジャーメントを閲覧、作成
オプション管理 パスワードのポリシーなどのアカウントオプションを閲覧、編集
データ保持ルール データ保持ルールの閲覧、編集
エクスポートをスケジュール レポートのエクスポートスケジュール管理
シミュレーター シミュレートされたデバイスの構築設定
SMS SMSの構成(Things Cloud では本機能は利用できません)
テナント管理 サブテナントを閲覧、作成、編集、削除
テナント統計 管理アプリケーションのホーム画面に表示されている該当アカウントのデータ使用量を閲覧
ユーザー管理 ユーザー、グローバルロール、アクセス権限を閲覧、編集
自身のユーザー管理 自身のユーザーを閲覧、編集

登録プランの機能によっては、追加の権限が表示される場合があります。それらは、各機能とともに説明されています。

重要
新しい権限を持つ新規機能がThings Cloudに追加されても、既存のロールには自動的に追加されません。最近発表された新規機能を使用できない場合は、権限を確認してください。

グローバルロールの割り当て

グローバルロールをユーザーに割り当てるには、ユーザーリストで直接割り当てるか、目的のユーザー画面を開いて追加します。

重要
デフォルトでは、SSO ユーザーのロール(SSO ログイン時に自動的に作成される)を変更することはできません。これは、動的アクセス マッピングによって上書きされるためです。ただし、この動作は変更できます。 詳細については、ユーザーガイド管理 > 設定の変更 をご覧ください。
ユーザーリストよりグローバルロールを割り当てる
  1. 目的のユーザーのグローバルロール列をクリックして、グローバルロールの一覧を開きます。
  2. 各チェックボックスをオンまたはオフにします。
  3. 適用をクリックして設定を保存します。

Apply global role

ユーザー画面よりグローバルロールを割り当てる
  1. 目的のユーザーの行をクリックします。
  2. 表示されたユーザー画面より、右側の関連するグローバルロールのチェックボックスをオンまたはオフします。
  3. 保存をクリックして設定を保存します。

Attach global role

インベントリロール

インベントリロールには、デバイスのグループに割り当てることができる権限が含まれています。例えば、インベントリロールにデバイスを再起動する権限を含めるとします。そして、そのインベントリロールをデバイスグループ「Region North」とユーザー「smith」に割り当てるとします。その結果、ユーザー「smith」は、グループ「Region North」とそのサブグループ内のすべてのデバイスを再起動できるようになります。

現在設定されているインベントリロールを表示するには、アカウントメニューのロールをクリックし、インベントリ ロールタブに切り替えます。

Context menu

インベントリロール タブでは、特定のグループやその配下にある子のユーザー権限を管理できます。デフォルトのインベントリロールがいくつか定義されていますが、必要に応じて独自のロールを定義できます。

新規テナントは、次のデフォルトのインベントリロールが最初から使用可能です。

ロール 説明
マネージャー すべてのアセットのデータの読み取りとインベントリ内のデータの管理ができますが、オペレーションの実行はできません。
さらに、ダッシュボードを含むインベントリデータとアラームの管理ができます
操作: すべて デバイスにオペレーションを送信し、アセットを遠隔管理することができます
(例:ソフトウェアのアップデート、リモート設定)
操作: デバイス再起動 デバイスの再起動ができます
リーダー アセットのデータをすべて閲覧することができます

インベントリ ロールの追加

インベントリ ロールタブでインベントリ ロールの追加をクリックします。新しいインベントリ ロール ページで、名前説明 を入力し、新しいインベントリ ロールに アクセス権限 を割り当てます。

Role details

アクセス権限は、次のカテゴリに分類されます。

カテゴリ 説明
アラーム デバイスからのアラーム操作に関連する権限
監査 監査ログに関連する権限
イベント デバイスからのイベント操作に関連する権限
インベントリ デバイスを閲覧および編集するための権限
計測値(メジャーメント) メジャーメントに関連する権限
デバイス制御 デバイスを遠隔制御するための権限
フルアクセス 構成設定を簡素化するための、関連するデバイスへの完全なアクセス権

目的のカテゴリの横にあるプラスアイコンをクリックして、ロールに権限を追加します。

タイプフィールドで、タイプを指定して、アクセス権限が適用されるデータタイプをさらに制限します。アクセスは、指定された タイプ を含むオブジェクトにのみ許可されます。

例えば、デバイスが「c8y_SignalStrength」などのデバイス管理に関連するメジャーメントと、実際の生産メジャーメントを送信するとします。デバイス管理メジャーメントのみをユーザーに表示したい場合、タイプとして「c8y_SignalStrength」と入力します。これにより、ユーザーは「c8y_SignalStrength」タイプを含むメジャーメントのみを表示できます。ユーザーは、同じメジャーメント オブジェクトの一部となりえる他のタイプを含んだ、メジャーメント オブジェクト全体を見れることを注意してください。

デフォルトでは、タイプフィールドにはすべてのタイプを選択するアスタリスク「*」が含まれています。

備考
使用可能なタイプの詳細については、デバイスのドキュメント、Things Cloud センサー・ライブラリまたはデバイス管理ライブラリを確認してください。ここで使用されているタイプは、「タイプ」プロパティではなく、いわゆる「フラグメントタイプ」です。メジャーメントを表示するには、メジャーメントで送信するすべてのフラグメントタイプを入力してください。他のタイプのデータについても同様です。

アクセス権限フィールドで、ドロップダウンリストから権限レベルを選択します。

重要
アクセス権限を追加すると、小さな感嘆符が表示される場合があります。感嘆符は、ユーザーが追加した権限が有効でないことを示します。これは、そのユーザーの別の「高位」権限セットに、対応するアクセス権限がすでに含まれているためです。例えば、「フルアクセス」を設定しているかどうか、または同じセクションにタイプが「*」で、アクセス権限が「すべて」である別の設定があるかどうかを確認してください。

別の例として、トラッキングデバイスを使用しているとします。ユーザーにはすべてのデバイスを表示できるようにしたいのですが、何も変更できないようにしたいとします。さらに、ユーザーはマップ上でデバイスの軌跡を追跡できるようにしたいとします。追跡は、フラグメントタイプ「c8y_Position」のイベントを使用して記録されます(センサー・ライブラリを参照)。そのためには、下の図で示すようにインベントリと「c8y_Position」をタイプに持つイベントに読み取り権限を割り当てます。

Permission example

ユーザーへのインベントリロールの割り当て

インベントリロールは、ユーザーとデバイスのグループに割り当てられます。

インベントリロールを割り当てるには、アカウントメニューのユーザーをクリックし、ユーザーリストでユーザーを選択してインベントリロールタブに切り替えます。

インベントリロールタブに、デバイスグループのツリーが表示されます。インベントリロールを割り当てるには、デバイスグループの右にある矢印をクリックします。関連するロールを選択し、適用をクリックします。ロールの詳細については、ロールの横にある情報アイコンにカーソルを合わせるか、インベントリロール をご覧ください。

重要
ユーザーがすでにインベントリ権限を含むグローバルロールを持っている場合、ここで設定したインベントリロールに関係なく、すべてのデバイスを表示または変更できます。

インベントリロールは、グループとその直接および間接的な配下にあるすべてのサブグループ、そしてこれらのグループ内のデバイスに継承されます。例えば、デバイスのグループのアラームに対する閲覧権限を持つロールを選択すると、ユーザーはこのグループ内のすべてのデバイスとサブグループのアラームを閲覧できます。

ユーザーがデバイスグループへのインベントリアクセス権を持っている場合、ユーザーはコックピットアプリケーションでそのデバイスグループのすべてのダッシュボードへのアクセス権も持ちます。

他のユーザーのインベントリロールをコピーすることもできます。ロールをコピーするには、別のユーザーからインベントリロールをコピーをクリックします。次のウィンドウで、リストからユーザーを選択し、コピーをクリックします。上部で、ロールを既存のユーザーロールにマージするか(デフォルト)、既存のユーザーロールを置き換えるかを選択できます。参照ユーザーを作成し、そこから権限をコピーできるため、ロールをコピーして多数のユーザーの権限を簡単に管理できます。

Copy roles

アクセス権限のトラブルシューティング

十分なアクセス権限のない状態で操作を実行しようとすると、エラーメッセージが表示されます。

アクセス権限のトラブルシューティングには、トップバーの右側にあるユーザーボタン(現在のユーザー名が表示)をクリックします。メニューから、拒否されたリクエストを選択します。次のウィンドウには、拒否されたリクエストの詳細が表示されます。アクセス権限の修正には、管理者ユーザーまたは製品サポートへお問い合わせください。

アプリケーションへのアクセス許可

アプリケーショへのアクセスタブには、テナントで使用可能なすべてのアプリケーションがアルファベット順に一覧表示されます。

ユーザーにアプリケーションを割当てるには、目的のアプリケーションを選択し、保存をクリックします。

アプリケーション管理の詳細については、管理 > アプリケーションの管理をご覧ください。

Application access

備考
ユーザーにすべてのアプリケーションを閲覧するグローバル権限がある場合、インフォメーションボックスが表示されます。

監査ログの表示

監査ログには、ユーザーが実行したオペレーションが表示されます。

監査ログリストを表示するには、アカウントメニューの監査ログをクリックします。ログエントリごとに、次の情報が表示されます。

説明
時間 オペレーションが処理されたサーバー時刻
イベント オペレーションのタイプ。例えば「アラームが作成されました」「スマートルールが削除されました」など。その下には、処理したユーザーが表示されます
説明 オペレーションに応じて、デバイス名、アラーム テキスト、操作ステータスなどの詳細情報を提供します
デバイス時間 オペレーションが処理されたデバイス時刻。サーバー時刻と異なる場合があります

最新の100個のログのみが表示されます。ページを下にスクロールして 読み込んでいます まで移動して、さらにログエントリを表示します。

Audit logs

備考
オペレーションがリアルタイムで更新されても、監査ログリストは自動更新されません。トップバーの右側にある再読み込みをクリックして、ログリストを最新のものに更新してください。

ログのフィルタリング

ログを簡単に検索するために、次の要素で絞り込むことができます。

フィルターを適用するには、各フィルター フィールドの横にある 適用 ボタンをクリックします。フィルターを破棄するには、適用 ボタンの横にある X アイコンをクリックします(フィルターが設定されている場合にのみ表示されます)。

アプリケーションの管理

Things Cloud プラットフォームは、アプリケーションとマイクロサービスを区別します。Things Cloud コンセプトガイドアプリケーションの開発 もご覧ください。

どちらも、ナビゲータの エコシステム メニューからアクセスできます。

Applications menu

アプリケーション

ナビゲータの エコシステム メニューで アプリケーション をクリックして、アカウント内のすべてのアプリケーションのリストまたはグリッドを表示します。

All applications

すべてのアプリケーション タブでは、テナントで使用できるすべてのアプリケーションを確認できます。 アプリケーションには次の 2 種類があります。

アプリケーションは、トップバーのアプリメニューから利用できます。

App switcher

登録済みアプリケーション

Things Cloud は、さまざまな目的に合わせて、さまざまなアプリケーションを提供します。インストールやオプションのサービスに応じて、利用可能なアプリケーションの選択肢がテナントに表示されます。

以下に、テナントでデフォルトで使用可能なすべてのアプリケーションを示します。さらに、多数のオプションのアプリケーションがテナントに登録されている場合があります。

備考
すべてのアプリケーションタブでは、登録されたアプリケーションは「登録済み」とラベルが付きます。登録されたアプリケーションは、ユーザーが追加、変更、または削除することはできませんが、テナント管理者のみが行うことができます。

デフォルトの登録済みアプリケーション

UI での名称 機能 APIでの識別 テクニカルタイプ
管理 アカウント管理者はユーザー、ロール、テナント、およびアプリケーションを管理できます administration Web アプリケーション
コックピット ビジネスの観点からIoTのアセットとデータを管理および監視します cockpit Web アプリケーション
デバイス管理 デバイスを管理および監視し、デバイスのリモートでの制御とトラブルシューティング devicemanagement Web アプリケーション
ストリーミング分析 Analytics Builder モデルと EPL アプリの管理と編集(有効な場合) Streaming Analytics Web アプリケーション

カスタムアプリケーション

カスタム アプリケーションは、次のような働きを行うことができます。

すべてのアプリケーション タブでは、カスタムアプリケーションに「カスタム」というラベルが付きます。

カスタムアプリケーションの追加

すべてのアプリケーション タブの右上にある アプリケーションを追加 をクリックします。

Add application methods
次に表示されるダイアログで、以下のいずれかの方法を選択します。
Webアプリケーションのアップロード
  1. すべてのアプリケーション タブの右上にある アプリケーションの追加 をクリックします。
  2. Webアプリケーションのアップロードを選択します。
  3. 次のダイアログで、zipファイルをドロップするか、ファイルシステムでファイルを参照します。

zipファイルがプラットフォームに正常にアップロードされると、アプリケーションが作成されます。

重要
zipファイルのルートディレクトリに index.htmlcumulocity.json が含まれている必要があります。含まれていない場合、アプリケーションは動作しません。

外部アプリケーションへのリンク
  1. すべてのアプリケーション タブの右上にある アプリケーションの追加 をクリックします。
  2. 外部アプリケーションを選択します。

    External application
  3. 次のウィンドウで、アプリケーションの名前を入力します。名前は、アプリケーションのタイトルとして表示されます。
  4. このアプリケーションを識別するアプリケーション・キーを入力します。
  5. アプリケーションにアクセスできる外部 URL を入力します。
  6. アプリケーションを追加をクリックしてアプリケーションを作成します。

フィールドの詳細については、後述の アプリケーションのプロパティ をご覧ください。

アプリケーションの複製

アプリケーションの複製は、登録済みアプリケーションを必要に応じてカスタマイズする場合に便利です。登録済みアプリケーションを複製すると、元のアプリケーションへのリンクを含む独自のアプリケーションとしてコピーが作成されます。

  1. すべてのアプリケーション タブの右上にある アプリケーションの追加 をクリックします。
  2. 次のダイアログで、既存のアプリケーションを複製を選択します。
  3. ドロップダウンリストから目的のアプリケーションを選択します。

    Duplicate application
  4. 次のウィンドウで、アプリケーションの名前を指定します。

    Duplicate application
備考
プラットフォームは、プレフィクス「feature-」の使用を制限しています。アプリケーション名にこのプレフィクスを使用してアプリケーションを作成することはできません。これは、複製アプリケーション機能が使用されている場合の既存のアプリケーションにも当てはまります。
  1. このアプリケーションの識別に使用されるアプリケーション・キーを指定します。
  2. アプリケーションを呼び出すURLの一部としてアプリケーションパスを指定します。元の登録済みアプリケーションのパスに設定すると、所有アプリケーションが登録済みアプリケーションを無効にします。
  3. 最後に、複製をクリックしてアプリケーションを作成します。

フィールドの詳細については、以下のアプリケーションのプロパティもご覧ください。

備考
「所有アプリケーション」で、登録済みの標準アプリケーションを無効にしたい場合、「所有アプリケーション」のパスを元の登録済みアプリケーションのパスに設定する必要があります。

アプリケーションのプロパティ

アプリケーションの詳細を表示するには、アプリケーションをクリックして プロパティ タブを開きます。

Application properties

プロパティ タブでは、各アプリケーションにアプリケーションのタイプ(HOSTED または EXTERNAL)に応じて、次の情報が表示されます。

フィールド 説明 ホスト(Webアプリケーション) 外部
ID アプリケーションを識別する一意のID 自動的に提供 自動的に提供
名前 アプリケーション名。トップバーとアプリメニューに、アプリケーションのタイトルとして表示されます 自動的に作成 ユーザーが指定
アプリケーション・キー アプリケーションを識別し、アプリケーションを登録可能にします。Things Cloud コンセプトガイドをご覧ください 自動的に作成 ユーザーが指定
タイプ アプリケーションタイプ ホスト 外部
パス アプリケーションを呼び出すURLの一部 自動的に作成 ユーザーが指定。例えば、アプリケーションのパスとして「hello」を使用する場合、アプリケーションのURLは「/apps/hello」になります

アプリケーションの編集

アプリケーションをクリックするか、エントリの右にあるメニューアイコンから編集をクリックします。

プロパティタブでは、アプリケーションタイプに応じて、複数のフィールドを変更できます(アプリケーションのプロパティ をご覧ください)。

重要
システムアプリケーション名は絶対に変更しないでください(「デバイス管理」「コックピット」など)。変更するとテナントの初期化に失敗します。

アプリケーションの削除

エントリの右にあるメニューアイコンをクリックし、削除をクリックします。

登録済みアプリケーションを上書きするアプリケーションを削除すると、現在登録済みアプリケーションはすべてのユーザーが使用できるようになります。さらに、ユーザーは登録済みアプリケーションの今後のアップグレードからもメリットを得ることができます。

登録済みアプリケーションを削除することはできません。これは、登録済みアプリケーションの所有者のみが実行できます。

アーカイブのアップロード

カスタム アプリケーションの場合、zip ファイルまたは mon ファイルをアップロードすることにより、作成された複数のファイルのバージョンを Things Cloud に保存することができます。各バージョンはアーカイブと呼ばれます。異なるバージョンを同時にアップロードし、これらのバージョンを切り替えることができます。

アーカイブのアップロード方法
  1. それぞれのアプリケーションをクリックして、アプリケーションのプロパティを開きます。
  2. アクティビティ ログ セクションの下部にあるプラス ボタンをクリックして、ファイルシステム内のアーカイブを参照するか、アーカイブ ファイルをドロップします。
  3. アップロードをクリックして、アーカイブを Things Cloud アカウントにアップロードします。
Application archive
アップロードされると、最新でアップロードされたバージョンが自動的にアクティブなバージョンとなります。これは、アカウントのユーザーに現在提供されているアプリケーションのバージョンとなります。このバージョンは削除できません。

備考
アプリケーションの所有者のみが、このアクションを実行できるため、登録済みアプリケーションではアーカイブ機能を使用できません。

アプリケーションを旧バージョンへ復元

ユーザーは、アーカイブからアプリケーションを旧バージョンへ復元することができます。

  1. それぞれのアプリケーションをクリックして、アプリケーションのプロパティを開きます。
  2. アクティビティ ログ セクションでメニューアイコンをクリックして、目的のバージョンのコンテキストメニューを開き、アクティブ化 を選択して、有効なバージョンにします。

単一のアプリケーションを再アクティブ化

ホストされたアプリケーションが正しくデプロイされていない場合、ユーザーは再アクティブ化できます。

  1. それぞれのアプリケーションをクリックして、アプリケーションのプロパティを開きます。
  2. アクティビティ ログ セクションでメニューアイコンをクリックして、目的のバージョンのコンテキストメニューを開き、アーカイブを再アクティブ化 を選択します。
アプリケーションの更新
選択したアプリケーションは、アプリケーションディレクトリから該当ファイルを削除し、ホストアプリケーションパッケージを再度展開することで、再アクティブ化されます。

機能

機能とは、明示的なアーティファクト(マイクロサービスや Web アプリケーションなど)によって表わせられない組み込みのアプリケーションです。

機能 タブには、テナントで登録されているすべての機能のリストが表示されます。

備考
ここにリストされているすべてのアプリケーションは、タイプが「Feature」です。

テナントの個々のサブスクリプションによって、他の機能が表示される場合があります。

マイクロサービスの管理と監視

ナビゲータの エコシステム メニューで マイクロサービス をクリックして、アカウントに登録されているすべてのマイクロサービスのリストまたはグリッドを表示します。

Microservices list

マイクロサービスは特定タイプのアプリケーションであり、Things Cloud 上にさらなる機能を開発するために使用されるサーバー側アプリケーションです。

登録済みマイクロサービス

Things Cloud は、さまざまな目的に合わせて、さまざまなマイクロサービス アプリケーションを提供します。インストールおよび/またはオプションのサービスに応じて、利用可能なアプリケーションの選択肢がテナントに表示されます。

以下に、テナントに デフォルトで登録されているすべてのマイクロサービスのリストを示します。さらに、多数のオプションのマイクロサービスがテナントに登録されている場合があります。

デフォルトの登録済みマイクロサービス

UI での名称 機能 APIでの識別
Apama-ctrl-05c-1g 完全なApamaマイクロサービス。 Analytics Builder、EPLアプリ、およびスマートルールのランタイム apama-ctrl-05c-1g
Apama-ctrl-smartrules Apamaマイクロサービスの制限付きバージョン。スマートルールのみのランタイム。Analytics Builderモデルまたは EPLアプリは利用できません apama-ctrl-smartrules
Device-simulator IoTデバイスのあらゆる側面をシミュレート device-simulator
Report-agent コックピット アプリケーション内からデータのエクスポートをスケジュールする report agent
Smartrule スマートルール エンジンを使用して、リアルタイム データに基づいてアクションを実行するスマートルールを作成します。次のいずれかのマイクロサービスが必要です:apama-ctrl-1c-4g、apama-ctrl-starter またはapama-ctrl-smartrules smartrule
備考
ここにリストされているすべてのアプリケーションは、タイプが「Microservice」です。

マイクロサービスのプロパティ

マイクロサービスの詳細を表示するには、マイクロサービスをクリックして プロパティ タブを開きます。

Microservice properties

プロパティ タブでは、各マイクロサービスに次の情報が表示されます。

フィールド 説明 コメント
ID マイクロサービスを識別する一意のID 自動的に提供
名前 アプリケーション名。トップバーにマイクロサービス アプリケーションのタイトルとして表示されます マイクロサービスのマニフェストファイルで指定されていない限り、zipファイル名から自動的に推測されます(認識されたバージョン番号は削除されます)
アプリケーション・キー マイクロサービス アプリケーションを識別し、マイクロサービスを登録可能にします。Things Cloudコンセプトガイドをご覧ください zipファイル名に基づいて自動的に作成
タイプ アプリケーションタイプ Microservice
パス アプリケーションを呼び出す URLの一部 .../service/< microservice-name >として自動的に作成

マイクロサービスのアクセス権限

アクセス権限 タブでは、各マイクロサービスに必要なアクセス権限と、提供されているロールを表示できます。

Microservice permissions

マイクロサービスの監視

Things Cloud がホストするマイクロサービスは、2つの方法で監視できます。

ステータス情報

マイクロサービスのステータスは、目的のマイクロサービス アプリケーションの ステータス タブより確認することができます。

Microservice status
ステータスを表示するには、アプリケーション管理の読み取りロールとインベントリの読み取りロールの権限が必要です。

ステータス タブには、次の情報が表示されます。

ステータス情報は、登録済みアプリケーションと所有アプリケーションで利用できます。 登録済みサブテナントに関する情報は、アプリケーションの所有者にのみ表示されます。

アラームとイベント

ステータスタブに表示されるほとんどのアラームとイベントは、マイクロサービスで何が起こっているかを厳密に技術的に説明したものです。

利用者向けのアラームタイプは2つあります。

上記のアラームは、マイクロサービス所有者のテナントに対してのみ作成されます。また、状況が正常に戻る、つまりすべてのマイクロサービス インスタンスが正常に動作している状態に戻ると、自動的にクリアされます。

これらのアラームはスマートルール作成にも利用できます。さまざまなタイプのスマートルールの作成についての詳細はスマートルールをご覧ください。

例えば、マイクロサービスがダウンしたときにメールを送信する場合は、「アラーム時に電子メールを送信」というスマートルールを作成します。

次のタイプのアラームの場合: セクションで、アラームタイプとしてc8y_Application_Downを使用します。対象アセットとして、例えば「echo-agent-server」など、監視するマイクロサービスを選択します。

ログファイル

Things Cloudは、閲覧ログを表示して、マイクロサービスのステータスに関する、より詳細な情報を提供します。

ログを表示するには、目的のマイクロサービスの ログ タブを開きます。

Microservice log

ページ上部で、ログを表示するマイクロサービスのインスタンスを選択できます。

備考
マイクロサービスが2つのインスタンスへと規模を変更した場合はインスタンスを切り替えることができますが、両方のインスタンスからのログを同時に表示することはできません。

インスタンスのドロップダウンの横にあるカレンダーから日付を選択し、時刻を入力すれば、ログエントリが表示される時間の範囲を選択できます。

備考
ここで入力する時刻は、タイムゾーンの違いによりサーバー時刻と異なる場合があります。

右上には、次の追加機能があります。

最初に、ログタブにマイクロサービス インスタンスの最新のログが表示されます。

右下には、ナビゲーションボタンがあります。

選択した時間範囲に利用可能なログがなかった場合、それに応じてメッセージが表示されます。

Microservice log
備考

以前に実行されていたインスタンスのログ、または 35MBを超える以前にローテーションされたログを表示することはできません。しかし、インスタンス内ではDockerコンテナが実行されており、(インスタンス全体ではなく)そのDockerコンテナのみが再起動した場合は、現在実行中のDockerコンテナと最近終了したDockerコンテナのログが表示されます。

ログは常に stdoutstderr の両方を使用してDockerコンテナから読み込まれ、ログ生成元によって区別/フィルタリングすることはできません。

ビジネスルールの管理

アラームマッピング

アラームマッピングを使用すると、アラームの重要度とテキストを変更して、業務の優先順位に合わせることができます。例えば、デバイスへの接続が失われると、デフォルトでは「メジャー」アラームになりますが、重大(クリティカル)な問題になる場合があります。これを変更するには、アラームマッピングを追加して、接続損失に関連するアラームを「クリティカル」に変更します。

ビジネスルールメニューのアラームマッピングをクリックすると、すべてのアラームマッピングのリストが表示されます。

Alarm mapping
アラームマッピングごとに、アラームの重大度、アラームタイプ、説明(オプション)が表示されます。

アラームマッピングの追加

  1. トップメニューバーの マッピングの追加 をクリックします。
  2. 変更するアラームのタイプを入力します。
  3. 新しい説明 フィールドに、必要に応じて、アラームの新しい説明を入力します。フィールドを空のままにすると、アラーム内の元来のテキストが保持されます。
  4. 新しい重大度を選択するか、「ドロップ」を選択してアラームを表示しないようにします。
  5. マッピングの追加 をクリックして設定を保存します。
備考
アラームマッピングとして提供されるアラームタイプは、アラームタイプ プレフィクス"<type-prefix>*"として解釈されます。例えば、"crit-alarm"タイプのアラームに対応するアラームマッピングを作成すると、このマッピングは、この値で始まるすべてのタイプ("crit-alarm-1"、"crit-alarm-2"、または"crit-alarm-xyz"など)のアラームに有効です。

アラームマッピングの編集

アラームマッピングの右端をクリックし、下へ展開すれば編集できます。説明とアラーム重大度の変更ができます。 アラームタイプは編集できません。

備考
保存せずに変更を破棄するには、リストを再読み込みします。
Edit alarm mapping

アラームマッピングの削除

アラームマッピングを削除するには、アラームマッピングの上にポインターを合わせ、表示される削除アイコンをクリックします。

データ管理

データ保持ルール

データ保持ルールにより、データを保持する期間を制御することができます。デフォルトとして、60日経過した履歴データはすべて削除されます(システム設定で設定可能)。

例えば、メジャーメントは90日間保存するが、アラームは10日間で削除するという設定も可能です。

通常、データ保持ルールは夜間に実行されます。データ保持ルールを編集しても、管理アプリケーションのホーム画面の使用状況セクションにはすぐに反映されません。

管理メニューのデータ保持ルールをクリックすると、アカウントに設定されているデータ保持ルールの一覧が表示されます。

Retention rules
ルールごとに、ルール名、削除するデータの詳細(フラグメントタイプ、タイプ、ソースについては、以下を参照)および最大保持期間(日数)が表示されます。

アスタリスク(*)は、どの値のデータもクリーンアップされることを示します。

データタイプ

次のデータタイプが、データ保持ルールの対象となります。

備考
データ保持ルールは、ファイルリポジトリに保存されているファイルには適用されません。

データ保持ルールの追加

  1. トップメニューバーのルールを追加をクリックします。
  2. 表示されたダイアログより、クリーンアップしたいデータタイプを選択します(アラーム、計測値、イベント、操作、一括操作、監査、またはすべて)。
  3. クリーンアップするデータをもっと細かく設定したい場合、フラグメントタイプを入力します。このルールに従ってすべての接続無効アラームをクリーンアップしたい場合、データタイプに「アラーム」を選択し、タイプ欄に「c8y_UnavailabilityAlarm」と入力します。
  4. 特定のデバイスからのデータのみ削除したい場合、デバイスIDをソース欄に入力します。
  5. 最大保持期間(日) を日数単位で入力します(最大許容値は10年分の日数です)。
  6. 保存ボタンをクリックして設定を保存します。

これで、データ保持ルールは一覧に追加されます。

備考
デフォルトとして最大保持期間を除く、すべての欄にはアスタリスク(*)が設定され、すべての値が含まれます。
備考
アラームは、ステータスが「クリア済み」でないと削除できません。

データ保持ルールの編集

編集したいルールの行をクリックし、表示された「データ保持ルールを編集」の画面より編集してください。

それぞれのフィールドの詳細については データ保持ルールの追加をご覧ください。

データ保持ルールの削除

削除したいルールの行の右にある削除アイコンをクリックして、データ保持ルールを削除します。

Delete retention rule
備考

すべてのデータ保持ルールは、互いに独立して順番に実行されます。したがって、2つのデータ保持ルールがある場合、最大保持期間がより長い具体的なルールと、最大保持期間がより短い一般的なルールで定義されているドキュメントのサブセットを定義します。すると、より一般的な単一のルールがあるかのように効果的に機能します。

例えば、次の 2 つのルールがあるとします。

Retention rules

ソースが12345に等しいものを含め、30日以上経過したc8y_Temperatureタイプのすべてのメジャーメントが削除されます。

一方、次のデータ保持ルールが定義されている場合:

Retention rules

データ保持プロセスは、30日以上経過したタイプc8y_Temperatureのメジャーメントを削除します。他のすべてのメジャーメントは、60日以上経過すると削除されます。

備考
ソース パラメータはデバイスIDです。定義されている場合、データ保持プロセスでは、ソースによって表されるデバイスに直接関連するドキュメントのみが削除され、デバイスが属する子デバイスやグループは削除されません。

ファイルリポジトリ内のファイル管理

ファイルリポジトリでは、アカウントに保存されているファイルの概要が表示されます。

管理メニューのファイルリポジトリをクリックして、ファイルの一覧を表示します。

ここで表示されるファイルはさまざまなソースから取得されます。これらは、ソフトウェア画像、デバイスから取得した構成スナップショット、デバイスからのログファイル、すべてのアプリケーション画面からアップロードしたwebアプリケーションがあります。

ファイルごとに、ファイル名、所有者、ファイルタイプ(image/bmp、text/csvなど)、サイズ、および最終更新日が表示されます。

Files Repository

ファイルシステムからファイルをアップロードする

トップメニューバーのファイルをアップロードをクリックします。

Files Repository download modal

表示されるダイアログボックスで、アップロードするファイルを選択します。複数ファイルをアップロードする場合は、ファイルを追加をクリックして別のファイルを選択します。ファイル フィールドの右側にある削除アイコンをクリックして、アップロードする前にファイルを削除することもできます。

アカウントからファイルをダウンロードする

目的の行の右にあるメニューアイコンをクリックし、ダウンロードをクリックします。

アカウントからファイルを削除する

目的の行の右にあるメニューアイコンをクリックし、削除をクリックします。

備考
ファイルが有効化されているアプリケーションに対応している場合は削除できません。ファイルを削除するには、まずアプリケーションを削除またはアップグレードしてください。

二要素認証

二要素認証(TFA)ユーザーが知っているもの(ユーザー名とパスワード)と所有しているもの(例えばスマートフォン)、または自身の一部(指紋など)という、2つの異なる要素を組み合わせて認証を完了するだけの、追加のセキュリティーレイヤです。TFAの設定方法の詳細については、認証設定 をご覧ください。

特定のユーザーに対してTFAが有効になっているかどうかを確認するには、ユーザーページに移動し、パスワード強度の列の右側にあるTFAステータスの列を確認します。鍵アイコンは、TFAが有効になっていることを示し、その上にポインターを置くと、使用されている手段が表示されます。

TFA status

TOTP (Google Authenticator)

ユーザーは自分のスマートフォンにTOTPアプリケーション(Google Authenticator 推奨)をインストールする必要があり、これはApp StoreとPlay Storeの両方で無料で入手できます。

設定方法

SMSの手段とは違い、TOTPは各ユーザーが設定しなければなりません。右上のユーザー設定を開いて、二要素認証を設定をクリックすると、設定を開始できます。

Trigger TOTP setup
TFAを有効にすると、ログイン時にQRコードが表示され、インストールされているTOTPモバイルアプリケーションでスキャンします。

QRコードの読み取りができない場合は、手動でシークレットを挿入することもできます。

TOTP setup process
処理後、モバイルアプリケーションは、認証プロセスを完了するために使用できる新しいコードを30秒ごとに生成します。

取り消し方法

設定は個々のユーザーが行う必要がありますが、シークレットを取り消すことができるのは、管理アプリケーションのテナント管理者のみです。そのため、ユーザーが電話を紛失したり、アプリケーションをアンインストールしたりした場合は、テナント管理者に連絡する必要があります。

TOTPは各ユーザーが個別に設定する必要がありますが、シークレットの取り消しは「ユーザー管理の管理者」権限を持つユーザーのみが行うことができます。

テナント管理者の観点から、シークレットを取り消す方法は次の通りです。

  1. 管理アプリケーションで、アカウント > ユーザーに移動し、ユーザー ページでユーザーを選択します。
  2. ログインオプションまで下へスクロールします。
  3. TOTP シークレットの取り消しをクリックします。
  4. 取り消しをクリックして確定します。
TOTP secret revoke

ユーザーのTOTP無効化

ユーザーが TOTP(およびTFA)の使用を完全にオフにしたい場合は、シークレットを無効にし、TOTPの強制を無効にする必要があります。

TOTPは各ユーザーが個別に設定する必要がありますが、シークレットの取り消しとTOTP強制の無効化は、「ユーザー管理の管理者」権限を持つユーザーのみ行うことができます。

ユーザーのTOTPを無効にする方法は次の通りです。

  1. 管理アプリケーションで、アカウント > ユーザーに移動し、ユーザー ページでユーザーを選択します。
  2. ログインオプションまで下へスクロールします。
  3. ユーザーに TOTP 設定を強制チェックボックスをオフにします。
  4. TOTP シークレットの取り消しをクリックします。
  5. 取り消しをクリックして確定します。
  6. 保存をクリックして変更を保存します。
TOTP disable user

設定の変更

設定メニューから、管理者はアカウントのさまざまな設定を管理できます。

認証設定の変更

ログインまたはTFA設定を表示または変更する場合は、設定メニューの認証をクリックします。

Password settings

備考
認証 メニューエントリを表示するには、「テナント管理」の管理者権限(ROLE_TENANT_ADMIN または ROLE_TENANT_MANAGEMENT_ADMIN)が必要です。

ログイン設定

優先するログインモードフィールドでは、次のオプションのいずれかを選択できます。

これらのログインモードは、ユーザーを認証するデフォルトの方法としてプラットフォームのアプリケーションによって使用されます。デバイス認証は変更されません。

重要
ログインモードを変更するたびに、強制的にログアウトされます。他のユーザーが変更を適用するには、ログアウトして再度ログインする必要があります。

パスワードの有効期限では、ユーザーがパスワードを変更しなければならなくなるまでの日数を指定して、ユーザーパスワードの有効期限を制限できます。ユーザーにパスワードの変更を強制したくない場合は、「0」を使用して、パスワードの有効期限を無制限(デフォルト値)にします。

備考
「devices」ロールを持つユーザーには、パスワードの有効期限は課されません。 これにより、デバイスのパスワードが期限切れになるのを防ぎます。

デフォルトでは、ユーザーは 8文字以上の任意のパスワードを使用できます。強力なパスワードを強制 (緑) を選択している場合、ユーザーは強度のあるパスワードを設定する必要があります。はじめに> Things Cloudへのアクセス方法 > パスワード変更をご覧ください。

備考
プラットフォーム管理者によって構成されている場合、「パスワードの有効期限」と「パスワード強度」は編集できない場合があります。

Basic Auth制限

ユーザーに対して OAI-Secure 認証が構成されている場合でも、プラットフォームを使用するデバイスとマイクロサービスに対しては引き続き Basic Auth (基本認証)を使用できます。より高いセキュリティーレベルを提供するために、Basic Auth を制限することができます。

Web ブラウザーに対して禁止 トグルを使用して、Web ブラウザーでの基本認証の使用を禁止します。さらに、次のパラメータを指定できます。

備考
信頼できるユーザーエージェントまたは禁止されているユーザーエージェントのリストに、ユーザーエージェントが見つからない場合、Things Cloud は外部ライブラリを使用する Web ブラウザーであるかどうかを確認しようとします。

OAI-Secure

OAI-Secure は、ユーザー名とパスワードによるログインもサポートする Basic Auth モードより安全な代替手段です。OAI-Secure モードでは、最初のリクエストの資格情報が、Web ブラウザーで Cookie として設定されるか、レスポンス本文で返される JWT トークンと交換されます。構成に基づいて、OAI-Secure は完全なセッション管理をサポートするか、ユーザーセッションの有効期間がトークンの有効期限によって制限される標準の JWT 認証として機能します。

セッション管理に関連する構成なしの OAI-Secure(セッション構成オフ)

セッションに関連する設定がない場合、OAI-Secure は特定の有効期間を持つ JWT トークンを発行します。トークンの有効期限が切れると、トークンの更新がサポートされていないため、ユーザーは強制的に再ログインされます。トークンの有効期間が短い場合、ユーザーは頻繁に再ログインする必要があるため、この動作はユーザーにとって非常に不便です。

セッション管理の構成を使用した OAI-Secure(セッション構成オン)

セッション構成で OAI-Secure を使用すると、より便利で安全になり、HTTP セッションに基づく認証と同様の動作を実現するために使用できます。

OAI-Secure トークンは、クライアント サイト (Web ブラウザー) でセッションIDとして機能します。 Cookie に格納されるこのようなトークンID は、事前構成された短い有効期間を持つことができます。次に、Things Cloud プラットフォームは、ユーザーの操作なしでセッションIDを更新する責任があります。 ユーザーのアクションによって、Web ブラウザーが Things Cloud にリクエストを送信するだけで十分です。次に、Things Cloud は、セッションIDの更新を実行する必要があるかどうかを調べ、必要に応じて操作を実行します。 Things Cloud は、テナント管理者がニーズに合わせて構成を調整できるように、この動作に関連する広範な構成を提供します。

セッション構成を使用 オプションが有効になっている場合、テナント管理者は次の設定をテナントレベルで構成できます。

フィールド 説明 デフォルト
ユーザー エージェントの検証が必要 オンにすると、1 つのセッションの範囲内で連続するリクエストのヘッダーで送信されたユーザーエージェントが比較され、ユーザーエージェントが変更されたリクエストは承認されません。 false
セッションの絶対的タイムアウト ユーザーが再認証なしで Things Cloud を使用できる最大期間を定義します。 14 日
セッション更新のタイムアウト 絶対的なタイムアウトよりも、はるかに短いことが予想されます。 Things Cloud が新しいトークン(セッションID)の提供を試みるまでの時間を定義します。更新は、Things Cloud が期限切れでないトークンを持つクライアントから HTTP リクエストを受信した場合、トークンを取得してからリクエストを実行するまでの時間が更新タイムアウトよりも長い場合にのみ行われます。 1 日
ユーザーごとの最大並行セッション数 各ユーザーが開始できるセッションの最大数を定義します(例えば、さまざまなマシンまたはブラウザ)。ユーザーがこの制限を超えた場合、最も古いセッションが終了し、ユーザーはこの特定デバイスからログアウトされます。 5 セッション
トークンの有効期限 トークンが有効な時間を定義します。ユーザーは、有効なトークンを使用してのみ Things Cloud にアクセスできます。この構成オプションは常に使用可能で、セッション構成には依存しません。以下のトークンと Cookie の設定をご覧ください。 2 日
備考

時間パラメータは、次のように相互に依存する必要があります:更新タイムアウト < トークンの有効期間 < 絶対的タイムアウト
さらに、更新タイムアウトは、トークンの有効期間の約半分にする必要があります。

したがって、OAI-Secure の標準的な使用例の推奨設定は次の通りです。

  • セッションの絶対的タイムアウト:28,800 秒(8 時間)
  • セッション更新のタイムアウト:2,700 秒(45 分)
  • トークンの有効期限:5,400 秒(90 秒)

このような構成では、セッションの最後のアクティビティがいつ実行されたかに応じて、アイドル タイムアウトは 45 ~ 90 分の範囲になります。

セッショントークンの更新中に、以前のトークンは取り消され、新しいトークンが提供されます。パラメータ renewal token delay は、このプロセスを円滑にし、ユーザーの邪魔にならないようにするために使用される遅延を定義します。古いトークンは、この期間(デフォルトは 1 分)は引き続き有効です。このようにして、新旧両方のトークンが Things Cloud によって受け入れられます。このパラメータは、プラットフォームレベルでのみ構成可能であり、テナント管理者は変更できません。

OAI-Secure によるトークン生成

OAI-Secure は、主にブラウザの Cookie に保存された JWT に基づいています。また、レスポンス本文で JWT を生成するためにも使用できます。トークンと Cookie の有効期間は、カテゴリ oauth.internal に属するテナントオプションによって構成できます。

ブラウザの Cookie に保存されている JWT トークンのデフォルトの有効期限は 2 週間です。これは、テナントオプションで変更できます。

最小許容値は 5 分です。

JWT トークンをブラウザに保存するために使用される Cookie には、テナントオプションで変更できる独自の有効期限があります。

デフォルト値は 2 週間です。また、ユーザーがブラウザを閉じたときに Cookie が削除されるように、任意の負の値に設定することもできます。

レスポンス本文の JWT の有効期限の設定

レスポンス本文で生成される JWT トークンの有効期限は、次のテナントオプションで構成されます。

詳細については、Things Cloud OpenAPI仕様 の Tenant API をご覧ください。

備考
マネジメントテナント への外部通信がブロックされている場合、安全な方法(SSH トンネル経由など)でのみテナントにアクセスできます。 これは、基本認証をそのまま使用できることを意味しています。 また、外部認可サーバーからの通信もブロックされるため、シングルサインオンは利用できません。 そのため、マネジメントテナント が外部通信をブロックするように設定されている場合、認証方法は自動的に「基本認証」に設定されます。

TFA設定

テナントにTFAを許可する場合は、二要素認証有効化にします(管理者のみ可能)。

次のオプションを選択できます。

備考
TOTP 方式は、ログインモード「OAI-Secure」でのみ使用できます。

保存をクリックして設定を適用します。

重要
TFA方式を変更するたびに、強制的にログアウトされます。 ユーザーの TFA 設定が消去され、再度設定する必要があります。
備考
「devices」ロールを持つユーザーは、TFA と TOTP から除外されます。 これは、TOTP がすべてのユーザーに強制されている場合にも当てはまります。

シングルサインオンの設定方法

Things Cloud は Azure Active Directoryなどの OAuth2 プロトコルを使用して、単一のサードパーティ認可サーバーでログインできるシングルサインオン機能を提供しています。現在、Authorization Code Grant は、JWT 形式のアクセス トークンでのみサポートされています。

備考
この機能は、Cookie 技術上に構築されています。使用するには、ブラウザの設定で Cookie を有効にする必要があります。

この機能は、Things Cloudバージョン 10.4.6 以降で有効になっています。正しい動作のためには、すべてのマイクロサービスでバージョン 10.4.6 以降のマイクロサービス SDK を使用する必要があります。

シングルサインオンオプションに切り替える前に、次のことが必須です。

構成設定

この機能を有効にするには、管理者は認可サーバとの接続を設定してください。これは、管理アプリケーションで行います。

認証ページのシングル サインオンタブをクリックします。

メイン画面左上から、テンプレートを選択できます。選択したオプションは、パネルの外観に影響します。デフォルトのテンプレートは「カスタム」で、OAuth2 Authorizaiton Code Grant をサポートしているすべての認可サーバーに利用できる、詳細な構成設定を行うことができます。他にも、よく知られた認可サーバー用に簡素化されたテンプレートが用意されています。次のステップでは、まず「カスタム」テンプレートの使用方法を説明し、次に Azure Active Directory 専用のテンプレートを説明します。

カスタムテンプレート

Custom authorization request

OAuthプロトコルはHTTPリクエストとリダイレクトの実行に基づいているので、一般的なリクエスト設定が提供されています。

シングルサインオンページの最初の部分は、リクエスト用の構成設定になります。ここでは、HTTPリクエストURL、リクエストパラメータ、トークンリクエスト、リクエストを更新する場合のヘッダーとボディが設定できます。認可メソッドは、POSTリクエストによってGET、トークン、および更新メソッドとして実行されます。

備考
各リクエストの body フィールドは、プレースホルダーに値を入力した後、「そのまま」リクエストで送信されることに注意してください。これは、Things Cloud によってエンコードされていないことを意味します。多くの認可サーバーでは、body 内の値を URL エンコード(x-form-urlencoded)する必要があります。 これは body フィールドに、すでにエンコードされた値を入力することで実現できます。

ログアウトリクエストの指定はオプションです。 フロントチャネル シングルログアウトを実行します。設定されている場合、ユーザーはThings Cloudからログアウトした後、定義された認可サーバーのログアウト URL にリダイレクトされます。

Custom logout request

シングルサインオンページの基本セクションは以下の設定から構成されています。

Custom basic configuration

フィールド 説明
リダイレクト URI リダイレクトパラメータ。${redirectUri} プレースホルダーとしてリクエスト定義で使用できます
クライアント ID OAuthの接続クライアントID。${clientId}プレースホルダーとしてリクエスト定義で使用できます
ボタン名 ログインページのボタンに表示される名前
トークン発行者 OAuthトークン発行者
プロバイダー名 プロバイダーの名前
対象 JWTのaudパラメータ
ログインページに表示 ログインオプションが有効かどうかを示します。

ユーザーはログインするたびに、アクセストークンの内容が検証されます。これがThings Cloudへのアクセスの基盤となります。次のセクションでは、JWTクレームとプラットフォームへのアクセスとの間のマッピングを示します。

Custom access mapping

上記の例で、ユーザーがログインを試みると、デコードされたJWTクレームは次のようになります。

{
  ...
  "user": "john.wick",
  ...
}

ユーザーには、グローバルロールの「business」とデフォルトアプリケーション「cockpit」が付与されます。

アクセスマッピングがユーザーアクセス トークンと一致しない場合、ユーザーがログインしようとすると、「アクセスが拒否されました」というメッセージが表示されます。これは、アクセスマッピングが定義されていない場合にも発生し、すべてのユーザーが SSO を使用してログインできなくなります。

下部のアクセスマッピングを追加をクリックすると、新しいルールを追加できます。 アクセスマッピング ステートメントは、次の図のように複数のチェックで構成できます。 およびをクリックすると、既存のステートメントにルールを追加できます。 ルールを削除するには、マイナスボタンをクリックします。

一致するすべてのアクセスマッピングから、新しいロールがユーザーに追加されます。あるアクセスマッピングステートメントがロール「admins」を割り当て、別のステートメントがロール「business」を割り当て、両方が定義された条件を満たす場合、ユーザーにはグローバルロール「business」および「admins」へのアクセス権が付与されます。

演算子として「=」を使用する場合、Valueフィールドにワイルドカードを使用できます。サポートされているワイルドカードはアスタリスク (*) で、0文字以上に一致します。例えば、「cur*」と入力すると「cur」、「curiosity」、「cursor」、および 「cur」 で始まるすべての文字列と一致します。「f*n」は「fn」、「fission」、「falcon」、および「f」で始まり「n」で終わるものすべてに一致します。

アスタリスク文字が文字通りに一致する必要がある場合は、バックスラッシュ (\) を追加してエスケープする必要があります。例えば、文字列「Lorem*ipsum」と完全に一致させるには、値を「Lorem\*ipsum」にする必要があります。

Custom access mapping

今回の場合、次のクレームが条件に一致します。

{
  ...
  "user": {
     "type": "human"
  },
  "role": [
     "ADMIN"
  ],
  ...
}

このように、「次の値内」オペレーターを介してリストに値が存在するかどうかを検証するオプションがあります。値は、他のオブジェクトに埋め込むこともできます。この場合、キー内のドットは埋め込みオブジェクトを調べることを意味します。

デフォルトでは、動的アクセスマッピングは、アクセストークンに基づいて、すべてのユーザーログインでユーザーロールを割り当てます。 つまり、Things Cloud 内のユーザーロールを変更することはできません。これは、次のユーザーログイン時に上書きされるためです。この動作を変更するには、アクセスマッピング セクションの下部にある ユーザー作成時にのみ動的アクセスマッピングを使用 をオンにします。

Custom access mapping

これをオンにすると、動的アクセスマッピングは、新しいユーザーがログインして初期ロールを埋める場合にのみ使用されます。すでにユーザーが Things Cloud に存在する場合、ロールは上書きも更新もされません。このオプションを選択すると、管理者はユーザー管理で SSO ユーザーのロールを編集することもできます。 詳細については、ユーザーガイド管理 > 権限の管理 をご覧ください。

ユーザーがアクセストークンを使用してログインする場合、ユーザー名はJWTクレームから取得できます。クレーム名は、ユーザーID 設定 画面で設定できます。 ユーザーID は、ログインプロセス中に承認サーバーからプラットフォームに送信される承認トークンペイロードの最上位フィールドに設定できます。監査ログで認証トークンを調べて、正しいフィールドが使用されていることを確認することをお勧めします( トラブルシューティング 参照)。

User ID configuration

定数値を使用 をオンにしている場合、SSO 経由で Things Cloud プラットフォームにログインする全ユーザーに対して、一定のユーザーID が使用されます。これは、SSO 経由でログインする全ユーザーが、Things Cloud プラットフォームで同じユーザーアカウントを共有することを意味します。このオプションの使用はお勧めしません。

次に、ユーザーデータのマッピング を構成できます。

User data mappings

ユーザーのログイン時に、名、姓、Eメール、電話番号などのユーザーデータも JWT クレームから取得できます。各フィールドは、JWT からデータを取得するために使用されるクレーム名を表します。ユーザーデータのマッピングの構成はオプションであり、管理者は必須フィールドのみを使用できます。構成が空であるか、クレーム名が JWT トークンで見つからない場合、ユーザーデータの値は空として設定されます。

エイリアスのマッピングは、シングルサインオン ログインのコンテキストでは使用されないため利用できません。

各アクセストークンは、署名証明書によって署名されます。現在、署名証明書を設定するオプションは3つあります。

  1. Azure AD証明書検出アドレスを指定します。

Signature verification Azure

  1. ADFSマニフェスト アドレスを指定します(ADFS 3.0の場合)。

Signature verification ADFS

  1. 証明書の公開鍵を手動で Things Cloud に提供します。証明書の定義には、アルゴリズム情報、公開鍵の値、有効期限が必要です。

Signature verification Custom

  1. JWKS(JSON Web Key Set)URI を指定します。JWKS は、認可サーバーによって発行されたトークンを検証するために使用される、公開鍵を含む一連の JWK オブジェクトです。

Signature verification JWKS

備考
Things Cloud は、(“n”, “e”) パラメータペアまたは「x5c」証明書チェーンのいずれかとして、RSA キーを使用する証明書のみをサポートします。他のキータイプ(楕円曲線など)はサポートされていません。

プレースホルダー

一部のフィールド内では、実行時に Things Cloud によって解決されるプレースホルダーを使用できます。使用可能なプレースホルダーは次の通りです。

プレースホルダー 説明
clientId クライアントID フィールドの値
redirectUri リダイレクト URI フィールドの値
code 認可リクエストに応じて認可サーバーから返されたコード
refreshToken トークンリクエスト後に認可サーバーから返されたリフレッシュトークン

これらのプレースホルダーは、承認リクエスト、トークンリクエスト、更新リクエスト、およびログアウトリクエストで、URL、本文、ヘッダー、およびリクエストパラメータのフィールドで使用できます。

フィールドでプレースホルダーを使用するには、ドル記号を前に付けた 2 つの中括弧内に入れます。

Placeholder standalone

プレースホルダーは、テキストの一部としても使用できます。

Placeholder text

プレースホルダーが正しいかどうかは検証されません。認識されない、またはスペルが間違っているプレースホルダーは、処理されずにテキストに残されます。

Azure ADとの統合

Azure ADの設定

Azure ADとの統合は正常に確認されました。構成手順は https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-codeをご覧ください。

Azure AD を構成するときは、完全なドメインアドレスをリダイレクト URI として使用します。このドキュメントでは、「http://documentation.je1.thingscloud.ntt.com/tenant/oauth」であると想定しています。リダイレクト URI は、単一ページ アプリケーションではなく、Web アプリケーションに対して設定する必要があります。Azure AD で必要な追加の手順はありません。

Keycloakとの統合

グローバルログアウト機能(バージョン 12.0.0 以降の Keycloak で利用可能)

Keycloak との統合により、管理者は OpenId Connect に基づくグローバルログアウト機能を使用できます。Keycloak 認可サーバーからのイベントは、ログインプロセスで使用するトークンと同じ方法で検証されるログアウトトークンとともに、すべてのアプリケーション(Things Cloudプラットフォームを含む)に送信されます。この機能により、特定ユーザーのアプリケーションと Keycloak の両側でセッションを終了できます。

グローバルログアウト機能を設定するには、次の手順を行います。

  1. 管理者コンソールに移動します。
  2. テナントの SSO 構成で使用されるレルムを選択します。
  3. 設定 セクションの クライアント に移動します。
  4. SSO 構成で使用されるクライアントを選択します。
  5. Backchannel Logout URL フィールドを「https://mytenant.je1.thingscloud.ntt.com/user/logout/oidc」に設定します。

グローバルログアウト機能を使用するには、次の手順を行います。

  1. 管理者コンソールに移動します。
  2. テナントの SSO 構成で使用されるレルムを選択します。
  3. 管理 セクションの ユーザー に移動します。
  4. 特定のユーザーを選択します。
  5. 管理 セクションの セッション タブに移動し、ログアウト をクリックします。
すべてのユーザーをログアウトする機能

Keycloakは、管理者がすべての SSO ユーザーをログアウトできる機能を提供します。

すべてのユーザーのログアウト機能を構成するには、次の手順を行います。

  1. 管理者コンソールに移動します。
  2. テナントの SSO 構成で使用されるレルムを選択します。
  3. 設定 セクションの クライアント に移動します。
  4. SSO 構成で使用されるクライアントを選択します。
  5. Admin URL を「https://mytenant.je1.thingscloud.ntt.com/user/keycloak」に設定します。

すべてのユーザーのログアウト機能を使用するには、次の手順を行います。

  1. 管理者コンソールに移動します。
  2. テナントの SSO 構成で使用されるレルムを選択します。
  3. 管理 セクションの セッション タブに移動し、すべてログアウトする をクリックします。

すべてのユーザーのログアウトイベントは、1 つの Keycloak レルムの範囲内でのみ実行されることに注意してください。 さらに、SSO 機能の構成として使用されているクライアントが正しい Admin URL 値を持つテナントに対してのみ送信されます。

セッション タブで、Keycloak管理者は、それぞれのクライアントに存在するアクティブなセッション数を確認し、ログアウトイベントによって影響を受けるテナントとユーザーの数を見積もることもできます。

全ユーザーまたは 1 人のユーザーのログアウトイベントがテナントによって受信されたかどうかを確認するために、Things Cloud 管理者は監査ログにログアウトイベントに関する情報があるかどうかを確認できます。監査ログは、管理アプリケーションのアカウント監査ログメニューで利用できます。

Things Cloudの設定

「Azure AD」テンプレートを選択すると、構成設定画面は次のようになります。

Azure Basic configuration Azure access mapping Azure user data mapping

フィールド 説明
Azure AD アドレス Azure ADテナントのアドレス
テナント Azure ADテナント名
アプリケーション ID アプリケーションのID
リダイレクト URI Things Cloud テナントの後に/tenant/oauthを追加したアドレス
クライアントシークレット Azure ADクライアントシークレット(ある場合)
ボタン名 ボタンに表示される名前
トークン発行者 HTTPアドレス形式のトークン発行者の値

オプションで、単一のログアウトを設定できます。

Azure logout request

フィールド 説明
ログアウト後にリダイレクト ログアウト後にユーザーを許可サーバーのログアウト・エンドポイントにリダイレクトすることにより、シングル・ログアウトをアクティブにします
リダイレクト URL 許可サーバーから正常にログアウトした後にユーザーをリダイレクトするアドレス

画面後半部分は「カスタム」テンプレートと同じく、アクセスマッピング、ユーザーデータのマッピング、ユーザーID フィールド、署名の確認用アドレスが表示されています。

トラブルシューティング

上述の構成設定に必要な情報が中には含まれているものもあるため、プラットフォームに送信されたトークンの内容を確認すると良いでしょう。

管理アプリケーションで アカウント > 監査ログ をクリックした後、カテゴリ「シングルサインオン」で絞り込み、「Json web token claims」を探します。

トークンの内容は JSON 形式で表示されます。

Audit token content

アプリケーション設定の変更

設定 メニューの アプリケーション をクリックして、アプリケーションの設定を変更します。

Default application

デフォルトアプリケーションでは、テナント内のすべてのユーザーに適用されるデフォルトアプリケーションをリストから選択できます。 例えば、特定のアプリケーションを指定せずにドメイン名のみでプラットフォームにアクセスすると、デフォルトアプリケーションとして選択されたアプリケーションが、デフォルトのランディング ページとして使用されます。

備考
すべてのユーザーは、このアプリケーションへのアクセスが必要です。

アクセス制御 から、管理者は Things Cloud API上で、クロスオリジン リソース共有(CORS)を使用可能にすることができます。

許可されたドメイン 設定により、JavaScript Webアプリケーションは REST API と直接通信できるようになります。

詳細については、http://enable-cors.org をご覧ください。

プロパティライブラリの管理

設定メニューのプロパティライブラリをクリックして、インベントリオブジェクト、アラーム、イベント、テナントにカスタムプロパティを追加します。

Properties library

カスタムプロパティを使用すると、Things Cloud 組み込みオブジェクトのデータモデルを拡張できます。次のカスタム値を作成できます。

備考
カスタムプロパティは、インベントリロールの権限に関係なく、テナントのすべての認証済みユーザに表示されます。

カスタムプロパティの追加

  1. 目的のプロパティのタブを選択し、プロパティを追加をクリックします。

    Add new property
  2. 表示されるダイアログボックスで、プロパティの識別子として固有の名前とラベルを指定します。そして、ドロップダウンリストからデータタイプを選択します。

  3. さらに、新しいプロパティの検証ルールを選択します。

チェックボックス 説明
必須 選択した場合、プロパティを指定する必要があります(アラームの作成中など)。プロパティタイプが「ブール値」の場合は使用できません。
デフォルト値 カスタムプロパティ フィールドに自動的に入力されるデフォルト値を指定します。タイプが「文字列」のプロパティでのみ使用できます。
最小値 最小の整数値を入力します。
最大値 最大の整数値を入力します。
最小長 文字列に必要な最小の長さを入力します。
最大長 文字列に必要な最大の長さを入力します。
正規表現 カスタムプロパティ フィールドに入力するために必要な正規表現を追加します。
  1. 保存 をクリックして、新しいプロパティを作成します。

カスタムプロパティの編集

  1. リスト内のプロパティ名をクリックして開きます。
  2. 編集を行います。フィールドの詳細については カスタムプロパティの追加 をご覧ください。
  3. 保存 をクリックして設定を保存します。

カスタムプロパティの削除

  1. リスト内のプロパティ名をクリックして開きます。
  2. 削除 をクリックしてプロパティを削除します。

接続設定の管理

接続ページでは、さまざまなプロバイダーの資格情報を管理できます。資格情報を追加または置換するには、管理者権限が必要です。

現在、次のプロバイダー設定を指定できます。

Provider settings

資格情報の入力または置換

  1. 目的のプロバイダーのタブに切り替えます。
  2. プロバイダーのURLを入力します。
  3. プロバイダープラットフォームの資格情報を入力します。プロバイダーに応じてこれらの資格情報は、プロバイダープラットフォームのユーザーアカウントの資格情報になるか、あるいは Things Cloud 接続ページで登録できる資格情報となります。プロバイダープラットフォームのユーザーアカウントに表示されます。
  4. 最後に、資格情報を保存をクリックして設定を保存します。

使用しているプロバイダーによっては、追加フィールドがある場合があります。追加フィールドについては、各エージェントのマニュアルで説明されています。プロトコル統合ガイド をご覧ください。