Skip to main content

アプリケーション

ほとんどのユーザは、主にアプリケーションによって InterSystems IRIS® データ・プラットフォームとの対話操作を実行します。また、ユーザ・アクセスとユーザ・アクションを制御するための一連の重要なツールは、アプリケーションのセキュリティによって提供されます。アプリケーション・セキュリティでは、インターシステムズの承認ツールを使用して、適切なユーザのみにアプリケーションの使用が許可されます。アプリケーションでは、そのアプリケーションを使用するユーザの特権をエスカレートすることもできます。

ここでは、以下のトピックについて説明します。

アプリケーション、およびそのプロパティと特権

セキュリティの観点から捉えた場合、アプリケーションは次のように定義されます。

  • ユーザによるアクションの実行を可能にするエンティティです。

  • 1 つ以上のリソースに関連付けられています。

  • その動作を制御するプロパティを持ちます。

  • 実行中に実行ユーザの特権を強化することができます。

  • プログラムによる特権チェックを内包することができます。

これらの特性および機能はすべてインターシステムズの承認ツールの一部であり、これらの承認ツールが、アプリケーションとそのユーザがインターシステムズ製品および他のセキュリティ・リソースと対話する方法を管理します。アプリケーションには、以下のようないくつかの種類があります。

このセクションでは以下について説明します。

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

アプリケーションでは、データベースに対する読み書きや他のアセットの使用など、ユーザに許可するアクションのセットを指定できます。この制限を可能にするため、InterSystems IRIS では、アプリケーション定義という機能をサポートしています。この定義は、InterSystems IRIS 内でアプリケーションを表現するために使用される一連の情報です(アプリケーションとアプリケーション定義の関係は、アセットとリソースの関係に似ています)。アプリケーション定義を設定することによって、アプリケーションを制御および管理できます。

Important:

アプリケーションとアプリケーション定義は、しばしば同じ意味で使用されます。この 2 つの区別が重要になるのは、実行可能コードまたはそのコードのユーザ・エクスペリエンスが、InterSystems IRIS 内でのそのコードの表現と異なる設定に限られます。この場合、前者 (実行可能コード) はアプリケーションそのものであり、後者 (InterSystems IRIS 内でのそのコードの表現) はアプリケーション定義になります。

各アプリケーションは、それぞれのアプリケーション定義を通して、次のプロパティを持ちます。

名前

アプリケーション名。スラッシュ (“/”) で始まり、その後に英数字、あるいは

/、-、_、.、または % のいずれかの文字が続く必要があります。

アプリケーション定義の名前は、どのリソース名にも依存しません。

説明

アプリケーションの説明。

有効

アプリケーションが使用可能かどうかを示すスイッチ。有効になっていないアプリケーションは、%All ロールのメンバも含めて誰も実行できません。このプロパティによって各タイプのアプリケーションがどのように制御されるかについての詳細は、アプリケーションのタイプに応じて "Web アプリケーション"、"特権ルーチン・アプリケーション"、または "クライアント・アプリケーション" を参照してください。

リソース

アプリケーションの動作を管理するリソース。リソースが及ぼす影響は、アプリケーションのタイプに応じて異なります。Web アプリケーションクライアント・アプリケーションの場合は、このリソースによって、ユーザがアプリケーションにアクセスできるかどうかが制御され、特権ルーチン・アプリケーションの場合は、アプリケーションの特権のエスカレーションが制御されます。Web アプリケーションまたはクライアント・アプリケーションにリソースが割り当てられていない場合、すべてのユーザがそのアプリケーションを実行できます。特権ルーチン・アプリケーションにリソースが割り当てられていない場合、すべてのユーザに対して特権のエスカレーションがそのアプリケーションで実行されます。

各アプリケーション定義は単一のリソースにのみ関連付けることができます。このプロパティによって各タイプのアプリケーションがどのように制御されるかについての詳細は、アプリケーションのタイプに応じて "Web アプリケーション"、"特権ルーチン・アプリケーション"、または "クライアント・アプリケーション" を参照してください。アプリケーションとリソースとの対話の詳細は、"リソースへのアプリケーションの関連付け" を参照してください。

アプリケーション・ロール

アプリケーションのユーザが割り当てられる 1 つ以上のロール。アプリケーションの実行中、ユーザはそのアプリケーションのアプリケーション・ロールに割り当てられます。この割り当ては、$Roles 変数のロールのリストに、該当するアプリケーション・ロールを付加することで設定されます。アプリケーション・ロールの使用の詳細は、"アプリケーションおよび特権のエスカレーション" を参照してください。

マッチングロール

アプリケーションの実行中に、ユーザが何らかの追加ロール (“ターゲット・ロール”) に割り当てられるように作用する 1 つ以上のロール。ユーザがいずれかのマッチングロールに割り当てられている場合、アプリケーションの使用中、そのユーザはターゲット・ロールにも割り当てられます。この割り当ては、$Roles 変数のロールのリストに、該当するロールを付加することで設定されます。例えば、マッチングロールが %Admin_Manage の場合、このロールのメンバがこのアプリケーションを使用すると、そのメンバはターゲット・ロール %Admin_Secure のメンバにもなります。マッチングロールの使用の詳細は、"アプリケーションおよび特権のエスカレーション" を参照してください。

すべてのアプリケーションはこれらのプロパティを持ちます。その他にも、アプリケーション・タイプのそれぞれが独自の特性を備えています。

リソースへのアプリケーションの関連付け

アプリケーション (および、結果としてそのアプリケーション定義) が 1 つの単体の全体である場合、そのアプリケーションのリソースは 1 つのみとなり、アプリケーションとリソースは一対一の関係になります。複数のアプリケーション (および、結果として複数のアプリケーション定義) が 1 つのリソースに関連付けられるように定義することもできます。この場合、アプリケーションとリソースの関係は多対一になります。アプリケーションの数がいくつでも、状況はこの 2 つの条件を何らかの形で組み合わせたものに帰着します。

アプリケーションが独立した複数の部分で構成される場合は、さらに状況が複雑になります。この各部分は、サブアプリケーションと呼ばれています。サブアプリケーションのグループで成立しているアプリケーションは、単体 (全体で 1 つ) のものとして動作するように設計されますが、それぞれのサブアプリケーションが異なるセキュリティの種類またはレベルを要求できます。このような状況では、サブアプリケーションごとに固有のアプリケーション定義を割り当て、それぞれを別のリソースに関連付けると便利です。この方法によって、各サブアプリケーションに独立したセキュリティ関連の動作を個別に割り当てることができます。アプリケーションの観点では、複数のサブアプリケーションによって 1 つの大きなアプリケーションが構成されることになりますが、インターシステムズのセキュリティの観点では、それぞれに独自のアプリケーション定義を持つ複数の個別アプリケーションが存在し、ユーザは意識することなくそれらのアプリケーション間を通過することになります。この場合も、一対一のケースと多対一のケースに帰着します。ただし、複数のアプリケーション定義は、エンドユーザには 1 つのアプリケーションに見えます。ユーザは既に認証されており、そのプロセスでロールが設定されているため、サブアプリケーション間の受け渡し時に認証は不要です。

