システムユーザー
システムユーザーは、内部サービスのアクセス許可の管理を容易にすると同時に、外部 API レイヤーのアクセス許可をユーザーごとに付与できるようにするために設計された ThingWorx のシステムオブジェクトです。システムユーザーはオプションです。システムユーザーがサービスに割り当てられていない場合、ThingWorx は以後すべてのラップされたサービスの元となったリクエストを行ったユーザーのアクセス許可を検査します。
通常、ユーザーがサービスを呼び出すときは、呼び出すサービスに対するアクセス許可と、最初に呼び出すサービスから呼び出されるほかのすべてのサービスに対するアクセス許可が、両方ともそのユーザーに必要です。たとえば、内部で QueryStreamEntriesWithData と GetDataTableEntryByKey を呼び出す Thing に対して、GetMachineRunTimeHistory という名前のサービスをユーザーが実行するとします。システムユーザーを使用しない場合は、GetMachineRunTimeHistory を呼び出したユーザーに、QueryStreamEntriesWithData と GetDataTableEntryByKey を実行するための明示的なアクセス許可も必要です。
システムユーザーを使用すると、カスタムサービスがサービスまたはサブスクリプションから呼び出された場合に (ラップされたサービス呼び出し)、サービスを実行するためのアクセス許可がシステムユーザーに与えられていれば、イベント、スクリプト、またはサービスのシーケンスを最初に起動したユーザーに関係なく、サービスの実行が許可されます。ただし、ユーザーはラップされたサービス自体を直接呼び出すことはできません (上記の例では、ユーザーが明示的に許可されていない限り、QueryStreamEntriesWithData または GetDataTableEntryByKey)。
この演習では、管理者は明示的にアクセスを有効にしたユーザーとグループを使用して、外部からアクセス可能なサーフェス API をロックできます。サービス呼び出しのラップはユーザー適用に依存して行うことを常にお勧めしますが、システムユーザーを使用すれば、アクセス許可の管理の観点から内部サービス呼び出しの管理が容易になります。
システムユーザーを管理者グループに追加できます。このようにすると、サービス呼び出しの内部でネストされているすべての項目に対する完全なアクセス許可が、すべてのユーザーに付与されます。つまり、呼び出し側ユーザーのアクセス許可に関係なく、カスタムサービス内で呼び出されるすべてのサービスが正常に実行されます。
システムユーザーは Thing をクエリーする際のユーザーの表示アクセス許可を拡張しません。システムユーザーを使用して、ユーザーが表示アクセス許可を持っていない Thing を取得することはできません。これを説明する以下の例について考えてみます。
1. Thing Template Template1 を継承する 5 つの Thing T1、T2、T3、T4、T5 があり、2 つのユーザー User1 および User2 があります。
2. User1 には T1 および T2 に対する表示アクセス許可があり、User2 には T4 および T5 に対する表示アクセス許可があります。
3. Template1 で QueryImplementingThings に対するサービス実行アクセス許可がシステムユーザーに付与され、CallQueryImplementingThings という名前のカスタムサービスが作成されます。このサービスは内部で QueryImplementingThings を呼び出して、サービス CallQueryImplementingThings に対するサービス実行アクセス許可を User1 と User2 に付与します。
4. User1 が CallQueryImplementingThings サービスを実行すると、結果に T1 と T2 が表示されます。
5. User2 が CallQueryImplementingThings サービスを実行すると、結果に T4 と T5 が表示されます。
 |
セキュリティを回避するため、またはセキュアなアプリケーションを慎重に設計して実装する必要を軽くするために、システムユーザーを使用することはお勧めしません。システムユーザーに頼るのは特定のユースケースに限ることが最良事例であり、ユーザー適用を実施するための一般的な次善策としては使用しないでください。
|
システムユーザーの例
サービスを実行するアクセス許可をシステムユーザーに付与すると、そのサービスをカスタムサービス内から実行するアクセス許可がすべてのユーザーに付与されますが、そのサービスを直接呼び出すアクセス許可は必ずしも付与されません。これを適切に使用するには、次の操作を行います。
1. サービスを実行するアクセス許可をシステムユーザーに付与しますが、そのサービスのアクセス許可を制限して、ほかのユーザーにそのサービスを実行するアクセス許可を付与しないようにします。
2. その制限されたサービスを呼び出すカスタムサービスを記述し、制限されたサービスではなくカスタムサービスを実行するアクセス許可をユーザーに付与します。
3. ユーザーは、制限されたサービスを実行するアクセス許可を持っていない場合でも、そのカスタムサービスを実行できます。
例を用いてこの概念をさらにわかりやすく説明するため、以下のユースケースについて考えます。
接続されている特定のデバイスのステータスがユーザーに表示される、CustomService1 という名前のカスタムサービスを記述します。このために、CustomService1 は DeviceFunctions リソースに対して SearchDevices サービスを使用してプラットフォーム上のすべてのデバイスを検索し、結果をフィルタして特定のデバイスのみを返します。
ただし、アクセス許可は CustomService1 だけでなく、CustomService1 内で行われたすべてのサービス呼び出しについてチェックされます。ユーザーは CustomService1 を正常に呼び出すためには SearchDevices サービスを実行するためのアクセス許可が必要であり、アクセス許可がない場合には CustomService1 の呼び出しは失敗します。すべてのデバイスのステータスにアクセスする権限をユーザーに付与するのではなく、特定のデバイスのみに付与するので、SearchDevices を呼び出すアクセス許可をユーザーに付与することは理想的でありません。
システムユーザーはこれを解決できます。サービスが直接実行された場合、そのユーザーにアクセス許可があるかどうかがチェックされます。これは、すべてのカスタムサービスを含む、あらゆるサービスに当てはまります。ただし、カスタムサービス内からサービスが実行された場合、実際には、ユーザーのアクセス許可とシステムユーザーのアクセス許可の 2 つのアクセス許可がチェックされます。ユーザーまたはシステムユーザーのいずれかがカスタムサービスからそのサービスを実行するアクセス許可を持っている場合、ユーザーがそのサービスを実行するアクセス許可を持っているものとしてカスタムサービス内のサービスが実行されます。SearchDevices は CustomService1 内からのみ呼び出され、直接は呼び出されないので、SearchDevices を実行するアクセス許可をシステムユーザーに付与できます。ユーザーが CustomService1 を呼び出すと、アクセス許可のチェックが行われ、User1 にはアクセス許可がないが、システムユーザーにはアクセス許可があることが判別されます。その結果、ユーザーにアクセス許可があるものとして SearchDevices が実行されます。ユーザーが SearchDevices を CustomService1 内から呼び出すのではなく直接呼び出そうとした場合、システムユーザーのアクセス許可は適用されず、ユーザーはアクセス許可を拒否されます。
