IDaaS/idPのAzure ADを利用して、テレワークで社内LAN側に設置のWebサーバーにSAML2.0対応のSP機能を持つリバースプロキシ/Reverse Proxy経由でアクセスする場合の構成です。Azure AD アプリケーションプロキシは使用しません。

SP/リバースプロキシの冗長化による負荷分散やマルチリージョン(マルチAZ)での運用も可能です。

Azure AD アプリケーションプロキシの未利用

Azure AD のSAML認証機能とSAML認証に対応のリバースプロキシのみを利用します。Azure AD アプリケーションプロキシは使用しないため、Windows環境に依存しない汎用的なWebサーバーへのアクセスをターゲットとした構成が組めます。またAzure ADの認証とは別にSP/リバースプロキシ上でSSLクライアント認証などの独自の認証を設定することができます。

idP / Azure AD
SP / SAMLやOIDC対応リバースプロキシ

Webの改修不要＆ゼロトラスト対応

SAML認証対応のリバースプロキシは、「ID認識型リバースプロキシ」として動作します

idPと連携するゼロトラストでの運用となります

Azure AD アプリケーションプロキシとは異なり

エージェントは不要
ターゲットネットワーク側のプロキシコネクタは不要
ターゲットWebの改修は不要でSSO
ターゲットWebのOSは不問
ブラウザのみで利用（プラグイン不要）

のため、「idP」と「ID認識型リバースプロキシ」のみで導入が出来ます。

