ハイブリッド・クラウド時代における
Webアプリの認証セキュリティ対策～シングルサインオンでセキュリティと利便性を両立させる～

オープンソース・ソリューション・テクノロジ株式会社
代表取締役 チーフアーキテクト 小田切耕司

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-1-

Part 1
講師紹介
オープンソース・ソリューション・テクノロジ
会社紹介

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-2-

講師紹介






役 職 ： 代表取締役 チーフアーキテクト
氏 名 ： 小田切 耕司 (おだぎり こうじ)
所属団体等
 OpenSSO&OpenAMコンソーシアム 副会長
 OSSコンソーシアム 副会長
 日本LDAPユーザ会設立発起人
 日本Sambaユーザ会初代代表幹事
執筆関係
 日経Linux 2011年9月号～2012年２月号 連載中
 『Linux認証のすべて』 （第１回～第６回）
 http://itpro.nikkeibp.co.jp/linux/
 ASCII.technologies 2011年2月号
 『キホンから学ぶLDAP』
 http://tech.ascii.jp/elem/000/000/569/569412/
 技術評論社 Software Design 2010年9月号
 第1特集 クラウド対策もこれでOK！
統合認証システム構築術
OpenAM／SAML／OpenLDAP／Active Directory http://gihyo.jp/magazine/SD/archive/2010/201009
 ＠ＩＴ やってはいけないSambaサーバ構築：2008年版
 2006年5月 技術評論社 LDAP Super Expert
 巻頭企画
 ［新規／移行］LDAPディレクトリサービス導入計画

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-3-

オープンソース・ソリューション・テクノロジ株式会社
 OSに依存しないOSSのソリューションを中心に提供– Linuxだけでなく、Windows/Solaris/AIXへも対応– Windows/UNIX から Linux への移行も支援！
 OSSを利用した認証基盤構築が得意分野– LDAP認証、Windowsドメイン認証、Webアプリケーショ

ン認証、クラウド認証
 Samba,OpenLDAP,OpenAM,IDMなどによる認証統合/シングルサインオン、ID管理ソリューションを提供– OSSの製品パッケージ・製品サポートを提供– OSSの改良、バグ修正などコンサルティングにも対応

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-4-

会社概要
会社名

オープンソース・ソリューション・テクノロジ株式会社

英語表記

Open Source Solution Technology Corporation

社名略称

OSSTech（ｵｰｴｽｴｽﾃｯｸ）または OSSテクノロジ

業務内容

・OSS（オープンソース）を中心とするソフトウエアの企画、開発、販売およびサポート
・システムの導入に関するコンサルティング
・ソフトウエアに関する教育、研修

役 員

代表取締役
技術取締役

オフィス

東京都品川区西五反田1-29-1 コイズミビル 8F
Tel.03-6417-0753 Fax.03-6417-0754

Web

http://www.osstech.co.jp/

設立

２００６年９月

資本金

１５００万円小田切 耕司
武田 保真

所属
団体等

取引先
および
ﾊﾟｰﾄﾅｰ様

OpenSSO&OpenAMコンソーシアム理事 副会長
OSSコンソーシアム理事 副会長
OSCA(Open Standard Cloud Association)理事
LPI-Japanビジネスパートナー
デルISVアリーナ パートナー
NEC CLUSTERPRO WORKSパートナー
レッドハット レディ・ビジネス・パートナー・株式会社野村総合研究所
・デル株式会社
・株式会社バッファロー
・日本電気株式会社
・株式会社 大塚商会
・キヤノンITソリューションズ株式会社
・伊藤忠テクノソリューションズ株式会社
・新日鉄ソリューションズ株式会社
・株式会社ＰＦＵ
・株式会社 日立ソリューションズ
・三菱電機インフォメーションシステムズ株式会社
・ソフトバンク・テクノロジー株式会社
・ニフティ株式会社
・三井情報株式会社・ダイワボウ情報システム株式会社
・ＮＴＴデータ先端技術株式会社

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-5-

認証基盤

システム管理

ID管

ID管

ID管

Active Directory

Google Apps
Salesforce
ファイル
サーバー

バ

LDAP

Windows
ドメインログオ

クラウド

