すべての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を構成することが出来ます。

【 idP連携のリバースプロキシからWebへ代理認証でのSSO】

ID / パスワード認証の「既存のWebサービス」を

1. SAMLやOIDC認証のシングルサインオンのメンバーとして構成
2. バックエンドの「Webサービス」は 改修不要　*1
3. バックエンドの「Webサービス」は LAN / WAN / DMZ  の任意の場所に設置

に対応で運用する構成です

*1　サードパーティ製のWebアプリも改修不要でSSO化に対応

【 代理認証 】

SAML/OIDC認証対応のID認識型リバースプロキシから（* 2）、既存のWebサービスへ「ID / パスワード」を代理入力＆代理認証を行います

1. ユーザー操作でのWebサービスへの「ID / パスワード」の入力不要
2. 「ID / パスワード認証」のWebサービスをSSOのメンバーとして構成

*2 SP機能のリバースプロキシと代理入力のリバースプロキシを分離して多段構成での運用にも対応

【 代理認証のSSOに必要な機器構成 】

1. 　idP
2. 　SAML / OIDC認証機能のID認識型リバースプロキシ（ ユーザー情報の代理入力機能 ）
3. 　既存のWebサービス （ Webの改修は不要 ）
4. 　ブラウザ（プラグイン不要）

 【idP】

idPとしては、Microsoft Entra ID（旧名称  Azure AD）の他に

SAML / OIDC認証をサポートの 一般的なidP に対応

• GMOトラストログイン
• Keycloak
• 他

【idPとリバースプロキシはSAML認証やOIDC認証で接続】

【代理認証でのSSO手順】

1. SAML / OIDC認証対応のID認識型リバースプロキシへアクセス
2. 初回のみ  idP へアクセス（シングルサインオン）
3. idP の認証後にリバースプロキシからバックエンドのWebへユーザー情報を代理入力
4. バックエンドのWebへ自動ログイン

【各種Web システムへのSSO】

一度の idP認証で、複数のWebシステムへSSOでアクセスできます

【SSLクライアント認証の併用（多要素認証 / MFA）】

SSLクライアント認証でidPやリバースプロキシへの認証を強化

1. idPとのSAML / OIDC認証
2. SSLクライアント認証

SSLクライアント認証時のアクセスコントロール 例

1. 組織や部門でのアクセス制限  （ 営業部にアクセス許可 ）
2. 曜日や時間帯でのアクセス制限　（ 月 – 金 / 9:00 – 18:00 はアクセス許可）
3. 特定ユーザーでのアクセス制限  （ bad-user のアクセス制限 ）
4. 端末を紛失したＡさんのアクセス禁止　（ 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に必要な機器構成】

1. 　idP
2. 　SAML / OIDC認証機能のID認識型リバースプロキシ（ ユーザー情報のヘッダー追加機能 ）
3. 　既存のWebサービス （ Webの改修は必要 ）
4. 　ブラウザ（プラグイン不要）

【アプライアンスの運用先】

idP連携のSAML / OIDC認証対応のID認識型リバースプロキシの運用先

　「Powered BLUE Reverse-Proxy with SSO 」

• VMware / Hyper-V
• AWS / Azure / FUJITSU Hybrid IT Service FJcloud-O (富士通) / WebARENA / ALTUS / VPSなど

製品についての、ご質問やご相談など

リバースプロキシを利用することで、既存のWebサービスを改修することなくSAML認証やOIDC認証の機能を付加して、idPと連携してSSOでの運用が出来ます。

自社のWebサービスの他、他社が管理・提供するWebアプリやサービスへのアクセスにもSSO化を適用させることが出来ます。

【SSOとは】

シングルサインオン（SSO）とは、ユーザーが複数のアプリケーションにログインする際に、1回だけ認証を行うことで、すべてのアプリケーションにアクセスできる仕組みです。SSOを利用することで、ユーザーはパスワードを記憶する必要がなくなります。

すべてのアプリケーションがSSOに対応しているわけではありません。特に、社内に設置されているWebサーバーは、SSOに対応していないことが多くあります。そのため、社内のユーザーは、各アプリケーションに個別にログインする必要があります。

ID / パスワード認証の既存Web

そこで、ID認識型リバースプロキシを利用することで、社内のWebサーバーにSSOを適用することができます。ID認識型リバースプロキシは、ユーザーがアクセスするWebサーバーと idPを連携し、ユーザーの認証を行います。これにより、ユーザーはID認識型リバースプロキシを経由してWebサーバーにアクセスするだけで、SSOを利用することができます。

【こんな場合に】

