既存で運用の ID / パスワード認証のWebサービスをidPのMicrosoft Entra ID（旧名称 Azure AD）などのiDaaSやidPと連携させる場合、既存のID / パスワード認証は残しながらidPと連携してシングルサインオンで運用する場合の構築方法です。
リバースプロキシを利用することで既存のWebサービスにSAML認証やOIDC認証を追加して、SaaS対応や多要素認証（MFA）により認証機能を強化することが出来ます。
 |
| 既存の ID / パスワード認証のWeb |
【改修不要でSSO対応】
既存で運用中のWebサービスを改修することなく、OIDCやSAML認証に対応の idP と連携を行いシングルサインオンを行う手法として
- OIDC認証やSAML認証に対応のID認識型リバースプロキシ
を利用してユーザー情報の「代理入力」を行い、Webサービスへシングルサインオンで構成します。
【ID認識型リバースプロキシ】
リバースプロキシは、SAML / OIDC認証に対応のID認識型リバースプロキシ・アプライアンス
「Powered BLUE ReverseProxy for SSO / IDaaS」
で構築運用します。
アプライアンスの機能
- リバースプロキシ機能
- SAMLやOIDC認証（SP / RP 機能 *1 ）
- バックエンドのWebへユーザー情報の代理入力機能
- SSLクライアント認証
- GUIから設定や運用
を有しており、任意の場所で自社管理でオールインワンでの運用を行うことが出来ます。
*1 SAML認証時はSP （Service Provider） OIDC認証時はRP（Relying Party）という名称です
【idP連携のリバースプロキシからWebへ代理入力＆SSO】
ID / パスワード認証の「既存のWebサービス」を
- SAMLやOIDC認証のシングルサインオンのメンバーとして構成
- バックエンドの「Webサービス」は 改修不要
- バックエンドの「Webサービス」は LAN / WAN / DMZ の任意の場所に設置
で運用します
* idPとしてMicrosoft Entra ID（旧名称 Azure AD）を利用時の構成
【代理認証】
SAML/OIDC認証対応のID認識型リバースプロキシ ( *2 ) から、既存のWebサービスへ「ID / パスワード」を代理入力＆代理認証
- ユーザー操作でのWebサービスへの「ID / パスワード」の入力不要
- ID / パスワード認証のWebサービスをSSOのメンバーとして構成
|
 |
*2 SP機能のリバースプロキシと代理入力のリバースプロキシを分離して多段構成での運用にも対応
【SSO運用時の必要な機器構成】
- idP
- SAML / OIDC認証機能のID認識型リバースプロキシ（ ユーザー情報の代理入力機能 ）
- 既存のWebサービス （ Webの改修は不要 ）
- ブラウザ（プラグイン不要）
【idP】
idPとしては、Microsoft Entra ID（旧名称 Azure AD）の他に
SAML / OIDC認証をサポートの idP に広く対応
- GMOトラストログイン
- Keycloak
- 他
idPとリバースプロキシはSAML認証やOIDC認証で接続
 |
|
【SSO時の手順】
- SAML / OIDC認証対応のID認識型リバースプロキシへアクセス
- 初回のみ idP へアクセス（シングルサインオン）
- idP の認証後にリバースプロキシからバックエンドのWebへユーザー情報を代理入力
- バックエンドのWebへ自動ログイン
【SSLクライアント認証の併用（多要素認証・MFA）】
SSLクライアント認証でidPやリバースプロキシへの認証を強化
- idPとのSAML / OIDC認証
- SSLクライアント認証
| クライアント証明書 〇 | クライアント証明書 ✕ |
【各種Web システムへのSSO】
一度の idP認証で、複数のWebシステムへSSOでアクセスできます
【既存の認証方法とSSOの併用】
アクセス元により認証方法を変えることも出来ます。
- 従来の ID / パスワード認証（社内からのアクセス）
- idP / IDaaS 連携によるSSO（社外からのアクセス）
の併用などの柔軟な運用が可能です。
| ID / パスワード認証 | SSO |
