水曜日 8 26, 2009

最新の OpenSSO ビルドを使用する際の注意事項〜JDK1.6 以上を使うべし



先日、最新の OpenSSO のナイトリービルドの評価のために、
Glassfish に配備して、試しにポリシーエージェント3.0 をインストールしようと
したのですが、以下のようなエラーに遭遇してしまいました。

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: /etc/agentpass.txt

WARNING:
Unreachable Server URL :
http://my.test.domain.com:8080/opensso/identity/authenticate ,
OpenSSO server version may be lower than 8.0. Agent profile/user can not be
validated

どうやら、アイデンティティーサービスが正しく機能してない様子。
エージェントのログファイルには、以下のようなエラーが出てました。


server.log:java.lang.UnsupportedClassVersionError: PWC1651: Class com.sun.identity.idsvcs.IdentityServicesImpl has unsupported major or minor version numbers, which are greater than those found in the Java Runtime Environment version 1.5.0_15

んー、おかしいな??と色々調べてみたところ、
最新の(少なくとも、2009年6月中旬以降) OpenSSO は、
JDK1.6 とともに使用しないといけないみたいですね。

上記の環境では、Glassfish を JDK1.5_0_15 を使って動かしていたために、
不具合が起こっていたようです。
早速、最新の JDK1.6_16 をとってきて、
Glassfish の asenv.conf ファイルを


AS_JAVA="/usr/jdk/jdk1.6.0_16"

と置き換えて、Glassfish を再起動したところ、
ポリシーエージェントのインストールは正常に完了しました。

この注意事項は、OpenSSO ビルド8 のリリースノートに記載される予定です。

月曜日 5 11, 2009

OpenSSO 診断ツール

ナイトリービルドのダウンロードディレクトリにある
ssoExternalTools.zip を解凍すると、その中に、ssoDiagnosticTools.zip というファイルがあります。
このファイルの中にある ssodtool は、エージェントの設定内容が正しいかとか、OpenSSO を配備した web コンテナの JVM オプションやポリシーの設定に不備はないか、といったさまざまな観点から診断をしてくれる便利なツールです。

ツールを実行するには、Unix 環境では、ssodtool.sh を、Windows 環境では、ssodtool.bat を実行します。

すると、以下のようなウインドウが表示されます。

例えば、OpenSSO サーバーの設定の診断をするのであれば、左側で「Server」を選択し、「Server Configuration」を選択し、右側の Configuration Directory には、OpenSSO の設定ディレクトリ(例:/opensso)を指定します。
そして、「Run Selected」を実行すると、以下のように診断結果が表示されます。

例えば、エージェントの診断をするのであれば、左側で「Agents」を選択し、「J2EE Agent」を選択し、右側の Configuration Directory には、インストール済みのエージェントのインスタンスの設定ディレクトリを指定します。

例: /workspace/j2ee_agents/appserver_v9_agent/Agent_002/config

そして、「Run Selected」を実行すると、以下のように診断結果が表示されます。

ぜひ、この便利なツールを使ってみてください。
なお、現在、このツールのメッセージをローカライズしているところです。
日本語化が完了したら、またこのツールの各機能について紹介できればと思ってます。

月曜日 3 09, 2009

SLX にコンテンツを載せてみました

私は、時々、Sun Learning eXchange にアップされてるコンテンツを見て色々勉強することがあるのですが、
ビデオにおさめてアップするのはちょっと敷居が高いなぁ・・と思い、
自分で何かをアップするのは二の足を踏んでました。

でも、PDF 版なら、ブログで載せてたものを変換するだけで使えるし、
それなら自分でもできるかもと思い、ものは試しに
以前このブログで紹介したHow-To ものを SLX に載せてみました。

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

J2EE Agent 3.0 を用いて Weblogic に配備したサンプルアプリケーションをプロテクトする(Part2, 検証編)

どれくらいの人が見てくれてるかがわかる、という点でも SLX は有効なので、
他のネタも PDF 形式で SLX にアップしてみようと思います。
#いずれは、ビデオ版もアップできればいいかなとは思いますが・・・・

ブログで色々と技術情報をアップされてる方は、
ぜひ SLX も有効活用してみてはいかがでしょう?

