Powered BLUE」カテゴリーアーカイブ

Azure ADと連携するOIDC認証対応のリバースプロキシ経由でターゲットWebへSSOアクセス

Azure ADと認証対応のリバースプロキシ経由でターゲットWebへのアクセスをさせます。Azure ADとリバースプロキシの認証連携としては、OpenID ConnectやSAML認証などが利用できます。今回はOpenID Connect / OIDC で連携します。

https://japan.zdnet.com/storage/2017/08/03/de5e58b6c73ae8f65bb4ce49490d6dce/newsigninpage.jpg

リバースプロキシ経由でのアクセスに際しては、ターゲットWeb側の改修は不要です。ターゲットWeb側の認証が脆弱もしくは認証機能が無い場合でも、Azure AD側の認証を追加できます。

ネットワークやサーバー負荷のかかるAzure ADに対応のアプリケーション・プロキシ・コネクタは使用しません。アプリケーション・プロキシ・コネクタを利用する際に必要となる「許可する外部URL」などの指定も不要です。

 

【こんな用途に】

  • Webを改修せずにSSOに対応させたい
  • Azure AD  の認証を利用したい
  • アプリケーションプロキシコネクタは設置したくない
  • WebのOSは不問でSSOを行いたい
  • サードパーティのWebアプリをSSOで利用したい
  • 共有アカウントでログインしたいWebアプリがある
  • ブラウザのみで利用したい
  • アクセス負荷の高いVPNは利用したくない

 

 

 

 

【リバースプロキシを中継してターゲットWebへアクセス

必要な機器構成

Azure AD  < OIDC >   リバースプロキシ      Web

  • Azure AD / OP
  • リバースプロキシ  / RP
  • ターゲットWeb

 

 

【OIDC対応リバースプロキシ / RP 】

今回は、OIDC認証やSAML認証に対応のリバースプロキシ・アプライアンス Powered BLUE ReverseProxy for SSO / IDaaS 」を利用します。

  • マルチドメイン・マルチサイトでのリバースプロキシの構築運用に対応
  • サイト毎にOIDC認証やSAML認証の異なるWeb認証での運用に対応
  • サイト毎に個別のサイト管理者に権限を委譲での運用に対応
  • リバースプロキシにはユーザーアカウント無しでの認証に対応
  • GUIからの設定の対応
  • 自社環境での運用に対応
  • アプライアンスでの‘提供
  • OS RockyLinux 8.x / RedHat 8.x に対応

 

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2022/08/pb-880-1.png

 

 

【構成図と設定概要】

    1. OP / RP の設定
      • 1.1. リバースプロキシ側(仮想サイトの作成)
      • 1.2. リバースプロキシの仮想サイトにOIDC認証を設定
      • 1.3. Azure ADにOIDC認証を設定
      • 1.4. 仮想サイトにリバースプロキシ先を設定
      • 1.5. 動作確認

 

 

【リバースプロキシ / RPの設定】

Powered BLUE ReverseProxy for SSO / IDaaS」での設定例です

OIDC認証やSAML認証に対応のリバースプロキシ機能を有したマルチドメインで運用できるアプライアンスです。

 

 

【仮想サイトの作成】

OIDC認証を設定するWebサイト 「www.example.jp」  を作成します。

 

認証として「OpenID Connect」を選択します

 

 

【Azure ADの設定】

https://www.mubit.co.jp/pb-blog/wp-content/uploads/2022/08/azure-ad-logo-1.png

 

Azure Active Directory」を選択

 

【アプリケーションの登録】

アプリの登録」を選択

 

 

【アプリケーションの新規登録】

+新規登録」を選択

 

【アプリケーションの名称設定】

例 keycloak-oidc (名称は適宜設定します)

登録」ボタンを押します

 

エンドポイント」を選択

 

OpenID Connect メタデータ ドキュメント」をコピーしてリバースプロキシ側へ登録します

 

Azureメタデータ」を選択します

 

 

 

【Azure ADからファイルの読み込み】

Azure メタデータ設定ファイルのインポート」の項にAzure AD側の

  • OpenID Connect メタデータ ドキュメント

のURLをペーストして「インポート」ボタンを押します

 

【データのインポート】

Azure AD側の情報が登録されます

リバースプロキシ側の「リダイレクトURI 」をコピーしてAzure ADの「リダイレクトURI」へに登録します。

 

【プラットフォームを追加】

+プラットフォームを追加」で選択します。

 

Webアプリケーション」を選択

 

リダイレクトURI」へ「リバースプロキシ側のリダイレクトURI」を登録します

構成」ボタンを押して、設定を保存します

 

【Azure AD】

アプリケーション(クライアント)ID」 をリバースプロキシ側の「クライアントID」の項に登録

 

 

証明書とシークレット」を選択

 

【シークレットの作成】

+新しいクライアントシークレット」を押す

 

  • 名称 適宜設定 例 for-keycloak-oidc
  • 有効期間 例 6ケ月
  • 追加」ボタンを押す

*クライアントシークレットの有効期間は重要です

 

 

【クライアント・シークレット】

Azure ADの「シークレットの値」を リバースプロキシ 側の「シークレット」の項に登録します

 

クライアントID」と「シークレット」に登録して「保存」ボタンを押します。

 

 

OIDCを有効にするに を入れて「保存ボタン」を押します

 

【認証ディレクトリ】

OIDC認証を適用するディレクトリを設定します

例 /test にOIDC認証とリバースプロキシを設定

  • https://www.example.jp/     認証なし
  • https://www.example.jp/test  に OIDC認証

 

【リバースプロキシを設定

仮想サイト www.example.jp へ「リバースプロキシ」を設定します。

 

リバースプロキシのパスを指定

  • アクセス元         /test
  • リダイレクト先 https://web.xyz.com/
  •  user     ⇒ https://www.example.jp/test    ⇒ https://www.xyz.com/

 

 

【Azure ADにログイン・ユーザー作成】

ここではAzure AD に新しいユーザーを作成します。

+新しいユーザー」を選択

 

アカウント

  • ユーザー名 keycloak-user
  • 姓 user
  • 名 keycloak
  • パスワード keycloak-test

* keycloak-user@tenant-name.onmicrosoft.com でE-mailアカウントが作成されます

 

【アクセス手順】

① https://www.example.jp/test にアクセス

② 初回は、Azure ADへリダイレクトされて認証を求められます

https://japan.zdnet.com/storage/2017/08/03/de5e58b6c73ae8f65bb4ce49490d6dce/newsigninpage.jpg

  • アカウント keycloak-user@tenant-name.onmicrosoft.com
  • パスワード keycloak-test

③ 認証後に https://www.example.jp/test 経由でリダイレクト先のWebページ

  • https://web.xyz.com/

が表示されます

 

 

 

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

SSOに対応していない ID / パスワード認証の「既存のWebサービス」を

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

SSOで運用する構成です

 

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

 

 

【 代理認証 】

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

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

 

 

【 代理認証の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でアクセスできます

 

 

 

 

 

 

 

 

 

 

【アプライアンスの簡単運用】

情シスの負担軽減での運用にも対応

  • サーバーの自己監視やサービスの自動再起動機能
  • パッチのスケジュールアップデート機能
  • 管理者への通知機能

 

 

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

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

 

 

【お問合せ】

 

 

 

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