Hanaki's weblog

All | Directory | G党日記 | IDM | JavaES | OpenSSO | WC2006 | 仕事 | 趣味etc..

« 前のページ | メイン | 次のページ »

2009年 2月 25日水曜日

Glassfish 用のポリシーエージェント(J2EE Agent 3.0)のインストール手順

wikis.sun.com に、Glassfish 用の J2EE 3.0 Agent のインストール手順を書いてみました。

Glassfish 用のポリシーエージェントのインストール手順

正式なマニュアルは docs.sun.com にあるので、手順については Installing the Application Server 8.1/8.2/9.0/9.1 Agent を見てもらえれば事足りるのですが、なにぶん英語ですので、ぱっと見でわかるものとして日本語で書かれていたものがあれば便利かなと思った次第です。

この中で特に気をつけたいのは、エージェントのインストール前に対象となる Glassfish のドメインを停止することでしょうか。私自身、これをうっかり忘れたために、インストール後にエージェントのクラスパスがうまく設定されてなくて、Glassfish の起動時に exception エラーが出てエージェントが機能しなかったという経験を何度かしましたので。。。。

参考にしていただければと思います。

Posted by hanaki ( 2月 25日 2009年, 11:37:31 午前 JST ) Permalink 投稿されたコメント [0]

2009年 2月 20日金曜日

【確認編】J2EE Agent 3.0 を用いて Weblogic に配備したサンプルアプリケーションをプロテクトする

前回のブログで、J2EE Agent 3.0 を用いて Weblogic に配備したサンプルアプリケーションをプロテクトするための設定について説明しました。
今回は、期待通りにポリシーが動作するかどうかを確認してみます。

11. 動作確認

セクション 9 で作成したユーザーを使ってサンプルアプリケーションのいろんなリンクにアクセスして、ポリシーが期待通りに動作するかどうかを確認してみます。

ブラウザを立ち上げて、http://my.test.domain.com:7023/agentsample へアクセスします。
次のような welcome ページが表示されるはずです。
左側の区画から、"J2EE Declarative Security" をクリックします。次のようなページが表示されるはずです。
右側の区画に、2 つのリンクが表示されてるので、まずは "Invoke the Protected Servlet" をクリックしてみます。
すぐ上に説明が書かれてるように、このリンクにアクセスできるのは、manager グループに属するメンバーだけです。
リンクをクリックすると、OpenSSO のログインページにリダイレクトされます。
ここで、chris でログインしてみます。
chris は、manager グループのメンバーなので、アクセスが許可されるはずです。
ログインしてみると・・・・・

このように、アクセスに成功したことを示すページが表示されます。
"J2EE Declarative Security" のリンクをクリックします。
今度は、"Invoke the Protected EJB via an Unprotected Servlet" をクリックしてみます。
説明が書かれてるように、このリンクにアクセスできるのは、employee グループに属するメンバーだけです。
chris は、employee グループにも属していますからアクセスできるはずです。
実際にリンクをクリックしてみると・・・

このように、アクセスに成功したことを示すページが表示されます。
次に、左の区画から "J2EE Security API" のリンクをクリックしてみます。
上の "Invoke Security Aware Servlet" をクリックしてみます。

このように、現在ログインしているユーザーが chris であり、manager と employee グループのメンバーであることを示すメッセージが表示されます。
次に、左の区画から "URL Policy Enforcement" をクリックします。
"Invoke a Servlet Protected by URL Policy" をクリックしてみます。
説明されてるように、このリンクにアクセスできるのは、customer グループのメンバーだけです。
chris は、customer グループのメンバーですからアクセスに成功するはずです。
実際にアクセスしてみると・・・・

このように、アクセスに成功した旨を示すページが表示されます。

以上の結果から、chris でログインした場合、アプリケーション側で定義されているポリシーと OpenSSO 側で設定した URL ポリシーの両方に基づいてアクセスコントロールが期待通りに動作していることが確認できました。
ブラウザで、http://my.test.domain.com:7023/agentsample/logout と入力して、ログアウト処理を行います。
これにより、OpenSSO からログアウトされた状態になり、別のユーザーでの検証が可能となります。
ログアウト処理が正しく行われていれば、以下のように webcome ページが表示されているはずです。

今度はユーザー andy で試してみます。

左側の区画から、"J2EE Declarative Security" をクリックします。
"Invoke the Protected Servlet" をクリックします。
OpenSSO のログインページが表示されたら、andy でログインします。
andy も manager グループのメンバーなのでアクセスに成功するはずです。
次に、左の区画から "URL Policy Enforcement" をクリックします。
"Invoke a Servlet Protected by URL Policy" をクリックします。
andy は、customer グループのメンバーではないのでアクセスが拒否されるはずです。
実際にクリックしてみると・・・・

このように、アクセスが拒否されたことを示すページが表示されます。

この結果からも、ポリシーが期待通りに動作していることが確認できます。
http://my.test.domain.com:7023/agentsample/logout にアクセスしてログアウト処理を行ったあと、今度は employee グループにのみ属している frank で試してみます。

左側の区画から、"J2EE Declarative Security" をクリックします。
"Invoke the Protected Servlet" をクリックします。
OpenSSO のログインページが表示されたら、frank でログインします。
frank は、manager グループのメンバーではないので、アクセスが拒否されます。
左側の区画で、"J2EE Declarative Security" のリンクをクリックします。
今度は、"Invoke the Protected EJB via an Unprotected Servlet" をクリックしてみます。
frank は、employee グループのメンバーなので、今度はアクセスに成功します。
次に、左の区画から "URL Policy Enforcement" をクリックします。
"Invoke a Servlet Protected by URL Policy" をクリックします。
frank は、customer グループのメンバーではないのでアクセスが拒否されるはずです。
実際にクリックしてみると・・・・

このように、アクセスが拒否されたことを示すページが表示されます。

