Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド

11g リリース1 (11.1.1)

B66696-01(原本部品番号:E12491-03)

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle Access Managerの新機能

- 製品およびコンポーネントの名前の変更

- Oracle Access Manager 11g Software Developer Kit

1 本書の概要

- 1.1 第2章: Access SDKおよびAPIの概要

- 1.2 第3章: カスタム認証プラグインの作成

- 1.3 第4章: Oracle Security Token Serviceモジュール・クラスの記述

- 1.4 Java APIリファレンスの概要

2 Access SDKおよびAPIの概要

- 2.1 Access SDKの概要

- 2.2 Access SDKパッケージおよびリソースの場所の確認

- 2.3 用途、機能および新機能

- 2.4 メッセージ、例外およびロギング

- 2.4.1 メッセージ

- 2.4.2 例外

- 2.4.3 ロギング

- 2.5 アクセス・クライアントの構成およびデプロイ

- 2.5.1 構成要件

- 2.5.2 必要な構成ファイルの生成

- 2.5.3 SSL証明書およびキー・ファイル

- 2.5.3.1 簡易トランスポート・セキュリティ・モード

- 2.5.3.2 証明書トランスポート・セキュリティ・モード

- 2.6 アクセス・クライアントの開発

- 2.6.1 アクセス・クライアントの概要

- 2.6.1.1 カスタム・アクセス・クライアントを作成するケース

- 2.6.1.2 アクセス・クライアントのアーキテクチャ

- 2.6.1.3 アクセス・クライアント・リクエストの処理の概要

- 2.6.2 アクセス・クライアントの構造

- 2.6.2.1 アクセス・クライアントの一般的な実行フロー

- 2.6.2.2 簡易アクセス・クライアントの例: JAccess Client.java

- 2.6.2.3 例: Javaログイン・サーブレット

- 2.6.2.4 追加のメソッドを使用した例: access_test_java.java

- 2.6.2.5 Javaにおける証明書ベース認証の実装の例

- 2.7 アクセス・クライアント・プログラムの構築およびデプロイ

- 2.7.1 開発環境の設定

- 2.7.2 新規アクセス・クライアント・プログラムのコンパイル

- 2.7.3 新規アクセス・クライアント・プログラムの構成およびデプロイ

- 2.8 互換性: 11gと10gのAccess SDKおよびAPI

- 2.8.1 Access SDKの互換性

- 2.8.2 10g JNI ASDKおよび11g Access SDKの互換性

- 2.8.3 非推奨: Oracle Access Manager 10g JNI SDK

- 2.9 旧アプリケーションの移行またはコードの変換

- 2.9.1 開発およびランタイム環境の変更

- 2.9.2 アプリケーションの移行

- 2.9.2.1 移行に固有の構成

- 2.9.3 コードの変換

- 2.9.3.1 JNI ASDKおよびAccess SDKの相違点の理解

- 2.9.3.2 コードの変換

- 2.10 ベスト・プラクティス

- 2.10.1 問題の回避

- 2.10.1.1 スレッド・セーフ・コード

- 2.10.2 問題の識別と解決

3 カスタム認証プラグインの作成

- 3.1 認証プラグインの概要

- 3.1.1 カスタム・プラグインのライフ・サイクルについて

- 3.1.2 計画、認証モデルおよびプラグインについて

- 3.2 プラグイン・インタフェースの概要

- 3.2.1 プラグイン・インタフェースについて

- 3.2.1.1 GenericPluginService

- 3.2.1.2 AuthnPluginService

- 3.2.2 プラグイン階層について

- 3.3 サンプル・コード: カスタム・データベース・ユーザー認証プラグイン

- 3.3.1 サンプル・コード: データベース・ユーザー認証プラグイン

- 3.3.2 プラグイン構成メタデータ要件のサンプル

- 3.3.3 プラグインのサンプル・マニフェスト

- 3.3.4 プラグインJARファイル構造

- 3.4 認証プラグインの開発

- 3.4.1 カスタム認証プラグインの記述について

- 3.4.2 カスタム認証プラグインの記述

- 3.4.3 カスタム認証プラグインのコンパイルに必要なJAR

- 3.5 カスタム・プラグインの追加

- 3.5.1 カスタム・プラグインの管理について

- 3.5.2 カスタム・プラグインの追加

- 3.5.3 プラグインのアクティブ化ステータスのチェック

- 3.5.4 カスタム認証プラグインの削除

- 3.6 カスタム・プラグインに対応したカスタム認証モジュールの作成

- 3.6.1 カスタム認証モジュールの作成について

- 3.6.2 カスタム認証モジュールの作成

- 3.7 カスタム認証モジュールを含む認証スキームの作成

- 3.8 カスタム・プラグインのロギングの構成

4 Oracle Security Token Serviceモジュール・クラスの記述

- 4.1 Oracle Security Token Serviceカスタム・トークン・モジュール・クラスの概要

- 4.2 TokenValidatorModuleクラスの記述

- 4.2.1 TokenValidatorModuleクラスの記述について

- 4.2.2 TokenValidatorModuleクラスの記述

- 4.3 TokenIssuanceModuleクラスの記述

- 4.3.1 TokenIssuanceModuleクラスの記述について

- 4.3.2 TokenIssuanceModuleクラスの記述

- 4.4 カスタム・クラスを使用可能にする

- 4.4.1 クラスを使用可能にする処理について

- 4.4.2 カスタム・トークンの検索範囲の絞込みについて

- 4.4.3 カスタム・トークンの管理

- 4.5 Oracle Security Token Serviceカスタム構成の管理

- 4.5.1 検証テンプレートの作成

- 4.5.2 カスタム・トークンの発行テンプレートの作成

- 4.5.3 カスタム・トークンをリクエスタ・プロファイルに追加

- 4.5.4 カスタム・トークンをリライイング・パーティ・プロファイルに追加

- 4.5.5 トークンをリクエスタにマップ

- 4.5.6 /wssuserエンドポイントの作成

例一覧

- 2-1 JAccess Client.java

- 2-2 Javaログイン・サーブレットの例

- 2-3 access_test_java.java

図一覧

- 2-1 アクセス・クライアントのアーキテクチャの詳細

- 2-2 プロセスの概要: リソース・リクエストの処理

- 2-3 フォーム・ベースのアプリケーションのプロセス・フロー

- 2-4 com.oblix.accessパッケージのバージョン間のマッピング

- 3-1 カスタム・プラグインのデプロイ・ワークフロー

- 3-2 認証モデルおよびプラグイン

- 3-3 プラグイン・パッケージ階層

- 3-4 プラグイン・クラス階層

- 3-5 プラグイン・インタフェース階層

- 3-6 プラグイン注釈タイプ階層

- 3-7 プラグイン列挙階層

- 3-8 データベース・ユーザー認証プラグイン・パート1

- 3-9 データベース・ユーザー認証プラグイン・パート2

- 3-10 データベース・ユーザー認証プラグイン・パート3

- 3-11 XSD構成データ: データベース・ユーザー認証プラグイン

- 3-12 XMLメタデータ: データベース・ユーザー認証プラグイン

- 3-13 データベース・ユーザー認証プラグイン・サンプルのMANIFEST.MF

- 3-14 「共通構成」のプラグイン・ノードおよびプラグイン・ページ

- 3-15 選択したプラグインのアクティブ化のステータス

- 3-16 カスタム認証モジュール・ノードおよび「一般」サブタブ

- 3-17 カスタム認証モジュールの「ステップ」サブタブおよび「詳細」セクション

- 3-18 ステップの追加

- 3-19 カスタム認証モジュールの「ステップ編成」サブタブ

- 4-1 第1部: EmailTokenValidatorModuleImplforBinary.java

- 4-2 第2部: EmailTokenValidatorModuleImplforBinary.java

- 4-3 EmailTokenIssuerModuleImpl.java

- 4-4 新規カスタム・トークン・ページ

- 4-5 カスタム・トークン定義: 電子メール

- 4-6 カスタム・トークン検索ページおよびコントロール

- 4-7 一般的な詳細: email-wstrust-valid-temp

- 4-8 トークン・マッピング: email-wstrust-valid-temp

- 4-9 一般的な詳細: email-issuance-temp

- 4-10 発行プロパティ: email-issuance-temp

表一覧

- 2-1 場所: Access SDKリソース

- 2-2 Oracle Access Manager 11g Access SDKの機能

- 2-3 アクセス・クライアントのバリエーション

- 2-4 アクセス・クライアントを作成するためのリソース

- 2-5 比較: 11gおよび10g Access APIクラス

- 2-6 JNI ASDK com.oblix.accessパッケージおよびAccess SDK oracle.security.am.asdkパッケージの相違点

- 3-1 プラグイン・ライフサイクルの状態

- 3-2 方法の比較

- 3-3 必要なプラグイン・メソッド

- 3-4 カスタム・プラグインの管理アクション

- 3-5 プラグイン・ステータス表の要素

- 3-6 XMLメタデータ・ファイルから抽出されたプラグイン詳細の例

- 3-7 「新規ステップの追加」のエントリ、ステップ結果表および「詳細」セクション

- 3-8 「ステップ編成」サブタブ

- 4-1 新規カスタム・トークン要素

- 4-2 カスタム・トークン検索要素およびコントロール

Oracle® Fusion Middleware

Oracle Access ManagerおよびOracle Security Token Service開発者ガイド

11g リリース1 (11.1.1)

B66696-01(原本部品番号:E12491-03)

2011年6月

Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド 11g リリース1 (11.1.1)

B66696-01

Copyright (C) 2000, 2011, Oracle and/or its affiliates.All rights reserved.

原本著者: Trish Fuzesy

原本協力著者: Toby Close, Peter Povenic, Umesh Waghode, Svetlana Klomeyskaya, Resha Chhada, Gail Flanegin

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

このガイドでは、カスタム・アプリケーションおよび機能へのプラグインをプログラム的に記述し、Webベースでないリソースを保護するカスタム・アクセス・ゲートを作成する方法を説明します。

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、Oracle Access ManagerおよびOracle Security Token Serviceに詳しい管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧のみを行に記述する必要があります。しかし、一部のスクリーン・リーダーは括弧のみの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

聴覚に障害があるお客様のOracleサポート・サービスへのアクセス

Oracleサポート・サービスに連絡するために、電気通信リレー・サービス(TRS)を使用して、1.800.223.1711でOracle Supportに電話してください。Oracleサポート・サービスのエンジニアは、技術的な問題を処理し、Oracleサービス要求処理に応じてカスタマ・サポートを提供します。TRSの詳細については、http://www.fcc.gov/cgb/consumerfacts/trs.htmlを参照し、 電話番号の一覧については、http://www.fcc.gov/cgb/dro/trsphonebk.htmlを参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware 11gリリース1(11.1.1)のドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

- Oracle Security Token Service Java APIリファレンス

- Oracle Access Manager Access SDK Java APIリファレンス

- Oracle Access Manager拡張Java APIリファレンス

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle Access Managerの新機能

この項では、Oracle Access Manager 11gの新機能について説明します。

このマニュアルで説明するOracle Access Managerの新機能は、次の各項から構成されます。

- 製品およびコンポーネントの名前の変更

- Oracle Access Manager 11g Software Developer Kit

製品およびコンポーネントの名前の変更

Oracle Access Managerの多くのコンポーネント名は変更ありません。ただし、次の表で示すように、知っておく必要のある重要な変更がいくつかあります。

領域

Oracle Access Manager 10g

Oracle Access Manager 11g

デプロイメント

スタンドアロン・サーバー

コンテナでデプロイ

コンポーネント名

アクセス・サーバー
ポリシー・マネージャ

アイデンティティ・サーバー

Webパス

OAMサーバー
OAM管理コンソール

なし

なし

エージェント

Webゲート
アクセス・ゲート

OAMエージェント
OAMエージェント

コンソール名

ポリシー・マネージャ
アイデンティティ・システム・コンソール

アクセス・システム・コンソール

OAM管理コンソール
なし

なし

ディレクトリ・プロファイル

ディレクトリ・プロファイル

ユーザー・アイデンティティ・ストア

アイデンティティ管理

アイデンティティ・サーバー

アイデンティティに依存しない(Oracle Identity Manager 11gがデフォルトで使用されます)

管理者

マスター管理者
マスター・アイデンティティ管理者

マスター・アイデンティティ管理者

委任管理者

OAM管理者
なし

なし

なし

エージェントおよびパートナ・アプリケーションの登録

なし

OAM管理コンソール
リモート登録ツールにより、デフォルトのセキュリティ・ポリシーを使用して、自動化されたエージェント登録とアプリケーション・ドメインの作成が行われます。

Oracle Access Manager 10gフォームに基づく認証スキーム、ポリシー・ドメイン、アクセス・ポリシー、シングル・サインオンのためのアイデンティティ・アサータ用Webゲート・プロファイルの自動作成

OAMCfgTool
プラットフォームに依存しないツールとスクリプト

なし

構成ストア

LDAP

XMLファイル

ポリシー・ストア

LDAP

RDBMS

ポリシー・モデル

オープン(デフォルト許可)

クローズ(デフォルト = アクセス拒否)

ポリシー・ドメイン

ポリシー・ドメイン

アプリケーション・ドメイン

セッション管理

ステートレスでcookieに格納

ステートフルでサーバーに格納

LDAPに対する認証

LDAPによりシステム全体で定義

認証スキームでLDAPにより定義

リソース・タイプ

リソース・タイプ

リソース・タイプ

リソース

リソース

リソース

ホスト識別子

ホスト識別子

ホスト識別子

認証

認証
認証スキーム

認証プラグイン

なし

認証ルール

認証
認証スキーム

認証プラグイン

認証モジュール

認証ポリシー

認可

認可
認可ルール

認可条件式

認可
制約

認可ポリシー

アクション

アクション

レスポンス

ソフトウェア開発キット

Access SDK

Access SDK

アクセス・プロトコル

NetPoint Accessプロトコル(NAP)

Oracle Accessプロトコル(OAP)

アクセス・プロトコルのポート番号

6021

5575(Internet Assigned Numbers Authority(IANA)により割り当て)

Oracle Access Manager 11g Software Developer Kit

Oracle Access Manager 11gでは、カスタム・アクセス・ゲートや認証および認可機能の拡張機能を作成するための、純粋なJava Software Developer Kit (SDK)を提供しています。また、Oracle Access Manager 11gではOracle Access Manager 10g JNI SDKとの互換性が保たれており、移行することでOracle Access Manager 11gを使用できます。

1 本書の概要

この章は、本書の概要として次の各項から構成されています。

- 第2章: Access SDKおよびAPIの概要

- 第3章: カスタム認証プラグインの作成

- 第4章: Oracle Security Token Serviceモジュール・クラスの記述

- Java APIリファレンスの概要

1.1 第2章: Access SDKおよびAPIの概要

Oracle Access Manager 11gでは、カスタムAccess Clients、Oracle Access Manager 11g認証および認可機能の拡張機能、およびカスタム・トークンを作成するための、純粋なJava Software Developer Kit (SDK)を提供しています。また、Oracle Access Manager 11gではOracle Access Manager 10g JNI SDKとの下位互換性が保たれており、移行してOracle Access Manager 11gとともに使用できます。

第2章の内容は次のとおりです。

- 第2.1項「Access SDKの概要」

- 第2.2項「Access SDKパッケージおよびリソースの場所の確認」

- 第2.3項「用途、機能および新機能」

- 第2.4項「メッセージ、例外およびロギング」

- 第2.5項「アクセス・クライアントの構成およびデプロイ」

- 第2.6項「アクセス・クライアントの開発」

- 第2.7項「アクセス・クライアント・プログラムの構築およびデプロイ」

- 第2.8項「互換性: 11gと10gのAccess SDKおよびAPI」

- 第2.9項「旧アプリケーションの移行またはコードの変換」

- 第2.10項「ベスト・プラクティス」

1.2 第3章: カスタム認証プラグインの作成

OAMサーバーでは、保護対象とするリソースへのアクセスを制限するために、認証と認可の両方の制御が利用されます。認証は特定の認証スキームにより制御され、認証スキームは、ユーザーがリソースへのアクセス試行時に入力した資格証明をテストする、1つ以上のプラグインに依存します。プラグインは、OAMサーバーのインストールで提供される標準セット、または独自のJava開発者が作成したカスタム・プラグインから取得できます。

第3章の内容は次のとおりです。

- 第3.1項「認証プラグインの概要」

- 第3.2項「プラグイン・インタフェースの概要」

- 第3.3項「サンプル・コード: カスタム・データベース・ユーザー認証プラグイン」

- 第3.4項「認証プラグインの開発」

- 第3.5項「カスタム・プラグインの追加」

- 第3.6項「カスタム・プラグインに対応したカスタム認証モジュールの作成」

- 第3.7項「カスタム認証モジュールを含む認証スキームの作成」

- 第3.8項「カスタム・プラグインのロギングの構成」

1.3 第4章: Oracle Security Token Serviceモジュール・クラスの記述

Oracle Security Token Serviceにおいて、検証または発行するトークンがデフォルトでサポートされていない場合、独自の検証および発行モジュール・クラスを記述できます。カスタム・トークンには、次の2つ(検証または発行クラス)のいずれかが必要です。

- カスタム検証クラスは、Oracle Security Token Serviceを使用してカスタム・トークンを検証します

- カスタム発行クラスは、Oracle Security Token Serviceによるカスタム・トークンの発行を可能にします

第4章では、Oracle Access Manager 11gおよびOracle Security Token Serviceのカスタム・トークン・オプションについて説明します。内容は、次のとおりです。

- 第4.1項「Oracle Security Token Serviceカスタム・トークン・モジュール・クラスの概要」

- 第4.2項「TokenValidatorModuleクラスの記述」

- 第4.3項「TokenIssuanceModuleクラスの記述」

- 第4.4項「カスタム・クラスを使用可能にする」

- 第4.5項「Oracle Security Token Serviceカスタム構成の管理」

1.4 Java APIリファレンスの概要

このリリースにおける特定のJava APIリファレンス詳細は、次の資料で説明しています。

- Oracle Access Manager Access SDK Java APIリファレンス

- Oracle Access Manager拡張Java APIリファレンス

- Oracle Security Token Service Java APIリファレンス

2 Access SDKおよびAPIの概要

この章の内容は次のとおりです。

- 第2.1項「Access SDKの概要」

- 第2.2項「Access SDKパッケージおよびリソースの場所の確認」

- 第2.3項「用途、機能および新機能」

- 第2.4項「メッセージ、例外およびロギング」

- 第2.5項「アクセス・クライアントの構成およびデプロイ」

- 第2.6項「アクセス・クライアントの開発」

- 第2.7項「アクセス・クライアント・プログラムの構築およびデプロイ」

- 第2.8項「互換性: 11gと10gのAccess SDKおよびAPI」

- 第2.9項「旧アプリケーションの移行またはコードの変換」

- 第2.10項「ベスト・プラクティス」

2.1 Access SDKの概要

Oracle Access Manager 11g Access SDKは、オラクル社が様々なエンタープライズ・プラットフォーム(32ビットおよび64ビットの両方のモードを使用)およびハードウェアの組合せで認証した、プラットフォーム非依存パッケージです。これは、Oracle Fusion Middlewareアプリケーション間でサポートされているJDKバージョンで提供されています。

oracle.security.am.asdkパッケージでは、Oracle Access Manager 11gバージョンのApplication Program Interface(API)が提供されています。11gバージョンはOracle Access Manager 10g APIによく似ていますが、OAM 11gサーバーで使用するための拡張機能が備わっています。11g Access SDKは、com.oblix.accessインタフェースをサポートすることで下位互換性を提供しています。

参照:
Oracle Security Token Service Java APIリファレンス

Oracle Access Manager 10g (10.1.4.3)のcom.oblix.accessパッケージおよびクラスは非推奨です。非推奨APIは、機能改良などの理由から使用が推奨されておらず、通常はそれに代わるAPIが提供されます。非推奨APIは今後の実装で削除される可能性があります。

注意:
開発者はあらゆる新規開発においてOracle Access Manager 11g Access SDKを使用することを強くお薦めします。

2.2 Access SDKパッケージおよびリソースの場所の確認

Access SDKのインストール後は、サブディレクトリおよびファイルの相対的な場所を変更しないでください。変更すると、APIが正しくビルドおよび操作できなくなります。

表2-1では、Access SDKパッケージおよびリソースと、それぞれの入手場所を特定しています。

表2-1 場所: Access SDKリソース

リソースおよび場所

バージョンおよびプラットフォームのサポート: Oracle Technology Network

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

パッケージのダウンロード: Oracle Technology Network

http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

Oracle Access Manager 11g Access SDKパッケージ:

- oracle.security.am.asdk: Oracle Access Manager 11gサーバー機能を利用するための拡張機能を提供する新規の認証および認可API。Oracle Access Manager 11gバージョンのAccess SDK APIは、Oracle Access Manager 10gR3 (10.1.4.3)またはOracle Access Manager 11gR1 (11.1.1.5+)バージョンのサーバーと併用できます。

- com.oblix.access: Oracle Access Manager 10g JNI ASDKで記述されたプログラムとの互換性を得るために使用可能であり、Oracle Access Manager 11g用の拡張機能を一部備えた10gバージョンの認証および認可APIです。

Javaマニュアル:

- Oracle Access Manager Access SDK Java APIリファレンス

- Oracle Access Manager拡張Java APIリファレンス

- Oracle Security Token Service Java APIリファレンス

各メソッドには次の詳細が含まれます。

- メソッドの包括的な説明

- メソッドのパラメータ

- 戻り値

- メソッドによりスローされる可能性がある例外

- その他の関連詳細

2.3 用途、機能および新機能

Oracle Access Manager 11g Access SDKは、Javaアプリケーション開発者を対象とし、密結合されている高パフォーマンスの統合の開発を目的としています。

機能的な観点からすると、Oracle Access Manager 11g Access SDKは10g (10.1.4.3) Java Access SDKのパリティを維持しており、新規APIレイヤーを使用して既存のカスタム・コードを記述しなおすことができます。

Oracle Access Manager 11g Access SDKには、認証および認可機能が組み込まれています。ただし、管理APIは組み込まれておらず(たとえば、11gポリシー・マネージャAPIはありません)、Oracle Access Manager 11g Cookieを使用しません。

Access SDKの最も一般的な用途は、Oracle Access Managerとその他のアプリケーション(Oracleまたはサード・パーティ)とのカスタム統合の開発を可能にすることです。使用例を次に示します。

- Oracle Access Manager認証プロセスの一部として格納される可能性があるセッション情報へのアクセス。

- プリンシパル・ユーザーのHTTPヘッダーを信頼せず、Oracle Access ManagerセッションCookieの有効性を確認。

Access SDKのもう1つの用途としては、Oracleがデフォルトで統合を提供しないWebサーバーまたはアプリケーション・サーバーに対する、カスタム・アクセス・クライアントの開発があります。

表2-2では、Oracle Access Manager 11g Access SDKの主な機能について説明します。

表2-2 Oracle Access Manager 11g Access SDKの機能

機能

説明

インストール

クライアント・パッケージ: 1つのjarファイルで構成されます。サポート・ファイル(署名およびTLSネゴシエーション用)は含まれておらず、個別に生成する必要があります。

サーバー関連コード: コアOracle Access Managerサーバー・インストールの一部として組み込まれています。

注意: Oracle Access Manager 10g (10.1.4.3)で開発されたアクセス・クライアントおよびプラグインは、Oracle Access Manager 11gで使用できます。Oracle Access Manager 10g (10.1.4.3)バンドル・パッチは、Oracle Access Manager 11gで使用するためのJava SDKコード拡張機能を配布する目的で使用します。

組込みバージョニング

次のことが可能です。

- インストールされているAccess SDKバージョンの判別

- 連携して動作できる互換バージョンの検証(Oracle Access Manager 10g (10.1.4.3)およびOracle Access Manager 11g)
一致しない場合、Access SDK関数が停止し、情報メッセージがログに記録され、表示されます。

ロギング

Access SDKロギング・メカニズムにより、ローカル・ファイルに表示する詳細のレベル(情報、警告およびエラーの各レベル)を指定できます。メッセージは、問題を解決するための十分な詳細を提供します。たとえば、互換性のないAccess SDKパッケージが使用されている場合、ログ・メッセージには、バージョン不一致に関する詳細と、遵守する必要があるバージョン基準が含まれます。

