仮想環境によるOpenAMを用いた認証基盤の紹介
An introduction of an authentication system using OpenAM in a virtual server environment.
花阪 元伸＊

山崎 玲＊

Motonobu Hanasaka, Akira Yamazaki

本稿では、仮想化やクラウド化のWebAPのサーバ構築への影響と、シングルサインオン（以下SSOと す る） に よ る ユ ー ザ・ 管 理 者 へ の 利 点 つ い て 簡 単 に 触 れ、SSOシ ス テ ム の 一 つ で あ る、OpenAMによるSSO構成について幾つかのパターンを紹介する。
We describe the impact on WebAP server virtualization and cloud computing,the benefits tousers and administrators in Single Sign-On System（SSO）. We introduce some of the pattern for
the SSO configuration using the OpenAM.

SSOシステムとは、一度ログインすると、複数のWebAP1．まえがき等をシームレスに利用できるようにするシステムとなる。今回 紹 介 す るSSOシ ス テ ム は、ForgeRock社（http://一般に、Webアプリケーション（以下WebAP）やコforgerock.com）が開発するOSSのOpenAMである。

ンピュータ自体など、何らかのコンピュータ資源を誰か

本稿に関しては、上記SSOシステムだけではなく、一に利用させるにあたり、次の事項に対応することを求め

般のWebAP向けSSOシステムに対して概ね当てはまるられる。のではないかと考える。

・情報へのアクセスを認められた者だけが、その情報にアクセスできる状態を確保すること。

（1）

2.

このために、コンピュータ資源等に少なくとも、次のユーザ管理機能を除いて、WebAP等で専用の認証認２つの機能が必要となる。
表１

仮想化と認証認可機構

可機構を実装することは難しいことではない。また、特アクセス制限のための機能定の条件において特定のユーザのみアクセスの許される情報がある場合等の細かなアクセス制御が必要な場合には、専用の認可機能の実装が必須となる。
WebAP等で専用の認証認可機構を持たず、ユーザ情報やアクセス条件を、共用のユーザ情報・認証認可サーバに保管し、各々のWebAPサーバからこれらの情報を参照する場合は、WebAP等とユーザ情報・認証認可サ

これらの機能を実装する機構を、本稿では、認証認可ーバの間で、下記の内容等について、色々なすり合わせ機構と呼ぶ。

が必要となる。

仮想化環境の利用により、気軽にWebAP毎にサーバ・WebAPとユーザ情報・認証認可サーバとの間の通信を立てることが可能となった。しかし、一人のユーザが規約多数のWebAPを利用する時に、それぞれ個別にログイ・ユーザ情報・認証認可サーバで保管する必要がある情ンして回ることは不便である。また、個々のWebAPに報の種類おいて、ユーザ名やパスワードと共にユーザの情報を・情報の利用条件等一々登録し、管理ポリシに応じて維持管理することは、特にWebAPサーバとユーザ情報・認証認可サーバで管理者の作業負荷等が大変大きい。

管理組織等が異なる場合、上記すり合わせ自体にコスト本 稿 ではこの問 題を解 決 する方 法として、複 数 のがかかる場合がある。

WebAPに共通して導入できる、基盤としてのシングルサ仮想化環境が広まる前までは、物理サーバ上に直接Webインオンシステム（以下SSOシステム）の紹介を行う。
＊つくば事業部 第六技術部
1MSS技報・Vol.25

サーバを配置する必要があった。WebAP毎にサーバを構一方、WebAP側では次の何れかの作業が必要となる。

築することは物理サーバを購入することと同義である。こ・SSOに対応するように改修する。のコストを低減するために、既設のサーバにWebAPのみを・WebAPには手を入れずに、SSOとWebAPを接続する追加配置することも多く、追加配置作業の一環として、上ための糊づけに当たる部分を作成する。

記のすり合わせを実施することが多かった。

・新規開発時に対象となるSSOに対応したWebAPを開し か し、 仮 想 サ ー バ 環 境 や ク ラ ウ ド 環 境 の 場 合、発する。

WebAP毎にサーバを構築したとしても、物理的にサー3.

バ等を購入する必要がないため、あまりコストがかからSSOの方式ない。これにより、面倒なすり合わせを避け、WebAPSSOを実現するための構成には次の２種類があげられる。

内にユーザ情報及び認証認可機能等をすべて取り込み、1. WebAP部分でSSOに対応するもの。（Agentタイプ）

自己完結することができるようになった。

2. WebAPより前にリバースプロキシをおいてSSOに対上記のようにWebAPが自己完結した場合、ユーザに応するもの。（リバースプロキシタイプ）は利用するWebAP毎に個別にパスワードやユーザ情報それぞれについて、図示する。

