|
| |
| Sun Java™ System Identity Manager 7.1 配備ツール | |
第 7 章
Identity Manager Web サービスでの SPML 1.0 の使用この章では、Identity Manager および Identity Manager Service Provider Edition でサポートされる SPML 1.0 について説明しています。これには、サポートされる機能とその理由、SPML 1.0 サポートの設定方法、フィールドでのサポートの拡張方法が含まれます。
説明する内容は次のとおりです。
注
この章では、SPML 1.0 のみを扱います。
特に明記されていないかぎり、この章での SPML への参照はすべて version 1.0 を示しています。ここで説明されている概念は、第 8 章「Identity Manager Web サービスでの SPML 2.0 の使用」で、SPML 2.0 についての説明を参照するときにも役立ちます。
この章の対象読者アプリケーション開発者および Identity Manager の統合を担当する開発者は、この章で説明されている SPML 1.0 クラスを使用して、サービスプロビジョニング要求メッセージをフォーマットしたり、応答メッセージを解析したりすることができます。
Identity Manager Web サービスインタフェースの操作Identity Manager Web サービスは、HTTP 用の SOAP メッセージを使用してアクセスされます。Identity Manager は、プロビジョニングシステムとの通信のための OASIS 標準である Service Provisioning Markup Language (SPML) の両方のバージョン、つまり、version 1.0 および 2.0 をサポートしています。
SPML 1.0 は、サービスプロビジョニングアクティビティーにオープンインタフェースを提供するための OASIS 標準です。SPML 1.0 は、独立系ソフトウェアベンダーによって支持されています。
注
Identity Manager Web インタフェースの操作で最高のパフォーマンスを得るには、Identity Manager にバンドルされている OpenSPML ツールキットを使用してください。http://www.openspml.org/ Web サイトにある openspml.jar ファイルを使用すると、メモリーリークが発生する可能性があります。
SPML の設定SPML インタフェースを公開するには、Identity Manager サーバーを正しく設定する必要があります。特定のリポジトリオブジェクトをインストールして変更し、waveset.properties ファイルを編集する必要があります。
リポジトリオブジェクトのインストールと変更
表 7-1 は、Identity Manager の SPML を設定するためにインストールして変更する必要のあるリポジトリオブジェクトを示しています。
Identity Manager は、sample/spml.xml ファイルで、SPML 設定オブジェクトのサンプルのセットを提供しています。このファイルは、リポジトリの初期化時にデフォルトではインポートされないので、手動でインポートする必要があります。
このサンプル設定では、SPML ワーキンググループによって定義され、作成中の標準スキーマ person という名前のクラスを定義しています。このワーキンググループは、まだ標準のユーザースキーマを公開していませんが、それはほぼ間違いなく、一般的な LDAP inetorgperson スキーマに基づくものになります。
waveset.properties ファイルの編集
表 7-2 は、SPML 要求の承認方法を制御するために使用できる、waveset.properties ファイル内の 3 つのオプションのエントリを示しています。
soap.epassword および soap.password プロパティーの編集
soap.username で指定されたユーザーは、プロキシユーザーと呼ばれます。プロキシユーザーを定義する場合は soap.username を設定する必要がありますが、設定する必要があるのは 2 つのパスワードエントリのいずれかのみです。soap.password の使用がもっとも簡単ですが、この方法では、プロパティーファイル内にクリアテキストパスワードが公開されます。soap.epassword の使用の方が安全ですが、暗号化パスワードの生成に追加の手順が必要になります。
プロキシユーザーには Web サービスを使用するための認証が必要ないため、プロキシユーザーの確立はクライアントにとって便利です。これは、Identity Manager サーバーが、ユーザーの認証を自身で処理する別のアプリケーションからのみアクセスされるポータル環境では、一般的な設定です。
警告
サーバーが応答している HTTP ポートが一般にアクセス可能な場合、これは危険な設定になります。Identity Manager サーバーの URL を知っていて、SPML 要求を作成する方法を理解しているユーザーの場合、プロキシユーザーが実行できる任意の Identity Manager 操作を実行できます。
SPML 標準では、認証や承認を実行する方法が指定されていません。認証に関連する Web 標準規格はいくつか存在しますが、これらの標準が広範囲に使用されることは当面ありません。おそらく、認証に対するもっとも一般的な当面のアプローチは、アプリケーションとサーバーの間での SSL の使用に依存することです。SSL の設定方法を Identity Manager で要求することはできません。
プロキシユーザーも SSL も使用できない場合、Identity Manager では、クライアントがログインしたあとも以降の要求の認証に使用されるセッショントークンを維持できるようにする、SPML に対するベンダー固有の拡張がサポートされています。これを行うためのもっとも簡単な方法は、資格の指定、ログイン要求の実行、およびすべての SPML 要求内のセッショントークンの引き渡しをサポートする、SpmlClient クラスの拡張である LighthouseClient クラスを使用することです。
暗号化パスワードの取得
暗号化パスワードを取得するための 1 つの方法は、Identity Manager コンソールでの encrypt コマンドの使用です。別の方法は、「デバッグ」ページまたはコンソールから、XML のプロキシユーザーを表示することです。password 属性の値に対する WSUser 要素を調べます。この値を soap.epassword プロパティーの値として使用できます。
設定オブジェクトの編集
アプリケーションには、SPML メッセージを送信したり、SPML 応答を受信したりするためのメカニズムが必要です。
Identity Manager で SPML を設定するには、次の設定オブジェクトを操作する必要があります。
設定の編集: SPML
SPML オブジェクトには、公開する SPML スキーマの定義と、これらの SPML スキーマが Identity Manager ビューにマップされる方法に関する情報が含まれています。この情報は、設定オブジェクトの拡張として格納されている GenericObject を使用して表されます。
この GenericObject で定義される属性には、schemas と classes の 2 つがあります。
- schemas: 各文字列に 1 つの SPML <schema> 要素のエスケープされた XML が含まれている、文字列のリスト。SPML 要素は waveset.dtd では定義されていないため、Identity Manager XML ドキュメントに直接含めることはできません。代わりに、エスケープされたテキストとして含める必要があります。
- Classes: サポートされている SPML クラスと、これらのクラスがビューにマップされる方法に関する情報を含むオブジェクトのリスト。このリストには、SPML スキーマの schemas リストで定義されているクラスごとに 1 つのオブジェクトが存在すべきです。
最初は、この 2 つのリストの区別がわかりにくいかもしれません。schemas リストに関する情報は、Identity Manager が SPML SchemaRequest メッセージに応答して何を返すかを定義します。クライアントがこの情報を使用すると、AddRequest などの、ほかのメッセージに含まれている可能性のある属性を理解できます。Identity Manager は、schemas リストの内容には関知しません。このリストは、単純にそのままクライアントに返されます。
SPML スキーマの定義は必須ではありません。Identity Manager は、スキーマがなくても機能します。SPML スキーマが定義されていない場合、Identity Manager は、スキーマ要求メッセージを受信すると空の応答を返します。スキーマがない場合、クライアントは、サポートされているクラスや属性についての既存の知識に依存する必要があります。これが一般的な状況ですが、それでもなお、要求の作成には OpenSPML Browser などの汎用のツールを使用できるように、SPML スキーマを記述することが良い方法であると考えられています。
デフォルトの SPML 設定
コード例 7-1 は、デフォルトの SPML 設定を示しています。簡潔にするために、SPML スキーマ定義のテキストは省略しています。
この例では、標準の person と、request という名前の Identity Manager 拡張の 2 つのクラスが定義されています。クラス定義では、次の属性がサポートされています。
- name: クラスの名前を特定します。この値は、SPML スキーマ内の <ObjectClassDefinition> 要素に対応している場合がありますが、これは必須ではありません。この名前は、追加要求または検索要求での objectclass 属性の値として使用されます。
- type: このクラスのインスタンスの管理に使用される Identity Manager のビュータイプを定義します。通常は、Userですが、ビューを介してアクセスできる任意のリポジトリタイプにすることができます。ビューについては、『Sun JavaTM System Identity Manager ワークフロー、フォーム、およびビュー』を参照してください。
- form: フォームを含む設定オブジェクトの名前を特定します。このフォームには、このクラスで定義される外部の属性と内部のビュー属性の間での、変換のための規則が含まれています。
- default: true に設定されている場合は、これがこのタイプのみのデフォルトクラスであることを示します。同じタイプに対して複数の SPML クラスが実装されている場合は、その 1 つをデフォルトとして指定するようにしてください。
- identifier: 各クラスは一般に、そのオブジェクトのアイデンティティーと見なされる 1 つの属性を定義します。可能な場合は、この属性の値が、そのインスタンスを表すために作成する対応したリポジトリオブジェクトの名前として使用されます。クラス定義内の identifier 属性は、どの属性がアイデンティティーを表すかを指定します。
- filter: SPML 検索要求がクラスに対して評価される場合は、一般に、そのクラスに関連付けられたすべてのリポジトリオブジェクトをその検索に含めます。これはユーザーオブジェクトについては問題ありませんが、一部のクラスは、TaskDefinition や Configuration などの、必ずしも SPML クラスのインスタンスとは見なされない、汎用的なタイプを使用して実装される可能性があります。
デフォルトのスキーマ
schemas 属性には、SPML <schema> 要素のエスケープされた XML を含む文字列のリストが含まれています。spml.xml ファイルを調べてみると、schema 要素が、CDATA でマークされたセクションで囲まれていることに気付きます。XML の長い文字列のエスケープには、この方法のほうが便利です。これを正規化すると、< 文字エンティティーを含む文字列に変換されます。
デフォルト設定には、次の 2 つのスキーマが含まれます。
設定の編集: SPMLPerson オブジェクト
Configuration:SPML で定義されている各クラスには一般に、そのクラスで定義された外部の属性モデルと、関連付けられたビューで定義された内部のモデルの間での、変換の規則を含むフォームオブジェクトが関連付けられています。
標準の person クラスは、次のフォーム (コード例 7-2) を参照します。
コード例 7-2 標準の Person クラスでのフォームの参照
<Configuration name='SPMLPerson'>
<Extension>
<Form><Field name='cn'>
<Derivation><ref>global.fullname</ref></Derivation>
</Field>
<Field name='global.fullname'>
<Expansion><ref>cn</ref></Expansion>
</Field><Field name='email'>
<Derivation><ref>global.email</ref></Derivation>
</Field>
<Field name='global.email'>
<Expansion><ref>email</ref></Expansion>
</Field><Field name='description'>
<Derivation>
<ref>accounts[Lighthouse].description</ref>
</Derivation>
</Field>
<Field name='accounts[Lighthouse].description'>
<Expansion><ref>description</ref></Expansion>
</Field><Field name='password'>
<Derivation><ref>password.password</ref></Derivation>
</Field>
<Field name='password.password'>
<Expansion><ref>password</ref></Expansion>
</Field><Field name='sn'>
<Derivation><ref>global.lastname</ref></Derivation>
</Field>
<Field name='global.lastname'>
<Expansion><ref>sn</ref></Expansion>
</Field><Field name='gn'>
<Derivation><ref>global.firstname</ref></Derivation>
</Field>
<Field name='global.firstname'>
<Expansion><ref>gn</ref></Expansion>
</Field><Field name='telephone'>
<Derivation>
<ref>accounts[Lighthouse].telephone</ref>
</Derivation>
</Field>
<Field name='accounts[Lighthouse].telephone'>
<Expansion><ref>telephone</ref></Expansion>
</Field></Form>
</Extension>
</Configuration>
クラス定義内の属性ごとに、1 対のフィールド定義が存在します。1 つのフィールドは <Derivation> 式を使用して、内部のビュー属性 name を外部名に変換します。1 つのフィールドは <Expansion> 式を使用して、外部名を内部名に変換します。
このフォームは、属性がクライアントに返されるときは、<Derivation> 式の結果のみが含まれるという方法で処理されます。属性がクライアントからサーバーに送信されると、<Expansion> 式の結果のみがビューに反映されます。この効果は、リソース定義のスキーママップに似ています。
設定の編集: ユーザー拡張属性オブジェクト
SPML 検索フィルタで使用する任意の属性を、Identity Manager ユーザーの拡張属性として定義する必要があります。これにより、その属性の値は、同時にリソースアカウント属性として格納される場合でも、Identity Manager リポジトリ内に格納されるようになります。拡張属性によって、リポジトリのサイズが増加するだけでなく、Identity Manager 内に格納された属性とリソース上に格納された属性の実際の値の間で、一貫性の問題が発生する可能性も増加するため、一般には、拡張属性の数は最小限に抑えるようにしてください。ただし、Identity Manager クエリーで使用される属性の場合は、リポジトリのクエリーインデックスが作成されたときにその値が常にアクセス可能になるように、拡張属性として宣言する必要があります。
ユーザーのための概要の属性の設定に含める任意の属性を、「拡張属性」として定義する必要があります。概要の属性を使用すると、オブジェクト XML のデシリアライズを回避することによって検索を最適化し、代わりにユーザーのもっとも重要な属性のいくつかだけを返すことができます。Identity Manager SPML の実装では、返される属性のリストを検索要求で明示的に指定しない場合は常に、概要の属性が返されます。
デフォルトの SPML 設定では、標準の person スキーマの属性 telephone と description が拡張属性として宣言されます。
コード例 7-3 拡張属性として宣言された telephone と description
<Configuration id='#ID#Configuration:UserExtendedAttributes' name='User Extended Attributes'>
<Extension>
<List>
<!-- これは標準のセットである -->
<String>firstname</String>
<String>lastname</String>
<String>fullname</String>
<!-- これらは、SPML の拡張である -->
<String>description</String>
<String>telephone</String>
</List>
</Extension>
</Configuration>
属性のリストは、サイトのニーズに応じてカスタマイズできます。
拡張属性として選択する名前は、クラスフォームで実行されるマッピングによって異なります。デフォルトの SPMLPerson フォームによって sn が lastname にマップされるため、拡張属性を lastname として宣言する必要があります。このフォームでは telephone または description の名前は変換されないため、拡張属性の名前は SPML スキーマから直接採用されます。
拡張属性を宣言するだけでなく、Configuration:UserUIConfig オブジェクトも変更して、どの属性をクエリー可能 (つまり、SPML フィルタで使用可能) にし、どの属性を (最適化された検索の結果によって返される) 概要の属性にするかを宣言する必要があります。
設定の編集: UserUIConfig オブジェクト
次の属性を宣言する必要があります。
コード例 7-4 は、拡張属性 telephone をクエリー可能な概要の属性として定義しています。また、firstname と lastname の宣言も含まれていますが、これらは通常、すでに宣言されています。これらのリストは、サイトのニーズに応じてカスタマイズできます。
コード例 7-4 クエリー可能な概要の属性として定義された telephone
<Object>
<Attribute name='add'>
<Object>
<Attribute name='SummaryAttrNames'>
<List>
<!-- これらは通常ここに存在するが、確認すること -->
<String>firstname</String>
<String>lastname</String>
<!-- これは SPML の追加である -->
<String>telephone</String>
</List>
</Attribute>
<Attribute name='QueryableAttrNames'>
<List>
<!-- これらは通常ここに存在するが、確認すること -->
<String>firstname</String>
<String>lastname</String>
<!-- これは SPML の追加である -->
<String>telephone</String>
</List>
</Attribute>
</Object>
</Attribute>
</Object>
TaskDefinition の編集: SPMLRequest オブジェクト
spml.xml ファイルにもまた、SpmlRequest という名前の新しいシステムタスクの簡単な定義が含まれています。このタスクは、非同期 SPML 要求を実装するために使用されます。サーバーが非同期要求を受信すると、このタスクの新しいインスタンスが起動され、その SPML メッセージがタスクへの入力変数として渡されます。このタスクインスタンスのリポジトリ ID は、あとの状態要求に対する SPML 応答で返されます。
<TaskDefinition name='SPMLRequest'
executor='com.waveset.rpc.SpmlExecutor'
execMode='asyncImmediate'
resultLimit='86400'>
</TaskDefinition>
定義の名前、executor の名前、および実行モードは変更しないでください。ただし、resultLimit の値は変更することができます。非同期要求が完了すると、クライアントが結果を取得するための SPML 状態要求を発行できるように、その結果は通常、一定期間保持されます。結果が保持される期間は、サイト固有の値です。
値が負でない場合は、resultLimit によって、タスクが完了したあとにシステムに結果が保持される時間 (秒単位) が指定されます。SPMLRequests のデフォルト値は通常、3600 秒 (約 1 時間) です。ほかのタスクは、そのタスクが別の値に変更されないかぎり、デフォルトで 0 秒になります。
負の場合、その要求インスタンスは自動的には削除されません。
配備記述子
Identity Manager の配備記述子 (通常、ファイル Web-INF/web.xml に含まれている) には、SOAP メッセージを受信するサーブレットの宣言が含まれている必要があります。
SPML Web サービスへの接続で問題が発生している場合は、web.xml ファイル内にある、コード例 7-5 に示すようなサーブレット宣言を探してください。
コード例 7-5 サーブレット宣言
<servlet>
<servlet-name>rpcrouter2</servlet-name>
<display-name>OpenSPML SOAP Router</display-name>
<description>no description</description>
<servlet-class>
org.openspml.server.SOAPRouter
</servlet-class>
<init-param>
<param-name>handlers</param-name>
<param-value>com.waveset.rpc.SimpleRpcHandler</param-value>
</init-param>
<init-param>
<param-name>spmlHandler</param-name>
<param-value>com.waveset.rpc.SpmlHandler</param-value>
</init-param>
<init-param>
<param-name>rpcHandler</param-name>
<param-value>com.waveset.rpc.RemoteSessionHandler</param-value>
</init-param>
</servlet>
この宣言を使用すると、次の URL を介して addRequest、modifyRequest、および searchRequest Web サービスにアクセスできます。
http://<host>:<port>/idm/servlet/rpcrouter2
<servlet-mapping> を定義する必要はありません (ただし、定義することは可能)。このサーブレット宣言の内容を変更しないでください。
要求の処理方法についてここでは、Identity Manager での SPML 要求の処理方法の一般的な概要について説明します。
追加要求の処理方法
次の手順は、追加要求の処理方法について説明しています。
変更要求の処理方法
次の手順は、変更要求の処理方法について説明しています。
- SPML <modifyRequest> メッセージが受信されます。この要求には、オプションの objectclass 属性が含まれている場合があります。この要求には、既存のオブジェクトの識別子が含まれている必要があります。この識別子には、リポジトリタイプとオブジェクト名の両方が含まれている必要があります。
- サーバーは、既存のオブジェクトの Session.checkoutView を呼び出します。
- サーバーは、Configuration:SPML オブジェクトを検査してクラスの定義を見つけます。要求で objectclass 属性が渡された場合は、その値によってクラスが決定されます。それ以外の場合は、リポジトリタイプのデフォルトクラスとしてマークされたクラスが使用されます。
- その要求に含まれている属性が、クラス定義で指定されたフォームによって処理されます。<Expansion> 式の結果がビューに反映されます。
- このビューがチェックインされます。
検索要求の処理方法
次の手順は、検索要求の処理方法について説明しています。
- SPML <searchRequest> メッセージが受信されます。この要求には、オプションの objectclass 属性が含まれている場合があります。
- サーバーは、Configuration:SPML オブジェクトを検査してクラスの定義を見つけます。要求で objectclass 属性が渡された場合は、その値によってクラスが決定されます。それ以外の場合は、ユーザータイプのデフォルトクラスとしてマークされたクラスが使用されます。
- この要求にフィルタが含まれている場合、そのフィルタは AttributeCondition オブジェクトのリストに変換されます。フィルタの用語は外部名を使用して記述されているため、これらの名前を、リポジトリタイプに対してクエリー可能な属性の名前に変換するためにクラスフォームが参照されます。
- サーバーは、リポジトリタイプとオプションの条件を使用して Session.listObjects メソッドを呼び出します。
- サーバーは、次の手順を適用しながら、listObjects 呼び出しの各行に対して処理を繰り返すことによって、検索応答を作成します。
- 返される属性のリストが検索で指定されていない場合は、リポジトリタイプに対して定義された概要の属性のみが返されます。概要の属性の内部名を外部名に変換するために、クラスフォームが使用されます。
- 返される属性のリストが指定されていて、これらがすべて概要の属性に対応している場合は、概要の属性の値が返されます。ここでも、内部名を外部名に変換するために、フォームが使用されます。
- 概要の属性ではない、返される属性が指定されている場合、サーバーは、このオブジェクトに対して Session.getView を呼び出してビューを生成します。このビューがクラスフォームを使用して処理されたあと、<Derivation> 式の結果が取得され、その行の結果として返されます。
Identity Manager は、最初、タイプに対して定義された概要の属性のみを使用して、検索要求を満たそうとします。その結果、特にフィルタが指定されておらず、結果に多数のオブジェクトが含まれる場合、検索がはるかに高速になります。検索を実行するためにビューをインスタンス化する必要がある場合は、検索の速度が大幅に低下するため、結果を少数のオブジェクトに制限するためのフィルタを指定する場合にのみ、検索を実行するようにしてください。
オブジェクトのアイデンティティーがわかっていて、フィルタ式を記述することなくその属性を取得したい場合は、検索要求でそのアイデンティティーを baseContext の値として使用します。これによって、Identity Manager がクエリーを回避してビューを作成するだけで済むため、検索が高速になります。
返される属性を指定しない場合は、概要の属性のみが返されます。そのため、すべての属性が必要な場合は、返される属性のリストにそれらの属性を明示的に含める必要があります。使用可能なすべての属性を要求することが一般的な操作であるため、これは多少不便です。属性の完全なリストを指定する代わりの方法として、Identity Manager は、結果を生成するためにオブジェクトビューを完全にインスタンス化し、クラスフォームを使用して処理すべきであることを示す、view という名前の 1 つの返される属性を認識します。
また、属性のレベル (accounts[Lighthouse] または accountinfo など) を指定することもできます。レベルを指定した場合、Identity Manager は、完全にインスタンス化されたビューの、そのレベルの適用範囲内にあるすべての属性値を返します。
SPML ブラウザの起動OpenSPML Browser アプリケーションを使用して Identity Manager SPML 設定をテストできます。
コマンド行からブラウザを起動するには、次のコマンドを入力します。
lh spml
Identity Manager サーバーへの接続Identity Manager サーバーに接続するには、「接続」ページを開き、Identity Manager サーバーの URL を入力します。たとえば、サーバーがローカルマシンのポート 8080 上で実行されている場合、URL は次のようになります。
http://localhost:8080/idm/servlet/rpcrouter2
ここで、localhost は Identity Manager を実行しているマシンです。
SPML 設定のテストとトラブルシューティングSPML 設定をテストするには、次の手順に従います。
正常な接続を確立できない場合は、次の操作を行います。
- 入力した URL を二重にチェックします。
- 受信したエラーに「応答なし」や「接続が拒否されました」などの語句が含まれている場合、問題としてもっとも可能性が高いのは、接続 URL で使用されているホストまたはポートです。
- エラーによって、接続は確立されたが、Web アプリケーションまたはサーブレットが見つからなかったことが示されている場合、問題としてもっとも可能性の高いのは、Web-INF/web.xml ファイルです。詳細については、「配備記述子」を参照してください。
SPML アプリケーションの開発サーバーを設定したら、アプリケーションには、SPML メッセージを送信したり、SPML 応答を受信したりするメカニズムが必要になります。Java アプリケーションの場合、これを行うためのもっとも簡単な方法は OpenSPML ツールキットの使用です。このツールキットは www.openspml.org から入手でき、Identity Manager にもバンドルされています。
このツールキットでは、次のコンポーネントが提供されます。
表 7-3 は、このツールキットで提供される、もっとも重要なクラスの概要を示しています。要求の種類ごとに、対応するクラスが存在します。詳細については、ツールキットとともに配布されている JavaDoc を参照してください。
表 7-3 OpenSPML ツールキットで提供されるクラス
クラス
説明
AddRequest
新しいオブジェクトの作成を要求するメッセージを作成します。
作成するオブジェクトのタイプは、objectclass という名前の属性を渡すことによって定義されます。渡されるほかの属性は、このオブジェクトクラスに関連付けられたスキーマに従っているべきです。SPML では、標準スキーマがまだ定義されていません。必要な任意のスキーマをサポートするように Identity Manager を設定できます。ModifyRequest
既存のオブジェクトの変更を要求するメッセージを作成します。この要求には、変更する属性のみを含める必要があります。要求に含まれていない属性は、現在の値を維持します。
DeleteRequest
オブジェクトの削除を要求するメッセージを作成します。
SearchRequest
特定の条件に一致する、オブジェクトの属性を要求するメッセージを作成します。
BatchRequest
複数の SPML 要求を含むことができるメッセージを作成します。
CancelRequest
以前の非同期に実行された要求を取り消すメッセージを作成します。
SchemaRequest
サーバーでサポートされている、SPML オブジェクトクラスに関する情報を要求するメッセージを作成します。
StatusRequest
以前の非同期に実行された要求のステータスを要求するメッセージを作成します。
SpmlResponse
サーバーから送り返された応答メッセージを表す、オブジェクトの基底クラス。各要求クラスには、対応する応答クラス (たとえば、AddResponse や ModifyResponse) があります。
SpmlClient
SPML メッセージを送受信するための単純なインタフェースを提供します。
注
SPE REF キットには、SPE SPML インタフェースの使用方法を実演する SpmlUsage.java ファイルが含まれています。この REF キットには SpmlUsage クラスをコンパイルする ant スクリプトも含まれています。
使用方法:
java [ -Dtrace=true ] com.sun.idm.idmx.example.SpmlUsage [ URL ]
ここで URL は SPE SPML インタフェースをポイントしており、デフォルトでは次のようになります。
http://localhost:8080/idm/spespml
SPE のトレースを有効にすると、すべての SPE SPML メッセージが標準出力に出力されます。
ExtendedRequest の例
表 7-4 は、クライアントでメッセージを送受信するために使用される ExtendedRequest クラスを示しています。
表 7-4 メッセージを送受信するための ExtendedRequest クラス
ExtendedRequest
説明
deleteUser
ユーザーの削除を要求するメッセージを作成します。
disableUser
ユーザーの無効化を要求するメッセージを作成します。
enableUser
ユーザーの有効化を要求するメッセージを作成します。
resetUserPassword
ユーザーパスワードのリセットを要求するメッセージを作成します。
changeUserPassword
ユーザーパスワードの変更を要求するメッセージを作成します。
launchProcess
プロセスの起動を要求するメッセージを作成します。
listResourceobjects
Identity Manager リポジトリ内のリソースオブジェクトの名前と、そのリソースでサポートされているオブジェクトのタイプを要求するメッセージを作成します。この要求では、名前のリストが返されます。
runForm
Identity Manager Session API を呼び出すことによって取得される情報を返す、カスタム SPML 要求を作成できるようにします。
サーバーコードは、これらの拡張要求をビュー操作に変換します。
サンプルの拡張要求
拡張要求は通常、コード例 7-6 に示す形式を取ります。
コード例 7-6 拡張要求の形式
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("changeUserPassword");
req.setAttribute("accountId", "jlarson");
req.setAttribute("password", "xyzzy");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
ほとんどの SPML 拡張要求は、次の引数を取ります。
accounts 属性を渡さない場合は、この操作によって、そのユーザーにリンクされたすべてのリソースアカウント (そのユーザー自身を含む) が更新されます。accounts を渡す場合は、この操作によって、指定したリソースのみが更新されます。特定のリソースアカウントに加えて Identity Manager ユーザーを更新する場合は、null 以外のアカウントリストに Lighthouse を含める必要があります。
deleteUser
コード例 7-7 は、disableUser 要求の標準的な形式を示しています。
(ビュー − 「プロビジョン解除」ビュー)。
コード例 7-7 deleteUser 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("deleteUser");
req.setAttribute("accountId", "jlarson");
req.setAttribute("accounts", "xyzzy");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
disableUser
コード例 7-8 は、disableUser 要求の標準的な形式を示しています。
(ビュー − 「無効化」ビュー)。
コード例 7-8 disableUser 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("disableUser");
req.setAttribute("accountId", "jlarson");
req.setAttribute("accounts", "xyzzy");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
enableUser
コード例 7-9 は、enableUser 要求の標準的な形式を示しています。
(ビュー − 「有効化」ビュー)。
コード例 7-9 enableUser 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("enableUser");
req.setAttribute("accountId", "jlarson");
req.setAttribute("accounts", "xyzzy");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
resetUserPassword
コード例 7-10 は、resetUser 要求の標準的な形式を示しています。
(ビュー − 「ユーザーパスワードのリセット」ビュー)。
コード例 7-10 resetUser 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("resetUserPassword");
req.setAttribute("accountId", "jlarson");
req.setAttribute("accounts", "xyzzy");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
changeUserPassword
コード例 7-11 は、changeUserPassword 要求の標準的な形式を示しています。
(ビュー − 「ユーザーパスワードの変更」ビュー)。
コード例 7-11 changeUserPassword 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("changeUserPassword");
req.setAttribute("accountId", "jlarson");
req.setAttribute("password", "xyzzy");
req.setAttribute("accounts","Lighthouse,LDAP,RACF");
ExtendedResponse res = (ExtendedResponse) client.send(req);
launchProcess
コード例 7-12 は、launchProcess 要求の標準的な形式を示しています。
(ビュー − 「プロセス」ビュー)。
コード例 7-12 launchProcess 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("launchProcess");
req.setAttribute("process", "my custom process");
req.setAttribute("taskName", "my task instance");
ExtendedResponse res = (ExtendedResponse) client.send(req);
各表記の意味は次のとおりです。
process 属性は、実行対象の、Identity Manager リポジトリ内のタスク定義オブジェクトを指定します。taskName 属性は、プロセス実行時の状態の保持のために作成される、タスクインスタンスオブジェクトの指定に使用されます。残りの属性は任意であり、タスクに渡されます。launchProcess 要求を使用すると、任意のカスタムプロセスを起動できます。
listResourceObjects
コード例 7-13 は、listResourceObjects 要求の標準的な形式を示しています。
コード例 7-13 listResourceObjects 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("listResourceObjects");
req.setAttribute("resource", "LDAP");
req.setAttribute("type", "group");
ExtendedResponse res = (ExtendedResponse) client.send(req);
各表記の意味は次のとおりです。
runForm
コード例 7-14 は、runForm 要求の一般的な形式を示しています。
コード例 7-14 runForm 要求
ExtendedRequest req = new ExtendedRequest();
req.setOperationIdentifier("runForm");
req.setAttribute("form", "SPML Get Object Names");
ExtendedResponse res = (ExtendedResponse) client.send(req);
ここで、form は、フォームを含む設定オブジェクトの名前です。
フォームの例
コード例 7-15 に示すフォームは、クエリーを実行し、現在のユーザーにアクセス可能なロール、リソース、および組織名のリストを返します。
コード例 7-15 クエリーフォーム
<Configuration name='SPML Get Object Names'>
<Extension>
<Form>
<Field name='roles'>
<Derivation>
<invoke name='com.waveset.ui.FormUtil'>
<ref>display.session</ref>
<s>Role</s>
</invoke>
</Derivation>
</Field>
<Field name='resources'>
<Derivation>
<invoke name='com.waveset.ui.FormUtil'>
<ref>display.session</ref>
<s>Resource</s>
</invoke>
</Derivation>
</Field>
<Field name='organizations'>
<Derivation>
<invoke name='com.waveset.ui.FormUtil'>
<ref>display.session</ref>
<s>ObjectGroup</s>
</invoke>
</Derivation>
</Field>
</Form>
</Extension>
</Configuration>
runForm 要求を使用すると、Identity Manager Session API を呼び出すことによって、取得される情報を返すカスタム SPML 要求を作成できます。たとえば、ユーザーを編集するためのユーザーインタフェースを設定する場合は、ユーザーに割り当てることのできる組織、ロールリソース、およびポリシーの名前を表示するセレクタの提供が必要になることがあります。これらのオブジェクトを SPML オブジェクトクラスとして公開するように SPML インタフェースを設定したあと、searchRequest を使用してそれらの名前をクエリーできます。ただし、それには、情報を収集するために 4 つの searchRequests が必要になります。代わりに、これらのクエリーをフォーム内にコード化したあと、単一の runForm 要求を使用してクエリーを実行し、結合された結果を返すことによって SPML 要求の数を減らすことができます。
SPML でのトレースの使用
Identity Manager の SPML トラフィックをロギングし、問題の診断に役立てることができるように、SPML では、次のようなトレース出力を有効にするためのオプションが提供されています。
メソッド 1
SpmlClient および LighthouseClient クラスは、ブール型の引数を取る setTrace メソッドを提供しています。この setTrace メソッドを有効にすると、クライアントによって送信された要求の XML や、サーバーから受信された応答の XML は、それらの送受信時にクライアントのコンソールに出力されます。たとえば、次のようにします。
SpmlClient client = new SpmlClient();
client.setURL("http://www.company.com/idm/spml");
client.setTrace(true);
メソッド 2
個別の SPML RPC 要求に対するトレースを有効にするために、trace というオペレーショナル属性をサーバー側の RPC 要求に渡すことができます。
トレースはサーブレットの初期化中に行われ、SPMLv2 要求を処理するサーブレットの RPC トラフィックに関する情報の出力方法を制御します。たとえば、トレースは、そのサーブレットについてどのような System.out (アプリケーションコンテナの関数) が指定されていても、そこでやり取りされる生の XML を出力します。たとえば、次のようにします。
trace 属性の使用方法がサーバー操作に与える影響はベンダー固有です。現在、Identity Manager は生の要求および応答データをサーバーコンソールに出力しています。これは、クライアントアプリケーションがコンソールウィンドウと関連付けられていない場合に役立ちます。
Identity Manager にはまだコードが実装されていないので、詳細については、OpenSPML ツールキットの製品マニュアルを参照してください。
例ここでは、SPML を実装するためのいくつかの一般的なメソッドを示すために、次の例について説明します。
追加要求
追加要求の例をコード例 7-16 に示します。
コード例 7-16 追加要求
SpmlClient client = new SpmlClient();
client.setURL("http://www.company.com/idm/spml");AddRequest req = new AddRequest();
req.setObjectClass("person");
req.setIdentifier("maurelius");
req.setAttribute("gn", "Marcus");
req.setAttribute("sn", "Aurelius");
req.setAttribute("email", "maurelius@example.com");SpmlResponse res = client.request(req);
if (res.getResult() .equals(SpmlResponse.RESULT_SUCCESS))
System.out.println("Person was successfully created");
変更要求
ここでは、認証された SPML 変更要求の 2 つの例を示します。
これらの例の唯一の違いは、コード例 7-18 では LighthouseClient クラス、および client.setUser と client.setPassword への 2 つの追加のメソッド呼び出しを使用している点です。
コード例 7-17 認証された SPML 要求
SpmlClient client = new SpmlClient();
client.setURL("http://www.company.com/idm/spml");ModifyRequest req = new ModifyRequest();
req.setIdentifier("maurelius");
req.setModification("email", "marcus.aurelius@example.com");SpmlResponse res = client.request(req);
if (res.getResult() .equals(SpmlResponse.RESULT_SUCCESS))
System.out.println("Person was successfully modified");
コード例 7-18 LighthouseClient を使用して認証された SPML 要求
LighthouseClient client = new LighthouseClient();
client.setURL("http://www.company.com/idm/spml");
client.setUser("maurelius");
client.setPassword("xyzzy");ModifyRequest req = new ModifyRequest();
req.setIdentifier("maurelius");
req.setModification("email", "marcus.aurelius@example.com");SpmlResponse res = client.request(req);
if (res.getResult() .equals(SpmlResponse.RESULT_SUCCESS))
System.out.println("Person was successfully modified");
検索要求
検索要求の例をコード例 7-19 に示します。
コード例 7-19 検索要求
SpmlClient client = new SpmlClient();
client.setURL("http://www.company.com/idm/spml");
SearchRequst req = new SearchRequest();
// 返す属性を指定する
req.addAttribute("sn");
req.addAttribute("email");
// フィルタを指定する
FilterTerm ft = new FilterTerm();
ft.setOperation(FilterTerm.OP_EQUAL);
ft.setName("gn");
ft.setValue("Jeff");
req.addFilter(ft);
SearchResponse res = (SearchResponse)client.request(req);
// 結果を表示する
List results = res.getResults();
if (results != null) {for (int i = 0 ; i < results.size() ; i++) {
SearchResult sr = (SearchResult)results.get(i);
System.out.println("Identifier=" +
sr.getIdentifierString() +
" sn=" +
sr.getAttribute("sn") +
" email=" +
sr.getAttribute("email"));
}
}