SDKが指定期間内に大量のログを生成した場合、ファイル制限または期間に基づいてログのロールオーバーを構成できます。たとえば、ファイル制限に達した場合(または一定時間が経過した場合)、ログ・ファイルはアーカイブ・ディレクトリにコピーされ、新規ログ・ファイルが開始されます。

新規コール

Access SDKには、Oracle Access Manager 11gの新規アーキテクチャに基づいてセッションに関する追加情報を決定する新規コールが組み込まれています。

注意: Oracle Access Manager 10gのcom.oblix.accessパッケージで開発されたアクセス・クライアントおよびプラグインは、移行してOAM 11gサーバーで動作できます。

Access SDKを使用することで、認証、認可および監査など保護されたリソースへのアクセスを制御する目的で、Oracle Access Managerとのカスタム統合を開発できます。通常このアクセス制御を実現するには、Access SDKランタイムとインタフェースするためのAccess Client APIを起動するアプリケーションまたはプラグインであるカスタム・アクセス・クライアントを開発およびデプロイします。

アクセス・クライアント側のキャッシュがAccess SDKランタイム内で内部的に使用され、処理オーバーヘッドがさらに抑えられます。Access SDKランタイムおよびOracle Access Managerサーバーの連携により、動的構成管理が透過的に実行され、それによって、Oracle Access Manager管理コンソールを使用したアクセス・クライアント構成の変更は、対象となるAccess SDKランタイムに自動的に反映されます。

アクセス・クライアントAPIのすべてまたはサブセットを使用することで、目的の機能に応じて、様々なタイプのカスタム・アクセス・クライアントを開発できます。APIは通常、ユーザーとの通信に使用される保護されたリソースおよびネットワーク・プロトコルのタイプは認識しません。たとえば、HTTPプロトコルの詳細およびHTTP Cookieの用途はAccess SDKの範囲外です。非HTTPリソースを保護するアクセス・クライアントは、HTTPリソースを保護するエージェントと同じくらい容易に開発できます。

カスタム・アクセス・クライアント単独で、または他のアクセス・クライアントと組み合せて実行できる一般的な機能は、次のとおりです。

- Oracle Access Managerおよびその構成済ユーザー・リポジトリに対する資格証明を検証してユーザーを認証します。

- ユーザーを認証し、リソースへのアクセスについて認可の有無をチェックします。

- ユーザーを認証し、セッション・トークンで表された一意のOracle Access Managerセッションを作成します。

- ユーザーにより提供されたセッション・トークンを検証し、保護されたリソースへのユーザーのアクセス権を認可します。

- セッション・トークンまたは名前付きセッション識別子がある場合は、Oracle Access Managerセッションを終了します。

- 名前付きユーザー識別子を指定し、指定ユーザーのOracle Access Managerセッションを列挙します。

- Oracle Access Managerのカスタム・セッション属性を保存または取得します。

アクセス・クライアントの一部の操作は、指定されたアクセス・クライアント・インスタンスによる使用に制限されています。たとえば、Oracle Access Manager Access SDK Java APIリファレンスのOperationNotPermittedに関する項を参照してください。

Oracle Access Manager管理者は、Oracle Access Manager管理コンソールを使用して、個々のアクセス・クライアントの権限を制御できます。詳細は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドを参照してください。

2.4 メッセージ、例外およびロギング

この項では、ステータスまたはエラーを示すためにAccess SDKで使用されるメッセージおよび例外について説明します。

Access SDKにより生成される実行ログについても説明します。実行ログは、実行された操作に関する情報を提供します。たとえば、操作ステータス、発生したエラーまたは例外、およびトラブルシューティングに役立つ一般情報があります。

この項で説明する項目は、次のとおりです。

- メッセージ

- 例外

- ロギング

2.4.1 メッセージ

Access SDKは、ステータスまたはエラーの状態を示すローカライズ済メッセージをサポートします。例外としてアプリケーションに提供されるエラー・メッセージもローカライズされます。これらのローカライズ済エラー・メッセージは、Access SDKログ・ファイルに記録されます。

2.4.2 例外

次のタイプの例外は、アプリケーションにエラーの状態を示すために使用されます。

- OperationNotPermittedException
Oracle Access Manager 11g Access SDKにより、新しいセッション管理APIのセットが導入されます。権限を持つアクセス・クライアントのみが、これらのセッション管理操作を実行できます。

アクセス・クライアントがこれらの操作の実行を許可されていない場合、Oracle Access Manager 11gサーバーがエラーを返します。サーバーがエラーを返すと、Access SDKがこの例外をスローします。

- AccessException
操作の実行中に予期しないリカバリ不能なエラーが発生すると、Oracle Access Manager Access SDK APIはAccessExceptionをスローします。

2.4.3 ロギング

Access SDKでは、ログの生成にJavaロギングAPIが使用されます。具体的には、oracle.security.am.asdkパッケージにAccessLoggerクラスが含まれ、このクラスはAccess SDKログを生成します。

Access SDKログを生成するには、アプリケーションの起動時にログ構成ファイルを指定する必要があります。このログ構成ファイルはアプリケーション実行中のJavaプロパティとして指定しますが、この場合、Javaプロパティ-Djava.util.logging.config.fileはlogging.propertiesへのパスです。

次に例を示します。

java -Djava.util.logging.config.file=JRE_DIRECTORY/lib/logging.properties

logging.propertiesファイルは、VMがロードされた直後に構成され準備が整うログ出力、ハンドラ、フォーマッタおよびフィルタの数を定義します。状況に応じて、必要なロギング・レベルを構成することもできます。

logging.propertiesファイルのjava.util.logging.FileHandler.patternプロパティに対して、ログ・ファイル・パスを指定する必要があります。ファイル名のみを指定した場合、ファイルはカレント・ディレクトリの下に作成されます。

logging.propertiesファイルの例は次のとおりです。

# "handlers" specifies a comma separated list of log Handler
# classes.  These handlers will be installed during VM startup.
# Note that these classes must be on the system classpath.
# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.
# Add handlers to the root logger.
# These are inherited by all other loggers.
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

# Set the logging level of the root logger.
# Levels from lowest to highest are
# FINEST, FINER, FINE, CONFIG, INFO, WARNING and SEVERE.
# The default level for all loggers and handlers is INFO.
.level= ALL

# Configure the ConsoleHandler.
# ConsoleHandler uses java.util.logging.SimpleFormatter by default.
# Even though the root logger has the same level as this,
# the next line is still needed because we're configuring a handler,
# not a logger, and handlers don't inherit properties from the root logger.
java.util.logging.ConsoleHandler.level =INFO
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

# The following special tokens can be used in the pattern property
# which specifies the location and name of the log file.
#   / - standard path separator
#   %t - system temporary directory
#   %h - value of the user.home system property
#   %g - generation number for rotating logs
#   %u - unique number to avoid conflicts
# FileHandler writes to %h/demo0.log by default.
java.util.logging.FileHandler.pattern=%h/asdk%u.log

# Configure the FileHandler.
# FileHandler uses java.util.logging.XMLFormatter by default.
#java.util.logging.FileHandler.limit = 50000
#java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.FileHandler.level=ALL

ログ出力のサンプルを次に示します。

Apr 19, 2011 5:20:39 AM AccessClient createClient
FINER: ENTRY
Apr 19, 2011 5:20:39 AM ObAAAServiceClient setHostPort
FINER: ENTRY
Apr 19, 2011 5:20:39 AM ObAAAServiceClient setHostPort
FINER: RETURN
Apr 19, 2011 5:20:39 AM ObAAAServiceClient setHostPort
FINER: ENTRY
Apr 19, 2011 5:20:39 AM ObAAAServiceClient setHostPort
FINER: RETURN
Apr 19, 2011 5:20:39 AM AccessClient createClient
FINER: RETURN
Apr 19, 2011 5:20:39 AM AccessClient initialize
FINER: read config from server, re-init if needed
Apr 19, 2011 5:20:39 AM AccessClient updateConfig
FINER: ENTRY
Apr 19, 2011 5:20:39 AM AccessClient readConfigFromServer
FINER: ENTRY
Apr 19, 2011 5:20:39 AM ObAAAServiceClient getClientConfigInfo
FINER: ENTRY
Apr 19, 2011 5:20:39 AM ObAAAServiceClient sendMessage
FINER: ENTRY
Apr 19, 2011 5:20:39 AM oracle.security.am.common.nap.util.NAPLogger log
FINER: Getting object using poolid primary_object_pool_factory
Apr 19, 2011 5:20:39 AM oracle.security.am.common.nap.util.pool.PoolLogger logEntry
FINER: PoolLogger : main entered: KeyBasedObjectPool.acquireObject
Apr 19, 2011 5:20:39 AM oracle.security.am.common.nap.util.NAPLogger log
FINEST: Creating pool with id = primary_object_pool_factory
Apr 19, 2011 5:20:39 AM oracle.security.am.common.nap.util.pool.PoolLogger log
FINER: PoolLogger:main : Maximum Objects = 1Minimum Objects1
Apr 19, 2011 5:20:39 AM oracle.security.am.common.nap.util.pool.PoolLogger logEntry
FINER: PoolLogger : main entered: constructObject
Apr 19, 2011 5:20:39 AM oracle.security.am.common.nap.ObMessageChannelImpl <init>

2.5 アクセス・クライアントの構成およびデプロイ

この項では、Access SDKを使用して開発されたアクセス・クライアントをデプロイする前に必要な構成ステップについて説明します。詳細は、第2.6.1.2項「アクセス・クライアントのアーキテクチャ」を参照してください。

アクセス・クライアントの開発後、テストおよび使用する前に、現在のOracle Access Manager 11g環境でデプロイする必要があります。アクセス・クライアントのデプロイメント・プロセスは、その他のOracle Access Managerエージェントのデプロイメント・プロセスに類似しています。

次の概要では、Oracle Access Managerの管理者資格証明を使用してユーザーが実行する必要があるタスクを説明します。

参照:
Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

タスク概要: アクセス・クライアント・コードのデプロイ

アクセス・クライアント・プログラムはすでに開発され、コンパイル済であることが前提です。

1. Access SDKのjarファイルを取得し、アクセス・クライアントの作成に使用するコンピュータにこれをコピーします。

2. 保護対象のアプリケーションをホストしているコンピュータにアクセス・クライアントをコピーします。

3. アクセス・クライアントを構成します。

4. 必要なJava環境があることを確認します。
アクセス・クライアントがスタンドアロン環境にある場合、Java Development Kit (JDK)またはJavaランタイム環境(JRE)を使用できます。アクセス・クライアントがサーブレット・アプリケーションである場合、Java EEまたはJava EEコンテナで使用可能なJava環境を使用できます。

5. Access SDKのjarファイルがクラス・パスにあることを確認します。

2.5.1 構成要件

Access SDK構成は、次のファイルで構成されます。

- 構成ファイル(ObAccessClient.xml)
この構成ファイルは、Oracle Access Managerサーバーのホスト、ポートおよびアクセス・クライアントの動作を決定する他の構成アイテムなど、各種詳細が含まれます。たとえば、アイドル・セッション時間などがあります。このファイルの名前はObAccessClient.xmlです。

- SSL認証およびキー・ファイル
このファイルは、トランスポート・セキュリティ・モードが簡易または証明書である場合のみ必要です。Oracle Access Manager 10gサーバーおよびOracle Access Manager 11gサーバーのどちらも、エージェントとの通信においてオープン、簡易および証明書のトランスポート・セキュリティ・モードをサポートしています。Access SDKを使用して開発されたアクセス・クライアントは、エージェントと呼ばれます。Oracle Access Managerサーバーが構成されているモードによっては、アクセス・クライアントが同じモードで通信するよう構成されることが必要となります。

トランスポート・セキュリティ・モードが簡易または証明書の場合、次のものが必要です。

- アクセス・クライアントの証明書

- アクセス・クライアントの秘密鍵

- OAMサーバーの証明書を信頼するためのCA証明書

- password.xmlファイル
このファイルは、トランスポート・セキュリティ・モードが簡易または証明書である場合のみ必要です。このファイルには、パスワードが暗号化された形式で含まれます。このパスワードは、SSLキー・ファイルの保護に使用されます。

- ログ構成
ログ・ファイルを生成するために必要です。

2.5.2 必要な構成ファイルの生成

ObAccessClient.xml構成ファイルを取得するには、Oracle Access Manager 11g管理コンソールまたはリモート登録ツールを使用して、アクセス・クライアントをOAM 10gエージェントとしてOAM 11gサーバーに登録します。詳細は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドを参照してください。

登録時にトランスポート・セキュリティ・モードが簡易または証明書モードに指定された場合、Oracle Access Manager管理コンソールによって、SSL証明書およびキー・ファイルがPEM形式で作成されます。この後、証明書およびキー・ファイルはoamclient-keystore.jksファイルにインポートできます。証明書およびキーの発行に使用されたCA証明書は、oamclient-truststore.jksにインポートされる必要があります。詳細は、第2.5.3項「SSL証明書およびキー・ファイル」を参照してください。

Oracle Access Manager管理コンソールでは、password.xmlファイルも作成されます。

oracle.security.am.asdk APIで開発されたアクセス・クライアント・アプリケーションは、構成ファイルおよびその他の必要なファイルを取得するための場所を指定できます。このためには、Access SDKを初期化し、構成ファイルが存在するディレクトリの場所を指定します。

構成ファイルの場所をAccess SDKに指定できるオプションの詳細は、Oracle Access Manager Access SDK Java APIリファレンスを参照してください。

2.5.3 SSL証明書およびキー・ファイル

Oracle Access Manager 11g Access SDKでは、一般に信頼ストアまたはキー・ストアとして知られるデータベースのSSL証明書およびキー・ファイルを使用します。これらのストアはJKS (Java Key Standard)形式である必要があります。

2.5.3.1 簡易トランスポート・セキュリティ・モード

CA証明書のインポート

CA証明書は信頼ストアにインポートする必要があります。Oracle Access Manager 10g JNI ASDKは、簡易モードで使用できる自己署名付きCA証明書を提供し、アクセス・クライアントに証明書を発行するために使用されます。また、OAM 11gサーバーも自己署名付きCA証明書を提供します。

Oracle Access Manager 10g JNI ASDKでは、CA証明書は次のディレクトリにあり、cacert.pemという名前です: ASDK_INSTALL_DIR/oblix/tools/openssl/simpleCA

OAM 11gサーバーでは、CA証明書は次のディレクトリにあり、cacert.derという名前です: $MIDDLEWARE_HOME/user_projects/domains/base_domain/config/fmwconfig

次のコマンドを実行して、PEMまたはDER形式のCA証明書を信頼ストアにインポートします。

1. テキスト・エディタを使用してca_cert.pemまたはcacert.derを編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除し、ファイルを保存します。次に例を示します。

-----BEGIN CERTIFICATE-----
Content to retain
-----END CERTIFICATE-----

2. 次のコマンドを実行し、必要に応じて環境にあわせて変更します。
keytool -importcert -file <<ca cert file cacert.pem or cacert.der>> -trustcacerts -keystore oamclient-truststore.jks -storetype JKS

3. プロンプトが表示されたら、キーストアのパスワードを入力します。これは、OAMサーバーで使用されるグローバル・パス・フレーズと同じである必要があります。

キーストアの設定

アクセス・クライアントのSSL証明書および秘密鍵ファイルをキーストアに追加する必要があります。アクセス・クライアントがOAMサーバーと通信できるように、SSL証明書および秘密鍵ファイルは簡易モードで生成する必要があります。

Oracle Access Manager 10g JNI ASDKは、アクセス・クライアントの証明書およびキー・ファイルの生成を提供します。これらの証明書はPEM形式です。

OAM 11gサーバーは、アクセス・クライアントの証明書およびキー・ファイルを生成するための、リモート登録および管理コンソールと呼ばれるツールを提供します。これらの証明書もPEM形式です。これらのファイルの名前は、aaa_cert.pemおよびaaa_key.pemです。

キーストアoamclient-keystore.jksに証明書およびキー・ファイルをインポートするには、次のコマンドを実行します。

1. テキスト・エディタを使用してaaa_cert.pemを編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除し、ファイルを保存します。次に例を示します。

-----BEGIN CERTIFICATE-----
Content to retain
-----END CERTIFICATE-----

2. 次のコマンドを実行し、必要に応じて環境にあわせて変更します。
openssl pkcs8 -topk8 -nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der -outform DER

このコマンドにより、パスワードの入力が要求されます。パスワードはグローバル・パス・フレーズである必要があります。

3. 次のコマンドを実行し、必要に応じて環境にあわせて変更します。
openssl x509 -in aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER

4. 次のコマンドを実行し、必要に応じて環境にあわせて変更します。
java -cp importcert.jar oracle.security.am.common.tools.importcerts.CertificateImport -keystore oamclient-keystore.jks -privatekeyfile aaa_key.der -signedcertfile aaa_cert.der -storetype jks -genkeystore yes

このコマンドでは、aaa_key.derおよびaaa_cert.derはDER形式の秘密鍵と証明書のペアです。

5. プロンプトが表示されたら、キーストアのパスワードを入力します。これはグローバル・パス・フレーズと同じである必要があります。

2.5.3.2 「証明書」トランスポート・セキュリティ・モード

証明書トランスポート・セキュリティ・モードでは、サーバーおよびエージェントの証明書を認証局にリクエストする必要があります。オプションにより、証明書モード証明書を発行する目的で、簡易モードの自己署名証明書を認証局として使用することもできます。

証明書モードを準備するには、次の手順を実行します。

1. アクセス・クライアントおよびOAMサーバーに対して発行された証明書とキーのペアを使用して、認証局のCA証明書をインポートします。「CA証明書のインポート」の手順を実行してください。cacert.pemまたはcacert.derのかわりに、発行局のCA証明書ファイルを使用します。

2. Oracle Access Manager 10g JNI ASDKインストールが使用可能である場合、アクセス・クライアントの証明書およびキー・ファイルを生成できます。これらの証明書はPEM形式となります。
インポートされたCA証明書を使用した証明書の生成方法の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

この証明書とキーのペアをPEM形式でoamclient-keystore.jksにインポートするには、「キーストアの設定」の手順を実行します。

2.6 アクセス・クライアントの開発

この項で説明する項目は、次のとおりです。

- アクセス・クライアントの概要

- アクセス・クライアントの構造

2.6.1 アクセス・クライアントの概要

アクセス・クライアントは、OAMサーバーで保護されたLDAPドメイン内のリソースへのユーザーのアクセス・リクエストを処理します。一般的には、リソース・リクエストを受け取るサーブレット(プラグイン)またはスタンドアロン・アプリケーションにカスタム・アクセス・クライアント・コードを埋め込みます。このコードは、Access Manager APIライブラリを使用して、OAMサーバー上での認証および認可サービスを実行します。

リソースが保護されていない場合、アクセス・クライアントはリクエストされたリソースに対する自由なアクセスをユーザーに許可します。リソースが保護されていて、ユーザーがアクセスを得るために特定の資格証明を提示できるように認可されている場合は、アクセス・クライアントがそのユーザー資格証明の取得を試み、OAMサーバーが資格証明を確認できるようにします。ユーザーの認証とリソースへの認可が成功すると、アクセス・クライアントは、ユーザーがリソースを利用できるようにします。

アクセス・クライアントには、表2-3に示すように各種要素に応じてバリエーションがあります。

表2-3 アクセス・クライアントのバリエーション

バリエーション

説明

アプリケーションのタイプ

スタンドアロン・アプリケーション対サーバー・プラグインです。

開発言語

各開発言語により、APIの基礎となる機能へのインタフェースを選択できます。

Oracle Access Manager 11gでは、Javaはカスタム・アクセス・クライアントの唯一の開発言語です。

リソース・タイプ

HTTPおよびHTTP以外の両方のリソースを保護します。

資格証明の取得

他のメソッド間における、HTTPフォーム・ベース入力、セッション・トークンの使用およびコマンドライン入力を有効にします。

2.6.1.1 カスタム・アクセス・クライアントを作成するケース

一般に、Oracle Access Managerによってまだデフォルト・ソリューションが用意されていないリソースへのアクセスを制御する必要がある場合に、標準のWebゲートのかわりに、カスタム・アクセス・クライアントをデプロイします。これには次のような場合が含まれます。

- HTTP以外のリソースの保護。

- 特殊機能を実装するために開発したカスタムWebサーバーの保護(リバース・プロキシなど)。

- HTTPとHTTP以外のリソースの組合せを保護するためのシングル・サインオン(SSO)の実装。
たとえば、Oracle WebLogic ServerクラスタおよびOracle WebLogic Server以外のリソースが含まれる企業環境内でのSSOを容易にするアクセス・クライアントを作成できます。

2.6.1.2 アクセス・クライアントのアーキテクチャ

表2-4に示すように、各アクセス・クライアントは3つのタイプのリソースから作成されます。

表2-4 アクセス・クライアントを作成するためのリソース

リソース

説明

カスタム・アクセス・クライアント・コード

サーブレットまたはスタンドアロン・アプリケーションに組み込まれます。Oracle Access Manager 11gでは、Java言語プラットフォームを使用してアクセス・クライアント・コードを記述します。

構成情報

- Access SDKに必要なプライマリ構成ファイルはObAccessClient.xmlであり、アクセス・クライアント・プロファイルを構成する構成情報が含まれます。

- アクセス・クライアントがOAMサーバーと相互作用するように構成されているトランスポート・セキュリティ・モード(オープン、簡易または証明書)に応じて、追加の構成アーティファクトが必要です。セキュリティ・モードが簡易または証明書の場合、次のファイルが必要です。

- oamclient-truststore.jks: 証明書発行局のCA証明書が含まれるJKS形式の信頼ストア・ファイル。

- oamclient-keystore.jks: アクセス・クライアントに対して発行された証明書および秘密鍵ファイルが含まれるJKS形式のキー・ストア・ファイル。

- password.xml: グローバル・パス・フレーズの値を保持するXMLファイル。秘密鍵ファイルの保護を解除する際にも同じパスワードが使用されます。

Access Manager APIライブラリ

アクセス・クライアントとOAMサーバーの相互作用を容易にします。

図2-1は、ホスト・サーバー上にインストールされるアクセス・クライアントのコンポーネントを示しています。

図2-1 アクセス・クライアントのアーキテクチャの詳細

「図2-1 アクセス・クライアントのアーキテクチャの詳細」の説明

2.6.1.3 アクセス・クライアント・リクエストの処理の概要

第2.6.1.2項「アクセス・クライアントのアーキテクチャ」で説明しているリソースのタイプにより生じる多様性にかかわらず、アクセス・クライアントの多くは同じ基本ステップに従ってユーザー・リクエストを処理します。

ユーザーまたはアプリケーションが、アクセス・クライアントがインストールされているサーバー上で動作するサーブレットまたはアプリケーションに対してリソース・リクエストを発行すると、そのサーブレットまたはアプリケーションに埋め込まれたアクセス・クライアント・コードが次の図に示す基本プロセスを開始します。

図2-2は、リソース・リクエストの処理方法を示しています。

図2-2 プロセスの概要: リソース・リクエストの処理

「図2-2 プロセスの概要: リソース・リクエストの処理」の説明

プロセスの概要: リソース・リクエストの処理

1. アクセス・クライアント・コードが埋め込まれているアプリケーションまたはサーブレットが、ユーザーのリソース・リクエストを受け取ります。

2. アクセス・クライアントにより、ResourceRequest構造体が構成されます。この構造体は、リクエストされたリソースが保護されているかどうかをアクセス・クライアント・コードがOAMサーバーに問い合せるために使用されます。

3. OAMサーバーが応答します。

4. 状況に応じて、次のいずれかが発生します。

- リソースが保護されていない場合、アクセス・クライアントはリソースに対するアクセスをユーザーに許可します。

- リソースが保護されている場合、アクセス・クライアントがAuthenticationScheme構造体を構成、使用して、ユーザーがどの資格証明を提示する必要があるかをOAMサーバーに問い合せます。このステップは、アクセス・クライアントでリソース別の認証スキームを使用できる場合にのみ必要です。

