Azure ADアプリケーションプロキシによるSSOを構成の場合には、Windows Serverの使用が推奨されており、Windows認証以外のアプリでは導入が困難です。またユーザーは、Azure ADアプリケーションプロキシで公開されたWebアプリにアクセスするために、ブラウザへのアドオンツールをインストールする必要があります。
  |
| SAMLやOIDC認証に未対応のWeb |
一方、 Microsoft Entra ID（旧名称 Azure AD ) に連携のリバースプロキシによるシングルサインオンは、Windows Serverの使用を必要とせず、Windows OS 以外のWebアプリでも利用できます。また、ブラウザへのアドオンも不要です。Webアプリを簡単にSSO化したい場合に適しています。
リバースプロキシは「Webの改修は不要」でSSO化を実現できます。そのため他社で提供のWebサービスやアプリへのアクセスもSSO化に対応できます。
アプリケーションプロキシとリバースプロキシの機能と特徴
| サービス | WebのOS | Webの改修 | 他社WebのSSO化 | 共有アカウントのSSO | ブラウザ |
| アプリケーションプロキシ | Windows | 必要 | ✖ | ✖ | プラグイン必要 |
| リバースプロキシ | OSは不問 | 不要 | 〇 | 〇 | プラグイン不要 |
代理認証に対応のリバースプロキシ
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）という名称
代理認証
SAML/OIDC認証対応のID認識型リバースプロキシから（* 2）、既存のWebサービスへ「ID / パスワード」を代理入力＆代理認証を行います
- ユーザー操作でのWebサービスへの「ID / パスワード」の入力不要
- 「ID / パスワード認証」のWebサービスをSSOのメンバーとして構成
|
 |
*2 SP機能のリバースプロキシと代理入力のリバースプロキシを分離して多段構成での運用にも対応
idP連携のリバースプロキシからWebへ代理認証でSSO
ID / パスワード認証の「既存のWebサービス」を
- SAMLやOIDC認証のシングルサインオンのメンバーとして構成
- バックエンドの「Webサービス」は 改修不要 *3
- バックエンドの「Webサービス」は LAN / WAN / DMZ の任意の場所に設置
に対応の構成で運用できます
*3 Webアプリは改修不要なので、他社で提供のWebアプリやサービスへのSSO化にも対応
SSOに必要な機器構成
- idP
- SAML / OIDC認証機能のID認識型リバースプロキシ（ ユーザー情報の代理入力機能 ）
- 既存のWebアプリ （ Webの改修不要 / エージェント不要）
- ブラウザ（プラグイン不要）
idP
 |
|
SAML / OIDC認証をサポートの 一般的なidP に対応
- Microsoft Entra ID（旧名称 Azure AD）
- GMOトラストログイン
- Keycloak
- 他
idPとリバースプロキシはSAML認証やOIDC認証で接続
SSOの利用手順
 |
- リバースプロキシへアクセス
- 初回のみ 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 のアクセス禁止 ）
共有IDや特権IDでのSSO
複数人で同じアカウント情報を共有するケースでは、SSOを利用することで、ユーザーの負担を軽減し、セキュリティを強化することができます。
例えば、取引先の会社で提供するサービスのアカウントを総務部で共有する場合、Azure AD連携の代理認証対応リバースプロキシを利用することで、Webアプリは改修不要で「共有アカウント」のSSOを簡単に実現できます。
共有アカウントでWebアプリをSSOで構成する場合の要件
- Azure AD / idP ではユーザーごとの個人認証
- 既存のWebアプリは「共有アカウント」を利用
- 既存のWebアプリは、改修不要でSSOに対応
- アカウントは 「Ｎ：１ 」 や 「N：Ｍ」での紐付け
- ユーザーには、Webアプリへの ID / パスワードの入力をさせない
- 自社で利用状況や利用者を確認できること
idP連携のリバースプロキシから代理認証で共有アカウントへSSO
ID / パスワード認証の「既存のWebサービス」を
- SAMLやOIDC認証のシングルサインオンのメンバーとして構成
- バックエンドの「Webサービス」は 改修不要 *4
- バックエンドの「Webサービス」は LAN / WAN / DMZ の任意の場所に設置
に対応で運用する構成です。
*4 サードパーティ製 Webアプリ や他社の Webサービス も改修不要で共有アカウントのSSO対応
代理認証のリバースプロキシはこんなケースに適しています
- 自社のWebアプリをSSOに対応させたい
- 他社のWebサービスをSSOで利用したい
- Webアプリやサービスは改修不要でSSO に対応させたい
- ブラウザのみで利用したい（プラグイン不要）
- ユーザーに「ID / パスワード」を入力させたくない
- ユーザーに「ID / パスワード」を公開したくない
- 共有アカウントや特権アカウントで利用のWebをSSOに対応させたい
- 他社のWebアプリやサービスへの利用状況も確認したい
お問合せ
