1回のログオン操作で複数の異なるサーバーにアクセス可能になるシングル・サインオン(SSO)。そのSSO製品が新たな機能を備え始めた。異なるWebサイト間でのシングル・サインオンを可能にするアフィリエート機能である。BtoC(企業対個人)向けEC(電子商取引)とBtoB(企業間)向けECサイトを連携させたりする場合に,ユーザー認証処理を効率化できるうえ,エンドユーザーの利便性を向上させられる。

(河井 保博=kawai@nikkeibp.co.jp)

 Webアプリケーションに特化したシングル・サインオン(SSO)製品に新機能の実装が進んでいる。アフィリエート(提携)機能と呼ばれるもので,一企業のWebサーバー群だけでなく,外部のWebサイトもシングル・サインオンの対象に組み込む機能である。

 例えば,ネットマークスが2001年2月中にも出荷を始める米ネテグリティの「SiteMinder 4.6i」,日本ヒューレット・パッカード(日本HP)が1月に発売した「IceWall」などが,アフィリエート機能を備える。また,米エンコマースの「getAccess」も,2000年10月に国内で発売されたバージョン4.0Jから,アフィリエート機能をサポートしている。

 この機能を使うと,企業間取引やインターネット・マーケットプレイス,個人向けECサイト間の連携といった場面で,ユーザー認証やアクセス制御の処理を効率化できる。さらに言えば,エンドユーザーに対しての利便性向上にもつながる。日本エンコマースのセールス・リプリゼンタティブである紺木 孝之氏は,「すでに国内のECサイトなどで導入が始まっている」と言う。

サービス間連携が容易に

 シングル・サインオンは,1回のログオン処理だけで複数の異なるシステムにアクセスできるようにする仕組み。ユーザーの属性情報と各システムへのアクセス権限を一元的に管理する。ただ,従来のシングル・サインオン製品は,一企業のシステムだけが対象だった。シングル・サインオンを実現する際には,ユーザーとアクセス権限を識別するためにクッキー(Cookie)などの手法を利用するが,その手法は基本的にドメイン内でしか有効でないためである。クッキーは,発行元のドメインのシステムにアクセスする場合以外には利用できない。

 そこで考えられたのがアフィリエート機能である。シングル・サインオン・ツールがユーザーに代わってほかのサイトにユーザー情報を提供し,バックグラウンドでログオン処理を実行してくれる。例えばECサイトと宅配便のWebサイトで,あるECサイトが発送した商品を,宅配便のサイトでトラッキングできるサービスを提供するとしよう。ECサイトの会員情報を宅配便サイトが参照できれば,ユーザーに繰り返しログオン処理を要求せずに済むようになる。システム的な観点で言えば,それぞれのWebコンテンツにはほとんど手を加えずに,容易にサービスを連携させられる。同様に,Webベースで企業間取引する場合やインターネット・マーケットプレイス同士を相互接続する場合などにも適用できる。

図1●アフィリエート機能を実現する場合のユーザー認証の流れ
図は米ネテグリティのSiteMinderを利用した場合。いったんポータルとなるサイトにログオンして,クッキーAを発行してもらっておくことが前提。提携サイト,ポータル,ブラウザの間でURLに情報を埋め込みながらリダイレクトを繰り返すことで,背後でログオン処理を実行する。ユーザーにはURLが変化するだけで,ログオン処理は見えない。