Web アプリ

ログイ

ログイ

ユーザ
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-6-

OSSTechの製品群
Unicorn IDM

ID管
システム管理ID連
Active Directory

Google Apps
Salesforce
ファイル
サーバー

バ

Web アプリ

LDAP

クラウド

SSO
Windows
ドメインログオ

認証基盤をすべOSS製品で提供

ログイ

ユーザ

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-7-

OSSTechの製品群（すべてOSSで提供）
原則Linux/Solaris/AIX共にRPMで提供① Samba for Linux/Solaris/AIX ADの代替、高性能NASの代替② OpenLDAP for Linux/Solaris/AIX
 認証統合、ディレクトリサービス、シングルサインオンのインフラ③ OpenAM for Linux/Windows/Solaris Tomcat,OpenLDAP対応で高機能なシングルサインオン機能を提供④ Unicorn ID Manager for Linux/Solaris Google Apps,ActiveDirectory,LDAP, Yahoo!メール
Academic Editionに対応した統合ID管理
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-8-

OSSTechの製品群（すべてOSSで提供）
原則Linux/Solaris/AIX共にRPMで提供⑤ Chimera Search for Linux アクセス権の無いファイルは表示されない全文検索システム⑥ LDAP Account Manager for Linux/Solaris 管理機能の弱いOSSのLDAP/SambaにWebベースのGUIを提供⑦ ThothLink for Linux リモートからのWindowsファイルサーバアクセス機能を提供⑧ Mailman for Linux/Solaris Google Appsのメーリングリスト機能を補完⑨ Netatalk for Linux/Solaris UTF-8に対応したMac OS対応のAFPファイルサーバー
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

-9-現在開発中 Nginxのポリシーエージェント開発中
 開発が終了した従来のSun Web Proxy Serverの代替用途として Apacheよりも軽量で高速、高セキュリティ
 Windows版の製品化も検討

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 10 -

エンジニア募集中です！
特にOpenAM(Java)のエンジニア募集中
http://www.osstech.co.jp/company/recruit
recruit@osstech.co.jp
 OpenAM(OpenSSO)を使ったシングルサインオンもしくはSamba、OpenLDAPを使った統合認証に関する開発エンジニア、コンサルタント、アーキテクト
 シングルサインオン、統合認証、Linux / UNIX / OSS
経験 Java,Cの知識があり、前向きに自分でスキル向上を目指せる方
 紹介会社などを通さず直接弊社へ募集エントリされた方には、入社後現金２０万円を差し上げます
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 11 -

Part ２

シングルサインオンとはCopyright © 2011 Open Source Solution

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.
Technology, Corp. - 12 -サービスを利用するには必ず必要な「認証」
ActiveDirectory

企業・組織内クラウド
Google Apps
Salesforce

ファイル バ LDAP
サーバー

メールサーバー
Client/Server

Windowsログオン/
LDAP 認証

ログイン

Webアプリログイン

ログイン

システムの数だ「認証」が必要ユーザー

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 13 -

SSO：シングルサインオンとは一度のログイン操作さえ完了すれば、複数のアプリケーションに
認証操作することなくアクセスすることが可能になる。
ActiveDirectory

Google Apps
Salesforce

ファイル
サーバー

バ

LDAP

メールサーバー/
クラサバ

クラウド

Webアプリ

SSO
Windowsログオン
LDAP 認証

ログイン
ログイン

ユーザ

今日は
この部分のお話

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 14 -

SSO（シングルサインオン）とは






１回のパスワード入力で複数のシステムやサービスを同時利用「ID統合を使った統合認証」ではIDとパスワードの管理を1カ所でできるためユーザの追加も楽、社員が退社した場合に1カ所IDを削除すれば、すべてのシステムが利用不可となる
近年クラウドサービス（SaaS, PaaS, IaaS, HaaSなど）の普及により、（社外にある）サービス毎にID／パスワードを登録しなければならないケースが増えており、「ID連携による統合認証」を使わざるを得ないケースが増えている
ところがこのID連携が費用の問題や技術的な問題で完全に実現されていない場合、例えば社員が退社した時に社内システムのIDを削除しても、SaaS側のIDが残っているとクラウド側のシステムは社外から使えてしまう、といった問題が起きてしまう

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 15 -

