IdentityXMLは、ユーザーがブラウザからアイデンティティ・システム・アプリケーションにアクセスする際に行うアクションを実行するためのプログラム・インタフェースを提供します。たとえば、プログラムで、IdentityXMLリクエストを送信してグループ・マネージャ・アプリケーションに定義されているグループのメンバーを検索することや、ユーザーをユーザー・マネージャに追加することができます。この章では、IdentityXMLリクエストを作成する方法と、リクエストを送信してアイデンティティ・システムからのレスポンスを処理するプロセスについて説明します。
Webサービス記述言語(WSDL)は、XMLリクエストの概要を記述したものです。アイデンティティ・システムのWSDLファイルは、IdentityXMLリクエストを生成するための入力として使用できます。この章では、アイデンティティ・システムのWSDLソリューションを使用してIdentityXMLリクエストを自動で生成する方法について説明します。
Universal Description, Discovery, and Integration(UDDI)は、WSDLを使用して作成されたWebサービスへのユーザー・アクセスを可能にするレジストリ(ホワイト・ページまたはイエロー・ページに類似)です。アイデンティティ・システムのUDDIおよびWSDL機能が組み合されて、ID管理できるWebサービスが構成されます。
内容は次のとおりです。
IdentityXMLは、ユーザーがブラウザからアイデンティティ・システム・アプリケーションにアクセスする際に行うアクションを実行するためのプログラム・インタフェースを提供します。ブラウザを通じたアプリケーションとの対話を代行するプログラムを作成できます。たとえば、会社が移転し、10万名の従業員の電話局番を変更する必要がある場合、IdentityXMLを使用してバルク更新を実行できます。または、従業員を定期的に追加する場合、人事管理アプリケーションとアイデンティティ・システムの両方に入力するかわりに、新規ユーザーをユーザー・マネージャに作成して人事管理アプリケーションからデータを取得するIdentityXML関数をコールするスクリプトを作成できます。
図1-1に、IdentityXMLの役割を示します。
IdentityXMLを使用すると、単純なアクションや複数ステップのワークフローを処理することで、ユーザー、グループおよび組織のオブジェクト・プロファイルを変更できます。
IdentityXMLを使用して、外部アプリケーションが次のアイデンティティ・システム機能にアクセスできるようになります。
ユーザー: ワークフローまたは非同期ワークフローの内部または外部でユーザーを作成、削除および管理します。
グループ: グループおよびサブスクリプションを作成、削除および管理します。
組織: 組織オブジェクト・データを作成、削除および管理します。
IdentityXMLリクエストを作成するためのリクエスト構文、関数名およびパラメータは、この章および「IdentityXMLの関数およびパラメータ」の情報を参照してください。IdentityXMLリクエストの作成後は、SOAPラッパーを作成し、HTTPを使用してIdentityXMLリクエストをWebPassに送信します。図1-2に、IdentityXMLリクエストの処理方法を示します。
IdentityXMLリクエストは、ユーザー・マネージャ、グループ・マネージャまたは組織マネージャのパネルで使用されるLDAP属性にのみ有効です。
IdentityXML APIは、XML over SOAPを使用します。図1-2に示すように、HTTPリクエストを使用してIdentityXMLパラメータをアイデンティティ・サーバーに渡します。このHTTPリクエストにはSOAPエンベロープが含まれます。WebPassがHTTPリクエストを受信すると、そのリクエストが通常のブラウザ・リクエストではなくIdentityXMLリクエストであることがSOAPエンベロープにより示されます。リクエストはアイデンティティ・サーバーに転送され、アイデンティティ・サーバーでリクエストが実行されてレスポンスが戻されます。または、WSDLを使用してSOAPリクエストを作成することもできます。
IdentityXMLリクエストへのレスポンスとして送信されるデータは、アイデンティティ・システムがブラウザに戻すHTMLを作成するためにスタイルシートと組み合せるXML出力に似ています。リクエストした情報を抽出および使用するには、XMLレスポンスを解析する必要があります。
Oracle Access Managerのインストールには多数のIdentityXMLサンプルが含まれています。これらのサンプルはサポートされていませんが、特定の関数を指定する方法の参考になります。サンプルを確認するには、次のディレクトリを参照してください。
IdentityServer_install_dir\identity\oblix\unsupported\integsvcs
IdentityXMLリクエストを実装するには、次のタスク概要に示す手順を実行する必要があります。
実行するアイデンティティ・システム操作を決定します。詳細は、『Oracle Access Manager Administration Guide』を参照してください。
「IdentityXMLの関数およびパラメータ」を参照し、必要な操作に該当する関数名とパラメータを探します。
IdentityXMLリクエストの対象がユーザー・マネージャ、グループ・マネージャまたは組織マネージャのパネルで構成されているLDAP属性であることを確認します。
詳細は、『Oracle Access Manager Administration Guide』を参照してください。
この章の手順に従って、IdentityXMLリクエストとそのリクエスト用のSOAPエンベロープを開発します。
HTTP/Sリクエストをアイデンティティ・システムに送信するプログラムを作成します。
詳細は、「デプロイ済IdentityXML関数のコード例」および「SOAPおよびHTTPクライアント」のサンプル・プログラムを参照してください。
プログラムは任意の言語で記述できます。HTTP/Sリクエストには、作成したIdentityXMLリクエストが含まれているXMLペイロードを含める必要があります。SOAPリクエストを理解するWebサーバーにリクエストを送信するJavaプログラムまたはPerlスクリプトを記述できます。
プログラムまたはスクリプトでは次の処理を行います。
リクエストの送信を行うホストを識別します。
IdentityXMLリクエストを含んだファイルを読み取ります。
データの送信先ポート(ポート80)を識別します。
IdentityXMLの送信先のcgi(ユーザー・マネージャの場合はuserservcenter.cgiなど)を識別します。
cgiファイルは、「各アプリケーションのロケーション」で説明されています。
XMLレスポンスを解析して必要に応じて追加処理を実行するプログラムを作成します。
アイデンティティ・システムでは、XMLリクエストをトラップして出力をXML文書の形式で戻します。この文書を解析して処理する必要があります。
注意: WSDLでは、Javaプロキシ・オブジェクトを介してIdentityXMLリクエストを送信できます。開発者によっては、前の各段落で説明した方法よりも、この方法が便利です。「WSDLによるIdentityXMLリクエストの作成」を参照してください。 |
各IdentityXMLファイルには、単一の操作で構成される単一のリクエストが含まれます。一般に、反復的なタスクの実行にはIdentityXMLを使用すると便利です。たとえば、従業員の自宅の住所を更新するIdentityXMLソリューションを実装するとします。後で他の従業員の住所を更新するには、このソリューションを再利用できると便利です。このためには、IdentityXMLファイル内のデータを更新してリクエストを再送信する必要があります。
IdentityXMLリクエスト内のデータを動的に更新するシェルまたはPerlスクリプトを記述してください。このスクリプトでは、元のデータ・ソースから情報を取得し、設定済のIdentityXMLファイル内でそのデータに置換します。この方法により、たとえば、人事管理データベースに入力した新規ユーザーに関する情報がアイデンティティ・システムのユーザー作成操作に自動的に変換されるようにすることができます。
すべてのIdentityXMLリクエストでは、次の各段落に示す構文を使用します。XMLの詳細は、「XMLについての予備知識」を参照してください。SOAPの詳細は、「SOAPおよびHTTPクライアント」で説明されています。
IdentityXMLの構文はWSDLおよびUDDIと互換性があります。詳細は、「WSDLによるIdentityXMLリクエストの作成」を参照してください。
例1-1に、リクエストの書式を示します。
例1-1 IdentityXMLリクエストの書式
<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:oblix="http://www.oblix.com" xmlns:SOAP-ENV="http://schemas-xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <oblix:authentication type="basic"> <oblix:login>login name</oblix:login> <oblix:password>login password</oblix:password> </oblix:authentication> <oblix:request application="application name" function="function name" version="NPWSDL1.0"> <oblix:params> <oblix:param1>value1</oblix:param1> <oblix:param2>value2</oblix:param2> <oblix:param3>value3</oblix:param3> </oblix:params> </oblix:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
注意: この章では、IdentityXMLの最新の構文について説明します。この構文は、バージョン6.5以降に使用が開始され、WSDL用に最適化されています。以前の構文は非推奨になりましたが、以前の構文を使用するコードは現在でも機能します。以前のIdentityXMLの構文に関するドキュメントは、次のOracle Technology Networkのサイトから入手できます。 |
XMLは次の文字列で開始する必要があります。
<?xml version="1.0"?>
この必須の文字列内でタグを使用してエンコーディング指定を選択できます。エンコーディング文字列がない場合は、デフォルトのエンコーディング指定としてUTF-8が使用されます。
10g(10.1.4.0.1)では、リクエストに対してISO-8859-1(Latin-1)とUTF-8の2つのエンコーディング形式をサポートしています。レスポンスのエンコーディングは、リクエストのエンコーディングと同じです。たとえば、リクエストでLatin-1エンコーディング・タグ(encoding="ISO-8859-1"
)が使用されている場合は、レスポンスでもLatin-1エンコーディングが使用されます。リクエストでUTF-8エンコーディングが使用されている場合は、レスポンスでUTF-8エンコーディングが使用されます。
10g(10.1.4.0.1)を新しくインストールした場合には、UTF-8エンコーディング・タグ(encoding="UTF-8"
)の使用をお薦めします。
<?xml version="1.0" encoding="UTF-8" ?>
アップグレードされた環境で以前のプラグインとの下位互換性を持たせる場合は、Latin-1エンコーディング・タグ(encoding="ISO-8859-1"
)を使用します。次に例を示します。
<?xml version="1.0" encoding="ISO-8859-1" ?>
IdentityXMLリクエストでencoding="ISO-8859-1"
が使用されているとき、これに対するレスポンスにLatin-1キャラクタ・セット以外の文字が含まれている場合、このような文字では文字化けが発生します。たとえば、リクエストにISO-8859-1が使用され、レスポンスに日本語またはアラビア語の文字が含まれている場合、これらの文字はレスポンスで文字化けを起こします。
必須のSOAPタグにより、SOAPルート要素(エンベロープ)が開始されます。
<SOAP-ENV:Envelope> xmlns:oblix="http://www.oblix.com" xmlns:SOAP-ENV="http://schemas-xmlsoap.org/soap/envelope/">
これは</SOAP-ENV:Envelope>
タグで終了となります。エンベロープ要素内で、名前空間属性xmlns:oblix
にアイデンティティ・システム固有のタグを使用できます。
このタグにより、SOAPエンベロープのボディが開始されます。
<SOAP-ENV:Body>
これは</SOAP-ENV:Body>
タグで終了となります。ボディには認証情報とリクエスト情報の2つのSOAP要素が含まれます。
この必須の要素では、使用する認証タイプを指定します。
<oblix:authentication type="basic">
現在のところ、Basic認証がサポートされている唯一の認証タイプです。つまり、認証にはOracle Access ManagerのログインIDとパスワードが必要です。この要素は、</oblix:authentication>
タグにより終了とされます。
Active Directoryフォレスト内のサーバーに対しては、ログインとパスワードに加えてログイン・ドメインも指定する必要があります。このためには、<oblix:domain>要素を<oblix:authentication>タグ内に指定します。
次に例を示します。
<oblix:authentication xmlns:oblix="http://www.oblix.com" type="basic"> <oblix:login>user1k1</oblix:login> <oblix:password>abc</oblix:password> <oblix:domain> DC=locations,DC=oblix,DC=com </oblix:domain> </oblix:authentication>
次のloginタグでは
<oblix:login>login name</oblix:login>
Oracle Access ManagerユーザーのログインIDを指定します。
次のpasswordタグでは
<oblix:password>login password</oblix:password>
Oracle Access Managerユーザーのパスワードそのものを指定します。
HTTPクライアントでアクセス・システムのシングル・サインオンCookieを受信および再送信できる場合、認証要素は、セッションでの最初のリクエストにのみ含める必要があります。これにより、複数のログインで発生するオーバーヘッドを削減できます。例として、「ObSSOCookieの例」のサンプルJavaコードのCookie設定を参照してください。シングル・サインオンCookieをHTTP(S)リクエストの一部として送信する場合は、IdentityXMLリクエストを処理するWebPassを保護するWebGate上のIPValidation設定を変更します。リクエストの送信元のIPアドレスに対してIPValidationを無効化します。これは通常、IdentityXMLリクエストを送信するアプリケーションをホスティングするWebサーバーです。
次の両方のタイプのリクエストを使用する場合は、特別な留意点があります。
SSOで認証済のユーザーのアクションを実行するアプリケーションのためにSSO Cookieを使用するIdentityXMLリクエスト
アイデンティティ・イベントAPIのIdentityXMLコールなどの特権操作に資格証明を使用するアプリケーションに対してBasic認証を使用するIdentityXMLリクエスト
この両方のタイプのリクエストを使用環境でサポートする場合は、SSO IdentityXMLリクエスト専用のWebGateとWebPassが1セット以上、Basic認証リクエスト用のWebGateとWebPassが1セット、それぞれ必要になります。
次のリクエスト行は
<oblix:request application="application name" function="function name" mode = "modename" version="NPWSDL1.0">
リクエストに使用する関数(searchなど)をアイデンティティ・システムに指示します。function nameは、スペルと大/小文字が正確で二重引用符で囲んだ関数名に置き換えます。関数のリストは、「共通関数」を参照してください。
application nameには次のいずれかを指定できます。
groupservcenter: グループ・マネージャ関数の場合
objservcenter: 組織マネージャ関数の場合
asynch: 非同期ワークフローの場合
リクエストの送信先のアプリケーションは、正しいURLを入力して指定します。各関数で使用する正しいアプリケーションのURLの詳細は、「各アプリケーションのロケーション」と、「共通関数」にある関数の説明を参照してください。
オプションで、requestタグでmode="modename"を指定して、この関数からの出力を制限することもできます。modenameには、次のどちらかの値を使用します。
silent(サイレント): ステータス情報を戻しますが、その他の出力は戻しません。これは、アクセスをテストするIdentityXML関数に使用できます。関数が成功するとステータスとして0が戻され、失敗すると1が戻されます。サイレント・モードを使用するには、<oblix:request>で始まる行に次の追加を行います。
mode="silent"
次に例を示します。
<oblix:request application="userservcenter" function="view" mode="silent">
dataonly(データのみ): 出力で表示情報を省略します。デフォルトのモードでは、ボタンやフォームなどすべての表示関連要素がXML出力に含まれて戻されます。データのみのモードでは、表示関連の要素が削除されて、出力XMLのサイズが最小化されます。
次に例を示します。
<oblix:request application="userservcenter" function="view" mode="dataonly">
注意: IdentityXMLパラメータviewGroupMembersに対しては、データのみのモードでも、一部のユーザー・インタフェース情報が出力に含まれます。 |
version(バージョン): versionタグは必須です。
version="NPWSDL1.0"
6.5より前のIdentityXMLのversionタグに関するドキュメントは、次のOracle Technology Networkのサイトから入手できます。
次のタグは
<oblix:params>
パラメータ名とパラメータ値のペアのリストのデリミタとなります。キーワードはparams(paramでなく複数形であることに注意)です。この要素は、タグ</oblix:params>
により終了となります。起動するパラメータによっては、paramsタグと同等の機能を持つ別のタグが用意されています。詳細は、「検索パラメータ」および「属性パラメータ」を参照してください。
この要素の各出現には、特定のパラメータ名とパラメータ値のペアを指定します。param1は、引用符で囲んだパラメータ名と置き換えます。value1は実際の値に置き換えます。次に例を示します。
<oblix:param name="uid"> cn=Marketing Team, ou=Marketing, o=Company, c=US </oblix:param>
この以前の構文は、古いIdentityXMLファイル(NetPoint 6.5より前)がある場合にサポートされます。詳細は、対象のバージョンの製品に関するドキュメントを参照してください。
パラメータの指定方法は次のとおりです。
<oblix:param1>value1</oblix:param1>
次に例を示します。
<oblix:uid> cn=Marketing Team, ou=Marketing, o=Company, c=US </oblix:uid>
この指定方法は、WSDLおよびUDDIの機能を使用する場合に必要になります。各関数のパラメータについては、「共通関数」を参照してください。
パラメータと値のペアは複数個指定できます。
<oblix:param2>value2</oblix:param2> <oblix:param3>value3</oblix:param3>
例1-2に、パスワードを変更するIdentityXML関数を示します。関連するキーワードは太字で示されています。
例1-2 サンプルのパスワード変更リクエスト
<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas-xmlsoap.org/soap/envelope/" xmlns:oblix="http://www.oblix.com"> <SOAP-ENV:Body> <oblix:authentication xmlns:oblix="http://www.oblix.com" type="basic"> <oblix:login>dadmin</oblix:login> <oblix:password>password</oblix:password> </oblix:authentication> <oblix:request application="userservcenter" function="modifyUser" mode="" version="NPWSDL1.0"> <oblix:attributeParams> <oblix:uid>uid=jones,ou=People,ou=NA,ou=DEALER,dc=company,dc=com</oblix:uid> <oblix:PasswordAttribute> <oblix:attrName>userPassword</oblix:attrName> <oblix:attrNewValue>password</oblix:attrNewValue> <oblix:attrConfirmValue>password</oblix:attrConfirmValue> <oblix:attrOldValue>d</oblix:attrOldValue> <oblix:attrOperation>REPLACE</oblix:attrOperation> <oblix:attrNoOfFields">1</oblix:attrNoOfFields> </oblix:PasswordAttribute> </oblix:attributeParams> </oblix:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
この例の内容は次のとおりです。
modifyUser: IdentityXML関数の名前です。この関数により、ユーザー・マネージャで管理されるユーザー属性が変更されます。
oblix:authentication: ユーザーのログインを可能にする認証タグです。
oblix:attributeParams: uidはパスワードを変更する必要があるユーザーを指定します。
attrName: 表示または変更の対象とする1つ以上の属性の名前を指定します。
attrNewValue: attrNameパラメータに指定した属性への入力を要求する値を指定します。
例1-3に、問合せを実行するIdentityXML関数を示します。この問合せでは、ログイン・ユーザーに特定のグループ・プロファイルを表示する権限があるかどうかを確認します。このリクエストはたとえば、次のURLのユーザー・マネージャに送信できます。
http://www.customer.com/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi
Oracle Access Managerではまず、John Smithを有効なユーザーとして認証し、このユーザーにパスワードを変更する権限があるかどうかを検証します。アイデンティティ・システムでは、ユーザー・マネージャの「従業員」タブでcn属性の部分文字列がjohnに一致するすべてのエントリを検索します。リクエストの一部にmode="silent"があるため、レスポンスにはステータス情報のみが含まれます。
例1-3に、IdentityXMLリクエストを示します。
例1-3 サンプルのIdentityXMLリクエスト
<?xml version="1.0"?> <SOAP-ENV:Envelope . . . </oblix:authentication> <oblix:request function="search" mode="silent" version="NPWSDL1.0"> <oblix:Params> <oblix:tab_id>Employees</oblix:tab_id> <oblix:SearchParams> <oblix:Condition> <oblix:SearchAttr>cn</oblix:SearchAttr> <oblix:SearchOperation>OSM</oblix:SearchOperation> <oblix:SearchString>john</oblix:SearchString> </oblix:Condition> </oblix:SearchParams> </oblix:Params> </oblix:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
ここでは、IdentityXMLの入力に応答するアプリケーションと、これらのアプリケーションで使用するファイルについて説明します。
各アプリケーションのURLは次のとおりです。
http://
www.domain.com
:
port
/identity/oblix/apps/ groupservcenter/bin/groupservcenter.cgi
http://
www.domain.com
:
port
/identity/oblix/apps/ objservcenter/bin/objservcenter.cgi
http://
www.domain.com
:
port
/identity/oblix/apps/ userservcenter/bin/userservcenter.cgi
http://
www.domain.com
:
port
/identity/oblix/apps/ asynch/bin/asynch.cgi
使用するスキーマ・ファイルは次のとおりです。
XMLスキーマ・ドキュメント・ファイル: WebPass_install_dir\oblix
\WebServices\XMLSchema\*.xsd
WSDLスキーマ・ファイル: WebPass_install_dir
\oblix\WebServices\WSDL\*.wsdl
UDDIサンプルJavaファイル: WebPass_install_dir\oblix\WebServices\samples\UDDI\*.*
使用するスタイルシートは次のとおりです(『Oracle Access Managerカスタマイズ・ガイド』も参照)。
グループ・マネージャ、組織マネージャ、ユーザー・マネージャの場合:
IdentityServer_install_dir
\oblix\lang\en-us\style0
非同期ワークフローの場合: なし
IdentityXML関数には次の3つのタイプがあります。
test(テスト): これらの関数では、ユーザーが特定の機能を実行することを許可されているかどうかをテストします。test関数は、大規模なバッチ操作を実行する前に使用してください。test関数では、レスポンスとしてyesまたはnoを戻します。
get(取得): これらの関数では、現在のディレクトリの内容を示します。
set(設定): これらの関数では、現在のディレクトリの内容を変更します。
すべての関数は、「IdentityXMLの関数およびパラメータ」にリストされています。これらの関数のパラメータは、任意の順序で指定できます。パラメータの説明が記載されている順に指定する必要はありません。
IdentityXMLのtest関数は、自分または別のユーザーが特定の機能を実行できるかどうかを判断するために使用します。CanIで始まる関数は直接テスト(本人テスト。自分に対するテスト)です。CanUserで始まる関数は間接テスト(第三者テスト。第三者に対するテスト)です。これらの関数で、ユーザーJ. Smithが特定の機能を実行できるかを確認します。第三者テストはプロキシ・テストとも呼ばれます。テストの対象者はproxysourceuidパラメータで指定します。
例1-4に、テストのリクエストの例を示します。
例1-4 テストのリクエストの例
<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:oblix="http://www.oblix.com" xmlns:SOAP-ENV="http: //schemas-xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <oblix:authentication type="basic"> <oblix:login>J.Smith</oblix:login> <oblix:password>J.Smith</oblix:password> </oblix:authentication> <oblix:request function="canIViewGroupProfile" version="NPWSDL1.0"> <oblix:AttrParams> <oblix:uid> cn=Marketing Team,ou=Marketing,o=Company,c=US </oblix:uid> </oblix:AttrParams> </oblix:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
リクエストの結果は、ObAccessAPIResult要素に含まれるObTextMessage要素の値として表示されます。結果は次の3つのいずれかになります。
Allowed(許可): 自分または指定したユーザーはリクエストしたアクティビティを実行できます。
Denied(拒否): 自分または指定したユーザーはリクエストしたアクティビティを実行できません。
Not authorized to use service(サービスの使用権限なし): 「表示および変更の権限」で説明されているように、リクエストを行うために必要な権限がありません。
例1-5に、テストのレスポンスの例を示します。
注意: 10g(10.1.4.0.1)では、リクエストに対してISO-8859-1とUTF-8の2つのエンコーディング形式をサポートしています。レスポンスでは、リクエストと同じエンコーディング形式が使用されます。ISO-8859-1エンコーディングを使用してリクエストをLatin-1データとして送信することは現在も可能です。ただし、10g(10.1.4.0.1)のリクエストでは、UTF-8エンコーディングを使用することをお薦めします。 |
IdentityXMLリクエストでencoding="ISO-8859-1"
が使用されているとき、これに対するレスポンスにLatin-1キャラクタ・セット以外の文字が含まれている場合、このような文字では文字化けが発生します。たとえば、リクエストにISO-8859-1が使用され、レスポンスに日本語またはアラビア語の文字が含まれている場合、これらの文字はレスポンスで文字化けを起こします。
例1-5 テストのレスポンスの例
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:oblix="http://www.oblix.com" xmlns:SOAP-ENV="http:// schemas-xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <Oblix> <ObAccessAPIResult> <ObRequestInfo>187658080</ObRequestInfo> <ObTextMessage>Allowed</ObTextMessage> </ObAccessAPIResult> </Oblix> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
情報をディレクトリから収集して戻す、IdentityXML関数の一群があります。ログイン・ユーザーのデータを取得する関数を使用するには、ターゲット・オブジェクトのネーミング属性と指定の属性を表示する権限が必要です。
例1-6に、ワークフロー・チケット情報のリクエストの例を示します。
例1-6 ワークフロー・チケット情報のリクエスト
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://
schemas-xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<oblix:authentication xmlns:oblix="http://
www.oblix.com" type="basic">
<oblix:login>J.Smith</oblix:login>
<oblix:password>J.Smith</oblix:password>
</oblix:authentication>
<oblix:request function="workflowTicketInfo"
version="NPWSDL1.0">
<oblix:AttrParams>
<oblix:workflowInstanceDn>
obwfinstanceid=20001019T1609090,
obcontainerId=workflowInstances,
o=Oblix,o=Company,c=US
</oblix:workflowInstanceDn>
<oblix:workflowStepInstanceId>
2
</oblix:workflowStepInstanceId>
<oblix:AttrParams>
</oblix:request>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
これらの関数では、ディレクトリの内容を変更します。
ユーザーに自分に関するデータの設定を許可する関数を使用するには、次の条件があります。
ユーザーにはターゲット・オブジェクトのネーミング属性に対する表示権限が必要です。
属性を設定するワークフローまたはリクエストの場合は、ログイン・ユーザーは対象のワークフローの参加者である必要があり、また、ログイン・ユーザーにはターゲット・オブジェクトのネーミング属性と設定することをリクエストした属性を表示する権限が必要です。
ユーザー、グループまたはオブジェクトを削除するワークフローまたはリクエストの場合は、ログイン・ユーザーは対象のワークフローの参加者である必要があり、また、ログイン・ユーザーにはターゲット・オブジェクトのネーミング属性に対する表示アクセス権が必要です。
ユーザー、グループまたはオブジェクトを作成するワークフローまたはリクエストの場合は、検索ベースのルールは適用されません。ドメインを指定している場合は、ログイン・ユーザーはそのターゲット・ドメインにある該当するワークフローの参加者である必要があります。ドメインを指定していない場合は、ログイン・ユーザーは該当するいずれかのワークフローの参加者である必要があります。
別のユーザーに関するデータの設定をログイン・ユーザーに許可する関数を使用するには、次の条件があります。
ユーザーに自分に関するデータの設定を許可するすべての権限を、proxysourceuid(つまり、CanUserで始まるコール内のユーザー)に適用する必要があります。
ログイン・ユーザーにはproxysourceuid(および、targetuidが存在する場合はtargetuid)のクラス属性に対する表示権限が必要です。たとえば、CanUserViewタイプのコールにはtargetuidがありますが、CanUserCreateコールにはありません。
ログイン・ユーザーにはproxysourceuid(および、targetuidが存在する場合はtargetuid)のクラス属性に対する付与および読取り権限が必要です。
共通のIdentityXML関数およびアプリケーション固有のIdentityXML関数を使用するには、次の条件があります。
すべてのアプリケーションに、等価なGUI機能と同じアクセス権限が必要です。
例外: ログイン・ユーザーに別のユーザーに関するデータの設定を許可する間接アクセス関数に適用されるルールは、グループ関数userGroupsProfile、subscribeUserToGroup、およびunsubscribeUserFromGroupにも適用されます。
例1-7に、グループへのサブスクライブを示します。
例1-7 グループへのサブスクリプション
<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http:// schemas-xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <oblix:authentication xmlns:oblix="http:// www.oblix.com" type="basic"> <oblix:login>J.Smith</oblix:login> <oblix:password>J.Smith</oblix:password> </oblix:authentication> <oblix:request function="subscribeToGroup" version="NPWSDL1.0"> <oblix:params> <oblix:uid> cn=Marketing Team, ou=Marketing, o=Company, c=US </oblix:uid> </oblix:params> </oblix:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
IdentityXMLリクエストを使用して、ディレクトリ内のデータの表示または変更できます。データを表示または変更できるかどうかは、マスター管理者から割り当てられる「表示」
、「変更」
および「付与」
権限で制御されます。詳細は、『Oracle Access Manager Administration Guide』を参照してください。
ほとんどの関数では、別途明記されている場合を除き、表示または変更しようとしているデータが、管理者によって自分に対して設定されている検索ベースに存在している必要があります。たとえば、自分の検索ベースが販売組織に制限されている場合、会計組織のデータは表示または変更できません。
直接関数では、自分がデータを表示または変更できるかどうかをテストします。
ワークフローを使用せずに自分が値を表示できるかどうかをテストする関数を使用するには、次の条件があります。
ターゲット・オブジェクトのネーミング属性に対する表示権限が必要です。
属性を指定する場合は、その属性を表示する権限が必要です。
属性は、アイデンティティ・システム・アプリケーションに構成されているパネルに表示される必要があります。
ワークフローを使用せずに自分が値を変更できるかどうかをテストする関数を使用するには、次の条件があります。
ターゲット・オブジェクトのネーミング属性に対する表示権限が必要です。
設定するターゲット属性に対する書込み権限が必要です。
属性は、アイデンティティ・システム・アプリケーションに構成されているパネルに表示される必要があります。
ワークフローを使用する関数を使用するには、次の条件があります。
属性を変更できるかどうかをテストするには、次の条件があります。
ターゲット・オブジェクトのネーミング属性(uidやtab_idなど)に対する表示権限が必要です。
ターゲット属性に対する表示権限が必要です。
その属性の設定に使用されるワークフローの参加者である必要があります。
削除できるかどうかをテストするには、次の条件があります。
ターゲット・オブジェクトのネーミング属性に対する表示権限が必要です。
そのオブジェクトの削除に使用されるワークフローの参加者である必要があります。
作成できるかどうかをテストするには、次の条件があります。
ドメインを指定している場合: そのドメイン内でのデータの作成に使用されるワークフローの参加者である必要があります。
ドメインを指定していない場合: そのデータを作成する少なくとも1つのワークフローの参加者である必要があります。
注意: 変更、削除、作成の3つのカテゴリでのアクセス権付与は、すべてワークフローの参加者であるかどうかによって決定されます。作成テストでは、ワークフローの参加者である場合、自分に割り当てられている検索ベース外にオブジェクトがあっても、アクセス権を付与されます。どのテストにおいても、ワークフローの参加者でない場合、属性に対する変更権限があっても、拒否のレスポンスが戻されます。 |
間接関数では、proxysourceuidパラメータに指定した別のユーザーがデータの表示または変更を行えるかどうかをテストします。このパラメータは、「IdentityXMLの関数およびパラメータ」で説明されているように、多数のIdentityXML関数で必須です。必要な権限は次のとおりです。
前述の各段落で説明されているすべてのアクセス権が、proxysourceuidパラメータに指定したユーザーに必要です。
proxysourceuid(および、targetuidを使用する場合はtargetuid)のクラス属性に対する表示権限が必要です。
proxysourceuidおよびtargetuidのオブジェクト・クラスが自分の検索ベース内に存在する必要があります。
proxysourceuid(および、targetuidを使用する場合はtargetuid)のクラス属性の読取り権限を付与できることが必要です。
アプリケーション固有のIdentityXMLリクエストは、データを表示または変更するget
またはset
関数です。どちらの関数もGUIで実行可能な操作と同等であり、権限はGUIに適用される権限と同じです。
ただし、次の3つの関数は例外です。これらの関数に対する権限は、間接アクセスAPIに対する権限と同じである必要があります。
userGroupsProfile
subscribeUsertoGroup
unsubscribeUserfromGroup
注意: どのIdentityXMLリクエストにおいても、指定または使用が可能なLDAP属性は、アイデンティティ・システムに構成済で、ユーザー、グループまたは組織のプロファイル内のパネルに表示される属性のみです。これ以外の属性はすべて無効であるとみなされます。 |
一部のパラメータはタイプがDNの値を取ります。DN操作に必要な権限は次のとおりです。
表示: DN属性値を表示するリクエストを(attrName関数などを使用して)送信すると、自分が表示権限およびローカライズ権限を持っている値のみが戻されます。つまり、そのDNのクラス属性に対する読取り権限が必要であり、DNの値がそのオブジェクト・クラスのタイプに関して自分の検索ベース内にある必要があります。
変更: DN属性値を追加、変更または削除するリクエストを(任意の変更関数またはワークフロー機能などを使用して)送信すると、値に対して表示権限およびローカライズ権限を持っている場合にのみ、その値は有効であるとみなされます。つまり、そのDNのクラス属性に対する読取り権限が必要であり、DNの値がそのオブジェクト・クラスのタイプに関して自分の検索ベース内にある必要があります。無効なDN値を指定すると、「パラメータuniqueMemberの値が無効です」などのエラー・メッセージが戻されます。
無効なDN値の例としては、不正な値、非アクティブなユーザー、アクセス権を満たさないDNなどがあります。
『Oracle Access Managerカスタマイズ・ガイド』のPresentationXMLに関する章では、HTMLレスポンスの作成方法が説明されています。XSDおよびXMLの内容の詳細は、「XMLについての予備知識」を参照してください。
使用するアイデンティティ・システム・アプリケーションに応じて、対応するXML登録ファイル(userservcenterreg.xmlなど)を探します。登録ファイル内で、次の要素を検索します。
ObProgram name="xxxxxx"
ここで、xxxxxは、使用する関数です。この例では、ObProgram name="search"を検索します。この要素内には、次の要素もあります。
ObSchema name="yyyy"
ここで、yyyyは、目的の出力を定義するXMLスキーマ・ファイルの名前です。この例では、この行を次のようにします。
ObSchema name="usc_search.xsd"
通常、XMLスキーマ・ファイルは複数のinclude文で始まりますが、出力XMLはObRequestInfoへの参照を含んだ要素で始まり、その要素で指定される情報のみを含みます。
たとえば、usc_search.xsdファイル内では、このファイルから取った例1-8に示すように、要素ObSearchにはObRequestInfo要素が含まれています。
例1-8 レスポンスの書式
<xsd:element name="ObSearch"> <xsd:complexType> <xsd:sequence> <xsd:element ref="ObRequestInfo"/> <xsd:element ref="ObScripts"/> <xsd:element ref="ObForm"/> <xsd:element ref="ObTextMessage"/> <xsd:element ref="ObColumnInfo"/> <xsd:element ref="ObEntry" maxOccurs="unbounded"/> <xsd:element ref="ObButton" maxOccurs="unbounded"/> <xsd:element ref="ObViewModeButtonsForSearchResults"/> <xsd:element ref="ObStatus"/> </xsd:sequence> </xsd:complexType> </xsd:element>
検索結果の詳細は、ObEntry要素にネストされたObAttribute要素内に戻されます。ObStatus要素には、リクエストのステータス値が戻されます。
ObStatusの0という値は、リクエストが受け入れられて処理されたことを示します。
1という値は、エラーが発生したことを示します。
レスポンス・データを操作するには、「XMLについての予備知識」で説明されているHTTPClientなどのツールを使用して、アイデンティティ・システムから戻される出力のサンプルを取得することをお薦めします。対応するXMLスキーマをガイドとして使用すると、アプリケーションがデータのどの部分を使用するかを決定できます。
IdentityXMLレスポンスは、特定のXMLスキーマに従って作成されます。アイデンティティ・システムにおける属性マッピングの特質が原因で、属性は使用可能な多数のデータ型のいずれかとして構成されます。たとえば、単一値文字列、複数値文字列、各種の日付書式、整数、選択リスト、チェック・ボックスなどです。このため、属性とデータ型の間にある解析用の関係をハードコードすることはお薦めしません。かわりに、データ型を認識して適切なデータおよび属性のプロパティを抽出できるパーサーを実装することをお薦めします。
IdentityXMLレスポンスの構造は、特定のオブジェクト・クラス・タイプのデータ定義に従います。たとえば、ユーザー、グループ、組織などのオブジェクトのプロファイルには、複数の属性からなるパネルが1つ以上あります。1つの属性を、アイデンティティ・システム・アプリケーションの複数のパネルに表示することもできます。属性間の順序は、構成設定で決定します。XMLレスポンス内での属性の出現回数や、属性には常に値が設定されることなどを、根拠もなく想定することは、IdentityXML実装ではよくある間違いです。
例1-9は、検索リクエストの例に対するレスポンスの例です。検索条件を満たすディレクトリ・エントリごとに、1つのObEntry要素が戻されます。
例1-9 レスポンスの例
<?xml version="1.0" encoding="UTF-8" ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http:// schemas-xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <Oblix> <ObSearch> <ObRequestInfo>181481520</ObRequestInfo> <ObScripts> ... </ObScripts> <ObForm ....> ... </ObForm> <ObTextMessage/> <ObColumnInfo> ... </ObColumnInfo> <ObEntry> <ObAttribute obattrName="cn"> <ObDisplay obdisplayName="Name" obdisplayType="dn" obname="cn" obmode="view" obcanRequest="false" obrequired="false"> <ObDn> <ObLink obdisplayName="John Fulton" obhref="userservcenter.cgi ?program=view&tab_id=Employees &uid=cn%3DJohn%20Fulton%2C %20ou%3DEngineering %2C%20o%3DCompany%2C%20c%3DUS" obmouseOver="View personal information"> cn=John Fulton, ou=Engineering, o=Company, c=US <ObImage obhref="CIMAGEperson" obalt="View personal information" /> </ObLink> </ObDn> </ObDisplay> </ObAttribute> <ObAttribute obattrName="mail"> <ObDisplay obdisplayName="E-Mail Address" obdisplayType="email" obsemanticType="ObSEmail" obname="mail" obmode="view" obcanRequest="false" obrequired="false"> <ObEmail> <ObValue>J.Fulton@company.com</ObValue> </ObEmail> </ObDisplay> </ObAttribute> . . . <ObAttribute obattrName="telephonenumber"> <ObDisplay obdisplayName="Phone Number" obdisplayType="textSÓobname="telephonenumber" obmode="view" obcanRequest="false" obrequired="false"> <ObTextS> <ObValue>408-555-1173</ObValue> </ObTextS> </ObDisplay> </ObAttribute> <ObAttribute obattrName="ou"> <ObDisplay obdisplayName="Organization" obdisplayType="select" obname="ou" obmode="view" obcanRequest="false" obrequired="false"> <ObSelect> <ObChoice obdisplayName="Engineering" obselected="true">Engineering </ObChoice> </ObSelect> </ObDisplay> </ObAttribute> </ObEntry> ... <ObViewModeButtonsForSearchResults> ... </ObViewModeButtonsForSearchResults> <ObStatus>0</ObStatus> </ObSearch> <ObStatus>0</ObStatus> </Oblix> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
リクエストに無効なデータが含まれる場合、または権限のないデータにアクセスしようとした場合は、エラーが戻されます。ここに示すエラー・レスポンスは、リクエスト内でSLk1パラメータの値としてXXXを使用した結果です。レスポンスには要素ObErrorが含まれ、値が1の要素ObStatusがObErrorと同じインデント・レベルに含まれています。この両方のパラメータがあるかを検索することで、レスポンスがエラーかどうかを識別できます。
例1-10に、エラー・リクエストへのレスポンスを示します。
例1-10 エラー・レスポンス
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelopexmlns:SOAP-ENV="http:// schemas-xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <Oblix xmlns:oblix="http://www.oblix.com/" xmlns="http://www.oblix.com/"> <ObError> <ObRequestInfo>187658080</ObRequestInfo> <ObTextMessage> The attribute specified for this search (XXX) is either not searchable or not a valid attribute. </ObTextMessage> <ObStatus>1</ObStatus> </ObError> <ObStatus>1</ObStatus> </Oblix> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
次のようなエラーが発生する可能性があります。
無効なパラメータ値: %1。
これは、入力パラメータに無効な値がある場合に戻されます。この原因としては、パラメータがDN形式で指定されていないか、スキーマに存在しないことが考えられます。%1には、不正なパラメータの名前(ObWorkflowName
など)が入ります。
パラメータが無効です。
これは、ワークフローに指定された必須またはオプションの属性が有効でない場合、たとえば、パスワードが8文字以上と設定されている場合に入力が3文字のみだった場合などに戻されます。
アクセス権がありません。
操作を実行する権限がありません。
XML構文エラーがあります。
コードに入力ミスなどのエラーがあります。
この種のユーザーのプロファイルは構成されていません。
これは、入力が無効でその他のエラー捕捉で捕捉されない場合に生成される一般的なエラーです。
%1に値が必要です。
このエラーは、通常、ワークフロー属性に対して、または削除リクエストの一部として、必須のパラメータがないことを示します。
サービスの使用権限がありません。
ユーザーが認証を受けていないか、特定のアプリケーションに対してリクエストを行うための、認可がありません。
Webサービスは、標準のインターネット・プロトコルを使用してアクセスできる、プログラム可能なアプリケーション・ロジックで構成されます。XML Webサービスでは、標準のWebプロトコルを通じて、便利な機能をWebユーザーに公開しています。ほとんどの場合、使用されるプロトコルはSOAPです。XML Webサービスを使用すると、インタフェースを詳しく記述でき、開発者はこのインタフェースと対話するクライアント・アプリケーションを作成できます。インタフェースの記述は、通常、Webサービス記述言語(WSDL)ドキュメントと呼ばれるXML文書に含めます。
WSDLは、XMLで作成されたWebリクエストを操作するうえで便利です。WSDLファイルは、XMLリクエストの概要を記述したものです。WSDLファイルの内容は、XML関数名やそのパラメータなどに関する情報で構成されています。
次の各項では、アイデンティティ・システムのWSDLファイルを使用する方法と、IdentityXMLリクエストを生成するための代替方法としてこれらのファイルを操作する方法について説明します。
WSDLを使用すると、Web上で誰からもアクセスできるサービスを作成できます。このため、XML Webサービスを部品として使用した、新たにより強力なアプリケーションを別の作成者がビルドできます。「UDDIによるWSDL機能の有効化」の項では、WSDL機能を登録し、その機能を、必要とするすべてのユーザーからアクセスできるようにする方法について説明します。
WSDLは、IdentityXML用の抽象化レイヤーも提供します。Webアプリケーション・サーバーまたはサード・パーティのアプリケーションとの統合にIdentityXMLを使用する場合、または多様なアプリケーション・フレームワークを使用していて、開発チームが複数ある場合は、アプリケーション開発者全員がIdentityXMLの専門知識を持っていることはまれです。WSDLには、IdentityXMLコールを直接コーディングしなくても済むようにできるツールが用意されています。開発者はツールを使用してIdentityXML関数用のプロキシ・コードを生成し、プロキシ・コードを使用してコールを行うことができます。このため、開発者はWSDLを使用することで、XMLプログラミングを直接行わずに済みます。
「IdentityXMLの概要」に記載されているように、IdentityXMLリクエスト・ドキュメントを手動で作成するには、このガイドのリクエスト構文、関数名およびパラメータを参照してXMLベースのSOAPリクエストを作成し、HTTPを使用してIdentityXMLリクエストをWebPassに送信します。WSDLを使用すると、XMLリクエストの手動作成は不要になり、オブジェクトの操作のみで済みます。WSDLでは、リクエストを送信するコードは、Javaなど開発者が選択した言語で自動的に生成されます。リクエスト全体の作成は不要で、リクエストへのパラメータの設定のみが必要です。たとえば、パラメータには、Javaオブジェクトに対するファンクション・コールなどを指定します。
アイデンティティ・システムには、「IdentityXMLの関数およびパラメータ」に記載されているIdentityXML関数ごとにWSDLファイルが用意されています。WSDLファイルは次のロケーションにあります。
oblix\WebServices\WSDL\*.wsdl
ファイル名は関数の名前を反映しています。たとえば、あるWSDLファイルはIdentityXMLのsearch関数に対応しているため、名前にsearchが含まれます。別のWSDLファイルの名前にはworkflowTicketSearchが含まれ、別のIdentityXML関数に対応しています。関数名の完全なリストは、「IdentityXMLの関数およびパラメータ」を参照してください。
ディレクトリoblix\WebServicesの構造は次のとおりです。
WSDL: 各WSDLテンプレート・ファイルが含まれていて、ファイルはそれぞれIdentityXML関数に対応しています。
Samples: 内容は次のとおりです。
UDDI: UDDI機能を実装するサンプル・ファイルが含まれています。詳細は、「UDDIによるWSDL機能の有効化」を参照してください。
ディレクトリoblix\WebServices\WSDL\*.wsdlにあるWSDLファイルの名前は、次のとおりです。
common_*.wsdl: 各ファイルには、共通のIdentityXMLリクエストの生成に必要な情報が含まれています。
gm_*.wsdl: 各ファイルには、グループ・マネージャのIdentityXMLリクエストの生成に必要な情報が含まれています。
um_*.wsdl: 各ファイルには、ユーザー・マネージャのIdentityXMLリクエストの生成に必要な情報が含まれています。
om_*.wsdl: 各ファイルには、組織マネージャのIdentityXMLリクエストの生成に必要な情報が含まれています。
WSDLのOracle実装は、UDDIへの公開への使用に推奨するモデルに基づいています。このモデルでは、各関数に2つのファイルが存在する必要があります。
IdentityXML関数のURLロケーションを含むファイルが、関数ごとに1つあります。このWSDLファイルの名前にはIdentityXML関数の名前が含まれ、接頭辞としてcommon_、gm_、um_またはom_が付いています。たとえば、search関数は、共通関数であるため、それに対応するWSDLファイルはcommon_search.wsdlになります。グループ・プロファイルを表示する関数は、viewという名前であるため、それに対応するWSDLファイルはgm_view.wsdlになります。
2つ目のWSDLファイルは関数のインタフェース用です。このファイルの名前には文字列interfaceが常に含まれます。
WSDLドキュメントには主なセクションが2つあります。最初のセクションは抽象的な定義で構成されます。この定義はアイデンティティ・システムに付属のWSDLドキュメントにあります。
Types: マシンおよび言語から独立したタイプ定義。
Messages: 関数のパラメータが含まれています。
PortTypes: 関数の構成要素(操作名、入力パラメータおよび出力パラメータ)の記述が含まれています。
2番目のセクションは具体的な定義で構成されます。この情報は使用環境に固有です。
Bindings: PortTypesセクション内の各操作のバインディング。
Services: 各バインディングのポート・アドレス。
各WSDLファイルには、そのファイル名に接尾辞_interfaceが付いた名前を持つ別のWSDLファイルがインポートされます。たとえば、gm_view.wsdlファイルにはgm_view_interface.wsdlというファイルがインポートされます。このインタフェースWSDLファイルには、属性タイプ、関数名、バインディングなどが含まれます。このファイルは抽象表現です。
IdentityXML関数の名前に対応するファイルには、実装定義が含まれます。このファイルには、このWebサービスを起動できるURLが含まれます。これは、アイデンティティ・システムのインストールへのURLです。このファイルには、このファイルの名前と_interfaceを連結した名前を持つファイル(gm_view_interface.wsdlなど)がインポートされます。
同じインタフェースの実装が複数個必要な場合は、各IdentityXML関数に2つのWSDLファイルを用意しておくと便利です。UDDIを通じて各インタフェース・ファイルを1度公開すれば、複数の実装ファイルもUDDIを通じて公開できるためです。
次に、アイデンティティ・システムのWSDLドキュメントの例と、最初のファイルにインポートされる2番目のWSDLファイルの例を示します。関数名は太字で示されています。
例1-11に、IdentityXMLのsearch関数に対応するWSDLドキュメントを示します。
例1-11 common_search.wsdlファイル
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap" xmlns:http="http://schemas.xmlsoap.org/wsdl/http" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:oblix="http:www.oblix.com" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="http://www.oblix.com/wsdl/common_search" targetNamespace="http://www.oblix.com/wsdl/common_search"> <import namespace="http://www.oblix.com/" location="common_search_interface.wsdl"/> <service name="OblixIDXML_common_search_Service"> <port name="OblixIDXML_common_search_Port" binding="tns:OblixIDXML_common_search_Binding"> <soap:address location ="http://echo.oblix.com:5555/identity/oblix/apps/ userservcenter/bin/userservcenter.cgi"/> </port> </service> </definitions>
例1-12に、直前の例のcommon_search.wsdlファイルで使用されている定義の多くを提供するインタフェース・ファイルを示します。
例1-12 common_search_interface.wsdl
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" . . . xmlns:oblix="http://www.oblix.com/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="http://www.oblix.com/wsdl/common_search" targetNamespace="http://www.oblix.com/wsdl/common_search"> <import namespace="http://www.oblix.com/" location="../XMLSchema/ common_parameters.xsd"/> <import namespace="http://www.oblix.com/" location="../XMLSchema/ common_authentication.xsd"/> <import namespace="http://www.oblix.com/" location="../XMLSchema/ common_component_search.xsd"/> <types> <xsd:schema targetNamespace="http://www.oblix.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="request"> <xsd:complexType> <xsd:sequence> <xsd:element name="params"> <xsd:complexType> <xsd:sequence> <xsd:element ref="oblix:tab_id" minOccurs="0"/> <xsd:element ref="oblix:startFrom" minOccurs="0"/> <xsd:element ref="oblix:noOfRecords" minOccurs="0"/> <xsd:element ref="oblix:noOfFields" minOccurs="0"/> <xsd:element ref="oblix:showAllResults" minOccurs="0"/> <xsd:element ref="oblix:sortBy" minOccurs="0"/> <xsd:element ref="oblix:sortOrder" minOccurs="0"/> <xsd:element ref="oblix:attrName" minOccurs="0" maxOccurs="unbounded"/> . . . <!--All of these functions can be invoked for any Identity System application --> <!--User Manager, Group Manager, or Organization Manager to get the --> <!--right search results. They are described in this one WSDL file. --> <xsd:pattern value="userservcenter\groupservcenter\objservcenter"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="function" type="xsd:string" use="required"/> <xsd:attribute name="mode" type="xsd:string" use="optional"/> </xsd:complexType> </xsd:element> </xsd:schema> </types> <message name="OlibxIDXMLInput"> <part name="authentication" element="oblix:authentication"/> <part name="request" element="oblix:request"/> </message> <message name="OblixIDXMLOutput"> <part name="body" element="oblix:Oblix"/> </message> <portType name="OblixIDXMLPortType"> <operation name="OblixIDXML_common_search"> <input message="tns:OblixIDXMLInput"/> <output message="tns:OblixIDXMLOutput"/> </operation> <portType> <binding name="OblixIDXML_common_search_Binding" type="tns:OblixIDXMLPortType"> <soap:binding style="document" transport="http://schemas:xmlsoap.org/soap/http"/> <operation name="OblixIDXML_common_search"> <soap:operation soapAction="http://www.oblix.com/"/> ... </definitions>
図1-3に示すように、IdentityXMLコールを使用することで、ユーザーがアイデンティティ・システムと対話しないで済みます。
IdentityXMLリクエストとSOAPエンベロープを手動で作成するか、WSDLを使用してクライアント・オブジェクトを自動で生成するかを選択できます。自動生成を選択した場合、必要な作業はクライアント・オブジェクトを編集して適切なパラメータを設定することのみです。
タスク概要: アイデンティティ・システムのWSDLファイルの操作
対象のWSDLファイルを編集します。
Javaまたは.NETプロキシ・オブジェクトを生成します。
Javaまたは.NETクライアントを開発します。
Javaまたは.NETによるWSDLソリューションの開発方法の詳細は、後に続く各項を参照してください。
Javaプログラミングをよく理解している場合は、アイデンティティ・システムのID管理用Webサービスを使用すると、WSDLを使用でき、IdentityXMLを直接操作しなくても済むようになります。アイデンティティ・システムでは、各IdentityXML関数には2つのWSDLファイルが用意されています。これらのファイルを使用して、IdentityXMLリクエスト用のJavaプロキシ・オブジェクトを生成します。
タスク概要: WSDLによるJava IdentityXMLリクエストの生成
生成するIdentityXMLリクエストに名前を付けます。
使用する関数を「IdentityXMLの関数およびパラメータ」で調べます。
または、対応するWSDLファイルをUDDIレジストリから探すこともできます。アイデンティティ・システムでは、WSDLファイルがローカル・インストール・ディレクトリに用意されていますが、当該のWSDL機能が含まれるUDDIレジストリにアクセスできる場合は、この方法でその機能を探すと便利です。詳細は、「UDDIによるWSDL機能の有効化」を参照してください。
対応するWSDLドキュメント内のsoap:address文でホスト名とポート番号を編集します。
たとえば、common_search.wsdlの場合、ユーザー・エントリの検索を実行するには、次のような行を入力します。
<soap:address location ="http://echo.oblix.com:5555/identity/oblix/apps/ userservcenter/bin/userservcenter.cgi"/>
グループ・エントリを検索する場合は、次のようなURLになります。
<soap:address location ="http://example.com:1234/identity/oblix/apps/ groupservcenter/bin/groupservcenter.cgi"/>
組織および汎用エントリを検索する場合は、次のようなURLになります。
<soap:address location ="http://example.com:1234/identity/oblix/apps/ objservcenter/bin/objservcenter.cgi"/>
Javaクライアントの場合は、プロキシ・オブジェクトと、リクエストを送信するJavaクライアントを開発します。
ID WSDLファイルの処理およびIdentityXMLリクエスト用のJavaプロキシ・オブジェクトの自動生成には、WSDLからJavaへの変換ツールを使用します。
WSDLからJavaへの変換ツールとしては、Apache Axisパッケージなどがあります。
.NETを熟知している場合は、次の手順を使用します。
.NET環境では、正しいWSDL共通ファイルをVisual Studioに送信すると、Visual Studioで.NETクライアントが作成されます。生成されたクライアント・コードでパラメータを編集し、コードを作成して、このコードを、その他のWebサービスの起動に使用されるコードと同様に使用して、Webサービスを起動します。
Oracleには、C#を使用したWebサービス起動用コード・サンプルが用意されています。
.NET WSDLクライアントを作成するための前提条件:
WebサービスのディレクトリがWebサーバーを通じて公開されていて、Visual Studioを使用してWeb参照を追加できることを確認します。
.NET Studio 2003と.NET Framework 1.1をインストールします。
2つのMicrosoft更新プログラムをインストールします。
最初に適用するプログラムは.NET FrameworkでのXMLメッセージング用であり、この更新プログラムのロールアップはhttp://support.microsoft.com?id=822411
にあります。
.NET Framework 1.1 WSDLおよびVisual Studio .NET 2003用のプログラムも適用する必要があり、この更新プログラムのロールアップはhttp://support.microsoft.com/?id=823639
にあります。
タスク概要: WSDLによる.NET IdentityXMLリクエストの生成
使用する関数を第2章「IdentityXMLの関数およびパラメータ」で調べます。
対応するWSDLドキュメント内のsoap:address文でロケーション情報を編集します。
たとえば、common_search.wsdlの場合、次の行を編集します。
<soap:address location ="http://echo.oblix.com:5555/identity/oblix/apps/ userservcenter/bin/userservcenter.cgi"/>
リクエストを送信する.NETコードを作成します。
Visual Studioを起動します。
「Visual C# プロジェクト」フォルダから「コンソール アプリケーション」テンプレートを選択し、「OK」をクリックします。
「プロジェクト」→「Web 参照の追加」の順にクリックします。
「Web 参照の追加」ダイアログで、Webサービスのディレクトリがあるロケーションを選択します。
Webサービスのディレクトリは、Oracle Access ManagerのWSDL入力ファイルのロケーションです。
たとえば、ローカル・マシンやUDDIサーバーを選択できます。
選択したロケーションにあるWSDLファイルが表示されます。
アプリケーションに該当するWSDLサービスが含まれるファイルを選択します。
これらのファイルの名前には、使用する関数が含まれますが、_interfaceは含まれません。たとえば、search関数の場合、common_search_interface.wsdlではなくcommon_search.wsdlを編集することになります。
例: common_search.wsdl
サービスが表示されます。
注意: WSDLファイル内のURLロケーションが、アイデンティティ・システムがインストールされているURLを指していることを確認してください。 |
「このページではポートまたはメソッドが見つかりませんでした。」というエラーを通知するウィンドウが表示されます。このエラーは無視できます。重要な情報は、このページの右側のペインに表示されます。
右側のペインにある「参照の追加」ボタンをクリックします。
Web参照へのリンクが追加されたことを示すプロジェクト ウィンドウが表示されます。Visual Studioでプロキシ・オブジェクト・コードが作成され、オブジェクトのすべての要素がreference.csという1つのファイルに格納されます。
メイン ウィンドウで、プロキシ・オブジェクト・コードを追加します。
アプリケーション、バージョン、関数のパラメータなど、クライアント・コードを完成するために必要な情報を指定します。
サンプルの.NETクライアントは、ディレクトリoblix\WebServices\samplesにあります。
.NETプロキシ・オブジェクト・コードをコンバイルするには、「ビルド」→「ソリューションのビルド」の順にクリックします。
ソリューションがコンパイルされたら、その他の実行可能ファイルと同様に、Visual Studioまたは別のロケーションからそのソリューションを実行できます。
Oracle Access Managerには、Javaを使用してWebサービスを起動および利用する方法を実際に示すサンプル・クライアント・コード・ファイルが3つ用意されています。これらのファイルはWebPass_install_dir\identity\oblix\WebServices\samples\WSDL\java_axisにあります。
testwsdl_gm_view.java: WebPassがWebGateで保護されている場合にWebサービスを起動する例を示します。
このサンプル・コードを使用するには、WebPassがインストールされていて、Oracle Access and Identity認証スキームを使用するWebGateで保護されている必要があります。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
testwsdl_search_deactivated_users.java: 非アクティブなユーザーを検索するリクエストを行う例を示します。
testwsdl_viewgroupmembers.java: グループのメンバーを表示するリクエストを行う例を示します。
testwsdl_reactivate_user.java: ユーザーを再アクティブ化する方法を示します。
また、WSDL_java_axis_README.htmlという名前のヘルプ・ファイルがディレクトリWebPass_install_dir\identity\oblix\lang\<language>\htmlにあります。
グループをグループ・マネージャに追加するなど追加のWSDL機能をテストする場合は、そのようなWSDL機能をサンプル・ファイルに追加できます。
続く各項では、コードをコンパイルして実行する方法について説明します。コードの実行時に例外がスローされない場合は、Webサービスは起動されています。エラーがある場合は、そのエラーがレスポンスに出力されます。
サンプル・クライアント・コードを使用するには、次のソフトウェアが実行されている必要があります。次のバージョンが必要であり、これより前のバージョンではサンプル・コードは使用できません。
Java 1.4以降(JDK 2、バージョン1.4)、http://java.sun.com/j2se/1.4.1/download.htmlから入手可能
Apache Axis 1.3以降、http://ws.apache.org/axis/から入手可能
Javax mailおよびJavax activation.jar、http://java.sun.com/products/javamail/downloads/index.htmlおよびhttp://java.sun.com/products/javabeans/glasgow/jaf.htmlから入手可能
次に、Access Manager SDKの設定タスクの概要を示します。このタスクは、WebPassがWebGateで保護されている場合にのみ必要です。
Webサービス・コールを行うローカル・マシンにAccess Manager SDKをインストールします。
新規のアクセス・ゲートを「アクセス・システム・コンソール」で構成します。
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。アクセス・ゲートの一意のIDと、Webサービス・コールを行うローカル・マシンのホスト名を指定します。
ローカル・マシンでconfigureAccessGateコマンドを実行し、このマシン上にアクセス・ゲートを構成します。
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
「アクセス・システム・コンソール」で、Webサービス・コールを受信するアクセス・ゲートおよびWebGateに対して「IPValidation」をオフにします。
次の手順では、サンプル・コードの実行に必要なコマンドについて説明します。
CLASSPATHを設定してサンプル・コードをコンパイル、実行する手順
インストール・ディレクトリに含まれるjavaおよびjavacコンパイラへのパスを設定します。たとえば、インストール・ディレクトリがc:¥j2sdk1.4.2_05の場合、パスを次のように設定します。
set java_home
=c:\j2sdk1.4.2_05
ここで、java_homeは、インストール・ディレクトリを表すパス変数です。
Access Manager SDKへのパスを次のように設定します。
set PATH=AccessServerSDK_install_dir
\oblix\lib;F:\j2sdk1.4.2_05\bin;%PATH%
ここで、Access_Server_install_dirは、アクセス・サーバーがインストールされたディレクトリです。
次のjarファイルを含むようにCLASSPATH変数を設定します。
Access Manager SDK内のjobaccess.jar
javaxのmail.jar
activation.jarファイル
これらのjarファイルは、次の例に示すように、CLASSPATHにすでに含まれているその他のファイルより前に含める必要があります。
set CLASSPATH=F:\axis\axis-1_3\lib\axis.jar;F:\axis\axis-1_3\lib\jaxrpc.jar; F:\axis\axis-1_3\lib\commons-discovery-0.2.jar; F:\axis\axis-1_3\lib\commons-logging-1.0.4.jar; F:\axis\axis-1_3\lib\saaj.jar;F:\xerces\xerces-1_4_4\xerces.jar; F:\axis\axis-1_3\lib\wsdl4j-1.5.1.jar;.; F:\TEMP\AcessServerSDK\oblix\lib\jobaccess.jar; F:\javax\javamail-1.3.3_01\mail.jar;F:\javax\jaf-1.0.2\activation.jar; %CLASSPATH%
WebPassがWebGateで保護されている場合は、次の例に示すように、Access Manager SDKを含むようにPATHを設定します。
set PATH=AccessServerSDK_install_dir
\oblix\lib;F:\j2sdk1.4.2_05\bin;%PATH%
ここで、AccessServerSDK_install_dirは、Access Manager SDKのインストール先の場所です。
次のコマンドを実行してサンプルをコンパイルします。
java org.apache.axis.wsdl.WSDL2Java -o f:\temp\mywsdl -p com.oblix.www d:\oblix\WebServices\WSDL\gm_view.wsdl
com\oblix\wwwという名前のディレクトリが作成され、Javaコードが移入されます。
前のコマンドを実行して作成されたディレクトリに移動します。
cd com\oblix\www
WebPassがWebGateで保護されていない場合の単純な表示操作実行用に用意されているファイルをコピーします。
このファイルはtestwsdl_viewgroupmembers.javaという名前であり、次のロケーションにあります。
WebPass_install_dir
\identity\oblix\WebServices\samples\WSDL\java\
このファイルをcom\oblix\wwwディレクトリにコピーします。
このファイルには、グループのメンバーを表示するコードが含まれています。このファイルは変更なしで実行することも、あるいはユーザーまたはグループの変更など別の操作をテストするためのベースとして使用することもできます。
または、WebPassがWebGateで保護されている場合の表示操作実行用に用意されているファイルをコピーすることもできます。
このファイルにはobSSOCookieを設定するコードが含まれています。このファイルはtestwsdl_gm_viewという名前であり、次のロケーションにあります。
WebPass_install_dir
\identity\oblix\WebServices\samples\WSDL\java_axis\
このファイルのサンプル・コードは次のように編集する必要があります。
静的な文字列accessSDKinstalldirを編集し、Access Manager SDKのロケーションを置き換えます。
ホスト名とポートを実際の環境に合せて変更します。
userNameとpasswordの値をアイデンティティ・システムの実際の管理者用の値に変更します。
ObSSOCookie(コード・サンプルを参照)を取得した後は、ユーザー名とパスワードを毎回指定せずにWebサービス・コールを何回でも行うことができます。ObSSOCookieを使用できるため、指定が不要になるのです。
次のコマンドをcom\oblix\wwwディレクトリから入力します。
javac *.java
com\oblix\wwwディレクトリから3つ上のレベルに移動します。
cd ..\..\..
Webサービスを次のように実行します。
java com.oblix.www.testwsdl_gm_view
リクエストのステータスがコマンド プロンプトのウィンドウに出力されます。ステータス0は成功を示します。
レスポンス・オブジェクトを解析すると、これ以外の情報も入手できます。
たとえば、検索結果を抽出できます。この例は、その他のサンプル・ファイルと同一の次のディレクトリにあるファイルtestwsdl_search_deactivated_users.javaに示されています。
WebPass_install_dir
\identity\oblix\WebServices\samples\WSDL\java_axis\
サンプル・コードにより、最初の非アクティブなユーザーの名前が出力されます。
Universal Description, Discovery, and Integration(UDDI)レジストリは、WSDL機能を使用する必要があるユーザーのためのデータベースです。UDDIを使用すると、WSDLで作成されたWebサービスを公開および分類できます。UDDIはホワイト・ページやイエロー・ページに似ており、必要な機能をUDDIレジストリで検索でき、レジストリに新機能を追加できます。あらゆる組織のすべてのユーザーがアクセスできるグローバルUDDIレジストリが、IBM社やMicrosoft社などの企業により提供されています。レジストリ・アカウントを作成および使用する手順は、これらの企業のUDDIサイトに記載されています。その他の組織では、独自の内部UDDIレジストリを保持しています。
UDDIの利用方法の例として、リモートのディーラとやり取りする必要がある車のディーラについて考えます。このディーラは、組織内部のUDDIレジストリをイエロー・ページのように使用して、別のディーラを検索するWebベースのサービスを探すことができます。この例を引き続き使用し、UDDIレジストリにディレクトリsoftware_publishers/identity management/Oracleが含まれていると想定します。前述の車のディーラが、ユーザーによるリモート・ディーラの検索を可能にするWebサービスのエントリをこのディレクトリで取得しました。このエントリには、必要な検索リクエストを生成できるWSDLファイルを指すURLが含まれます。
一般に、UDDIレジストリには、各Webサービスに対して次の情報が含まれます。
会社名(Oracleなど)。
サービス(UDDI用語ではインタフェースとも呼ばれる)。つまり、viewなどのXML関数に、XSD形式の入出力パラメータが追加されたもの。
実装。つまり、対応するWSDLを指すURL。
該当するUDDIレジストリを検索するには、所属の組織で使用している検索規則に従ってください。
アイデンティティ・システムのWebサービス機能を使用すると、独自の機能をUDDIに登録できます。IdentityXMLシステムと対話するインタフェースを作成する場合は、UDDIを使用して必要なWSDL定義を検索し、この定義をベースとして、IdentityXMLサービスと対話するJavaクライアントを開発できます。
.NETおよびJava形式のサンプルUDDI登録プログラムは、次のロケーションにあります。
webpass_install_dir
\oblix\WebServices\samples\UDDI\dotnet
および
webpass_install_dir
\oblix\WebServices\samples\UDDI\java
どちらのディレクトリにもreadmeファイルがあります。これらのディレクトリには、機能を登録した後でその機能をテストするためのサンプル・ファイルも含まれています。