許可 API の使用

目次
casso127jpjp
目次
2
Java 許可 API を使用すると、保護されたリソースへのアクセスを制御するためのカスタム機能を実装できます。
機能は、ポリシー サーバのアクティブな式で参照されるカスタム Java クラスによって提供されます。
アクティブな式
は、以下のポリシー サーバ オブジェクトに表示される、一連の変数定義です。
  • アクティブ ポリシー -- 外部のビジネス ロジックに基づいて動的な認可を提供するポリシー。
    たとえば、ユーザが LDAP ディレクトリ内で特定の組織ユニット(ou)に属する場合に true を返すカスタムの Java クラスを実装するとします。ou は、アクティブな式のパラメータ(
    param
    )フィールド内でカスタム Java クラスに返されます。
  • アクティブなレスポンス -- カスタム Java クラスから返されるレスポンス。アクティブ レスポンスの使用は、ユーザに固有の権限情報を定義できる 1 つの方法です。
    たとえば、ユーザがアクティブな式の[
    param
    ]フィールドに渡された ou に属する場合にユーザの共通名(cn)を返すアクティブなレスポンスを定義するとします。
  • アクティブ ルール
    --
    外部のビジネス ロジックに基づいて動的な認可を提供するルール。
    たとえば、レルムを参照する権限を持つディレクトリ管理者など、ユーザがグループのメンバである場合に true を返すカスタム Java クラスを定義するとします。グループ名がアクティブな式の[
    param
    ]フィールド内で Java クラスに渡されます。
アクティブな式
アクティブな式は以下の構文を使用して、管理 UI で作成されます。
<@ lib=
<lib-spec>
 func=
<func-spec>
 param=
<func-params>
@>
Java 許可 API に基づいたアクティブな式には以下の必須フィールドがあります。
  • lib
    には共有ライブラリ名 smjavaapi が含まれます。このライブラリは、
    param
    内のカスタム Java クラスを参照するすべてのアクティブな式と共に使用されます。
  • func
    には関数名 JavaActiveExpression が含まれます。この関数は smjavaapi ライブラリ用のエントリ ポイントです。
    param
    内のカスタム Java クラスを参照するすべてのアクティブな式と共に使用されます。
  • param
    には以下の情報が含まれます。
    • カスタム Java クラスの名前
    • オプションで、クラスのインスタンスに渡す任意のパラメータ
管理 UI でアクティブなポリシー、ルール、またはレスポンスを設定する場合にアクティブな式を定義します。
アクティブな式の実行
CA Single Sign-on
がカスタム Java クラスを参照するアクティブな式を検出した場合、以下のタスクを実行します。
  • 共有ライブラリおよびアクティブな式で指定されるカスタム Java クラスのインスタンスをロードします。
  • アクティブな式で指定されたライブラリ関数を呼び出します。
  • カスタム Java のインスタンスに、オプションのパラメータ文字列と以下のコンテキスト オブジェクトを渡します。
    • APIContext
    • RequestContext
    • UserContext
  • Java クラスのインスタンスはカスタム機能を実行し、
    CA Single Sign-on
    に結果を返します。結果がカスタム Java クラスの invoke() メソッドから返されます。