クラウドで統合認証ができていないと．．．
インターネッロ

クラウド・サービス SP
Google Apps
SalesForceなど

グイ

ログイ

プライベートクラウド/ASP

ユーザー情報ユーザー情報認証
IdP

SP

B2B,B2C
ログ

IdP

ユーザー情報ユーザー情報認証

イ

IdP

イントラネット
社内向けシステムSP
認証

ユーザー情報ユーザー情報システム毎にログイン操作が必要
クラウドにID/パスワードとパスワードを置く必要がある（パスワードを社外に置くと不正ログインされる危険性が高い）
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 16 -

クラウドで統合認証とSSOを実現するSP
クラウド・サービス
Google Apps
SalesForceなど

インターネッ
SAML認証

認証はすべて社内で行う

B2B,B2C
セ

DMZ

プライベートクラウド
/ASP

IdP

（1）
ログ

パスワードは社内で管理

SP

(2)

認証
チケッ

イ

LDAP/AD
ID/Pass

アク

認証チケット／
リバースプロク

ア

（3）

ク

セ

認証チケット／
リバースプロク

アクセス

ユーザー

イントラネット
社内向けシステムSP

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 17 -

Part ３

今こそシングルサインオン！
なぜ今シングルサインオンが必要なのか

Copyright © 2011 Open Source Solution

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.
Technology, Corp. - 18 -

SSO（ID管理）の需要推移

さらなる需要見込まれる

需要
J-SOX法対応（内部統制）

2008年

クラウドの普

2009年

2010年

2011年

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

時期- 19 -

SSO(OpenAM)導入動向
 クラウドの普及により、SSO（シングルサインオン）が急速に普及中
 IaaSやPaaSも増えつつあるが、やはりSaaSのGoogle
Apps（大学／企業）とSalesforce（企業）をまず導入するケースが多い 企業ではSalesforceのセキュリティ強化を目的にOpenAM
導入するケースが多い 大学ではGoogle AppsとイントラネットやShibbolethを連携させるケースが多い
 企業ではM&Aや会社合併のために増えすぎたアプリやIDを統合するためにSSOを導入
 今後は、 IaaSやPaaSがさらに普及し、これらの上で構築された社内向け個別アプリのSSOが普及しそう
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 20 -

Part ４OpenAM（旧OpenSSO）の紹介

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 21 -

OpenAMとは








Webアプリケーションにおけるシングルサインオンを
シングルサインオン実現するためのプラットフォームとなるオープンソー
スソフトウェア
SAML、OpenID、OAuth、ID-WSFなどの認証・認可にWSF関連した複数のプロトコルをサポート
ユーザー情報を格納するためのユーザーリポジトリ（ユーザーデータストア）として様々な LDAP サーバ
ー、RDBに対応充実した管理 GUI

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 22 -

OpenAMの歴史 - その1
AOLによる
買収

AOLからの分離

開発
主体

Netscape

iPlanet

製品名

dsame

Identity Server

認証連携
機能の強化

オープン
ソース

Sun Microsystems

Access Manager

OpenSSO

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 23 -

OpenAMの歴史 - その2
Oracleによる買収

OpenSSO は非戦略的な製品という位置づけSun

OracleOpenSSO

Oracle OpenSSO

ForgeRock社

OpenAM

Oracleから分離

新プロジェクの開始!

OSSTechとの協業

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 24 -

OpenAMのこれから（技術面）


OpenAM は OpenSSO の正常進化形

クラウド対応強化

Google Apps, Salesforce とのシングルサインオン（SAML）連携機能を強化
ＧＵＩ による操作でシングルサインオン設定が可能

機能拡充





OpenSSO を担当していたエンジニアが中心になりForgerock社を設立
OpenSSOと完全互換(ベースにするソースコードが同じ)

ワンタイムパスワード機能の追加
ユーザーリポジトリしてRDBをサポート

次期バージョン（OpenAM 10）では更なる認証機能の強化を検討中

リスクベース認証：ID/PW認証に加え、ユーザーのアクセス元IPアドレス、ブラウザ（デバイス）情報などから不正アクセスのリスクを判定し、必要に応じて多要素認証などをユーザーに要求する。

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 25 -

