CA SiteMinder® Secure Proxy
Server
管理ガイド
12.52 SP1
このドキュメント（組み込みヘルプ システムおよび電子的に配布される資料を含む、以下「本ドキュメント」）は、
お客様への情報提供のみを目的としたもので、日本 CA 株式会社（以下「CA」）により随時、変更または撤回される
ことがあります。 本ドキュメントは、CA が知的財産権を有する機密情報であり、CA の事前の書面による承諾を受け
ずに本書の全部または一部を複写、譲渡、変更、開示、修正、複製することはできません。
本ドキュメントで言及されている CA ソフトウェア製品のライセンスを受けたユーザは、社内でユーザおよび従業員
が使用する場合に限り、当該ソフトウェアに関連する本ドキュメントのコピーを妥当な部数だけ作成できます。ただ
し、CA のすべての著作権表示およびその説明を当該複製に添付することを条件とします。
本ドキュメントを印刷するまたはコピーを作成する上記の権利は、当該ソフトウェアのライセンスが完全に有効と
なっている期間内に限定されます。 いかなる理由であれ、上記のライセンスが終了した場合には、お客様は本ドキュ
メントの全部または一部と、それらを複製したコピーのすべてを破棄したことを、CA に文書で証明する責任を負いま
す。
準拠法により認められる限り、CA は本ドキュメントを現状有姿のまま提供し、商品性、特定の使用目的に対する適合
性、他者の権利に対して侵害のないことについて、黙示の保証も含めいかなる保証もしません。 また、本ドキュメン
トの使用に起因して、逸失利益、投資損失、業務の中断、営業権の喪失、情報の喪失等、いかなる損害（直接損害か
間接損害かを問いません）が発生しても、CA はお客様または第三者に対し責任を負いません。CA がかかる損害の発
生の可能性について事前に明示に通告されていた場合も同様とします。
本ドキュメントで参照されているすべてのソフトウェア製品の使用には、該当するライセンス契約が適用され、当該
ライセンス契約はこの通知の条件によっていかなる変更も行われません。
本書の制作者は CA および CA Inc. です。
「制限された権利」のもとでの提供：アメリカ合衆国政府が使用、複製、開示する場合は、FAR Sections 12.212、52.227-14
及び 52.227-19(c)(1)及び(2)、ならびに DFARS Section252.227-7014(b)(3) または、これらの後継の条項に規定される該当
する制限に従うものとします。
Copyright © 2014 CA. All rights reserved. 本書に記載されたすべての商標、商号、サービス・マークおよびロゴは、それ
ぞれの各社に帰属します。
CA Technologies 製品リファレンス
このマニュアルが参照している CA Technologies の製品は以下のとおりで
す。
■
CA SiteMinder for Secure Proxy Server
■
CA SiteMinder®
CA への連絡先
テクニカル サポートの詳細については、弊社テクニカル サポートの Web
サイト（http://www.ca.com/jp/support/）をご覧ください。
マニュアルの変更点
CA SiteMinder® の旧リリースで発見された問題の結果として、12.52 のド
キュメントに以下の更新が行われました。
■
JCE（Java Cryptographic Extension）に必要なパッチ -- このトピックでは、
Java が提供する暗号化アルゴリズムを使用するために更新が必要とな
るファイルの詳細について説明します。 CQ 174929 を解決します。
■
統合 Windows 認証 (P. 273) -- この章では、統合 Windows 認証がサポー
トされているオペレーティング システム、および Windows 認証方式を
有効にするのに必要な ACO パラメータの詳細について説明します。
CQ 172603 および 172605 を解決します。
■
認証および許可 (P. 215) -- この章では、AgentName 形式と、認証およ
び許可リクエスト形式の詳細について説明します。CQ 177424、173173、
172762、172758、172760、および 172764 を解決します。
このガイドの第 2 版では、以下の点が変更されています。
ドキュメントのみの変更
プロキシ サービス設定 (P. 121) -- -Dhttp_connection_timeout が設定されて
いる場合の http_connection_timeout の動作方法について説明するために
トピックが更新されました。 ドキュメントは 12.52 SP1 で更新されていま
す。 この変更によって、CQ 184414、21695829、および STAR 21695829 が
解決されます。
認証 REST インターフェース (P. 225) -- URI 形式を修正するためにトピック
が更新されました。 ドキュメントは 12.52 SP1 で更新されています。 この
変更によって、CQ 184721 および STAR 21755360-1 が解決されます。
前提条件 (P. 33) --ncurses パッケージの要件について記載し、別のコン
ピュータに CA SiteMinder for Secure Proxy Server をインストールする必要
があることを追加するためにトピックが更新されました。 ドキュメント
は 12.52 SP1 で更新されています。 この変更によって、CQ 184218 および
184222 が解決されます。
フィルタの実装 (P. 328) -- lib ディレクトリのパスを修正するためにトピッ
クが更新されました。 ドキュメントは 12.52 SP1 で更新されています。 こ
の変更によって、CQ 183762 および STAR 21730064-1 が解決されます。
Web エージェント置換としての SPS (P. 82) -- Web エージェント オプショ
ン パックの要件を明確にするためにトピックが更新されました。
Web エージェント置換として CA SiteMinder for Secure Proxy Server を使用
するための前提条件 (P. 83) -- Web エージェント オプション パックのイン
ストール要件に関する注意事項が削除されました。 ドキュメントは 12.52
SP1 で更新されています。 この変更によって、CQ 181448 および STAR
21657979-1 が解決されます。
自己署名証明書の生成 (P. 267) -- 自己署名証明書を生成するコマンドを修
正するためにトピックが更新されました。 ドキュメントは 12.52 SP1 で更
新されています。 この変更によって、CQ 172433 が解決されます。
認証機関からの証明書のダウンロードおよびインストール (P. 268) -- ルー
ト CA または自己署名証明書を ca-bundle.cert に追加する方法に関する手
順を追加するためにトピックが更新されました。 ドキュメントは 12.52
SP1 で更新されています。この変更によって、CQ 172433 が解決されます。
デバッグ属性 (P. 178) -- xmlns:nete の値の例が修正されました。 ドキュメ
ントは 12.52 SP1 で更新されています。 この変更によって、CQ 184884 お
よび STAR 21754567-02 が解決されます。
CA SiteMinder for Secure Proxy Server サーバ設定を設定する (P. 97) -enablecachepostdata、worker.ajp13.max_threads、
http_connection_pool_max_size、http_connection_timeout、
http_connection_stalecheck、http_connection_pool_min_size、および
http_connection_pool_incremental_factor のデフォルト値を修正するために
章が更新されました。 ドキュメントは 12.52 SP1 で更新されています。 こ
の変更によって、CQ 182068 および STAR 21652689-1 が解決されます。
詳細情報：
CA SiteMinder® SPS のアップグレード (P. 38)
アップグレード用の追加タスク (P. 38)
SSL 例外の無視 (P. 112)
目次
第 1 章： SiteMinder Secure Proxy Server の概要
15
CA SiteMinder for Secure Proxy Server アーキテクチャの概要 ............................................................................. 15
プロキシ サーバ アーキテクチャ ................................................................................................................... 15
従来型のリバース プロキシ サーバ アーキテクチャ .................................................................................. 16
SPS のアーキテクチャ ...................................................................................................................................... 16
コンポーネント ................................................................................................................................................. 18
製品の機能 ................................................................................................................................................................ 21
製品の制限 ................................................................................................................................................................ 22
企業内の CA SiteMinder® SPS ................................................................................................................................... 23
一元化されたアクセス制御フィルタとしての CA SiteMinder® SPS ............................................................ 24
Cookie がないセッションに対する CA SiteMinder® SPS のサポート ........................................................... 26
エクストラネット アクセス制御に対する CA SiteMinder® SPS のサポート ...................................................... 29
第 2 章： SPS をインストール、アップグレード、設定します
31
手動による SPS のインストール、アップグレード、設定 ................................................................................. 31
前提条件............................................................................................................................................................. 33
インストール ワークシート ............................................................................................................................ 34
CA SiteMinder® SPS のインストール ................................................................................................................ 36
CA SiteMinder® SPS の複数インスタンスのインストール ............................................................................ 37
CA SiteMinder® SPS のアップグレード ............................................................................................................ 38
CA SiteMinder® SPS の設定 ................................................................................................................................ 40
管理ユーザ インターフェースの保護 ............................................................................................................ 44
管理ユーザ インターフェースの起動 ............................................................................................................ 45
サイレント モードでの SPS のインストールと設定 ............................................................................................ 46
CA SiteMinder for Secure Proxy Server のアンインストール ................................................................................. 47
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定 ................................................................... 47
ユーザの言語の IANA コードを決定します。 ............................................................................................... 49
環境変数............................................................................................................................................................. 50
第 3 章： FIPS-140 のサポート
55
FIPS サポートの概要 ................................................................................................................................................ 55
FIPS ONLY モードの設定プロセス ........................................................................................................................... 56
FIPS MIGRATE モードへの移行 ................................................................................................................................ 57
目次 7
FIPS ONLY モードへの移行....................................................................................................................................... 58
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用
61
フェデレーション セキュリティ サービスの概要 .............................................................................................. 61
SiteMinder フェデレーション環境の SPS ユース ケース ..................................................................................... 62
ユース ケース 1： アカウント リンクに基づくシングル サインオン ....................................................... 62
ユース ケース 2： ユーザ属性プロファイルに基づくシングル サインオン ............................................ 63
ユース ケース 3： ローカル ユーザ アカウントなしのシングル サインオン .......................................... 64
ユース ケース 4： 拡張ネットワーク ............................................................................................................ 65
SiteMinder フェデレーション環境の SPS ロール .................................................................................................. 67
SPS ユース ケースのソリューション..................................................................................................................... 67
ソリューション 1： アカウント リンクに基づく SSO ................................................................................. 67
ソリューション 2： ユーザ属性プロファイルを使用した SSO .................................................................. 71
ソリューション 3： ローカル ユーザ アカウントなしの SSO .................................................................... 73
ソリューション 4： 拡張ネットワークの SSO .............................................................................................. 75
Cookie なしのフェデレーション ............................................................................................................................ 78
使用側での Cookie なしのフェデレーションの有効化 ................................................................................ 81
Web エージェント置換としての SPS の使用 ........................................................................................................ 82
Web エージェント置換として SPS を使用するための前提条件 ................................................................. 83
フェデレーション用 Web エージェントの置換として SPS を設定 ............................................................ 83
フェデレーション ゲートウェイとしての SPS の使用 ........................................................................................ 84
フェデレーション ゲートウェイを使用するための前提条件 .................................................................... 86
SPS フェデレーション ゲートウェイの設定 ................................................................................................. 86
SPS フェデレーション ゲートウェイの制限 ................................................................................................. 87
第 5 章： SPS 上のセキュリティ ゾーン
89
シングル サインオンのセキュリティ ゾーンの概要 .......................................................................................... 89
セキュリティ ゾーンの利点 ................................................................................................................................... 90
セキュリティ ゾーンの基本ユースケース ........................................................................................................... 91
セキュリティ ゾーン用パラメータ ....................................................................................................................... 92
CA SiteMinder for Secure Proxy Server セキュリティ ゾーンの設定 .................................................................... 94
第 6 章： Apache Web サーバを設定する
95
Apache Web サーバ設定ファイル .......................................................................................................................... 95
第 7 章： SPS サーバ設定を設定する
97
SPS server.conf ファイルの概要 .............................................................................................................................. 97
8 管理ガイド
server.conf ファイルの変更 ..................................................................................................................................... 98
server.conf ファイル内の一般的なサーバ設定 ..................................................................................................... 98
HTTP の接続パラメータ ................................................................................................................................... 99
server.conf ファイルの Tomcat 調整パラメータ .......................................................................................... 100
Tomcat の複数のバージョンにおける Cookie 仕様の差を解消します ..................................................... 102
Cookie 内の等号の解析 ................................................................................................................................... 102
server.conf ファイルのフェデレーション設定 ............................................................................................ 103
HttpClient のログ ............................................................................................................................................. 104
server.conf ファイル内の SSL 設定................................................................................................................. 106
Cookie 内の特殊文字の設定 ........................................................................................................................... 111
コード ヘッダの文字セットの選択 .............................................................................................................. 111
POST データのキャッシュ ............................................................................................................................. 112
SSL 例外の無視 ................................................................................................................................................ 112
カスタム エラー ページのプロパティ ................................................................................................................ 113
カスタム エラー メッセージの有効化 ......................................................................................................... 114
デフォルトのカスタム エラー ページ ......................................................................................................... 115
server.conf File でのセッション ストア設定........................................................................................................ 119
server.conf ファイル内のサービス ディスパッチャ設定 .................................................................................. 120
server.conf ファイル内のプロキシおよびリダイレクトの設定 ....................................................................... 121
プロキシ サービス設定 .................................................................................................................................. 121
接続プールに関する推奨事項 ....................................................................................................................... 126
リダイレクト サービス設定 .......................................................................................................................... 128
接続指向の接続プール設定 ........................................................................................................................... 129
server.conf ファイル内のセッション スキームの設定 ...................................................................................... 130
ユーザ セッションの確立 .............................................................................................................................. 132
デフォルト セッション スキーム ................................................................................................................. 133
SSL ID セッション スキーム ........................................................................................................................... 136
IP アドレス セッション スキーム ................................................................................................................. 138
ミニ Cookie セッション スキーム ................................................................................................................. 138
シンプル URL リライティング セッション スキーム ................................................................................. 139
ワイヤレス デバイス ID セッション スキーム ............................................................................................ 144
各セッション スキームに使用 ...................................................................................................................... 145
仮想ホスト用の複数のセッション スキーム .............................................................................................. 146
Cookie なしのフェデレーションの属性 Cookie の削除 .............................................................................. 147
Server.conf のユーザ エージェント設定 .............................................................................................................. 148
Nokia ユーザ エージェントの設定 ................................................................................................................ 149
server.conf ファイルの仮想ホスト設定 ............................................................................................................... 150
仮想ホスト Cookie パスおよびドメインを正しい URI に設定 ................................................................... 151
HOST ヘッダ ファイルの保持 ........................................................................................................................ 153
データ ブロックを使用した大きなファイルの処理 .................................................................................. 153
目次 9
デフォルト仮想ホスト用のセッション スキーム マッピング ................................................................. 156
デフォルト仮想ホスト用の Web エージェント設定 .................................................................................. 157
送信先サーバによるリダイレクトの処理 ................................................................................................... 159
仮想ホスト名の設定 ....................................................................................................................................... 160
仮想ホストのデフォルト値の上書き ........................................................................................................... 161
第 8 章： SPS ログ設定の設定
163
SPS logger.properties ファイルの概要 .................................................................................................................. 163
logger.properties ファイルの変更 ......................................................................................................................... 163
ログ記録設定 .......................................................................................................................................................... 164
SvrConsoleAppender 設定 ................................................................................................................................ 164
SvrFileAppender 設定 ....................................................................................................................................... 165
ログ設定........................................................................................................................................................... 166
ログ ローテーションの設定 .......................................................................................................................... 167
ログ記録用に WebAgent.conf の ServerPath を変更 ........................................................................................... 169
第 9 章： プロキシ ルールの設定
171
プロキシ ルールの概要 ......................................................................................................................................... 171
受信リクエストのルートの計画 ................................................................................................................... 172
プロキシ ルールの用語 .................................................................................................................................. 174
プロキシ ルール設定ファイルの確立 ................................................................................................................. 176
プロキシ ルール DTD ............................................................................................................................................. 177
nete:proxyrules ................................................................................................................................................. 177
nete:case ........................................................................................................................................................... 179
nete:cond .......................................................................................................................................................... 182
nete:default....................................................................................................................................................... 185
nete:forward ..................................................................................................................................................... 186
nete:redirect ..................................................................................................................................................... 187
nete:local........................................................................................................................................................... 188
nete:xprcond ..................................................................................................................................................... 188
nete:xprcond エレメントの動作のしくみ............................................................................................................ 191
正規表現の構文 ...................................................................................................................................................... 192
nete:rule および nete:result の正規表現の例................................................................................................ 195
転送フィルタ、リダイレクト フィルタ、結果フィルタでのヘッダ値 .......................................................... 197
nete:forward 内の動的なヘッダ値 ................................................................................................................ 197
nete:redirect 内の動的なヘッダ値 ................................................................................................................. 197
nete:result の動的ヘッダ値 ............................................................................................................................ 198
レスポンス処理 ...................................................................................................................................................... 198
プロキシ ルールの変更 ......................................................................................................................................... 199
10 管理ガイド
サンプル プロキシ ルール設定ファイル ............................................................................................................ 199
プロキシ ルールの例 -- 仮想ホストによるリクエストのルーティング .................................................. 200
プロキシ ルールの例 -- ヘッダ値によるリクエストのルーティング ...................................................... 201
プロキシ ルールの例—デバイス タイプでのリクエストのルーティング .............................................. 202
プロキシ ルールの例— URI でのリクエストのルーティング ................................................................... 202
プロキシ ルールの例—ファイル拡張子でのリクエストのルーティング ............................................... 203
プロキシ ルールの例 -- 入れ子の条件を持ったリクエストのルーティング .......................................... 204
プロキシ ルールの例 - プロキシ ルールで正規表現を使用する .............................................................. 205
プロキシ ルールの例 -- Cookie の存在によるリクエストのルーティング .............................................. 206
プロキシ ルールの例 -- Cookie 値によるリクエストのルーティング ...................................................... 206
第 10 章： SPS の展開
207
企業内の CA SiteMinder for Secure Proxy Server ................................................................................................... 207
スティッキー ビット ロード バランシング ................................................................................................ 209
信頼サイトと非信頼サイトに対するプロキシ ........................................................................................... 210
仮想ホストの設定 ........................................................................................................................................... 210
複数の仮想ホスト用のセッション スキーム マッピングを実装する...................................................... 212
第 11 章： Web サービスの設定
215
認証および許可 ...................................................................................................................................................... 215
認証および許可 Web サービスの使用方法.................................................................................................. 215
認証および許可 Web サービスの概要 ......................................................................................................... 216
Web サービスの設定 ...................................................................................................................................... 217
クライアント プログラムの作成 .................................................................................................................. 221
セキュリティ トークン サービス ........................................................................................................................ 229
複数 CA SiteMinder for Secure Proxy Server インスタンスの展開 ............................................................... 230
第 12 章： SiteMinder に SPS を統合する
233
SPS と SiteMinder の対話方法................................................................................................................................ 233
認証方式に関する注意事項 ........................................................................................................................... 235
プロキシ固有の WebAgent.conf の設定 ........................................................................................................ 236
送信先サーバ Web エージェントとのポリシー競合の回避 ...................................................................... 237
ユーザをリダイレクトする SiteMinder ルールの設定 ............................................................................... 239
SPS および SharePoint のリソース ........................................................................................................................ 241
SPS と ERP のリソース ........................................................................................................................................... 241
SPS のパスワード サービス .................................................................................................................................. 243
SPS のパスワード ポリシーの設定 ............................................................................................................... 243
SPS 用のパスワード サービスの確認 ........................................................................................................... 244
目次 11
ファイアウォールに関する注意事項 .................................................................................................................. 245
キープ アライブおよび接続プーリング ............................................................................................................. 245
Sun Java Web サーバの HTTP ヘッダ設定............................................................................................................. 246
SPS による SiteMinder 処理用の HTTP ヘッダ ..................................................................................................... 246
エンコードされた URL を処理する ...................................................................................................................... 247
第 13 章： SessionLinker をサポートするための CA SiteMinder® SPS の設定
249
SessionLinker をサポートするための SPS の設定 ................................................................................................ 250
SessionLinker の仕組み .................................................................................................................................... 251
SessionLinker の有効化 .................................................................................................................................... 253
NPS_Session_Linker ACO の作成 ..................................................................................................................... 254
Cookie の動作................................................................................................................................................... 256
SessionLinker のトラブルシューティング .................................................................................................... 259
第 14 章： SSL および Secure Proxy Server
261
SPS 用の SSL の設定 ................................................................................................................................................ 261
注意事項の確認 ............................................................................................................................................... 263
秘密キーの生成 ............................................................................................................................................... 264
証明書署名リクエストの生成およびサブミット ....................................................................................... 266
認証機関からの証明書のダウンロードおよびインストール ................................................................... 268
SSL の有効化 .................................................................................................................................................... 268
仮想ホストに対する SSL の有効化 ....................................................................................................................... 270
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の
設定
273
統合 Windows 認証をサポートするための SPS の設定 ...................................................................................... 273
Windows 認証方式........................................................................................................................................... 276
Kerberos 認証方式 ........................................................................................................................................... 281
第 16 章： CA Wily Introscope を使ったデータ モニタリング
301
CA Wily Introscope を使ったデータ モニタリング.............................................................................................. 301
データ モニタリングの有効化 ...................................................................................................................... 303
OneView モニタによる Web エージェントの監視 ............................................................................................. 304
第 17 章： エージェントに対するオペレーティング システムの調整
305
共有メモリ セグメントの調整 ............................................................................................................................. 306
12 管理ガイド
Solaris 10 リソース管理を調整する方法.............................................................................................................. 308
第 18 章： SPS API
309
セッション スキーム API ....................................................................................................................................... 309
セッション スキーム API 処理の概要 ........................................................................................................... 309
カスタム セッション スキームの実装 ......................................................................................................... 313
書き換え可能なセッション スキームの設定 .............................................................................................. 314
IP アドレス セッション スキームの使用 ..................................................................................................... 315
セッション ストレージ API............................................................................................................................ 317
API の概要のフィルタ............................................................................................................................................ 317
SPS がカスタム フィルタを処理する方法 ................................................................................................... 318
プロキシ ルールとカスタム フィルタの関連付け ..................................................................................... 319
API クラス ファイルのフィルタ .................................................................................................................... 319
ProxyFilter インターフェース ........................................................................................................................ 320
BaseProxyFilter の抽象的な実装 ..................................................................................................................... 321
ProxyFilterConfig インターフェース .............................................................................................................. 323
ProxyResponse インターフェース ................................................................................................................. 324
ProxyFilterException クラス ............................................................................................................................ 325
ProxyRequest インターフェース.................................................................................................................... 326
フィルタの実装 ............................................................................................................................................... 328
API の例のフィルタ ........................................................................................................................................ 329
リクエストされたページの絶対的なリンクを書き換えるためのフィルタの使用................................ 330
第 19 章： トラブルシューティング
331
SSL 設定の後にブラウザにポップアップ ウィンドウが表示される ............................................................... 332
UNIX システム上で Apache を起動できません ................................................................................................... 333
英語以外の入力文字にジャンク文字が含まれる .............................................................................................. 333
フェデレーション Web サービス エラーをログ記録できない ........................................................................ 334
DNS がリクエストのたびにキャッシュされる .................................................................................................. 335
リソース リクエストの失敗 ................................................................................................................................. 336
spsagent ログの設定 ....................................................................................................................................... 337
SPSAgentTrace ログの設定.............................................................................................................................. 338
mod_jk.log ファイルの設定 ............................................................................................................................ 339
httpclient.log ファイルの設定 ........................................................................................................................ 340
インストール プログラムが警告を表示する ..................................................................................................... 340
SPS サーバを起動できません ............................................................................................................................... 341
ブラウザで SPS にアクセスできません............................................................................................................... 342
仮想ホストの設定における問題 .......................................................................................................................... 342
目次 13
仮想ホストの設定が失敗する .............................................................................................................................. 343
リクエストを転送しない SPS ............................................................................................................................... 343
SharePoint ページへのアクセス エラー .............................................................................................................. 344
14 管理ガイド
第 1 章： SiteMinder Secure Proxy Server の概
要
このセクションには、以下のトピックが含まれています。
CA SiteMinder for Secure Proxy Server アーキテクチャの概要 (P. 15)
製品の機能 (P. 21)
製品の制限 (P. 22)
企業内の CA SiteMinder® SPS (P. 23)
エクストラネット アクセス制御に対する CA SiteMinder® SPS のサポート
(P. 29)
CA SiteMinder for Secure Proxy Server アーキテクチャの概要
CA SiteMinder® for Secure Proxy Server （CA SiteMinder for Secure Proxy
Server）は、アクセス制御用にプロキシ ベースのソリューションを提供す
るスタンドアロン サーバです。 CA SiteMinder for Secure Proxy Server は、
企業用のネットワーク ゲートウェイを提供し、従来の Cookie ベースの技
術に依存しない複数のセッション スキームをサポートするプロキシ エン
ジンを使用します。
プロキシ サーバ アーキテクチャ
従来のプロキシ サーバは、ファイアウォールと内部ネットワークの間に
配置され、内部ネットワークでリソースのキャッシュ機能とユーザ セ
キュリティを提供します。 従来のプロキシ サーバは、インターネット上
のすべてのリソースに対して、ユーザ グループの代わりに、プロキシと
して働きます。
第 1 章： SiteMinder Secure Proxy Server の概要 15
CA SiteMinder for Secure Proxy Server アーキテクチャの概要
次の図は、プロキシ サーバの設定を示しています。 プロキシ サーバは、
頻繁にアクセスされるリソースに対するリクエストが DMZ（DeMilitarized
Zone）で高速処理されるように、リソースをキャッシュに格納します。
従来型のリバース プロキシ サーバ アーキテクチャ
リバース プロキシ サーバは、1 つ以上の送信先サーバを表します。リバー
ス プロキシ アーキテクチャの一般的な使用では、以下のものが提供され
ます。
■
キャッシュされたリソース
■
セキュリティ
■
SSL の高速化
■
負荷分散
リバース プロキシ サーバは、送信先サーバのリソースを直接リクエスト
するのではなく、ユーザが直ちにアクセスできるように、送信先サーバか
ら多くのコンテンツをキャッシュします。 このタイプのプロキシ サーバ
展開はリバース プロキシと見なされます。プロキシがユーザに対して透
過的で、企業内の送信先サーバの代わりとして動作するためです。 複数
のリバース プロキシ サーバは負荷分散に使用できます。また、HTTPS リ
クエストに対する SSL の高速化に使用できます。 リバース プロキシ サー
バはまた、DMZ の後ろに存在する送信先サーバを隔離することで、追加の
セキュリティ レイヤの提供も行います。
SPS のアーキテクチャ
CA SiteMinder for Secure Proxy Server はリソース キャッシュ機能を提供し
ないため、CA SiteMinder for Secure Proxy Server は従来のリバース プロキシ
ソリューションではありません。 CA SiteMinder for Secure Proxy Server は、
ネットワークへのアクセス方法にかかわらず、企業リソースにアクセスす
るための単一のゲートウェイとして機能します。
16 管理ガイド
CA SiteMinder for Secure Proxy Server アーキテクチャの概要
1 セットの設定可能なプロキシ ルールは、CA SiteMinder for Secure Proxy
Server がユーザ リクエストを処理する方法を決定します。 ユーザ エー
ジェント タイプと仮想ホスト間のマッピングに基づいて、複数のセッ
ション スキームを介してリソースにアクセスできます。 ネットワークに
アクセスするために使われているデバイスのタイプに基づいて、リクエス
トを異なる送信先サーバにルーティングできます。
次の図では、CA SiteMinder for Secure Proxy Server の設定を示しています。
CA SiteMinder for Secure Proxy Server にはさまざまなデバイスを使ってア
クセスします。 CA SiteMinder for Secure Proxy Server はアクセス デバイス
に基づいて、作成するセッション スキームを決定し、適切な送信先サー
バへリクエストを転送またはリダイレクトします。 企業内にリバース プ
ロキシ サーバが存在することは、ユーザに認識されません。
第 1 章： SiteMinder Secure Proxy Server の概要 17
CA SiteMinder for Secure Proxy Server アーキテクチャの概要
コンポーネント
以下の図に示すように、スタンドアロン CA SiteMinder for Secure Proxy
Server は、HTTP リスナ（Apache）および Tomcat サーブレット コンテナか
ら構成されます。
18 管理ガイド
CA SiteMinder for Secure Proxy Server アーキテクチャの概要
CA SiteMinder for Secure Proxy Server アーキテクチャには以下のコンポー
ネントが含まれます。
Apache
CA SiteMinder for Secure Proxy Server は、受信リクエスト用の HTTP リス
ナとして動作する、オープン ソースの Apache Web サーバを使用しま
す。 追加コンポーネントである mod_jk（1.2.18）は、Tomcat コネクタ
として動作します。これにより、Apache Web サーバと Apache JServ プ
ロトコル（AJP）を使用している Tomcat 間の通信が可能になります。
Tomcat
Tomcat サーバは、CA SiteMinder for Secure Proxy Server の Tomcat サーブ
レット コンテナを提供します。 Tomcat の初期化はカスタマイズされ
ているため、外部アプリケーションやサーブレットの展開を許可され
ません。標準的な Tomcat XML（server.xml）は初期化に使われません。
CA SiteMinder for Secure Proxy Server の Tomcat コンテナの内部のコン
ポーネントには、以下が含まれています。
設定リゾルバ ProxyBootstrap
設定リゾルバ proxybootstrap は、server.conf ファイルから CA
SiteMinder for Secure Proxy Server 設定を読み取り、CA SiteMinder for
Secure Proxy Server を初期化します。
セッション ディスカバリ
セッション ディスカバリ コンポーネントは、CA SiteMinder for
Secure Proxy Server セッション情報を抽出するため、受信リクエス
トを分析します。ユーザ エージェント タイプと使われている仮想
ホストに応じて、このコンポーネントは、CA SiteMinder for Secure
Proxy Server セッション情報を抽出するため、適切なセッション ス
キームを使用します。
リクエストで既存の CA SiteMinder for Secure Proxy Server セッショ
ンが使われている場合、このコンポーネントはリクエストに含ま
れている CA SiteMinder for Secure Proxy Server セッション識別子を
使用して、インメモリ セッション ストアから対応する SiteMinder
セッションを抽出します。 CA SiteMinder for Secure Proxy Server は
SiteMinder セッションを、セッション検証のために、Java Web エー
ジェントへ渡します。リクエストに既存の CA SiteMinder for Secure
Proxy Server セッションが含まれていない場合、このコンポーネン
トはユーザ認証のために、Java Web エージェントにリクエストを
渡します。
第 1 章： SiteMinder Secure Proxy Server の概要 19
CA SiteMinder for Secure Proxy Server アーキテクチャの概要
Java Web エージェント
Java Web エージェントは、SiteMinder ポリシー サーバと一緒に、
ユーザの認証と認可を行います。
ポスト エージェント セッション ライタ
ポスト エージェント セッション ライタは、Cookie が存在しない
セッション スキームに、追加処理を実行します。 Java Web エー
ジェントがユーザの認証と認可を行い、SiteMinder セッションが作
成された後、このコンポーネントは CA SiteMinder for Secure Proxy
Server セッション識別子を作成します。 この識別子は、Java Web
エージェントが作成する SiteMinder セッションに付けられます。
次にこのセッション識別子は、CA SiteMinder for Secure Proxy Server
のインメモリ セッション ストアで保持されます。セッション スト
アでのセッションの保持に加え、このコンポーネントは URI の変換
を行います。たとえば、ポスト エージェント セッション ライタは、
simple_url セッション スキーム用に URI を操作します。
プロキシ ルール サーブレット フィルタ
プロキシ ルール サーブレット フィルタは、proxyrules.xml ファイル
からプロキシ ルールをロードします。 受信リクエストおよびプロ
キシ ルールに応じて、リクエストはバックエンド サーバに転送ま
たはリダイレクトされます。 リクエストが転送される場合、オー
プン ソース コンポーネントのヌードルが使用されます。
プロキシ ルールを変更しても、変更を有効にするための再起動は
不要です。 proxyrules.xml ファイルを変更すると、proxyrules が再
ロードされます。
ヌードル サーブレット
ヌードル サーブレットは、リクエストをバックエンド サーバに転
送します。 ヌードルは、プロキシ前フィルタの使用もサポートし
ます。このフィルタを使用すると、同じリクエストをバックエン
ド サーバに送信する前に、リクエストを修正することができます。
同様に、プロキシ後フィルタもサポートされます。このフィルタ
を使用すると、レスポンスをユーザ クライアントに送り返す前に、
バックエンド サーバから受信したレスポンスを修正できます。
HTTP クライアント
HTTP クライアントは、バックエンド サーバにリクエストを送信し、
バックエンド サーバからレスポンスを受信します。
20 管理ガイド
製品の機能
製品の機能
CA SiteMinder for Secure Proxy Server は、以下の機能を提供します。
HTTP および HTTPS リクエストのアクセス制御
CA SiteMinder for Secure Proxy Server を使用すると、埋め込み SiteMinder
Web エージェントを使用して、送信先サーバで送受信される HTTP お
よび HTTPS のリクエストのフローを制御することを可能にします。 さ
らに CA SiteMinder for Secure Proxy Server は、e ビジネス トランザク
ションを管理する SiteMinder と完全統合します。
シングル サインオン
CA SiteMinder for Secure Proxy Server の埋め込み Web エージェントを
使用すると、企業内の送信先サーバにインストール可能な SiteMinder
Web エージェントでのシングル サインオン（SSO）など、企業全体で
SSO が利用できるようになります。
複数のセッション スキーム
セッション スキームとは、認証後にユーザ ID を保持する方法です。
SiteMinder のコア製品は、セッションの保持に Cookie を使用します。
ただし、CA SiteMinder for Secure Proxy Server は、SSL ID、ミニ Cookie、
ハンドヘルド デバイス用のデバイス ID、URL リライティング、IP アド
レス、およびセッション スキーム API を使って作成したセッションに
基づいて、セッションを保持することができます。
セッション ストレージ
CA SiteMinder for Secure Proxy Server は、インメモリ セッション ストア
を装備しています。セッション ストアではセッション情報が保持され
ます。 CA SiteMinder for Secure Proxy Server は、セッション ストアの
セッション情報を参照するため、ミニ Cookie や SSL ID などのトークン
を使用します。 複数のセッション スキームとインメモリ セッション
ストレージを使用することで、CA SiteMinder for Secure Proxy Server は
コンピュータやワイヤレス デバイス（PDA や無線電話など）の枠組み
を超えた、E ビジネス管理用ソリューションが提供されます。
Cookie を使用しないシングル サインオン
いくつかの企業は、Cookie テクノロジを使用しないソリューションを
好みます。 セッション スキームとセッション ストアは CA SiteMinder
for Secure Proxy Server に組み込まれているため、Cookie ベースのセッ
ション管理の代替ソリューションを求める企業にソリューションを提
供します。
第 1 章： SiteMinder Secure Proxy Server の概要 21
製品の制限
インテリジェントなプロキシ ルール
プロキシ ルールを使用すると、要求された仮想ホストや URI 文字列な
どの特性に基づいて、CA SiteMinder for Secure Proxy Server からのクラ
イアント リクエストを満たす複数のパスを設定できます。 プロキシ
エンジンは、ユーザ リクエストを処理する方法を決定する 1 セットの
プロキシ ルールを解釈します。
一元化されたアクセス制御管理
ネットワーク リソース用の単一ゲートウェイを提供することで、CA
SiteMinder for Secure Proxy Server は企業ネットワークを分離し、アクセ
ス制御を一元化します。
エンタープライズ クラス アーキテクチャ
CA SiteMinder for Secure Proxy Server は、スケーラブルで、扱いやすく、
拡張可能となるように設計されています。
製品の制限
以下の条件が CA SiteMinder for Secure Proxy Server に適用されます。
22 管理ガイド
■
CA SiteMinder for Secure Proxy Server は、別の Web サーバへのプラグイ
ンではありません。CA SiteMinder for Secure Proxy Server は、完全サポー
トされた、スタンドアロン サーバです。
■
CA SiteMinder for Secure Proxy Server は、ローカル コンテンツをサポー
トしません。 CA SiteMinder for Secure Proxy Server 上にコンテンツを配
置する機能は公開されません。また、CA SiteMinder for Secure Proxy
Server はローカル コンテンツへのアクセスを提供するプロキシ ルー
ルをサポートしません。
■
CA SiteMinder for Secure Proxy Server は、CA SiteMinder for Secure Proxy
Server と同じシステムで Web サーバを持つことをサポートしません。
2 つのサーバが同じシステムでセットアップされる場合、Web サーバ
はインターネットからアクセス可能です。 この設定では、セキュリ
ティが確保されないおそれがあります。
■
CA SiteMinder for Secure Proxy Server は独自のセッション ストレージを
提供します。 ただし、セッション ストアには、汎用セッション サー
バとして使用するためのパブリック API はありません。
企業内の CA SiteMinder® SPS
■
CA SiteMinder for Secure Proxy Server を使用する一部の企業では、
SiteMinder Web エージェントやアプリケーション サーバ エージェン
トが送信先サーバにもインストールされていることがあります。 CA
SiteMinder for Secure Proxy Server エージェント用ポリシーが送信先
サーバにインストールされたエージェント用ポリシーと一致しない場
合、CA SiteMinder for Secure Proxy Server は呼び出すクライアントにレ
スポンス応答をパスできます。 CA SiteMinder for Secure Proxy Server が
そのようなポリシーを処理する際に矛盾に関する警告を提供しないの
で、そのような環境で SiteMinder ポリシーをセットアップする場合、
注意を使用します。
■
CA SiteMinder for Secure Proxy Server は、リクエストを受信するたびに、
送信先サーバに新しくリクエストを発行します。 すべてのキャッシン
グ ディレクティブは無視されます。
■
simple-url セッション スキームでは、CA SiteMinder for Secure Proxy
Server は、JavaScript に埋め込まれた URL、または JavaScript から生成さ
れた URL をリライトしません。
■
保護されているリソースにポスティングする場合、simple_url セッショ
ン スキームは POST データを保持しません。
企業内の CA SiteMinder® SPS
従業員、カスタマおよびパートナーに対して、ネットワーク リソースへ
のアクセスを提供する企業は、以下のような、さまざまな課題に直面しま
す。
■
適切なサービスへのリクエストの転送
■
ユーザ ID の確認と資格の確立
■
認定ユーザのセッションの保持
■
一元化されたアクセス制御設定の提供
■
複数のデバイス タイプのサポート
■
柔軟で安全なアーキテクチャの使用
第 1 章： SiteMinder Secure Proxy Server の概要 23
企業内の CA SiteMinder® SPS
SiteMinder は、ユーザの認証と認可、ユーザ資格を評価するための複雑な
エンジンなど、これら多くの課題に対するソリューションを提供します。
CA SiteMinder for Secure Proxy Server は、リバース プロキシ ソリューショ
ンを提供することで、コアとなるポリシー サーバと Web エージェントの
機能が持つメリットをさらに拡張します。
このリバース プロキシ ソリューションは、以下の機能を追加します。
■
既存の SiteMinder Web エージェントとの相互運用性
■
Cookie を使用しないシングル サインオンとセッション ストレージ
■
プロキシ ルールによる一元化された設定
■
セッションを保持するための複数のオプション
■
複数デバイスのサポート
CA SiteMinder for Secure Proxy Server を企業内に展開して、以下の機能を提
供することができます。
■
一元化されたアクセス制御フィルタとして機能する
■
Cookie がないセッション スキームをサポートする
■
エクストラネットのアクセス制御をサポートする
一元化されたアクセス制御フィルタとしての CA SiteMinder® SPS
送信先サーバへのアクセスを制限し、ネットワークへのセントラル エン
トリ ポイントを提供するため、CA SiteMinder for Secure Proxy Server を、企
業内のすべての送信先サーバの前に配置できます。 企業が受信する HTTP
または HTTPS リクエストは、CA SiteMinder for Secure Proxy Server を介して
フィルタリングし、条件を満たす適切な送信先サーバに転送できます。
24 管理ガイド
企業内の CA SiteMinder® SPS
以下の図は、CA SiteMinder for Secure Proxy Server がどのように HTTP およ
び HTTPS リクエストをすべて処理するか示します。
コンテンツが含まれる送信先サーバは、SiteMinder Web エージェントを必
要としません。最初のファイアウォールの後ろに存在するただ 1 つのネッ
トワーク エレメントは CA SiteMinder for Secure Proxy Server です。2 番目の
ファイアウォールの後ろに配置されている SiteMinder によって、すべての
ユーザの認証と認可が実行される必要があります。 SiteMinder および CA
SiteMinder for Secure Proxy Server がユーザ権限を確認した後、送信先サー
バはコンテンツを提供します。
この展開には、以下の利点があります。
■
プロキシ ルールによって設定が一元化されます。
CA SiteMinder for Secure Proxy Server は、CA SiteMinder for Secure Proxy
Server がリクエストを処理する方法を確立するため、XML 設定ファイ
ルで定義されたプロキシ ルールを使用します。 プロキシ ルールの基
準として以下を使用できます。
■
ホスト名
■
URI サブストリング
■
HTTP ヘッダ
第 1 章： SiteMinder Secure Proxy Server の概要 25
企業内の CA SiteMinder® SPS
■
SiteMinder ヘッダ
■
URI をベースとした正規表現
さらに、複数の条件を組み込んだルールを作成するため、プロキシ
ルールの条件をネスティングすることができます。
■
適切なサービスへのリクエストの転送
すべての HTTP および HTTPS のトラフィックは、CA SiteMinder for
Secure Proxy Server を通過します。 CA SiteMinder for Secure Proxy Server
に対して確立されたプロキシ ルールに基づいて、リクエストは条件を
満たす適切な送信先サーバに転送されます。
■
ユーザ ID を確認し、資格を確立します。
CA SiteMinder for Secure Proxy Server は、組み込み型の Web エージェン
トを使って SiteMinder と通信し、リクエストの認証および認可を実行
します。
Cookie がないセッションに対する CA SiteMinder® SPS のサポート
ほとんどのソリューションは Cookie テクノロジを使用します。 ただし、
HTTP または HTTPS を介してリソースにアクセスする場合、いくつかの企
業はユーザ セッションの確立と保持を行うための代替ソリューションを
望み、Cookie を使用しないソリューションを使用するシングル サインオ
ンを提供します。
CA SiteMinder for Secure Proxy Server はインメモリ セッション ストアを提
供し、Cookie を使用しない以下のいずれかのセッション スキームを使用
できます。
26 管理ガイド
■
ミニ Cookie（標準的な SiteMinder Cookie の代わりに、小さな Cookie を
使用します）
■
SSL ID
■
デバイス ID
■
シンプル URL リライティング
■
IP アドレス
企業内の CA SiteMinder® SPS
次の図は、CA SiteMinder for Secure Proxy Server が Cookie を使用する標準的
なセッションと Cookie を使用しないセッションの組み合わせを提供する
展開を示しています。
前の図で示した展開には、以下のメリットがあります。
■
複数のデバイス タイプをサポートします。
1 セットのプロキシ ルールによって、CA SiteMinder for Secure Proxy
Server はリクエストを発行しているデバイス タイプに基づいて、リク
エストを転送またはリダイレクトします。 たとえば、初期リクエスト
をすべて CA SiteMinder for Secure Proxy Server に送信することができま
す。CA SiteMinder for Secure Proxy Server は、デバイス タイプに基づい
てリクエストを送信先サーバに転送します。ブラウザ リクエストを送
信先サーバにリダイレクトすることが可能で、CA SiteMinder for Secure
Proxy Server はワイヤレス リクエストを処理します。
第 1 章： SiteMinder Secure Proxy Server の概要 27
企業内の CA SiteMinder® SPS
■
認定ユーザのセッションを保持します。
標準的な SiteMinder Cookie と Cookie を使用しないセッション スキー
ムの両方を、ユーザ セッションの保持に使用します。 セッション ス
キームは、各仮想ホストのユーザ エージェント タイプに基づいて割り
当てられます。 たとえば、Web ブラウザを介してネットワークにアク
セスしているすべてのユーザは、標準的な Cookie セッション スキーム
に割り当てられます。 無線電話によってリソースにアクセスするユー
ザは、デバイス ID セッション スキームに割り当てられます。
■
Cookie を使用しないシングル サインオンおよびセッション ストレー
ジを提供します。
インメモリ セッション ストアおよび複数のセッション スキームのサ
ポートを介して、CA SiteMinder for Secure Proxy Server は Cookie ベース
のセッションの代わりとなる代替ソリューションを提供します。 CA
SiteMinder for Secure Proxy Server は、セッション ストアでセッション
情報を保持し、トークンを返します。 このトークンはすべてのトラン
ザクションで交換されるため、CA SiteMinder for Secure Proxy Server は
セッション ストアでキャプチャされたセッション情報にトークンを
一致させることができます。
■
セッションを保持するための複数のオプションを提供します。
フェデレーション環境内の Cookie を使用しないセッション スキーム
Cookie を使用しないセッション スキームが内蔵されている CA SiteMinder
for Secure Proxy Server は、ユーザ エージェント（ワイヤレス デバイスなど）
が従来の SiteMinder Cookie をサポートしない環境にも展開することがで
きます。
SiteMinder フェデレーション セキュリティ サービス環境に CA SiteMinder
for Secure Proxy Server を展開した場合、ユーザ リクエストを受信すると、
以下のプロセスが実行されます。
1. CA SiteMinder for Secure Proxy Server は、フェデレーション リソースに
対するリクエストを受信します。 そのリクエストはアサーションを生
成しているサイトで、フェデレーション Web サービス（FWS）アプリ
ケーションに送信されます。
2. CA SiteMinder for Secure Proxy Server は、リダイレクトをリクエストし
ている仮想ホストに対して、Cookie を使用しないフェデレーションが
有効かどうかを確認できます。
28 管理ガイド
エクストラネット アクセス制御に対する CA SiteMinder® SPS のサポート
3. Cookie を使用しないスキームが使用されている場合、CA SiteMinder for
Secure Proxy Server は現在のセッションのセッション キー（SMSESSION
Cookie）を削除します。
4. CA SiteMinder for Secure Proxy Server は FWS リダイレクトが提供するリ
ンクに、ユーザを送信します。
CA SiteMinder for Secure Proxy Server が simple_url セッション スキームな
ど、リライト可能なセッション スキームを使用している場合、CA
SiteMinder for Secure Proxy Server は、リダイレクト先の URL のセッション
キー情報を含むようにリダイレクト レスポンスをリライトします。
エクストラネット アクセス制御に対する CA SiteMinder® SPS のサ
ポート
CA SiteMinder for Secure Proxy Server の別の展開では、外部ユーザに対して
アクセス制御を提供しますが、内部ユーザに対しては送信先サーバへの直
接アクセスを許可します。 送信先サーバが企業内の個人ユーザ用の安全
なアプリケーションへのアクセスを提供する場合、標準の SiteMinder Web
エージェントを送信先サーバにインストールして、アクセス制御を提供す
ることができます。CA SiteMinder for Secure Proxy Server を介して正しく認
証されたユーザは、シングル サインオンを使用できます。
第 1 章： SiteMinder Secure Proxy Server の概要 29
エクストラネット アクセス制御に対する CA SiteMinder® SPS のサポート
次の図は、エクストラネット ネットワークの展開例を示します。
この展開には、以下の利点があります。
■
エクストラネット ソースからリクエストを指示します。
すべてのエクストラネット トラフィックは CA SiteMinder for Secure
Proxy Server を通過し、リクエストされたリソースに対してユーザの認
証と認可が終了すると、適切な送信先サーバに転送されます。
■
柔軟なアーキテクチャが使用します。
情報はすべて、エクストラネット攻撃から保護するため、複数のファ
イアウォールの後ろに配置します。イントラネット ユーザにとって適
切な情報は、SiteMinder 通信に対するエージェントのオーバヘッドを
引き起こしません。 SiteMinder は今までどおり機密性の高いリソース
を保護できます。
■
Web エージェント間の相互運用性を実現します。
CA SiteMinder for Secure Proxy Server およびイントラネット Web エー
ジェントは同じポリシー サーバを使用して、すべての送信先サーバ上
の認可されたエクストラネット ユーザにシングル サインオンを提供
します。
30 管理ガイド
第 2 章： SPS をインストール、アップグレード、
設定します
このセクションには、以下のトピックが含まれています。
手動による SPS のインストール、アップグレード、設定 (P. 31)
サイレント モードでの SPS のインストールと設定 (P. 46)
CA SiteMinder for Secure Proxy Server のアンインストール (P. 47)
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定 (P. 47)
手動による SPS のインストール、アップグレード、設定
CA SiteMinder for Secure Proxy Server は、アクセス制御用にプロキシ ベース
のソリューションを提供するスタンドアロン サーバです。 CA SiteMinder
for Secure Proxy Server は、企業用のネットワーク ゲートウェイを提供し、
従来の Cookie ベースのテクノロジに依存しない複数のセッション スキー
ムをサポートするプロキシ エンジンを使用します。
第 2 章： SPS をインストール、アップグレード、設定します 31
手動による SPS のインストール、アップグレード、設定
次の図は、CA SiteMinder for Secure Proxy Server のインストールと設定方法
について説明しています。
32 管理ガイド
手動による SPS のインストール、アップグレード、設定
前提条件
CA SiteMinder for Secure Proxy Server をインストールまたはアップグレー
ドする前に、以下の前提条件を確認します。
■
ポリシー サーバがインストールされているコンピュータに CA
SiteMinder for Secure Proxy Server がインストールされていない必要が
あります。
■
Linux では、/opt/etc/CA ディレクトリに対する書き込み権限があること
を確認します。
■
Linux では、CA SiteMinder for Secure Proxy Server のインストール先の
フォルダに、十分な権限（755）を持っている必要があります。 デフォ
ルト許可（750）が不十分なため、/root フォルダの下に CA SiteMinder for
Secure Proxy Server をインストールしないでください。
■
Solaris では、CA SiteMinder for Secure Proxy Server は "Nobody" ユーザと
して実行されます。 このユーザとして CA SiteMinder for Secure Proxy
Server を実行しない場合、別のユーザを作成し、必要な権限を割り当
てます。
■
CA SiteMinder for Secure Proxy Server を RHEL にインストールする場合
は、ncurses パッケージがインストール済みであることを確認します。
■
CA SiteMinder for Secure Proxy Server を RHEL 5 または RHEL 6 64 ビット
のコンピュータにインストールする場合は、以下のライブラリをコン
ピュータにインストールしたことを確認します。
–
libstdc++.so.6
–
libexpat.so.0
–
libuuid.so.01
–
libkeyutils.so.1
注： これらのライブラリは 64 ビットのバイナリではなく 32 ビットの
バイナリである必要があります。
■
CA SiteMinder for Secure Proxy Server を RHEL 5.5 コンピュータにインス
トールする場合は、Legacy Software Development パッケージをコン
ピュータにインストールしたことを確認します。
■
Linux 上で CA SiteMinder for Secure Proxy Server をインストールまたは
アップグレードする場合は、keyutils-libs-1.4-4.el6.i686.rpm パッケージ
がインストールされていることを確認します。
第 2 章： SPS をインストール、アップグレード、設定します 33
手動による SPS のインストール、アップグレード、設定
■
JCE - 現在の Java Cryptography Extension （JCE） Unlimited Strength
Jurisdiction パッチは Java の暗号化アルゴリズムを使用するのに必要で
す。 使用しているプラットフォーム用の JCE パッケージを見つけるに
は、Oracle の Web サイトを参照してください。
システム上の以下のファイルにパッチを適用します。
■
local_policy.jar
■
US_export_policy.jar
これらのファイルは、以下のディレクトリにあります。
Windows: jre_home¥lib¥security
UNIX： jre_home/lib/security
jre_home
この変数は、Java Runtime Environment がインストールされる場所
を指定します。
インストール ワークシート
CA SiteMinder for Secure Proxy Server 設定ウィザードは、トラステッド ホス
トを登録するように求める一連のプロンプトを表示します。 トラステッ
ド ホストは、1 つ以上の SiteMinder Web エージェントをインストールでき
るクライアント コンピュータです。 トラステッド ホストとポリシー サー
バの間の接続を確立するために、ホストをポリシー サーバに登録する必
要があります。 登録が完了したら、登録ツールは SmHost.conf ファイルを
作成します。 このファイルが正常に作成されたら、クライアント コン
ピュータはトラステッド ホストになります。
CA SiteMinder for Secure Proxy Server のインストール、アップグレード、ま
たは設定を行う前に、ホスト登録、埋め込み Apache Web サーバ、および
Tomcat サーバに必要な以下の情報を収集したことを確認します。
パラメータ
Description
SiteMinder 管理者名
ポリシー サーバですでに定義されている名前に一
致する管理者の名前。この管理者には、トラステッ
ド ホストを作成する権限が必要です。
34 管理ガイド
手動による SPS のインストール、アップグレード、設定
パラメータ
Description
SiteMinder 管理者パスワード
トラステッド ホストを登録する権限がある
SiteMinder 管理者のパスワード。 ポリシー サーバ
で使用されるパスワードと一致する必要がありま
す。
トラステッド ホスト名
インストール時に割り当てられるトラステッド ホ
ストの名前。
ホスト設定オブジェクト
管理 UI ですでに定義されているホスト設定オブ
ジェクトの名前。
エージェント設定オブジェクト
既存のエージェント設定オブジェクトの名前は 管
理 UI に定義されています。
ホストが登録されているポリシー サーバ
の IP アドレス
注： SiteMinder がファイアウォールの後ろに配置
されている場合のポート番号を記述します。 例：
111.12.12.2:12
エージェント名
デフォルト エージェントまたは ACO で定義され
たエージェントの名前。
マスタ キー
高度な認証サーバのマスタ暗号化キーを識別しま
す。 ポリシー サーバで設定したのと同じ値を入力
します。
ホスト設定ファイルの名前と場所
SmHost.conf ファイルを識別します。Web エージェ
ントとカスタム エージェントはこのファイルを
使って、トラステッド ホストの代理として動作し
ます。 ウィザードは、デフォルトの場所をリスト
表示します。
Web エージェント設定ファイルの名前と
場所
ウィザードは、デフォルトの場所をリスト表示し
ます。
Apache Web サーバ管理者の電子メール ア デフォルトの管理者の電子メール アドレス：
[email protected]
ドレス
サーバの完全修飾ホスト名
次の形式の完全修飾名：
computer_name.company.com
Apache HTTP リクエスト用のポート番号
Apache からの HTTP リクエストをリスンするポー
ト。 デフォルト： 80
Apache SSL リクエスト用のポート番号
Apache からの SSL リクエストをリスンするポー
ト。
デフォルト： 443
第 2 章： SPS をインストール、アップグレード、設定します 35
手動による SPS のインストール、アップグレード、設定
パラメータ
Description
Tomcat HTTP リクエストをリスンするポー
ト番号
Tomcat からの HTTP リクエストをリスンするポー
ト。
デフォルト： 8080
Tomcat SSL リクエストをリスンするポート Tomcat からの SSL リクエストをリスンするポー
番号
ト。
デフォルト： 543
Tomcat シャットダウン リクエストのポー
ト番号
Tomcat からのシャットダウン リクエストをリス
ンするポート。
デフォルト： 8005
AJP のポート番号
AJP のポート番号。
デフォルト： 8009
CA SiteMinder® SPS のインストール
CA SiteMinder for Secure Proxy Server をインストールする前に、CA
SiteMinder for Secure Proxy Server のインストールに必要な情報を収集した
ことを確認します。
Windows への CA SiteMinder® SPS のインストール
次の手順に従ってください：
1. CA Support サイトのダウンロード場所からインストール プログラムを
コピーします。
2. 実行可能ファイルを右クリックし、［管理者として実行］を選択しま
す。
3. ca-proxy-<version>-<operating_system>.exe をダブルクリックします。
インストール プログラムが起動します。
4. インストール ウィザードの指示に従います。
注： デフォルトでは、CA SiteMinder for Secure Proxy Server は、デフォル
トとして最初のインストールのインスタンス名を設定します。 デフォ
ルト値を変更することはできません。また、他の CA SiteMinder for
Secure Proxy Server インスタンスの名前を使用することもできません。
5. インストールが完了した後、システムを再起動します。
36 管理ガイド
手動による SPS のインストール、アップグレード、設定
Linux または Solaris への CA SiteMinder® SPS のインストール
CA SiteMinder for Secure Proxy Server は、Linux および Solaris へのインス
トールをサポートします。
次の手順に従ってください：
1. CA Support サイト上のダウンロード場所から一時ディレクトリに、以
下のいずれかのプログラムをコピーします。
Solaris： ca-proxy-12.5-sol.bin
Linux： ca-proxy-12.5-rhel30.bin
2. 以下のいずれかのコマンドを入力します。
sh ./ca-proxy-12.5-sol.bin
sh ./ca-proxy-12.5-rhel30.bin
3. インストール ウィザードのプロンプトに従います。
CA SiteMinder® SPS インストールの確認
InstallLog ファイルを確認して、CA SiteMinder for Secure Proxy Server インス
トールが正常に実行されたかを確認できます。 デフォルトでは、InstallLog
は、すべてのプラットフォームで以下の場所にインストールされます。
sps_home¥install_config_info¥CA_SiteMinder_Secure_Proxy_Server_InstallLog.log
CA SiteMinder® SPS の複数インスタンスのインストール
複数の CA SiteMinder for Secure Proxy Server インスタンスを同じコン
ピュータにインストールできます。各 CA SiteMinder for Secure Proxy Server
インスタンスは、通信に一意のインスタンス名とポートを使用し、個別の
ディレクトリ構造を作成します。
次の手順に従ってください：
1. ca-proxy-<version>-<operating_system>.exe をダブルクリックします。
インストール プログラムが起動します。
2. 新しいインスタンスのインストール オプションを選択します。
3. インストール ウィザードの指示に従います。
注： 通信に使用するインスタンス名と複数のポートに、一意の値を入
力したことを確認してください。
第 2 章： SPS をインストール、アップグレード、設定します 37
手動による SPS のインストール、アップグレード、設定
CA SiteMinder® SPS のアップグレード
インストール プログラムを実行して、CA SiteMinder for Secure Proxy Server
の旧バージョンから現在のバージョンにアップグレードすることができ
ます。
注： フィルタまたはカスタマイズしたセッション スキームを設定した場
合は、アップグレードする前に、Tomcat/ パスから lib ディレクトリのバッ
クアップを作成してください。
次の手順に従ってください：
1. ca-proxy-<version>-<operating_system>.exe をダブルクリックします。
インストール プログラムが起動します。
2. ［OK］をクリックすると、CA SiteMinder for Secure Proxy Server のバー
ジョンがアップグレードされます。
3. インストール ウィザードの指示に従います。
4. インストールが完了した後、システムを再起動します。
アップグレード用の追加タスク
インストール処理の最後で、アップグレードをサポートするいくつかの追
加の手順を実行できます。CA SiteMinder for Secure Proxy Server 展開内のカ
スタマイズの量に応じて、以下のタスクを 1 つ以上実行できます。
■
ssl.conf ファイルおよび server.conf ファイルの内部の SSL 設定パスが
ユーザの環境に合っていることを確認します。 アップグレードの自動
部分は、すべての証明書がデフォルトの場所にあると仮定します。
■
SSL を有効にし、CA SiteMinder for Secure Proxy Server を以前のリリース
から Linux 上の CA SiteMinder for Secure Proxy Server 12.5 へとアップグ
レードした場合、以下のコマンドを実行して SSL モードで Apache を開
始します。
<install-path>/secure-proxy/proxy-engine/sps-ctl startssl
38 管理ガイド
■
sps_home¥secure-proxy¥SSL 内のフォルダに、証明書、認証機関、およ
びキーがすべて正しくコピーされたことを確認します。
■
proxyrules.xml ファイル内のプロキシ ルール DTD ファイルへのパスを
変更します。 DTD ファイルのデフォルト パスは
sps_home¥proxy-engine¥conf¥dtd¥proxyrules.dtd です。
手動による SPS のインストール、アップグレード、設定
JVM パラメータのカスタマイズ
以下のファイルで Java Virtual Machine（JVM）パラメータをカスタマイズ
できます。
■
Windows では、sps_home¥proxy-engine¥conf ディレクトリに格納さ
れている SmSpsProxyEngine.properties ファイルを変更します。
■
UNIX では、sps_home/proxy-engine ディレクトリに格納されている
proxyserver.sh ファイルを変更します。
第 2 章： SPS をインストール、アップグレード、設定します 39
手動による SPS のインストール、アップグレード、設定
CA SiteMinder® SPS の設定
CA SiteMinder for Secure Proxy Server をインストールした後、設定ウィザー
ドを実行します。 設定ウィザードを使用すると、埋め込み SiteMinder Web
エージェントにトラステッド ホストを登録し、埋め込み Apache Web サー
バに対して管理タスクを実行することができます。
重要： ウィザードを実行する前に、ホストを登録するポリシー サーバで必
要なオブジェクトを必ずセットアップしてください。 これらのオブジェ
クトが設定されていない場合、トラステッド ホストの登録は失敗します。
次の手順に従ってください：
1. コンソール ウィンドウを開き、sps_home/secure-proxy ディレクトリに
移動します。
2. 以下のいずれかのコマンドを入力します。
Windows： ca-sps-config.exe
UNIX： ca-sps-config.sh
設定ウィザードが起動します。
3. CA SiteMinder for Secure Proxy Server を設定するポリシー サーバのバー
ジョンを選択します。
4. ホスト登録をすぐに実行するオプションを選択します。
5. （オプション）共有秘密キーのロールオーバを有効にするオプション
を選択します。
6. トラステッド ホスト登録を登録するには、以下の手順に従います。
a. SiteMinder 管理者の名前とパスワードを指定します。
注： 入力する情報は、トラステッド ホストの登録先のポリシー
サーバですでに定義されている必要があります。
b. トラステッド ホストおよびホスト設定オブジェクトの名前を指定
します。
注： トラステッド ホストに入力する名前は一意である必要があり
ます。 設定オブジェクトの名前は、トラステッド ホストの登録先
のポリシー サーバですでに定義されている必要があります。
c. トラステッド ホストを登録するポリシー サーバの IP アドレスを
入力します。
d. FIPS モードを選択します。
40 管理ガイド
手動による SPS のインストール、アップグレード、設定
e. ホスト設定ファイル（SmHost.conf）の名前および場所を指定しま
す。 ウィザードは、デフォルトの場所をリスト表示します。
f.
エージェント設定オブジェクトの名前を指定します。
注： 入力するエージェント設定オブジェクトは、トラステッド ホ
ストの登録先のポリシー サーバですでに定義されている必要があ
ります。
第 2 章： SPS をインストール、アップグレード、設定します 41
手動による SPS のインストール、アップグレード、設定
7. Apache Web サーバの以下の情報を入力します。
■
Server name
■
Web サーバ管理者の電子メール アドレス
■
HTTP ポート番号
■
SSL ポート番号
8. Tomcat サーバについて、以下の基本情報を入力します。
■
HTTP ポート番号
■
SSL ポート
■
シャットダウン ポート番号
■
AJP ポート番号
注： Solaris または Linux を実行しているシステムにインストールを
行っている場合、Tomcat および Apache を実行するユーザ名の入力を
求める追加画面が表示されます。 このユーザをルートにすることはで
きません。 ユーザ アカウントを手動で作成します。インストール プ
ログラムによるユーザ アカウントの自動作成は実行されません。
Tomcat ユーザは、ログ ディレクトリに対してすべての権限（rwa）を
所有している必要があります。
9. Web エージェントを有効にするには、Yes を選択します。
10. CA SiteMinder for Secure Proxy Server をフェデレーション ゲートウェイ
として動作させる場合は、Yes を選択します。
11. 設定サマリの確認
12. ［インストール］をクリックします。
CA SiteMinder for Secure Proxy Server が設定され、設定ファイルがイン
ストールされます。
13. ［Done］をクリックして、ウィザードを終了します。
14. SiteMinder Secure Proxy および SiteMinder プロキシ エンジン サービス
を開始します。
注： 設定ウィザードを再実行する場合、SSL を再初期化する必要がありま
す。
42 管理ガイド
手動による SPS のインストール、アップグレード、設定
SPS の追加設定
CA SiteMinder for Secure Proxy Server をインストールし、設定ウィザードを
実行した後に、環境に合わせて CA SiteMinder for Secure Proxy Server 設定を
変更できます。 以下の設定ファイルには、CA SiteMinder for Secure Proxy
Server に影響を与える設定が記述されています。
httpd.conf
Apache Web サーバの設定が記述されています。
server.conf
仮想ホスト、セッション スキーム マッピングなど、CA SiteMinder for
Secure Proxy Server の動作を決定する設定が記述されています。
logger.properties
CA SiteMinder for Secure Proxy Server のロギング動作を決定する設定が
記述されています。
proxyrules.xml
CA SiteMinder for Secure Proxy Server による受信リクエストの処理方法
を決定するルールが記述されています。
詳細情報：
プロキシ ルールの設定 (P. 171)
Apache Web サーバを設定する (P. 95)
セッション保証の管理
デフォルトでは、CA SiteMinder for Secure Proxy Server はセッション保証を
有効にします。 機能を無効にする場合は、以下の手順を実行します。
1. server.conf ファイルを開きます。
2. <Context name="AALoginService"> セクションに移動し、有効値を「no」
に設定します。
3. <Context name="Advanced Auth Application"> に移動し、有効値を「no」
に設定します。
4. <Context name="UI Application"> セクションに移動し、有効値を「no」
に設定します。
5. 変更を保存します。
第 2 章： SPS をインストール、アップグレード、設定します 43
手動による SPS のインストール、アップグレード、設定
SiteMinder フォームのデフォルト場所の変更
CA SiteMinder for Secure Proxy Server v6.0 以降、SiteMinder フォームのデ
フォルト場所は /siteminderagent/forms ではなくなりました。 フォームの
入手先としてこの場所を継続して使用するには、CA SiteMinder for Secure
Proxy Server フォームの場所を変更します。
次の手順に従ってください：
1. 以下の場所に、siteminderagent ディレクトリを作成します。
sps_home/proxy-engine/examples/siteminderagent
2. forms フォルダを次のディレクトリからコピーします：
sps_home/proxy-engine/examples
コピー先のディレクトリ：
sps_home/proxy-engine/examples/siteminderagent
フォームは、sps_home/proxy-engine/examples/siteminderagent/forms に
コピーされます。
注：forms フォルダの場所をカスタマイズする場合は、forms イメージ
の場所を使って、httpd.conf ファイルを更新してください。
管理ユーザ インターフェースの保護
デフォルトでは、インストーラは、管理ユーザ インターフェースを保護
するための保護ポリシーを作成します。インストーラは、定義されたエー
ジェント名を使用して、以下の詳細で保護ポリシーを作成します。
■
ドメイン： DOMAIN-SPSPADMINUI
■
ポリシー： POLICY-SPSADMINUI
保護ポリシーにはユーザ ディレクトリ情報が含まれません。 管理ユーザ
インターフェースにログインするには、以下の手順に従います。
1. DOMAIN-SPSPADMINUI をユーザ ディレクトリ情報で更新します。
2. POLICY-SPSADMINUI をユーザ情報で更新します。
44 管理ガイド
手動による SPS のインストール、アップグレード、設定
管理ユーザ インターフェースの起動
プロキシ エンジン サービスの起動後、管理ユーザ インターフェースを起
動できます。 URL を起動するには、Web ブラウザに次の URL を入力しま
す。
http://fullyqualifiedhostname:Tomcat_port/proxyui/
CA SiteMinder for Secure Proxy Server のインストールまたはアップグレー
ドが実行され、設定されます。
最初のインストール後にインストールと設定をサイレントで実行する場
合は、「サイレント インストールと設定」を参照してください。 CA
SiteMinder for Secure Proxy Server をアンインストールする場合は、「CA
SiteMinder for Secure Proxy Server のアンインストール」を参照してくださ
い。 さまざまなモードで CA SiteMinder for Secure Proxy Server を起動する
場合は、「単一プロセス モードまたはマルチ プロセス モードでの CA
SiteMinder for Secure Proxy Server の開始」を参照してください。SiteMinder
フォームのデフォルト場所を変更する場合、「SiteMinder フォームのデ
フォルト場所の変更」を参照してください。
第 2 章： SPS をインストール、アップグレード、設定します 45
サイレント モードでの SPS のインストールと設定
サイレント モードでの SPS のインストールと設定
初めて CA SiteMinder for Secure Proxy Server のインストールと設定を実行
した後は、後から無人で再インストールすることも、保存した設定データ
を使って、CA SiteMinder for Secure Proxy Server の別のインスタンスを無人
インストールすることもできます。
インストール後、CA SiteMinder for Secure Proxy Server は
sps-home/install_config_info フォルダにサンプルのプロパティ ファイルを
作成します。設定後、同じプロパティ ファイルが、設定の追加プロパティ
により更新されます。 このプロパティ ファイルは、以降のサイレントの
インストールおよび設定で使用されます。その際、カスタマイズされた値
が使用されます。
次の手順に従ってください：
1. コマンド ウィンドウを開きます。
2. プロパティ ファイルをインストールしたフォルダに移動します。 デ
フォルトは sps-home/install_config_info です。
3. コマンド プロンプトを開きます。
4. 以下のどちらかまたは両方の手順を実行します。
a. サイレント インストールを実行するには、以下のコマンドを実行
します。
ca-proxy-12.5-operating_system -i silent -f ca-sps-installer.properties
operating_system
オペレーティング システム（win32、sol、または rhel30 のいず
れか）を定義します。
b. サイレント設定を実行するには、以下のコマンドを実行します。
ca-sps-config -i silent -f ca-sps-installer.properties
それ以上のユーザからの操作なしで、インストールまたは設定が実行
されます。
46 管理ガイド
CA SiteMinder for Secure Proxy Server のアンインストール
CA SiteMinder for Secure Proxy Server のアンインストール
Windows からアンインストールするには、以下の手順に従います。
1. コマンド プロンプトを開き、ルート インストール ディレトリに移動
します。
2. アンインストールするインスタンスごとに、以下のコマンドを実行し
ます。
ca-sps-uninstall.cmd
UNIX からアンインストールするには、以下の手順に従います。
1. コンソール ウィンドウを開き、ルート インストール ディレクトリに
移動します。
2. 以下のプログラムを実行します。
./ca-sps-uninstall.sh
注： server.conf など、いずれかのファイルを変更した場合、アンインストー
ル プログラムによって、これらのファイルやその親フォルダが自動的に
削除されることはありません。 ファイルおよびフォルダを手動で削除す
る必要があります。
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定
以下のコンポーネントは、ログ ファイル、およびその他の言語でのコマ
ンドライン ヘルプをサポートします。
■
ポリシー サーバ
■
Web エージェント
■
レポート サーバ
■
CA SiteMinder Agent for SharePoint
■
CA SiteMinder for Secure Proxy Server
■
<エージェント>
■
CA SiteMinder® SDK で作成される任意のカスタム ソフトウェア。
第 2 章： SPS をインストール、アップグレード、設定します 47
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定
以下の図は、ログ ファイル設定のワークフローおよび，別の言語へのコ
マンドライン ヘルプについて説明しています。
次の手順に従ってください：
1. 言語の IANA コードを決定します (P. 49)。
2. 以下のいずれかの手順を使用して、オペレーティング環境用の環境変
数を作成します。
■
Windows オペレーティング環境上でロケール変数を設定します (P.
51)。
■
UNIX または Linux オペレーティング環境で、ロケール変数を設定し
ます (P. 53)。
3. （オプション）ウィンドウ オペレーティング環境で、ロケール変数の
設定を確認します (P. 52)。
4. （オプション）手順 1 ～ 3 を繰り返して、ユーザの環境内の他のコン
ポーネントを同じ言語に設定します。
48 管理ガイド
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定
ユーザの言語の IANA コードを決定します。
各言語にはそれぞれ一意のコードがあります。 IANA（インターネット番
号割当機関）は、これらの言語コードを割り当てます。 言語コードをロ
ケール変数に追加することで、ソフトウェアが表示する言語を変更します。
ロケール変数を作成する前に、目的の言語に該当するコードを決定します。
以下の表は、このソフトウェアでサポートされている言語に対応する
IANA コードのリストを示しています。
言語
IANA コード
ポルトガル語（ブラジル）
pt_BR
フランス語
fr
ドイツ語
de
イタリア語
it
日本語
ja
韓国語
ko
中国語（簡体字）
zh-Hans
スペイン語
es
注： IANA 言語コードのリストは、このサードパーティ Web サイトから利
用可能です。
第 2 章： SPS をインストール、アップグレード、設定します 49
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定
環境変数
環境変数は、ユーザのニーズに適合するように、ユーザがコンピュータを
カスタマイズできる設定です。 この環境変数の例には、以下のような項
目があります。
■
ダウンロードされたファイルを検索または格納するためのデフォルト
ディレクトリ。
■
ユーザ名。
■
実行可能ファイルを検索する場所のリスト（パス）。
Windows オペレーティング環境ではグローバル環境変数を設定でき、これ
はコンピュータのすべてのユーザに適用されます。UNIX または Linux オペ
レーティング環境での環境変数は、各ユーザまたをプログラムに対して設
定する必要があります。
ロケール変数を設定するには、以下のリストからユーザのオペレーティン
グ環境用の手順を選択します。
50 管理ガイド
■
Windows オペレーティング環境上でロケール変数を設定します (P.
51)。
■
UNIX または Linux オペレーティング環境で、ロケール変数を設定しま
す (P. 53)。
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定
Windows オペレーティング環境でのロケール変数の設定
以下のロケール変数は、ソフトウェアの言語設定を指定します。
SM_ADMIN_LOCALE
この変数を作成し、それを目的の言語に設定します。 別の言語を使用す
る各コンポーネントで、この変数を設定します。たとえば、ポリシー サー
バ、およびフランス語に設定されているエージェントがあると仮定します。
それらのコンポーネントの両方で、この変数をフランス語に設定します。
注： インストールまたは設定プログラムでは、この変数は設定されません。
次の手順に従ってください：
1. ［スタート］-［コントロール パネル］-［システム］-［システムの詳
細設定］をクリックします。
［システムのプロパティ］ダイアログ ボックスが表示されます。
2. ［詳細設定］タブをクリックします。
3. ［環境変数］をクリックします。
4. ［システム変数］セクションを見つけてから、［新規］をクリックし
ます。
［新しいシステム変数］ダイアログ ボックスが、カーソルが［変数名］
フィールドにある状態で表示されます。
5. 以下のテキストを入力します。
SM_ADMIN_LOCALE
6. ［変数名］フィールドをクリックしてから、目的の IANA 言語コード (P.
49)を入力します。
7. ［OK］をクリックします。
［新しいシステム変数］ダイアログ ボックスが閉じ、
SM_ADMIN_LOCALE 変数がリストに表示されます。
8. ［OK］を 2 回クリックします。
ロケール変数が設定されます。
9. （オプション）手順 1 ～ 8 を繰り返して、他のコンポーネントを同じ
言語に設定します。
第 2 章： SPS をインストール、アップグレード、設定します 51
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定
Windows オペレーティング環境でのロケール変数値の確認
ロケール変数が設定される値は、随時変更できます。 この手順は、変数
を設定して、それが適切に設定されていることを確認した後に実行できま
す。
注： UNIX および Linux での変数の検証手順は、「プロシージャの設定 (P.
53)」にあります。
次の手順に従ってください：
1. 以下の手順で、コマンドライン ウィンドウを開きます。
a. ［スタート］-［ファイル名を指定して実行］をクリックします。
b. 以下のコマンドを入力します。
cmd
c. ［OK］をクリックします。
コマンドライン ウィンドウが開きます。
2. 以下のコマンドを入力します。
echo %SM_ADMIN_LOCALE%
ロケールが次の行に表示されます。 たとえば、言語がドイツ語に設定
される場合、以下のコードが表示されます。
de
ロケール変数の値が確認されます。
52 管理ガイド
ログ ファイルおよびコマンドライン ヘルプの別の言語への設定
UNIX または Linux オペレーティング環境でのロケール変数の設定
以下のロケール変数は、ソフトウェアの言語設定を指定します。
SM_ADMIN_LOCALE
この変数を作成し、それを目的の言語に設定します。 別の言語を使用す
る各コンポーネントで、この変数を設定します。たとえば、ポリシー サー
バ、およびフランス語に設定されているエージェントがあると仮定します。
それらのコンポーネントの両方で、この変数をフランス語に設定します。
注： インストールまたは設定プログラムでは、この変数は設定されません。
次の手順に従ってください：
1. 目的のコンポーネントを実行しているコンピュータにログインします。
2. コンソール（コマンドライン）ウィンドウを開きます。
3. 以下のコマンドを入力します。
export SM_ADMIN_LOCALE=IANA_language_code
以下の例のコマンドは、言語をフランス語に設定します。
export SM_ADMIN_LOCALE=fr
ロケール変数が設定されます。
4. （オプション）以下のコマンドを入力して、ロケール変数が適切に設
定されていることを確認します。
echo $SM_ADMIN_LOCALE
ロケールが次の行に表示されます。 たとえば、言語がドイツ語に設定
される場合、以下のコードが表示されます。
de
5. （オプション）手順 1 ～ 4 を繰り返して、他のコンポーネントを同じ
言語に設定します。
第 2 章： SPS をインストール、アップグレード、設定します 53
第 3 章： FIPS-140 のサポート
このセクションには、以下のトピックが含まれています。
FIPS サポートの概要 (P. 55)
FIPS ONLY モードの設定プロセス (P. 56)
FIPS MIGRATE モードへの移行 (P. 57)
FIPS ONLY モードへの移行 (P. 58)
FIPS サポートの概要
Secure Proxy Server は、FIPS 140-2 規格で指定された暗号モジュールの要件
をサポートします。CA SiteMinder for Secure Proxy Server のインストール時、
ご使用の動作設定で求められる FIPS サポート レベルを選択するように促
すダイアログ ボックスが表示されます。
新規インストール中、以下の 3 種類の FIPS モードのいずれかを選択できま
す。
■
COMPAT -- インストールが FIPS に準拠しないことを指定します。 CA
SiteMinder for Secure Proxy Server の以前のバージョンを実行するクラ
イアントと対話する場合に、このモードを選択します。
■
MIGRATE -- データの移行中、CA SiteMinder for Secure Proxy Server が
FIPS 準拠のアルゴリズムと、CA SiteMinder for Secure Proxy Server の以
前のバージョンで同時に使われていたアルゴリズムの両方を同時に操
作することを指定します。
■
ONLY -- FIPS 準拠のアルゴリズムのみが CA SiteMinder for Secure Proxy
Server によって使用され承認されることを指定します。 このモードで
インストールした場合、追加の手動設定が必要です。
第 3 章： FIPS-140 のサポート 55
FIPS ONLY モードの設定プロセス
インストール中に選択した FIPS モードは通常、ポリシー サーバで設定し
た FIPS モードと同じです。ポリシー サーバが Migrate モードの場合、任意
のモードの CA SiteMinder for Secure Proxy Server で作動できます。
COMPAT モードを使用しており、既存の CA SiteMinder for Secure Proxy
Server インストールをアップグレードする場合、新しいインストールは
COMPAT モードで動作を継続します。 以下の手順に注意してください。
■
後のセクションで説明するように、smreghost コマンドを使用して、
モードを手動で変更できます。
■
以下の行を JVM_HOME¥jre¥lib¥security¥java.security（Windows）または
JVM_HOME/jre/lib/security/java.security（UNIX）に追加し、JsafeJCE セキュ
リティ プロバイダの初期 FIPS モードに設定します。
com.rsa.cryptoj.fips140initialmode=NON_FIPS140_MODE
■
Web エージェント、CA SiteMinder® SPS サーバおよび Apache サーバが
変更を反映できるように、モード変更後はシステムを再起動します。
詳細情報：
FIPS MIGRATE モードへの移行 (P. 57)
FIPS ONLY モードの設定プロセス (P. 56)
FIPS ONLY モードの設定プロセス
FIPS ONLY モードで CA SiteMinder for Secure Proxy Server をインストールし
た後、次の追加設定手順が必要です。
56 管理ガイド
■
CA SiteMinder for Secure Proxy Server が完全 SSL モードで実行されてい
ることを確認します。
■
SSL モードの CA SiteMinder for Secure Proxy Server を設定するために使
用されるサーバ キーが、FIPS 準拠の暗号化アルゴリズムを使用して生
成されたかを確認します。
■
FIPS ONLY モードで SSL を設定する手順に従います。
FIPS MIGRATE モードへの移行
FIPS MIGRATE モードへの移行
以前のバージョンからのアップグレードを実行中で、FIPS に準拠している
アルゴリズムを使用する場合は、CA SiteMinder for Secure Proxy Server 内部
の Web エージェントを COMPAT モードから MIGRATE モードに変更でき
ます。
CA SiteMinder for Secure Proxy Server を FIPS MIGRATE モードに設定する方法
1. CA SiteMinder for Secure Proxy Server サービスを停止します。
2. コマンド ライン ウィンドウを開きます。
3. 以下のコマンドを入力します。
smreghost -i policy_server_ip_address -u administrator_user_name -p
administrator_password -hn hostname_for_registration -hc host_config_object -f
path_to_host_config_file -o -cf MIGRATE
例：
smreghost -i localhost -u siteminder –p firewall -hn helloworld -hc host -f
"C:¥Program Files¥CA¥secure-proxy¥proxy-engine¥conf¥defaultagent¥SmHost.conf"
-o –cf MIGRATE
4. マシンを再起動します（Windows のみ）。
5. CA SiteMinder for Secure Proxy Server サービスを再起動します。
CA SiteMinder for Secure Proxy Server の内部の Web エージェントが、FIPS
COMPAT から FIPS MIGRATE モードに変更されます。
第 3 章： FIPS-140 のサポート 57
FIPS ONLY モードへの移行
FIPS ONLY モードへの移行
SiteMinder ポリシー サーバが FIPS ONLY または FIPS COMPAT モードの場合、
アップグレード後に、CA SiteMinder for Secure Proxy Server の FIPS モードを
FIPS COMPAT から FIPS ONLY に変更できます。
次の手順に従ってください：
1. CA SiteMinder for Secure Proxy Server サービスを停止します。
2. OPENSSL_FIPS 環境変数の値を 1 に設定します。
3. 以下の手順のいずれかを実行します。
1. Windows で FIPS モードを変更している場合、CA_SM_PS_FIPS140 環
境変数を ONLY に設定します。
2. UNIX で FIPS モードを変更している場合、以下の手順に従います。
a. proxyserver.sh ファイルを開きます。
デフォルト パス： sps-home/proxy-engine/proxyserver.sh
b. CA_SM_PS_FIPS140 環境変数の値を ONLY に設定します。
4. コマンド プロンプトで、以下のコマンドを実行します。
smreghost -i policy_server_ip_address -u administrator_user_name -p
administrator_password -hn hostname_for_registration -hc host_config_object -f
path_to_host_config_file -o -cf ONLY
例：
smreghost -i localhost -u siteminder –p firewall -hn helloworld -hc host -f
"C:¥Program Files¥CA¥secure-proxy¥proxy-engine¥conf¥defaultagent¥SmHost.conf"
-o –cf ONLY
5. CA SiteMinder for Secure Proxy Server が完全 SSL モードで実行されてい
るかどうかを判断します。 SSL が CA SiteMinder for Secure Proxy Server
内部の Apache にすでに有効になっている場合、SSL を無効にして、FIPS
ONLY モードに再設定する必要があります。
6. httpd-ssl.conf ファイルを開きます。
デフォルト パス： sps_home¥httpd¥conf¥extra¥httpd-ssl.conf
7. SSLPassPhraseDialog 変数の値をカスタムに設定します。
8. 以下の行のコメント行を解除します。
SSLCustomPropertiesFile "<sps_home>/Tomcat/properties/spsssl.properties"
58 管理ガイド
FIPS ONLY モードへの移行
9. SSLCustomPropertiesFile 変数の値を
<sps_home>¥httpd¥conf¥spsapachessl.properties に設定します。
10. SSLSpsFipsMode 変数の値を ONLY に設定します。
11. コンピュータを再起動します。
12. CA SiteMinder for Secure Proxy Server サービスを開始します。
第 3 章： FIPS-140 のサポート 59
第 4 章： フェデレーション セキュリティ サー
ビスに対する SPS の使用
このセクションには、以下のトピックが含まれています。
フェデレーション セキュリティ サービスの概要 (P. 61)
SiteMinder フェデレーション環境の SPS ユース ケース (P. 62)
SiteMinder フェデレーション環境の SPS ロール (P. 67)
SPS ユース ケースのソリューション (P. 67)
Cookie なしのフェデレーション (P. 78)
Web エージェント置換としての SPS の使用 (P. 82)
フェデレーション ゲートウェイとしての SPS の使用 (P. 84)
フェデレーション セキュリティ サービスの概要
SiteMinder フェデレーション セキュリティ サービス（FSS）は、ビジネス
パートナー間のセキュリティ情報の交換を可能にします。 このサービス
は、企業間のシームレスな認証およびきめの細かい許可を提供します。
フェデレーション セキュリティ サービスは、以下の方法で CA SiteMinder
for Secure Proxy Server で実装されます。
■
SiteMinder Web エージェントの置換として。
■
SiteMinder Web エージェントおよび Web エージェント オプション
パックの置換として。
フェデレーション サービスは、組織およびそのパートナーに対して以下
を可能にします。
■
安全な方法でユーザ情報を交換
■
1 つの組織のユーザ ID を他の組織のユーザ ID にマップ
■
さまざまな組織間でのシングル サインオンを提供
■
パートナーから受信したユーザ情報に基づくリソースへのアクセスを
制御
■
Windows、UNIX、および IIS、Sun Java System および Apache などのさま
ざまな Web サーバなどの異機種環境で相互作用
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 61
SiteMinder フェデレーション環境の SPS ユース ケース
SiteMinder フェデレーション環境の SPS ユース ケース
パートナー間に業務協定があるように、おそらく同数のフェデレーション
ネットワークのユース ケースがあります。 次のユース ケースでは、パー
トナー間のシングル サインオンを提供するために、ユーザ ID を処理する
さまざまな方法を示します。
ユース ケースの詳細については、「CA SiteMinder フェデレーション セ
キュリティ サービス ガイド」を参照してください。
ユース ケース 1： アカウント リンクに基づくシングル サインオン
ユース ケース 1 では、smcompany.com が社員の健康保険の管理について、
パートナー企業 ahealthco.com と契約します。
smcompany.com の社員が自社サイトの社員ポータル www.smcompany.com
で認証を行い、リンクをクリックして ahealthco.com にある自分の健康保
険情報を表示します。 社員は ahealthco.com の Web サイトに移動し、この
サイトへサインオンしなくても自分の健康保険情報が表示されます。
次の図はこのユース ケースを示しています。
ahealthco.com 社は smcompany.com の社員の健康保険情報をすべて保持し
ます。 このために、ahealthco.com は smcompany.com の全社員のユーザ ID
を保持します。 smcompany.com の社員が ahealthco.com にアクセスすると、
その社員の識別子が安全な方法で smcompany.com から ahealthco.com に
渡されます。 この識別子によって、ahealthco.com はそのユーザが誰かを
特定し、また、そのユーザに対して許可するアクセス レベルを判別でき
ます。
62 管理ガイド
SiteMinder フェデレーション環境の SPS ユース ケース
詳細情報：
ソリューション 1： アカウント リンクに基づく SSO (P. 67)
ユース ケース 2： ユーザ属性プロファイルに基づくシングル サインオン
ユース ケース 2 では、smcompany.com はパートナー企業である
partsco.com から部品を購入します。
エンジニアは社員ポータル smcompany.com で認証を行い、リンクをク
リックして partsco.com の情報にアクセスします。 このユーザは
smcompany.com のエンジニアなので、partsco.com の Web サイトにログイ
ンせずに、このサイトの仕様部分に直接移動できます。
smcompany.com の購入者が認証を行い、partsco.com のリンクをクリック
すると、購入者は partsco.com の Web サイトの部品リスト部分に直接移動
します。 購入者はログインする必要がありません。
ユーザ名などの追加の属性が smcompany.com から partsco.com に渡され
ると、個々のユーザに合わせてインターフェースがカスタマイズされます。
partsco.com は、smcompany.com 全社員のユーザ ID を保持する必要はあり
ませんが、Web サイトの機密部分へのアクセスを制御する必要があります。
アクセスを制御するために、partsco.com は smcompany.com のユーザにつ
いて、限られた数のプロファイル ID を保有します。 エンジニア用に 1 つ
のプロファイル ID、購入者用に 1 つのプロファイル ID が保持されます。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 63
SiteMinder フェデレーション環境の SPS ユース ケース
smcompany.com の社員が partsco.com にアクセスすると、smcompany.com
は partsco.com に安全な方法でユーザ属性を送信します。Partsco.com はこ
の属性を使用して、アクセスを制御するプロファイル ID を決定します。
詳細情報：
ソリューション 2： ユーザ属性プロファイルを使用した SSO (P. 71)
ユース ケース 3： ローカル ユーザ アカウントなしのシングル サインオン
ユース ケース 3 では、smcompany.com が discounts.com とのパートナー
シップを確立して社員割引を提供します。
smcompany.com の従業員は smcompany.com で認証を行い、discounts.com
へアクセスするリンクをクリックします。 社員が discounts.com の Web サ
イトに移動すると、smcompany.com 社員に利用可能な割引が表示されます。
discounts.com の Web サイトにはログインする必要はありません。
次の図はこのユース ケースを示しています。
discounts.com は、smcompany.com の社員の ID を保守しません。
smcompany.com のすべての社員は、smcompany.com で認証を行う限り、
discounts.com へのアクセスが許可されます。 smcompany.com の社員が
discounts.com にアクセスするときに、認証情報が smcompany.com から
discounts.com に安全な方法で送信されます。 この情報を使って
discounts.com へのアクセスが許可されます。
64 管理ガイド
SiteMinder フェデレーション環境の SPS ユース ケース
ユーザ名など追加の属性が smcompany.com から discounts.com に渡される
と、個々のユーザに合わせてインターフェースがカスタマイズされます。
詳細情報：
ソリューション 3： ローカル ユーザ アカウントなしの SSO (P. 73)
ユース ケース 4： 拡張ネットワーク
ユース ケース 4 では、smcompany.com、ahealthco.com および discounts.com
がすべて、拡張されたフェデレーション ネットワークに参加します。 今
回のケースは前出の各ユース ケースの拡張です。
w w w . s m c o m p a n y.c o m
ユーザ ス ト ア
社員ポータ ル
初期認証
イ ン タ ーネッ ト
ユーザ 1
名前
リ ン ク ：
健康保険
ID
Joe
1213
部品サプ ラ イ ヤ
Jane
1410
割引
J a re d
1603
シ ン グル
サイ ン オン
w w w .a h e a lt h c o .c o m
ユーザ ス ト ア
ヘルス プ ラ ン
名前
医療
シ ン グル
サイ ン オン
歯科
リ ン ク ：
割引
sm co m p a n y
ID
Joe
1213
Jane
1410
J a re d
1603
初期認証
w w w .d is c o u n t s .c o m
よ う こ そ Ja n e S m i t h さ ん
イ ン タ ーネッ ト
ユーザ 2
シ ン グル
サイ ン オン
a h e a lth co . co m
社員様
向け特別割引
新規取引
過剰在庫品
このネットワークでは、ahealthco.com の全顧客が smcompany.com に勤務
しているわけではありません。ahealthco.com は、顧客自身と discounts.com
との関係を確立することによってのみ、顧客に割引を提供します。
ahealthco.com は、全顧客のユーザ ID を保持します。したがって、
ahealthco.com は、各ユーザのパスワードなどのローカル認証情報を管理
します。 ローカル認証情報を管理することにより、ahealthco.com はユー
ザを認証でき、提携会社へのシングル サインオン アクセスを提供できま
す。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 65
SiteMinder フェデレーション環境の SPS ユース ケース
この拡張ネットワークで、ユーザは各 Web サイトにさまざまな方法でア
クセスします。
■
User1 は ahealthco.com の Web サイトで健康保険情報にアクセスしま
す。 User1 は smcompany.com の社員ポータルで PartsSupplier リンクを
クリックすることにより、partsco.com の Web サイトにアクセスでき
ます。 また User1 は、社員ポータルでリンクをクリックして、
discounts.com の割引にアクセスすることもできます。
User2 は ahealthco.com の Web サイトで認証を行い、リンクをクリック
して discounts.com の割引にアクセスします。discounts.com の Web サ
イトにログインする必要はありません。 サイトが User2 に提示する割
引は、ahealthco.com と discounts.com の間の業務協定を反映したもので
す。 また、User2 は smcompany.com の社員なので、ahealthco.com のリ
ンクをクリックすると、Web サイトにログインせずに、smcompany.com
の社員ポータルにアクセスできます。
■
User3 （例には登場していません）は、ahealthco.com の顧客ですが、
smcompany.com の社員ではありません。 User3 は ahealthco.com の
Web サイトで認証を行い、リンクをクリックして discounts.com の割引
にアクセスします。User3 は discounts.com の Web サイトにはログイン
しません。 サイトが User3 に提示する割引は、ahealthco.com と
discounts.com の間の業務協定を反映したものです。 User3 は
smcompany.com の社員ではないので、smcompany.com の Web サイト
にはアクセスできません。
詳細情報：
ソリューション 4： 拡張ネットワークの SSO (P. 75)
66 管理ガイド
SiteMinder フェデレーション環境の SPS ロール
SiteMinder フェデレーション環境の SPS ロール
CA SiteMinder for Secure Proxy Server では、2 つのロールのうち 1 つのフェ
デレーション ユース ケースに対するソリューションを提供できます。
■
SiteMinder Web エージェントを置換する標準プロキシ サーバとして
■
フェデレーション ゲートウェイとして
これらの 2 つのロールの主な違いは、必要な設定および展開作業にありま
す。 Web エージェントを置換するプロキシ サーバは、フェデレーション
Web サービス アプリケーションを実行するために、ユーザが個別のサー
バおよびサーブレット エンジンをセットアップすることを必要とします。
フェデレーション ゲートウェイとして動作しているプロキシ サーバには、
Web エージェントのコンポーネントおよびフェデレーション Web サービ
スの組み込みアプリケーションがあります。 専用サーバおよびサーブ
レット エンジンは個別に設定されません。これにより、フェデレーショ
ン セットアップが簡略化されます。
SPS ユース ケースのソリューション
以下のセクションでは、フェデレーション ユース ケースに対する CA
SiteMinder for Secure Proxy Server のソリューションを示します。
ソリューション 1： アカウント リンクに基づく SSO
ソリューション 1 は、ユース ケース 1： アカウント リンクに基づくシン
グル サインオン (P. 62)を解決するために smcompany.com と ahealthco.com
でフェデレーション セキュリティ サービスをどのように展開できるかを
示しています。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 67
SPS ユース ケースのソリューション
以下の図では、アカウント リンクに基づいてソリューションを示します。
68 管理ガイド
SPS ユース ケースのソリューション
CA SiteMinder® は両方のサイトで展開され、インストールは
smcompany.com および ahealthco.com の両方で同じです。Web エージェン
ト オプション パックまたは CA SiteMinder for Secure Proxy Server フェデ
レーション ゲートウェイと共に CA SiteMinder for Secure Proxy Server は、
別のマシンにインストールされたポリシー サーバ オプション パックで、
Web サーバ システムおよびポリシー サーバにインストールできます。
作成側の FWS アプリケーションは、アサーションを取得するサービスを
提供します。 使用側の FWS アプリケーションは、アサーションを使用す
るサービスを提供します。
ソリューション 1 に SAML 1.x Artifact 認証を使用
次のプロセスは、アカウント リンクによるシングル サインオンの 1 つの
ソリューションです。 このソリューションは SAML 1.x Artifact プロファイ
ルを使用します。 他のプロファイル（SAML 1.x POST および SAML 2.0
Artifact および POST）を含むこのユース ケースには、他のソリューション
があります。これらのソリューションについては、「CA SiteMinder フェデ
レーション セキュリティ サービス ガイド」を参照してください。
このソリューションで、smcompany.com はプロデューサ サイトとして機
能しています。 smcompany.com の社員が社員ポータル
（www.smcompany.com）にアクセスした場合、イベント シーケンスは次
のようになります。
1. CA SiteMinder for Secure Proxy Server が初期認証を提供します。
2. 社員が ahealthco.com の健康保険情報を表示するために
smcompany.com でリンクをクリックすると、リンクは
www.smcompany.com のサイト間転送サービスに要求を出します。
3. サイト間転送サービスはアサーション生成プログラムを呼び出し、
SAML アサーションを作成し、SiteMinder セッション サーバにアサー
ションを挿入し、SAML Artifact を返します。
4. CA SiteMinder for Secure Proxy Server は SAML ブラウザ Artifact プロトコ
ルに従って、SAML Artifact により www.ahealthco.com にユーザをリダ
イレクトします。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 69
SPS ユース ケースのソリューション
ahealthco.com はコンシューマ サイトとして機能します。 SAML Artifact に
よるリダイレクト リクエストは、ahealthco.com で SAML 認証情報コレク
タ フェデレーション Web サービスによって処理されます。
イベント シーケンスを以下に示します。
1. SAML 認証情報コレクタが SAML Artifact 認証方式を呼び出し、
smcompany.com のアサーション検索サービスの場所を取得します。
2. SAML 認証情報コレクタは www.smcompany.com のアサーション検索
サービスを呼び出します。
3. www.smcompany.com のアサーション取得サービスは SiteMinder セッ
ション サーバからアサーションを取得し、これを ahealthco.com の
SAML 認証情報コレクタに返します。
4. その後、検証およびセッション作成のために SAML 認証情報コレクタ
はアサーションを SAML Artifact 認証方式へ渡し、ユーザのブラウザへ
の SiteMinder セッション Cookie の発行に進みます。
5. この時点でユーザは、ahealthco.com のポリシー サーバで定義され、
ahealthco.com の CA SiteMinder for Secure Proxy Server によって強制さ
れたポリシーに基づき、ahealthco.com のリソースへのアクセスを許可
されます。
この例では、smcompany.com の管理者は、ポリシー サーバのユーザ イン
ターフェースを使用して、ahealthco.com のアフィリエイトを設定します。
アフィリエイトは、ユーザ固有の ID である属性を使って設定されます。こ
れにより、アサーション生成プログラムは ahealthco.com に対して作成さ
れる SAML アサーションに、ユーザ プロファイルの一部としてその属性を
組み込みます。
ahealthco.com の管理者は、ポリシー サーバのユーザ インターフェースを
使用して、smcompany.com の SAML Artifact 認証方式を設定します。 認証
方式は、smcompany.com のアサーション取得サービス、SAML アサーショ
ンから一意のユーザ ID を抽出する方法、およびアサーションから抽出さ
れた値に一致するユーザ レコードを求めて ahealthco.com のユーザ ディ
レクトリを検索する方法を指定します。
70 管理ガイド
SPS ユース ケースのソリューション
ソリューション 2： ユーザ属性プロファイルを使用した SSO
ソリューション 2 は、ユース ケース 2： ユーザ属性プロファイルに基づく
シングル サインオン (P. 63)を解決するために、smcompany.com と
partsco.com で SiteMinder フェデレーション セキュリティ サービスをどの
ように展開できるかを示しています。
CA SiteMinder® は両方のサイトで展開します。 ユーザと各サイトの間の相
互作用は似ており、そこでは partsco.com が使用機関として機能します。作
成側の FWS アプリケーションは、アサーションを取得するサービスを提
供します。 使用側の FWS アプリケーションは、アサーションを使用する
サービスを提供します。
次の図は SAML 1.x、SAML 2.0 および WS-フェデレーション について類似し
ていますが、フェデレーション Web サービス コンポーネントは以下のよ
うに異なります。
■
SAML 1.x の場合、アサーション取得サービス（Artifact プロファイルの
み用）はプロデューサにあり、SAML 認証情報コレクタは SP にありま
す。
■
SAML 2.0 の場合、Artifact 解決サービス（Artifact バインディングのみ用）
は IdP にあり、アサーション コンシューマ サービスは SP にあります。
■
WS-フェデレーション の場合、シングル サインオン サービスは AP に
あり、セキュリティ トークン コンシューマ サービスは RP にあります。
注： WS-フェデレーション は HTTP-POST バインディングのみをサポー
トします。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 71
SPS ユース ケースのソリューション
72 管理ガイド
SPS ユース ケースのソリューション
次の場合を除き、設定はソリューション 1： アカウント リンクに基づくシ
ングル サインオンと同様です。
■
smcompany.com の管理者は、会社におけるユーザの部門を指定する属
性で、partsco.com のコンシューマまたは SP を定義します。アサーショ
ン生成プログラムは、partsco.com に対して作成する SAML アサーショ
ンに、ユーザ プロファイルの一部としてこの属性を組み込みます。
■
partsco.com の管理者は、smcompany.com の認証方式（Artifact、ポスト、
または WS-フェデレーション）を定義します。スキームは SAML アサー
ションから部門属性を抽出し、アサーションから取得された部門値に
一致するユーザ レコードを partsco.com のユーザ ディレクトリで検索
します。 管理者は、partsco.com の Web サイトへのアクセスを許可さ
れている各部門につき、1 つのユーザ プロファイル レコードを定義し
ます。
ソリューション 3： ローカル ユーザ アカウントなしの SSO
ソリューション 3 は、ユース ケース 3： ローカル ユーザ アカウントなし
のシングル サインオン (P. 64)を解決するために smcompany.com と
discounts.com で SiteMinder フェデレーション セキュリティ サービスをど
のように展開できるかを示します。
CA SiteMinder® は、CA SiteMinder for Secure Proxy Server を 1 台のマシンに
インストールし、Web エージェント オプション パックを別のマシンにイ
ンストールし、ポリシー サーバ オプション パックと共にポリシー サーバ
を 3 台目のマシンにインストールすることにより、smcompany.com で展開
されます。 SAML アフィリエイト エージェントは discounts.com でインス
トールされます。このエージェントは、SAML 1.0 のみをサポートします。
作成側の FWS アプリケーションはアサーション取得サービスを提供しま
す。 使用側の FWS アプリケーションは SAML 認証情報コレクタを提供し
ます。
注： CA SiteMinder for Secure Proxy Server フェデレーション ゲートウェイ
は SAML 1.0 をサポートしないため、SAML アフィリエイト エージェントの
プロデューサとして機能できません。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 73
SPS ユース ケースのソリューション
次の図は、ローカル ユーザ アカウントなしのシングル サインオンを示し
ています。
Smcompany.com は SAML 1.x プロデューサとして機能しています。
smcompany.com の社員が www.smcompany.com の社員ポータルにアクセ
スすると、以下が発生します。
1. CA SiteMinder for Secure Proxy Server が初期認証を提供します。
2. 社員が discounts.com で取り引きにアクセスするために
www.smcompany.com でリンクをクリックすると、リンクは
www.smcompany.com の CA SiteMinder for Secure Proxy Server に要求を
出します。
3. www.smcompany.com の CA SiteMinder for Secure Proxy Server はアサー
ション生成プログラムを呼び出し、SAML アサーションを作成し、
SiteMinder セッション サーバにアサーションを挿入し、SAML Artifact
を返します。
4. CA SiteMinder for Secure Proxy Server は SAML ブラウザ Artifact プロトコ
ルに従って、SAML Artifact により www.discounts.com にユーザをリダイ
レクトします。
74 管理ガイド
SPS ユース ケースのソリューション
Discounts.com はコンシューマ サイトとして機能しています。SAML Artifact
を使用したリダイレクト リクエストは、www.discounts.com の SAML ア
フィリエイト エージェントによって以下のように処理されます。
1. SAML アフィリエイト エージェントは、設定ファイルから
www.smcompany.com のアサーション検索サービスの場所を取得しま
す。
2. SAML アフィリエイト エージェントは www.smcompany.com でアサー
ション検索サービスを呼び出します。
3. www.smcompany.com のアサーション取得サービスは SiteMinder セッ
ション サーバからアサーションを取得し、www.discounts.com の SAML
アフィリエイト エージェントにこれを返します。
4. その後、SAML アフィリエイト エージェントは SAML アサーションを検
証し、ユーザのブラウザに対して SiteMinder アフィリエイト セッショ
ン Cookie を発行します。
5. ユーザは discounts.com のリソースへのアクセスを許可されます。
smcompany.com の管理者は、ポリシー サーバのユーザ インターフェース
を使用して、discounts.com のアフィリエイトを設定します。 アフィリエ
イトは、discounts.com に渡される属性情報で設定されます。 アサーショ
ン生成プログラムは、discounts.com に対して作成する SAML アサーション
に、ユーザ プロファイルの一部としてこの属性を組み込みます。
discounts.com の管理者は、discounts.com サイト、smcompany.com のアサー
ション取得サービスの場所、および smcompany.com で定義されたアフィ
リエイトに保護されるリソースに関する情報を持った SAML アフィリエ
イト エージェントを設定します。
ソリューション 4： 拡張ネットワークの SSO
ソリューション 4 では、ユース ケース 4： 拡張ネットワーク (P. 65)を解決
するために、smcompany.com、ahealthco.com および discounts.com で
SiteMinder フェデレーション セキュリティ サービスをどのように展開で
きるかを説明します。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 75
SPS ユース ケースのソリューション
次の図は、拡張ネットワークを説明しています。SAML 1.x は使用中のプロ
トコルです。
76 管理ガイド
SPS ユース ケースのソリューション
SiteMinder は smcompany.com と ahealthco.com で展開されます。
smcompany.com では、Web エージェント オプション パックと共に CA
SiteMinder for Secure Proxy Server を 2 台のマシンにインストールできます。
または、CA SiteMinder for Secure Proxy Server フェデレーション ゲートウェ
イを 1 台のマシンにインストールできます。 ポリシー サーバ オプション
パックと共にポリシー サーバは、別のマシンにインストールされます。
ahealthco.com では、Web エージェント オプション パックと共に CA
SiteMinder for Secure Proxy Server を 2 台のマシンにインストールできます。
また、ポリシー サーバ オプション パックと共にポリシー サーバを別のマ
シンにインストールされます。 discounts.com では、SAML アフィリエイト
エージェントがインストールされています。
作成側の FWS アプリケーションは、アサーションを取得するサービスを
提供します。 使用側の FWS アプリケーションは、アサーションを使用す
るサービスを提供します。
ソリューション 4 は以下のように展開します。
■
smcompany.com は User1 に対してはプロデューサ、User2 に対しては
コンシューマとして機能します。
■
ahealthco.com は、User1 に対してはコンシューマ、User2 に対してはプ
ロデューサ、および User3 に対してはプロデューサとして機能します。
■
discounts.com は User1、User2 および User3 に対してコンシューマとし
て機能します。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 77
Cookie なしのフェデレーション
smcompany.com の管理者は、アフィリエイト ドメインに ahealthco.com と
discounts.com を表す 2 つのエンティティを設定しました。 これらのサイ
トは、以前に説明した 例 1 および 3 と同様の方式で設定されます。しかし、
これらの設定は以下のように拡張されました。
■
smcompany.com で、管理者は SAML 認証方式（Artifact または POST）を
設定しました。User2 については、認証方式により、smcompany.com は
ealthco.com に対してコンシューマとして機能できるようになります。
■
ahealthco.com では以下のようになります。
■
■
管理者は、アサーションが User2 に対して作成されるように
smcompany.com を表すアフィリエイト オブジェクトを設定しまし
た。 これは、smcompany.com へのシングル サインオンを可能にし
ます。
■
管理者は、アサーションが User2 および User3 に対して作成される
ように discounts.com を表すアフィリエイト オブジェクトを設定
しました。 これは、discounts.com へのシングル サインオンを可能
にします。
discounts.com では、例 3 （2 つのサイトをつなぐ矢印は、図には表示
されていません）と同様、管理者は、smcompany.com に対してコン
シューマとして機能するように SAML アフィリエイト エージェントを
設定しました。 また、discounts.com の管理者は、SAML アフィリエイ
ト エージェントが User2 と User3 用の ahealthco.com からのアサー
ションを消費できるように、ahealthco.com に関する設定情報を追加し
ました。
Cookie なしのフェデレーション
特定のデバイスまたは環境では、ユーザ セッションを確立およびシング
ル サインオンを提供するために Cookie を使用できません。
フェデレーション環境で使用できるセッション スキームのタイプの 1 つ
は、Cookie なしのスキームです。 Cookie なしのフェデレーション スキー
ムは、シングル サインオンを確立するために使用されます。 FWS に生成
された Cookie （セッションおよび属性）が、Cookie をサポートしないモバ
イル デバイスを使用して、クライアントに返送されないことを確認しま
す。
78 管理ガイド
Cookie なしのフェデレーション
作成サイトの Cookie なしのフェデレーション
アサーションを作成するサイトで、Cookie なしのトランザクションのプロ
セスは以下のとおりです。
1. CA SiteMinder for Secure Proxy Server は、リダイレクトをリクエストし
ている仮想ホストに対して、Cookie を使用しないフェデレーションが
有効かどうかを確認できます。
2. CA SiteMinder for Secure Proxy Server は、セッション スキームが
simple_url スキームなどの書き換え可能なスキームであるかどうかを
確認します。
3. スキームが書き換え可能な場合、CA SiteMinder for Secure Proxy Server
はセッション キーがセッション用に作成されているかどうか、および
このキーが使用可能かどうかを決定します。
4. CA SiteMinder for Secure Proxy Server は、HTTP レスポンスのロケーショ
ン ヘッダが以下のいずれかの条件を満たしているかどうかを確認し
ます。
■
ヘッダが書き換えられている。
■
リクエストのホストと同じ。
5. CA SiteMinder for Secure Proxy Server は、リダイレクトされた URL に
セッション キー情報を含めるために、リダイレクト レスポンスを書き
換えます。
使用サイトの Cookie なしのフェデレーション
アサーションを使用しているサイトで、Cookie なしのフェデレーションが
有効な場合、Web エージェントを置換する CA SiteMinder for Secure Proxy
Server が、バックエンド サーバで SAML 認証を使用してリダイレクトを処
理します。
Cookie なしのフェデレーションで、CA SiteMinder for Secure Proxy Server は
以下のようにリクエストを処理します。
1. CA SiteMinder for Secure Proxy Server は携帯電話などの Cookie なしのデ
バイスからリクエストを受信します。
2. CA SiteMinder for Secure Proxy Server は、Cookie なしのフェデレーショ
ンがリダイレクトをリクエストする仮想ホストに対して有効かどうか
を確認します。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 79
Cookie なしのフェデレーション
3. その後、CA SiteMinder for Secure Proxy Server は以下の条件が満たされ
ているかどうかを確認します。
■
バックエンド サーバからのレスポンスはリダイレクト。
■
レスポンスに SMSESSION Cookie が含まれる。
これらの 2 つの条件が同時に満たされる場合、SAML 認証が FWS アプ
リケーションからのバックエンド サーバで発生していることを示し
ます。
4. CA SiteMinder for Secure Proxy Server は、使用中のセッション スキーム
を取得します。
5. CA SiteMinder for Secure Proxy Server は関連する Cookie なしのセッショ
ンを作成し、セッション情報をそのセッション ストアに追加します。
6. セッション スキームが単純な URL セッション スキームのように書き
換え可能な場合、CA SiteMinder for Secure Proxy Server はセッション
キーでロケーション ヘッダを書き換えます。
7. Cookie なしのフェデレーション セッション変換が発生していると CA
SiteMinder for Secure Proxy Server が判断する場合、CA SiteMinder for
Secure Proxy Server はブラウザに移動するレスポンスから SMSESSION
Cookie を削除します。
8. その後、CA SiteMinder for Secure Proxy Server は属性 Cookie も削除され
る必要があるかどうかを確認します。deleteallcookiesforfed パラメータ
(P. 147)を確認して、これを実行します。このパラメータが yes に設定
されている場合、CA SiteMinder for Secure Proxy Server はブラウザに移
動するレスポンスから他の Cookie をすべて削除します。
80 管理ガイド
Cookie なしのフェデレーション
使用側での Cookie なしのフェデレーションの有効化
CA SiteMinder for Secure Proxy Server がアサーションの使用側で Web エー
ジェントを置換する場合、Cookie なしのフェデレーション パラメータは、
CA SiteMinder for Secure Proxy Server によって実装された任意の Cookie な
しのセッション スキームに対して有効になります。
使用側で CA SiteMinder for Secure Proxy Server に対して Cookie なしのフェデ
レーションを有効にする方法
1. sps_home/secure-proxy/Tomcat/properties から noodle.properties ファイ
ルを開きます。
2. 以下の 2 つの行から「#」を削除し、ファイルを保存します。
■
filter._cookielessfederation_.class=org.tigris.noodle.filters.CookielessFe
dFilter
■
filter._cookielessfederation_.order=1
設定が保存されます。
3. sps_home/secure-proxy/proxy-engine/conf に配置された server.conf ファ
イルを開きます。
4. FWS を処理している仮想ホストの仮想ホスト セクションに以下の
コードを追加します。
cookielessfederation="yes"
5. ファイルを保存します。
CA SiteMinder for Secure Proxy Server は使用しているパートナーで
Cookie なしのフェデレーションに対して設定されます。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 81
Web エージェント置換としての SPS の使用
Web エージェント置換としての SPS の使用
フェデレーション シングル サインオンを提供するために、CA SiteMinder
for Secure Proxy Server を SiteMinder Web エージェントの代わりとして使
用できます。CA SiteMinder for Secure Proxy Server、および Web エージェン
ト オプション パックは、Web アプリケーションとしてパッケージ化され
たサーブレットのコレクションである、フェデレーション Web サービス
（FWS）アプリケーションを提供するためにまとめられます。 このアプリ
ケーションは、SiteMinder フェデレーション機能の多くを提供します。
SiteMinder フェデレーション セキュリティ サービスのナレッジは、フェデ
レーション環境で CA SiteMinder for Secure Proxy Server を設定している任
意のユーザに必要です。 フェデレーション セキュリティ サービスの詳細
については、「CA SiteMinder フェデレーション セキュリティ サービス ガ
イド」を参照してください。
以下の図では、CA SiteMinder for Secure Proxy Server が SiteMinder Web エー
ジェントを置換する環境を示します。
F ir e w a ll
F ir e w a ll
W eb Agent
P o lic y S e r v e r /
O p tio n P a c k
P o lic y S e r v e r
(F W S )
O p tio n P a c k
HTTP/
HTTPS
SPS
tr a ffic
(e m b e d d e d
W e b A g e n t)
D e s tin a tio n S e r v e r
重要： フェデレーション環境で Web エージェントの代わりに CA
SiteMinder for Secure Proxy Server を使用する場合、Web エージェント オプ
ション パックは、専用の Web サーバおよびサーブレット エンジンを必要
とします。
82 管理ガイド
Web エージェント置換としての SPS の使用
Web エージェント置換として SPS を使用するための前提条件
SiteMinder フェデレーション セキュリティ サービス環境で使用できるよ
うに CA SiteMinder for Secure Proxy Server を設定する前に、以下を考慮しま
す。
■
「CA SiteMinder フェデレーション セキュリティ サービス ガイド」の
情報に従って、SiteMinder 環境を設定する必要があります。フェデレー
ション セキュリティ サービスが正しく設定されていることを確認す
るには、標準の Web エージェントでフェデレーション環境を設定する
ことをお勧めします。
■
SiteMinder ポリシー サーバのユーザ インターフェースで、アサーショ
ンを生成する CA SiteMinder for Secure Proxy Server システムのホスト情
報（サーバおよびポート番号）を定義します。 CA SiteMinder for Secure
Proxy Server ホストは、指定しているフェデレーション パートナーの適
切なプロパティ ダイアログ ボックスの［サーバ］フィールドで定義さ
れています。
フェデレーション用 Web エージェントの置換として SPS を設定
フェデレーション環境で動作するための CA SiteMinder for Secure Proxy
Server の設定プロセスは、標準 CA SiteMinder for Secure Proxy Server 設定プ
ロセスと同様です。
CA SiteMinder for Secure Proxy Server フェデレーション ゲートウェイの設
定プロセスの概要を以下に示します。
1. CA SiteMinder for Secure Proxy Server をインストールします。
2. 設定ウィザードを実行します。
3. server.conf ファイルで一般的なサーバ設定を指定します。 ほとんどの
server.conf 設定にはデフォルトがありますが、ログ記録、セッション ス
キーム、または仮想ホスト設定などの設定を変更できます。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 83
フェデレーション ゲートウェイとしての SPS の使用
4. リクエストがバックエンド サーバに送信されるように、proxyrules.xml
ファイルでプロキシ ルールを定義します。
アサーションを作成する企業では、FWS をホストしているバックエン
ド サーバにリクエストを転送するプロキシ ルールを定義します。 ア
サーションを使用する側では、ユーザがターゲット リソースへのアク
セスを許可された後に、リクエストを送信先サーバに転送するルール
が必要です。
5. （オプション） CA SiteMinder for Secure Proxy Server に仮想ホストを設
定する場合、たとえば、Apache Web サーバ ファイル（httpd.conf）を
変更できます。
詳細情報：
プロキシ ルールの設定 (P. 171)
Apache Web サーバを設定する (P. 95)
SPS サーバ設定を設定する (P. 97)
フェデレーション ゲートウェイとしての SPS の使用
CA SiteMinder for Secure Proxy Server フェデレーション ゲートウェイは、
フェデレーション環境に含まれる設定を簡略化します。通常、パートナー
が多くの Web サーバを介して通信しているフェデレーション環境を所有
しています。 Web サーバはそれぞれ、Web エージェントおよび Web エー
ジェント オプション パックをインストールおよび設定することを必要と
します。
フェデレーション ゲートウェイとして CA SiteMinder for Secure Proxy
Server を有効にする場合、インストールおよびセットアップする必要があ
るコンポーネントの数が尐なくなります。 CA SiteMinder for Secure Proxy
Server フェデレーション ゲートウェイには、CA SiteMinder for Secure Proxy
Server の標準埋め込みコンポーネントおよび Web エージェント オプショ
ン パックによって提供されるフェデレーション Web サービス アプリ
ケーションがあります。
注： SiteMinder フェデレーション セキュリティ サービスのナレッジは、
フェデレーション環境で CA SiteMinder for Secure Proxy Server を設定して
いる任意のユーザに必要です。 フェデレーション セキュリティ サービス
の詳細については、「CA SiteMinder フェデレーション セキュリティ サー
ビス ガイド」を参照してください。
84 管理ガイド
フェデレーション ゲートウェイとしての SPS の使用
以下の図では、CA SiteMinder for Secure Proxy Server フェデレーション ゲー
トウェイの有無による違いを示します。
F e d e r a t e d E n v ir o n m e n t w it h o u t t h e S P S F e d e r a t io n G a t e w a y
F ir e w a ll
F ir e w a ll
P a r tn e r 3
P a r tn e r 2
P o lic y S e r v e r /
D e s tin a tio n S e r v e r
P o lic y S e r v e r
O p tio n P a c k
P a r tn e r 1
W e b A g e n ts /
W e b A g e n t O p tio n P a c k s
F e d e r a t e d E n v ir o n m e n t w it h t h e S P S F e d e r a t io n G a t e w a y
F ir e w a ll
F ir e w a ll
P a r tn e r 3
P a r tn e r 2
S P S F e d e r a tio n G a te w a y
P o lic y S e r v e r /
D e s tin a tio n S e r v e r
P o lic y S e r v e r
O p tio n P a c k
P a r tn e r 1
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 85
フェデレーション ゲートウェイとしての SPS の使用
フェデレーション ゲートウェイを使用するための前提条件
フェデレーション ゲートウェイとして CA SiteMinder for Secure Proxy
Server をセットアップする前に、以下を考慮します。
■
「CA SiteMinder フェデレーション セキュリティ サービス ガイド」の
情報に従って、SiteMinder 環境を設定する必要があります。フェデレー
ション用のポリシー サーバ側コンポーネントが設定されていること
を確認します。
■
CA SiteMinder for Secure Proxy Server をインストールし、プロンプトが
表示されたら enablefederationgateway 設定を有効にします。
■
SiteMinder ポリシー サーバのユーザ インターフェースで、アサーショ
ンを生成する CA SiteMinder for Secure Proxy Server システムのホスト情
報（サーバおよびポート番号）を必ず定義します。 CA SiteMinder for
Secure Proxy Server ホストは、指定しているフェデレーション パート
ナーの適切なプロパティ ダイアログ ボックスの［サーバ］フィールド
で定義されています。
SPS フェデレーション ゲートウェイの設定
CA SiteMinder for Secure Proxy Server フェデレーション ゲートウェイは、プ
ロデューサ サイトと消費者サイトに配置できます。
CA SiteMinder for Secure Proxy Server フェデレーション ゲートウェイの設
定プロセスの概要を以下に示します。
1. CA SiteMinder for Secure Proxy Server をインストールします。
2. 設定ウィザードを実行します。
3. server.conf ファイルで一般的なサーバ設定を指定します。 ほとんどの
server.conf 設定用にはデフォルト値が設定されていますが、こうした
設定をセッション スキーマまたは仮想ホスト設定として変更するこ
ともできます。
86 管理ガイド
フェデレーション ゲートウェイとしての SPS の使用
4. リクエストがバックエンド サーバに送信されるように、proxyrules.xml
ファイルでプロキシ ルールを定義します。
アサーションを生成する企業では、フェデレーション リクエストは CA
SiteMinder for Secure Proxy Server に埋め込まれている Tomcat サーバに
転送されます。Tomcat サーバは、FWS アプリケーションをホストしま
す。 フェデレーション リクエストが処理された場合、プロキシ ルー
ルとフィルタは関連付けされません。
アサーションを消費する企業では、ターゲット リソースへのアクセス
が許可された後、ターゲット サーバへリクエストを転送するプロキシ
ルールを定義する必要があります。
5. （オプション） Apache Web サーバ ファイル（httpd.conf）を変更でき
ます。
SPS フェデレーション ゲートウェイの制限
CA SiteMinder for Secure Proxy Server フェデレーション ゲートウェイを使
用する場合、以下の制限に注意してください。
■
フェデレーション リソースがリクエストされている場合、プレフィル
タおよびポストフィルタ（ビルトインおよびカスタム設定の両方）は
実行されません。デフォルト コンテキストに対して起動されたフェデ
レーション以外のリクエストの場合、これらのフィルタは通常通りに
実行されます。
■
フェデレーション リソースがリクエストされている場合、プロキシ
ルールは実行されません。デフォルト コンテキストに対して起動され
たフェデレーション以外のリクエストの場合、これらのルールは通常
通りに実行されます。
第 4 章： フェデレーション セキュリティ サービスに対する SPS の使用 87
第 5 章： SPS 上のセキュリティ ゾーン
このセクションには、以下のトピックが含まれています。
シングル サインオンのセキュリティ ゾーンの概要 (P. 89)
セキュリティ ゾーンの利点 (P. 90)
セキュリティ ゾーンの基本ユースケース (P. 91)
セキュリティ ゾーン用パラメータ (P. 92)
CA SiteMinder for Secure Proxy Server セキュリティ ゾーンの設定 (P. 94)
シングル サインオンのセキュリティ ゾーンの概要
SSO セキュリティーゾーンでは、同じ Cookie ドメイン内のアプリケーショ
ンのグループ間で設定可能な信頼関係を提供します。 ユーザには同じ
ゾーンの中ではシングル サインオンが適用されますが、別のゾーンに入
るときは、ゾーン間に定義された信頼関係に応じて認証情報を要求される
場合があります。 信頼済み関係に含まれているゾーンでは、グループの
任意のゾーンで有効なセッションを持つユーザには認証を要求しません。
CA SiteMinder® Web エージェントはシングル サインオン セキュリティ
ゾーンを実装します。 各ゾーンは、別々の Web エージェント インスタン
ス上に存在する必要があります。 同一のエージェント設定オブジェクト
を使用して設定される Web エージェントはすべて、同一のシングル サイ
ンオン ゾーンに属します。
Cookie は Web エージェント ID セキュリティーゾーンによって生成されま
す。 デフォルトで、Web エージェントは 2 つの Cookie （SMSESSION とい
う名前のセッション Cookie および SMIDENTITY という名前の ID Cookie）を
生成します。 セキュリティ ゾーンの設定時に、ゾーンのアフィリエイト
を Cookie 名に反映させるために、Web エージェントは固有の名前を持つ
セッション Cookie および ID Cookie を生成します。
注： SSO セキュリティーゾーンの詳細については、「CA SiteMinder Web
エージェント ガイド」を参照してください。
第 5 章： SPS 上のセキュリティ ゾーン 89
セキュリティ ゾーンの利点
セキュリティ ゾーンの利点
SSO セキュリティ ゾーン機能は、CA SiteMinder® 管理者が同じ cookie ドメ
イン内にあるシングル サインオン環境をセグメント化する必要がある場
合に使用することを目的としています。 たとえば、CA.COM というドメイ
ンがあるとします。 標準の CA SiteMinder® SSO 機能では、CA.COM 内の CA
SiteMinder® 保護下にあるすべてのアプリケーションは、SMSESSION cookie
を使用してシングル サインオンを管理します。以下のような、SSO セキュ
リティ ゾーンが存在しないシナリオを考えてみます。
1. ユーザがアプリケーション（APP1）にアクセスします。 ユーザは CA
SiteMinder® から認証情報を要求されます。CA SiteMinder® にログイン
すると、SMSESSION cookie が作成されます。
2. ユーザは 2 つ目のアプリケーション（APP2）にアクセスし、CA
SiteMinder® から認証情報を再要求されます （ユーザは APP1 のユーザ
認証情報を使用して APP2 にアクセスすることができないため、ルール
に従って、SSO は適用されません）。ユーザがログインすると、新し
い SMSESSION cookie が作成され、前の cookie は APP2 への新たなログ
イン セッションによって上書きされます。
3. ここでユーザが APP1 に戻ると、さらにもう一度認証情報を要求されま
す。これは、ユーザは元の APP1 セッションを失っており、かつ、APP1
は APP2 セッションを受け入れないためです。 したがって、APP1 と
APP2 の間で SSO は適用されず、非常に面倒な状況になります。
SSO セキュリティ ゾーンを使用すると、APP1 をゾーン Z1 に、APP2 をゾー
ン Z2 に置くことができます。 ここで、APP1 にログインすると Z1SESSION
cookie が作成され、APP2 にアクセスすると Z2SESSION cookie が得られます。
名前が異なるので、cookie は互いを上書きすることがなくなります。した
がって、上の例のようにユーザはアプリケーション間を移動するたびにロ
グインする必要がなくなり、アプリケーションごとに 1 回のログインで済
むようになります。
SSO セキュリティ ゾーン機能が提供されるまでは、アプリケーションにつ
いて SSO を同様にグループ化する唯一の方法は、異なるネットワーク ド
メインの作成を経て、異なる cookie ドメイン（CA1.COM、CA2.COM、その
他）を作成し、各種のマルチ cookie ドメイン設定を cookie プロバイダと
併用することでした。 これは、多くの企業にとって望ましくない方法で
す。複数のネットワーク ドメインを使用すると、相応の IT 保守およびサ
ポートが必要になるからです。
90 管理ガイド
セキュリティ ゾーンの基本ユースケース
セキュリティ ゾーンの基本ユースケース
シングル サインオンは、制御された基準に応じて、設定可能な信頼関係
を持ついくつかのセキュリティ ゾーンに分けることができます。 たとえ
ば、以下のゾーン A とゾーン B について考えてみます。
■
ゾーン A の持つトラステッド ゾーンは、ゾーン A 自身のみです。
■
ゾーン B は、ゾーン B 自身とゾーン A の 2 つのトラステッド ゾーンを
持ちます。
上の図の信頼関係は、矢印で示されています。つまり、ゾーン A で確立さ
れるユーザ セッションは、ゾーン B のシングル サインオンに使用できま
す。
この例では、ゾーン A は管理者専用ゾーンであるのに対して、ゾーン B は
共通のアクセス ゾーンである可能性があります。 ゾーン A で認証された
管理者は、再認証を要求されることなくゾーン B へのアクセス権を取得で
きます。 ただし、ゾーン B で認証されたユーザは、ゾーン A にアクセス
しようとすると、再認証を要求されます。
別のゾーン内のユーザ セッションは、相互に独立しています。 ユーザが
ゾーン B で最初に認証された場合は、ゾーン B で再度認証されます。 2 つ
の異なるセッションが作成されます。 実際は、ユーザは両方のセッショ
ンで異なる ID を持ちます。 ユーザがゾーン A に戻ると、このゾーンで確
立されたセッションが使用されます。
ユーザが、まだセッションを確立していないゾーンでシングル サインオ
ンを使用して検証されると、どうなるかについて考えてみます。 ユーザ
がゾーン A で認証されてから、初めてゾーン B にアクセスすると、ゾーン
A のセッション情報に基づいてユーザ セッションがゾーン B に作成され、
場合によってはポリシー サーバによって更新されます。 ゾーン A のユー
ザ セッションは、ユーザがゾーン A に戻るまで更新されないことに注意
してください。
第 5 章： SPS 上のセキュリティ ゾーン 91
セキュリティ ゾーン用パラメータ
セキュリティ ゾーン用パラメータ
以下に表示する 2 つのシングル サインオン パラメータが、ポリシー スト
ア内の Web エージェント設定オブジェクトに手動で追加されました。 こ
れらの設定は、ローカル設定ファイルでも使用される可能性があり、イン
ストール時に作成されるサンプルのローカル設定ファイルに追加されま
す。
SSOZoneName
Web エージェントがサポートするシングル サインオン セキュリ
ティー ゾーンの（大文字と小文字を区別する）名前を指定します。 こ
のパラメータの値は Web エージェントが作成する cookie の名前に先
頭に付けられます。このパラメータが空でない場合、CA SiteMinder® は
以下の規則を使用して、cookie を生成します: ZonenameCookiename デ
フォルトは空で、ゾーン名として SM を使用します。これにより cookie
に以下のデフォルト名が与えられます。
■
SMSESSION
■
SMIDENTITY
■
SMDATA
■
SMTRYNO
■
SMCHALLENGE
■
SMONDENIEDREDIR
例： Z1 に値を設定すると以下の cookie が作成されます。
92 管理ガイド
■
Z1SESSION
■
Z1IDENTITY
■
Z1DATA
■
Z1TRYNO
■
Z1CHALLENGE
■
Z1ONDENIEDREDIR
セキュリティ ゾーン用パラメータ
SSOTrustedZone
シングル サインオン セキュリティ ゾーンの信頼の信頼された
SSOZoneNames の順序づけられた（大文字と小文字を区別する）リストを
定義します。 必要に応じて、SM を使用してデフォルト ゾーンを追加しま
す。 エージェントは常に、その他すべてのトラステッド シングル サイン
オン ゾーンより、自身の SSOZoneName を信頼します。 デフォルトは空で
すが、指定された場合、SM または SSOZoneName になることもあります。
第 5 章： SPS 上のセキュリティ ゾーン 93
CA SiteMinder for Secure Proxy Server セキュリティ ゾーンの設定
CA SiteMinder for Secure Proxy Server セキュリティ ゾーンの設定
以下のいずれかのメソッドで、CA SiteMinder for Secure Proxy Server のセ
キュリティーゾーンを設定できます。
■
CA SiteMinder for Secure Proxy Server サーバの ACO オブジェクトに基づ
いてポリシー サーバに設定されている複数の CA SiteMinder for Secure
Proxy Server サーバに、セキュリティーゾーンを設定します。
■
CA SiteMinder for Secure Proxy Server サーバの後ろに展開された、複数
の Web サーバ上にセキュリティ ゾーンを設定します。
複数の CA SiteMinder for Secure Proxy Server サーバにセキュリティ ゾーン
を設定するには、以下の手順を実行します。
1. 最初の CA SiteMinder for Secure Proxy Server サーバに SSOZoneName パ
ラメータを設定します。
2. 1 つのセキュリティ ゾーンまたは複数のセキュリティ ゾーンとして
グループ化する CA SiteMinder for Secure Proxy Server サーバに、
SSOZoneName および SSOTrustedZone パラメータを設定します。
CA SiteMinder for Secure Proxy Server サーバの複数の Web サーバ上のセ
キュリティ ゾーンを設定するには、以下の手順を実行します。
1. セキュリティーゾーンに属する必要がある Web サーバごとに、ACO を
作成します。
2. セキュリティーゾーンに属する必要がある単一またはグループの
Web サーバに、仮想ホストを作成します。
3. 各仮想ホストが異なるセキュリティ ゾーンに属するように、一意の
ACO が仮想ホストをポイントしていることを確認します。
4. 最初の Web サーバの ACO に SSOZoneName パラメータを設定します。
5. 1 つのセキュリティ ゾーンまたは複数のセキュリティ ゾーンとして
グループ化する仮想ホストの ACO に、SSOZoneName および
SSOTrustedZone パラメータを設定します。
94 管理ガイド
第 6 章： Apache Web サーバを設定する
このセクションには、以下のトピックが含まれています。
Apache Web サーバ設定ファイル (P. 95)
Apache Web サーバ設定ファイル
CA SiteMinder for Secure Proxy Server プロキシ エンジンは埋め込み Apache
Web サーバと共に動作します。 たとえば、SPS 用の仮想ホストを設定する
場合、Apache Web サーバ設定を変更できます。
Apache の Web サーバ用の設定ファイルは httpd.conf ファイルで、以下の
場所にあります。
sps_home/secure-proxy/httpd/conf/
重要： SPS のアップグレード中、または他の再設定シナリオで Apache の設
定を変更した場合は、変更を反映するために CA SiteMinder for Secure Proxy
Server サービスを再起動します。さらに、新しい設定（たとえば新しいポー
ト番号）を適用した CA SiteMinder for Secure Proxy Server を再起動します。
第 6 章： Apache Web サーバを設定する 95
第 7 章： SPS サーバ設定を設定する
SPS server.conf ファイルの概要
CA SiteMinder for Secure Proxy Server は server.conf ファイルに記述されて
いる設定によって設定されます。 ファイル内のこれらの設定は、CA
SiteMinder for Secure Proxy ServerCA SiteMinder for Secure Proxy Server が起
動時に読み取る名前/値のペアまたはディレクティブのグループです。
CA SiteMinder for Secure Proxy Server が起動した後、このファイル内の値を
検証して、CA SiteMinder for Secure Proxy Server Web エージェント ログ レ
ベル設定が変更されたかどうかを決定します。 変更が検出された場合、
CA SiteMinder for Secure Proxy Server がネットワーク トラフィックを中断
せずにダイナミック更新を実行できるように、影響を受ける設定をリロー
ドします。
server.conf ファイルは以下のディレクトリにあります。
sps_home/secure-proxy/proxy-engine/conf
ファイルの内容は、以下のセクションにグループ化されます。
■
Server -- サーバ操作、フェデレーション ゲートウェイ操作、および SSL
の設定が記述されています。
■
Session Store -- セッション ストアを定義します。
■
Service Dispatcher -- 対象のグローバル サーバ パラメータの設定を定義
します。
■
Proxy and Redirect Services -- プロキシ サービスとリダイレクト サービ
スのクラスに対する接続プールとフィルタを指定します。
■
Session schemes -- セッション スキームを提議します。
■
User Agent -- ユーザ エージェントのタイプを指定します。
■
Virtual Host -- デフォルトの仮想ホストとその設定を特定します。
第 7 章： SPS サーバ設定を設定する 97
server.conf ファイルの変更
各セクションは、XML に似ているエレメント タグです。 セクションの名
前は XML エレメントの開始タグで、このセクションは対応する終了タグ
で終了します。 各セクションに記述されているディレクティブは、名=値
という形式になります。
# 記号で始まるすべての行はコメントで、CA SiteMinder for Secure Proxy
Server が設定を読み取る際に、読み取らることはありません。
注： Windows システム上のパス名は、¥¥logs¥¥server.log などのダブル円記
号（¥¥）を使用します
server.conf ファイルの変更
CA SiteMinder for Secure Proxy Server 用の設定は、以下のディレクトリに配
置される server.conf ファイルで保持されます。
sps_home/secure-proxy/proxy-engine/conf
server.conf ファイル内の設定を変更する方法
1. テキスト エディタでファイルを開きます。
2. 必要に応じて、ディレクティブを編集します。
3. SPS を再起動します。
設定が変更されます。
server.conf ファイル内の一般的なサーバ設定
server.conf ファイルの <Server> セクションには、サーバ コネクタ、フェデ
レーション、および SSL に関するパラメータが記述されています。これら
のパラメータは、この後のセクションに記述されています。
98 管理ガイド
server.conf ファイル内の一般的なサーバ設定
HTTP の接続パラメータ
# HTTP リスナとプロキシ エンジン間のリスナを定義します。
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.reply_timeout=0
worker.ajp13.retries=2
注： connector ディレクティブの値は、引用符に含みません。 他のタイプ
のディレクティブの値は、引用符で含みます。
名前/値のペアは次のとおりです。
worker.ajp13.port=8009
ajp13 コネクタのポートを指定します。
worker.ajp13.host=localhost
ローカル ホストとして、ローカル ajp13 ホストを指定します。
追加のチューニング パラメータは、HTTP リスナとプロキシ エンジンの間
の接続に対して定義できます。以下に例を示します。
worker.ajp13.reply_timeout
プロキシ エンジンから受信され、その後は HTTP リスナおよびプロキ
シ エンジンの接続が切断される、任意の 2 つのパケット間で経過でき
る最大時間（ミリ秒単位）を指定します。 値 0 は、応答を受信するま
で、無期限に待機状態になります。
デフォルト： 0
worker.ajp13.retries
ワーカが通信エラー状態のプロキシ エンジンにリクエストを送信す
る最大数を指定します。
デフォルト： 2
第 7 章： SPS サーバ設定を設定する 99
server.conf ファイル内の一般的なサーバ設定
server.conf ファイルの Tomcat 調整パラメータ
Tomcat サーバは SPS に組み込まれています。 Tomcat サーバには、サーブ
レット コンテナおよびサーブレット エンジンが備わっています。
以下は server.conf ファイルの Tomcat 調整セクションからの抜粋です。
# AJP13 調整パラメータの定義
# キューで待機しているリクエスト数（キューの長さ）
# 初期設定時に作成されるスレッド数
# 同時接続可能な最大数
worker.ajp13.accept_count=10
worker.ajp13.min_spare_threads=10
worker.ajp13.max_threads=400
worker.apj13.connection_pool_timeout=0
worker.apj13.max_packet_size=8192
100 管理ガイド
server.conf ファイル内の一般的なサーバ設定
Tomcat の調整ディレクティブを以下にリストします。
worker.ajp13.accept_count
スレッドを処理する実行可能なリクエストがすべて使用中の場合に、
キューで待機するリクエスト数を定義します。 キューがいっぱいのと
きに受信したリクエストはすべて拒否されます。
デフォルト： 10
worker.ajp13.min_spare_threads
新しいリクエストの到着を待機しているときのアイドル スレッドの
最小数を定義します。min_spare_threads は 0 より大きい必要がありま
す。
デフォルト： 10
worker.ajp13.max_threads
同時接続可能な最大数を定義します。プールはこのスレッド数より多
く作成することはありません。
デフォルト： 400
worker.apj13.connection_pool_timeout
タイムアウトになる前に、アイドル接続（mod-jk 経由の Apache と
Tomcat の間）を接続プールに残しておく最大時間（秒単位）を定義し
ます。 デフォルトはタイムアウトが発生しないことを示す 0 です。
デフォルト： 0
worker.ajp13.max_packet_size
最大のパケット サイズをバイト単位で定義します。最大値は 65536 で
す。
デフォルト： 8192
第 7 章： SPS サーバ設定を設定する 101
server.conf ファイル内の一般的なサーバ設定
Tomcat の複数のバージョンにおける Cookie 仕様の差を解消します
Tomcat バージョン 5.5 で Cookie 処理に関する動作が変更されました。
Tomcat バージョン 5.5 はデフォルトで、Cookie を引用符で囲みます。
Tomcat の以前のバージョンでは、Cookie を引用符で囲みませんでした。
Tomcat はブラウザに Cookie を送り返します。 CA SiteMinder for Secure
Proxy Server r12.0 SP 3 は Tomcat バージョン 5.5 を使用します。ご使用の展
開が SPS の以前のバージョンを参照しなければならない場合、Cookie はデ
コードできません。CA SiteMinder for Secure Proxy Server の以前のバージョ
ンでは、Tomcat バージョン 5.0 を使用していました。このバージョンでは
Cookie を引用符で囲みません。
Cookie の動作が SPS の複数のバージョン間で互換性を確保できるように
するため、server.conf ファイルで addquotestobrowsercookie パラメータを
"No" に設定します。 Tomcat
org.apache.catalina.STRICT_SERVLET_COMPLIANCE 変数を "TRUE" に設定され
ます。 Tomcat はサーブレットの指定に従って Cookie を解析します。つま
り、引用符は追加されないということです。 addquotestobrowsercookie パ
ラメータを "Yes" に設定すると、CA SiteMinder for Secure Proxy Server はデ
フォルトの Tomcat バージョン 5.5 の Cookie 動作を有効にします。
Cookie 内の等号の解析
Tomcat 5.5 以降では、Cookie に等号（=）が追加されます。CA SiteMinder for
Secure Proxy Server ではこの慣例を許可し、等号が含まれる Cookie 値を解
析します。 server.conf ファイル内の allowequalsincookievalue パラメータ用
のデフォルト値は Yes です。
パーサが等号に遭遇した場合に、Cookie 値の解析を終了するには、
allowequalsincookievalue パラメータを No に設定します。
102 管理ガイド
server.conf ファイル内の一般的なサーバ設定
server.conf ファイルのフェデレーション設定
server.conf ファイルのフェデレーション設定は、CA SiteMinder for Secure
Proxy Server が SiteMinder フェデレーション ネットワーク内のフェデレー
ション ゲートウェイとして動作できるようにします。
以下のコードは server.conf ファイルの <federation> セクションの抜粋で
す。
# ここでフェデレーションに関連するパラメータの値を指定します
#
# enablefederationgateway （「yes」または「no」） - SPS フェデレーション ゲートウェイの有
効化または無効化
# fedrootcontext - フェデレーション ルート コンテキストの名前（デフォルトでは
「affwebservices」）
# authurlcontext - 認証 URL のパス（jsp ファイル名なし）
（デフォルトでは siteminderagent/redirectjsp）
# protectedbackchannelservices - 保護されたバックチャネル サービスの名前
<federation>
enablefederationgateway="yes"
fedrootcontext="affwebservices"
authurlcontext="siteminderagent/redirectjsp"
protectedbackchannelservices="saml2artifactresolution,saml2certartifactre
solution,
saml2attributeservice,saml2certattributeservice,assertionretriever,certassert
ionretriever"
</federation>
フェデレーション パラメータは以下のとおりです。
enablefederationgateway
CA SiteMinder for Secure Proxy Server がフェデレーション ゲートウェイ
プロキシ サーバとして動作できるようにします。
制限： yes または no
このパラメータはインストール中に設定されます。
fedrootcontext
フェデレーション Web サービス アプリケーションのルート コンテキ
ストを指定します。 このパラメータを変更しないでください。
デフォルト： affwebservices
第 7 章： SPS サーバ設定を設定する 103
server.conf ファイル内の一般的なサーバ設定
authurlcontext
redirect.jsp ファイルのエイリアスを指定します。 ユーザが保護された
フェデレーション リソースを要求し、アサーションを作成するサイト
にその SiteMinder セッションがない場合、ユーザは redirect.jsp ファイ
ルを指すこの URL に送信されます。ユーザは認証の要求で表示される
作成サイトの Web エージェントにリダイレクトされ、ログインに成功
するとセッションが確立されます。
デフォルト： siteminderagent/redirectjsp.
protectedbackchannelservices
通信に安全なバック チャネルを必要とするサービスをリストします。
HttpClient のログ
httpclientlog パラメータを Yes に設定することにより、HttpLogging を有効
にできます。 このパラメータは、server.conf ファイルの <Server> セクショ
ンに配置されています。 デフォルトでは、このパラメータは No に設定さ
れます。
HttpClient はデバッグ用のみ有効にすることをお勧めします。 実稼働環境
でロギングを有効にすると、パフォーマンスの低下が発生することがあり
ます。
HttpClient ロギングの設定
httpclientlogging.properties ファイル内のパラメータに値を設定することに
より、HttpClient ロギングのさまざまな側面を設定できます。 このファイ
ルは sps_home¥Tomcat¥properties ディレクトリに格納されています。
重要： 性能低下が発生する可能性があるため、実稼働環境では、HttpClient
ロギングを有効にしないでください。
104 管理ガイド
server.conf ファイル内の一般的なサーバ設定
httpclientlogging.properties ファイルには、以下の設定パラメータがありま
す。
java.util.logging.FileHandler.formatter
説明: フォーマッタ クラスの名前を指定します。
制限：
java.util.logging.SimpleFormatter -- ログ レコードの概要を書き込み
ます
java.util.logging.XMLFormatter -- XML 形式で詳細な説明を書き込み
ます
デフォルト： java.util.logging.SimpleFormatter
java.util.logging.FileHandler.pattern
説明: HttpClient ログ ファイル名を指定します。
制限：
sps_home¥proxy-engine¥logs¥httpclient%g.log
%g は、ローテーションしたログ ファイルの世代番号を表します。
java.util.logging.FileHandler.count
説明： サイクル内の出力ファイルの数を指定します
デフォルト： 10
java.util.logging.FileHandler.limit
説明： 任意のログ ファイルに書き込まれた最大バイト数の近似値を指
定します。
制限： 0 に設定すると、制限はなくなります。
デフォルト： 5,000,000
第 7 章： SPS サーバ設定を設定する 105
server.conf ファイル内の一般的なサーバ設定
server.conf ファイル内の SSL 設定
server.conf ファイル内の <sslparams> セクションには、CA SiteMinder for
Secure Proxy Server と送信先サーバの間の Secure Sockets Layer （SSL）通信
を有効にするために必要な設定が記述されています。
SSL 設定セクションを以下に示します。
<sslparams>
# サポートする SSL プロトコルバージョンを設定します： SSLv3、TLSv1
# 注： SSL バージョン 2 は、サポート対象のバージョン ="SSLv3" でなくなりました。
ciphers="-RSA_With_Null_SHA,+RSA_With_Null_MD5,-RSA_With_RC4_SHA,+RSA_With_RC
4_MD5,+RSA_With_DES_CBC_SHA,+RSA_Export_With_RC4_40_MD5,-RSA_Export_With_DES_
40_CBC_SHA,+RSA_Export_With_RC2_40_CBC_MD5,-DH_RSA_With_DES_CBC_SHA,-DH_RSA_W
ith_3DES_EDE_CBC_SHA,-DH_RSA_Export_With_DES_40_CBC_SHA,-DH_DSS_With_DES_CBC_
SHA,-DH_DSS_Export_With_DES_40_CBC_SHA,-DH_Anon_With_RC4_MD5,-DH_Anon_With_DE
S_CBC_SHA,-DH_Anon_With_3DES_EDE_CBC_SHA,-DH_Anon_Export_With_DES_40_CBC_SHA,
-DH_Anon_Export_With_RC4_40_MD5,-DHE_RSA_With_DES_CBC_SHA,-DHE_RSA_Export_Wit
h_DES_40_CBC_SHA,-DHE_DSS_With_DES_CBC_SHA,-DHE_DSS_Export_With_DES_40_CBC_SH
A"
fipsciphers="+DHE_DSS_With_AES_256_CBC_SHA, +DHE_RSA_With_AES_256_CBC_SHA,
+RSA_With_AES_256_CBC_SHA, +DH_DSS_With_AES_256_CBC_SHA,
+DH_RSA_With_AES_256_CBC_SHA, +DHE_DSS_With_AES_128_CBC_SHA,
+DHE_RSA_With_AES_128_CBC_SHA, +RSA_With_AES_128_CBC_SHA,
+DH_DSS_With_AES_128_CBC_SHA, +DH_RSA_With_AES_128_CBC_SHA,
+DHE_DSS_With_3DES_EDE_CBC_SHA, +DHE_RSA_With_3DES_EDE_CBC_SHA,
+RSA_With_3DES_EDE_CBC_SHA, +DH_DSS_With_3DES_EDE_CBC_SHA"
# 変換する Covalent SSL CA 証明書バンドルおよび証明書パス
# 定義された場所に格納されたバンドルや証明書は、
# バイナリ（DER）形式に変換され、SSLParams としてロードされます。
# 注： Covalent 証明書ディレクトリには、Base64（PEM）でエンコードされた証明書ファイル/バ
ンドルだけを
# 格納してください。
cacertpath="<install-dir>¥SSL¥certs"
cacertfilename="<install-dir>¥SSL¥certs¥ca-bundle.cert"
# 以下で設定するこの証明書は、SSL クライアント認証が有効な場合、
# バックエンド サーバに対して SPS クライアント証明書として使用されます。
# キー ファイルの場所：<install-dir>¥SSL¥clientcert¥key¥
#パブリック証明書の場所： <install-dir>¥SSL¥clientcert¥certs¥
# 注： DER でエンコードされ、パスワードが暗号化された pkcs8 キー ファイルだけを格納してく
ださい。
# クライアント パス フレーズは EncryptUtil ツールを使用して暗号化する必要があります。
#ClientKeyFile=
#ClientPassPhrase=
106 管理ガイド
server.conf ファイル内の一般的なサーバ設定
</sslparams>
SSL パラメータには以下のパラメータがあります。
versions
SPS がサポートする SSL バージョンを決定します。 エントリは、以下
の 1 つの場合もあれば複数の場合もあります。
■
SSLv3
■
TLSv1
複数のバージョンを指定する場合は、カンマでバージョンを区切りま
す。
ciphers
有効または無効にできる暗号の一覧を指定します。 暗号が有効な場合、
リストの前に + 記号が付きます。暗号が無効な場合、リストの前に - 記
号が付きます。 複数の暗号を指定する場合は、各エントリをカンマで
区切ります。
cacertpath
信頼できる証明機関情報を格納するディレクトリ パスを指定します。
このパスは、SPS のインストール パスに対する相対パスになります。
CA SiteMinder for Secure Proxy Server のインストール中に設定ウィザー
ドを実行すると、この値が設定されます。この値は変更しないでくだ
さい。
cacertfilename
証明書の認証機関バンドルが含まれるファイルの完全修飾パス名を指
定します。このファイルは、.cer または .cert のファイル拡張子を持ち、
PEM でエンコードされている必要があります。 また、認証機関（CA）
バンドルへのフル パスを含む必要があります。 CA SiteMinder for
Secure Proxy Server のインストール中に設定ウィザードを実行すると、
この値が設定されます。
第 7 章： SPS サーバ設定を設定する 107
server.conf ファイル内の一般的なサーバ設定
ClientKeyFile
DER でエンコードされた CA SiteMinder for Secure Proxy Server クライア
ントの証明書キーのファイル名と、pkcs8 形式で暗号化されたパスワー
ドを指定します。 このファイルは、以下の場所に置かれていることを
確認します。
<CA SiteMinder for Secure Proxy Server インストール パス>/SSL/clientcert/key
ClientPassPhrase
EncryptUtil ツールを使用して、CA SiteMinder for Secure Proxy Server クラ
イアント証明書キー ファイルからキーを抽出するパスフレーズを指
定します。
maxcachetime
CA SiteMinder for Secure Proxy Server HTTPS クライアントが再使用する
ため、SSL セッション ID がキャッシュされる期間をミリ秒で指定しま
す。HTTPS 接続を介してファイルをリクエストすると、SSL ハンドシェ
イクが発生し、SSL セッション ID が作成されます。 この SSL セッショ
ン ID は、ユーザ セッションを識別するために、CA SiteMinder for Secure
Proxy Server およびバックエンド サーバが使用します。 ユーザの
HTTPS 接続が終了すると、CA SiteMinder for Secure Proxy Server はこの
パラメータによって指定された最大期間中、SSL セッション ID を
キャッシュします。
同じユーザがバックエンド サーバへの新しい HTTPS 接続をリクエス
トする場合、ユーザは応答を高速化するため、キャッシュされている
SSL セッション ID を送信できます。 この場合、ユーザが提供した SSL
セッション ID は、キャッシュされている SSL セッション ID と比較され
ます。 キャッシュの SSL セッション ID が使用可能な場合、新しい
HTTPS 接続の確立が高速化されます。
デフォルト： 120000 ミリ秒
注： SSL 通信を有効にする前に、SPS をインストールするために使用された
JDK のロケーションに Java Cryptography Extension （JCE） Unlimited Strength
Jurisdiction Policy ファイルがインストールされたことを確認します。
108 管理ガイド
server.conf ファイル内の一般的なサーバ設定
クライアント証明書認証
また、CA SiteMinder for Secure Proxy Server と Web サーバの間の安全な SSL
接続に対して、クライアント証明書認証を確立することもできます。 ク
ライアント証明書認証を有効にすると、CA SiteMinder for Secure Proxy
Server は、Web サーバのリソースをリクエストする場合に、自分自身を認
証するためにクライアント証明書を使用します。
前提条件
クライアント証明書認証を有効にするために CA SiteMinder for Secure
Proxy Server を設定する前に、以下のタスクが完了していることを確認し
ます。
■
ライアント証明書認証が、ユーザ リクエストの転送先の Web サーバ
で有効である。
■
クライアント証明書が、CA SiteMinder for Secure Proxy Server のインス
トール時にインストールされた openssl.exe ユーティリティを使って、
pkcs8 規格の CA SiteMinder for Secure Proxy Server に対して生成されて
いる。
■
既存のクライアント証明書を使用する場合は、pkcs8 DER 形式に変換さ
れている。
■
CA SiteMinder for Secure Proxy Server クライアント証明書のパブリック
証明書およびルート証明書が、
<SPS_Installation_Path>¥SSL¥Clientcert¥certs に格納されている。
■
設定済み Web サーバのパブリック証明書が、
<SPS_Installation_Path>¥SSL¥certs¥ca-bundle.cert に格納されている。
■
CA SiteMinder for Secure Proxy Server クライアント証明書のパブリック
証明書が、設定済み Web サーバの信頼できるストアに格納されている。
第 7 章： SPS サーバ設定を設定する 109
server.conf ファイル内の一般的なサーバ設定
クライアント証明書認証の有効化
クライアント証明書認証を有効にするために CA SiteMinder for Secure
Proxy Server を設定します。
次の手順に従ってください：
1. 以下の手順に従って、CA SiteMinder for Secure Proxy Server クライアン
ト証明書の秘密鍵のパスワードを暗号化します。
a. コマンド プロンプトを開きます。
b. <SPS_Installation_Path>¥SSL¥bin へ移動します。
c. 以下のコマンドを実行します。
Windows
EncryptUtil.bat <SPSCertificatePrivateKey_Password>
UNIX
EncryptUtil.sh <SPSCertificatePrivateKey_Password>
暗号化されたパスワードが表示されます。
2. sslparams セクションで以下の手順に従うことにより、server.conf ファ
イル内のクライアント証明書認証詳細を設定します。
a. CA SiteMinder for Secure Proxy Server クライアント証明書のキー
ファイル名を、ClientKeyFile に pkcs8 形式で入力します。
b. ClientPassPhrase の手順 1 で生成した、暗号化されたパスワードを
入力します。
クライアント証明書認証は、server.conf ファイルで設定されます。
3. 設定済み Web サーバへクライアント リクエストを転送するには、
proxyrules.xml ファイルを設定します。
4. SPS を再起動します。
クライアント証明書認証は、CA SiteMinder for Secure Proxy Server およ
び Web サーバの間で有効になります。
110 管理ガイド
server.conf ファイル内の一般的なサーバ設定
Cookie 内の特殊文字の設定
server.conf ファイルには、Cookie パラメータの値がゼロでない場合に、こ
の値を二重引用符で囲むという CA SiteMinder for Secure Proxy Server の慣
習を保持する、addquotestocookie パラメータが含まれています。 CA
SiteMinder for Secure Proxy Server が cookies の値をバックエンドに送信す
る前にその値を二重引用符で囲まないようにするには、addquotestocookie
の値を No に変更します。
server.conf ファイル内のエントリが以下のように表示されます。
<Server>
.
.
<sslparams>
.
.
</sslparams>
# このパラメータは。バックエンドで追加される cookie に適用できます。
# "yes"--- デフォルト値 Cookie バージョンが "0" 以外の場合、
#特殊文字を含む cookie パラメータの値に引用符が追加されます。
# "no" --- Cookie に引用符は追加されません。
addquotestocookie="yes"
</Server>
コード ヘッダの文字セットの選択
requestheadercharset パラメータの値を設定することで、適切なロケール
用の文字セットを指定できます。 HttpClient アプリケーションはこの値を
読み取って、バックエンド サーバに送信するヘッダをエンコードする方
法を決定します。 以下の値が使用可能です。
■
US-ASCII -- ロケールで英語（米国）を使用することを指定します。
■
Shift_JIS -- 日本語のユーザ名のサポートを含め、ロケールで日本語を使
用することを指定します。
デフォルトは requestheadercharset="US-ASCII" です。
第 7 章： SPS サーバ設定を設定する 111
server.conf ファイル内の一般的なサーバ設定
POST データのキャッシュ
次の 2 つのパラメータは、POST データのキャッシュを有効にし、キャッ
シュしたデータのサイズを設定するには、server.conf に記述されています。
enablecachepostdata
説明： CA SiteMinder for Secure Proxy Server が POST データをキャッ
シュするかどうかを指定します。
制限： はい、いいえ
デフォルト： Yes
maxcachedpostdata
説明： キャッシュする POST データのサイズ（KB）を指定します。
制限： なし
デフォルト： 1024 KB
SSL 例外の無視
バックエンド Web サーバが CA SiteMinder for Secure Proxy Server に切断通
知を返す場合、ユーザは CA SiteMinder for Secure Proxy Server を設定し、無
害な SSL 例外を無視することが可能です。 無害な SSL 例外を無視するには、
ignoresslbackendexception パラメータを yes に設定します。
112 管理ガイド
カスタム エラー ページのプロパティ
カスタム エラー ページのプロパティ
CA SiteMinder for Secure Proxy Server はカスタム エラー ページ機能をサ
ポートします。この機能を使用すると、クライアント リクエストが失敗
した場合に Web サーバが表示するエラー ページをカスタマイズできます。
カスタム エラー ページ セクションには、以下の形式があります。
<customerrorpages>
# 有効な値： "Yes" または "No"
# デフォルト値は "No" です。
enable="no|yes"
# カスタム エラー ページの実装クラス
class="com.netegrity.proxy.errorpages.ErrorPageImpl"
# ロケールのタイプを定義します。
# 有効な値：「0」（サーバ固有）、「1」（ブラウザ固有）
# デフォルト値は「0」です。
locale_type="0|1"
# この値は、java が認識する言語コードでなければなりません。
# ロケール オブジェクト。中国語の場合は "zh"、フランス語の場合は "fr"、スペイン語の場合は "es"、
# 英語の場合は "en" など
# デフォルト値は "en" です。
locale_language="en"
# この値は、java ロケール オブジェクトが認識する国/地域コードである必要があります。
# 中国の場合は "CN"、スイスの場合は "CH"、アルゼンチンの場合は "AR"、
# 米国の場合は "US" です。
# デフォルト値は "US" です。
locale_country="US"
# 例外の完全なコール スタックを表示します。
# 有効な値： "true" または "false"
# デフォルト値： "false"
showcallstack="true"
</customerrorpages>
no|yes
CA SiteMinder for Secure Proxy Server Web サーバのエラー ページを管
理する方法を指定します。 値を Yes に設定すると、Web サーバのエ
ラー ページをカスタマイズできます。クライアント リクエストが失敗
した場合、Web サーバは、はカスタマイズされたエラー ページを表示
します。 値を No に設定すると、クライアント リクエストが失敗した
場合、Web サーバはデフォルトの HTTP 1.1 エラー ページを表示します。
CA SiteMinder for Secure Proxy Server は起動時に値を読み取ります。
デフォルト： no
0|1
第 7 章： SPS サーバ設定を設定する 113
カスタム エラー ページのプロパティ
カスタム エラー ページのロケールを指定します。 値を 0 に設定する
と、CA SiteMinder for Secure Proxy Server は CA SiteMinder for Secure
Proxy Server サーバのロケール設定を使って、カスタム エラー メッ
セージを表示します。 値を 1 に設定すると、CA SiteMinder for Secure
Proxy Server はブラウザのロケール設定を使って、カスタム エラー
メッセージを表示します。
デフォルト： 0
showcallstack
デバッグ対象の例外を追跡するため、コール スタックを取得する必要
があるかどうかを指定します。 値を True に設定すると、CA SiteMinder
for Secure Proxy Server はコール スタックを取得し、カスタム エラー
ページに表示します。 値を False に設定すると、コール スタックは表
示されません。
デフォルト：: false
重要： セキュリティ上の理由から、デバッグ対象の例外の詳細を追跡
することを望まない限り、showcallstack オプションを有効にしないこ
とを強く推奨します。 デバッグを終了後、showcallstack を無効にしま
す。
カスタム エラー メッセージの有効化
クライアント リクエストが失敗した場合に、Web サーバがカスタマイズ
されたエラー ページを表示する機能と、メッセージまたはエラー コード
をカスタマイズする機能を有効にします。 デフォルトでは、CA SiteMinder
for Secure Proxy Server は HTTP 1.1 エラー コードをすべてサポートします。
次の手順に従ってください：
1. server.conf ファイルを開きます。
2. customerrorpages セクションに移動します。
3. 次のコマンドを設定します。
enable="yes"
4. 変更を保存します。
5. CA SiteMinder for Secure Proxy Server サーバを再起動します。
114 管理ガイド
カスタム エラー ページのプロパティ
デフォルトのカスタム エラー ページ
CA SiteMinder for Secure Proxy Server はデフォルトで、CA SiteMinder for
Secure Proxy Server および Web サーバから受信する可能性があるリクエス
ト エラーのリストを提供します。 SPSErrorMessages.properties および
WebServerErrorMessages.properties ファイルのエラー メッセージは以下の
形式になります。
exception|error code=error message|URL
説明
exception|error code
ユーザ リクエストが失敗した場合に CA SiteMinder for Secure Proxy
Server または Web サーバが返す例外またはエラー コードを定義しま
す。
上限： 100 文字
error message|URL
例外またはエラー コードが返された場合、CA SiteMinder for Secure
Proxy Server または Web サーバが表示するエラー メッセージを定義し
ます。 プレーン テキストのエラー メッセージ、またはユーザが使用
するターゲット URL のいずれかを指定できます。
上限： 4096 文字
第 7 章： SPS サーバ設定を設定する 115
カスタム エラー ページのプロパティ
デフォルトの CA SiteMinder for Secure Proxy Server エラー ページ
CA SiteMinder for Secure Proxy Server サーバの不適切な設定が原因でユー
ザ リクエストが失敗した場合、CA SiteMinder for Secure Proxy Server はデ
フォルトでエラー ページを表示します。 各エラー ページは、エラー コー
ドにマッピングされます。 ユーザ リクエストが失敗した場合、CA
SiteMinder for Secure Proxy Server はエラー コードを確認し、対応するエ
ラー ページを表示します。
次の表に、CA SiteMinder for Secure Proxy Server サーバの不適切な設定が原
因で CA SiteMinder for Secure Proxy Server が表示するデフォルト エラーの
リストを示します。
エラー コード
エラー メッセージの内容
VirtualHostNotFound
仮想ホストが正しく設定されていません。
server.conf ファイル内の仮想ホスト設定を確
認してください
SessionSchemeNotFound
定義されたセッション スキームが見つかりま
せん。 server.conf ファイル内のセッション ス
キーム設定を確認してください
SessionCreateError
作成中にセッション ストアが破損した可能性
があります。 SPS を再起動してください
SessionUpdateError
更新中にセッション ストアが破損した可能性
があります。 SPS を再起動してください
WebAgentException
CA SiteMinder for Secure Proxy Server が Web
エージェントと通信していない可能性があり
ます。詳細については、CA SiteMinder for Secure
Proxy Server ログを参照してください
Noodle_GenericException
ヌードル段階でリクエストの処理中にエラー
が発生した可能性があります。 詳細について
は、CA SiteMinder for Secure Proxy Server ログを
参照してください
Noodle_FilterException
ヌードルでフィルタの事前/事後処理中にエ
ラーが発生した可能性があります。
Noodle_UnknownHostException
ターゲット ホストの IP アドレスを特定できま
せんでした
116 管理ガイド
カスタム エラー ページのプロパティ
エラー コード
エラー メッセージの内容
Noodle_ConnectException
ソケットをリモート アドレスおよびポートに
接続しようとしてエラーが発生した可能性が
あります
Noodle_NoRouteHostException
ファイアウォールが関与したか、または中間
ルータが使用可能でないため、ソケットをリ
モート アドレスおよびポートに接続しようと
してエラーが発生した可能性があります
Noodle_InteruptedIOException
転送を実行中のスレッドが中断されたため、送
受信が終了しました
Noodle_SocketException
基礎となるプロトコルでエラーが発生しまし
た
Noodle_NoSuchMethodException
CA SiteMinder for Secure Proxy Server でメソッ
ドがサポートされていません
Noodle_ProxytoProxyNotSupported
CA SiteMinder for Secure Proxy Server はプロキ
シ Web サーバをサポートしません
Noodle_CouldNotConnectToBackEndServer
SPS での処理スレッド不足のため、バックエン
ド Web サーバに接続できませんでした
Noodle_NoAvailableConnections
リクエストに対応可能な接続がありません。
Redirect_NoTargetURLParameter
リダイレクト中に URL が指定されませんでし
た
FedRequest_Redirect_ImproperURL
リダイレクト URL が指定されていないか、形式
が間違っています。 クライアント リクエスト
内の RelayState またはフェデレーション設定
を確認してください
FedRequest_Redirect_RewriteLocationHeaderFail
ure
フェデレーション リクエストの処理中に、
セッション キーを保持するメモリのクラッ
シュが発生した可能性があるため、リダイレク
ト セッションを作成できません
FedRequest_CookieProcessingError
フェデレーション リクエストの処理中に
Cookie を作成できません
FedRequest_ResponseProcess_AddSessionError
フェデレーション リクエストの処理中に、
セッションの追加でエラーが発生しました。
セッション キーを保持するメモリのクラッ
シュが発生した可能性があります
第 7 章： SPS サーバ設定を設定する 117
カスタム エラー ページのプロパティ
エラー コード
エラー メッセージの内容
FedRequest_ResponseProcess_LocHeaderModifyE フェデレーション リクエストの処理中に、ロ
rror
ケーション ヘッダの更新でエラーが発生しま
した。セッション キーを保持するメモリのク
ラッシュが発生した可能性があります
リクエスト処理中にエラーが発生しました。
詳細については、CA SiteMinder for Secure Proxy
Server ログを参照してください
SPSException
CA SiteMinder for Secure Proxy Server エラー ページの変更
CA SiteMinder for Secure Proxy Server エラー ページのエラー メッセージを
変更できます。
次の手順に従ってください：
1. SPSErrorMessages.properties ファイルを開きます。
デフォルト パス： <SPS_installation_folder>¥Tomcat¥properties¥
2. 変更するエラー レコードに移動します。
3. 必要な変更を行います。
4. 変更を保存します。
デフォルトの Web サーバ エラー ページ
CA SiteMinder for Secure Proxy Server はデフォルトで、すべての HTTP 1.1 エ
ラーをサポートします。クライアント リクエストが失敗すると、Web サー
バはデフォルトの HTTP 1.1 エラー ページを表示します。 カスタム エラー
ページ機能を有効にすると、エラー ページをカスタマイズすることがで
きます。クライアント リクエストが失敗すると、Web サーバはカスタマ
イズされたエラー詳細を表示します。 各エラー ページは、エラー コード
にマッピングされます。
この機能を有効にし、エラー ページをカスタマイズすると、エラーが発
生した際に、Web サーバはカスタマイズされたエラー ページを表示しま
す。この機能を有効にし、エラー ページをカスタマイズしなかった場合、
エラーが発生した際に、Web サーバによって返されたデフォルトのエラー
ページが表示されます。
118 管理ガイド
server.conf File でのセッション ストア設定
Web サーバ エラー ページの変更
Web サーバ エラー ページのエラー コードまたはエラー メッセージの追
加、変更、削除ができます。 エラー コードのエラー メッセージを削除す
ると、CA SiteMinder for Secure Proxy Server は以下のメッセージが表示され
たページを表示します。
表示するカスタム メッセージはありません。 ログで詳細情報を検索します。
次の手順に従ってください：
1. WebServerErrorMessages.properties ファイルを開きます。
デフォルト パス： <SPS_installation_folder>¥Tomcat¥properties¥
2. 変更するエラー レコードに移動します。
3. 必要な変更を行います。
4. 変更を保存します。
server.conf File でのセッション ストア設定
server.conf ファイルの <SessionStore> セクションでは、ユーザ セッション
の格納に関する設定を指定します。 セッション ストア設定の形式は以下
のとおりです。
<SessionStore>
# セッション ストア情報
class="com.netegrity.proxy.session.SimpleSessionStore"
max_size="10000"
clean_up_frequency="60"
</SessionStore>
SessionStore のパラメータは以下のとおりです。
class
実装でユーザ セッションが維持されていたことを示します。この値は
変更しないでください。
デフォルト： com.netegrity.proxy.session.SimpleSessionStore
max_size
セッション ストアの最大サイズを指定します。 指定した数値は、イン
メモリ セッション ストアの同時セッションの最大数です。
デフォルト： 10000
第 7 章： SPS サーバ設定を設定する 119
server.conf ファイル内のサービス ディスパッチャ設定
clean_up_frequency
CA SiteMinder for Secure Proxy Server がセッション ストア キャッシュ
内にある期限切れセッションを消去する前に待機する間隔を秒単位で
設定します。
注： セッション タイムアウトが長いと、サーバで暗号化および復号化され
るセッション Cookie の数を減らすことができますが、キャッシュ内に維
持されるセッションの合計数は増加します。 まれに接続するユーザがい
る場合は、キャッシュ時間を短く、キャッシュ サイズを小さく指定しま
す。 ただし、サイトに頻繁にアクセスする多くのユーザがいる場合は、
より長いキャッシュ時間と、より大きいキャッシュ サイズを使用します。
server.conf ファイル内のサービス ディスパッチャ設定
<ServiceDispatcher> セクションでは、CA SiteMinder for Secure Proxy Server
がプロキシ サービスを提供する方法を決定します。 また、プロキシ ルー
ル XML 設定ファイルの場所も指定します。
注： このパラメータはグローバル サーバ設定パラメータで、個別の仮想ホ
ストごとには設定されません。
<ServiceDispatcher> セクションは以下のようにリストされます。
#
#
#
#
サービス ディスパッチャ
これは Proxy 6.0 以降の新しい設定です。
サービス ディスパッチャはグローバル サーバ設定パラメータになりました。
もう仮想ホスト単位で設定する必要はありません。
<ServiceDispatcher>
class="com.netegrity.proxy.service.SmProxyRules" rules_file=
"C:¥Program Files¥CA¥secure-proxy¥proxy-engine¥conf¥proxyrules.xml"
</ServiceDispatcher>
120 管理ガイド
server.conf ファイル内のプロキシおよびリダイレクトの設定
このセクション内のパラメータは次のとおりです。
class
ユーザ リクエストにルーティングする CA SiteMinder for Secure Proxy
Server によって使用されるサービス ディスパッチャを指定します。デ
フォルト値を変更しないでください。
デフォルト： com.netegrity.proxy.service.SmProxyRules
rules_file
proxyrules.xml の場所を指定します。 file
デフォルト： sps_home/secure-proxy/proxy-engine/conf/proxyrules.xml
server.conf ファイル内のプロキシおよびリダイレクトの設定
server.conf ファイルの <Service> セクションはプロキシ サービスおよびリ
ダイレクト サービスから構成されます。
CA SiteMinder for Secure Proxy Server には事前定義済みの 2 つのプロキシ
サービスがあります。
■
forward
■
redirect
これらのサービスはそれぞれ、<Service name> エレメントによって定義さ
れるセクションをファイル内に持っています。 カスタム サービスは、管
理者によって設定されるパラメータを含めて、server.conf ファイルで同様
に定義されます。
プロキシ サービス設定
CA SiteMinder for Secure Proxy Server の転送サービスは、プロキシ ルール
XML 設定ファイル内の条件およびケースに従って適切な送信先サーバへ
のリクエストを転送します。 このサービスのパラメータは、server.conf
ファイルの <Service name="forward"> で定義されています。
ディレクティブの多くは、SPS によって維持される接続プールを管理しま
す。 これらのディレクティブは、接続の維持および送信先サーバへの各
リクエストの新しい接続を確立するオーバーヘッドの緩和により、サーバ
のパフォーマンスの向上を支援します。
第 7 章： SPS サーバ設定を設定する 121
server.conf ファイル内のプロキシおよびリダイレクトの設定
追加のディレクティブはプロキシ フィルタを定義します。 プロキシ フィ
ルタはリクエストが送信先サーバに渡される前、および送信先サーバが
SPS にデータを返した後に、処理タスクを実行するためにここで定義でき
ます。 フィルタ名は一意です。
以下は <Service name="forward"> セクションの抜粋です。
注： 抜粋には、実際の server.conf ファイルを見たときにあるようなコメン
トの大半が含まれません。
# プロキシ サービス
<Service name="forward">
class="org.tigris.noodle.Noodle"
protocol.multiple="true"
http_connection_pool_min_size"2"
http_connection_pool_max_size="420"
http_connection_pool_incremental_factor="2"
http_connection_pool_connection_timeout="1"
http_connection_pool_wait_timeout="0"
http_connection_pool_max_attempts="3"
http_connection_timeout="3 minutes"
http_connection_stalecheck="true"
# プロキシ フィルタは前処理/後処理タスクを実行するために、ここで定義される可能性があります。
# フィルタを設定するには、以下の形式を使用する必要があります。
#
#
#
#
filter.<filter
filter.<filter
filter.<filter
filter.<filter
name>.class=<fully qualified filter class name> (required)
name>.init-param.<param name1>=<param value1> (optional)
name>.init-param.<param name2>=<param value2>
name>.init-param.<param name3>=<param value3>
# 以下の例は、グループ内のカスタム フィルタの使用を示しています
# 有効なカスタム フィルタ名のあるフィルタ グループを定義します。
#groupfilter.group1="filter1,filter2"
</Service>
122 管理ガイド
server.conf ファイル内のプロキシおよびリダイレクトの設定
転送セクション内のパラメータは次のとおりです。
class
SPS 用の転送サービスを提供する実装を指定します。 この値は変更し
ないでください。この値は、カスタム サービスがプロキシ ルール XML
設定ファイルで指定されたリクエストを転送できるといった、まれな
状況に対応する場合にのみ露出することになります。
デフォルト： org.tigris.noodle.Noodle
protocol.multiple
CA SiteMinder for Secure Proxy Server が HTTP 以外のプロトコルをサ
ポートするかどうかを示します。 以下のいずれかの値を指定します。
true
HTTP 以外のプロトコルがサポートされていることを示します。 現
在、HTTPS のみが SPS で追加のプロトコルとしてサポートされてい
ます。 True はこのディレクティブのデフォルト値です。
false
HTTP プロトコルのみがサポートされていることを示します。
http_connection_pool_min_size
ユーザ リクエストの処理に使用可能な単一の送信先サーバへの、最低
限の接続回数を設定します。
デフォルト： 2
http_connection_pool_max_size
CA SiteMinder for Secure Proxy Server と送信先サーバとの間の接続の最
大数を設定します。
デフォルト： 420
重要： CA SiteMinder for Secure Proxy Server によって確立された接続は
それぞれソケットを作成します。 UNIX オペレーティング システムに
対して、接続プールの最大サイズが大きい場合、多数のソケットに対
応するためにファイル記述子の制限を上げることができます。
http_connection_pool_incremental_factor
使用可能な接続がすべてリクエストを処理するために使用されている
場合に CA SiteMinder for Secure Proxy Server が開く送信先サーバに接続
の数を設定します。
デフォルト： 2
第 7 章： SPS サーバ設定を設定する 123
server.conf ファイル内のプロキシおよびリダイレクトの設定
http_connection_pool_connection_timeout_unit
タイムアウト単位を秒または分に設定します。
デフォルト： 分
http_connection_pool_connection_timeout
接続プール内のアイドル接続を閉じる前にシステムが待機する時間を
分で定義します。
デフォルト： 1
http_connection_pool_wait_timeout
使用可能な接続を CA SiteMinder for Secure Proxy Server が待機する時間
をミリ秒で定義します。
デフォルト： 0
デフォルトの 0 は、通知されるまで CA SiteMinder for Secure Proxy
Server が接続を待ち、http_connection_pool_max_attempts の使用を無効
にすることを指定します。
http_connection_pool_max_attempts
システムが接続の取得を試行する回数を示します。 待機タイムアウト
がゼロでない場合のみ、このディレクティブは適用可能です。
デフォルト： 3
以下のいずれかの値を指定します。
0
CA SiteMinder for Secure Proxy Server が無期限に試みることを示し
ます。
3
CA SiteMinder for Secure Proxy Server が 3 つの試みを行うことを示
します。
124 管理ガイド
server.conf ファイル内のプロキシおよびリダイレクトの設定
http_connection_timeout
ホスト名の翻訳、およびソケットを作成する場合にバックエンド サー
バとの接続を確立するために費やされる時間をミリ秒で定義します。
デフォルト： 3 分
注
■
このタイムアウトは接続プールではなく HTTP 接続を明示的に参
照します。
■
CA SiteMinder for Secure Proxy Server の開始中に
SmSpsProxyEngine.properties ファイル内の
-Dhttp_connection_timeout パラメータを設定した場合、
-Dhttp_connection_timeout の値は http_connection_timeout の値よ
り優先されます。
http_connection_stalecheck
古くなった接続確認を実行する必要があるかどうかを指定します。
ユーザが値を true に設定した場合、各リクエストの実行の前に古く
なった接続確認が実行されます。 ユーザが値を false に設定した場合、
ユーザがバックエンド Web サーバで閉じられる接続でリクエストを
実行する場合、I/O エラーが表示される可能性があります。
デフォルト： true
filter.filter name.class= 完全修飾フィルタ クラス名
プロキシ ルールで呼び出される各一意のフィルタの server.conf ファ
イルで設定されたフィルタを指定します。
例： filter.PreProcess.class=SampleFilter
filter.filter name.init-param.param name1=param value1
フィルタが Filter API を使用して、どのように定義されるかに基づいて
フィルタ用の初期化パラメータを指定します。 server.conf ファイルを
設定し、各フィルタのパラメータを定義します。
例： filter.PreProcess.init-param.param1=value1
第 7 章： SPS サーバ設定を設定する 125
server.conf ファイル内のプロキシおよびリダイレクトの設定
groupfilter.<groupname> = “filtername1,filtername2,…….filtername"
指定されたプロキシ ルール用の 1 つ以上のフィルタを実装するため
にフィルタ グループを指定します。 CA SiteMinder for Secure Proxy
Server は、グループ フィルタで公言されたフィルタ名を読み取り、
チェーン内のフィルタを処理します。groupfilter 名は、proxyrules.xml で
フィルタ名として同様に使用できます。 CA SiteMinder for Secure Proxy
Server がグループ フィルタを処理する場合、groupfilter で定義されて
いる指示が逆でも、プリ フィルタはポスト フィルタの前に処理されま
す。以下の制限が適用可能です。
■
フィルタ名は有効で一意である必要があります。
■
グループ フィルタ名は一意である必要があります。 ユーザが複数
のグループに対して同じグループ名を与える場合、最後のグルー
プのみが残ります。
■
グループ フィルタ名およびフィルタ名は異なる必要があります。
例：
groupfilter.BatchProcess="SampleFilter1, SampleFilter2, SampleFilter3"
接続プールに関する推奨事項
接続プールは CA SiteMinder for Secure Proxy Server パフォーマンス管理の
重要な部分です。CA SiteMinder for Secure Proxy Server が企業で可能な最大
限のサービスを提供するには、送り先サーバが、接続に対してキープアラ
イブ メッセージを有効にして設定されている必要があります。 送信先
サーバに対してキープアライブ メッセージを有効にすると、CA SiteMinder
for Secure Proxy Server で接続プール機能を使用できます。
キープアライブ メッセージは Web サーバのタイプごとに異なる方法で管
理されます。
126 管理ガイド
server.conf ファイル内のプロキシおよびリダイレクトの設定
キープアライブ メッセージを有効にすることに加えて、送信先サーバお
よび SPS では以下の設定が推奨されます。 次の表に、タイムアウトおよび
接続プールに関する推奨事項を示します。
設定
HTTP
HTTPS
送信先サーバのキープアライブ最大リク
エスト数
無制限
無制限
送信先サーバ タイムアウト
タイムアウトしない
HTTP 接続プール タイム
アウトに等しいかそれよ
り大きい
Secure Proxy Server HTTP 接続プール タイ
ムアウト単位
秒または分に設定。デ
フォルトは分。
秒または分に設定。デ
フォルトは分。
1分
1分
0
0
通知されるまで待機
通知されるまで待機
3
3
（http_connection_pool_max_attempts）
（http_connection_pool_connection_timeo
ut_unit）
Secure Proxy Server HTTP 接続プール タイ
ムアウト
（http_connection_pool_connection_timeo
ut）
Secure Proxy Server HTTP 接続プール待機
タイムアウト
（http_connection_pool_wait_timeout）
Secure Proxy Server HTTP 接続プール最大
試行数
（http_connection_pool_max_attempts）
Secure Proxy Server HTTP 接続タイムアウ
ト
この値は HTTP 接続プー この値は HTTP 接続プー
ル タイムアウトが 0 より ル タイムアウトが 0 より
大きい場合に限り有用
大きい場合に限り有用
3分
3分
（http_connection_timeout）
第 7 章： SPS サーバ設定を設定する 127
server.conf ファイル内のプロキシおよびリダイレクトの設定
リダイレクト サービス設定
CA SiteMinder for Secure Proxy Server のリダイレクト サービスは送信先
サーバにリクエストを送信します。 転送サービスとは異なり、SPS ではな
く送信先サーバが以降のリクエストを処理します。
リダイレクト サービスの形式は、以下のとおりです。
<Service name="redirect">
class=com.netegrity.proxy.service.RedirectService
</Service>
ディレクティブは次のとおりです。
class
リダイレクトされたリクエストを処理する実装を示します。 このディ
レクティブは変更できません。
デフォルト： com.netegrity.proxy.service.RedirectService
128 管理ガイド
server.conf ファイル内のプロキシおよびリダイレクトの設定
接続指向の接続プール設定
Web サーバが接続指向の認証方式を使用している場合、セキュアな転送リ
クエスト処理を実現するため、接続指向の接続プールを設定します。
重要： 接続指向の接続プールは設定しないことを強くお勧めします。
次の手順に従ってください：
1. JK 環境変数 REMOTE_PORT の値が httpd.conf ファイルで設定されるこ
とを確認します。
2. server.conf を開き、<Service name="forward"> セクションに以下の行を
追加します。
# 接続指向認証バックエンドのプール設定
# 接続例： NTLM
<connection-pool name="connection oriented authentication">
connection-timeout="connection_timeout_value"
max-size="maximum_connections"
enabled="yes|no"
</connection-pool>
connection_timeout_value
接続タイムアウトが発生するまでの時間を秒で定義します。 この
値を低い値に設定することをお勧めします。
デフォルト： 5
maximum_connections
接続プール内の接続数を定義します。
デフォルト： 50
yes|no
接続指向の接続プールのステータスを指定します。 接続指向の接
続プールを有効にするには、値を yes に設定します。
デフォルト： yes
3. proxyrules.xml を開き、転送ルールに connection-auth 属性を追加します。
例： <nete:forward connection-auth="yes">hostname:port$1</nete:forward>
第 7 章： SPS サーバ設定を設定する 129
server.conf ファイル内のセッション スキームの設定
server.conf ファイル内のセッション スキームの設定
セッション スキームは、セッション中常にシングル サインオンを提供し
て、ユーザの ID の保持方法を決定します。 潜在的な各セッション スキー
ムを、server.conf ファイルの SessionScheme セクションに 記述する必要が
あります。 セッション スキームは、セッションの動作を定義する Java ク
ラス ファイルに関連付ける必要があります。 特定のタイプのユーザ エー
ジェントに対してセッション スキームが指定されていない場合、デフォ
ルトのセッション スキームが使用されます。
企業のトランザクションの課題の 1 つは、ユーザ セッションの保持です。
SiteMinder は、セッション情報をカプセル化するために Cookie を使用しま
す。 SiteMinder とは異なり、CA SiteMinder for Secure Proxy Server は複数の
方法を使用し、Cookie に依存しない一連の API を提供し、セッションを保
持する代替メソッドをサポートします。 Cookie を使用しないセッション
スキームでは、インメモリ セッション-ストア内で CA SiteMinder for Secure
Proxy Server が保持するセッション情報を参照する、ある種のトークンが
使われます。 セッション ストアは CA SiteMinder for Secure Proxy Server
サーバのメモリ内に存在し、サーバの再起動によってクリアできます。
CA SiteMinder for Secure Proxy Server は、server.conf ファイルで設定でき、
すぐに使用可能な以下のセッション スキームを提供します。 これらのス
キームは、server.conf ファイルで定義されている仮想ホストごとに、ユー
ザ エージェント タイプに関連付けることができます。 ユーザ エージェン
ト タイプとのセッション スキームの関連付けは、セッション スキーム
マッピングと呼ばれます。
CA SiteMinder for Secure Proxy Server には以下のスキームが含まれます。
130 管理ガイド
■
デフォルト スキーム
■
SSL ID
■
IP アドレス
server.conf ファイル内のセッション スキームの設定
■
ミニ Cookie
■
シンプル URL リライティング
■
デバイス ID
ノート
■
追加のカスタム セッション スキームを作成するには、セッション ス
キーム API を使用できます。 セッション スキーム API を使って独自の
セッション スキームを作成する場合は、カスタム セッション スキー
ムに関連付けられた名前および Java クラスに関する固有情報が保存
された server.conf ファイルに <SessionScheme> セクションを追加する
必要があります。
■
makefile.cygwin を使用してカスタム セッション スキームを作成する
場合は、cygwin のガイドラインに従って、JAVA_HOME と SPS_HOME の
値を設定します。 たとえば、Windows 2008 R2 コンピュータで
makefile.cygwin を使用する場合は、以下の値を設定できます。
JAVA_HOME=C:/Progra~2/Java/jdk1.7.0_03
SPS_HOME=C:/Progra~2/CA/secure-proxy
第 7 章： SPS サーバ設定を設定する 131
server.conf ファイル内のセッション スキームの設定
ユーザ セッションの確立
以下に示すように、ユーザ セッションを確立するための個別の段階があ
ります。
1. 検出段階
セッションのこの段階に、CA SiteMinder for Secure Proxy Server はユー
ザ エージェント タイプに基づいて適切なセッション キーを探します。
セッション キーは、SiteMinder Cookie または CA SiteMinder for Secure
Proxy Server メモリ内セッション ストアの適切な情報を指している
トークンのいずれかです。 前に述べられたように、トークンはミニ
Cookie、SSL ID、デバイス ID または他のトークンのフォームにできます。
セッション キーを識別できない場合、CA SiteMinder for Secure Proxy
Server の Web エージェントが、認証および許可を求めるリクエストを
引き継ぎ、転送し、ユーザの ID および資格を確立します。
2. エージェントの処理段階
CA SiteMinder for Secure Proxy Server には、SiteMinder と通信する Web
エージェントが含まれます。 Web エージェントは、SiteMinder セッ
ション情報の復号化および SiteMinder によるセッションの検証を実行
します。ユーザのリクエストが SMSESSION Cookie を伴うか、または CA
SiteMinder for Secure Proxy Server がセッション ストアにユーザのセッ
ションを配置している場合、Web エージェントは SiteMinder でユーザ
のリクエストを検証します。
3. リバース プロキシ段階
この段階で、ユーザのセッションが検証された後に、CA SiteMinder for
Secure Proxy Server はユーザのリクエストを処理するためにその定義
されたサービス（転送、リダイレクト、または別のサービス）の 1 つ
を使用します。 この段階の CA SiteMinder for Secure Proxy Server のアク
ションは、プロキシ ルール XML 設定ファイルに含まれているプロキシ
ルールによって決定されます。
注： セッション スキームを書き換える URL の場合、コンテンツはユー
ザに返送される前に、この段階の書き換えメカニズムに転送されます。
132 管理ガイド
server.conf ファイル内のセッション スキームの設定
デフォルト セッション スキーム
デフォルト セッション スキームは、ユーザ エージェント タイプに他のス
キームが指定されていない場合に、ユーザ セッションを確立および管理
するために CA SiteMinder for Secure Proxy Server が使用するスキームです。
<SessionScheme> エレメントには名前属性が含まれます。これはユーザ
エージェント タイプにスキームを割り当てる際に、セッション スキーム
を特定するために使用されます。 server.conf ファイルには、デフォルト
セッション スキーム設定を含める必要があります。
デフォルト セッション スキームを設定して、利用可能な任意のセッショ
ン スキームを使用できます。
デフォルト セッション スキーム セクションには以下の形式があります。
#Session Schemes
<SessionScheme name="default">
class="com.netegrity.proxy.session.SessionCookieScheme"
accepts_smsession_cookies="true"
</SessionScheme>
第 7 章： SPS サーバ設定を設定する 133
server.conf ファイル内のセッション スキームの設定
<SessionScheme> エレメントには以下のディレクティブがあります。
class
デフォルト セッション スキームを含む Java クラスを示します。
デフォルト： com.netegrity.proxy.session.SSLIdSessionScheme
accepts_smsession_cookies
SiteMinder Cookie セッション スキームとユーザ エージェント タイプ
を関連付ける場合、そのユーザ エージェント タイプを介してリソース
にアクセスするユーザが、従来の SiteMinder Cookie を使用してセッ
ションを管理することを示します。
SiteMinder は Cookie を使用してセッションを追跡するため、Cookie ス
キームは SPS によってサポートされます。 SMSESSION Cookie が承諾さ
れるかどうかを示します。
以下のいずれかの値を指定します。
true
SMSESSION Cookie がセッション スキームによって承諾および使用
されることを示します。
false
SMSESSION Cookie がセッション スキームによってサポートされな
いことを示します。
134 管理ガイド
server.conf ファイル内のセッション スキームの設定
デフォルト セッション スキームを指定する
他のセッション スキームがユーザ エージェント タイプに対して指定され
ていない場合、デフォルトのセッション スキームが使用されます。
デフォルトのセッション スキーム ディレクティブを以下に示します。
defaultsessionscheme
SiteMinder Cookie セッション スキーム以外のセッション スキームを
デフォルト スキームとして指定します。 このエントリを変更して、任
意のセッション スキームをデフォルトのセッション スキームとして
含めることができます。
デフォルト： デフォルト
enablewritecookiepath
プロキシの後ろに存在するサーバによって設定される URI から初期リ
クエストの URI に、Cookie パスを書き換えるように CA SiteMinder for
Secure Proxy Server に指示します。
デフォルト： no
enablewritecookiedomain
プロキシの後ろに存在するサーバによって設定されたドメインから初
期リクエストのドメインに、Cookie ドメインを書き換えるように CA
SiteMinder for Secure Proxy Server に指示します。
デフォルト： no
第 7 章： SPS サーバ設定を設定する 135
server.conf ファイル内のセッション スキームの設定
SSL ID セッション スキーム
SSL （Secure Sockets Layer）接続には、SSL 接続が開始される際に作成され
る一意の識別子が含まれます。CA SiteMinder for Secure Proxy Server メモリ
内セッション ストアで管理されるユーザ用のセッション情報を参照する
ために、CA SiteMinder for Secure Proxy Server ではこの一意の ID をトークン
として使用できます。 このスキームは、ユーザのセッションを管理する
メカニズムとして Cookie を除去します。
SSL ID セッション スキームの制限は、CA SiteMinder for Secure Proxy Server
との最初の接点が SSL セッション ID を確立するということです。 ユーザ
の SSL セッションが中断され、新しい SSL 接続が確立される場合、同じシ
ステム上の仮想サーバであっても、新しい SSL 接続には新しいサーバへの
接続があるため、ユーザは再認証および再認可される必要があります。ま
た、これは保護されているリソースと同じホスト名から提供される必要の
ある、HTML フォーム認証方式によってフォームが使用されることを意味
します。
SSL ID セッション スキーム設定
SSL ID セクションでは、SSL ID を使用してセッション スキームのリストを
示します。
SSL ID セッション スキームは、SPS でパッケージ化された Java クラスを使
用して、カスタムな作業を行わずにサポートされます。
重要： SSL ID 認証方式を使用するには、Apache Web サーバの httpd.conf
ファイル内の設定も有効にする必要があります。
SSL ID セッション スキームには以下の形式があります。
<SessionScheme name="ssl_id">
class="com.netegrity.proxy.session.SSLIdSessionScheme"
accepts_smsession_cookies="false"
</SessionScheme>
136 管理ガイド
server.conf ファイル内のセッション スキームの設定
ssl_id 用のディレクティブを以下に示します。
class
SSL ID セッション スキームを処理する Java クラスを指定します。
デフォルト： com.netegrity.proxy.session.SSLIdSessionScheme
accepts_smsession_cookies
SMSESSION Cookie が承諾されるかどうかを示します。 以下のいずれか
の値を指定します。
true
SMSESSION Cookie がセッション スキームによって承諾および使用
されることを示します。
false
SMSESSION Cookie がセッション スキームによってサポートされな
いことを示します。
SSL ID スキーム用の httpd.conf ファイルを変更する
server.conf ファイル内の SSL ID セッション スキームの設定に加えて、SSL
を有効にするために Apache Web サーバの httpd.conf ファイルを変更する
必要があります。
SSL ID スキーム用の httpd.conf ファイルを変更する方法
1. sps_home/secure-proxy/httpd/conf ディレクトリに配置された
httpd.conf ファイルを開きます。
2. ファイル内で以下を読み取る行を見つけます。
#SSLOptions +StdEnvVars +ExportCertData +CompatEnvVars
3. 行の先頭から # 記号を削除します。
注： CA SiteMinder for Secure Proxy Server r6.0 SP 3 以降については、行が
以下を読み取るように +CompateEnvVars も削除します。
SSLOptions+StdEnvVars+ExportCertData
4. httpd.conf ファイルを保存します。
5. SPS を再起動します。
第 7 章： SPS サーバ設定を設定する 137
server.conf ファイル内のセッション スキームの設定
IP アドレス セッション スキーム
IP アドレスが固定された環境で、CA SiteMinder for Secure Proxy Server は IP
アドレスを使用して、セッション ストアのユーザのセッション情報を参
照できます。 このスキームは Cookie を削除しますが、ユーザに固定 IP ア
ドレスが割り当てられている環境でのみ使用できます。
ミニ Cookie セッション スキーム
従来の SiteMinder Cookie ベースのセッション スキームにおけるデメリッ
トの 1 つは、Cookie のサイズです。各リクエストで転送されるデータ量が
増加すると、携帯電話など特定タイプのデバイスにかかるアクセスのコス
トが増加します。
ミニ Cookie は、約 10 バイトの小さな Cookie です。ここには、SiteMinder メ
モリ内セッション ストアのセッション情報を参照するために使用できる
トークンが含まれています。 ミニ Cookie は標準的な SiteMinder Cookie の
サイズのごく一部で、標準的な SiteMinder Cookie の代わりになる選択肢を
提供します。
ミニ Cookie セッション スキーム設定
ミニ Cookie セッション スキームは、メモリ セッション ストア-の CA
SiteMinder for Secure Proxy Server にセッション情報を格納し、CA
SiteMinder for Secure Proxy Server がユーザに返す暗号化されたトークンを
含む Cookie を作成します。
このセクションの形式は以下のとおりです。
<SessionScheme name="minicookie">
class="com.netegrity.proxy.session.MiniCookieSessionScheme"
accepts_smsession_cookies="false"
# クライアントに格納される小さな Cookie の名前。
cookie_name="SMID"
</SessionScheme>
138 管理ガイド
server.conf ファイル内のセッション スキームの設定
ミニ Cookie セッション スキームのディレクティブを以下にリストします。
class
セッション スキームを定義する Java クラスを指定します。 ユーザが
SPS で提供されたミニ Cookie セッション スキームを使用する場合、こ
のディレクティブは変更されません。
デフォルト： com.netegrity.proxy.session.MiniCookieSessionScheme
accepts_smsession_cookies
SMSESSION Cookie が承諾されるかどうかを示します。 以下のいずれか
の値を指定します。
true
SMSESSION Cookie がセッション スキームによって承諾および使用
されることを示します。
false
SMSESSION Cookie がセッション スキームによってサポートされな
いことを示します。 この設定を使用し、ミニ Cookie セッションの
みがセッション スキームに使用されることを確認します。
cookie_name
ユーザ セッション用のトークンを含むミニ Cookie の名前を示します。
注： この名前は、シングル サインオンを提供する CA SiteMinder for
Secure Proxy Server すべてに同じ値を使用して設定されるわけではあ
りません。
シンプル URL リライティング セッション スキーム
シンプル URL リライティングは、トークンをリクエストされた URL に追加
して、ユーザ セッションを追跡する方法です。 このトークンはメモリ内
セッション ストアからセッション情報を取得するために使用されます。
単純な URL の書き換え設定
simple_url スキームは単純な URL の書き換えをサポートします。これによ
り、カスタム作業を行わずに実行できます。
注： CGI ベースおよび FCC ベースのパスワード スキームは、simple_url セッ
ション スキームでサポートされています。
第 7 章： SPS サーバ設定を設定する 139
server.conf ファイル内のセッション スキームの設定
例
ユーザがホストにアクセスし、ユーザ セッションは単純な URL の書き換
えセッション スキームによって確立されます。 初期リクエストは以下の
例のようになります。
http://banking.company.com/index.html
ユーザが適切な認証情報を指定し、認証および許可された場合、ユーザに
よってリクエストされた URL は書き換えられ、以下のようなフォームで
ユーザに返されます。
http://banking.company.com/SMID=nnnnnnnnnn/index.html
nnnnnnnnnn
ユーザ セッションを特定するために CA SiteMinder for Secure Proxy
Server が使用する、ハッシュされたランダムに生成されたトークンを
表します。
重要： 単純な URL の書き換えセッション スキームを動作させるには、企業
で定義されたリンクはすべて相対リンクである必要があります。 リンク
が絶対の場合、単純な URL の書き換えスキームは失敗します。 また、リ
クエストが転送される場合、CA SiteMinder for Secure Proxy Server が URL に
追加するトークンは URL から取り去られます。 バックエンド サーバの処
理が妨害されないように、トークンは CA SiteMinder for Secure Proxy Server
の対話レベルにのみ追加されます。
SimpleURL スキームの形式は次のとおりです。
<SessionScheme name="simple_url">
class="com.netegrity.proxy.session.SimpleURLSessionScheme"
accepts_smsession_cookies="false"
session_key_name="SMID"
</SessionScheme>
SimpleURL スキームのディレクティブを以下にリストします。
class
セッション スキームを定義する Java クラスを指定します。 ユーザが
Cookie なしの書き換えセッション スキームを使用する場合、このディ
レクティブは変更されません。
デフォルト： com.netegrity.proxy.session.SimpleURLSessionScheme
140 管理ガイド
server.conf ファイル内のセッション スキームの設定
accepts_smsession_cookies
SMSESSION Cookie が承諾されるかどうかを示します。 以下のいずれか
の値を指定します。
true
SMSESSION Cookie がセッション スキームによって承諾および使用
されることを示します。
false
SMSESSION Cookie がセッション スキームによってサポートされな
いことを示します。この設定を使用し、Cookie なしの書き換えセッ
ションのみがこのセッション スキームに使用されることを確認し
ます。
session_key_name
SiteMinder ID （SMID）のセッション識別子を指定します。
注： Cookie なしのフェデレーション トランザクションが CA SiteMinder for
Secure Proxy Server のフェデレーション ゲートウェイによって処理されて
おり、simple_url セッション スキームが使用される場合、SMID は URI に追
加される代わりに、クエリ パラメータとしてリクエストに追加されます。
第 7 章： SPS サーバ設定を設定する 141
server.conf ファイル内のセッション スキームの設定
書き換え可能なセッション スキームに対して Cookie なしのフェデレーションの有効化
フェデレーション環境で、CA SiteMinder for Secure Proxy Server が単純な
URL セッション スキームなどの書き換え可能なセッション スキームを使
用する場合、Cookie なしのフェデレーションを設定します。
Cookie なしのフェデレーションを設定する方法
1. テキスト エディタで server.conf ファイルを開きます。 ファイルは、
ディレクトリ sps_home/secure-proxy/proxy-engine/conf に配置されま
す。
2. FWS を処理している仮想ホストの仮想ホスト セクションに以下の
コードを追加します。
cookielessfederation="yes"
3. ファイルを保存します。
4. SPS を再起動します。
注： CookielessFedFilter などの個別のポスト フィルタは SPS フェデレー
ション ゲートウェイ用に有効である必要はありません。 フェデレーショ
ン ゲートウェイ機能を有効にすると、この機能は標準で提供されます。
SPS がフェデレーション ゲートウェイとして機能していない場合、このポ
スト フィルタを有効にする必要があります。
142 管理ガイド
server.conf ファイル内のセッション スキームの設定
単純な URL セッション スキーム用の FWS リダイレクトの書き換え
フェデレーション環境に CA SiteMinder for Secure Proxy Server を展開する
場合、アサーションを作成しているサイトで使用可能なセッション ス
キームの 1 つは、単純な URL セッション スキームです。 このスキームを
使用すると、セッション キーがリンクに追加されるように、適切なサイ
トをユーザに指示するリンクに書き換える必要がある場合があります。
SiteMinder ドキュメントで、これらの SAML 1.x 用のリンクは、サイト間転
送 URL と呼ばれます。 SAML 2.0 の場合、これらのリンクは未承諾応答ま
たは AuthnRequest リンクとして参照されます。
セッション キー情報が URL のベースに追加されるようにリンクを書き換
える場合、サンプルの事後フィルタ（RewriteLinksPostFilter）が CA SiteMinder
for Secure Proxy Server フィルタの例と共に提供されます。このフィルタは
コンパイルされ、サイト間転送 URL、未承諾応答、または AuthnRequest へ
の転送を処理する適切なプロキシ ルールにアタッチできます。
CA SiteMinder for Secure Proxy Server で提供される RewriteLinksPostFilter は
サンプル フィルタです。 要件に合わせて、フィルタを設定する必要があ
ります。
注： simple_url セッション スキームを SPS フェデレーション ゲートウェイ
に関するトランザクションに使用する場合、セッション キー（SMID）は、
URI に追加される代わりにクエリ パラメータとしてリクエストに追加さ
れます。 ただし、最終ターゲット リソースがバックエンド サーバでアク
セスされるとき、SMID は URI に追加されます。
第 7 章： SPS サーバ設定を設定する 143
server.conf ファイル内のセッション スキームの設定
ワイヤレス デバイス ID セッション スキーム
一意のデバイス ID 番号を持つワイヤレス デバイスもあります。 この番号
はリソースに対する任意のリクエストと共にヘッダ変数として送信され
ます。 セッション ストアでセッション情報を参照するために、CA
SiteMinder for Secure Proxy Server はトークンとしてこのデバイス ID を使
用できます。
デバイス ID はワイヤレス デバイス ベンダーによって異なるので、
server.conf ファイルでデバイス ID セッション スキームを定義します。 こ
のスキームにはクラス情報、およびベンダーに固有のデバイス ID に設定
される device_id_header_name ディレクティブを含む必要があります。
デバイス ID スキームの形式は次のとおりです。
<SessionScheme name="device_id">
class="com.netegrity.proxy.session.DeviceIdSessionScheme"
accepts_smsession_cookies="false"
device_id_header_name="vendor_device_id_header_name"
</SessionScheme>
144 管理ガイド
server.conf ファイル内のセッション スキームの設定
各セッション スキームに使用
以下の表は、各セッション スキームが使用されるシナリオについて説明
します。 セッション スキームは仮想ホストのリソースの感度に基づきま
す。
セッション スキー
ム
セキュリティ レベ
ル
推奨
SSL セッション ID 高
このスキームは、ユーザ セッションを保持するクリーン
で、高度なセキュリティで保護された手段を提供します。
使用可能なスキームで最もセキュアですが、拡張性は制
限されます。 すべてのコンテンツは SSL で供給される必
要があり、ユーザはセッションを保持するために同じ CA
SiteMinder for Secure Proxy Server サーバに引き続きアク
セスする必要があります。 また、一部のブラウザ（IE の
一部のバージョン）は、デフォルトで 2 分後に SSL セッ
ションを終了します。このスキームは、高いセキュリティ
が必要なイントラネットおよびエクストラネットのアプ
リケーションに最適です。
SiteMinder Cookie 中または高
このスキームは従来の SiteMinder セッション メカニズム
で、多くの企業展開において高度なセキュリティが証明
されています。
セキュリティを最大限に確保するには、WebAgent
SecureCookie 設定を「Yes」に設定します。
IP アドレス
低
このスキームは、ユーザが保護されているリソースから
情報を取得している（HTTP GET を使用）、および安全な
アプリケーションに情報を送信していない（HTTP POST を
使用）アプリケーションのみに使用されます。 適切なア
プリケーションの例は、オンライン ライブラリになりま
す。 不適切なアプリケーションの例は、債券取引アプリ
ケーションになります。
ミニ Cookie
中または高
このスキームは、ユーザ クライアントが Cookie を受け入
れるアプリケーションに最適ですが、制限のある速度お
よび帯域幅の接続でアプリケーションにアクセスしま
す。
セキュリティを最大限に確保するには、WebAgent
SecureCookie 設定を「Yes」に設定します。
第 7 章： SPS サーバ設定を設定する 145
server.conf ファイル内のセッション スキームの設定
セッション スキー
ム
セキュリティ レベ
ル
推奨
シンプル URL リ
ライティング
中
このスキームは、Cookie をサポートしない、または使用
しない環境に最適です。
デバイス ID
中
このスキームは、ユーザを特定するためにデバイス ID が
すべてのクライアント リクエストで送信される、ワイヤ
レス環境向けに設計されています。
仮想ホスト用の複数のセッション スキーム
CA SiteMinder for Secure Proxy Server では、企業の仮想ホストごとに複数の
セッション スキームをサポートします。 セッション スキームは、仮想ホ
ストにアクセス権のある各ユーザ エージェント タイプに割り当てること
ができます。 以下の図では、4 つの仮想ホスト向けに設定された CA
SiteMinder for Secure Proxy Server を示しています。
146 管理ガイド
server.conf ファイル内のセッション スキームの設定
前の図では、ユーザがアクセスする仮想ホストに応じて、セッション ス
キームはユーザ エージェントによって異なることを示しています。 たと
えば、ブラウザで www.company.com にアクセスする場合、CA SiteMinder
for Secure Proxy Server はユーザ セッションを保持するために SiteMinder
Cookie を使用します。 ただし、BondTrading.company.com にアクセスする
場合、ブラウザ セッションはユーザ HTTPS 接続の SSL ID を使用して保持さ
れます。ブラウザ ユーザ セッションが Cookie またはミニ Cookie によって
保持されている間、PDA および無線ユーザ用のセッションは Cookie のない
セッション スキームを使用して保持されます。
Cookie なしのフェデレーションの属性 Cookie の削除
Cookie を交換しない環境をサポートするには、CA SiteMinder for Secure
Proxy Server は SiteMinder セッション Cookie を Cookie なしのセッション
スキームにマップして、レスポンスから Cookie を削除します。 ただし、
属性 Cookie はマップされず、レスポンスに残ります。
FWS アプリケーションは、フェデレーション リクエストを処理し、属性
Cookie および SiteMinder に作成されたセッション Cookie をそのレスポン
スに挿入します。 レスポンスは SPS に転送されます。
CA SiteMinder for Secure Proxy Server は FWS アプリケーションによって挿
入された属性 Cookie を削除するように設定できます。
セッションおよび属性 Cookie を削除するように CA SiteMinder for Secure Proxy
Server を設定する方法
1. テキスト エディタで server.conf ファイルを開きます。
ファイルは、ディレクトリ sps_home/secure-proxy/proxy-engine/conf に
配置されます。
2. FWS を処理している仮想ホストの仮想ホスト セクションに以下の
コードを追加します。
deleteallcookiesforfed="yes"
3. ファイルを保存します。
4. SPS を再起動します。
第 7 章： SPS サーバ設定を設定する 147
Server.conf のユーザ エージェント設定
Server.conf のユーザ エージェント設定
ユーザ エージェントは、ユーザがネットワーク リソースにアクセスでき
る Web ブラウザ、携帯電話、および PDA などのデバイス タイプを定義し
ます。ユーザ エージェントはすべて <UserAgent> エレメントで定義される
必要があります。 <UserAgent> エレメントにはそれぞれ、ユーザ エージェ
ント タイプを識別する名前属性が含まれます。 デフォルトで、server.conf
ファイルに事前定義済みのユーザ エージェント タイプはありません。
ユーザ エージェント設定セクションには以下の形式があります。
#<UserAgent name="user_agent_name_1">
# header_name_1= 正規表現
# </UserAgent>
UserAgent セクションのディレクティブは次のとおりです。
header_name
このディレクティブには、HTTP リクエストのユーザ エージェント
ヘッダが含まれます。 このヘッダは、リクエストを行っているデバイ
スのタイプを示します。 正規表現を使用し、名前の一部を表現の一部
として提供できます。 これによって、ユーザはユーザ エージェント
ヘッダにバージョン番号などのわずかな違いが含まれる場合のある
ユーザ エージェント タイプを指定できるようになります。
<SessionSchemeMapping> エレメントでセッション スキームと関連付
けられるようにするには、デバイス タイプを <UserAgent> エレメント
で定義する必要があります。
148 管理ガイド
Server.conf のユーザ エージェント設定
Nokia ユーザ エージェントの設定
Nokia ユーザ エージェント タイプを指定できます。これは Nokia の無線電
話向けです。 <UserAgent> セクションの名前属性は、セッション スキーム
マッピングを指定する場合にユーザ エージェント タイプの識別に使用さ
れる名前です。
Nokia ユーザ エージェントの入力形式は以下のとおりです。
# Nokia
<UserAgent name="Nokia">
User-Agent="Nokia."
attribute_name="value"
</UserAgent>
Nokia ユーザ エージェントのディレクティブを以下に示します。
User-Agent
このディレクティブには、HTTP リクエストのユーザ エージェント
ヘッダのコンテンツが含まれます。 このヘッダは、リクエストを行っ
ているデバイスのタイプを示します。 正規表現を使用し、名前の一部
を表現の一部として提供できます。 このディレクティブでは、ヘッダ
にバージョン番号など、User-Agent にわずかな違いを含めることが可
能なユーザ エージェント タイプを指定することができます。
デフォルト：Nokia
attribute_name
ワイヤレス デバイスおよび他のユーザ エージェント タイプ用の
server.conf のセクションには、属性に対して追加の属性および値を含める
ことができます。 属性は必須ではありませんが、いくつかのアプリケー
ションでは指定した方が望ましいことがあります。
第 7 章： SPS サーバ設定を設定する 149
server.conf ファイルの仮想ホスト設定
server.conf ファイルの仮想ホスト設定
server.conf ファイルの <VirtualHostDefaults> エレメントは、仮想ホスト用の
デフォルト設定を指定します。 これらの設定は、SPS に追加する各仮想ホ
ストに使用されます。
仮想ホストにデフォルト以外の値を指定するには、<VirtualHostDefaults> エ
レメントに従って <VirtualHost> エレメントを追加します。<VirtualHost> エ
レメントには、デフォルト仮想ホストとは異なるディレクティブおよび値
が含まれる必要があります。
デフォルトの仮想ホスト設定は、以下のセクションに分割されます。
■
デフォルト セッション スキーム
■
セッション スキーム マッピング
■
WebAgent.conf 設定
■
デフォルト仮想ホスト名
<VirtualHostDefaults> セクションの形式は以下のとおりです。
<VirtualHostDefaults>
# デフォルト セッション スキーム
defaultsessionscheme="default"
enablerewritecookiepath="no"
enablerewritecookiedomain="no"
enableproxypreservehost="no"
filteroverridepreservehost="no"
# リクエストおよびレスポンスのブロック サイズを KB で指定
requestblocksize="4"
responseblocksize="4"
#TO-DO： 任意のセッション スキーム マッピングの定義
#<SessionSchemeMappings>
#
user_agent_name=session_scheme_name
#</SessionSchemeMappings>
# Web Agent.conf
<WebAgent>
sminitfile="C:¥Program Files¥netegrity¥secure-proxy¥proxy-engine¥
conf¥defaultagent¥WebAgent.conf"
</WebAgent>
</VirtualHostDefaults>
150 管理ガイド
server.conf ファイルの仮想ホスト設定
仮想ホスト Cookie パスおよびドメインを正しい URI に設定
server.conf ファイルの仮想ホスト設定には、enablerewritecookiepath およ
び enablerewritecookiedomain パラメータが含まれます。これは、SPS の後
ろに配置される送信先サーバによって生成された Cookie を管理するため
に使用できます。CA SiteMinder for Secure Proxy Server がクライアントから
リクエストを受信する場合、CA SiteMinder for Secure Proxy Server はユーザ
を認証し、クライアントにリクエストされた送信先サーバを指示します。
送信先サーバはブラウザに配置する Cookie を生成し、その後、CA
SiteMinder for Secure Proxy Server はその Cookie でクライアント レスポン
スをユーザに返送します。 SPS からレスポンスを受信した後に、クライア
ントは Cookie を格納します。
クライアントが後続のリクエストを送信する場合、ブラウザは URL と関連
付けられた格納済みの Cookie を取得します。 送信先サーバは初期リクエ
ストの URI へではなく、独自のリソース URI への Cookie パスを設定してい
る場合もあります。 その結果、クライアントが後続のリクエストを送信
する場合、ブラウザに間違った Cookie が含まれるか、または Cookie が 1 つ
もありません。 そのリクエストは、間違った Cookie を含む、またはまっ
たく Cookie のない送信先サーバで受信されます。
正しい Cookie がブラウザに設定されていることを確認するには、
Cookie パ
スおよび Cookie ドメインを書き換えるために CA SiteMinder for Secure
Proxy Server を設定できます。 送信先サーバでは、CA SiteMinder for Secure
Proxy Server サーバ上のリソースの URI への Cookie パスおよび Cookie ドメ
インを設定します。 クライアントは後続のリクエストで正しい Cookie を
SPS に送信できます。
2 つのパラメータは以下のように機能します。
enablerewritecookiepath
プロキシの後ろに配置されるサーバによって設定された、URI からの
初期リクエストの URI への Cookie パスを書き換えるように CA
SiteMinder for Secure Proxy Server に指示します。
デフォルト： no
enablerewritecookiedomain
プロキシの後ろに存在するサーバによって設定されたドメインから初
期リクエストのドメインに、Cookie ドメインを書き換えるように CA
SiteMinder for Secure Proxy Server に指示します。
デフォルト： no
第 7 章： SPS サーバ設定を設定する 151
server.conf ファイルの仮想ホスト設定
例
クライアントは CA SiteMinder for Secure Proxy Server のリソース
http://mysps.ca.com/basic/test/page0.html をリクエストします。
enablerewritecookiepath を yes に設定すると、Cookie パスはブラウザがク
ライアントに返送される前に /basic/test に書き換えられます。この Cookie
は、CA SiteMinder for Secure Proxy Server が送信先サーバから受信した
Cookie に元からあった Cookie パスにかかわらず書き換えられます。
バックエンド Cookie パスおよびドメインの書き換え方法
1. テキスト エディタで server.conf ファイルを開きます。
2. 次のパラメータの 1 つまたは両方を yes に設定します。
■
enablerewritecookiepath
■
enablerewritecookiedomain
3. ファイルを保存します。
4. SPS を再起動します。
152 管理ガイド
server.conf ファイルの仮想ホスト設定
HOST ヘッダ ファイルの保持
HTTP HOST ヘッダ ファイルを保持し、enableproxypreservehost パラメータ
を使用して、そのヘッダ ファイルをバックエンド サーバに送信できます。
enableproxypreservehost パラメータを使用するには、以下の手順に従いま
す。
1. server.conf ファイルを開きます。
2. 設定する仮想ホストの［仮想ホスト］セクションに以下のパラメータ
を追加します。
enableproxypreservehost
3. enableproxypreservehost の値を yes に設定します。
enableproxypreservehost を有効にすると、このパラメータは HTTP HOST
ヘッダを制御するために設定されたフィルタよりも優先されます。
enableproxypreservehost を無効にして、このパラメータよりもフィルタを
優先させるには、以下の手順に従います。
1. server.conf ファイルを開きます。
2. 設定する仮想ホストの［仮想ホスト］セクションに以下のパラメータ
を追加します。
filteroverridepreservehost
3. filteroverridepreservehost の値を yes に設定します。
HTTP HOST ヘッダを制御するフィルタが使用可能な場合にのみ、
filteroverridepreservehost を有効にできます。
データ ブロックを使用した大きなファイルの処理
CA SiteMinder for Secure Proxy Server は CA SiteMinder for Secure Proxy Server
およびバックエンド サーバの間で転送されるデータをブロックに分割し
て、ユーザへの大きなファイルの転送を処理します。 server.conf ファイル
の仮想ホスト セクションにある 2 つのパラメータを使用して、CA
SiteMinder for Secure Proxy Server によって読み取られるブロック サイズを
制御します。
■
requestblocksize
■
responseblocksize
第 7 章： SPS サーバ設定を設定する 153
server.conf ファイルの仮想ホスト設定
ユーザがファイルをバックエンド サーバに送信する際に、CA SiteMinder
for Secure Proxy Server ではその仮想ホストに指定された requestblocksize
が確認されます。requestblocksize の値に基づいて、CA SiteMinder for Secure
Proxy Server はデータをブロックに分割して、ブロックをバックエンド
サーバに転送します。
同様に、バックエンド サーバがユーザにデータを送信する際に、CA
SiteMinder for Secure Proxy Server ではその仮想ホストに指定された
responseblocksize が確認されます。 responseblocksize の値に基づいて、CA
SiteMinder for Secure Proxy Server はブロックをさらに処理する前に、バッ
クエンド サーバからのブロックのデータを読み取ります。 これにより、
ユーザはこのようなファイル転送用の読み取り/書き込み操作の数を制御
できます。 大きなファイル転送を処理するには、大きなブロック サイズ
を使用します。
注： requestblocksize および responseblocksize のパラメータは、CA
SiteMinder for Secure Proxy Server java プロセスに割り当てられた使用可能
な JVM ヒープ サイズに合わせて定義する必要があります。
サイズの大きなファイルを処理するためのファイル データ ブロック サイズの定義
仮想ホスト用のブロック サイズを設定した場合に、サイズの大きなファ
イルを処理するブロック サイズを定義するには、仮想ホストごとにリク
エストおよびレスポンスのブロック サイズを変更します。 これらのパラ
メータは、その仮想ホストに対してのみ有効です。 仮想ホストが異なれ
ばデータ ブロック サイズは異なることがありますが、その設定は、設定
対象の関連仮想ホストにのみ適用されます。
154 管理ガイド
server.conf ファイルの仮想ホスト設定
次の手順に従ってください：
1. テキスト エディタで server.conf ファイルを開きます。
2. 仮想ホスト設定の下にある以下のパラメータを編集します。
requestblocksize
データ ブロックがバックエンド サーバに送信される前に、一度に
読み取られるリクエスト データのブロック サイズを定義します。
ブロック サイズは KB 単位です。
制限： 1 KB ～およそ 352000 KB。8 KB 以上の任意の値については、
8 KB のチャンクが作成されます。 対応するチャンク サイズが 1 KB
と 8 KB との間の値に対して作成されます。
デフォルト： 4
responseblocksize
データ ブロックがバックエンド サーバからユーザに転送される
前に、一度に読み取られるレスポンス データのブロック サイズを
定義します。 ブロック サイズは KB 単位です。
制限： 1 KB ～およそ 352000 KB。
デフォルト： 8
3. server.conf ファイルを保存します。
4. SPS を再起動します。
データ ブロック用の JVM ヒープ サイズの調整
requestblocksize および responseblocksize のパラメータは、CA SiteMinder for
Secure Proxy Server Java プロセスに割り当てられた使用可能な JVM ヒープ
サイズに合わせて定義されます。
CA SiteMinder for Secure Proxy Server JVM ヒープ サイズを定義する方法
1. 次の適切なディレクトリに移動します。
■
Windows： sps_home/secure-proxy/proxy-engine/conf
■
UNIX： sps_home/secure-proxy/proxy-engine
2. 以下のいずれかのファイルを開きます。
■
Windows システム： SmSpsProxyEngine.properties ファイル
■
UNIX システム： proxyserver.sh ファイル
第 7 章： SPS サーバ設定を設定する 155
server.conf ファイルの仮想ホスト設定
3. ファイルの Java セクションに以下のパラメータを追加します。
■
–Xms256m
■
–Xmx512m
4. ファイルを保存します。
デフォルト仮想ホスト用のセッション スキーム マッピング
セッション スキーム マッピングは、ユーザ エージェント タイプとセッ
ション スキームを関連付けます。server.conf ファイルの <UserAgent> エレ
メントで定義されたユーザ エージェント タイプは、<SessionScheme> エレ
メントで定義されたセッション スキームにマップされる必要があります。
ユーザ エージェントと関連付けられたセッション スキーム マッピングの
形式を以下に示します。
#<SessionSchemeMappings>
#
user_agent_name=session_scheme_name
#</SessionSchemeMappings>
このセクション内のディレクティブは次のとおりです。
user_agent_name
セッション スキームとユーザ エージェントを関連付けます。 値を設
定するには、以下の作業を行います。
user_agent_name
ファイルの <UserAgent> セクションで定義される名前を指定しま
す。
session_scheme_name
SessionScheme エレメントで定義されるスキームを指定します。
例：
browser、phone1、および phone2 という名前のユーザ エージェン
トが、ファイルで定義されたセッション スキームのいずれかに定
義およびマップされています。 この例で、browser はデフォルト
セッション スキームにマップされ、phone1 は simple_url スキーム
にマップされ、phone2 はミニ Cookie セッション スキームにマップ
されます。
156 管理ガイド
server.conf ファイルの仮想ホスト設定
結果として得られる <SessionSchemeMappings> エレメントは、以下
のように表示されます。
# セッション スキームのマッピング
<SessionSchemeMappings>
browser="default"
phone1="simple_url"
phone2="minicookie"
</SessionSchemeMappings>
デフォルト仮想ホスト用の Web エージェント設定
server.conf ファイルには、<VirtuallHostDefaults> 用の <WebAgent> セクショ
ンが含まれます。 sminitfile ディレクティブは、設定ファイル（デフォル
ト Web エージェント用の WebAgent.conf）を指定します。ローカル設定が
許可されている場合、WebAgent.conf ファイルはローカル設定ファイル
（LocalConfig.config）を指します。
複数の仮想ホストを作成する場合、Web エージェント設定ファイルで別の
設定を使用しない場合は、デフォルトの Web エージェントを使用できま
す。 たとえば、別のログ レベルを指定するために、任意のディレクティ
ブを異なる方法で設定する場合、新しい仮想ホストに別の Web エージェ
ントを使用します。
新しい仮想ホストに新しい Web エージェントを設定する方法
1. 新しい仮想ホストの名前でディレクトリを作成します（例：serverb）。
2. デフォルトの仮想ホスト用のディレクトリのコンテンツを新しいディ
レクトリにコピーします。
新しい Web エージェントが別の SiteMinder インストールを指してい
る場合、smreghost を実行します。
注： 両方の仮想ホスト用の Web エージェント設定オブジェクトが同
じ SiteMinder インストールを指している場合は、smreghost を実行する
必要はありません。 両方の Web エージェントに同じ smhost ファイル
を使用できます。
3. テキスト エディタを使用して WebAgent.conf を変更し、新しいエー
ジェント設定オブジェクトを反映します。Web エージェントにさまざ
まなログ ファイルがあることを確認します。
第 7 章： SPS サーバ設定を設定する 157
server.conf ファイルの仮想ホスト設定
4. WebAgent.conf ファイルを開き、一意の値を持つ以下の必要なディレク
ティブを追加します。
ServerPath="path"
path
編集中の WebAgent.conf ファイルへの完全修飾パスを指定します。
■
Windows の場合、この値は一意の英数文字列である必要があり
ます。 円記号「¥」文字は、この文字列では許可されません。
■
UNIX の場合、この値は編集中の WebAgent.conf ファイルへの完
全修飾パスである必要があります。
5. server.conf ファイルの最初のホスト設定オブジェクトに相当するポリ
シー サーバのエージェント設定オブジェクトにアクセスします。
MaxResoureceCacheSize および MaxSessionCacheSize のエージェント
キャッシュ設定、およびそのキャッシュ制限がすべてのエージェント
設定オブジェクトを考慮していることを確認します。
注： Web エージェント設定の詳細については、「CA SiteMinder Web エー
ジェント ガイド」を参照してください。
requirecookies パラメータの設定
server.conf ファイルの requirecookies 設定は、基本認証がポリシー サーバ
設定中に設定された場合にのみ役立つ、特別な Web エージェント設定で
す。 この設定は、基本認証ヘッダを含め、HTTP リクエストの処理を成功
させるために、SMSESSION または SMCHALLENGE Cookie のどちらかを要求
するよう、エージェントに指示します。
Cookie を要求するように埋め込み Web エージェントを設定する場合、
Web ブラウザに HTTP Cookie を受け取るように設定する必要があります。
ブラウザが Cookie を受け取らない場合は、エージェントからエラーメッ
セージが返され、すべての保護されたリソースに対するユーザのアクセス
が拒否されます。
関連する仮想サーバ用のすべてのユーザ エージェント タイプがデフォル
ト セッション スキームを使用する場合、requirecookies 設定を yes に設定
します。 エージェント タイプが Cookie なしのセッション スキームを使用
する場合、requirecookies パラメータを no に設定します。
158 管理ガイド
server.conf ファイルの仮想ホスト設定
送信先サーバによるリダイレクトの処理
一部の送信先サーバは、リダイレクトによって CA SiteMinder for Secure
Proxy Server からのリクエストに応答できます。
注： CA SiteMinder for Secure Proxy Server へのリクエストの結果であるリダ
イレクトは、プロキシ ルールで発生するリダイレクトと同じではありま
せん。 プロキシ ルールのリダイレクトの詳細については、nete:redirect を
参照してください。
送信先サーバによって開始されたリダイレクトは DMZ の背後のサーバへ
のリダイレクトである可能性があるため、リダイレクトで指定された URL
はエラーになります。 ただし、仮想ホスト設定で、送信先サーバからの
リダイレクトの代わりに仮想ホスト サーバ名およびポート番号を置き換
えるパラメータを含めることができます。
リダイレクト書き込みのための仮想ホスト サーバおよびポートを置き換
えるには、以下を設定します。
enableredirectrewrite
リダイレクトを書き換えの有効化または無効化 このディレクティブ
が yes の値に設定された場合、送信先サーバによって開始されたリダ
イレクト用の URL は SPS によって検査されます。 リダイレクト URL に、
関連する redirectrewritablehostnames パラメータで指定された文字列
リスト内に見つかる文字列が含まれる場合、リダイレクトのサーバ名
およびポート番号は、仮想ホストのサーバ名およびポート番号に置換
されます。
パラメータが no の値に設定されている場合、送信先サーバによって開
始されたリダイレクトは、要求元のユーザに渡されます。
redirectrewritablehostnames
リダイレクトが送信先サーバによって開始されたときに、CA
SiteMinder for Secure Proxy Server が検索する文字列のカンマ区切りリ
ストが含まれています。 指定された文字列のどれかがリダイレクト
URL のサーバまたはポート部分に見つかった場合、CA SiteMinder for
Secure Proxy Server は、リダイレクト URL のサーバ名およびポート部分
を、仮想ホストの名前およびポート番号に置換します。
このパラメータに "ALL" の値を指定した場合、CA SiteMinder for Secure
Proxy Server は送信先サーバによって開始されたすべてのリダイレク
トを仮想ホストのサーバ名およびポート番号に置換します。
第 7 章： SPS サーバ設定を設定する 159
server.conf ファイルの仮想ホスト設定
たとえば、以下のパラメータが含まれる server.conf ファイルでの仮想ホス
ト設定を考えます。
<VirtualHost name="sales">
hostnames="sales, sales.company.com"
enableredirectrewrite="yes"
redirectrewritablehostnames="server1.company.com,domain1.com"
</VirtualHost>
http://sales.company.com:80 から要求する場合、CA SiteMinder for Secure
Proxy Server はプロキシ ルールに従って送信先サーバにリクエストを転送
します。送信先サーバが server1.internal.company.com へのリダイレクトで
応答する場合、リダイレクトはユーザに渡される前に
sales.company.com:80 として書き換えられます。
注： リダイレクトされたリクエストを処理するように CA SiteMinder for
Secure Proxy Server 用のプロキシ ルールを設定する必要があります。
仮想ホスト名の設定
1 つ以上のホスト名の仮想ホストとして機能させる CA SiteMinder for
Secure Proxy Server については、関連するホスト名および IP アドレス用の
<VirtualHost> エレメントを設定します。 各 server.conf ファイルに、他の IP
アドレスのホスト名に使用する追加のエレメントに加えて、デフォルト仮
想ホスト用の <VirtualHost> エレメントを 1 つ含める必要があります。
server.conf ファイル内のデフォルト仮想ホストに使用する <VirtualHost>
エレメントの例を以下に示します。
# デフォルト仮想ホスト
<VirtualHost name="default">
hostnames="home, home.company.com"
addresses="123.123.12.12"
</VirtualHost>
前の例のデフォルト仮想ホストは、IP アドレス 123.123.12.12 に存在する
home.company.com という名前のホストです。 ホスト名の値のカンマ区切
りリストに追加することにより、デフォルト仮想ホストとして解決するホ
スト名を追加できます。 追加の仮想ホストをプロキシ設定に追加するに
は、追加の仮想ホスト用のホスト名ディレクティブが含まれる追加の
<VirtualHost> エレメントを追加します。
160 管理ガイド
server.conf ファイルの仮想ホスト設定
例：
サーバ用の販売仮想ホスト（sales.company.com 仮想ホスト）を追加するに
は、以下のエレメントを追加します。
<VirtualHost name="sales">
hostnames="sales, sales.company.com"
</VirtualHost>
仮想ホストのデフォルト値の上書き
ユーザが特定の仮想ホストの設定を明示的に入力しない場合は、
<VirtualHostDefaults> 設定が server.conf ファイルで定義されたすべての仮
想ホストに使用されます。
単一の仮想ホストの仮想設定をすべて再設定する必要はありません。
<VirtualHost> エレメントで再定義していない設定は、<VirtualHostDefaults>
設定から適用されます。
仮想ホストのデフォルト値を上書きする方法
1. デフォルトの仮想ホスト設定の任意のディレクティブを、変更する
<VirtualHost> エレメントに追加します。
2. <VirtualHost> エレメントのディレクティブに新しい値を指定します。
3. ファイルを保存します。
4. SPS を再起動します。
例
「sales」という名前の仮想ホストは、デフォルトの仮想ホストに設定され
たものからのデフォルト セッション スキームを必要とします。 以下のよ
うに <VirtualHost> エレメントを変更できます。
<VirtualHost name="sales">
hostnames="sales, sales.company.com"
addresses="123.123.22.22"
defaultsessionscheme="minicookie"
</VirtualHost>
第 7 章： SPS サーバ設定を設定する 161
第 8 章： SPS ログ設定の設定
SPS logger.properties ファイルの概要
CA SiteMinder for Secure Proxy Server ログ設定は、logger.properties ファイル
を介して設定されます。 ファイル内のこれらの設定は、CA SiteMinder for
Secure Proxy Server が実行時に読み取る名前/値のペアまたはディレクティ
ブ グループです。 SPS を再起動せずに、logger.properties ファイルを更新
できます。
logger.properties ファイルのデフォルトの場所を以下に示します。
sps_home/Tomcat/properties
logger.properties ファイルの変更
CA SiteMinder for Secure Proxy Server 用のログ設定は、以下のディレクトリ
に格納されている logger.properties ファイルで保持されます。
sps_home/Tomcat/properties
次の手順に従ってください：
1. テキスト エディタでファイルを開きます。
2. 必要に応じて、ディレクティブを編集します。
3. ファイルを保存します。
ログ設定を変更します。
第 8 章： SPS ログ設定の設定 163
ログ記録設定
ログ記録設定
logger.properties ファイルの内容は、以下のセクションにグループ化され
ます。
■
SvrConsoleAppender 設定
■
SvrFileAppender 設定
■
Server log 設定
■
Server log rolling 設定
このファイルに記述されているディレクティブは、名=値という形式にな
ります。# 記号で始まるすべての行はコメントで、CA SiteMinder for Secure
Proxy Server が設定を読み取る際に、読み取られることはありません。
注： Windows システム上のパス名は、2 つの円記号（¥¥）を使用します。
SvrConsoleAppender 設定
SvrConsoleAppender Settings 設定セクションには、コンソールへのイベント
のロギングに関する設定が記述されています。 このセクションの形式は
以下のとおりです。
# SvrConsoleAppender は、ConsoleAppender に設定されます。
log4j.appender.SvrConsoleAppender=org.apache.log4j.ConsoleAppender
log4j.appender.SvrConsoleAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.SvrConsoleAppender.layout.ConversionPattern=<log_message_display_f
ormat_on_console>
log_message_display_format_on_console
コンソールでのログ メッセージの表示形式を指定します。 製品は
log4j 日付パターン文字列をすべてサポートします。
デフォルト値： [%d{dd/MMM/yyyy:HH:mm:ss-SSS}] [%p] - %m%n
164 管理ガイド
ログ記録設定
SvrFileAppender 設定
SvrFileAppender Settings 設定セクションには、ファイルへのイベントのロ
ギングに関する設定が記述されています。 このセクションの形式は以下
のとおりです。
# SvrFileAppender は、FileAppender に設定されます。
log4j.appender.SvrFileAppender=org.apache.log4j.FileAppender
log4j.appender.SvrFileAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.SvrFileAppender.layout.ConversionPattern=<log_message_display_form
at_in_file>
log_message_display_format_in_file
ファイルでのログ メッセージの表示形式を指定します。 製品は log4j
日付パターン文字列をすべてサポートします。
デフォルト値： [%d{dd/MMM/yyyy:HH:mm:ss-SSS}] [%p] - %m%n
第 8 章： SPS ログ設定の設定 165
ログ記録設定
ログ設定
サーバのログ設定セクションには、ロギングの有効/無効の切り替え、ロ
ギング レベルの設定、およびログ メッセージの出力形式の設定に関する
設定が記述されています。 このセクションの形式は以下のとおりです。
# Server.conf の設定：
# 「log4j.rootCategory」の設定詳細：
# 第 1 属性：
# 必要なロギング レベルに応じて、適切なレベルを設定します。
# 設定可能な値： OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL
# 第 2 属性：
# ログ コンソールを有効にする場合、SvrConsoleAppender を追加します。それ以外の場合は追加しな
いでください。
#第 3 属性：
# ファイルへのロギングを有効にする場合、SvrFileAppender を追加します。それ以外の場合は追加し
ないでください。
log4j.rootCategory=<log_level>,<output_format>
log level
メッセージのログ レベルを指定します。 以下のリストでは、優先度の
値を昇順に示します。
■
OFF
■
FATAL
■
ERROR
■
WARN
■
INFO
■
DEBUG
■
ALL
値を OFF に設定すると、ログ記録は無効になります。 値をそれ以外に
設定すると、ログ記録は有効になります。
デフォルト： INFO
output format
ログ メッセージをどのように表示されるかを指定します。コンソール
にログ メッセージを表示することも、ファイルに格納することも、両
方実行することもできます。
デフォルト： SvrFileAppender
166 管理ガイド
ログ記録設定
たとえば、ログ レベルが INFO で、コンソールにログ メッセージを表示し、
ファイルにもメッセージを保存する場合、次のコマンドを使用します。
log4j.rootCategory=INFO,SvrConsoleAppender,SvrFileAppender
ログ ローテーションの設定
サーバの Log Rolling の設定セクションでは、ログのローテーションを有効
にするための設定が記述されています。 以下のいずれかのメカニズムに
基づいて、ログのローテーションを有効にできます。
■
ファイル サイズに基づくログのローテーション
■
ファイルの経過時間に基づくログのローテーション
このセクションの形式は以下のとおりです。
# ファイルへのロギングがこれまでに有効になっている場合のみ、以下の設定を有効にします。 そうでな
い場合は、行の先頭に "#" を追加してコメント行うにします。
log4j.appender.SvrFileAppender.File=<logfile_path>
# ファイルへのロギングがこれまでに有効になっている場合のみ、この設定を有効にします。
# メッセージを既存ファイルに追加する場合は、値を "true" に設定します。そうでない場合は、"false"
に設定します。
log4j.appender.SvrFileAppender.Append=true|false
# ファイル サイズに基づいたサーバ ログ ファイルのロールオーバの設定
log4j.appender.SvrFileAppender=org.apache.log4j.RollingFileAppender
log4j.appender.SvrFileAppender.MaxFileSize=<maximum_logfile_size>
log4j.appender.SvrFileAppender.MaxBackupIndex=<maximum_number_of_logfile>
Log Rolling Based on File セクションには、ファイル サイズに基づいてログ
ローテーションを有効にする、以下の設定が記述されています。
logfile path
ログ ファイルの名前とパスを指定します。
デフォルト名： server.log
デフォルト パス： install_dir_home/secure-proxy/proxy-engine/logs/
true|false
システムがどのようにログ ファイルを管理するか指定します。この値
を true に設定すると、システムの起動時、既存のログ ファイルに新し
いログ メッセージが追加されます。 この値を false に設定すると、シ
ステムの起動時、既存のログ ファイルがロールオーバされ、新しいロ
グ メッセージ用にログ ファイルが作成されます。
デフォルト値： true
第 8 章： SPS ログ設定の設定 167
ログ記録設定
MaxFileSize
システムが新しいログ ファイルを作成した後のログ ファイルの最大
サイズを指定します。
デフォルト値： 1 MB
MaxBackupIndex
システムが作成するログ ファイルの最大数を指定します。 ログ ファ
イルの数が指定された最大数を超えている場合、最も古いログ ファイ
ルが削除され、新しいログ ファイルが作成されます。
デフォルト値： 10
Log Rolling Based on File Age セクションには、ファイルの経過時間に基づい
てログ ローテーションを有効にする、以下の設定が記述されています。
date_pattern
システムが新しいログ ファイルを作成する場合の日付を指定します。
デフォルト： yyyy-MM-dd
新しいログ ファイルは以下の形式で作成されます。
<logfile_name>.<date_format>
logfile_name
ログ ファイルの名前を指定します。
デフォルト： server.log
date_format
ログ ファイルが作成された日付を指定します。 ファイルは log4j 日付
パターン文字列をすべてサポートします。
デフォルト： yyyy-MM-dd
168 管理ガイド
ログ記録用に WebAgent.conf の ServerPath を変更
ログ記録用に WebAgent.conf の ServerPath を変更
仮想ホストに Web エージェントを設定する場合、各ホストには独自の
Web エージェント キャッシュ、ログ ファイル、および状態監視リソース
がある必要があります。 リソースが一意であることを確認するには、
ServerPath パラメータを設定します。
ServerPath パラメータは、キャッシュ、ログ記録、および状態監視の Web
エージェント リソースに一意の識別子を指定します。 各サーバ インスタ
ンスが独自のエージェント リソースのセットを持つように、ServerPath パ
ラメータの値は一意である必要があります。
たとえば、server_instance_root/logs など、Web サーバのログ ファイルが保
管されるディレクトリに ServerPath パラメータを設定できます。
環境内に仮想ホストがある場合、ServerPath パラメータが各
WebAgent.conf ファイルにあることを確認します。
ServerPath パラメータが各 WebAgent.conf ファイルにあることを確認する方法
1. ディレクトリ sps_home¥secure-proxy¥proxy-engine¥conf¥defaultagent
の WebAgent.conf ファイルに移動します。
2. ファイルを開きます。
3. ServerPath 設定が一意の文字列またはパスに設定されていることを確
認します。
Windows の場合、任意の一意の文字列を指定できます。 UNIX の場合、
一意のシステム パスを指定します。
4. WebAgent.conf ファイルを保存します。
第 8 章： SPS ログ設定の設定 169
第 9 章： プロキシ ルールの設定
このセクションには、以下のトピックが含まれています。
プロキシ ルールの概要 (P. 171)
プロキシ ルール設定ファイルの確立 (P. 176)
プロキシ ルール DTD (P. 177)
nete:xprcond エレメントの動作のしくみ (P. 191)
正規表現の構文 (P. 192)
転送フィルタ、リダイレクト フィルタ、結果フィルタでのヘッダ値 (P. 197)
レスポンス処理 (P. 198)
プロキシ ルールの変更 (P. 199)
サンプル プロキシ ルール設定ファイル (P. 199)
プロキシ ルールの概要
CA SiteMinder for Secure Proxy Server の主な目的は、企業内の適切な送信先
サーバにリクエストをルーティングすることです。 CA SiteMinder for
Secure Proxy Server は、サーバに組み込まれているプロキシ エンジンを使
用して、リクエストをルーティングします。 プロキシ エンジンはプロキ
シ ルールを解釈して、転送サービスおよびリダイレクト サービスを提供
し、バック エンド リソースに対するすべてのユーザ リクエストの配置を
処理します。
プロキシ ルールでは、企業内の送信先サーバに配置されたリソースへの
リクエストを CA SiteMinder for Secure Proxy Server が転送およびリダイレ
クトする方法の詳細を定義します。CA SiteMinder for Secure Proxy Server と
共にインストールされているプロキシ ルール DTD に従って、プロキシ
ルールのセットが XML 設定ファイルで定義されます。
注： proxyrules.xml ファイルには、リクエストを http://www.ca.com$0 に転
送するデフォルト ルールが含まれています。これは、送信先（この場合、
www.ca.com）への元のリクエストからの URI 全体に $0 が追加されていま
す。 ユーザの環境に合わせて、このルールを変更する必要があります。
詳細情報：
プロキシ ルール DTD (P. 177)
第 9 章： プロキシ ルールの設定 171
プロキシ ルールの概要
受信リクエストのルートの計画
proxyrules.xml ファイルをセットアップする前に、受信リクエスト用の
ルーティングを綿密に計画する必要があります。 リクエストされたリ
ソースを含む仮想ホストに応じて、プロキシ ルールはデフォルト送信先
を使用できます。ユーザ エージェント タイプに基づく、または HTTP ヘッ
ダ値を使用するリクエストを転送し、リクエストに対応する送信先サーバ
を確定します。 CA SiteMinder for Secure Proxy Server では、多くの仮想ホス
トへのアクセスが提供されます。
以下の図では、適切な送信先サーバにリクエストをルーティングするため
に、プロキシ ルールを使用する方法を示します。
注： プロキシ ルール設定ファイルは、CA SiteMinder for Secure Proxy Server
によって上から下まで処理されます。 受信リクエストが満たす最初の条
件によって、プロキシ エンジンの動作が確定されます。 たとえば、1 セッ
トのプロキシ ルールにリクエストの URI に含まれている文字列に基づい
た 2 つの条件があり、受信リクエストの URI の一部が文字列の両方に一致
する場合、プロキシ ルール ファイルで一覧表示された最初の条件がリク
エストをルーティングするために使用されます。
172 管理ガイド
プロキシ ルールの概要
また、送信先サーバにリクエストを直接送信するために、プロキシ ルー
ルを使用してより多くの複合条件を制御することもできます。
以下の図では、親条件内で入れ子にされた条件の第 2 レベルでプロキシ
ルールを使用する方法を示します。
第 9 章： プロキシ ルールの設定 173
プロキシ ルールの概要
プロキシ ルールの用語
プロキシ ルール設定ファイルは、ユーザ リクエストをルーティングする
場合に、CA SiteMinder for Secure Proxy Server が使用する XML エレメントを
記述したファイルです。 以下の用語を使って、プロキシ ルールを記述し
ます。
送信先
送信先はリクエストを満たしている URL です。CA SiteMinder for Secure
Proxy Server は、送信先にリクエストを転送するか、送信先を指定した
ユーザにリダイレクト レスポンスを送信します。 1 セットのプロキシ
ルールには、プロキシ ルールで定義された条件とケースに従って到達
できる送信先を記述する必要があります。
条件
条件は、CA SiteMinder for Secure Proxy Server がリクエストの送信先を
決定できるようにするリクエストの属性です。 条件には、リクエスト
を適切な送信先に配信するために CA SiteMinder for Secure Proxy Server
が評価するさまざまなケースがあります。 各条件には、リクエストが
条件内で定義したケースのいずれにも一致しなかった場合の動作を定
義するデフォルト エレメントを含む必要があります。
condition には、以下の 1 つまたは複数の項目が含まれていることがあ
ります。
URI
CA SiteMinder for Secure Proxy Server は、リクエストをルーティング
する方法を決定するため、ホスト名の後に続く、リクエストされ
た URL 部分を使用します。 DTD に記述されている基準を使って、
URI の一部（リクエストされたリソースのファイル拡張子など）を、
リクエストのルーティングに使用することができます。
クエリ文字列
CA SiteMinder for Secure Proxy Server は、リクエストをルーティング
する方法を決定するため、URI のクエリ文字列部分を使用します。
クエリ文字列には、リクエスト内の '?' に続く文字がすべてを含ま
れます。
174 管理ガイド
プロキシ ルールの概要
ホスト
CA SiteMinder for Secure Proxy Server は、リクエストをルーティング
する方法を決定するため、リクエストされたサーバのホスト名を
使用します。 ホスト名のポート番号もリクエストのルーティング
基準として使用できます。 プロキシに複数の仮想サーバが含まれ
ている場合、この条件が使用されます。
ヘッダ
CA SiteMinder for Secure Proxy Server は、リクエストをルーティング
する方法を決定するため、任意の HTTP ヘッダの値を使用します。
リソースにアクセスするために使用しているデバイスのタイプに
基づいてリクエストをルーティングするため、USER_AGENT HTTP
ヘッダに従って、リクエストをルーティングすることができます。
注： SiteMinder レスポンスから取得した HTTP ヘッダは、リクエス
トをルーティングする方法を決定するために使用できます。
Cookie
CA SiteMinder for Secure Proxy Server は、リクエストをルーティング
する方法を決定するため、Cookie の有無または値を使用します。
Cookie 値がエンコードされている場合、エンコーディング パラ
メータでエンコーディング スキームを指定します。 CA SiteMinder
for Secure Proxy Server は base64 エンコーディング スキームだけを
サポートします。
ケース
ケースとは、リクエストの最終送信先を決定するために、CA SiteMinder
for Secure Proxy Server が必要とする情報を提供する条件の一連の固有
値です。 たとえば、1 セットのプロキシ ルールがホスト条件を使用す
る場合、ケースには home.company.com や banking.company.com など、
システムに対して設定された仮想ホストが含まれます。
第 9 章： プロキシ ルールの設定 175
プロキシ ルール設定ファイルの確立
プロキシ ルール設定ファイルの確立
プロキシ ルール設定ファイルは、server.conf ファイル内の
<ServiceDispatcher> エレメントの rules_file ディレクティブによって識別さ
れる XML 設定です。 rules_file ディレクティブは、インストール ディレク
トリからプロキシ ルール設定ファイルまでの相対パスを示します。 イン
ストール時に、デフォルトのプロキシ ルール設定ファイルへの相対パス
が自動的に生成され、デフォルト仮想ホストの rules_file ディレクティブに
挿入されます。
生成されるパスおよびプロキシ ルール ファイル名を以下に示します。
sps_home/secure-proxy/proxy-engine/conf/proxyrules.xml
proxyrules.xml ファイル内のエントリの形式はすべて適切で、XML 仕様に
従った構文規則を満たしている必要があります。 プロキシ ルール設定
ファイルへの変更を有効にするために、サーバを再起動する必要はありま
せん。CA SiteMinder for Secure Proxy Server は、ファイルへの変更を検出し
て、新しいプロキシ ルール ファイルをロードします。
注： CA SiteMinder for Secure Proxy Server は、リクエストを満たしている
バックエンド サーバのマルチバイト文字セット（MBCS） URL へ送信され
たリクエストへの対応をサポートしています。
ルールの解析時に CA SiteMinder for Secure Proxy Server がプロキシ ルール
のエラーを検出すると、CA SiteMinder for Secure Proxy Server はサーバ ログ
にエラーを記録し、変更を無視して、既存のプロキシ ルールを使用しま
す。 サーバ ログ ファイルの場所は、logger.properties ファイルで指定しま
す。
詳細情報：
server.conf ファイル内のサービス ディスパッチャ設定 (P. 120)
176 管理ガイド
プロキシ ルール DTD
プロキシ ルール DTD
プロキシ ルール DTD を使用して、proxyrules.xml ファイルを作成する必要
があります。 プロキシ ルール DTD を表示するには、以下のディレクトリ
に移動します。
sps_home¥secure-proxy¥proxy-engine¥conf¥dtd
以下のエレメントを DTD で設定可能です。
■
nete:proxyrules
■
nete:description
■
nete:case
■
nete:cond
■
nete:default
■
nete:forward
■
nete:redirect
■
nete:local
■
nete:xprcond
nete:proxyrules
nete:proxyrules エレメントの詳細な定義は次のとおりです。
<!ELEMENT nete:proxyrules (nete:description?,(nete:cond | nete:forward |
nete:redirect | nete:local)) >
このエレメントはプロキシ ルール XML 設定ファイルのルート エレメント
です。 このエレメントにはオプションの nete:description エレメントと、
以下のいずれかのエレメントが含まれます。
■
nete:cond
■
nete:xprcond
第 9 章： プロキシ ルールの設定 177
プロキシ ルール DTD
■
nete:forward
■
nete:redirect
■
nete:local
nete:proxyrules エレメントはプロキシ ルール設定ファイル内に指定され
ている必要があります。
デバッグ属性
nete:proxyrules エレメントには以下の属性があります。
<ATTLIST nete:proxyrules
debug (yes|no) "no"
この属性は、プロキシ ルールのデバッグを支援するログ記録を有効また
は無効にします。 この属性のデフォルトは no です。ログ記録を有効にす
るには、この属性を yes に設定します。
例：
<nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">
有効にすると、CA SiteMinder for Secure Proxy Server のトレース ログ情報が
トレース ログに含まれます。 ログ ファイルの場所は、CA SiteMinder for
Secure Proxy Server インストール処理時に指定したエージェント設定オブ
ジェクトの TraceFileName パラメータによって決定します。 同じエージェ
ント設定オブジェクトの TraceConfigFile パラメータは、セキュア プロキシ
固有のトレース ログ設定ファイルを指している必要があります。
デフォルトでは、このファイルは以下の場所にあります。
<install-dir>¥proxy-engine¥conf¥defaultagent¥SecureProxyTrace.conf
注： この変更を有効にするために CA SiteMinder for Secure Proxy Server の
再起動は必要ありません。
178 管理ガイド
プロキシ ルール DTD
nete:description
nete:description エレメントの詳細な定義は次のとおりです。
<!ELEMENT nete:description (#PCDATA)>
これは、別のエレメントの解析された文字データ（PCDATA）説明が含ま
れるオプションのエレメントです。
注： PCDATA はマークアップ テキストでない任意のテキストです。
nete:description エレメントは nete:proxyrules エレメントの子になること
ができ、ユーザが選ぶ説明が含まれる可能性があります。
nete:case
nete:case エレメントは、nete:cond 親エレメントで定義された条件の特定
の値と関連付けられた送信先を指定します。CA SiteMinder for Secure Proxy
Server は、nete:case エレメントの値を使用してケースを評価します。
nete:case エレメントの定義は次のとおりです。
<!ELEMENT nete:case (nete:cond | nete:xprcond | nete:forward | nete:redirect |
nete:local)>
すべての nete:case エレメントは以下のいずれかの子エレメントを含む必
要があります。
nete:cond
nete:cond エレメントは追加の nete:cond エレメントを含むことができ
ます。 このため、一連のプロキシ ルールの中に複数の条件を入れ子に
することができます。
nete:xprcond
nete:case エレメントは、正規表現による URI 照合のための追加の
nete:xprcond エレメントを含むことができます。 このため、一連の他
の条件の中に正規表現条件を入れ子にすることができます。
第 9 章： プロキシ ルールの設定 179
プロキシ ルール DTD
nete:forward
nete:case 比較条件を満たすリクエストが転送される送信先を指定し
ます。
nete:redirect
nete:case 比較条件を満たすリクエストがリダイレクトされる送信先
を指定します。 リダイレクトされたリクエストは、CA SiteMinder for
Secure Proxy Server 経由ではなく、送信先サーバによって直接処理され
ます。
以下の例では、nete:cond エレメントは URI 照合を指定し、nete:case エレ
メントは、比較型の属性の可能な用途を示しています。
<nete:cond type="uri" criteria="beginswith">
<nete:case value="/hr">
<nete:forward>http://hr.company.com$0</nete:forward>
</nete:case>
<nete:case value="/employee">
<nete:forward>http://employees.company.com$1
</nete:forward>
</nete:case>
</nete:cond>
注： <nete:forward>URL</nete:forward> エレメントは同じ行に指定する必要
があります。 例では、終了タグである </nete:forward> がスペースの制約
により別の行に示されていますが、実際のプロキシ ルール ファイル内で
改行するとエラーになります。 CA SiteMinder for Secure Proxy Server は、終
了タグ </nete:forward> の前の改行を、nete:forward エレメントに含まれる
URL の一部として解釈します。
180 管理ガイド
プロキシ ルール DTD
転送とリダイレクトの構文
リクエストを転送またはリダイレクトする場合、CA SiteMinder for Secure
Proxy Server は、ユーザによって指定された URI （Universal Resource
Indicator）の一部または全体を維持するためにシステムを使用します。 こ
の URI は、送信先サーバ上にあるリソースをポイントし、リクエストを処
理するために CA SiteMinder for Secure Proxy Server によって解釈される必
要があります。
転送先またはリダイレクト先に指定された URL に以下のどちらかを追加
できます。
$0
ユーザのリクエストからプロキシ ルールで指定された送信先に URI
文字列全体を追加します。
たとえば、プロキシ ルールで www.company.com に対するすべての
ユーザ リクエストが proxy.company.com$0 に転送される場合、
proxy.company.com/employees/hr/index.html に対するユーザ リクエス
トは www.company.com/employees/hr/index.html に転送されます。
$1
親の nete:cond エレメントが開始文字の比較を使用して URI サブスト
リング一致を指定する nete:case エレメントでのみ使用できます。 $1
は、一致するテキストの右にあるものすべてが、転送またはリダイレ
クトされるリクエストに追加されることを示します。
たとえば、次の nete:cond エレメントがあるプロキシ ルール設定ファ
イルを考えます：
<nete:cond type="uri" criteria="beginswith">
この条件が、www.company.com というホスト名および次の nete:case
エレメントの URI を評価する条件の子であると仮定します：
<nete:case value="/hr">
<nete:forward>http://hr.company.com$1</nete:forward>
</nete:case>
第 9 章： プロキシ ルールの設定 181
プロキシ ルール DTD
ユーザが以下のようにリクエストした場合：
http://www.company.com/hr/employees/index.html
そのリクエストは以下に転送されます：
http://hr.company.com/employees/index.html
注： この例は $1 パラメータを指定するので、リクエストが
hr.company.com に転送される際、URI の /hr 部分が省略されます。
nete:cond
nete:cond エレメントの定義は次のとおりです。
<!ELEMENT nete:cond (nete:case+,nete:default)>
さらに、nete:cond エレメントには以下の属性があります。
<!ATTLIST nete:cond type (header | host | uri | query | cookie) #REQUIRED
criteria (equals | beginswith | endswith | contains | exists) "equals"
headername CDATA #IMPLIED>
nete:cond エレメントは、CA SiteMinder for Secure Proxy Server が受信リクエ
ストを処理する方法を決定するため、評価しなければならない条件を指定
します。 このエレメントには、CA SiteMinder for Secure Proxy Server によっ
て評価される属性を含める必要があります。
182 管理ガイド
プロキシ ルール DTD
ATTLIST エレメントで定義する使用可能な属性を以下に示します。
ヘッダ
HTTP ヘッダを指定します。 HTTP ヘッダは、SiteMinder がユーザ ディ
レクトリから取得できる名前/値のペアです。 タイプとして header を
選択した場合、ヘッダの名前も指定する必要があります。 ヘッダをタ
イプとして使用する nete:cond エレメントの例を以下に示します。
<nete:cond type="header" headername="USER_AGENT">
このエレメントは、リクエストの送信先を決定するためにヘッダが使
われること、および CA SiteMinder for Secure Proxy Server が評価する
ヘッダは USER_AGENT であることを示します。 リクエストの実際の送
信先は、nete:cond エレメントの子である nete:case エレメントによっ
て決まります。詳細は次のセクションを参照してください。
ヘッダを比較として使用する条件では、headername="value" という追
加の引数を必要とします。ここで value は、HTTP または SiteMinder の
ヘッダ名です。
注： SiteMinder レスポンスによって生成される HTTP ヘッダは、
nete:cond エレメントで指定できます。
ホスト
複数の仮想ホスト用に CA SiteMinder for Secure Proxy Server プロキシす
る導入内のホスト名を指定します。
ポート番号はホストの一部と見なされるため、後述する endswith 基準
をホスト条件を組み合わせて使用し、ポート番号に応じてリクエスト
をルーティングすることができます。
クエリ
'?' 文字の後の URI のクエリ文字列部分を指定します。 これは、以下の
ように URI を利用する nete:cond に似ています。
URI
URI（Universal Resource Indicator）を指定します。これはサーバ名
の後に続く、リクエストされた URI 部分です。
endswith 基準と URI 条件を組み合わせて使用して、ファイル拡張子
に応じてリクエストをルーティングすることができます。
第 9 章： プロキシ ルールの設定 183
プロキシ ルール DTD
Cookie
リクエストをルーティングする方法を決定するため、Cookie 属性を指
定します。 Cookie 値がエンコードされている場合、エンコーディング
パラメータでエンコーディング スキームを指定します。CA SiteMinder
for Secure Proxy Server は、base64 エンコーディング スキームのみをサ
ポートし、Cookie 作成をサポートしません。 エンコードされた Cookie
が考えられるケースを以下に示します。
■
base64 を使って Cookie がエンコードした場合、value 属性で Cookie
値を指定し nete:case エレメントのエンコーディング パラメータ
として base64 を指定します。 CA SiteMinder for Secure Proxy Server
は base64 エンコーディング アルゴリズムを使って httprequest か
ら受信した Cookie 値をデコードし、デコードされた結果の値と、
value 属性で指定した値を比較します。
■
Cookie がエンコードされていない場合、Value 属性で Cookie 値をプ
レーン テキストとして入力します。またエンコーディング パラ
メータを nete:case エレメント内でブランクとして指定できます。
CA SiteMinder for Secure Proxy Server は Cookie 値として指定された
プレーン テキストを承認し、nete:cond を確認します。
別のエンコーディング スキームを使って Cookie がエンコードされて
いる場合、エンコードされた Cookie 値を Value 属性で入力します。ま
たエンコーディング パラメータを nete:case エレメント内でブランク
として指定します。 CA SiteMinder for Secure Proxy Server は、指定され
たエンコード Cookie 値をプレーン テキストとして承認し、プレーン
テキストの Cookie 値を使って nete:cond を確認します。
前述のタイプ属性のいずれかを、nete:cond エレメント内で記述する必要
があります。 さらに、nete:cond エレメントは、比較を定義する基準を指
定する必要があります。この基準は、受信リクエストに対する条件値に関
してプロキシ エンジンが実行する比較で使われます。 使用可能な基準は
次のとおりです。
equals
nete:cond 親エレメントのタイプ属性の値が、リクエストに対して動作
する nete:case エレメントの Value 属性の内容と一致する必要がある
ことを示します。
beginswith
nete:cond 親エレメントのタイプ属性の値が、リクエストに対して動作
する nete:case エレメントの Value 属性の内容で始める必要があるこ
とを示します。
184 管理ガイド
プロキシ ルール DTD
endswith
nete:cond 親エレメントのタイプ属性の値が、リクエストに対して動作
する nete:case エレメントの Value 属性の内容で終了する必要がある
ことを示します。
contains
nete:cond 親エレメントのタイプ属性の値が、リクエストに対して動作
する nete:case エレメントの Value 属性の内容を含んでいる必要があ
ることを示します。
exists
nete:cond 親エレメントが存在する必要があり、リクエストに対して動
作するには、nete:case エレメントの Value 属性は true でなければなら
ないことを示します。 exists 基準は、ヘッダおよび Cookie 属性に対し
てのみ使用できます。
注： 基準が指定されていない場合、CA SiteMinder for Secure Proxy Server は、
デフォルトの基準が equals であると見なします。
各 nete:cond エレメントにはそれぞれ 1 つ以上の nete:case 子エレメント
が必要です。 nete:case 子エレメントは、CA SiteMinder for Secure Proxy
Server がリクエストを適切な送信先へルーティングするために使用する
一意の値を提供します。
nete:default
nete:default エレメントの定義は次のとおりです。
<!ELEMENT nete:default (nete:cond | nete:xprcond | nete:forward | nete:redirect |
nete:local)>
このエレメントは必須で、各 nete:cond エレメントの子エレメントである
必要があります。 リクエストが、nete:cond エレメント内に含まれるどの
nete:case エレメントの要件も満たさない場合、nete:default エレメントに
よってリクエストの処理方法が決定します。
nete:default エレメントと関連付けられた子エレメントとして使用できる
エレメントは、nete:case エレメントで使用可能なエレメントと同じです。
nete:cond エレメントを nete:default の子として作成する場合は、可能性が
あるすべてのクライアント リクエストを CA SiteMinder for Secure Proxy
Server で処理できるように、デフォルトのケースを考慮する必要がありま
す。
第 9 章： プロキシ ルールの設定 185
プロキシ ルール DTD
以下の例では、nete:default エレメントは、他のプロキシ ルールの基準を
満たすすべてのリクエストを全般情報のホーム ページに転送します。
<nete:default>
<nete:forward>http://home.company.com/index.html
</nete:forward>
</nete:default>
開始タグと終了タグである <nete:forward>URL</nete:forward> エレメント
は同じ行に指定する必要があります。 例では、終了タグである
</nete:forward> がスペースの制約により別の行に示されていますが、実際
のプロキシ ルール ファイル内で改行するとエラーになります。 CA
SiteMinder for Secure Proxy Server は、終了タグ </nete:forward> の前の改行
を、nete:forward エレメントに含まれる URL の一部として解釈します。
nete:forward
nete:forward エレメントの定義は次のとおりです。
<!ELEMENT nete:forward (#PCDATA)>
nete:forward エレメントは指定された URL にリクエストを転送します。
注： <nete:forward> タグと </nete:forward> タグは、プロキシ ルール ファイ
ル内に 1 行で指定する必要があります。 これらが同じ行にない場合、CA
SiteMinder for Secure Proxy Server は改行をエレメントに含まれる URL の一
部として解釈します。 そのため転送サービスが失敗します。
以下の例で、nete:forward エレメントはユーザによってリクエストされた
URI を保持しながらリクエストを転送します。
<nete:forward>http://home.company.com$0</nete:forward>
ユーザのリクエストが nete:case 親エレメントの条件を満たす場合、その
リクエストは home.company.com に転送されます。 そのため、前の
nete:forward エレメントによって転送される
http://server.company.com/hr/benefits/index.html に対するリクエストは、リ
クエストを http://home.company.com/hr/benefits/index.html に転送するこ
とによって処理されます。
SSL でリクエストを転送する場合、<nete:forward> エレメントに含まれる送
信先を定義するときに必ず http ではなく https を使用してください。
186 管理ガイド
プロキシ ルール DTD
nete:forward エレメントには以下の属性が含まれます。
<!ATTLIST nete:forward filter CDATA #IMPLIED>
この属性では、CA SiteMinder for Secure Proxy Server から送信先サーバへの
転送時に呼び出すことができる Java フィルタ クラスの名前を指定できま
す。 フィルタはフィルタ API を使用して作成できます。
詳細情報：
転送とリダイレクトの構文 (P. 181)
API の概要のフィルタ (P. 317)
フィルタ属性
nete:forward エレメントには以下の属性が含まれます。
<!ATTLIST nete:forward filter CDATA #IMPLIED>
この属性では、CA SiteMinder for Secure Proxy Server から送信先サーバへの
転送時に呼び出すことができる java フィルタ クラスの名前を指定できま
す。 フィルタはフィルタ API に従って作成できます。
nete:redirect
nete:redirect エレメントの定義は次のとおりです。
<!ELEMENT nete:redirect (#PCDATA)>
nete:redirect エレメントでは、ユーザのリクエストを適切な送信先サーバ
にリダイレクトする、ユーザに返すレスポンスを指定します。 PCDATA は
標準の転送およびリダイレクト構文に従います。 一度リダイレクトされ
たら、CA SiteMinder for Secure Proxy Server はリクエストの完了を処理しま
せん。 代わりに、そのリクエストはリダイレクト先のサーバによって処
理されます。
<nete:redirect> および </nete:redirect> タグは、プロキシ ルール ファイル内
の単一行に配置される必要があります。 これらが同じ行にない場合、CA
SiteMinder for Secure Proxy Server は改行をエレメントに含まれる URL の一
部として解釈します。 これによって、リダイレクト サービスが失敗しま
す。
第 9 章： プロキシ ルールの設定 187
プロキシ ルール DTD
以下の例では、nete:redirect エレメントはユーザからリクエストされた
URI を保持しながら、リクエストをリダイレクトします。 nete:forward と
は異なり、一度リクエストがリダイレクトされると、CA SiteMinder for
Secure Proxy Server はトランザクションから削除され、送信先サーバが直
接ユーザにリソースを提供します。
<nete:redirect>http://home.company.com$0</nete:redirect>
http://www.company.com/hr/index.html に対するユーザのリクエストが親
nete:case に一致し、上記の例によってリダイレクトされる場合、ユーザは
リダイレクトされ、ユーザのブラウザにはリクエストに対応する送信先
サーバの URL が次のように表示されます。
http://home.company.com/hr/index.html
注： SSL によってリクエストをリダイレクトする場合、<nete:redirect> エレ
メントに含まれる送信先を定義する際に、http ではなく必ず https を使用
してください。
詳細情報：
転送とリダイレクトの構文 (P. 181)
nete:local
nete:local エレメントは将来の機能をサポートするために含まれており、
プロキシ ルール設定ファイルに含める必要はありません。
nete:xprcond
nete:xprcond エレメントは、プロキシ ルールの条件として正規表現を適用
する状況で nete:cond エレメントのように使用できます。 正規表現は URI
文字列およびプロキシ ルールに添付されたクエリ文字列を評価するため
に使用できます。
nete:xprcond エレメントの定義は次のとおりです。
<!ELEMENT nete:xprcond (nete:xpr+, nete:xpr-default)>
このエレメントには、1 つ以上の nete:xpr エレメントおよび単一の
nete:xpr-default エレメントを含める必要があります。
188 管理ガイド
プロキシ ルール DTD
nete:xpr および nete:xpr-default
nete:xpr エレメントは nete:cond エレメントと似ていて、CA SiteMinder for
Secure Proxy Server が表現の一致を検索する場合、結果的な動作と正規表
現に基づいたルール用の他のエレメントを含んでいます。 nete:xpr-default
エレメントには、URI のデフォルトの動作またはクエリ文字列の組み合わ
せが含まれます。これは、nete:xprcond エレメント内の nete:xpr エレメン
トに含まれるどの正規表現にも一致しません。
nete:xpr エレメントの定義は次のとおりです。
<!ELEMENT nete:xpr (nete:rule, nete:result)>
nete:xpr エレメントには nete:rule エレメントが含まれます。これは、正規
表現、および正規表現に一致する文字列の動作を指定する nete:result エレ
メントを定義します。
nete:xpr-default エレメントの定義は次のとおりです。
<!ELEMENT nete:xpr-default (nete:forward|nete:redirect|nete:local)>
CA SiteMinder for Secure Proxy Server によって評価されている URI またはク
エリ文字列が、親 nete:xprcond エレメントに含まれている nete:xpr エレメ
ントのいずれかで述べられた条件に一致しない場合、nete:xpr-default エレ
メントは完了される必要のある転送またはリダイレクトを指定します。
nete:rule および nete:result
nete:rule および nete:result エレメントは nete:xpr エレメントに含まれて
いる必要があります。 nete:rule エレメントは、CA SiteMinder for Secure
Proxy Server が受信リクエストと照合して評価する正規表現を指定します。
nete:result エレメントは一致するリクエストの動作を確定します。
nete:rule エレメントの定義は次のとおりです。
<!ELEMENT nete:rule (#PCDATA)>
このエレメントには、正規表現である文字列が含まれます。 リクエスト
が nete： xpr 条件を満たすかどうかを判断するため、リクエストの URI お
よびクエリの文字列をこの正規表現と一致させます。
第 9 章： プロキシ ルールの設定 189
プロキシ ルール DTD
nete:result エレメントの定義は次のとおりです。
<!ELEMENT nete:result (#PCDATA)>
nete:result エレメントには以下の属性がある可能性があります。
<!ATTLIST nete:result service (forward|redirect) "forward">
このエレメントには、CA SiteMinder for Secure Proxy Server がサービスへ渡
す（転送またはリダイレクト） URL を作成する置換文字列（URL）で構成
される文字列が含まれます。 サービス属性は URL を受信する適切なサー
ビスを指定するために使用されます。 デフォルト サービスは server.conf
設定ファイルで定義された転送サービスです。
nete:result エレメント内の置換 URL は、オプションで $# （# は 0、1、2 な
ど）が含まれる URL である必要があります。
■
$0 では URI およびクエリ文字列全体が評価されています。
■
$n は、関連する nete:rule エレメントで説明された正規表現の丸かっこ
の n 番目のセットに一致した、リクエストされた URI の一部です。
たとえば、1 セットのプロキシ ルールには以下が含まれる可能性がありま
す。
<nete:xprcond>
<nete:xpr>
<nete:rule>^/realma(.*)</nete:rule>
<nete:result>http://server1.company.com$1</nete:result>
</nete:xpr>
<nete:xpr-default>
<nete:forward>http://www.company.com$0</nete:forward>
</nete:xpr-default>
</nete:xprcond>
190 管理ガイド
nete:xprcond エレメントの動作のしくみ
<nete:result>URL</nete:result> タグをプロキシ ルール ファイルの単一の行
に置く必要があります。 それらが同じ行に置かれない場合、CA SiteMinder
for Secure Proxy Server はエレメントに含まれる URL の一部として行侵入
と解釈します。 これが原因で、結果的に生じたサービスは失敗します。
前の nete:xprcond プロキシ ルールの例では、以下のリクエストがあります。
http://www.company.com/realma/index.html
以下へ転送されます。
http://server1.company.com/index.html
nete:xprcond エレメントの動作のしくみ
nete:xprcond エレメントの処理は、他のすべての nete:cond エレメントの
処理に似ています。CA SiteMinder for Secure Proxy Server がリクエストを処
理すると、プロキシ ルール設定ファイル内の nete:xprcond エレメントに遭
遇するため、以下が発生します。
1. CA SiteMinder for Secure Proxy Server は nete:xprcond エレメント内の最
初の nete:xpr エレメントを検査します。
2. プロキシ エンジンは、リクエストの URI およびクエリ文字列に対して、
nete:rule エレメントに記述された正規表現を評価します。
3. リクエストされた URI およびクエリ文字列が nete:rule エレメントで指
定された正規表現に一致する場合、CA SiteMinder for Secure Proxy Server
は一致結果を使用して結果文字列を解決します。また、リクエストは
nete:result エレメントから派生した URL の指定されたサービスに転送
されます。
4. リクエストされた URI およびクエリ文字列が最初の nete:xpr エレメン
トの正規表現に一致しない場合、プロキシ ルール エンジンは次の
nete:xpr エレメントを評価します（手順 2 および 3 を繰り返す）。 こ
のプロセスは、ルール エンジンが一致を検索するか、nete:xpr-default
に到達するまで続行されます。
5. nete:xpr-default に到達するまで一致が見つからない場合、
nete:xpr-default エレメントのコンテンツがリクエストのルーティング
方法を決定します。
第 9 章： プロキシ ルールの設定 191
正規表現の構文
正規表現の構文
このセクションでは、nete:rule エレメント用の正規表現を作成するために
使用する必要のある構文について説明します。 nete:xprcond エレメントは
以下のフォームを取得します。
<nete:xprcond>
<nete:xpr>
<nete:rule>regular_expression</nete:rule>
<nete:result>result</nete:result>
</nete:xpr>
<nete:xpr-default>forward_destination</nete:xpr-default>
</nete:xprcond>
nete:xpr エレメントで、nete:rule エレメントは以下の表に示されている構
文を使用する、正規表現から構成される必要があります。 この構文は
Apache によってサポートされ、http://www.apache.org に記述されている正
規表現の構文と同じです。
文字
結果
Unicode 文字
任意の同一の Unicode 文字と一致
¥
メタキャラクタ（「*」など）を引用する場合に使用
¥¥
1 つの「¥」文字と一致
¥0nnn
任意の 8 進数文字と一致
¥xhh
任意の 8 ビットの 16 進数文字と一致
¥¥uhhhh
任意の 16 ビットの 16 進数文字と一致
¥t
ASCII タブ文字と一致
¥n
ASCII 改行記号と一致
¥r
ASCII 段落記号と一致
¥f
ASCII 改ページ文字と一致
[abc]
単純な文字クラス
[a-zA-Z]
範囲での文字クラス
[^abc]
文字 abc... 以外の任意の 1 文字に一致
[:alnum:]
英数字
192 管理ガイド
正規表現の構文
文字
結果
[:alpha:]
英文字
[:blank:]
スペースおよびタブ文字
[:cntrl:]
制御文字
[:digit:]
数字
[:graph:]
印刷可能かつ表示可能な文字（スペースは印刷できるが、表示さ
れない。「a」は印刷および表示可能）
[:lower:]
小文字の英文字
[:print:]
印刷可能な文字（制御文字でない文字）
[:punct:]
句読点記号（英字、数字、制御文字またはスペース文字でない文
字）
[:space:]
スペース文字（スペース、タブおよび改ページなど）
[:upper:]
大文字の英文字
[:xdigit:]
16 進数の文字
[:javastart:]
Java 識別子の開始
[:javapart:]
Java 識別子の一部
.
改行以外の任意の 1 文字と一致
¥w
「単語」文字に一致（英数字と「_」）
¥W
単語以外の文字に一致
¥s
空白文字に一致
¥S
空白以外の文字に一致
¥d
数字に一致
¥D
数字以外の文字に一致
^
行の先頭に一致
$
行の末尾に一致
¥b
ワード バウンダリでのみ一致
¥B
ワード バウンダリ以外でのみ一致
A*
A が 0 回以上繰り返すものに一致（greedy）
A+
A が 1 回以上繰り返すものに一致（greedy）
第 9 章： プロキシ ルールの設定 193
正規表現の構文
文字
結果
A?
A が 1 回または 0 回現れるものに一致（greedy）
A{n}
A が正確に n 回繰り返すものに一致
（greedy）
A{n,}
A が尐なくとも n 階繰り返すものに一致
（greedy）
A{n,m}
A が n 回以上、m 回以下繰り返すものに一
致 （greedy）
A*?
A が 0 回以上繰り返すものに一致（reluctant）
A+?
A が 1 回以上繰り返すものに一致（reluctant）
A??
A が 0 回または 1 回現れるものに一致（reluctant）
AB
A の後に B が続くものに一致
A|B
A または B のいずれかが現れるものに一致
(A)
サブ式のグループ化に使用
¥1
1 番最初のかっこで囲まれた副次式への後方参照
¥n
n 番目のかっこで囲まれた副次式への後方
参照
量指定子（+、*、?、{m,n}）はデフォルトで Greedy です。つまり、全体的
な照合を中断することなく、文字列内で可能な限り多くの要素と一致しま
す。 控えめ（Non-greedy）な照合を行うには、量指定子に「?」を追加し
ます。 控えめな量指定子を使用すると、照合時に文字列のできるだけ尐
ない要素と一致します。 現在、{m,n} では控えめな量指定子はサポートさ
れません。
194 管理ガイド
正規表現の構文
nete:rule および nete:result の正規表現の例
正規表現では、CA SiteMinder for Secure Proxy Server プロキシ ルールで使用
できる、非常に柔軟かつ強力なツールを提供します。 このセクションで
は、プロキシ ルールの数尐ない nete:rule エレメントの例を示します。 さ
らに、この例には nete:result エレメントのさまざまな使用法も含まれてい
ます。これは、nete:xprcond エレメントの子によって生成された送信先に
反映させるために nete:rule のグループをどのように使用できるかを示し
ています。
多くの送信先サーバへの単一ルールのマップ
以下の例では、nete:rule エレメントには正規表現が含まれ、さまざまな送
信先にリクエストを転送するために使用できます。 この例では、CA
SiteMinder for Secure Proxy Server が以下のフォームを取る URI を受信する
と仮定します。
/GOTO=パスおよび（または）ファイル名
以下の子エレメントを含む nete:xprcond エレメントを考慮します。
<nete:xpr>
<nete:rule>/GOTO=(.*)/(.*)</nete:rule>
<nete:result>http://$1/$2</nete:result>
</nete:xpr>
nete:rule エレメントおよび関連する nete:result エレメントの正規表現は、
/GOTO=string を生成する URI に一致します。 一致が見つかると、CA
SiteMinder for Secure Proxy Server は URI の = 記号の後にある最初の文字列
を結果の値の $1 として使用し、= 記号の後に表示される最初の / 記号の後
の値を $2 の結果として使用します。nete:result エレメントは、URL を作成
するためにこれらのエレメントを組み合わせます。 デフォルトでは、
nete:result エレメントは CA SiteMinder for Secure Proxy Server の転送サービ
スを使用します。
第 9 章： プロキシ ルールの設定 195
正規表現の構文
たとえば、上述の nete:xpr エレメントによって評価されたリクエストの
URI が、以下であった場合：
/GOTO=server1.company.com/index.html
その後、nete:rule エレメント内の正規表現は一致を検索し、$1 の値を
server1.company.com として、また、$2 の値を index.html として割り当て
ます。 nete:result エレメントは、これらの値を収集して以下の URL を作成
します。
http://server1.company.com/index.html
この URL は、リクエストを解決するために CA SiteMinder for Secure Proxy
Server が使用するターゲットです。
ユーザをリダイレクトする正規表現
nete:result エレメントを使用し、リソースをリクエストしているユーザに
返すリダイレクト レスポンスを作成することもできます。 これは、認証
および許可の後に、他の CA SiteMinder for Secure Proxy Server のサーバに
よって処理されるリクエストの対応を強制します。 nete:result 子エレメン
トのリダイレクトを指定する nete:xpr エレメントの例を以下に示します。
<nete:xpr>
<nete:rule>/REDIR=(.*)/(.*)</nete:rule>
<nete:result service="redirect">http://$1/$2</nete:result>
</nete:xpr>
注： サービス属性は、CA SiteMinder for Secure Proxy Server にデフォルトの
転送サービスの代わりにリダイレクト サービスを使用するように指示し
ます。
196 管理ガイド
転送フィルタ、リダイレクト フィルタ、結果フィルタでのヘッダ値
転送フィルタ、リダイレクト フィルタ、結果フィルタでのヘッダ値
HTTP ヘッダまたは SiteMinder レスポンス ヘッダの値は、nete:forward、
nete:redirect、nete:result のいずれかのエレメントに直接置換できます。
forward または redirect エレメント内の URl、または result フィルタ エレメ
ント内のルールに {{HEADER_NAME}} が含まれる場合、プロキシ エンジン
は指定されたヘッダに一致するヘッダをリクエスト内で検索し、そのヘッ
ダ値を置換してから、forward、redirect、または result を解決します。 一
致するヘッダがリクエスト内に見つからない場合、プロキシ エンジンは
ヘッダ値の代わりに空の文字列を置換します。
注： ヘッダ名は大文字と小文字を区別します。
nete:forward 内の動的なヘッダ値
nete:forward エレメントの一部として動的なヘッダを使用するには、
forward の URL の部分に {{HEADER_NAME}} を入力します。 例：
<nete:forward>http://www.company.com/{{RESPONSE1}}$1</nete:forward>
単一の nete:forward エレメントで複数のヘッダを使用できます。 例：
<nete:forward>http://www.company.com/{{RESPONSE1}}/{{RESPONSE2}}$1
</nete:forward>
nete:redirect 内の動的なヘッダ値
nete:redirect エレメントの一部として動的なヘッダを使用するには、
redirect の URL の部分に {{HEADER_NAME}} を入力します。 例：
<nete:redirect>http://www.company.com/{{RESPONSE1}}$1</nete:redirect>
単一の nete:redirect エレメントで複数のヘッダを使用できます。 例：
<nete:redirect>http://www.company.com/{{RESPONSE1}}/{{RESPONSE2}}$1
</nete:redirect>
第 9 章： プロキシ ルールの設定 197
レスポンス処理
nete:result の動的ヘッダ値
nete:result エレメントの一部として動的ヘッダ値を使用するには、結果の
URL 部分に {{HEADER_NAME}} を挿入するだけです。 例：
<nete:result>http://www.company.com/{{HEADER_NAME}}$1</nete:result>
動的ヘッダ値と共に、フィルタなどのプロキシ ルールの他の機能を使用
できます。 例：
<nete:result filter="filter1">http://$1/$2?{{HEADER_NAME}}</nete:result>
レスポンス処理
CA SiteMinder for Secure Proxy Server は SiteMinder レスポンスを使用し、リ
クエスト用の送信先を決定します。CA SiteMinder for Secure Proxy Server に
よってルーティングされるトランザクションには、CA SiteMinder for
Secure Proxy Server Web エージェントと SiteMinder との相互作用が含まれ
るため、認証および許可プロセス中に収集された SiteMinder レスポンスは、
リクエストの送信先を決定するために CA SiteMinder for Secure Proxy
Server によって使用される場合があります。
たとえば、ユーザ ディレクトリに銀行の Web サイト用のアカウント タイ
プについて情報がある場合、CA SiteMinder for Secure Proxy Server は別の送
信先への別のアカウント タイプでユーザをプロキシできます。 これに
よって、企業は最高の顧客に対して高品質のサービスを提供できます。プ
レミアム アカウントの顧客は高パフォーマンスの送信先サーバの個別の
セットによって処理できますが、標準アカウントの顧客は 1 セットの送信
先サーバによって処理できます。
198 管理ガイド
プロキシ ルールの変更
プロキシ ルールの変更
プロキシ ルールを変更するには、テキスト エディタを使用して、プロキ
シ ルール XML 設定ファイルを編集する必要があります。プロキシ ルール
は XML ファイルであるため、プロキシ ルール設定ファイルは整形式かつ
有効である必要があります。 整形式の XML ファイル内のタグは、すべて
開始タグと終了タグで構成される必要があることに注意してください。
有効にするには、ファイルは proxyrules.dtd で説明されたガイドラインに
準拠する必要があります。
プロキシ ルール XML 設定ファイルへの変更は、SPS によって自動的に取得
されます。CA SiteMinder for Secure Proxy Server ではリクエストを受信する
際に、プロキシ ルールが変更されたかどうかを確認します。 ファイルが
変更されている場合、リクエストに応じる前にルールは再ロードされます。
注： server.conf ファイルの <ServiceDispatcher> エレメントにある rules_file
ディレクティブのプロキシ ルール XML 設定ファイルの名前を変更する場
合、CA SiteMinder for Secure Proxy Server を再起動する必要があります。
サンプル プロキシ ルール設定ファイル
CA SiteMinder for Secure Proxy Server には、プロキシ ルール設定ファイルの
例がいくつかインストールされます。 基礎としてこれらの XML ファイル
の例を自分のプロキシ ルール ファイルに使用できます。
これらのファイルの例をディレクトリ
sps_home¥secure-proxy¥proxy-engine¥examples¥proxyrules で見つけること
ができます。 このガイドの説明を読みながら、ファイルの例を確認する
ことをお勧めします。
ニーズに合うようにファイルをコピーおよびカスタマイズすることがで
きます。
プロキシ ルール ファイルをカスタマイズおよび展開する方法
1. ディレクトリ
sps_home¥secure-proxy¥proxy-engine¥examples¥proxyrules に移動しま
す。
2. 使用するファイルの例をコピーします。
第 9 章： プロキシ ルールの設定 199
サンプル プロキシ ルール設定ファイル
3. コンテンツをカスタマイズし、一意の名前で新しいファイルを保存し
ます。
4. 変更したファイルをディレクトリ
sps_home/secure-proxy/proxy-engine/conf にコピーします。
5. server.conf ファイルを開いて、カスタマイズされたファイルを指す
ファイルのプロキシ ルール セクションを変更します。
プロキシ ルールの例 -- 仮想ホストによるリクエストのルーティング
事例ファイルの proxyrules_example1.xml ファイルは、リクエストで指定さ
れたホスト名に基づいてリクエストをルーティングします。 事例ファイ
ルの proxyrules_example10.xml ファイルは、リクエストで指定されたホス
ト名に基づいて、CA SiteMinder for Secure Proxy Server リクエストもルー
ティングします。CA SiteMinder for Secure Proxy Server は［プロキシ ルール］
の PID を使用して、プロキシ ルールがトリガされた回数を数えます。 CA
SiteMinder for Secure Proxy Server を監視するよう CA Wily Introscope を設定
した場合、回数は CA Wily Introscope データ メトリックに表示されます。
このファイルで、プロキシ ルールの単純なセットは、リクエストされた
リソースで指定された仮想ホストに基づいてユーザ リクエストをルー
ティングします。 bondtrading.company.com サーバへのすべてのリクエス
トは server2 へ転送されます。banking.company.com へのすべてのリクエス
トは server1 へ転送されます。その他のすべてのリクエストは企業のホー
ム サーバへ転送されます。このホーム サーバは、nete:cond の他のどのエ
レメントにも一致しないリクエスト用のデフォルトです。
注： ポート番号はユーザによってリクエストされた仮想ホストの一部と
見なされるので、nete:case エレメントは、ポートを特定する必要がありま
す。 beginswith 条件を使用し、ポート番号の必要性を回避します。
以下のテーブルでは、仮想ホストに基づいてプロキシ ルールを使用したリクエストの結果につ
いて説明しています。
リクエストされた URL
転送された URL
http://banking.company.com/index.html
http://server1.company.com/index.html
http://bondtrading.company.com/index.html
http://server2.company.com/index.html
http://www.company.com/index.html
http://home.company.com/index.html
200 管理ガイド
サンプル プロキシ ルール設定ファイル
プロキシ ルールの例 -- ヘッダ値によるリクエストのルーティング
サンプル ファイルである proxyrules_example2.xml ファイルは、HTTP ヘッ
ダの値に基づいて CA SiteMinder for Secure Proxy Server リクエストをルー
ティングします。 HTTP ヘッダは標準的なヘッダか、SiteMinder レスポン
スを使用して作成されたヘッダです。
この例では、CA SiteMinder for Secure Proxy Server がデフォルトの仮想ホス
ト www.company.com に対するリクエストをルーティングするとします。
このファイルで、HTTP ヘッダ変数 "HEADER" の値は、リクエストの送信先
を決定します。
以下の表は、HTTP ヘッダに基づくプロキシ ルールを使用したリクエスト
の結果を示しています。
リクエストされた URL
転送された URL
http://www.company.com/index.html
http://server1.company.com/index.html
HTTP_HEADER の値：
HTTP_HEADER="value1"
http://www.company.com/index.html
http://server2.company.com/index.html
HTTP_HEADER の値：
HTTP_HEADER="value2"
http://www.company.com/index.html
http://home.company.com/index.html
HTTP_HEADER の値が value1 または value2 以外
の場合。
注：nete:cond エレメントでヘッダ変数名の HTTP_ を含める必要はありま
せん。 CA SiteMinder for Secure Proxy Server は、ヘッダ変数名に HTTP_ を想
定します。
ヘッダ値を使用するプロキシ ルールは、希望するサービス レベルに基づ
いてリクエストを転送する優れた方法です。 たとえば、ユーザ アカウン
ト タイプが含まれる HTTP ヘッダ変数の値を使用して、プレミアム アカウ
ントを持つユーザ向けに、高機能サーバにリクエストを分散できます。
第 9 章： プロキシ ルールの設定 201
サンプル プロキシ ルール設定ファイル
プロキシ ルールの例—デバイス タイプでのリクエストのルーティング
ファイルの例の proxyrules_example3.xml ファイルは、リソースにアクセス
するために使用されるデバイスのタイプに基づいて、CA SiteMinder for
Secure Proxy Server リクエストをルーティングします。
注： ユーザ エージェント HTTP ヘッダ値は、リクエストをルーティングす
る方法を決定するために使用されます。
ファイルで、他のすべてのユーザはワイヤレス サーバに転送されますが、
ブラウザ（ユーザ エージェントには Web ブラウザ用の Mozilla を含む）を
使用してリソースにアクセスするユーザは、Web サーバに転送されます。
以下の表は、デバイス タイプに基づくプロキシ ルールを使用して、リク
エストの結果について説明しています。
リクエストされた URL
転送された URL
http://www.company.com/index.html
http://home.company.com/index.html
Web ブラウザによるユーザ アクセス リソー
ス。
http://www.company.com/index.wml
http://wireless.company.com/index.wml
ワイヤレス デバイスによるユーザ アクセス リ
ソース。
プロキシ ルールの例— URI でのリクエストのルーティング
ファイルの例の proxyrules_example4.xml は、ユーザ リクエストで指定され
た URI に基づいて、CA SiteMinder for Secure Proxy Server リクエストをルー
ティングします。
以下の表は、URI に基づくプロキシ ルールを使用して、リクエストの結果
について説明しています。
リクエストされた URL
転送された URL
http://www.company.com/dir1/index.html
http://server1.company.com/index.html
http://www.company.com/dir2/index.html
http://server2.company.com/index.html
202 管理ガイド
サンプル プロキシ ルール設定ファイル
リクエストされた URL
転送された URL
http://www.company.com/index.html
http://home.company.com/index.html
プロキシ ルールの例—ファイル拡張子でのリクエストのルーティング
ファイルの例の proxyrules_example5.xml ファイルは、ユーザがリクエスト
したファイル拡張子に基づいて、CA SiteMinder for Secure Proxy Server リク
エストをルーティングします。 これは、endswith 基準と組み合わせて URI
条件を使用して行います。
ファイルで、<nete:forward> および </nete:forward> タグは、スペースの制
約のため別々の行に表示されます。 ただし、プロキシ ルール設定ファイ
ルでは、<nete:forward> エレメントの開始タグおよび終了タグは同じ行に
表示される必要があります。同じ行に配置されない場合、CA SiteMinder for
Secure Proxy Server では改行が転送 URL の一部として解釈されます。これ
により、リクエストが誤って転送されます。
前の例では、ワイヤレス ユーザがワイヤレス サーバに転送されている
間、.jsp リソースにアクセスするユーザはアプリケーション サーバに転送
されます。 他のすべてのユーザはホーム サーバーに転送されます。
以下の表は、ファイル拡張子に基づくプロキシ ルールを使用して、リク
エストの結果について説明しています。
リクエストされた URL
転送された URL
http://www.company.com/app.jsp
http://application.company.com/app.jsp
http://www.company.com/index.wml
http://wireless.company.com/index.wml
http://www.company.com/index.html
http://home.company.com/index.html
第 9 章： プロキシ ルールの設定 203
サンプル プロキシ ルール設定ファイル
プロキシ ルールの例 -- 入れ子の条件を持ったリクエストのルーティング
サンプル ファイルである proxyrules_example6.xml ファイルは、ホスト名に
基づいて CA SiteMinder for Secure Proxy Server リクエスト、特定のヘッダ、
およびデバイス タイプをルーティングします。 このファイルは、CA
SiteMinder for Secure Proxy Server が単一の設定ファイルで複雑な関係をど
のように処理できるかを示しています。
このファイルで、<nete:forward>URL</nete:forward> エレメントは同じ 1 つ
の行に指定する必要があります。例では、終了タグである </nete:forward>
がスペースの制約により別の行に示されていますが、実際のプロキシ
ルール ファイル内で改行するとエラーになります。 CA SiteMinder for
Secure Proxy Server は、終了タグ </nete:forward> の前の改行を、
nete:forward エレメントに含まれる URL の一部として解釈します。
以下の表は、入れ子の条件を持ったプロキシ ルールを使用したリクエス
トの結果を示しています。
リクエストされた URL
転送された URL
http://banking.company.com/index.wml
http://wireless.company.com/banking/index.wml
http://banking.company.com/index.html
http://server1.company.com/banking/index.html
http://bondtrading.company.com/index.html
http://fast.company.com/bondtrading/index.html
ヘッダ値 GOLD_USER="yes"
http://bondtrading.company.com/index.html
ヘッダ値 GOLD_USER="no"
http://www.company.com/index.wml
ワイヤレス デバイス名を含む USER_AGENT
ヘッダ値
http://www.company.com/index.html
ワイヤレス デバイス名を含まない
USER_AGENT ヘッダ値
204 管理ガイド
http://server2.company.com/bondtrading/index.h
tml
http://home.company.com/
wireless/index.wml
http://home.company.com/index.html
サンプル プロキシ ルール設定ファイル
プロキシ ルールの例 - プロキシ ルールで正規表現を使用する
ファイルの例の proxyrules_example7.xml ファイルは、正規表現に含まれる
nete:xprcond エレメントに基づいて、CA SiteMinder for Secure Proxy Server
リクエストをルーティングします。 正規表現は、URI およびリクエストの
クエリ文字列に基づいて評価されます。
ファイルで、URI およびリクエストのクエリ文字列は、nete:xpr エレメン
トで定義された 3 つの正規表現に対して評価されます。最初の nete:xpr エ
レメントに対して一致が見つからない場合、CA SiteMinder for Secure Proxy
Server は 2 番目と一致させようとし、最後に 3 番目の正規表現と一致させ
ようとします。 一致が見つからない場合、nete:xpr-default 条件を使用して
リクエストを処理します。
以下の表は、正規表現プロキシ ルールを使用して、リクエストの結果の
リストを示しています。
リクエストされた URL
転送された URL
http://server.company.com/realma/hr/index.html
http://server1.company.com/hr/index.
html
http://server.company.com/GOTO=server2.company.com/in http://server2.company.com/index.htm
dex.html
l
http://server.company.com/REDIR=server2.company.com/in http://server2.company.com/index.htm
dex.html
l
ユーザはリダイレクトされるため
server2.company.com はユーザのリク
エストに直接対応する必要がありま
す。
http://server.company.com/index.html
http://www.company.com/index.html
第 9 章： プロキシ ルールの設定 205
サンプル プロキシ ルール設定ファイル
プロキシ ルールの例 -- Cookie の存在によるリクエストのルーティング
事例ファイルの proxyrules_example8.xml ファイルは、Cookie の存在に基づ
いて CA SiteMinder for Secure Proxy Server のリクエストをルーティングし
ます。
この例では、リクエストに Cookie ヘッダ「mycookie」が含まれる場合、CA
SiteMinder for Secure Proxy Server は www.company.com へリクエストを
ルーティングします。
プロキシ ルールの例 -- Cookie 値によるリクエストのルーティング
事例ファイルの proxyrules_example9.xml ファイルは、Cookie 値に基づいて
CA SiteMinder for Secure Proxy Server のリクエストをルーティングします。
この例では、リクエストに Cookie ヘッダ「mycookie」が含まれて、リクエ
ストがエンコーディング メカニズムを指定しない場合、CA SiteMinder for
Secure Proxy Server は www.abcd.com へリクエストをルーティングします。
リクエストに Cookie ヘッダ「mycookie」および base64 エンコーディング
メカニズムが含まれる場合、CA SiteMinder for Secure Proxy Server は
www.xyz.com へリクエストをルーティングします。
206 管理ガイド
第 10 章： SPS の展開
このセクションには、以下のトピックが含まれています。
企業内の CA SiteMinder for Secure Proxy Server (P. 207)
企業内の CA SiteMinder for Secure Proxy Server
CA SiteMinder for Secure Proxy Server は、アクセス制御、シングル サインオ
ンおよび SSL 加速を有効にするためにリバース プロキシ アーキテクチャ
を使用します。 コンテンツ キャッシュと、従来のリバース プロキシ サー
バによって提供されていた他のいくつかの機能は提供されません。 CA
SiteMinder for Secure Proxy Server は他のプロキシ技術を置き換えるのでは
なく、企業アーキテクチャへの追加として利用されることを意図していま
す。 そのため CA SiteMinder for Secure Proxy Server は、クラスタのいずれ
かの側にキャッシング デバイスがある負荷分散デバイスを備えたクラス
タに配置できます。
第 10 章： SPS の展開 207
企業内の CA SiteMinder for Secure Proxy Server
以下の図は、負荷分散デバイスと共に動作するようにネットワークにどの
ように CA SiteMinder for Secure Proxy Server を追加できるかを示していま
す。
注： 負荷分散デバイスに加えて、キャッシング デバイスを CA SiteMinder
for Secure Proxy Server クラスタのどちらの側にも配置できます。
208 管理ガイド
企業内の CA SiteMinder for Secure Proxy Server
スティッキー ビット ロード バランシング
CA SiteMinder for Secure Proxy Server でサポートされている Cookie なしの
セッション スキームを使用する場合、CA SiteMinder for Secure Proxy Server
でリソースにアクセスするユーザのセッション情報はインメモリ セッ
ション ストアで保持されます。 セッション情報はユーザが最初に認証さ
れた CA SiteMinder for Secure Proxy Server で保持されるので、1 つのセッ
ション内のすべてのユーザ リクエストに対して同じ CA SiteMinder for
Secure Proxy Server が使用される必要があります。 クラスタに実装された
場合、CA SiteMinder for Secure Proxy Server はスティッキー ビット ロード
バランサと組み合わせて使用する必要があります。そうすることで、同じ
CA SiteMinder for Secure Proxy Server への一貫した接続を実現し、従来の
SiteMinder の Cookie セッション スキーム以外のセッション スキームを使
用する場合にシングル サインオンを可能にします。
Cookie なしのセッション スキームを使用して CA SiteMinder for Secure
Proxy Server を展開するには、以下のことを考慮する必要があります。
■
ほとんどの展開で、CA SiteMinder for Secure Proxy Server はクラスタに
展開され、複数のサーバで受信リクエストのロードを共有します。 負
荷分散はロード バランサ デバイスによって処理されます。 これらの
デバイスは、シングル サインオンを維持するためにスティッキー ビッ
ト機能を備えている必要があります。
スティッキー ビット ロード バランサにより、クラスタ内の特定の CA
SiteMinder for Secure Proxy Server とのユーザ セッションが一度確立さ
れた後は、その CA SiteMinder for Secure Proxy Server がすべてのユーザ
リクエストを処理します。 CA SiteMinder for Secure Proxy Server はアク
ティブなメモリ内に Cookie なしのセッションのセッション情報を保
持するため、この機能が必要です。 ユーザのリクエストがスティッ
キー ビット技術を使用して処理されない場合、リクエストがサーバ ク
ラスタ内の別々の CA SiteMinder for Secure Proxy Server によって処理さ
れるたびに、ユーザは新しい認証情報を求められます。
■
CA SiteMinder for Secure Proxy Server 用の設定を行う場合、CA
SiteMinder for Secure Proxy Server の server.conf ファイルで定義された
デフォルトの仮想ホストを、負荷分散デバイスの名前と IP アドレスを
使用して定義する必要があります。
■
負荷分散デバイスを CA SiteMinder for Secure Proxy Server へのエントリ
ポイントとして設定する必要があります。
■
負荷分散デバイスは CA SiteMinder for Secure Proxy Server クラスタを指
している必要があります。
第 10 章： SPS の展開 209
企業内の CA SiteMinder for Secure Proxy Server
■
sps_home/secure-proxy/httpd/conf ディレクトリにある httpd.conf ファ
イルを編集して、ServerName ディレクティブの値を、CA SiteMinder for
Secure Proxy Server をインストールしたシステムではなく負荷分散デ
バイスの名前に設定する必要があります。
■
SSL を使用する場合、CA SiteMinder for Secure Proxy Server ではなくロー
ド バランサに証明書を発行する必要があります。
■
CA SiteMinder for Secure Proxy Server をインストールするシステム（複
数可）には、インメモリ セッション ストアで保持される同時ユーザ
セッションごとにおよそ 1K のメモリが必要です。 たとえば、単一の
システムが 1000 の同時セッションを保持する必要がある場合、システ
ムにはこの目的に使用可能な 1 メガバイトの RAM が必要です。
信頼サイトと非信頼サイトに対するプロキシ
CA SiteMinder for Secure Proxy Server は企業内の信頼されたサイト用プロ
キシと見なされます。 プロキシ トランザクションの一部として、
SiteMinder は HTTP ヘッダ変数を生成しました。また、SiteMinder レスポン
スによって生成された変数は、各 HTTP および HTTPS リクエストと共に転
送されます。 これらのレスポンスは他の企業アプリケーションによって
使用できます。
重要： 信頼されていないサイト上のコンテンツに対してプロキシとなる
トランザクションで CA SiteMinder for Secure Proxy Server を使用する場合、
トランザクションに伴うヘッダも信頼されていないサイトに転送されま
す。 企業で信頼されている送信先サーバに対してプロキシとなるように
CA SiteMinder for Secure Proxy Server を使用することをお勧めします。
仮想ホストの設定
複数のホストを持つ CA SiteMinder for Secure Proxy Server を設定し、1 つ以
上のホスト名の仮想ホストとして動作させることができます。
次の手順に従ってください：
1. server.conf ファイルの <VirtualHost> パラメータを編集し、1 つ以上のホ
スト名の仮想ホストとして動作するように CA SiteMinder for Secure
Proxy Server を設定します。
2. 埋め込まれた Apache Web サーバの設定ファイルを編集します。
210 管理ガイド
企業内の CA SiteMinder for Secure Proxy Server
詳細情報：
仮想ホスト名の設定 (P. 160)
複数の仮想ホストを処理する Apache 構成ファイルの編集
CA SiteMinder for Secure Proxy Server と同じ動作環境内で複数の仮想ホス
トを実行していて、この環境でトランザクションが実行されている場合、
Apache 設定ファイル（httpd.conf）を更新します。 このファイルは、
sps_home¥secure-proxy¥httpd¥conf ディレクトリに格納されています。
Web サーバに対して SSL を有効にする場合は、
sps_home¥secure-proxy¥httpd¥conf¥extra directory に格納されている
httpd-ssl.conf ファイルにも同じ更新を適用してください。動作環境が IPv4
と IPv6 のどちらをベースにしているかによって、更新は異なります。
複数の仮想ホストを処理するため、httpd.conf ファイルを更新し、オプションで
httpd-ssl.conf ファイルを更新する方法
■
IPv4 環境については、以下の LISTEN ディレクティブを追加します。
LISTEN 127.0.0.1:<_port>
■
IPv6 環境については、以下の LISTEN ディレクティブを追加します。
LISTEN [::1]:<_port>
■
IPv4 および IPv6 の両方をサポートするデュアル スタック環境につい
ては、以下の LISTEN ディレクティブを追加します。
LISTEN 127.0.0.1:<_port>
LISTEN [::1]:<_port>
さらに、新しいホスト名が追加されるように、次のようにホスト ファイ
ル内のループバック アドレス エントリを更新します。
■
IPV4: 127.0.0.1
■
IPV6: [::1]
ホスト ファイルは通常、C:¥WINDOWS¥system32¥drivers¥hosts 内の
Windows に格納されています。 UNIX では、ホスト ファイルは通常
/etc/hosts に格納されています。
第 10 章： SPS の展開 211
企業内の CA SiteMinder for Secure Proxy Server
複数の仮想ホスト用のセッション スキーム マッピングを実装する
複数のユーザ エージェント タイプを認識するために CA SiteMinder for
Secure Proxy Server を設定する場合、仮想ホストに基づいてそれらのユー
ザ エージェント用に別のセッション スキーム マッピングを割り当てます。
これには、次の手順に従う必要があります。
1. セッション スキームを設定するか、または CA SiteMinder for Secure
Proxy Server に含まれているスキームの設定を確認します。
2. server.conf ファイルでユーザ エージェント タイプを定義します。
3. デフォルト設定とは異なるディレクティブを定義する server.conf ファ
イルで、仮想ホストごとにセクションを作成します（「仮想ホストの
デフォルト値をオーバーライドする」を参照）。
4. 仮想ホストごとにセッション スキーム マッピングを定義します。
以下の server.conf ファイルからの抜粋は、ユーザ エージェント タイプが
Internet Explorer（IE）ブラウザ ユーザに対して定義されている例を示して
います。 IE ユーザは仮想ホストに対して定義されたデフォルト セッショ
ン スキーム以外のセッション スキームを使用するようマップされます。
以下の例では、server.conf ファイルで定義されたセッション スキームを示
します。
#Session Schemes
<SessionScheme name="default">
class="com.netegrity.proxy.session.SessionCookieScheme"
accepts_smsession_cookies="true"
</SessionScheme>
<SessionScheme name="ssl_id">
class="com.netegrity.proxy.session.SSLIdSessionScheme"
accepts_smsession_cookies="false"
</SessionScheme>
<SessionScheme name="simple_url">
class="com.netegrity.proxy.session.SimpleURLSessionScheme"
accepts_smsession_cookies="false"
</SessionScheme>
<SessionScheme name="minicookie">
class="com.netegrity.proxy.session.MiniCookieSessionScheme"
accepts_smsession_cookies="false"
cookie_name="MiniMe"
</SessionScheme>
212 管理ガイド
企業内の CA SiteMinder for Secure Proxy Server
以下の例では、IE ユーザ エージェント タイプの定義を示します。
server.conf ファイルの後半でセッション スキーム マッピングを定義する
場合、このユーザ エージェント タイプが参照されます。
# TO-DO： サーバにアクセスするクライアントのタイプ
# に基づいて別のセッション スキームを使用する場合
# ユーザ エージェントを定義します。
#
# 注： UserAgent の照合は、このファイルに定義された
# ユーザ エージェントの順に実行されます。
<UserAgent name="IE">
User-Agent="MSIE"
</UserAgent>
# <UserAgent name="NS">
#
User-Agent=その他の正規表現
# </UserAgent>
前述の例では、defaultsessionscheme ディレクティブで指定されたデフォル
ト セッション スキームがミニ Cookie であることを示しています。 別の
セッション スキームがセッション スキーム マッピングに明示的に含まれ
ている場合、または、別のスキームによって仮想ホストの定義にあるデ
フォルト セッション スキームが上書きされる場合を除いて、このセッ
ション スキームがすべてのトランザクションに使用されます。
<VirtualHostDefaults> ディレクティブは、<UserAgent name="IE"> で定義さ
れた IE ユーザ エージェント タイプ用のセッション スキーム マッピング
を示します。このマッピングは、すべての仮想ホストがデフォルトのセッ
ション スキーム マッピングを使用することを示し、IE ブラウザ ユーザの
セッションはシンプル URL リライティング セッション スキームを使用し
て管理されます。
<VirtualHostDefaults>
# サービス ディスパッチャ
<ServiceDispatcher>
class="com.netegrity.proxy.service.SmProxyRules"
rules_file="conf¥proxyrules.xml"
</ServiceDispatcher>
# デフォルト セッション スキーム
defaultsessionscheme="minicookie"
#TO-DO： 任意のセッション スキーム マッピングの定義
<SessionSchemeMappings>
user_agent_name=session_scheme_name
IE="simple_url"
#
NS=simple_url
</SessionSchemeMappings>
#
第 10 章： SPS の展開 213
企業内の CA SiteMinder for Secure Proxy Server
仮想ホスト ディレクティブは、CA SiteMinder for Secure Proxy Server 用に設
定されたデフォルト仮想ホストのサーバ名および IP アドレスを示します。
# デフォルト仮想ホスト
<VirtualHost name="default">
hostnames="server1, server1.company.com"
addresses="192.168.1.10"
#
#
#
#
デフォルトは
仮想ホストだけでなく
その仮想ホストの WebAgent
も同様に上書きできます。
#<WebAgent>
#</WebAgent>
</VirtualHost>
追加の仮想ホスト用の仮想ホスト ディレクティブは、server2 仮想ホスト
用に上書きされる特定のデフォルト仮想ホスト設定を示します。 これら
の上書きには新しいセッション スキーム マッピングが含まれることに注
意してください。 server2 のデフォルト スキームはデフォルトです。 セッ
ション スキーム ディレクティブで、デフォルトは従来の SiteMinder Cookie
セッション スキームとして定義されます。 さらに、仮想ホスト ディレク
ティブ内の IE ユーザに対するセッション スキーム マッピングも、デフォ
ルト スキームにマップされます。そのため、CA SiteMinder for Secure Proxy
Server では SiteMinder Cookie セッション スキームを使用して、server2 に
アクセスするすべてのユーザ用のセッションを管理します。
# 追加の仮想ホスト
<VirtualHost name="host2">
requestblocksize="4"
responseblocksize="4"
hostnames="server2, server2.company.com"
#addresses="192.168.1.15"
# デフォルト セッション スキーム
defaultsessionscheme="default"
#TO-DO： 任意のセッション スキーム マッピングの定義
<SessionSchemeMappings>
#user_agent_name=session_scheme_name
IE="default"
</SessionSchemeMappings>
#<WebAgent>
#</WebAgent>
</VirtualHost>
214 管理ガイド
第 11 章： Web サービスの設定
このセクションには、以下のトピックが含まれています。
認証および許可 (P. 215)
セキュリティ トークン サービス (P. 229)
認証および許可
認証および許可 Web サービスの使用方法
CA SiteMinder® は、現在、認証 Web サービスおよび許可 Web サービスを
提供しています。CA SiteMinder® 認証および許可 Web サービスを使用する
プロセスには、以下の図に示す手順が含まれます。
第 11 章： Web サービスの設定 215
認証および許可
認証および認可 Web サービスを使用するには、以下の手順を実行します。
1. ACO を作成します (P. 218)。
2. Web サービスを保護します (P. 219)。
3. Web サービスを有効にします (P. 220)。
4. Web サービス ログを設定します (P. 220)。
5. クライアント プログラムを作成します (P. 221)。
認証および許可 Web サービスの概要
CA SiteMinder® 認証および許可 Web サービスは、CA SiteMinder for Secure
Proxy Server インストールの一部です。 これらは、個別に有効または無効
にできます。
Web サービス設定プロセスは、以下の CA SiteMinder® オブジェクトの設定
を前提としています。
■
呼び出し元が認証するターゲット アプリケーションを保護する 1 つ
以上のエージェント
■
認証および許可に必要なレルム、ユーザ ディレクトリ、ポリシー、お
よびレスポンス
ほかの方法では保護されないアプリケーションをサポートするために、認
証および許可 Web サービスを使用できます。 適切な CA SiteMinder® オブ
ジェクトが利用可能な場合、携帯電話上の独立したアプリケーションなど
で、ユーザを認証できます。
これらの Web サービスは、SOAP 1.2 プロトコルおよび HTTP ベースの
RESTful アーキテクチャをサポートしています。 認証および許可 Web サー
ビスは以下の機能を提供します。
■
login — 認証が成功すると、セッション トークンを認証し返します。
注： ［ユーザ追跡の有効化］オプションが有効な場合、レスポンスに
は ID トークンがさらに含まれます。
216 管理ガイド
■
blogin — 認証し、ログインが成功するかどうかを確認します。セッショ
ン トークンを返しません。
■
logout — ユーザまたはユーザのグループをログアウトします。
■
authorize — 許可ステータス メッセージおよびリフレッシュされた
セッション トークンを返します。
認証および許可
操作のリクエストに対するレスポンスは、対応する SiteMinder が生成する
ヘッダによって異なります。 リソースが匿名認証方式で保護されている
場合、レスポンスにはセッション トークンは含まれませんが、ID トーク
ンが含まれます。 ID トークンは、セッション トークンの代わりに後の許
可リクエストで使用できます。
認証リクエストには、以下のパラメータが含まれます。
■
appId
■
リソース文字列
■
action
■
ユーザ認証情報
appId は、CA SiteMinder® アプリケーション オブジェクトではなく、リソー
スの階層の場所に対するユーザ定義の論理名を参照します。 内部的に、
appId はエージェントにマップします。 CA SiteMinder® は、エージェント
名を使用してレルムを決定します。 ユーザを認証するには、レルム、リ
ソース文字列、およびユーザ認証情報で十分です。
許可リクエストは認証リクエストより単純です。 許可リクエストにはロ
グイン レスポンスから取得された appId、リソース パス、アクション、お
よびセッション トークンが含まれます。 Web サービスはトークンを検証
し、指定されたリソースへのアクセス権を付与するかどうかを判断します。
Web サービスの設定
デフォルトでは、CA SiteMinder for Secure Proxy Server 12.51 をインストー
ルまたはアップグレードすると、Web サービス機能がインストールされま
す。
Web サービスを設定するには、以下の手順に従います。
1. WAMUI を使用して Web サービス用の ACO を作成します。
2. Web サービスを保護にします。
3. 管理 UI を使用して Web サービスを有効にします。
4. （オプション）Web サービス ログを設定します。
第 11 章： Web サービスの設定 217
認証および許可
Web サービス用の ACO の作成
ACO を使用して Web サービスを管理できます。 ACO もリソース アクセス
保護に使用されるため、AgentName で定義する必要があります。Web サー
ビスを使用するには、enableauth パラメータまたは enableaz パラメータ、
またはその両方を有効にする必要があります。
次の手順に従ってください：
1. WAMUI 内の AuthAzServiceDefaultSettings テンプレートに基づいて ACO
を作成します。
2. サービスとして Web サービスを使用するために以下のパラメータを
設定します。
AgentName
リソースを保護する Web エージェントの名前、defaultagentname
または Web サービスを保護する ACO のエージェント名を定義し
ます。 AgentName にこれらの値を追加する必要があります。
アプリケーションを保護する複数の Web エージェントを定義する
には、以下の形式で複数値のペアを入力します。
agent_name1,appID1
agent_name2,appID2
agent_namen,appIDn
agent_name
リソースを保護する Web エージェントの名前を定義します。
appID
agent_name で指定された Web エージェント、または Web エー
ジェントによって保護されるアプリケーションの参照名を定
義します。 CA SiteMinder® は Web サービス リクエストでこの
値を使用し、それにより、ユーザからエージェント名を保護し
ます。
defaultagentname または Web サービスを保護する ACO のエージェ
ント名を持つ、指定された AgentName を追加します。
Web サービスを保護する ACO のエージェント名を使用するには、
以下の形式でエージェント名を定義します。
agent_name,hostname
Web サービスを保護する ACO の defaultagentname を使用するには、
以下の形式でエージェント名を定義します。
agent_name
218 管理ガイド
認証および許可
enableauth
認証 Web サービスのステータスを指定します。 認証 Web サービ
スを使用する場合は、値を「yes」に設定します。
enableaz
許可 Web サービスのステータスを指定します。 許可 Web サービ
スを使用する場合は、値を「yes」に設定します。
RequireAgentEnforcement
CA SiteMinder® エージェントによって Web サービスを保護する必
要があるかどうかを指定します。 実稼働環境では、この値を［は
い］に設定して、CA SiteMinder® エージェントによって Web サービ
スを保護することを強くお勧めします。 値を［はい］に設定して
も、Web サービスが保護されない場合は、Web サービスへのリク
エストは失敗します。
注： テスト環境で、または Web サービスが CA SiteMinder® 以外の方
法で保護されている場合は、RequireAgentEnforcement の値を［い
いえ］に設定できます。
3. 変更を保存します。
Web サービスの保護
実稼働環境では Web サービスを保護することをお勧めします。 Web サー
ビスの Web エージェントを保護すると、ユーザ リクエストが保護される
前に、CA SiteMinder® で Web サービス クライアントを認証および許可でき
ます。 実稼働環境で Web サービスを保護すると、CA SiteMinder for Secure
Proxy Server は SMSESSION Cookie をユーザ リクエストへ含めます。
RequestSmSessionCookie ACO パラメータが有効な場合、CA SiteMinder® は
ユーザ リクエストを処理する前に、Web サービスがユーザ リクエストで
SMSESSION Cookie を確認するようにします。
Web サービスを保護するには、X.509 クライアント証明書認証方式を使用
して Web サービス ルート URL を保護するように、CA SiteMinder for Secure
Proxy Server を設定することをお勧めします。
第 11 章： Web サービスの設定 219
認証および許可
Web サービスの有効化
前の手順で作成した ACO を使用して、管理 UI から Web サービスを有効に
します。
注： enableauth と enableaz の値が「no」に設定されている場合、CA
SiteMinder for Secure Proxy Server 管理者 UI からサポートを有効にしても、
Web サービスは機能しません。
次の手順に従ってください：
1. ［プロキシ設定］-［認証および許可 Web サービス］に移動します。
2. ［ホスト名］に Web サービス仮想ホストの一意のホスト名を入力しま
す。
3. ［エージェント設定オブジェクト］で、Web サービスに対して作成さ
れる ACO の名前を入力します。
4. ［保存］をクリックします。
Web サービスが有効になります。
Web サービス ログの設定
Web サービスを有効にすると、CA SiteMinder for Secure Proxy Server は、
server.log ファイルに Web サービスのログを保存します。 ログの場所を
server.log から authazws.log に変更できます。
ログの場所を変更する場合は、以下の手順に従います。
1. sps_home/proxy-engine/conf/webservicesagent に移動します。
2. authaz-log4j.xml ファイルのバックアップを作成します。
220 管理ガイド
認証および許可
3. 元の authaz-log4j.xml ファイルを開き、以下の手順に従います。
a. 以下の AuthAZ_ROLLING アペンダ タグのコメントを解除します。
<appender name="AuthAZ_ROLLING"
class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="logs/authazws.log"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%c] - %m%n"/>
</layout>
</appender>
b. AuthAZ_ROLLING タグに関する以下の appender-ref について、すべ
ての出現箇所のコメントを解除します。
<appender-ref ref="AuthAZ_ROLLING"/>
4. 変更を保存して、CA SiteMinder for Secure Proxy Server を再起動します。
ログの場所が authazws.log ファイルに変更されます。これは
sps_home/proxy-engine/logs/ に存在します。
クライアント プログラムの作成
クライアント プログラムの機能は、ほかのアプリケーションに代わって、
Web サービスに対して認証リクエストおよび許可リクエストを発行する
ことです。 クライアント プログラムは、クライアント スタブのコードを
必要とします。 スタブは、Web サービスと通信するためのメッセージを
管理、送信、および受信します。 Web サービスは、WSDL ファイル（SOAP
プロトコル用）と WADL ファイル（REST アーキテクチャ用）をサポートし
ています。 Web ブラウザを使用して、WSDL ファイルまたは WADL ファイ
ルにアクセスし、XML ファイルとしてそれを保存できます。
第 11 章： Web サービスの設定 221
認証および許可
次の手順に従ってください：
1. アプリケーション用に、必要な認証情報を収集するビジネス ロジック
を記述します。
2. クライアント スタブを作成します。 必要に応じて、サードパーティ
ツールで WSDL ファイルまたは WADL ファイルを使用して、クライア
ント スタブを生成できます。
■
WSDL をロードするには、以下の URL を使用します。
http://hostname:port/authazws/auth?wsdl
■
WADL をロードするには、以下の URL を使用します。
http://hostname:port/authazws/AuthRestService/application.wadl
注： これらの場所からメタデータを取得するには、必ず ACO 内の
DefaultAgentName パラメータをいずれかのエージェントに設定してく
ださい。
3. クライアント スタブをインポートし、スタブ オブジェクトをインスタ
ンス化して Web サービスを呼び出します。
以降のセクションでは、参考のために、簡略化された SOAP メッセージお
よび REST メッセージの例を示します。
認証 SOAP インターフェース
以下の簡略化された例は、認証が SOAP プロトコルを使用して動作するこ
とを示しています。 ほとんどの認証方式は、username、password、
binaryCredentials の 3 つのフィールドから構成される IdentityContext に
よってサポートできます。 より多くのフィールドを必要とするその他の
方式は、認証情報タイプに対して入力を調整する追加の操作を行うことで
サポートされます。
222 管理ガイド
認証および許可
以下の例は、認証 Web サービスの通常のユーザ ログイン リクエストです。
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:aut="http://ca.com/2010/04/15/authentication.xsd">
<s:Header/>
<s:Body>
<aut:login>
<identityContext>
<binaryCreds>
</binaryCreds>
<password>user1</password>
<userName>user1</userName>
</identityContext>
<appId>app1</appId >
<action>GET</action>
<resource>/*</resource >
</aut:login>
</s:Body>
</s:Envelope>
blogin 操作（ブール ログイン）は、ログイン操作に似ています。 ただし、
blogin は、以下の例に示すように、レスポンスで SMSESSION 値を返しませ
ん。
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:aut="http://ca.com/2010/04/15/authentication.xsd">
<s:Header/>
<s:Body>
<aut:blogin>
<identityContext>
<binaryCreds>
</binaryCreds>
<password>user1</password>
<userName>user1</userName>
</identityContext>
<appId>app1</appId >
<action>GET</action>
<resource>/*</resource >
</aut:blogin>
</s:Body>
</s:Envelope>
第 11 章： Web サービスの設定 223
認証および許可
以下の例は、成功したログイン レスポンスを表します。
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header/>
<s:Body>
<aut:loginResponse
xmlns:aut="http://ca.com/2010/04/15/authentication.xsd">
<return>
<message>Authentication successful.</message>
<resultCode>LOGIN_SUCCESS</resultCode>
<sessionToken>session</sessionToken>
<responses>
<response/>
<response/>
</responses>
</return>
</aut:loginResponse>
</s:Body>
</s:Envelope>
以下の例は、失敗したログイン試行を表します。
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header/>
<s:Body>
<ns2:loginResponse xmlns:ns2="http://webservice.sm.services.soa.ca.com/">
<return>
<message>Authentication failured</message>
<resultCode>LOGIN_FAILED</resultCode>
<smSessionCookieValue/>
</return>
</ns2:loginResponse>
</s:Body>
</s:Envelope>
以下の例は、認証 Web サービスのユーザ ログアウト リクエストを表しま
す。
注： ユーザが正常にログアウトしたとしても、 SessionToken は有効な
ユーザ認証情報と見なされるため、エージェントは引き続き
SessionToken を使用して許可を行います。
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:aut="http://ca.com/2010/04/15/authentication.xsd">
<s:Header/>
<s:Body>
<aut:logout>
<smSessionCookieValue>session</smSessionCookieValue>
</aut:logout>
</s:Body>
</s:Envelope>
224 管理ガイド
認証および許可
以下の例は、成功した認証 Web サービス ログアウト レスポンスを表しま
す。
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header/>
<s:Body>
<ns2:logoutResponse
xmlns:ns2="http://ca.com/2010/04/15/authentication.xsd">
<return>
<message>Logout successful.</message>
<resultCode>SUCCESS</resultCode>
</return>
</ns2:logoutResponse>
</s:Body>
</s:Envelope>
認証 REST インターフェース
REST は、REpresentational State Transfer を意味しています。REST では、サー
ビス リクエストは、URI によってアクセス可能な状態にオブジェクトを変
換します。 HTTP は、作成、読み取り、更新、および削除などのアクショ
ンを使用して、状態の変更を制御します。
認証と許可の URI マッピングは、appId と resourcePath から構成されます。
リソース状態は、リソースに関連付けられた認証ユーザまたは許可ユーザ
の集合です。認証のためのサービス名は login、blogin、および logout です。
この形式の URI、
http://hostname:port/authazws/AuthRestService/login/appID/Resource は以下
のリクエストをポストします。
<loginRequest>
<binaryCreds></binaryCreds>
<password>user1</password>
<userName>user1</userName>
<action>GET</action>
</loginRequest>
第 11 章： Web サービスの設定 225
認証および許可
ログイン レスポンス：
HTTP リターン コード 200
<loginResponse>
<message>Authentication successful</message>
<resultCode>LOGIN_SUCCESS</resultCode>
<sessionToken>session</sessionToken>
<authenticationResponses>
<response>
<name>SM_SESSIONDRIFT</name>
<value>0</value>
</response>
</authenticationResponses>
</loginResponse>
HTTP リターン コード 400
<loginResponse>
<message>Bad Request</message>
<resultCode>LOGIN_ERROR</resultCode>
</loginResponse>
HTTP リターン コード 200
<loginResponse>
<message>Authentication Failed</message>
<resultCode>LOGIN_FAILED</resultCode>
<authenticationResponses>
<response><name>SM_AUTHREASON</name>
<value>0</value>
</response>
</authenticationResponses>
</loginResponse>
HTTP リターン コード 500
<loginResponse>
<message>System</message>
<resultCode>Server Error</resultCode>
</loginResponse>
blogin 操作（ブール ログイン）は、ログインに似ています。
http://host:port#/blogin/appId/resourcePath の形式の URI は、ログイン リク
エストに示されるようにポストします。 レスポンス メッセージで「yes」
または「no」を返します。
226 管理ガイド
認証および許可
http://host:port#/authazws/AuthRestService/logout/ の形式の URI は、以下の
ログアウト リクエストをポストします。
<logoutRequest>
<sessionToken>session</sessionToken>
</logoutRequest>
認証 Web サービスのログアウト レスポンス：
<logoutResponse>
<message>Logout Successful</message>
<resultCode>LOGOUT_SUCCESS</resultCode>
<smSessionCookieValue>yyy</smessionCookieValue>
</logoutResponse>
<logoutResponse>
<message>Logout Failed</message>
<resultCode>LOGOUT_FAILURE</resultCode>
<smSessionCookieValue>yyy</smessionCookieValue>
</logoutResponse>
許可 SOAP サービス
以下の XML は、Web サービスに対する許可リクエストの例です。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:aut="http://ca.com/2010/04/15/authorization.xsd">
<soapenv:Header/>
<soapenv:Body>
<aut:authorize>
<sessionToken>session</sessionToken>
<appId></appId>
<action>GET,POST</action>
<resource>/domainAdmin/a.jsp</resource>
</aut:authorize>
</soapenv:Body>
</soapenv:Envelope>
第 11 章： Web サービスの設定 227
認証および許可
以下の例は、許可 Web サービスの AUTHORIZED レスポンスを表します。
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<ns2:authorizeResponse
xmlns:ns2="http://ca.com/2010/04/15/authorization.xsd">
<return>
<message>Authorization Successful</message>
<resultCode>AUTHORIZED</resultCode>
<sessionToken>aklaks</sessionToken>
<authorizationResponses>
<response/>
</authorizationResponses>
</return>
</ns2:authorizeResponse>
</env:Body>
</env:Envelope>
以下の例は、許可 Web サービスの UN AUTORIZED レスポンスを表します。
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<ns2:authorizeResponse
xmlns:ns2="http://ca.com/2010/04/15/authorization.xsd">
<return>
<message> Authorization Failed</message>
<resultCode>NOTAUTHORIZED</resultCode>
</return>
</ns2:authorizeResponse>
</env:Body>
</env:Envelope>
注： 有効なセッション トークンを含む許可 Web サービス リクエストの場
合、NOTAUTHORIZED 許可レスポンスに以下の制約があります。
1. WAMUI でレスポンスに設定できるのは、以下の属性のみです。
■
SM_ONREJECTTEXT
■
SMREDIRECTURL または SM_REDIRECTURL
■
SMERROR
2. レスポンスにはセッション トークンが含まれません。
228 管理ガイド
セキュリティ トークン サービス
許可 REST インターフェース
許可の REST インターフェースは
http://hostname:port/authazws/AuthRestService/authz/appID/Resource です。
<authorizationRequest>
<action>POST</action>
<resource>RealmA/index.html</resource>
<sessionToken>affl;;alkf;l;fd</sessionToken>
</authorizationRequest>
HTTP リターン コード 200：
<authorizationResult >
<message>The user is authorized.</message>
<resultCode>AUTHORIZED</resultCode>
</authorizationResult >
セキュリティ トークン サービス
CA SiteMinder for Secure Proxy Server は、トークンを発行および変換するた
めの WS トラスト ベース メカニズムを提供する、Office 365 向けのセキュ
リティ トークン サービス（STS）をサポートしています。 1 つまたは複数
の STS インスタンスを CA SiteMinder for Secure Proxy Server マシン上に展
開できます。
第 11 章： Web サービスの設定 229
セキュリティ トークン サービス
複数 CA SiteMinder for Secure Proxy Server インスタンスの展開
複数の STS インスタンスを展開するには、それぞれの STS インスタンスが
個々のログ ファイルにログを記録するように、すべての STS インスタンス
に同じ log4j 設定が必要です。
次の手順に従ってください：
1. 以下のいずれかのタスクを実行します。
■
Windows では、以下の手順に従います。
a. installation_home/proxy-engine/conf に移動します。
b. SmSpsProxyEngine.properties ファイルを開き、ファイル内の
STS_AGENT_LOG_CONFIG_FILE 変数のコメントを解除します。
c. 変更を保存します。
■
UNIX では、以下の手順に従います。
a. installation_home/proxy-engine に移動します。
b. proxyserver.sh ファイルを開き、ファイル内の
STS_AGENT_LOG_CONFIG_FILE 変数のコメントを解除します。
c. 変更を保存します。
2. installation_home/proxy-engine/conf/sts-config/globalconfig に移動しま
す。
3. agent-multiinstance-log4j.xml ファイルを開きます。
4. 各 STS インスタンスに対して以下の手順を実行します。
a. STS インスタンスのアペンダを作成します。
注： デフォルトでは、このファイルには STS インスタンス用のアペ
ンダが 1 つ含まれています。
b. アペンダ内の [SPS ROOT FOLDER] を CA SiteMinder for Secure Proxy
Server ルート フォルダ パスに置き換えます。
c. アペンダ内の [STS Service Name] を STS インスタンスのサービス名
に置き換えます。
5. 変更を保存します。
6. CA SiteMinder for Secure Proxy Server を再起動します。
各 STS インスタンスのログ ファイルは、
installation_home/proxy-engine/logs に以下の形式で作成されます。
230 管理ガイド
セキュリティ トークン サービス
STS_service_name.log
7. それぞれの STS インスタンスのログが個別のログ ファイルに記録さ
れることを確認します。
第 11 章： Web サービスの設定 231
第 12 章： SiteMinder に SPS を統合する
このセクションには、以下のトピックが含まれています。
SPS と SiteMinder の対話方法 (P. 233)
SPS および SharePoint のリソース (P. 241)
SPS と ERP のリソース (P. 241)
SPS のパスワード サービス (P. 243)
ファイアウォールに関する注意事項 (P. 245)
キープ アライブおよび接続プーリング (P. 245)
Sun Java Web サーバの HTTP ヘッダ設定 (P. 246)
SPS による SiteMinder 処理用の HTTP ヘッダ (P. 246)
エンコードされた URL を処理する (P. 247)
SPS と SiteMinder の対話方法
SiteMinder は、e ビジネスを安全に管理するためのソリューションです。
SiteMinder は、企業のポリシーをユーザが指定できるようにするポリシー
サーバと、Web サーバにインストールされる Web エージェントから構成
されます。 Web エージェントはポリシー サーバと通信し、認証、認可、
および他の機能を提供します。
CA SiteMinder for Secure Proxy Server には、SiteMinder Web エージェントお
よびポリシー サーバ技術と互換性のある Web エージェントが含まれます。
すべての SiteMinder Web エージェントと同様に、CA SiteMinder for Secure
Proxy Server を SiteMinder 内のオブジェクトとして設定する必要がありま
す。 送信先サーバにアクセスするための認証および認可の要件を決定す
るポリシーを作成する必要があります。
第 12 章： SiteMinder に SPS を統合する 233
SPS と SiteMinder の対話方法
SiteMinder オブジェクトは SiteMinder <adminui> を使用して設定されます。
以下のオブジェクトを設定できます。
エージェント
SPS に含まれている Web エージェント用の設定を指定してエージェン
ト オブジェクトを設定します。レルムを作成する場合、この Web エー
ジェントを指定します。
ユーザ ディレクトリ
ユーザを認証し認可する任意のユーザ ディレクトリへの接続を設定
します。
ポリシー ドメイン
レルム、ルール、およびポリシーが含まれるポリシー ドメインを設定
します。
レルム
SiteMinder で保護するリソースが含まれるレルムを設定します。
ルール
SiteMinder で保護する特定のリソースおよびアクションを識別する
ルールを設定します。
レスポンス
アプリケーションまたは SPS に情報を返すことができる任意のレスポ
ンスを設定します。 CA SiteMinder for Secure Proxy Server に返される情
報によって、ユーザ リクエストをどのようにルーティングするかを決
定できます。
ポリシー
ユーザおよびグループをルールおよびレスポンスにバインドするポリ
シーを設定します。
注： SiteMinder オブジェクトを設定する方法に関する詳細情報については、
「CA SiteMinder ポリシー サーバ設定ガイド」を参照してください。
234 管理ガイド
SPS と SiteMinder の対話方法
認証方式に関する注意事項
SiteMinder は、リソースを保護するために認証方式を適用します。 ユーザ
が、SiteMinder Web エージェントまたは SPS によって保護されているリ
ソースへのアクセスを試みると、SiteMinder はリソースを保護する認証方
式に基づいて認証情報を要求します。
また、SiteMinder では認証方式ごとに保護レベルが提供されます。 保護レ
ベルは、ユーザが別々の認証方式で保護されたリソースにアクセスしよう
とするシングル サインオン時に適用されます。このようなシナリオでは、
ユーザは再認証の必要なく、別々の認証方式で保護されているリソースに
アクセスできます（ただし、各認証方式の保護レベルが互いに等しいか、
より低い場合）。 低い保護レベルから高い保護レベルに移る場合、ユー
ザは認証を求められます。 高い保護レベルから低い保護レベルに移る場
合、ユーザは再認証を求められません。
CA SiteMinder for Secure Proxy Server が SiteMinder に統合されている場合、
CA SiteMinder for Secure Proxy Server は SiteMinder Web エージェントと同
様に動作します。 ただし、基本認証を使用する CA SiteMinder for Secure
Proxy Server が Web エージェントと同様に動作するのは、CA SiteMinder for
Secure Proxy Server がデフォルトの SessionCookieScheme スキームを使用
してユーザ セッションを追跡するように設定されている場合のみです。
CA SiteMinder for Secure Proxy Server が他の拡張スキームまたは Cookie な
しのセッション スキームを使用するように設定されている場合、ユーザ
の再認証が必要です。 シングル サインオンは機能しません。
たとえば、保護レベル 5 の基本認証方式では、resource1 および resource2
という 2 つのリソースを保護します。 CA SiteMinder for Secure Proxy Server
は、ミニ Cookie セッション スキーム（または他の Cookie なしのセッショ
ン スキーム）を使用してユーザ セッションを追跡するように設定されて
います。 ユーザが resource1 にアクセスしようとすると、CA SiteMinder for
Secure Proxy Server は SiteMinder にリクエストを転送します。 SiteMinder
は、resource1 の認証方式を確認し、ユーザに認証情報を要求します。
第 12 章： SiteMinder に SPS を統合する 235
SPS と SiteMinder の対話方法
CA SiteMinder for Secure Proxy Server はユーザから認証情報を収集し、
SiteMinder による認証が成功した後、ユーザに resource1 へのアクセスを
許可します。 その後、ユーザが resource2 にアクセスしようとすると、CA
SiteMinder for Secure Proxy Server は SiteMinder にリクエストを転送します。
SiteMinder は、resource2 の認証方式を確認し、ユーザに認証情報を要求し
ます。 CA SiteMinder for Secure Proxy Server はミニ Cookie セッション ス
キームを使用するように設定されているので、CA SiteMinder for Secure
Proxy Server はユーザの再認証を要求します。 CA SiteMinder for Secure
Proxy Server がデフォルトの SiteMinder Cookie セッション スキームを使用
するように設定されている場合、resource2 にアクセスするためにユーザ
の再認証は必要ありません‥
注： 認証方式および各方式の保護レベルの詳細については、「CA
SiteMinder ポリシー設定ガイド」を参照してください。
プロキシ固有の WebAgent.conf の設定
企業で DMZ の背後にインストールされた Web エージェントの
WebAgent.conf 設定ファイル内の多くの設定は、SPS に対して特定の意味
合いを持ちます。
送信先サーバの WebAgent.conf ファイルで変更する必要がある設定には
以下のものが含まれます。
proxytrust
最適化のために、proxytrust ディレクティブには SPS の背後に位置する
送信先サーバの Web エージェントを設定できます。 以下の設定のい
ずれかを入力します。
yes
送信先サーバの Web エージェントは、SPS による認可を自動的に
信頼します。
no
送信先サーバの Web エージェントは毎回認証を要求します。 (デ
フォルト)
236 管理ガイド
SPS と SiteMinder の対話方法
proxytimeout
送信先サーバの Web エージェントに、SPS によって作成されたリクエ
ストで使用されているシングル サインオン トークンをタイムアウト
するように指示します。 値は秒数で入力します。
デフォルト： 120 秒。
送信先サーバ Web エージェントとのポリシー競合の回避
一部の展開では、CA SiteMinder for Secure Proxy Server がプロキシ信頼モー
ドで実行されている場合、CA SiteMinder for Secure Proxy Server は一部の
ユーザからリソースを保護できます。同時に、送信先サーバ上の Web エー
ジェントが別の一部のユーザから同じリソースを保護しています。
以下の図で、送信先サーバ 2 にはそのサーバ用の Web エージェントがあ
ります。エクストラネット ユーザは SPS で認証され認可されます。一方、
イントラネット ユーザは送信先サーバ上の Web エージェントによって認
証され認可されます。 このような状況では、埋め込み CA SiteMinder for
Secure Proxy Server Web エージェントおよび送信先サーバ上の Web エー
ジェント用に、SiteMinder ポリシー ストアにポリシーが存在する必要があ
ります。
第 12 章： SiteMinder に SPS を統合する 237
SPS と SiteMinder の対話方法
注： ポリシーを作成する場合、管理者はポリシーが互いに競合していない
ことを確認する必要があります。 ポリシーが互いに矛盾する場合、
SiteMinder が不要または予期しない動作を許可する可能性があります。
送信先サーバ 2 に含まれているリソース用のポリシーおよび他の必要な
SiteMinder オブジェクトを正しく作成するために、SiteMinder に以下のオ
ブジェクトを作成できます。
■
CA SiteMinder for Secure Proxy Server Web エージェント
■
送信先サーバ 2 の Web エージェント
■
CA SiteMinder for Secure Proxy Server Web エージェントを使用している
レルム
■
送信先サーバ 2 の Web エージェントを使用しているレルム
■
CA SiteMinder for Secure Proxy Server Web エージェントを介してアクセ
スされるリソースに関するルール
■
送信先サーバ 2 の Web エージェントを介してアクセスされるリソー
スに関するルール
■
CA SiteMinder for Secure Proxy Server Web エージェント リソースに関
するポリシー
■
送信先サーバ 2 の Web エージェント リソースに関するポリシー
以下の図では、CA SiteMinder for Secure Proxy Server と Web エージェントの
両方を含む環境で互換性モードが使用されている場合に、単一のリソース
を保護するためにどのように 2 つのポリシーを作成する必要があるかを
示します。
238 管理ガイド
SPS と SiteMinder の対話方法
前の図で、同じリソース用のルールとレルムが、送信先サーバでのリソー
スの場所と、リクエストの転送に使用されるプロキシ ルールに基づいて、
別々のパスを持っている可能性があります。
たとえば、前の図のサンプル設定では、banking.html と呼ばれるリソース
が、server2.company.com/start/banking/ ディレクトリ内の送信先サーバ 2
に置かれる可能性があります。しかし、CA SiteMinder for Secure Proxy Server
には www.company.com/banking/banking.html に対するすべてのリクエス
トをサーバ 2 上の同じ送信先に転送するプロキシ ルールが設定されてい
る可能性があります。 そのため、同じリソースが、同じリソースを表す 2
つの異なる SiteMinder ルールを持つことがあります。 1 つのルールは、イ
ントラネット上の従業員に対してリソースへのアクセスを直接認可しま
す。また、もう 1 つのルールは、エクストラネットから同じリソースにア
クセスする、出張中の従業員を認可します。
ユーザをリダイレクトする SiteMinder ルールの設定
SiteMinder では、ある条件下でリクエストをリダイレクトするレスポンス
オブジェクトを作成する機能を提供します。 たとえば、認証に失敗した
後に、カスタム エラー ページにリクエストをリダイレクトするレスポン
スを作成できます（OnRejectRedirect）。 デフォルトでは、リクエストさ
れた URL を書き換える（シンプル URL リライティング）Cookie のないセッ
ション スキーマの場合、CA SiteMinder for Secure Proxy Server はリダイレク
ト後にユーザ セッション情報を認識します。
リダイレクト後にユーザ セッションを終了するには、SiteMinder
SM_REWRITE_URL ヘッダの値を変更する関連ポリシー用に SiteMinder で
レスポンス属性を作成します。 この HTTP ヘッダは、リダイレクト後に新
しいセッションを強制できるように NO に設定する必要があります。
第 12 章： SiteMinder に SPS を統合する 239
SPS と SiteMinder の対話方法
たとえば、ユーザが保護レベル 5 の認証方式によって保護される realmA
内にリソースを持ち、保護レベル 10 の認証方式によって保護される
realmB 内に第 2 のリソースを持つ場合、（より高い保護レベルのため）
realmB に移動する際に、realmA で正常に認証するユーザが認証情報を要
求されます。
OnRejectRedirect レスポンスが realmB と関連付けられ、ユーザが realmB 内
の認証情報を要求された際に認証に失敗した場合、ユーザがカスタム エ
ラー ページにリダイレクトされた後でも、CA SiteMinder for Secure Proxy
Server のデフォルト動作はユーザの元のセッション情報を保持します。
リダイレクトされた後にユーザのセッションを終了し、次のログイン試行
でまったく新しいセッションを強制するには、SM_REWRITE_URL=NO を設
定するレスポンス属性を作成し、適切なポリシーとレスポンスを関連付け
る必要があります。
240 管理ガイド
SPS および SharePoint のリソース
SPS および SharePoint のリソース
CA SiteMinder for Secure Proxy Server を使って Microsoft SharePoint が管理
するリソースを保護する場合、設定を次のように変更します。
■
CA SiteMinder for Secure Proxy Server Agent Configuration オブジェクト
では、以下のパラメータを設定します。
■
SPClientIntegration = server_name:port
サーバ名は、httpd.conf ファイルの［ServerName］フィールドに対
して設定された値と一致する必要があります。 ほとんどの場合、
ServerName は完全修飾ホスト名ですが、IP アドレスの場合もあり
ます。
■
ProxyAgent = Yes
注：これらのパラメータは CA SiteMinder for Secure Proxy Server
LocalConfig.conf ファイルに追加することもできます。
■
CA SiteMinder for Secure Proxy Server WebAgent.conf ファイルで、
SharePoint プラグイン（WIndows では SPPlugin.dll、Solaris では
libSPPlugin.so）の場所をポイントする LoadPlugin パラメータを追加しま
す。
■
server.conf ファイルで、以下のパラメータを備えた VirtualHost エレメ
ントを追加します。
<VirtualHost name="VHName">
hostnames="host_name, host_name"
enableredirectwrite="yes"
redirectwritablehostnames="server1.company.com, domain1.com"
</VirtualHost>
注： 詳細については、「CA SiteMinder Agent for SharePoint ガイド」を参照
してください。
SPS と ERP のリソース
CA SiteMinder for Secure Proxy Server を使って、ERP システムが管理するリ
ソースを保護することができます。 CA SiteMinder for Secure Proxy Server
は、以下の ERP システムを保護する ERP エージェントの前に配置されたプ
ロキシとして機能します。
■
Siebel アプリケーション サーバ
■
PeopleSoft アプリケーション サーバ
第 12 章： SiteMinder に SPS を統合する 241
SPS と ERP のリソース
■
SAP AS Web アプリケーション サーバ
■
SAP ITS アプリケーション サーバ
ERP エージェントは ERP サーバにインストールする必要がありますが、CA
SiteMinder for Secure Proxy Server はポリシー サーバの ERP リソース保護し
ます。
注：ERP サーバをサポートするために必要なポリシー サーバの設定につい
ては、適切な CA ERP エージェント ガイドを参照してください。
ERP エージェントに対するリバース プロキシとして CA SiteMinder for Secure
Proxy Server を設定する方法
1. proxyRules.xml ファイルで <_nete:forward>エレメントに対して ERP
サーバと適切なポート番号を指定します。
2. server.conf ファイルで以下の値を指定します。
■
enableredirectrewrite パラメータの値を Yes に設定します。
■
redirectrewritablehostnames パラメータの値を ERP サーバが実行さ
れているシステムのホスト名に設定します。 例：
<VirtualHost name="sales">
hostnames="sales, sales.company.com"
enableredirectrewrite="yes"
redirectrewritablehostnames="server1.company.com,domain1.com"
</VirtualHost>
■
server.conf の <_Sever> セクションで addquotestocookie パラメータ
の値を "no" に設定します。 例：
addquotestocookie="no"
注： ERP サーバ側での必須設定の詳細については、ご使用の ERP サーバ
用のマニュアルを参照してください。
CA SiteMinder for Secure Proxy Server は ERP エージェント用のプロキシと
して設定されます。
242 管理ガイド
SPS のパスワード サービス
SPS のパスワード サービス
パスワード サービスは、SiteMinder 管理者によるユーザ パスワードの管理
を可能にし、保護されているリソースへのセキュリティの追加のレイヤを
提供する SiteMinder 機能です。 パスワード サービスにより管理者はパス
ワード ポリシーを作成してルールと制限を定義し、パスワードの有効期
限、構成、使用方法を決定します。
SiteMinder 内のパスワード サービスを設定する場合、パスワード ポリシー
はディレクトリと関連付けられます。 ディレクトリに含まれているすべ
てのユーザ、または LDAP 検索式によって識別されたディレクトリの一部
分は、パスワード ポリシーを厳守する必要があります。 パスワード サー
ビスは、エージェントをホストしているバックエンド Web サーバからで
はなく、Apache Web サーバの内部から処理されます。
注： パスワード サービスの詳細については、「Policy Design Guide」を参照
してください。
SPS のパスワード ポリシーの設定
SiteMinder が CA SiteMinder for Secure Proxy Server 展開にパスワード サー
ビスを実装するには、ポリシー サーバ ユーザ インターフェースで指定さ
れたリダイレクト URL は、特定の仮想ディレクトリ パスを加えたもので、
CA SiteMinder for Secure Proxy Server サーバを参照する必要があります。
SPS のパスワード ポリシーを設定する方法
1. ポリシー サーバ ホスト ユーザ インターフェースにログインします。
2. ポリシー サーバのユーザ インターフェースで［システム］タブを選択
します。
3. ユーザ ディレクトリ オブジェクトをクリックします。
4. ユーザ ディレクトリ リストで、パスワード サービスで保護するディ
レクトリを選択します。
5. 右クリックし、ユーザ ディレクトリの［プロパティ］を選択します。
［ユーザ ディレクトリのプロパティ］ダイアログ ボックスが表示され
ます。
6. ［認証情報と接続］タブで、［認証情報が必要］を選択します。
7. ユーザ名やパスワードなど、管理者の認証情報を入力します。
第 12 章： SiteMinder に SPS を統合する 243
SPS のパスワード サービス
8. 同じダイアログ ボックスの［ユーザ属性］タブで、以下のディレクト
リ ユーザ プロファイル属性の名前を入力します。
■
ユニバーサル ID（例： uid）
■
無効フラグ（例： carLicense）
■
パスワードの属性（例： userpassword）
■
パスワード データ（例： audio）
注： ［ユーザ ディレクトリのプロパティ］ダイアログ ボックスの詳細
については、ポリシー サーバ ユーザ インターフェースのヘルプを参
照してください。
9. ［OK］をクリックします。
10. ［システム］タブで、［パスワード ポリシー］オブジェクトを選択し
ます。
11. ［パスワード ポリシー］オブジェクトを右クリックし、［パスワード
ポリシーの作成］を選択します。
［パスワード ポリシーのプロパティ］ダイアログ ボックスが表示され
ます。
12. ［一般］タブで、パスワード サービスの設定を行ったユーザ ディレク
トリの名前を選択します。
13. ［一般］ タブで、以下のようにリダイレクト URL を指定します。
/siteminderagent/pw/smpwservicescgi.exe
14. ［OK］をクリックします。
設定が完了しました。
SPS 用のパスワード サービスの確認
SPS 用のパスワード サービスを設定した後、パスワード サービスが有効か
どうか確認するために単純なテストを実行できます。
パスワード サービスが動作しているかどうかを確認する方法
1. ユーザ ディレクトリ リストからパスワードで保護されているディレ
クトリを選択します。
2. ［ツール］メニューから［ユーザ アカウントの管理］を選択します。
［ユーザ管理］ダイアログ ボックスが表示されます。
244 管理ガイド
ファイアウォールに関する注意事項
3. ユーザを選択します。
4. ［ユーザは次回ログイン時にパスワードﾞ変更が必要］チェック ボッ
クスをオンにします。
5. ［OK］をクリックします。
CA SiteMinder for Secure Proxy Server で保護されているページを次回要求
した際に、認証を求められた場合は、指定の認証情報を入力します。 パ
スワードサービスが動作していることを示すパスワード変更画面が表示
されます。
ファイアウォールに関する注意事項
SPS が含まれる DMZ 用のファイアウォールを設定する場合、CA SiteMinder
for Secure Proxy Server は内部通信用にポート 8007 および 8009 を使用しま
す。 これらのポートは DMZ の外側にあるエンティティによるアクセスか
ら保護されている必要があります。
注： server.conf ファイル内の適切なディレクティブを変更することで、CA
SiteMinder for Secure Proxy Server によって使用されるポートを変更できま
す。
キープ アライブおよび接続プーリング
CA SiteMinder for Secure Proxy Server は、サーバ接続の開始から生成された
ワークロードを分散させることによって、より高いパフォーマンスを提供
するために、接続プールを使用するよう設計されています。 これは、キー
プ アライブ設定を送信先サーバに対して有効にする必要があるというパ
フォーマンス上の理由から推奨されます。
送信先サーバ製品のすべてに、キープ アライブ設定を管理するための個
別のメソッドおよび属性があります。 SPS を設定する際に、これらの設定
は確認および認識される必要があります。
第 12 章： SiteMinder に SPS を統合する 245
Sun Java Web サーバの HTTP ヘッダ設定
Sun Java Web サーバの HTTP ヘッダ設定
デフォルトでは、Sun Java Web サーバなどの一部の Web サーバは、リクエ
ストに指定できるヘッダ変数の数を制限します。 多くのカスタム ヘッダ
が含まれるトランザクションを処理するために、この上限を引き上げるこ
とが必要になる場合があります。
ヘッダの数が許可される最大数を超えている場合、サーバは通常［リクエ
スト エンティティが大きすぎます］という 413 エラーを返します。 詳細
については、送信先サーバの管理ガイドを参照してください。
ヘッダの最大数を変更する方法
1. バックエンド Sun Java Web サーバの magnus.conf ファイルを見つけて、
テキスト エディタで開きます。
2. magnus.conf 内の以下のエントリを追加または変更します。
MaxRqHeaders 50
CA SiteMinder for Secure Proxy Server トランザクションによって作成さ
れるヘッダの数よりも 1 レベル上の最大値を設定してください。
3. 変更を有効にするために、Sun Java Web サーバを再起動します。
SPS による SiteMinder 処理用の HTTP ヘッダ
CA SiteMinder for Secure Proxy Server により、従来の SiteMinder アーキテク
チャに追加のレイヤが導入されました。 このレイヤはすべての要求を企
業内の宛先サーバに転送またはリダイレクトします。 CA SiteMinder for
Secure Proxy Server がリクエストを処理する場合、ユーザがリクエストし
た URL は SM_PROXYREQUEST という HTTP ヘッダ変数内に保持されます。
CA SiteMinder for Secure Proxy Server がリクエストをプロキシする前の、
ユーザがリクエストした元の URL を必要とする他のアプリケーションは、
このヘッダを使用できます。
エージェント設定オブジェクト内の ProxyAgent パラメータの値は、バック
エンドに SM_PROXYREQUEST HTTP ヘッダを送信できるように YES に設定
する必要があります。
注： 保護されているリソースにリクエストされる場合にのみ、このヘッダ
が追加されます。
246 管理ガイド
エンコードされた URL を処理する
エンコードされた URL を処理する
Web サーバは、エンコードおよびデコードされた、正規化された URL また
はエスケープされていない URL の両方を処理できます。 Web サーバがエ
ンコードされた URL を処理する方法は、サーバのタイプによって異なりま
す。 セキュリティ上の理由から、また、一貫した動作を提供ために、CA
SiteMinder for Secure Proxy Server は常に処理前に URI をデコードまたは正
規化します。 これによって、単一の URL 用のユニバーサル表現が提供さ
れ、エンコードされた文字列を使用して CA SiteMinder for Secure Proxy
Server の悪用が回避されます。
第 12 章： SiteMinder に SPS を統合する 247
第 13 章： SessionLinker をサポートするため
の CA SiteMinder® SPS の設定
このセクションには、以下のトピックが含まれています。
SessionLinker をサポートするための SPS の設定 (P. 250)
第 13 章： SessionLinker をサポートするための CA SiteMinder® SPS の設定 249
SessionLinker をサポートするための SPS の設定
SessionLinker をサポートするための SPS の設定
SessionLinker はセキュリティを強化するため、CA SiteMinder® セッション
とサードパーティ アプリケーシ ョン セッションを同期させます。 デフォ
ルトでは、CA SiteMinder for Secure Proxy Server は SessionLinker を無効モー
ドでインストールします。
次の図は、CA SiteMinder for Secure Proxy Server 管理者とポリシー管理者が
SessionLinker をサポートするために CA SiteMinder for Secure Proxy Server
をどのように設定できるかを説明しています。
250 管理ガイド
SessionLinker をサポートするための SPS の設定
SessionLinker の仕組み
SessionLinker はセキュリティを向上させるため、SiteMinder セッションと
サードパーティ製アプリケーション セッションを同期させます。
SiteMinder からログアウトした場合、SessionLinker はサードパーティ アプ
リケーションの関連セッションを無効にします。
ユーザ認証の実行時、SiteMinder はそのユーザ セッションに一意のセッ
ション識別子を割り当てます。 SiteMinder セッション ID と呼ばれるセッ
ション識別子は、ユーザ セッションの有効期間中、対象ユーザに対して
一定のままです。Logout URL を介してユーザが SiteMinder からログアウト
すると、SiteMinder セッション ID を追跡するために SiteMinder が使用した
SMSESSION Cookie が削除されます。
SessionLinker モジュールは、アプリケーション セッション Cookie を取得し、
SiteMinder セッションと Cookie を 1 つずつを関連付けます。関連付けが終
了したら、アプリケーション Cookie（ここでは「外部 Cookie」と呼びます）
は、特定の SiteMinder セッションと組み合わせた場合のみ使用できます。
SessionLinker は、別の SiteMinder セッションが同じ外部セッションを使用
することを許可しません。
SessionLinker の操作を理解するには、以下の例のように、SiteMinder セッ
ションと、SiteMinder が追跡する対応する外部 Cookie を、テーブルを使っ
て関連付けます。
SiteMinder セッション ID
外部 Cookie
ONE
ABCD
TWO
LMNO
THREE
PQRST
FOUR
VWXY
第 13 章： SessionLinker をサポートするための CA SiteMinder® SPS の設定 251
SessionLinker をサポートするための SPS の設定
SessionLinker は、以下のプロセスを使用します。
1. SessionLinker は Web サーバからリクエストを受信します。
2. SessionLinker は、HTTP ヘッダから SiteMinder セッション ID を抽出し、
受信するすべての HTTP Cookie から外部 Cookie を抽出します。
3. SessionLinker は、リクエストを許可するかどうかを決定するため、Web
サーバから提供された値をテーブルの内容と比較します。次に例を示
します。
a. セッション ID が FIVE で外部 Cookie が RSTU の場合、SessionLinker
はこの値をテーブルに挿入します。
b. セッション ID が SIX で外部 Cookie が ABCD の場合、外部 Cookie
ABCD は Session ONE にすでに関連付けられているため、
SessionLinker はリクエストをブロックします。
c. セッション ID が ONE で外部 Cookie が HIJK の場合、古いセッショ
ンは孤立し、SessionLinker はテーブルを更新して、セッション ID
ONE を HIJK に関連付けます。 セッションが孤立すると、その外部
Cookie を提供することはできなくなります。 この機能を使用する
と、SessionLinker はユーザ セッション中 Cookie を更新するアプリ
ケーションをサポートすることができるようになります。
プロセス全体が各外部 Cookie に対して繰り返されます。 生成されるテー
ブルが以下のように表示される可能性があります。
SiteMinder セッション ID
外部 Cookie
***Orphaned***
ABCD
ONE
HIJK
TWO
LMNO
THREE
PQRST
FOUR
VWXY
FIVE
RSTU
252 管理ガイド
SessionLinker をサポートするための SPS の設定
SessionLinker がサポートしないもの
SessionLinker は、以下のタスクはいずれも行いません。
■
CA SiteMinder® 環境全体にわたって発行された Cookie を追跡します。
そうする場合、SessionLinker を使用するすべての Web サーバによって
読み書きできる永続データ ストアを必要とします。このトラッキング
をサポートするのに必要な膨大な数の読み取りおよび書き込みは、か
なりの処理能力および帯域幅を必要とし、したがって管理不能です。
■
ユーザが CA SiteMinder® からログアウトする場合、既存ユーザの
Cookie を破棄します。 Cookie が中心で追跡されていないので、どの
Cookie を破棄したらよいのかを知るメカニズムはありません。 さらに、
異なる Web ブラウザが Cookie を処理する方法のために、ログアウト
ページは、ユーザがどの Cookie を受信したか必ずしも断定できません。
最後に、SessionLinker は CA SiteMinder® ログアウト プロセスとは実際
には統合しません。
■
基礎となるアプリケーションのセッションを終了します。 この機能を
サポートすると、SessionLinker は、アプリケーション（それらの多く
はセッションを管理するための露出した API を持っていない）の各々
でのセッションを終了する方法を知る必要があります。 ある程度のア
イドル時間の後にセッションを終了するようアプリケーションを設定
でき、セッションをアクティブにしておくことでオーバーヘッドはほ
とんどないことから、この機能は実装されていません。
SessionLinker はユーザが無効な Foreign Session Cookie を示すのを妨げるこ
とにより、リンクを実行します。
SessionLinker の有効化
SessionLinker を有効にすると、CA SiteMinder® セッションがサードパー
ティ アプリケーション セッションと同期します。 この機能を有効にした
後、SessionLinker ACO を設定できます。
次の手順に従ってください：
1. ［仮想ホスト］、［仮想ホスト］、［仮想ホストの編集/追加］、［Web
エージェント設定］と移動します。
2. ［セッション リンカの有効化］オプションをオンにします。
3. ［保存］をクリックします。
4. CA SiteMinder for Secure Proxy Server サーバを再起動します。
第 13 章： SessionLinker をサポートするための CA SiteMinder® SPS の設定 253
SessionLinker をサポートするための SPS の設定
NPS_Session_Linker ACO の作成
CA SiteMinder for Secure Proxy Server は、ACO を介して SessionLinker 設定を
管理します。 SessionLinker ACO の構文は、以下のとおりです。
SessionLinker=Cookie=cookie_value;BLOT|NOBLOT;Orphantimeout=timeout_value;
説明
COOKIE= cookie 名
外部セッションを保持している Cookie 名を指定します。Cookie 名が変
わる可能性がある場合は、ワイルドカード文字としてアスタリスクを
使用します。
BLOT|NOBLOT
（オプション）SessionLinker が無効なセッションに応答する方法を指
定します。 このパラメータの値を BLOT に設定した場合、ユーザには
アクセス権限が付与されますが、外部セッション Cookie は Web サー
バを介してターゲット ページに渡されません。 このパラメータ値を
NOBLOT に設定すると、外部 Cookie がリクエストから削除されます。
また、ユーザは URL パラメータで指定された URL にリダイレクトされ
ます。 URL パラメータで URL を指定しない場合、内部サーバ エラーが
表示されます。
デフォルト： BLOT
ORPHANTIMEOUT= 秒
SessionLinker が孤立したセッションを維持する秒数を指定します。
デフォルト： 86400 （24 時間の秒数）
制限： サードパーティ（外部）アプリケーションからの Cookie の受理
は、最大秒数未満にしないでください。
CA SiteMinder for Secure Proxy Server を設定して SessionLinker をサポート
するには、以下のいずれかの方法で SessionLinker という名前の ACO を作成
します。
254 管理ガイド
■
webagent.conf ファイルの使用
■
WAMU の使用
SessionLinker をサポートするための SPS の設定
webagent.conf を使用した NPS_Session_Linker ACO の作成
ローカル設定を使って SessionLinker ACO を作成するには、webagent.conf
ファイルを使用して、ACO を作成します。
次の手順に従ってください：
1. webagent.conf ファイルで指定した localconfigfile を開きます。
2. ファイルに、次のコマンドを追加します。
SessionLinker= Cookie=cookie_value;BLOT|NOBLOT;Orphantimeout=timeout_value;
3. 変更を保存します。
SessionLinker ACO が作成されます。SessionLinker をサポートするように CA
SiteMinder for Secure Proxy Server を設定します。
Cookie と連動するように SessionLinker を設定する場合は、「Cookie の動
作」を参照してください。 SessionLinker によって引き起こされたすべての
エラーをトラブルシューティングトするには、「トラブルシューティン
グ」を参照してください。
WAMUI を使用した NPS_Session_Linker ACO の作成
SessionLinker ACO を作成するセントラル設定を使用する場合、ポリシー管
理者は WAMUI によって ACO を作成する必要があります。
次の手順に従ってください：
1. WAMUI を開きます。
2. 以下の詳細を使って ACO を追加します。
Name: SessionLinker
Value: Cookie=cookie_name;BLOT|NOBLOT;Orphantimeout=timeout_value;
3. ［保存］をクリックします。
SessionLinker ACO が作成されます。SessionLinker をサポートするように CA
SiteMinder for Secure Proxy Server を設定します。
Cookie と連動するように SessionLinker を設定する場合は、「Cookie の動
作」を参照してください。 SessionLinker によって引き起こされたすべての
エラーをトラブルシューティングトするには、「トラブルシューティン
グ」を参照してください。
第 13 章： SessionLinker をサポートするための CA SiteMinder® SPS の設定 255
SessionLinker をサポートするための SPS の設定
Cookie の動作
単一セッション Cookie の適用
ほとんどの場合、アプリケーションには、関連付けられたセッション
Cookie に対して常に使用される特定の名前があります。 それ以外の場合、
Cookie の名前は ASPSESSIONID、MYAPPSESSION などの既知の文字列で始ま
り、ランダムまたは予測不能のサフィックスで終了します。 このような
場合、SessionLinker は、ユーザによる複数の Cookie の指定を防止し、予想
されるセッションのリンキングを適用します。
SessionLinker が複数の潜在的なセッション Cookie を検出した場合、以下の
手順が実行されます。
1. セッションへのアクセスをブロックします。
2. Cookie をすべて破棄します
3. ユーザを指定された URL にリダイレクトします。 URL を指定しない場
合、内部サーバ エラーが表示されます。
256 管理ガイド
SessionLinker をサポートするための SPS の設定
ワイルドカード Cookie 名の有効化
ポリシー サーバで設定されている ACO の以下のパラメータを、すでに選
択されていた設定に追加できます。
Cookie
指定された名前で始まる Cookie を、潜在的な外部セッション Cookie と
見なす必要があることを指定します。 Cookie 値はアスタリスク（*）
に終わる可能性があります。ワイルドカード構文以外の Cookie 値を指
定した場合、受信する Cookie を破棄する方法を決定する COOKIEPATH
および COOKIEDOMAIN の値を指定する必要があります。
COOKIEPATH
Cookie パスを指定します。COOKIE パラメータ用のワイルドカード構文
を指定した場合、このパラメータは指定しません。COOKIEPATH 値は、
セッション Cookie によって決まり、以下の形式があります。
COOKIEPATH=<送信 Cookie または Cookie のパス>
デフォルト値： /
例： COOKIEPATH=
COOKIEDOMAIN
Cookie ドメインを指定します。COOKIE パラメータ用のワイルドカード
構文を指定した場合、以下の形式でこの値を指定できます。
COOKIEDOMAIN=<送信 Cookie または Cookie のドメイン名>
デフォルト値： 空白
例： COOKIEDOMAIN=.ca.com
Cookie の設定を決定します。
Cookie 名設定を決定するには、以下の手順に従います。
1. アプリケーションに複数回アクセスします。
2. アプリケーションが送信する Cookie を書き留めます。
3. Web ブラウザで Cookie の警告プロンプトを有効にします。
4. 表示される警告を調べます。
第 13 章： SessionLinker をサポートするための CA SiteMinder® SPS の設定 257
SessionLinker をサポートするための SPS の設定
COOKIE の設定
アプリケーション用のセッション Cookie の名前が同じテキスト文字列で
始まり、別の文字列で終了する場合、以下の形式で Cookie 名を指定しま
す。
COOKIE=cookiename*
COOKIEDOMAIN の設定
Cookie のドメイン名は、以下の任意の項目から構成されます。
■
先頭にピリオド（.）が付けられた Web サーバのドメイン名
■
Web サーバの完全修飾コンピュータ名（myserver.example.com）
■
ブランク
完全修飾コンピュータ名またはブランク名は同等です。
注： Internet Explorer は、ドメインを表示する前に先頭のピリオドを削除し
ます。 このため、正しい設定を決定するには、ステージング環境でさま
ざまな設定をテストすることをお勧めします。
COOKIEPATH の設定
Cookie と関連付けられたパスは通常ディレクトリですが、ファイルまたは
別の文字列である場合もあります。 Web ブラウザの Cookie 警告ダイアロ
グに表示されるパスを確認します。 表示されたパスがスラッシュ（/）で
ない場合は、COOKIEPATH 設定に正しい値を入力します。
複数の Cookie へのリンクのメンテナンス
一部の Web アプリケーションは、サイトの同じ領域内で複数の Cookie を
同時に使用します。 単一 CA SiteMinder® セッションから多数の Cookie へ
のリンクをメンテナンスするように SessionLinker を設定できます。最大の
10 の外部セッション Cookie を単一 CA SiteMinder® セッションにリンクで
きます。
258 管理ガイド
SessionLinker をサポートするための SPS の設定
次の手順に従ってください：
1. 各 Cookie の正しい設定文字列を決定します。
注： 各設定文字列は尐なくとも 1 つの COOKIE ディレクティブを必要
としますが、任意のディレクティブと組み合わせることができます。
2. 各 Cookie に 0 ～ 9 の整数を割り当てます。
3. 選択した数をディレクティブ名に追加します。
注：ディレクティブのセットごとに任意の数を使用できますが、1 つの
Cookie の設定には同じ数が必要です。
4. 個別の設定文字列を単一の文字列へ連結します。
SessionLinker のトラブルシューティング
エラーが発生する場合、エラーをトラブルシューティングするため、以下
の可能性を検討してください。
■
有効な SMSESSION Cookie および FOREIGN SESSION Cookie がユーザ側で
設定され、CA SiteMinder for Secure Proxy Server に渡されることを確認
します。
■
webagent.conf ファイルを使用して SessionLinker を有効にした場合、
Web エージェントが有効であることを確認します。
■
SessionLinker ACO 構文が正しいことを確認します。
■
SessionLinker ACO でエージェント追跡が有効な場合、エージェント ロ
グおよびトレース内のログとトレース メッセージを確認します。
■
CA SiteMinder for Secure Proxy Server が SessionLinker プラグイン バイナ
リを正しくロードしたことを確認します。 ログ メッセージがあるか、
agents.log ファイルを確認します。 エラーがある場合は、依存ライブ
ラリが CA SiteMinder for Secure Proxy Server の SessionLinker プラグイン
ライブラリに存在するかどうかを確認します。
■
リクエストが拒否された場合、CA SiteMinder® ポリシー サーバのセッ
ション ID（SMSESSION）およびアプリケーション Web サーバのセッ
ション ID（FOREIGN SESSION）が同じユーザにリンクされていることを
確認します。
第 13 章： SessionLinker をサポートするための CA SiteMinder® SPS の設定 259
第 14 章： SSL および Secure Proxy Server
このセクションには、以下のトピックが含まれています。
SPS 用の SSL の設定 (P. 261)
仮想ホストに対する SSL の有効化 (P. 270)
SPS 用の SSL の設定
CA SiteMinder for Secure Proxy Server は SSL をサポートしており、クライア
ントとサーバの間で安全な通信を提供します。 CA SiteMinder for Secure
Proxy Server では OpenSSL 暗号化ツールキットを使用します。このツール
キットには SSL v2/v3 およびトランスポート レイヤ セキュリティ（TLS v1）
ネットワーク プロトコル、およびこれらのプロトコルに必要な関連する
暗号化標準が実装されています。 OpenSSL ツールキットには、キーおよび
証明書を生成するための openssl コマンド ライン ツールが含まれます。
openssl の実行可能イメージおよびサポート ライブラリは、
installation_home¥SSL¥bin フォルダまたは対応する UNIX ディレクトリにあ
ります。
第 14 章： SSL および Secure Proxy Server 261
SPS 用の SSL の設定
以下のフローチャートは、CA SiteMinder for Secure Proxy Server 用の SSL を
設定する方法を説明しています。
262 管理ガイド
SPS 用の SSL の設定
次の手順に従ってください：
1. 注意事項を確認します。
2. 以下のいずれかの手順を使用して、秘密キーを生成します。
■
暗号化された RSA サーバ秘密キーを生成します。
■
暗号化されていない RSA サーバ秘密キーを生成します。
3. 以下のいずれかの手順を使用して、証明書署名リクエストを生成し、
サブミットします。
■
認証機関への証明書署名リクエストを生成してサブミットします。
■
証明書署名リクエストを生成して自己署名します。
4. 認証機関から証明書をダウンロードしてインストールします。
5. 以下のいずれかの手順を使用して、SSL を有効にします。
■
暗号化された秘密キーに対して SSL を有効にします。
■
Windows 上の暗号化されていない秘密キーに対して SSL を有効に
します。
■
UNIX 上の暗号化されていない秘密キーに対して SSL を有効にしま
す。
SSL が設定されます。
注意事項の確認
SSL を設定する前に、秘密キーおよびサーバ証明書に関する以下の情報を
確認します。
■
サーバ証明書と秘密キーは連携して動作するため、対応する秘密キー
を含むサーバ証明書を使用します。
■
サーバ証明書は認証機関（CA）によってデジタル署名する必要があり
ます。 社内デモ用に SSL を有効にする場合、サーバ証明書をユーザ自
身の秘密キーで自己署名することができます。
■
SSL.conf ファイル内の SSLCertificateFile および SSLCertificateKeyFile ディ
レクティブは、対応する証明書およびキー ファイルを指している必要
があります。
■
Apache の仮想ホスト機能を使用している場合、保護する各仮想ホスト
にはそれぞれの秘密キーおよびサーバ証明書が必要です。
第 14 章： SSL および Secure Proxy Server 263
SPS 用の SSL の設定
秘密キーの生成
SSL ではキーを使用し、メッセージを暗号化および復号化します。 キーは
ペアで提供されます（公開キー 1 つと秘密キー 1 つ）。
キーでは、さまざまな暗号化アルゴリズムおよびキー交換メソッドを使用
します。証明書で使用する秘密キーを生成するには、一般的に、DES（Data
Encryption Standard）暗号化アルゴリズムを含む RSA キー交換メソッドが
使用されます。 キー出力ファイルは、暗号化された ASCII PEM 形式です。
264 管理ガイド
SPS 用の SSL の設定
暗号化された RSA サーバ秘密キーの生成
サーバ キーを保護する場合は、暗号化された RSA サーバ秘密キーを生成
します。
次の手順に従ってください：
1. コマンド ライン ウィンドウを開きます。
2. 以下のディレクトリに移動します。
installation_home¥SSL¥bin
installation_home
CA SiteMinder for Secure Proxy Server のインストール先ディレクト
リを定義します。
デフォルト：（Windows）［32-bit］C:¥Program Files¥CA¥secure-proxy
デフォルト： （Windows） ［64-bit］ C:¥CA¥secure-proxy
デフォルト： （UNIX/Linux）/opt/CA/secure-proxy
3. 以下のコマンドを実行します。
.¥openssl genrsa -des3 -out ..¥keys¥server.key [numbits]
server
サーバの完全修飾ドメイン名を指定します。
（オプション） numbits
生成する必要がある秘密キーのサイズ（ビット単位）を指定しま
す。
デフォルト： 1024
範囲： 1024 ～ 2048
暗号化されたサーバ秘密キーが作成され、指定されたキー出力ファイ
ルに書き込まれます。キー出力ファイルは、暗号化された ASCII PEM 形
式です。 このファイルは暗号化されているため、必要に応じて後で
ファイルを保護および復号化する際には、パスフレーズの入力を要求
されます。
第 14 章： SSL および Secure Proxy Server 265
SPS 用の SSL の設定
暗号化されていない RSA サーバ秘密キーの生成
サーバ キーを保護する必要がない場合は、暗号化されていない RSA サー
バ秘密キーを生成します。
次の手順に従ってください：
1. コマンド ライン ウィンドウを開きます。
2. 以下のディレクトリに移動します。
installation_home¥SSL¥bin
installation_home
CA SiteMinder for Secure Proxy Server のインストール先ディレクト
リを定義します。
デフォルト：（Windows）［32-bit］C:¥Program Files¥CA¥secure-proxy
デフォルト： （Windows） ［64-bit］ C:¥CA¥secure-proxy
デフォルト： （UNIX/Linux）/opt/CA/secure-proxy
3. 以下のコマンドを実行します。
.¥openssl genrsa -out ..¥keys¥server.key [numbits]
server
サーバの完全修飾ドメイン名を指定します。
（オプション） numbits
生成する必要がある秘密キーのサイズ（ビット単位）を指定しま
す。
デフォルト： 1024
範囲： 1024 ～ 2048
暗号化されていないサーバ秘密キーが生成されます。
証明書署名リクエストの生成およびサブミット
秘密キーを使用して、証明書リクエストまたは証明書署名リクエストを生
成します。 証明書署名リクエストを認証機関に送信して証明書に署名す
るか、または、社内デモ用に自己署名証明書を作成することができます。
266 管理ガイド
SPS 用の SSL の設定
証明書署名リクエストの生成および認証機関へのサブミット
証明書署名リクエストを生成し、ユーザの組織が使用する認証機関にサブ
ミットします。
次の手順に従ってください：
1. コマンド ライン ウィンドウを開きます。
2. 以下のコマンドを実行します。
.¥openssl req -config .¥openssl.cnf -new -key ..¥keys¥server.key
-out ..¥keys¥server.csr
3. 画面の指示に従って値を入力します。
システムは、証明書ファイル名とリクエスト番号を含む証明書リクエ
ストを生成します。
4. （オプション）後で参照するためにファイル名と証明書署名リクエス
トを記録しておきます。
5. 証明書署名リクエストを認証機関にサブミットします。
自己署名証明書の生成
社内デモ用に SSL を有効にする場合は、自己署名証明書を生成します。
次の手順に従ってください：
1. コマンド ライン ウィンドウを開きます。
2. 以下のコマンドを実行します。
.¥openssl req -config .¥openssl.cnf -new -x509 -key ..¥keys¥server.key
-out ..¥certs¥cert_name.crt
3. 出力ファイルを以下の場所に置きます。
sps_home¥SSL¥certs
自己署名証明書が生成されます。
第 14 章： SSL および Secure Proxy Server 267
SPS 用の SSL の設定
認証機関からの証明書のダウンロードおよびインストール
署名付き証明書を認証機関からダウンロードします。
次の手順に従ってください：
1. 証明書リクエストを発行した CA SiteMinder for Secure Proxy Server ホス
トにログインします。
2. httpd-ssl conf ファイルを開きます。
デフォルト パス： installation_home¥httpd¥conf¥extra¥httpd-ssl.conf
3. サーバ キーおよび証明書のディレクティブが正しいことを確認しま
す。
4. SSLPassPhraseDialog 変数の値をカスタムに設定します。
5. SSLCustomPropertiesFile 変数の値を
<installation_home>¥httpd¥conf¥spsapachessl.properties に設定します。
6. RootCA への参照が設定されていることを確認します。
7. RootCA または自己署名証明書を ca-bundle.cert に追加するには、以下
の手順に従います。
a. メモ帳で証明書を開き、BEGIN から END までの行をコピーします。
b. メモ帳で ca-bundle.cert を開き、証明書の行を末尾に貼り付けます。
c. 変更を保存します。
SSL の有効化
暗号化された秘密キー、または暗号化されていない秘密キーに対して SSL
を有効化することができます。
268 管理ガイド
SPS 用の SSL の設定
Windows 上の暗号化されていない秘密キーに対して SSL を有効化
Windows 上の暗号化されていない秘密キーに対して SSL を有効化するに
は、spsapachessl.properties ファイルを生成します。
次の手順に従ってください：
1. 管理者権限を使用してコマンドライン ウィンドウを開きます。
2. 以下のディレクトリに移動します
installation_home¥httpd¥bin
3. 以下のスクリプト ファイルを実行します。
configssl.bat -enable
注： 上書きの警告が表示される場合は、既存の spsapachessl.properties
ファイルに上書きすることを確認します。
SSL が設定されます。
UNIX 上の暗号化されていない秘密キーに対して SSL を有効化
UNIX 上の暗号化されていない秘密キーに対して SSL を有効化するには、以
下の場所にある spsapachessl.properties を編集します。
installation_home/httpd/conf/spsapachessl.properties
次の手順に従ってください：
1. テキスト エディタで spsapachessl.properties ファイルを開きます。
2. 以下の行を追加するか編集します。
3. 以下のいずれかのタスクを実行します。
■
ファイル内に「apache.ssl.enabled=」が存在する場合は、その行を
以下の値に設定します。
apache.ssl.enabled=Y
■
ファイル内に「apache.ssl.enabled=」が存在しない場合は、以下の
行を追加します。
apache.ssl.enabled=Y
4. 変更を保存します。
SSL が設定されます。
第 14 章： SSL および Secure Proxy Server 269
仮想ホストに対する SSL の有効化
暗号化された秘密キーに対して SSL を有効化
暗号化された秘密キーに対して SSL を有効化するには、
spsapachessl.properties ファイルを生成します。
次の手順に従ってください：
1. 管理者権限を使用してコマンドライン ウィンドウを開きます。
2. 以下のディレクトリに移動します。
Windows
installation_home¥httpd¥bin
UNIX
installation_home/httpd/bin
3. 以下のスクリプトを実行します。
Windows
configssl.bat -enable passphrase
UNIX
configssl.sh passphrase
注： パスフレーズ値は、サーバ キーのパスフレーズ値に一致する必要
があります。 上書きの警告が表示される場合は、既存の
spsapachessl.properties ファイルに上書きすることを確認します。
4. パスフレーズは暗号化され、spsapachessl.properties ファイルに格納さ
れます。
5. セキュア プロキシ サービスを再起動します。
SSL が設定されます。
仮想ホストに対する SSL の有効化
Apache サーバは仮想ホストをサポートします。仮想ホストは単一の
Apache バイナリから実行される複数の Web ホストです。Apache の仮想ホ
ストは名前ベースまたは IP ベースとすることができます。 名前ベースの
仮想ホストは単一の IP アドレスを共有できます。これに対し、IP ベースの
仮想ホストの場合、仮想ホストごとに異なる IP アドレスが必要です。
270 管理ガイド
仮想ホストに対する SSL の有効化
SSL プロトコルを使用する Apache の仮想ホスト：
■
プロトコルの制限により IP ベースである必要があります。
■
セキュリティで保護された（HTTPS）リクエストと、セキュリティで保
護されていない（HTTP）リクエストの両方に対して、Apache 設定ファ
イル内に仮想ホスト コンテナが設定されている必要があります。
セキュリティで保護された（HTTPS）仮想ホストの例を以下に示します。
<VirtualHost 10.0.0.1:443>
DocumentRoot ".../htdocs/site1"
ServerName www.site1.net
ServerAdmin [email protected]
ErrorLog logs/covalent_error_log_site1
TransferLog logs/...
SSLEngine on
SSLCertificateFile /www.site1.net.cert
SSLCertificateKeyFile /www.site1.net.key
CustomLog logs/cipher_log_site1 ¥
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x ¥"%r¥" %b"
</VirtualHost>
第 14 章： SSL および Secure Proxy Server 271
第 15 章： 統合 Windows 認証をサポートす
るための CA SiteMinder® SPS の設定
このセクションには、以下のトピックが含まれています。
統合 Windows 認証をサポートするための SPS の設定 (P. 273)
統合 Windows 認証をサポートするための SPS の設定
統合 Windows 認証（IWA）は、Windows のクライアントとサーバのセキュ
リティ機能を使用します。 IWA では、最初の対話形式のデスクトップ ロ
グイン プロセス時、およびその後のセキュリティ レイヤへの情報の転送
時に Windows がユーザ認証情報を取得することで、シングル サインオン
を実現しています。
SiteMinder では、Windows 認証方式が採用されており、Microsoft の統合
Windows 認証インフラストラクチャで取得されたユーザ認証情報を処理
することで、リソースを保護します。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 273
統合 Windows 認証をサポートするための SPS の設定
次の図は、IWA をサポートするように CA SiteMinder for Secure Proxy Server
を設定する方法を説明しています。
274 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 275
統合 Windows 認証をサポートするための SPS の設定
CA SiteMinder for Secure Proxy Server では、以下のいずれかの認証方式を設
定できます。
■
Windows サーバ上の Windows 認証方式
■
Windows および UNIX サーバ上の Kerberos 認証方式
Windows 認証方式
Windows 認証方式では、Active Directory がネイティブ モードで実行されて
いる展開に加えて、Active Directory が NTLM 認証をサポートするように設
定されている展開でも、SiteMinder がアクセス制御を提供することが可能
です。Windows 認証方式は、イニシエータおよびアクセプタが Kerberos ま
たは NTLMSSP のいずれかと交渉することを可能にするために SPNEGO を
使用します。
Windows 認証の設定
Windows 認証をサポートするには、以下の手順に従います。
1. 前提条件を確認します。
2. Windows 認証方式を設定します。
3. Windows 認証方式を有効にします。
4. 自動ログインをサポートするために Web ブラウザを設定します。
前提条件の確認
CA SiteMinder for Secure Proxy Server を設定して IWA をサポートする前に、
以下のタスクをユーザが実行することを確認します。
1. Windows ドメイン コントローラを設定します。
2. Windows ドメイン コントローラのドメイン ホストのメンバとして CA
SiteMinder for Secure Proxy Server ホストを追加します。
3. 混合モードのレガシー WinNT ディレクトリまたは Active Directory：
276 管理ガイド
■
管理 UI で作成するユーザ ディレクトリ接続で、WinNT ネームス
ペースが指定されていること。
■
リクエストされたリソースは、任意のタイプの Web サーバに置く
ことができること。
統合 Windows 認証をサポートするための SPS の設定
4. ネイティブ モードで稼働している Active Directory：
■
ユーザ データが Active Directory にあること。
■
ユーザ ディレクトリ接続で、LDAP または AD のどちらかのネーム
スペースが指定されていること。
■
リクエストされたリソースは、任意のタイプの Web サーバに置く
ことができること。
■
クライアント アカウントとサーバ アカウントが委任に対応して
いること。
Windows 認証方式の設定
Windows 認証方式を使用して、Windows 環境にあるユーザを認証できます。
注： 以下の手順では、新しいオブジェクトが作成されていることを前提と
します。 また、既存のオブジェクトのプロパティをコピーしてオブジェ
クトを作成することもできます。 詳細については、「ポリシー サーバ オ
ブジェクトの複製」を参照してください。
次の手順に従ってください：
1. ［インフラストラクチャ］-［認証］をクリックします。
2. ［認証方式］をクリックします。
3. ［認証方式の作成］をクリックします。
［認証方式タイプの新しいオブジェクトの作成］が選択されているこ
とを確認します。
［OK］ボタンをクリックします。
4. 名前と保護のレベルを入力します。
5. ［認証方式タイプ］リストから［Windows 認証テンプレート］を選択
します。
認証方式固有の設定が表示されます。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 277
統合 Windows 認証をサポートするための SPS の設定
6. サーバ名、ターゲットおよびユーザ DN 情報を入力します。 NT チャレ
ンジ/レスポンス認証を必要とする環境の場合は、エージェントの所有
者から以下の値を取得します。
Server Name
CA SiteMinder for Secure Proxy Server の完全修飾ドメイン名。たとえ
ば、以下のとおりです。
server1.myorg.com
ターゲット
/siteminderagent/ntlm/smntlm.ntc
注： このディレクトリは、インストール時にすでに設定された仮想
ディレクトリと一致している必要があります。 ターゲットである
smntlm.ntc は、存在していなくてもかまいません。また、.ntc で終
わる名前や、デフォルトの代わりに使用するカスタム MIME タイプ
でもかまいません。
ライブラリ
smauthntlm
7. ［サブミット］をクリックします。
認証方式が保存され、レルムに割り当て可能になります。
注： ユーザ認証が NTLM 認証で失敗しても、ブラウザによって停止される
まで認証処理は続行します。 この問題を解決するには、認証が失敗した
場合にユーザをカスタム ページにリダイレクトする以下のリダイレクト
レスポンスを作成します。
278 管理ガイド
■
onauthreject および onauthusernotfound によるルール
■
Webagent-onreject-redirect によるレスポンス
統合 Windows 認証をサポートするための SPS の設定
Windows 認証方式の有効化
CA SiteMinder for Secure Proxy Server は、Windows 認証方式をサポートして
います。これは、ポリシー サーバ上で設定されます。 CA SiteMinder for
Secure Proxy Server で Windows 認証方式をサポートするには、以下の手順
を実行します。
1. WindowsNativeAuthentication ACO パラメータをポリシー サーバに作成
します。
2. WindowsNativeAuthentication 値を No に設定します。
注： WindowsNativeAuthentication ACO の値を定義または設定しない場合、
CA SiteMinder for Secure Proxy Server は Windows 認証をサポートしません。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 279
統合 Windows 認証をサポートするための SPS の設定
自動ログインをサポートする Web ブラウザの設定
Internet Explorer 5.x および 6.x の各ブラウザで自動ログオンを設定するに
は、以下の手順に従います。
1. Internet Explorer のメニュー バーで、［ツール］-［インターネット オ
プション］を選択します。
［インターネットオプション］ダイアログ ボックスが開きます。
2. ［セキュリティ］タブをクリックして表示します。
3. 使用しているインターネット ゾーンを選択して［レベルのカスタマイ
ズ］をクリックします。
［セキュリティの設定］ダイアログ ボックスが開きます。
4. ［ユーザ認証］で、［ログオン］が表示されるまで下にスクロールし
ます。
5. ［現在のユーザ名とパスワードで自動的にログオンする］ラジオボタ
ンをオンにします。
6. ［OK］をクリックします。
Internet Explorer 4.x のブラウザで自動ログオンを設定するには、以下の手
順に従います。
1. Internet Explorer のメニュー バーで、［ツール］-［インターネット オ
プション］を選択します。
［インターネットオプション］ダイアログ ボックスが開きます。
2. ［セキュリティ］タブをクリックして表示します。
3. ドロップダウンリストから使用しているインターネット ゾーンを選
択します。
4. ［インターネット ゾーン］グループボックスで［カスタム］ラジオボ
タンをオンにし、［設定］をクリックします。
［セキュリティの設定］ダイアログ ボックスが開きます。
5. ［ユーザ認証］で、［ログオン］が表示されるまで下にスクロールし
ます。
6. ［現在のユーザ名とパスワードで自動的にログオンする］ラジオボタ
ンをオンにします。
7. ［OK］をクリックします。
280 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
Windows 認証をサポートするように CA SiteMinder for Secure Proxy Server
が設定されます。
Kerberos 認証方式
Kerberos は、MIT で設計された標準的なプロトコルで、オープン ネット
ワーク上のクライアントとサーバ間の認証の手段を提供します。 Kerberos
プロトコルは、メッセージを盗聴とリプレイ攻撃から保護します。
Kerberos は共有秘密キー、対称鍵および Kerberos サービスを使用します。
Microsoft Windows オペレーティング環境は、デフォルト認証パッケージと
して Kerberos V5 を使用します。Solaris 10 にも Kerberos V5 が含まれていま
す。
Kerberos 環境で、ユーザ アカウントとサービス アカウントはプリンシパ
ルと命名されます。 Kerberos は、信頼できるサードパーティ（Key
Distribution Center、つまり KDC）を使用してプリンシパル間のメッセージ
交換を仲介します。Key Distribution Center の目的はキー交換固有のリスク
を減らすことです。
Kerberos 認証は、チケットを要求し配信するメッセージに基づきます。Key
Distribution Center は 2 種のチケットを処理します。
■
チケット交付チケット（TGT） -- リクエスタの認証情報をチケット交
付サービス（TGS）に転送するために KDC によって内部的に使用され
ます。
■
セッション チケット -- リクエスタの認証情報をターゲット サーバま
たはサービスに転送するためにチケット交付サービス（TGS）によって
使用されます。
Kerberos は、KDC にログインするために keytab ファイルを使用します。
Keytab ファイルは、Kerberos プリンシパルおよび Kerberos パスワードから
派生した暗号化キーのペアで構成されます。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 281
統合 Windows 認証をサポートするための SPS の設定
Kerberos プロトコル メッセージ交換は、簡略化された方法で以下のように
要約できます。
1. ユーザがログインすると、クライアントは KDC 認証サービスに問い合
わせを行い、ユーザの ID 情報が含まれる一時的なメッセージ（チケッ
ト交付チケット）をリクエストします。
2. KDC 認証サービスは TGT を生成し、チケット交付サービスとの通信を
暗号化するためにクライアントが使用できるセッション キーを作成
します。
3. ユーザがローカルまたはネットワーク リソースへのアクセスをリク
エストすると、クライアントはチケット交付チケット（TGT）、認証
システムおよびターゲット サーバのサービス プリンシパル名（SPN）
を KDC に提示します。
4. チケット交付サービスは、チケット交付チケットおよび認証システム
を検査します。 これらの認証情報が受け入れ可能な場合、チケット交
付サービスはサービス チケットを作成します。それには、TGT からコ
ピーされたユーザの ID 情報が含まれています。 サービス チケットは
クライアントに送り返されます。
注： チケット交付サービスは、ユーザがターゲット リソースへのアク
セスを許可されるかどうかを決定できません。 チケット交付サービス
は、ユーザを認証し、セッション チケットを返すだけです。
5. クライアントがセッション チケットを受け取った後、クライアントは
セッション チケットおよび新しい認証システムをターゲット サーバ
に送信してリソースへのアクセスを要求します。
6. サーバはチケットを復号化し、認証システムを検証し、リソースへの
ユーザ アクセスを付与します。
Kerberos 認証の設定
Kerberos 認証を設定するには、以下の手順に従います。
1. Kerberos Key Distribution Center （KDC）の設定
2. ポリシー サーバの設定
3. Web サーバの設定
4. Kerberos 認証方式の設定
5. Windows 上での Kerberos 外部レルムの設定
282 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
Kerberos Key Distribution Center の設定
Kerberos を使用する場合、ドメイン コントローラは Kerberos レルムの
Kerberos Key Distribution Center （KDC）です。 純粋な Windows 環境では、
Kerberos レルムは Windows ドメインに相当します。 ドメイン コントロー
ラ ホストは、ユーザ、サービス アカウント、認証情報、Kerberos チケッ
ティング サービス、および Windows ドメイン サービスのためのストレー
ジを提供します。
Kerberos 認証は keytab ファイルを必要とします。このファイルにより、
ユーザはパスワードを促されることなく、KDC で認証することができます。
Windows では ktpass コマンド ツール ユーティリティを使用し、keytab
ファイルを作成します。UNIX では ktadd ユーティリティを使用し、keytab
ファイルを作成します。
KDC を設定するには、以下の手順に従います。
1. ユーザ アカウントを作成し、ワークステーションにログインします。
2. Web サーバ ホストにログインするための Web サーバ用のサービス ア
カウントを作成します。
3. ポリシー サーバ ホストにログインするためのポリシー サーバ用サー
ビス アカウントを作成します。
4. Web サーバ アカウントを Web サーバ プリンシパル名と関連付けます。
5. keytab ファイルを作成します。そのファイルは Web サーバ ホストに転
送されます。
6. ポリシー サーバ アカウントをポリシー サーバ プリンシパル名と関連
付けます。
7. 別の keytab ファイルを作成し、ポリシー サーバ ホストに新しい
keytab ファイルを転送します。
8. Web サーバおよびポリシー サーバのアカウントが委任用のトラス
テッド アカウントであることを確認します。
重要： Kerberos プロトコルを使用する任意のサービスについては、
service/fqdn_host@REALM_NAME 形式でサービス プリンシパル名（SPN）
を作成することを確認します。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 283
統合 Windows 認証をサポートするための SPS の設定
ポリシー サーバの設定
標準的なポリシー サーバ設定に加えて以下の手順に従います。
1. 設定するエージェントの ACO を開き以下の手順に従います。
a. KCCExt パラメータに .kcc の値を追加します。
b. HttpServicePrincipal パラメータに Web サーバ プリンシパル名の値
を追加します。
例： HTTP/[email protected]
c. SmpsServicePrincipal パラメータにポリシー サーバのプリンシパル
名を追加します。
例： [email protected]
2. Kerberos 設定ファイル（krb5.ini）を設定し、以下の手順のいずれかを
実行します。
■
Windows で、システム ルート パスに krb5.ini ファイルを配置しま
す。
■
UNIX で、/etc/krb5/ パスに krb5.ini ファイルを配置します。
3. ポリシー サーバ プリンシパルの認証情報が含まれる KDC 上で作成さ
れた keytab ファイルをポリシー サーバ上の安全な場所に展開します。
重要： ポリシー サーバが Windows 上にインストールされ、KDC が UNIX 上
で展開する場合は、Ksetup ユーティリティを使用して、ポリシー サーバ ホ
スト上で追加の設定を実行することを確認します。
284 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
Web サーバの設定
Web サーバを設定するには、以下の手順に従います。
1. SiteMinder Kerberos 認証方式サポートで SiteMinder Web エージェント
をインストールします。
2. トラステッド ホストをポリシー サーバに登録し、Web エージェント
を設定します。
3. Kerberos 設定ファイル（krb5.ini）を設定し、以下の手順に従います。
a. Kerberos レルム（ドメイン）に対する KDC を設定します。
b. Web サーバ プリンシパルの認証情報が含まれる keytab ファイル
を使用するために krb5.ini を設定します。
c. Windows 上のシステム ルート パスおよび UNIX 上の/etc/krb5/に
krb5.ini を配置します。
4. KDC 上で作成され、Web サーバ認証情報が含まれる keytab ファイルを
Web サーバ上の安全な場所に展開します。
重要： Windows に Web サーバがインストールされ、KDC が UNIX 上で展開
する場合は、Ksetup ユーティリティを使用して、Web サーバ上で追加の設
定を実行することを確認します。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 285
統合 Windows 認証をサポートするための SPS の設定
Windows ワークステーションの設定
Windows ワークステーションを設定するには、以下の手順に従います。
重要： KDC が UNIX 上で展開する場合は、Ksetup ユーティリティを使用して、
ワークステーション上で追加の必要な設定を実行することを確認します。
1. Windows ワークステーションのホストを KDC ドメインに追加します。
2. KDC で作成されたユーザ アカウントを使用して、ホストにログインし
ます。
3. 認証情報を自動的に渡すために Internet Explorer を設定します。
a. IE Web ブラウザのインスタンスを開始します。
b. インターネット オプション メニューを選択します。
c. ［セキュリティ］タブを選択します。
d. ［ローカル イントラネット］タブを選択します。
e. ［サイト］をクリックし、3 つのチェック ボックスをすべてオン
にします。
f.
［詳細］タブを選択し、http://*.domain.com をローカル イントラ
ネット ゾーンに追加します。
g. セキュリティ設定下の［カスタム レベル］タブを選択し、［ユー
ザ認証］タブ下の［イントラネット ゾーンでのみ自動的にログオ
ンする］を選択します。
h. インターネット オプションから［詳細］タブを選択し、［統合
Windows 認証を使用する（再起動が必要）］オプションを選択し
ます。
i.
286 管理ガイド
ブラウザを閉じます。
統合 Windows 認証をサポートするための SPS の設定
Kerberos 認証方式の設定
カスタム認証方式は SIteMinder 環境で Kerberos 認証をサポートするため
に必要です。 この認証方式を保護されたリソースが Kerberos 認証を使用
するレルムと関連付けます。
次の手順に従ってください：
1. 管理 UI にログインします。
注： [set the ufi variable for your book] にポリシー サーバ オブジェクト
を作成または変更するときは、ASCII 文字を使用します。 ASCII 文字以
外でのオブジェクトの作成または変更はサポートされていません。
2. ［インフラストラクチャ］-［認証］-［認証方式］を選択します。
Al
3. ［認証方式の作成］をクリックします。
4. ［認証方式のタイプ］リストから［カスタム テンプレート］を選択し
ます。
［カスタム テンプレート］設定が表示されます。
5. ［ライブラリ］フィールドに「smauthkerberos」と入力します。
6. ［パラメータ］フィールドに次の値を入力します。 以下のリストにセ
ミコロンで区切って順に値を入力します。
a. ホスト Web サーバの名前とターゲット フィールド
b. Kerberos ドメインからのポリシー サーバ プリンシパル名
c. ユーザ プリンシパルとユーザ ストア検索フィルタとのマッピン
グ
LDAP 例 1：
http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winp
[email protected]; （uid=%{UID}）
LDAP 例 2：
http:/win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.
[email protected]; （uid=%{UID}）
AD 例 1：
http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winp
[email protected]; （cn=%{UID}）
AD 例 2：
http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winp
[email protected]; （cn=%{UID}）
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 287
統合 Windows 認証をサポートするための SPS の設定
ODBC 例 1：
http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winp
[email protected];%{UID}
ODBC 例 2：
http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winp
[email protected];%{UID}
7. ［OK］をクリックします。
Kerberos 認証方式が保存され、認証方式リストに表示されます。
Windows 上での Kerberos 外部レルムの設定
Windows ワークステーションが UNIX 上で展開した Kerberos KDC を使用す
るには、Kerberos KDC サーバおよびワークステーションの両方を設定しま
す。
Kerberos レルムで、Windows ホストのホスト プリンシパルを作成します。
次のコマンドを使用します。
kadmin.local: addprinc host/machine-name.dns-domain_name.
たとえば、Windows ワークステーション名が W2KW で、Kerberos レルム名
が EXAMPLE.COM である場合、プリンシパル名は host/w2kw.example.com
です。
Kerberos レルムは Windows ドメインではありません。ワークグループのメ
ンバとして KDC 動作環境を設定するために、以下の手順に従います。
1. Windows ドメインからホストを削除します。
2. テスト ユーザ（たとえば testkrb）をローカル ユーザ データベースに
追加します。
3. Kerberos レルムを追加します。
ksetup /SetRealm EXAMPLE.COM
4. ホストを再起動します。
5. KDC の追加
ksetup /addkdc EXAMPLE.COM rhasmit
6. 新しいパスワードを設定します。
ksetup /setmachpassword password
288 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
注： ここで使用されるパスワードは、MIT KDC でホスト プリンシパル
アカウントを作成する際に使用されるものと同じです。
7. ホストを再起動します。
注： 外部 KDC およびレルム設定に対する変更が行われた場合は常に、
再起動が必要です。
8. レルム フラグを設定します。
ksetup /SetRealmFlags EXAMPLE.COM delegate
9. AddKpasswd の実行
ksetup /AddKpasswd EXAMPLE.COM rhasmit
10. Windows ホスト アカウント間のアカウント マッピングを Kerberos プ
リンシパルへ定義することにより、ローカル ワークステーション アカ
ウントへのシングル サインオンを設定するために Ksetup を使用しま
す。 例：
ksetup /mapuser [email protected] testkrb
ksetup /mapuser * *
2 番目のコマンドは、クライアントを同じ名前のローカル アカウント
にマップします。引数のない Ksetup を使用して現在の設定を参照しま
す。
Kerberos 認証をサポートするように CA SiteMinder for Secure Proxy Server
が設定されます。
Kerberos 設定の例
この後の設定には、keytab ファイルの作成など、SiteMinder 環境で Kerberos
認証を実装するのに必要な詳細の例が含まれます。 KDC が UNIX オペレー
ティング環境で展開され、ポリシー サーバ（Web サーバ）またはワーク
ステーションが Windows オペレーティング環境にあるときは、追加の設
定が必要であることに留意してください。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 289
統合 Windows 認証をサポートするための SPS の設定
Windows 2008 上での KDC 設定の例
以下に示す手順では、SiteMinder Kerberos 認証をサポートする Windows ド
メイン コントローラを設定する方法を例証します。
1. Windows dcpromo ユーティリティを使用して、Windows サーバをドメ
イン コントローラ（この例では test.com と名付けられています）に昇
格させます。
2. ドメイン機能レベルの昇格：
1. 管理ツールから［Active Directory ユーザとコンピュータ］ダイアロ
グ ボックスを開きます。
2. ダイアログ ボックスの左側にある test.com ドロップダウンを右ク
リックします。
3. ［ドメイン機能レベルの昇格］をクリックします。
4. Active Directory のドメイン機能レベルを上げます。
重要： この手順は元に戻せません。
3. ユーザ アカウントを作成します（例： testkrb）。 このアカウントのパ
スワードを提供します。 ［ユーザは次回ログオン時にパスワード変更
が必要］オプションをオフにします。 このアカウントをドメイン管理
者グループに追加して、ユーザがログイン許可を持てるようにします。
Windows ワークステーションは、このアカウントを使用して test.com
にログインします。
4. Web サーバのサービス アカウントを作成します（例： wasrvwin2k8sps）。
このアカウントのパスワードを作成します。 ［ユーザは次回ログオン
時にパスワード変更が必要］オプションをオフにします。 このアカウ
ントをドメイン管理者グループに追加して、ユーザがログイン許可を
持てるようにします。 CA SiteMinder for Secure Proxy Server は、このア
カウントを使用して test.com にログインします。
5. ポリシー サーバのサービス アカウントを作成します（polsrvwinps）。
このアカウントのパスワードを提供します。 ［ユーザは次回ログオン
時にパスワード変更が必要］オプションをオフにします。 このアカウ
ントをドメイン管理者グループに追加して、ユーザがログイン許可を
持てるようにします。 ポリシー サーバ ホスト（winps）は、このアカ
ウントを使用して test.com にログインします。
6. 手順 4 および 5 で作成したサービス アカウントを使用して、Web サー
バ（win2k8sps）およびポリシー サーバ（winps）ホストを test.com ド
メインに結び付けます。
290 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
7. Web サーバ プリンシパル名（HTTP/[email protected]）と
Web サーバ アカウント（wasrvwin2k8sps）を関連付けて、Ktpass ユー
ティリティを使用して、keytab ファイルを作成します。 ポリシー サー
バが Windows 上または UNIX 上にあるかによって構文が異なります。
注： Ktpass コマンド ツール ユーティリティは Windows サポート ツー
ルです。 MSDN ダウンロードまたはインストール CD からそれをイン
ストールできます。サポート ツールのバージョンを常に確認してくだ
さい。 デフォルト暗号化タイプは常に RC4-HMAC である必要がありま
す。暗号化タイプは、コマンド プロンプトで ktpass /? を実行すること
により 確認できます。
ポリシー サーバが Windows 上にある場合
ktpass -out c:¥wasrvwin2k8sps.keytab -princ HTTP/[email protected]
-ptype KRB5_NT_PRINCIPAL -mapuser wasrvwin2k8sps -pass <<password>>
標的ドメイン コントローラ： winkdc.Test.com
Using legacy password setting method
HTTP/win2k8sps.test.com を wasrvwin2k8sps に正常にマップしました。
Key created.
c:¥wasrvwin2k8sps.keytab への出力 keytab：
Keytab version: 0x502
keysize 67 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 2
etype 0x17 (RC4-HMAC) keylength 16 (0xfd77a26f1f5d61d1fafd67a2d88784c7)
パスワードは、Web サーバ用のサービス アカウントを作成する際に使
用されるものと同じです。
ポリシー サーバが UNIX 上にある場合
ktpass -out d:¥sol10sunone_host.keytab -princ
host/[email protected] -pass <<password>> -mapuser sol10sunone
–crypto DES-CBC-MD5 +DesOnly -ptype KRB5_NT_PRINCIPAL –kvno 3
標的ドメイン コントローラ： winkdc.test.com
host/sol10sunone.test.com を sol10sunone に正常にマップしました。
Key created.
d:¥sol10sunone_host.keytab への出力 keytab：
Keytab version: 0x502
keysize 52 host/sol10sunone.test.com@TEST ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x3 (DES-CBC-MD5) keylength 8 (0xb5a87ab5070e7f4a)
アカウント sol10sunone は DES のみの暗号化用に設定されました。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 291
統合 Windows 認証をサポートするための SPS の設定
8. ポリシー サーバ アカウント（polsrvwinps）をポリシー サーバ プリン
シパル名（smps/[email protected]）に関連付けて、ポリシー
サーバ ホスト（winps）に送信する別の keytab ファイルを作成します。
ポリシー サーバが Windows 上にある場合
Ktpass -out c:¥polsrvwinps.keytab –princ smps/[email protected] -ptype
KRB5_NT_PRINCIPAL -mapuser polsrvwinps -pass <<password>>
標的ドメイン コントローラ： winkdc.Test.com
Using legacy password setting method
smps/winps.test.com を polsrvwinps に正常にマップしました。
Key created.
c:¥polsrvwinps.keytab への出力 keytab：
Keytab version: 0x502
keysize 72 smps/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 2 etype
0x17 (RC4-HMAC) keylength 16 (0xfd77a26f1f5d61d1fafd67a2d88784c7)
パスワードは、ポリシー サーバ用のサービス アカウントを作成する際
に使用されるものと同じです。
ポリシー サーバが UNIX 上にある場合
ktpass -out d:¥sol10polsrv.keytab -princ host/[email protected]
-pass <<password>> -mapuser sol10sunone –crypto DES-CBC-MD5 +DesOnly -ptype
KRB5_NT_PRINCIPAL –kvno 3
標的ドメイン コントローラ： winkdc.test.com
host/sol10sunone.test.com を sol10sunone に正常にマップしました。
Key created.
d:¥sol10polserv.keytab への出力 keytab：
Keytab version: 0x502
keysize 52 host/sol10sunone.test.com@TEST ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x3 (DES-CBC-MD5) keylength 8 (0xb5a87ab5070e7f4a)
アカウント sol10sunone は DES のみの暗号化用に設定されました。
292 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
9. Web サーバおよびポリシー サーバ サービス アカウントが委任用のト
ラステッド アカウントであることを以下のように指定します。
1. サービス アカウント（polsrvwinps/wasrvwin2k8sps）プロパティを
右クリックします。
2. ［委任］タブを選択します。
3. 2 番目のオプション、［任意のサービスへの委任でこのユーザーを
信頼する（Kerberos のみ）］を選択します。
または、3 番目のオプション、［指定されたサービスへの委任での
みこのユーザーを信頼する］を選択します。 ［Kerberos のみを使
う］オプション ボタンを選択し、対応するサービス プリンシパル
名を追加します。
ドメイン コントローラは SiteMinder Kerberos 認証の準備ができました。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 293
統合 Windows 認証をサポートするための SPS の設定
UNIX 上での KDC 設定の例
以下に示すプロセスでは、SiteMinder Kerberos 認証をサポートするための
UNIX ホスト上での KDC Kerberos レルムを設定する方法を例証します。
1. 必要に応じ、MIT Kerberos をインストールします。
2. kdb5_util コマンドを使用して Kerberos データベースおよびオプショ
ンの stash ファイルを作成します。 stash ファイルは、ホスト自動ブー
ト シーケンスの一部として kadmind および krb5kdc のデーモンを開始
する前に、KDC が自身に対して自動認証するために使用されます。
stash ファイルおよび keytab ファイルはどちらも、潜在的な侵入のエン
トリ ポイントです。 stash ファイルをインストールする場合、ルート
によってのみ読み取り可能でなければならず、バックアップされては
ならないし、KDC ローカル ディスクにのみ存在する必要があります。
stash ファイルを望まない場合は、-s オプションなしで kdb5_util を実行
します。
この例では、kdc.conf ファイルで指定されたディレクトリに以下の 5
つのデータベース ファイルを生成します。
■
2 つの Kerberos データベース ファイル： principal.db と principal.ok
■
1 つの Kerberos の管理データベース ファイル： principal.kadm5
■
1 つの管理データベース ロック ファイル： principal.kadm5.lock
■
1 つの stash ファイル： .k5stash
[root@rhasmit init.d]# kdb5_util create -r EXAMPLE.COM –s
Initializing database '/var/kerberos/krb5kdc/principal' for realm
'EXAMPLE.COM',
マスタ キー名 'K/[email protected]'
データベース マスタ パスワードを求められます。
このパスワードは重要なので忘れないでください。
KDC データベース マスタ キーを入力します：
KDC データベース マスタ キーを再入力し、次を確認します：
3. ユーザ プリンシパル（testkrb）を作成します。
4. Web サーバ ホスト用のユーザ プリンシパル（たとえば testwakrb）、
ホスト プリンシパル（host/[email protected]）、
およびサービス プリンシパル
（HTTP/[email protected]）を作成します。 ホス
ト アカウントを作成するために使用されるパスワードは、Web サーバ
ホスト上で ksetup ユーティリティを使用する際に指定されるパス
ワードと同じである必要があります。
294 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
5. ポリシー サーバ ホスト用のユーザ プリンシパル（testpskrb）、ホスト
プリンシパル（host/[email protected]）、およびサー
ビス プリンシパル（smps/[email protected]）を作成
します。ホスト アカウントを作成するために使用されるパスワードは、
ポリシー サーバ ホスト上で ksetup ユーティリティを使用する際に指
定されるパスワードと同じである必要があります。
6. Web サーバ サービス プリンシパル用の keytab ファイルを以下のよう
に作成します。
ktadd -k /tmp/win2k8sps.keytab HTTP/win2k8sps.example.com
7. ポリシー サーバ サービス プリンシパル用の keytab を以下のように作
成します。
ktadd -k /tmp/winps.keytab smps/winps.example.com
Kerberos レルムは、UNIX ホスト上の SiteMInder に対して設定されます。
UNIX のポリシー サーバでの Kerberos 設定の例
以下の手順では、CA SiteMinder® Kerberos 認証をサポートする UNIX 上のポ
リシー サーバの設定例について説明します。
次の手順に従ってください：
1. Active Directory でポリシー サーバ ホスト（sol10ps）用のサービス アカ
ウントを作成するために使用されたものと同じパスワードで、ユーザ
（たとえば sol10psuser）を作成します。
2. ホストを test.com ドメインに追加し、ユーザ sol10psuser でホストにロ
グインします。
3. CA SiteMinder® ポリシー サーバをインストールし設定します。
4. ポリシー ストア ディレクトリ サービスをインストールし設定します。
5. Solaris ポリシー サーバを参照するホスト設定オブジェクトを追加し
ます。
6. エージェント設定オブジェクトを追加し、以下の新しい 3 つのパラ
メータを追加します。
パラメータ
値
KCCExt
.kcc
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 295
統合 Windows 認証をサポートするための SPS の設定
パラメータ
値
HttpServicePrincipal
Web サーバ プリンシパル名を指定します。
例： HTTP/[email protected]
ポリシー サーバ プリンシパル名を指定します。
SmpsServicePrincipal
例： [email protected]
7. ユーザ ディレクトリを作成します。
8. ユーザ ディレクトリで、ユーザを作成します（たとえば testkrb）。
9. CA SiteMinder® 管理 UI を使用して、新しい認証方式を設定します。
1. カスタム テンプレートを使用して、方式を作成します。
2. CA SiteMinder® Kerberos 認証方式ライブラリを指定します。
3. パラメータ フィールドを選択し、指定された順に以下のセミコロ
ンに区切られた 3 つの値を指定します。
■
サーバ名およびターゲット フィールド
■
Windows 2003 Kerberos レルムからのポリシー サーバ プリンシ
パル名。
■
ユーザ プリンシパルと LDAP 検索フィルタの間のマッピング。
サンプル パラメータ フィールドは以下のとおりです。
http://sol10sunone.test.com/siteminderagent/Kerberos/creds.kcc;smps/sol10
[email protected]; （uid=%{UID}）
10. ポリシー ドメインを設定します。
11. 認証方式を使用して、リソースを保護するためのレルムを追加します。
.
12. ユーザ（testkrb）にアクセスを許可するためのルールとポリシーを追
加します。
296 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
13. Kerberos 設定ファイル（krb5.ini）を設定し、/etc/krb5 システム パスに
krb5.ini を配置します。
■
Windows 2003 ドメイン コントローラを使用するために Windows
2003 Kerberos レルム（ドメイン）用の KDC を設定します。
■
ポリシー サーバ プリンシパル認証情報が含まれる Windows 2003
KDC keytab ファイルを使用するために krb5.ini を設定します。
以下のサンプル krb5.ini を参照してください。
[libdefaults]
ticket_lifetime = 24000
default_realm=TEST.COM
default_tgs_enctypes = des-cbc-md5
default_tkt_enctypes = des-cbc-md5
default_keytab_name = FILE:/etc/krb5.keytab
dns_lookup_realm = false
dns_lookup_kdc = false
forwardable = true
proxiable = true
[realms]
TEST.COM = {
kdc = winkdc.test.com:88
admin_server = winkdc.test.com:749
default_domain = test.com
}
[domain_realm]
.test.com=TEST.COM
test.com=TEST.COM
14. ktutil ユーティリティを使用して、ポリシー サーバ ホストのホスト プ
リンシパル名およびサービス プリンシパル名が含まれる keytab ファ
イル（sol10ps_smps.keytab & sol10ps_host.keytab）を /etc/krb5.keytab
ファイルにマージします。
ktutil:
ktutil:
ktutil:
ktutil:
ktutil:
ktutil:
rkt
wkt
q
rkt
wkt
q
sol10ps_host.keytab
/etc/krb5.keytab
sol10ps_smps.keytab
/etc/krb5.keytab
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 297
統合 Windows 認証をサポートするための SPS の設定
15. 作成された krb5.keytab を以下のように確認します。
klist -k
Keytab 名： FILE:/etc/krb5.keytab
KVNO プリンシパル
----------------------------------------------------------------------------3 host/[email protected]
3 smps/[email protected]
16. ホストおよびポリシー サーバ プリンシパル認証情報が含まれる
Windows 2003 KDC keytab ファイルをポリシー サーバ上の安全な場所
に展開します。
17. ポリシー サーバを起動する前に、以下の環境変数が設定されているこ
とを確認します。
KRB5_CONFIG=/etc/krb5/krb5.conf
UNIX ホスト上のポリシー サーバが Kerberos 認証に対して設定されます。
Windows のポリシー サーバでの Kerberos 設定の例
以下の手順では、CA SiteMinder® Kerberos 認証をサポートする Windows 上
のポリシー サーバの設定例について説明します。
注： ポリシー サーバが Windows 上にインストールされ、KDC が UNIX 上で
展開される場合は、Ksetup ユーティリティを使用して、ポリシー サーバ ホ
スト上で必要な追加の設定を実行することを確認します。
次の手順に従ってください：
1. CA SiteMinder® ポリシー サーバをインストールし設定します。
2. ポリシー ストア ディレクトリ サービスをインストールし設定します。
3. Windows ドメイン コントローラの Active Directory で作成されたサー
ビス アカウント（たとえば polsrvwinps）でポリシー サーバ ホストに
ログインします。
4. ポリシー サーバを参照するホスト設定オブジェクトを追加します。
298 管理ガイド
統合 Windows 認証をサポートするための SPS の設定
5. エージェント設定オブジェクトを作成し、これらの新しい 3 つのパラ
メータを追加します。
パラメータ
値
KCCExt
.kcc
HttpServicePrincipal
Web サーバ プリンシパル名を指定します。
例： HTTP/[email protected]
ポリシー サーバ プリンシパル名を指定します。
SmpsServicePrincipal
例： [email protected]
6. ユーザ ディレクトリを作成します。
7. ユーザ ディレクトリで、ユーザを作成します（たとえば testkrb）。
8. CA SiteMinder® 管理 UI を使用して、新しい認証方式を設定します。
1. カスタム テンプレートを使用して、方式を作成します。
2. CA SiteMinder® Kerberos 認証方式ライブラリを指定します。
3. パラメータ フィールドを選択し、指定された順に以下のセミコロ
ンに区切られた 3 つの値を指定します。
■
サーバ名およびターゲット フィールド
■
Windows 2003 Kerberos レルムからのポリシー サーバ プリンシ
パル名。
■
ユーザ プリンシパルと LDAP 検索フィルタの間のマッピング。
サンプル パラメータ フィールドは以下のとおりです。
http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.t
[email protected]; （uid=%{UID}）
9. ポリシー ドメインを設定します。
10. 認証方式を使用して、リソースを保護するためのレルムを追加します。
11. ユーザ（testkrb）にアクセスを許可するためのルールとポリシーを追
加します。
第 15 章： 統合 Windows 認証をサポートするための CA SiteMinder® SPS の設定 299
統合 Windows 認証をサポートするための SPS の設定
12. Kerberos 設定ファイル（krb5.ini）を設定し、Windows システム ルート
パスに krb5.ini を配置します。
■
Windows 2003 ドメイン コントローラを使用するために Windows
2003 Kerberos レルム（ドメイン）用の KDC を設定します。
■
ポリシー サーバ プリンシパル認証情報が含まれる Windows 2003
KDC keytab ファイルを使用するために krb5.ini を設定します。
以下のサンプル krb5.ini を参照してください。
[libdefaults]
default_realm = TEST.COM
default_keytab_name = C:¥WINDOWS¥krb5.keytab
default_tkt_enctypes = rc4-hmac des-cbc-md5
default_tgs_enctypes = rc4-hmac des-cbc-md5
[realms]
TEST.COM = {
kdc = winkdc.test.com:88
default_domain = test.com
}
[domain_realm]
.test.com = TEST.COM
13. ポリシー サーバ プリンシパル認証情報が含まれる Windows KDC
keytab ファイルをポリシー サーバ上の安全な場所に展開します。
Windows ホスト上のポリシー サーバが Kerberos 認証に対して設定されま
す。
300 管理ガイド
第 16 章： CA Wily Introscope を使ったデータ
モニタリング
このセクションには、以下のトピックが含まれています。
CA Wily Introscope を使ったデータ モニタリング (P. 301)
OneView モニタによる Web エージェントの監視 (P. 304)
CA Wily Introscope を使ったデータ モニタリング
組織ですでに CA Wily Introscope を使用している場合、SPS の健全性を監視
できます。Wily EPAgent を使って、Tomcat サーバの以下の統計を監視する
ことができます。
■
以下の CA SiteMinder for Secure Proxy Server コンポーネントの各平均応
答時間：
■
セッション ディスカバリ
■
Java Web エージェント
■
ポスト エージェント セッション ライタ
■
プロキシ ルール フィルタ
■
ヌードル サーブレット
■
HTTP クライアント
■
各バックエンド サーバの平均応答時間
■
CA SiteMinder for Secure Proxy Server のリクエスト待機時間
■
各プロキシ ルールのヒット数
■
CA SiteMinder for Secure Proxy Server Agent フレームワーク インスタン
スの健全性データ
第 16 章： CA Wily Introscope を使ったデータ モニタリング 301
CA Wily Introscope を使ったデータ モニタリング
データ モニタリング セクションには、以下の形式があります。
<Server>
.
.
monitor_data_buffer_size="1000"
.
.
</Server>
<metric-reporter name="Wily Metric Reporter">
enabled="yes"
class="com.ca.proxy.monitor.wily.WilyMetricReporter"
endpoint="tcp://localhost:8886"
</metric-reporter>
monitor_data_buffer_size
収集した統計情報を Wily に送信する前に、統計情報を保存するために
CA SiteMinder for Secure Proxy Server が保持しているバッファのサイズ
を指定します。
デフォルト値： 1000
metric-reporter name
メトリック レポータの名前を指定します。 任意のメトリック エラー
をデバッグするために、この名前を使用できます。
enabled
データ モニタリング機能の状態を指定します。 SPS の健全性を監視す
るには、値を Yes に設定します。 SPS の健全性を監視しない場合は、
値を No に設定します。
デフォルト値： No
endpoint
EPAgent の設定詳細を指定します。 SPS と通信する前に、EPAgent を起
動します。 endpoint パラメータの形式は、以下のとおりです。
protocol://hostname_of_EPAgent:port
protocol
EPAgent が使用する通信プロトコルを指定します。
hostname_EPAgent
EPAgent がインストールされているマシンのホスト名を指定しま
す。
デフォルト値： localhost
302 管理ガイド
CA Wily Introscope を使ったデータ モニタリング
port
SPS と通信するために EPAgent が使用するポート番号を指定しま
す。 TCP プロトコルを使用する場合は、EPAgent で設定されるネッ
トワーク データ ポートを入力します。 HTTP プロトコルを使用す
る場合は、EPAgent で設定される HTTP ポート番号を入力します。
データ モニタリングの有効化
データ モニタリングを有効にするには、以下の手順に従います。
注： CA Wily EPAgent の設定については、「CA Wily Introscope Environment
Performance Agent ガイド」を参照してください。
1. SPS からメトリックを収集するため、CA Wily EPAgent を設定します。
2. 以下の手順に従うことで、server.conf ファイルを設定します。
a. server.conf ファイルを開き、metric-reporter セクションに移動しま
す。
b. 以下の値を設定します。
enabled=yes
c. （オプション） CA SiteMinder for Secure Proxy Server を使って設定
したエージェント インスタンス メトリックを監視するには、以下
の値を設定します。
enablemonitoring=yes
d. 変更を保存します。
3. SPS で設定した各 Web エージェントの ACO を設定します。
4. CA Wily EPAgent を起動します。
5. SPS を再起動します。
第 16 章： CA Wily Introscope を使ったデータ モニタリング 303
OneView モニタによる Web エージェントの監視
OneView モニタによる Web エージェントの監視
CA SiteMinder® OneView モニタは、キャッシュ統計情報と他の情報をポリ
シー サーバへ送信します。管理者はポリシー サーバを使用して、Web エー
ジェントを分析し、微調整することができます。 以下のパラメータを使
用して CA SiteMinder® OneView モニタを制御します。
EnableMonitoring
CA SiteMinder® Web エージェントが監視情報をポリシー サーバに
送信するかどうかを指定します。
デフォルト： No
Web エージェントで CA SiteMinder® OneView モニタが使用されるように
するには、EnableMonitoring パラメータを yes に設定します。
注： 詳細については、ポリシー サーバ ドキュメントを参照してください。
304 管理ガイド
第 17 章： エージェントに対するオペレー
ティング システムの調整
このセクションには、以下のトピックが含まれています。
共有メモリ セグメントの調整 (P. 306)
Solaris 10 リソース管理を調整する方法 (P. 308)
第 17 章： エージェントに対するオペレーティング システムの調整 305
共有メモリ セグメントの調整
共有メモリ セグメントの調整
Apache ベースのエージェントを Solaris システムにインストールする場合
は、エージェントが正しく機能するようにオペレーティング環境の共有メ
モリ設定を調整します。 共有メモリ セグメントまたはオペレーティング
環境を増やすことによって、エージェントのパフォーマンスが向上します。
共有メモリ セグメントをコントロールする変数はオペレーティング環境
の指定ファイルで定義されます。
注： Linux オペレーティング環境では共有メモリ セグメントの調整が必要
となる場合があります。 共有メモリ セグメント、およびそれらを調整す
る方法の詳細については、特定のオペレーティング環境のドキュメントを
参照してください。
次の手順に従ってください：
1. ご使用のオペレーティング環境に該当する手順に従ってください。
■
Solaris： 任意のエディタを使用して、/etc/system ファイルを開き
ます。
2. 以下の方法のうちの 1 つを使用して、共有メモリ変数を変更します。
■
Solaris：以下のリストに表示された変数を追加し、例に表示された、
推奨設定を使用して、それらを設定します。 以下の構文を使用し
ます。
set shmsys:shminfo_shmmax=33554432
shmsys:shminfo_shmmax
最大の共有メモリ セグメント サイズを指定します。エージェント
のリソースおよびセッション キャッシュの最大サイズを制御しま
す。
注： 必要なメモリ セグメントの量を概算するために、各キャッ
シュに 4 KB/エントリを割り当てるか、または OneView モニタで
キャッシュ使用状況の統計を表示します。 OneView モニタ を使用
する方法の詳細については、「Web エージェント設定ガイド」を
参照してください。
例： 大きなキャッシュ容量を必要とするビジーなサイトには
33554432（32 MB）。
shmsys:shminfo_shmmin
306 管理ガイド
共有メモリ セグメントの調整
（Solaris では必要なし）最小の共有メモリ セグメント サイズ。
エージェントのリソースおよびセッション キャッシュの最小サイ
ズを制御します。
shmsys:shminfo_shmmni
システム全体で、同時に存在できる共有メモリ セグメントの最大
数を指定します。
例：（Solaris 9 以外） N/A
例：（Solaris 9） 200
shmsys:shminfo_shmseg
（Solaris 9 では必要なし）プロセスごとの共有メモリ セグメントの
最大数を指定します。
例： 24
semsys:seminfo_semmni
セマフォ識別子の数を指定します。 システムで実行するエージェ
ントのすべてのインスタンスに 11 を使用します。
例：（Solaris 9 以外） 100
例：（Solaris 9） 200
semsys:seminfo_semmns
システムのセマフォの数を指定します。 システムで実行するエー
ジェントのすべてのインスタンスに 10 を使用します。
例：（Solaris 9） 100
例：（Solaris 9） 400
semsys:seminfo_semmnu
undo 機能を使用して、プロセスの数を指定します。 最適なパ
フォーマンスを得るには、システム内で実行される Apache 子プロ
セスの数より常に大きくなるように semmnu 値を設定します。
Apache ベースのサーバに対しては、maxclients 設定を 200 以上超え
る値を使用します。
例：（Solaris 9） 200
3. 変更を保存してファイルまたはユーティリティを終了します。
4. システムを再起動します。
5. 次のコマンドを実行して変更を確認します。
$ sysdef -i
第 17 章： エージェントに対するオペレーティング システムの調整 307
Solaris 10 リソース管理を調整する方法
Solaris 10 リソース管理を調整する方法
エージェントのパフォーマンスを改善するためにプロジェクト レベルで
リソース管理を調整します。
注： 詳細については、Solaris のマニュアルを参照してください。
Solaris 10 でリソース管理を調整する場合は、以下のプロセスを使用します。
1. Web エージェントが実行されるユーザ アカウントに関連付けられた
プロジェクトを特定します。
2. そのプロジェクトの以下のリソース管理のうちのいずれかの設定を増
加します。
project.max-shm-ids
プロジェクトの最大共有メモリ ID を指定します。
project.max-sem-ids
プロジェクトのセマフォ ID の最大数を指定します。
project.max-msg-ids
プロジェクトのメッセージ キュー ID の最大数を指定します。
project.max-shm-memory
プロジェクトに許可された共有メモリの合計金額を指定します。
process.max-sem-nsems
セマフォ セットごとに許可されたセマフォの最大数を指定します。
process.max-sem-ops
semop ごとに許可されたセマフォ操作の最大数を指定します。
process.max-msg-messages
メッセージ キューのメッセージの最大数を指定します。
process.max-msg-qbytes
メッセージ キューのメッセージの最大バイト数を指定します。
308 管理ガイド
第 18 章： SPS API
このセクションには、以下のトピックが含まれています。
セッション スキーム API (P. 309)
API の概要のフィルタ (P. 317)
セッション スキーム API
CA SiteMinder for Secure Proxy Server は、ユーザのカスタム セッション ス
キームの開発を許可する Java API をサポートします。これらのスキームは
CA SiteMinder for Secure Proxy Server に設定された各仮想ホストのユーザ
エージェント タイプに割り当てることができます。
セッション スキーム API 処理の概要
CA SiteMinder for Secure Proxy Server は、典型的なユーザ セッションを確立、
維持、および終了する多くのメソッドを処理します。 セッション処理の
ステップの 1 つは、スキームが書き換え可能かどうかを判断することです。
書き換え可能なスキームは、URL を変更する機能を提供します。 単純な
URL 書き換えセッション スキームは、書き換え可能なスキームの例です。
リクエストの処理の一部として、トークンを含めるためにリクエストされ
た URL を書き換えることが含まれるためです。
書き換え可能なセッション スキームを実装するには、書き換え可能なイ
ンターフェースを実装する必要があります。書き換え可能なインター
フェースについては、「書き換え可能なセッション スキーム (P. 314)」を
参照してください。
第 18 章： SPS API 309
セッション スキーム API
以下の図は、セッション スキーム API メソッドのプロセス フローを示し
ます。
図に示されているメソッドは次のとおりです。
1. isValidRequest-- 有効なリクエストを構成する条件を決定および確認す
るために、このメソッドをカスタム セッション スキームに実装する必
要があります。
2. getKeyFromRequest -- 有効なリクエストからキーを抽出するためにこ
のメソッドを実装する必要があります。 キーが存在しない場合、
createKeyFromRequest メソッドがコールされます。
3. createKeyFromRequest -- 新しいセッションのキーの作成をトリガする
ためにこのメソッドを実装する必要があります。
4. onSessionCreate -- セッション作成時に使用中のセッション スキーム
が書き換え可能でない場合、このメソッドがコールされます。 このメ
ソッドは、新しいセッションの開始時にトリガされるコードで実装で
きます。
310 管理ガイド
セッション スキーム API
5. onSessionCreateRedirect -- セッション作成時に、スキームが書き換え可
能な場合はこのメソッドがコールされます。 このメソッドは、書き換
え可能なセッション スキームで新しいセッションの開始時にコール
されるコードで実装できます。
6. onSessionUpdate -- セッション中に新しいリクエストが発生するたび
にセッションが更新されます。 このメソッドは各セッションの更新時
にコールされます。 セッション更新時にトリガされるコードを追加す
ることで実装できます。
7. onSessionLogout -- セッションが終了したときに、このメソッドがコー
ルされます。ユーザ セッションが終了するたびに実行されるコードで
実装できます。
セッション スキーム API クラス ファイル
CA SiteMinder for Secure Proxy Server セッション スキーム API は、
sps_home/Tomcat/server/lib/proxycore.jar に含まれるセッション スキーム
の抽象型クラスを利用します。
セッション スキーム API のコンストラクタ
カスタム セッション スキームのコンストラクタは以下で構成する必要が
あります。
public IPAddrSessionScheme(String name, boolean
acceptFlag, Hashtable props) {
// 常に親コンストラクタを呼び出して適切に
// スキームを初期化
super(name,acceptFlag,props);
設定項目は以下のとおりです。
name
カスタム セッション スキーム クラスと関連付けられた server.conf
ファイル内の名前によって入力される文字列。
acceptFlag
カスタム セッション スキームが SiteMinder の SMSESSION Cookie を受
理するかどうか判断するブール値。
props
server.conf ファイルで指定された、セッション スキームに必要な他の
プロパティの名前/値ペアのリスト。
第 18 章： SPS API 311
セッション スキーム API
セッション スキーム API メソッド
セッション スキーム API クラスは以下のメソッドから構成されます。
戻り値
メソッド
説明
ブール値
acceptsCookies()
server.conf ファイル内のセッショ
ン スキームの
accepts_smsession_cookies パラ
メータから acceptFlag の値を取得
し、このスキームが SiteMinder
SMSESSION Cookie をサポートする
かどうかを示す値を返します。
abstract
java.lang.String
createKeyFromRequest(HttpServletRequest リクエストから新しいセッション
req)
キーを作成するために必要な値を
取得するコードを実行します。
abstract
java.lang.String
getKeyFromRequest(HttpServletRequest
req)
リクエストからセッション キー
を取得します。
java.lang.String
getName()
server.conf ファイルで定義された
カスタム セッション スキームの
名前を取得します。
abstract Boolean
isValidRequest(HttpServletRequest req)
このセッション スキームに対す
るリクエストが有効かどうかを評
価します。
abstract int
onSessionCreate(java.lang.String id,
HttpServletRequest req,
HttpServletResponse resp)
セッション作成時に使用可能な
フック。
java.lang.String
onSessionCreateRedirect(java.lang.String id, 書き換え可能なスキームのセッ
java.lang.String url, HttpServletRequest req, ション作成時に使用可能なフッ
HttpServletResponse resp)
ク。
abstract void
onSessionLogOut(HttpServletRequest req,
HttpServletResponse resp)
セッション終了時（ログアウト）
に使用可能なフック。
abstract void
onSessionUpdate(HttpServletRequest req,
HttpServletResponse resp)
セッション更新時に使用可能な
フック。 このメソッドは内部使用
専用です。
312 管理ガイド
セッション スキーム API
戻り値
メソッド
説明
static Boolean
usingDefaultSessionScheme(HttpServlet
Request req)
リクエストがデフォルトのセッ
ション スキームを使用している
ことを認識するヘルパー メソッ
ド。
カスタム セッション スキームの実装
カスタム セッション スキームを実装するには、以下の手順に従います。
次の手順に従ってください：
1. IP アドレス セッション スキームで IP アドレス セッション スキーム
用サンプルコードを確認します。
2. セッション スキーム用のソース コードを作成します。
3. リライト可能なセッション スキームを作成している場合、リライト可
能なインターフェースを実装します。
4. システムの CLASSPATH に以下のコンテンツが含まれることを確認し
ます。
■
セッション スキーム API を含む proxycore.jar
■
JDK バージョン 1.6.0_30 以降の jar ファイル
■
sps_home/Tomcat/lib の jar ファイル
5. セッション スキームをコンパイルします。
6. 以下のいずれかの手順を実行します。
■
カスタム セッション スキームを含む .jar ファイルを作成し、そ
の .jar ファイルを sps_home/Tomcat/lib ディレクトリにコピーしま
す。
■
カスタム セッション スキーム用のクラス ファイルを
sps_home/Tomcat/lib ディレクトリの jar に追加し、CA SiteMinder for
Secure Proxy Server server.conf ファイルでスキームを設定します。
7. CA SiteMinder for Secure Proxy Server サーバを再起動します。
第 18 章： SPS API 313
セッション スキーム API
server.conf ファイル内のカスタム セッション スキームの設定
カスタム セッション スキーム用のコードをコンパイルする場合、CA
SiteMinder for Secure Proxy Server server.conf ファイルのセッション スキー
ムを設定する必要があります。 セッション スキームを設定するには、
SessionScheme エレメントをファイルに追加します。 例：
<SessionScheme name="custom_scheme">
class="com.netegrity.proxy.session.CustomScheme"
accepts_smsession_cookies="false"
property1="value1"
property2="value2"
</SessionScheme>
さらに、ユーザ エージェント タイプを設定している場合、任意の適切な
ユーザ エージェント タイプにセッション スキームをマップできます。
詳細情報：
デフォルト仮想ホスト用のセッション スキーム マッピング (P. 156)
書き換え可能なセッション スキームの設定
ユーザによってリクエストされた URL を変更する機能がセッション ス
キームに必要な場合、書き換え可能なインターフェースを実装する必要が
あります。 たとえば、このインターフェースは、セッション スキームが
URL リクエストの最後にトークンを追加できるように、単純な URL 書き換
えスキームで使用されます。
リライト可能なインターフェースの実装
リライト可能なインターフェースを実装する場合、以下のメソッドが使用
可能です。
戻り値
メソッド
説明
公開文字列
rewrite(String url, String id,
HttpServletRequest req)
セッション識別子を含むようにリクエスト
された URL を書き換えます。
314 管理ガイド
セッション スキーム API
戻り値
メソッド
説明
公開文字列
onSessionCreateRedirect(String id, リダイレクトによるセッション作成のイベ
String url, HttpServletRequest req, ント用のコールバックを提供します。 ター
HttpServletResponse resp)
ゲット URL がリクエストされた URL とは異
なる場合に、フォーム ベースの認証と共に
通常使用されます。 たとえば、認証方式に
よって URL を変更するか、または Cookie を
追加する可能性があります。
書き換えできるインターフェースに加えて、メソッドはカスタム セッ
ション スキームで実現する必要があります。
戻り値
メソッド
説明
protected void
setRequestURI （HttpServletRequest スキームがリクエスト URI を変更すること
req、String uri）
を許可します。
protected void
setRequestPathInfo
（HttpServletRequest req、String
pathInfo）
スキームがリクエストのパス情報を変更
することを許可します。
IP アドレス セッション スキームの使用
デフォルトの CA SiteMinder for Secure Proxy Server インストールには、IP ア
ドレス セッション スキームが含まれています。 このスキームはクライア
ントの IP アドレスを使用して、セッションをマップします。 ユーザがリ
クエストする際に、CA SiteMinder for Secure Proxy Server は HTTP ヘッダか
らクライアントの IP アドレスを取得し、これを使用してクライアントの
セッション用のセッション キーを生成します。
IP アドレス セッション スキームは、セッション スキーム API を使用して
作成されています。 このスキーム用のソース コードは、ディレクトリ
sps_home¥secure-proxy¥proxy-engine¥examples¥sessionschemes で見つける
ことができます。
注： サンプルのセッション スキーム ファイルで、円記号（¥）の文字は行
が続行されることを示しますが、このドキュメントではスペースに制約が
あるため中断される必要があります。
第 18 章： SPS API 315
セッション スキーム API
IP アドレス セッション スキームを実装する方法
1. 以下のような server.conf ファイルに <SessionScheme> セクションを追
加します。
<SessionScheme name="ip_address">
class="com.netegrity.proxy.session.IPAddrSessionScheme"
accepts_smsession_cookies="false"
allowed_proxied_addresses="true"
</SessionScheme>
ディレクティブは次のとおりです。
class
このディレクティブは、IP アドレス セッション スキームを処理す
る Java クラスを指定します。 ユーザが CA SiteMinder for Secure
Proxy Server と共にインストールされたデフォルトの IP アドレス
セッション スキームを使用する場合、この値は変更できません。
デフォルト： com.netegrity.proxy.session.IPAddrSessionScheme
accepts_smsession_cookies
SiteMinder SMSESSION Cookie がこのセッション スキームにサポー
トされないことを示します。 IP アドレス スキームを使用して、
Cookie のないセッションを保証するには、このディレクティブの
値は変更できません。
デフォルト： false
allowed_proxied_addresses
リクエストが SessionScheme.isValidRequest コールを使用して検証
されるかどうかを示します。 プロキシされたアドレスの使用を許
可するには、値を true に設定します。 VIA HTTP ヘッダ変数が存在
するかどうかを判断するために isValidRequest メソッドを使用する
には、デフォルトの false にします。 この変数が存在する場合、CA
SiteMinder for Secure Proxy Server はアドレスがプロキシされてい
ると判断し、リクエストをブロックします。
デフォルト： true
2. server.conf ファイルの仮想ホスト用の 1 つ以上のユーザ エージェント
にセッション スキームをマップします。
3. CA SiteMinder for Secure Proxy Server サーバを再起動します。
316 管理ガイド
API の概要のフィルタ
セッション ストレージ API
CA SiteMinder for Secure Proxy Server はセッション トークンから
SiteMinder セッションにマッピングを格納します。 この情報は
SessionStorageAPI を使用してアクセスされます。
SessionStorageAPI では以下の機能が提供されます。
セッション作成
新しいセッションの作成を許可します。
セッションの更新または同期
SiteMinder セッション情報への更新を許可します。
セッション取得
正しいセッション キーで提供された場合にセッション情報の取得を
許可します。
明示的なセッション削除
特定のセッション キーを使用して、セッションの削除を許可します。
セッション有効期限
すべての期限切れセッションの削除を許可します。
API の概要のフィルタ
カスタム フィルタは顧客のニーズによって定義されたフィルタです。 CA
SiteMinder for Secure Proxy Server ではカスタム フィルタを使用し、バック
エンド サーバにリクエストを転送する前にリクエストを操作し、また、
ユーザ クライアントに対してバックエンド サーバから送信されたレスポ
ンスを操作します。
CA SiteMinder for Secure Proxy Server は単一のカスタム フィルタまたは各
リクエストのカスタム フィルタのグループを処理できます。 カスタム
フィルタ グループを作成する場合、CA SiteMinder for Secure Proxy Server は
チェーン内のカスタム フィルタ グループの一部であるフィルタをすべて
処理します。
第 18 章： SPS API 317
API の概要のフィルタ
フィルタ API で作成された前処理フィルタおよび後処理フィルタ用の
ソース コードを確認することができます。 これらのサンプルは以下の
ディレクトリで見つかる場合があります。
sps_home/proxy-engine/examples/filters
注： コード サンプルで、円記号（¥）の文字は行が続行されることを示し
ますが、このドキュメントではスペースに制約があるため中断される必要
があります。
詳細情報
プロキシ ルールとカスタム フィルタの関連付け (P. 319)
SPS がカスタム フィルタを処理する方法
CA SiteMinder for Secure Proxy Server には、リクエストのプロキシ段階に前
処理および後処理を挿入するための API が含まれています。
標準 CA SiteMinder for Secure Proxy Server トランザクションでは、以下のプ
ロセスが発生します。
1. ユーザはリソースをリクエストします。
2. CA SiteMinder for Secure Proxy Server はそのプロキシ ルールを検討し、
（認証および許可に成功した後に）リクエストを管理する場所を決定
します。
3. 送信先サーバはリクエストされたリソースを CA SiteMinder for Secure
Proxy Server に送信します。ここからリソースをユーザに渡します。
フィルタ API は、前のプロセスの手順 2 に述べられているようにリクエス
トが送信先サーバに渡される前に、または前のプロセスの手順 3 に述べら
れているように送信先サーバからのレスポンスが CA SiteMinder for Secure
Proxy Server に返された後に、リソースがユーザに渡される前に処理を挿
入する開発者用のメソッドを提供します。
318 管理ガイド
API の概要のフィルタ
プロキシ ルールとカスタム フィルタの関連付け
CA SiteMinder for Secure Proxy Server がリクエストまたはレスポンスを受
信する場合、CA SiteMinder for Secure Proxy Server はプロキシ ルールを読み
取り、関連するフィルタを処理します。 server.conf ファイルで宣言されて
いるカスタム フィルタまたはカスタム グループ フィルタは、プロキシ
ルールと関連付ける必要があります。 カスタム フィルタまたはカスタム
グループ フィルタをプロキシ ルールに関連付けるには、<install
dir>/secure-proxy/proxy-engine/conf にある proxyrules.xml を開いて、フィル
タを実行すると予想されるルール用に proxyrules.xml ファイルを編集しま
す。
例：
<nete:forward filter="your filter name or your
groupfiltername">http://FQDN$0</nete:forward>
API クラス ファイルのフィルタ
CA SiteMinder for Secure Proxy Server フィルタ API は、
sps_home/Tomcat/server/lib/proxyrt.jar に含まれるプロキシ フィルタ クラ
スを利用します。
第 18 章： SPS API 319
API の概要のフィルタ
ProxyFilter インターフェース
ProxyFilter インターフェースは、プロキシ フィルタによって実装されるイ
ンターフェースを定義します。 ただし、ProxyFilter インターフェースを実
装するのではなく、BaseProxyFilter の抽象的な実装を拡張することが推奨
されます。
ProxyFilter インターフェースは以下のメソッドから構成されます。
戻り値
メソッド
void
doFilter(ProxyRequest prequest, ProxyResponse presponse)
フィルタリングを実行します。
パラメータ：
request - プロキシ リクエスト データ
response - プロキシ レスポンス データ
スローする値：
ProxyFilterException - ‥フィルタリング処理に失敗した場合にスロー
されます。
ProxyFilterConfig
getFilterConfig()
このフィルタの ProxyFilterConfig オブジェクトを返します。（このフィ
ルタを初期化した ProxyFilterConfig オブジェクト）。
void
init(ProxyFilterConfig config)
要求された初期化を実行するためにフィルタが作成される場合にコー
ルされます。
パラメータ：
config - フィルタの設定および初期化パラメータが含まれる
ProxyFilterConfig オブジェクト
スローする値：
ProxyFilterException - このフィルタの初期化に失敗した場合にスロー
されます。
320 管理ガイド
API の概要のフィルタ
BaseProxyFilter の抽象的な実装
フィルタ API には、BaseProxyFilter （ProxyFilters を作成するためにサブク
ラスとして実装できるプロキシ フィルタの抽象的な実装）が含まれます。
注： ProxyFilter インターフェースを実装するのではなく、BaseProxyFilter の
抽象的な実装を拡張することが推奨されます。
BaseProxyFilter のサブクラスは尐なくとも以下のいずれかのメソッドを
オーバーライドする必要があります。
■
doPreFilter
■
doPostFilter
■
doFilter （推奨されません）
BaseProxyFilter にはフィルタ初期化が含まれて、以下の表に示すように、
CA SiteMinder for Secure Proxy Server トランザクションにユーザ自身の
フィルタを挿入するための前処理フックと後処理フックを分離します。
戻り値
メソッド
Void
doFilter(ProxyRequest prequest,
ProxyResponse presponse) throws
ProxyFilterException
この実装はリクエスト処理の状態を判定し、受信状態である場合は
doPreFilter をコールし、送信状態の場合は doPostFilter をコールします。
フィルタがコールされる時点で、処理は必ずこれらの状態のいずれか
になります。
以下によって指定されます。
doFilter in interface ProxyFilter
パラメータ：
request - プロキシ リクエスト データ
response - プロキシ レスポンス データ
スローする値：
ProxyFilterException - ‥フィルタリング処理に失敗した場合にスローさ
れます。
第 18 章： SPS API 321
API の概要のフィルタ
戻り値
メソッド
Void
doPreFilter(ProxyRequest prequest,
ProxyResponse presponse) throws
ProxyFilterException
事前フィルタリングを実行します。 このメソッドをオーバーライドし
て、リクエストがターゲット サーバに送信される前にフィルタリング
タスクを実行します。
パラメータ：
request - プロキシ リクエスト データ
response - プロキシ レスポンス データ
スローする値：
ProxyFilterException - ‥フィルタリング処理に失敗した場合にスローさ
れます。
Void
doPostFilter(ProxyRequest prequest,
ProxyResponse presponse) throws
ProxyFilterException
ポストフィルタリングを実行します。 このメソッドをオーバーライド
して、レスポンスがターゲット サーバから受信された後にフィルタリ
ング タスクを実行します。
パラメータ：
request - プロキシ リクエスト データ
response - プロキシ レスポンス データ
スローする値：
ProxyFilterException - ‥フィルタリング処理に失敗した場合にスローさ
れます。
ProxyFilterConfig
getFilterConfig()
このフィルタの ProxyFilterConfig オブジェクトを返します。
以下によって指定されます。
ProxyFilter インターフェース内の getFilterConfig
戻り値：
ProxyFilterConfig - ‥このフィルタを初期化した ProxyFilterConfig オブ
ジェクト。
322 管理ガイド
API の概要のフィルタ
戻り値
メソッド
Void
init(ProxyFilterConfig config) throws
ProxyFilterException
要求された初期化を実行するためにフィルタが作成される場合にコー
ルされます。
注： このメソッドをオーバーライドする場合、最
初のステートメントは親 init メソッドである
"super.init(config)" をコールする必要があります。
以下によって指定されます。
init in interface ProxyFilter
パラメータ：
config - フィルタの設定および初期化パラメータが含まれる
ProxyFilterConfig オブジェクト
スローする値：
ProxyFilterException - このフィルタの初期化に失敗した場合にスローさ
れます。
ProxyFilterConfig インターフェース
フィルタで使用可能な設定データへのインターフェースを定義します。
インターフェースは以下のメソッドから構成されます。
戻り値
メソッド
java.lang.String
getFilterName()
このフィルタの名前を返します。
java.lang.String
getInitParameter(java.lang.String name)
命名された初期化パラメータの値が含まれる String、またはパラ
メータが存在しない場合は NULL を返します。
パラメータ：
name - 初期化パラメータの名前を指定する String
java.util.Enumeration
getInitParameterNames()
フィルタの初期かパラメータの名前を String オブジェクトの列挙
として返します。または、フィルタに初期化パラメータがない場
合は空の列挙を返します。
第 18 章： SPS API 323
API の概要のフィルタ
ProxyResponse インターフェース
プロキシ クライアントに返される HTTP レスポンス情報へのアクセスを
提供するインターフェースを定義します。 インターフェースは以下のメ
ソッドから構成されます。
戻り値
メソッド
void
addHeader(java.lang.String name, java.lang.String value)
指定された名前および値を持ったヘッダを追加します。 このメ
ソッドは、レスポンス ヘッダが複数の値を持つことを可能にし
ます。
パラメータ：
name - ヘッダ名を指定する String
value - ヘッダ値を指定する String
byte[]
getContent()
プロキシ リクエストに対するレスポンスのコンテンツのバイト
配列を返します。 これはプロキシ クライアントに返されるコン
テンツです。
java.lang.String
getHeader(java.lang.String name)
指定されたヘッダの値を String として返します。 ヘッダが存在
しない場合、このメソッドは NULL を返します。 ヘッダ名は、大
文字と小文字が区別されません。
パラメータ：
name - ヘッダ名を指定する String
java.util.Enumeration
getHeaderNames()
すべてのヘッダ名の列挙を返します。ヘッダが存在しない場合、
このメソッドは空の列挙を返します。
int
getStatusCode()
プロキシ リクエストに対するレスポンスの HTTP レスポンス ス
テータス コードを返します。
324 管理ガイド
API の概要のフィルタ
戻り値
メソッド
java.lang.String
removeHeader(java.lang.String name)
指定されたヘッダを削除します。削除されたヘッダの値を String
として返します。 ヘッダが存在しない場合、このメソッドは
NULL を返します。 ヘッダ名は、大文字と小文字が区別されませ
ん。
パラメータ：
name - ヘッダ名を指定する String
void
setContent(byte[] content)
プロキシ リクエストに対するレスポンスのコンテンツを設定し
ます。 これは、プロキシ クライアントに返されるコンテンツを
上書きします。
パラメータ：
content - コンテンツが含まれるバイト配列
void
setHeader(java.lang.String name, java.lang.String value)
指定された名前および値を持つヘッダを設定します。 同じ名前
のヘッダが存在する場合、そのヘッダは上書きされます。
パラメータ：
name - ヘッダ名を指定する String
value - ヘッダ値を指定する String
ProxyFilterException クラス
ProxyFilterException クラスは、障害に遭遇した場合にフィルタがスローで
きる一般的な例外を定義します。
コンストラクタの署名
説明
ProxyFilterException()
新しい ProxyFilterException を作成します。
ProxyFilterException(java.lang.String
message)
指定されたメッセージで新しい ProxyFilterException
を作成します。
パラメータ：
message - 例外のメッセージ
第 18 章： SPS API 325
API の概要のフィルタ
コンストラクタの署名
説明
ProxyFilterException(java.lang.String
message, java.lang.Throwable rootCause)
指定されたメッセージおよび根本原因で新しい
ProxyFilterException を作成します。
パラメータ：
message - 例外のメッセージ
rootCause - 発生するこの例外の原因になった例外
ProxyFilterException(java.lang.Throwable
rootCause)
指定されたメッセージおよび根本原因で新しい
ProxyFilterException を作成します。
パラメータ：
rootCause - 発生するこの例外の原因になった例外
ProxyRequest インターフェース
プロキシによって送信される HTTP リクエスト情報へのアクセスを提供す
るインターフェースを定義します。 インターフェースは以下のメソッド
から構成されます。
戻り値
メソッド
java.lang.String
getHeader(java.lang.String name)
指定されたヘッダの値を String として返します。 ヘッダが存
在しない場合、このメソッドは NULL を返します。 ヘッダ名
は、大文字と小文字が区別されません。
パラメータ：
name - ヘッダ名を指定する String
java.util.Enumeration
getHeaderNames()
すべてのヘッダ名の列挙を返します。ヘッダが存在しない場
合、このメソッドは空の列挙を返します。
javax.servlet.http.HttpServletRequ
est
326 管理ガイド
getOriginalRequest()
プロキシに対して作成された元の HttpServletRequest を返し
ます。
API の概要のフィルタ
戻り値
メソッド
java.lang.String
getSessionKey()
セッション キーの値を String として返します。キーが使用可
能でない場合、このメソッドは NULL を返します。 キーは、
Cookie なしのスキームを使用する場合にコンテンツ内の URL
を書き換えるために使用できます。
注： SessionScheme は、キーを作成し、
SessionScheme.DEFAULT_SESSION_KEY_NAME という名前の属
性にそれを格納します。
java.lang.String
getTargetQueryString()
プロキシがターゲット URL と一緒に使用するクエリ文字列
を返します。 クエリ文字列は、元のリクエストまたはプロキ
シ ルールによって定義された新しいリクエストのものであ
る可能性があります。 URL にクエリ文字列がない場合、この
メソッドは NULL を返します。
java.lang.String
getTargetURL()
プロキシ ルールによって定義されたリクエストを作成する
ためにプロキシが使用する URL を返します。URL にはクエリ
文字列パラメータが含まれません。
boolean
isInbound()
リクエスト処理の状態を示すブール値を返します。リクエス
トがターゲット サーバに転送されていない場合は、true を返
します。 リクエストが送信され、レスポンスが受信された場
合は、false を返します。
boolean
isOutbound()
リクエスト処理の状態を示すブール値を返します。リクエス
トがターゲット サーバに転送されていない場合は、false を返
します。 リクエストが送信され、レスポンスが受信された場
合は、true を返します。
java.lang.String
removeHeader(java.lang.String name)
指定されたヘッダの値を削除し、String として返します。ヘッ
ダが存在しない場合、このメソッドは NULL を返します。ヘッ
ダ名は、大文字と小文字が区別されません。
パラメータ：
name - ヘッダ名を指定する String
第 18 章： SPS API 327
API の概要のフィルタ
戻り値
メソッド
void
setHeader(java.lang.String name, java.lang.String value)
指定された名前および値を持つヘッダを設定します。同じ名
前のヘッダが存在する場合、そのヘッダは上書きされます。
パラメータ：
name - ヘッダ名を指定する String
value - ヘッダ値を指定する String
byte[]
getContent()
Request POST データのコンテンツのバイト配列を返します。
これはバックエンド サーバに送信されるコンテンツです。
void
setContent(byte[] content)
POST データのコンテンツをプロキシ リクエストに設定しま
す。
これは、バックエンド サーバに送信されるコンテンツを上書
きします。
パラメータ：
content - リクエスト POST データが含まれるバイト配列
フィルタの実装
セッション キーを使用するフィルタは、キーを定義するセッション ス
キームに依存します。 セッション キーをフィルタで使用できるようにす
るには、SessionScheme.DEFAULT_SESSION_KEY_NAME によってキー設定さ
れた属性が、createKeyFromRequest(..) コールバックにより作成され、以降
のリクエストでセッション スキーム API の getKeyFromRequest(..) コール
バックによって取得された場合、キーの値を保持するように設定する必要
があります。
セッション キーを生成する、すぐに使用可能なセッション スキームは次
のとおりです。
328 管理ガイド
■
ミニ Cookie
■
シンプル URL リライティング
API の概要のフィルタ
次の手順に従ってください：
1. 「フィルタの例」 内のフィルタ用のサンプル コードを確認します。
2. フィルタ用のソース コードを作成します。
3. システムの CLASSPATH に以下のコンテンツが含まれることを確認し
ます。
■
フィルタ API を含む proxyrt.jar
■
JDK バージョン 1.6.0_30 以降の jar ファイル
■
sps_home/Tomcat/lib の jar ファイル
4. フィルタをコンパイルします。
5. 以下のいずれかの手順を実行します。
■
使用するフィルタを含む .jar ファイルを作成し、このファイルを
sps_home/Tomcat/lib ディレクトリにコピーします。
■
sps_home/Tomcat/lib ディレクトリ内の jar のフィルタ用のクラス
ファイルを追加します。
6. CA SiteMinder for Secure Proxy Server server.conf ファイルを設定します。
7. フィルタを実装すると予想されるルールに対して、proxyrules.xml ファ
イルを編集します。 例：
<nete:forward filter="your filter name">http://FQDN$0</nete:forward>
8. CA SiteMinder for Secure Proxy Server サーバを再起動します。
API の例のフィルタ
CA SiteMinder for Secure Proxy Server のインストールには、前処理フィルタ
および後処理フィルタ用のサンプル ソース ファイルが含まれます。 これ
らのサンプルはどちらも BaseProxyFilter の抽象型の実装を使用します。
フィルタの例の完全な説明については、フィルタの例を参照してください。
第 18 章： SPS API 329
API の概要のフィルタ
リクエストされたページの絶対的なリンクを書き換えるためのフィルタの使用
Filter API の最もよく見られる用途の 1 つは、ユーザによってリクエストさ
れたページの絶対的なリンクの CA SiteMinder for Secure Proxy Server によ
る書き換えをサポートすることです。 絶対的なリンクが CA SiteMinder for
Secure Proxy Server によって正しく処理されるためには、CA SiteMinder for
Secure Proxy Server リクエストに基づいてユーザに返されたリソースに含
まれていた絶対的なリンクの適切な置き換えを実行するために、フィルタ
API を使用する必要があります。
330 管理ガイド
第 19 章： トラブルシューティング
このセクションには、以下のトピックが含まれています。
SSL 設定の後にブラウザにポップアップ ウィンドウが表示される (P. 332)
UNIX システム上で Apache を起動できません (P. 333)
英語以外の入力文字にジャンク文字が含まれる (P. 333)
フェデレーション Web サービス エラーをログ記録できない (P. 334)
DNS がリクエストのたびにキャッシュされる (P. 335)
リソース リクエストの失敗 (P. 336)
インストール プログラムが警告を表示する (P. 340)
SPS サーバを起動できません (P. 341)
ブラウザで SPS にアクセスできません (P. 342)
仮想ホストの設定における問題 (P. 342)
仮想ホストの設定が失敗する (P. 343)
リクエストを転送しない SPS (P. 343)
SharePoint ページへのアクセス エラー (P. 344)
第 19 章： トラブルシューティング 331
SSL 設定の後にブラウザにポップアップ ウィンドウが表示される
SSL 設定の後にブラウザにポップアップ ウィンドウが表示され
る
症状：
SSL 設定の後にインターネット ブラウザを使用して CA SiteMinder® SPS に
アクセスすると、ポップアップ ウィンドウが表示されます。
解決方法：
SSL を設定した後に、弱い暗号化アルゴリズムを備えたインターネット ブ
ラウザを使用して CA SiteMinder® SPS に初めてアクセスした場合、ポップ
アップ ウィンドウが表示されます。 このポップアップを許可すると、CA
SiteMinder® SPS にアクセスできます。ポップアップを表示したくない場合
は、以下のいずれかの手順を実行します。
■
強力な暗号化アルゴリズムをサポートしている強力なインターネット
ブラウザ（Internet Explorer 8.0、Chrome、Mozilla Firefox など）を使用
します。
■
X509 ベースの認証方式を使用していない場合は、以下の手順を実行し
ます。
a. <install_path>/httpd¥conf¥extra¥ に移動します。
b. httpd-ssl.conf ファイルを開きます。
c. SSLVerifyClient に移動し、値を none に設定します。
d. 変更を保存します。
e. CA SiteMinder® SPS を再起動します。
332 管理ガイド
UNIX システム上で Apache を起動できません
UNIX システム上で Apache を起動できません
症状：
UNIX システムで CA SiteMinder for Secure Proxy Server を実行している場合、
Apache サーバは起動に失敗します。 Apache のログ ファイルで、以下のエ
ラー メッセージが表示されます。
Invalid argument: setgid: unable to set group id to ...
解決方法：
UNIX システム上の Run-As-User 用のグループが Apache 設定ファイル
（httpd.conf）で指定されたグループに対応しない場合、このエラーが発
生します。 このエラーが表示される場合は、Apache httpd.conf ファイル内
の Group ディレクティブを編集します。
Group ディレクティブを編集する方法
1. Group ディレクティブの前のコメント記号（#）の削除
2. Run-As-User が属するグループを指定します。
3. 再度、CA SiteMinder for Secure Proxy Server スタートアップ コマンドを
実行します（sps-ctl start または startssl）。
英語以外の入力文字にジャンク文字が含まれる
UNIX/Linux 上で有効
症状：
英語以外の入力文字の一部がコンソール ウィンドウに正しく表示されま
せん。解決方法：
コンソール ウィンドウのターミナルの設定を確認します。 コンソールが
入力文字の高位（8）ビットをクリアしないことを確認します。 以下のコ
マンドを実行します。
stty –istrip
第 19 章： トラブルシューティング 333
フェデレーション Web サービス エラーをログ記録できない
フェデレーション Web サービス エラーをログ記録できない
症状：
フェデレーション Web サービス エラーがログに記録されません。
解決方法：
フェデレーション Web サービスのエラーをログ記録するには、
LoggerConfig.properties ファイル内の AffWebServices と FWSTrace ログ パラ
メータを有効にします。
次の手順に従ってください：
1. LoggerConfig.properties ファイルを開きます。
デフォルト パス：
sps_home/secure-proxy/Tomcat/webapps/affwebservices/WEB-INF/classes
/LoggerConfig.properties
2. 以下のパラメータを設定します。
LoggingOn=Y
TracingOn=Y
3. 変更を保存します。
334 管理ガイド
DNS がリクエストのたびにキャッシュされる
DNS がリクエストのたびにキャッシュされる
症状：
CA SiteMinder for Secure Proxy Server にサーバの DNS 名ルックアップ設定
がキャッシュされないようにしたいのですがされてしまいます。
解決方法：
CA SiteMinder for Secure Proxy Server はデフォルトでサーバの DNS 設定を
キャッシュするように設定されています。 このデフォルト動作を変更す
るには、java.security ファイル内の networkaddress.ttl 設定を調節します。
次の手順に従ってください：
1. ディレクトリ NETE_SPS_JAVA_HOME¥jre¥lib¥security に移動します。
2. java.security ファイルを開きます。
3. networkaddress.cache.ttl パラメータを正の整数に設定します。 例：
networkaddress.cache.ttl=2
networkaddress.ttl
CA SiteMinder for Secure Proxy Server が正常に実行された DNS 名前
ルックアップをキャッシュする期間（秒）を指定します。 正の整
数を入力します。 負の値を入力すると、CA SiteMinder for Secure
Proxy Server は DNS 設定をキャッシュします。
デフォルト： -1
第 19 章： トラブルシューティング 335
リソース リクエストの失敗
リソース リクエストの失敗
症状：
CA SiteMinder for Secure Proxy Server は、リソース リクエストに応えること
ができませんでした。
解決方法：
エラーをトラブルシューティングするには、エラー詳細について、以下の
ログ ファイルを確認します。
■
spsagent および spsagenttrace ログ
■
Apache のアクセスおよびエラー ログ
■
httpclient.log
■
server.log
■
mod_jk.log
ログ ファイルにログが含まれていない場合、ログ ファイルのロギングを
有効にしたかを確認します。
詳細情報：
spsagent ログの設定 (P. 337)
SPSAgentTrace ログの設定 (P. 338)
mod_jk.log ファイルの設定 (P. 339)
httpclient.log ファイルの設定 (P. 340)
336 管理ガイド
リソース リクエストの失敗
spsagent ログの設定
CA SiteMinder for Secure Proxy Server は、spsagent ログ内のプロキシ エンジ
ンに関連したエラーをログ記録します。 ポリシー サーバ内のローカル設
定ファイルまたは ACO には、エラー ログ記録を有効にし、ログ記録オプ
ションを確定するパラメータが含まれます。
次の手順に従ってください：
1. ポリシー サーバ内の CA SiteMinder for Secure Proxy Server の ACO を開
きます。
2. LogFile パラメータの値を yes に設定します。
注： ローカル設定ファイル内でこのパラメータの値を yes に設定する
と、ポリシー サーバ上で定義されたあらゆるロギング設定をオーバー
ライドします。
3. 以下のパラメータをすべて設定します。
LogFileName
ログ ファイルの完全パス（ファイル名を含む）を指定します。
LogAppend
既存のログ ファイルの最後に新しいログ情報を追加します。 この
パラメータを no に設定した場合、ロギングが有効になるたびに、
ログ ファイル全体が上書きされます。
LogFileSize
ログ ファイルのサイズ制限（メガバイト単位）を指定します。 現
在のログ ファイルがこの制限に到達すると、新しいログ ファイル
が作成されます。
LogLocalTime
ログがグリニッジ標準時（GMT）とローカル時間のどちらを使用
するかを指定します。GMT を使用するには、この設定を no に変更
します。このパラメータが存在しない場合は、デフォルト設定が
使用されます。
4. CA SiteMinder for Secure Proxy Server を再起動します。
エラー ログが設定されます。
第 19 章： トラブルシューティング 337
リソース リクエストの失敗
SPSAgentTrace ログの設定
トレース ログを設定し、ファイルのサイズおよび形式を制御することが
可能です。 トレース ロギングを設定したら、トレース ログ ファイルのコ
ンテンツを別個に指定します。 これにより、トレース ログ ファイル自体
のパラメータを変更することなく、必要に応じて、トレース ログに含め
る情報のタイプを変更することができます。
次の手順に従ってください：
1. SecureProxyTrace.conf ファイルを見つけて、ファイルを複製します。
2. エージェント設定オブジェクトまたはローカル設定ファイルを開きま
す。
3. TraceFile パラメータに yes を設定します。
注： ローカル設定ファイル内でこのパラメータの値を yes に設定する
と、ポリシー サーバ上で定義されたあらゆるロギング設定をオーバー
ライドします。
4. 以下のパラメータを設定します。
TraceFileName
トレース ログ ファイルの完全パスを指定します。
TraceConfigFile
監視するコンポーネントとイベントを決定する
SecureProxyTrace.conf 設定ファイルの場所を指定します。
TraceAppend
ログ記録が呼び出されるたびにファイル全体を書き直す代わりに、
既存のログ ファイルの最後に新しいログ記録情報を追加する必要
があるかどうかを指定します。
TraceFormat
トレース ファイルがメッセージを表示する方法を指定します。
TraceDelimiter
トレース ファイル内のフィールドを区切るカスタム文字を指定し
ます。
TraceFileSize
トレース ファイルの最大サイズを指定します（メガバイト単位）。
この指定が満たされると、CA SiteMinder for Secure Proxy Server は新
しいファイルを作成します。
338 管理ガイド
リソース リクエストの失敗
LogLocalTime
ログがグリニッジ標準時（GMT）とローカル時間のどちらを使用
するかを指定します。GMT を使用するには、この設定を no に変更
します。このパラメータが存在しない場合は、デフォルト設定が
使用されます。
5. CA SiteMinder for Secure Proxy Server を再起動します。
mod_jk.log ファイルの設定
CA SiteMinder for Secure Proxy Server は、Apache とプロキシ エンジンとの
間の通信メッセージをすべて mod_jk.log ファイルにログ記録します。 デ
フォルトでは、このファイル内でログ記録は有効です。ログ ファイルは
sps_home¥secure-proxy¥httpd¥logs¥mod_jk.log にあります。
次の手順に従ってください：
1. httpd.conf ファイルを開きます。
デフォルト パス： sps_home¥secure-proxy¥httpd¥conf
2. 必要に応じて使用可能なパラメータを変更します。
注： httpd.conf ファイルおよび mod_jk.log ファイルの設定に関する詳
細については、Apache のドキュメント セットを参照してください。
3. JkRequestLogFormat は、%w %V %T %m %h %p %U %s フォーマットで設
定されていることを確認します。
4. 変更を保存します。
5. CA SiteMinder for Secure Proxy Server を再起動します。
第 19 章： トラブルシューティング 339
インストール プログラムが警告を表示する
httpclient.log ファイルの設定
デバッグする場合のみ、httpclient.log を有効にできます。デフォルトでは、
httpclient.log ファイルは sps_home¥secure-proxy¥proxy-engine¥logs にあり
ます。
次の手順に従ってください：
1. server.conf ファイルを開きます
2. httpclientlog が yes に設定されていることを確認します。
3. httpclientlogging.properties ファイルを開きます。
デフォルト パス： sps_home¥Tomcat¥properties ディレクトリ
4. 必要に応じて使用可能なパラメータを変更します。
注： httpclientlogging.properties ファイルを設定する詳細については、
Apache のドキュメント セットを参照してください。
5. 変更を保存します。
インストール プログラムが警告を表示する
UNIX で該当
症状：
CA SiteMinder for Secure Proxy Server をインストールすると、インストール
ウィザードに、いくつかのファイルを手動で設定する必要があるという警
告が表示されます。
解決方法：
ユーザにルート権限がない場合、CA SiteMinder for Secure Proxy Server をイ
ンストールすることはできますが、自動インストール プロセスですべて
のインストール手順を完了できません。 インストール ウィザードは、手
動で設定する必要があるファイルをユーザが判断するのに役立つ警告を
表示します。
注： SSL 対応のサーバの場合、ルート権限以外でのインストールは推奨さ
れません。 これはルート権限を持つ追加のユーザにキーおよび証明書に
アクセスすることを許可するため、ルート以外のインストールはそれほど
安全ではありません。
340 管理ガイド
SPS サーバを起動できません
SPS サーバを起動できません
症状：
CA SiteMinder for Secure Proxy Server サーバが起動しません。
解決方法：
サーバを起動できない場合、以下の情報を使用します。
■
sps_home/secure-proxy/httpd/conf/httpd.conf の ServerName ディレク
ティブが、ユーザのサーバの名前に対応していることを確認します。
■
以下のコマンドのいずれかを実行して、サーバがまだ実行されていな
いことを確認します。
■
BSD 互換システムの場合： ps -ax|grep http
■
System V リリース 4 互換システムの場合： ps -elf|grep http
これがプロセスのリストに表示される場合、新しいサーバを開始する
前に実行中のサーバを停止します。
■
ディレクトリ sps_home/secure-proxy/httpd/logs のログ ファイルを確認
します。
■
httpd.conf ファイルの SSLCertificateFile および SSLCertificateKeyFile ディ
レクティブが、ユーザの証明書およびキー ファイルを指していること
を確認します。 ファイルは、ディレクトリ
sps_home/secure-proxy/httpd/conf にあります。
■
IP ベース以外の仮想ホストを使用しているかどうか判断します。 SSL
には IP ベースの仮想ホストが必要です。
■
他のサーバが SPS のデフォルト ポートで実行されていないことを確
認します。 デフォルト ポートは httpd.conf ファイルで指定されます。
■
SSL を使用している場合、サーバを起動する前にキーおよび証明書をし
てください。そうしないとエラーが発生します。
第 19 章： トラブルシューティング 341
ブラウザで SPS にアクセスできません
ブラウザで SPS にアクセスできません
症状：
ブラウザを使用した CA SiteMinder for Secure Proxy Server へのアクセス困
難。
解決方法：
ブラウザを使用して CA SiteMinder for Secure Proxy Server にアクセスする
方法
■
コマンド nslookup servername で DNS がサーバ名を認識していること
を確認するか、
ping servername コマンドでサーバに「ping」を試行します。
■
SSL なしでサーバを実行し、問題がキーまたは証明書のファイルにある
かどうかを確認するために Web サイトにアクセスします。 SSL なしで
サーバを開始するには、sps_home¥secure-proxy¥proxy engine directory
ディレクトリで ./sps-ctl start を実行します。
■
Web サーバ（または指定したデフォルト以外のポート）のポート 80 お
よび 443 に telnet 接続を行おうとします。 ルート以外のユーザでイン
ストールした場合、ポート 8080 および 8443 に接続しようとします。
仮想ホストの設定における問題
症状：
仮想ホストの設定で問題があります。
解決方法：
以下で仮想ホストの設定に関する情報を参照してください。
http://httpd.apache.org/docs-2.0/vhosts/
342 管理ガイド
仮想ホストの設定が失敗する
仮想ホストの設定が失敗する
症状：
仮想ホストの設定が失敗します。
解決方法：
仮想ホストの設定の詳細については、www.apache.org を参照してください。
リクエストを転送しない SPS
症状：
リソースにアクセスすると、404 「ファイルが見つかりません」というブ
ラウザ エラーが表示され、アクションは Web エージェント ログに記録さ
れません。
解決方法：
server.conf ファイル内の仮想ホストの名前および IP アドレスを確認しま
す。
第 19 章： トラブルシューティング 343
SharePoint ページへのアクセス エラー
SharePoint ページへのアクセス エラー
症状：
SPS を介して SharePoint ページにアクセスすると、CA SiteMinder for Secure
Proxy Server は、proxyrule.xml ファイルで設定されたモード（Forward また
は Redirect）にかかわらず、常に Alternate Access Mapping Connection パラ
メータを表示します。
解決方法：
この問題の解決するソリューションに対して、以下の手順を実行します。
1. SharePoint サーバで、［Central Administration］、［Operation］、
［Alternate Access Mapping］と移動します。［Alternate Access Mapping］
には、デフォルトの Zon 内部 URL およびパブリック URL が含まれてい
ることに注意してください。
2. パブリック URL セットが設定された内部 URL を、http://<SPS Host>:port
およびデフォルト ゾーンとして追加します。
3. もう 1 つの内部 URL パブリック URL セットを、http://<SharePoint
Host>:port およびデフォルト ゾーンとして追加します。
4. 手順 3 で作成したイントラネット ゾーンのエントリを編集し、パブ
リック URL を http://<SPS Host>:port として指定します。
5. バックエンドは、CA SiteMinder for Secure Proxy Server proxyrule.xml
ファイルで、CA SiteMinder for Secure Proxy Server ホストをポイントし
ているパブリック URL が設定された内部 URL です。 例：
<!--Proxy Rules-->
<nete:proxyrules xmlns:nete="http://ww.ca.com/">
<nete:forward>http://SharePointServer with public URL as SPS
host:port$0</nete:forward>
</nete:proxyrules>
344 管理ガイド

iUSBport HD - act2 サポートポータル

HP プロダクトセレクション12月号(JPS11465-41) OS SW

PRIMERGY システム構成図 (2014年5月版) プリンタ

詳細なシステム要件資料のダウンロード（Corp. 11

PRIMERGY TX1310 M1 システム構成図 (2015年2月版) 樹系図

OSセットアップガイド for Windows Server

インストレーションガイド(Windows編) エクスプレス通報サービス(MG)

テクニカルガイド LANボード編 (No.053272)

PRIMERGY RX1330 M1 システム構成図 (2015年2月版) 樹系図

HA8000/RS220 AN （筐体色：黒） 1．2 HA8000／RS220 （1

Small Voice 細き 聲 聖書研究

LPICレベル2技術解説無料セミナー LPICレベル2技術解説無料セミナ