OpenSSOでSSOを実践
用途をWebに限定してWebの用語でOpenSSOを説明します。最初に目的を設定して、目的どおりに動かすために何が必要かを説明します。
OpenSSOは難しい
やっていることの割にOpenSSOが難しく感じる理由
- 用語が独特(OpenSSO自体はWeb固有の技術ではないので、Webの用語で説明して欲しい所でWebの用語を使ってくれない)
- 自由度が異常に高い
- SSO界隈には、説明を難しくすることで得をしている人がいる(たぶん)
この文書の方針
- 用途をWebに限定してWebの用語で説明する
- 最初に目的を設定して、目的どおりに動かすために何が必要かを説明する
用語
- 認証処理をOpenSSOに任せるWebアプリを「SSO対象Webアプリ」と呼びます
- Webのクライアントを指す用語は「Webブラウザ」で統一します
- 「Webブラウザ」は暗黙にSSO対象Webアプリの利用者も意味します
参考サイト
- http://sdc.sun.co.jp/javasystem/techtopics/identity/index.html
- http://developers.sun.com/identity/reference/techart/app-integration.html
- http://planets.sun.com/OpenSSO/
- http://wikis.sun.com/display/OpenSSO/agentsample_ja
日本語の簡易スタートアップ
- http://wikis.sun.com/display/OpenSSO/getstarted_ja
- http://wikis.sun.com/display/OpenSSO/samplepolicy_ja
SSOの実例
SSOの構成
SSOを実現するシステムは、一般的にリバースプロクシ型とエージェント型に分類されます。この分類に従えばOpenSSOはエージェント型です。
しかし一般的なエージェント型から受ける印象とは少し違い
- エージェントに相当するモジュールがpolicy agentとして提供されているので(apacheのモジュールやtomcatのフィルタ)、対応済みのWebサーバやアプリケーションサーバであればSSO対象Webアプリにエージェントのコードを組み込む必要はありません
- (後述するように)policy agentをモジュールとして組み込んだapacheをリバースプロクシにすれば、リバースプロクシ型としてOpenSSOを動かせます
個人的に、この分類はそれほど重要だとは思っていません。より重要な分類は、SSO対象アプリ側のコードに「手を入れる必要があるか否か」の分類の方です。これは後述します。
認証と認可
OpenSSO無の世界
ログイン処理 [Webブラウザ] ===> [SSO対象Webアプリ] userid password 認証処理 => フォーム認証であれば、受け取ったuseridとpasswordで検証。普通はWebアプリが自前で管理するRDBをひくか、ディレクトリサーバに問い合わせる (必要なら)認可処理 => Webアプリの観点では利用者をセッション処理の管理下において、利用者ごとに何ができるかを制限すること
少し乱暴ですが、Webアプリを次の2つに分類します。
- 認証処理のみ: Webアプリから見ると、アクセスできる人を制限しているだけ
- 認証処理と認可処理: Webアプリから見ると、セッションに紐付いたユーザの識別をしている
イメージ的には前者は単にアクセス制限しただけのWebサイト、後者はログイン処理を必要とするWebアプリです。以後の説明のため、前者を「制限したWeb」、後者を「要ログインWeb」と呼ぶことにします。
OpenSSO導入の目的
- 自作のWebアプリ(「SSO対象Webアプリ」)の認証処理をOpenSSOに任せること
認証処理をOpenSSOに任せるメリット
- 各Webアプリが独自に認証処理を実装する手間がなくなる
- システム管理者から見ると、ユーザ管理を一元管理できる(ユーザ追加、削除、パスワード変更などが一回で済む。各Webアプリが単一のディレクトリサーバを参照する形の認証処理でも実現できることですが)
- 利用者から見ると、各Webアプリのログインごとにパスワードを入力する手間が減る(いわゆるシングルサインオン(SSO))
認可処理について
- 識別したユーザに応じてWebアプリが何をするか、たとえばユーザごとに見せる画面を変えたり、アクセス制御に使ったり、を定義したルールをユーザ権限やユーザプロファイルと呼びます
- Webアプリがユーザ権限を参照して処理することを「認可処理」と呼びます
- 「認可処理の集中管理」もSSOの一環ですが、この文書では説明しません。理由は個人的に必要性を感じないからです
以下、認可処理はあくまでSSO対象Webアプリが行う前提です
policy agentとは
- (SSO対象Webアプリへの)リクエストを横取りしてOpenSSOに流すモジュール(apacheのmoduleやtomcatのフィルタとして実装)
- policy agentは、SSOToken(実体はcookieなどで運ばれる文字列)の有無で、認証済みか否かを判断
- OpenSSOとは別配布(Tomcat用policy agent、Apache用policy agentなど)
- OpenSSO SDKを使って自分で書くことも可能 => 認証処理をOpenSSOに任せるだけなら、普通は不要(メジャーなサーバ用に既に提供されているので)
アーキテクチャ概論(タイムライン)
- WebブラウザでSSO対象Webアプリにアクセス
- SSO対象Webアプリのリクエストを横取りしたpolicy agentがOpenSSOサーバへのリダイレクトを返す
- WebブラウザがOpenSSOサーバにアクセス
- OpenSSOがログイン画面を返す
- 利用者がユーザIDとパスワードを入力
- OpenSSOサーバは裏側でディレクトリサーバなどを使って認証
- 認証が通ると、OpenSSOサーバは、tokenをクッキーにセットして、SSO対象アプリへのリダイレクトを返す(同じドメインの場合)
- SSO対象サーバのリクエストを横取りしたpolicy agentがtokenを使ってOpenSSOサーバと通信して認証済みかを確認
- SSO対象サーバが認証結果に応じたレスポンスを返す
=> policy agentがすべて面倒を見てくれるので、policy agentに任せると、SSO対象Webアプリは裏側の動作を知る必要はない
「制限したWeb」でのSSO対象Webアプリの責務
- (適切に設定すれば)すべてのアクセスがpolicy agentに横取りされる
- 認証済みのアクセスだけがSSO対象Webアプリに来る
結局、SSO対象Webアプリがやることは何もない
policy agentをすり抜けるアクセスがあるとアクセス制御に穴が開きますが、これは(apacheの)設定をミスってBASIC認証に穴が開くのと同じことなのでOpenSSO固有の課題ではありません
「要ログインWeb」でのSSO対象Webアプリの責務
- (適切に設定すれば)すべてのアクセスがpolicy agentに横取りされる
- 認証済みのアクセスだけがSSO対象Webアプリに来る
認可処理のために認証処理済みユーザの情報を取得する方法
- 一番簡単なのはリクエストヘッダ(独自ヘッダやクッキーヘッダなど)で取得する方法
- 標準準拠にこだわるならSAMLで取得する
この文書では前者で説明します。どちらにしろ、SSO対象Webアプリのコードに手をいれる必要があります
policy agentをすり抜けるアクセスがあるとアクセス制御に穴が開きます。「要ログインWeb」のWebアプリはOpenSSO対応以前はログイン処理を実装しているはずです。これをスキップする穴を開けることになるので注意が必要です。
これから説明するふたつの構成図
- Tomcat上で動くWebアプリをOpenSSOの対象にします
- Webアプリは「要ログインWeb」を前提にしています
Tomcat上のWebアプリにpolicy agentを組み込む
[Webブラウザ] ====> [Tomcat policy agent|SSO対象Webアプリ(認可処理)] ^ | v [OpenSSOサーバ(認証処理)]
Apacheにpolicy agentを組み込み、Tomcatの前にリバースプロクシとして設置
[Webブラウザ] ====> [apache ====> [Tomcat policy agent] SSO対象Webアプリ(認可処理)] ^ | v [OpenSSOサーバ(認証処理)]
模式図なので、HTTPのやりとりは上記「アーキテクチャ概論(タイムライン)」を参照してください。
OpenSSOの配布物
- Enterprise版とExpress版がある
- OpenSSO Enterprise 8.0 (= OpenSSO Express Build 6) というバージョン番号の対応 注意: Enterprise8.0とExpress build7の場合、後者の方が新しい
嫌がらせのようにわかりにくい...
この文書で使うバージョン
- Tomcat6.0.20
- apache2.2.x
- OpenSSO Enterprise 8.0
OpenSSOサーバの構成
- 実体はJavaのサーブレットアプリ(opensso.war)
- この文書では、アプリケーションサーバとしてTomcatを使います
- ディレクトリサーバはOpenSSO組み込み(OpenDSベース?)を使います
必要な作業(概論)
- OpenSSOのdeploy(Tomcatにdeploy => これをOpenSSOサーバと呼びます)
- OpenSSOサーバの設定(基本的にWebブラウザから設定可能)
- SSO対象WebアプリのTomcatにpolicy agentをdeploy
- policy agent用の設定(基本設定はpolicy agent付属のスクリプト(agentadmin)で実施。細かい部分は設定ファイルを記述)
- SSO対象Webアプリにフィルタ設定(web.xml)
- (必要なら)適切な認可処理できるようにSSO対象Webアプリ側のコードを改変
説明に使う環境(1)
1台のPCで試験しています
- OpenSSOサーバ用のTomcat(ポート8080)
- SSO対象Webアプリ用のTomcat(ポート8081)
- (リバースプロクシ用の)apache(ポート80)
policy agnetを/home/inoue/Work/opensso/に展開しています。抽象的なパスにするよりわかりやすいと判断してそのまま書いています。
説明に使う環境(2)
URLをlocalhostでアクセスするとうまく行かないという記事を見つけました。 裏は取っていませんが、こんなことではまると嫌なので、以下、URLのFQDNはo.ariel-networks.comで説明します。
OpenSSOのdeployとセットアップ
- opensso.warをTomcatのwebappsディレクトリに手動コピー
- http://o.ariel-networks.com:8080/opensso にWebブラウザでアクセス。 OpenSSOサーバのセットアップ画面になります
- Webブラウザ上でセットアップします
スーパーユーザ: amAdmin password エージェントユーザ: UrlAccessAgent password00
- ユーザIDとパスワードは好きにつけてください
設定ファイルの実体はデフォルトではホームディレクトリ以下のopenssoディレクトリ(e.g. /home/inoue/opensso)にできます(微妙に気持ち悪い)。
OpenSSOサーバの管理画面
- http://o.ariel-networks.com:8080/opensso にWebブラウザでアクセスするとOpenSSOサーバの管理画面にログインできます
- 管理コンソールへのログインは amAdmin で行えます
管理項目が多すぎて大変ですが、アクセス制御タブの「レルム」を選んで色々設定するのが基本です
OpenSSO管理対象の構造
管理コンソール / アクセス制御 / レルム / エージェント - (後述する)policy agentに対応する設定項目 => エージェントプロファイル作成 - Tomcatのpolicy agentの場合はJ2EEを選択 - apacheのpolicy agentの場合はWebを選択
エージェントプロファイルに対して設定することで、認証済みリクエストにヘッダ追加やクッキー追加など色々できる(属性フェッチ機能)
管理コンソール / アクセス制御 / レルム / ポリシー - エージェントプロファイルにぶらさがる複数のポリシー作成 - ポリシー: URLごとに許可ユーザ(orグループ)を指定 - ルール: URLで指定可能 - 対象: OpenSSOアイデンティティー対象を選択して、ユーザもしくはグループを指定可能
管理コンソール / アクセス制御 / 対象 - OpenSSO組み込みのディレクトリサーバの設定 - ユーザ追加、削除、編集 - グループ追加、削除、編集
Tomcatにpolicy agentをdeployする手順
- OpenSSOサーバの管理画面からpolicy agentに対応するエージェントプロファイルを作成して設定
- policy agent付属のagentadminコマンドラインツールを実行
- SSO対象Webアプリにフィルタとしてpolicy agentを組み込む
OpenSSO管理画面でpolicy agent用の設定(1)
管理コンソール / アクセス制御 / レルム / エージェント / J2EE - エージェントプロファイル作成 - ユーザID: agentadminuser - パスワード: password
- ユーザIDとパスワードは好きにつけてください
- このユーザIDとパスワードが次のagentadminコマンド実行時に必要です
agentadminコマンド実行
$ ./agentadmin --custom-install
- 質問(Tomcatのパスなど)に答えるとインストール終了します
- コマンド実行中、(policy agentをdeployする)SSO対象Webアプリが動くTomcatは停止しておく必要があります
- つまり、OpenSSOが動くTomcatと同じTomcatにはpolicy agentをdeployできません
agent.jar
- policy agentの実体です(サーブレットアプリのフィルタとして動作します)
- agent.jarをSSO対象Webアプリ用Tomcatのlibディレクトリに手動コピーしす(agentadminコマンドがコピーしてくれなかったので)
agentadminコマンドの内部的な動作
- /home/inoue/Work/opensso/j2ee_agents/tomcat_v6_agent/Agent_001/config/に設定ファイルを生成
- setAgentclasspath.shの追加とsetclasspath.shの書き換え(下記参照)
- SSO対象Webアプリ用Tomcatのserver.xmlを書き換えるが、あまり本質的ではない様子
SSO対象Webアプリ用Tomcatに必要な最小限のファイル
- libディレクトリ下のagent.jar
- binディレクトリ下のsetAgentclasspath.sh
- binディレクトリ下のsetclasspath.shからsetAgentclasspath.shを呼び出す行
SSO対象Webアプリのweb.xmlにフィルタ設定
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLoc ation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> 以下を追記 <filter> <filter-name>Agent</filter-name> <filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class> </filter> <filter-mapping> <filter-name>Agent</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>INCLUDE</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>ERROR</dispatcher> </filter-mapping>
- 動かない場合、tomcat_v6_agent_3.zipに含まれているサンプル(agentapp.war)のweb.xmlを参照してください
ここまででできたこと(中間チェックポイント)
- SSO対象Webアプリのフィルタ設定によりSSO対象Webアプリへのアクセスがpolicy agentに横取りされる
- policy agentはOpenSSOサーバと認証処理のために通信する
- OpenSSOサーバはエージェントプロファイル設定を見て認証処理を行う
ここから必要なこと
- OpenSSOサーバ側でどんな認証処理をするかの設定。つまり、どのURLに誰がアクセスできるかを設定
- 「要ログインWeb」の場合、認証済みユーザの情報をどのようにSSO対象Webアプリに引き渡すかを設定(属性フェッチ機能)
ポリシー設定
管理コンソール / アクセス制御 / レルム / ポリシー ルール例: rule0 URL http://o.ariel-networks.com:8081/simple/* メソッド GET POST 対象例: ユーザinoueを選択
これで、http://o.ariel-networks.com:8081/simple/以下へのアクセスがユーザinoueだけに許可される
プロファイル属性設定
管理コンソール / アクセス制御 / レルム / エージェント / J2EE / エージェントプロファイル / アプリケーション / プロファイル属性処理 - 対応するマップ値」 => HTTPヘッダ名(SM_USERなど任意。ちなみにSM_USERはSiteMinderが使うヘッダ名) - 「マップキー」 => HTTPヘッダの値(cnなど。X.500ベースの属性名)
この設定で、SSO対象Webアプリは認証済みユーザの情報をHTTPヘッダで読み取れます
SSO対象Webアプリの認可処理
- policy agentのプロファイル属性処理に従い、HTTPヘッダの値から認証済みユーザの情報を取得
- 上記ヘッダの値のユーザを認証済みと見なして認可処理を行う
- 既にログイン処理を実装済みのWebアプリであれば、ログイン処理をスキップするコードに変更する
apache2.2にpolicy agentをdeployする手順
基本はTomcatの場合と同じです
- OpenSSOサーバの管理画面からpolicy agentに対応するエージェントプロファイルを作成して設定(エージェントプロファイルがJ2EEではなくWebを選ぶことに注意)
- policy agent付属のagentadminコマンドラインツールでdeploy
OpenSSO管理画面でpolicy agent用の設定(for apache2.2)
管理コンソール / アクセス制御 / レルム / エージェント / Web - エージェントプロファイル作成 - ユーザID: agentadminuser - パスワード: password
J2EEの代わりにWebを選ぶ以外はTomcatの場合と同じです
agentadminコマンドの内部的な動作(for apache2.2)
- /home/inoue/Work/opensso/web_agents/apache22_agents/Agent_001/config/に設定ファイルを生成
- httpd.confを書き換える(下記参照)
httpd.conf に以下が追加される include /home/inoue/Work/opensso/web_agents/apache22_agent/Agent_001/config/dsame.conf
apache2.2のpolicy agentでの問題と解決策
上記手順に従っても動きません。エラーメッセージはこの文書を最後を参照してください
解決策
管理コンソール / 設定 / サーバおよびサイト / サーバ選択 / セキュリティ / Cookie 値のエンコード => なぜか管理画面から設定できない(bug?)
仕方ないので
管理コンソール / 設定 / サーバおよびサイト / サーバ選択 / 高度 で次のプロパティを設定(値はtrue) com.iplanet.am.cookie.encode
これで解決しました(やれやれ)
Apacheをリバースプロクシとして動作させればリバースプロクシ型で動作するOpenSSO環境ができます
OpenSSOのトラブルシューティング
- 注意: OpenSSOサーバが起動していることを確認してからSSO対象Webアプリ側のTomcatを起動すること(順序が逆だと動きません)
詳細ログを出す方法
管理コンソール / /アクセス制御 / レルム / エージェント / Web/ agentadminuser2/ 一般 / デバッグレベル:エージェントデバッグレベル => 「すべて」に変更
ログの出力パス
/home/inoue/Work/opensso/web_agents/apache22_agent/Agent_001/logs/debug/amAgent
policy agentのエラーコード一覧
apache2.2のpolicy agentで出るエラー(参考)
Webで検索する人向け
2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <RequestSet vers="1.0" svcid="com.iplanet.am.naming" reqid="10"> <Request><![CDATA[ <NamingRequest vers="3.0" reqid="2" sessid=""AQIC5wM2LY4SfcyX2UmNzn3IREpGqPSEWCS0FooTF1y2p3w=@AAJTSQACMDE=#""> <GetNamingProfile> </GetNamingProfile> </NamingRequest>]]> </Request> </RequestSet> 2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: BaseService::sendRequest Request line: POST /opensso/namingservice HTTP/1.0 2009-10-27 19:06:19.389 Debug 12733:83e0f60 NamingService: BaseService::sendRequest Cookie and Headers =Host: o.ariel-networks.com 2009-10-27 19:06:19.389 Debug 12733:83e0f60 NamingService: BaseService::sendRequest Content-Length =Content-Length: 335 . 2009-10-27 19:06:19.389 Debug 12733:83e0f60 NamingService: BaseService::sendRequest Header Suffix =Accept: text/xml Content-Type: text/xml; charset=UTF-8 2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: BaseService::sendRequest(): Total chunks: 7. 2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: BaseService::sendRequest(): Sent 7 chunks. 2009-10-27 19:06:19.396 Debug 12733:83e0f60 NamingService: HTTP Status = 500 (Internal Server Error) 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Http::Response::readAndParse(): Reading headers. 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Server: Apache-Coyote/1.1 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Content-Type: text/html;charset=utf-8 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Date: Tue, 27 Oct 2009 10:06:19 GMT 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: Connection: close 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: Http::Response::readAndParse(): Reading body content of length: 13147527253975893888 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 all: Connection::waitForReply(): returns with status success. 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: Http::Response::readAndParse(): Completed processing the response with status: success 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: <html><head><title>Apache Tomcat/6.0.20 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTPステータス 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> 例外レポート</p><p><b>メッセージ</b> <u></u></p><p><b>説明</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>例外</b> <pre>javax.servlet.ServletException: AMSetupFilter.doFilter com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:117) </pre></p><p><b>原因</b> <pre>java.lang.NullPointerException com.iplanet.services.naming.service.NamingService.processRequest(NamingService.java:346) com.iplanet.services.naming.service.NamingService.process(NamingService.java:337) com.iplanet.services.comm.server.PLLRequestServlet.handleRequest(PLLRequestServlet.java:185) com.iplanet.services.comm.server.PLLRequestServlet.doPost(PLLRequestServlet.java:134) javax.servlet.http.HttpServlet.service(HttpServlet.java:637) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:91) </pre></p><p><b>注意</b> <u>原因のすべてのスタックトレースは、Apache Tomcat/6.0.20のログに記録されています</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.20</h3></body></html> 2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <RequestSet vers="1.0" svcid="com.iplanet.am.naming" reqid="10"> <Request><![CDATA[ <NamingRequest vers="3.0" reqid="2" sessid=""AQIC5wM2LY4SfcyX2UmNzn3IREpGqPSEWCS0FooTF1y2p3w=@AAJTSQACMDE=#""> <GetNamingProfile> </GetNamingProfile> </NamingRequest>]]> </Request> </RequestSet> 2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: BaseService::sendRequest Request line: POST /opensso/namingservice HTTP/1.0 2009-10-27 19:06:19.389 Debug 12733:83e0f60 NamingService: BaseService::sendRequest Cookie and Headers =Host: o.ariel-networks.com 2009-10-27 19:06:19.389 Debug 12733:83e0f60 NamingService: BaseService::sendRequest Content-Length =Content-Length: 335 . 2009-10-27 19:06:19.389 Debug 12733:83e0f60 NamingService: BaseService::sendRequest Header Suffix =Accept: text/xml Content-Type: text/xml; charset=UTF-8 2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: BaseService::sendRequest(): Total chunks: 7. 2009-10-27 19:06:19.389MaxDebug 12733:83e0f60 NamingService: BaseService::sendRequest(): Sent 7 chunks. 2009-10-27 19:06:19.396 Debug 12733:83e0f60 NamingService: HTTP Status = 500 (Internal Server Error) 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Http::Response::readAndParse(): Reading headers. 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Server: Apache-Coyote/1.1 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Content-Type: text/html;charset=utf-8 2009-10-27 19:06:19.396MaxDebug 12733:83e0f60 NamingService: Date: Tue, 27 Oct 2009 10:06:19 GMT 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: Connection: close 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: Http::Response::readAndParse(): Reading body content of length: 13147527253975893888 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 all: Connection::waitForReply(): returns with status success. 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: Http::Response::readAndParse(): Completed processing the response with status: success 2009-10-27 19:06:19.397MaxDebug 12733:83e0f60 NamingService: <html><head><title>Apache Tomcat/6.0.20 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTPステータス 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> 例外レポート</p><p><b>メッセージ</b> <u></u></p><p><b>説明</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>例外</b> <pre>javax.servlet.ServletException: AMSetupFilter.doFilter com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:117) </pre></p><p><b>原因</b> <pre>java.lang.NullPointerException com.iplanet.services.naming.service.NamingService.processRequest(NamingService.java:346) com.iplanet.services.naming.service.NamingService.process(NamingService.java:337) com.iplanet.services.comm.server.PLLRequestServlet.handleRequest(PLLRequestServlet.java:185) com.iplanet.services.comm.server.PLLRequestServlet.doPost(PLLRequestServlet.java:134) javax.servlet.http.HttpServlet.service(HttpServlet.java:637) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:91) </pre></p><p><b>注意</b> <u>原因のすべてのスタックトレースは、Apache Tomcat/6.0.20のログに記録されています</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.20</h3></body></html>