OpenAMのこれから（ビジネス面）


ベンダ独自のパッケージングも可能

生体認証などの独自認証方式を組み合わせる
ID管理システムと組み合わせる
OSSTech 版 OpenAM の特徴

OpenLDAP 用拡張スキーマを提供

ID管理製品（Unicorn IDM）との組合わせ
Google Apps/Salesforce/学認などと連携するシングルサインオンソリューションを提供




需要






日本では多くが新規ユーザー
企業・大学などの認証基盤として OpenAM を利用
クラウドにおける認証基盤・認証強化ツールとして OpenAM を利用
既存ユーザー（Sun Access Manager、OpenSSO）からの移行（米国、ヨーロッパ）
複数のシングルサインオン環境を統合する”ハブ”システムとして利用

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 26 -

Part ５

シングルサインオン方式

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 27 -

何が違う？「認証」と「認可」


認証（Authentication）
本人性を確認する ID/パスワード認証、生体認証、ワンタイムパスワード認
証など




認可（Authorization）


あるリソースへアクセスするための権限を与える（認証後のアクセス制御）

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 28 -

Part ６
OpenAMが提供するシングルサインオン方式

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 29 -

シングルサインオン方式の詳細（1） SAMLによるシングルサインオン– Secure Assertion Markup Lauguage– 認証、認可、ユーザ属性情報などをXMLで送受信するためのフレームワーク– 標準化団体OASISにより策定– GoogleApps、Salesforceなどが採用
 エージェント方式– SSO対象のWebアプリが動作するサーバー上にアクセ

ス制御用のモジュールを配置する方式– サーバーのバージョンに影響を受ける
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 30 -

シングルサインオン方式の詳細（2）

リバースプロキシ方式– リバースプロキシを使用してアクセス制御を行う– ユーザーデータの受け渡しはHTTPヘッダーを利用– SSO対象Webアプリのバージョンや設定変更の影響が少ない– リバースプロキシが性能上のボトルネックになる可能性がある

代理認証方式– SSO対象Webアプリの既存ログイン画面に対して、OpenAMがユーザーの代理でログインID/パスワードを送信する– SSO対象Webアプリの改修が不要– 細かなアクセス制御はできない（ログイン処理の代理実行のみ）

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 31 -

SAMLによるシングルサインオン

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 32 -

SAMLによるシングルサインオン（HTTP Redirect/POST Bindingの場合）

User Agent(ブラウザ)

IdP(OpenAM)SP(Webアプリ)(1)SPへアクセス

HTTP Redirect(2)SAML認証要求メッセージ（AuthnRequest）(3)ユーザ認証(4)SAML認証応答メッセージ（Response。認証情報（アサーション）を含む）(5)コンテンツ

アサーション
生成

HTTP POST

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 33 -

エージェント型

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 34 -

エージェント方式によるシングルサインオン

User Agent
Policy Agent(ブラウザ)(Webアプリケーション)(1)Webアプリケーションへアクセス

認証サーバ(OpenAM)(2)OpenAMへリダイレクト(3)ユーザ認証
Cookie発行(4)Cookieを発行(5)認証後のアクセス(6)Cookieの正当性確認(7)Webアプリケーションのコンテンツ

HTTPヘッダなどから認証情報を入手

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 35 -

リバースプロキシ型

後方のサーバを仮想的に１台に見せることも可能
認証とサーバへのアクセス制御はプロキシサーバで行う
後方のサーバは認証なしもしくはBasic認証でアクセス可能
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 36 -

リバースプロキシ方式によるシングルサインオン

User Agent(ブラウザ)

リバースプロキシ

認証サーバ(OpenAM)

Webアプリケーション(1)Webアプリケーションへアクセス(2)OpenAMへリダイレクト(3)ユーザ認証
Cookie発行(4)Cookieを発行(5)認証後のアクセス(6)Cookieの正当性の確認

ヘッダ情報を確認(7)リクエストのフォワード(8)コンテンツ

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 37 -

代理認証方式
プロキシ
または
代理認証ポータル

認証情報をPOST

