シングルサインオンについて調べたのでメモ。


まず念のためシングルサインオンとは何か？から。

通常のログインは
「①自分が使いたいシステムAで認証して」
「②同じく自分が使いたいシステムAでログインする」
と思う。

図で表すと以下の通り。
サービスプロバイダが「自分が使いたいシステム」ということ。



ただしこれだと、使っているシステムが「システムA」「システムB」「システムC」と、
増えていくとそれらがすべて毎日使っているシステムだったら、毎日最低3回ログインする必要があることになる。

それだけならまだしも、これらのシステムが3カ月に1回、6カ月に1回など
異なるタイミングでパスワードの変更を求めるようなシステムだった場合、
パスワードの管理が非常にめんどくさいことも問題になる。

ログインポリシーもそれぞれで異なるため、その管理も面倒になる。

それらを解決するために生まれたのがシングルサインオン。

通常のログインと異なり、
「①認証用のシステムAで認証して」
「②自分が使いたいシステムBでログインする」
という方式を使っている。

図で表すとこうなる。
IDプロバイダが「認証用のシステム」。



これだけだとパッとしないかもしれないが、
サービスプロバイダの数を増やしてみるとシングルサインオンっぽくなる。



こうすれば、パスワードもログインポリシーもIDプロバイダで一元管理できるし、毎日のログインも最低1回で済む。

これがシングルサインオンでそのメリットである。


上の説明がシングルサインオンの説明。
そしてそのシングルサインオンの時に使われる認証方法の一つが、SAML認証。

SAML認証の最大の特徴は「異なるドメイン間で容易に認証用メッセージのやり取りが行えること」らしい。
これは後述する通り、サービスプロバイダとIDプロバイダが直接メッセージのやり取りをすることはなく、
クライアントを介して行っているためらしい。

そのため社内認証システムとクラウドシステムの時によく使われるらしい。


SAML認証には「SP initiatedフロー」と「IdP initiatedフロー」の二つがある。

より複雑なのは「SP initiatedフロー」の方。
というより、「SP initiatedフロー」の前の方の手順が無いのが、「IdP initiatedフロー」。

内部的な話で言うと、
「SP initiatedフロー」は「AuthnRequest」から始まるフロー、
「IdP initiatedフロー」は「SAMLResponse」から始まるフロー
ということでいいと思う。

それぞれのフローの概要は以下の通り。
（あくまで一例）

SP initiatedフロー


IdP initiatedフロー


これだけだとパッとしないと思うが、これをベースに後々の説明をしていく。



まず最初にやらないといけないこととして、何らかの方法でSAML認証を起動しないといけない。
方法はいろいろあると思うが「URLを開くと起動する」「ボタンを押すと起動する」などがある。


AuthnRequestは、IDプロバイダに認証を依頼するためのもので、ここの中に認証する際の約束事も記載されているらしい。
またAuthnRequestだけでなく、「RelayState」、「電子署名」、「ハッシュ化アルゴリズム」なども送られているらしい。
RelayStateとは、SAML認証完了後、どのページ（URL）を開くかを記載したもの。


これは普通に社内の認証システムが表示されるようなイメージ。
もちろんすでに認証（ログイン）済の場合、この手順は飛ばされる。


ここでAuthnRequestを見て、これから作るSAMLRequestの作り方をきめている。
電子署名の比較もやっている（はず）。


IDプロバイダがSAMLRequestと呼ばれるXMLメッセージを「クライアントに」返す。
厳密にいうと、それをそのまま返しているわけではなく、そのメッセージを含んだinputフォームを持ったHTMLをブラウザに返しているらしい。
この際SAMLRequestと一緒に「RelayState」も返している。


前の手順で送られてきたSAMLResponse（とRelayState）を「サービスプロバイダに」送る。

直接IDプロバイダからサービスプロバイダに送らず、クライアントを一回クッションにしているのがポイント。


SAMLResponseをサービスプロバイダが検証する。
こっちでも電子署名の確認をしているらしい。


SAMLResponseに含まれるNameIDからログインするユーザを特定してセッションを返す。
同時に「RelayState」のページにクライアントをリダイレクトさせる。


「SP initiatedフロー」の中で「2～5」の手順を省いたものが「IdP initiatedフロー」になると思う。
例えば社内ポータルサイトからリンクを開くと、サービスプロバイダの画面が開くなど。


思いつく限りでSP initiatedフローでしかできないことが2つある。
一つが、認証後に開くページを可変にすること。

例えばメールにサービスプロバイダへのリンクが2つあって、
一つはAというデータへのリンク、もう一つはBというデータへのリンクがあった場合。

Aというデータへのリンクを押したときには、最終的にAというデータが開き、
Bというデータへのリンクを押したときには、最終的にBというデータが開くようにする、ということがSP initiatedフローではできる。
（サービスプロバイダからIDプロバイダへAuthnRequestを送るときに、RelayStateの値をそれぞれで変えればいいだけ）

IDプロバイダではこのように可変にするのはかなり難しいと思う。

もう一つがサービスプロバイダが独自のアプリを使っている場合のSAML認証。
例えばIDプロバイダはIEやChromeなどの普通のWebブラウザを使うのに対して、サービスプロバイダが専用のアプリケーションだった場合。

IdP initiatedフローでは、ブラウザからSAML認証が始まるため、
セッションはブラウザに対して返されるはずなので、サービスプロバイダアプリケーション側の認証が行われない（はず）。

対してSP initiatedフローでは、サービスプロバイダのアプリケーションからSAMLを始めれば問題ない。