NTT communications が運用するOpenStackのクラウド基盤である、
SDPF クラウド/サーバー（旧 Enterprise Cloud）上にSAML認証対応のリバースプロキシサーバーを構築します。
IDaaS/idPのAzure ADを利用して、テレワークで社内LAN側に設置のWebサーバーにSAML2.0対応のSP機能を持つリバースプロキシ/Reverse Proxy経由でアクセスする場合の構成です。
SP/リバースプロキシの冗長化による負荷分散やマルチリージョン(マルチAZ)での運用も可能です。
NTT communications 社のSDPF クラウド/サーバー での構築
SAML認証対応のリバースプロキシとしては、「Powered BLUE Reverse Proxy for SSO/IDaaS」
を利用します。SDPF クラウド/サーバー環境で構築する方法は
Enterprise CloudにCentOS/RedHat対応Powered BLUEをセットアップ する
を参照してください
Azure AD 連携
Azure AD のSAML認証機能とSAML認証に対応のリバースプロキシのみを利用します。またAzure ADの認証とは別にSP/リバースプロキシ上でSSLクライアント認証などの独自の認証を設定することができます。
- idP / Azure AD
- SP / SAML対応リバースプロキシ
ゼロトラスト対応
SAML認証対応のリバースプロキシは、「ID認識型リバースプロキシ」として動作します
idPと連携するゼロトラストでの運用となります
ID管理や端末のアクセス設定などのゼロトラスト関連の事項は、すべてidP/Azure AD側で設定をします
Azure AD アプリケーションプロキシとは異なり
- エージェントは不要
- ターゲットネットワーク側のプロキシコネクタは不要
のため、「idP」と「ID認識型リバースプロキシ」のみで導入が出来ます。またエージェントなどが不要のためリバース先のWebサイトのOSなどに制約はありません（任意のOSに対応）
リモートワーク＆ブラウザ
リモートワーク時の社内Webへのアクセスに際して、モバイル用の閉域網やVPN、専用のエージェントなどは不要です。ユーザーはブラウザのみで利用できます。
idP(アイデンティティ・プロバイダ）
idPとしてはSAML2.0に対応した Azure ADの他、TrustLogin、G suiteやCloudGate UNO、HENNGE ONE(旧HDE ONE)、OneLogin、Okta等のIDaaSなどや、OpenAM、Keycloakなどと連携が出来ます。
ID認識型リバースプロキシ
SPとしては、SAML2.0に対応した「ID認識型リバースプロキシ」機能を持つ「Powered BLUE Reverse Proxy for SSO/IDaaS」を利用します。
この製品は
- SAML2.0対応のWeb&リバースプロキシ機能
- Web/Mail/DNS/ftp（インターネットサーバー機能）
- Let’s Encrypt （フリープラグインで提供）
- 仮想アプライアンス
- SSLクライアント認証
- ワンタイムパスワード認証
- ひとり情シスでの運用に対応
のリバースプロキシ・アプライアンスです。CentOSやRedHatに対応しておりAzure / AWSなどのクラウド環境や、VMware / Hyper-Vなどの仮想環境でオールインワンで運用することが出来ます。
自社で運用出来るリバースプロキシでは、idPの認証の他にリバースプロキシ独自で、SSLクライアント認証やワンタイムパスワード認証を設定することが可能です。社内LAN側へのアクセスに際して自社のポリシーを個別に適用したい場合などには有効です。
ユーザーアカウント不要
SP側のリバースプロキシサーバーにはユーザーアカウントを作成することなくidP/Azure ADによるSAML認証を行い、内部のWebサーバーへ中継させることが出来ます。またグループアクセスでのコントロールに対応しています。
グループアクセスコントロール 例
- 営業部・開発部・支店のみにアクセスを許可
- 管理職のみにアクセスを許可
- 社員・会員・代理店のみにアクセスを許可
SP側のリバースプロキシにはユーザーアカウントがないため、SP側のリバースプロキシからのアカウント漏洩の心配はありません。またアカウントがないので運用が簡単です。
SP（サービス・プロバイダ）
「Powered BLUE Reverse Proxy for SSO/IDaaS」をSAML2.0のSP（サービスプロバイダ）として設定します
SAML2.0の設定例
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アプリケーションを利用出来る、ユーザーやグループを割り当てます
- アプリケーションのサイドバーで、 [ユーザーとグループ] を選択します。 [<アプリケーション名> – ユーザーとグループ] ページが表示され、割り当てられたユーザーとグループの現在の一覧が示されます。
- [ユーザーの追加] を選択します。 [割り当ての追加] ページが表示されます。
- [ユーザーとグループ] (選択した <数>) を選択します。 [ユーザーとグループ] ページが表示され、使用可能なユーザーとグループの一覧が示されます。
- 一覧から割り当てるユーザーまたはグループを入力するか、スクロールして見つけます。
- 追加する各ユーザーまたはグループを選択し、 [選択] ボタンを選択します。 [ユーザーとグループ] ページは表示されなくなります。
- [割り当ての追加] ページで [割り当て] を選択します。 [ – ユーザーとグループ] ページが表示され、追加ユーザーが一覧に示されます。
シングルサインオンでの認証のステップ
① ID認識型リバースプロキシへアクセス
② 初回のみ idP へアクセス ( シングルサインオン ）
③ idPの認証後にリバースプロキシ先のWebサイトの表示
* SP initiated SAML および idP initiated SAMLに対応
アクセス
https://wp-sam.mubit.jp/develop-dep/
初回
シングルサインオンでは、一度 idP/Azure AD へのログイン
ターゲットのwebページ
SAML認証後に設定のターゲットのWebページが表示されます
sharepointへ
WordPressへ
WebMailへ
ビジネスチャットMattermostへ
SSO/SAML認証対応のアプリ
SAML認証対応の各種アプリとシングルサインオンでアクセスができます。
多要素認証
idP側の認証とは別に、「Powered BLUE Web for SSO / IDaaS」のSP上で単独で
- SSLクライアント認証
- ワンタイムパスワード認証
を設定して運用する事が出来ます
社内Webサイトへのアクセスに際して、IDaaS側の認証に加えて自社で運用出来るリバースプロキシに自社のポリシーに準じた認証を別途設定したい場合には有効です。
SSLクライアント認証
SP上でPrivate CAを運用 SSLクライアント証明書を発行してSSLクライアント認証によるアクセスコントロールが出来ます。
OTP/ワンタイムパスワード認証
SP/リバースプロキシの冗長構成
SP側のリバースプロキシを2重化して、シングルサインオン/SAML認証でのアクセスを分散させる冗長構成にも対応しています。
HA構成
ロードバランサーでの負荷分散
シングルAZ + ロードバランサー
マルチAZでの運用構成
GSLBやRoute53などを利用してのマルチAZでの運用に対応
異なるアベイラビリティゾーンでの運用により耐障害性の向上
- リージョンA / 東日本データセンター
- リージョンB / 西日本データセンター
クラウドやWAN側に設置のWebの認証を強化
認証対応のリバースプロキシ経由でのみWebへアクセスする運用で、セキュリティを確保します
idPの費用を抑えたい場合
IdPの費用を抑えてSAML認証で運用したい場合には、Azure ADと同様の機能を持ち、idPの基本機能は無料で利用出来るGMOグローバルサイン社のIDaaSサービス「TrustLogin」を使うことも出来ます。