認証サーバで認証したら後方のサーバへ認証情報をPOSTして認証する
後方のサーバが独自の認証画面を持っていてもSSO可能
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 38 -

代理認証方式によるシングルサインオン

User Agent(ブラウザ)

代理認証サーバー

認証サーバ(OpenAM)

Webアプリケーション(1)Webアプリケーションへアクセス(2)OpenAMへリダイレクト(3)ユーザ認証
Cookie発行(4)Cookieを発行(5)認証後のアクセス(6) IDとパスワードの代理送信
Cookie発行(７)コンテンツ

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 39 -

シングルサインオン方式の比較
方式

Webアプリケーションの改修

長所・短所

SAMLに対応していれば不要■標準的な仕様に準拠したSSOシステムを構築可能。他
製品との互換性が高い■認証サーバー（IdP）を社内に設置し、クラウドサービスであっても、アクセスを社内のみからに制限することも可能（
サービスのSAML実装に依る）■WebアプリケーションがSAMLに対応している必要がある

必要■Webアプリケーションへの全ての通信をエージェントがフックするため、細かなアクセス制御が可能■サーバーに対応したエージェントが必要

リバース
プロキシ

必要

■Webアプリケーションへの全ての通信をリバースプロキシがフックするため、細かなアクセス制御が可能■リバースプロキシがボトルネックになる可能性もある

代理認証

不要

■既存Webアプリケーションの改修が不要■代理認証不可能な場合もある

SAML

エージェントCopyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 40 -

シングルサイオン方式の採用基準
WebアプリケーションがSAMLに対応しているか
No
No
Webアプリケーションの改修が可能かYes
WebアプリケーションをSAMLに対応させることができるかNo
No
ポリシーエージェントがWebサーバ/APサーバに対応しているかNo

Yes

SAMLを採用

No

代理認証方式を採用

Yes
Yes

SAMLを実装

エージェント方式を採用
リバースプロキシ方式を採用

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 41 -

本当はやってはいけない「代理認証」「既存アプリに手を入れられない」という理由で代理認証を採用するユーザーは多いが本当はやってはいけない！
• IDとパスワードを（HTTPSでも）ネットワークに何度も流すのは良くない。（SSO入り口の１カ所に限定すべき）• 代理認証はイントラネットのみに限るべき• クラウドへの代理認証は危険• SAMLに対応しているGoogle AppsやSalesforceに対して、代理認証は絶対にやってはいけない！
（SAMLを使ってIdPを社内に置けばパスワードはクラウドに流れない）

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 42 -

Part ７

Google Appとの連携
設定手順

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 43 -

Google AppsへのＳＳＯ
OpenAM(SAML IdP)

ログイン
SAML
アサーションユーザ

Google Apps
(SAML SP)

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 44 -

設定手順
ＯｐｅｎＡＭのメニューに従い設定を行う
 OpenAMをＩｄＰとして設定する– 新規にトラスト・サークルを作成する
 Google AppsをＳＰとして設定する– OpenAM側での設定– Google Apps側での設定– OpenAMが表示する値をGoogle

Appsに反映
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 45 -

手順１： ＩｄＰの作成

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 46 -

手順２： Google AppsをSPとして登録

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 47 -

手順３： Google Appsで設定するSAMLパラメータ

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 48 -

手順４： Google AppsのSSOを有効化

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 49 -

手順５： Google Appsのシングルサイン設定

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 50 -

Part ８OpenAMの機能（その２）認証方式（多様素認証）

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 51 -

OpenAMの機能
データストアと認証方式

認証方式

ワンタイムパスワード
指静脈認証Windows Desktop SSO
クライアント証明書
外部DB
認証連鎖

Web
Application

OpenAM
ログイン

ログイン

SSO

ID
PW

Web
Application

ユーザー
Web
Application

User
Data
Store
ユーザーデータスト（ユーザー情報DB）
Active Directory
OpenLDAPRDB

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 52 -

