V4エージェントを使うべきか

2016年の4月にバージョン4.0.0のWebエージェントがリリースされました。以前のバージョンにあったいくつかの問題に対応するため、一から実装し直しています。

リリースノートにかかれている主な新機能は以下の通りです:

  • IISのマルチサイト構成のサポート
    IISエージェントV4は、IISのマルチサイト構成に対応し、サイト毎に独自のエージェント設定が可能になっています。
  • Apacheのバーチャルホストのサポート
    ApacheエージェントV4は、Apache Webサーバー上の複数のバーチャルホストにエージェントをインストールすることができ、仮想ホスト毎に独自のエージェントの設定が可能です。
  • 権限の自動付与
    Webサーバーの実行ユーザーが書き込む必要のあるフォルダに、権限を自動的に付与することができます。
  • カスタマイズ可能な暗号化設定
    エージェントとOpenAM間の通信の暗号化の方式を詳細に設定できます。

この他に地味にうれしいのが、Javaのインストールが必要無くなったということです。以前のバージョンは、なぜかエージェントのセットアップツールがJavaで実装されていて、それだけのためのJavaをインストールしなければいけなかったのですが、これが不要になっています。

また、–s オプションでサイレントインストールがより簡単にできるようになっています。

$ ./agentadmin --acceptLicence --changeOwner --s \
  /etc/httpd/conf/httpd.conf \
  http://openam.example.co.jp:8080/openam \
  http://app.example.co.jp:80/ \
  webagent1 \
  pwd.txt

・・・

Installation complete.

ということで、今すぐアップグレードしてバージョン4.0.0のWebエージェントを使うべきか、というとまだ現時点ではお勧めはできません(ForgeRock社のサブスクリプションを購入していない場合は)。実際に動かしてみたのですが、いくつかの(致命的とも言えそうな)問題が見つかりました。JIRAを見る限り、バグも多く上がっています。動作が安定するまでまだ時間がかかるのかなぁと思っています。

 

(…とまで書いて、このブログ記事を公開するのを忘れていました…そして数ヶ月後…)2016年の12月にWebエージェント 4.1.0がリリースされました。

Webエージェント 4.1.0リリース

新しい4.1.0はどのような変更があったかというと、ここに書かれている通りです。いくつかのエンハンスがされていますが、それほど大きなものではないように思います。ただし、このバージョンで修正したバグは、リリースノートに載っているだけでも78件あります。これらの中には「メモリリーク」、「リダイレクトループ」、「クラッシュ」などの用語が見られるので、やはり4.0.0は本番環境で使用するのは避けるべきという判断は正しかったと思います。4.1.0になり、バグが大量に修正され動作は大分安定するようになったと予想しますが、まだ3.3.xなどのバージョンの方が安定しているかもしれません。

 

OpenAMの新しい監査ログについて (2)

前回は、OpenAM 13.0.0で刷新された監査ログの概要について説明しました。最新のOpenAMでは、監査ログをCSVファイルに出力したり、SyslogやElasticSearchなどへの転送ができるようになっています。詳細については以下のページを参照下さい。

OpenAMの新しい監査ログについて (1)

今回はそれらの機能の一つであるJDBC監査ロギングについて書きます。JDBC監査ロギングは、OracleやMySQLなどのRDBMSに、OpenAMの監査ログを登録(INSERT)する機能です。

まず最初に言っておくと、このJDBC監査ロギングはOpenAM 13.0.0ではまともに動作しません…(新規に開発した機能は、最初のリリースでの動作が安定しないことがありますが、この機能はちょっと酷過ぎました…)。したがって、JDBC監査ロギングを利用する場合は、13.5.0以降(14.0.0のナイトリービルド)を使うか、いくつかのバグのパッチ(以下)を適用する必要があります。

設定手順

ここでは、MySQLに監査ログを登録する設定をします。おおまかな設定手順は、以下の通りです。

  1. JDBCドライバーをlibディレクトリにコピーする
  2. MySQLに、OpenAMの監査ログ用のテーブルを作成する
  3. OpenAMの管理コンソールで監査ログの設定を追加する

もう少し詳しく説明します。

※なお、MySQLのインストールや初期設定はしてあるものとします(省略します)。

手順1. JDBCドライバーをlibディレクトリにコピーする

JDBCドライバーを次のページからダウンロードしてきます。

https://dev.mysql.com/downloads/connector/j/

ダウンロードしたら、TomcatかOpenAMのlibディレクトリにコピーして下さい。

$ cp mysql-connector-java-5.1.38-bin.jar /usr/share/tomcat7/lib/

手順2. MySQLに、OpenAMの監査ログ用のテーブルを作成する

次に、MySQLにOpenAMの監査ログ用のデータベースを作成し、適当なユーザーでOpenAMからアクセスできるようにします。

$ mysql -u root -p 
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.1.73 Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE audit;
Query OK, 1 row affected (0.22 sec)

mysql> GRANT ALL PRIVILEGES ON audit.* TO root@'192.168.1.0/255.255.255.0' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.04 sec)

mysql> select user,host,password from mysql.user; 
+------+---------------------------+-------------------------------------------+
| user | host                      | password                                  |
+------+---------------------------+-------------------------------------------+
| root | localhost                 | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
| root | openam02.example.co.jp    | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
| root | 127.0.0.1                 | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
| root | 192.168.1.0/255.255.255.0 | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
+------+---------------------------+-------------------------------------------+
4 rows in set (0.03 sec)