火曜日 3 03, 2009

OpenSSO のログインページをカスタマイズする方法

OpenSSO のログインページをカスタマイズする方法について日本語で書いたドキュメントを
wikis.sun.com に掲載しました。

原文は、docs.sun.com に掲載されているオフィシャルガイド「Internationalizing the Sun OpenSSO Enterprise 8.0 Login Page」の wiki ページ版「Internationalizing the Sun OpenSSO Enterprise 8.0 Login Pageです。

なお、このカスタマイズガイドでは、ログインページのロゴを変えたり、ページに表示されるメッセージテキストを追加したり変更したりするといった、いわゆる「見た目」をカスタマイズする方法について説明しています。
機能の点から、ログインページを変更するといったことには触れていませんのでご注意ください。

例えば、こんな風にログインページをカスタマイズできますよ、ってことが書かれています。

土曜日 2 28, 2009

OpenSSO を用いた仮想フェデレーション(Virtual Federation)

今回は、SDN(Sun Developper Network)の記事の中から、Enabling Virtual Federation With OpenSSO, Part 1: Introduction に掲載されている、OpenSSO を用いてレガシーなアプリケーションの連携を、シンプルにかつ安全に行う仮想フェデレーション (Virtual Federation)技術について、原文の一部を翻訳しつつ紹介していきたいと思います。

課題


ここ最近では、アイデンティティー管理やアクセス管理を行う上で、「フェデレーション(連携)」が非常に重要なキーワードとなっていて、以下にあげるようなものがビジネス上のゴールとなってきています。
  • 複数のアプリケーションを外部のパートナー(のアプリケーションなど)と連携させる
  • 外部パートナーとの間でのユーザーデータの同期をより精度良く行う
  • セキュアな(技術的に安全な)状態を保ちながら連携を行い、ユーザーのプライバシーを保持する
  • 連携で相互運用性の利益を得る
  • 企業内のアイデンティティー情報と連携のインフラを集中管理する


多くの企業ではすでに、上記のゴールの達成を目指して、アイデンティティー管理や連携に関するプロジェクトに投資を行っていますが、技術的に解決しなければならない多くの課題に直面しています。
それらの課題はおおまかに次の2つに区分けすることができます。

  • 連携をサポートしていない既存の(レガシー)アプリケーションに対してセキュアに連携を行う 企業でアイデンティティー情報の連携を行う上では、Web ポータル、e-コマースのサイト、人事システムなど、既存のアプリケーションを連携することが必須となります。 それらのアプリケーションが商用の既製製品であるか、社内で構築したアプリケーションであるかにかかわらず、連携のためにはいくつかのインテグレーション作業(SOA 用語で言うところの first-mile や last-mile)が必要となります。 さらに、インテグレーションはセキュアに行わなくてはなりません。どのような企業でも外部のパートナーへユーザーのアイデンティティー情報を提供する際にはセキュリティとデータのプライバシーの保持を最優先とします。 それ以外にもまだまだやらなくてはいけないことは色々とあります。ユーザーのアイデンティティー情報をリモートのパートナーとどうデータ交換したり、同期をとったり、どのようにしてデータを複製(レプリケーション)するか、などです。
  • 外部パートナーに対して標準規格の連携で管理する 成熟度の高い組織では、相互運用性の利点について非常に敏感であり、次のようなものを採用する傾向にあります。
    • オープンな標準規格の連携技術 -- これを用いることで、1 つのベンダーのロックイン(占拠)を避けることができる。
    • スタンダードなインテグレーション技術 -- これを用いることで、連携を行おうと予定しているさまざまなアプリケーションに対して同じ技術を繰り返し適用することができる。
    しかしながら、標準規格を用いてアプリケーションをパートナーと連携させようとすると、すぐに管理コストが法外なものとなってしまいます。 多くの企業にとっての重要な問題は、いかにして集中化させたアイデンティティー管理のインフラを再利用させるかなのです。 要するに、我々にとっては集中管理型の連携ソリューションが必要となるわけです。

仮想フェデレーション〜上記課題へのソリューション提起

