Hanaki's weblog

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

20081203 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]

20080327 2008年 3月 27日 木曜日

外部向けMySQLカンファレンス〜春のMySQL祭り

来月、４月９日に、「春のMySQL祭り」と題しまして、
外部の方向けにMySQLカンファレンスを開催します。
プログラムの詳細および参加申し込みについては、こちらから。
みなさんの参加をお待ちしてます。

Posted by hanaki ( 3月 27日 2008年, 02:10:57 午後 JST ) Permalink 投稿されたコメント [1]

20070324 2007年 3月 24日 土曜日

Sun Java Communications Suite 5 is available on sun.com!!

先日、JavaES 5がリリースされましたが、今リリースから　Messaging Server, Calendar Server などの Communication Suites 製品は JavaES 5 とは別個でリリースされることになりました。 具体的には、以下のリリースが、Communication Suite 5 の製品群です。

  1. Java System Calendar Server
  2. Java System Messaging Server
  3. Java System Instant Messaging
  4. Java System Connector for Microsoft Outlook
  5. Java System Communications Sync
  6. Java System Communications Express
そして、本日 Communication Suite 5 がリリースとなりました！ こちらよりダウンロード可能となっておりますので、ぜひダウンロードしてみてください。
次回は、この Communication Suite 5 を使ったインストール＆セットアップについて触れてみようと思います。

Posted by hanaki ( 3月 24日 2007年, 10:08:47 午前 JST ) Permalink 投稿されたコメント [0]

20070316 2007年 3月 16日 金曜日

GlassFish community 日本語版ページ公開

数週間ほど前から、、私が属してる東京ソフトウェア本部にて、荻布さんを中心に、GlassFish Communityを日本語翻訳して、日本語用コミュニティーページを作ろうというプロジェクトが立ち上がっていたのですが、昨日、最初の一歩としていくつかのページの翻訳が終わり、日本語ページが公開されることとなりました。

GlassFish Community からも以下のように日本語版へのリンクが貼られています。

↓

まだはじめの一歩を踏み出したにすぎないので、今後はより多くのページを日本語翻訳したり、他の言語への翻訳の検討も行っていきたいですね。そのためには、より多くの方にこの翻訳プロジェクトに加わってもらって、（できればコミュニティーの方も巻き込んで）、より活性化させていければと思ってます。

Posted by hanaki ( 3月 16日 2007年, 10:00:19 午前 JST ) Permalink 投稿されたコメント [0]

20060331 2006年 3月 31日 金曜日

J2EE Policy Agent 続き 先日のブログで、unauthorized access の場合の挙動がうまく動かないと書きましたが、その後の調査と、U.S. エンジニアのヘルプにより、進展がありました。 現在、エラーページとして設定しているのは、
com.sun.identity.agents.config.login.error.uri[0] = /acmgr-wl/ssoerror.jsp であるため、このページ自体、agent によるプロテクト対象となってます。 つまり、当然、unauthrized user はこのページを見れませんから、 Forbidden 403 が返ってきちゃうわけです。 では、どうしても、/acmgr-wl 以下に用意したエラーページを表示させたいときにはどうするか？
そのためには、さらに AMAgent.properties にある以下のプロパティーを設定する必要があります。 
com.sun.identity.agents.config.notenforced.uri[x]
(x = 0, 1, 2, .....)
ここに指定したパスは、agent のプロテクトの対象外となりますので、unauthorized user であっても、アクセス可能です。 今回のケースでは、以下のように設定すればよいというわけです。 
com.sun.identity.agents.config.notenforced.uri[0] = /acmgr-wl/ssoerror.jsp
確かに、これを設定すると、めでたく、ユーザー satonaka でアクセスしたときには、以下の画面を表示させることができました。 :)

Posted by hanaki ( 3月 31日 2006年, 10:22:50 午前 JST ) Permalink 投稿されたコメント [0]

20060316 2006年 3月 16日 木曜日

J2EE Policy Agent 奮闘記

先日、あるパートナーさんからこのような質問を受けました。 

