CRMやBI、SaaSにも使える「安全な器」
ID連携が実現されることで、結果としてSSOやユーザーの属性交換が可能になる。SSOによってユーザーの利便性が高められ、SSOでログインした後で、住所や年齢といった個人情報を安全に各種サービスへと引き渡すことが可能になる。同事業グループ セキュリティ基盤事業ユニットの永野一郎氏は、TrustBindを「何にでも使える安全な器」に喩える。
「TrustBindは何にでも使える安全な器だ」と永野氏「SAMLの仕様は非常に柔軟にできているので、使おうと思えばCRMやBI、SaaS（Software as a Service）にも使える。SAMLは、今使えるテクノロジーを用いて新しいサービスを提供したいと考える企業に利用される可能性が一番高い仕様だ」
SaaSにおいてSAMLを利用する場合、SaaSのプロトコルにSAMLのプロトコルを埋め込む形になる。例えば、いったんサイトAにログインした後、サイトBに移行すると、SAMLのプロトコルを使って認証連携が行われる。その中にユーザーの属性情報やセッション情報も埋め込むことにより、サイトAで提供されたサービスがサイトBに引き継がれる。
「もともとLibertyやSAMLの仕様は、SSOがメインのターゲットではなくWebサービスのための基盤だ。つまり、SSOだけではなくWebサービスの発展に寄与する仕様となっている」（久米田氏）
確かに、Liberty Allianceが発足当時に提示した活用イメージは、サービスとサービスが連携したWebサービスだった。当時のイメージは、コンサートのチケットを予約すると、コンサート会場に近いホテルやレンタカーの予約ができ、ユーザーの属性に合わせた情報が届くようになるといった具合で、サービス提供者が連携することにより、ユーザーの利便性を高めるという提案だった。サービス同士が連携するWebサービスにおいてID管理をどうするか。その解を導き出したのがLiberty Allianceであった。
実際に交換されるのは特殊な文字列
ただ、一般のユーザーにはSSOのメリットしか見えてこないため「すべてのサイトで同じIDやパスワードを使えばいいじゃないか」と思ってしまいがちだ。しかし、それは極めて危険な判断と言える。また、Webサービスが注目された当時最も心配されたのが、ユーザーが知らないところでWebサイト同士が勝手に連携し、ユーザーの属性情報を無断で交換し始めること。特定のサービス提供者だけにユーザー情報が集中し独占されてしまうのではないかといったことだった。
永野氏は、「LibertyやSAMLのターゲットは安全なIDの連携にある。結果としてユーザー情報の交換もできれば、サービス同士の連携も可能になる。ウェブの上で何らかのサービスを提供しようとするとき、必ず必要となる基盤だ」と解説する。
例えば、企業買収などで企業間をつなぐとき、システムをつくり直すのではなく、ID連携の仕組みを活用して外側のインターフェースだけに手を加えて連携させることができる。もちろん、同一システムに統一することも選択肢ではあるが、統合される側のユーザーのアカウントを移行させなければならない。その際、アカウントに重複がでた場合どう調整するかといった問題もあり、かなり手間のかかる作業となる。久米田氏も「IDの連携型モデルを使えるのであれば、ユーザーが使い慣れたサイトにログインして、そのまま連携される方が良いはず」と述べる。
ここで一般ユーザーのために説明を加えておくと、Liberty Allianceの仕様は、構成上ウェブサイト間において、お互いのユーザーのIDやパスワードは知らせないプロトコルになっている。実際に交換されるのは特殊な文字列であるため安全なのだ。また、メッセージング仕様においても、SAMLはXMLの暗号化やSSL、署名といった既存のセキュリティ標準に準拠しており、それらを組み合わせることで安全性を確保している。
こうした基盤を活用したいと考える企業は、SAMLのプロトコルを自社のウェブサイトに組み込むときに注意すべき点があると永野氏は指摘する。SAMLのシーケンスがサイトのシーケンスに食い込む部分があるからだ。「サイトによって追加が必要なシーケンスが異なるため、連携する事業者間での調整が必要となる場合もある」と説明する。この辺りの構築にはノウハウが必要となるのだろう。