例えば、経費レポートのアプリケーションがあるとします。このアプリケーションでは、全従業員が経費レポートを入力できますが、小切手を生成できるのは会計責任者だけです。この場合、アプリケーションは 1 つのアプリケーション全体のように見え、小切手を生成する機能は会計責任者を除くすべての従業員にグレー表示されます。このようなアプリケーションを作成するには、1 つはレポートの入力、もう 1 つは小切手の生成に使用する、2 つの独立したサブアプリケーションが必要になります。1 つ目のサブアプリケーションはすべてのユーザが使用できますが、2 つ目のアプリケーションを使用できるのは会計責任者だけです。2 つのサブアプリケーションは 1 つのアプリケーション内の独立した 2 つの画面にしか見えず、それ以上の外観上の違いはありません。

アプリケーションおよび特権のエスカレーション

ユーザのロールはアプリケーション・リソースを使用することでエスカレートできるため、それらのリソースには動的に推移する承認のニーズを満たすメカニズムが用意されています。アプリケーションの特権のエスカレーションを実行するには、以下の操作を実行します。

  1. 既存のアプリケーションに対してリソースを作成し、そのリソースにアプリケーションを関連付けます。

  2. そのリソースに対して Use 許可を持つロールを 1 つ以上作成します。

  3. アプリケーションの実行に必要な特権のリストを決定します。そのアプリケーションが複数のサブアプリケーションで構成される場合、リストが複数になる場合があります。

  4. 各特権リストを個々のロールに関連付けます。各ロールを、そのアプリケーションまたはサブアプリケーションのアプリケーション・ロールとして設定します。

  5. そのアプリケーションまたはサブアプリケーションのマッチングロールを設定します。それぞれのマッチングロールには、1 つ以上のターゲット・ロールを関連付けます。

  6. ユーザが正常にアプリケーションを起動すると、InterSystems IRIS は次の 2 つのアクションを実行します。

    • アプリケーションの使用中、ユーザをそのアプリケーションのロールに割り当てます(特権ルーチン・アプリケーションの場合、この割り当ては、AddRoles メソッドが正常に起動されたかどうかに依存します。詳細は、"特権ルーチン・アプリケーション" を参照してください)。

    • ユーザがいずれかのマッチングロールに割り当てられている場合、ユーザは、アプリケーションの使用中、アプリケーションによってターゲット・ロールに割り当てられます(これについても、特権ルーチン・アプリケーションの場合、この割り当ては、AddRoles メソッドが正常に起動されたかどうかに依存します。詳細は、"特権ルーチン・アプリケーション" を参照してください)。

例えば、AppRsrc という専用のリソースを持つアプリケーションがあるとします。AppRsrc:Use 特権を保持している、AppUserAppOperator という 2 つのロールがあります。AppOperator はマッチングロールでもあり、そのターゲット・ロールは %Manager です。このシナリオでは、AppUser ロールに属するユーザがこのアプリケーションを呼び出しても、$Roles の値は変化しません。一方で、AppOperator ロールに属するユーザがこのアプリケーションを呼び出すと、%Manager を含むように $Roles の値が拡張されます。アプリケーションにアプリケーション・ロール AppExtra がある場合、AppUser ロールに属するユーザがこのアプリケーションを呼び出すと、このユーザは AppExtra ロールを受け取ります。マッチングロールのみの最初のシナリオでは、AppOperator ロールに属しているユーザで、特権のエスカレーションが発生します。マッチングロールとアプリケーション・ロールがある 2 番目のシナリオでは、どちらのロールに属しているユーザにも特権のエスカレーションが発生します。

ユーザ・ベースのセキュリティおよびアプリケーション・ベースのセキュリティ

インターシステムズのセキュリティ・モデルでは、ユーザ・ベース、アプリケーション・ベース、または両方をベースにした柔軟な特権の割り当てが可能です。アプリケーションの使用を特定のユーザのみに限定できるほか、すべてのユーザが使用できるようにすることもできます。アプリケーションの使用を承認されているユーザに対するそのアプリケーションの動作として、次の複数の動作が可能です。

  • ユーザの特権のみでアプリケーションを実行できます。

  • アプリケーションで一部のユーザの特権をエスカレートすることができます (マッチングロールとターゲット・ロールを使用)。

  • アプリケーションですべてのユーザの特権をエスカレートすることができます (アプリケーション・ロールを使用)。

  • 一部の特権については、アプリケーションですべてのユーザに対してエスカレーションを発生させ、他の特権については特定のユーザに対してのみエスカレーションを発生させることができます (マッチングロール/ターゲット・ロールとアプリケーション・ロールを組み合わせて使用)。

このように、アプリケーションの使用を、特定のユーザのみに限定して認めるか、すべてのユーザに認めるか制御できます。また、アプリケーションをユーザの特権で実行するか、アプリケーション自体の特権で実行するかも制御できます。これにより、InterSystems IRIS では以下のような極めて柔軟なモデルが実現します。

安全なアプリケーションの保護とエスカレーションのマトリックス
Privilege Level / Protection Level Public Application Restricted Application
With User-Dependent Privileges 1.どのユーザでもアプリケーションを実行できます。アプリケーションはユーザの特権で実行されます。 2.指定されたユーザのみがアプリケーションを実行できます。アプリケーションはユーザの特権で実行されます。
With Privilege Escalation 3.どのユーザでもアプリケーションを実行できます。アプリケーションは、アプリケーション・ロールとマッチングロールを通して、(拡張された) アプリケーション特権で実行されます。 4.指定されたユーザのみがアプリケーションを実行できます。アプリケーションは、アプリケーション・ロールとマッチングロールを通して、(拡張された) アプリケーション特権で実行されます。

上記のテーブルで説明した各シナリオは、以下のようなさまざまな承認モデルで広く使用されています。

1.ユーザ依存の特権を持つパブリック・アプリケーション

このモデルは、認証されたすべてのユーザが使用できるアプリケーションを表します。このアプリケーションは実行しても追加の特権は付与しません。例えば、企業の連絡先データベースの場合、その企業全体のロールに属するユーザであれば、任意の社員の所属先電話番号と電子メール・アドレスを知ることができます。管理職は、社員の自宅電話番号を知ることができる上位の特権を保持しています。人事担当のスタッフは、すべてのレコードを閲覧および更新できる、さらに上位の特権を保持しています。このアプリケーションにはすべての社員がアクセスできますが、その動作は、アプリケーションを呼び出したときに各社員が既に持っている特権で決まります。つまり、アプリケーションそのものからロールが与えられるわけではありません。