OpenAMの機能 - 認証方式
 基本的には OpenAM のユーザーデータストアに保存された ID/パスワードにより認証を行なう
 ユーザー認証時に外部のデータベースを参照することも可能（更新できない参照のみのものでも可能）– LDAP、Active Directory、RADIUS、RDB（JDBC）
 よりセキュアな認証方式も使用可能– ワンタイムパスワード（電子メールを利用）– クライアント証明書による認証– Windows Desktop SSO（統合Windows認証）
 複数の認証方式を組み合わせて使用可能：認証連鎖
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 53 -

OpenAMの機能 - ユーザー情報DB
 ユーザーデータストア– OpenAMのユーザー情報を格納するLDAPサーバー/データベースサーバー（更新権限が必須）
 Active Directory Open LDAP Sun Directory Server OpenDS（Sun Directory Server のオープンソース
版。OpenAMに標準で組み込まれている）
 RDB（OpenAMから対応）

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 54 -

OpenAMの機能 - 認証連鎖
多様素認証の必要性– 複数の認証方式を組合わせて認証を行うことにより個々の認証方式の欠点を補完
 認証連鎖– 複数の認証方式を組み合わせて利用可能– 認証方式にはそれぞれ適用条件を指定する
 必須：失敗したらそこで終了
 十分：成功したらそこで終了
 必要：成功しても失敗しても次に継続 任意：認証結果には関係しない付随的な処理

認証方式１（必須）
ID/PW認証

認証方式２（必須）
ワンタイムパスワード

ログイン完了Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 55 -

多要素認証
複数の認証方式を組合わせて認証を行うことにより個々の認証方式の欠点を補完

厳密なユーザ認証– 異なるタイプの認証方式を組合わせることが重要

使い勝手の向上– いつも同じ認証方式が使えるとは限らない– 状況により要求される認証の精度が異なる



認証方式間での連携– 組合わせて使うことを前提にしている認証方式もある

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 56 -

認証連鎖
認証方式を組合わせる方法を指定する
 認証方式にはそれぞれ適用条件を指定する– 十分：成功したらそこで終了– 必要：成功しても失敗しても次に継続– 必須：失敗したらそこで終了– 任意：認証結果には関係しない付随的な処理 認証成功時には認証方式に応じて認証レベルが設定される
認証方式１（十分）認証方式２（必要）評価

認証方式３（任意）評価

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 57 -

例１．Windows Desktop SSO
Windows Server
2000/2003/2008
ActiveDirectory
チケット発行

ドメインログオン①

自動チケット送付②

OpenAM③

認証、認可、
属性情報

利用④
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 58 -

例１．Windwos Desktop SSO
WindowsドメインログオンするだけでＷｅｂアプリケーシ
ョンにもＳＳＯが可能になる便利な方式
 いつも、全てのユーザがドメインログオン可能であるとは限らない– リモート・アクセスの場合– 非常勤社員の場合
 通常のユーザＩＤ・パスワードによる認証と組み合わせて以下のように認証連鎖構成する– Windows Desktop SSO: 十分– ユーザＩＤ・パスワードによる認証：必須
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 59 -

例２．携帯電話を使ったワンタイム・パスワード
通常のユーザＩＤ・パスワード
による認証

ユーザＩＤ・パスワード
認証成功

ワンタイム・パスワード要求
ユーザの
携帯電話

ワンタイム
パスワードの入力画面+HMAC
ワンタイム・パスワード+HMAC返送
認証成功

OpenAM
同時に携帯電話へ
ワンタイム・
パスワードを送付

ワンタイム・
パスワード認証

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 60 -

例２．携帯電話を使ったワンタイム・パスワード



所持物認証と知識認証の組合わせによる厳密なユーザ認証が可能

携帯電話を使うことによる利点

–

導入コストの低減–

所持品の軽減フィッシングへの対応– HMAC（RFC2104:Keyed-Hashing for Message Authentication）を利用–

両方のパスワードが盗まれた場合は問題–

参考：RSAセキュリティ（株）による月例記者会見

http://internet.watch.impress.co.jp/docs/news/20100728_383861.html

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 61 -

応用例


Windows Desktop SSOによる認証は便利なのでぜひ使いたいが全てのユーザがドメインログオン可能とは限らない
ワンタイム・パスワードは厳密な認証が出来る点は良いが、いつも携帯電話を開いてパスワードを確認するのは面倒だ ２つを組合わせることにより便利かつ厳密な認証を行うことが可能– Windows Desktop SSO: 十分– ユーザＩＤ・パスワードによる認証：