• 既存のWebを改修せずにSSO化したい
• 自社の既存WebをSaaS化したい
• 他社のWebサービスをSSOで利用したい
• ユーザーにWebアプリの ID / パスワードを入力させたくない
• ユーザーにWebアプリの ID / パスワードを公開したくない
• 共通のアカウントでログインしたいWebアプリがある
• 既存の ID / パスワード認証 と SSOを併用したい
• 改修不要で多要素認証（MFA）に対応させたい
• ブラウザのみで利用したい
• リバースプロキシは自社管理で運用したい
• VPNは負荷が高いので使用を控えたい

【リバースプロキシの特徴】

• アクセス先のWebサーバーのOSは問わない
• アクセス先のWebサーバーを隠蔽
• アクセス先のWebサーバーの改修不要

【リバースプロキシでSSO対応】

既存で運用中のWebサービスを改修することなく、OIDCやSAML認証に対応の idP  と連携を行いシングルサインオンを行う場合

• SAML / OIDC認証に対応のID認識型リバースプロキシ

を利用してユーザー情報の「代理入力」を行い、Webサービスへシングルサインオンを構成します。

リバースプロキシは、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サービス」を

1. SAMLやOIDC認証のシングルサインオンのメンバーとして構成
2. バックエンドの「Webサービス」は 改修不要
3. バックエンドの「Webサービス」は LAN / WAN / DMZ  の任意の場所に設置

に対応で運用します

【代理認証】

SAML/OIDC認証対応のID認識型リバースプロキシ ( *2 ) から、既存のWebサービスへ「ID / パスワード」を代理入力＆代理認証を行います

1. ユーザー操作でのWebサービスへの「ID / パスワード」の入力不要
2. ID / パスワード認証のWebサービスをSSOのメンバーとして構成

*2 SP機能のリバースプロキシと代理入力のリバースプロキシを分離して多段構成での運用にも対応

【SSOに必要な機器構成】

1. 　idP
2. 　SAML / OIDC認証機能のID認識型リバースプロキシ（ ユーザー情報の代理入力機能 ）
3. 　既存のWebサービス （ Webの改修は不要 ）
4. 　ブラウザ（プラグイン不要）

 【idP】

idPとしては、Microsoft Entra ID（旧名称  Azure AD）の他に

SAML / OIDC認証をサポートの 一般的なidP に対応

• GMOトラストログイン
• Keycloak
• 他

idPとリバースプロキシはSAML認証やOIDC認証で接続

【SSO時のアクセス】

1. SAML / OIDC認証対応のID認識型リバースプロキシへアクセス
2. 初回のみ  idP へアクセス（シングルサインオン）
3. idP の認証後にリバースプロキシからバックエンドのWebへユーザー情報を代理入力
4. バックエンドのWebへ自動ログイン

【各種Web システムへのSSO】

一度の idP認証で、複数のWebシステムへSSOでアクセスできます

【SSLクライアント認証の併用（多要素認証/MFA）】

SSLクライアント認証でidPやリバースプロキシへの認証を強化

1. idPとのSAML / OIDC認証
2. SSLクライアント認証

【既存の認証方法とSSOの併用】

アクセス元により認証方法を変えることも出来ます。

1. 従来の ID / パスワード認証（社内からのアクセス）
2. idP 連携によるSSO（社外からのアクセス）

の併用など柔軟な運用が可能です。

【お問合せ】

ご質問やご相談など

リバースプロキシを利用することで既存の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サービス」を

1. SAMLやOIDC認証のシングルサインオンのメンバーとして構成
2. バックエンドの「Webサービス」は 改修不要
3. バックエンドの「Webサービス」は LAN / WAN / DMZ  の任意の場所に設置

で運用します

* idPとしてMicrosoft Entra ID（旧名称 Azure AD）を利用時の構成

【代理認証】

SAML/OIDC認証対応のID認識型リバースプロキシ ( *2 ) から、既存のWebサービスへ「ID / パスワード」を代理入力＆代理認証

1. 　ユーザー操作でのWebサービスへの「ID / パスワード」の入力不要
2. 　ID / パスワード認証のWebサービスをSSOのメンバーとして構成

*2 SP機能のリバースプロキシと代理入力のリバースプロキシを分離して多段構成での運用にも対応

【SSO運用時の必要な機器構成】

1. 　idP
2. 　SAML / OIDC認証機能のID認識型リバースプロキシ（ ユーザー情報の代理入力機能 ）
3. 　既存のWebサービス （ Webの改修は不要 ）
4. 　ブラウザ（プラグイン不要）

 【idP】

idPとしては、Microsoft Entra ID（旧名称  Azure AD）の他に