J2EE Policy Agent 2.2 for Weblogic 8.1SP4 を J2EE_POLICY モードで
セットアップし、Weblogic 上に配備したサンプル web アプリケーションにしてみたのだが
認証成功するはずのユーザーでアクセスしても、"403 forbidden" が表示されてしまう。
URL_POLICY モードでは問題ないので、J2EE_POLICY モードでは、
何か追加で設定すべきことがあるのか？
えー、正直に言いますと、私、このときまで、 J2EE ポリシーエージェントに触れたことがありませんでした。 (Web ポリシーエージェントは、それなりにセットアップしたことはあったのですが。。。） んー、このままではいけない。それに、上の問題も解決しなくちゃいけないし…（汗） というわけで、今回は、遅ればせながら J2EE Policy Agent と接することになった私の J2EE Policy Agent 奮闘記でございます。

シナリオ

まず始めに、今回の想定シナリオを整理しておきます。 今回使用した OS および製品群は以下の通りです。 またマニュアルは、docs.sun.com にある 、Sun Java System Access Manager Policy Agent 2.2 Guide for BEA WebLogic Server/Portal 8.1 SP4 の PDF 版をダウンロードしました。 では、以降の節で、今回行った手順を順に書いていきます。

1. Weblogic のインストールと設定

Weblogic のインストールと設定については、詳細は省くとして、設定内容は以下のとおりです。

2. JavaES 製品(AM, DS & WS) のインストールと設定

これも詳細は割愛します。 Access Manager は、Web Server 上に配備するように選択し、 legacy モードでインストール。その後、パッチ 120956-01 を適用し、 7.0patch1 にアップグレードしました。

ここまではあくまで土台となるもののセットアップ。ここからいよいよ本題です。

3. エージェントのインストールの前に…

ポリシーエージェントをインストールする前に、事前準備として、以下の操作を Access Manager コンソール上で行いました。

3-1) ユーザーとロールの作成

まずは、「manager」ロールを作成。 次に、アクセス許可された場合と拒否された場合の挙動を確認するために、 2 つのユーザーを作成して、片方にだけ「manager」ロールを割り当てました。 まとめるとこんな感じです。
ユーザー名 ロール acmgr-wl へのアクセス
yamada manager 許可される
satonaka なし 拒否される

3-2) エージェントプロファイルの作成

次に、エージェントプロファイルを作成しました。
  1. amadmin で、AM にログイン。
  2. トップのレルムを選択。
  3. 「対象」タブをクリック。
  4. 「エージェント」タブをクリック。
  5. 「新規...」ボタンをクリック。
  6. 次のように値をセットして「作成」をクリック。
    • ID: agent_weblogic
    • パスワード: weblogic
そして、上で設定したパスワードを格納したファイルを用意しました。 （これは、次のエージェントのインストールにおいて、必要） 
# echo "weblogic" > /export/password.txt
これで、準備完了。いよいよポリシーエージェントのインストールへ…。

4. ポリシーエージェントのインストール

Access Manager のポリシーエージェントは、www.sun.comから、ダウンロードできます。
今回使用した、Policy Agent 2.2 for Weblogic 8.1 SP4 は、 ここからダウンロードしました。

早速、ダウンロードした Weblogic_8.1sp4_agent_2.2.tar.gz を解凍＆展開し、j2ee_agents/am_wl81_agent/bin ディレクトリにある agentadmin を --install オプションをつけて実行。 

