ちょっとSSOの話するわ

そもそもSSO（Single Sign On）ってなに？

複数のサービスへのログインを一回で完了させるための仕組み
一回の認証でセッション情報を保持して、複数サービスへのアクセスを一元管理する。

いちいちログインしなくていいからラク。
IDとパスワードを1個覚えておけばいいからラク。
ユーザー的にはラクするための仕組み。

アカウント情報を統合してしまえば、守るべき情報も減るからセキュリティ的にも強固になるという感じ。

どうせ守らなくてはいけないので、1つに集約しちゃいましょうねーという。

上述の通り、セキュリティの向上が見込める。
接続のコントロールが一元化出来て管理がラクになるらしい。
→ここはよくわかんない。管理者側で不要なセッション切ったりできるってことなんだろうか。

また、BtoB/BtoCのサービス提供者の場合、顧客の囲い込みが強化できるらしい。
わたしはピンと来ていないが、顧客の傾向とかを融通してんのかしら？

アカウントやアクセス管理を一元化して守るところを集約するということは、裏を返せば守りが突破されてしまったときに連携しているサービスも巻き添えになってしまうこと。
よって一元管理された情報はセキュアな状態を保つ必要があり、セキュリティ対策にかけるコストは増えてしまう。

ざっくり以下の4つ。

以下ざっくり説明

SSOでログインされる側のシステム（SP：Service Provider）にエージェントを入れる方式。
メリットはネットワークの構成変更がないこと。
デメリットは、エージェントを入れないといけないので対象システムの改修が必要。

また、エージェントに不要なキャッシュが残っているせいで挙動がおそくなることがある
定期的なキャッシュクリアやガベージも要考慮かも。（沢渡さんより）

少数の社内システム同士でSSO実装したいときによく使うらしい。

SSOを提供するシステム（IDP：Identity Provider）と、SPのシステムの間にプロキシサーバーを置く方式。
メリットは対象システムにエージェントは不要で、SSOでのアクセス制御を集中管理できること。
デメリットはネットワーク構成変更が必要なこと。

社内システム同士のSSOを実装したいが、エージェント方式使えないくらい大量にあるときや、SSO実装以降に対象システムを増やす予定があるときに使われるらしい。

構造的にはリバースプロキシと同じ。
リバースプロキシ方式よりも導入難易度は低い。らしい。
IDとパスワードの情報は個別管理が必要でセキュリティ的に他の方式より弱い。

仕方なく、、以外では採用することはほぼないらしい。

これが流行りらしい。
Qiitaのアカウント作った時に、「Twitterでログイン」ってのがあるのは(多分)この方式だと思う。
SAMLやOpenIDConnect、OAuth等、実装の方法はたくさんある。

デメリットとしては、対応していないシステムには使えないこと。
現状でG SuiteとかSalesForceとかOffice365とか、クラウドサービスとの連携はこれ一択。

本日（2018/02/28）SAMLの脆弱性情報がニュースになりました。
→　スピーカーに影響しそうで、口から何か出そう。

Q：ADが「このユーザは偽物じゃないよー」と判定したら、アプリケーションはその結果だけ受け取って次の画面に遷移させる？

A：結論で言うとNo。
ADFS（IdP）側で、事前にどこにリダイレクトさせるかを事前に設定しておく必要があり、クライアントをそこで設定したURLに対してリダイレクトさせる。
その際にユーザーの情報をSAMLトークンとして発行して、リダイレクト先のURLに渡してもらうように動作する。

Q：自分で始めるとしたらOpenAMがいいの？

A：あんまりおすすめしないです。
理由としてはオープンソースとしての先行きの不透明感があるため。
オープンソースとしてというのであれば、個人的にはコミュニティの活発さと要件の緩さからKeyCroakがおすすめ。