必須– ワンタイム・パスワードによる認証： 必須
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 62 -

アダプティブ・リスク
認証モジュール
リスク評価に基づく認証強度の選択

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 63 -

アダプティブ・リスクの考え方


認証時にリスクを評価することによりリスクに見合った認証方式を動的に追加
Risk Based 認証とも呼ばれる



リスクの評価 予め各リスクについて重み付けを行う
 認証時にすべてのリスクについてそれらを合算する
 既定の閾値を超えた場合は認証失敗とする
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 64 -

リスクの例


リスクが高いと評価される例


パスワードを間違えたユーザからのアクセス

最終的に正しいパスワードを入力したとしてもリスクは高い

アカウント・ロックとの併用/代用

長期間アクセスがなかったユーザからのアクセス

特定のIPアドレスの範囲からのアクセス 例：社外からのアクセス

特定の地域からのアクセス 例：日本国外

いつもとは異なる端末からのアクセス（複数可）



いつもとは異なるIPアドレスからのアクセス（複数可）



特定の属性を持つユーザからのアクセス 例：正社員でない

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 65 -

アダプティブ・リスク認証モジュールの設定

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 66 -

認証連鎖と組み合わせたソリューション例
認証連鎖
複数の認証方式を組み合わせ
高いセキュリティを実現閾値を超えた
ためリスクが高いと判定さ
れた

通常の
認証方式

認証方式１（必
ID/PW
認証

OK

認証方式２（十分）アダプティブ・リスク
認証

NG

OK

閾値を超えず
リスクが低いと判定された

でも毎回だ
少し面倒！

強固だが
少し面倒な
認証方式
認証方式３（必要）
ワンタイム・パスワード
認証
OK

ログイン完

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 67 -

Oauth 2.0を使った
Facebookとの連携
連携に基づく様々なシナリオ

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 68 -

Oauth 2.0を使ったやりとり
ユーザ（ブラウザ）

OpenAM

Facebook

未認証ユーザのアクセス

Facebookのログインページへのリダイレクト
認証とユーザ承認の取得
認可コード
OpenAMへのリダイレクト
認可コード
アクセストークン

この先が重要

アクセストークン
ユーザ情報（許可されたもの）

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 69 -

取得したユーザ情報の取り扱い








セッション情報としてメモリ上にのみ保存

必要に応じてセッションオブジェクトからユーザ情報を取得



一時的な利用に限られ、Facebook経由でのアクセス時のみ有効

DB等に永続的に保存

取得したユーザ情報をLDAPやRDBに保存



必要に応じてユーザIDやパスワードを追加



登録されたメールアドレスに確認コードを送ることも可能

次回からは直接アクセスすることも可能

ユーザ情報を元にDB上の既存ユーザにマップ

メールアドレス等をキーにして対応付けを行う

勝手に対応付けると問題になるかも？

上記を組み合わせることにより様々なシナリオが考えられる

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 70 -

Oauth 2.0 認証モジュールの設定（その１）Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 71 -

Oauth 2.0 認証モジュールの設定（その２）Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 72 -

Part 2.
OpenAM導入事例
国立大学法人 北見工業大学 様
http://www.kitami-it.ac.jp/

Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 73 -

北見工業大学様 システムの特徴
 ユーザー（学生や教職員）はOpenAMに一度ログインすると、複数のWebアプリケーションをログイン操作なしで利用できます。
 ログインするとポータルメニューが表示されますが、ユーザ
ー権限やログイン場所(学内/学外)によって表示されるメニューが変化します。
 ログインしたユーザーが利用できないアプリケーションは表示されず、インターネットからログインするとイントラネット
専用アプリケーションも表示されません。
 システム全体設計やプロジェクトとりまとめは、兼松エレクトロニクス株式会社
が行いました。
 シングルサインオン システム構築は、 オープンソース・ソリューション・テクノロジ株式会社が行いました。
Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 74 -

北見工業大学様Copyright © 2012 Open Source Solution Technology Corporation All Rights Reserved.

- 75 -