CSP セッション管理
HTTP は、ステートレスのプロトコルであり、それぞれの要求は前の要求を認識しません。ユーザに静的なコンテンツを提供する Web サイトには適切に機能しますが、インタラクティブで動的な Web アプリケーションの開発は困難です。この問題に対処するために、CSP ではセッション管理機能を提供しています。
CSP.Session を持つセッション
セッションとは、一定時間内に、特定のクライアントから特定のアプリケーションへ送信される一連の要求です。
CSP は、自動的にセッションのトラッキングを実行するため、手動で実行する必要はありません。CSP アプリケーションは、%CSP.SessionOpens in a new tab オブジェクトを使用して、セッション状況の問い合わせや変更ができます。CSP サーバは、%session という ObjectScript 変数を介して、このオブジェクトを使用できるようにします。アプリケーション間での認証セッションまたはデータの共有の詳細は、"認証共有の方法" を参照してください。
セッションの生成
セッションは、HTTP クライアントが CSP アプリケーションに要求を送信したときに始まります。
新規セッションの開始後、CSP サーバは以下を実行します。
-
新規セッションの ID 番号を生成します。
-
ライセンスが適切であるかを確認します。
-
%CSP.SessionOpens in a new tab オブジェクト (永続オブジェクト) の新規インスタンスを生成します。
-
現在のセッション・イベント・クラスがある場合は、その OnStartSession メソッドを実行します。
-
セッション進行中、HTTP クライアントからの連続した要求を追跡するために、セッション cookie を生成します。クライアントのブラウザで cookie が無効になっている場合、CSP はセッションを追跡するために、自動的に (各 URL に特別な値を付ける) URL の再書き込み機能を使用します。
%CSP.SessionOpens in a new tab オブジェクトの NewSession プロパティは、セッションの最初の要求では 1 に、それに続くすべての要求では 0 に設定されています。
If (%session.NewSession = 1) {
// this is a new session
}
セッション ID
CSP アプリケーションは、%CSP.SessionOpens in a new tab オブジェクトの SessionId プロパティから、特定のセッション ID を検索することができます。
Write "Session ID is: ", %session.SessionId
セッションの終了とクリーンアップ
セッションは、以下のいずれかの理由で終了します (ログアウトの詳細は、このドキュメントの “セッションのログアウトまたは終了” を参照してください)。
-
セッション・タイムアウトの設定時間内に要求を受け取らず、セッションがタイムアウトになった場合
-
CSP セッションからログアウトする方法として、アプリケーションのホーム・ページにリンクし、CacheLogout=end という文字列を含む URL を渡すことをお勧めします。これにより、現在のセッションが終了し、取得したすべてのライセンスの解放、既存のセッション・データの削除、セッションのセキュリティ・コンテキストの削除が実行されたうえで、ホーム・ページの実行に移ります。
-
セッションは、サーバ上でプログラム処理で明示的に終了します (%CSP.SessionOpens in a new tab オブジェクトの EndSession プロパティを 1 に設定することによる)。例えば、クライアントが停止した場合や別のサイトに移動した場合は、セッションを終了する必要があります。
-
セッションは、%CSP.SessionOpens in a new tab オブジェクトの Logout メソッドを使用してログアウトできます。
セッションが終了した場合、CSP サーバは、永続 %CSP.SessionOpens in a new tab オブジェクトを削除し、必要に応じてセッション・ライセンスのカウンタをデクリメントします。タイムアウトまたはサーバの処理によってセッションが終了した場合は、そのセッションのイベント・クラスが存在していれば、そのクラスの OnEndSession メソッドも呼び出されます。
ある Zen コンポーネント (tablePane など) は、一時データを ^CacheTemp.zenData に格納します。これは通常、既定のイベント・クラスにより自動的にクリーンアップされます。しかし、ユーザ自身のカスタム・イベント・クラスを定義する場合、そのイベント・クラスの OnEndSession() コールバック・メソッドの %ZEN.Controller.OnEndSession() を明示的に呼び出す必要があります。これをしない場合は、一時データはクリーンアップされません。
CSP の予約パラメータ
以下のテーブルは、予約パラメータとそれらの使用を示しています。
| パラメータ | 使用 |
|---|---|
| CacheUserName |
ログイン・ページから使用します。例えば、CacheUserName="fred など、ログインするユーザ名が含まれます。 |
| CachePassword |
ログイン・ページから使用します。例えば、CachePassword="fredspwd" など、CacheUserName で指定したユーザのパスワードが含まれます。 |
| CacheOldPassword |
CacheUserName と CachePassword と共に渡された場合、このパラメータにはユーザの現在のパスワードが含まれます。セキュリティ・ルーチンによってユーザのパスワードが、CacheOldPassword="fredsAboutToBeChangedPwd" など、CachePassword の値から取られた新しい値に変更されます。パスワードが変更されたら、ユーザは新規パスワードを使用してログインされます。 |
| CacheRepeatPassword |
使用されていません。 |
| CacheLogin |
使用されていません。 |
| CacheLogout |
CacheLogout に値を指定しないか、"cookie" 以外の値を指定すると、この要求のセッションがログアウトされます (ただし破棄はされません)。ログアウトによって、現在のログイン Cookie が破棄され、このセッションに不安定なまま保持されている 2 要素向けのセキュリティ・トークンが削除されます。 CacheLogout="cookie" によって、現在のログイン Cookie が破棄されます。 |
| CacheSecurityToken |
CacheSecurityToken には、CacheSecurityToken="12345678" など、[ログイン・セキュリティ・トークン] ページから送信されたセキュリティ・トークンの値が含まれます。 |
| CacheSecuritySubmit |
この名前が存在するということは、値が CacheSecurityToken に関連付けられているセキュリティ・トークンをユーザが送信していることを示しています。 |
| CacheSecurityCancel |
この名前が存在するということは、ユーザが [ログイン・セキュリティ・トークン] ページでキャンセルしたことを示しています。 |
| CacheLoginPage |
カスタム・ログイン・ページを含め、ログイン・ページには 2 つのサブページがあります。ログイン用のサブページと、セキュリティ・トークンの値を返すためのサブページです。ログイン・ページでは、CacheLoginPage の値が確認されて、表示するサブページが決められます。CacheLoginPage=1 は、ログイン・サブページを表示することを示しています。 |
| CacheNoRedirect |
要求されたページ P が非認証の場合は、ログイン・ページが表示されます。ユーザがログイン・ページから情報を送信した後、通常は、P のページ要求は元のブラウザにリダイレクトされます (これによって、ブラウザが P を表示する前に、ユーザに <Resend> ボタンを押すように求めることがなくなります)。この動作は、CacheNoRedirect=1 を渡すことによって簡略化できます。 |
%CSP.Session オブジェクト
%CSP.SessionOpens in a new tab オブジェクトには、現在のセッションとセッションの側面をプログラミングによって管理するための情報が含まれています。
ユーザ・セッション・データ — Data プロパティ
%CSP.SessionOpens in a new tab オブジェクトの Data プロパティを使用して、そのオブジェクトにアプリケーション固有の情報を格納できます。Data は多次元配列のプロパティで、これを使用することで特定の情報の断片を多次元配列に関連付けることができます。この配列のコンテンツは、セッションの終了まで自動的に維持されます。
他の ObjectScript 多次元配列の使用法と同じ方法で、%CSP.SessionOpens in a new tab オブジェクトの Data プロパティを使用できます。
例えば、OnPage メソッドで以下のコードを実行します。
Set %session.Data("MyData") = 22
同じセッションのそれ以降の要求は、(どのクラスが処理をするかにかかわらず) %CSP.SessionOpens in a new tab オブジェクト内のこの値を参照します。
Write $Get(%session.Data("MyData")) // this should print 22
%CSP.SessionOpens in a new tab にアプリケーション特有のデータを格納する機能は非常に高機能ですが、適切に使用する必要があります。詳細は、“ステート管理” のセクションを参照してください。
ユーザ・セッション・データの設定 — Set コマンド
%CSP.SessionOpens in a new tab オブジェクトにデータを格納するには、Set コマンドを使用します。この場合のデータはリテラル・データのみで、オブジェクト参照は除きます。Data 配列中のすべてのノードは、最大 32,000 語までの文字列を含むことができます。
Set %session.Data("MyData") = "hello"
Set %session.Data("MyData",1) = 42
ユーザ・セッション・データの取得 — Write コマンド
ObjectScript 式の一部として Data プロパティからデータを取得できます。
Write %session.Data("MyData")
Write %session.Data("MyData",1) * 5
値を有していない Data 配列のノードを参照すると、実行時に <UNDEFINED> (未定義) エラーが発生します。これを避けるには、ObjectScript の $Get 関数を使用します。
Write $Get(%session.Data(1,1,1)) // return a value or ""
ユーザ・セッション・データの削除 — Kill コマンド
Data プロパティからデータを削除するには、ObjectScript の Kill コマンドを使用します。
Kill %session.Data("MyData")
セッション・タイムアウト
CSP セッションは、クライアントからの要求の受信後の経過時間を自動的にトラッキングします。あらかじめ設定した時間が経過すると、セッションは自動的にタイムアウトになります。
セッション・タイムアウトの既定値は、900秒 (15分) です。CSP アプリケーションに対するこの既定値は、管理ポータルの システム, セキュリティ, ウェブアプリケーション ページで変更できます。目的のアプリケーションを選択して [編集] をクリックします。また、%CSP.SessionOpens in a new tab オブジェクトの AppTimeout プロパティを設定すると、アプリケーションでもその値を設定できます。
Set %session.AppTimeout = 3600 // set timeout to 1 hour
セッション・タイムアウトを無効にするには、タイムアウト値を 0 に設定します。
セッションがその有効期間中に CSP アプリケーションを変更する場合、そのタイムアウト値はセッションの移動先のアプリケーションで定義された既定のタイムアウト値に合わせて更新されないことに注意してください。例えば、既定のタイムアウト値が 900 秒の CSP アプリケーション A でセッションが開始し、その後、既定のタイムアウト値が 1800 秒の CSP アプリケーション B に移動した場合、セッションは 900 秒後にタイムアウトになります。
アプリケーションを変更するときにセッション・タイムアウトが新規アプリケーションのセッション・タイムアウトに更新されるようにするには、セッション・イベント・クラスを使用し、OnApplicationChange コールバック・メソッドをオーバーライドして、%session オブジェクトの AppTimeout プロパティの更新を処理するコードを追加します。
タイムアウト通知 — OnTimeout メソッド
CSP アプリケーションでタイムアウトが発生すると、CSP サーバは、指定された %CSP.SessionEventsOpens in a new tab クラスの OnTimeout メソッドを実行してアプリケーションに通知できます。このクラス名は、%CSP.SessionOpens in a new tab オブジェクトの EventClass プロパティで指定します。
既定では、イベント・クラスは定義されていないため、タイムアウトは現在のセッションを終了します。
ステート管理
HTTP はステートレスなプロトコルです。したがって、Web 向けに作成するアプリケーションでは、アプリケーションのコンテキストであるステートを管理するために特別な手法が必要です。CSP には、ステート管理の機能がいくつか用意されています。これらの機能にはそれぞれ、最適な使用状況があります。
要求間のデータの追跡
Web アプリケーションでステートを管理する場合、連続的な HTTP 要求の間の情報を継続的に追跡するという点が基本的な問題となります。これを解決するために、以下のようなテクニックがあります。
-
非表示フォーム・フィールドまたは URL パラメータを使用して、個々のページにデータを格納します。
-
クライアント上の cookie にデータを格納します。
-
サーバ上の %CSP.SessionOpens in a new tab オブジェクトにデータを保存します。
ページへのデータの格納
ページにステート情報を格納するには、後に続く要求がその情報を持つ必要があります。
ハイパーリンク経由でページが要求された場合、データはハイパーリンクの URL 内に配置される必要があります。以下は .csp ファイル内で定義されたステート情報を含むハイパーリンクの例です。
<a href="page2.csp?DATA=#(data)#">Page 2</A>
このリンクを含むページを CSP サーバから提供する場合、式 #(data)# は、クライアントに送信するテキストに記述されたサーバ変数データの値に置き換えられます。ユーザが page2.csp へのリンクを選択すると、CSP サーバは、%request オブジェクトを介して DATA 値にアクセスします。必要に応じて、CSP はこのようなデータを暗号化できます。詳細は、“認証と暗号化” を参照してください。
ページに書式が含まれている場合、ステート情報は非表示フィールドに配置できます。
<form>
<input type="HIDDEN" name="DATA" value="#(data)#">
<input type="SUBMIT">
</form>
ハイパーリンクの例と同様に、この書式がクライアントに送信されるとき、式 #(data)# は変数データの値に置き換えられます。ユーザがこの書式を選択すると、%request オブジェクトを介して DATA 値を利用できるようになります。
すべてのリンクと書式に自動的に値を挿入するには、%response.Context を使用します。
セッションへのデータの格納 — Data プロパティ
前述のセクションで説明したように、Data プロパティを使用して %CSP.SessionOpens in a new tab オブジェクトにステート情報を格納できます。%session オブジェクトに格納された情報は、現在のセッションが継続している間、または %session オブジェクトから削除されるまで利用できます。
%session オブジェクトは、現在のユーザ名のようにセッション実行中に必要な簡単な情報を格納するのに最適です。しかし、%session オブジェクトは、現在のセッションの有効範囲を超えて保持する必要のある情報には不適切です。また、アプリケーションをユーザがどのように経由したかという経路 (ナビゲーション・パス) に左右される情報にも適していません。通常、ユーザは自由に Web アプリケーションを移動できるため、特定のパスを通過したと仮定してアプリケーションを構築すると問題が生じます。
データベースへのデータの格納
ユーザに関する情報でさらに複雑なものがある場合は、組み込みの Caché データベース内に保存するのが最適です。その方法の 1 つとして、データベースに 1 つ以上の永続クラスを定義し、そのオブジェクト ID の値を %session オブジェクトに格納しておき、以降のアクセスで使用できるようにする方法があります。
サーバ・コンテキストの保存 — Preserve プロパティ
通常、ある要求から次の要求まで CSP サーバに保存される処理コンテキストのみが、%session オブジェクトに保持されます。CSP サーバには、すべての処理コンテキスト変数、インスタンス化したオブジェクト、データベースのロック、および要求間で開いているデバイスを保持する機能があります。これは、コンテキスト・プリザービング (状況保存) モードと呼ばれています。%CSP.SessionOpens in a new tab オブジェクトの Preserve プロパティ値を設定することで、いつでも CSP アプリケーションのコンテキスト保存のオン、オフを切り替えることができます。1 つのセッションに 1 プロセスを結びつけると、スケーラビリティが不足します。
認証と暗号化
ステート情報は、HTTP クライアントへ送信するページにあるのが一般的です。後続の要求がこれらのページから生じた場合、このステート情報はサーバへ返送されます。多くの場合、Web ページにステート情報を置くには、a) HTTP ソース・コードを見た人がステート情報の値を理解できないこと、b) 返送された情報が実際に、同じサーバ、同じセッションから送信された情報かどうかをサーバが検証できること、などが重要です。暗号化サービスにより、CSP はこの条件に合う使いやすい機能を提供します。
セッション・キー
CSP では、暗号化キーを使用して、サーバのデータの暗号化および解読を実行します。各 CSP セッションは、%CSP.SessionOpens in a new tab オブジェクトの Key プロパティからアクセス可能な一意のセッション・キーを持ち、セッションのデータを暗号化するために使用します。セッション・キーは HTTP クライアントに送信されないため、この機能は安全です。セッション・キーは %CSP.SessionOpens in a new tab オブジェクトの一部として CSP サーバに残ります。
%CSP.PageOpens in a new tab クラスの Encrypt メソッドを使用して、サーバの値を手動で暗号化できます。その後、Decrypt メソッドを使用してこの値を解読することもできます。
暗号化された URL と CSPToken
ある特定の状況 (以下の説明参照) では、.csp ファイルから生成されたクラスは、クライアントに送信される URL 値を自動的に暗号化します (手動で作成されたクラスでは、暗号化するには %CSP.PageOpens in a new tab クラスの Link メソッドを呼び出す必要があります)。
例えば、以下の .csp ファイルには、他のページへのリンクが定義されているアンカー・タグが含まれます。
<a href="page2.csp?PI=314159">Page 2</a>
この URL が暗号化されている場合、以下の内容がクライアントに送信されます。
<a href="page2.csp?CSPToken=8762KJH987JLJ">Page 2</a>
ユーザがこのリンクを選択すると、暗号化パラメータ CSPToken が CSP サーバに送信されます。サーバはこれを解読し、解読したコンテンツを %request オブジェクトに配置します。暗号化された値が変更された場合や別のセッションから送信された場合、サーバはエラー・メッセージを生成します。%CSP.RequestOpens in a new tab クラスの IsEncrypted メソッドを使用して、パラメータ値が最初から暗号化されているかどうかを確認できます。
CSP コンパイラは、HTML 文書に存在する URL のすべての場所を自動的に検出して、必要に応じ、(以下のセクションの説明にある、目的のページのクラス・パラメータに基づいて) 暗号化を実行します。プログラミングで生成されたページの場合も、%CSP.PageOpens in a new tab クラスの Link メソッドによって同様の動作を実行できます。
リンクを引数として関数に渡す場合、#url()# 指示文ではなく、%CSP.PageOpens in a new tab クラスの Link メソッドを常に使用します。以下にその例を示します。
window.showModalDialog('#(..Link("locks.csp"))#','',windowFeatures);
#url()# を関数への引数として使用する次の例は、機能しません。
window.showModalDialog('#url(locks.csp)#','',windowFeatures);
CSP コンパイラでは検出できない場所にある .csp ファイル内で URL を暗号化する必要がある場合は、#url()# 指示文を使用します。例えば、クライアント側の JavaScript 関数では、リンクがパラメータの場合、以下のように使用できます。
<script language=JavaScript>
function NextPage()
{
// jump to next page
CSPPage.document.location = '#url(nextpage.csp)#';
}
</script>
プライベート・ページ
CSP は、プライベート・ページという概念を提供します。プライベート・ページへは、同じ CSP セッションのページからのみ移動できます。これは、特定のページへのアクセスを制限する必要があるアプリケーションで役に立ちます。
例えば、private.csp (CSP サンプル・ページの 1 つ) というプライベート・ページがあります。ユーザは、private.csp に (その URL を入力するなどの方法により) 直接アクセスすることはできません。private.csp へは、別の CSP ページに含まれたリンクからのみアクセスできます。参照元の CSP ページに含まれるリンクは、http:// で始まる絶対 URL にはできません。参照元ページを基準とした相対パスのみが、プライベート・ページの手法によって適切に暗号化またはトークン化されます。 つまり、以下の最初の 2 つのリンクは、同じトークンを対象のプライベート・ページ test2.csp に渡します。
<A HREF='test2.csp'>Link to private page - relative path</A> <BR>
<A HREF='/csp/samples/test2.csp'>
Link to private page - full application path</A> <BR>
次のリンクは、上記のリンクとは異なる方法でハッシュ化され、アクセスに失敗します。
<A HREF='http://myserver/csp/samples/test2.csp'>
Link to private page - absolute path</A>
また、プライベート・ページはブックマークへの登録もできません。プライベート・ページを保護している暗号化されたトークンは、現在のセッションにのみ有効だからです。
プライベート・ページは以下のように機能します。プライベート・ページに対応する %CSP.PageOpens in a new tab サブクラスには、クラス・パラメータ PRIVATE があり、その値が 1 に設定されています。そのため、このページを要求する URL では、有効な暗号化された CSPToken 値を、問い合せ文字列に記述する必要があります。CSP で処理されたこのページへのすべてのリンクには、自動的に CSPToken 値が指定されます。
コード化された URL パラメータ
プライベート・ページと同様に、CSP ページは %CSP.PageOpens in a new tab クラス・パラメータ ENCODED の値を設定することで、URL パラメータをコード化するかどうかを指定できます。ENCODED は、0、1、または 2 に設定できます。ENCODED クラス・パラメータが 1 または 2 のページへのリンクには、暗号化された CSPToken 値にコード化された URL パラメータが自動的に設定されます。ENCODED が 2 の場合、値のコード化が必要です。1 の場合は、コード化された値とコード化されていない値が混在していてもかまいません。
ENCRYPTED の 3 つの設定は以下のとおりです。
-
ENCODED=0 — クエリ・パラメータは暗号化されません。
-
ENCODED=1 — クエリ・パラメータは暗号化され、CSPToken に渡されます。
-
ENCODED=2 — Page メソッドを呼び出す前に、暗号化されていないパラメータが %request オブジェクトから削除される点を除いて、ENCODED=1 と同じです。このため、暗号化されたパラメータのみが %CSP.RequestOpens in a new tab オブジェクトで使用されるようになります。
ENCODED=2 によって、暗号化されていないパラメータが URL から削除されるため、Zen の <form> 要素などのコンポーネントが無効になる可能性があります。
ENCODED=2 の例
例えば、2 つの .csp ページがあるとします。一方のページ (list.csp) にはハイパーリンクで銀行口座のリストが表示され、もう一方のページ (account.csp) には特定の口座の情報が表示されます。account.csp では、表示する口座を判断するために、ACCOUNTID という URL パラメータを必要とします。クライアント上で口座番号を公開せず、また account.csp への権限のないアクセスやその他の口座番号の表示をしないようにするには、account.csp の ENCODED パラメータを 2 に設定します。以下は、関連のある .csp です。
list.csp のソース
<html>
<body>
Select an account:<br>
<a href="account.csp?ACCOUNTID=100">Checking</a>
<a href="account.csp?ACCOUNTID=105">Saving</a>
</body>
</html>
account.csp のソース
<html>
<csp:class private=1 encoded=2>
<body>
Account Balance: <b>$#(..GetBalance())#</b>
</body>
<script language="Cache" method="GetBalance" arguments=""
returntype="%Integer">
// server-side method to lookup account balance
New id
Set id = $Get(%request.Data("ACCOUNTID",1))
If (id = 100) {
Quit 157
}
ElseIf (id = 105) {
Quit 11987
}
Quit 0
</script>
</html>
CSP サーバは、list.csp が要求されたとき、以下の HTML をクライアントに送信します。
<html>
<body>
Select an account:<br>
<a href="account.csp?CSPToken=fSVnWw0jKIs">Checking</a>
<a href="account.csp?CSPToken=1tLL6NKgysXi">Saving</a>
</body>
</html>
ACCOUNTID の暗号化された値のみがクライアントに送信されます。
account.csp が処理されると、ACCOUNTID の解読された値が認識され、account.csp の GetBalance メソッドで参照されます。
ENCODED=1 の例
ENCODED=2 と ENCODED=1 との違いは、ENCODED=2 の場合は、暗号化されていない形式の URL に追加されるテキストはすべて破棄されるということです。ENCODED=1 を使用すると、暗号化されていないテキストがページに渡されます。次に、ページには、この暗号化されていないテキストの処理を指定するコードを含めることができます。
サンプル・ページの protected.csp と protectedentry.cspOpens in a new tab は、ENCODED=1 を使用した例を示しています。protected.csp のソースは、暗号化されていない URL に追加されているものが確認されることを示しています。暗号化されていないものがある場合、ページには、HACKER ALERT! というスクローリング・マーキーが表示されます。
これを確認するには、サンプル・ページOpens in a new tabに移動してください。
-
protectedentry.cspOpens in a new tab をダブルクリックします。
-
[残高] フィールドに「500」と入力します。
-
[残高の確認] をクリックします。
-
protected.csp ページが開き、「お客様の口座の残高は、500 です」と、表示されます。
-
URL には、暗号化された CSPToken が含まれていることに注意してください (CSPTaken= の後すべて)。これは、入力して暗号化された 500 です。
-
この URL の末尾に移動し、「BALANCE=8000」と入力し、Enter キーを押します。
-
protected.csp ページが表示されます。このページは、URL への暗号化されていない追加を受け入れ、HACKER ALERT! マーキーを表示することによってそれに対処しました。ENCODED を 2 に設定していたら、暗号化されていない入力は無視されていました。
認証共有の方法
このセクションでは、以下の 2 つの方法でグループとして機能するアプリケーションのセットを作成する方法を説明します。
-
認証の共有 ： アプリケーションで認証を共有しない場合、ユーザは、別のアプリケーションによってリンクされているアプリケーションごとに個別にログインする必要があります。認証の共有によって、ユーザは、一度ログインするだけで、リンクされているすべてのアプリケーションに入れるようになります。
-
データの共有 ： アプリケーションで、グローバル状態の情報を共有したり調整したりできます。
このセクションでは、以下の項目について説明します。
認証方法
このセクションでは、以下の認証方法について説明します。これらの認証方法を実装するためのオプションは、システム, セキュリティ, ウェブ・アプリケーション ページにあります。
-
1 回限りの共有 ： ログイン Cookie。ID が同じアプリケーションすべてで認証が共有されます。これは、CSP アプリケーションのオプション Login Cookies に対応しています。
-
連続する共有 ： ID 単位またはセッション単位による認証グループ
-
セッション単位。これは、CSP アプリケーションの 2 つのオプションに対応しています。[セッションCookieパス] オプションを使用すると、同じ session-path-cookie を用いるアプリケーションで、セッションとその認証が共有されます。CSPSHARE オプションを CSPSHARE=1 に設定した場合、ユーザが (ソース・アプリケーションで) ターゲット・アプリケーションへのリンクをクリックすると、ターゲット・アプリケーションは、ソース・アプリケーションと同じセッションに配置されます。
-
1 回限りの共有 ： ログイン Cookie
ログイン Cookie には、最後にログインしたユーザに関する情報が保持されています。ユーザによる頻繁なログインの必要性をなくすが、アプリケーションを独立した接続されていない状態に保つには、ログイン Cookie を使用します。
ログイン Cookie の場合、各アプリケーションは別々のセッションに配置します。そうすれば、アプリケーションに最初に入ったときにのみ認証が共有されます。ログイン Cookie を使用したアプリケーションでは、グループは形成されません。このため、ログイン後、1 つのアプリケーションで認証を変更しても、他のアプリケーションに影響を与えることはありません。
ユーザがパスワードを使用してログインすると、その認証は Cookie に保存されます。ログイン Cookie が有効になっている別のアプリケーションに (初めて) 入った場合、Cookie に保存されている認証が使用されます。次に、ログイン Cookie が有効になっていない 3 つ目のアプリケーションに (初めて) 入った場合、このユーザはユーザ名/パスワードを入力する必要があります。
使用する方法の決定の詳細は、“方法を選択するときの考慮事項” のセクションを参照してください。
ログイン Cookie を使用するかどうかを決める場合の考慮事項を以下に示します。
-
ログイン Cookie は、ユーザがパスワードを使用してログインするたびに、新しいユーザに更新されます。
-
ログイン Cookie は、非認証の (不明な) ユーザには生成されません。
-
ログイン Cookie は、API 呼び出しを使用してログインした場合は生成されません。
-
ログイン Cookie が有効なセッションは、一度認証されたら独立したセッションになります。このため、1 つのセッションでログアウトやタイムアウトが行われても、他のセッションに影響を与えることはありません。
-
ログイン Cookie を使用したアプリケーションの認証を、パスワード認証のみ (非ログイン Cookie) のアプリケーションと共有することはできません。グループで認証されるアプリケーションの場合、動作の一貫性のためには、ログイン Cookie をすべてのアプリケーションで使用するか、またはすべてのアプリケーションで使用しないかのいずれかに設定します。
連続する共有 ： ID 単位またはセッション単位による認証グループ
グループでの共有の場合、グループのアプリケーションの認証はユニットとして移動します。グループ内の 1 つのアプリケーションのユーザが新規ユーザとしてログインすると、すべてのアプリケーションがそのユーザに移動します。1 つのアプリケーションがログアウトすると、すべてのアプリケーションがログアウトされます。
アプリケーションは、2 つの方法でグループにすることができます。セッション単位と ID 単位です。セッション単位のグループでは、認証とデータが共有されます。ID 単位のグループでは、認証のみが共有されます。
アプリケーションは CSP セッションで実行されます。各セッションにはセキュリティ・コンテキストが関連付けられています CSP セッションの詳細は、このドキュメントの "CSP セッションについて" のセクションを参照してください。
同じセッションに複数のアプリケーションを配置すると、それらのアプリケーションで認証が共有されます。これは、セッション単位のグループ (セッション共有) と呼ばれます。また、セッションにユーザ定義のデータが含まれる場合があります。リンクを介してアプリケーション間を移動するときに、アプリケーションの Cookie パスを完全に一致させるか、または CSPSHARE=1 フラグを使用することによって、アプリケーションがセッションを共有できるようになります。
マッチング・グループ識別子をアプリケーションに割り当てることによって、アプリケーションをグループ化することができます。これは、ID 単位のグループと呼ばれます。このグループでは、セキュリティ・コンテキストが共有されます。アプリケーションは通常、別々のセッションに配置されます。このグループでは、ユーザ・データが管理されることはなく、認証のみが共有されます。
詳細は、“方法を選択するときの考慮事項” のセクションを参照してください。
セッション単位のグループ (セッション共有)
セッションを共有すると、問題が発生する可能性があります。セッション・イベントは、元の CSP アプリケーションからのみ取得できます。リンク先のページが別のセッションのイベントを要求する場合、そのセッション・イベントは実行されません。また、セキュリティ・コンテキストが異なる別の CSP アプリケーションでページを実行するにはログインが必要となる場合があります。そのログインによって、元の CSP アプリケーションで実行しているページのセキュリティ・コンテキストが影響を受ける可能性があります。 セッション単位のグループの使用を選択する前に、後述の "方法を選択するときの考慮事項" をお読みください。
アプリケーションでセッションを共有する場合、アプリケーションではセッション・オブジェクトを介して認証とデータの両方が共有されます。セッションを共有するには、以下の 2 つの方法があります。
-
セッションCookieパス ： セッション Cookie パスが完全に一致するすべてのアプリケーションが、同一セッションに配置されます。
-
CSPSHARE ： アプリケーションのページへのリンクに CSPSHARE=1 を入れます。これは、ソース・アプリケーションのセッション Cookie パスがターゲットのセッション Cookie パスと異なる場合に使用します。
セッション単位の共有が必要な場合、最善の方法は、すべてのアプリケーションに、同一のセッション Cookie パスを指定できるような名前を付けることです。セッション Cookie パスはアプリケーション名の部分文字列である必要があるため、アプリケーションの名前の変更が必要になる場合があります。
これを実行できない場合にセッションの共有が必要なときは、アプリケーション間を移動するリンクに CSPSHARE パラメータを入れる必要があります。ターゲット・アプリケーションのページは、ソース・アプリケーションのページと同じセッションに配置されます。ソースのセッションは、CSPCHD パラメータとセッション Cookie のいずれかから決定されます。
詳細は、“方法を選択するときの考慮事項” のセクションを参照してください。
ID 単位のグループ
アプリケーションをグループ化するには、システム, セキュリティ, ウェブアプリケーション ページの [ID 単位のグループ化] フィールドで目的のグループの名前を指定します。この名前により、開いているアプリケーションはまとめてグループ化されます。グループは別々のセッションに配置されます。アプリケーションでデータを共有することはありません。
グループ名は、ネームスペースではなくアプリケーションにアタッチされます。ネームスペースに関係なく、同じグループ名を持つアプリケーションで認証が共有されます。
認証はブラウザ単体のみで共有されます。
詳細は、“方法を選択するときの考慮事項” のセクションを参照してください。
認証アーキテクチャ
セキュリティ・コンテキストとスティッキー・ログイン
アプリケーションはセッションで実行されます。セッションには、アプリケーションを実行するためのセキュリティ・コンテキストが必要です。セキュリティ・コンテキストには、認証状態が含まれます。
セッション単位および ID 単位のグループには、セッションまたはグループで最後に使用されたアプリケーションのセキュリティ・コンテキストを記憶するスティッキー・ログインが含まれます。グループ・アプリケーション内のユーザが、別のユーザとしてログインした場合、スティッキー・ログインは更新されます。(未認証のアプリケーションにログインする場合、スティッキー・ログインは更新されません。)
セッション内の 1 つのアプリケーションに移動すると、セッションは、そのターゲット・アプリケーションに適したスティッキー・ログインを使用しようとします。スティッキー・ログインがセッションの現在のセキュリティ・コンテキストと一致せず、アプリケーションでスティッキー・ログインの認証メソッドを受け入れることができる場合、セッションのセキュリティ・コンテキストは、スティッキー・コンテキストのものに切り替わります。
セッションのスティッキー・ログインは、セッションの終了時に失われます。グループのスティッキー・ログインは、グループのアプリケーションのいずれかが含まれるセッションがすべて終了したときに失われます。
初期ログインの後に、グループには、グループのいずれかのアプリケーションに入るときに使用しようとするスティッキー・ログインが関連付けられます。このスティッキー・ログインは、グループ内の 1 つのアプリケーションに、不明なユーザとして入るときには更新されません。これによって、グループ内のその他すべてのアプリケーションが非認証のセキュリティ・コンテキストに移動することになるためです。
スティッキー・ログインに 2 要素認証ユーザが含まれる場合、その 2 要素認証は、ユーザ名認証が 2 つのアプリケーションで一致する限り、非 2 要素アプリケーションで使用されます。
カスケード認証
CSP サーバは、アプリケーションの認証情報を取得しようとするときに、優先度を使用します。CSP サーバは、以下のイベントそれぞれで新しい認証情報を取得しようとします。
-
新規セッションに対する最初の要求の場合
-
セッション内でアプリケーションの変更があった場合
-
アプリケーションが ID 単位のグループに属していて、セッションの現在のセキュリティ・コンテキストが、グループのスティッキー・コンテキストのセキュリティ・コンテキストに一致しない場合
-
ユーザ名とパスワードの組み合わせが要求に含まれる場合
CSP サーバは、以下の順序で新しい認証情報を順次取得しようとします。
-
明示ログイン ： 認証されているユーザ名とパスワードをユーザが入力したかどうか確認します。入力した場合、システムでは、アプリケーションの認証グループのコンテキストが更新されます (これによってグループのスティッキー・ログインが設定されます)。
-
スティッキー・ログイン ： アプリケーションのグループのスティッキー・コンテキストを取得します。スティッキー・ログインもグループ単位のセッションもない場合は、セッションの現在のコンテキストを使用します。
-
ログイン Cookie ： ログイン Cookie が存在し、対象のアプリケーションで有効になっている場合に使用します。
-
非認証 ： アプリケーションに対して有効になっている場合は不明なユーザを使用します。
-
ログイン・ページの表示 ： 上記すべてに失敗した場合は、ユーザ名/パスワードを入力するようにユーザに要求します。%CSP.Session API から呼び出された場合は、ユーザ名/パスワードのみが試行されます。UnknownUser としてログインしない限り、ログイン後に、グループのスティッキー・ログインが更新されます。
セッションのログアウトまたは終了
認証は、セッションがログアウトまたは終了すると失われます セッションをログアウトまたは終了するには、以下の %CSP.SessionOpens in a new tab メソッドを使用できます。
CSP セッションからログアウトする方法として、アプリケーションのホーム・ページにリンクし、CacheLogout=end という文字列を含む URL を渡すことをお勧めします。これにより、現在のセッションが終了し、取得したすべてのライセンスの解放、既存のセッション・データの削除、セッションのセキュリティ・コンテキストの削除が実行されたうえで、ホーム・ページの実行に移ります。
認証を必要とする CSP アプリケーションでは、このログアウト処理を実行するとセッションも認証されたユーザも存在しない状態になります。この場合、Caché ではホーム・ページのロジックは実行されず、代わりにログイン・ページが表示されます。ユーザが有効なログインを送信すると新しいセッションが開始され、ホーム・ページが表示されます。
これによってセッションが強制終了されます。セッションのスティッキー・コンテキストは破棄されます。OnEndSession が呼び出されます。セッションにセッション単位のグループが含まれる場合、そのグループは破棄されます。セッションに ID 単位のアプリケーションが含まれる場合、そのアプリケーションはグループから削除されますが、それがグループにある唯一のアプリケーションでない限り、グループは存続します。ログイン Cookie への影響はありません。セッション単位のグループは、データを失います。一方、ID 単位のグループの場合、ログインが 1 つ破棄されただけでそのグループのスティッキー・ログインが影響を受けることはなく、グループのその他のメンバはログイン状態を維持します。
また、セッション単位のグループの場合、破棄によってグループのメンバが分散され、メンバ・アプリケーションに再び入る場合に、同一の新規セッションに再統合されることも、(メンバ・アプリケーションが CSPSHARE を使用してグループ化されていた場合に) さまざまなセッションに送信されることも保証することはできません。
セッションがログアウトされます。そのスティッキー・コンテキストは破棄されます。セッションにセッション単位のグループが含まれる場合、そのグループ内のすべてのアプリケーションが認証を失います。セッションに ID 単位のグループに属するアプリケーションが含まれる場合、そのグループはスティッキー・コンテキストを失い、グループ内のすべてのアプリケーションがログアウトされます。
さらに、OnLogout が呼び出されます。ログイン Cookie は破棄されます。
セッションは存続し、データはセッション単位のグループのために維持されます。
特定のユーザとして現在認証されているすべてのセッションをログアウトすることができます。
これによってログイン Cookie が破棄されます。
セッションは存続しますが、認証は失われます。
方法を選択するときの考慮事項
このセクションでは、方法を選択するときに考慮すべきいくつかの点を示します。使用する方法の決定の詳細は、“1 回限りの共有 ： ログイン Cookie” のセクションを参照してください。
グループの場合の考慮事項
このセクションでは、認証グループを作成するときに考慮すべきいくつかの点を示します。
-
セッション・オブジェクトを介してデータを共有する必要があると判断した場合にのみ、セッション共有を使用します。ID 単位の共有およびログイン Cookie による共有の方が堅牢で予測可能です。
-
グループを作成する場合、できる限り一貫性を持って、ターゲット・ユーザに一様の動作を作成します。1 つのアプリケーションを、ID 単位のグループとセッション単位のグループの両方に配置しないでください。複数の異なる認証方法を使用すると、予期しない動作が生じる可能性があります。ID 単位の共有は、セッション単位の共有よりも優先されます。このため、1 つのアプリケーションに両方が含まれる場合は、ID 単位で同期がとられます。
-
グループ内のすべてのメンバに同じ認証タイプを使用します。特に、グループ内の一部のアプリケーションでログイン Cookie が有効で、その他のアプリケーションでは有効になっていない場合、ユーザ名/パスワードを使用してグループに入ろうとするとグループ全体が認証されますが、ログイン Cookie を使用して入ろうとすると、一部のアプリケーションのみが認証されます。これによって、ログインが必要な場合もあれば、タイムアウトになる場合もあるため、ユーザ間に混乱を招く可能性があります。
-
CSP サーバでは、あらゆるアプリケーションがいずれかの認証グループに属していると見なされます。1 つのセッション内にアプリケーションが 1 つのみある場合は、単一エンティティのセッション単位の認証グループが形成されます。
-
ID 単位のグループには、非認証のみをサポートしているアプリケーションを配置しないでください。
-
セッション単位のグループは不安定です。ID 単位の方がより堅牢な認証方法です。1 つのグループに関するすべての情報が、共有データを含めて、1 つのセッションに格納されるため、グループが簡単に失われる可能性があります。これは、セッションがタイムアウトする可能性がある、つまり一定時間を過ぎるとセッションが自動的に破棄されるためです。ユーザがコンピュータから離れたり、対象のセッション単位のグループには属していないアプリケーションを使用したりすると、セッションがタイムアウトになる場合があります。グループ内のアプリケーションのいずれかに ENDSESSION=1 が指定されると、グループは分散されます。
-
ブラウザで、分散されたアプリケーションのページが含まれるタブが開いているときに、それらのタブをクリックすると、特にそれらのアプリケーションが元々 CSPSHARE=1 を使用してグループ化されていた場合に、複数のログインが必要になることがあります。いずれの場合でも、元のセッションのデータは完全に失われます。
-
グループが認証を失うと、ページを更新するとき、またはグループのアプリケーションの開いているページに移動するときに、ユーザの再ログインが必要になります。
-
セッション単位のアプリケーションが含まれるセッションを終了する場合には、そのセッション単位のグループ内のいずれかのアプリケーションのいずれかのページを更新するときに、ユーザは再ログインする必要があります。ID 単位のアプリケーションが含まれるセッションを強制終了する場合には、そのセッションのアプリケーションがグループ内の唯一のメンバであった場合を除き、ログインは必要ありません。
-
セッションをログアウトすると、そのセッションのグループのすべてのメンバが、たとえ異なるセッションに入っていた場合でもログアウトされます。グループのページのいずれかを更新するには、新規ログインが必要です。ただし、ID 単位のグループの場合、1 回のログインでグループ全体にログインされます。セッション単位のグループの場合、分散されたアプリケーションを新しく作成されたセッション・オブジェクトに戻すことが CSP ゲートウェイで可能である限り、1 回のログインでグループ全体にログインされます。
-
ログアウトしてもセッションが破棄されることはないため、セッションのデータはすべて存続します。
-
同一ブラウザの別々のタブで、2 人の異なるユーザが同一アプリケーションにログインすることはできません。
-
認証はブラウザ単体のみで共有されます。この実行時識別子は、%Session オブジェクトに格納されます。
-
グループ化により、認証を同じグループ (ID 単位) もしくは同じセッション (セッション単位) 内にいるユーザと共有できるようになります。指定したグループの外部にあるアプリケーションから認証を共有する場合、ログイン Cookie を使用します。指定したグループの外部にあるアプリケーションに認証を送付する場合、CSPSHARE=1 を使用します (このドキュメントの “CSPSHARE についての考慮事項” を参照してください)。
データの共有
セッション単位のグループでは、セッション・オブジェクトを介してデータを共有できます。
ID 単位のグループでは、グループ自身のデータを管理する必要があります。例えば、データをグローバルに格納する場合、現在のユーザ $Username またはグループの実行時の ID を使用して、そのデータにキーが割り当てられることがあります。CSP サーバによって、各ブラウザに browser-id Cookie が割り当てられます。ID 単位のグループの作成時に、そのグループには、group-id と連結されたブラウザ id であるキーが割り当てられます。これによって一意のキー %CSP.Session.BrowserId が作成され、データの格納時に割り当てるキーとして使用できます。
