クラウド時代のID管理とSSO（シングル・サイン・オン）
最新技術動向と導入事例
オープンソース・ソリューション・テクノロジ株式会社
代表取締役 チーフアーキテクト 小田切耕司

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

-1-

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

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

-2-

講師紹介






役 職 ： 代表取締役 チーフアーキテクト
氏 名 ： 小田切 耕司 (おだぎり こうじ)
所属団体等
 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 © 2013 Open Source Solution Technology Corporation All Rights Reserved.

-3-

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

OSに依存しないOSSのソリューションを中心に提供
Linuxだけでなく、AIX, Solaris, Windowsなども対応！



OpenAM, OpenLDAP, Sambaによる認証統合/
シングル・サイン・オン、ID管理ソリューションを提供
 製品パッケージ提供
機能証明、定価証明が発行可能
 製品サポート提供
３年～５年以上の長期サポート
コミュニティでサポートが終わった製品のサポート
 OSSの改良、機能追加、バグ修正などコンサルティン
グ提供

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

-4-

OSSTechの製品群 Unicorn IDM

ID管理
システム管理者

ID連携
Active Directory

Google Apps
Salesforce
ファイル
サーバー

バ

Web アプリ

LDAP

クラウド

SSO
Windows
ドメインログオン
ログイン

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

ユーザー

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

-5-

OSSTechの製品群（すべてOSSで提供）
原則Linux/Solaris/AIX共にRPMで提供●Samba for Linux/Solaris/AIX● ADの代替、高性能NASの代替●OpenLDAP for Linux/Solaris/AIX● 認証統合、ディレクトリサービス、シングルサインオンのインフラ●OpenAM for Linux/Windows● Tomcat, OpenLDAP対応で高機能なシングルサインオン機能を提供（旧OpenSSO)●Unicorn ID Manager for Linux● Google Apps, Active Directory, LDAPに対応した統合ID管理

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

-6-

OSSTechの製品群（すべてOSSで提供）
原則Linux/Solaris/AIX共にRPMで提供●Chimera Search（キメラサーチ） for Linux●

アクセス権の無いファイルは表示されない全文検索システム●LDAP Account Manager for Linux●

管理機能の弱いOSSのLDAP/SambaにWebベースのGUIを提供●ThothLink（トートリンク） for Linux
WebブラウザからのWindowsファイルサーバアクセス機能を提供● SSLBridge後継製品●●Mailman for Linux
日本語での細かな問題を解決● YahooメールやGoogle Appsのメーリングリスト機能を補完●

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

-7-

統合認証とシングルサインオン

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

-8-

統合認証とシングルサインオンの必要性
 クラウド（外部のWebサービスの業務利用）が普及したことで、統合認証/シングルサインオン/ID管理の必要性がが急上昇
 社内Webアプリ（オンプレミス）の利便性・セキュリティ向上のための需要も同時に増加中
 社内にある多数ありWebアプリ（オンプレミス）へのアクセスをシングルサインオンで管理し、利便性を向上させたい 社内のWebアプリと外部のWebサービス（Google Apps、Salesforceなど）をシングルサインオン連携したい（クラウドサー
ビス利用者）
 クラウド基盤の構成コンポーネントとして、OpenAMを利用した
い（クラウドサービス提供者）
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

-9-

統合認証とシングルサインオンとID管理 統合認証とシングルサインオンとID管理は同時に使うことで最大の効果を発揮する
 ユーザーID/パスワードはシングルサインオンシステムで一元管理可能でも、各アプリケーション・サービス毎に必要なユーザー
情報は、基本的には個々に管理される
 ID管理ツールなどを利用した一元管理をしなければ、ID管理は破綻する
 クラウドサービスにおいても、ID管理は必要
 クラウドサービスもユーザー情報を保存することから、ID管理の対象となる
 ID管理用のAPI（プログラムインタフェース）を備えているものが多い（Google Apps、Yahoo! など）
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 10 -

統合認証とは？
 WindowsやLinux/UNIXの認証をできる限りユーザの負担が少ない方法で提供する
 色々なコンピュータへ同じアカウント名とパスワードでログインできる コンピュータのログインだけでなく、その上で動く様々なサービスへも同じパスワードでログインできる※例） メールサーバ(POP,IMAP,SMTPサービス)の認証
 PPPやVPNなどのリモート接続のためのRadius認証
 ApacheやIISなどのWebサーバのBasic認証やForm認証

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

- 11 -

プロビジョニング（ID配布）による統合認証 複数のシステムに同じアカウントとパスワードを設定
 ID管理データベースは別々になっている
 システム毎にやるのは大変 「統合ID管理機能」を持つソフトウェアを導入するのが一般的
 統合ID管理ソフトは、複数システムのアカウントとパスワードを集中
管理 1ヶ所でIDを登録すると複数のシステムへ自動的にIDを一括登録する機能
 ユーザが1ヶ所でパスワードを変更すると関連するすべてのシス
テムのパスワードを変更する機能
 既存システムにできる限り手を加えずに実現できる方式として大変実用的 パッケージソフト利用やSaaS利用において「ID統合による統合認証」に対応していない場合にも有用な方法
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 12 -

プロビジョニング（ID配布）による統合認証SP
IdP：LDAPサーバ
認証
ユーザー情報

SP
認証
SP

ユーザー情報ID連携サーバ
ユーザ登録
パスワード変更

IdP：ADサーバ
・ユーザ登録をADとLDAPに一括して行う
・パスワード変更も同時に行う
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 13 -

ID統合による統合認証とは？
 望ましい形はIDをひとつに集約し、これですべての認証を統合してしまうこと
 ID連携による統合認証は、導入費用が既存ソフトを改修する費用よりも安くないとメリットはない IDをひとつに統合する方法① UNIX/Linux上のLDAPによる統合認証② Windows ActiveDirectoryによる統合認証③ UNIX/Linux上のActiveDirectoryによる統合認証④ Windows上のLDAPによる統合認証※RDBによるID統合は不可能ではないが容易ではない
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 14 -