等を登録し、これを維持管理する必要が発生する。これは、結果的に、情報システム全体として見た場合、覚えにくい多数のIDとパスワードを、機密性を高く保持するという難易度の高い作業を、一般のユーザに要求することになる。この要求は、一般のユーザには無理な要求となるため、複数のサービスで同じパスワードを使いまわす等、何らかのセキュリティ上のリスクとなることが考えられる。（2）
また、Internet向けのWebAP等の場合、Facebookや図１

Google等のソーシャル系の認証が使えず、WebAP独自

AgentタイプのSSO

AgentタイプのSSO について、必要な機構は次の通りのユーザ登録が必要である場合、それだけで、ユーザに・SSOを行うSSOサーバ避けられる要因となる。

・WebAP上でアクセス制限を実施する部分。

管理の面から見て、ユーザの情報を個々のWebAPでユーザからWebAPへのアクセスでは次のように処理独立に維持管理することは、全体として無駄なコストとなる。特にエンタープライズシステムにおいて、定期的が行われる。

なパスワード変更が強制されたり、人事異動等によるユ

1. SSOサーバに対して、どのユーザがログインしてアクセスしているのか確認するーザの属性情報の変更が多数発生した場合、管理者及び

2. SSOサーバに対して、ログインユーザがアクセス先ユーザが、各々のWebAPで個別に関係する作業を行うにアクセスしても良いかを確認することになるため、大きなコストとなる。

3. 問題がなければ、WebAPへのアクセスが行われる。

上記の問題は、SSOシステムを導入することで解決することができる。
ユーザは統一されたログイン画面からログインするこ

これにより、ユーザはSSOサーバにログインしていれとで、SSOがサポートする全てのWebAPをシームレス

ば、各々のWebAPでユーザ認証をする必要が無くなる。に使用することができ、利便性が高まる。
管理側から見たメリットとしては、下記のものがある。
・WebAP側の認可の条件が非常に単純な場合、SSO側で認可を全て行うことができ、WebAPを単純にできる。
・WebAPで共通に利用するユーザに関する情報を集中管理することで、ユーザ管理のコストを抑えることができる。
・WebAPを作成する者のスキルレベルによらず、安定したセキュリティレベルを維持できる。
・ユーザがいつどのWebAPを利用したかの監査が容易となる。

図２

2

リバースプロキシタイプのSSO

MSS技報・Vol.25

リバースプロキシタイプのSSOについて、必要な機構

IDMサーバについては、これまで紹介されていないは次の通り

が、「5.OpenIDMによるユーザ情報管理を行う構成」で・SSOを行うSSOサーバ紹介する。

・通信変換及びアクセス制限を実施するリバースプロキシ

以降では、エンタープライズ向けのSSOシステムとし

なお、この構成では、SSOサーバとリバースプロキシて、OpenAMを採用した構成の例をいくつかあげる。

が一体になっているものも多い。

なお、本稿では、インターネット向けSSOシステムとユーザからリバースプロキシにアクセスがあった際して、OpenAMを構成した場合の例は含まない。に、リバースプロキシ上で次のような処理が行われる。

4.

1. SSOサーバに対して、どのユーザがログインしてアクセスしているのか確認する。

アクセス制限に関する構成

本項では、「3. SSOの方式」のアクセス制限の方法に

2. SSOサーバに対して、ログインユーザがアクセス先着目した構成を紹介する。にアクセスしても良いかを確認する。

実際の構成では、個々のWebAPの用件に合わせた結3. ユ ー ザ がWebAPに ロ グ イ ン し て い な い 場 合、果、以下に述べる２つの方法を組み合わせて利用するこWebAPに対して、ユーザ毎に予め登録されたユーともある。

ザIDと認証情報を送信してWebAPにログインする。
4. リバースプロキシサーバへのアクセスを変換して、4.1

WebAPにアクセスする。

WebAP部分でSSOに対応するもの

本構成は、下記の構成となる。

これにより、ユーザは一度SSOサーバにログインしていれば、其々のWebAPで個別に認証を行う必要が無くなる。
AgentタイプのSSOとリバースプロキシタイプのSSOの構成を比べると、Agentタイプは構成及び動作がシンプルという利点があり、リバースプロキシタイプはWebAP自体がSSOを想定していないものでも対応できるという利点がある。

図３

OpenAMは関連ソフトウエアと合わせて利用することにより上記どちらの方法にも対応する。

OpenAMによるAgentタイプSSO

この構成はOpenAMを用いたSSOシステムでもかな

今回紹介するOpenAM及び関連ソフトウエアは下記

り単純な例である。WebAPの改修ができるのであれば、の通りである。