2.ユーザ依存の特権を持つ制限アプリケーション

このモデルは、指定のロールに属するユーザのみが使用できるアプリケーションを表します。このアプリケーションは実行しても追加の特権は付与しません。例えば、時給制の社員を扱う給与アプリケーションでは、勤務時間数や時給などが表示されます。このアプリケーションを実行するユーザは、HourlyEmployee ロールまたは HourlyManager ロールのメンバであることが必要です。このアプリケーションを実行すると、どのロールが指定されたかがチェックされます。このチェックにより、HourlyEmployee ロールのメンバは自身のデータを閲覧できますが、それを編集することはできません。一方、HourlyManager ロールのメンバは、報告の目的でデータの閲覧と編集が可能です。HourlyEmployee ロールのメンバである社員は、このアプリケーションを実行して個人データが正しいかどうかを確認できます。ここで要求されるロールのメンバではない月給制の社員などの他の社員は、このアプリケーションは実行することもできません。

3.特権のエスカレーションを伴うパブリック・アプリケーション

このモデルは、認証されたすべてのユーザが使用できるアプリケーションを表します。このアプリケーションは、実行するとユーザが属するロールに基づいて特権をエスカレートします(特定のロールについてのみ、特権をエスカレートすることもできます)。例えば、学生が自身のレコードを確認および更新できるアプリケーションが、大学にあるとします。ここでは、どの学生も認証されたユーザであり、自身の連絡先情報を編集できます。この機能をサポートするために、アプリケーションにはエントリを編集するためのコードがあります。このコードでは、編集されているエントリが認証ユーザと一致しているかどうかが確認され、一致していれば、レコードを更新できるようにコード自身の特権がエスカレートされます。更新の終了後は、特権が元の状態に戻されます。ある学生が他の学生のレコードを更新しようとしても、このエントリの確認に失敗するので、特権のエスカレートが発生せず、更新も行われません。このアプリケーションでは、ユーザが学籍係の業務ロールのメンバであるかどうかも確認されます。そのメンバである場合は、さらに広範囲に情報を更新できます。

4.特権のエスカレーションを伴う制限アプリケーション

このモデルは、指定のロールに属するユーザのみが使用できるアプリケーションを表します。このアプリケーションは、ユーザが属するロールに基づいて特権をエスカレートします(特定のロールについてのみ、特権をエスカレートすることもできます)。例えば、病院の救急処置室に置かれたアプリケーションでは、現在救急治療を受けている患者のレコードを閲覧できる、特別に幅広い特権を担当の医師に与えることが考えられます。救急処置室では高い緊急性が発生する可能性があることから、この設定では、単純な巡回診療の場合よりも多くの情報を医師に提示できることが必要です。したがって、この場合は特権のエスカレートが発生します。

プログラムによる特権チェック

特定のアクションを実行するために必要な特権をユーザが保持しているかどうか確認するコードを、アプリケーションに組み込むこともできます。この操作には、$SYSTEM.Security.Check メソッドを使用します。これを呼び出すための構文は次のとおりです。

 Set status = $SYSTEM.Security.Check(app_resource, app_permission)

以下はその説明です。

  • app_resource は、ユーザが許可を保持していなければならないリソースです。

  • app_permission は、保持していなければならない許可です。

  • status は、メソッドの返り値、True または False (1 または 0) です。

例えば、あるアプリケーションでユーザに Application_Order_Customer への Write 許可を付与する必要がある場合、Check 呼び出しは以下のようになります。

 Set status = $SYSTEM.Security.Check("Application_Order_Customer", "WRITE")
Note:

$SYSTEM.Security.Check の呼び出しには、特権は必要ありません。

アプリケーション・タイプ

アプリケーションには、以下のようないくつかのタイプがあります。

Web アプリケーション

これらのアプリケーションは、%Service_WebGateway サービスを使用して InterSystems IRIS に接続します。

Web アプリケーションでは、セキュリティ情報が Web セッションの一部として保持されます。つまり、$USERNAME および $ROLES の値が複数のページ要求にわたって保持されます(より具体的に言うと、ページに対する処理が開始されたとき、$ROLES にはユーザのロールに加えて、アプリケーションに定義されたロールも記述されます)。その前のページを処理したときに、SET $ROLES または $SYSTEM.Security.AddRoles を介して動的に追加されたロールは含まれません。これは、ステートレスおよび “ステートフル” のどちらのセッションにも当てはまります。

Web アプリケーションを使用すると、クライアント (つまりブラウザ) は通常、接続時にユーザ名とパスワードをサーバに送信することはありません。その代わりにユーザはページを要求し、それを受けたサーバはログイン・ページを送り返します。そのアプリケーションにさらにアクセスするには、ユーザはこのログイン・ページで必要な情報を入力する必要があります。2 要素認証が有効な場合、ユーザがユーザ名とパスワードを入力すると、サーバではセキュリティ・コードを入力するためのページが表示されます。認証に成功すると、ユーザはアプリケーションにアクセスできるようになります。

Note:

2 要素認証では、ユーザ名とパスワードのペアが有効でない場合でも、サーバでは、1 回限りのセキュリティ・トークンを入力するためのページが必ず表示されます。1 回限りのセキュリティ・トークンをユーザが入力すると、サーバではアクセス拒否を示すメッセージが表示され、システムで使用可能な最小限の情報が提供されます。

CSP のセキュリティ処理は以下のように行われます。

  1. ページ要求が受信されるたびに、そのアプリケーションは要求の URL によって決まります。そのアプリケーションが有効になっていない場合、接続は行われません。

  2. そのアプリケーションが Web セッションで直前に処理されたページのアプリケーションと同じ場合は、既に接続されているため、それ以上のセキュリティ・チェックは要求されません。

  3. %Service_WebGateway の Use 許可がパブリックではなく、この許可をユーザが保持していない場合、接続は行われません。

  4. そのアプリケーションまたは %Service_WebGateway が認証を必要とし、ユーザがまだ認証済みでない場合は、要求に IRISUsername および IRISPassword パラメータが含まれているかどうかが InterSystems IRIS によって確認されます。

    1. IRISUsernameIRISPassword が含まれている場合、InterSystems IRIS はログインを試行し、ログインに成功すると、そのアプリケーション・リソースの Use 許可をユーザが保持しているかどうかを確認します。この両方に成功しないと、接続は行われません。

    2. IRISUsernameIRISPassword が含まれていない場合、その Web アプリケーションの構成でアプリケーション固有のログイン・ページが定義されていれば、そのページが表示されます (安全なアプリケーションでは、これがログイン前に使用できる唯一のページです)。アプリケーション固有のログイン・ページがないと、ユーザ名とパスワードによる認証に失敗します。また、ユーザがそのアプリケーション・リソースに対する Use 許可を保持していない場合、接続は行われません。