アクティブな式の結果の解釈
CA Single Sign-on
は、カスタム Java クラスのインスタンスによって返された結果を、Java クラスを参照するアクティブな式のタイプに基づいて以下のように解釈します。
  • アクティブなポリシー - 返される結果が空の文字列である場合または例外がスローされる場合、許可は拒否されます。
    返される結果が文字列(大文字と小文字は区別されません) FALSE、F、または 0 のいずれかに一致する場合、ポリシーは起動されません。
    ポリシーは他のどの結果によっても起動されます。
  • アクティブ ルール - 返される結果が空の文字列である場合または例外がスローされる場合、以下の動作が発生します。
    • アクセス許可ルールでは、ルールが起動しません。
    • アクセス拒否ルールでは、ルールが起動します。
    これ以外の場合は、動作はアクティブ ポリシーと同じです。
  • アクティブ レスポンス - 結果はレスポンス属性に対応する文字列です。
    CA Single Sign-on
    が結果文字列を解釈する方法は、管理 UI で指定されるレスポンス属性によって決定されます。以下に例を示します。
    • WebAgent-OnReject-Redirect。このレスポンス属性では、
      CA Single Sign-on
      は結果文字列が URL など、リソースへのアクセスを拒否されたユーザをリダイレクトする場所を指定することを想定します。
      (返される URL はカスタム Java クラスに渡される情報によって異なる場合があります。たとえば、グループ名はアクティブな式の
      param
      フィールドに渡される場合があります。この後、カスタム Java クラスはグループ名をテストして、返す URL を決定できます)。
    • WebAgent-HTTP-Cookie-Variable。このレスポンス属性では、
      CA Single Sign-on
      はユーザの共通名などの結果文字列が Cookie 変数に割り当てられることを想定します。結果文字列は、フォームのカスタマイズのためのユーザの共通名の表示など、望む方法で使用できます。
      CA Single Sign-on
      レスポンス属性エディタで Cookie 名を指定します。
    メソッドが失敗する場合(メソッドが -1 または 0 を返す場合)、レスポンス属性は無視されます。
ActiveExpression メソッド
Java 許可 API 内の基本インターフェースは ActiveExpression です。カスタム許可機能を提供する Java クラスはすべてこのインターフェースを実装する必要があります。
基本インターフェースから実装するクラスの名前は、任意の関連するアクティブな式の[
param
]フィールドに表示される必要があります。
Method
説明
init()
カスタム Java クラスが必要とするあらゆる初期化手順を実行します。
CA Single Sign-on
は、このメソッドをカスタム ActiveExpression クラスの各インスタンスにつき 1 回ずつ呼び出します。
invoke()
ActiveExpression オブジェクト内のカスタム許可機能を実行し、結果を返します。
release()
ActiveExpression オブジェクトが必要とする任意の要約手順を実行します。のシャットダウン中、
CA Single Sign-on
CA Single Sign-on
は ActiveExpression クラスの各インスタンスに対してこのメソッドを 1 回ずつ呼び出します。
注:
ActiveExpression を実装するクラスは、ActiveExpression クラスのメンバ変数に保存されたインスタンスのステートに依存しないステートレス モデル上で実装される必要があります。
許可 API 内の他のクラス
クラス
説明
ActiveExpressionContext
invoke() に渡される以下のコンテキスト クラスが含まれます。
APIContext
RequestContext
UserContext
RequestContext
たとえば、要求のサーバまたはリソース部分など、ユーザのアクセスの要求に関する情報を提供します。
SAML アサーションまたはレスポンスの変更
SAML 仕様に基づき、アサーション(SAML 1.x)またはレスポンス(SAML 2.0)はプロデューサ サイトで生成され、検証のためにコンシューマ サイトへ送られます。通常、
CA Single Sign-on
がプロデューサ サイトで生成するデフォルトの SAML アサーションまたはレスポンスを使用します。アサーションまたはレスポンスのコンテンツを変更する場合、Java アサーション ジェネレータ プラグインを実装することで実行できます。このプラグインは、コンシューマ(SAML 1.x)およびサービス プロバイダ(SAML 2.0)の両方に適しています。
SAML アサーションまたはレスポンスを変更する方法
  1. Java SAML アサーション ジェネレータ プラグインを実装します。
    実装は、Assertion Generator Framework 用のプラグインです。Assertion Generator Framework はカスタム プラグイン オブジェクトにデフォルト トークンを送信します。処理の後、カスタム オブジェクトは変更されたトークンを Assertion Generator Framework に渡します。
  2. プラグイン クラスの完全修飾名およびプラグインが必要とする可能性のある任意のオプションのパラメータを指定することでプラグインを設定します。以下のいずれかの方法でカスタム アサーション ジェネレータ プラグインを設定します。
    • 管理 UI の使用
    • C または Perl ポリシー管理 API を使用。
