シングルサインオン/SAML認証について
概要
シングルサインオンについて調べたのでメモ。
シングルサインオンとは
まず念のためシングルサインオンとは何か？から。
通常のログインは
「①自分が使いたいシステムAで認証して」
「②同じく自分が使いたいシステムAでログインする」
と思う。
図で表すと以下の通り。
サービスプロバイダが「自分が使いたいシステム」ということ。
画像クリックで等倍
ただしこれだと、使っているシステムが「システムA」「システムB」「システムC」と、
増えていくとそれらがすべて毎日使っているシステムだったら、毎日最低3回ログインする必要があることになる。
それだけならまだしも、これらのシステムが3カ月に1回、6カ月に1回など
異なるタイミングでパスワードの変更を求めるようなシステムだった場合、
パスワードの管理が非常にめんどくさいことも問題になる。
ログインポリシーもそれぞれで異なるため、その管理も面倒になる。
それらを解決するために生まれたのがシングルサインオン。
通常のログインと異なり、
「①認証用のシステムAで認証して」
「②自分が使いたいシステムBでログインする」
という方式を使っている。
図で表すとこうなる。
IDプロバイダが「認証用のシステム」。
画像クリックで等倍
これだけだとパッとしないかもしれないが、
サービスプロバイダの数を増やしてみるとシングルサインオンっぽくなる。
画像クリックで等倍
こうすれば、パスワードもログインポリシーもIDプロバイダで一元管理できるし、毎日のログインも最低1回で済む。
これがシングルサインオンでそのメリットである。
SAML認証とは
上の説明がシングルサインオンの説明。
そしてそのシングルサインオンの時に使われる認証方法の一つが、SAML認証。
SAML認証の最大の特徴は「異なるドメイン間で容易に認証用メッセージのやり取りが行えること」らしい。
これは後述する通り、サービスプロバイダとIDプロバイダが直接メッセージのやり取りをすることはなく、
クライアントを介して行っているためらしい。
そのため社内認証システムとクラウドシステムの時によく使われるらしい。
SP initiatedフローとIdP initiatedフロー
SAML認証には「SP initiatedフロー」と「IdP initiatedフロー」の二つがある。
より複雑なのは「SP initiatedフロー」の方。
というより、「SP initiatedフロー」の前の方の手順が無いのが、「IdP initiatedフロー」。
内部的な話で言うと、
「SP initiatedフロー」は「AuthnRequest」から始まるフロー、
「IdP initiatedフロー」は「SAMLResponse」から始まるフロー
ということでいいと思う。
それぞれのフローの概要は以下の通り。
（あくまで一例）
SP initiatedフロー
画像クリックで等倍
IdP initiatedフロー
画像クリックで等倍
これだけだとパッとしないと思うが、これをベースに後々の説明をしていく。
SP initiatedフロー
1.SP initiatedフローを呼ぶ
まず最初にやらないといけないこととして、何らかの方法でSAML認証を起動しないといけない。
方法はいろいろあると思うが「URLを開くと起動する」「ボタンを押すと起動する」などがある。
2.AuthnRequestをIDプロバイダに送る
AuthnRequestは、IDプロバイダに認証を依頼するためのもので、ここの中に認証する際の約束事も記載されているらしい。
またAuthnRequestだけでなく、「RelayState」、「電子署名」、「ハッシュ化アルゴリズム」なども送られているらしい。
RelayStateとは、SAML認証完了後、どのページ（URL）を開くかを記載したもの。
3、4.IDプロバイダが認証画面をユーザに表示し、ユーザが認証する
これは普通に社内の認証システムが表示されるようなイメージ。
もちろんすでに認証（ログイン）済の場合、この手順は飛ばされる。
5.AuthnRequestを検証する
ここでAuthnRequestを見て、これから作るSAMLRequestの作り方をきめている。
電子署名の比較もやっている（はず）。
6.SAMLResponseをクライアントに返す
IDプロバイダがSAMLRequestと呼ばれるXMLメッセージを「クライアントに」返す。
厳密にいうと、それをそのまま返しているわけではなく、そのメッセージを含んだinputフォームを持ったHTMLをブラウザに返しているらしい。
この際SAMLRequestと一緒に「RelayState」も返している。
7.SAMLResponseをサービスプロバイダに送る
前の手順で送られてきたSAMLResponse（とRelayState）を「サービスプロバイダに」送る。
直接IDプロバイダからサービスプロバイダに送らず、クライアントを一回クッションにしているのがポイント。
8.SAMLResponseをサービスプロバイダが検証する
SAMLResponseをサービスプロバイダが検証する。
こっちでも電子署名の確認をしているらしい。
9.サービスプロバイダがログインセッションを返す
SAMLResponseに含まれるNameIDからログインするユーザを特定してセッションを返す。
同時に「RelayState」のページにクライアントをリダイレクトさせる。
IdP initiatedフロー
「SP initiatedフロー」の中で「2～5」の手順を省いたものが「IdP initiatedフロー」になると思う。
例えば社内ポータルサイトからリンクを開くと、サービスプロバイダの画面が開くなど。
SP 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を始めれば問題ない。
コメントログ
コメント投稿