上であげた課題に対するソリューションとして、ここで提起するのが Sun OpenSSO Enterprise を用いた「仮想フェデレーション」技術です。

仮想フェデレーションでは、アイデンティティー情報(認証、プロファイル、トランザクション属性) を OpenSSO にセキュアにプッシュし、OpenSSO がそのデータを外部のパートナーへ標準の連携プロトコルを用いて伝搬することで、レガシーアプリケーションの連携を可能にします。

さらに、企業のアイデンティティーインフラ内で、OpenSSO を集中管理連携コンポーネントとし、その OpenSSO を用いて連携対象となるアプリケーションと外部のパートナーを一括管理することもできます。

利益


ハイレベルな観点では、仮想フェデレーションは非常にシンプルで、セキュアなメカニズムです。 SAML(Security Assertion Markup Language) 2.0 プロトコルを用いて、1 つのアプリケーションのアイデンティティー情報を別のドメインのアプリケーションへと伝送し、OpenSSO インスタンスを通してアプリケーションやサービスを外部パートナーと連携させることが容易にできます。
仮想フェデレーションでは、OpenSSO での認証処理と組み合わせることでアイデンティティー情報のセキュアな伝搬を実現します。アプリケーションに代わって、OpenSSO が、外部パートナーへのデータ転送の役目を担うわけです。
現在、仮想フェデレーションは以下のプロトコルに対してのみ動作しますが、将来的には他の連携プロトコルやプロファイルにも対応させる予定です。
  • SAML 2.0 browser-based transient federation and federated SSO
  • Browser-based HTTP GET and POST binding mechanisms of the SAML 2.0 protocol

仮想フェデレーションは次のような利益をもたらします:
  • 各アプリケーションを緩い結びつき(loosely coupled)で連携するので、従来の事前に設定済みのローカルリポジトリからデータを抽出するという手法と比べると、アイデンティティー連携の拡張性があります。
  • 1 つの OpenSSO インスタンスだけで複数のアプリケーションを連携することができます。
  • ローレベルでは、OpenSSO インスタンスは SAML 2.0 標準準拠プロトコルゲートウェイの役割を担います。OpenSSO によりユーザー認証が可能となり、SAML 2.0 を用いて安全にアイデンティティー情報を伝搬させることができるわけです。
  • 仮想フェデレーションは、わずかなクライアント API のみを要するライトウェイトな OpenSSO コンポーネントなので、元々フェデレーションに対応してないレガシーなアプリケーションやサービスを連携するためにインテグレーションに費やす労力を軽減させることができます。

仮想フェデレーション導入前後の比較

以下の表では、仮想フェデレーションを導入する前と後では、各課題への取り組みのシナリオがどう違ってくるかを示しています。
課題 仮想フェデレーション導入前 仮想フェデレーション導入後
レガシーアプリケーションを安全に連携する トラディショナルな手法を用いて、複雑で密結合(tightly coupled)な連携を実現する シンプルな連携とインテグレーション作業により、シンプルに、安全で疎結合な連携を実現する
連携したアプリケーションと連携のためのインフラを集中管理する アプリケーションごとに 1 つずつ、アプリケーションの数だけの連携ソリューションを配備する 連携管理のためにアイデンティティープロバイダ側とサービスプロバイダ側に OpenSSO インスタンスを 1 つずつ配備する
さまざまな企業内にある、ばらばらのデータリポジトリの間で、アイデンティティー情報(ユーザー属性、プロファイル、認可データ)の同期をとる リポジトリ間でアイデンティティー情報をやりとりするためにプロビジョニングツールや同期ツールを使う シンプルで安全で標準化されてる手法により、追加のアイデンティティー情報を使ってやりとりする。場合によっては、やりとりの際に使ったデータはアプリケーションから削除する
標準に準拠した相互運用性 専用の、拡張不可なテクノロジーとだけ動作可能な独自のソリューション SAML 2.0 による アイデンティティープロバイダとサービスプロバイダ間での標準準拠なインタラクション


Figure 1 に示すような仮想フェデレーションの例を考えてみます。



