認証の共有方法

CSPSHARE

CSP はブラウザから要求を受け取ると、受け取った sessionId が有効なものであるかどうかを確認するため、一連のチェックを行います。これらのチェックには、以下が含まれます。

• ユーザ - エージェントがこの sessionId からの以前の要求のものと同じであるかどうか

• Cookie が使用されている場合、この sessionId が Cookie に由来するものなのか、CSPCHD パラメータに由来するものなのか

CSPSHARE=1 のクエリ・パラメータを渡すと、[ログイン CSRF 攻撃を防ぐ] オプションがチェックされている場合、アプリケーションが Cookie のみを使用するよう構成されていても、URL を介して sessionId を渡すことはできません。この動作を採用することをお勧めします。

[ログイン CSRF 攻撃を防ぐ] オプションがチェックされておらず、CSPSHARE=1 である場合、CSP はチェックを実施せず、ユーザは別のアプリケーションへのリンクを構築し、CSPCHD=sessionId を使用して現在の sessionId を含めることができるため、このリンクは既存のページと同じセッションを実行します。また、リンクを構築する際に CSPSHARE=1 である場合、CSP は自動的にリンクに CSPCHD=sessionId を挿入します。Write 文を使用して手動でリンクを挿入する場合は、sessionId を手動で挿入する必要がある場合があります。例えば、https ページから http ページ (または http ページから https ページ) を要求するアプリケーションがある場合、以下のように CSPSHARE=1 をリンクに追加します。

#(..Link()(%request.URL_"?CSPSHARE=1"))#

CSPSHARE=1 はリンクの構築で CSPCHD が強制的に追加されるようにし、InterSystems IRIS で Cookie が有効であることが検出された場合でも、sessionId が共有されます。

詳細は、"CSPSHARE に関する考慮事項" を参照してください。

セキュリティ・コンテキストと Sticky Login

アプリケーションはセッションで実行されます。セッションでは、アプリケーションを実行するセキュリティ・コンテキストを必要とします。セキュリティ・コンテキストには、認証の状態が含まれます。

By-Session グループと By-ID グループには、Sticky Login があり、セッションまたはグループで最後に使用されたアプリケーションのセキュリティ・コンテキストが記憶されます。グループのアプリケーション内のユーザが異なるユーザとしてログインした場合、Sticky Login は更新されます (ユーザが認証のないアプリケーションにログインした場合は、Sticky Login は更新されません)。

セッションでアプリケーションにジャンプすると、そのセッションはターゲット・アプリケーションに適した Sticky Login の使用を試みます。Sticky Login がセッションの現在のセキュリティ・コンテキストに一致せず、アプリケーションが Sticky Login の認証方法を受け入れることができる場合は、セッションのセキュリティ・コンテキストは Sticky Login のコンテキストに切り替えられます。

セッションが終了すると、セッションの Sticky Login は失われます。グループのアプリケーションのいずれかを含むセッションがすべて終了すると、グループの Sticky Login は失われます。

最初のログイン後、グループには関連付けられた Sticky Login オブジェクトが存在します。グループのアプリケーションのいずれかに入る際に、このオブジェクトの使用が試みられます。グループ内のアプリケーションに UnknownUser として入ると、グループ内のその他すべてのアプリケーションを認証なしのセキュリティ・コンテキストに移動することになるため、Sticky Login は更新されません。

Sticky Login に 2 要素認証で認証されたユーザが含まれる場合、2 要素以外のアプリケーションでもその 2 要素認証が使用されます (ただし、ユーザ名認証がその 2 つのアプリケーションで一致する場合)。

カスケード認証

アプリケーションの認証情報の取得を試みる際、CSP サーバは優先度を使用します。CSP サーバは、以下のイベントごとに新しい認証情報を取得しようとします。

• 新規セッションへの最初の要求の場合

• セッション内でアプリケーションの変更があった場合

• アプリケーションが By-ID グループの一部であり、セッションの現在のセキュリティ・コンテキストがグループの Sticky Login のコンテキストと一致しない場合

• 要求にユーザ名/パスワードのペアが含まれる場合

CSP サーバは、以下の順序で新しい認証情報を取得しようとします。

1. 明示的なログイン ： ユーザが認証されたユーザ名/パスワードを入力したかどうかをチェックします。そうである場合、システムはアプリケーションの認証グループのコンテキストを更新します (これによりグループの Sticky Login が設定されます)。

2. Sticky Login ： アプリケーションのグループの Sticky Login のコンテキストが取得されます。Sticky Login と By-Session グループがない場合、セッションの現在のコンテキストを使用します。

