Webサービスをe-Commerceシングル・サインインに使用する

分散コンピューターのSOAP認証

Webアプリケーション・ユーザーは、Webサイトを使用する際、シームレスな統合とインターオペラビリティーを期待します。しかし、このサイトを動かしているバックエンド・システムは、個々のサーバー・ソフトウェア・パッケージの集まりです。このケース・スタディーでは、皆さんにシングル・サインインを体験していただくために、Webサービスを使用して、エレクトロニック・カスタマー・リレーションシップ・マネージメント (eCRM) アプリケーションを既存のe-Commerceマーケットプレイス・アプリケーションに統合します。

Frank Cohen (fcohen@pushtotest.com), President, PushToTest

Frank Cohenは、1975年以来パーソナル・コンピューターの世界的な成功に貢献してきたソフトウェア起業家です。彼は、まず最初にマイクロコンピューター用のオペレーティング・システムを書き、ビデオ・ゲームの産業としての確立を支援し、Norton Utilitiesフランチャイズの確立を支援し、ミドルウェアおよびインターネット・テクノロジーへのAppleの取り組みを主導し、最近ではSun Community Server、Inclusion.net、およびTuneUp.comの主任設計者となっています。Frankは、オープン・ソースのLoadプロジェクトを保守していて、また、スケーラビリティーとパフォーマンスに関するテスト・ソリューションを提供する会社であるPushToTestのCEOです。詳しい情報は、 www.PushToTest.com で得ることができます。Frankの連絡先はfcohen@pushtotest.com です。



2002年 2月

いったい、空港はいつ完成するのですか?

インターネット・アプリケーションやイントラネット・アプリケーションの構築は、空港の建設とよく似ています。乗客、航空路線、設備などの要件を満たすために増改築が必要になるのは、物事が絶え間なく動いていることを示しています。普通、Webサイトもこれと同じような展開になります。つまり、昨年作成した基本Webシステムが、もう新しい機能を必要としています。新しい機能や新規のサーバー・ソフトウェアを統合する場合、SOAPを使用すれば作業が容易になります。SOAPは、新たに登場したオープン・スタンダードで、以前はエンジニアリング作業に費用が掛かったり、保守が難しいなどの理由で実現できなかった統合を可能にします。

このケース・スタディーでは、Webサービスを使用して、シームレスで簡単なシングル・サインインを行います。そこでは、開発チームがWebサービスを使用して、どのようにしてeCRMアプリケーションを既存のe-Commerceマーケットプレイス・アプリケーションにシームレスに統合したかを示します。SwitchouseがInclusion共同作成メッセージング・ソフトウェアをWebサイトに統合した実体験に基づく詳しい例を紹介します。この記事では、統合プロジェクトで発生したいくつかの問題も提示しますので、問題回避の参考にしてください。


オンライン・コンシューマー・マーケットプレイスの費用を削減する

SwitchouseはWebを利用する大手コンシューマー・マーケットプレイスの1つで、その活動の中心は、何百万というユーザーが必要なものを入手するために新しい優れた方法を見つけ出す際の手助けをすることです。人気のあるオークション・サイトのeBayとは異なり、Switchouseの場合、ユーザーは、音楽CD、映画、ビデオ・ゲーム、書籍などといった中古のエンターテイメント品目を定価で売買することができます。Switchouseは、各取引ごとに手数料を受け取ります。通常の買い付けは $10 - $15の範囲内で行われます。Switchouseは、費用を掛けない方法で自社ユーザーをサポートする必要がありました。

Switchouseの経営陣は、e-Commerce Webサイトを世に出した後、間もなくして、オンライン・カスタマー・リレーションシップ・マネージメント (eCRM) サービスを追加してユーザー・サポートのコストを減らすことを決定しました。Switchouseは、現在、自社Webサイト内のeCommunity を使用してメンバー間のサポート・システムを提供しています。

Switchouseは、自社の公開および非公開のディスカッション・グループ、e-mailによる発表、通知などを行うために必要なeCRMソフトウェアを、システム・インテグレーターのInclusion社 (カリフォルニア州ロス・アルトス) にアウトソーシングすることに決定しました。Inclusionソフトウェアはタグ・ベースのスクリプト言語を特徴としており、そのスクリプト生成ページのルック・アンド・フィールは、Switchouseのe-Commerceサイト・ページに一致します。

