Commentこの記事は1年以上前に投稿された記事で現在は正しい情報とは限りません。以前、OpenAMを使ってSAML2.0でSSOをする記事を書きましたが、SAML2.0を使ったSSOだとWebアプリケーション側が対応してないケースが多く、実装も困難であるため任意のWebアプリケーションに対するSSOの手段としてあまり適用できません。いうことで、今回から「OpenAMを認証プロバイダにして任意のWebアプリに対してシングルサインオン」をする方法に関して書いてみます!SAML以外の方法で任意のWebアプリに対してOpenAMを使ってSSOするには以下のパターンがあります。Agent(リクエストを監視するソフトウェア)をインストールしてHTTPのアクセスを監視。認証していなければOpenAMへの認証要求(リダイレクト)をする仕組みになっています。フローは以下のようになります。AgentがインタラプトしてCookieが入っていなければOpenAMにリダイレクト→OpenAM側で認証(OpenAM側でセッション+Cookie発行)してWebアプリにリダイレクト→リダイレクト先でCookieを発行(cdcservlet)→Webアプリへのアクセス(Cookieが発行されているためAgentが認証済みとして処理)参考URLは以下のとおり。参考URL見た方がわかりやすい説。名前とパスワードは適当に(2で使います)サーバーURLはOpenAMのURLを入力。エージェントURLはWebサーバーのURLを入力。作成した後に詳細な設定ができます。適用されないURLは認証を必要としないURLを入力。適用されないURLの反転の有効にチェックを付けると上記設定が「適用されるURL」、つまり「認証を必要とするURL」に変更されます。SSO対象のドメインが異なる場合(サブドメインが異なるのはOK)は、Cookieドメインリストに対象のドメインを入力します。クロスドメインのSSOでこれを設定しないと挙動がおかしくなります。(私の場合は認証無限ループしました)認証した証拠となるCookieの名前は以下で設定します。デフォルトはiPlanetDirectoryProです。Agentを使います。OSはUbuntuで。stopでstopします。Agentを以下サイトからダウンロード。--install設定例は以下のとおり。apache2の設定フォルダ:/etc/apache2OpenAMのURL:http://test.example.com:8080/openamWebアプリ(SSO対象)のURL:http://hoge.fuga.com:80エージェントの設定の名前(OpenAMで設定したエージェントの名前):ApacheAgentパスワードファイル:/home/hoge/.passwdインストール時にWebサーバの設定ディレクトリを聞かれますが、設定ディレクトリというよりもhttpd.confが含まれるディレクトリを指定してください。Agentの設定が追記される仕様なので、CentOSとかだとhttpd.confがあるのでそのまま設定ディレクトリを指定してあげればOKですが、Ubuntuとかだとapache2.confがメインの設定ファイルなのでhttpd.confを意図的に作成しないといけません。directory」って言われます。/home/hoge/web_agents/apache24_agent/Agent_001/config/dsame.confが書き込まれているので、これを本物の設定ファイルapache2.confの末尾にコピーします。テストアプリをWebアプリケーションとして設置。OpenAMから発行されたCookieを元に認証を行うアプリを作成します。今回はPython/Flaskで。Trueapp.run()OpenAMの設定で認証CookieキーをiPlanetDirectoryProとしているので、そのCookie値(token)を取得。APIを叩いてtokenの検証をした後にユーザ属性情報を取得します。validateのレスポンスはこんな感じ。"/"}ユーザ属性はこんな感じ。[]}あとはOpenAMのユーザ情報をWeb側のユーザ情報とマッピングしSession張るなりすればOK。apache→flaskのリバースプロキシをしたいので、以下の一文をapache2.confに記述するのもお忘れなく。動作確認ネットワークレベルで動作確認をしてみます。以下はサブドメイン間のSSOをトラッキングしたものです。モザイクかけすぎて何が何だかわかんなくなっているのはご了承wまずは何も認証してない状態でWebサイトにアクセスするとOpenAMへのリダイレクト処理が走ります。->XUI/#loginへのリダイレクト処理が走ります。するとログイン画面が出てくるので認証します。ログインリクエストこんな感じ。あとはJSでごにょごにょやってCookieセットして、OpenAM→Webサイトへリダイレクトします。この時点で有効なCookieが発行されているためWebサイト側で認証扱いになります。ちなみに、クロスドメインSSOの場合はcdcservletというモジュールを介すため、ややシーケンスが増えます。instance.).と言われてAgentがインストールできなくなります。これは/etc/.amAgentLocatorにエージェントの設定ファイルの場所が書かれているためで、一度作成した設定を削除するにはこのファイルも削除しないとダメ。いうか、設定の削除は以下のコマンドでやるべきですね。AgentとApacheのバージョンが合っているかを見直してください。→Webサーバの設定ディレクトリを指定するときには設定ファイルに対して書き込み権限が必要になりますし、パスワードファイルも読み込み権限が必要になります。この2つのファイルの権限を見直してください。Agentは設定もインストールもさほど難しくないので手軽では有りますが、OpenAMのCookieを使った認証になるため、プログラム側の改修が必要になります。Agentが自動的に行ってくれますが、どのユーザでログインしているかどうかを判別する処理はアプリケーション側で実装しなければなりません。Cookie認証の実装やOpenAMの設定がそんなに難しくないため、要件次第ではSSO実現の強力な方法になりそうです。