5. OAMサーバーが応答します。

6. アプリケーションは、フォームまたはその他の手段を使用してユーザー資格証明を要求します。場合によっては、ユーザー資格証明が次の一部としてすでに発行されていることがあります。

- 有効なセッション・トークン

- Webブラウザからの入力

- アクセス・クライアント・アプリケーションを起動したコマンドライン・スクリプトの引数またはキーボード入力

7. ユーザーがアプリケーションに応答します。

8. アクセス・クライアントによりUserSession構造体が構成され、この構造体を通して、OAMサーバーはユーザー資格証明を取得し、資格証明をOracle Access Managerユーザー・ディレクトリ内のユーザー・プロファイルにマップします。

9. 資格証明が有効と判定されると、アクセス・クライアントがユーザーのセッション・トークンを作成し、認可リクエストをOAMサーバーに送信します。このリクエストには、ユーザーID、ターゲット・リソースの名前およびリクエストされた操作が含まれています。

10. アクセス・クライアントはリソースへのアクセス権をユーザーに付与しますが、これはユーザーがリクエストした特定のリソースに対する操作を行う権限がある場合に限られます。

11. (図に対応部分なし)。正常に動作する場合、アクセス・クライアントは、作成したオブジェクトによって使用されているメモリーの割当てを解除して、Access Manager APIを停止します。

「プロセスの概要: リソース・リクエストの処理」で説明しているステップは、認可プロセスの主な経路のみ示しています。その後に分岐する次の場合については、通常、サーブレットまたはアプリケーション内の追加コード部分によって処理されます。

- リクエストされたリソースが保護されていない場合。

- 保護されたリソースに関連付けられている認証チャレンジ・メソッドがアプリケーションでサポートされていない場合。

- 有効なシングル・サインオンCookie (ObSSOCookie)がユーザーにあり、Cookieに埋め込まれたセッション・トークンが現在でも有効なため、資格証明を再提示しなくてもリソースにアクセスできる場合。ObSSOCookiesおよびシングル・サインオンの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

- ユーザーが、指定された条件で有効な資格証明を提示できなかった場合。

- その他のエラー状態が発生した場合。

- 特殊な状況や機能を処理するために、開発者がアクセス・クライアントに追加のカスタム・コードを組み込んである場合。

2.6.2 アクセス・クライアントの構造

一般的なアクセス・クライアント・アプリケーションの構造は、アクセス・クライアント・セッションの設定に必要な一連のイベントを大まかにミラー化しています。

アクセス・クライアント・アプリケーション構造セクション

1. 必要なライブラリをインクルードまたはインポートします。

2. リソースを取得します。

3. 認証スキームを取得します。

4. 認証スキームに必要となるユーザー資格証明を収集します。

5. ユーザー・セッションを作成します。

6. リソースに対するユーザー認可をチェックします。

7. クリーン・アップします(Javaは自動ガベージ・コレクションを使用)。

8. 停止します。

2.6.2.1 アクセス・クライアントの一般的な実行フロー

HTTPフォーム・ベースのアクセス・クライアントのアプリケーションとプラグインは、すべて次の図に示すような同じ基本パターンを実行します。図2-3は、フォーム・ベースのアプリケーションのプロセス・フローを示しています。

図2-3 フォーム・ベースのアプリケーションのプロセス・フロー

「図2-3 フォーム・ベースのアプリケーションのプロセス・フロー」の説明

プロセスの概要: アクセス・クライアントによるフォーム・ベースのアプリケーションの実行

1. ライブラリをインポートします。

2. SDKを初期化します。

3. ResourceRequestオブジェクトを作成します。

4. リクエストされたリソースが保護されているかどうかを判別します。
リソースが保護されていない場合: アクセスを許可し、APIを停止し、プログラムを終了します。

5. リクエストされたリソースが保護されている場合: AuthenticationSchemeオブジェクトを作成します。

6. HTTPフォーム・ベースの認証スキームの場合: ユーザーIDとパスワードを含む構造体を作成し、UserSessionオブジェクトを作成し、ユーザーが認証されるかどうかを判定します。

7. HTTPフォーム・ベースでない認証スキームの場合: アクセスを拒否して理由を報告し、APIを停止し、プログラムを終了します。

8. ユーザーが認証された場合: ユーザーが認可されるかどうかを判定します(ステップ10)。

9. ユーザーが認証されていない場合: アクセスを拒否して理由を報告し、APIを停止し、プログラムを終了します。

10. ユーザーが認可された場合: アクセスを許可し、APIを停止し、プログラムを終了します。

11. ユーザーが認可されなかった場合: アクセスを拒否して理由を報告し、APIを停止し、プログラムを終了します。

注意:
このテスト・アプリケーション、あるいはその他のいずれかの例を実行する場合、アクセス・システムが正しくインストールおよび設定されていることを確認してください。特に、サンプル・プログラムで必要とされるURLと認証スキームに完全に一致するリソースが保護されるように構成されているかどうかを確認してください。アプリケーション・ドメインの作成およびアプリケーション・ドメインによるリソースの保護の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

2.6.2.2 簡易アクセス・クライアントの例: JAccess Client.java

この例は、簡易アクセス・クライアント・プログラムです。ここでは、動作中のアクセス・クライアントに必要な最小限のタスクの実装方法を示しています。

簡易アクセス・クライアントの処理: JAccess Client.java

- OAMサーバーに接続します。

- HTTPフォーム・チャレンジ・メソッドを採用した認証スキームを使用してログインします。

- HTTP GETリクエストを使用してリソースの認証を確認します。

- Access SDK APIの例外を捕捉およびレポートします。

通常、このコール順序は、フォーム・チャレンジ・メソッドを使用するアクセス・クライアントに共通です。フォーム・メソッドのアクセス・クライアント間の主な違いは、認証に必要な資格証明と保護するリソース・タイプです。

JAccess Client.javaの完全なリストは例2-1に示しています。このコードをテキスト・ファイルJAccess Client.javaに一字一句すべてコピーし、Access Manager SDKがインストールされているコンピュータ上でこれを実行できます。

第2.6.2.2.1項「注釈付きコード: JAccess Client.java」では、Java Access Manager APIコールに慣れることができるよう、注釈付きコードを1行ずつ示しています。

例2-1 JAccess Client.java

import java.util.Hashtable;
import oracle.security.am.asdk.*;

public class JAccessClient {
public static final String ms_resource = "//Example.com:80/secrets/
index.html";
public static final String ms_protocol = "http";
public static final String ms_method = "GET";
public static final String ms_login = "jsmith";
public static final String ms_passwd = "j5m1th";
public String m_configLocation = "/myfolder";
public static void main(String argv[]) {
AccessClient ac = null;
try {
ac = AccessClient.createDefaultInstance(m_configLocation,
AccessClient.CompatibilityMode.OAM_10G);

ResourceRequest rrq = new ResourceRequest(ms_protocol, ms_resource,
ms_method);
if (rrq.isProtected()) {
System.out.println("Resource is protected.");
AuthenticationScheme authnScheme = new AuthenticationScheme(rrq);
if (authnScheme.isForm()) {
System.out.println("Form Authentication Scheme.");
Hashtable creds = new Hashtable();
creds.put("userid", ms_login);
creds.put("password", ms_passwd);
UserSession session = new UserSession(rrq, creds);
if (session.getStatus() == UserSession.LOGGEDIN) {
if (session.isAuthorized(rrq)) {
System.out.println("User is logged in and authorized for the"
+"request at level " + session.getLevel());
} else {
System.out.println("User is logged in but NOT authorized");
}
//user can be loggedout by calling logoff method on the session object
} else {
System.out.println("User is NOT logged in");
}
} else {
System.out.println("non-Form Authentication Scheme.");
}
} else {
System.out.println("Resource is NOT protected.");
}
}
catch (AccessException ae) {
System.out.println("Access Exception: " + ae.getMessage());
}
ac.shutdown();
}
}

2.6.2.2.1 注釈付きコード: JAccess Client.java

資格証明を保持する標準Javaライブラリ・クラス・ハッシュテーブルをインポートします。

import java.io.Hashtable;

Access SDK APIクラスのJava実装が含まれるライブラリをインポートします。

import oracle.security.am.asdk.*;

このアプリケーションにJAccessClientと命名します。