最後に、everyone グループにのみ属している gina で試してみます。 (その前に、http://my.test.domain.com:7023/agentsample/logout へアクセスしてログアウトしておきます。)

左側の区画から、"J2EE Declarative Security" をクリックします。
"Invoke the Protected EJB via an Unprotected Servlet" をクリックしてみます。
OpenSSO のログインページが表示されたら gina でログインしてみます。
これまで試したユーザーと違って、gina は、employee グループのメンバーではないので、アクセスが拒否されるはずです。
実際に試してみると・・・

このように、アクセスが拒否されたことを示すページが表示されます。
gina は、"J2EE Security API" のページにある 2 つのリンクに対してもアクセス拒否されます。
また、"URL Policy Enforcement" ページにある "Invoke a Servlet Protected by URL Policy" をクリックした場合もアクセス拒否されます。

このように、いくつかのユーザーを使って、サンプルアプリケーション上のさまざまなページにアクセスし、ポリシーによるアクセスコントロールが期待通りに動作しているかを確認しました。
今回試さなかった、他のユーザーについても同じように期待通りの結果が得られることを確認してみてください。
また、新しいユーザーを作成して、グループに追加してみたり、既存のユーザーをグループから削除した場合にも、ポリシーが期待通りに動作するかどうかも試してみてください。

Posted by hanaki ( 2月 20日 2009年, 07:18:11 午後 JST ) Permalink 投稿されたコメント [0]

【設定編】J2EE Agent 3.0 を用いて Weblogic に配備したサンプルアプリケーションをプロテクトする

今回は、OpenSSO Enterprise 8.0 と J2EE Agent 3.0 を使用して、 Weblogic サーバー上に配備したサンプルアプリケーションをプロテクトする手順についてスナップショットともにデモ形式で紹介しようと思います。

使用するソフトウェア

OpenSSO Enterprise 8.0
J2EE Agent 3.0 for Weblogic
Glassfish V2 Update Release 2
Oracle Weblogic Server 10.3(for sparc platform)

前提条件

OpenSSO, J2EE Agent およびサンプルアプリケーションは同じホスト my.test.domain.com 上にインストールする。
OpenSSO は、Glassfish 上に配備済み。
- URL: http://my.test.domain.com:48080/opensso80
- データストアには組み込みの OpenDS を使用。ルートサフィックスはデフォルトの dc=opensso,dc=java,dc=net とする。
Weblogic は、/opt/bea 以下にインストールし、 J2EE Agent とサンプルアプリケーションの配備用にポート 7023 で、domain2 を作成済み。
エージェントのインストール用にパスワードファイル /export/passwd.txt は作成済み。(パスワードは password とする。)

では、始めてみましょう。

1. エージェントのプロファイルを作成する

まず最初に、OpenSSO コンソール上でエージェントのプロファイルを作成します。

http://my.test.domain.com:48080/opensso80 にアクセスして、amadmin でログインします。
デフォルトでは「共通タスク」のページが表示されるので、「アクセス制御」タブをクリックします。
レルムの一覧ページが表示されますので、"/ (最上位のレルム)" をクリックします。
レルムのプロパティーページが表示されるので、「エージェント」タブをクリックします。
エージェントのページが表示されるので、「J2EE」タブをクリックします。
エージェントセクションで「新規」ボタンをクリックします。
エージェントのプロファイルを作成します。ここでは、次のように入力します。
- 名前：weblogic
- パスワード: password
- 設定: 集中を選択(デフォルトのまま)
- サーバー URL: http://my.test.domain.com:48080/opensso80
- エージェント URL: http://my.test.domain.com:7023/agentapp
入力が終わったら、「作成」ボタンをクリックして、プロファイルを作成します。

2. J2EE Agent 3.0 をインストールする

ダウンロードした weblogic_v10_agent_3.zip を解凍し、 j2ee_agents/weblogic_v10_agent/bin ディレクトリに移動します。
agentadmin を実行可能にします。
```
# chmod a+x agentadmin
```

agentadmin --install を実行してインストールを開始します。ここでは、以下のように入力します。


# ./agentadmin --install

Please read the following License Agreement carefully:

[Press  to continue...] or [Enter n To Finish]
n

Do you completely agree with all the terms and conditions of this License
Agreement (yes/no): [no]: yes

Enter the path to the location of the script used to start the WebLogic domain.
Please ensure that the agent is first installed on the admin server instance
before installing on any managed server instance.
[ ? : Help, ! : Exit ]
Enter the Startup script location
[/usr/local/bea/user_projects/domains/base_domain/startWebLogic.sh]: /opt/bea/user_projects/domains/domain2/startWebLogic.sh

Enter the WebLogic home directory
[ ? : Help, < : Back, ! : Exit ]
Enter the WebLogic home directory [/usr/local/bea/wlserver_10.0]: /opt/bea/wlserver_10.3

Enter the URL where the OpenSSO server is running. Please include the
deployment URI also as shown below:
(http://opensso.sample.com:58080/opensso)
[ ? : Help, < : Back, ! : Exit ]
OpenSSO server URL: http://my.test.domain.com:48080/opensso80

Enter the Agent URL. Please include the deployment URI also as shown below:
(http://agent1.sample.com:1234/agentapp)
[ ? : Help, < : Back, ! : Exit ]
Agent URL: http://my.test.domain.com:7023/agentapp

Enter the Agent profile name
[ ? : Help, < : Back, ! : Exit ]
Enter the Agent Profile name: weblogic

Enter the path to a file that contains the password to be used for identifying
the Agent.
[ ? : Help, < : Back, ! : Exit ]
Enter the path to the password file: /export/passwd.txt

インストールが成功したことを確認したら、次のステップに進みます。

3. startWebLogic.sh を編集する。

J2EE Agent のインストールが完了すると、/opt/bea/user_projects/domains/domain2 ディレクトリに、setAgentEnv_AdminServer.sh が作られています。
このファイルには、J2EE Agent を使用するのに必要な CLASSPATH や JAVA_OPTIONS が定義されているので、
Weblogic の起動時に、このファイルを読み込むように、startWebLogic.sh を編集する必要があります。

/opt/bea/user_projects/domains/domain2/bin ディレクトリに移動し、テキストエディタで startWebLogic.sh を開きます。
". ${DOMAIN_HOME}/bin/setDomainEnv.sh $*" という行がファイルの中程にあるので、
この行のすぐ下に、". /opt/bea/user_projects/domains/domain2/setAgentEnv_AdminServer.sh" という行を追加します。
追加後のファイルは、以下のようになります。(赤字が追加した行)
```
# Call setDomainEnv here.

DOMAIN_HOME="/opt/bea/user_projects/domains/domain2"

. ${DOMAIN_HOME}/bin/setDomainEnv.sh $*
. /opt/bea/user_projects/domains/domain2/setAgentEnv_AdminServer.sh

SAVE_JAVA_OPTIONS="${JAVA_OPTIONS}"

SAVE_CLASSPATH="${CLASSPATH}"

# Start PointBase
```
ファイルを保存して、Weblogic を再起動します。

4. エージェントアプリケーション(agentapp.war) を配備する

次に、Weblogic の console (http://my.test.domain.com:7023/console) に管理者 ID(ここでは、weblogic としてます。) でアクセスして、
j2ee_agents/weblogic_v10_agent/etc ディレクトリにある agentapp.war を配備します。
agentapp.war の配備が完了したら次のステップに進みます。

5. Agent Authentication Provider を設定する

引き続き、Weblogic のコンソール画面で、次の手順を実行します。

左の区画で、Security Realms をクリックします。
右の区画で、myrealm をクリックします。
右の区画で、Providers タブをクリックします。
右の区画で、New ボタンをクリックします。
Name フィールドに適当な名前を入力します。ここでは、agenttest とします。
Type のリストから、AgentAuthenticator を選び、「OK」ボタンをクリックします。
Authentication Providers の一覧から DefaultAuthenticator をクリックします。
Control Flag の値を OPTIONAL に変更し、「Save」ボタンをクリックします。
Weblogic サーバーを再起動して、変更内容を反映させます。

6. バイパス主体リストに weblogic の管理者を追加する

次に、OpenSSO コンソールに amadmin でログインして、先ほど作成したエージェントのプロファイルを編集し、バイパス主体リストに weblogic の管理者 ID を追加します。

ログイン後、「アクセス制御」タブをクリックします。
レルムの一覧ページから "/ (最上位のレルム)" をクリックします。
レルムのプロパティーページで、「エージェント」タブをクリックします。
エージェントのページが表示されるので、「J2EE」タブをクリックします。
先ほど作成したプロファイル weblogic をクリックします。
プロファイルの編集画面で、「その他」タブをクリックします。
バイパス主体リストの新しい値フィールドに、weblogic (ここでは、これが管理者ID となっています。) と入力し、「追加」ボタンをクリックします。
「保存」ボタンをクリックして、変更内容を反映させます。

7. サンプルアプリケーションを配備する

次に J2EE Agent に付属されてるサンプルアプリケーションを配備します。
アプリケーションは、j2ee_agents/weblogic_v10_agent/sampleapp/dist ディレクトリにある agentsample.ear です。
これを、weblogic の管理コンソールで配備します。
配備したら、http://my.test.domain.com:7023/agentsample にアクセスしてみます。
ここまでの設定が正しく行えていれば、次のように OpenSSO のログイン画面へリダイレクトされるはずです。

いったん、ブラウザを再起動して次のステップに進みます。

8. エージェントプロファイルを編集する

次に、先ほど配備したサンプルアプリケーションのプロテクトが正しく行えるように、エージェントのプロファイルにいくつかプロパティーを設定します。

エージェントのプロファイル weblogic をクリックして、編集ページを表示します。
「アプリケーション」タブをクリックします。
「ログイン処理」のセクションで、「ログインフォーム URI」の新しい値に /agentsample/authentication/login.html を入力し、「追加」ボタンをクリックします。
「ログアウト処理」のセクションで、「アプリケーションログアウト URI」の新しい値のマップキーに、agentsample を、
対応するマップ値に、/agentsample/logout を入力し、「追加」ボタンをクリックします。
「アクセス拒否 URI 処理」のセクションで、「リソースアクセス拒否 URI」の新しい値のマップキーに、agentsample を、
対応するマップ値に、/agentsample/authentication/accessdenied.html を入力し、「追加」ボタンをクリックします。
「適用されない URI 処理」のセクションで、「適用されない URI」の新しい値に次の URI を 1 つずつ入力し、その都度「追加」ボタンをクリックします。
- /agentsample/public/*
- /agentsample/images/*
- /agentsample/styles/*
- /agentsample/index.html
- /agentsample
「特権属性処理」セクションで、「特権属性マッピング」の「マップキー」と「対応するマップ値」に
次の値を入力し、その都度「追加」ボタンをクリックします。
これにより、あとで OpenSSO 上で作成するグループの UUID とアプリケーション側であらかじめ設定されているロールのマッピングが行われます。

マップキー対応するマップ値

id=employee,ou=group,dc=opensso,dc=java,dc=net am_employee_role

id=manager,ou=group,dc=opensso,dc=java,dc=net am_manager_role
入力が終わったら、編集内容を反映させるために「保存」ボタンをクリックします。
保存が完了したら、「メインページに戻る」ボタンをクリックして、エージェントの一覧ページに戻ります。

9. 検証用に使うユーザーとグループを作成する

今回配備したサンプルアプリケーションは、アプリケーション側で事前に設定してあるポリシーと、あとで OpenSSO 上で作成する URL ポリシーの両方のポリシーによって
以下のリンクへのアクセスの可否を次のようにコントロールすることを想定しています。

リンク	アクセスを許可する対象
http://my.test.domain.com:7023/agentsample/protectedservlet	manager グループのメンバー
http://my.test.domain.com:7023/agentsample/unprotectedservlet	employee グループのメンバー
http://my.test.domain.com:7023/agentsample/securityawareservlet http://my.test.domain.com:7023/agentsample/invokerservlet	OpenSSO の認証をパスしたユーザー
http://my.test.domain.com:7023/agentsample/urlpolicyservlet	customer グループのメンバー

ここでは、検証用に次の 7 人のユーザーを作成します。

* ユーザーID/パスワード
* andy/andy
* bob/bob
* chris/chris
* dave/dave
* ellen/ellen
* frank/frank
* gina/gina

簡単化のため、各ユーザーの名は省略。姓とフルネームは、ID と同じにする。

次に、manager、employee、everyone、customer と 4 つのグループを作成し、上の各ユーザーを次のようにグループ分けします。

グループ	ユーザー
employee	andy, bob, chris, dave, ellen, frank
manager	andy, bob, chris
everyone	andy, bob, chris, dave, ellen, frank, gina
customer	chris, ellen

例えば、manager グループを作成して、andy、bob、chris の 3 人をグループのメンバーにするには、次の手順で行います。

「対象」をクリックし、「グループ」タブをクリックします。
「新規」ボタンをクリックし、新しいグループページで、ID フィールドに manager と記入し、「了解」ボタンをクリックします。
グループの一覧ページに戻るので、manager のリンクをクリックします。
「ユーザー」タブをクリックして、「選択可能」ボックスから、andy、bob、chris の 3 人を選択して、「追加」ボタンをクリックします。
「保存」をクリックします。

この手順を他のグループについても同様に行います。

10. URL ポリシーを作成する

ここでは、次の 2 つのポリシーを作成します。

policy1
- リソース
  - http://my.test.domain.com:7023/agentsample/jsp/*
  - http://my.test.domain.com:7023/agentsample/invokerservlet
  - http://my.test.domain.com:7023/agentsample/protectedservlet
  - http://my.test.domain.com:7023/agentsample/securityawareservlet
  - http://my.test.domain.com:7023/agentsample/unprotectedservlet
- 対象: 認証済みユーザー
policy2
- リソース
  - http://my.test.domain.com:7023/agentsample/urlpolicyservlet
- 対象: customer グループのメンバー

1 つめのポリシーによって、リソースで定義された各 URL にアクセスするには
少なくとも、OpenSSO での認証をパスすることが必要となります。
その上で、アプリケーション側で設定されたポリシーに基づき、
ユーザーがどのグループに属するかによって最終的にアクセスの可否が決定されます。

また、2 つめのポリシーによって、customer グループのメンバーのみが、
http://my.test.domain.com:7023/agentsample/urlpolicyservlet へのアクセスを許可されます。

例えば、policy1 は次のような手順で作成します。

"/ (最上位のレルム)" のリンクをクリックして、「ポリシー」タブをクリックします。
「新規ポリシー」ボタンをクリックします。
新規ポリシーページで、名前の欄に適当な値を入力します。ここでは、policy1 とします。
注: OpenSSO Enterprise 8.0 では、ポリシー名に日本語を使うとポリシーがうまく動作しません。
この問題は、課題4440で登録されていて、2009/02/14 の時点で修正されたため、それ以降にビルドされた OpenSSO では、ポリシー名に日本語を使えます。
次にルールセクションで、「新規」ボタンをクリックします。
「ルールのサービスタイプを選択」ページでは、「サービスタイプ」として「URL ポリシーエージェント」がデフォルトで選択されているので、そのままの状態で「次へ」をクリックします。
新規ルールのステップ 2 のページで、保護したい URL に関するルールを定義します。
まず、名前を入力しますが、これはどのような名前でも構いません。ここでは、「JSP ページ」と入力します。
次に、プロテクトする URL のパターンを入力します。
「リソース名」フィールドに、http://my.test.domain.com:7023/agentsample/jsp/* と入力します。
「アクション」のところで、GET と POST の両方のチェックボックスをクリックします。
「終了」ボタンをクリックします。
他の 4 つの URL についても手順 4 〜 9 を繰り返します。
5 つの URL についてルールの作成を終えたら、これらの URL パターンに対してアクセスを許可する対象を定義する必要があります。
対象セクションで、「新規」ボタンをクリックします。
「ステップ 1/2: 対象タイプを選択」ページで、「認証済みユーザー」を選択し、「次へ」ボタンをクリックします。
「ステップ 2/2: 対象タイプを選択」ページで、名前フィールドに「認証済みユーザー」と入力し、「終了」ボタンをクリックします。
これで、policy1 の設定が完了したので、最後に新規ポリシーページで「了解」ボタンをクリックします。

policy2 についても policy1 と概ね同じ手順で行いますが、以下の箇所については異なります。

新規ルールのステップ 2 のページで、「リソース名」フィールドに http://my.test.domain.com:7023/agentsample/urlpolicyservlet と入力します。
「ステップ 1/2: 対象タイプを選択」ページで、「OpenSSO アイデンティティー対象」を選択し、「次へ」ボタンをクリックします。
「ステップ 2/2: 新規対象 - OpenSSO アイデンティティー対象」ページで、名前フィールドに適当な値を入れます。
フィルタで、「グループ」を選択し、その横の「検索」ボタンをクリックします。
「選択可能」ボックスに、既存のグループが表示されるので、customer を選んで、「追加」ボタンをクリックします。

2 つの URL ポリシーの作成が完了すると、次のような画面になっているはずです。

これで、必要な設定がすべて完了しました。設定通りにポリシーが動作するかどうか、次のステップで検証してみます。 (長くなりましたので、別のページに書きます。)

Posted by hanaki ( 2月 20日 2009年, 11:39:54 午前 JST ) Permalink 投稿されたコメント [0]

2009年 1月 23日金曜日

OpenSSO FAQ center 日本語版

以前からこのブログで書いてましたように、仕事の合間をぬって
OpenSSO FAQ center の翻訳をしてましたが、
一部のページを除いて翻訳を終えましたので、さきほど opensso のサイトにチェックインしました。

英語版の FAQ は Enterprise 8.0 がリリースされるよりもかなり以前に書かれたものなので、
手順にあるコマンドが古かったり、手順が間違っていたりなど、翻訳作業以外にもこういった箇所
の手入れにずいぶんと時間がかかりましたが、
手順の確認のために実際に試したりすることで、いろいろ学ぶこともできました。

OpenSSO FAQ center の日本語版は、日本語トップページから直接アクセスできます。

FAQ のアイコンをクリックすると、日本語の FAQ ページに直接飛びます。

ここ翻訳がおかしいとか、書いてる内容が違ってるとか（そもそも英語が間違ってる場合もあるが・・）、何かお気づきの点があればコメントください。
まだ未翻訳の部分について翻訳を手伝ってくれる方いましたら、大歓迎です！

Posted by hanaki ( 1月 23日 2009年, 04:30:45 午後 JST ) Permalink 投稿されたコメント [0]

2009年 1月 20日火曜日

OpenSSO wiki サイトの翻訳について

前回のブログで、wikis.sun.com の OpenSSO コンテンツの日本語翻訳始めました、と書きましたが、実際に日本のユーザーの方が、ここにある様々なコンテンツの中で、日頃どういったものを読んでいて、またそれが日本語になっているといいのに・・・と思っているのか、
そういったユーザーの声をぜひ聞いてみたいなと思いまして、
このブログのコメント欄にでも、このページが翻訳されてるとありがたい！なんてコメントをいただけると助かります。
（リクエスト→即翻訳というわけにはいかないですが、優先順位は上がります。）
よろしくおねがいします。

Posted by hanaki ( 1月 20日 2009年, 01:16:43 午後 JST ) Permalink 投稿されたコメント [0]

2009年 1月 18日日曜日

OpenSSO とポリシーエージェントに関するスターティングガイド(wikis.sun.com)

OpenSSOのトップページにある、"Get Started" のボタンをクリックすると、wikis.sun.com にある Getting Started with OpenSSO and Policy Agents に飛びます。
このページは残念ながら英語で書かれてます。

というか、wikis.sun.com にある OpenSSO 関連のコンテンツのほとんどが英語のみで、日本語に翻訳されたものや、日本語で書き下ろしたものはあまりありません。wikis.sun.com は、公式のマニュアル文書ではないものの、技術的に非常に助けになる情報がいろいろと載ってますので、OpenSSO をもっと多くの日本のユーザーに使ってもらう上では、こういったコンテンツの日本語化も大事だと思うので、佐藤さんと協同で、少しずつ日本語化作業を始めていくことにしました。

手始めに、Getting Started with OpenSSO and Policy Agents を日本語にしてみたのが、こちらになります。

OpenSSO とポリシーエージェントに関するスターティングガイド

このページからリンクを飛ばしてる先のページについては、まだ３つほど英語のままのものがあるので、近いうちに日本語にしていく予定です。

あとで、OpenSSO のトップページからも飛べるように、ボタンのリンク先を変えておきます。（せっかくなので、ボタンのイメージも日本語にしよう・・・）

Posted by hanaki ( 1月 18日 2009年, 11:04:16 午後 JST ) Permalink 投稿されたコメント [0]

2009年 1月 08日木曜日

The Globosso 始めました

OpenSSO の globalization チームで The Globosso というブログを立ち上げました。
このブログでは、globalization(ローカライズ＋国際化）の観点から、
OpenSSO についてのいろんな情報をさまざまな言語、英語、日本語、中国語、韓国語、ドイツ語、フランス語、スペイン語などで発信していく予定です。（私はもちろん日本語担当です。）

まだブログを始めたばかりですが、徐々にコンテンツの量が増えるにつれて、さまざまな言語が飛び交うグローバルなブログらしいものになっていくことでしょう。

Posted by hanaki ( 1月 08日 2009年, 07:45:08 午後 JST ) Permalink 投稿されたコメント [0]

J2EE Agent 2.2 の設定手順例

本日の作業の備忘録として書き残しておきます。

使った環境は以下のとおり。

machineA: Web Server 7.0 上に Access Manager 7.1 を配備済み。
machineB: Tomcat 5.5 上に Web アプリケーション /community を配備済み。
このアプリケーションをプロテクトして、特定のユーザーにのみアクセスを許可する。

machineA 上で、Access Manager にログインし、エージェントプロファイルを作成。
```
名前：agent

パスワード:password
```
machineB 上で、あとで行うエージェントのインストール用に、パスワードファイルを作成。
```
# echo "password" > /tmp/passwd.txt
```

J2EE Agent for Tomcat 5.5 をダウンロードし、machineB にインストール。



# pkgadd -d . SUNWamtc

# cd /opt/j2ee_agents/am_tomcat_agent/bin

# ./agentadmin --install

（デフォルト以外の値を入力した箇所のみ記載。）

Enter the Tomcat Server Config Directory Path

[/opt/jakarta-tomcat-5.5.9/conf]: /usr/home/wrldsrvr/apache-tomcat-5.5.17/conf

Access Manager Services Host: machineA

Enter the Agent Host name: machineB

Enter the $CATALINA_HOME environment variable: /usr/home/wrldsrvr/apache-tomcat-5.5.17

Enter the port number for Application Server instance [80]: 8080

Enter the Agent Profile name: agent

Enter the path to the password file: /tmp/passwd.txt

エージェントのインストールがおわったら、agent_00*/config/AMAgent.properties を編集する。



プロテクトの対象外となるパスを指定。

com.sun.identity.agents.config.notenforced.uri[0] = /ws/*


フィルタモードは、URL_POLICY にする。(以下の行を追加）

com.sun.identity.agents.config.filter.mode[community]=URL_POLICY

/opt/j2ee_agents/am_tomcat_agent/etc/agentapp.war を Tomcat に配備する。
Tomcat を再起動する。
Access Manager にログインし、「allowedusers」というグループを作成し、
アプリケーションへのアクセスを許可するユーザーを登録する。（例えば、user01 を登録しておく）

次の条件でポリシーを作成する。



リソース：http://machineB/community/*

対象：Access Manager アイデンティティー対象　グループ「allowedusers」

この状態で、http://machineB/community/* にアクセスすると、http://machineA/amserver/UI/Login にリダイレクトされるので、user01 でログインすると、http://machineB/community/* へアクセスできる。このとき、他のユーザーアカウントでログインすると 403 error でアプリケーションへのアクセスは拒否される。Access Manager でのログインに失敗した場合もアプリケーションへのアクセスはできない。

かなり簡易的ではあるが、これでアプリケーションへのアクセスをポリシーで制御できる。

Posted by hanaki ( 1月 08日 2009年, 01:17:28 午前 JST ) Permalink 投稿されたコメント [0]

2008年 12月 19日金曜日

ssoadm コマンドを使ってポリシーエージェント 3.0 のプロファイルを OpenSSO に設定する方法

この方法については、以前からこちらのページに載っているので、すでにご覧になっている方も多いと思いますが、 2008年5月の時点で書かれているために、製品名やコマンド名が古いままですね。やはり、現状に即して、しかも日本語で書かれた手順書があった方が日本のユーザーにとってはより便利だと思うので、上記の wiki ページの内容をベースにしつつ、実際に、OpenSSO Enterprise 8.0 と Web Agent 3.0 for Webserver 7 を使って設定した結果を元に、手順をまとめてみました。

使用した環境は以下のとおりです：

マシン１：machine1.example.com
- Glassfish V3 がインストール済み。(ポート 8080)
- ここに OpenSSO を配備する。
マシン２：machine2.example.com
- Web Server 7.0 がインストール済み。(ポート 80)
- Web Agent 3.0 をインストールし、この web server をプロテクトする。

こちらから、OpenSSO 8.0 をダウンロードし、こちらから、Web Agent 3.0 for Webserver 7 for Solaris Sparc をダウンロードします。
マシン1 上で、OpenSSO 8.0 を配備します。（今回はエージェントの設定がメインなので、OpenSSO の設定手順は省略します。）
マシン2 上で、sjsws_v70_SunOS_sparc_agent_3.zip を解凍します。
web_agents/sjsws_agent/bin/ ディレクトリに移動し、 agentadmin を実行可能にします。
```
   #chmod 755 agentadmin
```

マシン2 で、agentadmin --install を実行します。


Sun Java System Web Server Config Directory :
/var/opt/SUNWwbsvr7/https-machine2.example.com/config
OpenSSO server URL : http://machine1.example.com:8080/opensso
Agent URL : http://machine2.example.com:80
Agent Profile name : WS7Agent
Agent Profile Password file name : /export/agentpw.txt

マシン2 の Web Server を再起動します。
再起動後に、http://machine2.example.com にアクセスしてみると、
エージェントによりプロテクトされているために、Web Server のトップぺージは表示されません。

　　これで、ポリシーエージェントが機能していることは確認できました。

次に、本稿での本題である、ssoadm コマンドを用いてのエージェントの作成を行います。
マシン1 で、opensso_enterprise_80.zip から、opensso/tools/ssoAdminTools.zip を抽出し、さらに ssoAdminTools.zip を解凍します。
```
# cd /workspace
# unzip openssoenterprise_80.zip opensso/tools/ssoAdminTools.zip 
# cd opensso/tools
# unzip ssoAdminTools.zip
```
JAVA_HOME を指定して、setup コマンドを実行します。(Windows 環境では、setup.bat コマンドを実行します。)
```
#  export JAVA_HOME=/usr/jdk/jdk1.5.0_16
# ./setup
Path to config files of OpenSSO server (example: /opensso): 
Debug directory is /tmp.
Log directory is /tmp.
The version of this tools.zip is: Enterprise 8.0 Build 6(2008-October-31 09:07)
The version of your server instance is: Enterprise 8.0 Build 6(2008-October-31 09:07)
#
```
最初に、OpenSSO の設定ディレクトリの場所を聞かれますので、 OpenSSO の設定を行った際に指定したディレクトリを入力します。
残りのプロンプトに対しても適切な値を指定すると、上記のように設定が完了し、 <設定ディレクトリ>/bin の下に ssoadm などのコマンドラインツールが用意されます。
(デフォルトでは、opensso/bin の下に置かれます。)
sso コマンドのあるディレクトリに移動します。
このディレクトリに、マシン 2 でエージェントをインストールしたときに生成された OpenSSOAgentConfiguration.properties をコピーします。
OpenSSOAgentConfiguration.properties を編集し、最後に以下の行を加えます。
```
userpassword=エージェントのパスワード(/export/agentpw.txt に書いた値)
```
必要に応じて、ファイル内の他の属性の値を変更、もしくは値が入ってない箇所について値を入れます。
そして、最終的に値を入れていない行については、削除します。
注意：値がセットされていない行を残したままだと、次の手順で ssoadm の操作が失敗するかもしれません。（実際に、私が試した場合は、以下の行に値が入ってない状態だとエラーになりました。)
```
com.sun.identity.agents.config.debug.level =
com.sun.identity.agents.config.auth.connection.timeout =
```

amadmin のパスワードを平文形式で /export/passwd.txt に書き、 root ユーザーに対してのみ read-only とします。


#chmod 400 /export/passwd.txt

そして、以下のコマンドを実行します。　


# ./ssoadm create-agent -e / -b WS7Agent -t WebAgent -u amadmin -f /export/passwd.txt -D OpenSSOAgentConfiguration.properties

エージェント設定が作成されました。
#

これで、エージェントのプロファイルが OpenSSO 上に作成されました。

確認には、list-agents サブコマンドを用います。


# ./ssoadm list-agents -e / -u amadmin -f /export/passwd.txt

SecurityTokenService (id=SecurityTokenService,ou=agentonly,o=openssosp)
wsc (id=wsc,ou=agentonly,o=openssosp)
test2 (id=test2,ou=agentonly,o=openssosp)
WS7Agent (id=WS7Agent,ou=agentonly,o=openssosp)
agentAuth (id=agentAuth,ou=agentonly,o=openssosp)
test3 (id=test3,ou=agentonly,o=openssosp)
wsp (id=wsp,ou=agentonly,o=openssosp)
test (id=test,ou=agentonly,o=openssosp)

#

このように　WS7Agent が作成されていることが確認できます。
また、amadmin で、http://machine1.example.com:8080/opensso にログインし、「アクセス制御」->「/ (最上位のレルム)」->「エージェント」と順にクリックすると、以下のように WS7Agent が作られていることが確認できます。

エージェントの設定内容を確認するには、show-agent サブコマンドを用います。


# ./ssoadm show-agent -e / -b WS7Agent -u amadmin -f /export/passwd.txt

(出力結果の一部を抜粋）
:
com.sun.identity.agents.config.iis.filter.priority=HIGH
com.sun.identity.agents.config.agent.logout.url[0]=
com.sun.identity.agents.config.local.log.size=52428800
com.sun.identity.agents.config.cookie.name=iPlanetDirectoryPro
com.sun.identity.agents.config.fqdn.check.enable=true
com.sun.identity.agents.config.debug.file.size = 10000000
:
#

このようにエージェントの属性が表示されます。

属性の値を変更するには、update-agent というサブコマンドを用います。
例えば、com.sun.identity.agents.config.debug.file.size の値を 20000000 にするには、次のようにコマンドを実行します。


# ./ssoadm update-agent -e / -b WS7Agent -u amadmin -f /export/passwd.txt -s -a "com.sun.identity.agents.config.debug.file.size=20000000"

エージェント設定が更新されました。
#

これで属性値が更新されました。show-agent サブコマンドで確認してみると、


#./ssoadm show-agent -e / -b WS7Agent -u amadmin -f /export/passwd.txt  | grep debug.file.size
com.sun.identity.agents.config.debug.file.size=20000000
#

このように値が変更されていることが確認できます。

ちなみに、エージェントの削除は、delete-agents サブコマンドを用います。


# ./ssoadm delete-agents -e / -s test -u amadmin -f /export/passwd.txt

次のエージェントが削除されました。
    test
#

注意：エージェントを作成、変更、削除した場合は、変更内容を反映させるために　Web Server を再起動してください。

マシン2 で Web Server を再起動し、http://machine2.example.com/ にアクセスします。
今度は、マシン1の OpenSSO のログインページ (http://machine1.example.com:8080/opensso) にリダイレクトされるはずです。

ここまで来ればもう一息。残る作業は、OpenSSO 上でのポリシーの定義です。
（ポリシー定義についての細かい手順についての説明はここでは省きます。）
今回、定義したポリシーは次のとおりです。
```
ルール：
 サービスタイプ：URL ポリシーエージェント
 リソース名：http://machine2.example.com:80/*
 アクション： GET 許可  POST 許可
対象： OpenSSO アイデンティティー対象
　　　 選択したユーザー：amadmin のみ
条件：なし
応答プロバイダ：なし
```
また、検証用に amadmin 以外に amuser1 というユーザーを作成しておきます。

この状態で、もう一度 http://machine2.example.com にアクセスし、リダイレクトされた OpenSSO のログインページで、 amadmin でログインすると、

このように、Web Server のトップページが表示されます。

ブラウザを再起動して、http://machine2.example.com にアクセスし、リダイレクトされた OpenSSO のログインページで、今度は、amuser1 でログインしてみます。
amuser1 は、ポリシー定義で、http://machine2.example.com/* へのアクセスを許可した対象に含まれていないので

このように、アクセス不可となり、ポリシーの定義にしたがって、 http://machine2.example.com/*　へのアクセスの可否が制御されていることが確認できます。

最後に：
OpenSSO 8.0 および関連するポリシーエージェントのマニュアルは、以下のサイトにありますので、 ssoadm コマンドやエージェントに関連するサブコマンドについての情報はこちらで参照できます。(ドキュメントは英語で書かれています。)
http://docs.sun.com/app/docs/coll/1767.1?l=ja
リリースノートのみ、日本語マニュアルがあります。
http://docs.sun.com/app/docs/coll/1905.1?l=ja

Posted by hanaki ( 12月 19日 2008年, 11:24:58 午前 JST ) Permalink 投稿されたコメント [0]

2008年 12月 11日木曜日

OpenSSO を Glassfish V3(Prelude) に配備するための手順

Glassfish の最新版、"V3 Prelude" がリリースされてますが、 OpenSSO を V3 Prelude に配備する際にはワークアラウンドを施す必要があるようですね。
Installing OpenSSO Enterprise 8.0 on GlassFish v3 Prelude Release

実際に自分でも OpenSolaris 2008/11 上で配備して確かめてみました。

1. Glassfish V3 のインストール

まずは、Glassfish V3 をダウンロード。
JAVA_HOME を設定したあと、インストーラを起動したら日本語が□で表示されてしまったので、以下の workaround を実行。
```
# mkdir jdk1.6.0_10/jre/lib/fonts/fallback
# ln -s /usr/X11/lib/X11/fonts/TrueType/ipafont/ipagui.ttf jdk1.6.0_10/jre/lib/fonts/fallback
```
再度インストーラを起動すると、日本語が表示されました。
ライセンスに同意して、インストールディレクトリを指定し、管理の設定画面でユーザー名とパスワードを指定して、インストールを実行。
インストール終了後、"asadmin start-domain" でサーバーを実行し、インスタンスが動いていることを確認。

これで、Glassfish のインストールが完了したので、次は OpenSSO を Glassfish に配備します。

2. OpenSSO の配備と設定

OpenSSO Enterprise 8.0 をダウンロードして、zip ファイルから opensso.war を抽出。
```
# unzip opensso_enterprise_80.zip opensso/deployable-war/opensso.war
```
Glassfish の管理コンソールにログインし、opensso.war を配備。
配備が完了したら、左の区画で「アプリケーションサーバー」をクリック。
右の区画で、「JVM 設定」->「JVM オプション」をクリック。
-client は、-server に、-Xmx512m は -Xmx1024m に変更し保存。
Glassfish を再起動。
OpenSSO を配備した URL にアクセスし、設定を行う。
設定が完了したら、「ログインに進む」をクリック。
ログインページで、amadmin でログインしてみると・・・・

あらら？？リダイレクトがうまくいかずに、ログインページに戻ってしまいます。

これは、OpenSSO が値に"="(イコール)を含んだ cookie を設定しようとするのに対して、Glassfish V3 が、その cookie の値を正しく処理できないために起こる問題です。
(= のところで値を切ってしまう) これは、Glassfish の課題 6875として登録されており、まだ修正されていませんが、以下のワークアラウンドでこの問題を回避することができます。

回避方法

Glassfish の管理コンソールにログインし、左の区画で「アプリケーションサーバー」をクリック。
右の区画で、「JVM 設定」->「JVM オプション」をクリック。
「JVM オプションを追加」をクリック。
-Dcom.iplanet.am.cookie.c66Encode=true を値に入れて保存。

Glassfish を再起動して、もう一度 amadmin でログインしてみると・・・・・

今度は、無事ログインできました。

確かに、上のワークアラウンドを適用することで Glassfish V3 上で OpenSSO を利用できます。なお、users@opensso.dev.java.net メーリングリストでのやりとりによれば、このワークアラウンドの使用に関して１点注意事項があるそうで、 OpenSSO とともに J2EE エージェントを使用する場合は、このワークアラウンドは使用してはいけないとのことです。
ご注意ください。(J2EE エージェントを使う場合は、Glassfish V3 以外の web コンテナに配備した方がよいということですね。)

Posted by hanaki ( 12月 11日 2008年, 06:06:18 午後 JST ) Permalink 投稿されたコメント [0]

2008年 12月 05日金曜日

OpenSSO 日本語ページにリダイレクトされるようになりました。
先日、OpenSSO 日本語プロジェクトページを始めました、とお知らせしましたが、本日より、ブラウザの言語設定が ja になっている場合、OpenSSO トップページにアクセスすると、自動的に日本語のトップページにリダイレクトされるようになりました。
Posted by hanaki ( 12月 05日 2008年, 03:41:06 午後 JST ) Permalink 投稿されたコメント [0]

2008年 12月 03日水曜日

Sun Tech Days 2008 in Tokyo
今日から3日間、東京ミッドタウンでは Sun Tech Days 2008 in Tokyoが開催されてます。
Sun で出している展示コーナーの１つに、Globalization pod というのがありまして、Sun が関連しているコミュニティの紹介や、コミュニティでの日本語化活動について、翻訳テクノロジーの紹介などを行ってます。
去年に引き続き、今年もその pod の説明員として、*初めて*東京ミッドタウンに足を運びました。
こういう機会でもないとなかなか行ける場所じゃないですね。。。

展示コーナーの入り口では、Duke がお出迎え(^^)

今回、説明員として、いろんな方とお話させていただいて印象に残ったのは、コミュニティというのが、まだまだ特殊なもの、「マニアな、すでにその分野の知識を備えている人が集まった、新参者にはちょっと敷居の高い集まり」と思われている方が結構いたということです。
製品を使ってみようかなとか、使っててちょっとわからないことがあるからコミュニティに質問投げかけてみようかな・・・と思って、「でも、こんなこと知ってて当たり前なんだろうなぁ。。。こんな基本的なこときけないなぁ・・・」といった感じで二の足踏んでしまうんです、という声をちらほらききました。
コミュニティは、基本的には誰でも自由に参加できる「オープン」な場ではあるものの、扉は開いていても、どこかまだ近寄りがたさをイメージさせてしまうものなんですね。
で、そういうコメントをくださった人達のほとんどが、だからこそ、こういったイベントを開催してくれることで、その分野のエキスパートな人達からいろんな話が聞けるし、展示コーナーなどで、普段相手が見えないコミュニティでは聞きにくいことも、face-to-face の安心感もあって質問できたりして、非常にありがたいです、とおっしゃってました。
Sun Tech Days の開催意義はこういったところにもあるんですね。(^^)
あと、どんなコミュニティに関心ありますか？という質問に、思いのほか（といっては、製品を担当してるくせにおかしな話ですが）、”OpenSSO”という声が返ってきて驚きでした。
でも、そのあとには、「英語がねぇ・・・・」でした。
タイムリーなことに、数日前に、OpenSSO 日本語プロジェクトページをオープンしていたので、「まだまだはじめたばかりですが、徐々にこちらの内容も充実させていきたいと思ってます」という風に回答することができました。
とりあえずトップページだけでも日本語になってるものを見せることができてよかったです^^;;
（現在は、FAQページの日本語化を行ってますので、近日中のアップをお待ちください。）
今後は、OpenSSO コミュニティに入ってる日本の方と協業して、こういった日本語ページの充実化というものをはかっていきたいですね。興味ある方いましたら、ぜひぜひご一報を！（もちろん、サンの社員の方でも！）
日本語ユーザー用のメーリングリストなんてのもあるといいですよね。

Posted by hanaki ( 12月 03日 2008年, 12:29:05 午前 JST ) Permalink 投稿されたコメント [0]

2008年 11月 28日金曜日

OpenSSO 日本語プロジェクトページ
OpenSSO のプロジェクトページ自体は、ご存じの方は多いと思いますが、これまでは英語のサイトしかありませんでした。（一部 UI は日本語化されてますが）
かねてから、Glassfish のように OpenSSO も日本語ページがあった方がより、日本語ユーザーが OpenSSO コミュニティに興味を持ってくれるんじゃないかなぁ。。。と思ってまして、ここ数日、OpenSSO owner といろいろやりとりをしてました。で、ついに、昨日、「はじめの一歩」として、トップページを開設することができました。
URL は、こちらです。

まぁ、開設といいましてもまだ index.html を翻訳しただけなので、「一歩」踏み出したにすぎませんが。今後は、他のページの翻訳とか、右サイドのハイライトページに載せるとよさそうな HOW TO ものや、トピックネタの日本語記事などを集めたり、自分でも書いたり、色々やることはありそうです。
まずは、日本語ページの開設を宣伝するとともに、この日本語プロジェクトページを充実させていくのに、一緒に興味を持ってやっていただける方などいないかなぁ。。とさりげなく募ってみたりなんかして・・・(もちろん、Sun 社内、社外の方問わずです。）

Posted by hanaki ( 11月 28日 2008年, 03:02:21 午後 JST ) Permalink 投稿されたコメント [0]

2008年 11月 27日木曜日

JavaES 5 U1 の Access Manager を Solaris 10 U6 上で Glassfish に配備する際の注意事項

今回は、JavaES 5 Update 1 の Access Manager (バージョン 7.1) を Solaris 10 Update 6 (Solaris 10 の最新のアップデートリリース) 上で、Glassfish に配備する際に注意すべきことについて書きたいと思います。

説明のために、具体的なシナリオとして、以下のような手順でインストール、設定、配備を行うことにします。

プラットフォームは、Solaris 10 U6 for x86(64 bit) とする。
まず、 Glassfish v2 Update release 2(Sun Java System Application Server 9.1 Update 2) をインストールする。
次に、Sun Java System Directory Server Enterprise Edition version 6.3(以下 DSEE 6.3) をインストールする。
最後に、JavaES 5 Update 1 のインストーラを用いて、同梱されている Access Manager 7.1 (以下 AM 7.1) をインストールし、amconfig コマンドを用いて、Glassfish に配備する。

1. Glassfish のインストール

Glassfish は、Sun download centerや、Glassfish のダウンロードページからダウンロードできます。
ダウンロードしたら、インストーラを起動して、画面の指示に従ってインストールを行ってください。インストールが完了し、サーバーの起動を済ませたら、ブラウザで実際に確認してみます。
こんな画面が表示されていれば、OK です。

2. DSEE 6.3 のインストール

DSEE 6.3 は、こちらからダウンロードできます。各選択肢については、以下のように選んで「View Downloads」をクリックします。

Step1 Select Component: Directory Server Enterprise Edition 6.x
Step2 Select Version: 6.3
Step3 Select Delivery Type: Compressed Archive(ZIP)
Step4 Select Platform: Solaris 10 64x86

すると、次のような画面が表示されますので、Installation Type が "Full Install" となっている箇所のリンクをクリックします。(画面で紫色になっている箇所です。)

すると、次のような画面になりますので、再度 Platform を選択し、(Solaris x64) License Agreement のボックスをチェックして、「Continue」をクリックします。

新たに表示される画面で、DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz のリンクをクリックするとダウンロードできます。

ダウンロードが終わったら、適当なディレクトリにファイルを置いて、解凍します。


# mkdir /export/DSEE
# cp DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz /export/DSEE
# cat DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz | gunzip | tar xf -

解凍後は、このような感じになっているはずです。


# ls /export/DSEE
DSEE_Directory_Editor
DSEE_Identity_Synchronization_for_Windows
DSEE_ZIP_Distribution
LICENSE.txt
Legal
README.txt
#

DSEE 6.3 をインストールします。(ここでは、Directory Editor と Identity Sync 以外の全てのコンポーネントをインストールします。)

# cd DSEE_ZIP_Distribution/
# ./dsee_deploy install -i /opt/dsee63
英語のライセンステキストが表示されるので、最後まで表示されるまでリターンキーを押し、
Do you accept the license terms ?  : に対して、「yes」と入力。

これで、/opt/dsee63 に、DSEE6.3に含まれているディレクトリサーバーなどがインストールされました。 Access Manager の配備用に、インスタンスの作成、起動およびサフィックスの作成を済ませておきます。


# cd /opt/dsee63
# ./dsadm create /export/dsins1
# ./dsadm start /export/dsins1
# ./dsconf create-suffix dc=example,dc=com
# ./dsconf import /opt/dsee63/ds6/ldif/Example.ldif dc=example,dc=com

(ここでは念のため、空のサフィックス dc=example,dc=com を作ったあとに、Example.ldif をインポートしています。)
これで、ディレクトリサーバーの準備が整いました。

3. JavaES5 U1 のインストーラを用いて AM 7.1 をインストール

次に、JavaES 5 U1 のインストーラを起動して、AM 7.1 をインストールします。
インストーラを起動する際には、ja_JP.UTF-8 ロケールで起動することをお勧めします。なぜその方がよいかはあとの項目で説明します。
諸事情により、ja ロケールなど、UTF-8 以外のロケールで起動したい場合は、それで進めてもかまいません。（あとでワークアラウンドで対処します。）
ソフトウェアコンポーネントの選択画面では、Access Manager 7.1 の全てのコンポーネントを選択し、Directory Server Enterprise Edition 6.2 のコンポーネントのチェックは全て外します。
「次へ」をクリックすると、Web コンテナの選択画面が表示されますので、「互換性のある Web コンテナが、このシステム上にすでにインストール済み」を選択します。
さらに、依存関係の警告画面が表示されますので、ここでは「リモートマシンにインストールされている Directory Server Enterprise Edition 6.2 を使用する」を選択します。注意：これは、あくまで、DSEE6.2 のインストールを回避するためであり、実際には、ローカルにある DSEE6.3 を使います。
これで、画面を先に進めていくと、アップグレードの必要がある共有コンポーネントが表示されます。その中に、Cacao も含まれていますが、インストール済みと必要なバージョンについて見てみると、必要なバージョンの方が古い（パッチのリビジョンが低い）ことに気づくかと思います。

JavaES 5 U1 がリリースされた時点では、JavaES 5 U1 に同梱されている Cacao のパッチのリビジョン(123896-03)が最も新しかったために、その想定のもとにインストール時には常に Cacao のパッケージを入れ替える動作になっていました。
しかしながら、Solaris 10 U6 は、JavaES 5 U1 以降にリリースされましたので、パッチのリビジョンがより新しい(123896-05) Cacao が同梱されているわけですが、JavaES 5 U1 のインストーラはその想定外のことに対処できていないわけです。結果として、古いリビジョン (123896-03) の Cacao に入れ替わってしまいます。
とりあえずここでは、画面を先に進めて、設定タイプの選択画面では、「あとで設定」を選択し、インストールを完了させます。

4. amconfig を使って、AM 7.1 を設定し、Glassfish に配備する

次に、amconfig を使って、AM 7.1 を設定し、Glassfish に配備します。 /opt/SUNWam/bin/ にある amsamplesilent を環境に合わせて編集し、 "amconfig -s amsamplesilent" と実行すればよいわけですが、ここでストップ！！！このまま実行してはいけません！
もし、そのままコマンドを実行すると、途中で以下のようなエラーが出て設定に失敗してしまいます。

:
:
Creating the agent security materials in /etc/opt/SUNWmfwk/config/security
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
No Java runtime found.
Error : Calling [genkey]
Cleaning up config in /etc/opt/SUNWmfwk/config
amconfig : Looking for registered module...
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
:
:

先ほど説明しましたように、JavaES 5 U1 によって、Cacao が古いリビジョンに入れ替わってしまってます。そのため、cacaoadm のコマンドが動きません。試しに、以下のコマンドを実行してみてください。


# cacaoadm status
Cannot find property: [cacao.embedded].

こんな結果が返ってくるはずです。
この問題を解決するには、もう一度、パッチ 123896-05 をインストールして、Cacao のリビジョンを Solaris 10 U6 に同梱されているリビジョンに戻してあげる必要があります。(sparc 版の場合は、123893-05 です。)

注意事項１: JavaES 5 U1 のインストーラによって Cacao のパッチのリビジョンがダウングレードしてしまったため、Cacao の最新のリビジョンのパッチを再度インストールする。

必要なパッチは、Sunsolveよりダウンロードできます。


# patchadd 123896-05
:
(中略)
:
Patch 123896-05 has been successfully installed.
See /var/sadm/patch/123896-05/log for details

Patch packages installed:
  SUNWcacaort

#

試しにさきほどと同じコマンドを実行してみます。


# cacaoadm status
default instance is DISABLED at system startup.
default instance is not running.

今度はこのようにステータス情報が正しく返ってくるはずです。
これで、Cacao の状態は正常に戻ったので、amconfig コマンドを使って、 Access Manager の設定と配備を行うことができますが、その前に注意すべきことがあります。
amconfig コマンドを使って、Access Manager の設定を行っている過程の最後の方で、 /etc/opt/SUNWam/config/com.sun.cmm.am.xml ファイルの中に、SUNWamsdkconfig パッケージのバージョン情報や、インストールされた日付などが書き込まれます。

amconfig 実行前のファイル：

  <parameter>
  <param-name>RevisionNumber</param-name>
  <param-value>AM_VERSION</param-value>
  </parameter>
<!--
       The InstalledProduct's Installation Date in milliseconds.
-->
  <parameter>
  <param-name>InstallDate</param-name>
  <param-value>AM_INSTDATE</param-value>
  </parameter>

amconfig 実行後のファイル：

-->
  <parameter>
  <param-name>RevisionNumber</param-name>
  <param-value>7.1,REV=06.12.15.12.35</param-value>
  </parameter>
<!--
       The InstalledProduct's Installation Date in milliseconds.
-->
  <parameter>
  <param-name>InstallDate</param-name>
  <param-value>11月 27 2008 13:36</param-value>
  </parameter>

ここで、InstallDate の日付の文字列に「月」という日本語が含まれています。これがちょっとくせものです。
JavaES 5 U1 のインストーラが、SUNWamsdkconfig を pkgadd したときのインストール日時の値が、/var/sadm/pkg/SUNWamsdkconfig/pkginfo の INSTDATE の値に書き込まれます。

INSTDATE=11月 27 2008 13:36

この日付の値は、インストーラを ja ロケールで起動していれば、EUC エンコーディングで、ja_JP.UTF-8 ロケールで起動していれば、UTF-8 エンコーディングで書き込まれます。
そして、amconfig の実行中に、この INSTDATE の値が、 /etc/opt/SUNWam/config/com.sun.cmm.am.xml に書き込まれます。
ところで、/etc/opt/SUNWam/config/com.sun.cmm.am.xml の最初の行を見ると、

<?xml version='1.0' encoding='utf-8'?>

という風に、"このファイルは UTF-8 エンコーディングで書かれてますよ。" と宣言されています。
つまり、JavaES 5 U1 のインストーラを ja_JP.UTF-8 ロケールで起動していれば、日付の値が UTF-8 エンコーディングで書き込まれるため、そのまま amconfig を実行したときに何も問題が起こらないわけです。
さきほど、インストーラを ja_JP.UTF-8 ロケールで起動することをお勧めします。と書いたのはこういった理由があるからです。
もし、インストーラを ja ロケールで起動していたとすると、日付の値は EUC エンコーディングになっているため、そのまま amconfig コマンドを実行すると、 /etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーは、UTF-8 で定義されているのに、中身が EUC エンコーディングになっている、という矛盾によって、次のようなエラーが発生して、amconfig は途中で失敗してしまいます。

Cannot execute command deploy: Invalid byte 1 of 1-byte UTF-8 sequence.

このエラーに対処するには、あらかじめ、/etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーのエンコーディングの定義を適切な値に変えておく必要があります。
例えば、次のように編集します。

<?xml version='1.0' encoding='eucJP'?>

このように編集した上で、amconfig -s amsamplesilent を実行すると、ja ロケール環境でも amconfig による設定が完了します。

:
:
Deploying Node Agent in Cacao from descriptor '/etc/opt/SUNWmfwk/xml/com.sun.mfwk.xml'
Registering Node Agent in Cacao from descriptor '/etc/opt/SUNWmfwk/xml/com.sun.mfwk.xml'
amconfig : Looking for registered module...
amconfig : Registration successful !
amconfig : Restarting cacao. Please wait...
amconfig : Restart of cacao was successful !
#

注意事項２: JavaES 5 U1 のインストーラを ja_JP.UTF-8 ロケール以外で起動した場合には、amconfig を実行する前に、/etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーでのエンコーディングの定義を適切な値に変えておく。

5. 配備ができたことを確認する

さて、amconfig コマンドが完了したら、glassfish を再起動して、AM 7.1 が正しく配備できたかどうかを確認してみます。
が、その前に、またまた注意事項があります！
asenv.conf(アプリケーションサーバーをインストールしたディレクトリの下の config ディレクトリに含まれているファイル) の中の次の行を変更する必要があります。

< AS_NSS="/opt/SUNWappserver/lib"
> AS_NSS="/usr/lib/mps/secv1:/opt/SUNWappserver/lib"

この変更を行わずに glassfish を再起動すると、

[#|2008-11-27T15:51:42.027+0900|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;_RequestID=dd8f3ed3-c2f2-4847-bed0-c89e2003d13a;|WEB0207: 仮想サーバー server で Web コンテキスト StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/amserver] の起動中にエラーが発生しました
LifecycleException:  java.lang.UnsatisfiedLinkError: no jss4 in java.library.path

このように、jss4 が見つかりません、というエラーが server.log に出力されます。
実際に、amserver コンソールにアクセスしても、次のようなエラーになります。

このエラーは、AS_NSS で定義された /opt/SUNWappserver/lib ディレクトリに libjss4.so が存在しないために発生します。libjss4.so は /usr/lib/mps/secv1 に存在するため、そのパスを AS_NSS の値に追加する必要があります。
そのため、上記で述べたように asenv.conf を変更する必要があるわけです。

注意事項３: asenv.conf の AS_NSS に libjss4.so が存在するパスを指定してから、glassfish を起動する。

asenv.conf を修正してから、再度 glassfish を起動すると。。。。

このように、Access Manager のログインページが表示されます。
amadmin でログインしてみると、以下のように正しくページが表示されるはずです。

これで、Access Manager 7.1 を Solaris 10 U6 上で、Glassfish に配備することができました。
もう一度注意事項を以下に記しておきます。全部で３点です。

注意事項１: JavaES 5 U1 のインストーラによって Cacao のパッチのリビジョンがダウングレードしてしまうので、JavaES 5 U1 のインストールの後に、Cacao の最新のリビジョンのパッチを再度インストールする。
注意事項２: JavaES 5 U1 のインストーラを ja_JP.UTF-8 ロケール以外で起動した場合には、amconfig を実行する前に、/etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーでのエンコーディングの定義を適切な値に変えておく。
注意事項３: amconfig による設定が終わったら、asenv.conf の AS_NSS に libjss4.so が存在するパスを指定してから、glassfish を起動する。

Posted by hanaki ( 11月 27日 2008年, 04:24:12 午後 JST ) Permalink 投稿されたコメント [0]

2008年 11月 11日火曜日

OpenSSO Enterprise 8.0 がリリースされました

OpenSSO のダウンロードサイトでは、すでにリリース版のバイナリーが置かれてます。

https://opensso.dev.java.net/public/use/index.html

リリースノートについては、あと１ヶ月後に docs.sun.com にアップされる予定です。

Posted by hanaki ( 11月 11日 2008年, 05:56:04 午後 JST ) Permalink 投稿されたコメント [0]

マップキー	対応するマップ値
id=employee,ou=group,dc=opensso,dc=java,dc=net	am_employee_role
id=manager,ou=group,dc=opensso,dc=java,dc=net	am_manager_role

日	月	火	水	木	金	土
« 12月 2009
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

今日

Hanaki's weblog

2009年 2月 25日 水曜日

2009年 2月 20日 金曜日

11. 動作確認

使用するソフトウェア

前提条件

1. エージェントのプロファイルを作成する

2. J2EE Agent 3.0 をインストールする

3. startWebLogic.sh を編集する。

4. エージェントアプリケーション(agentapp.war) を配備する

5. Agent Authentication Provider を設定する

6. バイパス主体リストに weblogic の管理者を追加する

7. サンプルアプリケーションを配備する

8. エージェントプロファイルを編集する

9. 検証用に使うユーザーとグループを作成する

10. URL ポリシーを作成する

2009年 1月 23日 金曜日

2009年 1月 20日 火曜日

2009年 1月 18日 日曜日

2009年 1月 08日 木曜日

2008年 12月 19日 金曜日

2008年 12月 11日 木曜日

1. Glassfish V3 のインストール

2. OpenSSO の配備と設定

回避方法

2008年 12月 05日 金曜日

2008年 12月 03日 水曜日

2008年 11月 28日 金曜日

2008年 11月 27日 木曜日