完了したら、OpenAMのwarファイルの中にあるaudit.sqlを実行して、監査ログ用のテーブルを作成します。

mysql> source /var/lib/tomcat7/webapps/openam/WEB-INF/template/sql/mysql/audit.sql
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 1 row affected, 1 warning (0.00 sec)
Database changed
Query OK, 0 rows affected (0.09 sec)
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

mysql> exit

手順3. OpenAMの管理コンソールで監査ログの設定を追加する

管理コンソールの 設定 > グローバル > 監査ロギング で、監査イベントハンドラのセクションの「新規」ボタンをクリックし「JDBC」を選択すると、JDBC用の監査ログを制御するハンドラが追加されます。

auditjdbcsettings1

「データベースの種類」はMySQLを選択し、「JDBCドライバー URL」から「データべースパスワード(確認)」までの項目に適切な値を入力して下さい。

auditjdbcsettings2

設定に問題がなければ、以下のように監査ログが4つのテーブルに登録されます。

audittables

大量の監査ログを捌くための仕組み

監査ログの設定後、OpenAMのログインや設定変更、ログアウトなどを行ってみると、あっという間にたくさんの監査ログレコードが登録されているのが分かります。実際の運用となり、ユーザー数が多くなると、さらに大量に登録されることになります。大量なログの高速な登録を実現するために、OpenAMは以下のような仕組みを実装しています。

afw4

ポイントとなるのは、以下の技術です。

  • 監査イベントバッファリング
  • ライタースレッド
  • ExecuteBatch()
  • HikariCP

ユーザーがOpenAMにログインしたり、自身の情報を更新すると、監査イベント(ログデータ)は、バッファ変数に一時的に保存されます(監査イベントバッファリング)。このログデータは監査ログINSERT用のSQLのプリペアドステートメントに結びつけられて、ライタースレッドによりexecuteBatch()メソッドで複数件まとめてデータベースに登録されます。

この時、データベースへのアクセスに使用しているコネクションプールのライブラリには、Commons DBCPやC3P0ではなく、HikariCPというものが使用されています。HikariCPは、軽量なJDBCコネクションプールのライブラリで、高速な処理性能を持っていることが特徴です。ただし、それだけではなく、シンプルな実装であるがゆえに信頼性や安定性も高いようです。

hikaricp-bench-2-4-0

HikariCPについて興味がある方は、以下を参照してみて下さい。

https://github.com/brettwooldridge/HikariCP

Java EEエージェントのビルド

Java EEエージェントのビルドもOpenAMサーバーと同様にmvnコマンドを実行するだけで完了します。

ビルド環境の整備

ビルドに必要なソフトウェアは、JDKとMavenです。前提ソフトウェアのバージョンについて、公式な情報は公開されていませんが、OpenAMのビルドができるバージョンを使えば問題はないはずです。

Java JDK Maven
1.7 以上 3.1.0 以上

ただし、1つ注意すべき点があります。WebSphere ASとWebLogic Server用のエージェントのビルドには、サーバーベンダーが提供する非公開のライブラリが必要です。これらの依存関係を解決するには、各サーバーソフ トウェアに含まれるライブラリを取得し、mvnコマンド実行時に参照できるようにしておく必要があります。詳細に関しては、Java EEエージェントのソースコードに添付されているreadme.mdファイルを参照してください。

手順. Java EEエージェントのビルド

まずは、ビルド用のディレクトリを作成し、そこに移動します。

$ mkdir jeeagent_build
$ cd jeeagent_build/

ソースコードはForgeRock社のBitbucketサーバー上で公開されています。ここでは、バージョン3.5.0のソースコードを圧縮したファイルをダウンロードします。

https://stash.forgerock.org/projects/OPENAM/repos/jee-agents/browse?at=refs%2Ftags%2F3.5.0

ダウンロードが完了したら、圧縮ファイルを解凍してください。

$ unzip jee-agents-master\@36016b991ff.zip 
Archive:  jee-agents-master@36016b991ff.zip
36016b991ff2aeb694a5d09e062591704f9eec45
 extracting: .gitignore              
   creating: jee-agents-agentapp/
  inflating: jee-agents-agentapp/pom.xml  

  .......

  inflating: pom.xml                 
  inflating: readme.md

解凍したら圧縮ファイルは削除します。