public class JAccessClient {

このアプリケーションは最も単純な例のため、リソースへのユーザー・アクセス・リクエストに関連したパラメータを表すためにグローバル定数を宣言することとします。

このパラメータ・セットは、実際のアプリケーションでは通常、リクエスト元アプリケーション、HTTPフォーム入力またはコマンドライン入力から渡される文字列の配列として受信されます。次に例を示します。

public static final String ms_resource = "//Example.com:80/secrets/index.html";
public static final String ms_protocol = "http";
public static final String ms_method = "GET";
public static final String ms_login = "jsmith";
public static final String ms_passwd = "j5m1th";

Javaインタプリタ上でメイン・メソッドを起動します。argvという名前の文字列配列がメイン・メソッドに渡されます。この例では、jsmithというユーザーが、j5m1thというパスワードを使用して、HTTPリソースの//Example.com:80/secrets/index.htmlをリクエストします。GETは、リクエスト先リソースに対して実行するHTTP操作です。サポートされているHTTP操作およびアプリケーション・ドメインによるリソースの保護の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

public static void main(String argv[]) {

メイン・メソッド内のすべての関連するプログラム文をtryという大きなブロック内に配置し、プログラム終了までにすべての例外をこの捕捉用ブロックで捕捉できるようにします。

AccessClient ac = null;

try {

構成ファイルObAccessClient.xmlのディレクトリの場所を指定し、アクセス・クライアント・インスタンスを作成してAccess SDKを初期化します。Access SDKを初期化するための構成場所を指定するには複数の方法があります。詳細は、Oracle Access Manager Access SDK Java APIリファレンスを参照してください。

作成する必要があるのはアクセス・クライアントのインスタンスのみであり、これがAccess SDK APIを初期化します。AccessClient.CompatibilityMode.OAM_10Gは、Oracle Access Managerの10gおよび11gリリースと互換性があるモードで動作するようAccess SDKが初期化されることを示します。

ac = AccessClient.createDefaultInstance(m_configLocation ,
AccessClient.CompatibilityMode.OAM_10G);

ResourceRequestコンストラクタを次の3つのパラメータとともに使用して、rrqという名前の新規のリソース・リクエスト・オブジェクトを作成します。

- ms_protocol: リクエストするリソースのタイプを示します。未指定の場合、デフォルト値はHTTPです。使用可能な値としてEJBもありますが、ここでの例にはこれは使用しません。『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』で説明しているように、カスタム・タイプを作成することもできます。

- ms_resource: リソース名です。この特定の例でリクエストされたリソース・タイプはHTTPであるため、次のようにリソース名の先頭にホスト名およびポート番号を追加することは有効です。

//Example.com:80/secrets/index.html

- ms_method: リソースに対して実行する操作のタイプです。リソース・タイプがHTTPの場合、指定可能な操作はGETとPOSTです。EJBタイプのリソースでは、操作はEXECUTEにかぎります。カスタム・リソース・タイプの場合、リソース・タイプを設定する際に、許可する操作を定義します。リソース・タイプの定義およびアプリケーション・ドメインによるリソースの保護の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

ResourceRequest rrq = new ResourceRequest(ms_protocol,
ms_resource, ms_method);

リクエスト先リソースrrqが認証スキームによって保護されているかどうかを確認します。

if (rrq.isProtected()) {

リソースが保護されている場合は、そのことをレポートします。

System.out.println("Resource is protected.");

AuthenticationSchemeコンストラクタを使用して、authnSchemeという名前の認可スキーム・オブジェクトを作成します。リソース・リクエストrrqを指定し、この特定のリソースに特定の認可スキームが関連付けられているかどうかを、AuthenticationSchemeに確認させます。

AuthenticationScheme authnScheme =new AuthenticationScheme(rrq);

フォーム・ベースの認可スキームが使用されているかどうかを判別します。

if (authnScheme.isForm()) {

認可スキームがチャレンジ・メソッドとしてHTTPフォームを使用している場合、そのことを報告してから、ユーザー名(userid)およびユーザー・パスワード(password)を表すname:valueペアを保持するための、credsという名前のハッシュテーブルを作成します。ms_loginおよびms_passwdの値をハッシュテーブルに読み込みます。

System.out.println("Form Authentication Scheme.");
Hashtable creds = new Hashtable();
creds.put("userid", ms_login);
creds.put("password", ms_passwd);

UserSessionコンストラクタを使用して、sessionという名前のユーザー・セッション・オブジェクトを作成します。リソース・リクエストをrrqに、認証スキームをcredsに指定して、認証試行が成功したかどうかを示す状態情報が含まれる新規の構造体をUserSessionが戻すようにします。

UserSession session = new UserSession(rrq, creds);

UserSession状態情報に対してgetStatusメソッドを起動し、ユーザーが正常にログインできたか(認証されたか)どうかを確認します。

if (session.getStatus() == UserSession.LOGGEDIN) {

ユーザーが認証されている場合は、リソース・リクエスト構造体rrqに指定したリソースへのアクセスをユーザーが認可されるかどうかを確認します。

if (session.isAuthorized(rrq)) {
System.out.println(
"User is logged in " +
"and authorized for the request " +

sessionという名前のユーザー・セッションに対してgetLevelメソッドによって戻される認可レベルを確認します。

"at level " + session.getLevel());

rrqに指定されたリソースに対してユーザーが認可されていない場合は、ユーザーは認証されているが、リクエストしたリソースへのアクセスは認可されていないことを報告します。

} else {
System.out.println("User is logged in but NOT authorized");

ユーザーが認証されていない場合は、そのことを報告します。(実際のアプリケーションでは、ユーザーに認証のための機会をさらに与える場合があります)。

} else {
System.out.println("User is NOT logged in");

認証スキームでHTTPフォーム・ベースのチャレンジ・メソッドが使用されていない場合は、そのことを報告します。実際のアプリケーションでは、このようなとき、basic(useridとpasswordのみを要求する)、certificate(SSL over HTTPSまたはTLS over HTTPS)、またはsecure(リダイレクトURLによるHTTPS)など、認可スキームに指定されている他のチャレンジ・メソッドを提供するように分岐する場合があります。チャレンジ・メソッドおよびユーザー認証の構成の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

} else {
System.out.println("non-Form Authentication Scheme.");
}

リソースが保護されていない場合は、そのことを報告します。(アクセス・クライアントはリソースを保護しようとしなくなるので、ユーザーはリクエストしたリソースへのアクセスを自動的に取得します)

} else {
System.out.println("Resource is NOT protected.");
}
}

前述のtryブロック内でエラーが発生した場合は、オブジェクトaeから関連テキスト・メッセージを取得して、これを報告します。

catch (AccessException ae) {
System.out.println(
"Access Exception: " + ae.getMessage());
}

アプリケーションにおいてユーザーのログアウトが必要な場合は、UserSessionクラスのオブジェクト上でログオフ・メソッドを起動できます。

これで、OAMサーバーへのコールが終了になるため、APIを停止して、このコールでAPIが保持してきたメモリーを解放します。

ac.shutdown();
}
}

プログラムを終了します。このアプリケーションで作成した構造体が使用するメモリーは、不要になった時点でJava Garbage Collectionにより自動的にクリーンアップされるので、割当て解除する必要はありません。

2.6.2.3 例: Javaログイン・サーブレット

この例では、第2.6.2.2項「簡易アクセス・クライアントの例: JAccess Client.java」で説明しているように、アクセス・クライアントを定義するAPIコールの基本パターンを実行しています。ただしこの例は、Webサーバーまたはアプリケーション・サーバー内で実行されるJavaサーブレットとして実装されています。アクセス・クライアント・サーブレットは、この環境では、Webアプリケーションのユーザーに対してさらに重要な役割を果すことができます。サーブレットは、セッション・トークンをユーザーのHTTPセッション内に格納することで、ユーザーがシングル・サインオンできるようにします。つまり、最初のリクエストで確立された認証済OAMサーバー・セッション情報は、1回認可確認した後でも破棄されません。格納されたセッション・トークンは、破棄されずに、Beansやその他のサーブレットなどのサーバー側アプリケーション・コンポーネントで利用できるようになり、これらのコンポーネントが同じ資格証明をリクエストするためにユーザーに繰り返し割り込む必要がなくなります。セッション・トークン、ObSSOCookiesおよびシングル・サインオンの構成の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

このサンプル・ログイン・サーブレットは、カスタム・ログイン・ページ上のフォームでuserid/passwordパラメータを受け付け、ユーザーにOracle Access Managerへのログインの機会を提供します。ログインが成功した場合、サーブレットは、セッション・トークンをUserSessionオブジェクト内に格納します。これにより、同じHTTPセッション内の後続のリクエストは認証ステップをバイパスし(後続のリクエストが最初のリクエストと同じ認証スキームを使用する場合)、シングル・サインオンを実現します。

Javaログイン・サーブレットの完全なリストは、例2-2に示しています。このコードは、Webサーバーまたはアプリケーション・サーバーに組み込むプラグインのベースとして使用できます。

第2.6.2.3.1項「注釈付きコード: Javaログイン・サーブレット」は、このコードの注釈付きバージョンです。

例2-2 Javaログイン・サーブレットの例

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
import oracle.security.am.asdk.*;

public class LoginServlet extends HttpServlet {

public void init(ServletConfig config) throws ServletException {
try {

AccessClient ac = AccessClient.createDefaultInstance("/myfolder" ,
AccessClient.CompatibilityMode.OAM_10G);
} catch (AccessException ae) {
ae.printStackTrace();
}
}

public void service(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
AuthenticationScheme authnScheme = null;
UserSession user = null;
ResourceRequest resource = null;
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<HTML>");
out.println("<HEAD><TITLE>LoginServlet: Error Page</TITLE></HEAD>");
out.println("<BODY>");
HttpSession session = request.getSession( false);
String requestedPage = request.getParameter("request");
String reqMethod = request.getMethod();
Hashtable cred = new Hashtable();
try {
if (requestedPage == null || requestedPage.length()==0) {
out.println("<p>REQUESTED PAGE NOT SPECIFIED\n");
out.println("</BODY></HTML>");
return;
}
resource = new ResourceRequest("http", requestedPage, "GET");
if (resource.isProtected()) {
authnScheme = new AuthenticationScheme(resource);
if (authnScheme.isBasic()) {
if (session == null) {
String sUserName = request.getParameter("userid");
String sPassword = request.getParameter("password");
if (sUserName != null) {
cred.put("userid", sUserName);
cred.put("password", sPassword);
user = new UserSession(resource, cred);
if (user.getStatus() == UserSession.LOGGEDIN) {
if (user.isAuthorized(resource)) {
session = request.getSession( true);
session.putValue( "user", user);
response.sendRedirect( requestedPage );
} else {
out.println("<p>User " + sUserName + " not" +
" authorized for " + requestedPage + "\n");
}
} else {
out.println("<p>User" + sUserName + "NOT LOGGED IN\n");
}
} else {
out.println("<p>USERNAME PARAM REQUIRED\n");
}
} else {
user = (UserSession)session.getValue("user");
if (user.getStatus() == UserSession.LOGGEDIN) {
out.println("<p>User " + user.getUserIdentity() + " already"+
"LOGGEDIN\n");
}
}
} else {
out.println("<p>Resource Page" + requestedPage + " is not"+
" protected with BASIC\n");
}
} else {
out.println("<p>Page " + requestedPage + " is not protected\n");
}
} catch (AccessException ex) {
out.println(ex);
}
out.println("</BODY></HTML>");
}
}

2.6.2.3.1 注釈付きコード: Javaログイン・サーブレット

システム入出力および基本機能を実装する標準Javaパッケージをインポートします。

import java.io.*;
import java.util.*;

サーブレット関連機能を実装する2つのJava拡張機能パッケージをインポートします。

import javax.servlet.*;
import javax.servlet.http.*;

Access SDK APIのJava実装であるoracle.security.am.asdk.jarパッケージをインポートします。

import oracle.security.am.asdk.*;

このサーブレットは、Java Enterprise Editionでサポートされている汎用HttpServletの機能をベースにビルドされており、LoginServletという名前です。

public class LoginServlet extends HttpServlet {

サーブレット・エンジンはinitメソッドを1回コールして、アクセス・クライアントを初期化します。initメソッドでは、構成ファイルObAccessClient.xmlの場所を渡し、アクセス・クライアントをインスタンス化してAccess SDKを初期化できます。アクセス・クライアントの作成の詳細は、Oracle Access Manager Access SDK Java APIリファレンスを参照してください。OAM_10g互換性フラグにより、OAM 10gサーバーおよびOAM 11gサーバーの両方と互換性があるモードでAccess SDKが初期化されました。

初期化に失敗した場合は、そのことを該当のエラー・メッセージとともに報告します。

public void init() {
AccessClient ac =
AccessClient.createDefaultInstance("/myfolder" ,
AccessClient.CompatibilityMode.OAM_10G);
} catch (AccessException ae) {
ae.printStackTrace();
}
}

javax.servlet.serviceメソッドを起動し、ユーザーのリソース・リクエストを処理します。

public void service(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {

メンバーをnullとして初期化します。これらはリソース・リクエストの処理に使用するアクセス構造を格納し、このアプリケーションが使用するレスポンス・タイプをtext/htmlに設定します。

AuthenticationScheme authnScheme = null;
UserSession user = null;
ResourceRequest resource = null;
response.setContentType("text/html");

LoginServlet: Error Pageという名前の出力ストリームを開き、ユーザーのブラウザにリダイレクトします。

PrintWriter out = response.getWriter();
out.println("<HTML>");
out.println("<HEAD><TITLE>LoginServlet: Error Page</TITLE></HEAD>");
out.println("<BODY>");

このユーザーのセッションがすでに存在するかどうかを確認します。パラメータとしてfalseを指定してgetSessionメソッドを起動すると、既存のサーブレット・セッション(UserSessionではない)の値が戻され(セッションが存在する場合)、存在しない場合はNULLが戻されます。

HttpSession session = request.getSession(false);

ターゲット・リソースの名前を取得して、これをrequestedPage変数に代入し、リクエストに使用されたHTTPメソッド(GET、POST、PUTなど)の名前を取得して、これをreqMethod変数に代入します。

String requestedPage = request.getParameter(Constants.REQUEST);
String reqMethod = request.getMethod();

credという名前のハッシュテーブルを作成し、ユーザーの資格証明を格納します。

Hashtable cred = new Hashtable();

requestedPage変数が空のまま戻された場合は、ターゲット・リソースの名前が正しく指定されていないことを報告し、サーブレットを終了します。

try {
if (requestedPage == null) {
out.println("<p>REQUESTED PAGE NOT SPECIFIED\n");
out.println("</BODY></HTML>");
return;
}

リクエストしたページの名前が戻された場合は、ResourceRequest構造体を作成して、次を設定します。

- リソース・タイプ: HTTP

- HTTPメソッド: GET

- resource: requestedPage変数に設定されている値

resource = new ResourceRequest("http", requestedPage, "GET");

ターゲット・リソースが保護されている場合は、リソース・リクエスト用にAuthenticationScheme構造体を作成し、名前をauthnSchemeとします。

if (resource.isProtected()) {
authnScheme = new AuthenticationScheme(resource);

ターゲット・リソースに関連付けられている認証スキームがHTTP basicで、現在ユーザー・セッションが存在しない場合は、javax.servlet.servletrequest. getParameterを起動してユーザーの資格証明であるユーザー名とパスワードを戻し、それぞれsUserNameとsPasswordの変数に代入します。

次の文でauthnScheme.isBasicコールを正しく動作させるには、次のように、ユーザー名とパスワードをユーザーのHTTPリクエストの問合せ文字列内に含める必要があります。

http://host.example.com/resource?username=bob&userpassword=bobspassword

ここで、resourceは、リクエスト先のリソース、bobはリクエスト元のユーザー、bobspasswordはユーザーのパスワードです。

authnScheme.isFormの追加コード

注意:
authnScheme.isBasicのかわりにauthnScheme.isFormを使用する場合は、追加コードを記述して、次のステップを実装する必要があります。

1. 元のリクエストを処理して、フォーム・ベースのログインが必要なことを判断します。

2. ログイン・フォームに関する302リダイレクト・レスポンスを送信し、HTTPセッションに元のリソース情報を保存します。

3. ユーザー名とパスワードとともにポストされたフォーム・データを処理して、ユーザーを認証します。

4. HTTPリソースから元のリソースを取得し、そのリソースに関する302リダイレクト・レスポンスを送信します。

5. 元のリクエストをもう1回処理しますが、今回はHTTPセッション内に格納されているUserSessionを使用して処理します。

if (authnScheme.isBasic()) {
if (session == null) {
String sUserName = request.getParameter(Constants.USERNAME);
String sPassword = request.getParameter(Constants.PASSWORD);

ユーザー名が存在する場合は、credという名前のハッシュテーブルに、関連パスワードとあわせて読み取ります。

if (sUserName != null) {
cred.put("userid", sUserName);
cred.put("password", sPassword);

resourceという名前のResourceRequest構造体とcredハッシュテーブルの情報に基づいて、ユーザー・セッションを作成します。

user = new UserSession(resource, cred);

戻されたユーザーのステータス・コードがLOGGEDINの場合、そのユーザーの認証は成功しています。

if (user.getStatus() == UserSession.LOGGEDIN) {

ターゲット・リソースへのアクセスをユーザーが認可されるかどうかを確認します。

if (user.isAuthorized(resource)) {

サーブレット・ユーザー・セッション(UserSessionと混同しないでください)を作成し、そこにユーザーの名前を追加します。

session = request.getSession( true);
session.putValue( "user", user);

ユーザーのブラウザをターゲット・ページにリダイレクトします。

response.sendRedirect(requestedPage);

ターゲット・リソースへのアクセスをユーザーが認可されなかった場合は、そのことを報告します。

} else {
out.println("<p>User " + sUserName + " not authorized
for " + requestedPage + "\n");
}

ユーザーが正しく認可されていない場合は、そのことを報告します。

} else {
out.println("<p>User" + sUserName + "NOT LOGGED IN\n");
}

ユーザー名が入力されていない場合は、そのことを報告します。

} else {
out.println("<p>USERNAME PARAM REQUIRED\n");
}

セッションがすでに存在する場合は、USERを取得し、これをuserセッション変数に代入します。

} else {
user = (UserSession)session.getValue("user");

ユーザーがログインできた場合、つまりユーザーの認証が成功した場合は、そのことをユーザー名とともに報告します。

if (user.getStatus() == UserSession.LOGGEDIN) {
out.println("<p>User " + user.getUserIdentity() + " already
LOGGEDIN\n");
}
}

ターゲット・リソースがbasic認証スキームで保護されていない場合は、そのことを報告します。

} else {
out.println("<p>Resource Page" + requestedPage + " is not protected
with BASIC\n");
}

ターゲット・リソースがどの認証スキームによっても保護されていない場合は、そのことを報告します。

} else {
out.println("<p>Page " + requestedPage + " is not protected\n");
}

エラーが発生した場合は、トレースバックを報告します。

} catch (AccessException ex) {
oe.println(ex);
}

出力をユーザーのブラウザにストリームとして送信します。

out.println("</BODY></HTML>");
}
}

2.6.2.4 追加のメソッドを使用した例: access_test_java.java

第2.6.2.2項「簡易アクセス・クライアントの例: JAccess Client.java」で説明しているように、次のサンプル・プログラムは、サンプル・アプリケーションJAccess Client.java内で確立されている基本パターンをベースとしてビルドされており、追加でいくつかのOAMサーバー・メソッドを起動しています。たとえば、セッション・オブジェクトを点検して、現在の認証スキームに関連付けられているポリシー・ルール内にどのアクションおよび名前付きレスポンスが現在構成されているかを確認します。

このデモを実行するには、アプリケーションを実行する前にOAMサーバーによりいくつかのアクションを構成する必要があります。認証アクションおよびユーザー認証の構成の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。例2–3には、このサンプル・アプリケーションの完全なリストが記載されています。

コードの注釈付きバージョンは、第2.6.2.4.1項「注釈付きコード: access_test_java.java」を参照してください。

例2-3 access_test_java.java

import java.util.*;
import oracle.security.am.asdk.*;

public class access_test_java {

public static void main(String[] arg) {
String userid, password, method, url, configDir, type,
location;
ResourceRequest res;
Hashtable parameters = null;
Hashtable cred = new Hashtable();
AccessClient ac = null;
if (arg.length < 5) {
System.out.println("Usage: EXPECTED: userid password Type
HTTP-method"
+" URL [Installdir [authz-parameters] [location]]]");
return;
} else {
userid    = arg[0];
password  = arg[1];
type      = arg[2];
method    = arg[3];
url      = arg[4];
}
if (arg.length >= 6) {
configDir = arg[5];
} else {
configDir = null;
}
if (arg.length >= 7 && arg[6] != null) {
parameters = new Hashtable();
StringTokenizer tok1 = new StringTokenizer(arg[6], "&");
while (tok1.hasMoreTokens()) {
String nameValue = tok1.nextToken();
StringTokenizer tok2 = new StringTokenizer(nameValue,
"=");
String name = tok2.nextToken();
String value = tok2.hasMoreTokens() ? tok2.nextToken() :
"";
parameters.put(name, value);
}
}
location = arg.length >= 8 ? arg[7] : null;
try {
ac = AccessClient.createDefaultInstance(configDir ,
AccessClient.CompatibilityMode.OAM_10G);

} catch (AccessException ae) {
System.out.println("OAM Server SDK Initialization
failed");
ae.printStackTrace();
return;
}
cred.put("userid", userid);
cred.put("password", password);
try {
res = new ResourceRequest(type, url, method);
if (res.isProtected()) {
System.out.println("Resource " + type + ":" + url + "
protected");
} else {
System.out.println("Resource " + type + ":" + url + "
unprotected");
}
} catch (Throwable t) {
t.printStackTrace();
System.out.println("Failed to created new resource
request");
return;
}
UserSession user = null;
try {
user = new UserSession(res, cred);
} catch (Throwable t) {
t.printStackTrace();
System.out.println("Failed to create new user session");
return;
}
try {
if (user.getStatus() == UserSession.LOGGEDIN) {
if (location != null) user.setLocation(location);
System.out.println("user status is " + user.getStatus());

if (parameters != null ? user.isAuthorized(res,
parameters) :
user.isAuthorized(res)) {
System.out.println("Permission GRANTED");
System.out.println("User Session Token =" +
user.getSessionToken());
if (location != null) {
System.out.println("Location = " +
user.getLocation());
}
} else {
System.out.println("Permission DENIED");
if (user.getError() == UserSession.ERR_NEED_MORE_DATA)
{
int nParams =
res.getNumberOfAuthorizationParameters();
System.out.print("Required Authorization Parameters
(" +
nParams + ") :");
Enumeration e =
res.getAuthorizationParameters().keys();
while (e.hasMoreElements()) {
String name = (String) e.nextElement();
System.out.print(" " + name);
}
System.out.println();
}
}
}
else
{
System.out.println("user status is " + user.getStatus());
}
} catch (AccessException ae)
{
System.out.println("Failed to get user authorization");
}
String[] actionTypes = user.getActionTypes();
for(int i =0; i < actionTypes.length; i++)
{
Hashtable actions = user.getActions(actionTypes[i]);
Enumeration e = actions.keys();
int item = 0;
System.out.println("Printing Actions for type " +
actionTypes[i]);
while(e.hasMoreElements())
{
String name = (String)e.nextElement();
System.out.println("Actions[" + item +"]: Name " + name + "
value " +  actions.get(name));
item++;
}
}
AuthenticationScheme auths;
try
{
auths = new AuthenticationScheme(res);
if (auths.isBasic())
{
System.out.println("Auth scheme is Basic");
}
else
{
System.out.println("Auth scheme is NOT Basic");
}
}
catch (AccessException ase)
{
ase.printStackTrace();
return;
}
try
{
ResourceRequest resNew = (ResourceRequest) res.clone();
System.out.println("Clone resource Name: " +
resNew.getResource());
}
catch (Exception e)
{
e.printStackTrace();
}
res = null;
auths = null;
ac.shutdown();
}
}

2.6.2.4.1 注釈付きコード: access_test_java.java

基本ユーティリティ、列挙およびトークン処理機能を実装する標準のJavaライブラリをインポートします。

import java.util.*;

Access SDK APIライブラリをインポートします。

import oracle.security.am.asdk.*;

このクラスにaccess_test_javaという名前を付けます。

public class access_test_java {

argという名前の配列で渡される値を格納する、7つの変数文字列を宣言します。

public static void main(String[] arg) {
String userid, password, method, url, configDir, type, location;

現在のResourceRequestをresに設定します。

ResourceRequest res;

まだ空になっていない可能性を考慮して、ハッシュテーブル・パラメータをnullに初期化します。

Hashtable parameters = null;

credという名前の新規のハッシュテーブルを作成します。

Hashtable cred = new Hashtable();

アクセス・クライアント参照をnullに初期化します。

AccessClient ac = null;

argという名前の配列に含まれている文字列が5個未満の場合、コマンドライン入力で予期している構文と内容を報告します。これは順序が指定された5個の必須引数、およびオプションの変数であるconfigDir、authz-parametersおよびlocationです。

if (arg.length < 5) {
System.out.println("Usage: EXPECTED: userid password type
HTTP-method URL [configDir [authz-parameters] [location]]]");

最初に指定された引数が5個未満の場合、メイン・メソッドを終了することで事実上プログラムの実行を終了します。

return;
} else {

argという名前の配列に5個以上の文字列がある場合は、最初の5個の引数(arg[0]からarg[4])をuserid、password、type、method、urlの変数に代入します。

userid = arg[0];
password = arg[1];
type = arg[2];
method = arg[3];
url = arg[4];
}

argに6個以上の引数がある場合は、配列内の6番目の文字列をconfigDir変数に代入します。

if (arg.length >= 6)
configDir = arg[5];

argに6個以上の引数がない場合、つまり、5個以下ではないことをすでに確認し、ちょうど5個の引数があることがわかっている場合は、configDirをNULLに設定します。

else
configDir = null;

argに7個以上の文字列があり、arg[6] (authz-parameters変数に暗黙のうちに割り当てられる)が空ではない場合、parametersという名前の新規のハッシュテーブルを作成します。authz-parameters文字列の構文の形式: p1=v1&p2=v2&...

if (arg.length >= 7 && arg[6] != null) {
parameters = new Hashtable();

デリミタとしてアンパサンド記号(&)を使用して、tok1という名前の文字列トークン関数を作成し、arg[6]を解析します。これにより、arg[6]がpn=vnの形式でトークンの配列に分解されます(nはトークンの連番)。

StringTokenizer tok1 = new StringTokenizer(arg[6], "&");

tok1のすべてのアイテムについて、直後のトークンをnameValue変数として戻します。このようにして、nameValueに文字列pn=vnが代入されます(nはトークンの連番)。

while (tok1.hasMoreTokens()) {
String nameValue = tok1.nextToken();

デリミタとして等記号(=)を使用して、tok2という名前の文字列トークン関数を作成し、nameValueを解析します。このようにして、pn=vnをpnとvnのトークンに分解します。

StringTokenizer tok2 = new StringTokenizer(nameValue, "=");

最初のトークンをname変数に代入します。

String name = tok2.nextToken();

2番目のトークンをvalueに代入します。tok2に他のトークンが残っている場合は、直後のトークンを戻し、これをvalueに代入します。残っていない場合は、空文字列をvalueに代入します。

String value = tok2.hasMoreTokens() ? tok2.nextToken() : "";

parametersハッシュテーブルにnameとvalueを挿入します。

parameters.put(name, value);
}
}

arg内に8個以上の引数がある場合は、arg[7]をlocation変数に代入します。ない場合は、locationを空にします。

location = arg.length >= 8 ? arg[7] : null;

他のオプションを使用して提供する構成ファイルの場所がnullである場合、configDirを使用してAccessClientインスタンスを作成します。アクセス・クライアントの作成の詳細は、Oracle Access Manager Access SDK Java APIリファレンスを参照してください。

try {
ac = AccessClient.createDefaultInstance(configDir ,
AccessClient.CompatibilityMode.OAM_10G);
}

初期化の試行によりエラーが発生した場合は、トレースバックとともに標準エラー・ストリームに当該のエラー・メッセージ(ae)を報告します。

catch (AccessException ae) {
System.out.println("
OAM Server SDK Initialize failed");
ae.printStackTrace();

メイン・メソッドを終了することで、事実上プログラムを終了します。

return;
}

各変数、ユーザーIDおよびパスワードをcredという名前のハッシュテーブルに読み取ります。

cred.put("userid", userid);
cred.put("password", password);

resという名前のResourceRequestオブジェクトを作成すると、変数タイプ、URLおよびメソッドの値がOAMサーバーから戻されます。

try {
res = new ResourceRequest(type, url, method);

リクエストしたリソースresが保護されているかどうかを確認して、該当するメッセージを表示します。

if (res.isProtected())
System.out.println("Resource " + type ":" + url + " protected");
else
System.out.println("Resource " + type + ":" + url + " unprotected");
}

ResourceRequest構造体を作成できなかった場合は、エラー・メッセージtとともに障害を報告します。

catch (Throwable t) {
t.printStackTrace();
System.out.println("Failed to create new resource request");

メイン・メソッドを終了することで、事実上プログラムを終了します。

return;
}

UserSessionパラメータのuserを空に設定します。

UserSession user = null;

ResourceRequest構造体のresとAuthenticationScheme構造体のcredの値を戻す、userという名前のUserSession構造体を作成します。

try
user = new UserSession(res, cred);

UserSession構造体を作成できなかった場合は、エラー・メッセージtとともに障害を報告します。

catch (Throwable t) {
t.printStackTrace();
System.out.println("Failed to create new user session");

メイン・メソッドを終了することで、事実上プログラムを終了します。

return;
}

ユーザーが現在ログインしているかどうか、つまりこのユーザーの認証が成功しているかどうかを確認します。

try
{
if (user.getStatus() == UserSession.LOGGEDIN) {

ユーザーがログインしている場合は、location変数が空でないかどうかを確認します。locationが空でない場合は、AccessClientのlocationパラメータにこのlocation変数の値を設定し、OAMサーバーが戻すステータス・コードとともに、ユーザーがログインしていることを報告します。

if (location != null) user.setLocation(location);
System.out.println("user status is " + user.getStatus());

認可をチェックします。これを行うには、parametersが存在するかどうかを確認します。存在する場合は、parametersに格納されているパラメータをアタッチしたときにターゲット・リソースへのアクセスがユーザーに認可されるかどうかを確認します。parametersが存在しない場合は、ターゲット・リソースへのアクセスがユーザーに認可されているかどうかを確認します。

try {
if (parameters != null ? user.isAuthorized(res, parameters) :
user.isAuthorized(res)) {

存在するすべてのパラメータを指定したときにユーザーがリソースへのアクセスを認可される場合は、権限が付与されたことを報告します。

System.out.println("Permission GRANTED");

さらに、ユーザー・セッション・トークンをシリアル番号付きで表示します。

System.out.println("User Session Token =" + user.getSessionToken());

location変数が空でない場合は、その値を報告します。

if (location != null) {
System.out.println("Location = " + user.getLocation());
}

リソースへのアクセスをユーザーが認可されなかった場合は、権限が拒否されたことを報告します。

} else {
System.out.println("Permission DENIED");

UserSessionがERR_NEED_MORE_DATAを戻す場合は、nParams変数を認可に必要なパラメータの数に設定し、その数値をユーザーに報告します。

if (user.getError() == UserSession.ERR_NEED_MORE_DATA) {
int nParams = res.getNumberOfAuthorizationParameters();
System.out.print("Required Authorization Parameters (" +
nParams + ") :");

resという名前のResourceRequestオブジェクトのgetAuthorizationParametersメソッドによって戻されるハッシュテーブルのkeysパラメータの値として、eを設定します。

Enumeration e = res.getAuthorizationParameters().keys();

eに含まれているすべての要素の名前を報告します。

while (e.hasMoreElements()) {
String name = (String) e.nextElement();
System.out.print(" " + name);
}
System.out.println();
}

そうでない場合は、次の文に進みます。

else
}
}

ユーザーがログインできなかった場合は、現在のユーザー・ステータスを報告します。

else
System.out.println("user status is " + user.getStatus());

エラーが発生した場合は、認可の試行が失敗したことを報告します。

catch (AccessException ae)
System.out.println("Failed to get user authorization");
}

ここで、現行のユーザー・セッションに現在設定されているすべてのアクションを報告します。これを行うには、getActionTypesメソッドによって戻される文字列からactionTypesという名前の配列を作成します。次に、actionTypes内の各文字列をactionsという名前のハッシュテーブルに読み取ります。actionsに含まれている各キーの名前および値を報告します。

String[] actionTypes = user.getActionTypes();
for(int i =0; actionTypes[i] != null; i++){
Hashtable actions = user.getActions(actionTypes[i]);
Enumeration e = actions.keys();
int item = 0;
System.out.println("Printing Actions for type " + actionTypes[i]);
while(e.hasMoreElements()) {
String name = (String)e.nextElement();
System.out.println("Actions[" + item +"]: Name " + name + " value " +
actions.get(name));
item++;
}
}

ResourceRequestオブジェクトのresに対するauthsという名前のAuthenticationSchemeオブジェクトの作成を試みます。

AuthenticationScheme auths;
try
auths = new AuthenticationScheme(res);

AuthenticationSchemeを作成できなかった場合は、エラー・メッセージaseとともに障害を報告します。

catch (AccessException ase) {
ase.printStackTrace();

メイン・メソッドを終了することで、事実上プログラムを終了します。

return;
}

認可スキームがBasicかどうかを確認します。

try
{
if (auths.isBasic())

Basicの場合は、そのことを報告します。

System.out.println("Auth scheme is Basic");

Basicではない場合は、そのことを報告します。

else
System.out.println("Auth scheme is NOT Basic");

コピー・コンストラクタを使用して、元オブジェクトresからresNEWという名前の新規のResourceRequestオブジェクトを作成します。

ResourceRequest resNew = (ResourceRequest) res.clone();

新しくクローニングしたオブジェクトの名前を報告します。

System.out.println("Clone resource Name: " + resNew.getResource());

なんらかの理由によりResourceRequestオブジェクトがクローニングできなかった場合は、対応するトレースバックによって障害を報告します。

}
catch (Exception e) {
e.printStackTrace();
}

ResourceRequestオブジェクトresとAuthenticationSchemeオブジェクトauthsをNULLに設定し、Access SDK APIを切断します。

res = null;
auths = null;
ac.shutdown();
}
}

2.6.2.5 Javaにおける証明書ベース認証の実装の例

次のコードの抜粋では、X.509証明書を処理するアクセス・クライアントのJavaでの実装例を示しています。この抜粋は、管理者がアクセス・システムに証明書ベースの認証を構成する場合に適しています。

証明書はBase64でエンコードされている必要があります。OAMサーバーでは、ユーザーの識別にのみこの証明書を使用します。有効期間、ルート認証が信頼されているかどうかなどの検証は実行されません。

File oCertFile = new File("sample_cert.pem");
FileInputStream inStream = new FileInputStream(oCertFile);
CertificateFactory cf =
CertificateFactory.getInstance("X.509");

// cert must point to a valid java.security.cert.X509Certificate instance.
X509Certificate cert = (X509Certificate)
cf.generateCertificate(inStream);

// Convert the certificate into a byte array
byte[] encodecCert = cert.getEncoded();

// Encode the byte array using Base 64-encoding and convert it into a string
String base64EncodedCert = new String(Base64.encodeBase64 (encodedCert));

// Create hashtable to hold credentials
Hashtable creds = new Hashtable();

// Store the Base 64-encoded under the key "certificate"
cred.put("certificate", base64EncodedCert);

// Create ResourceResource request object including all information about the // // resource being accessed
ResourceRequest resourceRequest = new ResourceRequest(resourceType, resourceUrl, operation);

// Create a UserSession with the requestRequest and the cred hashtable
UserSession userSession = new UserSession(resourceRequest, creds);

// The above statement will throw an exception if the certificate cannot be mapped // to a valid user by the OAM Server.

この抜粋に関連するインポート文を次に示します。

import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.io.FileInputStream;
import oracle.security.am.common.nap.util.Base64;

2.7 アクセス・クライアント・プログラムの構築およびデプロイ

この項で説明する項目は、次のとおりです。

- 開発環境の設定

- 新規アクセス・クライアント・プログラムのコンパイル

- 新規アクセス・クライアント・プログラムの構成およびデプロイ

2.7.1 開発環境の設定

必要な環境は次のとおりです。

- JDK 1.6.0以上をインストールします。

- Oracle Access Manager 11g Access SDKをインストールします。

- JAVA_HOME環境変数がJDKインストール・ディレクトリを指すように定義します。たとえば、UNIX型オペレーティング・システムでは、次のコマンドを実行します。

setenv JAVA_HOME <JDK install dir>/bin

- PATH環境変数を、JAVA_HOME/binが指す場所に変更します。たとえば、UNIX型オペレーティング・システムでは、次のコマンドを実行します。

setenv PATH $JAVA_HOME/bin:$PATH

- CLASSPATH環境変数を、JDKおよびAccess SDK jarファイルを指すように変更します。たとえば、UNIX型オペレーティング・システムでは、次のコマンドを実行します。

setenv CLASSPATH $JAVA_HOME/lib/tools.jar:$ACCESSSDK_INSTALL_DIR/oamasdk-api.jar:$CLASSPATH

2.7.2 新規アクセス・クライアント・プログラムのコンパイル

開発環境の構成後(第2.7.1項「開発環境の設定」を参照)、次のようなコマンドを使用してアクセス・クライアント・プログラムをコンパイルできます。

Javac –cp <location of Access SDK jar> SampleProgram.java

必要に応じて、クラスパスおよびアクセス・クライアント・プログラム名などの詳細を変更します。

2.7.3 新規アクセス・クライアント・プログラムの構成およびデプロイ

詳細は、第2.5項「アクセス・クライアントの構成およびデプロイ」を参照してください。

2.8 互換性: 11gと10gのAccess SDKおよびAPI

この項で説明する項目は、次のとおりです。

- Access SDKの互換性

- 10g JNI ASDKおよび11g Access SDKの互換性

- 非推奨: Oracle Access Manager 10g JNI SDK

11g Access Manager APIにより、開発者はカスタム・アクセス・クライアント・コードをJavaで記述できますが、これは10g (10.1.4.3) Javaアクセス・クライアントと機能的に同等です。Oracle Access Manager 11gにより、JavaコードはAPIの基礎となるJavaバイナリと通信します。

組込みの自動Javaガベージ・コレクタにより、未使用のオブジェクトのメモリーはガベージ・コレクタが適切と見なした場合に割当て解除されます。ガベージ・コレクタでは、オブジェクトがいつクリーン・アップされるかは保証されませんが、オブジェクトが参照されなくなった場合にすべて破棄され、メモリー・リークが発生しないことが保証されます。

10gおよび11g Access Manager APIの機能は、7つの基本クラスで編成されています。表2-5に、Java言語プラットフォームの対応するクラス名をリストします。

表2-5 比較: 11gおよび10g Access APIクラス

クラスの用途

11g Javaクラス

10g Javaクラス

パラメータを格納するための構造体(リストまたはハッシュテーブル)をサポートする

Java Development Kitから:

java.util.Hashtable、java.util.Dictionaryを拡張

java.util.Set

java.util.Hashtable、java.util.Dictionaryを拡張(これはCom.Oblix.Accessクラスではありません)

リスト内の反復をサポートする(Javaはハッシュテーブルを列挙)

Java Development Kitから:

java.util.Hashtable、java.util.Dictionaryを拡張

java.util.Set

java.util.Hashtable、java.util.Dictionaryを拡張(これはCom.Oblix.Accessクラスではありません)

ユーザー認証を処理するための構造体を作成および操作する

oracle.security.am.asdkのAuthenticationSchemeクラス

ObAuthenticationSchemeはObAuthenticationSchemeInterfaceを実装する

リソースに対するユーザー・リクエストを処理するための構造体を作成および操作する

oracle.security.am.asdkのResourceRequestクラス

ObResourceRequestはObResourceRequestInterfaceを実装する

ユーザー・セッションを処理するための構造体を作成および操作し、ユーザー・セッションは、ユーザー認証とともに開始され、ユーザーがログオフするかセッションがタイムアウトになると終了する

oracle.security.am.asdkのUserSessionクラス

ObUserSessionはObUserSessionInterfaceを実装する

アクセス・クライアント構成情報を取得および変更する

oracle.security.am.asdkのAccessClientクラス

ObConfig

Access Manager APIによってスローされるエラーを処理する

oracle.security.am.asdkのAccessException、OperationNotPermittedException

ObAccessException

2.8.1 Access SDKの互換性

Access SDKは、10g JNI ASDKでサポートされている機能を実装しています。この機能は、これを使用してOracle Access Manager 10gサーバーおよびOracle Access Manager 11gサーバーの両方とシームレスに連携するカスタム・アクセス・ゲートを開発できるように実装されています。

また、Access SDKには、Oracle Access Manager 11gサーバーでのみ使用できる新機能および変更された機能が実装されています。したがって、Access SDKではアプリケーションがOracle Access Manager 10gサーバーでこの機能の使用を試みるかどうかを正常に検出できます。

Oracle Access Manager 11g Access SDK(oracle.security.am.asdk)の新機能は、次のとおりです。

- 指定されたユーザーのセッションの列挙

- 指定されたセッションの終了

- 指定されたユーザー・セッションでの属性の設定

- 指定されたセッションで設定された属性の取得

- セッションを確立せずにユーザー資格証明を検証

- セッションを確立せずにユーザー資格証明を検証し、同じリクエストで認可を実行

注意:
最後の2つの機能は、Oracle Access Manager 11g Access SDKのcom.oblix.accessパッケージでも提供されています。

さらに、Access SDKはサーバー側のセッションを削除するユーザー・ログアウト機能の変更済実装を提供します。この機能は、Oracle Access Manager 10gサーバーではサポートされていません。

2.8.2 10g JNI ASDKおよび11g Access SDKの互換性

次の図は、Oracle Access Manager 10g JNIバージョンおよびOracle Access Manager 11g Access SDKバージョンのcom.oblix.accessパッケージの1対1マッピングを示しています。

図2-4 com.oblix.accessパッケージのバージョン間のマッピング

「図2-4 com.oblix.accessパッケージのバージョン間のマッピング」の説明

10g JNI ASDKを使用して開発されたカスタム・アクセス・ゲートは、コードの変更なしで引き続き11g Access SDKで動作できます。

図2-4に示すように、次のクラスがOracle Access Manager 11g Access SDKのcom.oblix.accessパッケージに追加されています。

- ObPseudoUserSession: このクラスは、Oracle Access Manager 11gサーバーでのみ使用できる次の機能を提供します。

- セッションを確立せずにユーザー資格証明を検証します。

- セッションを確立せずにユーザー資格証明を検証し、同じリクエストで認可を実行します。

- ObAccessRuntimeException: このクラスは、ObAuthenticationSchemeクラスおよびObResourceRequestクラスを使用する操作の実行中にランタイム・エラーを示します。

2.8.3 非推奨: Oracle Access Manager 10g JNI SDK

Access SDKは、10g JNI ASDK com.oblix.accessパッケージのインタフェースをサポートします。ただし、com.oblix.accessのすべてのAPIが非推奨としてマークされています。これらのAPIは、将来のOracle Access Manager 11g Access SDKリリースにおいて拡張もサポートもされません。

2.9 旧アプリケーションの移行またはコードの変換

この項では、Access SDKを使用する場合に実行する移行プロセスを説明します。次の理由から、Access SDKへの移行が必要となる場合があります。

- アプリケーションを移行することで、これらのアプリケーションにおけるAccess SDKの使用方法を変更せずに、Oracle Access Manager 10g JNI ASDKのcom.oblix.access APIを、Oracle Access Manager 11g Access SDKの対応するAPIと置き換えます。

- アプリケーション・コードを移行することで、com.oblix.accessのかわりにoracle.security.am.asdk APIを使用するようにしますが、これは下位互換性のためにOracle Access Manager 11g Access SDKでサポートされています。

この項には次のトピックが含まれます:

- 開発およびランタイム環境の変更

- アプリケーションの移行

- コードの変換

2.9.1 開発およびランタイム環境の変更

アプリケーションを移行する前に、開発環境が構成されていることを確認します。また、Oracle Access Manager 11g Access SDKが正しく構成されていることを確認します。詳細は、第2.5項「アクセス・クライアントの構成およびデプロイ」を参照してください。

2.9.2 アプリケーションの移行

Oracle Access Manager 10gのcom.oblix.accessパッケージで開発されたアクセス・クライアントおよびプラグインは、OAM 11gサーバーで動作するよう移行できます。この項では、Oracle Access Manager 10g JNI ASDKで記述されたプログラムをOracle Access Manager 11gで使用する方法を説明します。

注意:
Oracle Access Manager 10g JNIおよびOracle Access Manager 11g Access SDKのそれぞれにおけるcom.oblix.access APIの類似点と相違点の詳細は、第2.8.2項「10g JNI ASDKおよび11g Access SDKの互換性」を参照してください。

Oracle Access Manager 10g JNI SDKおよびOracle Access Manager 11g Access SDKで提供されているクラスおよびインタフェースのサポートは同じです。

通常、Oracle Access Manager 11g Access SDKのcom.oblix.accessクラスを使用するためにアプリケーションを移行する場合、アプリケーション・コードを変更または再コンパイルする必要はありません。

新しいランタイム例外のObAccessRuntimeExceptionはcom.oblix.accessパッケージに導入されています。Oracle Access Managerは、AuthenticationSchemeクラスおよびResourceRequestクラスの操作の実行時にこの例外をスローします。

アプリケーション・コードで正しい例外処理を実行することをお薦めします。これを実行した場合、アプリケーションはOAM 11g Access SDK jarファイルで再コンパイルする必要があります。

2.9.2.1 移行に固有の構成

この説明では、Oracle Access Manager 10g ASDKコンポーネントがインストールされており、OAMサーバーで構成されていることを前提としています。このシナリオでは、Oracle Access Manager 10g JNI ASDKを使用して開発された既存のアクセス・クライアント・アプリケーションを使用します。前提は次のとおりです。

- 第2.5.1項「構成要件」にリストした構成アイテムは、Oracle Access Manager 10g ASDKのインストール・ディレクトリ(ASDK_INSTALL_DIR)から参照されます。

- ASDK_INSTALL_DIR/access/oblix/libからObAccessClient.xmlが読み取られます。

- トランスポート・セキュリティ・モードが簡易または証明書である場合、ASDK_INSTALL_DIR/access/oblix/configからpassword.xmlが読み取られます。

簡易モード

Oracle Access Manager 10g ASDKコンポーネントを簡易モードで構成するには、10gリリースのOracle Access Manager管理ガイドを参照してください。

次のステップを実行します。

1. aaa_cert.pemおよびaaa_key.pemファイルをoamclient-keystore.jksにインポートします。
aaa_cert.pemおよびaaa_key.pemファイルは、ASDK_INSTALL_DIR/access/oblix/config/simpleに置かれています。

2. 簡易モード証明書の発行に使用される自己署名CA証明書を、ASDK_INSTALL_DIR/access/oblix/tools/openssl/simpleCAに置きます。

3. 自己署名CA証明書をoamclient-truststore.jksにインポートします。

4. 第2.5.3項「SSL証明書およびキー・ファイル」の手順を実行し、証明書およびキー・ファイルをJKSストアにインポートします。

5. JKSストアをASDK_INSTALL_DIR/access/oblix/config/simpleにコピーします。

証明書モード

Oracle Access Manager 10g ASDKコンポーネントを証明書モードで構成するには、10gリリースのOracle Access Manager管理ガイドを参照してください。

次のステップを実行します。

1. aaa_cert.pemおよびaaa_key.pemファイルをoamclient-keystore.jksにインポートします。aaa_chain.pemをoamclient-truststore.jksにインポートします。
aaa_cert.pem、aaa_key.pemおよびaa_chain.pemファイルは、ASDK_INSTALL_DIR/access/oblix/configに置かれています。

2. 第2.5.3項「SSL証明書およびキー・ファイル」の手順を実行し、証明書およびキー・ファイルをJKSストアにインポートします。

3. JKSストアをASDK_INSTALL_DIR/access/oblix/config/simpleにコピーします。

構成ファイルの場所

com.oblix.access APIを使用するために移行されたアクセス・クライアント・アプリケーションは、Oracle Access Manager 10g JNI ASDK構成ファイルの場所を次のように指定できます。

- ASDKの初期化中に、Oracle Access Manager 10g ASDKがインストールされているディレクトリの場所を指定します。または、

- Oracle Access Manager 10g JNI ASDKがインストールされているディレクトリの場所を指す、環境変数OBACCESS_INSTALL_DIRを設定します。

これによって、Oracle Access Manager 11g Access SDKは、渡された場所に基づいて必要なファイルのパスを判別します。

環境

環境を設定するには、第2.7.1項「開発環境の設定」の手順を実行します。Oracle Access Manager 10g JNI ASDKは、jobaccess.jarという名前です。jobaccess.jarがCLASSPATHにある場合、削除する必要があります。

2.9.3 コードの変換

この項では、Oracle Access Manager 10g JNI ASDKで記述されたプログラムをOracle Access Manager 11gで使用する方法を説明します。

11g Access SDKでは、com.oblix.accessパッケージの10g JNI ASDK APIの機能をサポートしています。11g Access SDKでこれらの機能を実装すると、10g JNI ASDKとの下位互換性が保たれます。ただし、com.oblix.accessのAPIはすべて非推奨です。これらのAPIは、将来の11g Access SDKリリースにおいて拡張もサポートもされません。

oracle.security.am.asdkパッケージには、新規の認証および認可APIが含まれます。com.oblix.accessパッケージにより提供される機能の他に、oracle.security.am.asdkパッケージにも、OAM 11gサーバーの機能を利用する拡張機能が含まれます。

2.9.3.1 JNI ASDKおよびAccess SDKの相違点の理解

次の表では、Oracle Access Manager 10g JNI SDKのcom.oblix.accessパッケージのAPIと、Oracle Access Manager 11g Access SDKのoracle.security.am.asdkパッケージのAPIを比較しています。また、この表では必要に応じて、Oracle Access Manager 10g ASDKおよびOracle Access Manager 11g Access SDKのクラスをマップしています。

表2-6 JNI ASDK com.oblix.accessパッケージおよびAccess SDK oracle.security.am.asdkパッケージの相違点

JNI ASDK com.oblix.accessパッケージ

Access SDK oracle.security.am.asdkパッケージ

インタフェースの要約:

- ObAuthenticationSchemeInterface

- ObResourceRequestInterface

- ObUserSessionInterface

インタフェースの要約:

なし

クラスの要約:

- ObAuthenticationScheme

- ObConfig

- ObDiagnostic

- ObResourceRequest

- ObUserSession

クラスの要約:

- AuthenticationScheme

- AccessClient

- Supported through AccessClient

- ResourceRequest

- UserSession

- PseudoUserSession

- BaseUserSession

例外の要約:

ObAccessException

例外の要約:

- AccessException

- OperationNotPermittedException

列挙の要約:

なし

列挙の要約:

AccessClient.CompatibilityMode.OAM_10G

Oracle Access Manager 11g Access SDKには、Oracle Access Manager 10g JNI SDK APIに機能的に類似した新規のAPIセットが含まれますが、インタフェースが新しくなっているので注意してください。

2.9.3.2 コードの変換

Oracle Access Manager 10g JNI ASDKを使用して実装されたアプリケーション・コードを移行して、Oracle Access Manager 11g Access SDKの機能を実現できます。この項では、Oracle Access Manager 11g Access SDKで新規APIを使用するために、既存のアプリケーション・コードを変更する方法を説明します。

2.9.3.2.1 Access SDKの初期化および非初期化

Oracle Access Manager 10g JNI SDKでは、com.oblix.access.ObConfigクラスがASDKの初期化および非初期化を実行する機能を提供します。Oracle Access Manager 11g Access SDKでは、oracle.security.am.asdk.AccessClientがこの機能を提供します。

Oracle Access Manager 10g JNI SDKと同様に、アクセス・クライアント・アプリケーション・インスタンスは指定された構成で動作できます。

要件に応じて、AccessClientクラスを次の2通りに使用できます。

- createDefaultInstance静的関数を使用して、AccessClientクラスの単一インスタンスを作成できます。このクラスのデフォルト・インスタンスは1つのみ使用できます。アクセス・クライアント・アプリケーションの単一インスタンス内でこのメソッドを複数回起動すると、例外が発生します。
createDefaultInstanceメソッドを使用する場合、AuthenticationScheme、ResourceRequestまたはUserSessionクラスをインスタンス化する際に、このメソッドを使用して取得されたAccessClientクラス・インスタンスを使用する必要があります。

- createInstance静的関数を使用して、指定の構成で初期化された新規のAccessClientクラス・インスタンスを作成できます。このクラスは、アクセス・クライアント・アプリケーションの同じ実行中インスタンス内にある場合に必要であり、アプリケーションは様々なOracle Access Managerシステムまたは構成で動作する必要があります。各AccessClientクラス・インスタンスは、アクセス・クライアント・インスタンスの構成時に適切なログ出力名を渡すことで、メッセージを別のログ・ファイルに記録できます。
AccessClientオブジェクトを初期化する際には、AccessClient.CompatibilityMode.OAM_10Gを互換モードで渡す必要があります。

createInstanceメソッドを使用する場合、AuthenticationScheme、ResourceRequestまたはUserSessionクラスをインスタンス化する際に、このメソッドを使用して取得されたAccessClientクラス・インスタンスを使用する必要があります。

アプリケーションの停止時に、AccessClientクラスのshutdownメソッドを起動して、次の例に示すように非初期化を実行します。

- Oracle Access Manager 10g JNI ASDKの場合

Public static void main (String args[]) {
try {
ObConfig.Initialize (); // Configuration is read from the location pointed by OBACCESS_INSTALL_DIR
// environment variable

または

ObConfig.Initialize (configLocation); //Configuration is read from the location provided
………..
}catch (ObAccessException e){
}
ObConfig.shutdown();
}//main ends here

- Oracle Access Manager 11g Access SDKの場合

import java.io.*;
import java.util.*;
import oracle.security.am.asdk.*; //Import classes from OAM11g Access ASDK
…………..
Public static void main (String args[]) {
try {
ac = AccessClient.createDefaultInstance (“”, AccessClient.CompatibilityMode.OAM_10G); // Refer to Oracle Access Manager Access SDK Java API Reference

または

AccessClient.createInstance(“”,AccessClient.CompatibilityMode.OAM_10G); // Refer to Oracle Access Manager Access SDK Java API Reference
………..
}catch (AccessException e){
}
ac.shutdown();
}//main ends here

2.9.3.2.2 アクセス操作の実行

表2-6に示すように、アクセス操作の実行に使用されるクラス間には1対1マッピングがあります。oracle.security.am.asdkのクラスは、AuthenticationScheme、ResourceRequestおよびUserSessionです。

AccessClientクラスのインスタンス化の方法に応じて、これらのクラスの対応するコンストラクタを使用します。

Oracle Access Manager 10g JNI ASDKと同様に、初期化時またはアクセス操作の実行中に発生したエラーは例外として報告されます。AccessExceptionは、次の例に示すように、Oracle Access Manager 11g Access SDKで使用される例外クラスです。

- Oracle Access Manager 10g JNI ASDKの場合

Public static void main (String args[]) {
try {
ObConfig.Initialize (); // Configuration is read from the location pointed by OBACCESS_INSTALL_DIR
// environment variable
ObResourceRequest rrq = new ObResourceRequest(ms_protocol, ms_resource,ms_method);
if (rrq.isProtected()) {
System.out.println("Resource is protected.");
ObAuthenticationScheme authnScheme = new ObAuthenticationScheme(rrq);
if (authnScheme.isForm()) {
System.out.println("Form Authentication Scheme.");
Hashtable creds = new Hashtable();
creds.put("userid", ms_login);
creds.put("password", ms_passwd);
ObUserSession session = new ObUserSession(rrq, creds);
if (session.getStatus() == ObUserSession.LOGGEDIN) {
if (session.isAuthorized(rrq)) {
System.out.println("User is logged in and authorized for the
request at level " + session.getLevel());
} else {
System.out.println("User is logged in but NOT authorized");
}
} else {
System.out.println("User is NOT logged in");
}
} else {
System.out.println("non-Form Authentication Scheme.");
}
} else {
System.out.println("Resource is NOT protected.");
}
}catch (ObAccessException oe) {
System.out.println("Access Exception: " + oe.getMessage());
}
ObConfig.shutdown();
}//main ends here

- Oracle Access Manager 11g Access SDKの場合

import java.io.*;
import java.util.*;
import oracle.security.am.asdk.*; //Import classes from OAM11g Access ASDK

Public static void main (String args[]) {
AccessClient ac;
try {
ac = AccessClient.createDefaultInstance(“”,
AccessClient.CompatibilityMode.OAM_10G);

ResourceRequest rrq = new ResourceRequest(ms_protocol,ms_resource, ms_method);

if (rrq.isProtected()) {
System.out.println("Resource is protected.");
AuthenticationScheme authnScheme =new AuthenticationScheme(rrq);
if (authnScheme.isForm()) {
System.out.println("Form Authentication Scheme.");
Hashtable creds = new Hashtable();
creds.put("userid", ms_login);
creds.put("password", ms_passwd);
creds.put("ip", ms_ip);
creds.put("operation", ms_method);
creds.put("resource", ms_resource);
creds.put(“targethost”, ms_targethost);

UserSession session = new UserSession(rrq, creds);
if (session.getStatus() == UserSession.LOGGEDIN) {
if (session.isAuthorized(rrq)) {
System.out.println("User is logged in " +
"and authorized for the request " +"at level " + session.getLevel());
} else {
System.out.println("User is logged in but NOT authorized");
}
} else {
System.out.println("User is NOT logged in");
}
}
}catch (AccessException oe) {
System.out.println("Access Exception: " + oe.getMessage());
}
ac.shutdown();
} //main ends here

2.10 ベスト・プラクティス

この項では、様々な問題を回避する方法や、開発中に頻繁に発生する問題を解決するためのいくつかの方法について説明します。

2.10.1 問題の回避

作成したアクセス・クライアントでの問題発生を回避するための提案を次に示します。

- アクセス・クライアントが適切なOAMサーバーに接続しようとしているかを確認します。

- OAMサーバーについての構成情報とアクセス・クライアントについての構成情報が一致するようにします。Oracle Access Suiteを使用して、OAMサーバー上のアクセス・クライアントの構成情報を確認できます。詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』のアクセス・クライアントの登録に関する項を参照してください。

- OAMサーバーとの接続や切断をきれいに行うには、AccessClientクラスのinitializeメソッドおよびshutdownメソッドを使用します。

- 環境変数OBACCESS_INSTALL_DIRをWindowsまたはUNIXのようなホスト・コンピュータ上で設定し、アクセス・クライアントをコンパイルおよびリンクできるようにする必要があります。一般的に、この変数は、アクセス・クライアントを実行する場合にも必ず設定しておく必要があります。

- 開発中に問題を捕捉したり報告するには、カスタム・アクセス・クライアント・コードの作成に使用した言語の例外処理機能(try、throwおよびcatch)を使用します。

2.10.1.1 スレッド・セーフ・コード

アクセス・クライアントは、マルチスレッド・アプリケーション全体でただ1つのスレッドとなります。

そうした環境でも安全に操作できるよう、開発者は次のガイドラインを順守することをお薦めします。

- シングル・スレッド関数ではなく、スレッド・セーフ関数を使用します。たとえば、localtimeでなくlocaltime_rを使用します。

- マルチスレッド機能がサポートされるよう、適切なビルド環境とコンパイラ・フラグを指定します。たとえば、-D_REENTRANTを使用します。また、UNIX型プラットフォームでは-mt、Windowsプラットフォームでは/MDを使用します。

- FILEポインタなどのスレッド・セーフ方式の共有ローカル変数は注意して使用してください。

- アクセス・クライアントがAccess SDKのcom.oblix.access APIを使用して開発された場合、環境変数OBACCESS_INSTALL_DIRをWindowsまたはUNIXのようなホスト・コンピュータ上で設定し、アクセス・クライアントをコンパイルおよびリンクできるようにする必要があります。一般的に、この変数は、アクセス・クライアントを実行する場合にも必ず設定しておく必要があります。アクセス・クライアントがAccess SDKのoracle.security.am.asdk APIを使用して開発された場合、環境が正しく設定されていることを確認します。Oracle Access Manager Access SDK Java APIリファレンスのAccessClientクラスに関する項を参照してください。

2.10.2 問題の識別と解決

アクセス・クライアントが実行に失敗したかどうかの確認点を次に示します。

- OAMサーバーが実行中であることを確認します。Windowsシステムでこれを確認するには、「コンピュータの管理」、「サービス」、「AccessServer」の順にナビゲートします。AccessServerは、アクセス・クライアントを接続するOAMサーバーの名前です。

- アクセス・クライアントがユーザー・ログアウトを実行することを確認し、OAMサーバー側のセッションが必ず削除されるようにします。ユーザー・セッションが蓄積すると、ユーザー認証に失敗する可能性があります。

- コードが想定しているドメイン・ポリシーが正しく存在し、アクセス・システムで有効化されていることを確認します。

- 作業しているアクセス・システム製品に付属のリリース・ノートをお読みください。

- アクセス・システムの低位レベルのポリシーが、検査中のポリシーをオーバーライドして、アクセス・クライアントに応答しないようにします。

- Oracle Access Manager 11gアクセス・テスターを使用すると、特定のリソースにどのポリシーが適用されるかを確認できます。アクセス・テスターの使用およびアプリケーション・ドメインによるリソースの保護の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

3 カスタム認証プラグインの作成

OAMサーバーでは、保護対象とするリソースへのアクセスを制限するために、認証と認可の両方の制御が利用されます。認証は特定の認証スキームにより制御され、認証スキームは、ユーザーがリソースへのアクセス試行時に入力した資格証明をテストする、1つ以上のプラグインに依存します。プラグインは、OAMサーバーのインストールで提供される標準セット、または独自のJava開発者が作成したカスタム・プラグインから取得できます。

この章の内容は次のとおりです。

- 第3.1項「認証プラグインの概要」

- 第3.2項「プラグイン・インタフェースの概要」

- 第3.3項「サンプル・コード: カスタム・データベース・ユーザー認証プラグイン」

- 第3.4項「認証プラグインの開発」

- 第3.5項「カスタム・プラグインの追加」

- 第3.6項「カスタム・プラグインに対応したカスタム認証モジュールの作成」

- 第3.7項「カスタム認証モジュールを含む認証スキームの作成」

- 第3.8項「カスタム・プラグインのロギングの構成」

3.1 認証プラグインの概要

Oracle Access Manager 11gは、初期状態ですぐに使用できる認証モジュールの他に、次のものを提供します。

- カスタマイズされた認証モジュール(プラグイン)を構築してデフォルトの機能を個々の要件に合せるための、認証プラグイン・インタフェースおよびSDKツールを提供します。新規インタフェースおよびSDKツールは次のとおりです。

- Oracle Access Manager 10gのカスタム・プラグインをサポートするための下位互換性を提供します。

- カスタム・プラグインを編成するための決定論的メソッドを認証モジュール内に含めます。

- カスタマイズされた認証プラグインをOracle Access Manager 11gに素早くデプロイできるようにするメカニズムを提供します。

- 管理対象サーバーの状態ライフサイクルのプラグインすべてを保持し、これと同じものがAdminServerにも伝播されます。

資格証明コレクション用のカスタム・プラグインの作成が、認証のためにサポートされています(編成可能なステップ)。

参照:
プラグイン・インタフェースについて

図3-1では、カスタム・プラグインのデプロイ・タスクの概要を示しています。

図3-1 カスタム・プラグインのデプロイ・ワークフロー

「図3-1 カスタム・プラグインのデプロイ・ワークフロー」の説明

次の概要では、カスタム・プラグインのデプロイ・タスクを識別しています。

タスク概要: カスタム・プラグイン要件のデプロイ

1. 計画: 第3.1.2項「計画、認証モデルおよびプラグインについて」で説明しているように、このプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討します。
セキュリティ・アーキテクトは、Oracle Access Manager 11gの使用方法および顧客のユーザー・ベースを把握しています。システム・アーキテクトは、顧客の実装における改善点を識別できます。

2. 開発:
開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。

1. プラグインを記述します。

2. カスタム・モジュールのメタデータXMLを記述します。

3. マニフェストを作成します。

4. 次のjarファイルをクラスパスに追加します: felix.jar、identitystore.jar、oam-plugin.jar、utilities.jar。

3. デプロイ:
Oracle Access Manager管理者は、複数のプラグインが認証モジュールで連携するようにデプロイおよび編成し、プラグインをテストおよびモニターします。

1. カスタム・プラグインの追加には、プラグイン・データ・ソースまたはドメインの構成、プラグインの配賦およびアクティブ化が含まれます。

2. カスタム・プラグインに対応したカスタム認証モジュールの作成には、ステップおよび結果(OnSuccess、OnFailureおよびOnError)の追加および編成が含まれます。

3. カスタム認証モジュールを含む認証スキームの作成。

4. カスタム・プラグインのロギングの構成。

5. 『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』の説明にあるように、Oracle Access Managerアクセス・テスターを使用してプラグインをテストします。

6. プラグインをモニターし、セキュリティ・アーキテクトまたはシステム・アーキテクトにフィードバックを提供して、ビジネス要件およびアーキテクチャに対するリビジョンを可能にします。

3.1.1 カスタム・プラグインのライフ・サイクルについて

プラグインのライフ・サイクルは、OAMサーバーへのプラグインの追加およびプラグインを使用した機能の追加作成の機能を中心としています。これによりユーザーは、サーバーの拡張機能の役割を果たす標準(すぐに使用できる)プラグインおよびユーザーが追加したプラグインに基づいて、機能およびワークフローを作成できます。

次のリストは、標準的なプラグインのライフ・サイクルの概要を示しています。

- 計画

- プラグイン開発時間、プラグイン・メタデータ・アーティファクトの生成が含まれます

- プラグインのロードおよびライフサイクル

- インポート: プラグインをOracle Access Managerにアップロードし、サーバーを再起動せずにこれを使用

- 配布: サーバーの停止時間なしで、プラグインjarを1つのローカルAdminServerファイル・システムからクラスタ内のすべての管理サーバーに伝播

- アクティブ化: プラグインが認証モジュール・フローで使用される際に、このプラグイン実装を実行時にロード

- プラグインのスタートアップ・パラメータまたは構成を使用

- プラグイン構成データをoam-config.xmlにプッシュおよびプル

- 管理対象サーバーの状態ライフサイクルのすべてを保持し、これと同じものがAdminServerに伝播

- デプロイされたプラグインの状態

- プラグインのモニターおよび監査

- プラグイン実行の所要時間およびプラグインの実行回数に関するマトリクス・データを収集

- プラグイン入出力のマトリクス・データを収集

- プラグイン実行開始時間および終了時間のマトリクス・データを収集

- プラグインのライフサイクル・メソッド・コードの監査

新規プラグインJARが使用可能な場合、デプロイヤはこれをOracle Access Suiteのインポート・アクションからAdminServer DOMAIN_HOME/oam/pluginsにインポートできます。

表3-1では、Oracle Access Manager管理者が制御するプラグイン・ライフサイクルの状態を示しています。詳細は、第3.5項「カスタム・プラグインの追加」を参照してください。

表3-1 プラグイン・ライフサイクルの状態

状態

説明

インポート

プラグインJARファイルをAdminServer DOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。

配布

登録済のすべてのOAMサーバーにプラグインを伝播します。

アクティブ化

プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。

非アクティブ化

非アクティブ化では、oam-config.xmlのプラグイン・エントリ・フラグがチェックされます。

非アクティブ化プロセスでOAMサーバーに障害が発生した場合、非アクティブ化に失敗しましたというメッセージが伝播されます。

削除

AdminServerのDOMAIN_HOME/config/fmwconfig/oam/pluginsディレクトリから指定されたプラグイン(JAR)を削除し、AdminServerがすべてのOAMサーバーに通知します。

3.1.2 計画、認証モデルおよびプラグインについて

OAMサーバーのプラグインは、カスタム認証スキームの一部です。各種プラグインを次の目的に使用できます。

- ユーザー・アイデンティティ・マッピング
プラグインにより、ログイン・ユーザー名の形式ではなくユーザー入力の形式に対応するための機能を追加できます。フィンガープリント、一連のセキュリティ質問およびその他の方法を使用できます。プラグインによりこれらの入力が翻訳され、データベースと照らしあわせてチェックされます。

- ユーザー認証
ユーザーの認証時には、レスポンス(すぐに使用できる提供なし)が必要となる場合があります。カスタム・プラグインによりこのニーズに応えることができます。

- カスタム・レスポンス
レスポンスおよびこれらのレスポンスが残りのシステムと対話する方法について、カスタム・プラグインを使用できます。

- その他のタイプのプラグインもサポート

図3-2は、ユーザーが保護されたリソースをリクエストした場合の認証フローを示しています。認証はプロセスであり、プロトコルではありません。緑色の矢印は、OAMサーバーにデプロイされたプラグインによって生成されたカスタム・レスポンスです。

図3-2 認証モデルおよびプラグイン

「図3-2 認証モデルおよびプラグイン」の説明

カスタム認証プラグインを設計および開発する前に、開発者はOracle Access Manager認証決定プロセスを綿密に分析し、ユーザーをどのように認証する必要があるかを確認することをお薦めします。

あるリクエストを受け取った場合、これを処理するには2通りの方法が考えられます。1つは、リクエストの属性に応じて特定のスキームを実行する方法であり、デシジョン・エンジンを使用して1つ以上のスキームを実行し、ユーザーを正しく認証します。これは、各スキーム内のコードが少なくて済み、モジュール性が高くなります。もう1つのオプションは、特定の目的でリクエストの様々な属性を処理するためにすべてのスキームをハードコードする方法であり、デジション・エンジンを使用せずに、どのスキームを実行する必要があるかを全体から把握します(1つのスキームのみ実行されます)。

例: デジション・エンジン対ハードコード認証

ユーザーが夜中に自宅のコンピュータを使用して、オンラインバンクの口座にログインすると仮定します。次の概要では、デシジョン・エンジンおよびハードコードのそれぞれの方法における処理の相違点を説明しています。開発者は、どの方法が要件に最も合うかを判断する必要があります。

プロセスの概要: デシジョン・エンジンを使用する方法

2つの方法の相違点は単純ですが、重要です。

1. 夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。

2. デシジョン・エンジンにより、このIPアドレスが以前処理されたことが確認されます。また、夜中に認証を試みるユーザーは疑わしいと判断され、ユーザーはユーザー名およびパスワードだけでなく、セキュリティ質問に回答することが要求されます。

3. 指定されたユーザーに対してセキュリティ質問スキームが実行され、成功します。これは、デジション・エンジンによって選択された2つの認証スキームのうちの1つ目です。

4. ユーザーパスワード・スキームが実行され、ユーザーは正常に認証されます。これは、デジション・エンジンによって選択された2つ目の認証スキームです。

プロセスの概要: ハードコードを使用する方法

1. 夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。

2. オンラインバンク口座のアクセス・スキームが他の認証スキーム(クレジット・カード・アクセス・スキーム、新規口座作成および検証など)の中から選択されます。

3. このスキームでは最初にIPアドレスがチェックされ、ユーザーが以前このコンピュータから接続を試みたことがあるかどうかが確認されます。ユーザーが以前そうしたと確認されます。

4. スキームにより時間がチェックされます。セキュリティ質問の回答が要求され、正しく回答されます。

5. スキームによりユーザーはログイン資格証明の入力が要求され、正常に認証されます。

どちらの方法にも、それぞれメリットとデメリットがあります。デシジョンエンジン・モデルの場合、コードの再利用が主なメリットですが、ハードコードを使用した方法はセキュリティが向上する場合があります。開発者は、どの方法を選択するかを決定する必要があります。

表3-2 方法の比較

方法

説明

デシジョン・エンジン

認証スキームをより小さい連続モジュールに分割し、必要に応じて連携するよう編成できます。

メリット:

- コードの再利用が主なメリットです。

- Oracle Adaptive Access Managerを使用した方法のミラー化が2つ目のメリットです。

ハードコード

決定事項はありません。ユーザーが認証のために渡す必要があるIf-Else文一式に類似します。

メリット: セキュリティが向上する可能性があります。

3.2 プラグイン・インタフェースの概要

ここでは、次の内容について説明します。

- プラグイン・インタフェースについて

- プラグイン階層について

3.2.1 プラグイン・インタフェースについて

このトピックでは、パッケージ、クラス、インタフェースおよび注釈の階層について概要を説明します。

カスタム・プラグイン実装には、プラグイン実装クラス・アーティファクトの記述が含まれます。プラグイン実装クラスは、AbstractAuthenticationPlugInクラスを拡張し、initializeおよびprocessメソッドを実装する必要があります。カスタム・プラグイン実装者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。

プラグインの構成要件はXML形式で指定する必要があります。この構成データ(メタデータ)には、プラグイン名、作成者、作成日、バージョン、インタフェース・クラス、実装クラスおよび構成データが、属性/値ペアの形式で含まれます。

Oracle Access Manager 11gは、次に説明する汎用プラグイン・インタフェースおよびより詳細な認証インタフェースを提供します。

- 第3.2.1.1項「GenericPluginService」

- 第3.2.1.2項「AuthnPluginService」

3.2.1.1 GenericPluginService

oracle.security.am.plugin

パブリック・インタフェースoracle.security.am.pluginは、プラグイン名、プラグイン実装クラス名、プラグイン・バージョン、プラグイン実行ステータス、プラグイン・モニター・データ、プラグイン構成データを取得するメソッド、プラグインを起動および停止するメソッドを提供する汎用プラグイン・インタフェースです。

AbstractAMPlugin

パブリック抽象クラスoracle.security.am.plugin.AbstractAMPluginは、java.lang.Object implements GenericPluginServiceおよびorg.osgi.framework.BundleActivatorを拡張します。

oracle.security.am.plugin.AbstractAMPlugin

これは、すべてのAccess Managementプラグインによって拡張される必要がある抽象プラグイン・クラスです。これは、プラグインの起動および停止メソッドのための基本実装を提供します。

参照:
Oracle Fusion Middleware Oracle Access Manager Java APIリファレンス

3.2.1.2 AuthnPluginService

oracle.security.am.plugin.authn.AuthnPluginService

パブリック・インタフェースoracle.security.am.plugin.authn.AuthnPluginServiceは、GenericPluginServiceを拡張します。

これは認証プラグイン・インタフェースであり、AuthenticationContextオブジェクトで使用可能なすべてのデータにアクセスおよび処理し、プロセス実行ステータスを戻すための追加認証固有メソッドを提供します。プラグインはSESSIONに追加されるレスポンスを設定し、コンテキストをリクエストおよびリダイレクトできます。

AbstractAuthenticationPlugIn

パブリック抽象クラスoracle.security.am.plugin.authn.AbstractAuthenticationPlugInは、AbstractAMPluginを拡張し、AuthnPluginServiceを実装します。

oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn

これはプラグイン開発者に公開される認証抽象プラグイン・クラスです。カスタム・プラグイン実装はすべて、このAbstractPlugInServiceクラスを拡張する必要があります。リソース・クリーン・アップを処理する必要があるプラグインは、shutdown(Map < String, Object > OAMEnvironmentContext)メソッドをオーバーライドします。また、これはjava.util.Loggerのインスタンスをプラグインに提供します。

3.2.2 プラグイン階層について

このトピックでは、階層の一覧を提供します。

- 図3-3「プラグイン・パッケージ階層」

- 図3-4「プラグイン・クラス階層」

- 図3-5「プラグイン・インタフェース階層」

- 図3-6「プラグイン注釈タイプ階層」

- 図3-7「プラグイン列挙階層」

参照:
Oracle Fusion Middleware Oracle Access Manager Java APIリファレンス

図3-3 プラグイン・パッケージ階層

図3-4 プラグイン・クラス階層

図3-5 プラグイン・インタフェース階層

図3-6 プラグイン注釈タイプ階層

図3-7 プラグイン列挙階層

3.3 サンプル・コード: カスタム・データベース・ユーザー認証プラグイン

この項では、データベース・ユーザー認証プラグインのサンプル実装のスナップショットを提供し、開発者タスクを示しています。この項の内容は次のとおりです。

- サンプル・コード: データベース・ユーザー認証プラグイン

- プラグイン構成メタデータ要件のサンプル

- プラグインのサンプル・マニフェスト

- プラグインJARファイル構造

3.3.1 サンプル・コード: データベース・ユーザー認証プラグイン

次の各図では、データベース・ユーザー認証プラグインのサンプル実装を3つの部分に分けて示しています。

- 図3-8「データベース・ユーザー認証プラグイン・パート1」

- 図3-9「データベース・ユーザー認証プラグイン・パート2」

- 図3-10「データベース・ユーザー認証プラグイン・パート3」

参照:
Oracle Fusion Middleware Oracle Access Manager Java APIリファレンス

図3-8 データベース・ユーザー認証プラグイン・パート1

続く..

図3-9 データベース・ユーザー認証プラグイン・パート2

続く...

図3-10 データベース・ユーザー認証プラグイン・パート3

3.3.2 プラグイン構成メタデータ要件のサンプル

プラグインの構成要件はXML形式で指定する必要があります。

この構成データ(メタデータ)には、プラグイン名、プラグイン作成者、作成日、プラグイン・バージョン、プラグイン・インタフェース・クラス、プラグイン実装クラスおよびプラグイン構成データが、属性/値ペアの形式で含まれます。

図3-11では、サンプル: データベース・ユーザー認証プラグイン実装のメタデータが含まれるXMLスキーマ定義(XSD)ファイルを示しています。

図3-11 XSD構成データ: データベース・ユーザー認証プラグイン

図3-12では、サンプル: データベース・ユーザー認証プラグインのXMLメタデータを示しています。

図3-12 XMLメタデータ: データベース・ユーザー認証プラグイン

3.3.3 プラグインのサンプル・マニフェスト

図3-13では、データベース・ユーザー認証プラグイン・サンプルのMANIFEST.MFファイルを示しています。

図3-13 データベース・ユーザー認証プラグイン・サンプルのMANIFEST.MF

3.3.4 プラグインJARファイル構造

サンプル(データベース・ユーザー認証プラグイン)のJARファイル構造を次に示します。

- <plugin>.xml

- <plugin>.class (パッケージ構造、第3.2項「プラグイン・インタフェースの概要」を参照)

- META-INF (MANIFEST.MF)

3.4 認証プラグインの開発

開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。

この項では、Oracle Access Manager 11g認証スキームで使用する認証プラグインの開発について説明します。内容は次のとおりです。

- カスタム認証プラグインの記述について

- カスタム認証プラグインの記述

- カスタム認証プラグインのコンパイルに必要なJAR

3.4.1 カスタム認証プラグインの記述について

カスタム・プラグイン実装の記述には、次を行うためのプラグイン実装クラスの記述が含まれます。

- AbstractAuthenticationPlugInクラスの拡張(第3.2.1項「プラグイン・インタフェースについて」を参照)

- initializeメソッドの実装

- processメソッドの実装

表3-3では、プラグインの機能に必要なメソッドについて説明します。

表3-3 必要なプラグイン・メソッド

必要なメソッド

説明

initialize

PluginConfigオブジェクトにハンドルを提供します。

PluginConfigオブジェクトは、プラグインのアップロード時に入力されたプラグイン固有システム構成データを取得する際に実行できます。このデータはプラグイン独自の機能に必要です。

process

AuthenticationContextオブジェクトにハンドルを提供するもので、次のプラグイン固有ランタイム構成データを取得する際に実行できます。

- プラグイン・インスタンス・レベルで更新済

- またはプラグイン編成ステップで更新済

AuthenticationContextオブジェクトは、次を取得する各種メソッドを提供するPluginContextオブジェクトを拡張します。

- プラグイン構成データ

- 例外データ

- プラグイン環境データ

さらに、AuthenticationContextオブジェクトは次を取得するメソッドを提供します。

- 認証スキーム

- 認証サブジェクト

- 資格証明オブジェクト

- ランタイム・ポリシー・リソース

注意:
カスタム・プラグイン開発者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。

3.4.2 カスタム認証プラグインの記述

この項では、カスタム認証プラグインの記述ステップを示します。

次の概要では、システム・アーキテクトがこのプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討した後に開発者が実行する必要があるアクションについて説明します。詳細は、第3.1.2項「計画、認証モデルおよびプラグインについて」を参照してください。

前提条件

認証プラグインの概要

サンプル・コード: カスタム・データベース・ユーザー認証プラグイン

タスクの概要: 開発者によるカスタム認証プラグインの記述

1. AbstractAuthenticationPlugInクラスを拡張し、次のメソッドを実装します(第3.4.1項「カスタム認証プラグインの記述について」も参照)。

- initializeメソッドの実装

- processメソッドの実装

2. 適切なOracle Access Manager 11gインタフェースおよびパッケージを使用して、プラグイン・コードを開発します。参照:

- 第3.1項「認証プラグインの概要」

- 第3.3項「サンプル・コード: カスタム・データベース・ユーザー認証プラグイン」

3. カスタム・プラグインのメタデータを作成します。参照:

- 第3.3.2項「プラグイン構成メタデータ要件のサンプル」

4. プラグインJarファイルおよびマニフェストを作成し、これらをデプロイ・チームに引き継ぎます。参照:

- 第3.3.3項「プラグインのサンプル・マニフェスト」

- 第3.3.4項「プラグインJARファイル構造」

5. 次に進みます。

- 第3.4.3項「カスタム認証プラグインのコンパイルに必要なJAR」

- 第3.5項「カスタム・プラグインの追加」

3.4.3 カスタム認証プラグインのコンパイルに必要なJAR

カスタム認証プラグインのコンパイルには、複数のJARファイルが必要です。次のjarがあります。

- extensibility_lifecycle.jar

- . felix.jar

- .felix-service.jar

- oam-plugin.jar

これらのJARファイルは、次のパスに置かれています。

DOMAIN_HOME/servers/MANAGED_INSTANCE_NAME/tmp/_WL_user/oam_server/RANDOM_STRING
/APP-INF/lib

3.5 カスタム・プラグインの追加

ここでは、次の内容について説明します。

- カスタム・プラグインの管理について

- カスタム・プラグインの追加

- カスタム認証プラグインの削除

3.5.1 カスタム・プラグインの管理について

カスタム認証プラグインは、カスタム認証モジュールで作成および使用し、同様に認証スキームで使用できます。

プラグインの開発後、JARファイルとして管理サーバーにデプロイする必要があり、自動的に検証されます。検証後、管理者はOracle Access Suiteを使用してプラグインを構成および配布できます。

サーバーは、プラグインJARファイル内のXML構成ファイルを処理し、プラグインに関するデータを抽出します。プラグインがインポートされた後、管理者はAdminServerから使用できる情報に基づいて様々なプラグインの状態を参照し、変更できます。

図3-14は、「システム構成」タブの「共通構成」セクションにあるプラグイン・ノードおよびプラグイン・ページを示しています。このページに含まれるツールバーのコマンド・ボタンは、その多くが表で選択されたプラグインに作用します。この表は、既存のカスタム・プラグインとその状態に関する情報を提供します。ページ最下部の「プラグインの詳細」セクションは、表内の選択されたプラグインの構成詳細を反映しています。

図3-14 「共通構成」のプラグイン・ノードおよびプラグイン・ページ

表3-4に示すように、管理者はプラグイン・ページ上部の表の上にあるコマンド・ボタンを使用して、プラグインの状態を制御します。

表3-4 カスタム・プラグインの管理アクション

アクション

説明

プラグインのインポート

プラグインJARファイルをAdminServer DOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。

- 同一のJAR名: 新規プラグインJAR名(DOMAIN_HOME/oam/plugins内)が既存のプラグインJAR名(DOMAIN_HOME/config/fmwconfig/oam/plugins内)と一致する場合、Oracle Access ManagerはJAR(DOMAIN_HOME/oam/plugins内)のXMLファイルから新規構成メタデータを抽出し、新規プラグインのバージョンをチェックします。

- XMLバージョン: 新規プラグインXMLバージョン(DOMAIN_HOME/oam/plugins内)が既存のXMLバージョン(DOMAIN_HOME/config/fmwconfig/oam/plugins内)より新しい場合、検証は成功します。そうでない場合、無効なバージョンを持つ無効なプラグイン名が戻され、新規プラグインJARが削除されます(DOMAIN_HOME/oam/pluginsから)。

- 異なるJAR名: 新規プラグインJAR名(DOMAIN_HOME/oam/plugins内)が既存のプラグインJAR名(DOMAIN_HOME/config/fmwconfig/oam/plugins内)と異なる場合、新規プラグインJARがアップロードされ、検証は成功します。

成功時: ステータスが「アップロード済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アップロード済」と報告し、AdminServerにおけるステータスも「アップロード済」となります。

失敗時: ステータスは「アップロードに失敗しました」と報告されます。

関連項目: 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』の「カスタム・プラグインのライフ・サイクルについて」

選択項目の配布

- 登録済のすべてのOAMサーバーにプラグインを伝播します。

- oam-config.xmlのプラグイン・フラグをDistribute=trueに設定します。

- AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

- AdminServerノードからDOMAIN_HOME/config/fmwconfig/oam/pluginsの下の各OAMサーバー・ノードに、プラグインJARを配布します。

成功時: ステータスが「配布済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「配布済」と報告し、AdminServerにおけるステータスも「配布済」となります。

失敗時: ステータスは「配布に失敗しました」と報告されます。

選択項目のアクティブ化

プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。

アクティブ化:

- oam-config.xmlのプラグイン・フラグをActivate=trueに更新します。

- AdminServerとOAMサーバーの間で、メッセージ・リスナーおよび通知メカニズムを起動します。

- AdminServerは、登録済のすべてのOAMサーバーにメッセージ「アクティブ化」を送信します。

成功時: ステータスが「アクティブ化済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アクティブ化済」と報告し、AdminServerにおけるステータスも「アクティブ化済」となります。

失敗時: ステータスは「アクティブ化に失敗しました」と報告されます。

すべてのOAMサーバーについてアクティブ化した後、認証モジュールの作成または編成でプラグインを使用および実行できます。

選択項目の非アクティブ化

プラグインをアクティブ化した後で、管理者はプラグインが認証モジュールまたはスキームで使用されていない場合などに、プラグインの非アクティブ化を選択できます。登録済のすべてのOAMサーバーから選択されたプラグイン。

非アクティブ化:

- oam-config.xmlのプラグイン・フラグをDe-activate=trueに更新します。

- AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

- AdminServerおよび登録済の各OAMサーバー(DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。

- AdminServerは、登録済のすべてのOAMサーバーにメッセージ「非アクティブ化」を送信します。

- OAMサーバーは、AdminServerおよびOAMサーバーの両方のメッセージ・リスナーを使用して、AdminServerにステータス・メッセージを送信します。

成功時: ステータスが「非アクティブ化」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「非アクティブ化」と報告し、AdminServerにおけるステータスも「非アクティブ化」となります。oam-config.xmlからプラグイン構成が削除されます。

注意: 非アクティブ化の後は、認証モジュールまたは編成でプラグインを使用または実行できません。

失敗時: ステータスは「非アクティブ化に失敗しました」と報告されます。

選択項目の削除

プラグインを非アクティブ化した後、管理者は選択したプラグインを削除できます。このプロセスでは、Oracle Access Managerは次の処理を実行します。

削除:

- oam-config.xmlのプラグイン・フラグをRemove=trueに更新します。

- AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

- AdminServerおよび登録済の各OAMサーバー(DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。

- AdminServerは、登録済のすべてのOAMサーバーにメッセージ「アクティブ化」を送信します。

成功時: ステータスが「削除済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「削除済」と報告し、AdminServerにおけるステータスも「削除済」となります。oam-config.xmlからプラグイン構成が削除されます。

失敗時: ステータスは「削除に失敗しました」と報告されます。

表3-4では、プラグイン・ステータス表の要素について説明します。

表3-5 プラグイン・ステータス表の要素

要素

説明

プラグイン名

XMLメタデータ・ファイルのプラグイン名要素から抽出されます。

説明

XMLメタデータ・ファイルの説明要素から抽出されます。

アクティブ化のステータス

AdminServerの情報に基づいてアクティブ化のステータスが報告されます。

タイプ

XMLメタデータ・ファイルのタイプ要素から抽出されます。

最終更新日

XMLメタデータ・ファイルの作成日要素から抽出されます。

最終更新者

XMLメタデータ・ファイルの作成者要素から抽出されます。

このページの「プラグインの詳細」セクションでは、表3-6に示すように、「アクティブ化のステータス」がAdminServerによって維持されます。

図3-15 選択したプラグインのアクティブ化のステータス

プラグインによっては、様々な構成詳細がXMLメタデータ・ファイルの構成要素から抽出され、「プラグインの詳細」セクションの「構成パラメータ」に移入されます。表3-6に例を示します。

表3-6 XMLメタデータ・ファイルから抽出されたプラグイン詳細の例

構成要素

説明

データソース

Kerberos詳細

このプラグインを使用するには、Kerberos詳細を定義します。

ユーザー識別詳細

このプラグインを使用するには、ユーザー・アイデンティティ・ストアおよびフィルタの詳細を定義します。

ユーザー認証詳細

このプラグインを使用するには、ユーザー・アイデンティティ・ストアを定義します。

X.509詳細

このプラグインを使用するには、証明書詳細を定義します。

3.5.2 カスタム・プラグインの追加

有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。

前提条件

認証プラグインの開発

カスタム認証プラグインを追加する手順は、次のとおりです。

1. プラグインをインポートします。

1. Oracle Access Suiteにアクセスし、通常どおりログインします。次に例を示します。

https://hostname:port/oamconsole/

2. 「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。

3. 「プラグインのインポート」ボタンをクリックします。

4. 「プラグインのインポート」ダイアログ・ボックスで、「参照」をクリックしてプラグインJARファイルの名前を選択します。

5. ダイアログ・ボックスのメッセージを確認し、「インポート」をクリックします。
『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』で説明しているように、JARファイルが検証されます。

2. パラメータの構成: 「プラグインの詳細」セクションを開き、「構成パラメータ」をクリックして、必要に応じて適切な情報を入力します。次に例を示します。

3. プラグインをOAMサーバーに配布します。

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目の配布」ボタンをクリックし、「アクティブ化のステータス」をチェックします。

4. プラグイン(およびカスタム・プラグイン実装クラス)をアクティブ化し、OAMサーバーで使用できるようにします。

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目のアクティブ化」ボタンをクリックし、「アクティブ化のステータス」をチェックします。

5. 必要に応じて次のタスクを実行します。

- 第3.5.3項「プラグインのアクティブ化ステータスのチェック」

- 第3.5.4項「カスタム認証プラグインの削除」

- 第3.6項「カスタム・プラグインに対応したカスタム認証モジュールの作成」

3.5.3 プラグインのアクティブ化ステータスのチェック

有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。

前提条件

認証プラグインの開発

カスタム認証プラグインのアクティブ化ステータスをチェックする手順は、次のとおりです。

1. 「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。

2. プラグイン表で、目的のプラグイン名をクリックして選択します。

3. サーバー・インスタンス名: 「プラグインの詳細」セクションを開き、「アクティブ化のステータス」をクリックしてプラグインの場所とステータスを表示します。次に例を示します。

4. 必要に応じて次のタスクを実行します。

- 第3.5項「カスタム・プラグインの追加」

- 第3.5.4項「カスタム認証プラグインの削除」

- 第3.6項「カスタム・プラグインに対応したカスタム認証モジュールの作成」

3.5.4 カスタム認証プラグインの削除

有効な管理者資格証明を持つユーザーは、次の手順を使用してカスタム・プラグインを非アクティブ化してから削除できます。

管理者がカスタム認証プラグインを削除した場合、その名前はプラグインのリストから削除されません。プラグインを削除するには(同じプラグインを後で再インポートするため)、管理者はWebLogic Serverを停止し、oam-config.xmlを手動で編集する必要があります。

前提条件

カスタム・プラグインの追加

カスタム認証プラグインを削除する手順は、次のとおりです。

1. Oracle Access Suiteにアクセスし、通常どおりログインします。次に例を示します。

https://hostname:port/oamconsole/

2. 「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。

3. プラグインの非アクティブ化: プラグインを削除する前に、これを実行する必要があります。

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目の非アクティブ化」ボタンをクリックし、プラグインの「アクティブ化のステータス」をチェックします。

4. 非アクティブ化したプラグインの削除:

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目の削除」ボタンをクリックします。

3. WebLogic管理サーバーを停止し、oam-config.xmlの場所を確認し手動で編集して、非アクティブ化したプラグインを削除してから、WebLogic管理サーバーを再起動します。

5. 必要に応じて次のタスクを実行します。

- 第3.5項「カスタム・プラグインの追加」

- 第3.5.3項「プラグインのアクティブ化ステータスのチェック」

- 第3.6項「カスタム・プラグインに対応したカスタム認証モジュールの作成」

3.6 カスタム・プラグインに対応したカスタム認証モジュールの作成

ここでは、次の内容について説明します。

- カスタム認証モジュールの作成について

- カスタム認証モジュールの作成

3.6.1 カスタム認証モジュールの作成について

「システム構成」ナビゲーション・ツリーの「Access Managerの設定」セクションには、認証モジュール・ノードが含まれます。カスタム認証モジュールを作成する場合、モジュールに必要な情報のタイプごとにサブタブが表示されます。

- 一般

- ステップ

- ステップ編成

図3-16では、「システム構成」ナビゲーション・ツリーの「Access Managerの設定」セクションの認証モジュール・ノードと、モジュールの情報を入力する3つのサブタブを示しています。

図3-16 カスタム認証モジュール・ノードおよび「一般」サブタブ

「一般」サブタブには、モジュール名およびオプションの説明を入力するスペースがあります。名前は、最大60文字で指定できます。オプションの説明は、最大250文字で指定できます。

図3-17では、カスタム認証モジュールに関する「ステップ」サブタブおよび「詳細」セクションを示しています。「ステップの詳細」の下の「プラグイン・パラメータ」として、ステップごとに有効な値のみが受け入れられます。無効な値は、カスタム認証モジュールを保存する際にエラーとなります。ステップを追加する際には、表に表示するデータはありません。ただし、1つ以上のステップがあれば、表および「詳細」セクションは移入されます。

図3-17 カスタム認証モジュールの「ステップ」サブタブおよび「詳細」セクション

新規ステップを追加すると、次のダイアログ・ボックスが表示されます。表3-7に示すように、入力した情報はページの表および「詳細」セクションの移入に使用されます。

図3-18 ステップの追加

表3-7では、新規ステップの追加に必要な情報を説明しています。

表3-7 「新規ステップの追加」のエントリ、ステップ結果表および「詳細」セクション

要素

説明

ステップ名

このステップの追加時に入力された名前。

説明

このステップの追加時に入力された、このステップのオプションの説明。

プラグイン名

このステップの追加時に選択されたプラグイン名。

ステップの詳細

結果表の選択済ステップの詳細、プラグインの追加およびアクティブ化の際に設定されたプラグイン構成詳細。

関連項目: 表3-6「XMLメタデータ・ファイルから抽出されたプラグイン詳細の例」

図3-19では、カスタム認証モジュールの「ステップ編成」サブタブを示しており、ここでは定義済の各ステップ(および各操作条件について選択したアクション)の情報が移入されます。

図3-19 カスタム認証モジュールの「ステップ編成」サブタブ

表3-8では、「ステップ編成」サブタブの要素を説明します。OnSuccess、OnFailureおよびOnErrorで使用できるリストには、次の選択肢が含まれます。

- success

- failure

- StepName (モジュール内のステップは、操作条件に対するアクションとして選択できます)

表3-8 「ステップ編成」サブタブ

要素

説明

ステップ名

このステップの追加時に入力された名前。

説明

このステップの追加時に入力された、このステップのオプションの説明。

OnSuccess

このステップの操作の成功について選択されるアクション。

OnFailure

このステップの失敗について選択されるアクション。

OnError

このステップの実行時のエラーについて選択されるアクション。

3.6.2 カスタム認証モジュールの作成

有効な管理者資格証明を持つユーザーは、次の手順を使用して、Oracle Access Suiteにインポートされアクティブ化された1つ以上のカスタム認証プラグインを使用する認証モジュールを作成できます。

注意:
テンプレートとして使用する既存のカスタム・モジュールは複製できません。

前提条件

認証プラグインの開発

カスタム・プラグインの追加

カスタム・プラグインを使用するカスタム認証モジュールを作成する手順は、次のとおりです。

1. 「システム構成」タブの「Access Managerの設定」セクションから、認証モジュール・ノードを開きます。

2. ナビゲーション・ツリーから、「カスタム認証モジュール」をクリックします。

3. ツールバーの「作成」ボタンをクリックします。

4. 一般情報(「名前」およびオプションの「説明」)を追加します。

5. モジュールにステップを追加します。

1. 「ステップ」サブタブをクリックします。

2. ステップ表の上の「追加」ボタンをクリックします。

3. 「新規ステップの追加」ダイアログ・ボックスで、「ステップ名」およびオプションの「説明」を入力します。

4. 目的のカスタム・プラグイン名を参照して選択し、「OK」をクリックします。

5. 結果表の情報を確認します。

6. bからeまでを繰り返し、このモジュールの必要なすべてのプラグインがリストされるまで、他のステップを追加します。

6. 各ステップの構成: リクエストされたパラメータに適切な値を使用します。

1. 表の「StepName」をクリックし、必要な詳細を表示します。

2. リクエストされたパラメータの有効な値を入力します。

3. 「保存」ボタンをクリックします。

4. aからcまでを繰り返し、各ステップを適切に構成します。

7. ステップの使用方法を編成します。

1. 「ステップ編成」サブタブをクリックします。

2. InitialStepリストから、使用する最初のステップの名前を選択します。

3. 表の「StepName」を選択します。

4. OnSuccessリストから、条件(成功または失敗)またはステップ名を選択します。

5. OnFailureリストから、目的の条件またはStepNameを選択します。

6. OnErrorリストから、目的の条件またはStepNameを選択します。

7. cからeまでを繰り返し、このモジュール内の各プラグインの操作を編成します。

8. 編成を確認します。

8. 方針の検証の開始: 「適用」をクリックし、編成方針の検証を開始します。

- 正常な方針: 編成方針が適用され、モジュールが認証スキームに含められるようになります。ステップ9および10に進みます。

- 無効な方針: 「エラー」ボックスで「OK」をクリックしてから、OnSuccess、OnFailure、OnErrorの方針を編集(あるいはプラグインを追加または削除)し、問題を修正します。方針が正常になるまでこのステップを繰り返します。

9. ナビゲーション・ツリーで、新しいカスタム認証モジュールがリストされていることを確認し、ページを閉じて終了します。

10. カスタム認証モジュールを含む認証スキームを作成します。

3.7 カスタム認証モジュールを含む認証スキームの作成

有効な管理者資格証明を持つユーザーは、次の手順を使用して、カスタム認証モジュールを含む新規認証スキームを作成できます。

これは、標準認証モジュールを含む認証スキームを作成する際に使用する手順と基本的には同じです。唯一の相違点は、カスタム・プラグインを使用するために定義された編成済ステップを含む認証モジュールを選択できることです。

参照:
『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』の認証スキームに関する詳細

前提条件

カスタム・プラグインに対応したカスタム認証モジュールの作成

カスタム認証スキームを作成する手順は、次のとおりです。

1. 「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」ノードを拡張します。

2. 「認証スキーム」ノードをクリックし、ツールバーの「作成」ボタンをクリックします。

3. 新規の認証スキーム・ページに入力します。

1. 名前

2. 説明

3. 認証レベル

4. デフォルト

5. チャレンジ・メソッド

6. チャレンジ・リダイレクト

7. 認証モジュール(カスタム・プラグインがあるものを含む)

4. 「適用」をクリックして新しいスキームを送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じます。

6. オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。

7. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。

3.8 カスタム・プラグインのロギングの構成

Oracle Access Manager with Oracle Security Token Serviceは、WebLogic Serverコンテナのロギング・デフォルトを使用します。カスタム・プラグインの必要な属性とともに、Oracle Access Manager固有のカスタム・ログ出力およびログ・ハンドラを指定するには、ここで説明するようにWLSTコマンドを使用できます。

参照:
Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

カスタム・プラグインのログ出力およびハンドラを変更する手順は、次のとおりです。

1. OAMサーバーが稼動中であることを確認します。

2. Oracle Access Manager用のカスタムWLSTスクリプトを取得します。次に例を示します。

<ORACLE_HOME>/common/bin/wlst.sh

3. WebLogic Serverに接続してWebLogic管理者としてログインします。次に例を示します。

sh wlst.sh wls:/offline> connect ('adminID','password','adminURL')

4. カスタム・プラグインの使用可能なログ出力をリストします。次に例を示します。

wls:/base_domain/serverConfig> listLoggers(pattern="oracle.oam.*",target="oam_
server1")

ここで、pattern=はoam.controllerコンポーネントを表し、target=は希望のOAMサーバー(登録時に指定されたもの)を表します。

5. このOAMサーバーに関連付けられているOracle Access Managerログ出力のリストを表示します。次に例を示します。

Logger                                      | Level
--------------------------------------------+-----------------
oracle.oam                                  | <Inherited>
oracle.oam.commonutil                       | <Inherited>
oracle.oam.config                           | <Inherited>
oracle.oam.controller                       | <Inherited>
...

6. 自身の要求に基づいてoracle.oam.controllerログ・レベルを変更します。たとえば、TRACE:32(永続性なし)は次のようになります。

wls:/base_domain/serverConfig> domainRuntime()
wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.oam.controller",
level="TRACE:32", persist="0", target="oam_server1")

7. ステップ4を繰り返して再びロガーをリストし、ログ・レベルの変更を確認します。次に例を示します。

wls:/base_domain/serverConfig> listLoggers(pattern="oracle.oam.*",target="oam_
server1")

Logger                                      | Level
--------------------------------------------+-----------------
oracle.oam                                  | <Inherited>
oracle.oam.commonutil                       | <Inherited>
oracle.oam.config                           | <Inherited>
oracle.oam.controller                       | TRACE:32
...

8. 生成されたログ・ファイルを検証して、コントローラが指定レベルでロギングされていることを確認します。

DOMAIN_HOME/server/SERVER_INSTNCE_NAME/logs/

9. 次のように、Oracle Access Manager固有のカスタム・ログ出力およびログ・ハンドラを追加し、ログ・ファイル・パスおよび必要な属性を指定します。

1. 次のようにOAMログ出力を追加します。

wls:/base_domain/serverConfig> domainRuntime>
wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.oam",level="WAR
NING", persist="0", target="oam_server1")

2. 次に示すように、カスタム・ログ・ハンドラを追加して、それにOAMログ出力を関連付けます。

wls:/base_domain/domainRuntime> configureLogHandler(name="oam-log-handler",
target="oam_server1", rotationFrequency="daily", retentionPeriod="week",
path="${domain.home}/oamlogs", maxFileSize ="10485760", maxLogSize =
"104857600",addHandler="true", handlerType="oracle.core.ojdl.logging.ODLHan
dlerFactory", addToLogger="oracle.oam")

wls:/base_domain/domainRuntime>configureLogHandler(name="oam-log-handler",
addProperty="true", propertyName="supplementalAttributes",
propertyValue="OAM.USER, OAM.COMPONENT", target="oam_server1")

3. DOMAIN_HOME/oamlogsフォルダにすべてのOAMログが表示されていることを確認します。

10. 生成されたログ・ファイルを検証して、コントローラがTRACE:32レベルでロギングされていることを確認します。

DOMAIN_HOME/server/SERVER_INSTNCE_NAME/logs/

4 Oracle Security Token Serviceモジュール・クラスの記述

この章では、Oracle Access Manager 11gおよびOracle Security Token Serviceのカスタム・トークン・オプションについて説明します。内容は、次のとおりです。

- 第4.1項「Oracle Security Token Serviceカスタム・トークン・モジュール・クラスの概要」

- 第4.2項「TokenValidatorModuleクラスの記述」

- 第4.3項「TokenIssuanceModuleクラスの記述」

- 第4.4項「カスタム・クラスを使用可能にする」

- 第4.5項「Oracle Security Token Serviceカスタム構成の管理」

4.1 Oracle Security Token Serviceカスタム・トークン・モジュール・クラスの概要

Oracle Security Token Serviceにおいて、検証または発行するトークンがデフォルトでサポートされていない場合、独自の検証および発行モジュール・クラスを記述できます。カスタム・トークンには、2つ(検証または発行クラス)のいずれかが必要です。

- Oracle Security Token Serviceは、カスタム検証クラスを使用してカスタム・トークンを検証します。

- Oracle Security Token Serviceは、カスタム発行クラスを使用してカスタム・トークンを発行します。

注意:
カスタム・トークンには、2つ(検証または発行クラス)のいずれかが必要です。

次の概要では、実行する必要があるタスクを説明します。

タスク概要: カスタム・トークン・モジュール・クラスのデプロイ

1. TokenValidatorModuleクラスを記述し、必要に応じて、Oracle Security Token Serviceによりカスタム・トークンを検証します。

2. TokenIssuanceModuleクラスを記述し、必要に応じて、Oracle Security Token Serviceによりカスタム・トークンを発行します。

3. カスタム・クラスを使用可能にし、カスタム・トークンの検証テンプレートおよび発行テンプレートをユーザーが作成できるカスタム・トークン・モジュールを作成します。

4. Oracle Security Token Serviceのカスタム構成を管理し、カスタム・トークンの検証および発行テンプレートを作成し、そのカスタム・テンプレートを、標準トークンのテンプレートを使用するようにエンドポイントおよびパートナ・プロファイルで使用します。

4.2 TokenValidatorModuleクラスの記述

ここでは、次の内容について説明します。

- TokenValidatorModuleクラスの記述について

- TokenValidatorModuleクラスの記述

4.2.1 TokenValidatorModuleクラスの記述について

Oracle Security Token Service検証モジュール・クラスは、oracle.security.fed.sts.token.tpe.TokenValidatorModule interfaceを実装します。検証プロセスでは、次のプロパティをTokenContextからフェッチできます。

- XML_TOKEN: 検証が必要なトークンが含まれるXMLメッセージのバイト数。

- BST_VALUE_TYPE: カスタム・トークンがバイナリ・セキュリティ・トークンとして送信される場合、これにはバイナリ・セキュリティ・トークン値タイプが含まれます。

- BST_ENCODING: トークンがバイナリ・セキュリティ・トークンとして送信される場合、これにはエンコーディングが含まれます。

- BST_CONTENT: トークンがバイナリ・セキュリティ・トークンとして送信される場合、これにはバイナリ・セキュリティ・トークン・コンテンツが含まれます。

- TOKEN_ELEMENT: トークンがバイナリ・セキュリティ・トークンではなく、Oracle Security Token Service内部クラスにJAXB表現がない場合、これにはトークンを表すXML要素またはカスタムJAXBクラスが含まれます。

- XML_DOM: これは着信メッセージのDOM表現です。これは、DOMオブジェクトがこれまでOracle Security Token Service処理の一部として作成されていた場合のみ存在します。

トークンは、TokenContextのプロパティの情報を使用して検証される必要があり、TokenResultが戻される必要があります。TokenResultオブジェクトで次のプロパティを設定し、Oracle Security Token Serviceに情報を戻すことができます。

- TPE_RESULT_FAILURE_CODE: 失敗した場合の失敗コード。

- TPE_RESULT_FAILURE_STRING: 失敗を説明する文字列。

- 結果で設定された他のプロパティは、トークン・マッピングに使用される状況において使用可能です。通常、バリデータはSTS_SUBJECT_IDプロパティを名前IDに設定し、これを使用してユーザー・レコードにマップします。

EmailTokenValidatorModuleImplforBinary.javaの完全な実装の例が含まれる次の図を参照してください。

- 図4-1「第1部: EmailTokenValidatorModuleImplforBinary.java」

- 図4-2「第2部: EmailTokenValidatorModuleImplforBinary.java」

図4-1 第1部: EmailTokenValidatorModuleImplforBinary.java

図4-2 第2部: EmailTokenValidatorModuleImplforBinary.java

次の概要では、このモジュール・クラスの開発におけるハイライトを説明します。

開発におけるハイライト: TokenValidatorModuleクラスの記述

1. init(Map options)メソッドを実装します。これはTokenValidatorModuleが初期化された場合にコールされます。initメソッドは、検証テンプレートで定義されたパラメータが含まれるマップに渡されます。

2. validate(TokenContext context)メソッドを実装します。これは、特定の着信カスタム・トークンを検証する必要がある場合にコールされます。

1. TokenContextオブジェクトのプロパティからトークン情報をフェッチします。

2. トークンを検証し、TokenResultオブジェクトを戻します。
成功時には次を戻します。

TokenResultImpl result = new TokenResultImpl(0, TokenResult.SUCCESS, token);

失敗時には次を戻します。

TokenResultImpl result = new TokenResultImpl(0, TokenResult.FAILURE, token);
result.setTokenProperty("TPE_RESULT_FAILURE_CODE", failureCode);
result.setTokenProperty("TPE_RESULT_FAILURE_STRING", "validation failed");

3. 検証済トークン結果において、トークンのNameIdおよびトークンに基づいて解析された属性が次の形式で戻されることを確認します。

result.setTokenProperty(TPEConstants.NAMEID_VALUE, emailAddress);

//attributes
List attributeList = new ArrayList();
Return any other properties that should be available in the context for :
token mapping and issuance by setting the properties on the result
result.setTokenProperty(name, value);
Return any other properties that should be available in the context for
token mapping and issuance by setting the properties on the result as
follows: result.setTokenProperty(name, value);
emailAttribute.put(TPEConstants.SAML_ATTRIBUTE_NAMESPACE, null);
List attributeValues = new ArrayList();
attributeValues.add(emailAddress);
emailAttribute.put(TPEConstants.SAML_ATTRIBUTE_VALUES, attributeValues);
attributeList.add(emailAttribute);
result.setTokenProperty(TPEConstants.TOKEN_ATTRIBUTES, attributeList);

4.2.2 TokenValidatorModuleクラスの記述

次のタスクを実行し、カスタムTokenValidatorModuleクラスを記述します。

タスクの概要: TokenValidatorModuleクラスの記述

1. 次を参照して、独自のモジュール・クラスを開発します。

- 第4.2.1項「TokenValidatorModuleクラスの記述について」

- Oracle Security Token Service Java APIリファレンス

2. 必要に応じて次に進みます。

- 第4.3項「TokenIssuanceModuleクラスの記述」

- 第4.4項「カスタム・クラスを使用可能にする」

4.3 TokenIssuanceModuleクラスの記述

ここでは、次の内容について説明します。

- TokenIssuanceModuleクラスの記述について

- TokenIssuanceModuleクラスの記述

4.3.1 TokenIssuanceModuleクラスの記述について

EmailTokenIssuerModuleImpl.javaクラスは、oracle.security.fed.sts.token.tpe.TokenIssuerModuleインタフェースおよびTokenContextの属性を実装する必要があります。

詳細は、図4-3を参照してください。次の概要では、このモジュール・クラスの開発におけるハイライトを説明します。

図4-3 EmailTokenIssuerModuleImpl.java

開発におけるハイライト: TokenIssuanceModuleクラスの記述

1. public void init(Map options)throws TokenProcessingExceptionメソッドを実装します。
発行者モジュールが初期化されると、init()メソッドがコールされます。initメソッドには、発行テンプレートで定義されたパラメータが含まれるマップが渡されます。

2. public TokenResult issue(TokenContext context) throws TokenProcessingExceptionメソッドを実装します。
このメソッドは、カスタム送信トークンを作成する必要がある場合にコールされます。

1. issueメソッド内で、発行テンプレートの属性およびTokenContextに渡された属性を使用してトークンを作成します。TokenContextの属性には、次の方法でアクセスします。

List attributes = (List)context.getOtherProperties().get(TPEConstants.TOKEN_ATTRIBUTES);
String emailAddress = null;
HashMap attributes = (HashMap)context.getOtherProperties().get("STS_TOKEN_ATTRIBUTES");
Object valueObj = attributes.get("mail"); //valuesObj will be a list if mail has more than 1 value;
if(attributes != null)
attrIter = attributes.iterator();
if(attrIter != null){
HashMap attributes = (HashMap)context.getOtherProperties().get("STS_TOKEN_
ATTRIBUTES");
Object valueObj = attributes.get("mail"); //valuesObj will be a list if
mail has more than 1 value.
Map<String, Object> attribute = attrIter.next();
String attributeName = (String)attribute.get(TPEConstants.SAML_ATTRIBUTE_NAME);
if("mail".equals(attributeName)){
{Object valuesObj = attribute.get(TPEConstants.SAML_ATTRIBUTE_VALUES); if(valuesObj instanceof List) { Iterator iter = ((List)valuesObj).iterator(); while(iter.hasNext())
{Object valueObj = iter.next(); if(valueObj instanceof String)

}
}else if(valuesObj instanceof String)
Unknown macro: { emailAddress = (String)valuesObj; }
}

2. 結果オブジェクトを作成し、トークンのバイト数と、トークンのDocument Object Model (DOM)表現を設定します(DOM表現がこのクラスの処理中に作成された場合のみ)。

token.setTokenDocument(null);--> if you have a doc object that can be reuse.d set it here
token.setTokenBytes(tokenBytes);
TokenResult result = new TokenResultImpl(0, TokenResult.SUCCESS, token);

3. 次のように、キー識別子情報をトークン・プロパティに設定します。

Map resultMap = new HashMap();
resultMap.put("STS_KEY_IDENTIFIER_VALUE", emailAddress);
resultMap.put("STS_KEY_IDENTIFIER_VALUE_TYPE", "EmailAddress");
result.setTokenProperties(resultMap);

4.3.2 TokenIssuanceModuleクラスの記述

タスクの概要: 発行モジュール・クラスの記述

1. 第4.3.1項「TokenIssuanceModuleクラスの記述について」およびOracle Security Token Service Java APIリファレンスを参照し、発行モジュール・クラスを記述します。

2. 第4.4項「カスタム・クラスを使用可能にする」に進みます。

4.4 カスタム・クラスを使用可能にする

この項では、コンソールを使用してカスタム・クラスをOracle Access Manager 11gで使用できるようにする方法を説明します。

ここに記載した情報は、次のものがある場合に適用されます。

- WS-Securityユーザー名トークン

- WS-Trustカスタム・トークン

- 発行中のカスタム・トークン

注意:
コンソールを介して実行できる操作のWebLogic Scripting Toolコマンドが含まれるスクリプトも記述できます。手順は、Oracle Fusion Middleware WebLogicスクリプト・ツール・コマンド・リファレンスを参照してください。

ここでは、次の内容について説明します。

- クラスを使用可能にする処理について

- カスタム・トークンの検索範囲の絞込みについて

- カスタム・トークンの管理

4.4.1 クラスを使用可能にする処理について

カスタム・トークンの検証または発行クラス(あるいはその両方)を記述した後、Oracle Security Token Serviceにカスタム・トークン構成を追加して、これらのクラスを使用するケースと使用方法を指定する必要があります。

図4-4に示すように、新規カスタム・トークン・ページでは、「トークン・タイプ名」のみ必須です(アスタリスク*で識別)。すべての要素がすべてのカスタム・トークンに適用されるわけではありません。ただし、不完全な情報を送信した場合、不足内容を示すダイアログ・ボックスが表示されます。

図4-4 新規カスタム・トークン・ページ

新規カスタム・トークン詳細を正常に送信した後、保存されたページは図4-5に示すように編集できます。

図4-5 カスタム・トークン定義: 電子メール

カスタム・トークンについては、XML要素名、XML要素のネームスペース、バイナリ・セキュリティ・トークン・タイプなどを決定する必要があります。表4-1では、この章の例に基づくカスタム・トークン・ページの要素について説明します。

表4-1 新規カスタム・トークン要素

要素

説明

トークン・タイプ名

このカスタム・トークンについて選択する一意の名前。次に例を示します。

email_token

注意: 新規カスタム・トークン構成を保存した後は、この名前は編集できません。

デフォルト・トークンURI

このカスタム・トークンのURI。このURIをRSTで使用し、このタイプのカスタム・トークンを発行する必要があることをリクエストできます。この章の例の場合、値は次のようになります。

oracle.security.fed.sts.customtoken.email

XML要素名

ユーザーが決定する名前であり、トークン・タイプ名に関連付けられます。次に例を示します。

email

XML要素名としてemailを指定した場合、要素名emailが着信トークンに表示されるたび、トークン・タイプ名に関連付けられます(この場合はemail_token)。

注意: 少なくともXML要素名またはバイナリ・セキュリティ・トークン・タイプのいずれかが必要です。

検証クラス名

Oracle Security Token Serviceで使用できるようにしたカスタム・トークン検証クラスの名前。次に例を示します。

oracle.security.fed.sts.tpe.providers.email.EmailTokenValidatorModuleImpl

注意: カスタム・トークンを発行するか検証するかに応じて、少なくとも発行クラス名または検証クラス名のいずれかが必要です。

XML要素のネームスペース

カスタム・トークン要素名のネームスペース。次に例を示します。

http://email.example.com

発行クラス名

Oracle Security Token Serviceで使用できるようにしたカスタム・トークン発行クラスの名前。次に例を示します。

oracle.security.fed.sts.tpe.providers.email.EmailTokenIssuerModuleImpl

注意: カスタム・トークンを発行するか検証するかに応じて、少なくとも発行クラス名または検証クラス名のいずれかが必要です。

バイナリ・セキュリティ・トークン・タイプ

BinarySecurityTokenとして送信されたカスタム・トークンをクラスで検証できるようにします。

このカスタム・トークンのBinarySecurityTokenのValueType。Oracle Security Token Serviceがこの値タイプのバイナリ・セキュリティ・トークンを受け取った場合、検証のためにこのカスタム・トークンの検証クラスに転送されます。

検証属性

この項では、検証属性を追加(または削除)できます。既存の検証属性が表に表示されます(ある場合)。この例では、次のようになります。

- 属性名: testsetting

- 属性タイプ: String

注意: トークン検証テンプレートの作成時に、属性に値を追加します。

発行属性

この項では、発行属性を追加(または削除)できます。既存の発行属性に関する次の情報が表に表示されます。

- 属性名: testsetting

- 属性タイプ: String

注意: トークン発行テンプレートの作成時に、属性に値を追加します。

保存

構成情報を保存するには、新規カスタム・トークン・ページでこのボタンをクリックします。

取消

構成詳細を閉じるには、このボタンをクリックします。

適用

変更内容を送信するには、このボタンをクリックします。

元に戻す

変更内容を取り消すには、このボタンをクリックします。

タスク概要: カスタム・クラスのカスタム・トークンの追加

1. カスタムTokenIssuerModuleまたはTokenValidatorModuleクラス(あるいはその両方)のみが含まれるJARファイルを作成します。XMLメタデータもマニフェストも必要ありません。

2. 図4-5および表4-1の情報を確認します。

3. 第4.4.3項「カスタム・トークンの管理」で説明するように、Oracle Security Token ServiceをホストするOAMサーバーにJARを追加し、新規カスタム・トークンを作成します。

4.4.2 カスタム・トークンの検索範囲の絞込みについて

図4-6では、カスタム・トークン検索コントロールおよび結果表を示しています。これらは、ナビゲーション・ツリーでカスタム・トークン・ノードをダブルクリックすると表示されます。デフォルトでは、「検索結果」表が表示されると、現在定義されているすべてのカスタム・トークンがリストされます。

図4-6 カスタム・トークン検索ページおよびコントロール

表4-2では、カスタム・トークン検索要素およびコントロールについて説明します。カスタム・トークン検索では、ワイルド・カード(*)は使用できません。

表4-2 カスタム・トークン検索要素およびコントロール

要素

説明

デフォルト・トークンURI

カスタム・トークンに対して定義されたURI。URI全体またはその一部のみを入力できます。たとえば、「ai」と入力した場合、「検索結果」表には、文字「ai」が含まれるトークンURIで定義されたすべてのカスタム・トークンが表示されます。

注意: カスタム・トークン検索では、ワイルド・カードは使用できません。

検索

フォームで指定された基準を使用して検索機能が開始されます。

リセット

デフォルトのみが含まれる「検索」フォームがリセットされます。

検索結果

「表示」メニューの選択内容に基づいて、検索結果が表示されます。

「アクション」メニュー

結果表の選択内容について実行できる次の機能を提供します。

注意: 「アクション」メニューの機能は、結果表の上のコマンド・ボタンを反映しています。次に例を示します。

- 新規カスタム・トークン: 検索ページ上部の「新規カスタム・トークン」ボタンをクリックするか、メニューから「新規カスタム・トークン」を選択するか、または表の上の「+」ボタンをクリックします。

- 編集: 「検索結果」表の「トークン・タイプ名」列で名前をダブルクリックするか、「アクション」メニューから「編集」を選択するか、結果表の上の編集(鉛筆アイコン)コマンド・ボタンをクリックします。

- 類似作成: 表内の目的の行を選択して、「アクション」メニューから「類似作成」を選択するか、表の上の類似作成コマンド・ボタンをクリックします。

- 削除: 表内の目的の行を選択して、「アクション」メニューから「削除」を選択するか、表の上の削除「X」コマンド・ボタンをクリックします。

「表示」メニュー

結果表に各種情報を表示するために使用できる機能を提供します。

結果表にリストされるアイテムの順序に影響するコントロール:

- 昇順

- 降順

4.4.3 カスタム・トークンの管理

有効な管理者資格証明を持つユーザーは、この項の手順を使用して、カスタム・トークン・モジュール・クラスのカスタム・トークンを管理できます。

次の手順には、カスタム・トークンまたはカスタム・トークンの属性を追加、編集および削除するステップが含まれます。不要なステップはスキップします。

前提条件

TokenValidatorModuleクラスの記述

TokenIssuanceModuleクラスの記述

参照:

- 第4.4.1項「クラスを使用可能にする処理について」

- 第4.4.2項「カスタム・トークンの検索範囲の絞込みについて」

カスタム・クラスを使用できるようにする手順は、次のとおりです。

1. 次のいずれかの方法を使用して、発行および検証クラスが含まれるJARを作成し、Oracle Security Token ServiceをホストするOAMサーバーに追加します。

- 起動スクリプトを編集することで、カスタム・トークンjarおよびDOMAIN_HOME/config/fmwconfig/mbeans/oamにあるsts-common.jarを、管理対象サーバーのクラスパスに追加します。

- カスタム・トークンjarおよびDOMAIN_HOME/config/fmwconfig/mbeans/oamにあるsts-common.jarを、DOMAIN_HOME/libディレクトリに追加し、管理対象サーバーのクラスパスにこれらのjarを自動的に追加します。

- OAMサーバーを再起動します。

2. 新規カスタム・トークン: Oracle Access Suiteの「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開き、次のようにします。

1. カスタム・トークン・ノードをダブルクリックしてページを開きます。

2. 「新規カスタム・トークン」ボタンをクリックします。

3. 新規カスタム・トークン・ページにカスタム・クラスの詳細を入力します(表4-1)。

4. 「保存」をクリックし、確認ウィンドウを閉じます(または「取消」をクリックし、送信せずにページを閉じます)。

5. ページを閉じます(またはステップ4のとおりに編集します)。

6. 必要に応じてステップ4に進むか、第4.5項「Oracle Security Token Serviceカスタム構成の管理」に進みます。

3. カスタム・トークンの検索: 「システム構成」タブの「セキュリティ・トークン・サービス」セクション:

1. すべて検索: カスタム・トークン・ノードをダブルクリックし、カスタム・トークンがすべてリストされた結果表を表示します。

2. 検索の絞込み: 目的のデフォルト・トークンURIに一部またはすべての文字を入力し、「検索」ボタンをクリックして、結果表を確認します。

3. 検索フォームのリセット: 「リセット」ボタンをクリックします。

4. カスタム・トークン構成の編集: 作成した保存済ページから開始します。
代替手段: ステップ3を使用して目的のカスタム・トークンを検索してから、「検索結果」表で名前をダブルクリックし、ページを開きます。

1. 指定されたカスタム・トークン・ページで、該当するフィールドをクリックし、必要に応じて編集します。

2. 属性の追加: 「属性」表の追加「+」アイコンをクリックし、属性名および属性タイプを入力します(表4-1)。

3. 属性の削除: 「属性」表から、削除する属性が含まれる行をクリックし、表の削除「X」アイコンをクリックし、「確認」ウィンドウを閉じます。

4. 変更内容の適用: ページ上部の「適用」ボタンをクリックし、変更内容を送信します。

5. カスタム・トークンの削除:

1. 「検索結果」表で目的の名前をクリックし、削除するアイテムを選択します。

2. 「アクション」メニューから「削除」をクリックします(または表の上の削除「X」コマンド・ボタンをクリックします)。

3. 「確認」ウィンドウで「削除」ボタンをクリックします(または「いいえ」をクリックして操作を取り消します)。

4.5 Oracle Security Token Serviceカスタム構成の管理

このタスクは、次の手順で構成されます。

- 検証テンプレートの作成

- カスタム・トークンの発行テンプレートの作成

- カスタム・トークンをリクエスタ・プロファイルに追加

- カスタム・トークンをリライイング・パーティ・プロファイルに追加

- トークンをリクエスタにマップ

- /wssuserエンドポイントの作成

4.5.1 検証テンプレートの作成

有効なOracle Access Manager管理者資格証明を持つユーザーは、次のタスクを実行して、Webservice Trustのトークン・プロトコルを含む検証テンプレートを作成し、トークンをリクエスタにマップできます。

この例のテンプレートは、この章で前述したモジュール・クラスに使用できます。次の各図では、実装の完全な詳細を示しています。これらを確認する際に、このテンプレートの仕様がモジュール・クラス・コードを参照する仕組みに注意してください。

- 図4-7「一般的な詳細: email-wstrust-valid-temp」

- 図4-8「トークン・マッピング: email-wstrust-valid-temp」

図4-7 一般的な詳細: email-wstrust-valid-temp

図4-8 トークン・マッピング: email-wstrust-valid-temp

参照:
Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

カスタム・モジュール・クラスの検証テンプレートを作成する手順は、次のとおりです。

1. 既存のトークン検証テンプレートのリストを表示します。
Oracle Access Suite
システム構成
セキュリティ・トークン・サービス
トークン検証テンプレート

2. 右上角の「新規検証テンプレート」ボタンをクリックします(または「検索結果」表の上にある追加「+」コマンド・ボタンをクリックします)。

3. 一般: カスタム・トークンで使用する次のものを設定します。
検証テンプレート名: email-wstrust-valid-temp

トークン・プロトコル: Webservice Trust

トークン・タイプ: email

デフォルト・パートナ・プロファイル: requester-profile

カスタム検証属性: testsetting: hello

4. トークン・マッピング: この章でカスタム・トークンに使用する次のものを設定します。
「トークンの宛先ユーザーのマップ」の隣のボックスを選択します(有効化)。

「簡易ユーザー・マッピングの有効化」の隣のボックスを選択し、次を入力します。

ユーザー・トークン属性: STS_SUBJECT_ID
データストア属性: mail

5. 「保存」をクリックし、「確認」ウィンドウを閉じます。

6. 「カスタム・トークンの発行テンプレートの作成」に進みます。

4.5.2 カスタム・トークンの発行テンプレートの作成

これはサーバー側の構成です。有効なOracle Access Manager管理者の資格証明を持つユーザーは、次のタスクを実行してトークン発行テンプレートを作成できます。

各トークン発行テンプレートは、トークンの構成方法およびトークン構成時に使用する署名または暗号化を示します。また、各トークン発行テンプレートは、データのマッピングおよびフィルタ処理のためにアウトバウンド・トークンの一部として送信される属性を定義します。ただし、発行テンプレートには、リライイング・パーティ・パートナ・プロファイルで定義されたマッピングまたはフィルタ処理ルールはリストされません。

この例のテンプレートは、この章で前述した電子メール・カスタム・トークンに使用できます。実装の詳細を次の各図に示しており、付け加えられた手順で説明しています。これらを確認する際に、このテンプレートの仕様がモジュール・クラス・コードを参照する仕組みに注意してください。

- 図4-9「一般的な詳細: email-issuance-temp」

- 図4-10「発行プロパティ: email-issuance-temp」

図4-9 一般的な詳細: email-issuance-temp

カスタム・トークン・タイプをデプロイした場合、発行プロパティはカスタム・トークンにあわせて調整されます。たとえば、図4-10に示した発行テンプレートでは、カスタム電子メール・トークン・タイプが選択されています。

図4-10 発行プロパティ: email-issuance-temp

この手順では、この章のカスタム・モジュール・クラスのコンパニオン発行テンプレートを生成します。この例の場合、次のようになります。

- カスタム・トークンタイプ: 電子メールでは使用されないトークン暗号化アルゴリズムは無視します。

- カスタム・トークン・コードから移入されるカスタム・トークン属性の値を入力します。

参照:
Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

カスタム・モジュール・クラスの発行テンプレートを作成する手順は、次のとおりです。

1. 既存のトークン発行テンプレートのリストに進みます。
Oracle Access Suite
システム構成
セキュリティ・トークン・サービス
トークン発行テンプレート

2. 新規トークン発行テンプレート:

1. 右上角の「新規発行テンプレート」ボタンをクリックします(または「検索結果」表の上にある追加「+」コマンド・ボタンをクリックします)。

2. 一般: この章でカスタム・トークンに使用する次のものを設定します。
発行テンプレート名: email-issuance-temp
トークン・タイプ: email

3. 「保存」をクリックし、確認ウィンドウを閉じます(または保存せずに「取消」をクリックします)。

4. 発行プロパティ: この章でカスタム・トークンに使用する次のものを設定します。
カスタム・トークン属性値: world

5. 「適用」をクリックし、確認ウィンドウを閉じます(または保存せずに「元に戻す」をクリックします)。

6. 定義を閉じます(またはステップ4のとおりに編集します)。

3. テンプレートの編集: 作成した保存済ページから開始します。
代替手段: ステップ3を使用して目的のテンプレートを検索し、「検索結果」表で名前をクリックし、定義を表示します。

1. 必要に応じて詳細を編集します。

2. ページ上部の「適用」ボタンをクリックし、変更内容を送信します(または「元に戻す」をクリックして変更内容を元に戻します)。

4.5.3 カスタム・トークンをリクエスタ・プロファイルに追加

既存のリクエスタ・プロファイルを編集してカスタム・トークンを「トークン・タイプ構成」表に追加するか、新規リクエスタ・プロファイルを作成してカスタム・トークンで使用できます。どちらの方法も、次を構成します。

- トークン・タイプ: email (カスタム・トークン)

- 検証テンプレート: email-wstrust-valid-temp

前提条件

カスタム・トークンおよび検証テンプレートを定義する必要があります。

カスタム・トークンのリクエスタ・プロファイルを作成または編集する手順は、次のとおりです。

1. Oracle Access Suiteの「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. ナビゲーション・ツリーで、パートナ・プロファイル・ノードを開き、リクエスタ・プロファイル・ノードをダブルクリックして既存のプロファイルのリストを表示します。

3. 既存のプロファイル:

1. リクエスタ・プロファイル・ページの「検索結果」表で、目的のプロファイルの名前をクリックします。

2. トークンと属性: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「保存」ボタンをクリックします。
トークン・タイプ: email
検証テンプレート: email-wstrust-valid-temp

3. 「保存」をクリックし、確認ウィンドウを閉じてページを閉じます(または「取消」をクリックし、送信せずにページを閉じます)。

4. 第4.5.4項「カスタム・トークンをリライイング・パーティ・プロファイルに追加」に進みます。

4. 新規プロファイル: 「新規リクエスタ・プロファイル」ボタンをクリックし、詳細を入力する新規パートナ・プロファイル・ページを表示します。

1. 一般: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「次」ボタンをクリックします。
プロファイルID: unique_requesterprofile_name
デフォルト・リライイング・パーティ・プロファイル: unique_relyingparty_name

2. トークン・タイプ構成の追加: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「保存」ボタンをクリックします。
トークン・タイプ: email
検証テンプレート: email-wstrust-valid-temp

3. 第4.5.4項「カスタム・トークンをリライイング・パーティ・プロファイルに追加」に進みます。

4.5.4 カスタム・トークンをリライイング・パーティ・プロファイルに追加

既存のリライイング・パーティ・プロファイルを編集するか、デフォルトでカスタム・トークンを発行するプロファイルを新規作成し、発行テンプレートおよび関連情報を参照できます。どちらの方法も、次を構成します。

- 発行するデフォルト・トークン: email (カスタム・トークン)

- 発行テンプレート: email-issuance-temp

前提条件

カスタム・トークンおよび発行テンプレートを定義する必要があります。

カスタム・モジュール・クラスのリクエスタ・プロファイルを編集する手順は、次のとおりです。

1. Oracle Access Suiteの「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. ナビゲーション・ツリーで、パートナ・プロファイル・ノードを開き、リライイング・パーティ・プロファイル・ノードをダブルクリックして既存のプロファイルのリストを表示します。

3. 既存のプロファイル:

1. リライイング・パーティ・プロファイル・ページの「検索結果」表で、目的のプロファイルの名前をクリックします。

2. 「トークンと属性」タブをクリックします。

3. トークン・タイプ構成: 「トークン・タイプ構成」表の上の追加「+」ボタンをクリックし、次の詳細を入力します。
トークン・タイプ: email
発行テンプレート: email-issuance-temp

4. 属性: 「属性」表の上の追加「+」ボタンをクリックし、次の内容を定義します。
属性名: mail
ストア・タイプ: Userstore
トークンに含める: (check to enable)
暗号化(空のまま)
値(空のまま)

5. 「適用」をクリックし、確認ウィンドウを閉じてページを閉じます(または「取消」をクリックし、送信せずにページを閉じます)。

4. 新規プロファイル: 「新規リライング・パーティ・プロファイル」ボタンをクリックし、詳細を入力する新規パートナ・プロファイル・ページを表示します。

1. 一般: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「次」ボタンをクリックします。
プロファイルID: unique_relyingparty-name
デフォルト・トークン: email

2. 「トークンと属性」タブをクリックし、ステップ2cおよび2dを実行してから「適用」をクリックします。

4.5.5 トークンをリクエスタにマップ

ユーザー名検証テンプレート(username-wss-valid-template)がない場合、Oracle Access Suiteを使用して、トークンをリスナーにマップするテンプレートを作成します。

検証テンプレート名: username-wss-valid-template

トークン・タイプ: Username

第4.5.6項「/wssuserエンドポイントの作成」に進みます。

4.5.6 /wssuserエンドポイントの作成

前提条件

「トークンをリクエスタにマップ」

エンドポイントを作成する手順は、次のとおりです。

1. Oracle Access Suiteの「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. エンドポイント・ノードをダブルクリックし、既存のエンドポイントのリストを表示します。

3. 新規エンドポイント:

1. 表の上の追加「+」ボタンをクリックします(または「アクション」メニューから「新規エンドポイント」を選択します)。

2. 新規エンドポイントURIを入力します(/wssuser)。

3. Oracle WSMポリシー(sts/wss_username_service_policy)を選択します。

4. 検証テンプレートを選択します(username-wss-validation-template)。

5. 「適用」をクリックして定義を送信し、確認ウィンドウを閉じます(または「元に戻す」をクリックし、送信せずにページを閉じます)。

6. ページを閉じます。

Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved.