タイトル通り。これもまた自分用。
内容としては、SSO（Single Sign On）とは？というところから、
IDaaSにも言及しつつ、OpenAMとIDaaSの比較や構築の注意点等。
セミナー講師の人が言っていたことに、自分なりの解釈を加えて書き残していく。
※Active DirectoryとGoogle Suite間のSSOを、どうやって実装するのかというネタ探し目的で参加。ADFSでなぜうまくいかないんだ.....
そもそもSSO（Single Sign On）ってなに？
複数のサービスへのログインを一回で完了させるための仕組み
一回の認証でセッション情報を保持して、複数サービスへのアクセスを一元管理する。
メリットあるの？
ユーザー視点
いちいちログインしなくていいからラク。
IDとパスワードを1個覚えておけばいいからラク。
ユーザー的にはラクするための仕組み。
アカウント情報を統合してしまえば、守るべき情報も減るからセキュリティ的にも強固になるという印象。
管理者・サービス側のメリット
上述の通り、セキュリティの向上が見込める。
接続のコントロールが一元化出来て管理がラクになるらしい。
→ここはよくわかんない。管理者側で不要なセッション切ったりできるってことなんだろうか。
また、BtoB/BtoCのサービス提供者の場合、顧客の囲い込みが強化できるらしい。
→ピンとこないが、ID連携してる他のサービスを知れるからということなのだろうか。
SSOの種類
ざっくり以下の4つ。
1.エージェント方式
2.リバースプロキシ方式
3.代理認証方式
4.フェデレーション方式
以下ざっくり説明
エージェント方式
SSOでログインされる側のシステム（SP：Service Provider）にエージェントを入れる方式。
メリットはネットワークの構成変更がないこと。
デメリットは、エージェントを入れないといけないので対象システムの改修が必要。
少数の社内システム同士でSSO実装したいときによく使うらしい。
リバースプロキシ方式
SSOを提供するシステム（IDP：Identity Provider）と、SPのシステムの間にプロキシサーバーを置く方式。
メリットは対象システムにエージェントは不要で、SSOでのアクセス制御を集中管理できること。
デメリットはネットワーク構成変更が必要なこと。
社内システム同士のSSOを実装したいが、エージェント方式使えないくらい大量にあるときや、SSO実装以降に対象システムを増やす予定があるときに使われるらしい。
代理認証方式
構造的にはリバースプロキシと同じ。
リバースプロキシ方式よりも導入難易度は低い。らしい。
IDとパスワードの情報は個別管理が必要でセキュリティ的に他の方式より弱い。
仕方なく、、以外では採用することはほぼないらしい。
フェデレーション方式
これが流行りらしい。これの話を聞きたかった。
Qiitaのアカウント作った時に、「Twitterでログイン」ってのがあるのは(多分)この方式だと思う。
SAMLやOpenIDConnect、OAuth等、実装の方法はたくさんある。
デメリットとしては、対応していないシステムには使えないこと。
現状ではG SuiteとかSalesForceとかOffice365とか、クラウドサービスとの連携はこれ一択っぽい。
IDaaSとオンプレミスでのユーザー情報管理
OpenAMなどのSSOと、ユーザー情報の一元管理は別のソリューションなので、個別に考える必要があるとか。
どっちを選んだらいいの？というお話
IDaaSのメリットデメリット
・メリット
利用開始できるまでが早い
初期費用が安く、運用の手間がかからない
オプション機能があれば、それらもすぐに利用できる
・デメリット
構築のサポートは提供されない
→SIer使えばいいんじゃね？と思った。強いSIerがいるかは知らないけど。
既存業務やシステムをIDaaSにあわせる必要がある
機能のカスタマイズが難しい
ユーザー単位での課金が主流で、ユーザー数やオプションによってはオンプレのほうが安上がり
ユーザー情報を社外（クラウド）で管理することになるので、そもそも容認されなければ利用できない
→ 個人的には「クラウドだからセキュリティ弱い」って脳みそが時代遅れな気はしている。
小規模な環境に短期間で導入するのに有効
オンプレミス
・メリット
構築や運用支援を社外の専門家に頼める
→上述の通り、別にIDaaSだから頼めないことなくない？と思った。
カスタマイズがきくので既存環境への影響は少なめ。
一回構築すれば運用保守の費用はIDaaSより安上がりなことが多い。
ユーザー情報を社内で保管できる
→ クラウドだからry
・デメリット
構築に時間がかかる。
導入の初期費用は高い。
一定以上の規模で長期間運用するために導入するのに向いてる
講師の人的に、境目の規模感は500～1000ユーザー
OpenAMについて
SSOを実現するためのOSSの、デファクトスタンダードらしい。
以下の通り基本的な機能は網羅しており、SSOを導入するときには大体の場合検討対象になるらしい。
複数Webサイトとの認証統合機能あるよ！
SAML、OAuth、OpenIDConnect等の標準プロトコルに対応しており、クラウドやソーシャルとの連携も可能
2段階等のリスクベース認証も実装可能で、セキュリティ強化が可能
最新プロトコルにも対応していくため、将来の継続的な認証連携対象の追加も容易
Forge Rock社がCDDLライセンスで提供している。
無料なのはメジャーアップデート版のみ。マイナー版はサブスクリプション。ヤクザってるらしい。
マイナー版の売り方がエグいので、ベンダーが独自に作成したディストリビューションもある。
OpenAMの歴史
Sun MicroSystem社がオープンソースコミュニティと共同開発した「OpenSSO」が源流。
Oracle社がSunを買収したのに伴い、OpenSSOは開発中止。
その後、Forge Rock社によって「OpenAM」として継続。
こんな歴史があるので、OpenAMの初代バージョンは9から始まっている。
実現できること
リスクベース認証（多要素認証）
クロスドメイン対応（cookie）
フェデレーション（SAML/OAuth/OpenIDConnect）
マルチSSO対応（複数SSO環境の管理）
アカウントロック（認証失敗時）
同時接続数制限（セッション数管理）
アクセス制限（認可）
なお主な認証モジュール
LDAP
Active Directory
SQL
RADIUS
WindowsデスクトップSSO
NTドメイン
デバイスID
電話番号
証明書
匿名
ワンタイムパスワード
具体的な構成図については、以下のホームページとかでふんわり。
https://hondou.homedns.org/pukiwiki/pukiwiki.php?OpenAM%2520%25A5%25A4%25A5%25F3%25A5%25B9%25A5%25C8%25A1%25BC%25A5%25EB#dee34309
資料は公開NGらしいので構成図をこっちに残せない.....！
導入における注意点
・ネットワークとその周辺の広い範囲のスキルが必要
具体的には、ファーム、Web、DB、あたり。
・GUIで設定できるが、概念ごとに項目がまとまっていないので煩雑
パッと見はわかりやすそうに見えるけど、項目にまとまりがないからめんどくさいとのこと。
・セッション管理をどうするか、ちゃんとした設計が必要
IDP側がタイムアウトしたときにSP側のセッションは残す？どう設定/管理する？
※OpenAM自身のタイムアウトはOFFにできない
・IPアドレスによる運用は不可能
ホスト名がないとOpenAM自体のインスコも不可。
1サーバーでの同時処理は100～200くらい。
その他
障害対策は必須。そりゃそうだ。
冗長構成がシンプルながら超有効らしい。
冗長構成を組んで、セッション情報まで含めた同期をとっておくようにしておけばユーザーへの影響はほぼなくせるとのこと。
感想
OSSだからこその大変さあるよね。
一番の障壁は知識やスキルの守備範囲だなーと。
少なくとも、現状で社内環境を構築ってなったときに自分一人の今の状態では導入できねえ。。
IDaaS個人で使ってみようかしら。。やっぱり煩雑だしね。