Web アプリケーションの編集は、以下を参照してください。

"Web アプリケーションへのカスタム・ログインの保護" も参照してください。

Web アプリケーションでロールをプログラムによってエスカレートする方法の例

以下は、Web アプリケーションのアプリケーション・ロールをエスカレートする方法の例です。この例では、以下のアクションが実行されます。

  1. 制御を %SYS ネームスペースに変更します。これは、必要な呼び出しを実行するために行わなければなりません。ロールの管理とエスカレーションを実行するコードを使用できるのは、%SYS ネームスペース内のみだからです。

  2. アプリケーションのターゲット・ロールを追加します。

    1. すべてのユーザに MYAPP ロールが割り当てられます。これは、行内のコロンの前に、matchroles の値を初期設定するマッチングロールがリストされていないためです。構文は、matchrole:targetrole です。matchrole の値が空の場合、すべてのユーザに targetrole が割り当てられます。

    2. MYAPPSPECIAL ロールが既に割り当てられているユーザに、MYAPP2 ロールを追加します。ここの構文は、matchrole1:targetrole1,matchrole2:targetrole2 です。つまり、MYAPPSPECIAL ロールが割り当てられているユーザには、アプリケーションによって MYAPP2 ロールが追加されます(2 つ目以降のマッチングロールおよびターゲット・ロールの構文の後には、先行コンマが付きます。詳細は、Security.Applications.CreateOpens in a new tab メソッドを参照してください)。

  3. ロール・エスカレーション情報を保持しているローカル変数を使用して、アプリケーションの MatchRoles プロパティを更新します。Security.Applications.ModifyOpens in a new tab メソッドは、値が指定されているプロパティのみを更新します。それ以外のプロパティは変更されないままです。

  4. 最後に、ロール・エスカレーションが成功した場合に、これを通知します。

このコードは以下のとおりです。

Method UpdateRoles() As %Status {
 // ********************* modify application roles *********************
 write !, "All users receive the added MYAPP role."
 write !, "Users who have MYAPP2 receive MYAPPSPECIAL also."  
 
 // Change to the %SYS namespace.
 new $NAMESPACE
 set $NAMESPACE="%SYS"
 
 // Add roles for the application.
 //
 // Add the MYAPP role for all users.
 set matchroles=":MYAPP"
 // Also add MYAPP2 for users who already have the MYAPPSPECIAL role.
 set matchroles=matchroles_",MYAPPSPECIAL:MYAPP2"
 
 // Use the matchroles variable to 
 // set the applications's MatchRoles property. 
 set MyAppProps("MatchRoles")=matchroles
 set status=##class(Security.Applications).Modify("/csp/MyApp",.MyAppProps)
 
  // Announce success.
  if $$$ISOK(status) {
    write !, "Roles were successfully modified."
 }
}

特権ルーチン・アプリケーション

特権ルーチン・アプリケーションは、1 つ以上のクラスまたはルーチンにロールをエスカレートする特権を付与して、それらのクラスまたはルーチンのユーザのためにロールをエスカレートします。特権ルーチン・アプリケーションのクラスまたはルーチンは、ObjectScript で作成します。特権ルーチン・アプリケーションを使用するには、以下の操作を実行します。

  1. 管理ポータルでアプリケーション定義を作成します。詳細は、"アプリケーションの作成" を参照してください。

  2. そのアプリケーション定義にクラスまたはルーチンを追加します。詳細は、"アプリケーションの編集 : [ルーチン/クラス] タブ" を参照してください。

  3. ロールをエスカレートするように開発環境でアプリケーション定義のクラスまたはルーチンを編集します。詳細は、"特権ルーチン・アプリケーションでのロールのエスカレート : AddRoles メソッド" を参照してください。

ポータルには、特権ルーチン・アプリケーションを編集するための以下のページがあります (これには、前述した最初の 2 つのページが含まれます)。

特権ルーチン・アプリケーションでのロールのエスカレート : AddRoles メソッド

特権ルーチン・アプリケーションでロールをエスカレートするには、%SYSTEM.SecurityOpens in a new tab クラスの AddRoles メソッドを呼び出します。AddRoles を呼び出すには、以下の構文を使用します。

 Set sc = $SYSTEM.Security.AddRoles("AppDefName")

AppDefName はアプリケーション定義の名前で、sc はステータス・コードです。アプリケーション定義に記述されているクラスまたはルーチンがあり、ユーザが適切な特権を持っている場合に、そのクラスまたはルーチンから AddRoles を呼び出すことで、あらゆるアプリケーション・ロール (“アプリケーションの編集 : [アプリケーションロール] タブ” を参照) および関連するあらゆるマッチングロール (“アプリケーションの編集 : [マッチングロール] タブ” を参照) を扱うことができるように特権がエスカレートされます。

Important:

エントリ・ポイントでコードを区切る中括弧をルーチンに使用していない場合は、制御がエントリ・ポイント間で受け渡しされることがあります。その結果、ユーザに過度な特権が与えられ、意図しないレベルのアクセスが可能になる恐れがあります。ルーチンの構造化の詳細は、"ユーザ定義コード" を参照してください。

AddRoles の呼び出しは、以下のように処理されます。

  1. 呼び出しが特権クラスまたはルーチン以外からの場合、呼び出しは失敗します。

  2. アプリケーション定義で指定された要求リソースがパブリックではないときに、このリソースに対する Use 権限を保持していないユーザがメソッドまたはルーチンを呼び出した場合、呼び出しは失敗します。

  3. 上記以外の場合、この呼び出しは成功します。

Tip:

特権をエスカレートしたルーチンのスコープ外に制御が渡されたときに、ユーザからすべてのアプリケーション・ロールを剥奪してログイン・ロールに戻すには、AddRoles 呼び出しのに以下のコマンドを含めます。

 New $Roles

これらのトピックの詳細は、"プログラムで管理するロール" を参照してください。

特権ルーチン・アプリケーションの使用例

例えば、DB1 という名前のデータベースを使用するアプリケーションがあるとします。このアプリケーションの各ユーザは %DB_DB1 ロールのみを所持していて、そのすべてのユーザが DB1 に対する特権を所持しています。このアプリケーションの一部のユーザは、一時的に別のデータベース (DB2) へのアクセスも必要とします。こうしたユーザは、PRATestClass クラスの PRAEscalateメソッド (“特権ルーチン・アプリケーション” の “PRA”) によって DB2 へのアクセス権を取得します。このメソッドは、該当するユーザの特権をエスカレートします。具体的には、PRAEscalate によって、%DB_DB2 ロールを追加して DB2 へのアクセスを可能にします。

