シングルサインオン（SSO）とは、ユーザーが複数のアプリケーションにログインする際に、1度だけ認証を行うことで、すべてのアプリケーションにアクセスできます。SSOを利用することで、ユーザーはパスワードを記憶する必要がありません。SSO時に多要素認証などの対応もできます。
すべてのWebアプリケーションがSSOに対応しているわけではありません。従来から運用中のWebアプリは、SSOに対応していないことがほとんどです。
  |
| SAML / OIDC認証に未対応のWeb |
【リバースプロキシの利用】
既存で運用の「SAMLやOIDC認証に未対応のWebサービス」を Azure AD（新名称 Microsoft Entra ID）などの、iDaaSやidPと連携してシングルサインオンで運用する場合の構築方法です。
SAML/ OIDC認証に対応の代理認証やHTTPヘッダー方式のリバースプロキシを利用することで、idPと連携して既存のWebサービスへのSSOが構成できます。
【こんなケースに】
- ユーザーにID / パスワードを入力させたくない
- 社内のWebをSSOに対応させたい
- 自社のWebサービスをSSOによりSaaS化したい
- サードパーティのWebアプリをSSOで運用したい
- Webサービスは改修不要でSSO を導入したい
- Webサービスへ多要素認証を適用したい
- 共有アカウントでログインさせたいWebアプリがある
- ブラウザのみで利用させたい
- 既存の認証とSSOの認証を併用したい
- VPNは負荷が高いので使用を控えたい
【リバースプロキシの特徴】
- アクセス先のWebサーバーのOSは問わない
- アクセス先のWebサーバーを隠蔽
- ブラウザのみでアクセスできる（専用のクライアントは不要）
【 SAML / OIDC認証に対応のリバースプロキシ】
idP連携のSAML / OIDC認証対応のID認識型リバースプロキシ
「Powered BLUE Reverse-Proxy with SSO 」
を利用します。
【アプライアンスの機能】
- リバースプロキシ機能
- SAMLやOIDC認証（SP / RP 機能 *1 ）
- バックエンドのWebへユーザー情報の代理入力機能
- バックエンドのWebへHTTPヘッダーでのユーザー情報の転送機能
- SSLクライアント認証
- GUIから設定や運用
を有しており、任意の場所で自社管理でオールインワンでの運用を行うことが出来ます。
*1 SAML認証時はSP （Service Provider） OIDC認証時はRP（Relying Party）という名称
【2種類のSSO】
SAMLやOIDC認証に未対応のWebサービスに対しては、リバースプロキシ 「Powered BLUE Reverse-Proxy with SSO 」を利用することで、2種類の方法でターゲットWeb側へユーザー情報を渡してSSOを構成することが出来ます。
| SSO 方式 | 内 容 | 備 考 |
| 代理認証方式 | idPからのユーザー属性を元に ユーザー ID / Passwdをリバースプロキシから ターゲットWebへ代理入力を行う |
Webの改修不要 |
| HTTPヘッダ方式 | idPからのユーザー属性をHTTPヘッダを介して ターゲットWebへ渡す |
Webの改修必要 |
【 idP連携のリバースプロキシからWebへ代理認証でのSSO】
ID / パスワード認証の「既存のWebサービス」を
- SAMLやOIDC認証のシングルサインオンのメンバーとして構成
- バックエンドの「Webサービス」は 改修不要 *1
- バックエンドの「Webサービス」は LAN / WAN / DMZ の任意の場所に設置
に対応で運用する構成です
*1 サードパーティ製のWebアプリも改修不要でSSO化に対応
【 代理認証 】
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へ自動ログイン
【各種Web システムへのSSO】
一度の idP認証で、複数のWebシステムへSSOでアクセスできます
【SSLクライアント認証の併用（多要素認証 / MFA）】
SSLクライアント認証でidPやリバースプロキシへの認証を強化
- idPとのSAML / OIDC認証
- SSLクライアント認証
| クライアント証明書 〇 | クライアント証明書 ✕ |
SSLクライアント認証時のアクセスコントロール 例
- 組織や部門でのアクセス制限 （ 営業部にアクセス許可 ）
- 曜日や時間帯でのアクセス制限 （ 月 – 金 / 9:00 – 18:00 はアクセス許可）
- 特定ユーザーでのアクセス制限 （ bad-user のアクセス制限 ）
- 端末を紛失したＡさんのアクセス禁止 （ user-A のアクセス禁止 ）
【 HTTPヘッダー方式でのSSO 】
【idP連携のリバースプロキシからHTTPヘッダ方式でのSSO】
idPからのユーザー情報をHTTPヘッダに乗せるSSOの場合、ターゲットWeb側ではヘッダーへ記載のユーザー情報からWebへのログインをさせる改修が必要です。
【 リバースプロキシでのHTTP header の設定 】
- リバースプロキシでは、SAMLやOIDC認証の ヘッダマップを有効にします
【 HTTP header への追加の例 】
- idPでの認証ユーザーのEmail アドレスをhttpヘッダーに追加
Remote-User-Email: demo-user@mubit.com .
【 プロキシID を追加の例 】
バックエンドのWebサーバー側へ「プロキシID」を渡すことが出来ます
- リバースプロキシの「プロキシID」をhttpヘッダーに追加
【HTTP header方式のSSOに必要な機器構成】
- idP
- SAML / OIDC認証機能のID認識型リバースプロキシ（ ユーザー情報のヘッダー追加機能 ）
- 既存のWebサービス （ Webの改修は必要 ）
- ブラウザ（プラグイン不要）
【アプライアンスの運用先】
idP連携のSAML / OIDC認証対応のID認識型リバースプロキシの運用先
「Powered BLUE Reverse-Proxy with SSO 」
- VMware / Hyper-V
- AWS / Azure / FUJITSU Hybrid IT Service FJcloud-O (富士通) / WebARENA / ALTUS / VPSなど
【お問合せ】
