この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
サービス カタログ(Service Catalog)ディレクトリ統合は、一元化されたユーザ認証およびエンタープライズ ディレクトリとの同期を実装することによって、セキュリティ管理を簡略化し、ユーザの利便性と生産性を向上します。
サービス カタログ(Service Catalog)では、カスタマーは(通常は LDAP プロトコルを使用して)外部ディレクトリと統合し、ユーザ情報を同期することができます。この同期は、ユーザが Order-on-behalf(OOB)で選択されたとき、または Person Lookup 時に起動されます。
シングル サインオン(SSO)の統合により、一元管理されたユーザ認証が可能になり、個別のログイン メカニズムが不要になります。SSO イベントを有効にすると、サービス カタログ(Service Catalog)が統合されているエンタープライズ ポータルにすでにログインしているユーザは、ログインし直す必要がありません。サービス カタログ(Service Catalog)は SSO ツールを利用してすべての Service Catalog URL を保護し、認証を実行します。サービス カタログ(Service Catalog)で認証を正常に行うには、SSO ツールにより個人の識別情報を HTTP ヘッダーまたは cgi ヘッダーを介して、毎回の認証でサービス カタログ(Service Catalog) URL へ提供する必要があります。認証されると、それらの情報をアプリケーション データベースと同期することができます。
SSO が有効でない場合は、サービス カタログ(Service Catalog)のログイン画面がすべてのユーザに表示され、ユーザは正しいユーザ名とパスワードの組み合わせを入力することができます。デフォルトでは、これらのクレデンシャルは内部データベースで認証されます。または、外部システム(通常は LDAP ディレクトリ)で認証するよう、Directory Integration を設定することもできます。サービス カタログ(Service Catalog)にアクセスするすべてのユーザは、認証が正常に行われるように、このソース内に存在している必要があります。
Directory Integration Framework は、頻繁に導入される SSO およびディレクトリ サーバ製品に対して、Administration モジュールで使用できる設定オプションを通じて上記の機能を提供します。フレームワークには、定義済みの設定機能を補完可能なアプリケーション プログラミング インターフェイス(API)も含まれています。プログラマは API を使用して追加の SSO ポータルやディレクトリ サーバにアクセスできるだけでなく、サービス カタログ(Service Catalog)と外部ディレクトリの間でユーザ情報が同期されるよう、デフォルトの動作を変更または補完できます。
この章では、Administration モジュールを使用してサービス カタログ(Service Catalog)に対してディレクトリ統合を設定する方法について説明します。また、有効な統合オプションのカスタマイズで使用できる公開 API とインターフェイスのセット、カスタム コードをコンパイルおよび導入するためのベスト プラクティス、Administration モジュールを使用してカスタム コードを設定するための手順についても説明します。
(注) LDAP ブラウザにアクセスすることを強く推奨します。
ディレクトリ統合を設定するには、SSO の現在の実装(使用している場合)および社内のディレクトリ サーバに関する有用な情報を入手し、これらのシステムをサービス カタログ(Service Catalog)に統合するための要件を文書化する必要があります。ここでは、この情報を収集するためのワークシートをいくつか示します。
これらのワークシートは、ディレクトリ/SSO 統合を設定したり、統合を実装する前に解決すべき問題を特定したりするのに必要な情報を収集するうえで役に立ちます。また、ディレクトリ統合で必要な開発およびテストの時間を見積もる場合にも有用です。
サービス カタログ(Service Catalog)は、アクセスされる個人データおよび組織データを格納する各ディレクトリに対して「データソース」を定義します。データソースの定義には、外部ディレクトリへの接続で必要なすべての情報、およびそのディレクトリからの抽出情報が含まれています。
各外部ディレクトリに対して 1 つのデータソースを定義する必要があります。たとえば、開発と実稼働で別のディレクトリを使用することができます。また、サービス カタログ(Service Catalog)は LDAP ディレクトリ照会をサポートしており、データソースは参照チェーン内の各ディレクトリに対して定義する必要があります。
|
|
|
---|---|---|
現時点でサポートされているプロトコルは LDAP だけです。他のプロトコルを使用してディレクトリ情報を格納する場合は、この情報にアクセスするためのカスタム コードを作成する必要があります。 |
||
使用するディレクトリ サーバ製品を選択します。現時点でサーバがサポートされていない場合は、サーバにアクセスするためのカスタム コードを作成し、ディレクトリ情報を抽出する必要があります。 |
||
Simple はプレーン テキストのユーザとパスワードを表します。 SASL (Simple Authentication and Security Layer)も使用できますが、SASL は Sun ONE Directory Server でのみ機能します。 |
||
バインドの識別名フィールド。BindDN は、サービス カタログ(Service Catalog)がディレクトリ操作を実行するときに LDAP サーバに接続するために使用されます。 このデータソースを外部認証の手順で使用する場合は、[Options] 領域に EUA Bind DN を指定してこの値を変更します。詳細については、外部ユーザ認証(EUA)操作を参照してください。 |
||
認証で Simple または SASL を選択した場合に必要です。Bind DN に指定されたユーザのパスワードです。アカウントでパスワード エージングを使用する場合は、このパスワードを定期的に更新する必要があります。 |
||
ディレクトリ内の個人の検索を開始するディレクトリ。社内ディレクトリには多くのブランチが含まれることがあるため、ユーザ データに対してベース DN を指定することによって、ディレクトリ検索が最適化されます。 |
||
このフィルタは、使用する他の検索フィルタに追加されます。このフィルタを使用して、検索結果を効果的に変更できます。フィルタ式はカッコで囲む必要があります。たとえば、次のフィルタがあるとします。 |
||
1 つ以上のデータソースを照会用として追加できます。データソース検索で結果が返ってこない場合、システムは照会用のデータソースも検索します。照会は、検索でのみサポートされており、バインディングではサポートされていません。 循環照会は設定できません。循環照会は、あるデータソースが照会用として別のデータソースを持っており、同時にそのデータソースが、照会用として元のデータソースを使用しているものです。たとえば、データソース A が照会用としてデータソース B を持っており、データソース B が照会用としてデータソース A を持っている場合です。 |
「マッピング」は、外部ディレクトリからサービス カタログ(Service Catalog)へデータをどのように転送するか、という指示を与えるルール セットです。これにより、ディレクトリ内のソース属性と、サービス カタログ(Service Catalog)データベース内のターゲット フィールド間がマッピングされます。サービス カタログ(Service Catalog)データベースがディレクトリと同期されるとき、これらのルールを使用して、ディレクトリのデータを、指定されたターゲット フィールドへ転送します。
同じマッピングを複数のディレクトリ(データソース)に適用できます。
マッピングには、ユーザ/個人のプロファイルと、関連するすべてのエンティティ(住所、連絡先、場所、1 つ以上のグループ関係、1 つ以上の組織単位(OU)関係、1 つ以上の RBAC(ロールベース アクセス コントロール)ロール関係など)が含まれます。
個人のプロファイルには、7 個の必須フィールドが含まれており、これらのフィールドは以下のマッピング ワークシートの「必須」セクションにリストされています。これらのどのフィールドについても値を提供していないディレクトリ レコードはインポートできません。その他のフィールドで、個人プロファイルの一部になっているものもマップできます。詳細については、『 Cisco Prime Service Catalog Administration and Operations Guide 』の「Organization Designer」の章の「People」の項を参照してください。
個人プロファイルの大半のフィールドは、Service Catalog の機能を動作させるために使用されます。マッピングでは、マップされる属性が、フィールドに対して適切なソース値を提供していることを確認する必要があります。つまりこれらのフィールドに対して、フィールド名によって示されるよりも多くの情報、またはフィールド名に一致しない情報を指定しないようにします。
サービス カタログ(Service Catalog)には、標準の個人データを拡張するフィールドも含まれています。これらのフィールドは、以下の表では「拡張」として記載されており、Organization Designer の Person 情報の [Extensions] ページに表示されます。最も頻繁に必要になる拡張フィールドの一部には意味のある名前(たとえば、会社コードや部門)が割り当てられていますが、他のフィールドの名前は Custom 1 から Custom 10 であり、事前に考えられた意味を使用せずに、自由に使用できます。LDAP ディレクトリに追加の個人情報があり、Service Catalog で公開する必要がある場合は、この情報が含まれている属性を、個人の拡張フィールドの 1 つにマップします。
以下のワークシートの「Directory Attribute」カラムは、個人プロファイルのすべてのフィールドについて値を挿入する必要があります。このフィールドには、ディレクトリがデータを提供します。属性には次のいずれかを指定できます。
|
|
---|---|
マップされる LDAP 属性の戻り値の型は、long にする必要があります。サービス カタログ(Service Catalog)では他の形式はサポートされていません。 |
|
マップされる LDAP 属性の戻り値の型は、long にする必要があります。サービス カタログ(Service Catalog)では他の形式はサポートされていません。 |
|
マップされる属性は、次の形式のいずれかの値を返す必要があります。 2008 年 3 月以降、一般的に使用されていた 3 文字のタイム ゾーン指定(東部標準時は「EST」など)は使用されなくなりました。上記の形式についてサポートされている値のリストは、サポートされるタイム ゾーンを参照してください。戻り値が、正しい形式のどれにも一致しない場合、サービス カタログ(Service Catalog)はデフォルトのタイム ゾーンとして PST を使用します。 |
|
このフィールドはマネージャの ID を表します。詳細については、[マネージャのインポート(Import Manager)] 操作を参照してください。 |
|
数値を返す必要があります。このフィールドが Import Manager イベントで使用された場合、階層に従って Management Level が大きくなるようにしてください。たとえば、Junior Engineer と Senior Engineer の 2 つの指定があった場合、Junior Engineer に対して返される Management Level は、Senior Engineer の Management Level よりも小さくなる必要があります。 |
|
このマッピングを使用して、個人を 1 つ以上の組織単位に関連付けます。マッピングでは、複数の値が返されることがあります。このフィールドの場合、サービス カタログ(Service Catalog)は複数値の LDAP 属性によって返されたすべての値を使用します。このフィールドの入力は、次の形式のいずれかにする必要があります。 |
|
Organizational Unit List と同様です。返されるロールは、システム定義またはユーザ定義のいずれかです。 システム定義ロールの場合、名前は言語が米国英語のときにブラウザに表示されるものと同一にする必要があります。他の言語はサポートされていません。たとば、ユーザに「My Services Executive」ロールを関連付けるには、このロールが返される必要があります。 |
以下のワークシートを使用して、カスタム マッピングの要件を文書化できます。
|
|
|
統合イベントはサービス カタログ(Service Catalog)と外部ディレクトリや SSO プログラムとの間のインターフェイスです。外部プログラムまたはディレクトリにアクセスするサービス カタログ(Service Catalog)を使用しているときだけのものです。これらのイベントは、順次実行される複数の操作によって構成されています。
サービス カタログ(Service Catalog)は、4 つのディレクトリ統合イベントをサポートしています。
– 代理オーダーの個人検索(Person Lookup for Order on Behalf):あるユーザが他の個人の代わりにサービスを要求し、そのサービスのカスタマーとなっている個人を選択する必要があります。
– Person Lookup for Service Form :サービス フォームに [Person] フィールドが含まれ、これによってユーザが他の個人をサービス データの一部として指定できます。
– Person Lookup for Authorization Delegate :サービスの確認または承認を行うユーザが、他の個人を一時的な代理承認者として指定するために、自身のプロファイルの変更を要求します。
さまざまな種類の操作を実行するよう、イベントを設定できます。操作はそれぞれのイベントごとに一連の手順で指定され、これにより、呼び出される各操作の順序が決まります。
各操作は、カスタム コード インターフェイスの実装によってカスタマイズできます。
次のトリガー順序は、操作がトリガーされる順序を示しています。
ディレクトリ統合のログイン イベントが設定されていない場合は、デフォルトでログイン画面が表示され、アプリケーション データベースに対して入力されたクレデンシャル(ユーザ名とパスワード)が検証されます。
ディレクトリ統合イベントが有効になっている場合は、最初の手順として、次のいずれかの操作を使用して Login イベントを設定できます。
EUA が有効で、ユーザ名とパスワードの両方が渡されると、LDAP 認証がトリガーされます。提供されるパスワードは LDAP パスワードである必要があり、LDAP ユーザはセッションを所有します。
ユーザのクレデンシャルが検証されると、「ログイン(Login)」イベントには、外部データベースとサービス カタログ(Service Catalog)間でユーザ データを同期するために、次の操作が含まれることがあります。
シングル サインオン(SSO)ソリューションとの統合では、次の 2 つのメカニズムやプロトコルのいずれかを使用できます。
1. Active Directory Services(ADS)/NT LAN Manager(NTLM)ベースの認証済みユーザ
– サービス カタログ(Service Catalog)へのログインに、サードパーティの IM/AM/SSO 製品は必要ありません。
– ログインしたユーザの、POSIX 準拠 OS のクレデンシャルが、ブラウザによって サービス カタログ(Service Catalog)に返されます。
– これは、SSO の CGI ヘッダーによる統合とも呼ばれます。
– http プロトコルで要求ヘッダーを使用してサービス カタログ(Service Catalog)にログインするために、サードパーティの IM/AM/SSO 製品が必要です。
Portlet と Directory Integration の両方で SSO の使用を計画しているカスタマーについては、HTTP ヘッダー SSO のみがサポートされます。Directory Integration フレームワークのカスタム SSO プラグインはサポートされていません。
一部のユーザにシングル サインオンのバイパスを許可して、サービス カタログ(Service Catalog)に直接ログインできるようにすることが必要な場合があります。この機能は通常、次のユーザにとって必要です。
サービス カタログ(Service Catalog)には、ユーザがログイン画面にアクセスし、ユーザ名とパスワードを入力できるようなメカニズムが用意されています。newscale.properties ファイル(RequestCenter.war にあります)では「BackDoorURLParam」の値が指定されます。たとえば、次のようになります。
ログイン画面からサービス カタログ(Service Catalog)にアクセスするために使用する URL には、パラメータを含める必要があります。たとえば backDoorURLParam の上記の値について、サンプル URL は次のようになります。
<app_server_port> はアプリケーション サーバのポート番号です。
会社のガイドラインに従って BackDoorURLParam の値の期限切れについてポリシーを設定したり、サービス カタログ(Service Catalog)への管理アクセスの制御についてポリシーを設定したりすることは、管理者が行います。管理 URL でアクセスできるのは、対応する管理者設定によって「Site Administrator」ロールを付与されたユーザだけです。
管理者は、ユーザが URL に直接アクセス可能なことも確認する必要があります。以前は、サービス カタログ(Service Catalog)アプリケーションへのアクセスが、Web サーバまたはネットワーク設定パラメータを介した SSO ソフトウェアによるアクセスに制限されていました。
外部認証を使用して、すべてのサービス カタログ(Service Catalog)ユーザを社内ディレクトリで認証します。このようにすれば、ユーザ パスワードの同期を心配する必要もありません。
外部ユーザ認証は、ログインの試行後に、設定済みのシングル サインオン操作またはアプリケーションのログイン画面から行う必要があります。前の操作で取得した LoginId は EUA 操作で使用できます。ただし、このユーザを外部ディレクトリで検証する場合には、BindDN を見つけられるように、追加情報が必要になります。
EUABindDN 設定により、アプリケーションで、サインオンしようとしているユーザのバインド DN を自動的に推定できます。
Person Lookup のすべてのイベント(Order on Behalf、Service Form、Authorization Delegate)は同じ動作および設定オプションを使用します。
ディレクトリ統合のイベントが有効でない場合、[個人検索(Person Search)] ウィンドウはサービス カタログ(Service Catalog)データベースにある個人情報を検索します。個人が選択された場合、その情報が使用されます。個人情報は更新されません。
ディレクトリ統合イベントが有効になっている場合、Person Lookup イベントは次の操作によって設定できます。
Person Search 操作の設定により、検索条件を満たす人を表示するウィンドウの外観および動作が決まります。
個人をサービス カタログ(Service Catalog)にインポートするためには、すべての必須フィールドが正しい属性マッピングを持ち、空白以外の値を返す必要があります。必須の値が 1 つでも指定されていない場合は、デフォルトで、検索結果から対象となる人が除外されます。代わりに、そうした除外される人を検索結果に含めて、不完全な情報を持つ対象者としてフラグを付けることができます。
|
|
|
個人の検索を設定およびテストする場合には、ワイルドカード文字としてアスタリスク(*)の使用に注意する必要があります。
ユーザに対して透過的になるよう、システムは検索文字列の最後に、常に * を付けます。したがって、ユーザが [姓(Last Name)] フィールドに john と入力して [検索(Search)] をクリックすると、ディレクトリにある「John」、「Johnson」、「Johnson」など、姓が john という語で始まるすべての個人が返されます。
[個人の検索(Search Person)] ダイアログ ボックスの検索文字列に、明示的に * の文字を入力することもできます。次に、ワイルドカード検索の使用例をいくつか示します。
(注) 検索文字列内では、* は常にワイルドカード文字として扱われます。したがって、ユーザは文字 * を含むディレクトリの値を検索できません。その他のすべての特殊文字は、検索文字列で使用できます。
デフォルトでは、[人を選択します(Select Person)] ポップアップの [検索結果(Search Results)] ウィンドウに、ユーザの名、姓の順で表示されます。Administration モジュールで使用できる [個人(Person)] ポップアップの設定を変更すると、フィールドを表示に追加できます。
[個人のインポート(Import Person)] 設定は、アプリケーションの個人情報を、選択した個人に関する最新の情報で更新するか([個人検索(Person Search)] イベントで [個人のインポート(Import Person)] を使用する場合)、または、ログインした個人に関する最新情報で更新するか([ログイン(Login)] イベントで [個人のインポート(Import Person)] を使用する場合)を制御します。
サービス カタログ(Service Catalog)では、承認と確認を動的に割り当てることができます。たとえば、要求のドル値が指定されたしきい値を超えている場合、特定の部署の部長による承認が必要な場合があります。別の要求では、要求者の直属の上司による確認が必要な場合があります。
こうしたビジネス ルールを実装するには、従業員のマネージャ(サービスを要求できる人)が サービス カタログ(Service Catalog)データベースにも存在している必要があります。[マネージャのインポート(Import Manager)] 操作は、この要件(従業員のデータとともにマネージャ(上司)のデータをインポートすること)をサポートしています。
[マネージャのインポート(Import Manager)] 操作の動作を制御するには:
考えられるシナリオでは、個人の上司を一意に識別する単一の属性が、各個人のディレクトリ レコードに存在します。たとえば、従業員のディレクトリ レコードの属性 manager_email にマネージャの電子メール ID が含まれていると仮定します。マネージャの他の情報はありません。
別のシナリオとして、個人の上司の DN に完全に一致する属性がディレクトリ レコードに含まれている場合が想定されます。この属性の名前が manager であると仮定します。
|
|
||
|
|
直属の上司の承認を得なければならない要求の場合、ツリーの 1 つ上のレベルに上がる、「相対的な」検索が必要です。
または、特定の要求で部長の承認が必要、といった場合には、「絶対的な」検索が必要です。現在の個人の地位が「部長」になるまで、人(マネージャ)がインポートされます。上記の例の S. Person の場合、2 名の追加の個人、つまり直属の上司である A. Name と、その上司であり部長である J. Doe が必要です。T. Tom の場合、インポートが必要なのは 1 回だけです。
絶対検索を使用している場合(指定した役職の人物を見つけるまで、連続的により高い権限レベルを持つすべてのマネージャをインポート)、その役職に相当する数字を割り当てる必要があります。
既知の値よりも上位の上司と同期しない場合は、検索の終わりを設定することができます。複数の値は、#value1#, #value2# のような形式で指定できます。
たとえば、UID が「scarter」である個人よりも上位の上司はインポートしないとします。この個人の [スーパーバイザ(Supervisor)] 属性は、その電子メール(scarter@email.com)にマップされています。このケースでは、Search Terminator を #scarter@email.com# に設定します。ディレクトリ統合は、scarter@email.com で上司としてレコードが見つかるとすぐに、上司の同期を停止します。
制約条件が Maximum Level または Search Terminator のいずれかを満たすとすぐに、上司の同期は停止します。
カスタム コード操作を使用して、アプリケーションでサポートされていないルーチンを呼び出します。カスタム コード操作は、サービス カタログ(Service Catalog)の操作を置き換えたり、補完したりできます。
|
|
|
マッピング名を提供するために Java クラスを使用します。Java クラスの詳細については、Javadoc を参照してください。 |
次の内容のファイル jboss web.xml を、ディレクトリ ServiceCatalogServer/RequestCenter.war/'WEB-INF' に作成します。
(注) これは、</context-param> の後ろかつフィルタの前に追加する必要があります。
standalone-full.xml の変更、セキュリティ ドメインの追加
(注) security–domains を検索し、その後ろに次の内容を追加します。
(注) クラスタについては、ディレクトリ C:\Install_dir\dist\RequestCenter.war で、jboss-web.xml を作成し、web.xml を変更する必要があります。詳細については、『Cisco Prime Service Catalog 11.1.1』の「Applying Patch or Customizations to the WildFly Cluster Setup」の項を参照してください。
ディレクトリ統合の設定には Administration モジュールのディレクトリ オプションを使用する必要があります。基本的なプロセスは次のとおりです。
手順 1 管理権限を持つアカウントを使用してログインし、Administration モジュールを選択します。
手順 2 [設定(Settings)] タブをクリックします。
手順 3 [ディレクトリ統合(Directory Integration)] の横の [オン(On)] をクリックします。
手順 4 [カスタマイゼーション(Customizations)] 画面の下部で [更新(Update)] をクリックします。
これで、ディレクトリ統合が有効になりました。(ディレクトリ統合の有効化を参照)。
|
|
||
|
|
Administration モジュールの [Directories] タブを使用して、ディレクトリ統合の多数の設定を行います。
図 8-6 [Directory Integration] 領域
|
|
|
手順 1 管理権限を持つアカウントを使用してログインします。
手順 2 ドロップダウン メニューから、[Administration] を選択します。
手順 3 [ディレクトリ(Directories)] タブをクリックします。
[ディレクトリ統合(Directory Integration)] ページが表示されます。ディレクトリ統合が有効にされると、これらの設定が有効になります。
データソースは少なくとも 1 つ定義してください。新しいデータソースを追加するには、次の手順を実行します。
|
|
||
|
|
手順 1 Administration モジュールを選択してから [ディレクトリ(Directories)] タブをクリックして、[ディレクトリ統合(Directory Integration)] ページに移動します。
手順 2 ページ ナビゲータで [データソース(Datasources)] オプションをクリックします(まだ選択されていない場合)。
手順 3 [追加(Add)] をクリックします。新しいデータソースを追加する代わりに、既存のデータソースを編集するには、リストで目的のデータソースの横にある [編集(Edit)] をクリックします。
[データソース設定(Datasource Configuration)] 領域が拡大します。
手順 4 [データソース名(Datasource name)]、[データソースの説明(Datasource Description)]、および必要な設定に入力します。隣接領域のすべての設定にアクセスするには 、をクリックします。これらの設定の詳細については、データソース ワークシートを参照するか、または次の項を参照してください。
データソースへの接続に使用する接続プロトコルおよびユーザ クレデンシャルを指定します。
接続方式として [SSL] を選択した場合は、ディレクトリ統合システムの証明書を指定する必要があります。
|
|
||
|
|
手順 1 Administration モジュールを選択してから [ディレクトリ(Directories)] タブをクリックして、[ディレクトリ統合(Directory Integration)] ページに移動します。
手順 2 ページ ナビゲータで [データソース(Datasources)] オプションをクリックします(まだ選択されていない場合)。
手順 3 証明書を追加するデータソースの横にある [編集(Edit)] をクリックします。
手順 4 [証明書の追加(Add Certificate)] をクリックします。
手順 5 証明書に名前を付けます。証明書のエイリアス名には、スペースや特殊文字を使用しないでください。
手順 6 [証明書タイプ(Certificate Type)] ドロップダウン メニューから、証明書タイプを選択します。
手順 7 証明書フィールドに証明書の値(VeriSign などのベンダーから取得)を貼りつけます。
複数のデータソースを設定した場合は、選択したデータソースに対して、照会用システムとしてデータソースを指定することができます。この方法では、選択されたデータソースに対してシステムが検索を実行するたびに、照会用のすべてのデータソースも検索されます。
照会用データソースは、一致が見つかるまで指定された順序で検索されます。
検索条件で 1 つ以上のレコードが返されたときに、一致が見つかったことになります。
照会用データソースは、通常、ディレクトリ情報が複数のディレクトリ間で分割される場合に使用されます。たとえば、企業の複数の事業部で、それぞれ独自のディレクトリを保持することができます。
|
|
||
|
|
手順 1 Administration モジュールの [Directory Integration] ページに移動します。
手順 2 ページ ナビゲータで [データソース(Datasources)] オプションをクリックします(まだ選択されていない場合)。
手順 3 照会用データソースを設定するデータソースの横にある [編集(Edit)] をクリックします。
手順 5 [照会用データソース(Referral Datasource)] 領域が表示されます。[データソース名(Datasource Name)] ドロップダウン メニューからデータソース名を選択し、[マッピング名(Mapping Name)] ドロップダウン メニューからマッピング名を選択します。
必要な設定手順をすべて完了すると、次はディレクトリ統合の接続をテストできます。
|
|
手順 1 Administration モジュールの [Directory Integration] ページに移動します。
手順 2 ページ ナビゲータで [データソース(Datasources)] オプションをクリックします(まだ選択されていない場合)。
手順 3 データソース名の左にあるチェック ボックスをオンにして、テストするデータソースを選択します。
手順 4 [テスト接続(Test Connection)] をクリックします。
接続が成功した場合は [テストステータス(Test Status)] カラムに OK と表示され、接続が失敗した場合は が表示されます。
Administration モジュールの [ディレクトリ(Directories)] タブで [マッピング(Mappings)] 領域を使用して、サービス カタログ(Service Catalog)データをディレクトリ サーバ データにマップします。
マッピングを設定するには、マッピングの設定を参照し、次の手順に従います。
|
|
||
|
|
手順 1 Administration モジュールの [ディレクトリ統合(Directory Integration)] ページに移動します。
手順 2 ページ ナビゲータで、[マッピング(Mappings)] オプションをクリックします。
手順 3 新しいマッピングを追加するには、[追加(Add)] をクリックし、既存のマッピングを編集するにはリストの目的のマッピングの横にある [編集(Edit)] をクリックします。
[マッピング設定(Mapping Configuration)] 領域が拡大します。
手順 4 マッピング ワークシートに記載されている要件に基づいて、マッピングの名前、説明、および属性を設定します。[Person Data] セクションに表示された、先頭にアスタリスク(*)が付いているマッピングは必須です 。ボタンをクリックしてオプションのマッピングを設定し、[Optional Person Data Mappings] セクションを展開することもできます。
ここでは、指定可能なマッピング タイプについて説明し、正しいサンプルのマッピングを示します。また、式マッピングの例についても説明します。次の表に、サポートされているマッピング タイプを示します。
|
|
属性の組み合わせをフィールドにマッピングします。# を使用して各属性名を区切ります。マッピングはリテラルを含むことができます。次に例を示します。 |
|
式では、正規表現とパターン マッチングを使用してマッピングが得られます。詳細については、式マッピングを参照してください。 |
|
簡易、複合、または式の各マッピングで目的とする機能を提供できない場合は、Java マッピングを使用します。これには、Java クラスを記述し、アプリケーション サーバ上の適切なディレクトリに、コンパイルしたクラス ファイルを配置する、という作業が含まれます。詳細については、Java クラス マッピングを参照してください。 |
次の表は、必須フィールドに対する簡易マッピングと複合マッピングの例を示しています。
|
|
式マッピングを使用すると、式が一致するパターン(正規表現)に基づいて、値を条件付きで属性に割り当てることができます。システムの式マッピングは Perl5 Regular Expression Language を使用し、Java の条件演算子に似た構文と組み合わせて、一致させるパターンを指定します。 構文 :
パターンのセットに対応する、パイプ(|)で区切られた値のセットです。それぞれの値は、式が対応するパターンと一致した場合の戻り値を指定します。 |
|
<expression> が <pattern1> に一致すると、<value1> を返します。
<expression> が <pattern2> に一致すると、<value2> を返します。
<expression> がどのパターンにも一致しない場合、<default> を返します。
各要素(expression、pattern、または value)には、# 記号で区切って、ディレクトリの属性名を含めることができます。たとえば、パターンを「#givenName#_#sn#」のように指定できます。ここで #givenName# と #sn# はどちらも属性名です。
また、括弧を使用して一連のパターン要素を 1 つの要素にグループ化できます。括弧内のパターンと一致した場合、$1、$2 などの形式で後方参照を使用して、以前に一致したパターンを参照することができます。
ディレクトリ統合に適用される式の簡単な利用法として、ディレクトリ内でコード化されている 1 つ以上の値を、よりわかりやすい記述、または広範なカテゴリに変換することができます。たとえば、サービスによっては、従業員と請負業者の区別が必要になることがあります。costCenter 属性は、「000000」が請負業者用です。したがって、[Employee Type] フィールドに次の式を適用することができます。
もうひとつの式の利用法は、ソース属性が空白の場合に、フィールドにデフォルト値を入力することです。これは多くの場合に、ディレクトリ データが標準化できるまでの「応急処置」となります。また、たとえば外部の請負業者に部門が割り当てられない場合などの標準にすることができます。次の式を [Home OU] フィールド(マッピングの必須フィールド)に適用することができます。
この式では、該当する場合に DeptLevel2 属性を使用することも、ユーザの Home OU に対して事業部門のデフォルトを「Unknown」にすることもできます。
同様に、この式を使用して、一連の入力値を、異なる戻り値のセットに変換できます。これは、case 文、またはネストされた if/then 構造と同じです。たとえば、次の式を [Locale ID] フィールドに適用し、ユーザのロケーションに基づいて、そのユーザに言語を割り当てることができます。
ユーザの国が United States の場合は、言語を米国英語に設定し、Germany の場合は言語をドイツ語に設定します。その他の国の場合は、言語を米国英語に設定します。
正規表現では、ソース属性の長さ、および英数字で構成されているかどうかをチェックできます。たとえば、郵便番号が数値データ タイプとして格納され、先行ゼロが切り捨てられることがあります。先行ゼロを回復するには、[Company Postal Code] フィールドに次のような式を適用できます。
postalCode 属性がちょうど 4 桁の場合は、属性に先行ゼロの値を追加します。これにより、郵便番号 1701 は 01701 に変換され、特定のパターンに一致しないすべてのソース値は、変更されずにそのままになります。
正規表現の同様の使用法として、属性値の形式が、予想したパターンと一致するかをチェックする、というものがあります。有効なマネージャのユーザ ID は、必ず 2 文字と、それに続く一連の数字で構成されている場合について考えてみましょう。たとえば、有効な ID は fd1024 や ID3839 となります。次の式を使用できます。
パターンと照合するためにあらゆる試行を作成する前に、Doe、Jane などのディレクトリ レコードの姓および名が 1 つの文字列に組み合わされます。
パターンの一部を抽出するには、括弧および後方参照を組み込むと役立ちます。たとえば個人が所属している組織は、識別名(dn)属性内に組み込まれることがよくあります。
[Home Organizational Unit] フィールドにマップされる式は、次のような形式になります。
戻り値「Corporate」は後方参照値 $1 で、これは最初の括弧 ([a-zA-Z]+) 内の式で照合したパターンに相当します。
複数のフィールドが含まれているオーバーロード属性を解析するために、後方参照変数の使用が必要になることがあります。たとえば、1 つの属性に、個人の勤務先住所(ビル名、階数(レベル)、オフィスなど)を含めることが可能です。
異なる後方参照変数を、次の値として使用すると、同じパターンを使用して、式内で 3 つの要素を照合することができます。
ディレクトリ データをフィールドにマップするためのカスタム Java クラスを実装するには、Java プログラミングをよく理解し、Java 開発環境が用意されている必要があります。
すべてのカスタム マッピング クラスは、“ディレクトリ統合でのカスタム コードの使用” sectionのガイドラインに従っています。マッピング クラスは IEUIAttributeMapping インターフェイスを実装する必要があります。
開発者は以下のガイドラインに従って、カスタム コード モジュールをテストおよびインストールする必要があります。
1. 最適な Java IDE をインストールし、カスタム マッピング コードを開発するためのプロジェクトをセットアップします。
2. 要件を満たすようにカスタム コード ファイルを編集します。
4. カスタム Java クラスは、Service Catalog サービスがアクセスできるように、サービス カタログ(Service Catalog)の Web アーカイブ(war)にインストールする必要があります。RequestCenter.war/WEB-INF/classes にディレクトリを作成し、パッケージと一致するようにします。このようなディレクトリは通常、次のような名前になります。
com/newscale/client/<clientname>(com/newscale/client/aib など)。
5. CustomMapping.class ファイルを、前の手順で作成したディレクトリにコピーします。
6. Service Catalog サービスを再起動します。
7. クラス ファイルの完全修飾名を Mapped Attribute として指定し、フィールドに値が挿入されるようにします。
マッピング テスト機能を使用して、自身のデータ マッピングが正しく設定されていること、およびディレクトリ サーバから正しい値を取得することをテストします。
ディレクトリ マップのテスト機能を有効にするには、マッピング テストの有効化を参照し、次の手順に従ってください。
|
|
||
|
|
手順 1 Administration モジュールの [Settings] タブをクリックして [Settings] ページを表示します。
手順 2 ページ ナビゲータで、[デバッグ(Debugging)] オプションをクリックします。
手順 3 [ディレクトリマップテスト(Directory Map Testing)] 設定の横にある [オン(ON)] をクリックします。
データ マッピング テスト機能が有効になります。[Data Mapping] タブにアクセスすると、マッピング テスト コントロールに示すように、次の追加機能が表示されます。
|
|
||
|
|
||
|
|
手順 1 [Mapping] ページが表示されていない場合は、[Mappings] をクリックします。
手順 2 テストするマッピングの横にある [編集(Edit)] をクリックします。
手順 3 [テストするデータソースの選択(Choose a Datasource for testing)] ドロップダウン メニューから目的のデータソースを選択します。
手順 4 [テスト値(Test Values)] カラムにテスト値を入力します。簡易、複合、Java、および式の各マッピングを使用できます。
手順 6 [Test Values] カラムにテスト値が表示され、ページの下部に結果の概要が示されます。
(注) [Fetch] により値が返されるのは 1 つのデータソースのみで、照会先は検索されません。照会先の検索が統合されているとデバッグが難しいため、便宜上そのようになっています。
手順 7 [取得(Fetch)] ボタンの右にある [クリア(Clear)] をクリックして、希望するマッピングが設定されるまで、新しい値をさらに試します。
Administration モジュールの [Directories] タブで [Events] 領域を使用して、次のイベントに対するディレクトリ統合の動作を設定します。
イベントを設定するには、イベントの設定を参照し、次の手順に従います。
手順 1 Administration モジュールの [Directory Integration] ページに移動します。
手順 2 ページ ナビゲータの [イベント(Events)] をクリックし、[イベント(Events)] ページを表示します。
手順 3 設定するイベントのタイプの横にある [編集(Edit)] をクリックします。
[Event Configuration] 領域が表示されます。
手順 4 [イベントステータス(Event Status)] ドロップダウン メニューから [有効(Enabled)] を選択し、イベントを有効にします。
手順 5 [Add step] をクリックして手順を追加し、選択したイベントが発生したときにシステムで開始されるようにします。
手順 7 [オプション(Options)] をクリックして、選択した操作に関連付けるオプションを設定します。[Options] 領域が表示されます。[オプション(Options)] 領域は、選択した操作によって異なります。使用できる操作、およびその操作のオプションについては、次の項で詳しく説明します。
手順 8 関連付けるオプションを設定します。使用できる操作および操作の設定用のオプションの詳細は、この章のディレクトリ イベントに関する項を参照してください。
手順 9 [Update] をクリックし、追加する各手順および操作に対して、これらの手順を繰り返します。
|
|
||
|
|
||
|
|
||
|
|
ディレクトリ統合フレームワークは、「Login」および「Person Lookup」イベントの柔軟性を利用し、カスタマイズできるよう設計されています。
Administration モジュールの [Directories] タブでは、すべてのイベントに対する標準操作を使用できます。そのような標準の操作としては、SSO、External User Authentication、Import Person、Import Manager、および Person Search などがあります。
これらの標準操作ではビジネス シナリオを満たせない場合、[Directories] タブには、カスタム Java コードを実行するためのインターフェイスも用意されています。このカスタム コードは、この章に記載されたインターフェイスに準拠している必要があり、サービス カタログ(Service Catalog)が公開している API を使用して、すべてのカスタマイズ ソリューションを開発する必要があります。
以下に、イベントの操作をカスタマイズできるシナリオの有効な使用例を示します。
|
|
ベンダーと SSO との統合をサポートするために、ユーザのクレデンシャルを取得するカスタム コード SSO 操作を提供する。 |
|
カスタム コード External Authentication、およびカスタム コード Import Person 操作を提供する。 |
ディレクトリ統合カスタム コード フレームワークでは、外部データソースのレコードから個人またはユーザ プロファイルの特定のフィールドに対する、複雑な取得ロジックを提供するよう実装可能なインターフェイスも定義されます。
ディレクトリ統合の Public API およびインターフェイスには次のものが含まれています。
一般的なカスタム コード プロジェクトには、次のタイプのアクティビティが含まれています。
次の ディレクトリ統合の操作 に、ディレクトリ統合の操作を詳しく示します。
|
|
|
|
外部データソースからサービス カタログ(Service Catalog) データベースに、マネージャまたはマネージャのチェーンをインポートする |
標準操作とカスタム コード操作の混在と照合、または置換も、ディレクトリ統合フレームワークでサポートされています。次の表に示すように、サービス カタログ(Service Catalog)は、1 つのイベントでさまざまな操作の組み合わせをサポートしています。独自にカスタマイズしたコードと、これらのインターフェイスを実装しやすくするよう設計された、サービス カタログ(Service Catalog)の公開 API を使用できます。
カスタム コードの設計および開発エンジニアは、ディレクトリ統合フレームワーク、公開 API、およびカスタム コード インターフェイスについて理解することが重要です。これらについては、この章で詳しく説明します。
次の 表 8-16 は、カスタム コード操作のメソッド、イベント、および操作タイプ間の関係を表しています。次の 表 8-16 に記載されていない組み合わせはサポートされていません。
|
|
|
|
イベント内で設定されている操作のカスタム実装を提供する場合、「カスタム コード操作インターフェイス」を実装する必要があります。
カスタム コード操作インターフェイスは、特定の操作がトリガーされたときに呼び出されるコールバック メソッドを定義します。どのメソッドが呼び出されるかは、操作で選択された操作タイプによって決まります。詳細については、カスタム コード操作のメソッド、イベント、およびタイプの表を参照してください。カスタム コードの操作インターフェイスで定義されるすべてのメソッドは、同じパターンに従っています。
以下のリストで、「**」は次のいずれかの操作タイプで置き換える必要があります。
1. **OperationDTO:このオブジェクトには、Administration モジュールの [Directories] タブで操作をどのように設定したか、についての情報が含まれています。これには、マッピングおよびデータソースの情報が含まれます。
2. **OperationContext:Context オブジェクトを使用して、メソッドの呼び出しで情報を共有します。ディレクトリ統合フレームワークは、1 つのコンテキスト オブジェクトに情報を格納しますが、これは同じ HttpServletRequest の呼び出しのときに他のコンテキスト オブジェクトで使用することができます。
a. setLocalContextObject および getLocalContextObject を使用すると、結果の一部にはならないカスタム情報を設定できます。
b. get**Result を使用すると結果オブジェクトが取得されます。結果オブジェクトには、イベント要求全体で発生したことに関するすべての情報が含まれています。結果には、製品化されたインポートでサポートされている情報が含まれています。LocalContext オブジェクトを使用して、製品化された操作の実装で予期しなかったオブジェクトを格納します。
3. Request:HttpServletRequest です。
4. **ImportAPI:このオブジェクトを使用して個人をインポートします。詳細については、Javadoc を参照してください。
5. **LDAPAPI:この API を使用して LDAP クエリーを作成します。詳細については、Javadoc を参照してください。
**Result。カスタム タスクを実行すると、API は、有効な戻りタイプに結果を挿入して返します。関連するプロパティを更新した後、OperationContext から取得される、同じ結果オブジェクトが返されます。結果オブジェクトの新しいインスタンスが返されると、予期しない動作が生じることがあります。
次の 表 8-17 は、予想される入力または戻りと、各コールバック メソッドのパラメータにあるオブジェクトの関係を示しています。
実装クラスをコンパイルするには、すべてのメソッドを実装する必要があります。制限されている操作タイプのみをカスタマイズする場合、その操作タイプに関連しないメソッドの、空の実装を提供する必要があります。
たとえば、カスタマイズされた SSO のみを対象にする場合は、getCredentials メソッドの完全な実装を提供します。その他のすべてのメソッドについては、ヌルを返します。
システムはインターフェイスのインスタンスをプールできます。また、複数のスレッドから同時にアクセスすることができます。したがって、インスタンスはステートレスにしておくことを推奨します。
これは、ログイン イベント SSO、EUA、Import Person、Import Manager、およびカスタム コード操作をカスタマイズするために、カスタム コードが実装する必要のあるインターフェイスです。
SSO カスタム コード操作の主な目的は、Remote NTML/IWA のタイプが Sign-On の場合に、Sign-On、または CGI ヘッダー(CGI 変数 REMOTE_USER)からログイン名を取得し、返すことです。
表 8-16 に概要を示すように、ISignOn インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、getCredentials メソッドの完全な実装を提供してください。詳細な仕様については、ISignOn インターフェイスのマニュアルを参照してください。
以下に、getCredentials メソッドを実装するためのガイドラインを示します。これらのすべてのガイドラインを実装する必要はありません。以下の概説では取り上げていませんが、カスタマイズによっては追加の要件が存在する場合があります。
IEUIEventSSOOperationDTO.getEventSsoDTO() で取得された SSO 操作のオプションはヌルになる可能性があります。カスタム コード操作に対しては、Administration モジュールが SSO オプションを受け入れないからです。
EUA カスタム コード操作の主な目的は、外部システムに対してユーザを認証することです。
表 8-16 に概要を示すように、ISignOn インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、authenticate メソッドの完全な実装を提供してください。詳細な仕様については、ISignOn インターフェイスのマニュアルを参照してください。
以下に、EUA 操作を実装するためのガイドラインを示します。これらのすべてのガイドラインを実装する必要はありません。以下では取り上げていませんが、カスタマイズによっては追加の要件が存在する場合があります。
– 文字列から、プレフィックス「!@^_」およびサフィックス「_^@!」を削除します。
– 上記から得られたテキストに対し、Java の Base64 復号化方式を使用します。
IEUIEventEUAOperationDTO.getEventEuaDTO() で取得した EUA 操作オプションは空になります。カスタム コードの操作に対しては、Administration モジュールが EUA オプションを受け入れないからです。
[個人のインポート(Import Person)] 操作の主な目的は、外部システム(ディレクトリ サーバや外部データベースなど)からサービス カタログ(Service Catalog)アプリケーションにユーザをインポートまたは更新することです。
表 8-16 に概要を示すように、ISignOn インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、importPerson メソッドの完全な実装を提供してください。詳細な仕様については、ISignOn インターフェイスのマニュアルを参照してください。
以下に、Import Person 操作を実装するためのガイドラインを示します。これらのすべてのガイドラインを実装する必要はありません。以下では取り上げていませんが、カスタマイズによっては追加の要件が存在する場合があります。
IEUIEventImportPersonOperationDTO.getImportPersonDTO() メソッドによる Import Person 操作のオプションは空です。カスタム コードの操作に対しては、Administration モジュールが Import Person オプションを受け入れないからです
[マネージャのインポート(Import Manager)] 操作の主な目的は、ディレクトリ サーバなどの外部システムから、個人の上司チェーンをサービス カタログ(Service Catalog)にインポートまたは更新することです。
表 8-16 に概要を示すように、ISignOn インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、importPerson メソッドの完全な実装を提供してください。詳細な仕様については、ISignOn インターフェイスのマニュアルを参照してください。
以下に、Import Manager 操作のガイドラインを示します。
マネージャ チェーンをインポートする場合は、個人よりも先に最上位のマネージャをインポートすることを推奨します。これにより、personDTO が個人のマネージャとのリンクを更新するための不要な更新が防止されます。
IEUIEventImportManagerOperationDTO. getImportManagerDTO() で取得した Import Manager 操作オプションは空になります。カスタム コードの操作に対しては、Administration モジュールが Import Manager オプションを受け入れないからです。
カスタム コード操作の主な目的は、アプリケーションの他のどの場所にも示されていない、必要なカスタム操作を実行することです。
これは、Person Search イベントの Person Search、Import Person、Import Manager、およびカスタム コード操作をカスタマイズするために、カスタム コードが実装する必要のあるインターフェイスです。
実装クラスは、Administration モジュール > [ディレクトリ(Directories)] タブ > [イベント(Events)] で設定されます。サービス カタログ(Service Catalog)アプリケーション内の次の場所で個人を検索するために設定することができます。
Person Search 操作の主な目的は、ディレクトリ サーバなどの外部システムからユーザを検索することです。
カスタム コード操作 の表に概要を示すように、IPersonSearch インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、search メソッドの完全な実装を提供してください。詳細な仕様については、ISignOn インターフェイスのマニュアルを参照してください。
以下に、Person Search 操作のガイドラインを示します。
IEUIEventPersonSearchOperationDTO.getPersonSearchOperationDTO() メソッドで取得した Person Search 操作のオプションは空です。これは、カスタム コードの操作に対しては、Administration モジュールが Person Search オプションを受け入れないからです。
カスタム コード操作 の表に概要を示すように、IPersonSearch インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、importPerson メソッドの完全な実装を提供してください。詳細な仕様については、IPersonSearch インターフェイスのマニュアルを参照してください。
カスタマイズする手順は、Login イベントに対する Import Person 操作のカスタマイズと同様です。
カスタム コード操作 に概要を示すように、IPersonSearch インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、search メソッドの完全な実装を提供してください。詳細な仕様については、IPersonSearch インターフェイスのマニュアルを参照してください。
カスタマイズする手順は、Login イベントに対する Import Manager 操作のカスタマイズと同様です。
カスタム コード操作 に概要を示すように、IPersonSearch インターフェイスを実装する Java クラスを提供する必要があります。このインターフェイスでは、performCustom メソッドの完全な実装を提供してください。詳細な仕様については、IPersonSearch インターフェイスのマニュアルを参照してください。
カスタマイズする手順は、Login イベントに対するカスタム操作のカスタマイズと同様です。
簡易、複合、または正規表現の各属性マッピングでは不十分な場合は、ディレクトリ統合属性マッピングでカスタム Java クラスを使用することができます。
これは、ディレクトリ属性マッピングをカスタマイズするために、カスタム コードが実装する必要のあるインターフェイスです。カスタム マッピング クラスの主な目的は、ディレクトリ サーバから取得した属性値をカスタマイズすることです。
実装クラスは、Administration モジュール > [Directories] タブ > [Mappings] で設定され、マッピングのすべての属性に対して設定できます。
図 8-16 属性マッピングに対するカスタム Java クラス
以下に、カスタム Java クラスのマッピング クラスを使用するためのガイドラインを示します。
これは、製品に組み込まれているディレクトリ サーバ(LDAP)接続機能と統合するために、シスコが提供する API ラッパーです。
この API が提供する機能は、ディレクトリ サーバに対する認証、およびクエリーのみです。この API は、サービス カタログ(Service Catalog)でサポートされているすべてのディレクトリ サーバをサポートします。
通常、Directory Server API はディレクトリ統合のデータソースおよびマッピング設定から機能し、クエリー用の接続情報、フィルタ、および属性を手作業でコーディングする必要がありません。
一般的に、LDAP API を使用するには、LDAPConfigInfo オブジェクトも必要です。この目的のためには、すべてのデータソースおよびマッピングから EUIUtil.get LDAPConfigInfo() を使用します。
ILDAPApi のインスタンスを作成する必要はありません。両方のカスタム コード API インターフェイス(ISignOn と IPersonSearch)のすべてのメソッド引数で使用できます。
ディレクトリ統合ユーティリティクラス(EUIUtil)は、Administration モジュールで設定されたデータソースおよびマッピングを、Directory Server API が認証、検索、およびクエリー機能の入力として使用できる形式に変換します。
LDAPConfigInfo クラスのオブジェクトは、ディレクトリ サーバ API に渡す必要がある、次のすべての設定オプションをカプセル化します。
上級ユーザの場合は、何らかの設定を上書きする必要がある場合に、すべての設定に対する getter および setter が LDAPConfigInfo から提供されます。これらのメソッドの詳細については、このクラスに関する Javadoc を参照してください。
ILDAPApi は、ディレクトリ サーバ上で次の 2 つの基本操作を提供するメイン インターフェイスです。
ILDAPApi インターフェイスは、サービス カタログ(Service Catalog)全体で LDAP と一貫性を保って対話を行うためのメソッドを提供します。
ILDAPApi.query(…) メソッドを使用してディレクトリ サーバに対してクエリーまたは検索を行うと、LDAPEntryBean のコレクションとして結果が返されます。
この API を使用すると、個人プロファイルのインポートまたは更新、OU またはグループの作成、OU、グループ、またはロールへの個人のリンクまたはリンク解除を行えます。この API は、個人をインポートするためのトランザクション管理、および SQL データソースへの接続もサポートしています。この API には、CnfParams テーブルから読み込むためのメソッドも含まれています。
個人のインポート/更新 API インターフェイスは、次のためのメソッドを提供します。
SQL データソースに接続するために Java クラスをカスタマイズするには、次の手順に従います。
手順 1 DatasourceName を渡すことで、ISignOnImportPersonAPI から SQL データソース データベースへの接続を取得します。DatasourceName には、newscale.properties ファイルの「DatasourceJNDIPrefix」プロパティで定義されているように、JNDI プレフィックスが付加されます。
手順 2 JDBC ステートメントを使用してクエリーを実行するには、上記の接続を使用します。
手順 3 try ブロックの最後で、接続オブジェクトを直接コミットします。
手順 4 障害または例外が発生したときに接続をロールバックするには、ISignOnImportPersonAPI をコールします。
手順 5 final ブロックで、ステートメントを直接閉じて ISignOnImportPersonAPI をコールし、接続を解放して接続プールに戻します。
カスタム コードをコンパイルおよび導入する手順を、次に示します。
手順 1 build.xml ファイルの例に示す build.xml ファイルをコピーして、任意のフォルダ(C:\CustomCode など)に貼り付けます。
手順 2 build.xml ファイルを編集して、RequestCenter.war を使用できるフル パスを指すようプロパティ「rcwar.dir」を変更します。
手順 3 build.xml を編集して、servlet-api.jar を使用できるフル パスを指すようプロパティ「javax.servlet.dir」を変更します。これはアプリケーション サーバに特有の設定です。
手順 4 カスタム コード Java ファイル用に、(C:\CustomCode\src などの)サブフォルダを作成します。
手順 5 「com.newscale.SignOnCustomCode」などのパッケージ名を付けてカスタム コードを作成し、SignOnCustomCode.java ファイルを C:\CustomCode\src\com\newscale\SignOnCustomCode.java ディレクトリに配置します。
手順 6 C:\CusomCode フォルダのコマンドラインから「ant」を実行します。
手順 7 ant のビルド ファイルは、「src」サブフォルダの下のすべての java ファイルをコンパイルし、クラス ファイルを「out」サブフォルダに配置します。
手順 8 ant のビルド ファイルは、「RequestCenter.war\WEB-INF\classes」フォルダにもクラス ファイルを導入します。
カスタム コードの開発、コンパイル、および導入が終了したら、そのコードを使用するように Administration モジュールを設定する必要があります。設定には、いつ(どのイベントで)、どの操作で、どの順序(ステップ)でカスタム コードを呼び出すかを指定します。
Administration モジュールの [Settings] タブでこの設定をオンにして、Directory Integration が有効になっていることを確認します。Directory Integration をオンにする方法は、ディレクトリ統合の有効化に説明があります。
カスタマイズされているかどうかに関係なく、大半の操作ではデータソースとマッピングが必要です。このため、最初に Directory Administration の 2 つの領域を設定する必要があります。
データソースは LDAP などの外部サーバであり、ユーザのデータが現在格納されています。サービス カタログ(Service Catalog)はデータソースにアクセスする必要があります。データソースが必要ないカスタム操作は SSO だけです。
データソースの設定の詳細については、データソースの定義およびデータソース情報の設定を参照してください。
外部データソースを設定したら、サービス カタログ(Service Catalog)で使用できる個人関連のデータを、LDAP ディレクトリ(または他の外部データソース)内のデータにマップする必要があります。これらのマッピングでは、イベントおよび操作のシーケンスで、どこを検索するか、および何を取得するかがサービス カタログ(Service Catalog)に指示されます。
Login 以外のすべてのイベントに対するシングル サインオン(SSO)および認証の操作のカスタマイズは、不正なアクションとみなされます。これらの操作が必要になるタイミングは他にありません。外部の LDAP サーバから、アプリケーションにユーザがサインインして認証された後は、プロセスを複製する必要がありません。
外部データソースへの接続が必要なすべてのイベントは、ここで設定されます。このガイドに記載されているカスタム コード API を呼び出す場合には、カスタム操作が不正な順序で発生したり、失敗したりしないよう、各イベントに対する操作の順序を考えることが重要です。
手順 1 ナビゲーション ペインで [イベント(Event)] をクリックします。
手順 2 カスタマイズするイベントの [編集(Edit)] をクリックします。
手順 3 イベントが無効になっている場合は、ドロップダウン メニューを使用して [有効(Enabled)] を選択します。
手順 4 [Add step] をクリックして操作を追加します。ここでは、ステップを必要なだけ追加できます。また、各ステップの詳細を設定してから、その次のステップを追加および設定してください。
手順 5 ドロップダウン メニューから [操作(Operation)] を選択します。
手順 6 ドロップダウン メニューから [マッピング(mapping)] および [データソース(datasource)] を選択します。
手順 7 [追加オプション(Additional Options)] の見出しの下で、[オプション(Options)] をクリックします。
手順 9 ステップの追加オプションを閉じるには、[Close] をクリックします。
手順 11 イベント用のすべてのステップを保存するには、[Update] をクリックします。
前述のステップで、操作として [カスタムコード(Custom Code)] を選択し、操作タイプとして [カスタムコード(Custom Code)] を選択した場合は、未定義のカスタム コードをコールしているため、設計する必要があります。
シスコが提供しているカスタム コード テストの例では、Java クラス「performCustom」を使用して、独自のカスタム コードを定義できます。
すべてのカスタム コードは、サービス カタログ(Service Catalog)インストーラに対するカスタマイズとしてパッケージ化する必要があります。これにより、インストールの更新が必要な場合や、新しいサイトをインストールする場合に、カスタマイズを再適用できます。
カスタム コードをパッケージおよび導入するための方法は、サービス カタログ(Service Catalog)をホストしているアプリケーション サーバによって異なります。カスタム コードの設定の詳細については、『 Cisco Prime Service Catalog 12.0 アダプタ統合ガイド 』および『 Cisco Prime Service Catalog Administration and Operations Guide 』を参照してください。
また、ホーム OU がサービス カタログ(Service Catalog)に存在しない場合に、個人のホーム OU を事業部門として作成します。
(注) このソリューションでは、データソースをアプリケーション サーバ上に設定する必要があります。以降では、EUIPersonSearchSQL クラスの設定および使用法について説明します。
個人プロファイルの必須フィールドのデータが含まれている(または、これらのフィールドの値を得ることができる)SQL テーブルは、データソースとして使用できます。次に、この例で使用されるテーブルの定義を示します。
次に、上記のテーブル定義で使用するサンプル データの一部を示します。
Directory Integration インターフェイスを使用するには、LDAP データソースを設定しておく必要があります。LDAP は、データソースでサポートされている唯一の UI です。データソースなしでマップを作成できますが、LDAP データソースなしではテストできません。
コンテナで管理されるデータソースの設定は、コンテナによって異なります。データソースの設定の詳細については、『 Cisco Prime Service Catalog Installation and Upgrade Guide 』を参照してください。
EUIPersonSearchSQL クラスに対するマッピングを作成する必要があります。
このマッピングには、Custom 9 として JNDI への参照が含まれ、Custom 10 にはテーブル名の参照が含まれています。このようなマッピングを使用すると、「select * from tablename」のような簡単なクエリーを実行し、JDBC のメタデータ機能を使用して、マッピングに基づいてカラムを選択することができます。
「Person Lookup for Order on Behalf」イベントには 2 つのステップがあり、最初のステップでは「Person Search」操作を実行する必要があります。クラスの名前はマッピングとして与えられます。パッケージの仕様全体は、Java クラスとして与えられます。
「Person Lookup for Order on Behalf」イベントの 2 番めのステップは、選択した個人のインポート(「Import Person」)です。この設定では同じ Java クラスを使用しますが、カスタム コード操作タイプは異なります。ドロップダウン メニューのカスタム コード操作タイプは、インターフェイス クラスでコールされるメソッドに対応したものとなります。
図 8-20 イベントのステップ 2:カスタム Import Person 操作
タイム ゾーンのマッピングにサポートされているタイム ゾーンは、次のとおりです。
|
|
---|---|