SAML認証ってなんやねん
自己紹介
どもども、フリーランスエンジニアとして働いている井上弥風です
「SAML認証ってなんやねん」と思ったのでそのまま記事にしました
初めに
記事の内容
当記事ではSAMLとは何か、その上でSAML認証とは何か、SSOとどのような関連性があるのかを見ていきます
記事のゴール
記事のゴールは下記の内容を理解することです
- SAMLとは何か
- SAML認証とは何か
- SSOとは何か
- SAML認証とSSOがどう絡むのか
- AzureADとSAML認証の関係性
ではではスタート
SAMLとは？
SAMLは、Security Assertion Markup Languageの略称で、異なるシステム間でユーザーの認証や認可を安全に実現するためのXMLベースの標準規格です
後述しますが、SAMLはアイデンティティプロバイダ(IdP)とサービスプロバイダ(SP)間の認証情報の連携で利用され、SAMLを利用することで認証情報を安全に扱うことができ、セキュア(デジタル署名・暗号化)なSSO認証を行うことが可能になります
SSO・OAuthとは？
SSOとは？
ここではSSOに関する情報を紹介します
SSOとは？
SSOは、一度の認証で複数の異なるシステムやアプリケーションに安全にアクセスできる仕組みです
この仕組みを利用することで、ユーザーは異なるサービスに対する複数の認証情報を覚えておく必要がなくなり、利便性が向上する他、認証情報の管理がシンプルかつ安全になります
SSOを利用しない場合の問題点
SSOがない場合、ユーザーは各サービスごとにログイン情報(ユーザー名、パスワード、メールアドレスなど...)を覚えておく必要があります
これは管理が煩雑になるだけでなく、適切に管理していない場合、機密情報の漏洩や不正アクセスといったセキュリティリスクに直面する可能性があります
SSOを利用しない場合の問題点の具体例
- 単一サービスを利用している場合
- 例として「Zenn」というサービスのみを利用する場合、Zennのログイン情報だけを覚えておけば良いため、管理が煩雑になることはありません
- Zennのログイン情報が仮に漏洩した場合、被害はZennだけにとどまります(だからと言って問題ないわけではないですが..)
- 複数サービスを利用している場合
- LINE、Twitter、Instagramなど複数のサービスを利用する場合、各サービスのログイン情報を個別に覚えておく必要があり、管理は複雑になります
- さらに、すべてのログイン情報を一か所(例：メモ帳)で管理している場合、そのメモ帳を失くした時の被害は甚大です
SSOを利用するメリット
多くの人が複数のサービスに同一または類似のパスワードを使用している現状では、SSOは一つの強力なパスワードによる管理を実現し、パスワードの再利用や弱いパスワード使用に伴うリスクを減らすことができます
よく、Googleと全く関係のないサービスに新規登録をしようとする際に、「Googleアカウントでログインする」といった表示を見たことは無いでしょうか？
あれがSSOの仕組みそのものであり、「一つの認証情報(Googleアカウント)だけで複数のサービスにログインすることができる仕組み」なのです
(実際に利用できる認証情報はGoogleアカウント以外にもFacebookやTwitter、Linkedlnなど複数存在します)
整理すると、SSOを使用することでユーザーは一つの強力なパスワードを管理するだけで済むため、パスワードの再利用や弱いパスワードの使用リスクを減らすことができます
OAuthとは？
OAuthはオープンスタンダードな認証プロトコルで、アプリケーションAがユーザーの代わりに安全にアプリケーションBのリソースにアクセスするための許可を得る仕組みです
例として、あなたが写真共有アプリ(アプリケーションA)にログインしているときに、そのアプリがあなたのFacebook(アプリケーションB)に写真を投稿する許可を求めるケースを想像してみましょう
本来、写真共有アプリはFacebookのログイン情報を知らないと写真を投稿することができませんが、Facebookのログイン情報をやたらと他のサービスに共有するのはセキュリティ上あまり良くありません
こういった状況下でOAuthが利用されます
具体的な処理フローは割愛しますが、大枠の流れとしては下記のような順序で処理が進みます
- 写真共有アプリがユーザーにFacebookへのアクセス許可を要求する
- ユーザーがアクセスを許可すると、写真共有アプリはFacebookから特定のアクション(この場合は写真の投稿)を実行するためのトークン(改札に入るための切符的な感じですね)を受け取る
- 写真共有アプリは、受け取ったトークンを使用してユーザーのFacebookアカウントに写真を投稿する
これにより、写真共有アプリはユーザーのFacebookアカウントのログイン情報を知ることなく、許可されたアクション(写真の投稿)のみを実行することが可能になります
SSOとOAuthの違い
SSOは主に、ユーザーが複数のシステムやアプリケーションに対して一度のログインでアクセスできるようにすることを目的としています
OAuthは、アプリケーションがユーザーの資源やデータにアクセスするための許可を安全に得ることを目的としています
簡単に言えば、SSOはユーザーが複数のサービスに対して一度の認証でアクセスするためのものであり、OAuthはユーザーの利用しているアプリケーションへのアクセスを第三者アプリケーションに安全に許可するためのものと言えます
認証・認可とは？
認証
認証と認可の説明は下記サイトから抜粋しています
(私の記事です)
認証(Authenticaation)
認証とは簡単に言うと「ログインしてきた"あなた"が本当に"あなた"なのか」を確認するプロセスです
現実世界に例えると、区役所や市役所で何かの手続きを行う際、「身分証明書の提示をお願いします」と言われることがありますが、あれは本人確認のプロセスそのものであり、「"あなた"が本当に"あなた"であるか」を確認しているとも言えます
もう少し具体的に見ていくと、何かのサイトやサービスにログインする際に、下記の入力を求められることがありますよね
ユーザー名とパスワードを入力してください~~
メールアドレスとパスワードを入力してください~~
ユーザー名・生年月日・パスワードを入力してください~~
上記が意味しているのは、あなたが新規会員登録時に登録した情報と、ログイン時に入力する情報が一致するか、つまり本当に"あなた"なのかという確認を行っており、その確認作業が「認証」です
※指紋認証なんかもロックを解除している人が「本当に"あなた"なのか」を指紋を用いてチェックしていると言えますね！^^
認可
認可とは、システムが「ログインしてきた"あなた"が特定の機能を使用できるかどうか」を確認するプロセスです
このプロセスにより、ユーザーが特定の操作に対して実行権限を持っているかをシステムがチェックします
例として、YouTubeの課金システムを考えてみましょう
YouTubeでは、課金をすることで動画を視聴する際に表示される広告を非表示にでできます
この場合、あなたが課金しているかどうかが、ある種の認可の基準となります
つまり、「課金したユーザーは広告なしで動画を視聴できる」というルールが、ユーザーが特定の機能(この場合は「広告なしでの視聴」)を使用できるかどうかを決定する認可の一例です
ここで、「"あなた"はYouTubeの広告を見ずに動画を視聴できるか」という確認が、そのまま認可のプロセスです
認証と認可の違い
- 認証
- 「あんたは本当にあんたなんかい！？」
- 認可
- 「あんたはこの機能使える権利を持ってるんかい！？」
認証は本人確認おばちゃん
認可は権利権利うるさいおばちゃんですね
SAML認証とは？
SAML認証は、前途したSAMLを使用して、異なるサービス間でユーザーの認証と認可情報を交換するプロセスです
詳細は後述しますが、SAML認証ではアイデンティティプロバイダ(IdP)がユーザーの身元を確認し、その認証結果をサービスプロバイダ(SP)に対して安全に返却します
SAML認証は主にSSOと一緒に利用されることが多く、そのプロセスは大きく分けて下記の3つから構成されます
- 認証要求
- 認証応答
- アサーションの交換
詳しくは後で紹介しますが、SAML認証はデジタル署名と暗号化を使用するため、認証情報の完全性と機密性を保持することが可能になります
SAML認証を適切に利用することで、不正アクセスやデータ漏洩のリスクを軽減し、企業や組織のセキュリティを強化します
SAML認証・SSOで登場する用語
IdP(アイデンティティプロバイダ)
アイデンティティプロバイダ(IdP)は、ユーザーの認証を行い、そのアイデンティティ情報を管理するシステムです
SSO環境において、ユーザーがサービスにアクセスする際、IdPはユーザーの認証情報を確認し、認証が成功するとサービスプロバイダ(SP)に対してユーザーが認証されたことを示す情報を提供します
例として、Googleとは全く関係のないサービスにGoogleアカウントでログインしようとする場合、GoogleがIdPとして機能します
つまり、上記の例ではGoogleがユーザーの認証情報を管理し、認証のプロセスを行うということですね
SP(サービスプロバイダ)
サービスプロバイダ(SP)は、ユーザーにサービスやアプリケーションを提供するシステムです
SSOの文脈では、SPはIdPからユーザーの認証情報を受け取り、その情報に基づいてユーザーにサービスのアクセスを許可します
SPは、ユーザーが安全にサービスを利用できるように、IdPからの情報を検証し、管理します
例として、「美味しいビールが販売されているお店を見つけることのできるアプリ」があるとします
このアプリを利用するにはまずアカウントの登録を行う必要があるのですが、なんと嬉しいことにこのアプリではGoogleアカウントを利用してログインをすることが出来るようです
この場合、「IdPとして機能するのがGoogle」であり、「SPが美味しいビールが販売されているお店を見つけることのできるアプリ」になります
簡単にIdPとSPの連携フローを記載すると
- ユーザーが美味しいビールが販売されているお店を見つけることのできるアプリにアクセスする
- ログイン方法としてGoogleアカウントによるログインを選択
- SPがGoogleにリダイレクトし、Google(Idp)がユーザーの認証を行う
- IdPが認証結果をSPへ返却する
- SPはIdPから返却された認証結果を基にアプリにアクセスさせるか否かを判定する
といった流れになります
Assertions(アサーション)
アサーションは、ユーザーの認証情報や属性情報などを含む、SAMLメッセージの一部です
アサーションには、ユーザーが誰であるか(認証情報)、ユーザーが何をする権限を持っているか(承認情報)、その他ユーザーに関する属性情報が含まれることがあります
IdPは、ユーザーが認証されると、これらの情報をアサーションとしてSPに送信します
つまりアサーションはSPがIdPに送るものではなく、IdPがSPに返却する「認証の結果・データ」です
先の例で記載した下記のフローで言うと
- ユーザーが「美味しいビールが販売されているお店を見つけることのできるアプリ」にアクセスする
- ログイン方法としてGoogleアカウントによるログインを選択
- SPがGoogleにリダイレクトし、Google(IdP)がユーザーの認証を行う
- IdPが認証結果をSPへ返却する
この4でIdPが返却する認証結果がアサーションです
「認証結果の情報 = アサーション」ですね
SPはアサーションを基にユーザーをサービスへアクセスさせるか否かを判断します
Protocols(プロトコル)
プロトコルは、IdPとSP間で情報を安全に交換するための規則や手順を定義したものです
SAMLプロトコルは、アサーションの交換、認証リクエスト、認証レスポンスなど、SAML認証プロセスにおける様々なメッセージの形式と通信の流れを規定します
Bindings(バインディング)
バインディングは、SAMLプロトコルメッセージを特定の通信プロトコル(例えば、HTTP、SOAPなど)にどのように適用するかを定義します
つまり、BindingsはSAMLメッセージをどのようにHTTPやSOAPなどのプロトコルで送受信するかを定義するルールです
例えば、HTTPリダイレクトバインディングは、ブラウザを介してSAMLリクエストやレスポンスをリダイレクトする際に用いられます
バインディングはSAMLメッセージが実際の通信プロトコル上でどのように扱われるかの「橋渡し」の役割を果たします
SAML認証がHTTPSを使用する場合でも、バインディングはそのメッセージの形式や送信方法を規定するために必要です
Profiles(プロファイル)
プロファイルは、特定の使用ケースやシナリオにおいて、SAMLアサーション、プロトコル、バインディングをどのように組み合わせて使用するかを定義したものです
プロファイルによって、SAMLの実装が様々なアプリケーションやサービスの要求に柔軟に対応できるようになります
SAML認証の仕組み
SAML認証は主に「アイデンティティプロバイダ(IdP)」と「サービスプロバイダ(SP)」の二つが連携して処理を進めます
- ユーザーがSP(例としてZenn)へアクセス
- SPからIdPへのリダイレクト
- 例としてユーザーがログインボタンをクリックした時、セッションが存在しない場合などにリダイレクトを行う(システム次第)
- IdPで認証を行う
- IdPはユーザーの認証情報を検証し、その結果をアサーション(ユーザーID、属性情報、認証の成否など)としてSPへ返却する
- SPによるアサーションの処理
- SPはアサーションを受け取り、検証を行う
- 検証が成功すると、ユーザーはSPのサービスにアクセスできるようになる
- 検証が失敗すると、SPはユーザーに認証のやり直しや他のアカウントでのログインを促す
SAML認証の種類
SAML認証には大きく分けて下記の二種類が存在します
- IdP Initiated(アイデンティティプロバイダが処理を開始する)
- SP Initiated(サービスプロバイダプロバイダが処理を開始する)
それぞれの特徴を説明していきます
IdP Initiated(アイデンティティプロバイダが処理を開始する)
この方式では、認証プロセスがアイデンティティプロバイダ(IdP)から開始されます
ユーザーは最初にIdPにログインし、その後、IdPのユーザーポータルやダッシュボードからアクセスしたいサービスプロバイダ(SP)を選択します
IdPはユーザーが選択したSPに対してSAMLアサーションを送信し、ユーザーはSPのサービスに直接アクセスできるようになります
-
特徴
- ユーザーは最初にIdPにログインするため、セキュリティが高い
- ユーザーがSPを選択するまで、どのSPにアクセスするかは未定である
- IdPがユーザーに提供するサービスへのアクセスを一元管理している
-
利用例
- 組織内で多数のサービスやアプリケーションに対してシングルサインオン(SSO)を提供する場合によく使用される
- 企業ポータルやダッシュボード
- 多くの大企業や教育機関では、従業員や学生が日常的に利用する様々なサービスへのアクセスを提供するための中央管理されたポータルやダッシュボードを提供している
- このポータルはIdPとして機能し、従業員や学生はここにログインしてから、メール、ドキュメント管理システム、学内情報システムなど、さまざまなSPのリソースに一回のログインでアクセスできる
- この場合、ユーザーはポータル上で利用したいサービスを選択するだけで、追加の認証手続きなしにサービスを利用することができる
- 多くの大企業や教育機関では、従業員や学生が日常的に利用する様々なサービスへのアクセスを提供するための中央管理されたポータルやダッシュボードを提供している
- クラウドベースのアプリケーションへのアクセス
- クラウドサービスを提供するベンダーが企業に対して、その企業の従業員がクラウドサービスにアクセスするための統合された方法を提供する場合にもIdP Initiated SAML認証が利用される
- 例えば、企業がクラウドストレージサービス、CRMシステム、プロジェクト管理ツールなど、複数のクラウドベースのアプリケーションを利用している場合、企業のIdPからこれらのアプリケーションへのアクセスを一元管理することができる
-
整理すると
- IdP Initiated SAML認証は、特にユーザーが一元的な場所から複数のサービスやアプリケーションへのアクセスを必要とする場合、または組織がユーザーのアクセスを厳格に管理したい場合に適している
SP Initiated(サービスプロバイダプロバイダが処理を開始する)
この方式では、認証プロセスがサービスプロバイダ(SP)から開始されます
ユーザーは最初にアクセスしたいSPのウェブサイトに行き、ログインを試みます
SPはユーザーをIdPのログインページにリダイレクトし、ユーザーはそこで認証を行います
認証後、IdPはSAMLアサーションをSPに送信し、ユーザーはサービスへのアクセスを許可されます
どちらかと言うとSP Initiated SAML認証の方が一般的かもですね
-
特徴
- ユーザー体験が直感的で、最初にアクセスしたいサービスからログインプロセスが始まる
- ユーザーは、特定のSPへのアクセスを意図しているため、プロセスが目的に即している
- SPからのアクセス要求があった際にのみIdPへリダイレクトされる
-
利用例
- 企業のクラウドアプリケーションへのアクセス
- 従業員が企業が提供するクラウドベースのHRシステムやプロジェクト管理ツールにアクセスしようとする場合、従業員はまずそのサービス(SP)のログインページにアクセスする
- サービスはユーザーを企業のアイデンティティプロバイダ(例えば、Microsoft Azure AD)にリダイレクトし、そこで認証が行われた後、ユーザーはサービスに戻されてアクセスが許可される
- オンライン学習プラットフォーム
- 大学生がオンラインで提供される学習マネジメントシステム(LMS)にアクセスする際、学生はLMSのログインページにアクセスし、ログインを行う
- システムは学生を大学のIdPにリダイレクトし、そこで正しい認証情報を入力することにより、LMSへのアクセスが許可される
- このプロセスにより、学生は大学が提供するさまざまなオンラインリソースにシームレスにアクセスできる
- オンラインショッピング
- 顧客がオンラインショッピングサイトにアクセスし、チェックアウトの際にログインを求められる場合、サイトは顧客を支払いサービスプロバイダ(例えば、PayPalなど)の認証ページにリダイレクトする
- 顧客が認証情報を提供すると、認証情報はサイトに戻され、購入プロセスを続行できる
- 企業のクラウドアプリケーションへのアクセス
-
整理すると
- SP Initiated SAML認証は、ユーザーが特定のサービスやリソースへのアクセスを求めたときに始まる認証フローです
- この方式は、ユーザーが直接アクセスしたいサービスから認証プロセスを開始するため、直感的でユーザーフレンドリーなアプローチを提供します
- ユーザーは特定のサービスプロバイダのログインページから認証プロセスを始め、必要に応じてアイデンティティプロバイダにリダイレクトされます
- 認証が成功すると、ユーザーはサービスに安全にアクセスでき、必要な作業やトランザクションを行うことができます
- このプロセスは、現代の多くのオンラインサービスやアプリケーションで広く採用されており、セキュアなユーザー認証とスムーズなアクセス体験を提供します
AzureADとSAML認証の連携
そもそもAzureADとは？
Azure Active Directory(Azure AD)は、Microsoftが提供するクラウドベースのアイデンティティおよびアクセス管理サービスです
組織のユーザー認証(サインイン)やアクセス権限の管理(承認)を行うためのサービスで、Office 365、Azure、SaaSアプリケーションなど、様々なクラウドサービスへのアクセス管理を一元化します
Azure ADは、従業員が社内外の様々なアプリケーションとサービスに安全にアクセスできるようにすることで、企業のIT管理を効率化し、セキュリティを強化します
AzureADとSAML認証の関係性
Azure ADとSAML認証の関係性は、Azure ADがSAMLプロトコルをサポートするアイデンティティプロバイダ(IdP)として機能できる点にあります
Azure ADを使用すると、企業はSAML認証を利用して従業員が複数のウェブアプリケーションに対してシングルサインオンを行えるように設定できます
具体的には、Azure ADがSAMLアサーションを生成し、ユーザーがアクセスしようとしているサービスプロバイダ(SP)に対してユーザーの認証情報を安全に伝えます
これにより、従業員は一度のログインでAzure ADを通じて認証され、連携する全てのアプリケーションやサービスへアクセスできるようになります
- 具体的な利点としては
- SAMLを使用することで、ユーザーの認証情報が直接サービスプロバイダに渡されることがないため、セキュリティリスクを低減できます
- 管理者はAzure ADを中心にユーザーのアクセス権を管理でき、どのユーザーがどのアプリケーションにアクセスできるかを一元的に制御できます
- ユーザーは複数のアプリケーションへのログイン情報を覚える必要がなく、シングルサインオンを通じてスムーズに必要なサービスにアクセスできます
Azure ADとSAML認証の組み合わせは、企業がクラウドサービスを利用する際のセキュリティと利便性のバランスを最適化する強力な手段を提供します
AzureAdとSAML認証の具体的な処理フロー(SP Initiated)
ステップ1: サービスプロバイダ(SP)へのアクセス要求
ユーザーがブラウザを通じてサービスプロバイダ(例えば、クラウドベースのアプリケーション)にアクセスを試みます
ステップ2: 認証要求のリダイレクト
SPはユーザーがまだ認証されていないことを検出し、ユーザーのブラウザをAzure AD(アイデンティティプロバイダ、IdP)のログインページにリダイレクトします
この際、SAML認証要求がIdPに送信されます
ステップ3: Azure ADでのユーザー認証
ユーザーはAzure ADのログインページで自分の認証情報(例：ユーザー名とパスワード)を入力します
多要素認証(MFA)が要求される場合、ユーザーは追加の認証ステップを完了します
ステップ4: SAMLアサーションの生成と送信
Azure ADはユーザーを認証し、ユーザーの認証情報やアクセス権限を含むSAMLアサーションを生成します
生成されたSAMLアサーションは、ユーザーのブラウザを通じてSPに送信されます
ステップ5: SAMLアサーションの受信と検証
SPは受信したSAMLアサーションを検証します
この検証プロセスには、アサーションの署名が有効であること、発行者が信頼できるIdPであること、アサーションが期限切れでないことなどが含まれます
ステップ6: サービスへのアクセス許可
アサーションが正しく検証された後、SPはユーザーに対してサービスへのアクセスを許可します
ユーザーはSPが提供するサービスやリソースを利用できるようになります
整理すると
この処理フローにより、ユーザーは安全にシングルサインオンを通じて複数のクラウドサービスやアプリケーションにアクセスできるようになります
Azure ADとSAML認証を利用することで、企業はセキュリティを維持しながらユーザーエクスペリエンスを向上させることができます
そもそもなぜSAML認証だと安全なのか？
SAML(Security Assertion Markup Language)認証が安全な理由は、主にその設計と使用するセキュリティ技術に基づいています
ここでは、SAML認証の安全性を担保する主要な要素を、初歩的な部分も含めて説明します
データの署名と暗号化
- デジタル署名
- SAMLレスポンス(アサーション)はデジタル署名で保護されます
- デジタル署名により、アサーションが改ざんされていないことを受信側(サービスプロバイダ、SP)が検証できます
- この署名は、アイデンティティプロバイダ(IdP)の秘密鍵を使用して作成され、受信側は対応する公開鍵を使用して署名の検証を行います
- 暗号化
- 機密情報(例えば、ユーザーの属性情報)を含むアサーションは、送信前に暗号化されることがあります
- これにより、アサーションの内容が転送中に第三者によって読み取られるリスクが低減されます
- 暗号化されたデータは、適切な鍵を持つ受信者のみが復号化して読むことができます
相互認証
SAML認証では、IdPとSPの間で相互に認証が行われます
これは、双方が信頼できるエンティティであることを確認するプロセスです
IdPはSPに対して認証されたユーザーの情報を提供しますが、この情報は信頼できるIdPからのみ受け入れられます
同様に、SPは信頼できるIdPからのアサーションのみを処理します
シングルサインオン(SSO)
SAML認証はシングルサインオン(SSO)をサポートします
SSOにより、ユーザーは一度のログイン操作で複数の関連サービスにアクセスできます
これにより、ユーザーが多数の異なるパスワードを覚える必要がなくなり、パスワードの再利用や弱いパスワードの使用が減少します
結果として、全体的なセキュリティが向上します
信頼できる通信チャネル
SAML認証プロセスは、HTTPS(HTTP over SSL/TLS)を使用してセキュアな通信チャネル上で行われます
これにより、データの機密性と完全性が保護され、中間者攻撃(Man-in-the-Middle Attack)のリスクが低減されます
整理すると
SAML認証の安全性は、データの署名と暗号化、相互認証、SSOの利用、信頼できる通信チャネルの確立など、複数のセキュリティ対策に基づいています
これらの技術とプロトコルは、SAML認証が情報を安全に交換し、信頼できる認証情報を提供するための強固な基盤を提供します
参考サイト一覧
Discussion