URLにユーザー情報を埋め込む

 では,実際にどういう仕組みでアフィリエート機能が実現されているか,SiteMinderの動作を例に見てみよう。パラメータの内容など細かな部分に違いはあるが,getAccessもおおまかな動作は同じである。

 わかりやすくするために,シングル・サインオン製品を導入し,ユーザー情報やアクセス制御情報を管理するサイトをポータル・サイト,連携するサイトを提携サイトと呼ぶことにする。ポータル・サイトのWebサーバーには,セッションを管理するWebエージェントをインストールしておく。同時に,ユーザー属性やアクセス権限などの情報を登録したポリシー・サーバーを設置しておく必要がある。一方,提携サイトのWebサーバーには,アフィリエート・エージェントと呼ぶソフトを搭載しておく。ここで,ユーザーはいったんポータル・サイトにログオンしているとする。

 SiteMinderの場合,ポータル・サイトと提携サイトは,ブラウザのURL(ユニフォーム・リソース・ロケータ)に組み込む専用のパラメータを利用し,Webエージェントとアフィリエート・エージェントが間接的に通信してユーザー情報をやり取りする(図1[拡大表示])。

 ユーザーが提携サイトに初めてアクセスする時点では,ユーザーを識別できない。ポータル・サイトのクッキーは,ドメイン名が異なる提携サイトへは送信されないからだ。そこで提携サイトは,アクセス要求をポータルのWebサイトにリダイレクトする。アフィリエート・エージェントが,ブラウザに対して,ポータル・サイトのURLを返信するのである。ポイントはここだ。ブラウザに返信するポータル・サイトのURLに,SMPROFILEというパラメータを添付する。SMPROFILEは,ユーザー情報を要求するメッセージや,応答となる情報を埋め込むためのパラメータ。ここでは,アフィリエート・エージェントは「SMPROFILE=要求」と設定する。

 ブラウザはこのURLをもとに自動的にポータル・サイトにアクセスする。この際,ポータル・サイトでは,ポータル・サイトにログオンした際に発行したクッキーAをもとにユーザーを識別する。Webエージェントは,そのユーザーの属性をポリシー・サーバーに問い合わせ,データを抽出。暗号化してSMPROFILEパラメータに埋め込み,提携サイトのURLに添付してユーザーに返信する。つまり,Webブラウザから見ると,再度,提携サイトにリダイレクトされることになる。

 こうして再度提携サイトにアクセスすると,アフィリエート・エージェントはSMPROFILEパラメータからユーザー情報を抽出してログオン処理を実行し,ユーザーに向けて提携サイト用のクッキーBを発行する。

 一連の処理が実行される間,ユーザーにはログオン処理はまったく見えない。エージェント間でやり取りするユーザー情報はすべて暗号化されているため,ユーザー情報が漏えいする危険性は低い。また,ブラウザを経由させるため,ファイアウォールが介在しても,ファイアウォールの設定を変更する必要はない。

図2●日本HPのIceWallのアフィリエート機能
IceWallはリバース・プロキシとして動作するシングル・サインオン製品。このため,提携サイトとの通信もプロキシ経由になる。IceWallにログオンしていれば,プロキシが動作する際に提携サイトとの認証を自動実行するため,ユーザーにはシングル・サインオンに見える。提携サイトに対するユーザーIDなどはあらかじめIceWallに登録しておく。

リバース・プロキシはログオンを代行

 日本HPのIceWallは,ほかの2製品とはアフィリエート機能の実現手法が違っている。製品の仕組みそのものが異なるからだ。

 getAccessやSiteMinderは,Webサーバー上に搭載するエージェント・ソフトとポリシー・サーバーで構成される,いわゆるエージェント型である。これに対して,IceWallはリバース・プロキシ型。エージェント・ソフトは使わず,すべてのアクセスをIceWallが受け付けて各Webサーバーとの通信を代行する。このプロキシがユーザーの属性情報を管理し,ユーザーの代わりにログオン/認証処理を自動実行してくれるのである(図2[拡大表示])。

 IceWallを導入したポータル・サイトwww.icewall.co.jpと,提携サイトのmro.nikkeibp.co.jpがあるとしよう。アクセス制限がかかるリソースはmro.nikkeibp.co.jp/xxxxである。

 ユーザーがIceWallにいったんログオンすると,IceWallは,ユーザーに対してアクセス可能なリソースの一覧を表示したWebページを返す。ここで,提携サイトのリソースは,www.icewall.co.jp/mro/xxxxというようにIceWallを導入しているWebサイトのサブディレクトリにしか見えない。

 ただ,このリンクを選んで提携サイトにアクセスしても,www.icewall.co.jpが発行したクッキーはnikkeibp.co.jpというドメインでは使えないため,提携サイトはユーザーを識別できない。そこで,提携サイトはユーザーにログオン操作を要求する。

 ここで,IceWallがこのログオン要求を受け取る。IceWallはすでにユーザーを認証済みで,かつ,このユーザーのセッションを管理しているため,ユーザーを識別できる。内蔵するポリシー・データベースから対象となるユーザーの属性情報を抽出し,ログオン処理を自動実行する。提携サイトはログオン処理を完了すると,改めてクッキーを発行。IceWallはこのクッキーのドメイン属性などの情報をwww.icewall.co.jp用に変換し,ユーザー(ブラウザ)に中継する。これ以降,ユーザーはこのクッキーを使って提携サイトにアクセスできる。また,URLとしてwww.icewall.co.jp/mro/xxxxと入力すれば,リソース一覧からでなくても提携サイトにアクセスできる。