いまどきのシングルサインオン事情 (第1回 企業編)

この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

いまどきのシングルサインオン事情 (第1回 企業編)

エンドポイントセキュリティ 2013/06/04

 以前、弊社の担当者がキーマンズネットで連載させていただいた記事(これから覚えるシングルサインオン)では、シングルサインオンの概要と導入事例などを紹介した。今回はもう少し踏み込んで、最新のシングルサインオン動向や、シングルサインオンシステムを構築する際の注意点などについて4回にわたって解説する。動向というと、製品やサービスが実装している最新機能の紹介が多いが、今回はシングルサインオン製品/サービスを導入するユーザ側の動向について紹介したい。
 第1回目は、企業の最新のシングルサインオン動向について解説する。

企業向けシングルサインオンの動向

 まずは企業向けシングルサインオンシステムのよくある構成をご紹介しよう(図1)。弊社が企業向けに導入するシングルサインオンシステムでは、以下の図のような構成を取ることが多い。なお、この構成は弊社が提供しているオープンソースのシングルサインオンソフトウェアであるOpenAMを前提としたものだが、他のシングルサインオン製品でも同じような構成になるはずである。

図1.シングルサインオンのシステム構成例

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図1.シングルサインオンのシステム構成例

 企業向けシングルサインオンの最近の流行は、やはりクラウドサービスとの認証連携(フェデレーション)である。Google Apps、Salesforceは既に積極的に利用されているし、最近では「Office 365と認証連携したい」という声もよく聞くようになった。その一方で、やはり企業内にはオンプレミスなWebアプリケーションがまだまだ残っているという現実もある。

クラウドサービスへのシングルサインオン

 企業向けにサービスを提供しているクラウドサービスでは、シングルサインオンのためのプロトコルとして“SAML”を採用しているものが多い。
 SAMLは以前から多くのシングルサインオン製品で実装されているため、既に企業が導入しているシングルサインオン製品や、これから導入するシングルサインオン製品が、SAMLに対応している確立は高いと思われる。そのことが企業のクラウドサービス利用を促進している1つの要因でもあると筆者は考えている。

 つい最近、オンラインストレージサービスの米Dropboxが、企業向けサービスにシングルサインオン機能を追加し、シングルサインオンのプロトコルとしてSAMLを採用するという発表があった。クラウドにおけるシングルサインオンプロトコルの流行は“OAuth2.0”や“OpenID Connect”であるため、クラウドサービスの最先端を走るDropboxがあえて今SAMLを採用したということに驚きを感じた読者もいるのではないだろうか。しかし、今現在、企業に最も浸透しているシングルサインオンプロトコルはおそらくSAMLであり、そのことを考慮すれば、DropboxのSAML採用の判断は企業ユーザの獲得を狙った非常にしたたかなものであると考えることもできる。

なくならないオンプレミスアプリ

 クラウドの利用が進んでいる一方で、やはり企業内にはオンプレミスなWebアプリケーションが存在している。オンプレミスなWebアプリケーションをシングルサインオン環境に組み込むためには、以下のような理由から「リバースプロキシ方式」を採用することが多い。リバースプロキシ方式については、以前の連載記事(シングルサインオンの認証、認可、連携)や、キーマンズネットの過去の記事でも何度も解説されているので、そちらを参照して頂きたい。

 *

シングルサインオン対応するための改修をアプリケーションに対して実施することができない

 *

アプリケーションに対するユーザのアクセスを細かな条件で制御したい(認可を行いたい)

 既存のアプリケーションをシングルサインオン環境に組み込む場合は改修が必要となることもあるが、オンプレミスなWebアプリケーションは費用や工数の面から改修できない場合が多い。このような場合は、リバースプロキシ方式のようにWebアプリケーションの改修を必要としない方式を採用せざるを得ない。

 アプリケーションの改修が可能な場合は、フェデレーションに対応させるという選択肢も考えられる。しかし、認証後の認可まで標準的なプロトコルで行う場合は、実装コストが増加してしまうこともある。例えば、認可のためのプロトコルとして“XACML”という仕様が策定されているが、Webアプリケーションの認可に関わる処理を全てXACMLに対応させるためのコストは大きくなることが予想され、筆者が知る限りは実際に採用されている例も少ない。

 そのため、改修のコストと新たにリバースプロキシを導入するコストを天秤にかけた結果、リバースプロキシを採用することが多い。改修不可能なWebアプリケーションが複数存在する場合でもリバースプロキシであれば対応可能であることから、「とりえあずオンプレのアプリはリバースプロキシで」となることが多い。

 次回は文教分野(主に大学)における動向を解説する。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30006199


IT・IT製品TOP > Key Conductors > 野村 健太郎(オープンソース・ソリューション・テクノロジ株式会社 ) > いまどきのシングルサインオン事情 (第1回 企業編)

このページの先頭へ

キーマンズネットとは
Open Standard Cloud Association(OSCA)所属。某SIerでのID管理/アクセス管理製品のプリセールスを経て、2009年にOSSTechに入社。オープンソースソフトウェアであるOpenAMやOpenLDAPを利用したシングルサインオンシステムの構築を担当している。

ページトップへ