SaaSの活用が進んでくると、一つの企業が
複数SaaSを利用する場面が必然的に生じて
きます。
その際に問題となるのが、運用ポリシーの
一貫性を如何に担保するか？という点です。
これは単にシングルサインオンによる認証
情報の一括管理だけでは解決しません。
どの社員がどの情報にどうアクセスできるのか？
をきちんと定めておき、それに基づいてSaaS活用を
進めていかないとセキュリティや内部統制の観点で
大きな問題となります。
とはいっても、各SaaSで設定できるアクセス管理の実装
は千差万別なので、個々のサービスをカスタマイズして
対処するのは現実的ではありません。かといって、自社
に権限管理サーバーのようなものを立てて、権限情報を
変換・中継する仕組みを作ったのではせっかくのSaaSの
コストメリットが帳消しになってしまいます。
そこで個人的に期待しているのがSAMLです。
簡単に言うと、アクセス権限情報を無理に統合するのではなく
アクセス権限管理の仕組みが個々のシステムで異なっている
ことを前提として、認証・認可情報を仲介するための約束事を
定義しようというものです。
この仲介される情報は「アサーション」と呼ばれ、ユーザーの
認証/属性/認可(アクセス権限)の各情報をXMLで記述します。
アサーションはIdP(Identity Provider)がユーザーのログイン
要求を受けて発行します。各サービスはSP(Service Provider)
と呼ばれ、発行されたアサーションを元にして自サービス内で
ユーザーに対して許可するアクセス権限レベル等を判断します。
つまり、アサーションの具体的解釈をSPに任せることによって
各サービス毎に異なるアクセス権限管理実装とユーザーが持つ
認可情報を切り離しているわけです。
SAMLは1.1までの仕様ではSP間の認証情報の紐付けをどうするか？
といった課題があったのですが、Liberty Allianceで策定された
ID-FFを取り込んだことで「アイデンティティフェデレーション」
の仕組みを備えるようになりました。
従来はSP間で認証情報の紐付けを行う場合には「IDは統一する」
などの制限を加えて、それを紐付けのキーにしたりするケースが
多かったと思います。(そこが実装上の大きな障害となっていた
面が大きいですが)SAML2.0では「Opaque Handle」というキーを
ランダムに生成し、それを紐付けに利用することでこの制限を
解消しています。
SAML2.0は各ベンダーやサービス提供会社の採用も徐々に進んで
きているようで、今後SaaSを提供する各社としてはSAML2.0準拠
のSPとしての対応が他社サービスとの連携という観点での1つの
キーポイントになってくるのではないかと予想しています。
また以前から言われている.NET Passport(将来はInfocard?) vs
Liberty Allianceの行く末や中立的もしくは独自の立場を取る
一部のベンダーやサービス提供会社がどう動くか？といった点も
合わせてウォッチしていく必要がありそうです。
もう一つ、複数のSaaSを活用する際の課題となるのがコンテンツの
串刺し検索です。SaaSで提供されるサービスが扱う情報は非定型・
非構造化のものが多いので、それらを効率的かつ網羅的に全文検索
できるかどうか？も重要なポイントになります。これについては別
のエントリで触れたいと思います。