idP(アイデンティティ・プロバイダ）

idPとしてはSAMLやOIDC認証に対応した　Azure ADの他、TrustLogin、G suiteやCloudGate UNO、HENNGE ONE(旧HDE ONE)、OneLogin、Okta等のIDaaSなどや、OpenAM、Keycloakなどと連携が出来ます。

ID認識型リバースプロキシ

SPとしては、SAML/OIDC認証に対応した「ID認識型リバースプロキシ」機能を持つ「Powered BLUE Reverse Proxy for SSO/IDaaS」を利用します。

この製品は

SAMLやOIDC認証対応のリバースプロキシ機能
代理認証方式でのSSO
HTTPヘッダー方式でのSSO
Web/Mail/DNS/ftp（インターネットサーバー機能）
Let’s Encrypt （フリープラグインで提供）
仮想アプライアンス
SSLクライアント認証
ひとり情シスでの運用に対応

のリバースプロキシ・アプライアンスです。RockyLinuxやRedHatに対応しておりAzure / AWSなどのクラウド環境や、VMware / Hyper-Vなどの仮想環境でオールインワンで運用することが出来ます。

自社で運用出来るリバースプロキシでは、idPの認証の他にリバースプロキシ独自で、SSLクライアント認証を設定することが可能です。社内LAN側へのアクセスに際して自社のポリシーを個別に適用したい場合などには有効です。

SP（サービス・プロバイダ）

「Powered BLUE Reverse Proxy for SSO/IDaaS」をSAMLのSP（サービスプロバイダ）として設定します

SAMLの設定例

http://wp-sam.mubit.jp/　以下の指定ディレクトリにSAML2.0の認証を設定する例です

idP 「Azure AD」
SP 「Powered BLUE Reverse Proxy for SSO/IDaaS」

を利用します。

idPとSPにそれぞれ、SAML認証の設定を行います。

構成例

ID認識型リバースプロキシでの設定例です

SAML/SP リバースプロキシのWebサイト

例　https://wp-sam.mubit.jp

リバースプロキシ上でSAML2.0の認証を行います
SAML認証後に、リバースプロキシにより指定のサイトへリダイレクトさせます

例　社内のSharePointへアクセス

例　社内のWeb Mailへアクセス

ネットワーク構成

ブログのサイトへリレイ

idP –>> SP (Reverse Proxy )https://wp-sam.mubit.jp/blog –>> https://sni-1.mubit.jp/blog/

Webメールのサイトへリレイ

idP ⇒ SP (Reverse Proxy )https://wp-sam.mubit.jp/webmail/ ⇒ https://sni-1.mubit.jp/webmail/

設定構成

以下のようなリバースプロキシ構成での設定例です

例　User ⇒ https://wp-sam.mubit.jp/blog ⇒ https://sni-1.mubit.jp/blog/

例　User –>> https://wp-sam.mubit.jp/webmail/ –>> https://sni-1.mubit.jp/webmail/

SP側の設定

Powered BLUE Reverse Proxy for SSO/IDaaSにリバースプロキシを運用する仮想サイトを作成

例　http://wp-sam.mubit.jp

Webサーバの有効化

Webサーバーを有効にする　にチェックを入れます

仮想サイトのSSL化

リバースプロキシを運用するWebサイトのSSL化を行ないます。SAML認証に際しては、WebサイトのSSL化が必須です。

SSLのサーバー証明書としては

サイトのSSL自己証明
パブリックなSSLサーバー証明書
Let’s EncryptでのSSLサーバー証明書

に対応しています。

WebサイトのSSL自己証明の場合

SSLを有効にする　にチェックを入れます

パブリックなSSLサーバー証明書の場合

必要情報を記載して「署名リクエストの作成」ボタンで作成したテキストを、SSLサーバー証明書を発行する機関へ送付します。

「署名リクエストの作成」でファイルを保存
作成された「署名リクエスト」　ファイル　signig-request.txt を、公的なSSLサーバー証明書の発行機関へ送付

公的機関で発行された、サーバー証明書を　「インポート」　します
中間証明書のインポートにも対応しています

SSLサーバー証明書が発行されたら「インポート」ボタン操作でSSLサーバー証明書をインポートします

Let’s Encryptの場合

フリープラグイン機能を利用して、Let’s Encryptプログラムをインポートします

FreeSSLを選択

「インストール」　ボタンをクリック

Let’s Encryptインストール後に　「有効にする」　にチェックを入れます

リバースプロキシ

作成した仮想サイトにリバースプロキシを設定します

例　https://wp-sam.mubit.jp/blog/ —-> https://sni-1.mubit.jp/blog/

例　 https://wp-sam.mubit.jp/webmail/—> http://sni-1.mubit.jp/webmail/

SAML2.0設定

SAMLのエンドポイントを指定します　　例　/

idP側のxmlのメタデータをSPへインポートします

idP側のxmlのメタデータをインポートします

SP側のxmlのメタデータをダウンロードします

idP側で作成のメタデータ（xml）をアップロードします

SAML2.0の認証をかけたいdirを指定します

例　/blog

https://wp-sam.mubt.jp/blog/ 　にSAML認証が適用されます

グループアクセスでのコントロールが不要の場合には、SP側はここまでの設定です。

https://wp-sam.mubt.jp/webmail/ 　　にSAML認証を適用させる場合も、同様の設定を行います

attributeの指定

グループでのリバースプロキシへのアクセスコントロールを行なう場合に、attributeを追加で設定します

それぞれのパスに対して、idP側で設定の　attribute-value　もしくは　ロール　の指定が出来ます

部門毎やグループ毎などにリバースプロキシへのアクセスコントロールを行ないたい場合には、便利な機能です。

例　営業部・開発部・総務部はidPでリバースプロキシへのアクセスを許可する
例　特定の役職以上はリバースプロキシへのアクセスを許可する

attribute=”groups” value=” mbt” でのアクセスを許可の場合の設定例

samlの有効化

設定のSAMLを有効にします

idPの設定

idP/IDaaSでSAML2.0をサポートしていれば、Powered BLUE Web for SSO/IDaaSと接続が出来ます。

今回はidPとしてAzure ADを利用します

Azure AD の前提条件

Azure AD Premium

エンタープライズアプリケーションブレード

自社独自のSAMLベースWebを登録の場合には、[エンタープライズアプリケーション] ブレードを使用して、アプリケーションを Microsoft ID プラットフォームに接続します。

お使いの Microsoft ID プラットフォーム管理者アカウントを使用して、Azure Active Directory ポータルにサインインします。
Azure Active Directory を選択
[エンタープライズアプリケーション] > [新しいアプリケーション] の順に選択します。
(省略可能だが推奨) [ギャラリーから追加する] 検索ボックスに、アプリケーションの表示名を入力します。検索結果にアプリケーションが表示されたら、それを選択し、この手順の残りをスキップします。
[ギャラリー以外のアプリケーション] を選択します。 [独自のアプリケーションの追加] ページが表示されます。

新しいアプリケーションの表示名を入力します。
[追加] を選択します。

この方法でアプリケーションを追加することにより、事前に統合されたアプリケーションに似たエクスペリエンスを提供します。まず、アプリケーションのサイドバーから、 [シングルサインオン] を選択します。次の画面 ( [シングルサインオン方式の選択] ) は、SSO を構成するためのオプションを示しています。

SAMLを選択

① 基本的なSAML構成を選択

idp側のxmlを読み込み

メタデータファイルをクリック

idPに読み込むメタデータファイルの指定（SP側のxmlファイル）

もしくは、以下の項目をxmlの内容に沿って記述します

Azure AD SAML の設定例

SAMLの項目

SP側のxmlの内容に従って、以下の項目を設定します。SP側のxmlファイルのアップロードでの登録も出来ます。

エンティティID

https://wp-sam.mubit.jp/endpoint/metadata

応答URL (Assertion Consumer Service URL )

https://wp-sam.mubit.jp/endpoint/postResponse

サインオンURL

https://twp-sam.mubit.jp/develop-dep/

リレー状態

空欄でも可能

ログアウトURL

空欄でも可能

② ユーザー属性とクレーム

必要に応じて設定

③ SAML署名

idP/Azure AD側のフェデレーションメタデータ(XML)をダウンロードして、SP側に登録します

グループアクセスコントロールが不要の場合には、ここまでの設定となります

Validate

idPおよびSP側の設定が正しければ、「Validate]　ボタンをクリックすると　SP側のWebページが表示されます。

例　現在のユーザーとしてサインイン

エラーが表示される場合には、メッセージをコピーします

エラーが表示される場合には、メッセージをクリップボードに貼り付けると修正方法が、サジェスチョンされます

エラーを適宜修正して、正常にアクセス出来ればセットアップは終了です。

SAMLアプリケーションにユーザーとグループのアサイン

作成したSAMLアプリケーションを利用出来る、ユーザーやグループを割り当てます

アプリケーションのサイドバーで、 [ユーザーとグループ] を選択します。 [<アプリケーション名> – ユーザーとグループ] ページが表示され、割り当てられたユーザーとグループの現在の一覧が示されます。
[ユーザーの追加] を選択します。 [割り当ての追加] ページが表示されます。
[ユーザーとグループ] (選択した <数>) を選択します。 [ユーザーとグループ] ページが表示され、使用可能なユーザーとグループの一覧が示されます。
一覧から割り当てるユーザーまたはグループを入力するか、スクロールして見つけます。
追加する各ユーザーまたはグループを選択し、 [選択] ボタンを選択します。 [ユーザーとグループ] ページは表示されなくなります。
[割り当ての追加] ページで [割り当て] を選択します。 [ – ユーザーとグループ] ページが表示され、追加ユーザーが一覧に示されます。