今回はSAML認証について、初心者にも分かりやすく解説していきます。 SAML認証は、Webサービス間での認証情報のやり取りを効率化する仕組みです。
SAMLって何?
SAML (Security Assertion Markup Language) は、XMLベースのデータフォーマットで、異なるシステム間でセキュアな認証情報を交換するためのプロトコルです。
主にシングルサインオン(SSO)を実現するために使われます。
簡単に言うと、
SAML認証は、他のサービス(たとえばGoogleやFacebook)を使って、別のサイト(たとえばSalesforce)にログインする仕組み。
たとえば、Googleが「この人は正しくログインしているよ」とSalesforceに教えてくれる感じ。
例えば、複数のWebサービスを利用する場合、各サービスに毎回ログインするのは面倒ですよね。
SAML認証を使えば、一度のログインで複数のサービスを利用できるようになります。
SAML認証の登場人物
SAML認証を理解するには、3つの重要な役割を知る必要があります。
- ユーザー(User): サービスを利用する人。
- サービスプロバイダー(SP, Service Provider): ユーザーがアクセスするWebサービス。
- アイデンティティプロバイダー(IdP, Identity Provider): ユーザー認証を行うサービス。例えば、OktaやGoogle、Azure ADが代表的なIdPです。
これらが連携して、ユーザーがSPにアクセスする際にIdPで認証を行い、その結果をSPに伝える形になります。
SAML認証の流れ
次に、具体的な認証フローを見ていきましょう。
① ユーザーがSPにアクセス
ユーザーが最初にアクセスするのはSPです。
ここで、SPはユーザーが認証済みかどうかを確認します。
② SPがSAMLリクエストを生成
未認証の場合、SPはSAMLリクエストと呼ばれる情報をIdPに送ります。
③ ユーザーをIdPにリダイレクト
SPはユーザーをIdPのログインページにリダイレクトします。
④ ユーザーがIdPで認証
ユーザーはIdPのログインページでIDやパスワードを入力して認証します。
⑤ IdPが認証結果をSPに送信
認証が成功すると、IdPはSAMLレスポンスという認証情報をSPに送ります。
このレスポンスには、デジタル署名が付与されており、改ざんされていないことが証明されます。
⑥ SPが認証情報を検証
SPは受け取ったSAMLレスポンスを検証し、ユーザーを認証済みとしてサービスにアクセスさせます。
証明書と秘密鍵の役割
SAML認証で重要なのが、証明書と秘密鍵です。
- 証明書(公開鍵): SAMLレスポンスに付与された署名をSPが検証するために使用します。
- 秘密鍵: IdPがSAMLレスポンスに署名するために使用します。
例えば、OktaのSAML認証でSalesforceにアクセスする場合を考えます。
まず、Oktaはあらかじめ証明書(公開鍵)をSalesforceに教えておきます(設定で登録しておく)。
ユーザーがIdPで認証を終えると、IdPで、秘密鍵を使用した署名が施されたSAMLレスポンスが生成され、Salesforceに送信されます。
Salesforceで、受信したSAMLレスポンスの署名が本当に有効なものかを証明書を使用して検証します。
この仕組みで、SPはレスポンスが本当にIdPから送られてきたものかを確認できます。
SAMLのメリットとデメリット
メリット
- ユーザーの利便性向上: 一度のログインで複数のサービスを利用可能。
- セキュリティの向上: パスワードを各SPで管理する必要がない。
- 管理の簡素化: IdPで一元管理。
デメリット
- 初期設定が複雑: 証明書や設定ファイルの準備が必要。
- 依存関係の発生: IdPがダウンすると全サービスに影響。
SAMLリクエストとレスポンスの詳細
SAMLリクエストやレスポンスはXML形式で記述されています。
SAMLリクエストの例
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_123456"
Version="2.0"
IssueInstant="2024-12-27T12:34:56Z"
Destination="https://idp.example.com/sso">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.example.com</saml:Issuer>
</samlp:AuthnRequest>
samlp:AuthnRequest
: 認証リクエストを表します。この要素の属性には以下が含まれます。ID
: リクエストの一意な識別子。Version
: SAMLのバージョン(通常2.0)。IssueInstant
: リクエストが作成された日時。Destination
: リクエストを送るIdPのエンドポイントURL。saml:Issuer
: リクエストを発行したSPの識別子(通常はURL)。
SAMLレスポンスの例
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_abcdef"
InResponseTo="_123456"
Version="2.0"
IssueInstant="2024-12-27T12:34:56Z"
Destination="https://sp.example.com">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.example.com</saml:Issuer>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Subject>
<saml:NameID>user@example.com</saml:NameID>
</saml:Subject>
</saml:Assertion>
</samlp:Response>
samlp:Response
: IdPからSPに送られるレスポンス。ID
: レスポンスの一意な識別子。InResponseTo
: 対応するSAMLリクエストのID。IssueInstant
: レスポンスが作成された日時。Destination
: レスポンスを受け取るSPのURL。saml:Issuer
: レスポンスを発行したIdPの識別子(通常はURL)。saml:Assertion
: 認証に関する詳細情報が含まれます。saml:Subject
: 認証されたユーザーを表します。saml:NameID
: ユーザーの識別子(例:メールアドレス)。
まとめ
SAML認証は、複数のWebサービス間で安全かつ効率的に認証情報をやり取りするための仕組みです。
一見複雑に見えますが、基本的な流れや仕組みを理解すれば難しくありませんね。
今回は以上です。
コメント