SAML / OIDC認証をサポートの idP に広く対応

• GMOトラストログイン
• Keycloak
• 他

idPとリバースプロキシはSAML認証やOIDC認証で接続

【SSO時の手順】

1. SAML / OIDC認証対応のID認識型リバースプロキシへアクセス
2. 初回のみ  idP へアクセス（シングルサインオン）
3. idP の認証後にリバースプロキシからバックエンドのWebへユーザー情報を代理入力
4. バックエンドのWebへ自動ログイン

【SSLクライアント認証の併用（多要素認証・MFA）】

SSLクライアント認証でidPやリバースプロキシへの認証を強化

1. idPとのSAML / OIDC認証
2. SSLクライアント認証

【各種Web システムへのSSO】

一度の idP認証で、複数のWebシステムへSSOでアクセスできます

【既存の認証方法とSSOの併用】

アクセス元により認証方法を変えることも出来ます。

1. 従来の ID / パスワード認証（社内からのアクセス）
2. idP / IDaaS 連携によるSSO（社外からのアクセス）

の併用などの柔軟な運用が可能です。

既存で運用の社内Webシステムなどは、SAML認証やOIDC認証に未対応のケースが多くiDaaS/idPと直接の連携が取れません。またidPとの連携を行う為のWebアプリの改修が困難なシステムもあります。

現在運用中のWebアプリを改修することなく、iDaaS / idPとのシングルサインオンやSaaS化で運用するための構成です。

SAMLやOIDC認証機能のSSOリバースプロキシを利用

SAMLやOIDC認証に対応していない既存のWebサービスを、シングルサインオンに対応させる方法として

• SAML / OIDC認証機能のSSOリバースプロキシ

を利用して「ID / パスワード」の代理入力により、既存のWebアプリへSSOを行います。

リバースプロキシは、Webサービスとユーザー間の仲介役として機能し、ユーザー認証やアクセス制御などの機能を提供します。

リバースプロキシの特徴

1. バックエンドの既存Webを隠蔽（セキュリティ上のメリット）
2. ブラウザのみで利用（VPNのような専用のクライアント不要）
3. VPNなどに比べて負荷が低い

代理入力のシングル・サインオン構成

SAML / OIDC認証機能のSSOリバースプロキシでの「ID / パスワード」代理入力時の構成

• 「Webシステム」のOSに依存せずに導入できる
• 「Webシステム」は 改修不要
• 「Webシステム」は WANやLAN の任意の場所に設置
•  サードパーティ製の「Webシステム」にも対応
•  他社が運用する「Webシステム」にも対応
•  ブラウザのみで利用

代理認証

リバースプロキシが代理認証を行うため  *1

1. 利用者からの「ID/パスワード」の入力＆管理不要　*2
2. 利用者からの「ID/パスワード」漏洩リスクを低減
3. SAML / OIDC認証に未対応のWebをSSOのメンバーとして構成

*1 SP機能のリバースプロキシと代理入力のリバースプロキシを分離して多段構成での運用にも対応
*2 Webへの入力データのカスタムにも対応可能（自社やサードパーティのWebアプリ）

SSOに必要な機器

1. idP
2. リバースプロキシ（ ユーザー情報の代理入力機能 ）
3. 既存のWebアプリ（ 改修不要 / エージェント不要 ）
4. ブラウザ（ プラグイン不要 ）

idP

SAML認証やOIDC認証の一般的なidPが利用できます。

• Microsoft Entra ID / Azure AD
• GMOトラストログイン
• Keycloak
• 他

idPとリバースプロキシはSAML認証やOIDC認証で連携します。

リバースプロキシ・アプライアンス

リバースプロキシは、SAML / OIDC認証機能のID認識型リバースプロキシ・アプライアンス

「Powered BLUE ReverseProxy for SSO / IDaaS」

で構築運用します。

リバースプロキシ・アプライアンスの機能

• リバースプロキシ
• SAMLやOIDC認証（SP / RP 機能  *1 ）
• バックエンドのWebへユーザー情報の代理入力
• GUIからの設定および運用

機能を有しており、任意の場所で自社管理でオールインワン運用を行うことが出来ます。

*1  SAML認証時はSP （Service Provider）  OIDC認証時はRP（Relying Party）という名称です

代理入力のSSOアクセス手順

1. リバースプロキシへアクセス
2. 初回のみ idP へアクセス
3. idP の認証後にリバースプロキシから既存Webへユーザー情報を代理入力
4. 既存Webへ自動ログイン

各種Web システムへのシングルサインオン

一度の idP認証で、複数のWebシステムへSSOでアクセスできます

多要素認証（MFA）