図1. Switchouse.comホーム・ページのサインイン・フォーム
図1
図1b. Inclusion生成eCRMページのサインイン・フォーム
図1b

Inclusionソフトウェアは、GateKeeper呼ばれるシングル・サインインのWebサービスを提供します。ユーザーは、Switchouseのe-CommerceページまたはInclusionで生成したページのどちらかからサインインします。Switchouseは、さらに機能を追加し、GateKeeperと同じシングル・サインインのWebサービスを使用してこれらの機能も統合することを計画しています。

ユーザーにとって使いやすいかどうかがシステムを統合する場合の最も大きな関心事となります。これまでの経験から、Switchouseのユーザーは応答時間が長いと我慢ができないことが分かっていますので、サインイン・システムをリアルタイムで動かす必要があります。さらにSwitchouseには、以下のような要件もあります。

  1. セッション中、ユーザーIDとパスワードの検証は1回しか行わない。
  2. ユーザーは任意のページからサインインできる。
  3. サインイン・サービスはリアルタイムで動作する。ユーザーがサインイン・ボタンをクリックしたら、5秒以内に応答しなければならない。
  4. サーバー間通信は、セキュアで認証済みである。
  5. システムは双方向に動作する。
  6. データ共用のための一般的な方法を提供するようにシステムを拡張できる。

設計チームが心配したのは、次の2つです。1つは、Inclusionで生成したページのサインイン・フォームに対して、システムはどのようにして即時応答ができるか。もう1つは、将来、より大量のデータを転送しなければならなくなったときに、システムを拡張できるか。


2つの部分からなるソリューション

ソリューションは、次の2つの部分で実行されます。1つは同期プロトコルで、HTTP POSTとリダイレクト・コマンドを使って、見掛け上、サインインがリアルタイムで行われるようにします。もう1つは非同期プロトコルで、追加データの転送を操作します。まず、同期プロトコルについて説明します。

図2. GateKeeperシステムの同期部分
図2

スクリプト生成ページには、サインイン用のHTMLフォームが含まれています。このフォームは、e-Commerceアプリケーション・サーバーのKeyMasterサーブレットに送られます。戻りパラメーターは、サインインが正常に終了した場合にユーザーのリダイレクト先をKeyMasterに知らせます。

リスト1: HTMLサインオン・フォーム
<FORM action="http://www.switchouse.com/keymaster.html" METHOD="POST">
	<INPUT type="text" size="10" maxlength="32" name="login_username">
	<INPUT type="password" size="10" maxlength="32" name="login_password"
	<input type="hidden" name="return" value="/switchouse/summary.html">
	<input type="hidden" name="submitKey" value="Log In">
</FORM>

e-Commerceアプリケーション・サーバーのKeyMasterサーブレットは、ユーザー・アカウントを検証し、eCRMサーバーのGateKeeperサーブレットにリダイレクトを戻してフォーム要求に応答します。このリダイレクトは、次のようになっています。

http://eCRMsite.inclusion.net/sq=%0A%12%38%31...%8B%9C&return=/switchouse/summary.html

sq パラメーターにはユーザー・データが含まれています。SOAPベースのWebサービス環境では、複号されたユーザー・データは、次のようになっています。

<gatekeeper>
  <name>Frank</name>
  <password>83jdiej</password>
  <action>sign-in</action>
</gatekeeper>

GateKeeperサーブレットはユーザー・データを複号し、ユーザーをeCRMアプリケーションにサインインし、ユーザーのブラウザーを戻りページへリダイレクトします。このトランザクションにはリダイレクトされたいくつかのページが含まれていますが、ユーザーには、サインイン・フォームが入っている元のページと、自分がサインインした戻りページしか表示されません。それで、ユーザーは満足です。


非同期プロトコル

e-CommerceサーバーとeCRMサーバー間の双方向交換という目標を達成するために、GateKeeperは非同期プロトコルを取り入れています。Switchouseは、新規ユーザーをe-Commerceサイトに登録するときに非同期Webサービスを使用します。

新規ユーザーの登録には、通常、名前、住所、電話番号、所属グループ、および新規メンバーとしての権限が必要です。URLエンコード・ユーザー・データが2000バイトを超えるほどの大きさになった場合 (多くのブラウザーは非常に長いURLをクリップする)、同期方式が正しく機能するという保証はありません。GateKeeperは、最も基本的なユーザー情報を受信する場合は同期Webサービスを使用し、追加のユーザー情報を受信する場合は非同期Webサービスを使用します。

