1.はじめに
1.1.本書の位置づけ
このレポートは、シングルサインオン(SSO)を実現するためのオープンソース・ソフトウェアであるOpenAMについて実施した検証についての報告をまとめたものです。
1.2.背景
認証処理は、セキュリティを担保するための必要不可欠な要素であり、様々なシステム・アプリケーションに組み込まれています。しかし現状ではアプリケーションごとにログインを必要としたり、場合によってはいくつものID・パスワードを使い分けることを余儀なくされたりしていることも多くあります。このような課題を解決するためには、ID・パスワードを統合する統合認証と一度のログインですべてのアプリケーション・システムを使うことを可能にするSSOを提供する認証基盤を構築することが有用です。認証基盤を構築するための商用製品はいろいろなベンダから提供されています。しかし、それらの製品は高機能ですが、ユーザアカウント数に応じたライセンスを必要とし、大規模なシステムでは非常に高価となりコストを圧迫します。そこでOSSを組合せて認証基盤を構築することにより、コストを抑制することが期待されます。最近では、認証基盤を構築するためのOSSが存在し、その導入事例も報告されています。認証基盤を構築する技術は、SSOの他にもユーザ情報・権限情報などを格納する統合ディレクトリ、人事システムからユーザ情報を取り込み各システムに連携するID管理、SSLなどの暗号化基盤、電子証明書のためのPKI(Public Key Infrastructure)基盤など幅広い領域にわたります。それぞれOSSを利用することで実現可能です。図１は認証基盤全体の概要を示しています。認証システムのOSSとしてはOpenAM、統合ディレクトリのOSSとしてはOpenLDAPが利用できます。このレポートでは、認証基盤の中核となる技術であるSSOを中心として取り上げ、それを実現するOpenAMの機能面・非機能面に関する動作検証を行った結果を報告します。
1.3.前提知識
本書では、認証・認可の仕様について詳しく説明しておりません。SSO、SAML、XACML、OpenID、LDAPなどについての基礎的な知識が前提になります。 ※本文中に登場する会社名、商号名、製品名、サービス名称などの名称は、各社の商号、商標または登録商標です。
2.機能検証
2.1.  OpenAM概要
OpenAMは、SSOによる認証やアクセス制御を実現するためのオープンソース・ソフトウェアです。 Sun Microsystems(現Oracle)により提供されていたOpenSSOを起源に持ち、現在は、Sun Microsystemsの技術者が設立したforgerock社により開発が進められています。日本においても、OpenAMの発展と普及を目指し、2010年10月に「OpenSSO&OpenAMコンソーシアム(www.openam.jp)」が設立されました。
2.1.1.サポートする認証方式
OpenAMでは、ユーザ名・パスワードを元にしたパスワード認証をはじめ、ワンタイムパスワード認証、クライアント証明書を利用した認証、生体認証などさまざまな認証方式をサポートしています。またそれらを組み合わせた多要素認証（OpenAMでは認証連鎖と呼ぶ)を実現することもできます。
2.1.2.   SSO実現方式
SSOを実現する方式として、システム構成上から大きくエージェント方式とリバースプロキシ方式に分けることができます。エージェント方式では、Webアプリケーションサーバに配置されたエージェントが認証処理を行います。リバースプロキシ方式では、Webアプリケーションサーバのフロントに配置されたリバースプロキシが認証処理を行います。リバースプロキシ方式の特殊な形としてアプリケーションの認証を肩代わりする代理認証方式があります。また、通常SAMLは、異なる組織問で認証の連携を実現するフェデレーションを行うための標準規格ですが、SAMLを利用することでもSSOを実現できます。SSO実現方式の概要を図2に示します。表1はそれぞれのSSO方式について比較をしたものです。

表 1.  SSO実現方式の比較
OpenAMは、認証・アクセス制御や安全なWebサービス、フェデレーションなどの機能を提供するために、 HTML・XML・SAML・SOAPなど多くの標準に準拠しています。構成要素には、クライアントプログラミング・インタフェース(Client Software Development Kit(SDK))、ビジネスロジックを実装ションしたサービスのコンポーネント、サービスプロバイダインタフェース(SPI)を実装したプラゲインがあります。それぞれのコンポーネントは、OpenAM内部Frameworkを利用してプラグインや他のコンポーネントが提供しているデータを取得します。プラグインはOpenAMが標準で提供しているもの以外にもSPIに準拠することで独自に開発することができます。認証前後の処理やユーザリポジトリの操作などに独自に開発したモジュールを組み込むことができるので、案件の要件に合せて柔軟に対応した認証基盤を構築することが可能となります。今までの認証基盤製品ではできなかったことが実現できる可能性を秘めています。 OpenAMのコアサービスを以下に挙げておきます。 . Authentication Service特定の認証データストアに対する、ユーザ認証機能を提供する。認証に成功すると、SSO環境で利用するための認証セッションデータを作成する。 Policy Service認証済みのユーザに関連付けられたポリシーを評価する、認可の機能を提供する。 Session Service Webアプリケーションを横断して、認証済みのユーザのセッションを管理する。 . Logging Service各コンポーネントが利用する共通のログ出力機能を提供する。 Identity Repository Service企業のLDAPサーバのように既存のユーザデータストア環境と連携するための機能を提供する。 Federation Service SAMLなどフェデレーション規格に準拠した機能を提供する。 Web Services Stack OpenAMのサービスをWebサービス経由で提供する。 Web Services Security and the Security Token Service Webアプリケーションを横断して、認証済みのユーザのセッションを管理する。 Identity Web Services認証・認可・セッション管理・ロギングのためのWebサービスインタフェースを用意している。主にPolicy Agentが利用する。
2.2.検証目的と検証内容
OpenAMの基本的な動作検証を行うために、以下のような認証基盤の検証テーマを想定しました。 ・認証基盤を導入し、既存のアプリケーションをSSO対応させる（エージェント方式） ・認証基盤を導入し、既存のアプリケーションをSSO対応させる（リバースプロキシ方式） • Salesforceなどの外部サービスと社内アプリケーションをSSOで利用する・セキュリティ向上のためモバイル端末の固体認証を行うそれぞれがOpenAMによって実現可能であると確認することを検証の目的としました。また、設定項目が正常に動作することを確認し、その際に発生した課題・解決方法などを明らかにすることとしました。
2.2.1.  検証テーマ1  エージェント方式によるSSO対応
認証基盤を導入するにあたっては、既存のアプリケーションをどのようにSSOに対応させるかが重要です。そこで既存アプリケーションをエージェント方式によりSSO対応を行い、その際に必要となる設定・既存アプリケーションの修正方法を確認します。対象となる既存アプリケーションとしては会議室予約システムを利用します。
2.2.2.   検証テーマ2   リバースプロキシ方式によるSSO対応
検証テーマ１のエージェント方式では、既存アプリケーションの修正が必要となりますが、リバースプロキシ方式の一つである、代理認証方式を使えば、既存アプリケーションを修正せずにSSO対応が可能となります。ここでは、代理認証による既存アプリケーションのSSO対応を行い、その際に必要となる設定・留意点を確認します。対象となる既存アプリケーションとしては検証テーマ１と同様に会議室予約システムを利用します。
2.2.3.検証テーマ３外部サービスも含めたSSO対応
企業での利用が本格化してきているGoogle Apps、SalesforceなどをSSOで使いたいという要求は、今後も増加してくると予想されます。そこで外部サービスがSSOで使えることを確認します。対象となる外部サービスはSalesforceのCRMを利用し、社内システムとしては検証テーマ１と同様に会議室予約システムを利用します。
2.2.4.検証テーマ４モバイル端末の個体認証
スマートフォンなどの普及により、外出先からも社内システムへ接続する機会が多くなりました。その際にセキュリティを向上させるため、ID/パスワードを知っていたとしても、正式に登録されたスマートフォン以外からはログインできないようにすることが要求されることもあります。ここではOpenAMによってモバイル端末の個体認証が実現できることを確認します。モバイル端末としてはiPhone/iPadを利用します。
2.3. 検証環境
動作検証に関しては、Linux上のTomcat6.0にOpenAMおよび認証対象のWebアプリケーションをデプロイして使用しました。また、SAMLを使用したフェデレーションの検証は、外部サービスとしてSalesforceを使用しました。クライアントは、Windows PC上のFirefox, ChromeプラウザおよびiPhoneやiPadのMobile Safariプラウザを使用しました。代理認証機能に関しては、標準のOpenAMでは提供されていないため、野村総合研究所（以下「NRI」）版のOpenAMに付属の機能を利用して検証を行いました。 iPhoneやiPadから接続を行うために、OpenAMおよび認証対象のWebアプリケーションは、OSS戦略企画宝のラボ環境とAmazon EC2のそれぞれに同様の環境を用意しました。

