アプリケーション層のパフォーマンス
目次
casso11jp
目次
2
ポリシー サーバは、リソースを保護するため、アプリケーション層でポリシーを評価し、データ層でユーザ認証情報および属性を評価します。アプリケーション層を調整するパフォーマンスに対する以下のガイドラインを考慮してください。
- ユーザの認証に必要なシステム リソースの量はパフォーマンスに影響します。
- ユーザの許可に必要なシステム リソースの量はパフォーマンスに影響します。
- 認証および許可の際の ユーザ ディレクトリへのポリシー サーバ リクエストの数はパフォーマンスに影響します。
ポリシー設計およびパフォーマンス
Single Sign-On
ポリシーは、ユーザとリソースがどのように関連するかを定義します。管理 UI で ポリシーを作成すると、ユーザ、リソース、リソースに関連するアクションを特定するさまざまなオブジェクトが結び付けられます(バインドされます)。特定の コンポーネントを設定する方法で、またはオプション機能を有効にすることによって、パフォーマンスを向上または低下させる場合があります。パフォーマンス戦略には以下が含まれます。
- パフォーマンスに影響する可能性がある ポリシー オブジェクトの特定
- ユーザ認証に影響するパラメータおよび機能の特定
- ユーザ許可に影響するパラメータおよび機能の特定
最終的には企業のビジネス ルールおよびセキュリティ要件によって ポリシー設計を指定する必要があります。以下のガイドラインは、これらの要件を満たすと同時に
Single Sign-On
のパフォーマンスも維持するようバランスを保つのに役立ちます。Single Sign-On
ポリシー オブジェクトおよびパフォーマンス ロードマップSingle Sign-On
では、特定の順序で のコア ポリシー オブジェクトを設定する必要があります。以下の図にこの順序を一覧表示します。グレー表示された項目は、ユーザ認証または許可中のパフォーマンスに影響するオブジェクトを表します。注
: ホスト設定オブジェクト(HCO)およびエージェント設定オブジェクト(ACO)は、Web 層のパフォーマンスに影響します。
アプリケーション
アプリケーションの設定方法によって、認証および許可中のパフォーマンスを向上または低下させる場合があります。
アプリケーションは、1 つ以上の関連する Web サービスの完全なセキュリティ ポリシーを定義するポリシー サーバ オブジェクトです。アプリケーションは、Web サービス リソースをユーザ ロールと関連付けて、どの Web サービス ユーザがどの Web サービス アプリケーション リソースにアクセスできるかを決める資格ポリシーを指定します
アプリケーションを作成すると、それをポリシー サーバがユーザ認証を試行する 1 つ以上のユーザ ディレクトリ接続にバインドします。そのため、ディレクトリ接続の数、およびそれらがリストされている順序は、認証中の
Single Sign-On
のパフォーマンスに直接影響します。アプリケーションで保護されたリソースとして定義されている Web サービス ポートおよび操作の数は、許可中の
Single Sign-On
のパフォーマンスに相関します。リソースは 1 つ以上のレスポンスにバインドできます。リソースにアクセスすると、関連するレスポンスがユーザ属性、DN 属性、静的なテキスト、またはカスタマイズされたアクティブなレスポンスなどの情報をエージェントに返します。
Web サービス リソースにバインドするレスポンスのタイプは、許可中の
Single Sign-On
のパフォーマンスと直接相関します。ドメイン
ドメインを設定する方法によって、認証中のパフォーマンスを向上または低下させる場合があります。
Single Sign-On
ポリシードメインは、1 つ以上のユーザ ディレクトリに関連したリソースの論理グループです。ドメインの作成時に、1 つ以上のユーザ ディレクトリ接続をドメインにバインドします。ポリシー サーバは、これらのディレクトリ接続を使用して、ユーザの認証を試行します。そのため、ディレクトリ接続の数、およびそれらが一覧表示されている順序は、認証中の
Single Sign-On
のパフォーマンスと直接相関します。レルム
レルムを設定する方法によって、認証中のパフォーマンスを向上または低下させる場合があります。
ドメインのリソースを 1 つ以上のレルムにグループ化します。レルムとは、共通のセキュリティ(認証)要件を持つリソース(URL)のセットです。定義するリソース フィルタおよび選択する認証方式は、認証中のパフォーマンスと直接相関します。
- リソース フィルタは保護されたリソースのルートとして機能します。ポリシー サーバは、リソース フィルタを評価してリクエストされたリソースが保護されているかどうかを判断する必要があります(IsProtected?)。
- レルムに関連付けられた認証方式によって、ユーザがレルム内のリソースへのアクセス権を取得するために示す必要がある認証情報のタイプが決まります(IsAuthenticated?)。
レルム設定によって、以下のことも決定します。
- Single Sign-Onによるユーザ セッションの処理方法。Single Sign-Onは、ユーザが認証されたレルムのコンテキストでユーザ セッションを作成します。
- 認証中にアクションを制御するためにレルムを使用できるかどうか。
ルールおよびルール グループ
レルムを設定する方法によって、許可中のパフォーマンスを向上または低下させる場合があります。
レルムのコンテキストでルールまたはルール グループを作成します。ルール
- 保護を必要とするレルム内の特定のリソースを識別する
- 特定の認証または許可イベントに基づいて、リソースへのアクセスを許可または拒否するために使用される場合があります。
ルールで定義するリソース フィルタ(その前にはレルム フィルタが付いている)は、保護を必要とするリソースを識別します。
ポリシー サーバはルールを評価して、リクエストされたリソースに一致するリソース フィルタを決定します。一致に際して、ポリシー サーバはルールがバインドされたポリシーを起動して、ユーザがリソースへのアクセスを許可されているかどうかを判断します。
レルム内のルールの数および各リソース フィルタの定義方法は、許可における
Single Sign-On
のパフォーマンスと直接関係します。[Responses]
レスポンスを設定する方法によって、許可中のパフォーマンスを向上または低下させる場合があります。
レスポンスまたはレスポンス グループは特定のルールまたはルール グループにバインドされます。ルールの起動時に、レスポンスは以下を実行できます。
- ユーザ セッションが有効である期間をカスタマイズします。
- ユーザをほかのリソースにリダイレクトします。
- ユーザ ディレクトリに含まれる属性に基づいて、ユーザが受信するコンテンツをカスタマイズします。
- スタティック テキスト、ユーザ属性、DN 属性、カスタマイズされたアクティブ レスポンス、または定義された変数のランタイム値をポリシー サーバから <stmndr> エージェントに渡します。
- WS-Security ヘッダおよび SAML セッション チケットを生成するように <agent> に指示します。
ポリシー ルールは 1 つ以上のレスポンスにバインドできます。ポリシー ルールにバインドするレスポンスのタイプは、許可中の
Single Sign-On
のパフォーマンスと直接相関します。認証ガイドライン
通常、認証(IsAuthenticated?)手順における
Single Sign-On
パフォーマンスは以下と相関します。- 認証リクエストの処理に使用されるシステム リソース
- ポリシー サーバが認証リクエストを処理するために <stmndr> ユーザ ディレクトリに対して行う読み取り/書き込み(リクエストと総称される)の数
ポリシー オブジェクトおよびパフォーマンス ロードマップ
特定の <stmndr> ポリシー オブジェクトの設定方法に応じて、またはそれらのオブジェクトに関連付けられたオプション機能を有効にすることによって、認証パフォーマンスが向上または低下する場合があります。
Single Sign-On
では、特定の順序で のコア ポリシー オブジェクトを設定する必要があります。以下の図にこの順序を一覧表示します。グレー表示された項目は、ユーザ認証中のパフォーマンスに影響するオブジェクトを表します。
ユーザ ディレクトリおよび認証パフォーマンス
ドメインの設定では、1 つ以上のユーザ ディレクトリ接続をドメインにバインドする必要があります。ポリシー サーバはユーザ ディレクトリ接続で指定する検索条件を使用して、認証手順中にユーザ認証情報を確認します。
以下の要因がディレクトリ レベルでユーザ認証のパフォーマンスに影響します。
- 式およびクエリの検索 -- LDAP 式または ODBC クエリが複雑であるほど、ポリシー サーバが条件を解決してユーザを認証するために時間がかかります。
- パスワード サービス -- パスワード ポリシーを <stmndr> ユーザ ディレクトリに適用できます。パスワード ポリシーの実装前に以下の点について考慮してください。
- ポリシー サーバはパスワード ポリシーに関連する属性を読み取り、それらを更新する必要がある場合があります。属性の更新には、ポリシー サーバによるユーザ ディレクトリへの書き込みが必要です。
- ログイン詳細を追跡するようにパスワード ポリシーが設定されている場合、すべての認証で追加のユーザ ディレクトリ書き込みが必要です。
- ポリシー サーバが、ディレクトリ全体ではなく、ディレクトリ内の特定のユーザ グループにのみ適用されるパスワード ポリシーを解決する場合に、より時間がかかります。
Single Sign-On
Web サービス セキュリティ認証方式および認証パフォーマンス<soasm> 認証方式によって、オーバーヘッドを処理する WSS エージェントのレベルが異なります。これは WSS エージェントのタイプによっても変わる場合があります。
一般的に、認証のスループットは、デジタル署名の検証やペイロードの機密性を必要としない認証方式に対して高くなります。
デジタル署名の検証は、Web サーバの WSS エージェントで CPU に負担がかかり、データ量が多くなりますが、アプリケーション サーバの WSS エージェントにも多少影響を与えます。
ドメインおよび認証パフォーマンス
以下の要因が、ドメイン(またはアプリケーション オブジェクト)レベルでユーザ認証のパフォーマンスに影響します。
- ドメイン内のディレクトリ接続数 -- ユーザ認証情報を検証できるまで、ポリシー サーバはドメイン内の各ユーザ ディレクトリを検索します。ユーザ ディレクトリ接続数が多いほど、ポリシー サーバによるユーザの認証に時間がかかる場合があります。ドメイン内のディレクトリ接続数を減らす方法を評価して、不要なポリシー サーバ リクエストを防止します。以下について考慮してください。
- ドメイン内のリソースをリクエストしているユーザ、およびそれらの情報が格納されているディレクトリ
- 組織をSingle Sign-On環境に追加する場合のユーザ ディレクトリの組み合わせ
- ユーザ ディレクトリ接続が一覧表示される順序 -- ポリシー サーバは、ドメインによって一覧表示される順にユーザ ディレクトリを検索します。接続の順序を決定するときに、認証優先度を評価します。以下について考慮してください。
- ユーザの大半が特定のディレクトリ(複数可)からアプリケーションにアクセスするかどうか
- 認証優先度が高い小規模なユーザ グループが存在するかどうか
レルムおよび認証パフォーマンス
以下の要因はレルム(またはアプリケーション オブジェクト コンポーネント)レベルでユーザ認証のパフォーマンスに影響します。レルムを設定する際に、以下のそれぞれを考慮してください。
- 認証情報コレクション -- レルムは特定の認証方式に関連付けられ、その一部は認証情報コレクタの使用を必要とします。これらのタイプの認証方式でリソースを保護するエージェントは、認証情報を収集するためにユーザを認証情報コレクタにリダイレクトします。認証情報の収集により、認証プロセスに手順が追加されます。
- 永続セッション --Single Sign-Onがユーザを認証するときに、ポリシー サーバはセッション チケットを発行します。セッション チケットには、ユーザの基本情報およびユーザの認証コンテキストが含まれます。デフォルトでは、Single Sign-Onは、非永続セッションによってセッション管理を実装します(エージェントはそのセッション チケットをユーザの Web ブラウザの Cookie に書き込みます)。永続ユーザ セッションを必要とするSingle Sign-On機能をサポートします。永続セッションに対してレルムを設定できます。このレルムのリソースを保護するエージェントはセッション チケットをSingle Sign-Onセッション ストアに書き込み、それにより認証ごとにセッション ストアに追加のリクエストが発生します。重要: 永続セッションはパフォーマンスに重大な影響を及ぼす場合があります。
- 認証イベント -- デフォルトでは、レルムは[認証イベントの処理]に設定されます。この設定によって、ユーザが認証するとき、または認証に失敗するときに起動するルールを定義できます。ポリシー評価ロジックは、認証イベントを処理するように設定されたすべてのレルムに適用されます。このロジックはシステム リソースを消費し、ユーザ ディレクトリ リクエストをもたらす場合があります。ユーザがリソースへのアクセスを取得するために認証する場合に発生するイベント アクションの必要性を評価します。認証アクションを必要としない場合は、レルムに対して認証イベントを無効にして、認証手順を促進します。
許可ガイドライン
通常、許可手順における
Single Sign-On
パフォーマンスは以下と相関します。- 許可リクエストの処理に使用されるシステム リソース。
- ポリシー サーバが許可リクエストを処理するために <stmndr> ユーザ ディレクトリに対して行う読み取り/書き込み(リクエストと総称される)の数。
Single Sign-On
ポリシー設計の複雑さは、これらの各領域に影響します。ポリシー オブジェクトおよびパフォーマンス
特定の <stmndr> ポリシー オブジェクトの設定方法によって、またはそれらのオブジェクトと関連付けられたオプション機能を有効にすることによって、認証のパフォーマンスを向上または低下させる場合があります。以下のポリシー オブジェクトは、ユーザの許可中にパフォーマンスに影響を与える場合があります。
ルールおよび許可パフォーマンス
以下の要因がルール(またはアプリケーション オブジェクト リソース)レベルでユーザ許可のパフォーマンスに影響します。
- 単一のレルム内の多数のルールによって許可決定が遅くなる場合があります。ユーザが特定のレルムに対して認証される場合、ポリシー サーバはレルム内のすべてのルールを評価して、ユーザがリクエストしている特定のリソース(URL)に一致するリソース フィルタを決定する必要があります。
- リソース フィルタのタイプは、ポリシー サーバがリソース一致を評価する速さに影響します。
以下のフィルタが、パフォーマンスに及ぼす影響が小さい順に一覧表示されます。
完全一致 -- 特定のリソースによるリソース フィルタの定義がパフォーマンスに及ぼす影響は最小です。ポリシー サーバは、リソース フィルタとリクエストされたリソースの URL との比較のみを行う必要があります。
例
: ある会社はカスタマ レルム(/customer)を作成し、ポータル アプリケーションの特定のページ(lending_home.html)でルールを指定します。この結果、リソース フィルタは/customer/lending_home.html です。リクエストされたリソースとルールの一致を評価するために必要なことは、ポリシー サーバがリクエストされたリソースをリソース フィルタと比較してそれが一致するかどうかを判断することのみです。- 完全なプレフィックス -- プレフィックスでリソース フィルタを定義すると、完全一致よりパォーマンスへの影響が大きくなります。ポリシー サーバは、リクエストされたリソースがリソースのルート(レルム)内に含まれているかどうかを判断する必要があります。例:ある会社は従業員レルム(/employee)を作成し、「*.html」でルールを指定します。* プレフィックスは、従業員レルムのすべての html ファイルが保護されることを指定します。この結果、リソース フィルタは /employee /*.html です。リクエストされたリソースとリソース フィルタの一致を評価するには、リクエストされたリソースが従業員ディレクトリの一部で、HTML ファイルであるかどうかをポリシー サーバが評価する必要があります。
- 正規表現 -- 正規表現によるリソース フィルタの定義はパフォーマンスに最大の影響を及ぼします。ポリシー サーバは式を評価し、その結果をリクエストされたリソースと比較する必要があります。式の複雑さはさらにパフォーマンスに影響します。
レスポンスおよび許可パフォーマンス
Single Sign-On
ポリシーのルールにバインドされたレスポンス属性のタイプは、パフォーマンスに影響します。以下のレスポンス タイプが、パフォーマンスに及ぼす影響が小さい順に一覧表示されます。- スタティック -- スタティック属性を定義すると、不変のデータを返します。
- ユーザ属性 -- ユーザ属性を定義すると、ユーザ ディレクトリのユーザのエントリからプロファイル情報を返します。注: このタイプのレスポンスには、ポリシー サーバによるユーザ ディレクトリの検索が必要です。
- DN 属性 -- DN 属性を定義すると、ユーザが関連するディレクトリ オブジェクトに関連付けられた情報を返します。ユーザが所属するグループ、およびユーザ DN の一部である組織単位(OU)は、属性を DN 属性として扱うことのできるディレクトリ オブジェクトの例です。注: このタイプのレスポンスには、ポリシー サーバによるユーザ ディレクトリの検索が必要です。
ポリシー メンバシップおよび許可パフォーマンス
ポリシー メンバシップは、ポリシーに適用されるユーザを指定する
Single Sign-On
ポリシーの一部です。<stmndr> ポリシーがドメインに格納されるため、フィルタを使用して、ドメインにバインドされたユーザ ディレクトリに格納されたいずれかまたはすべてのユーザに <stmndr> ポリシー メンバシップを適用します。定義するフィルタのタイプによって、ポリシー サーバが <stmndr> ポリシー メンバシップを評価する方法が決まります。以下のフィルタが、パフォーマンスに及ぼす影響が小さい順に一覧表示されます。
- すべて -- 「すべて」がパフォーマンスに及ぼす影響は最小です。Single Sign-Onがユーザを認証するときに、ポリシー サーバはセッション チケットを発行します。セッション チケットによって、ユーザが格納されているユーザ ディレクトリが識別されます。ポリシー サーバは、ポリシーがユーザに適用されることを判断するために、<stmndr> ポリシーにバインドされたディレクトリとセッション チケットの比較のみを行う必要があります。
- 識別名 -- 識別名(dn)は、「すべて」より大きな影響をパフォーマンスに及ぼします。認証されたユーザの dn を含む組織または組織単位は、セッション チケットに格納されます。ポリシー サーバはセッション チケット情報を <stmndr> ポリシー メンバシップ フィルタと比較して、ポリシーがユーザに適用されるかどうかを判断する必要があります。
- グループ メンバシップまたは検索式 -- これらのタイプのフィルタは、識別名より大きな影響をパフォーマンスに及ぼします。グループ メンバシップおよび検索式はシステム リソースをさらに消費し、ユーザ ディレクトリ検索をもたらします。ポリシー サーバは以下を実行する必要があります。
- グループ メンバシップまたは検索式を解決します。
- ユーザ ディレクトリを検索して、<stmndr> ポリシーがユーザに適用されるかどうかを判断します。
- ネストされたグループ -- ネストされたグループによる <stmndr> ポリシー メンバシップの定義はパフォーマンスに最大の影響を及ぼします。ポリシー サーバは、ディレクトリの各ユーザ グループおよびすべてのサブグループを検索して <stmndr> ポリシーがユーザに適用されるかどうかを判断する必要があります。重要: グループ階層が深いディレクトリは、ポリシー サーバがポリシー メンバシップを評価するためにかかる時間に著しい影響を及ぼす場合があります。
注
: ユーザ許可キャッシュを有効にして、ポリシー メンバシップを解決するためにポリシー サーバがユーザ ディレクトリに対して行うリクエスト数を減らすことができます。ユーザ許可キャッシュ
ユーザ許可キャッシュは、ユーザとポリシーの関係を格納することにより <stmndr> ポリシー メンバシップを判断するためのユーザ ディレクトリ リクエストの数を減らします。
注
: ユーザ許可キャッシュは、ユーザに関するデータおよびユーザ属性値を格納せず、ユーザ エントリのキャッシュも行いません。たとえば、3 つのポリシーが「管理者」グループ(ユーザ A が属する)に適用されるように設定されています。ポリシー サーバが最初に <stmndr> ポリシー メンバシップを評価するときに、各 <stmndr> ポリシーが適用されることを判断するために、グループ メンバシップを解決してユーザ ディレクトリに 3 つのリクエスト(ポリシーごとに 1 つ)を行う必要があります。
ポリシー サーバはこれらの結果をユーザ許可キャッシュに書き込みます。後続のポリシー評価では、ポリシー サーバがユーザ ディレクトリ リクエストを行う必要がありません。その代わりに、ポリシー サーバはキャッシュされた許可情報を使用して、ポリシー メンバシップを判断します。
注
: ポリシー サーバは、ポリシー更新に対して定期的にポーリングします。デフォルトの間隔は 60 秒です。ポリシー メンバシップが変更する場合、ポリシー サーバはポリシーを再ロードして、更新されたポリシーに関連するキャッシュ エントリを削除します。ユーザ許可キャッシュ効率
ユーザ許可キャッシュは次の場合に最も効果的です。
- セッション中のすべてのユーザ リクエストが、同じサーバに一貫して送信(持続)されます。
- すべての <stmndr> エージェントはラウンド ロビン ロード バランシングではなくポリシー サーバ フェールオーバに対して設定されます。
これらの要因に適合しない場合、ユーザ許可キャッシュの有効性は低下します。
例: ラウンド ロビン方式で負荷分散するように設定されたユーザ許可キャッシュおよびエージェント
<stmndr> エージェント ラウンド ロビン プール内のポリシー サーバが多いほど、ユーザ許可キャッシュの効率が下がる可能性が高くなります。
単一の <stmndr> エージェントが 2 つのポリシー サーバ間でラウンド ロビンするように設定されている場合、保護されたリソースへの最初のリクエストによっていずれかのポリシー サーバのユーザ許可キャッシュ エントリが生じます。キャッシュ エントリがないポリシー サーバが 2 番目のリクエストを処理する必要がある可能性は、約 50 パーセントです。ただし、両方のポリシー サーバは後のリクエスト用にデータをキャッシュしています。
では、10 のポリシー サーバ間でラウンド ロビンするように設定された単一のエージェントの影響について考えてみましょう。ポリシー サーバがユーザを許可して、その結果を許可キャッシュに入力した後、同じポリシー サーバが次のリクエストを処理する可能性は 10 パーセントのみです。この設定では、キャッシュ ヒットの可能性が 50 パーセントになる前に、必ずキャッシュ ミスが 5 回発生します。
注
: ポリシー サーバ クラスタは、ラウンドロビン ロード バランシングがユーザ許可キャッシュに対して持っている効果を低下させることがあります。ユーザ許可キャッシュのサイズの概算
ユーザ許可キャッシュのデフォルト サイズは 10 MB です。ユーザ許可キャッシュに必要な容量を概算し、ポリシー サーバ管理コンソールを使用してデフォルト サイズを調整できます。
ユーザ許可キャッシュのサイズを概算する方法
- 以下の式を使用してキャッシュ エントリの数を概算します。expected_users*number_of_policies_per_session = entries
- expected_usersSingle Sign-Onが保護しているアプリケーションに対して認証するユーザの総数を指定します。
- number_of_policies_per_sessionセッション中にユーザに適用される <stmndr> ポリシーの平均数を指定します。注:各ポリシーは、ユーザ許可キャッシュに一意のエントリを入力する可能性があります。
- エントリ許可によって作成できるキャッシュ エントリの数を指定します。
- 以下の式を使用してキャッシュのサイズを概算します。(エントリ* .000062) + 1注: .000062 は、MB でキャッシュ エントリの近似サイズを表します。
監査およびパフォーマンス
デフォルトでは、ポリシー サーバはポリシー サーバ ログと呼ばれるテキスト ファイルに監査イベントを書き込みます。オプションで、監査データベースにイベントをログ記録するようにポリシー サーバを設定できます。
イベントを監査データベースにログ記録する場合は、以下の要因を考慮してください。
- Single Sign-Onは認証および許可に関するすべての決定をデータベースに記録するので、認証および許可に関連するパフォーマンスが影響を受けます。
- (オプション)同期ログ記録 -- レルム レベルで同期ログ記録を設定できます。これを設定した場合、レコードが監査データベースに保存されるまで、ポリシー サーバは各認証および許可リクエストの結果を防止します。レコードが保存されるまで、ユーザは認証または許可されません。
アプリケーション層の負荷分散
さまざまなエージェント パラメータを調整したり
Single Sign-On
ポリシー設計ガイドラインに従っても、ポリシー サーバが認証および許可リクエストを処理するためにかかる時間はほとんど改善しません。複数のエージェントおよびポリシー サーバがある場合は、エージェントがすべてのポリシー サーバ間でリクエストを分散させるので、ダイナミック ロード バランシングによって遅延が軽減されてスループットが向上します。