管理
管理アプリケーションを使用すると、アカウント管理者はユーザー、ロール、テナント、アプリケーション、およびビジネスルールを管理し、アカウントに関する多数の構成設定を行うことができます。
管理アプリケーションを使用すると、アカウント管理者はユーザー、ロール、テナント、アプリケーション、およびビジネスルールを管理し、アカウントに関する多数の構成設定を行うことができます。
ここでは、管理アプリケーションのすべての機能について詳しく説明します。このドキュメントの内容の概要については、以下をご覧ください。
セクション | コンテンツ |
---|---|
ホーム画面 | 容量使用状況と登録済みアプリケーションに関する情報の表示 |
テナントの管理 | サブテナントの管理方法 |
使用状況の統計 | サブテナントの使用状況統計の確認方法 |
ユーザーの管理 | ユーザーの追加、編集、無効化、または削除する方法 |
権限の管理 | グローバルロール と インベントリロールの追加および編集方法、ユーザーへの割り当て方法、アプリケーションへのアクセスを許可する方法 |
アプリケーションの管理 | Things Cloudアカウントでの登録済みアプリケーションの管理方法、および、カスタム アプリケーションの構成設定 |
ビジネスルールの管理 | アラームマッピングによってアラームの優先順位を変更する方法 |
データ保持の管理 | データの保持ルールの管理と設定方法、およびファイルリポジトリでの保存ファイルの管理 |
二要素認証 | ユーザーの二要素認証をアクティブ/非アクティブにする方法 |
設定の変更 | アプリケーション設定や認証設定などのアカウント設定の変更方法、プロパティライブラリの管理方法、 シングルサインオンの構成方法 |
管理アプリケーションのホーム画面には、以下が表示されます。
使用状況には以下の情報が表示されます。
Things Cloud では、サブテナントの作成と管理ができるテナント機能を利用することができます。
テナント機能を使用するには、ユーザーに適切な権限が必要です。権限の編集の詳細については、 グローバルロールの追加をご覧ください。テナントの編集は機密性の高い操作であるため、テナントの編集権限はより細かくなります。
テナントメニューのサブテナントをクリックすると、アカウントで使用可能なすべてのサブテナントがグリッドまたは一覧で表示されます。
テナントページには、各サブテナントに関する次の情報が表示されます。
トップメニューバーの右にあるテナントを作成をクリックします。
次のプロパティを指定します。
フィールド | 説明 |
---|---|
ドメイン/ 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へのログイン方法をご覧ください)。 |
テナントポリシー | ドロップダウンリストから、テナントに適用するテナントポリシーを選択できます。 |
サブテナントが作成されると、自動生成されたIDが取得されます。このIDは変更できません。また、最初の管理ユーザー(管理者のユーザー名)が自動的に表示されます。この管理者は、他のユーザーを作成し、権限を設定できます。ロックアウトを防ぐため、最初のユーザーは削除することができません。
目的のサブテナントをクリックするか、サブテナントの右側にあるメニューアイコンをクリックして、編集をクリックします。
プロパティタブでは、ID、ドメイン/ URLと管理者のユーザー名以外のすべてのフィールドを編集できます。フィールドの詳細については、サブテナントの作成をご覧ください。
テナントのパスワードを変更するには、パスワードの変更をクリックし、次のフィールドに新しいパスワードを入力して、保存をクリックします。
テナントを一時停止すると、このテナントへのアクセスは、デバイス、ユーザー、またはその他のアプリケーションからのアクセスに関係なく、すべてブロックされます。 さらに、すべてのマイクロサービスがデプロイ解除され、テナントが再有効化されると、すべてのマイクロサービスが再デプロイされます。
テナントが停止された場合、テナントのデータはデータベースに残ったままになるので、有効化をクリックすることで再度使用可能になります。
各サブテナントの右側にあるメニューアイコンをクリックして、一時停止をクリックします。
表示されるダイアログボックスで、一時停止をクリックしてパスワードを入力し、停止を確認します。
停止されるテナント管理者の構成設定でメールアドレスが指定されている場合は、一時停止の一環として、そのテナント管理者にメールが送信されます。
テナントの管理者は、アクティブなサブテナントを一時停止することはできますが、削除することはできません。
アプリケーションタブでは、登録しているすべてのアプリケーションを表示したり、テナントをアプリケーションに登録したり、テナントからアプリケーションを削除したりできます。テナントは、デフォルトで標準 Things Cloud アプリケーションが登録されます。
右側の利用可能なアプリケーションの下のアプリケーションにカーソルを合わせ、目的のアプリケーションで登録をクリックします。
左側の登録済みアプリケーションの下にあるアプリケーションの上にカーソルを合わせ、登録解除をクリックします。
Things Cloudによってマイクロサービスとしてホストされているすべてのアプリケーションは、名前の横に表示される記号でそのステータスを確認することができます。
各エントリを展開すると、ステータスの詳細を表示できます。
詳細については、各アプリケーションの プロパティを参照してください。アプリケーションの管理をご覧ください。
カスタム プロパティタブでは、定義済みプロパティ(「外部参照」など)または プロパティライブラリ で定義されているカスタム プロパティの値を表示および編集できます。これらのプロパティは、使用状況の統計ページの列としても表示されます。
プラットフォーム管理者は、次のカスタム プロパティより、各サブテナントのリクエスト頻度を制限できます。
リクエスト調整メカニズムは、両方のHTTPプロパティ(「HTTPキューを制限」と「HTTPリクエストを制限」)が構成されている場合にのみ有効になります。値の1つが省略されていると機能しません。
また、特定のテナントのCEPキューおよびデータブローカキューのバッファサイズをカスタマイズすることもできます。これは、次のサブテナントカスタムフラグメントを使用して、管理テナントから実行できます。
テナントおよびシステムレベルで制限がない場合、制限機能は無効とみなされ、テナントは無制限にアクセスできます。制限を付けた後に、リクエスト頻度の制限をオフにする場合は、値を「-1」に設定してください。
プラットフォーム管理者は「デバイスの数を制限」というカスタム プロパティから、同時に登録されるルートデバイスまたはすべてのデバイス(子デバイスを含む)の数を制限できます。
同時に登録されているデバイスの最大数、ルートデバイス、およびストレージ使用量の最大値は、使用状況の統計ページに表示されます。
テナントポリシーとは、テナントオプションとデータ保持ルールのセットです。テナントオプションと保持ルールは、テナントの作成時に指定できます。
テナントメニューのテナントポリシーをクリックすると、利用可能なテナントポリシーがすべて表示されます。
テナント ポリシーがテナント ポリシー一覧に追加されます。
該当するポリシーをクリックするか、ポリシーの右側にあるメニューアイコンをクリックして、編集をクリックします。
表示されるウィンドウで編集を行い、保存をクリックして設定を保存します。
ポリシーからデータ保持ルールまたはテナントオプションを削除するには、その上にカーソルを合わせ、削除アイコンをクリックします。
複製するテナントポリシーのメニューアイコンをクリックし、複製をクリックします。
削除するテナントポリシーのメニューアイコンをクリックし、削除をクリックします。
使用状況の統計ページには、各サブテナントの統計情報が表示されます。
サブテナントごとに次の情報が提供されます(スペースが限られているため、上のスクリーンショットではすべての項目は表示されていません)。
フィールド | 説明 |
---|---|
ID | サブテナントのID |
テナント | サブテナント名 |
APIリクエスト | デバイスおよびアプリケーションからのリクエストを含む、APIリクエスト総数 |
デバイスからのAPIリクエスト | デバイスからのAPIリクエスト数 |
ストレージ(MB) | アカウントに保存されているデータ量 |
ピークストレージ(MB) | ストレージのピーク値 |
ルートデバイス | 子デバイスを除くルートデバイス数 |
ルートデバイスのピーク数 | 子デバイスを除くルートデバイスのピーク数 |
デバイス | 子デバイスを含む、サブテナントに接続されたデバイスの合計数 |
デバイスのピーク | 子デバイスを含むデバイスのピーク数 |
エンドポイントのデバイス | ゲートウェイやエッジを除くリーフデバイス |
登録済みアプリケーション | サブテナントにサブスクライブされているアプリケーション数 |
作成日時 | サブテナントの作成日時 |
アラームが作成されました | 作成されたアラーム数 |
アラームが更新されました | 更新されたアラーム数 |
インベントリが作成されました | 作成されたマネージドオブジェクト数 |
インベントリが更新されました | 更新されたマネージドオブジェクト数 |
イベントが作成されました | 作成されたイベント数 |
イベント更新済み | 更新されたイベント数 |
作成された計測値 | 作成されたメジャーメント数 |
受信転送合計 | すべての受信転送の合計(アラームの作成、アラームの更新、作成イベント、更新イベント、インベントリの作成、インベントリの更新、メジャーメントの作成) |
CPU (M) | マイクロサービスのCPU使用率(CPUミリ秒で指定) |
メモリ (MB) | マイクロサービスのメモリ使用量 |
外部参照 | 例えば、CRM システムへのリンクをここに追加したり、内部顧客番号を追加するなど、個別の用途に使用します |
さらに、カスタム プロパティが設定されている場合は表示されます。
カスタムプロパティは、プロパティ ライブラリで定義し、テナントのカスタム プロパティタブで値を設定できます。
上部のメニューバーに開始日と終了日を追加して 適用 をクリックすると、ある期間の使用統計リストをフィルター処理できます。使用状況の統計ページには、この期間のすべてのサブテナントの数値が表示されます。
列名の横にあるフィルターアイコンをクリックし、フィルター条件を指定して、任意の列のリストをフィルター処理したり、並べ替えることもできます。はじめに > UIの機能と特長 > 絞り込み(フィルタリング)をご覧ください。
上部のメニューバーの右側にある CSVをエクスポート をクリックして、統計テーブルの現在のビューをCSVファイルにエクスポートします。
表示されるダイアログボックスで、フィールド区切り記号、小数点記号、および文字セットを指定して、CSV出力をカスタマイズできます。
ダウンロード をクリックしてエクスポートを開始します。
CSV ファイルがダウンロードされます。
使用統計は、リクエスト数のような進行する値と、特定の期間における状態のスナップショットである値で構成されます。後者のタイプのデータの場合、値は毎日数回更新されますが、EOD (End of the Day - 1日の終わり) からの値は特定の日に割り当てられた値です。
値のタイプ | 更新 |
---|---|
リクエスト数フラッシュ | 5分ごと |
使用済みストレージ | 9、17およびEOD |
デバイス数 | 9、17およびEOD |
登録されたアプリケーション | 9、17およびEOD |
テナント
Things Cloudプラットフォームテナントには、いくつかの状態があります。
ユーザー管理機能を使用すると、テナント内のユーザーを管理でき、次の機能が提供されます。
テナント内のすべてのユーザーを表示するには、ナビゲータの アカウント メニューで ユーザー をクリックします。
ユーザーリストが表示され、ユーザーごとに次の情報が提供されます。
リストをユーザー名で絞り込むには、トップメニューバーの左側にあるフィルター フィールドを使用します。ドロップダウン リストを使用すると、グローバルロールで絞り込みができます。フィルタリングの詳細については、はじめに > UI の機能と特長 > 絞り込み(フィルタリング) をご覧ください。
選択したフィルターを適用するには、適用 をクリックします。
トップメニューバーの右側にあるユーザーを追加をクリックします。
新しいユーザーウィンドウの左側から、ユーザーを識別するために次の情報を入力してください。
フィールド | 説明 |
---|---|
ユーザー名 | システム内でユーザーを識別するための一意のユーザーIDです。ユーザーの作成後にユーザー名を変更することはできません。このフィールドは必須です。ユーザー名に日本語を用いることはできません |
ログイン エイリアス | ユーザー名に加えて、ログオンに使用するエイリアスをオプションで指定できます。このエイリアスは必要に応じて変更できます |
ステータス | ユーザーアカウントを有効/無効にします。ユーザーアカウントが無効になっている場合、ユーザーはログインできません |
Eメール | 有効なメールアドレスです。これは、ユーザーがパスワードをリセットできるようにするために必要です。このフィールドは必須です |
名 | ユーザーの名前。ユーザーがログインすると、この名前がユーザーボタンのトップバーの右側に表示されます |
姓 | ユーザーの姓 |
電話番号 | 有効な電話番号です。ユーザーが二要素認証を使用する場合は必須項目となります |
ユーザーのログインオプションを選択します。
ページの右側から、ユーザーのグローバルロールを選択します。グローバルロールの詳細については、権限の管理をご覧ください。
保存をクリックして設定を保存します。
新規ユーザーがユーザーリストへ追加されます。
選択されたユーザーのインベントリロールをコピーします。
変更したい列の右側にあるメニューアイコンをクリックし、無効化をクリックします。無効化されているユーザーを有効にするには、有効化をクリックします。
削除したいユーザの列の右側にあるメニューアイコンをクリックし、削除をクリックします。
権限では、ユーザーが Things Cloud アプリケーションで実行を許可される内容を定義します。権限をより簡単に管理するために、「ロール」と呼ばれるグループにまとめられています。すべてのユーザーは、権限を追加しながら複数のロールに関連付けることができます。
次のタイプのロールをユーザーに関連付けることができます。
さらに、ユーザーがアプリケーションを使用できるようアプリケーションアクセスを付与することができます。
アカウントメニューのロールをクリックして、構成設定済みのロールの一覧を表示します。
グローバルロールタブには、システムレベルで権限を付与するロールがあります。既定でグローバルロールがいくつか定義されていますが、必要に応じて独自のロールを定義できます。
定義済みロールは、特定の目的のためのサンプルとして構成されています。これらを出発点として使用し、個々のニーズにおいて、さらに適合させることができます。
新しいユーザーを作成するとき、割り当てられた各ロールによって、ユーザーに割り当てるグローバルロールに特定ユーザー関連の必要なすべての権限が含まれていることを確認します。 異なるロールの権限は、同じユーザーに割り当てられるとマージされます。 例えば、ユーザーが「コックピット ユーザー」ロール(以下参照)しか持っていない場合、ユーザーはコックピット アプリケーションのみアクセスでき、それ以上はアクセスできません。ただし、利用可能なロールの一部を介してインベントリのアクセス許可を割り当てると、ユーザーはデバイス、グループ、構成などのインベントリ全体にアクセスできるようになります。
「admins」と「devices」のロールには特別なステータスがあります。
ロール | 説明 |
---|---|
admins | 管理者権限が有効になっています。テナントで最初に作成された初期管理者がこのロールを持ちます |
devices | デバイスの一般的な権限の設定。登録後、デバイスは自動的にこのロールを持ちます。デバイスが必要とするアクセス許可が既定より少ないか多い場合に、このロールを編集するか、デバイスに他のロールを割り当てます |
さらに、次のロールがデフォルトで設定されています。
ロール | 説明 |
---|---|
CEPマネジャー | すべてのスマートルールおよびイベント処理ルールにアクセスできます |
コックピットユーザー | コックピットアプリケーションにアクセスできます。さらに、デバイスへのアクセスを許可するロールを追加する必要があります |
デバイス管理ユーザー | デバイス管理アプリケーションにアクセスできます。ユーザーはシミュレーターを使用して、一括操作を実行できます。さらに、デバイスへのアクセスを許可するロールを追加する必要があります |
グローバルマネージャー | すべてのデバイスに対し、閲覧、書き込みができます |
グローバルリーダー | すべてのデバイスを閲覧できます |
グローバルユーザーマネージャー | すべてのユーザーを管理できます |
共有ユーザーマネージャー | サブユーザーを管理できます。サブスクライブしているプランには、サブユーザーを管理できるようにユーザー階層を含める必要があります |
テナントマネージャー | 所有アプリケーション、データブローカー、データ保持、オプション、テナント統計など、テナント全体の設定を管理できます |
次のレガシーロールも表示される場合があります。
ロール | 説明 |
---|---|
business | すべてのデバイスとそのデータにアクセスできますが、テナントでの管理権限がありません |
readers | すべてのデータを閲覧できます(「グローバルリーダー」とは違い、ユーザー管理を含みます) |
グローバルロールタブでグローバルロールの追加をクリックします。
新しいグローバルロールページではアクセス権限タイプの一覧が左側に表示され、アクセス可能なアプリケーションの一覧が右側に表示されます。
次のスクリーンショットは、「admins」ロールの設定を示しています。
権限レベル
タイプごとに、次の権限レベルを選択できます。
それぞれのレベルをすべての権限タイプに設定するには、列の最上部にあるチェックボックスを選択します。
権限のカテゴリ
次の権限カテゴリは、デフォルトで使用可能です。
カテゴリ | 説明 |
---|---|
アラーム | アラームを閲覧、または編集 |
アプリケーション管理 | アカウントで使用可能なアプリケーションの閲覧と編集 |
監査 | 監査ログを閲覧、作成 |
一括操作 | 一括操作を閲覧、作成 |
CEP管理 | CEPルールの閲覧、編集 |
データブローカー | 他のテナントへデータを送信、または他のテナントからデータを受信 |
デバイス制御 | デバイスに送信するコマンドを表示、編集。デバイスにコマンドを送信。またデバイス登録にも使用されます |
イベント | イベントを閲覧、作成 |
グローバルスマートルール | グローバルスマートルールの構成設定 |
識別子 | デバイスの識別IDを閲覧、編集 |
インベントリ | インベントリデータの閲覧、編集 |
計測値(メジャーメント) | メジャーメントを閲覧、作成 |
オプション管理 | パスワードのポリシーなどのアカウントオプションを閲覧、編集 |
データ保持ルール | データ保持ルールの閲覧、編集 |
エクスポートをスケジュール | レポートのエクスポートスケジュール管理 |
シミュレーター | シミュレートされたデバイスの構築設定 |
SMS | SMSの構成(Things Cloud では本機能は利用できません) |
テナント管理 | サブテナントを閲覧、作成、編集、削除 |
テナント統計 | 管理アプリケーションのホーム画面に表示されている該当アカウントのデータ使用量を閲覧 |
ユーザー管理 | ユーザー、グローバルロール、アクセス権限を閲覧、編集 |
自身のユーザー管理 | 自身のユーザーを閲覧、編集 |
登録プランの機能によっては、追加の権限が表示される場合があります。それらは、各機能とともに説明されています。
グローバルロールをユーザーに割り当てるには、ユーザーリストで直接割り当てるか、目的のユーザー画面を開いて追加します。
インベントリロールには、デバイスのグループに割り当てることができる権限が含まれています。例えば、インベントリロールにデバイスを再起動する権限を含めるとします。そして、そのインベントリロールをデバイスグループ「Region North」とユーザー「smith」に割り当てるとします。その結果、ユーザー「smith」は、グループ「Region North」とそのサブグループ内のすべてのデバイスを再起動できるようになります。
現在設定されているインベントリロールを表示するには、アカウントメニューのロールをクリックし、インベントリ ロールタブに切り替えます。
インベントリロール タブでは、特定のグループやその配下にある子のユーザー権限を管理できます。デフォルトのインベントリロールがいくつか定義されていますが、必要に応じて独自のロールを定義できます。
新規テナントは、次のデフォルトのインベントリロールが最初から使用可能です。
ロール | 説明 |
---|---|
マネージャー | すべてのアセットのデータの読み取りとインベントリ内のデータの管理ができますが、オペレーションの実行はできません。 さらに、ダッシュボードを含むインベントリデータとアラームの管理ができます |
操作: すべて | デバイスにオペレーションを送信し、アセットを遠隔管理することができます (例:ソフトウェアのアップデート、リモート設定) |
操作: デバイス再起動 | デバイスの再起動ができます |
リーダー | アセットのデータをすべて閲覧することができます |
インベントリ ロールタブでインベントリ ロールの追加をクリックします。新しいインベントリ ロール ページで、名前 と 説明 を入力し、新しいインベントリ ロールに アクセス権限 を割り当てます。
アクセス権限は、次のカテゴリに分類されます。
カテゴリ | 説明 |
---|---|
アラーム | デバイスからのアラーム操作に関連する権限 |
監査 | 監査ログに関連する権限 |
イベント | デバイスからのイベント操作に関連する権限 |
インベントリ | デバイスを閲覧および編集するための権限 |
計測値(メジャーメント) | メジャーメントに関連する権限 |
デバイス制御 | デバイスを遠隔制御するための権限 |
フルアクセス | 構成設定を簡素化するための、関連するデバイスへの完全なアクセス権 |
目的のカテゴリの横にあるプラスアイコンをクリックして、ロールに権限を追加します。
タイプフィールドで、タイプを指定して、アクセス権限が適用されるデータタイプをさらに制限します。アクセスは、指定された タイプ を含むオブジェクトにのみ許可されます。
例えば、デバイスが「c8y_SignalStrength」などのデバイス管理に関連するメジャーメントと、実際の生産メジャーメントを送信するとします。デバイス管理メジャーメントのみをユーザーに表示したい場合、タイプとして「c8y_SignalStrength」と入力します。これにより、ユーザーは「c8y_SignalStrength」タイプを含むメジャーメントのみを表示できます。ユーザーは、同じメジャーメント オブジェクトの一部となりえる他のタイプを含んだ、メジャーメント オブジェクト全体を見れることを注意してください。
デフォルトでは、タイプフィールドにはすべてのタイプを選択するアスタリスク「*」が含まれています。
アクセス権限フィールドで、ドロップダウンリストから権限レベルを選択します。
別の例として、トラッキングデバイスを使用しているとします。ユーザーにはすべてのデバイスを表示できるようにしたいのですが、何も変更できないようにしたいとします。さらに、ユーザーはマップ上でデバイスの軌跡を追跡できるようにしたいとします。追跡は、フラグメントタイプ「c8y_Position」のイベントを使用して記録されます(センサー・ライブラリを参照)。そのためには、下の図で示すようにインベントリと「c8y_Position」をタイプに持つイベントに読み取り権限を割り当てます。
インベントリロールは、ユーザーとデバイスのグループに割り当てられます。
インベントリロールを割り当てるには、アカウントメニューのユーザーをクリックし、ユーザーリストでユーザーを選択してインベントリロールタブに切り替えます。
インベントリロールタブに、デバイスグループのツリーが表示されます。インベントリロールを割り当てるには、デバイスグループの右にある矢印をクリックします。関連するロールを選択し、適用をクリックします。ロールの詳細については、ロールの横にある情報アイコンにカーソルを合わせるか、インベントリロール をご覧ください。
インベントリロールは、グループとその直接および間接的な配下にあるすべてのサブグループ、そしてこれらのグループ内のデバイスに継承されます。例えば、デバイスのグループのアラームに対する閲覧権限を持つロールを選択すると、ユーザーはこのグループ内のすべてのデバイスとサブグループのアラームを閲覧できます。
ユーザーがデバイスグループへのインベントリアクセス権を持っている場合、ユーザーはコックピットアプリケーションでそのデバイスグループのすべてのダッシュボードへのアクセス権も持ちます。
他のユーザーのインベントリロールをコピーすることもできます。ロールをコピーするには、別のユーザーからインベントリロールをコピーをクリックします。次のウィンドウで、リストからユーザーを選択し、コピーをクリックします。上部で、ロールを既存のユーザーロールにマージするか(デフォルト)、既存のユーザーロールを置き換えるかを選択できます。参照ユーザーを作成し、そこから権限をコピーできるため、ロールをコピーして多数のユーザーの権限を簡単に管理できます。
十分なアクセス権限のない状態で操作を実行しようとすると、エラーメッセージが表示されます。
アクセス権限のトラブルシューティングには、トップバーの右側にあるユーザーボタン(現在のユーザー名が表示)をクリックします。メニューから、拒否されたリクエストを選択します。次のウィンドウには、拒否されたリクエストの詳細が表示されます。アクセス権限の修正には、管理者ユーザーまたは製品サポートへお問い合わせください。
アプリケーショへのアクセスタブには、テナントで使用可能なすべてのアプリケーションがアルファベット順に一覧表示されます。
ユーザーにアプリケーションを割当てるには、目的のアプリケーションを選択し、保存をクリックします。
アプリケーション管理の詳細については、管理 > アプリケーションの管理をご覧ください。
監査ログには、ユーザーが実行したオペレーションが表示されます。
監査ログリストを表示するには、アカウントメニューの監査ログをクリックします。ログエントリごとに、次の情報が表示されます。
列 | 説明 |
---|---|
時間 | オペレーションが処理されたサーバー時刻 |
イベント | オペレーションのタイプ。例えば「アラームが作成されました」「スマートルールが削除されました」など。その下には、処理したユーザーが表示されます |
説明 | オペレーションに応じて、デバイス名、アラーム テキスト、操作ステータスなどの詳細情報を提供します |
デバイス時間 | オペレーションが処理されたデバイス時刻。サーバー時刻と異なる場合があります |
最新の100個のログのみが表示されます。ページを下にスクロールして 読み込んでいます まで移動して、さらにログエントリを表示します。
ログを簡単に検索するために、次の要素で絞り込むことができます。
フィルターを適用するには、各フィルター フィールドの横にある 適用 ボタンをクリックします。フィルターを破棄するには、適用 ボタンの横にある X アイコンをクリックします(フィルターが設定されている場合にのみ表示されます)。
Things Cloud プラットフォームは、アプリケーションとマイクロサービスを区別します。Things Cloud コンセプトガイド の アプリケーションの開発 もご覧ください。
どちらも、ナビゲータの エコシステム メニューからアクセスできます。
ナビゲータの エコシステム メニューで アプリケーション をクリックして、アカウント内のすべてのアプリケーションのリストまたはグリッドを表示します。
すべてのアプリケーション タブでは、テナントで使用できるすべてのアプリケーションを確認できます。 アプリケーションには次の 2 種類があります。
アプリケーションは、トップバーのアプリメニューから利用できます。
Things Cloud は、さまざまな目的に合わせて、さまざまなアプリケーションを提供します。インストールやオプションのサービスに応じて、利用可能なアプリケーションの選択肢がテナントに表示されます。
以下に、テナントでデフォルトで使用可能なすべてのアプリケーションを示します。さらに、多数のオプションのアプリケーションがテナントに登録されている場合があります。
UI での名称 | 機能 | APIでの識別 | テクニカルタイプ |
---|---|---|---|
管理 | アカウント管理者はユーザー、ロール、テナント、およびアプリケーションを管理できます | administration | Web アプリケーション |
コックピット | ビジネスの観点からIoTのアセットとデータを管理および監視します | cockpit | Web アプリケーション |
デバイス管理 | デバイスを管理および監視し、デバイスのリモートでの制御とトラブルシューティング | devicemanagement | Web アプリケーション |
ストリーミング分析 | Analytics Builder モデルと EPL アプリの管理と編集(有効な場合) | Streaming Analytics | Web アプリケーション |
カスタム アプリケーションは、次のような働きを行うことができます。
すべてのアプリケーション タブでは、カスタムアプリケーションに「カスタム」というラベルが付きます。
すべてのアプリケーション タブの右上にある アプリケーションを追加 をクリックします。
zipファイルがプラットフォームに正常にアップロードされると、アプリケーションが作成されます。
フィールドの詳細については、後述の アプリケーションのプロパティ をご覧ください。
アプリケーションの複製は、登録済みアプリケーションを必要に応じてカスタマイズする場合に便利です。登録済みアプリケーションを複製すると、元のアプリケーションへのリンクを含む独自のアプリケーションとしてコピーが作成されます。
フィールドの詳細については、以下のアプリケーションのプロパティもご覧ください。
アプリケーションの詳細を表示するには、アプリケーションをクリックして プロパティ タブを開きます。
プロパティ タブでは、各アプリケーションにアプリケーションのタイプ(HOSTED または EXTERNAL)に応じて、次の情報が表示されます。
フィールド | 説明 | ホスト(Webアプリケーション) | 外部 |
---|---|---|---|
ID | アプリケーションを識別する一意のID | 自動的に提供 | 自動的に提供 |
名前 | アプリケーション名。トップバーとアプリメニューに、アプリケーションのタイトルとして表示されます | 自動的に作成 | ユーザーが指定 |
アプリケーション・キー | アプリケーションを識別し、アプリケーションを登録可能にします。Things Cloud コンセプトガイドをご覧ください | 自動的に作成 | ユーザーが指定 |
タイプ | アプリケーションタイプ | ホスト | 外部 |
パス | アプリケーションを呼び出すURLの一部 | 自動的に作成 | ユーザーが指定。例えば、アプリケーションのパスとして「hello」を使用する場合、アプリケーションのURLは「/apps/hello」になります |
アプリケーションをクリックするか、エントリの右にあるメニューアイコンから編集をクリックします。
プロパティタブでは、アプリケーションタイプに応じて、複数のフィールドを変更できます(アプリケーションのプロパティ をご覧ください)。
エントリの右にあるメニューアイコンをクリックし、削除をクリックします。
登録済みアプリケーションを上書きするアプリケーションを削除すると、現在登録済みアプリケーションはすべてのユーザーが使用できるようになります。さらに、ユーザーは登録済みアプリケーションの今後のアップグレードからもメリットを得ることができます。
登録済みアプリケーションを削除することはできません。これは、登録済みアプリケーションの所有者のみが実行できます。
カスタム アプリケーションの場合、zip ファイルまたは mon ファイルをアップロードすることにより、作成された複数のファイルのバージョンを Things Cloud に保存することができます。各バージョンはアーカイブと呼ばれます。異なるバージョンを同時にアップロードし、これらのバージョンを切り替えることができます。
ユーザーは、アーカイブからアプリケーションを旧バージョンへ復元することができます。
ホストされたアプリケーションが正しくデプロイされていない場合、ユーザーは再アクティブ化できます。
機能とは、明示的なアーティファクト(マイクロサービスや Web アプリケーションなど)によって表わせられない組み込みのアプリケーションです。
機能 タブには、テナントで登録されているすべての機能のリストが表示されます。
テナントの個々のサブスクリプションによって、他の機能が表示される場合があります。
ナビゲータの エコシステム メニューで マイクロサービス をクリックして、アカウントに登録されているすべてのマイクロサービスのリストまたはグリッドを表示します。
マイクロサービスは特定タイプのアプリケーションであり、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 |
マイクロサービスの詳細を表示するには、マイクロサービスをクリックして プロパティ タブを開きます。
プロパティ タブでは、各マイクロサービスに次の情報が表示されます。
フィールド | 説明 | コメント |
---|---|---|
ID | マイクロサービスを識別する一意のID | 自動的に提供 |
名前 | アプリケーション名。トップバーにマイクロサービス アプリケーションのタイトルとして表示されます | マイクロサービスのマニフェストファイルで指定されていない限り、zipファイル名から自動的に推測されます(認識されたバージョン番号は削除されます) |
アプリケーション・キー | マイクロサービス アプリケーションを識別し、マイクロサービスを登録可能にします。Things Cloudコンセプトガイドをご覧ください | zipファイル名に基づいて自動的に作成 |
タイプ | アプリケーションタイプ | Microservice |
パス | アプリケーションを呼び出す URLの一部 | .../service/< microservice-name >として自動的に作成 |
アクセス権限 タブでは、各マイクロサービスに必要なアクセス権限と、提供されているロールを表示できます。
Things Cloud がホストするマイクロサービスは、2つの方法で監視できます。
マイクロサービスのステータスは、目的のマイクロサービス アプリケーションの ステータス タブより確認することができます。
ステータス タブには、次の情報が表示されます。
ステータス情報は、登録済みアプリケーションと所有アプリケーションで利用できます。 登録済みサブテナントに関する情報は、アプリケーションの所有者にのみ表示されます。
ステータスタブに表示されるほとんどのアラームとイベントは、マイクロサービスで何が起こっているかを厳密に技術的に説明したものです。
利用者向けのアラームタイプは2つあります。
c8y_Application_Down
- マイクロサービスインスタンスを利用できない場合に作成されるクリティカルアラームc8y_Application_Unhealthy
- 少なくとも1つのマイクロサービスインスタンスが正常に動作しているが、すべてが完全に動作しているわけではない場合に作成されるマイナーアラーム上記のアラームは、マイクロサービス所有者のテナントに対してのみ作成されます。また、状況が正常に戻る、つまりすべてのマイクロサービス インスタンスが正常に動作している状態に戻ると、自動的にクリアされます。
これらのアラームはスマートルール作成にも利用できます。さまざまなタイプのスマートルールの作成についての詳細はスマートルールをご覧ください。
例えば、マイクロサービスがダウンしたときにメールを送信する場合は、「アラーム時に電子メールを送信」というスマートルールを作成します。
次のタイプのアラームの場合: セクションで、アラームタイプとしてc8y_Application_Down
を使用します。対象アセットとして、例えば「echo-agent-server」など、監視するマイクロサービスを選択します。
Things Cloudは、閲覧ログを表示して、マイクロサービスのステータスに関する、より詳細な情報を提供します。
ログを表示するには、目的のマイクロサービスの ログ タブを開きます。
ページ上部で、ログを表示するマイクロサービスのインスタンスを選択できます。
インスタンスのドロップダウンの横にあるカレンダーから日付を選択し、時刻を入力すれば、ログエントリが表示される時間の範囲を選択できます。
右上には、次の追加機能があります。
最初に、ログタブにマイクロサービス インスタンスの最新のログが表示されます。
右下には、ナビゲーションボタンがあります。
選択した時間範囲に利用可能なログがなかった場合、それに応じてメッセージが表示されます。
以前に実行されていたインスタンスのログ、または 35MBを超える以前にローテーションされたログを表示することはできません。しかし、インスタンス内ではDockerコンテナが実行されており、(インスタンス全体ではなく)そのDockerコンテナのみが再起動した場合は、現在実行中のDockerコンテナと最近終了したDockerコンテナのログが表示されます。
ログは常に stdout
と stderr
の両方を使用してDockerコンテナから読み込まれ、ログ生成元によって区別/フィルタリングすることはできません。
アラームマッピングを使用すると、アラームの重要度とテキストを変更して、業務の優先順位に合わせることができます。例えば、デバイスへの接続が失われると、デフォルトでは「メジャー」アラームになりますが、重大(クリティカル)な問題になる場合があります。これを変更するには、アラームマッピングを追加して、接続損失に関連するアラームを「クリティカル」に変更します。
ビジネスルールメニューのアラームマッピングをクリックすると、すべてのアラームマッピングのリストが表示されます。
アラームマッピングの右端をクリックし、下へ展開すれば編集できます。説明とアラーム重大度の変更ができます。 アラームタイプは編集できません。
アラームマッピングを削除するには、アラームマッピングの上にポインターを合わせ、表示される削除アイコンをクリックします。
データ保持ルールにより、データを保持する期間を制御することができます。デフォルトとして、60日経過した履歴データはすべて削除されます(システム設定で設定可能)。
例えば、メジャーメントは90日間保存するが、アラームは10日間で削除するという設定も可能です。
通常、データ保持ルールは夜間に実行されます。データ保持ルールを編集しても、管理アプリケーションのホーム画面の使用状況セクションにはすぐに反映されません。
管理メニューのデータ保持ルールをクリックすると、アカウントに設定されているデータ保持ルールの一覧が表示されます。
アスタリスク(*)は、どの値のデータもクリーンアップされることを示します。
次のデータタイプが、データ保持ルールの対象となります。
これで、データ保持ルールは一覧に追加されます。
編集したいルールの行をクリックし、表示された「データ保持ルールを編集」の画面より編集してください。
それぞれのフィールドの詳細については データ保持ルールの追加をご覧ください。
削除したいルールの行の右にある削除アイコンをクリックして、データ保持ルールを削除します。
すべてのデータ保持ルールは、互いに独立して順番に実行されます。したがって、2つのデータ保持ルールがある場合、最大保持期間がより長い具体的なルールと、最大保持期間がより短い一般的なルールで定義されているドキュメントのサブセットを定義します。すると、より一般的な単一のルールがあるかのように効果的に機能します。
例えば、次の 2 つのルールがあるとします。
ソースが12345
に等しいものを含め、30日以上経過したc8y_Temperature
タイプのすべてのメジャーメントが削除されます。
一方、次のデータ保持ルールが定義されている場合:
データ保持プロセスは、30日以上経過したタイプc8y_Temperature
のメジャーメントを削除します。他のすべてのメジャーメントは、60日以上経過すると削除されます。
ファイルリポジトリでは、アカウントに保存されているファイルの概要が表示されます。
管理メニューのファイルリポジトリをクリックして、ファイルの一覧を表示します。
ここで表示されるファイルはさまざまなソースから取得されます。これらは、ソフトウェア画像、デバイスから取得した構成スナップショット、デバイスからのログファイル、すべてのアプリケーション画面からアップロードしたwebアプリケーションがあります。
ファイルごとに、ファイル名、所有者、ファイルタイプ(image/bmp、text/csvなど)、サイズ、および最終更新日が表示されます。
トップメニューバーのファイルをアップロードをクリックします。
表示されるダイアログボックスで、アップロードするファイルを選択します。複数ファイルをアップロードする場合は、ファイルを追加をクリックして別のファイルを選択します。ファイル フィールドの右側にある削除アイコンをクリックして、アップロードする前にファイルを削除することもできます。
目的の行の右にあるメニューアイコンをクリックし、ダウンロードをクリックします。
目的の行の右にあるメニューアイコンをクリックし、削除をクリックします。
二要素認証(TFA)ユーザーが知っているもの(ユーザー名とパスワード)と所有しているもの(例えばスマートフォン)、または自身の一部(指紋など)という、2つの異なる要素を組み合わせて認証を完了するだけの、追加のセキュリティーレイヤです。TFAの設定方法の詳細については、認証設定 をご覧ください。
特定のユーザーに対してTFAが有効になっているかどうかを確認するには、ユーザーページに移動し、パスワード強度の列の右側にあるTFAステータスの列を確認します。鍵アイコンは、TFAが有効になっていることを示し、その上にポインターを置くと、使用されている手段が表示されます。
ユーザーは自分のスマートフォンにTOTPアプリケーション(Google Authenticator 推奨)をインストールする必要があり、これはApp StoreとPlay Storeの両方で無料で入手できます。
SMSの手段とは違い、TOTPは各ユーザーが設定しなければなりません。右上のユーザー設定を開いて、二要素認証を設定をクリックすると、設定を開始できます。
QRコードの読み取りができない場合は、手動でシークレットを挿入することもできます。
設定は個々のユーザーが行う必要がありますが、シークレットを取り消すことができるのは、管理アプリケーションのテナント管理者のみです。そのため、ユーザーが電話を紛失したり、アプリケーションをアンインストールしたりした場合は、テナント管理者に連絡する必要があります。
TOTPは各ユーザーが個別に設定する必要がありますが、シークレットの取り消しは「ユーザー管理の管理者」権限を持つユーザーのみが行うことができます。
テナント管理者の観点から、シークレットを取り消す方法は次の通りです。
ユーザーが TOTP(およびTFA)の使用を完全にオフにしたい場合は、シークレットを無効にし、TOTPの強制を無効にする必要があります。
TOTPは各ユーザーが個別に設定する必要がありますが、シークレットの取り消しとTOTP強制の無効化は、「ユーザー管理の管理者」権限を持つユーザーのみ行うことができます。
ユーザーのTOTPを無効にする方法は次の通りです。
設定メニューから、管理者はアカウントのさまざまな設定を管理できます。
ログインまたはTFA設定を表示または変更する場合は、設定メニューの認証をクリックします。
ROLE_TENANT_ADMIN
または ROLE_TENANT_MANAGEMENT_ADMIN
)が必要です。優先するログインモードフィールドでは、次のオプションのいずれかを選択できます。
これらのログインモードは、ユーザーを認証するデフォルトの方法としてプラットフォームのアプリケーションによって使用されます。デバイス認証は変更されません。
パスワードの有効期限では、ユーザーがパスワードを変更しなければならなくなるまでの日数を指定して、ユーザーパスワードの有効期限を制限できます。ユーザーにパスワードの変更を強制したくない場合は、「0」を使用して、パスワードの有効期限を無制限(デフォルト値)にします。
デフォルトでは、ユーザーは 8文字以上の任意のパスワードを使用できます。強力なパスワードを強制 (緑) を選択している場合、ユーザーは強度のあるパスワードを設定する必要があります。はじめに> Things Cloudへのアクセス方法 > パスワード変更をご覧ください。
ユーザーに対して OAI-Secure 認証が構成されている場合でも、プラットフォームを使用するデバイスとマイクロサービスに対しては引き続き Basic Auth (基本認証)を使用できます。より高いセキュリティーレベルを提供するために、Basic Auth を制限することができます。
Web ブラウザーに対して禁止 トグルを使用して、Web ブラウザーでの基本認証の使用を禁止します。さらに、次のパラメータを指定できます。
User-Agent
ヘッダーに含み、有効な基本認証の日付を持つすべての HTTP リクエストが受け入れられます。User-Agent
ヘッダーに含み、基本認証を使用するすべての HTTP リクエストが拒否されます。OAI-Secure は、ユーザー名とパスワードによるログインもサポートする Basic Auth モードより安全な代替手段です。OAI-Secure モードでは、最初のリクエストの資格情報が、Web ブラウザーで Cookie として設定されるか、レスポンス本文で返される JWT トークンと交換されます。構成に基づいて、OAI-Secure は完全なセッション管理をサポートするか、ユーザーセッションの有効期間がトークンの有効期限によって制限される標準の JWT 認証として機能します。
セッションに関連する設定がない場合、OAI-Secure は特定の有効期間を持つ JWT トークンを発行します。トークンの有効期限が切れると、トークンの更新がサポートされていないため、ユーザーは強制的に再ログインされます。トークンの有効期間が短い場合、ユーザーは頻繁に再ログインする必要があるため、この動作はユーザーにとって非常に不便です。
セッション構成で 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 の標準的な使用例の推奨設定は次の通りです。
このような構成では、セッションの最後のアクティビティがいつ実行されたかに応じて、アイドル タイムアウトは 45 ~ 90 分の範囲になります。
セッショントークンの更新中に、以前のトークンは取り消され、新しいトークンが提供されます。パラメータ renewal token delay
は、このプロセスを円滑にし、ユーザーの邪魔にならないようにするために使用される遅延を定義します。古いトークンは、この期間(デフォルトは 1 分)は引き続き有効です。このようにして、新旧両方のトークンが Things Cloud によって受け入れられます。このパラメータは、プラットフォームレベルでのみ構成可能であり、テナント管理者は変更できません。
OAI-Secure は、主にブラウザの Cookie に保存された JWT に基づいています。また、レスポンス本文で JWT を生成するためにも使用できます。トークンと Cookie の有効期間は、カテゴリ oauth.internal
に属するテナントオプションによって構成できます。
ブラウザの Cookie に保存されている JWT トークンのデフォルトの有効期限は 2 週間です。これは、テナントオプションで変更できます。
oauth.internal
;basic-token.lifespan.seconds
;最小許容値は 5 分です。
JWT トークンをブラウザに保存するために使用される Cookie には、テナントオプションで変更できる独自の有効期限があります。
oauth.internal
;basic-user.cookie.lifespan.seconds
;デフォルト値は 2 週間です。また、ユーザーがブラウザを閉じたときに Cookie が削除されるように、任意の負の値に設定することもできます。
レスポンス本文で生成される JWT トークンの有効期限は、次のテナントオプションで構成されます。
oauth.internal
;body-token.lifespan.seconds
;詳細については、Things Cloud OpenAPI仕様 の Tenant API をご覧ください。
テナントにTFAを許可する場合は、二要素認証を有効化にします(管理者のみ可能)。
次のオプションを選択できます。
Google Authenticator(時間ベースのワンタイムパスワード=TOTP)は次の設定に対応しています。
保存をクリックして設定を適用します。
Things Cloud は Azure Active Directoryなどの OAuth2 プロトコルを使用して、単一のサードパーティ認可サーバーでログインできるシングルサインオン機能を提供しています。現在、Authorization Code Grant は、JWT 形式のアクセス トークンでのみサポートされています。
この機能は、Things Cloudバージョン 10.4.6 以降で有効になっています。正しい動作のためには、すべてのマイクロサービスでバージョン 10.4.6 以降のマイクロサービス SDK を使用する必要があります。
シングルサインオンオプションに切り替える前に、次のことが必須です。
この機能を有効にするには、管理者は認可サーバとの接続を設定してください。これは、管理アプリケーションで行います。
認証ページのシングル サインオンタブをクリックします。
メイン画面左上から、テンプレートを選択できます。選択したオプションは、パネルの外観に影響します。デフォルトのテンプレートは「カスタム」で、OAuth2 Authorizaiton Code Grant をサポートしているすべての認可サーバーに利用できる、詳細な構成設定を行うことができます。他にも、よく知られた認可サーバー用に簡素化されたテンプレートが用意されています。次のステップでは、まず「カスタム」テンプレートの使用方法を説明し、次に Azure Active Directory 専用のテンプレートを説明します。
OAuthプロトコルはHTTPリクエストとリダイレクトの実行に基づいているので、一般的なリクエスト設定が提供されています。
シングルサインオンページの最初の部分は、リクエスト用の構成設定になります。ここでは、HTTPリクエストURL、リクエストパラメータ、トークンリクエスト、リクエストを更新する場合のヘッダーとボディが設定できます。認可メソッドは、POSTリクエストによってGET、トークン、および更新メソッドとして実行されます。
ログアウトリクエストの指定はオプションです。 フロントチャネル シングルログアウトを実行します。設定されている場合、ユーザーはThings Cloudからログアウトした後、定義された認可サーバーのログアウト URL にリダイレクトされます。
シングルサインオンページの基本セクションは以下の設定から構成されています。
フィールド | 説明 |
---|---|
リダイレクト URI | リダイレクトパラメータ。${redirectUri} プレースホルダーとしてリクエスト定義で使用できます |
クライアント ID | OAuthの接続クライアントID。${clientId}プレースホルダーとしてリクエスト定義で使用できます |
ボタン名 | ログインページのボタンに表示される名前 |
トークン発行者 | OAuthトークン発行者 |
プロバイダー名 | プロバイダーの名前 |
対象 | JWTのaudパラメータ |
ログインページに表示 | ログインオプションが有効かどうかを示します。 |
ユーザーはログインするたびに、アクセストークンの内容が検証されます。これがThings Cloudへのアクセスの基盤となります。次のセクションでは、JWTクレームとプラットフォームへのアクセスとの間のマッピングを示します。
上記の例で、ユーザーがログインを試みると、デコードされた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」にする必要があります。
今回の場合、次のクレームが条件に一致します。
{
...
"user": {
"type": "human"
},
"role": [
"ADMIN"
],
...
}
このように、「次の値内」オペレーターを介してリストに値が存在するかどうかを検証するオプションがあります。値は、他のオブジェクトに埋め込むこともできます。この場合、キー内のドットは埋め込みオブジェクトを調べることを意味します。
デフォルトでは、動的アクセスマッピングは、アクセストークンに基づいて、すべてのユーザーログインでユーザーロールを割り当てます。 つまり、Things Cloud 内のユーザーロールを変更することはできません。これは、次のユーザーログイン時に上書きされるためです。この動作を変更するには、アクセスマッピング セクションの下部にある ユーザー作成時にのみ動的アクセスマッピングを使用 をオンにします。
これをオンにすると、動的アクセスマッピングは、新しいユーザーがログインして初期ロールを埋める場合にのみ使用されます。すでにユーザーが Things Cloud に存在する場合、ロールは上書きも更新もされません。このオプションを選択すると、管理者はユーザー管理で SSO ユーザーのロールを編集することもできます。 詳細については、ユーザーガイドの 管理 > 権限の管理 をご覧ください。
ユーザーがアクセストークンを使用してログインする場合、ユーザー名はJWTクレームから取得できます。クレーム名は、ユーザーID 設定 画面で設定できます。 ユーザーID は、ログインプロセス中に承認サーバーからプラットフォームに送信される承認トークンペイロードの最上位フィールドに設定できます。監査ログで認証トークンを調べて、正しいフィールドが使用されていることを確認することをお勧めします( トラブルシューティング 参照)。
定数値を使用 をオンにしている場合、SSO 経由で Things Cloud プラットフォームにログインする全ユーザーに対して、一定のユーザーID が使用されます。これは、SSO 経由でログインする全ユーザーが、Things Cloud プラットフォームで同じユーザーアカウントを共有することを意味します。このオプションの使用はお勧めしません。
次に、ユーザーデータのマッピング を構成できます。
ユーザーのログイン時に、名、姓、Eメール、電話番号などのユーザーデータも JWT クレームから取得できます。各フィールドは、JWT からデータを取得するために使用されるクレーム名を表します。ユーザーデータのマッピングの構成はオプションであり、管理者は必須フィールドのみを使用できます。構成が空であるか、クレーム名が JWT トークンで見つからない場合、ユーザーデータの値は空として設定されます。
エイリアスのマッピングは、シングルサインオン ログインのコンテキストでは使用されないため利用できません。
各アクセストークンは、署名証明書によって署名されます。現在、署名証明書を設定するオプションは3つあります。
一部のフィールド内では、実行時に Things Cloud によって解決されるプレースホルダーを使用できます。使用可能なプレースホルダーは次の通りです。
プレースホルダー | 説明 |
---|---|
clientId | クライアントID フィールドの値 |
redirectUri | リダイレクト URI フィールドの値 |
code | 認可リクエストに応じて認可サーバーから返されたコード |
refreshToken | トークンリクエスト後に認可サーバーから返されたリフレッシュトークン |
これらのプレースホルダーは、承認リクエスト、トークンリクエスト、更新リクエスト、およびログアウトリクエストで、URL、本文、ヘッダー、およびリクエストパラメータのフィールドで使用できます。
フィールドでプレースホルダーを使用するには、ドル記号を前に付けた 2 つの中括弧内に入れます。
プレースホルダーは、テキストの一部としても使用できます。
プレースホルダーが正しいかどうかは検証されません。認識されない、またはスペルが間違っているプレースホルダーは、処理されずにテキストに残されます。
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 との統合により、管理者は OpenId Connect に基づくグローバルログアウト機能を使用できます。Keycloak 認可サーバーからのイベントは、ログインプロセスで使用するトークンと同じ方法で検証されるログアウトトークンとともに、すべてのアプリケーション(Things Cloudプラットフォームを含む)に送信されます。この機能により、特定ユーザーのアプリケーションと Keycloak の両側でセッションを終了できます。
グローバルログアウト機能を設定するには、次の手順を行います。
グローバルログアウト機能を使用するには、次の手順を行います。
Keycloakは、管理者がすべての SSO ユーザーをログアウトできる機能を提供します。
すべてのユーザーのログアウト機能を構成するには、次の手順を行います。
すべてのユーザーのログアウト機能を使用するには、次の手順を行います。
すべてのユーザーのログアウトイベントは、1 つの Keycloak レルムの範囲内でのみ実行されることに注意してください。 さらに、SSO 機能の構成として使用されているクライアントが正しい Admin URL 値を持つテナントに対してのみ送信されます。
セッション タブで、Keycloak管理者は、それぞれのクライアントに存在するアクティブなセッション数を確認し、ログアウトイベントによって影響を受けるテナントとユーザーの数を見積もることもできます。
全ユーザーまたは 1 人のユーザーのログアウトイベントがテナントによって受信されたかどうかを確認するために、Things Cloud 管理者は監査ログにログアウトイベントに関する情報があるかどうかを確認できます。監査ログは、管理アプリケーションのアカウントの監査ログメニューで利用できます。
「Azure AD」テンプレートを選択すると、構成設定画面は次のようになります。
フィールド | 説明 |
---|---|
Azure AD アドレス | Azure ADテナントのアドレス |
テナント | Azure ADテナント名 |
アプリケーション ID | アプリケーションのID |
リダイレクト URI | Things Cloud テナントの後に/tenant/oauthを追加したアドレス |
クライアントシークレット | Azure ADクライアントシークレット(ある場合) |
ボタン名 | ボタンに表示される名前 |
トークン発行者 | HTTPアドレス形式のトークン発行者の値 |
オプションで、単一のログアウトを設定できます。
フィールド | 説明 |
---|---|
ログアウト後にリダイレクト | ログアウト後にユーザーを許可サーバーのログアウト・エンドポイントにリダイレクトすることにより、シングル・ログアウトをアクティブにします |
リダイレクト URL | 許可サーバーから正常にログアウトした後にユーザーをリダイレクトするアドレス |
画面後半部分は「カスタム」テンプレートと同じく、アクセスマッピング、ユーザーデータのマッピング、ユーザーID フィールド、署名の確認用アドレスが表示されています。
上述の構成設定に必要な情報が中には含まれているものもあるため、プラットフォームに送信されたトークンの内容を確認すると良いでしょう。
管理アプリケーションで アカウント > 監査ログ をクリックした後、カテゴリ「シングルサインオン」で絞り込み、「Json web token claims」を探します。
トークンの内容は JSON 形式で表示されます。
設定 メニューの アプリケーション をクリックして、アプリケーションの設定を変更します。
デフォルトアプリケーションでは、テナント内のすべてのユーザーに適用されるデフォルトアプリケーションをリストから選択できます。 例えば、特定のアプリケーションを指定せずにドメイン名のみでプラットフォームにアクセスすると、デフォルトアプリケーションとして選択されたアプリケーションが、デフォルトのランディング ページとして使用されます。
アクセス制御 から、管理者は Things Cloud API上で、クロスオリジン リソース共有(CORS)を使用可能にすることができます。
許可されたドメイン 設定により、JavaScript Webアプリケーションは REST API と直接通信できるようになります。
http://my.host.com
、http://myother.host.com
に設定すると、http://my.host.com
と http://myother.host.com
からのアプリケーションがプラットフォームと通信できるようになります。詳細については、http://enable-cors.org をご覧ください。
設定メニューのプロパティライブラリをクリックして、インベントリオブジェクト、アラーム、イベント、テナントにカスタムプロパティを追加します。
カスタムプロパティを使用すると、Things Cloud 組み込みオブジェクトのデータモデルを拡張できます。次のカスタム値を作成できます。
目的のプロパティのタブを選択し、プロパティを追加をクリックします。
表示されるダイアログボックスで、プロパティの識別子として固有の名前とラベルを指定します。そして、ドロップダウンリストからデータタイプを選択します。
さらに、新しいプロパティの検証ルールを選択します。
チェックボックス | 説明 |
---|---|
必須 | 選択した場合、プロパティを指定する必要があります(アラームの作成中など)。プロパティタイプが「ブール値」の場合は使用できません。 |
デフォルト値 | カスタムプロパティ フィールドに自動的に入力されるデフォルト値を指定します。タイプが「文字列」のプロパティでのみ使用できます。 |
最小値 | 最小の整数値を入力します。 |
最大値 | 最大の整数値を入力します。 |
最小長 | 文字列に必要な最小の長さを入力します。 |
最大長 | 文字列に必要な最大の長さを入力します。 |
正規表現 | カスタムプロパティ フィールドに入力するために必要な正規表現を追加します。 |
接続ページでは、さまざまなプロバイダーの資格情報を管理できます。資格情報を追加または置換するには、管理者権限が必要です。
現在、次のプロバイダー設定を指定できます。
使用しているプロバイダーによっては、追加フィールドがある場合があります。追加フィールドについては、各エージェントのマニュアルで説明されています。プロトコル統合ガイド をご覧ください。