ID統合による統合認証
SP

認証

SP
認証

SP

ユーザー情報IdP：LDAPまたはADサーバ

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

- 15 -

UNIX/Linux上のLDAPによる統合認証









サーバやクライアントにUNIX/Linux（Mac OS XもUNIX系）を利用している場合に推奨
メールサーバやWebサーバ、アプリケーションサーバがUNIX/Linux上で動作している場合も推奨
UNIX/Linuxが標準でPAM (Pluggable Authentication Module：IDとパスワードで認証するモジュール、ICカード認証や生体認証など他の認証方式もPAMがあれば実現可能）とNSS（Name Service Switch：ユーザやプロセスにUNIXのuid,gidを提供する）をサポートしている
JavaやRuby, Perl, PHP, Pythonなどのプログラム言語がLDAPのクラスやモジュールを提供している
PAMはUNIX/LinuxのOSログインから、それの上で動く様々なサーバソフトの認証も制御することのできるモジュールで大変汎用的にできているため、PAMに対応しているvsftpや
sshd, postfix, dovecotなどは簡単にLDAP認証に切り替えることが可能
ApacheやProFTPdやFreeRADIUSなどPAM経由だけでなく、直接LDAPのAPIを利用することでLDAP認証を実現しているものもある
すべてのOSやプログラムが認証データベースもしくは認証プロトコルとしてLDAPのそれを利用することで同じIDとパスワードでOSやアプリにログインできることになる

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

- 16 -Windows ActiveDirectoryによる統合認証
 Windowsでは標準機能で実現可能 クライアントをADドメインに参加
 UNIX/Linuxの場合でもPAMを使うことで利用可能① LDAPのPAMを使う方法② KerberosのPAMを使う方法③ SambaのWinbind機能のPAMを使う方法

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

- 17 -

LDAPのPAMを使う方法
 認証後プロセスが動作するためのuid,gidが必要になるため、これをNSSから利用できるようにするにはAD側にSUA（Subsystem for UNIX-based Applications）などを使ってUNIX用の拡張スキーマを入れる必要がある ADを変更する必要があるので敬遠されがち

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

- 18 -

KerberosのPAMを使う方法
 Kerberosサーバで認証後にチケットもらってサーバにアクセスする方法 セキュリティが強固になるが、uid,gidが必要
 Kerberosサーバは提供してくれないため、AD側にUNIX用の拡張スキーマを入れ、NSSだけNISを使う
 Kerberosのチケットを使うことができるので、一度ログイ
ンすれば同じPAMを使うサービスに再度パスワードを入力せずに利用できるSSOも実現可能

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

- 19 -

SambaのWinbind機能のPAMを使う方法
 Kerberosのチケット方式で認証し、udi,gidをWindowsのSID（セキュリティ識別子）から自動生成することが可能
 SUAのインストールは不要（SUAを入れてADのUNIX拡張スキーマでuid,gidを提供することも可能） PAMもNSSもSambaが提供するwinbindモジュールを使うことで実現可能 認証でKerberosのチケットを使うことができるので、一度ログインすれば同じPAMを使うサービスに再度パスワードを入力せずに利用できるSSOも実現可能

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

- 20 -

それぞれの長所と短所


LDAPの制限
Sambaを使えばWindowsクライアント統合認証も可能だがSamba3系ではADのグループポリシーをサポートしていない
 ADの制限 ADで統合認証するにはWindowsのCALが必要
ユーザ数が増えるとコストがかさむ Windowsサーバの信頼性がUNIXサーバより劣る場合が多く、UNIXサーバの認証をADに任せるとWindowsサーバの障害がUNIXサーバの障害へつながってしまう ADとLDAPの両方を導入し、WindowsクライアントにはADを使った統合認証を提供し、UNIX/Linux/Mac OSクライアントにはLDAPを使った統合認証を提供し、ADとLDAPの間をID連携による統合認証を行うという方式を取るユーザが多い
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 21 -

Unicorn ID ManagerによるAD,LDAP連携
 WebブラウザからCSVを投入するだけで統合ID管理
Active DirectoryUnicorn ID Manager
Provisioning API(HTTPS)

ユーザー情報パスワード情報

Google Apps

LDAPS

ユーザー情報パスワード情報

LDAP
ユーザー情報パスワード情報管理者

Web画面
パスワード変更
Web管理画面
CSVファイルアップロード

一般ユーザーCopyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 22 -

UNIX/Linux上のADによる統合認証







ADとLDAP両方の欠点を補う方法
UNIX / Linux上でADを動作させ統合認証する方法
ADとほぼ同機能を持ったSamba4がリリースされた
LDAPによる統合認証が実現できる
UNIX/Linux(Mac) はLDAPクライアントになる
Windows(Mac)クライアントはSamba4を通してLDAPの中に格納されたIDでAD（Kerberos）認証が可能

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

- 23 -Windows上のLDAPによる統合認証








ADはLDAPの機能を包含しており、Windowsの上でADではないLDAPを動かす意
義はあまり無い
しかし、OpenLDAPなどのUNIX系LDAPの代わりにADを使うのは品質、性能、柔軟性の綿で不安要素が多い
OpenLDAP for WindowsというOSSの製品もある
Javaの上で動くOpenDS/OpenDJやOracle Directory Serverなど商用のLDAP製品も多数ある
Windowsサーバの上でOpenLDAPを利用する場合もCALを購入する必要がある
商用製品の場合は該当製品のユーザライセンスに加え、WindowsのCALの２重の費用がかかるWindows XP,Vista,7クライアントの上にサーバソフトをインストールしてサーバ用途に利用することは費用がかかる以前にライセンス違反となる（Windowsクライアント製品の場合、サーバプロセスへの同時接続数に制限がかけられている）

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

- 24 -

シングルサインオンとは






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

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

- 25 -

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

クラウド・サービス SP
Google Apps
SalesForceなど
プライベートクラウド
/ASP

IdP
ユーザー情報認証
IdP

SP

B2B,B2C

IdP

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

ユーザー情報認証

SP
ユーザー情報認証

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

- 26 -

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

インターネット
SAML認証DMZ

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

認証はすべて社内で行う

B2B,B2C
認証チケット／
リバースプロクシ

IdP

（1）

SP

(2)

認証
チケット

（3）

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

アクセス
LDAP/AD
ID/Pass

パスワードは社内で管理

ユーザー

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

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

- 27 -

LDAP概念と設計入門

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

- 28 -

LDAPとは?


ディレクトリサービスを利用するための規約の1つ(RFCで定義)
–
–
–



高機能だが運用負荷や開発コストが高かったITU- T 勧告のX.500 ディレクトリ・サービ
スを「90 ％の機能を10 ％のコストで実現する」ために設計

商用LDAP製品も多数存在––

ディレクトリサービスとは、キーを基に関連情報を取り出す仕組み
ユーザ管理、電話帳、リソース管理などに利用

Sun Java Directory Server, Red Hat Directory Server, Novell eDirectoryなど
MS Active DirectoryもLDAP準拠（認証はKerberos）

オープンソースソフト–

OpenLDAP–Linux ディストリビューションに同梱されるオープンソースのLDAP

Red Hat / Fedora Directory Server かつてのNetscape Directory ServerをOSSにしたもの(RHは有償、Fedoraは無償）–

Apache Directory Server Apacheプロジェクトが進めるJavaで書かれたDS

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

- 29 -

LDAPのプロトコルスタック（X.500との違い）

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

- 30 -

LDAPにおいてX.500から削除されたもの

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

- 31 -

ディレクトリの機能モデル
 DSA(Directory Service Agent):ディレクトリ情報を管理する個々のシステム。
ディレクトリはDSAの集合体として構成される。
 DUA(Directory User Agent):ディレクトリの利用者に代わってディレクトリへアクセスする機能（プログラムやコマンド、ライブラリ） LDAPでは単純にLDAPサーバーとLDAPクライアントと呼ぶことが多い

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

- 32 -

LDAP概念を勉強のための参考書
 LDAPハンドブック

ディレクトリ・サービス標準プロトコル– 出版社: ソフトリサーチセンター(2002/03)– 発売日： 2002/03

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

- 33 -

LDAPとRDBMSの違い
 LDAPはﾈｯﾄﾜｰｸﾌﾟﾛﾄｺﾙ、SQLは言語

用途
構造
スキーマ

更新
分散
操作
検索手法

LDAP

RDBMS

検索性能重視、頻繁な更新には向かない
木構造（行や列といった概念はない）
既存の登録済みスキーマ(ObjectClass)を利用するのが一般的
トランザクションの概念はない(トランザクション機能を持った製品もある）
大量更新には向かないので１時間に数件といった更新頻度のものに利用するツリーの枝単位で分散配置が可能
LDAP（ネットワークプロトコル）で操作
プロトコルは単純
木の枝葉をたどるイメージ

検索だけでなく頻繁な更新も重視
表構造（行や列が存在）
ユーザが業務に合わせて個別に設計し、利用する
トランザクションの概念あり
１秒間に何十、何百もの更新に耐えられる設計となっている
キーの範囲で分散配置が可能
SQL（プログラム言語）で操作
複雑な操作が可能
表の行を走査するイメージ

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

- 34 -

LDAP概念に関する勘違い
 RDBMSは永続的なユーザ情報を蓄えるために使う、

LDAPは管理情報を集約するために使う（社員DBはRDMS、全社認証システムはLDAP）
 LDAPは検索重視となっているが、RDBより必ずしも早い
わけではない LDAPはスケールアウト型負荷分散がやりやすいから
 更新がすぐに反映されるとは限らない– ユーザ追加やパスワード変更がすぐにされないことがある(だからWindowsはパスワードをキャッシュする）
 マルチマスターの利用は要注意– トランザクションやロックの概念が弱い– uid,gidの自動割り振りをLDAPでやると危険
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 35 -

負荷分散方法１：レプリケーション


同じ内容のサーバを複数用意する– サーバを増やすだけでスケールアウトする– 負荷分散装置やldap.confで負荷を分散– １つのサーバが持つデータ量は同じなので規模が大きくなると更新性能が低下– Syncreplではサブツリーだけを複製することも可能(slave)(slave)(master)

グループA

グループB

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

- 36 -

負荷分散方法２：リファラル
 サブツリー単位でサーバを分散する– ldap.confでbaseツリーを変える（負荷分散というよりも管理分散）– １サーバがもつデータ量が減るので更新性能も上がる– referralが返ったら別なサーバを見に行くのはプログラム側の責任

分散管理(referral)
東京本社
ＬＤＡＰサーバ
大阪支社
ＬＤＡＰサーバ

本社社員
支社社員
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 37 -

DIT(Directory information Tree)の概念
 概念として組織構造をあげる書籍が多いが．．．

会社

営業部

技術部

営業一課

開発１課

人事部

開発２課

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

- 38 -

DIT(Directory information Tree)の概念
 実構造としては管理単位で分ける
dc=company,dc=com

ou=Users

ou=Groups

ou=Computers

uid=odagiri

cn=salescn=techCopyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 39 -

DIT(Directory information Tree)の設計(1) 組織構造にマッピングしないこと、管理対象で分ける
dc=company,dc=com
ou=Users
ou=Tokyouid=odagiri
ou=osaka
uid=takeda
ou=Groups
cn=techcn=salesou=Computers

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

- 40 -

DIT(Directory information Tree)の設計(2) 組織構造にマッピングしないこと、管理対象で分ける
dc=company,dc=com
ou=Tokyoou=Users
uid=odagiri
ou=Groups
cn=techou=Computers
ou=osaka
ou=Users

uid=takeda

ou=Groups

cn=salesCopyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 41 -

LDAPで何ができるか？
 Linuxユーザの統合管理(Mail,FTP,Telnet,Proxy,sshなど）
 Samba/Windowsユーザの統合管理 Webサーバ（Apache）のアクセス制御
 電話帳、メールアドレス帳
 PKI（公開キー）の保管場所として
 LDAPのスキーマはむやみに拡張しない

本当に必要か精査する

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

- 42 -

クラウドと共に普及する
シングルサインオン

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

- 43 -

サービスを利用するには必ず必要な「認証」
ActiveDirectory

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

ファイル
サーバー

LDAP

メールサーバー
Client/Server

Windowsログオン/
LDAP 認証

ログイン

Webアプリログイン

ログイン

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

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

- 44 -

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

Google Apps
Salesforce

ファイル
サーバー

LDAP

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

クラウド

Webアプリ

SSO
Windowsログオン/
LDAP 認証

ログイン
ログイン

ユーザー

今日は
この部分のお話

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

- 45 -

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

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

- 46 -

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

クラウド・サービス SP
Google Apps
Salesforceなど
プライベートクラウド
/ASP

IdP
ユーザー情報認証
IdP

SP

B2B,B2C

IdP

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

ユーザー情報認証

SP
ユーザー情報認証

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

- 47 -

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

インターネット
SAML認証DMZ

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

認証はすべて社内で行う

B2B,B2C
認証チケット／
リバースプロクシ

IdP

（1）

SP

(2)

認証
チケット

（3）

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

アクセス
LDAP/AD
ID/Pass

パスワードは社内で管理

ユーザー

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

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

- 48 -

シングルサインオンを実現するソフトウェア
 Webアプリケーションにおけるシングルサインオンを実現するためのプラットフォームとなるソフトウェア
 現在はオープンソースだが、元はSun Microsystems社の商用製品（Access Manager）
 弊社で製品パッケージを提供

 SAMLを扱えるオープンソースのソフトウェア
 Shibboleth1.3以前のバージョンがSAML1.1を実装
 Shibboleth2.0よりSAML2.0を実装
 学認フェデレーションでの主な認証ミドルウェアとして使用
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 49 -

シングルサインオン
技術動向

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

- 50 -

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

- 51 -

OpenAMで実現する
シングルサインオン・ハブ
オープンソースのOpenAMだから
高機能・安価に実現できる

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

- 52 -

混在する複数のSSO環境
Shibboleth IdP で SSO を実現(Shibboleth は SAML を利用しているが、仕様上 OpenAM では代替不可能)SAML IdP を導入してSSO を実現
Google Apps
SAML

SAML

Salesforce

クラウドSSOセグメント
リバースプロキシ/
エージェント

大幅な改修はした
くないため、エージ
ェント型/リバースプ
ロキシ型で SSO を実現

Shibboleth
SP
Shibboleth
IdP

学認（Shibboleth）
SSOセグメント

社内SSOセグメント

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

- 53 -

OSSで実現するシングルサインオン・ハブ
Shibboleth
SP
Shibboleth

Google Apps

IdP

Salesforce

クラウドSSOセグメント

OpenAM（認証サーバー）

学認（Shibboleth）
SSOセグメント

リバース
プロキシ/
エージェント社内SSOセグメント

SSO セグメントを結合するハブとして OpenAM を利用。
ユーザーは OpenAM へのログインさえ完了していれば、全てのアプリに SSO 可能
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 54 -

シングルサインオン・ハブを実現するための機能
 認証機能 ユーザーの本人性を確認する。セキュリティ強化のために、多要素認証が望ましい。
 ユーザー情報保存機能
 認証情報や他システムに連携するユーザー情報を保存する 外部システムと連携可能なインタフェース
 フェデレーション（SAML, OpenID, OAuthなど）
 REST API SDKCopyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 55 -

シングルサインオン方式

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

- 56 -

シングルサインオン方式の詳細（1） フェデレーション：SAMLによるシングルサインオン– Secure Assertion Markup Language– 認証、認可、ユーザ属性情報などをXMLで送受信するためのフレームワーク– 標準化団体OASISにより策定– GoogleApps, Salesforceなどが採用– 今後OpenIDの普及によりOpenAMでOAuth実装予定
 エージェント方式– SSO対象のWebアプリが動作するサーバー上にアクセ
ス制御用のモジュールを配置する方式– サーバーのバージョンに影響を受ける
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 57 -

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

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

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

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

- 58 -

フェデレーション：SAMLによるシングルサインオン

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

- 59 -

エージェント型

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

- 60 -

リバースプロキシ型

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

- 61 -

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

認証情報をPOST

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

- 62 -

シングルサイオン方式の採用基準
WebアプリケーションがSAMLに対応しているか
No
No

Yes

Webアプリケーションの改修が可能かNo

SAMLを採用

代理認証方式を採用

Yes
WebアプリケーションをSAMLに
SAMLを実装
対応させることができるか
Yes
No
No
Yes
エージェント方式を採用
ポリシーエージェントがWebサーバ/APサーバに対応しているか
リバースプロキシ方式を採用
No
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 63 -

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

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

- 64 -

OpenAMの認証方式（多要素認証）Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 65 -

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

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

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

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

- 66 -

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

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

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



認証方式間での連携–

組合わせて使うことを前提にしている認証方式もある

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

- 67 -

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

認証方式３（任意）評価

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

- 68 -

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

ドメインログオン①

自動チケット送付②

OpenAM③

認証、認可、
属性情報

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

- 69 -

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

- 70 -

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

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

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

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

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

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

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

- 71 -

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



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

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

–

導入コストの低減–

所持品の軽減フィッシングへの対応–

HMAC（RFC2104:Keyed-Hashing for Message Authentication）を利用–

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

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

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

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

- 72 -

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

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

- 73 -

学術認証フェデレーション
学認：GakuNinとは？

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

- 74 -

学認とは

学認とは？

参考） 「学術認証フェデレーションシンポジウム」の資料より
https://www.gakunin.jp/docs/open/3

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

- 75 -

学認の構成参考） 学術認証フェデレーションの資料より
https://www.gakunin.jp/

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

- 76 -

学認で利用されている技術SAML（Security Assertion Markup Language）


学認に参加し、SPやIdPと連携するためには・・・

認証情報の連携を行うプロトコル
学認のSP - IdPのやりとりはSAMLで行うと取り決め

SAMLを扱える認証基盤の構築が必要
ソフトウェアはSAMLを扱えれば何でも良い

しかし、実際はほとんどShibbolethで構築

学認のシステム運用基準で推奨されている
GakuNin では，フェデレーション内で利用するソフトウェアとして，上記プロトコルの実装例であるShibboleth を利用することが推奨される。
（※上記プロトコルとはSAMLのこと）
学術認証フェデレーションシステム運用基準（Ver 1.2）より引用
https://www.gakunin.jp/docs/files/GakuNin_System_SpecV1.2.pdf

学認のWebページにShibbolethの情報があり、構築しやすい

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

- 77 -

学認(Shibboleth)の動作の仕組み参考） 「学術認証フェデレーションシンポジウム」の資料より
https://www.gakunin.jp/docs/open/3

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

- 78 -

OpenAMとShibbolethの連携

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

- 79 -

学内の認証をShibbolethで？ (1)

学認へ参加する場合はShibbolethで構築するのが良いShibbolethが学認推奨のソフトウェアである点
メタデータの取扱いや属性情報の用意等、Shibboleth独自の機能を使った方が運用上において楽な点【例えばOpenAMで学認に参加することを考える】
SAMLでやりとりを行うため、OpenAMと学認との連携は技術的には可能。
しかし、OpenAMで学認との連携するシステムを運用していくためは、Shibbolethの独自機能を補う仕組みを用意する必要がある。

Shibbolethによる学内のシングルサインオン
 学認用に導入したShibboleth IdPを使い、学内のシングルサインオンを実現できないか？（せっかくシングルサインオン製品を導入したのだから）

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

- 80 -

学内の認証をShibbolethで？ (2)

学内のアプリケーションをSAML化すればShibbolethでのシングルサインオン環境を実現できる

SAMLに対応していないアプリは改修が必要

他にもこんな懸念も・・・


学認との接続ノウハウの情報はあるが、学内アプリのSSO化の情報が少ない
アプリケーションのSAML化ってどうすれば良いかわからない
アプリケーションの改修にコストがかかるShibbolethの標準機能では認証方式はID/Password形式



デスクトップSSO/クライアント証明書等柔軟な認証方式を採用できない
複数の認証方式の組み合わせ認証連鎖を行えない
Shibbolethでは認証のみ提供。認可の提供はない。
Shibbolethは学内アプリケーションのシングルサインオンに不向き
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 81 -

学内のシングルサインオンはOpenAM

学内のシングルサインオンはOpenAMで行うのが良い

OpenAMはシングルサインオンの方式としてSAML以外も用意

多様な認証方式を用意

様々な方式を用意しアプリの改修なしでシングルサインオンを実現可能
ID/パスワード認証以外に認証方式を標準で備えており、システムのセキュ
リティや用途にあった認証方式の選択が可能

学内はOpenAM、学認はShibbolethという構成がベスト
学内SSO環境

学認フェデレーション環
境

認証

学内アプリ

OpenAM
学認SP
Shibboleth(IdP)

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

- 82 -



OpenAMとShibbolethの連携


OpenAMとShibbolethが別々では、それぞれで認証が必要

シングルサインオン製品を活かせていない！
学内SSO環
学認フェデレーション環
2回認証をしないといけ境
境
ないのは煩わしい・・・

そこでOpenAMとShibbolethを連携する

Shibboleth IdPの認証をOpenAMで行う


具体的にはShibbolethがOpenAMにRest APIによる認証有無の問い合わせを行い、ユーザーはShibbolethでのログイン操作は行わなくて済む

ユーザーは一度の認証で、学認、学内のアプリケーションが使用可能
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 83 -

OpenAMとShibbolethの構成
学認：NII
Shibboleth
SP

SAML

OpenAM
IdP
OpenAM
リバプロ

認証連携

ヘッダー認証
または
代理認証
OpenAMSP
SAMLに対応できない
既存アプリ

Shibboleth IdPはOpenAMと連携し、OpenAMでログイン完了するとShibbolethのログインも完了

Shibboleth
IdP
SAML

Shibboleth
SP

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

- 84 -

OpenAMによるシングルサインオン
システム導入事例

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

- 85 -

某通信会社グループ共通
シングルサインオンシステム

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

- 86 -

某通信会社グループ共通
シングルサインオンシステム
ユーザー総数 約２５万人● ID/パスワードとユーザー証明書の多要素認証(認証連
鎖)● 一部グループ会社ユーザーはSAML 2.0対応IdPによる認証連携● OpenLDAPのパスワードポリシー対応モジュールの開発● 保護対象アプリケーションとの連携はPolicyAgentを用いたリバースプロキシ型●

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

- 87 -

某通信会社グループ 全体構成図
グループ会社
ユーザーE
OpenAM

グループ会社
ユーザーW

SSO
リバース
プロキシ

グループ共通イントラネット

SAML 2.0による認証連携

グループ会社S社
A社認証基盤IdP

保護対象
企業グループ
SSOポータル
アプリケーション
グループ共通システム

グループ会社D社
B社認証基盤IdP

一部グループ会社では各社の認証基盤をIdPとしてOpenAMと連携
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 88 -

某通信会社グループ 構築のポイント
グループ
ユーザー

アクセス

SSO
リバース
プロキシ

ユーザー証明書

ポイント1

ログイン

OpenAM

保護対象
グループ会社
SSOポータル
アプリケーション
グループ共通
システム

ポイント2
アクセス

SAML2.0認証連携

ポイント3

各社認証基盤IdP
OpenLDAP

グループ会社
認証統合基盤

ログイン

一部のグループ
会社ユーザーCopyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 89 -

多要素認証●

ポイント1➢ ID/パスワードとユーザー証明書を用いた多要素認
証➢ 「認証連携」での接続方法も、同等の認証レベルをセットするカスタム認証モジュールを開発➢ OpenAMリバースプロキシのポリシーでレベルをチェックしアクセス制御

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

- 90 -

多要素認証時の認証・認可シーケンス●

認証レベル判別シーケンス

ユーザー(ブラウザ)

OpenAM

ID/PW ログイン

Level0

リバース
プロキシ

保護対象
サービス

ID/PW認証
だけではアクセス不可OpenAMセッション
アクセス
ID/PW ログイン
ユーザー証明書Level3

ID/PWと証明書認証の両方でアクセス可能認証方式からLevelを付与

OpenAMセッション
アクセス

SSO Level3

Level3 コンテンツ

Levelに基づきアクセス制御認証連携

Level5OpenAMセッション
アクセス

SSO Level5

Level5 コンテンツ

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

Levelに基づきアクセス制御- 91 -

異なるIdP製品との認証連携●

ポイント2➢ 一般的にユーザーはOpenAMで認証を行う。
➢ 一部のグループ会社ユーザーは各社認証基盤のIdPで認証を行い、OpenAM保護下のグループ会社
SSOポータルアプリケーションとはSAML認証連携でアクセス可能とする。

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

- 92 -

異なるIdP製品との認証連携シーケンス
一部グループ
会社ユーザー自動
リダイレクト

各社認証基盤

OpenAM

リバース
プロキシ

ログイン

保護対象
サービス

OpenAMセッションを確認
ポータルリンクからログインぺージへリダイレクト
SAML SPによる認証連携

初回アクセスのみ認証連携を行う

OpenAMセッション

OpenAM
セッション
開始

アクセス
２回目以降の
アクセス
シーケンス

OpenAMセッションを確認
SSO

コンテンツ

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

- 93 -

OpenLDAPポリシーへの対応●

ポイント3➢ OpenAM 9系では対応していないOpenLDAP(RFC標準)のアカウントポリシーエラー対応のため
OpenAMの拡張開発を行った。
➢ 拡張を行ったOpenAMは、パスワード有効期限切れなどOpenLDAPからの戻り値を判定し、任意のURLへ遷移する。

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

- 94 -

OpenLDAPポリシーへの対応●

OpenLDAPエラー情報判定シーケンス

ユーザー(ブラウザ)

OpenAM

ログイン
LDAP バインド

OpenLDAP
アカウントロックパスワード有効期限など
ポリシーのチェック

LDAP 応答

ポリシー対応のエラー画面表示

LDAP応答の内容をハンドリングし適切な画面を応答

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

- 95 -

某総合電機メーカー
シングルサインオンシステム

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

- 96 -

某総合電機メーカー
シングルサインオンシステム
 規模：グループ企業７社、約５０００人、海外22拠点
今後拡大予定 海外ディーラー向けの技術情報やマーケティング情報のCMSおよびECサイトへのシングルサインオン
 CMS, ECサイトとの連携はOpenAM PolicyAgentとお客様開発の連携モジュール
 SAML認証と代理認証を利用 対象ユーザー、保護対象アプリケーションはインター
ネット上に点在

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

- 97 -

某総合電機メーカー 構成図
パートナー

Login

Internet

CMS
マーケティングサイト
SSO

OpenAM
Login
パートナー

SSO

CMS
マーケティングサイト

Login
SSO
パートナー
Login

認証は一カ所
全てのシステムへSSO
SAMLや代理認証

SSO

CMS
テクニカルサイト

ECサイト

パートナー

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

- 98 -

国立大学法人
名古屋工業大学

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

- 99 -

名古屋工業大学様 事例のポイント

規模 学生数 約5,800人 教職員数 約510人
旧Sun製品の置き換え
 旧Sun製品（Sun Java System Access Manager）からの移行を実現
 旧Sun製品のOracle後継製品を導入する場合はコスト高
 Sun Java System Access Managerの後継であり、OSSのOpenAMを採用
 他にもLDAPにOpenLDAP, ID管理にUnicorn IDMと積極的にOSSを採用
 ICカードによる認証とID/パスワードによる認証の使い分け アクセスリソースに対しての認証レベルの使いわけ 「ICカードによる証明書認証」と「ID/パスワードによる認証」の二つの認証方式を用意
 重要なリソースへのアクセスの際にはより安全なICカードで認証したユーザー
のみをアクセス可能とした
 日立製作所とオープンソース・ソリューション・テクノロジで実現

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

- 100 -

名古屋工業大学 構成図
ユーザー
アクセス

SSO
リバース
プロキシ

ユーザー証明書

ポイント1

ログイン

保護対象
学内ポータルアプリケーションSSO
OpenAM

ポイント2
Active Directory
ID連携

OpenLDAP

ID連携
保護対象
Unicorn IDM

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

- 101 -

名古屋工業大学 認証の使い分け●

ポイント1➢ ICカードを使った証明書認証を基本とする➢ 証明書認証に失敗した場合（証明書の提示が無い）にログイン画面を表示しID/パスワードを用いた認証➢ 証明書認証とID/パスワード認証では異なる認証レ
ベルをセット➢ OpenAMリバースプロキシのポリシーでレベルをチェックしアクセス制御

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

- 102 -

名古屋工業大学 認証シーケンス
証明書提示
有り

ユーザー(ブラウザ)

OpenAM(1) ログイン画面表示
ユーザー証明書
ユーザー証明書

リバース
プロキシ

保護対象
サービス

証明書の提示有り
証明書による認証が成功証明書で認証を行って入ればアクセス可能(2) セッション発行(3) アクセス

証明書提示無し(1) ログイン画面表示(2) ログイン画面応答

証明書の提示が無い
ため、証明書認証失敗
ログイン画面応答(3) ID/パスワード送信(4) セッション発行

ID/PW認証
だけではアクセス不可(5) アクセス(6) 拒否画面応答
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 103 -

名古屋工業大学 ID管理●

ポイント2
➢ Unicorn IDMによるID連携を実施
 Active Directory と OpenLDAPのアカウントを同期➢ OpenAMとのシングルサインオンを実現 ユーザーはOpenAMにログイン済みであれば、再度の認証無しでパスワードの変更が可能
 UnicronIDMの管理者アカウントもシングルサイン
オンを実現

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

- 104 -

名古屋工業大学 パスワード変更
リバース
ユーザー(ブラウザ) プロキシ
OpenAMへログイン

Unicorn
IDM

OpenAM認証済みでHTTPヘッダーに
ユーザー名をセット
HTTPヘッダーのユーザー名で認証(1) パスワード変更
新パスワードActiveOpenLDAP Directory

ユーザー名(2) パスワード変更

新パスワード(3) 変更完了(4) パスワード変更(6) 変更完了(5) 変更完了

 ユーザーはOpenAMログイン済みなので新パスワードのみでパスワード変更可能
 Unicorn IDMによりOpenLDAPとActive Directoryのパスワードが同時変更

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

- 105 -

名古屋工業大学 管理者シーケンス
ユーザー(ブラウザ)

OpenAM(1) ログイン画面表示
ユーザー証明書(2) セッション発行

リバース
プロキシ

Unicorn
IDM

証明書の提示有り
証明書による認証が成功
特定の条件を満たしたアカウントであればアクセス可能(3) アクセス(4) 代理認証(5) 管理者ログイン成功

特定の条件を満たしたアカウントはOpenAMにログインすることで、Unicorn IDMの管理者としてログインすることができる。

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

- 106 -

大学法人 福岡大学 様

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

- 107 -

福岡大学様 システムの特徴
規模

9つの学部、2つの病院、22の付置施設で構成される総合大学
学生数 約21,000人
教職員数 約3,000人
ミッション

高い拡張性と柔軟性を持つ先進的SSO基盤の構築

日立製作所とオープンソース・ソリューション・テクノロジで実現


OpenAMとShibbolethによるハイブリッド型SSO基盤

システムのシングルサインオンを実現する認証基盤をOpenAMとShibbolethを使って実現様々なアプリケーションとのシングルサインオンを実現する基盤
ユーザーは1度の認証で学認と学内のアプリケーションを利用可能

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

- 108 -

学認

Shibboleth SP
Shibboleth SP

Shibboleth DS
SAML

SAML

福岡大学様
Apache(リバースプロキシ)

学内アプリ

SAML

ID/PW
認証

HTTP
Header

SAML

OpenAM(学内認証
サーバー)

Shibboleth SP

SAML
認証

認証連携

アクセス制御
ポリシー

学内SSO

学認連携

ユーザー

LDAP

Shibbolethの
外部認証機能を利用

Shibboleth IdP(Shibboleth
認証サーバー)
Shibboleth SSO

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

- 109 -

国立大学法人 北見工業大学 様

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

- 110 -

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

- 111 -

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

- 112 -

OpenAM 10
OAuth 2.0の機能

Facebook認証のアプリを簡単開発！

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

- 113 -

自社のサービスにFacebookなどのアカウントでログインしてもらうOAuth クライアント機能
OAuthサーバ
Facebook

OAuthクライアント
アクセス
ユーザ情報
の登録
アクセス
トークン

通販等の
会員登録制
サイト

Googleユーザのプロファイル
情報

MSN, 他

認可サーバ

アクセス
許可

登録時のオプションとして以下が可能
ログイン

登録申請フォームの自動記入● パスワードの新規登録● メール送付による本人性のチェック●

ユーザ

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

- 114 -OAuth クライアントとしてOpenAMを使う
OAuthクライアント
OpenLDAPOAuthサーバ

通販等の
会員登録制
サイト

Facebook
GoogleMSN, 他

アクセス

ユーザ情報
の登録

ユーザの
プロファイル
情報

OpenAM
通販等の
会員登録制
サイト

認可サーバ

アクセス
トークン
アクセス
許可
ログイン

ユーザー側のアプリはOAuthを知らなくてもFacebookなどで認証することが可能
ユーザ

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

- 115 -OAuth 2.0 のクライアントとして使う設定
管理コンソールで
簡単設定

詳細手順は弊社ホームページで紹介中

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

- 116 -

認可サーバとしての OpenAMと“tokeninfo” RESTサービス
OAuthクライアント

OAuthサーバ
Tokeninfo
RESTサービス
OpenLDAP
アクセス
トークン

ユーザの
プロファイル
情報

アクセス
トークン

Tokeninfo REST サービスの応答内容
トークンのタイプ、有効期間など● スコープで許可されたユーザ
情報

OpenAM
認可サーバ
アクセス
許可
ログイン

●

ユーザ

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

- 117 -

OpenAMのREST API●●

RFCで規定されたもの●

access_toke エンドポイント●

authorize エンドポイント

OpenAM独自●●

tokeninfoエンドポイント●

トークンの検証●

属性の設定

トークン管理用エンドポイント

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

- 118 -OAuth 2.0の認可サーバとして使う
設定
管理者用ＧＵＩを使って簡単に設
定可能

スコープをカスタマイズしたクラス

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

- 119 -

OpenID Connect
は対応中！
●OAuth 2.0 の土台の上にOpenIDを構築●

OpenAM 10.2 (2013, Q2)で対応予定●

Facebook相当のOpenIDの認証サーバーをOpenAMを使って自社（オンプレミスやプライベー
トクラウド）で構築可能になる
Copyright © 2012 Open Source Solution

Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.
Technology, Corp.- 120 -Oauthサーバ機能：
Facebookなどの認証サーバーを独自に構築可能
OAuthサーバ
OAuthクライアント
アクセス
ユーザ情報
の登録
アクセス
トークン

通販等の
会員登録制
サイト

ユーザの
プロファイル
情報
OpenAM
認可サーバ

アクセス
許可

ログイン

ユーザ

FacebookやGoogleなどに依頼していた認証サーバー機能を自社で構築可能●セキュリティ対策●プライベートクラウドの構築

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

- 121 -

コアトークン・サービス（様々な認証トークンに柔軟に対応）
コアトークンサービスの概
念図
トークンの要求

XML

トークンの払出し
OAuth トークン

JSON

OpenAM トークン

Cookieトークンの交換要求（※）
異なる種類のトークン

コアトーク
ン

SAML トークン

その他のトークン(※）token exchange はOpenAM 10.9で予定されている機能で現在は使用できません。

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

- 122 -

OSSTechのOpenAMへの取り組み

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

- 123 -

オープンソースであること●

ソース修正はオープンソースだからこそ

実戦投入

新規課題

改良

追加

OpenAM
ソースコード問題点の改良、要件に合わせた機能追加
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 124 -

オープンソースであること●

ソース改修力は課題解決力

案件

新たなる
課題

要件

OSSTech
ノウハウ
技術
改修

実戦投入

OpenAM
全てのサイクルをサポートできる
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 125 -

OpenAM
ソースコードへの貢献

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

- 126 -

コミッター数
社内開発者6名● コミット権限のある社内開発者4名● OpenAM コミッター総数37名●

ForgeRock社

OSSTech社
commit４名

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

- 127 -

コミット件数
社内コミッターによるコミット件数111件● ForgeRockツリーのコミット総数は3346件●

ForgeRock社

OSSTech社
111件
４名

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

- 128 -

問題修正件数
社内コミッターによる修正件数66件● 現在のチケット数1739(重複等含む)●

ForgeRock社

OSSTech社
111件
４名

66件

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

- 129 -

コミット例
nginexエージェント開発● ユーザーデータストアの修正➢ JDBCの設定が共有されてしまう問題➢ ログ出力の改善● コマンドツール(ssoadm など)の修正➢ エージェントの設定に不正な値が登録される問題➢ Windows 用ツールが動作しない問題● ファイルアップロードの修正➢ Safari・Chromeでファイルアップロードが動作しな
い問題●

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

- 130 -

コミット例
メモリリーク関連の修正➢ エージェントのメモリリーク➢ HTTPコネクションのリーク➢ DBコネクションのリーク● マルチバイト文字➢ マルチバイト文字の表示の問題● 日本語化➢ 日本語表示の追加➢ 誤訳の修正●Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 131 -

OSSTech版カスタマイズ

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

- 132 -

OSSTech版カスタマイズ●

OpenLDAPと親和性向上＞自社ソリューション
➢ OpenAMにOpenLDAP専用の設定を追加➢ OSSTech社製OpenLDAP向け拡張スキーマを用意➢ OSSTech社製OpenLDAPをSHA-2対応にアドオ
ンモジュール開発

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

- 133 -

OSSTech版カスタマイズ●●

Tomcatとの親和性向上＞環境の統一化➢ OpenAM向けにパラメータを調整したTomcatをOpenAMとセットで提供
パッケージング＞セットアップ容易化➢ RPMパッケージとして提供➢ Windowsインストーラー提供

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

- 134 -

OSSTech版カスタマイズ
OpenAM10からのバックポート➢ 重要な修正、必要な機能をバックポート➢ 多重構成でのセッション数の共有➢ ポリシーの設定方法の改善➢ メモリリークの修正● プラットフォーム毎にエージェントを提供➢ RHEL5でも動作可能なApache2.2エージェントの提供● 日本語化➢ 画面の文字化け対策●

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

- 135 -

案件個別カスタマイズ

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

- 136 -

カスタマイズ事例●

OpenLDAP パスワードポリシー対応

ppolicyの対応をOSSTechの対応
LDAP認証モジュール修正Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 137 -

カスタマイズ事例●

OpenLDAP パスワードポリシー対応
OpenAM-9.5系ではLDAP標準のアカウントポリシー※に未対応● 全て同一の認証エラーとなるという課題●●

LDAP認証モジュールにLDAPのアカウントポリシー(パスワード有効
期限、ロック等)エラーをハンドリングし、個別のエラー遷移するよう改修※アカウントポリシーとはパスワード有効期限、アカウントロックアウト等
SunJavaDSやOpenDSを利用する場合は独自実装で対応されていた。
OpenAM-10から対応開始
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 138 -

カスタマイズ事例●

認証パラメータの追加

追加認証
パラメータ
OSSTechの対応
LDAP認証モジュール修正Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 139 -

カスタマイズ事例●

認証パラメータの追加●●

LDAP認証時に入力するユーザー名、パスワード以外に別パラメーターをドロップダウンリストとして表示し入力したい

LDAP認証モジュールを別パラメーター取得、表示可能なよう改修した

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

- 140 -

カスタマイズ事例●

認証モジュールの開発

特別な
認証方式を
OSSTechの対応
新規認証モジュール開発
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 141 -

カスタマイズ事例●

認証モジュールの開発●●

既存認証モジュールでは対応できない認証方式(リクエストヘッダ)で認証したい

要件に合った認証モジュールを開発し、既存モジュールとの認証連鎖とした。

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

- 142 -

開発事例●

Apacheより早いリバースプロキシを構築したい

リバース
プロキシに
パフォーマンスを！
OSSTechの対応
nginx用PolicyAgent開発
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 143 -

開発事例●

Apacheより早いリバースプロキシを構築したい●

Apacheによるリバースプロキシよりスケーラビリティが欲しい●

nginx※用 Policy Agentの開発※nginxとはスケーラビリティ、
パフォーマンスに優れる第三のhttpサーバー
netcraftの2011年資料第３位にnginxが伸びてきている
apacheほど多機能ではないが、リバースプロキシ利用では十分の機能を持たせられる
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 144 -

オープンソース・ソリューション・テクノロジ株式会社
http://www.osstech.co.jp/
Copyright © 2013 Open Source Solution Technology Corporation All Rights Reserved.

- 145 -