SSLクライアント認証でidPやリバースプロキシへの認証を強化の例

1. SSLクライアント認証
2. ID / Passwd認証

Microsoft Entra ID / Azure AD / KeycloakなどのidP ではワンタイムパスワード認証も利用が出来ます。

1. ワンタイムパスワード認証は、毎回「入力する」必要があります
2. SSLクライアント認証は、SSLクライアント証明書を一度インストールすると操作は不要です

多要素認証の比較

認証	SSLクライアント認証	ワンタイムパスワード認証
認証操作	不要	毎回必要
判定のタイミング	ID / passwd 入力前に判定	ID / passwd 入力後に判定
リスト攻撃	ブロック　〇	ブロック

既存の認証方法とSSOの併用

アクセス元により認証方法を変えることも出来ます。

の併用などの柔軟な運用が可能です。

こんな場合に

• Webの改修不要でSSOを導入したい
• 自社のWebサービスをSSOによりSaaS化したい
• サードパーティのWebアプリをSSOで利用したい
• ユーザーにWebアプリの「 ID / パスワード」を入力させたくない
• ユーザーにWebアプリの「 ID / パスワード」を公開したくない
• ブラウザのみで利用したい
• 多要素認証に対応させたい
• VPNは負荷が高いので使用を控えたい

お問合せ

ご質問やご相談など

SAML / OIDC認証に未対応のWeb

idP連携・代理入力のリバースプロキシでのシングル・サインオン構成

* バックエンドの「Webシステム」は WANやLAN の任意の場所に設置
* バックエンドの「Webシステム」は 改修不要

代理認証＆SSO

SAML / OIDC認証に対応のリバースプロキシが代理認証を行うため、

1. 利用者からのWebへの「ID / パスワード」の入力不要
2. 利用者からの「ID / パスワード」漏洩リスクを低減
3. WebをSSOのメンバーとして構成

* 入力データ項目のカスタムにも対応可能

SSOでの機器構成

1. idP / IDaaS
2. SAML / OIDC認証に対応のリバースプロキシ（ ユーザー情報の代理入力機能 ）
3. バックエンドのWeb（改修不要）
4. ブラウザ（ プラグイン不要 ）

 idP

SAML認証やOIDC認証に対応の一般的なidPと連携できます。

• Microsoft Entra ID（旧名称　Azure AD）
• GMOトラストログイン
• Keycloak
• 他

idPとリバースプロキシはSAML認証やOIDC認証で接続します。

リバースプロキシの特徴

1. バックエンドのWebを隠蔽できる（セキュリティ上のメリット）
2. バックエンドのWebのOSに依存せずに導入できる
3. ブラウザのみで利用できる（VPNのような専用ソフトは不要）

ID認識型リバースプロキシ（ IAP: Identity Aware Proxy )

リバースプロキシは、SAML / OIDC認証に対応のSSOリバースプロキシ

「Powered BLUE ReverseProxy for SSO / IDaaS」

で構築運用します。

アプライアンスの機能

• リバースプロキシ機能
• SAMLやOIDC認証（SP / RP 機能  *1 ）
• バックエンドのWebへユーザー情報の代理入力機能
• SSLクライアント認証
• GUIから設定や運用

を有しており、任意の場所で自社管理でオールインワンでの運用を行うことが出来ます。

*1 　SAML認証時はSP （Service Provider）  OIDC認証時はRP（Relying Party）という名称です

代理入力のSSO利用ステップ

1. SAML / OIDC認証対応のリバースプロキシへアクセス
2. 初回のみ idP へアクセス
3. idP の認証後にリバースプロキシからバックエンドのWebへユーザー情報を代理入力
4. バックエンドのWebへ自動ログイン

各種Web アプリへのSSO

一度のidP認証で、複数のWebアプリへSSOでアクセスできます

SSLクライアント認証の併用（多要素認証 / MFA)

SSLクライアント認証でidPやリバースプロキシへの認証を強化

1. idPとのSAML / OIDC認証
2. SSLクライアント認証

既存の認証方法とSSOの併用

アクセス元により認証方法を変えることも出来ます。

1. 従来の ID / パスワード認証（社内からのアクセス）
2. idP / IDaaS 連携によるSSO（社外からのアクセス）

の併用などの柔軟な運用が可能です。

こんな場合に

• Webアプリの改修は不要でSSO対応にしたい
• ユーザーにWebアプリの ID / パスワードを入力させたくない
• ユーザーにWebアプリの ID / パスワードを公開したくない
• Webアプリへのアクセスに多要素認証を適用したい
• ブラウザのみで利用したい（プラグインやエージェント不要）