多くの場合、小規模な改修で対応可能だと思われる。
OpenAMを利用した場合、アクセス制限自体を施行す
る の は 各Webサ ー バ 等 に 配 置 さ れ るOpenAM

表２

OpenAM及び関連ソフトウエア

PolicyAgentで、これがWebサーバ等に組み込まれてアクセス制限を実施する。
OpenAM自体は、認証と、OpenAM PolicyAgentからの要求による認可の判断を実施する。
この構成の特徴は、下記の通りとなる。
・WebAPを 提 供 す るWebサ ー バ 自 体 にOpenAM
PolicyAgentを配置しアクセス制限を実施する。
・ユーザ情報をLDAPサーバであるOpenDJに保管して、OpenAMはこれを参照して動作する。
この構成のメリット及びデメリットは下記の通りとなる。
メリット・ ユ ー ザ に 対 し て、SSOが 提 供 で き る。
（ユ ー ザ はOpenAMに 対 し て ロ グ イ ン す る だ け で 良 く、WebAP1,WebAP2に個々にログインする必要がない。
）

3

MSS技報・Vol.25

・構成がシンプルで分かりやすい。

な い と こ ろ で 実 施 さ れ る た め、 ユ ー ザ は あ た か も・ログインユーザの識別方法やユーザ情報の入手に、WebAPに対して追加のログイン処理をせずに、シームOpenAMやLDAPが利用できる。

レスにアクセスしているように見える。

・ユーザ情報がLDAPに集中しているため、統一されたこの構成のメリット及びデメリットは下記の通りとなる。

ユーザ管理機能を開発することで、個々のWebAPでメリットユーザ管理の機能が必要なくなり全体的に見て開発工・WebAPの改修をせずに、ユーザはSSOの恩恵を受け数が低減できる。

られる。

デメリット

デメリット

・OpenAM PolicyAgentをWebサーバに導入して、ア・OpenIGをリバースプロキシとして立てる必要がある。

クセス制限を行うため、OpenAM PolicyAgentに対応

・OpenIGにリバースプロキシや代理認証の複雑な設定したWebサーバしか対応できない。

が必要となる。

・WebAP等 に よ る ロ グ イ ン ユ ー ザ の 識 別 方 法 等 が、・WebAPでユーザ管理や、OpenIGによる代理ログインOpenAMで提供する幾つかの方法に合致する必要が処理用のパスワード等の管理を管理者等が実施する必ある。

要がある。

・ユーザ情報の入手先が、OpenAMかLDAPサーバに限定される。

なお、OpenIGの設定は、JSON形式のファイルを用い

・上記に合致していない場合、WebAPの改修が必要とて実施する。

なる。

正しく構成するためには、複雑な設定が必要なため、構成を良く検討し、十分テストを行う必要がある。低コ

4.2 WebAPより前にリバースプロキシをおいてSSO

ストで構築運用するためには、セキュリティ要件を検討に対応するもの

したうえで、割り切った設計が求められる。

本構成は、下記の通りとなる。

（代理認証用パスワードは長期にわたり利用する。
WebAPへの通信路をOpenIGに固定してWebAP側では認証を行わないなど。
）
5.

OpenIDMによるユーザ情報管理を行う構成

ここでは、SSOシステムにOpenIDMを配置し、ユーザ情報に関する管理機能を強化した構成について紹介する。本構成は、「4．アクセス制限に関する構成」のどの構成に対しても追加できる。
図４

本構成をとることにより、ユーザID・パスワードをOpenAMによるリバースプロキシタイプSSO

含めたユーザ情報について、SSOシステム内外での連携
この構成はWebAPが、SAML等他の認証機構と連携を強化した基盤が構築できる。

する機能を有せず、ブラックボックスとなっており改修

本構成は、下記の通り。などが不可能な場合に利用される構成となる。
この構成の特徴は、下記の通り。
・コンテンツを提供するWebサーバの前に、リバースプロキシであるOpenIGを構成する。
・OpenIGにOpen AM PolicyAgentを配置しアクセス制限を実施する。
・OpenIGから、Webサーバ上のWebAPに対する代理認証等を実施する。
代理認証とは、SSO認証済みユーザからのアクセスに

図５

関して、ユーザの替わりに、OpenIGがWebAPに代理でログイン処理（ユーザID,Password）の入力等を実施す

OpenIDMを加えた構成

この構成は下記のような場合に用いられる。

ることである。この代理認証の処理は、ユーザから見え・外部にユーザ情報（または人情報）管理システムがあ

4

MSS技報・Vol.25

り、この情報を取り込んでSSOのユーザ情報を作成す

6.

る場合。

PKIを利用する構成

