日本語
  • SAML
  • SSO
  • アイデンティティプロバイダー

開発者のための SAML 認証連携を簡単にする

SAML とは何か、SSO の実装方法、および IdP(アイデンティティプロバイダー)または SP(サービスプロバイダー)として SAML 認証を統合するための迅速な手順を学ぼう。

Ran
Ran
Product & Design

ユーザー認証に何週間も費やすのはもうやめましょう
Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。
始めましょう
Product screenshot

シングルサインオン (SSO)は最新のアプリに不可欠であり、SAML はビジネスのアイデンティティシステム間で安全かつユーザーフレンドリーな認証を実現します。このガイドでは、開発者とデザイナー向けに SAML をわかりやすい手順と実践的な例で簡単に解説し、効率的な導入をサポートします。

SAML 認証と SAML アプリとは?

セキュリティ・アサーション・マークアップ言語 (SAML) は、2 つの主役、アイデンティティプロバイダー (IdP)サービスプロバイダー (SP) 間で認証・認可データをやり取りするための XML ベースの標準規格です。組織で SSO を実現する一般的なソリューションであり、エンタープライズユーザーが 1 回のサインインで複数のアプリへアクセスでき、利便性が向上します。

アイデンティティプロバイダー (IdP) は、ユーザー名やパスワードなどのユーザー認証情報を管理・検証する役割を持ちます。ユーザーが保護されたサービスへアクセスを試みると、IdP が本人確認を行い、その確認情報をサービスに送信します。

  • 例: あなたが Microsoft Azure AD で従業員アカウントを管理している大企業に勤めていると想像してみてください。Salesforce にログインしたい場合、Azure AD が IdP として動作します。Azure AD があなたの認証情報を確認し、Salesforce にアクセス権があることを伝えます。

サービスプロバイダー (SP) はユーザーが実際にアクセスしようとするアプリやサービスです。SP は認証という重要な処理を IdP に任せています。

  • 例: 上記シナリオの続きで、Salesforce が SP です。Salesforce は Microsoft Azure AD(IdP)から本人確認の保証を受けてから、あなたのアクセスを許可します。

SAML アプリ」という場合、ほとんどは SP(サービスプロバイダー)を指します。

SAML プロトコルを使うことで、Azure AD や Google Workspace などとのアプリ連携をサポートする IdP に自サービスを設定したり、Salesforce や Slack のようにユーザー向けの SSO を提供する SP に設定したりできます。

SAML アサーションは SAML プロトコルの中核となるもので、IdP が作成し SP に送信する「このユーザーは認証済み」というデジタルメッセージです。次に IdP と SP それぞれの処理の流れを紹介します。

SAML アイデンティティプロバイダーとして動作する場合

自サービスを IdP として機能させることで、複数のアプリケーションを横断した SAML 認証が可能になります。ユーザーはひとつのエンタープライズIDでさまざまなサービスにアクセスできます。

as_saml_identity_provider_idp.png

IdP での典型的な SAML SSO フローは以下の通りです:

  1. ユーザーが Salesforce などのアプリケーション(SP)へのアクセスを試みる。
  2. アプリケーションがユーザーを自 IdP の認証ページにリダイレクトする。
  3. ユーザーが IdP のサインイン画面で認証情報を入力。
  4. IdP が認証情報をチェック。
  5. 認証情報が正しければ、IdP は SAML アサーションを SP に返す。
  6. SP はアサーションを検証し、有効であればユーザーのアクセスを許可する。

SAML サービスプロバイダーとして動作する場合

自サービスが SP の場合、さまざまなアイデンティティプロバイダーとの連携によってユーザーに SSO 機能を提供します。これにより、複数の組織やテナントのエンタープライズユーザーが安全かつ効率的にあなたのアプリにアクセスできます。

as_saml_service_provider_sp.png

SP 起点の SSO のフローは次の通りです:

  1. ユーザーがアプリケーションへのサインインを試みる。
  2. アプリケーションが SAML リクエストを生成し、ユーザーを IdP のサインインページにリダイレクトする。
  3. ユーザーが IdP でサインインする(または既にサインイン済みの場合はこの手順をスキップ)。
  4. IdP はユーザーの本人確認を行い、確認できたらユーザー情報を SAML アサーションに格納する。
  5. IdP がアサーションをアプリケーションに返す。
  6. サービスがアサーションを検証し、有効であればユーザーにアクセスを許可する。

SAML SSO での主なパラメーター

SAML SSO の連携に必要なパラメーターは IdP/SP 双方が共有する必要があります。主な項目を見ていきましょう:

IdP から提供されるパラメーター

  1. IdP エンティティ ID: SAML 通信内で IdP を一意に識別する ID(デジタルの名札のようなもの)。
  2. SSO URL: SP が認証のためユーザーをリダイレクトするログインエンドポイントの URL。
  3. X.509 証明書: SAML アサーション署名用の公開鍵。これはアサーションの信頼性やセキュリティを保証する「印鑑」です。

ヒント:IdP が SAML メタデータ URL を提供している場合はさらに簡単です。この URL ひとつで証明書や SSO URL、IdP エンティティ ID など必要情報がすべて揃います。手動コピペミスを防ぎ、証明書ファイル更新の手間もなくなります。