ある銀行の web アプリケーションは顧客のユーザー認証を行う役目を担っているアイデンティティープロバイダ(IdP)であり、外部のパートナーのアプリケーションと連携している。外部のパートナーのアプリケーションはサービスプロバイダ(SP)として小切手の処理を行い、適切な小切手画像をユーザーに提供する。

このシナリオの背後では次のようなプロセスが流れています。
  1. SAML 2.0 を用いて、IdP から SP へとトランザクションが伝搬される。トランザクションには、認証データ、アイデンティティーデータおよびトランザクションに関するデータが含まれている。
  2. まず最初にユーザーは、IdP に対してユーザー認証を行う。
  3. 認証されたユーザーが自分の所有する小切手の番号をクリックすると、銀行の IdP ポータルアプリケーション(以下、IdP)は小切手処理を行う SP アプリケーション(以下、SP)に対して小切手画像をリクエストする。
  4. ユーザーを識別・特定するために、IdP はアカウント番号 (ユーザー属性) と小切手の番号 (トランザクション属性) を SP に対してプッシュする。
  5. SP はユーザーの認証結果を確認した上で、IdP からの SAML 表明に含まれる属性(ペイロード)を受け取り、その表明の内容を全面的に信頼した上で、ユーザーに対して小切手画像データを送る。

仮想フェデレーション導入以前は、アカウントと小切手情報を IdP から SP へ渡すのには問題がありました。異なる企業に存在するリポジトリ間でのユーザーデータのプロビジョニングや同期の際に起こる問題に対処するケースが多々ありました。仮想フェデレーションの導入により、データ交換はシンプルで安全で標準化されます。

SAE(Secure Attribute Exchange)


仮想フェデレーションには SAE(Secure Attribute Exchange) と呼ばれるコンポーネントが含まれていて、次に示すように、SAE と OpenSSO によって first-mile と last-mile のインテグレーションをセキュアに行います。
  • セキュアな first-mile インテグレーション (IdP 側) — SAE は、アイデンティティー情報を連携対象となるアプリケーションから IdP の OpenSSO インスタンスへと注入します。そして、アイデンティティー情報は SAML 2.0 表明の属性ステートメントの中に埋め込まれて、IdP から SP へと伝達されます。
  • セキュアな last-mile インテグレーション (SP 側) - SAE のセキュリティメカニズムにより、SP の OpenSSO から連携対象となるアプリーケーションへデータを安全に転送します。どのような場合でも、SAE は共通鍵暗号法または公開鍵暗号法によりセキュリティを保証します。 このデータの流れを図解で示したのが Figure 2 になります。



    ここまで見てきたように、OpenSSO のシングルサインオン、SAML 2.0、SAE を組み合わせることで、レガシーアプリケーションの連携をシンプルに、安全に実現できます。
    Enabling Virtual Federation With OpenSSO, Part 2: A Tutorial では、OpenSSO 付属のサンプルプログラムを例に、実際にどのように設定するかの手順が説明されてるので、こちらの記事についても次回紹介したいと思います。

木曜日 2 26, 2009

OpenSSO でカスタマイズしたユーザー属性を作成して使用する方法

wikis.sun.com にある Creating Custom User Attributes in OpenSSOを元にして、
OpenSSO でカスタマイズしたユーザー属性を作成して使用する方法を書いてみました。

wikis.sun.com - OpenSSO でカスタマイズしたユーザー属性を作成して使用する方法
一応、実機(OpenSSO Enterprise 8.0 + embedded OpenDS + Glassfish U2V2)での結果を元にして書きましたが、もし手順や説明に間違いなどあればご指摘ください。

ここのところ話題の WBC にちなんだサンプルシナリオとなってます\^\^;
昨日、一昨日のオーストラリア戦は相手のレベルが低すぎて、
(1試合で6エラーはひどい・・・)
いまいち「強化試合」になったのかは疑問ですが、
(サインプレーもほとんど試してないし・・・・)
いよいよ来週からアジアラウンドが始まります。
2連覇への道は険しいでしょうが、がんばってほしいものです。

水曜日 2 25, 2009

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 エラーが出てエージェントが機能しなかったという経験を何度かしましたので。。。。

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

金曜日 2 20, 2009

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

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

11. 動作確認