PRAEscalate メソッドによって該当するユーザに %DB_DB2 ロールを追加できるようにするには、以下のセキュリティ項目が存在している必要があります。

  • PRATestResource という名前のパブリックではないリソース。

  • PRA_DB2 という名前のロール (1 つの特権 PRATestResource:Use のみを持つロール)。

  • %DB_DB2 ロール (DB2 データベースの作成時に作成したロール)。

  • PRATestApp という名前の特権ルーチン・アプリケーション。PRATestApp に関する説明は以下のとおりです。

    • PRATestApp アプリケーションを実行するには、ユーザが PRATestResource:Use 特権を持っている必要があります。そのため、DB2 データベースへのアクセスを必要とするユーザは、PRA_DB2 ロール (PRATestResource:Use 特権を付与するロール) を持っている必要があります。

    • PRATestClass クラスは、PRATestApp アプリケーションに含まれます(このクラスをアプリケーションに含めるには、PRATestApp の [編集] ページにある [ルーチン/クラス] タブを使用します)。

    • %DB_DB2 ロールは、PRATestApp のアプリケーション・ロールです(アプリケーション・ロールを指定するには、PRATestApp の [編集] ページにある [アプリケーションロール] タブを使用します)。

この設定を実行したときに、PRATestBasicUser および PRATestDB2User というユーザが存在すると仮定すると、以下のようになります。

  • PRATestBasicUser は、%DB_DB1 専用のユーザです。そのため、PRATestApp アプリケーションは、PRATestBasicUser のロールをエスカレートすることはありません。また、このユーザは、DB2 へのアクセスを必要とするアプリケーションの部分を使用できません

  • PRATestDB2User は、%DB_DB1 ロールと PRA_DB2 ロールのメンバです。そのため、PRATestApp アプリケーションは PRATestBasicUser のロールをエスカレートします。このユーザは、DB2 へのアクセスを必要とするアプリケーションの部分を使用できます

PRAEscalate のコードは以下のとおりです。

Method PRAEscalate()
 {
   Write "This method is a part of the privileged routine application ",!
   Write "called PRATestApp.",!
   Write "The user invoking this routine is ",$Username,!
   Write "The current value of $Roles is ",$Roles,!,!
   Write "Calling the AddRoles method...",!,!
   New $Roles
   Set sc = $SYSTEM.Security.AddRoles("PRATestApp")
   If sc = 1
   {
      Write "Application roles have been added.",!
      Write "$Roles now is ",$Roles,!,!
   } Else {
      Write "The call to AddRoles has failed.",!
      Do $system.Status.DecomposeStatus(sc,.Err)
      Write Err(Err),! 
   }
 }

このルーチンを PRATestDB2User が実行した場合のターミナル・セッションは以下のとおりです。

Username: PRATestDB2User
Password: ********
USER>set x = ##class(PRATestClass).PRATest()
This method is a part of the privileged routine application
called PRATestApp.
The user invoking this routine is PRATestDB2User
The current value of $Roles is %DB_DB1, PRA_DB2
 
Calling the AddRoles method...
 
Application roles have been added.
The current value of $Roles is %DB_DB1, %DB_DB2, PRA_DB2 
Removing %DB_DB2 from $Roles...
$Roles now is %DB_DB1, PRA_DB2

USER>

このルーチンを PRATestBasicUser が実行した場合のターミナル・セッションは以下のとおりです。

Username: PRATestBasicUser
Password: ********
USER>set x = ##class(PRATestClass).PRATestMethod()
This method is a part of the privileged routine application
called PRATestApp.
The user invoking this routine is PRATestUser
The current value of $Roles is %DB_DB1
 
Calling the AddRoles method...
 
The call to AddRoles has failed.
ERROR #862: User is restricted from running privileged application PRATestApp 
-- cannot execute.
 
USER>

クライアント・アプリケーション

これは、InterSystems IRIS への接続にクライアント アプリケーション タイプを使用するアプリケーションです。

Important:

クライアント・アプリケーションに関して、以下の点に注意してください。

  • Windows でのみサポートされます。このため、これらのアプリケーション用の管理ポータルのオプションは、Windows でのみ使用できます。

  • アプリケーションの認証を設定するには、"認証" で説明されているツールを使用します。

クライアント・アプリケーションを編集するには、ポータルの以下のページを使用します。

ドキュメント・データベース・アプリケーション

これらのアプリケーションは、ドキュメント・データベースを使用して InterSystems IRIS に接続します。

Important:

このようなアプリケーションでは、"認証" で説明されている認証ツールを使用してください。

ドキュメント・データベース・アプリケーションを編集するには、ポータルの以下のページを使用します。

アプリケーションの作成および編集

ここでは、以下のトピックについて説明します。

アプリケーションの作成

アプリケーションを作成する手順は以下のとおりです。

  1. 管理ポータルのメニューで、[システム管理][セキュリティ][アプリケーション] を選択します。これにより、さまざまなアプリケーション・タイプが表示されます。

  2. [Web アプリケーション][特権ルーチンアプリケーション][クライアントアプリケーション]、または [ドキュメント DB アプリケーション] を選択します。選択したアプリケーション・タイプのページが表示されます。

  3. アプリケーション・ページの左上隅で、新しいアプリケーションの作成ボタンをクリックします。選択した種類のアプリケーション編集ページが表示されます。以下の情報を使用して、既存のアプリケーションと同様に、アプリケーションを編集できます。

Web アプリケーションの編集 : [一般] タブ

Web アプリケーションを編集する手順は以下のとおりです。

  1. 管理ポータル・メニューで、[システム管理][セキュリティ][アプリケーション][ウェブ・アプリケーション] を選択します。

    構成済みの Web アプリケーションが一覧表示されます。[タイプ] 列には、アプリケーションがユーザ・アプリケーション (CSP) またはシステム・アプリケーション (CSP,System) として示されます。

  2. アプリケーションを選択して [編集] をクリックした後、情報を入力または変更します。

  3. 編集が完了したら、新規設定を有効にするために InterSystems IRIS を再起動します。

一般設定

[一般] タブの最初のセクションには、さまざまなオプションが表示されます。

Note:

ここでは、CSP/ZEN アプリケーションにのみ関連するフィールドについては説明しません (別のインターシステムズ製品から CSP/ZEN アプリケーションを InterSystems IRIS に移行した場合は、その関連フィールドOpens in a new tabについてのドキュメントが用意されていますので参照してください)。

名前