・複数のユーザ情報レポジトリとSSOのユーザ情報を連

ここでは、OpenAMの豊富な認証機能の例として、携し、一貫性のある状態を維持する必要がある場合。

ユーザIDとパスワードの入力ではなく、ユーザが所有・SSOシステムの外に対して、Webサービスやワークフするクライアント証明書を用いたSSOの例を示す。

ローの機能としてユーザ管理機能を提供する場合。

本構成は、下記の構成となる。

OpenIDMは、内部的にSQLDBによるレポジトリを持ち、SSOのユーザ情報等の管理を行うサービスである。
以下の機能をもつ。
・他のユーザ情報源と、OpenDJ間のPushPull型の情報連携機能。
・ユーザ情報をJSON形式で提供し、同様に取り込み可能なREST APIによるユーザ管理用Webサービス。
・BPMNによるワークフローの提供。
・簡単な管理画面の提供。
情 報 連 携 機 能 は、 ユ ー ザ 情 報 源 と し て フ ァ イ ル、SQLDB、LDAP等が利用できる。OpenAMで認証用ユーザ情報源として参照するOpenDJもLDAPの情報源として扱われる。

図６

クライアント証明書による認証構成

OpenIDMは、定期的に各情報源にアクセスし、更新された情報を内部レポジトリに反映する。これにより、この構成ではユーザにPKIの鍵と証明書（以下クライ内部レポジトリが更新された場合、各情報源を更新されアント証明書）を配り、これによる認証を実施するものた情報で更新する。また、REST API等で直接内部レポである。このため、下記の構成を追加する。

ジトリが変更された場合は、即時に各情報源を更新する・クライアント証明書を発行する証明局の構成または、機能を持つ。

外部の証明書発行サービスの利用

これらの機能の組み合わせで、OpenIDMは全ての情・クライアント証明書の照合を行うために、OpenDJのユ報源のデータの整合性を維持する。

ーザ情報にクライアント証明書の保管（オプション）

この連携機能は、先のOpenIGでの代理認証用に必要

・ ク ラ イ ア ン ト 証 明 書 の バ リ デ ー シ ョ ン の た め に、な、各WebAPでのユーザ管理（及びパスワードの維CRL、OCSPレスポンダへの準備（オプション）持）に関して支援を提供する。
なお、OpenIDMの設定は、JSON形式のファイルを用

この構成のメリット及びデメリットは下記の通りとないて実施する。各種情報源と内部レポジトリとの間の情報る。のコンバートの際には、JavaScriptによるスクリプティン

メリットグを実施することができる。

・ユーザが明示的にパスワードを提示することなく、クライアント証明書を用いてシームレスに認証することができる。
デメリット
・クライアント証明書の作成・配布などの管理作業が発生する。
・ユーザがクライアント証明書を利用するための何らかの手続きが必要。
・ICカードによるPKI等を運用するためには、加えてハードウエア等の設備投資が必要。

5

MSS技報・Vol.25

7.

むすび

執筆者紹介

本稿では、OpenAMによる、エンタープライズシス

花阪元伸

テムで用いられそうなSSOの構成を紹介した。より進ん1996年入社。つくば事業部第六技術部第三グループ所だ構成としては、Windows Desktop SSOの機能を用い属。基幹サーバ・大型計算機 及び オープンソースを使て、WindowsのログオンによりSSOを開始するなどの用したSI・運用支援業務に従事。

構成がある。これが適切に構成できた場合、ユーザは、Windowsにログインするだけで、全てのエンタープラ

山崎

イズアプリケーションをシームレスに利用可能となる。

1997年入社。つくば事業部第六技術部第一グループ所

OpenAMでは、本稿には含まれないソーシャル系ID属。基幹サーバ・ネットワークシステム 及び オープンを用いた、クラウド連携の機能や、Internet向けのSSO玲

ソースを使用したSI業務に従事。

連携の機能も含まれている。将来的には、社内システムやBtoBシステムにおいてもソーシャル系IDを用いたSSOが要求されるのではないだろうか。
そのためには、認証システムに対するより深い知見が必要であると考える。
参考文献（１）情報セキュリティ（http://ja.wikipedia.org/wiki/
情報セキュリティ），ウィキペディア（2014）（２）「覚えられない」を前提にしたパスワード管理術とは？
（http://www.atmarkit.co.jp/ait/articles/1311/08/
news128.html），高橋睦美, ＠IT（2013）（３）ForgeRock社WebSite（http://www.forgerock.
com/），ForgeRock社（2014）（４）ForgeRock Documentation（http://docs.forgerock.
org/en/index.html），ForgeRock社（2014）

6

MSS技報・Vol.25