3. ログイン Cookie ： このアプリケーションでこれが存在し、有効化されている場合に使用します。

4. 認証なし ： アプリケーションで有効にされている場合に不明ユーザを使用します。

5. ログイン・ページの表示 ： 上記すべてが失敗した場合、ユーザからユーザ名/パスワードを要求します。%CSP.SessionOpens in a new tab API から呼び出された場合、ユーザ名/パスワードのみが試行されます。ログイン後、UnknownUser としてログインした場合を除き、グループの Sticky Login を更新します。

ログアウトまたはセッションの終了

セッションがログアウトまたは終了されると、認証は失われます。セッションをログアウトまたは終了するには、以下の %CSP.SessionOpens in a new tab メソッドを使用できます。

CSP セッションをログアウトするには、文字列 CacheLogout=end を含む URL を渡して、アプリケーションのホーム・ページにリンクすることをお勧めします。これにより、ホーム・ページの実行が試行される前に、現在のセッションが終了します (つまり、取得したライセンスが解放され、既存のセッション・データが削除され、セッションのセキュリティ・コンテキストが削除されます)。

この Web アプリケーションで認証が必要な場合、セッションも認証されたユーザも存在しません。この場合、IRIS ではホーム・ページのロジックを実行せず、代わりにログイン・ページを表示します。ユーザが有効なログインを実行すると、新しいセッションが開始され、ホーム・ページが表示されます。

これによりセッションは強制終了されます。セッションの Sticky Login のコンテキストは破棄されます。OnEndSession() が呼び出されます。セッションに By-Session グループが含まれる場合、このグループは破棄されます。セッションに By-ID アプリケーションが含まれる場合、そのアプリケーションはグループから削除され、それがグループ内の唯一のアプリケーションでない限り、グループは存在し続けます。ログイン Cookie は影響を受けません。By-Session グループのデータは失われます。ただし、By-ID グループの場合、グループの Sticky Login は一度の破棄では影響を受けず、グループのその他のメンバは引き続きログインしたままになります。

さらに、By-Session グループでは、破棄によりグループのメンバは分散され、メンバのアプリケーションに再び入った場合、同じ新規セッションに再度統合されるか、(CSPSHARE を使用してグループ化されていた場合) さまざまなセッションに送られるかは保証されません。

セッションはログアウトされます。Sticky Login のコンテキストは破棄されます。セッションに By-Session グループが含まれる場合、グループ内のすべてのアプリケーションの認証が失われます。セッションに、By-ID グループのアプリケーションが含まれる場合、グループは Sticky Login のコンテキストを失い、そのグループ内のすべてのアプリケーションはログアウトされます。

また、OnLogout が呼び出されます。ログイン Cookie が破棄されます。

セッションは存続するため、データは By-Session グループ用に保持されます。

特定のユーザとして現在認証されているすべてのセッションをログアウトすることができます。

これにより、ログイン Cookie は破棄されます。

セッションは存続しますが、認証は失われます。

ログイン Cookie の考慮事項

ログイン Cookie を介して共有するかどうかを決定する際は、以下の点について検討してください。

• ログイン Cookie は、新規ユーザがパスワードを入力してログインするたびに、そのユーザに更新されます。

• ログイン Cookie は、認証なしのログイン (UnknownUser として) に対しては生成されません。

• ログイン Cookie は、API 呼び出しを介したログイン時には生成されません。

• ログイン Cookie のセッションは、セッションが認証されると独立します。そのため、あるセッションからログアウトするか、そのセッションがタイムアウトしても、その他のセッションには影響しません。

• ログイン Cookie アプリケーションからの認証は、パスワードのみの (ログイン Cookie を使用しない) アプリケーションとは共有できません。グループ内の認証ありのアプリケーションの一貫した動作を確保するには、すべてのアプリケーションにログイン Cookie を使用するか、またはどれにも使用しないでください。

グループの考慮事項

このセクションには、認証を共有する認証グループを作成する際に検討すべきいくつかのポイントが含まれています。

• セッション共有は、セッション・オブジェクトを介してデータを共有する必要があると判断した場合にのみ使用してください。By-ID およびログイン Cookie による共有が、より堅牢で、予測可能です。

• ターゲット・ユーザに対して統一された動作を生み出すために、グループを作成する際は可能な限り一貫性を維持するようにしてください。1 つのアプリケーションを、By-ID グループと By-Session グループの両方に配置しないでください。異なる認証方針を使用すると、予期しない動作を引き起こす可能性があります。By-ID は、By-Session より優先されます。そのため、あるアプリケーションに両方のグループがある場合、By-ID での同期が維持されます。

