|
<< Click to Display Table of Contents >> Navigation: システム設定（管理者マニュアル） > セキュリティ設定 > SAML 連携について |
FileBlogのSAML連携機能を使用するには以下2つの要件をみたすことが必要です。
•Active Directoryの環境でFileBlogサーバーがドメイン参加している
oFileBlogサーバーのネットワークドライブを検索対象にする場合、Active Directoryで委任許可がの設定が必要です
•Active Directoryのユーザーアカウントと一致する情報が、SAML認証を提供するIdP （ID Provider）側に登録されていることが必要です
SAML（＝Security Assertion Markup Language）とは、複数のWebサービスがシングルサインオン連携するための標準通信プロトコルです。
企業内に複数のシステムが立ち上がっている場合、それぞれのシステムに個別にログイン画面があって、毎回ログインするというのが、シングルサインオン以前の状態でした。
しかし、何度もログインするのは面倒であり、ID/パスワードを入力する回数が増えると、パスワード漏洩の危険も高まります。
そこで、一度どこか（IdP=Id Provider）でログインしたら、個別のシステム（SP=Service Provider）にはログインを求められず、自動ログインできる仕組みである「シングルサイン」機能が求められるようになりました。
特に近年は、インターネット上で稼働する複数のクラウドサービスを連係利用するユーザが増え、インターネット越しに安全に利用できるシングルサインオンの仕組みが必要になりました。
そこで標準的に使われる（IdPとSPの間での情報交換）プロトコルがSAMLです。
例えば、Microsoft365の各アプリケーション（Outlook/Share Point/One Drive/Teamsなど）の認証はSAMLに基づいて連動しているため、一度Microsoftアカウントでログインすれば、アプリケーションを切り替えてもログインを求められることはありません。
クラウド上での認証を提供するIdP （ID Provider）は様々に存在しますが、2020年夏現在、日本国内で比較的存在感のあるプロバイダとして、鉄飛では下記の二つのIdPとの組み合わせで動作検証を行いました。
•ひとつは、Microsoft 365 サービスの 認証基盤である、マイクロソフトの Azure Adです。Microsoft 365 サブスクリプションを契約し、outlook.com のWebメールシステムを利用しているお客様は、日常的に Azure AD でユーザ認証を行っていることになります。
•もうひとつは、GMOグローバルサインのTrustLogin （ https://trustlogin.com/ ）です。
oAzure ADがMicrosoft 365サブスクリプションと密接な包括的サブスクリプションであるのと異なり、認証サービス単体で比較的安価に提供されていることから、動作検証対象製品リストに加えました。Azure ADの全社導入に踏み切るには運用体制上・費用面で問題がある、という場合のオプションとなりうると考えます。
上記以外の各社Idpについても導入済み製品をお知らせいただければ動作検証を実施します。検証にはお客様とプロバイダーの両者のご協力が不可欠であり、期間を要することもあります。また、オンプレミスのIdp製品について検証環境を構築できないこともあります。