# ./agentadmin --install
…どうやら、コマンドラインベースのようですねー。Web Policy agent をインストールしてたときは、大概 GUI が使えてましたが、J2EE Policy agent は、どれも CLI でのインストールなんですかねぇ。。
ま、それはさておき、ライセンスを accept すると、順にプロンプトが表示され、設定すべき内容について、問われたので、環境にあわせて入力しました。詳細は省きますが、インストールの最後に表示されたサマリーを以下に記しておきます。 
SUMMARY OF YOUR RESPONSES
-----------------------------------------------
Startup script location :
/usr/local/bea/user_projects/domains/domain1/startWebLogic.sh 
WebLogic Server/Portal instance name : server1 
Access Manager Services Host : angel3.japan.sun.com 
Access Manager Services Port : 80 
Access Manager Services Protocol : http 
Access Manager Services Deployment URI : /amserver 
Agent Host name : angel3.japan.sun.com 
WebLogic home directory : /usr/local/bea/weblogic81 
Agent Installed on Portal domain : false 
Application Server Instance Port number : 7021 
Protocol for Application Server instance : http 
Deployment URI for the Agent Application : /agentapp 
Encryption Key : QFXPxqR/y17S02W/rrdbEMonn+g3YWoi 
Agent Profile name : agent_weblogic 
Agent Profile Password file name : /export/password.txt 
Agent and Access Manager on same application server instance : false

SUMMARY OF AGENT INSTALLATION
-----------------------------
Agent instance name: agent_001
Agent Configuration file location:
/export/j2ee_agents/am_wl81_agent/agent_001/config/AMAgent.properties
Agent Audit directory location:
/export/j2ee_agents/am_wl81_agent/agent_001/logs/audit
Agent Debug directory location:
/export/j2ee_agents/am_wl81_agent/agent_001/logs/debug
インストール後、AMAgent.properties を編集し、あとで配備するサンプルアプリケーションにあわせて、com.sun.identity.agents.config.login.form[0] の値を設定し、 さらに、com.sun.identity.agents.config.filter.mode = J2EE_POLICY　を設定しました。

5. サンプルアプリケーションの配備

サンプルアプリケーションには、パートナーさんから頂いた acmgr-wl.war を利用。 weblogic.xml を編集し、 

   <security-role-assignment>
      <role-name>USER-ROLE</role-name>
      <principal-name>id=manager,ou=role,dc=japan,dc=sun,dc=com,amsdkdn=cn=m
anager,dc=japan,dc=sun,dc=com</principal-name>
   </security-role-assignment>
「manager」ロールの universal-ID をこちらの環境にあわせて変更したあと、weblogic に配備して、再起動…

が、以下のエラーが発生して、再起動できず… 

<Error> <HTTP> <BEA-101165> <Could not load user defined filter in web.xml: ServletContext(id=71734232,name=acmgr-wl,context-path=/acmgr-wl) com.sun.identity.agents.filter.AmAgentFilter.
java.lang.ClassNotFoundException: com.sun.identity.agents.filter.AmAgentFilter
        at weblogic.utils.classloaders.GenericClassLoader.findClass(Ljava.lang.String;)Ljava.lang.Class;(GenericClassLoader.java:199)
:
どうやらパスの設定が不十分な様子…。マニュアル p.80 を参考に、 /usr/local/bea/user_projects/domains/domain1 にある setAgentEnv_server1.sh ファイルに書かれてるパスの設定を、/usr/local/bea/weblogic81/common/bin/commEnv.sh に追加したところ、無事再起動できました。

6. アクセステスト


ブラウザ上で、http://HOST:PORT/acmgr-wl にアクセスしてみると、 期待通りに、Access Manager のログイン画面が表示されました。 ここで、ユーザー「yamada」でログインすれば、以下のような画面が表示されるはず…。
しかし、結果は、
このように、"403 Forbidden..." といったページが表示されてしまいました。 アクセス許可されてるユーザーでログインしたにもかかわらず、アクセス拒否されるのはなぜ？？ まさに、パートナーさんが最初に質問してきた問題に、こちらも遭遇してしまいました。