セクション 9 で作成したユーザーを使って サンプルアプリケーションのいろんなリンクにアクセスして、 ポリシーが期待通りに動作するかどうかを確認してみます。
  1. ブラウザを立ち上げて、http://my.test.domain.com:7023/agentsample へアクセスします。
    次のような welcome ページが表示されるはずです。



  2. 左側の区画から、"J2EE Declarative Security" をクリックします。 次のようなページが表示されるはずです。



  3. 右側の区画に、2 つのリンクが表示されてるので、まずは "Invoke the Protected Servlet" をクリックしてみます。
    すぐ上に説明が書かれてるように、このリンクにアクセスできるのは、manager グループに属するメンバーだけです。
  4. リンクをクリックすると、OpenSSO のログインページにリダイレクトされます。
    ここで、chris でログインしてみます。
    chris は、manager グループのメンバーなので、アクセスが許可されるはずです。



  5. ログインしてみると・・・・・



    このように、アクセスに成功したことを示すページが表示されます。
  6. "J2EE Declarative Security" のリンクをクリックします。



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



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



  9. 上の "Invoke Security Aware Servlet" をクリックしてみます。



    このように、現在ログインしているユーザーが chris であり、manager と employee グループのメンバーであることを示すメッセージが表示されます。
  10. 次に、左の区画から "URL Policy Enforcement" をクリックします。



  11. "Invoke a Servlet Protected by URL Policy" をクリックしてみます。
    説明されてるように、このリンクにアクセスできるのは、customer グループのメンバーだけです。
    chris は、customer グループのメンバーですからアクセスに成功するはずです。
    実際にアクセスしてみると・・・・



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

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



今度はユーザー andy で試してみます。
  1. 左側の区画から、"J2EE Declarative Security" をクリックします。
  2. "Invoke the Protected Servlet" をクリックします。
  3. OpenSSO のログインページが表示されたら、andy でログインします。
    andy も manager グループのメンバーなのでアクセスに成功するはずです。



  4. 次に、左の区画から "URL Policy Enforcement" をクリックします。
  5. "Invoke a Servlet Protected by URL Policy" をクリックします。
    andy は、customer グループのメンバーではないのでアクセスが拒否されるはずです。
    実際にクリックしてみると・・・・



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

この結果からも、ポリシーが期待通りに動作していることが確認できます。
http://my.test.domain.com:7023/agentsample/logout にアクセスしてログアウト処理を行ったあと、今度は employee グループにのみ属している frank で試してみます。
  1. 左側の区画から、"J2EE Declarative Security" をクリックします。
  2. "Invoke the Protected Servlet" をクリックします。
  3. OpenSSO のログインページが表示されたら、frank でログインします。
    frank は、manager グループのメンバーではないので、アクセスが拒否されます。



  4. 左側の区画で、"J2EE Declarative Security" のリンクをクリックします。
  5. 今度は、"Invoke the Protected EJB via an Unprotected Servlet" をクリックしてみます。
    frank は、employee グループのメンバーなので、今度はアクセスに成功します。



  6. 次に、左の区画から "URL Policy Enforcement" をクリックします。
  7. "Invoke a Servlet Protected by URL Policy" をクリックします。
    frank は、customer グループのメンバーではないのでアクセスが拒否されるはずです。
    実際にクリックしてみると・・・・



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