アプリケーションの識別子。名前の先頭にはスラッシュ (/) を含める必要があります (例えば、/myorg/myapp アプリケーションのようにします)。

名前 /csp/docbook は予約されていることに注意してください。

説明

アプリケーションの説明テキスト。

ネームスペース

このアプリケーションが実行されるネームスペース。別のネームスペースを選択すると、そのネームスペースの既定アプリケーションがこのドロップダウン・メニューの右側に即座に表示されます。

ネームスペースの既定アプリケーション

アプリケーションがこのネームスペースの既定アプリケーションかどうかの指定。%System.CSP.GetDefaultApp メソッドは、ネームスペースの既定アプリケーションを返します。$system.OBJ.Load$system.OBJ.ImportDir などの InterSystems IRIS のインポート関数は、関連付けられているアプリケーションなしでページをインポートする際に、この既定アプリケーションを使用します。

アプリケーション有効

アプリケーションを使用できるかどうかの指定。有効になっていれば、認証および承認されたユーザはアプリケーションを使用できます。無効の場合は使用できません。

[REST][WSGI]、または [CSP/ZEN] の有効化

Web アプリケーションのタイプ :

ディスパッチ・クラス

(REST アプリケーションの場合) REST サービスを実装するための %CSP.RESTOpens in a new tab の対応するカスタム・サブクラス。詳細は、"手動による REST サービスの作成" を参照してください。

空のパスをリダイレクト

(REST アプリケーションの場合) アプリケーションが空のパスを / に送るかどうか。例えば、アプリケーション /csp/appname の場合、/csp/appname に対する要求は、/csp/appname/ にリダイレクトされます。

JWT 認証を使用

(REST アプリケーションの場合) アプリケーションが JSON Web トークン (JWT) 認証をサポートするかどうか。

JWTアクセストークンタイムアウト

(REST アプリケーションの場合) JWT が失効するまでの秒数。

JWTリフレッシュトークンタイムアウト

(REST アプリケーションの場合) JWT のリフレッシュ・トークンが失効するまでの秒数。

アプリケーション名

(WSGI アプリケーションの場合) 呼び出し可能な Python アプリケーションを含むファイルの名前。

呼び出し可能名

(WSGI アプリケーションの場合) 既定値 (application) でない場合、呼び出し可能なアプリケーションの名前。

WSGI アプリケーション・ディレクトリ

(WSGI アプリケーションの場合) 呼び出し可能な Python アプリケーションを含むディレクトリ。

セキュリティの設定

セキュリティの設定を以下に示します。

必要なリソース

ユーザがアプリケーションを実行するために Use 許可を保持していなければならないリソース。これらのリソースおよび許可の詳細は、"リソースについて" を参照してください。

ID でグループ化

使用しません。このフィールドは、従来のアプリケーションを移行した場合にのみ使用します。詳細は、ドキュメントOpens in a new tabを参照してください。

許可された認証方法

アプリケーションでサポートされている認証メカニズム。ここで使用可能なオプションは、[認証オプション] ページ ([システム管理] > [セキュリティ] > [システム・セキュリティ] > [認証/Web セッション・オプション]) での選択内容によって異なります。アプリケーションが複数の認証メカニズムをサポートする場合、認証は以下のように行われます。

  • [認証なし]含む複数のオプションが有効になっている場合、ユーザはユーザ名とパスワードを入力せずにログインできます。

  • 複数のオプションが有効になっている状態で、かつユーザ名とパスワードを入力した場合、InterSystems IRIS によってカスケード認証が試行されます。

  • 選択したオプションが Kerberos 認証やインスタンス認証 (パスワード) であっても、[認証なし] を選択していない場合、ユーザ名とパスワードを入力する必要があります。InterSystems IRIS では、最初に Kerberos を使用して認証が実行され、次にインスタンス認証が実行されます。いずれかが成功すれば、ユーザは認証されます。両方の認証が失敗した場合、アクセスは拒否されます。

詳細は、"認証" を参照してください。

許可したクラス

使用しません。このフィールドは、従来のアプリケーションを移行した場合にのみ使用します。詳細は、ドキュメントOpens in a new tabを参照してください。

セッションの設定

このセクションのこの設定を使用して、Web アプリケーションのセッション・プロパティを管理できます。

Important:

これらの設定を使用するには、まずアプリケーションのディスパッチ・クラスの UseSession パラメータをゼロ以外の値に設定する必要があります。そうしないと、これらの設定の値を変更しても効果はありません。詳細は、"手動による REST サービスの作成" を参照してください。

セッションの設定を以下に示します。

セッション・タイムアウト

既定のセッション・タイムアウトを秒単位で指定します。この値は、%CSP.SessionOpens in a new tab オブジェクトの AppTimeout プロパティを使用してオーバーライドできます。

1 つのセッションでその有効期間中に Web アプリケーションを変更した場合、新しいアプリケーションでは、既定のタイムアウト値を使用してセッションのタイムアウト値が更新されません。例えば、既定のタイムアウト値が 900 秒の Web アプリケーション A でセッションが開始し、その後、既定のタイムアウト値が 1800 秒の Web アプリケーション B に移動した場合、セッションは 900 秒後にタイムアウトになります。

アプリケーションを変更するときにセッションのタイムアウト値が更新されるようにするには、セッション・イベント・クラスで OnApplicationChange コールバック・メソッドをオーバーライドし、%session オブジェクトの AppTimeout プロパティを更新するためのコードを追加します。

インターシステムズ管理ポータルの [Interoperability] ページで自動ログアウトを無効にした場合、これらのページにセッション・タイムアウトは適用されません。すなわち、ページはタイムアウトしません。自動ログアウトを無効にすることはお勧めしません。詳細は、"管理ポータルの自動ログアウト動作" を参照してください。

イベントクラス

クラス (%CSP.SessionEventsOpens in a new tab のサブクラス) の既定名。この既定名のメソッドは、タイムアウトやセッションの終了などの Web アプリケーション・イベントを呼び出します。この値を上書きするには、拡張子 (.cls など) を除いたクラス名を値として使用して、%CSP.SessionOpens in a new tab オブジェクトの EventClass プロパティの値を指定します。

セッションにクッキーを使用する

アプリケーションでブラウザ・セッションを追跡するために cookie を使用するか、URL 書き換え手段 (各 URL に値を挿入する) を使用するかの設定。選択肢は以下のとおりです。

  • 常時 — 既定。常に cookie を使用します。

  • なし — cookie を使用しません。

  • 自動検出 — クライアント・ブラウザで無効になっている場合を除き、cookie を使用します。ユーザが cookie を無効にしている場合、アプリケーションでは、URL 書き換えが使用されます。

