「共有アカウント」カテゴリーアーカイブ

Microsoft Entra IDと代理認証機能のリバースプロキシで既存Webの共有アカウントをSSO化

企業では、取引先が提供するWebサービスや社内システムなどのアカウントを、複数のユーザーで共有するケースがあります。

共有アカウントでは、認証に際して生体認証やスマートフォンなどの個人の所持認証が使えずに「ID/パスワード認証」などの知識情報での利用に限定されるなど、セキュリティ上の制約が生じる場合があります。

またWebサービスがシングルサインオンに対応していない場合、ユーザーは毎回IDとパスワードを入力する必要があります。社員の移動や退職などに伴うIDとパスワードの変更や告知作業をはじめ、ID/パスワードの漏洩のリスクも生じます。さらに共通アカウントでのアクセスでは、どのユーザーが利用したのかを判別しにくいという問題もあります。

これらの課題を解決するために、Microsoft Entra IDと代理認証機能のリバースプロキシを活用した共有アカウントのSSO化が有効です。

 

共有アカウントでのシングルサインオン

シングルサインオン（SSO）は、ユーザーが複数のアプリケーションにログインする際に、一度の認証で済むようにする仕組みです。ユーザーの利便性向上や、セキュリティの向上に効果があります。

企業では、idP / IDaaS やMicrosoft Entra ID（旧名称 Azure AD）の利用などでSSOの環境が整っているケースもあります。複数人で同じアカウントを共用するケースでは、idPと連携してSSO化を行い

  1. セキュリティを強化
  2. トレーサビリティの強化
  3. ユーザーの負担軽減

を図ることができます。

 

 

 

共通アカウントでのシングルサインオンの要件（Ｎ：１ や N：M）

idPと連携できないSAML/OIDC認証に未対応のWebサイトの共有アカウントをSSOで構成させる際の要件としては

  • idP ではユーザーごとの個人認証
  • 既存のWebサイトは「共有アカウント」を利用
  • 既存のWebサイトは、改修不要でSSOに対応させる
  • アカウントは　Ｎ：１  や　N：Ｍでの紐付け
  • ユーザーには、Webサイトへの ID / パスワードの入力をさせない
  • ユーザーには、Webサイトへの ID / パスワードを公開しない
  • ブラウザのみでの利用（プラグイン不要）
  • 多要素認証に対応
  • ユーザーの利用状況や利用者を特定できること

などです。

 

 

 

 

 

 

 

Webサイトの改修不要で共有IDのSSO化

既存で利用の共有アカウントのWebへ、 idPと連携したSAMLやOIDC認証のリバースプロキシ経由でアクセスすることで、共有アカウントのSSO化を実現することができます。

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

 

リバースプロキシのメリット

  1. ID/パスワード認証に加えて、生体認証や多要素認証などの高度な認証方式を採用できる
  2. Webアプリの改修をすることなくSSOを実現できる（エージェント不要）
  3. ブラウザのみで利用できる（プラグイン不要）
  4. ユーザーのアクセス履歴を記録し、安全な運用を支援できる

 

 

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）という名称

 

 

共有アカウント＆代理認証

SAML/OIDC認証対応のID認識型リバースプロキシから、既存のWebサービスへ共有アカウントや特権アカウントの「ID / パスワード」を代理入力＆代理認証を行います   *2

  1. アカウントはＮ：１ や  N：Ｍでの紐付け
  2. ユーザー操作でのWebアプリへの「ID / パスワード」の入力不要
  3. 「ID / パスワード認証」のWebアプリをSSOのメンバーとして構成

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

 

 

idP連携のリバースプロキシから代理認証で共有アカウントへSSO

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

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

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

*3  サードパーティ製 Webアプリ や他社の サービス も改修不要で共有アカウントのSSO対応

 

 

SSOに必要な機器構成

 

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

 

idP

 

 

 

 

 

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

  • Microsoft Entra ID（旧名称  Azure AD）
  • 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 のアクセス禁止 ）

 

 

 

こんな場合に適しています

 

 

  • 共通のアカウントで利用したいWebサイトがある
  • WebサイトへSSOでアクセスしたい
  • Webサイト側の改修はできない
  • ユーザーにWebサイトの 「 ID / パスワード」を公開したくない
  • ユーザーにWebサイトの 「 ID / パスワード」を入力させたくない
  • Webサイトへのアクセスに多要素認証を適用したい
  • ブラウザのみで利用したい（プラグイン不要）
  • ユーザーの利用状況を把握したい

 

アプライアンスの運用先

 

 

 

 

 

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

　「Powered BLUE Reverse-Proxy with SSO 」

 

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

 

 

お問合せ

 

 

 

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