最後に、everyone グループにのみ属している gina で試してみます。 (その前に、http://my.test.domain.com:7023/agentsample/logout へアクセスしてログアウトしておきます。)
  1. 左側の区画から、"J2EE Declarative Security" をクリックします。
  2. "Invoke the Protected EJB via an Unprotected Servlet" をクリックしてみます。
  3. OpenSSO のログインページが表示されたら gina でログインしてみます。
    これまで試したユーザーと違って、gina は、employee グループのメンバーではないので、アクセスが拒否されるはずです。
    実際に試してみると・・・



    このように、アクセスが拒否されたことを示すページが表示されます。
  4. gina は、"J2EE Security API" のページにある 2 つのリンクに対してもアクセス拒否されます。
    また、"URL Policy Enforcement" ページにある "Invoke a Servlet Protected by URL Policy" をクリックした場合もアクセス拒否されます。
このように、いくつかのユーザーを使って、サンプルアプリケーション上のさまざまなページにアクセスし、ポリシーによるアクセスコントロールが期待通りに動作しているかを確認しました。
今回試さなかった、他のユーザーについても同じように期待通りの結果が得られることを確認してみてください。
また、新しいユーザーを作成して、グループに追加してみたり、既存のユーザーをグループから削除した場合にも、ポリシーが期待通りに動作するかどうかも試してみてください。

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

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

使用するソフトウェア

前提条件

  • 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 コンソール上でエージェントのプロファイルを作成します。
  1. http://my.test.domain.com:48080/opensso80 にアクセスして、amadmin でログインします。
  2. デフォルトでは「共通タスク」のページが表示されるので、「アクセス制御」タブをクリックします。
  3. レルムの一覧ページが表示されますので、"/ (最上位のレルム)" をクリックします。
  4. レルムのプロパティーページが表示されるので、「エージェント」タブをクリックします。
  5. エージェントのページが表示されるので、「J2EE」タブをクリックします。



  6. エージェントセクションで「新規」ボタンをクリックします。
  7. エージェントのプロファイルを作成します。ここでは、次のように入力します。
    • 名前:weblogic
    • パスワード: password
    • 設定: 集中を選択(デフォルトのまま)
    • サーバー URL: http://my.test.domain.com:48080/opensso80
    • エージェント URL: http://my.test.domain.com:7023/agentapp




  8. 入力が終わったら、「作成」ボタンをクリックして、プロファイルを作成します。

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

  1. ダウンロードした weblogic_v10_agent_3.zip を解凍し、 j2ee_agents/weblogic_v10_agent/bin ディレクトリに移動します。
  2. agentadmin を実行可能にします。
    
    # chmod a+x agentadmin
    
    
  3. 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
    
    
  4. インストールが成功したことを確認したら、次のステップに進みます。

3. startWebLogic.sh を編集する。

J2EE Agent のインストールが完了すると、/opt/bea/user_projects/domains/domain2 ディレクトリに、setAgentEnv_AdminServer.sh が作られています。
このファイルには、J2EE Agent を使用するのに必要な CLASSPATH や JAVA_OPTIONS が定義されているので、
Weblogic の起動時に、このファイルを読み込むように、startWebLogic.sh を編集する必要があります。
  1. /opt/bea/user_projects/domains/domain2/bin ディレクトリに移動し、テキストエディタで startWebLogic.sh を開きます。
  2. ". ${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
    
  3. ファイルを保存して、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 のコンソール画面で、次の手順を実行します。
  1. 左の区画で、Security Realms をクリックします。



  2. 右の区画で、myrealm をクリックします。



  3. 右の区画で、Providers タブをクリックします。



  4. 右の区画で、New ボタンをクリックします。



  5. Name フィールドに適当な名前を入力します。ここでは、agenttest とします。
    Type のリストから、AgentAuthenticator を選び、「OK」ボタンをクリックします。



  6. Authentication Providers の一覧から DefaultAuthenticator をクリックします。



  7. Control Flag の値を OPTIONAL に変更し、「Save」ボタンをクリックします。



  8. Weblogic サーバーを再起動して、変更内容を反映させます。

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

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



  8. 「保存」ボタンをクリックして、変更内容を反映させます。

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

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



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

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

次に、先ほど配備したサンプルアプリケーションのプロテクトが正しく行えるように、 エージェントのプロファイルにいくつかプロパティーを設定します。
  1. エージェントのプロファイル weblogic をクリックして、編集ページを表示します。
  2. 「アプリケーション」タブをクリックします。
  3. 「ログイン処理」のセクションで、「ログインフォーム URI」の新しい値に /agentsample/authentication/login.html を入力し、「追加」ボタンをクリックします。



  4. 「ログアウト処理」のセクションで、「アプリケーションログアウト URI」の新しい値のマップキーに、agentsample を、
    対応するマップ値に、/agentsample/logout を入力し、「追加」ボタンをクリックします。



  5. 「アクセス拒否 URI 処理」のセクションで、「リソースアクセス拒否 URI」の新しい値の マップキーに、agentsample を、
    対応するマップ値に、/agentsample/authentication/accessdenied.html を入力し、「追加」ボタンをクリックします。



  6. 「適用されない URI 処理」のセクションで、「適用されない URI」の新しい値に 次の URI を 1 つずつ入力し、その都度「追加」ボタンをクリックします。
    • /agentsample/public/\*
    • /agentsample/images/\*
    • /agentsample/styles/\*
    • /agentsample/index.html
    • /agentsample




  7. 「特権属性処理」セクションで、「特権属性マッピング」の「マップキー」と「対応するマップ値」に
    次の値を入力し、その都度「追加」ボタンをクリックします。
    これにより、あとで 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




  8. 入力が終わったら、編集内容を反映させるために「保存」ボタンをクリックします。
  9. 保存が完了したら、「メインページに戻る」ボタンをクリックして、エージェントの一覧ページに戻ります。

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 人をグループのメンバーにするには、次の手順で行います。
  1. 「対象」をクリックし、「グループ」タブをクリックします。
  2. 「新規」ボタンをクリックし、新しいグループページで、ID フィールドに manager と記入し、「了解」ボタンをクリックします。
  3. グループの一覧ページに戻るので、manager のリンクをクリックします。
  4. 「ユーザー」タブをクリックして、「選択可能」ボックスから、andy、bob、chris の 3 人を選択して、「追加」ボタンをクリックします。



  5. 「保存」をクリックします。
この手順を他のグループについても同様に行います。

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 は次のような手順で作成します。
  1. "/ (最上位のレルム)" のリンクをクリックして、「ポリシー」タブをクリックします。
  2. 「新規ポリシー」ボタンをクリックします。
  3. 新規ポリシーページで、名前の欄に適当な値を入力します。ここでは、policy1 とします。
    注: OpenSSO Enterprise 8.0 では、ポリシー名に日本語を使うとポリシーがうまく動作しません。
    この問題は、課題4440で登録されていて、2009/02/14 の時点で修正されたため、それ以降にビルドされた OpenSSO では、ポリシー名に日本語を使えます。
  4. 次にルールセクションで、「新規」ボタンをクリックします。
  5. 「ルールのサービスタイプを選択」ページでは、「サービスタイプ」として「URL ポリシーエージェント」がデフォルトで選択されているので、そのままの状態で「次へ」をクリックします。
  6. 新規ルールのステップ 2 のページで、保護したい URL に関するルールを定義します。
  7. まず、名前を入力しますが、これはどのような名前でも構いません。ここでは、「JSP ページ」と入力します。
  8. 次に、プロテクトする URL のパターンを入力します。
    「リソース名」フィールドに、http://my.test.domain.com:7023/agentsample/jsp/\* と入力します。
  9. 「アクション」のところで、GET と POST の両方のチェックボックスをクリックします。



  10. 「終了」ボタンをクリックします。
  11. 他の 4 つの URL についても手順 4 〜 9 を繰り返します。
  12. 5 つの URL についてルールの作成を終えたら、これらの URL パターンに対してアクセスを許可する対象を定義する必要があります。
    対象セクションで、「新規」ボタンをクリックします。
  13. 「ステップ 1/2: 対象タイプを選択」ページで、「認証済みユーザー」を選択し、「次へ」ボタンをクリックします。
  14. 「ステップ 2/2: 対象タイプを選択」ページで、 名前フィールドに「認証済みユーザー」と入力し、「終了」ボタンをクリックします。
  15. これで、policy1 の設定が完了したので、最後に新規ポリシーページで「了解」ボタンをクリックします。
policy2 についても policy1 と概ね同じ手順で行いますが、以下の箇所については異なります。
  1. 新規ルールのステップ 2 のページで、「リソース名」フィールドに http://my.test.domain.com:7023/agentsample/urlpolicyservlet と入力します。
  2. 「ステップ 1/2: 対象タイプを選択」ページで、「OpenSSO アイデンティティー対象」を選択し、「次へ」ボタンをクリックします。
  3. 「ステップ 2/2: 新規対象 - OpenSSO アイデンティティー対象」ページで、名前フィールドに適当な値を入れます。
  4. フィルタで、「グループ」を選択し、その横の「検索」ボタンをクリックします。
  5. 「選択可能」ボックスに、既存のグループが表示されるので、customer を選んで、「追加」ボタンをクリックします。
2 つの URL ポリシーの作成が完了すると、次のような画面になっているはずです。



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

金曜日 1 23, 2009

OpenSSO FAQ center 日本語版

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

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

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

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

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

火曜日 1 20, 2009

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

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

日曜日 1 18, 2009

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 とポリシーエージェントに関するスターティングガイド

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

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

木曜日 1 08, 2009

The Globosso 始めました

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

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

水曜日 1 07, 2009

J2EE Agent 2.2 の設定手順例


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

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


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


  1. machineA 上で、Access Manager にログインし、エージェントプロファイルを作成。

    名前:agent
    パスワード:password

  2. machineB 上で、あとで行うエージェントのインストール用に、パスワードファイルを作成。

    # echo "password" > /tmp/passwd.txt

  3. 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

  4. エージェントのインストールがおわったら、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


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

    リソース:http://machineB/community/\*
    対象:Access Manager アイデンティティー対象 グループ「allowedusers」

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

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

金曜日 12 19, 2008

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

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

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

  • マシン1:machine1.example.com
    • Glassfish V3 がインストール済み。(ポート 8080)
    • ここに OpenSSO を配備する。
  • マシン2:machine2.example.com
    • Web Server 7.0 がインストール済み。(ポート 80)
    • Web Agent 3.0 をインストールし、この web server をプロテクトする。
  1. こちら から、OpenSSO 8.0 をダウンロードし、こちら から、Web Agent 3.0 for Webserver 7 for Solaris Sparc をダウンロードします。
  2. マシン1 上で、OpenSSO 8.0 を配備します。 (今回はエージェントの設定がメインなので、OpenSSO の設定手順は省略します。)
  3. マシン2 上で、sjsws_v70_SunOS_sparc_agent_3.zip を解凍します。
  4. web_agents/sjsws_agent/bin/ ディレクトリに移動し、 agentadmin を実行可能にします。
    
       #chmod 755 agentadmin
    
    
  5. マシン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
    
    
  6. マシン2 の Web Server を再起動します。
    再起動後に、http://machine2.example.com にアクセスしてみると、
    エージェントによりプロテクトされているために、Web Server のトップぺージは表示されません。



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

    次に、本稿での本題である、ssoadm コマンドを用いての エージェントの作成を行います。
  7. マシン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
    
    
  8. 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 の下に置かれます。)
  9. sso コマンドのあるディレクトリに移動します。
    このディレクトリに、マシン 2 でエージェントをインストールしたときに生成された OpenSSOAgentConfiguration.properties をコピーします。
  10. OpenSSOAgentConfiguration.properties を編集し、最後に以下の行を加えます。
    
    userpassword=エージェントのパスワード(/export/agentpw.txt に書いた値)
    
    
    必要に応じて、ファイル内の他の属性の値を変更、もしくは値が入ってない箇所について値を入れます。
    そして、最終的に値を入れていない行については、削除します。
    注意:値がセットされていない行を残したままだと、次の手順で ssoadm の操作が失敗するかもしれません。(実際に、私が試した場合は、以下の行に値が入ってない状態だとエラーになりました。)
    
    com.sun.identity.agents.config.debug.level =
    com.sun.identity.agents.config.auth.connection.timeout =
    
    
  11. 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 を再起動してください。
  12. マシン2 で Web Server を再起動し、http://machine2.example.com/ にアクセスします。
    今度は、マシン1の OpenSSO のログインページ (http://machine1.example.com:8080/opensso) にリダイレクトされるはずです。



    ここまで来ればもう一息。残る作業は、OpenSSO 上でのポリシーの定義です。
  13. (ポリシー定義についての細かい手順についての説明はここでは省きます。)
    今回、定義したポリシーは次のとおりです。
    
    ルール:
     サービスタイプ: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

About

hanaki

Search

Archives
« 4月 2014
  
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
   
       
今日