$ rm jee-agents-master\@36016b991ff.zip 
rm: remove 通常ファイル `jee-agents-master@36016b991ff.zip'? yes

ディレクトリ構成は、以下のようになっています。各サーバー毎のエージェントモジュールやサンプルアプリケーション(sampleapp)用のモジュールが、ディレクトリ毎に分かれて配置されています。

$ ll
合計 1828
drwxr-xr-x  3 root root    4096  9月 16 23:26 2016 jee-agents-agentapp
drwxr-xr-x  4 root root    4096  9月 16 23:26 2016 jee-agents-appserver
drwxr-xr-x 12 root root    4096  9月 16 23:26 2016 jee-agents-distribution
drwxr-xr-x  5 root root    4096  9月 16 23:26 2016 jee-agents-jboss
drwxr-xr-x  4 root root    4096  9月 16 23:26 2016 jee-agents-jetty
drwxr-xr-x  3 root root    4096  9月 16 23:26 2016 jee-agents-jsr196
drwxr-xr-x  3 root root    4096  9月 16 23:26 2016 jee-agents-library
drwxr-xr-x 15 root root    4096  9月 16 23:26 2016 jee-agents-sampleapp
drwxr-xr-x  3 root root    4096  9月 16 23:26 2016 jee-agents-sdk
drwxr-xr-x  3 root root    4096  9月 16 23:26 2016 jee-agents-tomcat
drwxr-xr-x  3 root root    4096  9月 16 23:26 2016 jee-agents-weblogic
drwxr-xr-x  4 root root    4096  9月 16 23:26 2016 jee-agents-websphere
drwxr-xr-x  2 root root    4096  9月 16 23:26 2016 legal
-rwxr-xr-x  1 root root   33221  9月 16 23:26 2016 pom.xml
-rw-r--r--  1 root root    2097  9月 16 23:26 2016 readme.md
$

全体のpom.xmlがあるので、ここでmvnコマンドを実行すれば、ビルドが開始されますが、前述した商用のサーバーのライブラリが存在しないの で、ビルドエラーとなってしまいます。Tomcatエージェントだけをビルドしたいということでれば、以下のようにpom.xmlを編集し、Tomcat以外のサーバー用のmoduleタグをコメントアウトすればビルドできるようになります。

    <modules>
        <module>jee-agents-sdk</module>
        <module>jee-agents-library</module>
        <module>jee-agents-agentapp</module>
        <module>jee-agents-tomcat</module>
<!-- ここから
        <module>jee-agents-jboss</module>
        <module>jee-agents-jetty</module>
        <module>jee-agents-appserver</module>
        <module>jee-agents-weblogic</module>
        <module>jee-agents-websphere</module>
        <module>jee-agents-jsr196</module>
ここまでコメントアウト -->
        <module>jee-agents-sampleapp</module>
        <module>jee-agents-distribution</module>
    </modules>

mvn clean installコマンドでビルドを実行します。テストを省略する場合は、-DskipTests=trueオプションを付加してください。

$ mvn -DskipTests=true clean install
[INFO] Scanning for projects...
[WARNING] 

  .......

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:00.510s
[INFO] Finished at: Sun Sep 25 09:42:15 JST 2016
[INFO] Final Memory: 64M/349M
[INFO] ------------------------------------------------------------------------

数分で、ビルドは完了します。jee-agents-distribution/jee-agents-distribution-tomcat- v6/target/以下に、Tomcatエージェントの圧縮ファイル(tomcat_v6_agent_4.0.0-SNAPSHOT.zip)が作成 されているはずです。

$ ll jee-agents-distribution/jee-agents-distribution-tomcat-v6/target/
合計 33888
drwxr-xr-x 2 root root     4096  9月 25 09:41 2016 archive-tmp
-rw-r--r-- 1 root root       27  9月 25 09:41 2016 build_date.js
-rw-r--r-- 1 root root 34692736  9月 25 09:41 2016 tomcat_v6_agent_4.0.0-SNAPSHOT.zip

OpenAMをビルドする

 OpenAMのビルドはとても簡単です。基本的には、OpenAMのソースコードをダウンロードして、Mavenのコマンドを実行するだけです。ただし、注意すべき点がいくつかあります。

注意点

  • OpenAMと、Java、Maven、Gitのバージョンを確認すること
  • Windows上でのビルドは失敗する可能性があるので、LinuxかMac上で実施すること
  • ビルドするだけであれば、-DskipTests=trueオプションを付けること(テストはスキップする)

ビルド環境の整備

 OpenAM 11.0.0以降のビルドに必要なソフトウェアは、JDK、Maven、Gitですが、OpenAMのバージョンによって若干異なります。

OpenAM Java JDK Maven Git
OpenAM 13.0.0 1.7 以上 3.1.0 以上 1.7.6 以上
OpenAM 12.0.0 1.6 以上 3.3.1 以下 1.7.6 以上
OpenAM 11.0.0 1.6 または 1.7 3.0.5 1.7.6 以上

Mavenのビルドコマンドを実行する前に、これらのバージョンを確認しておきましょう。

$ mvn -version
Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28 11:15:32+0900)
Maven home: /opt/apache-maven-3.1.0
Java version: 1.7.0_101, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101.x86_64/jre
Default locale: ja_JP, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-642.el6.x86_64", arch: "amd64", family: "unix"

$ git --version
git version 2.2.0

参考までに、今回使った環境は以下の通りです。

  • CentOS 6.8
  • OpenJDK 1.7.0.101
  • Apache Maven 3.1.0
  • Git 2.2.0

ソースコードの取得

 ソースコードはForgeRock社のBitbucketサーバーからgit cloneで取得してくることもできますが、アカウントをつくってログインしないといけないので、GitHubからダウンロードします。ダウンロードしたら、解凍して出来たディレクトリに移動して下さい。

$ wget --no-check-certificate https://github.com/ForgeRock/openam/archive/13.0.0.zip
$ unzip 13.0.0.zip
$ cd openam-13.0.0

Mavenによるビルド

 以下のコマンドを実行すると、ビルドが始まります。

$ export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m"
$ mvn -DskipTests=true clean install

マシンの性能によりますが、30分くらいはかかると思います。完了すると、openam-server/target/にOpenAM-13.0.0.warが作成されます。

非公式日本語版OpenAMのビルド

 次のページにも書きましたが、私がつくった非公式日本語版OpenAMも簡単にビルドできます。

https://github.com/k-tamura/openam1300-japanese-properties/blob/master/README.jp.md

Java、Maven、Gitがインストールされていれば、以下のコマンドを実行するだけです。

$ wget --no-check-certificate https://raw.githubusercontent.com/k-tamura/openam1300-japanese-properties/master/build-openam-jp.sh
$ chmod +x build-openam-jp.sh
$ ./build-openam-jp.sh

※レビュー未実施なので、日本語訳が間違っていたり、分かりにくい部分はあるかもしれません。

ということで、ビルドはとても簡単なので試してみて下さい。

OpenAMのデバッグログについて

 一般的なアプリケーションと同様に、OpenAMも問題が発生した際の解析などを目的として、デバッグログを出力します。OpenAMが意図した通りに動作しない場合、デバッグログを確認することが問題解決の第一歩になります。

OpenAMサーバーのデバッグログ

 OpenAMサーバーのデバッグログの出力先は、デフォルトで[OpenAMの設定ディレクトリ]/[コンテキスト名]/debug (例えば、/opt/tomcat7/openam/openam/debug) になります。この中に以下のようなカテゴリー単位のログが出力されます。

表. デバッグログのファイル名と内容

ファイル名 内容
amUpgrade OpenAMのアップグレード中に出力されるログ
Authentication 認証に関するログ
Configuration 設定に関するログ
CoreSystem OpenAMのコアとなるクラスが出力するログ
Federation SAMLなどのフェデレーションに関するログ
IdRepo データストアにアクセスするモジュールが出力するログ
Policy ポリシーに関するログ
Session セッションに関するログ

この他にも、カテゴリーに応じたデバッグログファイルは出力されます。ちなみに、[OpenAMの設定ディレクトリ]/[コンテキスト名]/log (例えば、/opt/tomcat7/openam/openam/log) 以下には、監査ログが出力されます。問題が発生した場合に最初に確認するのは、logディレクトリではなく、debugディレクトリのファイルであることに注意して下さい。

デバッグレベルと出力先の変更

 デバッグログのレベルと出力先は、管理コンソールで変更できます。 設定 > サーバーおよびサイト > サーバー名 をクリックして、表示された一般設定のページの「デバッグ」セクションで設定ができます。

Screenshot from 2016-06-18 17-51-20

「デバッグ」セクションの設定項目の詳細は、以下の通りです。

表. OpenAMのデバッグログの設定

設定項目 デフォルト値 説明
デバッグレベル エラー OpenAM全体のデバッグレベル。
デバッグファイルのマージ オン すべてのデバッグログを 1 つのファイル (debug.out) に転送します。オフ: カテゴリー毎に個別のデバッグファイルを作成します。
デバッグディレクトリ %BASE_DIR%/%SERVER_URI%/debug デバッグファイルが存在するディレクトリ。

解析のためにログの出力量を多くしたいば場合は、デバッグレベルを「メッセージ」に変更します。

カテゴリー単位のデバッグレベルの変更

 OpenAMは、システム全体のログレベルだけでなく、カテゴリーやデバッグインスタンス単位でログレベルを変更することができます。 この機能を利用するには、amadminでOpenAMにログインし、Debug.jsp (例えば、http://openam.example.com:8080/openam/Debug.jsp) にアクセスします。

Screenshot from 2016-06-18 18-17-46

例えば、カテゴリー「OAuth2Provider」のログレベルだけを「メッセージ」レベルにして、詳細なデバッグ情報を出力する、といったことができます。

デバッグログのローテーション

 デフォルトでは、OpenAMはデバッグログをローテーションしません。デバッグログをローテーションさせるには、OpenAMがデプロイされているディレクトリのWEB-INF/classes/debugconfig.propertiesを編集します。

表. デバッグログのローテーション設定

プロパティ名 デフォルト値 説明
org.forgerock.openam.debug.prefix 無し デバッグログファイルのプレフィックスを文字列で指定します。
org.forgerock.openam.debug.suffix -MM.dd.yyyy-kk.mm デバッグログファイルのサフィックスをSimpleDateFormat形式で指定します。
org.forgerock.openam.debug.rotation 無し ローテーションの間隔を分単位で指定します。ゼロよりも大きい値に設定します。

debugconfig.propertiesへの変更は、OpenAMを再起動後に反映されます。

ポリシーエージェントのデバッグログ

 ポリシーエージェントのデバッグログの設定は、WebエージェントとJ2EEエージェントで若干異なります。なお、以降で説明するWebエージェントはバージョン3.xについてです。バージョン4.0以上の場合は、若干異なります。

Webエージェントのデバッグログ

 Webエージェントのデバッグログの出力先はデフォルトで、[Webエージェントのインストールディレクトリ]/agent_[N]/logs/debug/amAgentになります。出力先を含むデバッグログの設定は、[Webエージェントのインストールディレクトリ]/agent_[N]/config/OpenSSOAgentBootstrap.propertiesに以下のように定義されています。

#
# AGENT DEBUG FILE
#   Name of the file to use for debug information.
#
# Hot-Swap Enabled: No
#
com.sun.identity.agents.config.debug.file = /root/web_agents/apache22_agent/Agent_001/logs/debug/amAgent

#
# AGENT DEBUG LOG LEVEL
# Set the logging level for the specified logging categories.
# The format of the values is
#
# <ModuleName>[:<Level>][,<ModuleName>[:<Level>]]*
#
# The currently used module names are: AuthService, NamingService,
# PolicyService, SessionService, PolicyEngine, ServiceEngine,
# Notification, PolicyAgent, RemoteLog and all.
#
# The all module can be used to set the logging level for all currently
# none logging modules. This will also establish the default level for
# all subsequently created modules.
#
# The meaning of the 'Level' value is described below:
#
# 0 Disable logging from specified module*
# 1 Log error messages
# 2 Log warning and error messages
# 3 Log info, warning, and error messages
# 4 Log debug, info, warning, and error messages
# 5 Like level 4, but with even more debugging messages
# 128 log url access to log file on AM server.
# 256 log url access to log file on local machine.
#
# If level is omitted, then the logging module will be created with
# the default logging level, which is the logging level associated with
# the 'all' module.
#
# For level of 128 and 256, you must also specify audit.access.type property.
#
# Even if the level is set to zero, some messages may be produced for
# a module if they are logged with the special level value of 'always'.
#
# Hot-Swap Enabled: No
#
com.sun.identity.agents.config.debug.level =256

また、デバッグログに関する設定の一部は管理コンソールで変更が可能です。Webエージェントの場合は、 レルム > (レルム名) > エージェント > Web > グローバル をクリックして、表示されたエージェントのグローバル設定ページの「デバッグ」セクションで以下の設定ができます。全ての項目でホットスワップが有効になっています。

表. Webエージェントのデバッグログの設定

設定項目 デフォルト値 説明
エージェントデバッグレベル エラー Webエージェントのデバッグレベル。
エージェントのデバッグファイルローテーション 有効 デバッグファイルは指定されたサイズに基づいてローテーションされます。
エージェントのデバッグファイルサイズ 10000000 エージェントのデバッグファイルサイズ (バイト単位)。

ただし、「エージェント設定リポジトリの場所」が「集中化」に選択されている場合に限ります。「ローカル」に設定されている場合は、ポリシーエージェントのインストールディレクトリ配下にある[Webエージェントのインストールディレクトリ]/agent_[N]/config/OpenSSOAgentConfiguration.propertiesというファイルでこれらの設定を変更可能です。

J2EEエージェントのデバッグログ

 J2EEエージェントのデバッグログの出力先はデフォルトで、[J2EEエージェントのインストールディレクトリ]/agent_[N]/logs/debug/debug.outになります。出力先を含むデバッグログの設定は、[J2EEエージェントのインストールディレクトリ]/agent_[N]/config/OpenSSOAgentBootstrap.propertiesに以下のように定義されています。

#
# DEBUG SERVICE PROPERTIES
# - com.iplanet.services.debug.directory: Specifies the complete path to the
# directory where debug files will be stored by the Agent.
# - com.sun.services.debug.mergeall: consolidates all the debug information
# into one file if it is set to on. Each component has its own debug file
# if it is set to off.
# Hot-Swap Enabled: No
#
com.iplanet.services.debug.level=error
com.iplanet.services.debug.directory=/home/jetty/j2ee_agents/jetty_v7_agent/Agent_003/logs/debug
com.sun.services.debug.mergeall=on

また、デバッグログに関する設定の一部は管理コンソールで変更が可能です。J2EEエージェントの場合は、 レルム > (レルム名) > エージェント > Web > グローバル をクリックして、表示されたエージェントのグローバル設定ページの「デバッグ」セクションで以下の設定ができます。この項目もホットスワップは有効になっています。

表. J2EEエージェントのデバッグログの設定

設定項目 デフォルト値 説明
エージェントデバッグレベル エラー J2EEエージェントのデバッグレベル。

ただし、こちらも「エージェント設定リポジトリの場所」が「集中化」に選択されている場合に限ります。「ローカル」に設定されている場合は、ポリシーエージェントのインストールディレクトリ配下にある[J2EEエージェントのインストールディレクトリ]/agent_[N]/config/OpenSSOAgentConfiguration.propertiesというファイルでこれらの設定を変更可能です。

OpenAM 13のユーザーセルフサービスとGoogle reCAPTCHAを使う

OpenAM 12.0.0では、XUI(※)ベースの「ユーザーセルフサービス」という機能が導入されました。ユーザセルフサービスは、次のようなユーザーの自身の情報を管理するためのサービスです。

  • ユーザー自身によるアカウントの登録
  • ログイン時に使用したデバイスの管理
  • パスワードのリセット

さらにバージョン13.0.0では、UMA(※2)のリソース共有管理機能の追加や、パスワードリセット時にKBA(※3)やGoogle reCAPTCHAで本人性を確認するといったことも可能になっています。

  • ※1:OpenAMから導入された新しいJavaScriptベースのユーザーインターフェイス。
  • ※2:User Managed Access:OAuth 2.0を拡張したアクセス管理プロトコル
  • ※3:Knowledge Based Authentication:ナレッジベース認証

今回は、KBAとGoogle reCAPTCHAを使ったパスワードリセット機能について紹介します。この機能を設定した場合、ユーザーがパスワードをリセットするフローは次のようになります。

flow

概要

KBAとは、いわゆる秘密の質問と回答のことです。ユーザーが設定した秘密の質問を回答することで本人であることを確認する仕組みです。Google reCAPTCHAは、Googleが提供する、ロボットによるなりすましを防止する機能です。パスワードをリセットするプロセスで、KBAとreCAPTCHAを使って、本人性を確認します。

hero-recaptcha-demo

設定

設定は簡単です。まずはGoogle側の設定をします。Googleアカウントでログインしてから、Google reCAPTCHAのページにアクセスし、このページの右上の「Gget reCAPTCHA」ボタンをクリックします。

Screenshot-9

適当なラベル名とOpenAMサーバーのドメインを入力します。私の環境では、OpenAMサーバーのホスト名(FQDN)がopenam09.example.co.jpなので、Domainsには「example.co.jp」と入力します。入力したら「Register」ボタンをクリックします。

Screenshot-10

完了すると、「Site key」と「Secret key」が発行されます。これらの値は、後でOpenAMの設定で使用するので、このページはこのまま開いておいて下さい。

screenshot-8

次に、OpenAMの設定を行います。管理コンソールにamadminでログインして、設定 > グローバル > User Self Service をクリックします。

Screenshot-2

画面の最上部に「Google Re-captcha Site key」と「Google Re-captcha Secret key」の入力欄があるので、先ほど取得した値を入力します。

screenshot-3

画面の中央部に「Forgotten Password」のセクションがあるので、全てのチェックボックスにチェックを入れて、「保存」ボタンをクリックします。

screenshot-4

パスワードをリセットするためのURLはメールでユーザーに通知するため、「電子メールサービス」の設定も必要です。設定 > グローバル > 電子メールサービス をクリックします。

Screenshot-5

送信可能なSMTPサーバーのホスト名、ポート番号、認証ユーザーのIDとパスワードを入力して下さい。

Screenshot-6

これで、基本的な設定は完了です。

パスワードリセットの動作検証するために、適当な名前でユーザーを作成します。作成したら、電子メールアドレスを設定して下さい。

Screenshot-7

管理コンソールからログアウトして、秘密の質問と回答を設定するため、作成したユーザーでOpenAMにログインします。

Screenshot52

適当な質問を選択し、その回答を入力します。今回は秘密の質問はデフォルトで用意されている「What is the name of your favourite restaurant?」(お気に入りのレストランは?)で、回答は「denny’s」(デニーズ)としました。

※日本語で設定して、日本語で回答することも可能です。

Screenshot91

動作確認

それでは、実際に動作確認してみましょう。OpenAMのログイン画面にアクセスして下さい。「Forgotten Password」のチェックがしてある場合(有効の場合)は、以下のように「Forgot Password」のリンクが表示されます。

Screenshot51

このリンクをクリックすると、Google reCAPTCHの画像が表示されます。「私はロボットではありません」にチェックを入れます。

Screenshot-1

すると、次のような画像認証システムが表示されます。画面の指示に従って、画像を選択して「確認」ボタンをクリックして下さい。

Screenshot-2

パスワードリセット画面が表示されるので、メールアドレスを入力して「SUBMIT」ボタンをクリックします。

Screenshot-3

登録したアドレスにメールが送信された旨が表示されるので、メールを確認してみます。

screenshot-41

これまでの設定に問題がなければ、パスワードをリセットするためのページにアクセスするためのリンクを含んだメールが送信されているはずです。

mail

リンクをクリックすると、秘密との質問に対する回答を入力する画面が表示されます。先ほど設定した回答(denny’s)を入力して下さい。

screenshot-61

間違いがなければ、パスワードリセット画面が表示されます。新しいパスワードを入力して、パスワードをリセットして下さい。

Screenshot-7

これでパスワードがリセットされました。

screenshot-81

以上で完了です。

注意事項

一点注意事項があります。OpenAMを11.0.xからアップグレードしてからユーザーセルフサービスを使用する場合は、以下のような「Unable to find account」のメッセージが表示されて、正常に機能しません。

Screenshot54

この場合は、グローバル設定のREST APIsページで、「Default Version」を「Oldest」から「Latest」に変更してみて下さい。

Screenshot53

ユーザーセルフサービスの処理内で実行されるユーザー検索は新しいバージョンのREST APIを使用しているのですが、アップグレード後は下位互換性の保証のために、古いバージョンのREST APIを使用するようになっていて、それによりこのような問題が起こります。


 

今回紹介した以外にも、ユーザーセルフサービス機能やオプションの設定はあります。OpenAM 13.0.0の管理者ガイドのユーザーセルフサービスのセクションを参照して、試してみて下さい。

OpenAM 13.0.0がリリースされました

2016年1月27日にOpenAM 13.0.0がリリースされました。ということで、リリースノートに記載されている新機能を日本語で紹介します。

※一部、原文と内容を変えています。原文は以下にあります。

https://backstage.forgerock.com/#!/docs/openam/13.0.0/release-notes/chap-whats-new

このリリースでは、次の拡張機能が導入されています:

1. よりスマートなセキュリティ機能

  • ForgeRock オーセンティケータアプリと認証モジュール
    iOSとAndroid用のオーセンティケータモバイルアプリと、それが生成したワンタイムパスワード(OTP)を検証する認証モジュール「ForgeRockオーセンティケータ(OATH)認証モジュール」が導入されました。この2つを連携することで、強力な多要素認証が実現できます

    FR_Auth      FRA_OATH

    このモバイルアプリは、デバイスの紛失や盗難があった場合でもQRコードとリカバリーコードを介して簡単な配信と安全なプロビジョニングを提供します
    詳細
    については、OpenAM管理ガイドの Section 2.4.10, “Hints for the ForgeRock Authenticator (OATH) Authentication Module” を参照してください。

  • 認可ポリシーの改良
    OpenAM 13.0.0では、認可ポリシーの「条件」がスクリプトで実装できるようになりました。保護されたリソースにアクセスする際の認可プロセスを強化するために、ユーザーのプロファイル属性をデータストアから取得したり、外部のポリシー情報ポイント(PIP)をRESTで呼び出すことができます

    CondScript

    詳細については、OpenAM開発者ガイドの Chapter 6, “Scripting OpenAM” を参照してください。

    また、OpenAMの認可ポリシーの構成方法や実装が改良されています。これにより、デバイスがURL以外のリソースにアクセスしようとするIoTのプロジェクトなど、より多くの状況でポリシーを外部化できます。

    resource-types-console

    詳細については、OpenAM管理ガイドの Chapter 3, “Defining Authorization Policies” を参照してください。

  • SAML2 認証モジュール
    SAML 2.0の仕様に基づいた新しい認証モジュール「SAML2認証モジュール」が提供されました。 SAML2認証モジュールは、強力な多要素認証のシナリオでフェデレーションアイデンティティを活用し、認証連鎖内にフェデレーションを組み込むことを可能にします
    SAML2認証モジュール
    詳細
    については、OpenAM管理ガイドの Chapter 12, “Managing SAML v2.0 Federation” を参照してください。

  • ビルトイン RADIUS サーバーのサポート
    以前のバージョンのOpenAMでは、Remote Authentication Dial-In User Service(RADIUS)認証モジュールを使用することで、RADIUSクライアントとして機能することができました。 さらに13.0.0からは、RADIUSサーバーとしても機能することが可能になりました。VPNコンセントレータ、ルータ、スイッチ、無線アクセスポイント、その他の多くのデバイスがRADIUSをサポートしており、その認証にOpenAMを使うことができます
    詳細については、OpenAM管理ガイドの Chapter 19, “Configuring OpenAM as a RADIUS Server” を参照してください。

2. IoT 機能

  • OAuth 2.0 デバイスフロー
    最小限の入力機能しか持っていないデバイス(セットトップボックスなどのInternet of Things(IOT)デバイス)を、別のデバイス(スマートフォンなど)と連携させて認可する、OAuth 2.0の拡張仕様「OAuth 2.0デバイスフロー」をサポートしましたこの機能は、IOTデバイスをサービスへと接続する標準ベースのアプローチを提供します
    詳細
    については、OpenAM管理ガイドの Section 13.1.1.5, “OAuth 2.0 Device Flow” を参照してください。

4. OAuth 2.0/OpenID Connect 1.0 機能強化

  • OAuth 2.0 プロバイダウィザード
    プロバイダのタイプに最適な設定を保証するための、OAuth 2.0プロバイダウィザードがサポートされました。次のプロバイダを使用できます:

    • OAuth 2.0 プロバイダ
    • OpenID Connect 1.0 プロバイダ
    • Mobile Connect プロバイダ
    • UMA プロバイダ

    OAuth 2.0 プロバイダこれらのウィザードは、本番環境にデプロイするための時間をスピードアップします。

  • OpenID 認定
    OpenAM 13.0.0は、OpenID Foundationの適合性テストに全て合格しています。このテストでは、モバイルアプリケーションとWebアプリケーションがその基準に厳密に準拠していることを検証します。標準規格への適合は、ベンダー独自のソリューションにロックインされていないことを顧客に保証します

    The OpenID Certified mark

     

  • OpenID Connect 1.0 クレームスクリプト
    OIDCクレームスクリプトによって、追加のクレームを付加したIDトークンを発行できます。この機能により、追加のアイデンティティ情報を必要とするソリューションの構築が簡単になります
    OIDCScript
    詳細については、OpenAM開発者ガイドの Section 6.3, “Using the Default Scripts” を参照してください。

  • ベース URL ソースサービス
    クライアントへURLを返す必要があるコンポーネントに対して、ベースURL(プロトコルを含む)を変更する設定がレルム単位でできるようになりましました。このサービスは、 OpenID Connect 1.0およびUMAで使用される .well-known エンドポイントが返す各URLを変更するために使用されます。以下のようにサイト(冗長)構成の1号機の .well-known エンドポイントで取得できる各エンドポイントのURLを、ロードバランサーのURLに書き換えることなどができます。

    # curl https://openam01.example.co.jp:8080/openam/oauth2/.well-known/openid-configuration
    {
        "authorization_endpoint":"https://openam.example.co.jp/openam/oauth2/authorize",
        "check_session_iframe":"https://openam.example.co.jp/openam/oauth2/connect/checkSession",
        "end_session_endpoint":"https://openam.example.co.jp/openam/oauth2/connect/endSession",
        "jwks_uri":"https://openam.example.co.jp/openam/oauth2/connect/jwk_uri",
        "registration_endpoint":"https://openam.example.co.jp/openam/oauth2/connect/register",
        "token_endpoint":"https://openam.example.co.jp/openam/oauth2/access_token",
        "userinfo_endpoint":"https://openam.example.co.jp/openam/oauth2/userinfo",
        "issuer":"https://openam.example.co.jp/openam/oauth2",
        "acr_values_supported":[],
        "claims_parameter_supported":false,
        "claims_supported":["zoneinfo","phone_number","address","email","locale","name","family_name","given_name","profile"],
        "id_token_signing_alg_values_supported":["HS256","HS512","RS256","HS384"],
        "response_types_supported":["token id_token","code token","code token id_token","token","code id_token","code","id_token"],
        "scopes_supported":["phone","address","email","openid","profile"],
        "subject_types_supported":["public"],
        "token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt","client_secret_basic"],
        "version":"3.0"
    }

    詳細については、OpenAM開発者ガイドの Section 14.4, “Configuring the Base URL Source Service” を参照してください。

5. CTS パフォーマンスの強化

  • CTS パフォーマンス
    OpenAM 13.0.0は、コアトークンサービスのパフォーマンスを向上させるために、インデックスを最適化しました

6. エラスティシティとスケーリング機能

  • ステートレスセッション
    OpenAM 13.0.0では、従来のステートフセッションの他にステートレスセッションをサポートしました。ステートフルセッションは、OpenAMサーバーのメモリに常駐するセッションです(またはセッションフェイルオーバーが有効になっている場合は、コアトークンサービスの トークンストアに保持されるセッションです)。ステートフルセッションは、以前のバージョンのOpenAMでサポートされている唯一のセッションタイプでした。OpenAM 13.0.0では、JWT(JSON Web Token)を使った新しいタイプのセッション「ステートレスセッション」をサポートしています。ステートレスセッションの情報は、OpenAMサーバーのメモリには保持されず、エンコードされてブラウザのクッ キー値としてクライアントに保存されます。ブラウザはOpenAMにそのクッキーを送信すると、OpenAMはクッキーからセッションの情報をデコードします。エラスティシティ(Elasticity)が必要なシステム構成(例えば、サーバーの負荷が変化するクラウド環境でのシステム構成)での水平方向の負荷の調整などにおいて、ステートレスセッションは効果を発揮します。
    詳細については、OpenAM管理ガイドの Chapter 9, “Configuring Session State”

  • 動的設定
    以前はサーバーの再起動が必要であった多くのサービスが、ホットスワップに対応しています

7. ユーザーエクスペリエンスの強化

  • テーマ対応のユーザーインターフェース
    OpenAM 13.0.0では、レスポンシブでリッチなJavaScriptベースの新しいユーザーインタフェースのテーマを提供しました。テーマは簡単にカスタマイズできます。
    詳細については、OpenAMインストールガイドの Section 5.1, “Customizing the End User Interface” を参照してください。

  • トラブルシューティング情報の記録
    ssoadm start-recording コマンドは、OpenAMを監視するイベントを起動し、トラブルシューティングを行う際に便利な出力を保存することができます。また、 /json/records エンドポイントにリクエストを送信することでも、同様にイベントを開始することができます。イベントを起動した後、イベントの状況を取得する ssoadm get-recording-status コマンドや、イベントを終了する ssoadm stop-recording コマンドを使用することができます。
    詳細については、OpenAM管理ガイドの Section 24.5, “Recording Troubleshooting Information” と開発者ガイドの Section 2.1.8, “RESTful Troubleshooting Information Recording” を参照してください。

8. プラットフォーム機能

  • ユーザーセルフサービス
    ユーザーがWebサイトに登録したユーザー名やパスワードを忘れてしまった場合に、そのユーザー名やパスワードをリセットできるサービスなど、ユーザーセルフサービス機能が導入・拡張されました。ユーザーが自分自身のアカウントをメンテナンスすることができるため、ヘルプデスクのコストを低下させます。この機能は、ForgeRockプラットフォーム(OpenAM、 OpenIDM、OpenDJ)全体で一貫したユーザーエクスペリエンスを提供します。
    詳細については、OpenAM管理ガイドのChapter 8, “Configuring User Self-Service Features” を参照してください。

  • 共通監査ログ
    すべてのユーザーと管理者のアクティビティを記録することができる、新しいForgeRock 共通監査フレームワークが導入されました。ログは、ファイル、データベース、syslogに書き込むことができます。共通監査ログは、ForgeRock プラットフォーム全体のすべてのユーザーアクティビティの共通で一貫性のある監査証跡を管理者に提供します。
    AuditLogs
    詳細については、OpenAM管理ガイドの Chapter 6, “Configuring Audit Logging” を参照してください。

  • DASの代替としてのOpenIG
    ForgeRock OpenIGは、クライアントとOpenAMサービス間のリバースプロキシサーバとして動作することができます。DMZ内にデプロイすると、OpenIGはすべてのトラフィックを検査し、OpenAMへ適切にリクエストを転送することができます。なお、これにより、13.0.0からはDAS(DAUI)が削除されています。

    fromDUAItoOIG

  • OpenDJ 3.0
    設定ストア/トークンストア/UMAストアとして、新しいOpenDJ 3.0サーバーを使用するように、組み込みディレクトリサービスがアップグレードされました。OpenDJ 3.0のアップグレードの内容についてはリリースノートを参照してください。

9. デベロッパーフレンドリーな機能

  • スクリプティングサービス
    13.0.0ではスクリプティングサービスを強化しており、以下のスクリプトを構築するライブラリとエディタを提供しています。

    • 認証スクリプト(クライアントとサーバー)
    • 認可ポリシー条件スクリプト
    • OpenID Connectクレーム収集スクリプト

    OpenAMスクリプティングサービスは、認証/認可サービスを簡単かつ迅速にカスタマイズできます。
    詳細については、OpenAM管理ガイドの Chapter 22, “Managing Scripts with the OpenAM Console” を参照してください。

  • SOAP STS
    OpenAM 13.0.0では、OpenAM 12.0のREST STS(セキュリティトークンサービス)にSOAP STSを加えることで、STSソリューションを強化しました。SOAP STSは、SOAPを用いて様々なトークン変換を行うサービスです。例えば、このサービスにより、OpenID ConnectのトークンをSAMLアサーションに変換し、SAMLのサービスプロバイダが保持するリソースにアクセスすることができます。SOAP STSは、以下のコンテナにOpenAMからリモートでデプロイされます

    • Apache Tomcat, バージョン 6, 7, or 8
    • Jetty, バージョン 7, 8, or 9

     


ということで、13.0.0もいろいろな機能が追加されています。是非ダウンロードして、使ってみてください。

https://backstage.forgerock.com/#!/downloads/OpenAM/OpenAM%20Enterprise/13.0.0/OpenAM%2013/zip#list