このオプションは、アプリケーションが cookie を使用するどうかを設定するものではなく、ユーザの設定に従ってアプリケーションがどのようにセッションを管理するかを制御するものです。さらに、値が [常時] または [自動検出] であっても、アプリケーションは、コードが cookie を使用するように記述されている場合にのみ cookie を使用します。

セッションクッキーパス

このアプリケーションに関するセッション Cookie をブラウザから InterSystems IRIS に返送する際に使用する URL の一部。このフィールドの値を指定しない場合、アプリケーションは、[名前] フィールドの値の先頭と末尾にスラッシュを付けたものを既定のスコープとして使用します。したがって、ここで値を指定しない場合、myapp という名前のアプリケーションのスコープは /myapp/ になります。

アプリケーションは、指定されたスコープ内にあるページの cookie のみを送信します。スコープを 1 つの Web アプリケーションで必要なページに制限すると、このマシン上の他の Web アプリケーションがこのセッション cookie を使用するのを防ぐことができます。また、この Web サーバ上の他の Web アプリケーションが cookie を参照するのも防ぐことができます。

1 つのセッション cookie を同時に共有しながら、プライマリ・アプリケーションとそのサブアプリケーションとで異なるセキュリティ設定を使用できます (すべてのアプリケーションがプライマリ・アプリケーションのパスを使用している場合)。

Session Cookie Scope

Web アプリケーションに関連付けられているセッション Cookie の SameSite 属性の既定値を制御します。詳細は、以下の “SameSite 属性について” を参照してください。

User Cookie Scope

%CSP.Response.SetCookieOpens in a new tab を使用して作成したユーザ定義 Cookie の SameSite 属性の既定値を制御します。詳細は、以下の “SameSite 属性について” を参照してください。

SameSite 属性について

SameSite 属性では、サードパーティ・アプリケーションに関連する Cookie をアプリケーションでどのように処理するかを指定します (クロスサイト・リクエストともいいます)。

[Session Cookie Scope] フィールドおよび [User Cookie Scope] フィールドを使用して、アプリケーションの Cookie の SameSite を設定できます。[Session Cookie Scope] では、セッション、ログイン、CSRF、およびグループ ID の各 Cookie について SameSite 属性の値を設定し、[User Cookie Scope] では、ユーザ定義 Cookie について SameSite 属性の値を設定します。

SameSite には、以下の値を設定できます。

  • [None] — アプリケーションはクロスサイト・リクエストに応じて Cookie を送信します。SameSite の値が [None] の場合、ブラウザにより、アプリケーションで HTTPS 接続を使用するよう要求されることがあります。

  • [Lax] — アプリケーションは、安全な最上位のクロスサイト・ナビゲーションを使用して Cookie を送信します。

  • [Strict] — アプリケーションはクロスサイト・リクエストに応じて Cookie を送信することはありません(システム Web アプリケーション、および新規またはアップグレードしたユーザ・アプリケーションの既定値)。

アプリケーションの Cookie をよりきめ細かく制御するには、%CSP.Response.SetCookieOpens in a new tab メソッドを使用します。これは、特定の Cookie の SameSite の既定値を上書きします。%CSP.Response.SetCookieOpens in a new tab を使用して、Cookie の SameSite の値を [None] に指定する場合は、HTTPS 接続を使用する必要があります。

SameSite 属性は IETFOpens in a new tab の計画の一環であり、IETF のいくつものドキュメントで扱われています。

特権ルーチン・アプリケーション、クライアント・アプリケーション、またはドキュメント・データベース・アプリケーションの編集 : [一般] タブ

以下はその方法です。

  1. 管理ポータルのメニューで、[システム管理][セキュリティ][アプリケーション] を選択します。これにより、さまざまなアプリケーション・タイプが表示されます。

  2. [Web アプリケーション][特権ルーチンアプリケーション][クライアントアプリケーション]、または [ドキュメント DB アプリケーション] を選択します。選択したアプリケーション・タイプのページが表示されます。

  3. アプリケーションのページで、アプリケーションの名前をクリックして編集用に選択します。そのアプリケーションの [編集] ページが表示されます。

  4. 既定では、[一般] タブが表示されます。特権ルーチン・アプリケーションとクライアント・アプリケーションの場合、このページには以下のフィールドが表示されます。

    [名前] フィールド (アプリケーション・タイプによって異なります)

    アプリケーションの識別子。

    説明

    アプリケーションの説明テキスト。

    有効

    アプリケーションが有効かどうかの指定。有効になっていれば、認証および承認されたユーザはアプリケーションを使用できます。無効の場合は使用できません。

    アプリケーションの実行に必要なリソース

    ユーザが特定のアクションを実行するために Use 許可 (ロールで特権の一部として有効化されたもの) を保持していなければならないリソース。Web アプリケーションおよびクライアント・アプリケーションの場合、このリソースはアプリケーションの単純な操作に必要です。特権ルーチン・アプリケーションの場合、このリソースは、アプリケーションでのロールのエスカレーションを可能にする AddRoles メソッドの呼び出し時に必要になります。

アプリケーションの編集 : [アプリケーションロール] タブ

Web アプリケーション、特権ルーチン・アプリケーション、またはクライアント・アプリケーションについては、すべてのユーザが特定のロールを取得するようにアプリケーションを構成できます。こうしたロールは、アプリケーション・ロールと呼ばれます。

アプリケーションのアプリケーション・ロールを指定する手順は以下のとおりです。

  1. 管理ポータルのメニューで、[システム管理][セキュリティ][アプリケーション] を選択します。これにより、さまざまなアプリケーション・タイプが表示されます。

  2. [ウェブ・アプリケーション][特権ルーチンアプリケーション]、または [クライアントアプリケーション] を選択します。選択したアプリケーション・タイプのページが表示されます。

  3. アプリケーションのページで、アプリケーションの名前をクリックして編集用に選択します。そのアプリケーションの [編集] ページが表示されます。

  4. [編集] ページで、[アプリケーション・ロール] タブを選択します。

  5. 1 つ以上のアプリケーション・ロールを指定するには、[使用可能] リストに含まれているロールをクリックします。ロールを [選択済み] リストに移動します。

  6. [割り当てる] をクリックして、アプリケーション・ロールを設定します。

アプリケーションの編集 : [マッチングロール] タブ

Web アプリケーション、特権ルーチン・アプリケーション、またはクライアント・アプリケーションについては、マッチングロールおよびターゲット・ロールをサポートするようにアプリケーションを構成できます。いずれかのマッチングロールに割り当てられているユーザがそのアプリケーションを実行すると、そのユーザは InterSystems IRIS によって関連するターゲット・ロールに割り当てられます。1 つのアプリケーションに複数のマッチングロールを含めることができます。マッチングロールごとに、複数のターゲット・ロールを含めることができます。また、複数のマッチングロールに同一のターゲット・ロールを含めることができます。

