ログインが別々にあれば、それだけリセットするパスワードが増え、退職者が出たときに閉じるアカウントも増えます。SAML シングルサインオン（SSO）は、ラーニングマネジメントシステムを ID プロバイダーに接続し、勤務先のアカウントで研修にログインできるようにして、アクセス権をディレクトリに連動させます。ここでは、SAML の仕組み、Microsoft Entra ID、Okta、Google Workspace での設定の流れ、そして本番稼働前に確認すべき点を紹介します。
SAML シングルサインオンの仕組み
SAML（Security Assertion Markup Language）2.0 は、互いに信頼する 2 つのシステム間でログイン情報をやり取りするためのオープン標準です。LMS が本人のパスワードを見ることはありません。LMS は本人を ID プロバイダーへ送り、ID プロバイダーが（必要に応じて多要素認証も含めて）本人確認を行い、署名付きの声明とともに本人を戻します。
| 用語 | 意味 |
|---|---|
| ID プロバイダー（IdP） | 利用者を認証するシステム。Entra ID、Okta、Google Workspace など。 |
| サービスプロバイダー（SP） | 利用者がログインするアプリケーション。ここでは LMS。 |
| アサーション | IdP が発行する署名付きの XML の声明。本人が誰か、いつログインしたか、メールアドレスや氏名などの属性を含みます。 |
| エンティティ ID | 双方に付ける一意の名前。URL のような形をしていることが多いものの、あくまで識別子です。完全に一致している必要があります。 |
| ACS URL | Assertion Consumer Service URL。IdP からの応答を受け取る LMS 側のアドレス。 |
| 署名証明書 | IdP は秘密鍵で署名し、LMS は IdP の公開証明書で検証して、偽造または改ざんされたアサーションを拒否します。 |
| メタデータ | エンティティ ID、エンドポイント、証明書をまとめた XML ファイル。そのままインポートできます。 |
アサーションは有効期間が短く、宛先（SP のエンティティ ID）が指定されています。SP は、期限切れのものや、他のアプリケーション宛てのものを拒否します。
LMS に SSO を導入する価値
- 余分なパスワードが不要に。 普段使いのアカウントをそのまま使え、MFA やアクセスポリシーが研修にも適用されます。
- 新入社員がすぐに使える。 LMS アプリケーションをグループに割り当てれば、そのグループに入った新しいスタッフは初日からログインできます。
- 退職者はもとの場所でアクセスを失う。 ディレクトリで無効化すれば、新しい LMS セッションは開始できません。SAML が制御するのはログインであってアカウントではないため、退職手続きの一環として LMS のアカウントもアーカイブしてください。
ジャストインタイムのアカウント作成
ジャストインタイム（JIT）プロビジョニングでは、LMS が初回ログイン時にアサーションの属性からアカウントを作成するため、取り込むユーザー一覧が不要です。ただし、次のガードレールを設けてください。
- 自社のメールドメインに限定し、設定ミスのあるアプリケーションやゲストアカウントから不要なユーザーが作られないようにします。
- 新しいアカウントには最も低いロールを付与し、管理者権限は意図して付与します。
- メールアドレスは変わりうるため、IdP が送信できる場合は、変わらない識別子でユーザーを照合します。
SP 起点と IdP 起点のログイン
- SP 起点：本人が LMS を開くと、LMS が IdP に認証リクエストを送り、IdP がその応答を ACS URL に POST します。ブックマークやメール内のリンクからも動作し、応答が LMS の出したリクエストに対するものであるため、一般により安全な方式とされています。
- IdP 起点：本人が Microsoft My Apps、Okta のダッシュボード、Google のアプリメニューにあるアプリケーションのタイルをクリックすると、IdP がリクエストなしの応答を ACS URL に送ります。
両方を提供できます。それぞれテストしてください。
SAML SSO の設定手順
手順は、どこでもほぼ同じです。
- 対象範囲を計画する：SSO を使う人、アプリケーションを割り当てるグループ、許可するメールドメイン、各人を識別する属性を決めます。
- LMS で接続を作成し、そのエンティティ ID と ACS URL を控えます。
- IdP で SAML アプリケーションを作成し、それらの値を設定して、NameID の形式を選び、メール、名、姓の属性を追加します。
- ユーザーまたはグループを割り当てます。割り当てられていない人は、通常はログインを拒否されます。
- IdP の情報を LMS に渡します：メタデータ URL、メタデータファイル、または IdP のエンティティ ID、ログイン URL、署名証明書のいずれか。
- 属性をマッピングし、IdP が実際に送信する名前に合わせます。
- テストしてから有効化し、変更内容を利用者に伝えます。
プロバイダー別の注意点
正確な画面については、各プロバイダーのドキュメントを参照してください。知っておくと役立つ点は次のとおりです。
- Microsoft Entra ID：アプリの登録ではなく、ギャラリー以外のエンタープライズアプリケーションを使います（アプリの登録は SAML に対応していません）。クレーム名は長い URI なので、正確にコピーしてください。オブジェクト ID は、変わらない識別子として適しています。メールボックスを持たない人は、メールクレームが空になることがあります。実在するアドレスであれば、ユーザープリンシパル名で代用できます。
- Okta：SAML 2.0 アプリ統合を作成します。属性ステートメントの名前は自分で付けるため、大文字小文字も含めて、LMS のマッピングと完全に一致させる必要があります。Okta の内部ユーザー ID は、変わらない識別子として使えます。
- Google Workspace：カスタム SAML アプリを追加し、そのメタデータファイルをダウンロードします。アプリは最初はオフになっているため、対象の組織部門またはグループに対してオンにします。一般的な設定ではプライマリメールアドレスで人を識別するため、名前の変更や、アドレスの再利用に備えてください。
テストチェックリスト
本番稼働前に、プライベートブラウジングのウィンドウで次を確認します。
- 既存ユーザーが LMS から開始してログインでき、アプリのタイルからも再度ログインできる。
- 自社ドメインの新規ユーザーに、適切なロールでアカウントが作成される。
- アプリケーションに割り当てられていない人が拒否される。
- 許可されたドメイン以外の人が拒否される。
- メール、名、姓が正しく届く。
- 管理者が、リカバリー用の経路から引き続きログインできる。
よくある落とし穴
時刻のずれ
IdP と LMS の時計のずれが LMS の許容範囲を超えると、正しいアサーションが「まだ有効でない」または「すでに期限切れ」として拒否されます。主にセルフホストの ID サーバーで起こるため、時計は同期しておいてください。
証明書の更新
IdP の署名証明書には有効期限があり、LMS が更新後の証明書を信頼していないと、すべてのログインが一斉に失敗します。有効期限をスケジュールに登録しておきましょう。LMS が 2 つの証明書を信頼できる場合は、先に LMS 側で新しい証明書を追加し、その後 IdP 側で有効化します。そうでなければ、利用の少ない時間帯に双方を同時に切り替えます。切り替えたら、すぐにテストしてください。
属性のマッピング
属性名は通常、完全一致で照合されます。email を期待する LMS は、Email を受け付けません。識別子も確認してください。一時的な（transient）NameID はセッションごとに変わり、メールアドレスも変わることがあります。永続的な（persistent）NameID や不変の ID 属性は変わりません。メールアドレスで人を照合している場合は、退職者のアドレスが再割り当てされる前に、そのアカウントをアーカイブしてください。
メールドメインの不一致
ディレクトリには、ログイン名がメールアドレスではない人、他のドメインの請負業者、買収した事業のスタッフで旧ドメインのままの人が含まれていることがよくあります。LMS が特定のドメインにアカウントを限定していると、こうした人は拒否されます。本番稼働前に、すべてのドメインを洗い出してください。
Acadenix の場合
SAML SSO は Gold プランで提供され、Entra ID、Okta、Google Workspace 向けの手順ガイドが付属します。
- テストしてから有効化。 IdP の情報を下書きとして保存し、プロバイダーでログインして Test configuration（設定のテスト）を実行し、その後で初めて有効化します。メールクレームが不足している場合は、プロバイダーが実際に送信したクレーム名とともに報告されます。
- 段階的な変更。 新しい証明書やテナントは設定の更新として追加され、有効化するまでは、現在の設定が引き続き動作します。
- ドメイン内での JIT。 アカウントを持たない人は、メールアドレスが組織の登録ドメインにある場合に限り、初回ログイン時に受講者アカウントが作成されます。これは無効にすることもできます。すでに Acadenix アカウントを持っている人が初めて IdP 経由でログインすると、Acadenix は連携を確認するためのワンタイムコードをメールで送ります。これは 1 人につき 1 回だけです。
- どちらの入り口にも対応。 ログインページから開始でき（IdP に直接移動させることも、ボタンを表示することもできます）、My Apps、Okta、Google のタイルからも開始できます。
- 1 つの接続は 1 つの組織に。 SAML 接続は、その所有者の下位にある組織には引き継がれません。これは、多数の拠点を持つグループでは重要な点です。
- リカバリー用の経路。 IdP が停止していても、管理者はメールで届くワンタイムコードでログインでき、この経路は無効にできません。
SAML のほかに、メールコード、または Google、Microsoft、LinkedIn のアカウントでもログインできます。詳しくはセキュリティのページをご覧ください。
重要なポイント
- エンティティ ID、ACS URL、メタデータを交換し、変わらない識別子と検証済みのメールをマッピングします。
- JIT のアカウントは、自社ドメインと最も低いロールに限定します。
- 本番稼働前に、両方のログインフロー、拒否されるケース、リカバリー経路をテストします。
- 証明書の有効期限をスケジュールに登録し、退職者の LMS アカウントをアーカイブします。
Acadenix を ID プロバイダーに接続したいとお考えですか？料金ページでプランを比較するか、ご利用環境についてお問い合わせください。