• グループのすべてのメンバに対して同じ認証タイプを使用してください。特に、グループ内の一部のアプリケーションがログイン Cookie を許可し、その他のアプリケーションが許可しない場合、ユーザ名/パスワードを介してグループに入るとグループ全体が認証されますが、ログイン Cookie を介して入ると一部のアプリケーションのみが認証されることになります。このため、ログインが要求される場合と要求されない場合があることについて、ユーザ間で混乱が生じる可能性があります。

• CSP サーバでは、すべてのアプリケーションが認証グループに属しているものと見なします。そのため、1 つのセッション内の単独のアプリケーションは、単一エンティティの By-Session 認証グループを形成します。

• By-ID グループに、認証なしのみのアプリケーションを配置しないようにしてください。

• By-Session グループは脆弱です。By-ID グループの方が堅牢なアプローチです。共有データを含め、あるグループについてのすべての情報が単一のセッションに含まれるため、グループは容易に失われる可能性があります。これは、セッションはタイムアウトする可能性があるためです。つまり、特定の期間が経過すると、セッションは自動的に破棄されます。ユーザがコンピュータから離れるか、By-Session グループに含まれていないアプリケーションを使用すると、セッションはタイムアウトする可能性があります。グループ内のアプリケーションの 1 つが ENDSESSION=1 とマークすると、グループは分散されます。

• ブラウザで、分散したアプリケーションのページを含むタブが開かれている場合 (特に、それらが元々 CSPSHARE=1 を使用してグループ化されていた場合)、それをクリックすると複数のログインが必要になる場合があります。いずれにしても、元のセッションのデータは永久的に失われます。

  グループが認証を失った場合、グループのアプリケーションから開いているページを更新するか、そのページに移動すると、ユーザの再ログインが必要になります。

• By-Session アプリケーションを含むセッションを終了すると、その By-Session グループ内のアプリケーションのページを更新する際に、ユーザの再ログインが必要になります。By-ID アプリケーションを含むセッションを強制終了する場合は、そのセッションのアプリケーションがグループの唯一のメンバでない限り、ログインは必要ありません。

• セッションをログアウトすると、そのセッションのグループのすべてのメンバが (異なるセッションに属していても) ログアウトされます。グループのいずれかのページを更新するには、新規のログインが必要になります。ただし、By-ID グループでは、1 回のログインで、グループ全体にログインします。By-Session グループの場合、Web ゲートウェイが分散したアプリケーションを新規に構築されたセッション・オブジェクトに戻すことができるならば、1 回のログインでグループ全体にログインします。

• ログアウトしてもセッションは破棄されないため、セッション・データはすべて存続します。

• 同じブラウザの異なるタブで、2 人の異なるユーザが同じアプリケーションにログインすることはできません。

• 認証は単一のブラウザでのみ共有されます。このランタイム識別子は、%Session オブジェクトに格納されます。

• グループ化により、同じグループ (By-ID) または同じセッション (By-Session) 内のユーザ間で認証を共有することが可能になります。指定のグループ外のアプリケーションからの認証を共有する場合は、ログイン Cookie を使用してください。指定のグループ外のアプリケーションに認証を送信する場合は、CSPSHARE=1 を使用してください ("CSPSHARE に関する考慮事項" を参照してください)。

CSPSHARE に関する考慮事項

CSPSHARE は、最終的な手段として使用してください。

By-Session アプリケーションのリンクは、以下の状況では CSPSHARE=1 を必要としません。

• ソース・アプリケーションとターゲット・アプリケーションが同じグループ ID を持っている場合。

• ターゲット・ページがソース・ページと同じアプリケーションに存在する場合。

• ターゲット・ページのアプリケーションのセッション Cookie パスが、ソース・アプリケーションのセッション Cookie パスと一致する場合。

データの共有

By-Session グループは、セッション・オブジェクトを介してデータを共有できます。

By-ID グループは、独自のデータを管理する必要があります。例えば、データがグローバルに格納されている場合、現在のユーザ、$Username、またはグループのランタイム ID を使用して、データにキーを設定できます。CSP サーバは各ブラウザにブラウザ ID の Cookie を割り当てます。By-ID グループが作成されると、そのグループにキーが割り当てられます。このキーは、ブラウザ ID とグループ ID が連結されたものです。これにより一意のキーである %CSP.Session.BrowserId が作成されます。これはデータを格納する際のキーとして使用できます。