改めて、マニュアルの Chapter 4. "Post Installation Task" を見直してみると、Weblogic 上で Agent Authentication Provider の作成および設定に関する記述があることを発見(p.82 に記載)。早速、その記述にそって、以下の操作を行いました。
  1. Weblogic のコンソールにログインし、左側の画面から、「Security」を選択。
  2. さらに「Realm」→「myrealm」を選択。
  3. 右側の画面で、「Providers」タブを選択し、「Authentication」をクリック。
  4. リンクの一覧から、「Configure a New Agent Authenticator」をクリック。
  5. 「Create」をクリック。
  6. Control flag の値が「OPTIONAL」になってることを確認して、「Apply」をクリック。
  7. 左の区画で「Providers」→「Authentication」をクリックして、画面の下の方を見ると、確かに「AgentAuthenticator」が作成されてます。
  8. さらに、「Default Authenticator」をクリックして、control flag を OPTIONAL に変更して、Apply をクリック。
そして、Weblogic を再起動しました。

7. アクセステスト(再挑戦)

もう一度さっきと同じように、http:HOST:PORT/acmgr-wl を表示し、Access Manager ログイン画面で、yamada/yamada と ID とパスワードを入力。その結果…

…なんと、またしても、"403 Forbidden" の文字が…。 んー、完全に息詰まってしまいました。。。
他に、マニュアルの Chapter 4 でやり残しているようなものはなさそうだし。
とりあえず、この状況を U.S. のエンジニアに伝えてみました。
と、翌日、こんな返事が返ってきました。
Is your AM is 7.0 or 63? If 63, then your value is right, otherwise change 
it as       <principal-name>id=manager,ou=role,dc=japan,dc=sun,dc=com</principal-name>
どうやら、今の principal-name の値は、AM 7.0 では正しくないようです。 早速、weblogic.xml を次のように変更して、acmgr-wl.war を再配備しました。 
<!--      <principal-name>id=manager,ou=role,dc=japan,dc=sun,dc=com,amsdkdn=cn=m
anager,dc=japan,dc=sun,dc=com</principal-name>-->
      <principal-name>id=manager,ou=role,dc=japan,dc=sun,dc=com</principal-name>

8. アクセステスト(３度目の挑戦)

もう一度さっきと同じように、http:HOST:PORT/acmgr-wl を表示し、Access Manager ログイン画面で、yamada/yamada と ID とパスワードを入力。さぁ、結果はいかに…

やりましたっ！ ようやく期待された動作を示してくれました。:)

いったんブラウザを再起動し、今度は、ユーザー「satonaka」でログインしてみました。すると…

おや？こちらの想定では、ssoerror.jsp が表示されるはずなのですが、"403 Forbidden"が表示されてしまいました。
んー、一難去ってまた一難…。
AMAgent.properties には、確かに、

com.sun.identity.agents.config.login.error.uri[0] = /acmgr-wl/ssoerror.jsp
と設定しており、また、配備した acmgr-wl.war の web.xml でも 
         <form-error-page>/ssoerror.jsp</form-error-page>
と設定しているので、これで合ってる気がするのですが…。(/acmgr-wl/ssoerror.jsp ではなくて、/ssoerror.jsp で合ってるはず。)

ものはためしと、com.sun.identity.agents.config.login.error.uri[0] の値を空欄にしてみました。すると…

あら？不思議なことに、error.uri に何も指定しないと、期待通りに ssoerror.jsp の内容が表示されました。
これで合ってるんでしょうか？
でも、表示して欲しいファイルを指定すると、表示されず、何も指定しないと、それが表示される…なんかしっくりきませんね。
おそらく、最初の設定のどこかが違ってるんでしょうけど。。。
とりあえず、この点については、現在 U.S. に質問しているところですが、まだ回答はもらってません。
とりあえず、今は、上の値は空欄にした状態で、使用しています。(パートナーさんの環境でも)

9. ここまでのまとめ

とりあえず、authorized user がアクセスした際の挙動については、期待通りの動作をするように、セットアップすることができました。ポイントは以下の３つ。


unauthorized user がアクセスした際の挙動に関しては、まだ不明なことがあるので、引き続き U.S. からの回答待ち。このブログをご覧になった方で、何かご存じのことあれば、ぜひアドバイスお願いします。 m(_ _)m Posted by hanaki ( 3月 16日 2006年, 04:52:01 午後 JST ) Permalink 投稿されたコメント [0]