注:
アサーション ジェネレータ プラグインの設定は、バージョン v6.0 SP 2 以降のポリシー管理 API セッションを必要とします。
ポリシー サーバとアサーション ジェネレータ間の相互作用
以下の手順では、ポリシー サーバとカスタム アサーション ジェネレータ プラグインの相互作用の概要について説明します。アクティビティは、許可されたユーザがポリシー サーバを通して、アサーションを使用するサイトでのリソースに対する要求を作成する場合に開始されます。
  1. 認定ユーザは、コンシューマまたはサービス プロバイダに対して SAML アサーションまたはレスポンスを必要とします。
  2. Assertion Generator Framework はデフォルトの SAML アサーションまたはレスポンスを生成します。
  3. アサーション ジェネレータ プラグインがアサーションを使用するサイトに対して定義される場合、Assertion Generator Framework はプラグイン キャッシュからプラグイン オブジェクトのインスタンスを要求します。
    注:
    アサーションを消費するサイトに定義できるアサーション ジェネレータ プラグインは 1 つのみです。
  4. プラグインがキャッシュにまだロードされていない場合、以下が実行されます。
    1. CA Single Sign-on
      はプラグイン クラスをインスタンス化し、キャッシュにそれをロードします。
    2. CA Single Sign-on
      はプラグインの init() メソッドを呼び出します。このメソッドは、プラグインに対して実装したあらゆる初期化手順を実行します。
    正常に初期化されたプラグイン オブジェクトは、
    CA Single Sign-on
    がシャットダウンするまでキャッシュに残ります。これにより、プラグインが要求されるたびにオブジェクトを再ロードおよび再初期化する必要がなくなります。
  5. Assertion Generator Framework は、手順 2 で生成されたデフォルトの XML トークンをプラグインの customizeAssertion() メソッドに渡します。
  6. プラグインは、情報を必要とされたとおりに検証または修正し、処理されたアサーションを Assertion Generator Framework に返します。
  7. Assertion Generator Framework は処理されたトークンをコンシューマまたはサービス プロバイダへ渡します。このサイトは、ユーザの要求に応答する方法を決定するのにアサーション内の情報を使用します。
  8. ユーザがサービス プロバイダに対するアサーションを要求する場合は常に手順が繰り返されます。
CA Single Sign-on
がシャットダウンする直前に、
CA Single Sign-on
はプラグインの release() メソッドを呼び出して必要な要約アクティビティを実行します。
開発と展開の注意点
カスタムの アサーション ジェネレータ プラグインを開発および展開する場合、以下の点を念頭に置いてください。
  • 実装されたプラグイン クラスは、パラメータのないパブリック デフォルト コンストラクタ メソッドを提供する必要があります。
  • 実装はステートレスである必要があります。つまり、単一のプラグイン インスタンスを同時に複数のスレッドに使用できる必要があります。
  • 構文の要件および customizeAssertion() メソッドに渡されるパラメータ文字列の使用はカスタム オブジェクトの責任です。
  • カスタム オブジェクトは、customizeAssertion() に渡されるデフォルトのアサーションを、たとえば Document Object Module (DOM) パーサまたは Simple API for XML (SAX) パーサを使用して解析する必要があります。サンプル プラグイン クラス AssertionSample.java は DOM パーサを使用します。
  • 展開したプラグイン クラスを
    CA Single Sign-on
    が見つけられるようにするには、設定ファイル JVMOptions.txt の -Djava.class.path に展開場所を指定します。このファイルは、
    CA Single Sign-on
    のインストールされたディレクトリ構造
    install_path
    \siteminder\config に置かれています。
  • アサーション プラグイン クラスのサンプルについては、AssertionSample.java (
    CA Single Sign-on
    がインストールされたディレクトリ構造
    install_path
    \sdk\samples\assertiongeneratorplugin)を参照してください。これは、SAML 1.x アサーションに対するプラグイン プロセスを示します。同じディレクトリ内に、Assertion Generator Plugin for SAML 2.0、SAML2AppAttrPlugin.java、および WS-Federation、WSFedAppAttrPlugin.java のサンプルが置かれています。