2.4. 検証結果
2.4.1.  検証テーマ1  エージェント方式によるSSO対応前述のようにOpenAMではいくつかのSSOの実現方式をサポートしており、システム要件により柔軟に選択することができます。この検証ではエージェント方式により既存アプリケーションのSSO対応ができることを確認できました。 WebアプリケーションサーバであるTomcatにOpenAMのPolicy Agentを導入し、既存アプリケーションとした会議室予約システムにおいては認証処理の替わりにHTTPヘッダからユーザ情報を取得するように修正しました。これらの対応により既存アプリケーションのSSO対応が実現できることが確認できました。エージェント方式は、既存アプリケーションの修正を必要としますが、HTTPヘッダからユーザ情報を取得するなど比較的簡単なアプリケーションの修正によりSSOの対応が可能となりました。図 5. エージェント方式によるSSO対応エージェント方式では、図６のようにPolicyAgentがクライアントからのアクセスを最初に処理します。 Apache  Webサーバの場合はapacheのモジュールとして、Tomcatの場合は認証用拡張モジュールとして実装されています。 PolicyAgentは未認証のクライアントからのリクエストを受け付けると、OpenAMのログイン画面ヘリダイレクトします。認証済みのクライアントからのリクエストの場合は、認証情報を付加して連携APヘリクエストを転送します。どのような認証情報を付加するかはOpenAMの管理コンソールで設定できます。IDなどユーザプロファイルに含まれている情報をHTTPヘッダやクッキーなどに付加することが可能です。連携APでは、HTTPヘッダやクッキーなどからリクエストに付加された認証情報を取得することができます。
2.4.2.   検証テーマ2   リバースプロキシ方式によるSSO対応
この検証では代理認証により既存アプリケーションのSSO対応ができることを確認しました。検証テーマ１とは異なりリバースプロキシサーバにOpenAMのPolicy Agentを導入し、アプリケーションが動作するWebアプリケーションサーバおよび、既存アプリケーションである会議室予約システムには手を入れること無くSSO対応が実現出来ました。図 7. リバプロ方式によるSSO対応代理認証機能は、現在のOpenAMでは標準機能として提供されていないため、NRIのパッケージ版OpenAMを利用して検証しました。以下に代理認証の処理の流れを示します。
図８のようにNRI版OpenAMの代理認証機能は、リバースプロキシ上のApacheで動作するmod_rewriteモジュールとTomcatで動作するLoginHandler(代理認証モジュール)により実現しています。連携APへのログイン処理はJavaScriptにより自動的に実施されます。連携APのログイン後は、LoginHandlerを経由せずmod_rewriteから連携APへ転送されます。連携先のAPがSSLであったり、複数のAPであったりした場合もApacheの仮想ディレクトリや仮想ホストの機能を利用して対応できるはずなので今回は検証対象としていません。今回の検証で利用した会議室予約システムは、Form認証を元にしていたので、アプリケーションを修正することなく代理認証によるSSO対応することができました。しかし、Basic認証を元にしたアプリケーションはこのままでは対応できないので、別の仕組みを検討する必要があります。OpenSSOコミュニティで、 OpenAMの認証後処理モジュールにおいてBasic認証で必要なAuthenticationヘッダ情報を生成する方法が紹介されています(http://java.net/jira/browse/OPENSSO-2889)。詳細は「5.3Basic認証APに対する代理認証」を参照ください。なお、リバースプロキシ方式の場合、アプリケーション内で相対URLを使っている事が前提となります。絶対 URL を使っている場合は、別途コンテンツ書き換えをリバースプロキシで行う必要があります。特にJavaScript内部で絶対URLを利用している場合は対応できない可能性もあります。その場合はエージェント方式による対応を取らざるを得ないでしょう。代理認証機能は、既存APをそのままSSO対応させることを可能にする技術でありながら、現在のOpenAMの標準機能としては提供されていません。そのため、OpenAMのソリューションを提供している各社が独自に対応して機能を提供しています。今回の検証では、NRI社の製品版OpenAMを使い代理認証の機能を検証しました。連携先のアプリケーションがForm認証の場合は、この機能で代理認証に対応することができます。ただし前述したように、Basic認証のアプリケーションを代理認証でSSO対応するには、別の仕組みが必要になります。また、リバースプロキシにApacheとTomcatの両方を必要とするなどやや煩雑な構成となっています。 OpenAMの次期バージョンである10.0では、リバースプロキシであるOpenIG(Identy  Gateway)が導入されます。これを使うことによりForm認証・Basic認証の双方に対応した代理認証を実現することができます。
2.4.3.  検証テーマ３外部サービスも含めたSSO対応
OpenAMでは多くのフェデレーション標準規格に準拠しているため、外部サービスのSSO対応も容易に可能です。今回の検証では、SAMLによりSalesforceとのフェデレーションを実現し、社内システムである会議室予約システムとのSSOを実現できることを確認しました。SalesforceはSAMLのHTTP Post Binding方式ですが、 OpenAMではHTTP Artifact Bindingにも対応しています。以下にSAMLの２つの方式の処理の流れを示します。

図 9.  SAML認証シーケンス(HTTP Redirect Binding/HTTP Post Binding)
SAMLでは、認証処理の開始としてSPを起点にする場合(SP Initiated)とIdPを起点にする場合(IdP Initiated)が定められています。 Salesforceの場合は、SPを起点とする認証はサポートしていないので、まずIdPにアクセスします。その後は④からの流れとなります。
図 10．SAML認証シーケンス(HTTP Artifact Binding)
HTTP Redirect Binding/HTTP Post BindingとHTTP Artifact Bindingの大きな違いは、SPからIdPへの通信が発生するかどうかです。 Artifact Bindingでは図10のようにユーザから送られて来たアーティファクトを解決するためにSPからIdPへの通信が必要となります。外部サービスとSAMLで連携する場合、HTTP Redirect Binding/HTTP Post Binding方式を利用すれば、IdPを内部ネットワークに配置することも可能です。なお、 Artifact BindingにもSP InitiatedとIdP Initiatedの二通りがあります。今回の検証では企業ユースを視野に入れて、Google AppsやSalesforceで採用されているSAMLを優先的に検証しましたが、コンシューマ向けの外部サービスではOpenIDも利用されているので今後必要であれば調査対象としたいと考えています。検証テーマ3 :外部サービスも含めたSSO対応•クラウドの外部サービスもSSOで使いたい– Google Apps, SalesforceはSAMLに対応図 11. 外部サービスも含めたSSO対応なおSAMLを利用することで社内システムなど既存アプリケーションをSSO対応させることも可能ですが、独自にSAMLを実装することは容易ではありません。そのため、OpenAMではFedletという機能が用意されており、OpenAMの管理コンソールから自動作成したFedletの雛形を利用してSAML対応させることができます。しかし、Fedlet はアプリケーションの実装上の制約も大きいので、既存のアプリケーションに利用するのは不向きでしょう。また、自動作成したFedletには一部問題があります。詳細は「5.2.2自動作成されたFedletを使用する上での留意点」を参照ください。
2.4.4.検証テーマ4 モバイル端末の個体認証
OpenAMでモバイル端末の個体認証を実現するため、クライアント証明書によるPKI認証の構成を行い、動作を確認しました。クライアント証明書が導入された端末からしか接続できないことと、パスワード認証と組み合わせた際に、クライアント証明書のユーザと一致しない場合に認証エラーとなることが確認できました。検証テーマ4:端末の個体認証•セキュリティ向上のため、登録された端末からしか接続できないようにしたい–クライアント証明書を使ったPKI認証を利用クライアント証明書が導入された端末からだけ接続を許可図12.端末の固体認証.
2.4.5.機能検証項目および結果一覧
以下に機能検証項目とそれぞれの結果を示します。
ない付随的な処理※ 2：クライアントはWindows PCのみ確認
2.4.6.機能検証のまとめと考察
今回の検証にあたり、認証基盤で4つの検証テーマを想定しました。 ・認証基盤を導入し、既存のアプリケーションをエージェント方式によりSSO対応させる・認証基盤を導入し、既存のアプリケーションをリバースプロキシ方式によりSSO対応させる• Salesforceなどの外部サーピスと社内アプリケーションをSSOで利用する・セキュリティ向上のため端末の個体認証を行う機能検証では、エンタープライズの認証基盤では基本的だと考えられる３つの構成と、今後利用が進むと考えられる携帯端末の認証の構成を検証しました。エージェント方式では、既存APをHTTPヘッダから認証情報を取得するように修正することによりSSOに対応させることができました。特に認証のために複雑なAPIを実装することも無く比較的少ない修正により対応することができることが確認できました。リバースプロキシ方式では、代理認証機能を利用することにより既存APを修正すること無しにSSOに対応させることができました。
2つのSSO方式を比較すると、代理認証機能を使ったリバースプロキシ方式には、既存APを修正することなくSSOに対応できるという大きなメリットがあります。ただし、リバースプロキシを通すことによるURL変更の影響を受けるデメリットもあります。AP内で相対URLによる画面遷移を行なっていれば影響も少ないのですが、絶対URLを使っている場合は書き換えをリバースプロキシで別途実装する必要があります。 JavaScriptなどで絶対URLを利用する実装をしている場合は、代理認証機能の利用ができない場合も想定されます。エージェント方式は、既存APの修正を必要とするものの、比較的少ない修正で既存APをSSO対応とすることが可能になります。AP内でのURL取り扱いに関する制約も無いので、新規にAPをSSO対応する場合は有力な遷択肢となるでしょう。 SAMLを利用することによりSalesforceと社内アプリケーションをSSOで利用できることも確認できました。特に、SAMLのHTTP Post Binding方式を利用すれば、認証サーバであるIdPや認証DBであるユーザリポジトリを社内に配置したまま、クラウドなどの外部サービスをSSOで利用することが可能となります。セキュリティを確保しながら、外部サービスを利用する際の利便性も向上することができます。既存アプリケーションをSSO対応するために、SAMLを実装する方式を取ることも可能です。しかし、 SAMLを実装するのは困難であり、Fedletを使ったとしても既存アプリケーションをSAML対応させることは現実的ではありません。SAMLの利用は外部サービスとの連携に留めておき、既存アプリケーションをSSO対応させるためには、エージェント方式やリバースプロキシ方式を選択すべきでしょう。認証DBとなるユーザリポジトリとしては、代表的なOpenLDAPとActive Directoryについて利用できることを確認しました。他の商用ディレクトリサービス製品にも対応しているので選択可能です。また、現在は実験的な機能ですが、大規模なシステム向けにRDBMSをユーザリポジトリとして選択することもできます。また特殊な案件の用途に合せて独自にユーザリポジトリを実装することも可能です。携帯端末による認証構成の検証をテーマとして、iPhone/iPadの個体認証にPKIのクライアント証明書認証をOpenAMで利用できることを確認できました。PCでも同様にしてクライアント証明書を利用することができます。ただし、Androidの場合、現在のところ標準機能としてはクライアント証明書を利用することができません。今回の検証では、プラウザベースのWebアプリケーションを利用しました。しかし、スマートフォンではプラウザベースでないネイティプアプリケーションも多く利用されています。ネイティプアプリケーションでOpenAMの認証を利用するためには、WebサービスベースのAPIを利用することで可能となりますが、開発を効率的に行うにはネイティプAPIライプラリが整備されることが望まれます。外部サービスの連携では、SAMLを利用してSalesforceとの連携を検証しました。今後機会があれば、Google AppsなどのSAMLサイトの他、別のフェデレーション規格であるOpenIDに関しても検証したいと考えています。 OpenAM は認証基盤を構築する上で今回想定したシナリオにおいて十分な機能を備えていることが確認できました。また「認証基盤製品比較」でも挙げているようにカタログスペックで比較すると認証基盤製品と比較しても遜色のない機能であることが分かります。ただし、それぞれの提供する機能の程度の差異に関しては実際に検証して確認・評価する必要があるでしょう。
3.非機能検証
OpenAMの非機能検証では、主に性能面と可用性の面について検証環境を構築し試験を行います。また、セキリティ面と運用面においても考察します。
3.1.性能試験
3.1.1.検証目的
ここでは、OpenAMを利用して企業の認証基盤を構築した際に、性能面において実用に耐えうるかを検証します。その際に性能上の課題が存在しないか、ボトルネックの存在、検証環境のハードウェアスペックにおけるパフォーマンスの指標などを明らかにすることを目的とします。想定した企業の規模、利用シナリオは以下の通りです。 ・登録ユーザ数   10,000人・10万アクセス/日、ピーク時1.4アクセス/秒・ユーザは、出社後ポータルヘログインし、スケジューラなどのアプリケーションを利用•同時利用ユーザ　1,000人
3.1.2.  検証内容
以下の２つのシナリオにより負荷を発生させます。 ・認証のみ(OpenAMへのログイン・ログアウト) ・認証＋連携アプリケーション会議室予約システムを代理認証方式で連携負荷の発生には、Apacheが提供しているOSSのJMeterを利用します。テストシナリオの作成は、JMeterのレコーディング機能を利用してプラウザの操作を記録したものをベースに想定した要件に合せて修正します。均等に負荷が掛かるように、JMeterのテストシナリオを調整し、リクエスト毎に異なるサーバへ向くようにします。負荷発生時に各サーバのリソース状況（CPU、メモリ、IO、JVM、など）を確認します。また、ログ出力内容もチェックし致命的な障害が発生していないことを確認します。リソース状況の取得にはespfのリソース情報収集ツールを利用します。各ミドルウェアは、基本的にはデフォルト設定を元にし、性能目標を達成できない時にチューニングを実施するという方針とします。図14.認証＋連携アプリケーション
3.1.3. 検証環境
性能訣験を実施するにあたり、APの連携方式として利用シーンが多いと想定される、代理認証方式を採用し、各サーバを冗長構成にした検証環境を構築しました。表５に構成要素を示します。

表5.性能試験検証療境構成
表 6。仮想環境スペック

3.1.4.検証結果
3.1.4.1.
性能試験シナリオ１の結果OpenAMの認証のみのシナリオを実施した結果では、同時1,000ユーザ利用時に、スループットが150リクエスト/秒、90%タイル1.6秒となっており、性能目標をクリアしました。ただ、スループットに関しては同時 2,000ユーザをピークに減少傾向が見られます。同時1,000ユーザの負荷を発生させた時に、スループット230リクエスト/秒、90%タイル5秒となり性能目標は達成することができました。ただし、主にAPサーバの処理限界に達しており、それ以上の負荷を与えると安定した試験結果を得ることはできませんでした。また、APサーバのメモリリークの兆候が見られたために、原因を調査したところ、ログアウト時にセッションデータが削除されていないことと、Tomcat7で開発されTomcat6にも導入されたメモリリーク検知機能(JreMemoryLeakPreventionListener)が原因であることが判明しました。アプリケーションおよびAPサーバ(Tomcat)で行ったチューニング内容は以下のようになります。 ・ログアウト時にセッションデータを削除する画面(JSP)を追加しテストシナリオに追加Copyright 2012 SCSK CORPORATION. All rights Reserved. OpenAM検証報告・設定ファイル(server.xml)からJreMemoryLeakPreventionListenerをコメントアウト• Tomcatの起動時にJVMにおけるヒープ割当ての調整-XX:+UseConcMarkSweepGCんん-XX:+CMSParallelRemarkEnabled
3.1.4.3.性能試験結果のまとめ
OpenAMを企業の認証基盤で利用するために以下のような性能目標を想定しました。 ・登録ユーザ数   10,000人・10万アクセス/日、ピーク時1.4アクセス/秒・同時利用ユーザ1,000人シナリオ１のOpenAM単体では性能目標を問題なく達成しており、検証環境のような一般的なスペックの仮想マシン（CPU:Xeon2.0GHz相当× １、メモリ２GB詳細は表６参照）の２台構成で特に問題なく処理できることが検証出来ました。シナリオ２のOpenAMと連携APまで含めた試験の場合は、性能目標は達成しましたが、以下のような課題がありました。 ・AP処理の影響が大きいのでサーバのスケールアウトやチューニングが必要・同時５００ユーザを超えると性能劣化傾向が見られる今回の検証ではOpenAMの性能試験ということで、アプリケーションのチューニングには踏み込んでいませんが、実際のシステムを構築する際には重要なポイントとなります。リバースプロキシ方式の場合、連携するアプリケーションが増えてきた場合、リバースプロキシサーバの処理がパフォーマンスのネックになることが懸念されます。今回の性能検証では、リバースプロキシサーバがボトルネックにはなっていませんでしたが、連携するアプリケーションが増えた場合は、合せてリバースプロキシサーバの台数を増やすことを検討すべきでしょう。図19.スケールアップ時の考慮点
3.2.可用性試験
認証基盤は、企業システムの重要な構成要素となるため、一部に障害が発生したとしてもサービスを継続するだけの十分な可用性を担保することが求められます。可用性を向上するためには、一般的に冗長構成を検討する必要がありますが、その際に• OpenAMにおける冗長構成・ユーザリポジトリと負荷分散装置における冗長構成の両面を考慮する必要があります。以降ではそれぞれについて説明していきます。
3.2.1. OpenAMにおける冗長構成
OpenAMでは、認証基盤の可用性を向上するために冗長構成をとることができます。サイト構成とセッションフェイルオーバ構成の２つの方式があります。サイト構成の場合、サイトに参加しているOpenAMはお互いに構成情報のやり取りを行います。そのため管理コンソールはどちらのサーバにアクセスしても構成情報は共有されます。一方、ユーザのセッション情報に関しては個々のOpenAMで独立して保持し、共有しません。よって１台のOpenAMが落ちるとそのサーバで認証したセッション情報にアクセスできないため、ユーザは再ログインをする必要があります。負荷分散装置は、OpenAMのセッション情報を元にクライアントからのアクセスを振り分ける必要があります。 3.2.1.2. セッションフェイルオーバ構成セッションフェイルオーバ構成では、サイト構成に加えてセッション情報を障害に備えて保持しておく機能が組込まれています。そのため、一台のOpenAMが落ちても別のインスタンスからセッション情報にアクセスできるため、ログイン済みのユーザは処理を継続できます。セッション情報は、Message Queue Brokerを経由してamsessiondbに保持されます。OpenAMは自分が保持していないセッション情報でもMessage Queue Brokerを経由で問い合わせることに取得することができます。これにより、ユーザがログインした時と別のOpenAMにアクセスした際でも、OpenAMは処理を受け付けることができます。
3.2.2.ユーザリポジトリと負荷分散装置における冗長構成
3.2.2.1. ユーザリポジトリ
ユーザリポジトリにはOpenLDAPを利用しています。レプリケーション方式は、大きくslurpdという専用のデーモンプログラムを利用しマスタサーバから変更情報をスレープサーバへ送付する形式と、overlay機能で提供されるsyncprovモジュールを利用してスレープサーバからマスタサーバを検索して変更情報を取得する２つの方式が存在します。今回の検証では、今後の利用が多くなると予測されるsyncprovモジュールを利用したレプリケーション方式を採用しています。
3.2.2.   負荷分散装置
今回構築したOpenAM検証環境では、リバースプロキシサーバ、認証サーバ、アプリケーションサーバの冗長性を確保するために負荷分散装置（ロードバランサ）を配置しています（図 22にてLBと表記）。負荷分散装置はそれぞれのサーバへのリクエストの振り分けとサービス監視をおこなっており、サーバに障害が発生した場合でも全体としてサービスが継続できるようにするための処理を行なっています。一般のシステムにおいてよく用いられる負荷分散装置としては、F5ネットワークス社のBig-IPなどがありますが、今回の検証では、Linuxシステムにおける負荷分散ソリューションであるLVS(Linux Virtual Server)を中心に用いて検証環境を構築しました。LVSの他にもkeepalivedやiptablesなどのソフトウェアコンポーネント（OSS）を以下の用途で組み合わせて、負荷分散装置全体の機能を実現しています。 LVSを用いたネットワークトラフィック分散keepalivedを用いたサービス監視と障害サーバ回避iptablesを用いた仮想IPアドレス実現それぞれの詳細については末尾の「負荷分散装置の構成詳細」を参照ください。
3.2.3.検証目的
認証基盤は企業システムの中で重要な役割を持つため、例え一部の機能に障害が発生したとしてもサービスを継続することが求められます。そのため、この検証では、OpenAMを中心とした認証基盤の構成要素を冗長構成にして可用性を向上させることを図ります。それぞれの構成要素に障害が発生したとしても、認証基盤全体としてはサービスが継続できることを確認します。
3.2.4.  検証内容
OpenAMの冗長構成として以下の２つの方式について試験を実施します。 •サイト構成・セッションフェイルオーバ構成それぞれの構成について、各構成要茶を起動・停止を行い、認証基盤のサービスが継続できるかを確認します。テストシナリオは、性能試験と同様に、以下の２つを利用して可用性の試験を実施します。 ・シナリオ1 ：認証のみ(OpenAMへのログイン・ログアウト) ・シナリオ2 ：認証＋連携アプリケーション会議室予約システムを代理認証方式で連携
表７はサイト構成におけるテストケースを示します。 1-1では、別のプラウザからアクセスすることにより、別のOpenAMにリクエストが分散されることを確認します。どのOpenAMにアクセスしているかは、OpenAMの管理コンソールに表示されているサーバ名で確認できます。 1-2では、一台のOpenAMを停止した後、まだログインをしていないプラウザからアクセスすることにより、認証システムが継続してサービスを提供していることを確認します。 1-3、1-4では、ログイン済みのプラウザを利用して、セッション情報の有無によるOpenAMサーバ停止の影響を確認します。 1-5、1-6では、OpenAMサーバ再起動による影響を確認します。 1-7、1-8、1-9、1-10では、OpenLDAPサーバー台の啓止、再起動がOpenAMの認証システムに影響を与えないことを確認します。 1-11〜1-14では、リバプロー台のホスト停止、再起動がOpenAMの認証システムに影響を与えないことを確認します。 1-15〜1-18では、リバプロー台のApacheサービス停止、再起動がOpenAMの認証システムに影響を与えないことを確認します。 1-19〜1-22では、リバプロー台のTomcatサービス停止、再起動がOpenAMの認証システムに影響を与えないことを確認します。
2-1では、別のプラウザからアクセスすることにより、別のOpenAMにリクエストが分散されることを確認します。どのOpenAMにアクセスしているかは、OpenAMの管理コンソールに表示されているサーバ名で確認できます。 2-2では、一台のMQ Brokerを停止しても、OpenAMの認証システムに影響を与えないことを確認します。 2-3では、一台のOpenAMを停止した後、まだログインをしていないプラウザからアクセスすることにより、認証システムが継続してサービスを提供していることを確認します。 2-4、2-5では、ログイン済みのプラウザを利用して、セッション情報の有無によるOpenAMサーバ停止の影響を確認します。 2-6、2-7では、OpenAMサーバ再起動による影響を確認します。 2-8、2-9では、OpenAMセッションフェイルオーバの構成要素である、MQ  Broker、amsessiondbをそれぞれ一台ずつ停止しても、OpenAMの認証システムに影響を与えないことを確認します。 2-10〜2-13では、OpenLDAPサーバー台の停止、再起動がOpenAMの認証システムに影響を与えないことを確認します。 2-14〜2-17では、リバプロー台のホスト停止、再起動がOpenAMの認証システムに影響を与えないことを確認します。 2-18～2-21では、リバプロー台のApacheサービス停止、再起動がOpenAMの認証システムに影響を与えないことを確認します。 2-22〜2-25では、リバプロー台のTomcatサービス停止、再起動がOpenAMの認証システムに影響を与えないことを確認します。 2-26、2-27では、全てのMQ Brokerが停止していても、片側のOpenAMの認証システムだけは利用できることを確認します。 2-28、2-29では、全てのamsessiondbが啓止していても、片側のOpenAMの認証システムだけは利用できることを確認します。
3.2.5.  検証環境
検証環境も基本的に性能試験と同一の環境を利用して試験を実施します。
図22.可用性検証環境
可用性検証を行う環境としては、以下に留意しておく必要があります。 ・APサーバのセッションレプリケーション設定が必要・負荷分散装置でリバプロの監視をするときは、ApacheとTomcatの両方のサービスを考慮が必要
3.2.6. 検証結果・考察

可用性試験については、サイト構成とセッションフェイルオーバ構成の２つの方式についてそれぞれ想定した通りの結果を確認できました。サイト構成の場合、ログインしたユーザのセッション情報は、OpenAMのサーバ間で共有されないので、一台のOpenAMサーバを停止した場合、そのサーバが保持していたユーザの処理は雑続できず、新たにログインをし直す必要があります。ただし、ログインしていないユーザが新たにログインをすることには影響を与えません。セッションフェイルオーバ構成の場合、OpenAMのサーバ間でセッション情報を共有するため、一台のOpenAMサーバを停止した場合でも、そのサーバがセッション情報を保持していたユーザの処理を継続することができます。構成要素であるMQ Brokerとamsessiondbのインスタンスがサイト内に最低限１台ずつ残っていれば機能を果たすことが確認できました。しかし、構成要茶が複雑になる、OpenAMを3台以上に増やした際にスケールするかなどの懸念もあります。システムの可用性として、OpenAMサーバの障害時にユーザの再ログインを許容できるかがどちらの構成を選択するかのポイントに繋がります。再ログインをすることによりサービスが継続できるレベルの可用性であれば、シンプルなサイト構成を選択することができます。障害発生時にユーザの再ログインを許容できないのであれば、セッションフェイルオーバ構成を選択する必要があります。次期バージョンのOpenAMではセッションフェイルオーバのアーキテクチャが見直され、Message Queueなどを必要としないシンプルな構成が予定されています。新しいセッションフェイルオーバ機能に関しては、改めて検証する機会を設けたいと考えています。
3.3.セキュリティに関する考察
OpenAMはアーキテクチャ上、ユーザはログインの際にOpenAMの認証画面に直接アクセスする必要があります。そのため、外部ネットワークからの接続をユーザに対して提供する場合は、OpenAMサーバ自体をDMZに配置する必要があります。その際には、外向きのFireWallによりOpenAMサーバへのアクセスを制限する、OpenAMサーバでの余分なサービスを上げない、リモートからのOSログインを制限するなど一般的なセキリティ対策は必須となります。またOpenAMでは、標準のフル機能を備えたWARモジュール以外に、管理コンソールのみ・管理コンソール以外、など用途を制限して配置可能となっています。DMZには管理コンソール以外の機能を提供するOpenAMを配置し、内部ネットワークに管理コンソールのみを配置すれば、よりセキュリティを向上することができます。認証DBとなるOpenLDAPなどのユーザリポジトリは、直接ユーザからアクセスする必要は無いので、内部ネットワークへ配置し、OpenAMサーバからのみアクセスできるように内部FireWallで制限をしておくべきでしよう。まとめると、セキュリティを考慮したOpenAMの構成に関する考慮点は以下のようになります。 • OpenAMサーバは、DMZに配置する際は管理コンソールの機能を外したものとする・ユーザリポジトリは、内部ネットワークに配置OpenAMはJavaを中心に実装されたWebアプリケーションを基本構成としているため、一般的なWebアプリケーションの脆弱性(パラメータ改さん、SQLインジェクション、など)が存在するリスクもあります。そのような脆弱性を確認するための手法としてチェックツールを使う方法があります。なおOpenAMの前身である、OpenSSOはセキュリティの国際規格であるISO/IEC15408(Common Criteria)に準拠しています¹。従ってOpenAMも同様に準拠していることが期待できます。ここでは、Googleにより開発・提供されている脆弱性チェックツールratproxyとskipfishを使ってOpenAMのチェックを実施しました。これらのツールには、大規模なインターネットサービスを提供するGoogle社が実際に遭遇した攻撃パターンなどのノウハウが蓄積されており、またOSSとして提供されているため広く使われています。ratproxyはproxy型の脆弱性チェックツールで、ratproxyをプロキシとして設定してWebアプリケーションを操作することで、XSS(Cross Site Scripting)や不適切なXSRF(Cross Site Request Forgeries)対処など、各種の脆弱性を検出できます。skipfishは、指定したURLをクロールすることで同様の脆弱性を検出できます。表 11、表 12にそれぞれのツールによる脆弱性のチェックをOpenAMの管理コンソールに対して実施した結果を示します。
表 12.   skipfish2.05bによるチェック結果
表 IIより、①、④でXSRF対策に高・中のリスクが指摘されています。XSRFの根本的な対策はOpenAM ¹ http://docs.oracle.com/cd/E19316-01/820-3886/ghhsp/index.html OpenAM検証報告側での対応を待つ必要があります。しかし、XSRFの脆弱性に対しては、現状のOpenAMを利用する場合は、管理コンソールを扱えるユーザを制限し、かつ管理者は外部の不明なサイトへアクセスさせないという基本的な対策を講じる事で対処可能です。②、③に対しては内部でパラメータのチェックを行なっているため脆弱性はありません。表12に関しては、リスクの説明にあるように、OpenAMには脆弱性は無く今回のチェックでは誤検出でした。
3.4.  OpenAMの運用面
ここでは運用面に関してOpenAMが提供する機能・考慮する点を紹介します。
3.4.1.バックアップとリカバリー
OpenAMの設定データをバックアップするには、以下の２つを考慮する必要があります。ファイルシステム上の設定ファイルのバックアップOpenAMの設定データストアに保存されたデータのバックアップファイルシステム上の設定ファイルは、通常のバックアップツールやアーカイプコマンドを利用してバックアップする事ができます。リカバリーする際も使用するバックアップツールやアーカイプコマンドの方法に従います。
3.4.1.1.    OpenAMの設定データストアのバックアップ
OpenAMの管理コンソールで設定した情報は、設定データストアに保存されます（デフォルトでは付属のOpenDS）。これらは特殊なLDAPスキーマに保存されているため、バックアップ用のユーティリティが用意されています。バックアップには、ssoadm²コマンドを以下のように使用します。 # $SSOADM_PATH/bin/ssoadm export-svc-cfg –u amadmin –f パスワードファイル–e 暗号
化パスワード-o /tmp/openam-backup.xml
パスワードファイルには、管理者のパスワードを保存しておきます。このファイルは所有者のみが読取りできるパーミッションに設定しておく必要があります。また、バックアップしたデータはXMLファイルとなるのでパスワード情報などが平文で含まれているとセキュリティ上問題があります。そのため暗号化パスワードを指定することにより、XMLファイル内のパスワード情報などは暗号化されて保存されます。このように設定データストアの情報をバックアップしておくことにより、ハードウェア障害の他、管理者の設定ミスなど人為的な障害にも備えることができます。
3.4.1.2.  OpenAMの設定データストアのリカバリー
設定データストアのリカバリーには、前節で作成したバックアップファイルを利用します。リストア用のコマンドもssoadmコマンドを使用します。 # $SSOADM_PATH/bin/ssoadm import-svc-cfg –u amadmin –f パスワードファイル–e 暗号化パスワード–X /tmp/openam-backup.xml暗号化パスワードは、バックアップ時に指定したものと同じものを指定する必要があります。バックアップ・リカバリーの仕組みを、テスト環境から本番環境へ移行するために利用することも可能です。バックアップした設定データストアの情報は XMLファイルとなっていますので、管理コンソールで行うよりも設定の変更が容易にできます。
3.4.2. OpenAMのログ監視
OpenAMでは、コンポーネント毎にデバッグログの出力を行なっており、例外のスタックトレースなどの情報を障害時解析などに利用することができます。ログの粒度を示すデバッグレベルは、実行時に変更することができるので、トラプルシューティング時などに必要なときにだけ、詳細なデバッグログを出力するように、動的に設定することが可能です。また、デフォルトではコンポーネント毎に別ファイルにデバッグログを出力するようになっていますが、一つのファイルに出力するように変更することも可能です。デバッグログと同様に監査ログ出力も行なっています。監査ログもコンポーネント毎にアクセスファイルとエラーファイルの2つずつを出力しています。例えば、SSOに関する監査ログはamSSO.accessとamSSO.errorとなります。監査ログの有効化・無効化、ログの粒度も実行時に変更することが可能です。運用の際にはログファイルの最大長や、履歴ファイルの数を考慮する必要があるでしょう。監査ログの書式は、一般的なタプ区切りのテキストファイルですので別途監視ツールや集計ツールなどでも利用することは容易ですが、OpenAMでは特別なツールが用意されているわけではありません。また、デフォルトでは監査ログはファイルベースになっていますが、RDBMSのテープルに出力するように設定することも可能です。大規模なユーザが使う場合、ファイルベースの監査ログよりもRDBMSの監査ログの方が適しているかもしれません。ファイルベースのログには、署名により保護されたログを出力する機能もあります。この機能によりログの改竄を防ぐことが可能となります。出力されたログに対してamverifyarchiveコマンドを使用して妥当性を検証することで改竄されていないかのチェックを行います。
3.4.3.ユーザ管理
OpenAMの管理コンソールを利用してユーザの追加・修正・削除などを行うことも可能ですが、大量のユーザのメンテナンスを行うには管理コンソールは適していません。ユーザデータストアにOpenLDAPを利用している場合は、LDIFファイルを用意して、ldapmodifyコマンドを使用して一括で変更することが可能です。企業の基幹システムの認証基盤として使用するのであれば、何らかのIDM(ID管理)機能を利用することが望まれます。OpenAMではIDMの機能を提供していませんが、OpenAMをベースとした独自の製品・ソリューションを展開している各社はIDM機能を提供しています。Forgerock社もIDM機能を提供する、OpenIDMを開発中です。
4.まとめ
本レポートでは、OpenAMを中心としてOSSを活用した認証システムを構築可能であるか否かを、様々な親点から検証しました。検証では、OpenAMを中心に据えたシングルサインオン（SSO）による認証システムを構築し、システム全体の評価を行う事を目標としました。評価指標は機能、信頼性、可用性、運用性という基本的なシステム評価尺度に基いています。加えてOpenAMソフトウェア自体の脆弱性およびその対策にも触れていますが、認証システムへはインターネットなどからアクセスする場合が想定される為であり、安全なシステム構築の為には必要であると考えた為です。機能検証でのシステム構成は実用性が高いと言われているエージェント方式とリバースプロキシ方式の２方式としました。また、認証対象は社内システムとインターネットサービス（Salesforce、Googleなど）とし、被認証側はPCとスマートデバイス（iPhone）という構成にする事で、最近の新しい認証システムの利用形態を想定しました。性能検証では、アプリケーションの負荷が性能に与える影響は大きいですが、アプリケーション部分の処理負荷を事前に想定する事により、可能な限り認証システム側の性能を測定する事に配慮しました。検証環境のハードウェアスペック（仮想マシンHP社製（CPU：Intel　Xeon2.0GH z × 1 、メモリ2 GB）の２台構成で、同時1,000ユーザ程度の認証処理を行っています。また、システムへの処理要求が増加した際の対応方法についても検証過程において明らかにする事ができました。可用性検証では、サイト構成（コールドスタンバイ方式に相当）とセッションフェイルオーバ（アクティプスタンバイ方式に相当）構成を構築して、システム障害時の対応動作を確認しました。ただし、セッションフェイルオーバ構成は、障害時の復旧時間は短縮できるものの、OpenAMの次バージョンではソフトウェア構造の変更が予定されており、再検証が必要です。システム運用については、OpenAM自体は多くの設定作業を必要としない為、複雑な作業は発生しません。しかしながら、認証対象のIDの追加、削除、修正などの運用作業を効率的に行う為には、OpenAMの機能だけでは不足している為、別途ソフトウェア製品を利用するか独自のツールの開発が必要となります。認証システムは、インターネットを経由してアクセスする際にはDMZなどに配置される事になります。その際にはOpenAMがセキュリティ上の脅威にさらされることになるため、本検証ではOpenAMのソフトウェアとしての脆弱性についても各種セキュリティチェックツールを利用して評価しました。結果、システム構築時の留意点、対応策を提示していますので是非参考にして頂きたいと思います。本検証を通じて、OpenAMを利用して実用性の高い認証システムを構築する事が可能です。ただし、商用製品と比較した場合には認証IDの管理機能を具備しておらず、現時点でOpenAMの導入を検討する際には注意が必要です。しかしながら、OpenAMの開発元Forgerock社は今後、認証ID管理用ソフトウェア（OpenIDM）を提供予定であり、認証システム全てをOSSで実現する日も問近になっています。最後に本レポートの結果を活用して頂き、社内でオープンソース・ソフトウェアの利用が進むと共に、多くのソフトウェアが評価された事例と知見が、当社の財産となる事を願っています。

5.1. 認証基盤製品比較

※1：△はオプション、※2：標準機能ではなくOpenAMを提供している各社(NRIなど)独自拡張して提供※3 : Enterprise Editionの2台構成を想定。ユーザライセンスは不要でバッケージライセンスのみでよい
5.2.  OpenAMを使用する上での留意点
今回の機能検証では、OpenAM9.5.3を使用していましたが、そこで発見した２つの問題を留意点として報告します。それぞれ内容の詳細はOpenAMの環境構築ガイドを参照してください。
5.2.1.クライアント証明書認証を使う上での留意点
OpenAM9.5.3はクライアント証明書認証を使う場合、必ずCRL（証明書失笏リスト）を設定する必要があります。検証環境では、CRLを使用していなかったため問題が発生しましたが、クライアント証明書による認証を実運用で利用する場合、通常CRLを設定することになりますのでこの問題は発生しません。
5.2.2. 自動作成されたFedletを使用する上での留意点
OpenAMの管理コンソールで生成されたFedletを利用する場合、自動生成された雛形のソースコードを修正する必要があります。検証において、自動生成されたFedletを利用した際に、そのままでは動作に問題がありました（画面のレスポンスが返ってこない)。自動生成されたソースコードを修正することにより正常にFedletが動作することが確認できました。
5.3.  Basic認証APに対する代理認証
今回検証したNRIの代理認証モジュールは、Form認証のAPにしか対応していません。 Basic認証APに対する代理認証に対応する方法がOpenSSOのコミュニティで紹介されています。 ( http://java.net/jira/browse/OPENSSO-2889 )。今回の検証では動作を試していませんが参考情報としてここで取り上げます。 OpenAMには認証の後処理として独自のモジュールで処理を追加する機能が用意されています。この認証後処理においてBasic認証に必要な情報を生成し、ポリシーエージェントでその情報を元にAuthenticationへッダを付加することで、Basic認証を必要とするアプリケーションに対応する事が可能となります。
図 24.  Basic認証における代理認証の処理の流れ
OpenAMのセッションフェイルオーバのアーキテクチャは図25のようになっています。構成要素は以下の通りです。 . OpenAMユーザセッションの操作（作成、更新、削除）の際にSessionServiceを経由してMessage QueueプロV ーカとやり取りするMessage Queueプローカ. OpenAMとamsessiondbの間でメッセージの中継を行うV実体はGlassFish Message Queue Service(OpenMQ) V . amsessiondb V OpenAMからのリクエストを受取、セッション情報をBerkeley DBに格納する。メッセージはMessage Queueプローカ経由でやり取りする
5.4.1.   Message Queueブローカ
JMS（Java Message Service）の実装の一つであるGlassFish Message Serviceを利用したクラスタリング構成を取っています。GlassFish Message Serviceは、以下の２つのクラスタリングモデルをサポートしています。 Conventional broker clusters(サービス可用性) Enhanced broker clusters(サービス可用性＋データ可用性) OpenAMのセッションフェイルオーバでは前者のモデルを利用しており、データ(メッセージ)に関する可用性は保証していません。 Message Queueプローカクラスタのクライアントは、接続しているプローカとの通信に障害が発生すると自動的に再接続されます。これにより、Message Queueプローカに障害が発生しても、サービスは継続されます。 OpenAMのセッションフェイルオーバでは以下の3つのMessage Queueの宛先を、いずれもPub/Sub(1:n)モデルで利用します。 . AM_DBREQUEST（OpenAMからのリクエスト） AM_DRESPONSE(amsessiondbからのレスポンス) AM_DBNODE_STATUS(amsessiondbのステータス)
5.4.2. amsessiondb
BerkeleyDB  Java  API を利用してセッション情報の永続化を行います。 Oracle com.sun.identity.ha.jmqdb.client.FAMHaDBをメインクラスとするJavaアプリケーションとなっています。 process()メソッドにより以下の処理を繰り返します。 Message Queue AM_DBREQUESTをSubscribeしOpenAMからのリクエストを受信リクエストの内容に従いBerkeleyDBを操作結果をAM_DRESPONSE宛にPublish amsessiondbは、サイト内の他のamsessiondbの状態を監視し、一番長く稼働しているものがマスターとなります。 . AM_DBNODE_STATUSをSubscribeし、Activeなamsessiondbの情報を取得すると同時に自分の情報をPublish NodeStatusSender, NodeStatusReceiver2つのスレッドを利用1秒間隔でチェック、5秒間レスポンスが無いと死んでいると判断amsessiondbのマスター特有の機能は以下の通りです。 . READ処理でnot foundのレスポンスを返すGET_RECORD_COUNT処理のレスポンスを返す
5.4.3. OpenAM
OpenAM内部では、AMSessionRepositoryインタフェース(実装クラスはJMQSessionRepository)かamsessiondbのプロトコルに対応しています。 Message Queue Brokerへの送受信はFAMRecordJMQPersisterが担当します。 (FAMRecord send(FAMRecord famRecord)メソッド)留意点として、Message Queueへの送受信時に発生したエラーはログに出力するだけであり、クライアントには報告されません。従って、セッションフェイルオーバが機能していない場合でも、OpenAMはサービスを継続することができます。 Oのamsessiondbでは、FAMHaDBクラスがreceive()メソッドでMQ BrokerのAM_DBREQUESTからリクエストの到着を待ちます。 OpenAMではセッションの操作の際にJMQSessionRepositoryクラスのsend()メソッドでセッション情報を送信します。 ③ FAMRecordJMQPersisterクラスはpublish()メソッドでMQ BrokerのAM_DBREQUEST宛にメッセージを送信します。メッセージ送信後、receive()メソッドでMQ BrokerのAM_DRESPONSE宛にamsessiondbからのレスポ(4)ンスが到着するのを待ちます。 amsessiondbはOpenAMから到着したリクエストを受信します。 ⑤ amsessiondbは、受診したリクエストに応じてBerkeleyDBを操作し、セッション情報を永続化します。 (6) amsessiondbはpublish()メソッドでレスポンスをMQ BrokerのAM_DRESPONSE宛に送信します。のFAMRecordJMQPersisterクラスがレスポンスを受信します。 (8) JMQSessionRepositoryクラスのsend()メソッドは受信した結果を戻り値として返します。 @
5.4.5.セッションの操作とプロトコルの対応
以下にOpenAMのセッション操作とamsessiondbにおけるプロトコルの対応を示します。
表14.セッション操作とプロトコルの対応
5.5. 負荷分散裝置の構成詳細
今回の検証では、Linuxシステムにおける負荷分散ソリューションであるLVS(Linux Virtual Server)を中心に用いて検証環境を構築しました。LVSの他にもkeepalivedやiptablesなどのソフトウェアコンポーネント(OSS)を以下の用途で組み合わせて、負荷分散装置全体の機能を実現しています。 LVSを用いたネットワークトラフィック分散keepalivedを用いたサービス監視と障害サーバ回避. iptablesを用いた仮想IPアドレス実現.以下でそれぞれについて説明します。
5.5.1.   LVS (Linux Virtual Server)
・概要LVSは、linux kernelにおいてパケットレベルの振り分けを行う機能です。Kernelレベルで機能が実装されており、トランスポートレイヤ（Layer-4）での振り分けを行うことができます。LVSを利用するためには、 Linux2.6.10以上のkernelが必要です。今回のOpenAM検証環境においては、CentOS6.0に含まれるLinux2.6.32を利用しました。 ・負荷分散ネットワーク構成LVSでは以下の３方式の負荷分散ネットワーク構成をサポートしています。 (1)  NAT経由仮想サーバ（LVS/NAT）
図 27.   NAT経由仮想サーバ(LVS/NAT)構成
一度LVSの仮想アドレス（VIP）でリクエストを受けた後、宛先アドレス変換（NAT）してからServerにリクエストを送ります。Serverからの応答はLVSを経由してクライアントに返されます。Serverを構築する際に、LVS配下にあることを特に考慮する必要がなく、普通にサーバを並べればいいというのがこの構成のメリットです。また、Server-Client間のすべてのトラフィックがLVSを通ることになるので、LVSが性能的なボトルネックになってしまうというデメリットがあります。 (2)  IPトンネル経由仮想サーバ（LVS/TUN）
図 28.  IPトンネル経由仮想サーパ（LVS/TUN）構成
LVSの仮想アドレスで受けたリクエストを、サーバに向けたIPトンネルで送る方式です。この方式では、Serverからの応答は直接Clientへ返されるため、LVSがボトルネックにならないメリットがあります。また、LVSと全てのServerの間にそれぞれ個別にIPトンネルを構築・設定して維持しなければならないことや、すべてのServerがLinuxと同方式のIPトンネルプロトコルをサポートしなければならないという構成上の制約がある点がデメリットになります。 LVS/DPT方式の場合は、Clientからリクエストを受けるLVSのインタフェースとServerのインタフェースが同一サプネットに存在しなければならないという構成上の制約があります。動作としては、LVSで受けたリクエストパケットをNATによるアドレス変換やIPトンネルによるIPヘッダ付与といった処理を一切行わないで、そのまま直接Serverに転送してしまいます。Serverからの応答はClientへ直接返されます。注意すべき点としては、LVSとServerは同じVIPアドレスを受信するにもかかわらず、同一サプネットで接続されているという点が挙げられます。最初にClient側からVIPにパケットが送られるときにARPリクエストがプロードキャストされ、LVSと（複数の）Server全体にARPリクエストが届きますが、LVS以外はこのリクエストに応答してはなりません。しかし、LVSより中継された（中身が全く同一の）パケットはLVSが選定したServerが同一サプネット経由で受信する必要があります。このあたりのL2の挙動に基づく構成が複雑になってしまうというのがLVS/DPT方式のデメリットといえます。この問題に対応する方法としては、ServerにてVIPをループバックインタフェースに設定し、同時にARPに応答しないような特殊な設定をおこなうという方法や、iptablesを用いて実現する方式があります。今回の検証では、両パターンについて試行を行いましたが、後者のiptablesを使う方式のほうが設定項目がシンプルで、安定的に稼働させることができました。 iptablesを用いた方式については後述します。以上、３方式のうち、今回のOpenAM検証においては、一般的に最も実用的であるLVS/DPT方式で検証を行いました。
•負荷分散方式
LVSでは複数のサーバに対して処理を振り分けるスケジューリング方式として、Round-Robin、Weighted Round-Robin、Least-Connection、Weighted Least-Connectionの４方式をサポートしています。
(1)Round-Robin
Round-Robinスケジューリングでは、すべてのサーバに対して順番にコネクションを割り振る方式です。サーバのレスポンス時間やコネクション数の違いにかかわらず、すべてのサーバに対して単純に順番に新コネクションを割り振ります。
(2)Weighted Round-Robin
Weighted Round-Robinスケジューリングは、サーバごとに異なる重みを割り当てることができます。重みは整教値でデフォルトは１です。サーバに設定した重みの割合に応じてコネクションを順番に割り振ります。
(3)Least-Connection
Lest-Connectionスケジューリングはアクティプなコネクションが一番少ないサーバに新たなコネクションを割り振る方式です。性能が同じ性能のサーバを並べた場合にはうまく平等に負荷を分散することができます。性能に違いがあるサーバを並べた場合でもコネクション数に応じた割り振りが行われるためうまく負荷が分散されるように思えますが、実際にはTCPのTime-Waitステートが２分間続くため、うまく負荷に応じた分散はできません。
(4)Weighted Least-Connection
Weighted  Least-Connection スケジューリングはアクティプなコネクション数に応じた割り振りをサーバ毎に異なる重みづけで行うことができます。
• Session Persistence
上記４方式のいずれの負荷分散方式においても、Clientより新たなコネクションリクエストが送られると、毎回新たにServer遷定プロセスが実行され、同一Clientから複数Serverにコネクションが張られることになりますが、通常のWebアプリケーションではセッションを維持する必要があるため、Clientに対するServerを一度決めたらそれ以降のリクエストは同じサーバに送ることが必要になります。このようなセッション維持の方式には、URLパラメータを用いるものやクッキーを用いるものやIPアドレス情報を利用する方式がありますが、LVSではソースIPアドレス方式のみサポートしています。今回のOpenAM検証におけるLVS構成は以下のとおりとしました。負荷分散ネットワーク構成： LVS/DPT .負荷分散方式： Least-Connection . Session Persistense：あり. OpenAMをLVSで負荷分散する場合には、この構成をとることにより負荷分散がうまく行われることを確認しました。 LVSを動作させるためには、LVSに対応したカーネルを動作させた上で、ipvsadmコマンドによって、カーネル内の振り分けテープルをひとつひとつ設定する必要がありますが、後述するkeepalivedなどの元長化ソフトウェアを用いて自動的にLVSの振り分けテープルを設定するのが一般的です。今回のOpenAM検証においてはkeepalivedを用いてLVS設定を行いました。
5.5.2. keepalived
LVSを用いることで負荷分散機能そのものは実現することは可能ですが、LVSには実サーバを監視する機能がなく、実サーバに障害が発生してもその実サーバにリクエストを送り続けてしまいます。この課題に対応するためには別途冗長化ソフトウェアを組み合わせて負荷分散環境を構築する必要があります。今回のOpenAM検証では、keepalivedを用いた方式について検証を行いました。 keepalivedはLVSと組み合わせて冗長化機能を実現するためのOSSで、keepalivedを動作させることにより以下の機能が実現されます。 1.  LVSの振り分けテープルの制御実サーバの死活チェック2. LVS自体のVRRPによる冗長化3.
図 30.  Keepalivedの構成
今回のOpenAM検証では１と２について確認を行いました。実際のサービス環境においてkeepalivedを用いる場合にはkeepalived自身の冗長化を行ったほうがいいと思いますが、その場合は事前検証を行うべきです。
5.5.3.   iptablesを用いたL2特殊処理
LVSの章で述べましたが、今回のOpenAM検証においてはLVSの負荷分散ネットワーク構成としてLVS/DPSを採用したため、L2ネットワーク的に特別に考慮しなければならない点があります。以下の図は、Client、LB、Server1、Server2は同一のプロードキャストドメイン（IPサプネット）に接続されている状態を例示したものです。各インタフェースにはそれぞれ同一サプネット内のIPアドレスが設定されており、LBにはReal IPアドレスに加えて、Clientからのリクエストを受けるためのVirtual IPアドレス(VIP)の設定がされています。ClientからVIP宛のパケットを送るとき、まずL2アドレス解決のためにClientよりARPリクエストがプロードキャストされ、これにLBが応答し、VIP宛のパケットはまずLBに送られることになります。Server1とServer2についてもLB経由でVIP宛のパケットを受け取る必要があるので、 VIPに関する設定が必要ではありますが、ClientからのARPリクエストに応答してはならないため、通常の用にインタフェースにIPアドレスを設定することは出来ません（図では括弧つきアドレスで表記）。
図 31.  LVS/DPSのネットワーク構成
LBで振り分け処理が行われた後にServerヘパケットが送られますが、この時パケットの宛先アドレスがVIPのままでServer1かServer2に送られます。したがって、Server1とServer2はVIP先のパケットについても自分アドレス宛と同様に受信する必要があります。まとめると、以下のようになります。 (1)  LBはVIP宛のパケットを受信しなければならない(2) 実サーバ（ServerlとServer2）はVIP宛のパケットを受信しなければならないがARPに応答してはならない(1)を実現するために、LBにおいて以下のようにVIPアドレスをインタフェースに追加します。 LB# ip addr add 192.168.1.1 dev eth0 LBにて、iptalbesおよびポリシールーティングを設定します。 LB# iptables -t mangle -A PREROUTING -d 192.168.1.1 -j MARK -set mark 1 LB# ip route add local 0/0 dev lo table 100 LB# ip rule add prio 100 fwmark 1 table 100この設定により、LBにてVIP宛のパケットを処理できるようになります。 OpenAM検証報告(3)を実現するために、実サーバ（Server1とServer2）において、以下のような設定を行います。 Server1# iptables -t nat -A PREROUTING -d 192.168.1.1 -j REDIRECTこの設定により、実サーバにおいて、VIP先のパケットを処理するようになります。
ssoadmコマンドをOpenAMのサイト構成で利用する場合、以下のように正常に動作しないという問題があります。 3 # ./ssoadm …この場合、ssoadmコマンド(スクリプト)を修正し、以下の設定を追加することで正常に動作するようになります。 -D"com.iplanet.am.naming.map.site.to.server= https://lb.example.com:443/openam=https://server1.example.com:443/openam,https: //lb.example.com:443/openam=https://server2.example.com:4438080/openamここでは下のような構成を仮定しています。 • https://lb.example.com:443 サイトのURL • https://server1.example.com:443/openam　サイトの属するOpenAMサーバインスタンス1 • https://server2.example.com:443/openam　サイトの属するOpenAMサーバインスタンス2 OpenAM検証報告
5.7.関連情報
• OpenAM開発元であるForgeRock社のサイト> http://www.forgerock.com/ • OpenAMコンソーシアムA http://www.openam.jp/