新規ユーザーは、名前、住所などの登録情報をHTMLフォームに入力します。このフォームはe-Commerceサーバーに送られ、新規ユーザー・データがe-Commerceシステム・データベースに挿入されます。ここからリダイレクト・コマンドが戻され、このコマンドがGateKeeper XML文書に組み込まれます。

<gatekeeper>
  <name>Frank</name>
  <password>83jdiej</password>
  <action>new-user</action>
</gatekeeper>

GateKeeperサーブレットはXML文書を複号し、新規ユーザーをeCRMサーバー・データベースに追加し、ユーザーをサインインし、ユーザーを戻りページへリダイレクトします。これらの動作はすべて、ユーザーにリアルタイムで行われているという印象を与えます。

またGateKeeperは、項目を非同期要求のキューにも追加します。この項目は、e-CommerceサーバーのKeyMasterサーブレットに連絡するようGateKeeperに指示して、ユーザーの拡張情報 (会社名、職位、電話番号、部門名、管理者名前、e-mailアドレスなど) を検索させます。

<keymaster>
  <name>Frank</name>
  <password>83jdiej</password>
  <action>send-extended-info</action>
</keymaster>

KeyMasterは、これらのユーザーの拡張情報を使用してGateKeeperにWebサービス要求を行います。

<gatekeeper>
  <name>Frank</name>
  <password>83jdiej</password>
  <action>update-user-info</action>
  <company>PushToTest.com</company>
  <title>Developer</title>
  <phone>408 374 7426</phone>
  <department>7</department>
  <manager>Fred Gibbons</manager>
  <email>fcohen@pushtotest.com</email>
</gatekeeper>

このシステムは、新規ユーザーのためのデータ交換、既存ユーザーの更新、ユーザーの削除、エラー報告などを行います。たとえば、応答XML文書がエラー・メッセージの場合があります。

<gatekeeper>
  <action>error</action>
  <error>400></error>
  <error_description>KeyMaster received an XML document that
     will not decode</error_description>
  <timestamp>38274883</timestamp>
</gatekeeper>

このシステムは、同期Webサービスと非同期Webサービスを利用することで、目標のシングル・サインインを達成します。新規ユーザーは、e-Commerceサイトに即時にアクセスできます。非同期システムでの待ち時間は、通常、5秒かからないと計測されています。開発者は満足です。


開発者のみが学ばなければならない教訓

私は、シングル・サインイン・システムの設計やWebサービスの実行、また時には保守などを楽しんで行うことができたかもしれません。しかし現実には、いくつかの問題が出てきて、それらの解決に当たらなければなりませんでした。

単一方向ファイアウォール

新規製品ラインを発表する直前になって、ある電子機器メーカーは、製品説明書を配布したり、現場の販売担当マネージャーからのフィードバックを受け取ったりする際に使用するセキュアなエクストラネットを構築するために、Inclusionソフトウェアを使用することに決定しました。このメーカーは、社内のLDAP従業員ディレクトリーに照らしてユーザー認証を行うためのKeyMasterサーブレットを作成しました。

発表に間に合うように、メーカーはまず、Inclusionがホスティングしているアプリケーション・サービス・プロバイダー (ASP) サービスを選択し、後日、Inclusionソフトウェアをデータセンターに投入しました。KeyMasterとLDAPディレクトリーはメーカーのネットワークに常駐し、Inclusionソフトウェアは外部ネットワークに常駐しています。残念ながら、このメーカーのネットワークでは、アウトバウンドのHTTP要求は受け入れますが、インバウンドのHTTP要求は拒否します。

図3. 単一方向ファイアウォール。
図3

新規ユーザーがサインインすると、KeyMasterはURLエンコード要求をGateKeeperに送ります。次にGateKeeperは、KeyMasterにWebサービス要求を出して追加のユーザー情報を要求します。GateKeeper要求は、メーカーがネットワーク保護のために使用するSecureIDベースの認証システムに対するリダイレクト指示を受け取ります。

シングル・サインイン・システムの双方向特性が原因で、ファイアウォールを通過することができませんでした。最初、私は、内部KeyMasterサーバーへの無保護接続を特別にオープンにしてくれるようメーカーのITグループに頼もうと考えました。しかし私はこの考えをあきらめました。なぜなら、私がメーカーの立場になった場合、果たしてユーザーのネットワークを特殊なケースのためにオープンにしてあげたいと思うだろうかと考えたからです。

