今回は、SSOのSAMLにおけるIdP initiatedとSP initiatedの認証フローの違いについて解説したいと思います。
期待する目標
本記事で期待する目標は以下の通りです。
- 従来のログインとSSOの違いを理解する
- SAMLの概念をざっくり理解する
- IdPとSPの違いについて理解する
- IdP initiatedとSP initiatedの違いを理解する
従来のログインを取り巻く環境
SSOが有効になっていない環境だと、AzureであればMicrosoftアカウント、Google CloudだとGoogleアカウント、AWSだとAWSアカウント、VMwareだとVMwareアカウントがあり、それぞれのサービスを利用するには、それぞれのアカウントでログインする必要があります。
どれか一つだけ利用しているような職場であれば問題ないのですが、メールはGoogle Workspace、オフィスソフトはMicrosoft Officeなど、2アカウント以上使用している場合もあったりします。
最近ではさらにZoomで会議をしたりとリモートワーク特有のアカウントを持っていたりする場合も多いかと思います。
パスワードマネージャーなどで管理するのも一つだと思いますが、これらを1回のログインで利用するサービスをすべてログインできれば非常に便利だともいます。
Single Sign-Onとは
シングルサインオン（英語：Single Sign-On、略称：SSO）は、一度のユーザ認証処理によって、独立した複数のソフトウェアシステム上のリソースが利用可能になる機能または環境である[1]。シングルサインオンによって、ユーザはシステムごとにユーザIDとパスワードの組を入力する必要がなくなる。
また、アイデンティティ管理を連邦化（federate）することによって、ひとつの組織（管理ドメイン）を超えて他の管理ドメインのWebサーバにも同一のユーザIDとパスワードの組でログインできるようにする処理も、しばしば「シングルサインオン」と呼ばれている。ユーザ認証結果をクレデンシャル（SAMLアサーションやOpenID ConnectのIDトークン）によって伝えて実現させるが、通常、各Webサーバに同一のユーザIDとパスワードの組を入力する必要がある。
必ずしも一度（single）の処理にならない実装についても含めるために「Reduced sign-on」という用語が使われることがある[2]。
wikiより引用
前項で記載した1つのログインで様々なサービスを利用できるようにしたものが、シングルサインオンとなります。
このように、初めに決められたサイトでログインを行うと、ログインしたサービスがID情報を管理してくれるので、連携した他のサービスを利用する際にIDとパスワードの入力が無くなります。
従業員的な立場で見ると、管理するIDが1つで済むのでパスワードを使いまわしたり、複数覚えたり、乱立するパスワード有効期限とも戦わなくて済むため、従業員の生産性が向上します。
管理・運用する立場で見ると、1人が管理するIDが1つになるため、〇〇システムのパスワードを忘れたのでリセットしてほしいという依頼もかなり少なくなり、運用する工数も少なくなります。
これは、Win-Winですね。
社内システムでシングルサインオンに対応していないシステムがあれば、情シスを問い詰めましょう。
SAMLとは
前置きは置いておいて、さっそく本題に入っていきます。
シングルサインオンで使われる方式の1つとしてSAMLがあります。
Security Assertion Markup Language（セキュリティ アサーション マークアップ ランゲージ、略称SAML、読み： sam-el[1]）はOASISで標準として策定されたマークアップ言語で、主にシングルサインオンやID連携で利用されている[2]。メッセージの送受信にはHTTPやSOAPが使われる[3]。
wikiより引用
SAMLは、SSOを実現するために使われる言語のひとつになります。
初めにログインしたサービスから、SAMLを発行してもらいそのSAMLを別のサービスに提供することで、ID情報が連携され別のサービスにもログインができるようになります。
IdPとSPについて
前項では、ログインしたサービスからSAMLを発行してもらい、SAMLを別のサービスに連携すると、解説しました。
ここで登場するのが、IdPとSPになります。
IdPは、Identity Providerと呼ばれる役割を持つサービスになります。
IdPはIdentityと言われているように、ユーザの認証情報の大元を管理しているサービスになります。
例えば、Microsoft AzureにあるAzure Active Directoryなどが、IdPの役割を持つサービスです。
基本的には、IdPがSAMLの発行元となります。
一方、発行されたSAMLを受け取り、ログインされる側になる役割をSP(Service Provider)と呼ばれます。
ここで一つの疑問が生まれます。
最初にIdPのサービスを利用する場合は、IdPにログインしてSAMLを発行できるが、最初にSP側のサービスを利用する場合、SAMLが発行されないのではないか？と。
IdP initiatedとSP initiated
SAMLを使用したSSOでもIdP側からログインした場合でもSPからログインした場合でもSSOがしっかりと動作するような工夫がされています。
それが、IdP initiatedとSP initiatedです。
自然と考えられるパターンがこちらになります。
初めに、IdPであるAzure ADにログインします。Azure ADはIdPのため、この時点でSAMLが発行されます。
この場合、他のサービスにログインする場合は、Azure ADで発行されたSAMLをSPとやり取りすれば問題なくSPへログインすることができます。
この方式を[IdP Initiated]と呼びます。
一方、初めにSP側にログインした場合は、まだSAMLを発行していないため、ログインはできません。
初めに、SP側のログインページでメールアドレスを入力します。
SP側は、SAMLで使用するメールアドレスが入力された場合、IdPにリダイレクトするように設定されており、ユーザが入力したメールアドレスが入力されるとIdPであるAzure AD側のログインページに移動します。
そこで、IdPであるAzure ADにログインすると、SAMLが発行されそのSAMLをSPに連携とリダイレクトをしてログインが完了します。
この方式を[SP initiated]と呼びます。
このようにすることで、IdPからログインしてもSPからログインしても最終的にIdP側でログインが求められ、SAMLによるSSOが成立するわけです。
まとめ
今回は、シングルサインオンの概念とSAML、IdP initiatedとSP initiatedの挙動の違いを簡単に解説しました。
昔は、メールアドレスとパスワードは同一のページに入力フォームがあり、そこでサインインすることが多かったですが、SAMLによるSSOなどがあるため、最近のフォームはメールアドレスを入力してからパスワードを入力するようになっています。
これは、SAMLによるSSOの対象かどうかをメールアドレスで判断しているため、このような作りになっているんだなーと理解できました。
おまけ
本ブログではVMwareやWindows、Linuxのインストール手順等も公開しております。
インフラエンジニアとして有益な記事や無益なコンテンツも作成しておりますので、通勤時間や休憩時間、休日のスキマ時間等に合わせて読んでいただけると幸いです。
また、Youtubeで解説動画も鋭意作成中です。本ブログで記事にしているものも動画にしようと思っておりますので、よろしくお願いいたします。
willserverのnoteも開設したのでフォローお願いします。
コメント