SP から提供されるパラメーター

  1. SP エンティティ ID: SP の一意識別子。IdP エンティティ ID に相当。
  2. アサーションコンシューマサービス (ACS) URL: SP が IdP から SAML アサーションを受け取るためのエンドポイント。
  3. RelayState(オプション): ユーザーがもともとアクセスしようとしていた URL など、SAML プロセス通過中にデータを渡すために使う値。

SAML 属性マッピングと暗号化

  1. NameID フォーマット: ユーザー識別子の型(例:メールアドレスやユーザー名など)の定義。
  2. SAML 属性: 役割やメール、部門など、IdP が SP へ渡す追加のユーザー情報。
    • 例: IdP が署名した SAML アサーションに email[email protected])、role(admin)、department(engineering)が含まれている場合、SP は role 属性で管理者権限を割り当てたり、department でユーザーを適切なチームにグループ化できます。このようなユーザーデータの受け渡しには、どんな情報をどう渡すか(属性マッピング)を IdP/SP で決めておく必要があります。たとえば IdP 側が「department」(部門)として定義していても、SP 側では「group」として期待していることも。そのため、適切なマッピング設定が重要です。
  3. 暗号化アサーション(オプション): 機密認証データを守るため、SAML アサーションには暗号化を適用できます。
    • IdP の役割: SP の公開鍵を使ってアサーションを暗号化する。
    • SP の役割: 自身の秘密鍵で暗号化されたアサーションを復号し、ユーザー情報を取得する。

これで SAML 接続の設定に必要な情報は一通りそろいます。例えば Salesforce(SP)と Azure AD(IdP)を連携する場合は次のようにします:

  • Azure AD から IdP エンティティ ID、SSO URL、証明書を取得し、Salesforce に設定。
  • Salesforce 側の SP エンティティ ID と ACS URL を Azure AD に提供。

Logto なら SAML 連携がシンプルに

Logto は IdP としても SP としても動作し、アプリケーションの SAML SSO をサポートできます。

Logto を SAML IdP として利用する

Logto は他アプリケーションが連携認証基盤として利用でき、多要素認証 (MFA)にも対応してセキュリティを強化できます。

  1. Logto アプリを作成 Logto コンソール > アプリケーション で新しい SAML アプリを作成します。
  2. SAML パラメータを設定 サービスプロバイダー(SP)の アサーションコンシューマサービス URLSP エンティティ ID を指定してアプリをセットアップ。
  3. メタデータ URL の提供 Logto から発行される IdP メタデータ URL を SP に渡せば、SP 側で SSO URL や証明書等の必要情報を自動取得できます。
  4. 高度な設定(任意)
    • フィンガープリント付き新規 証明書 を複数作成可能/有効期限も設定可能ですが、同時に有効なのは 1 つだけです。
    • ビジネス要件に応じて Name ID フォーマット の変更が可能です。
    • サービスプロバイダーの x509 証明書を貼り付けて SAML アサーションの暗号化 を有効にできます。
  5. 属性マッピング (任意) ユーザー属性がサービスプロバイダー(SP)へどう共有されるか簡単にカスタマイズできます。

logto_saml_apps_saml_providers.png

詳細な手順は公式ドキュメント: SAML アプリ をご覧ください。

Logto を SAML SP として利用する

Logto は SAML または OIDC プロトコル経由であらゆるエンタープライズ IdP と連携できます。統合サインイン画面での SP 主導 SSO でも、IdP 主導 SSO の設定でも簡単です。

  1. エンタープライズコネクタを作成 Logto コンソール > Enterprise SSO で新規エンタープライズコネクタを作成し、SAML をプロトコルとして選択します。
  2. SAML パラメーターを設定 IdP から メタデータ URL または メタデータ XML ファイル を提供してください。メタデータが利用できない場合は手動設定に切り替え、IdP エンティティ ID・SSO URL・署名用証明書のアップロードを行います。
  3. ACS URL と SP エンティティ ID の共有 連携完了のため、Logto の ACS URL および SP エンティティ ID を IdP 側へ伝えます。
  4. 属性マッピング(任意) メールや名前などユーザーデータのマッピング設定で、ユーザー情報が正しく IdP から Logto 間を流れるようにします。
  5. エンタープライズメールドメインの追加 エンタープライズコネクタの「SSO エクスペリエンス」タブで、1 つ以上のメールドメインを追加。指定ドメインのユーザーのみ SSO 認証できるよう制御します。
  6. IdP 主導 SSO の有効化(任意) エンタープライズクライアントが必要とする場合のみ IdP 主導 SSO を有効化。この機能により、ユーザーは IdP のダッシュボードから直接あなたのアプリにサインインできます。

logto-enterprise-saml-sso.png

詳細な手順は公式ドキュメント: Enterprise SSO documentation をご覧ください。

まとめ

SAML は標準化された安全な SSO を実現し、認証をよりスムーズにします。Logto を使えば、IdP・SP どちらの構成もシンプルです。わかりやすい UI、クラウドオープンソース の両バージョン対応で、SAML 連携の複雑さを解消します。数個のパラメータを設定するだけで、あらゆる SAML IdP/SP との接続が完成し、ユーザー体験づくりに集中できます。