WebSphere Application Server も V4.0 になりましたし、ドミノも R5.0.9 になりました。以前 WAS が V3.5 でドミノが R5.0.6a の時に構成してみましたが、今回 WAS が V4.0.1 で、ドミノが R5.0.9 という状態で構成してみる機会がありました。
WAS が V4.0 になって、ドミノの HTTP タスクの使用の仕方や、新規インスタンスの作成、グローバル・セキュリティの設定などもこのサイトで実例での紹介をしていなかったので、今回それも含めてご紹介してみたいと思います。
また、必ず XML ファイルへのエクスポート機能などを使用して、うまくいった区切り区切りで構成のバックアップを取ってください。
ここでの話に限ったことではなく、ちょっと間違えたりすると取り返しがつかなくなっちゃたりしますので
．．．
ドミノと WebSphere をシングルサインオン構成で使用するには、まず WebSphere はドミノの HTTP サーバーにプラグインされている構成になっている必要があります。
構成のしかたについては、以前 WebSphere Application Server の導入のところで書きましたが、簡単におさらいしておきましょう。
まず最初に、ブラウザーからでかまわないので (もちろんノーツクライアントからでも OK です)、ドミノディレクトリを開きます。
サーバー・ビューから、WebSphere をプラグインする先のドミノサーバーを選択します。
[インターネット]タブで「DSAPIフィルタ名」に以下のように入力します。
すでに DOLS かなにかのプログラム名が入っていた場合は、改行してから次に追加してください。(この例も見えなくなっていますが、実はそうなっています)
次に notes.ini の設定です。前回はオペレーション･ナビゲーターからのやり方のご紹介だったので、今回は 5250 画面の例です。
EDTF /(サーバーのデータディレクトリ)/notes.ini か、WRKDOMSVR で該当サーバーのオプション13
(NOTES.INI の編集)で、次のような編集画面になります。
以下の例は、編集後ですが、この例の最後の行(WebSphereInit=/QIBM/UserData/WebASAdv4/default/config/plugin-cfg.xml)をそのまま入力し、F3キーを押して保管してください。
前回は Webサーバー管理ツールからの例でしたが、今回は
5250 画面からの例です。
ドミノのコンソールから、restart server コマンドでサーバーの再起動をかけてください。(もちろん、終了して、開始、でもかまいません)
「DSAPIフィルタ名」の指定が正しくない場合、また指定が正しくても notes.ini に "WebSphereInit= "以下の指定をしていなかったような場合、その指定が有効でないような場合、以下のようなエラーメッセージが出ます。当たり前ですが、正しく構成されていないので、もう一度「DSAPIフィルタ名」と notes.ini を確認してください。
snoop サーブレットか showCfg サーブレットなどで、ドミノのHTTPサーバー経由で WAS にアクセスできることは確認しておいてください。
showCfg サーブレットの例です。WAS の V4.0. であることなんかが確認できてますね。
どのドミノ・パーティションと WebSphere インスタンスが対応するか、はドミノのサーバー名/ポートと WebSphere の仮想ホストの一致で行われています。今回は、もとのデフォルトの管理インスタンスを停止し、新規インスタンスを作成しその仮想サーバーのデフォルトの構成である *:80 (すべてのサーバーアドレスのポート 80) を使用しているので、ドミノのHTTPサーバーのやはりデフォルトの指定と一致しています。そのため、特別に構成はしなくても使用できるようになっています。
WAS の複数インスタンスの作成の仕方は V4.0 になっても同じです。(V3.5 の例はこちらです)
複数インスタンスを同時に稼動させなくても、デフォルトの構成をそのまま使用するのはあまり好ましくありません。セキュリティの問題もありえますし、変更に変更を重ねてわけがわかんなくなってしまうと戻しようがありません。
導入後、デフォルトの環境でひととおりの稼動確認をすませたら、新しくインスタンスを作成して、必要な構成を追加していった方が確実です。(その度にバックアップするのは忘れずに!!)
本番環境でもテスト環境でも、デフォルトの構成はそのまま今後の稼動確認などのために取っておいて、新しい構成を作ってそれを使用するようにしてください。
QSH または STRQSH コマンドで Qshell 画面を出します。
カレントディレクトリを /QIBM/ProdData/WebASADV4/bin にしてください。(下の画面例で最初に実行されているコマンドです)
次に crtnewinst スクリプトで新しいインスタンスを作成します。
構文は以下のようになっています。
crtnewinst -instance <instance_name> -bootstrap <bootstrap_port>
-lsd <lsd_port>
[-job <job_name>] [-repository
<collection_name>] [-initconfigoff]
[-numretries
<number_of_retries>] [-owner <user_profile>] [-help]
たとえば以下のように指定します。
crtnewinst -instance R5EJB -bootstrap 905 -lsd 9005 -job R5EJBADMIN -repository R5EJSADMIN
R5EJBという名のインスタンスを作成し、ブートストラップのポート(管理コンソールが接続に使用するポート。デフォルトは900)に905、ネーミングサービスをルックアップしに行くポート(デフォルトは9000)に9005、起動された時のジョブ名をR5EJBADMIN、リポジトリをR5EJSADMIN(この過程で自動的に作成されますので、現在存在していない名前を使用)にそれぞれ指定しています。
-instance で指定したインスタンス名のサブディレクトリが /QIBM/UserData/WebASADV4/ の元に作成され、その下に各種プロパティファイル等が格納されるわけです。
2つめに実行されているのが、そのコマンドです。結果のメッセージが V3.5 の時にくらべてシンプルになっていますね。
strwasinst スクリプトでインスタンスを開始できます。
STRSBS QEJBADV4/QEJBADV4 で開始できるようにするのは、以前 V3.5 の時のご紹介したやり方で OK です。別途、独立したサブシステムで稼動させ、そのサブシステムの開始で WAS が開始されるようになるようにするやり方を後ほどご紹介してます。
WRKACTJOB コマンドで状況を確認します。
実際の管理サーバーのジョブのジョブログを参照して、「WEBSPHERE 管理サーバー R5EJBADMIN は作動可能です。」のメッセージを確認してください。
crtnewinst スクリプトの -bootstrap で指定したポート (ここでは 905) を指定して、管理クライアントを起動します。
ちゃんとアクセスできることを確認してください。
WebSphere 自体はデフォルトでは、ほとんどセキュリティはかかっていません。
管理クライアントはサーバー名とポート番号がわかれば、なんのチェックもなく全権で
WAS にアクセスできてしまいます。サーバー名なんてポートスキャンすればわかるし、ポートは変更していなければ
900 だというのは誰でも知っていることといっていいわけです。そこでやはり「デフォルトの構成の使用は好ましくない」ということになるわけです。
ここの一連の記事の目的である、ドミノと WebSphere とのシングルサインオン構成にももちろん必要ですが、いずれにしてもセキュリティはかける必要があるでしょう。
ドミノにそのセキュリティを認証してもらう構成をこれからご紹介します。
前提として、ドミノで LDAP タスクが稼動している必要があります。以下のようにコンソールかその他管理クライアントやWebサーバー管理などから
load ldap とコンソールコマンドを実行させてください。
これだけでドミノディレクトリが LDAP サーバーを通して使用できるようになります。
V5R1 のOS/400 はいらんことに、勝手に誰も使っていない LDAP サーバーを起動してしまうので、先立って ENDTCPSVR *DIRSRV で OS/400 の LDAP サーバーを止めて置いてください。ポートが競合している、というエラーが出ます。
WebSphere 管理コンソールから、以下のように「セキュリティー･センター」を選択してください。
出てきた「セキュリティー･センター」の画面で、「セキュリティーを使用可能にする」にチェックしてください。
「認証」タブに移って、以下の画面を参考に入力を行ってください。
認証メカニズムは「LTPA」にチェックします。
「単一サインオンを使用可能にする (SSO)」にチェックし、「ドメイン」にはシングルサインオンを共有したいドメインを指定してください。
「LDAP設定」では、まず「ディレクトリー･タイプ」で「Domino 5.0」を選択し、「ホスト」にはドミノサーバーのホスト名、「セキュリティー･サーバー ID」にドミノ・ディレクトリに存在するユーザーを cn=(ユーザー名), o=(組織名) の形で指定し、「セキュリティー･サーバー･パスワード」にはそのユーザーのインターネット･パスワードを指定します。
「適用」ボタンを押すと、LDAP サーバーにチェックを行ってくれます。(つまり、ドミノ上の LDAP タスクは稼動していないといけません)
「OK」ボタンを押すと、以下のようなメッセージが出てきます。
メッセージに「OK」を押して、ノードを再起動させてください。
管理サーバーのジョブのジョブログを参照して、「WEBSPHERE 管理サーバー R5EJBADMIN は作動可能です。」のメッセージを確認します。
管理クライアントを起動します。
ユーザー/パスワードの入力を促すダイアログ･ボックスが出てきます。
指定したユーザー名を、cn=(ユーザー名), o=(組織名) の形で入力し、インターネットパスワードを入力します。
ログインが成功すると、しばらくして以下のように管理コンソールが起動されます。
Web リソースを確認してみましょう。
snoop サーブレットをアクセスしてみましょう。
http://asdomino.test.com(ホスト名)/servlet/snoop と実行すると以下のようなダイアログ･ボックスが出てきます。
ユーザー名を、cn=(ユーザー名), o=(組織名) の形で入力し、インターネットパスワードを入力します。
ログインが成功すると snoop サーブレットの結果が表示されます。
ShowConfig サーブレットをアクセスしてみましょう。
http://asdomino.test.com(ホスト名)/webapp/examples/showCfg と実行すると以下のようなログイン画面が出てきます。
ユーザー名を、cn=(ユーザー名), o=(組織名) の形で入力し、インターネットパスワードを入力し、ログインが成功すると結果が出てきます。
これまで
と順を追って、それぞれチェックしながら設定を行ってきました。
ここでやっとシングルサインオンそのものの構成に入ります。
WebSphere 管理コンソールから、以下のように「セキュリティ･センター」を選択してください。
「認証」タブで「キーの生成」ボタンを押してください。
「LTPA パスワード」ダイアログボックスが出てきますので、何かパスワードを入力してください。
WebSphere 管理コンソールに、以下のように「コマンド"LTPAキーの生成"は正常に完了しました。」とメッセージが出てくれば OK です。
今度は「キーのエクスポート」ボタンを押してください。
「ファイルにエクスポート」ダイアログボックスが出てきます。
管理クライアントを実行しているローカルのディスクへの保管するためのダイアログ･ボックスです。適当なディレクトリに適当な名前で保管してください。
これからの作業はノーツクライアントです。
ノーツクライアントを使用して、ドミノディレクトリを開いてください。
「サーバー」ビューで、アクションバーから以下のように「Web SSO設定の作成」メニューを選択してください。
こんな画面になりますので、今度はアクションバーから「WebSphere LTPAキーの取り込み」メニューを選択します。
インポートするファイル名を聞いてきますので、WebSphere 管理クライアントで「キーのエクスポート」で保管したファイルを指定します。
LTPA キーのパスワードを聞いてきますので、WebSphere 管理クライアントで「キーの生成」の「LTPA パスワード」で指定したパスワードを入力します。
以下のような完了メッセージが出てきます。
自動的に「WebSphere関連情報」セクションができ、内容が入ります。
「参加するサーバー」セクションの「ドミノサーバー名」の横の三角マークを押すとアドレス帳が参照できます。サーバーを選択して、指定してください。
「トークンドメイン」にシングルサインオンを共有するドメインを入力します。WebSphere 管理クライアントの「セキュリティー･センター」の「認証」タブで「単一サインオンを使用可能にする (SSO)」の「ドメイン」に指定したものと同じになると思います。
「保存して閉じる」で、設定を保管して終了です。
「Web設定」ビューで以下のように「Web SSO設定先 LtpaToken」のように出てきます。
サーバー文書を開いて、編集モードにします。
[インターネット]タブの[Domino Web Engine]で、「セッション認証」を「複数サーバー」に変更します。
「保存して閉じる」で、変更を保管してサーバー文書を閉じます。
ということで、「Web SSOの設定」と「セッション認証」に変更を行った後、HTTP サーバーを再起動させます。
以下のように「HTTP: Successfully loaded Web SSO Configuration」というメッセージが出てくれば、設定は OK です。
ちゃんと動くかどうか、確認してみましょう。
http://asdomino.test.com/webapp/examples/showCfg をアクセスします。
自動的に redirect されて以下のようなログイン画面が出てきます。
ユーザーとパスワードをチェックした後、以下のように表示されます。
その画面のまま、ドミノディレクトリ (names.nsf) にアクセスしてみましょう。
何も言われずに (ログインを要求されることなく)、内容が表示されます。
いちいち QSH で strwasinst スクリプトを使用して、WAS を起動するのも面倒ではあります。
とりあえず、デフォルトの設定と同じように STRSBS で専用のサブシステムを開始させると、WAS も起動されるように設定してみましょう。
まず、ジョブ記述を複製して使用します。もとは QEJBADV4 ライブラリーの QEJBJOBD
というジョブ記述です。
CRTDUPOBJ コマンドか何かで複製を作ってください。
今度はその複製を変更します。「要求データ」というフィールド/プロパティがあるのですが、この値の一部を変更します。
CHGJOBD コマンドでの例です。先ほどのジョブ記述を指定した CHGJOBD コマンドで F4 キーを押すと、現在の値を検索して表示してくれます。
F10 キーを押して、次のページにすると「要求データ」というパラメータがあります。
このパラメータの中の一部の値でどのWebSphereインスタンスを起動させるかを
admin.properties の在り処を持って指定しています。
もともとは /QIBM/UserData/WebASADV4/default/properties/admin.properties になっていて、デフォルトの管理インスタンスが起動されるようになっていますが、このデフォルトを新規インスタンス作成時に指定したインスタンス名に変更してやります。
今度はサブシステムを複製します。
QEJBADV4 ライブラリーの QEJBADV4 サブシステムが複製元です。やはり CRTDUPOBJ
コマンドか何かで複製を行ってください。
複製したサブシステムの変更です。
変更は「自動開始ジョブ項目」に対して行います。
サブシステム記述に存在する「自動開始ジョブ項目」に"QEJBMNTR"が存在し、それと結びついているのがデフォルトサーバーが起動されるようになっているジョブ記述です。ジョブ名はそのままで、結び付けられているジョブ記述のみを先ほど複製して変更を行ったジョブ記述に変更します。
STRSBS コマンドで、このサブシステムを開始します。
以下のように指定したインスタンスのサーバーが起動されます。
|
|
