SAML非対応システムのSSOとオンプレ・クラウドの認証統合課題

SAMLに対応していない業務システムでも、認証方式に応じた連携を行えばシングルサインオン（SSO）を実現できる場合があります。代表的な方法には、HTTPヘッダーを使った認証連携、Kerberos制約付き委任（KCD）、パスワードベースのSSOなどがあります。重要なのは、対象システムの認証方式や対応機能、オンプレミス・クラウド間のIDの対応関係を把握することです。代表的な方法と導入時の注意点を解説します。

SAML非対応システムでSSOを実現する方法

HTTPヘッダーを使った認証連携

Webアプリケーションがユーザー名などの属性情報をHTTPヘッダーで受け取れる場合は、リバースプロキシを介して認証情報を渡す方法があります。Microsoft Entraアプリケーションプロキシでは、クラウド側で利用者を認証し、設定した属性情報をHTTPヘッダーとしてバックエンドのアプリケーションへ連携できます。アプリケーション側がヘッダー認証に対応していることが前提で、プライベートネットワークコネクタから対象アプリへ接続できる必要があります。また、プロキシを通らない直接アクセスをファイアウォールやIP制限などで防ぎ、認証ヘッダーを偽装されないようにすることも重要です。

Kerberos認証を利用するシステム

Windows統合認証（IWA）を使う社内Webシステムでは、Kerberos制約付き委任（KCD）が選択肢になります。Microsoft Entraアプリケーションプロキシで利用者を認証した後、プライベートネットワークコネクタがオンプレミスのActive Directoryと連携し、利用者に代わるKerberosチケットを取得してアプリケーションへ渡します。導入には、対象アプリケーションのIWA対応、サービスプリンシパル名（SPN）の設定、コネクタサーバーとアプリケーションサーバーのドメイン参加、委任権限の設定などが必要です。ドメインコントローラーとの接続も確保しなければなりません。

フォーム認証にはパスワードベースのSSO

ログイン画面にID・パスワードを入力するシステムでは、認証情報を保管し、ログイン時に自動入力するパスワードベースのSSOも選択肢です。Microsoft Entra IDでは、ユーザーの認証情報を暗号化して保存し、ブラウザー拡張機能を通じてログインフォームに入力する仕組みを提供しています。既存のログイン画面を利用できる一方、利用者ごとの認証情報の登録・更新が必要です。また、HTML形式のログインページが前提となり、画面構成や入力項目の変更によって動作しなくなる可能性があります。

オンプレミスとクラウドの認証統合で起きる課題

オンプレミスとクラウドのIDを連携する場合は、ユーザー名やUPN、メールアドレスなどの識別子を確認し、同一人物のアカウントを正しく対応付ける必要があります。アカウントの紐付けが不適切だと、意図したユーザーで認証できなかったり、アプリケーション側の権限と一致しなかったりする可能性があります。グループやアプリケーション側の権限、入退社・異動時のアカウント更新ルールも整理しましょう。

また、Microsoft Entra IDへのハイブリッド認証方式として、パスワードハッシュ同期（PHS）とパススルー認証（PTA）があります。PHSはオンプレミスのAD DSからパスワードハッシュをMicrosoft Entra IDへ同期し、クラウド側で認証する方式です。認証時にオンプレミスのドメインコントローラーへ接続する必要はありません。一方、PTAはオンプレミスに設置した認証エージェントを通じて、Active Directoryでパスワードを検証します。そのため、認証時にはエージェントが稼働しているサーバーとドメインコントローラーへの接続が必要です。

なお、PHSとPTAはMicrosoft Entra IDへのハイブリッド認証方式であり、SAML非対応の業務システムに対するSSO連携方式そのものではありません。アプリケーションへのSSO方式と、クラウドID基盤への認証方式を分けて検討し、可用性とセキュリティ要件に合う構成を選ぶことが重要です。

導入前に確認したいポイント

対象システムの認証方式や対応プロトコル、IDの紐付け、MFA・アクセス制御、ログ取得、障害時の代替手段を確認します。HTTPヘッダー認証では、アプリケーションへの直接アクセスを制限し、信頼できるプロキシやコネクタからの通信だけを許可することが重要です。KCDでは、SPNや委任権限、ドメイン接続を確認します。フォーム認証では、ログイン画面の仕様やブラウザー拡張機能の利用条件を確認しましょう。

コネクタや認証エージェントを使う場合は、冗長化や通信経路、障害発生時の復旧手順も検討します。SAML非対応でもSSOを実現できる可能性はありますが、利用できる方式や運用負荷はシステムによって異なります。まずは小規模な検証環境で認証動作やセキュリティを確認し、問題がないことを確かめてから段階的に展開することが大切です。