アプリケーションでマッチングロールとそのターゲット・ロールを設定する手順は以下のとおりです。

  1. 管理ポータルのメニューで、[システム管理][セキュリティ][アプリケーション] を選択します。これにより、さまざまなアプリケーション・タイプが表示されます。

  2. [ウェブ・アプリケーション][特権ルーチンアプリケーション]、または [クライアントアプリケーション] を選択します。選択したアプリケーション・タイプのページが表示されます。

  3. アプリケーションのページで、アプリケーションの名前をクリックして編集用に選択します。そのアプリケーションの [編集] ページが表示されます。

  4. [編集] ページで、[マッチングロール] タブを選択します。

  5. [マッチングロール] タブで、[マッチングロールの選択] ドロップ・ダウンからマッチングロールとするロールを選択します。

  6. 付随するターゲット・ロールを選択するには、[使用可能] リストに含まれているロールをクリックします。ロールを [選択済み] リストに移動します。

  7. [割り当てる] をクリックして、マッチングロールとそのターゲット・ロールを設定します。

アプリケーションの編集 : [ルーチン/クラス] タブ

このタブは特権ルーチン・アプリケーションでのみ使用できます。このタブでは、特権ルーチン・アプリケーションに組み込むクラスまたはルーチンを指定できます。

特権ルーチン・アプリケーションにクラスまたはルーチンを追加する手順は以下のとおりです。

  1. 管理ポータルのメニューで、[特権ルーチンアプリケーション] ページ ([システム管理] > [セキュリティ] > [アプリケーション] > [特権ルーチンアプリケーション]) に移動します。

  2. [特権ルーチン・アプリケーション] ページには編集可能なアプリケーションのリストがあります。該当するアプリケーションの [名前] をクリックします。アプリケーションの [特権ルーチンアプリケーション編集] ページが表示されます。

  3. [特権ルーチンアプリケーション編集] ページで、[ルーチン/クラス] タブを選択します。

  4. [ルーチン/クラス名] フィールドに、アプリケーションに追加するルーチンまたはクラスの名前を入力します。

  5. [ルーチン][クラス] のうちの追加する方を、該当するチェック・ボックスを選択して指定します。

  6. [割り当てる] をクリックして、アプリケーションにルーチンまたはクラスを追加します。

Web アプリケーションの相互運用対応ネームスペース用の設定

InterSystems IRIS では、特定のインスタンス内で相互運用対応ネームスペースごとに異なる Web アプリケーションを使用できます。したがって、異なるユーザ・セットを有効にして、同じ InterSystems IRIS インスタンス内で異なる相互運用対応ネームスペースにアクセスすることができます。

Web アプリケーションを既存の相互運用対応ネームスペース用に設定する手順は以下のとおりです。

  1. ネームスペースの最初の Web アプリケーションのコピーである Web アプリケーションを作成します。

    ネームスペースを作成すると、最初の Web アプリケーションが /csp/namespace という名前で作成されます。namespace はネームスペースの名前です。

    手順については、"アプリケーションの作成" を参照してください。[コピー元] フィールドを使用して、コピーするアプリケーションを指定できます。

  2. ^%SYS("Ensemble","InstalledNamespace","namespace") グローバル・ノードを、作成した Web アプリケーションの名前に設定します。namespace の値は、新しい Web アプリケーションを使用するネームスペースの名前です。

    例えば、/csp/ensdemocopy という名前の Web アプリケーションを作成し、この Web アプリケーションを ENSDEMO ネームスペースに使用したい場合は、ターミナルで以下のコマンドを実行します。

    set ^%SYS("Ensemble","InstalledNamespace","ENSDEMO")="/csp/ensdemocopy"
    

    ユーザがネームスペースの相互運用性のページに移動すると、新しい Web アプリケーションが表示されます。

組み込みアプリケーション

各 InterSystems IRIS インスタンスには、いくつかの組み込みアプリケーションが付属しています。これにはシステム・アプリケーションのグループが含まれ、%Service_WebGateway サービスが無効になっていても、これらのアプリケーションには常にアクセスできます。

InterSystems IRIS の組み込み Web アプリケーション
名前 目的または管理された対話処理 関連付けられたリソース システム・アプリケーション
/api/atelier InterSystems VS Code 拡張機能によって使用される REST API (%Api.Atelier ディスパッチ・クラス)。 %Development いいえ
/api/deepsee InterSystems IRIS Code Business Intelligence によって使用される REST API (%Api.DeepSee ディスパッチ・クラス)。   いいえ
/api/docdb DocDB REST API (%Api.DocDB ディスパッチ・クラス)。   いいえ
/api/iam InterSystems API Manager (IAM) REST API (%Api.IAM ディスパッチクラス)。InterSystems IRIS から IAM ライセンスを取得する際に使用します。 %IAM いいえ
/api/iknow iKnow REST API (%Api.iKnow ディスパッチ・クラス)。   いいえ
/api/interop-editors ルール・エディタ REST API (%Api.InteropEditors ディスパッチ・クラス)。   いいえ
/api/mgmnt API 管理 REST API (%Api.Mgmnt ディスパッチ・クラス)。   いいえ
/api/monitor Monitoring REST API (%Api.Monitor ディスパッチ・クラス)   いいえ
/api/uima UIMA REST API (%Api.UIMA ディスパッチ・クラス)。   いいえ
/csp/broker 共通の静的ファイル・ストア。インターシステムズ内部での使用専用。   はい
/csp/documatic インターシステムズのクラス・リファレンス・ドキュメント。 %Development はい
/csp/sys ポータルへの一般アクセス。   はい
/csp/sys/exp ポータルのデータ管理オプション。 %Development はい
/csp/sys/mgr ポータルの構成およびライセンス・オプション。 %Admin_Manage はい
/csp/sys/op ポータルの操作オプション。 %Admin_Operate はい
/csp/sys/sec ポータルのセキュリティ管理および暗号化オプション。 %Admin_Secure はい
/csp/user USER ネームスペースの既定のアプリケーション。   いいえ
/isc/pki インターシステムズ公開鍵基盤 (PKI)。   はい
/isc/studio/rules CSP ルール・ファイルへのマッピング。   はい
/isc/studio/templates システム定義のスタジオ・テンプレート・ファイルへのマッピング。 %Development はい
/isc/studio/usertemplates ユーザ定義のスタジオ・テンプレート・ファイルへのマッピング。   いいえ
/oauth2 InterSystems IRIS が OAuth 2.0 承認サーバとして構成されている場合、そのサーバによって使用。 %Admin_Secure いいえ
/ui/interop/rule-editor ルール・エディタのユーザ・インタフェース。   いいえ
FeedbackOpens in a new tab