ソリューションは、KeyMasterだけがトランザクションを開始できるようにコール・フローを変更することです。メーカーのネットワークで稼動するKeyMasterは、新規ユーザー登録時とユーザーのサインイン時に、GateKeeperに連絡します。

まず統合の計画を立てる

現在、GateKeeperシングル・サインイン・システムを使用している会社は6社あります。Inclusionは、新しい傾向が生じていることを早い段階で見つけました。すなわち、シングル・サインイン・プロジェクトでは、最も重要なリソースの割り振りと計画作成を適時に実行する必要があるということです。Webサービスを開発するには、基本コーディングやXML構文解析についての知識のほか、LDAPサービスを始めとする、ディレクトリー・サービスとのシステム統合についての知識が必要になります。こういったスキルをすべて兼ね備えたエンジニアはほとんどいません。私の経験では、中堅のエンジニアは、3~5週間でシングル・サインインWebサービスを作成できます。通常、コードの納入には4週間かかり、これにさらに2週間のテストが必要になります。

強力なセキュリティー

この記事で説明しているシングル・サインインのWebサービスは、HTTPセキュア・プロトコルにも接続します。GateKeeperプロトコルとKeyMasterプロトコルは、セキュアなSSL接続を介して操作されます。ブラウザーとWebサーバー・ソフトウェアは、通常、SSL暗号化と認証を行います。

現在のSOAP 2.2仕様には、セキュリティー・プロトコルと認証プロトコルが定義されていません。しかし多くのエンジニアは、Webサービス要求をセキュアに実行できるようにするための手段として、SSLが最終的なSOAP仕様に定義されるのを期待しています。OpenSSL.orgはSSLテクノロジーの優れた情報源であり、しかも無料です。

現在はDTD、将来はXMLスキーマ

この記事で紹介しているシングル・サインイン・システムは、Webサービスの呼び出し時にXML文書を交換します。このシステムは、1998年に設計されました。それは、XMLライブラリー (SAXおよびDOMパーサー) が広く使用されるようになるずっと前のことです。当初このシステムはJavaでインプリメントされ、IBM alphaWorksのSAXライブラリーを使用しました。SAXは強力である反面、中堅のソフトウェア開発者には使いにくいという面も併せ持っています。多くのコールバック方式をインプリメントする必要がありますが、そのためには、XMLとDocument Type Definition (DTD) 構文を完全に理解していなければなりません。

次世代シングル・サインイン・システムは、SOAPとXMLスキーマを使用して、要求/応答呼び出しパラメーターを定義することになります。Javaインプリメンテーションでは、XML文書の作成や操作にJDOMを使用するようになるでしょう。JDOMは、SAXおよびDOMパーサーを介して実行される単純なAPIで、XMLデータを処理するためのJava類似方式を提供します。

私がKeyMasterです。いいえ、私がKeyMasterです

私の経験では、エンジニアたちがそれぞれ最初のサーバー・ソフトウェア統合プロジェクトを無事完了すると、引き続きさらに多くの統合プロジェクトを担当することになります。これでいくらか作業が楽になるように思われます。GateKeeper/KeyMaster Webサービスは、クレジット・カード会社との共同販売促進の強化、インセンティブ・プログラム (航空会社のマイレージ・ポイント・システムなど) や調査システムとの組み合わせなどに用途を見出しました。

最初これは、潜在的な問題を提示しました。たとえば、あるe-Commerce会社が他社のサービスを自社システムに統合したいと考えている場合に、他社が独自のサーバー間通信システムを提供してきたらどうしますか? だれがGateKeeperで、だれがKeyMasterですか? Webサービスは、この難題を解決するために、すべてのシステムがクライアントにもサーバーにもなるようにしています。インバウンド要求は、アウトバウンド応答と同じプロトコルによって転送されます。


結論

最近の多くのサーバー・システムでは、インターオペラビリティーは、共通ディレクトリーへのアクセスから始めて、セキュアなシステム間シングル・サインイン・メカニズムを提供しています。次にインターオペラビリティーは、データ同期、報告、およびe-Commerceへ広がります。Webサービス・ベースの同期および非同期サーバー間通信プロトコルをインプリメントすることで、ユーザーに満足を与え、作成したソフトウェアを保守可能にします。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=243775
ArticleTitle=Webサービスをe-Commerceシングル・サインインに使用する
publish-date=022002