Project Zero および WebSphere sMash アプリケーションのセキュリティーを守る: 第 3 回 OpenID を使って Project Zero および WebSphere ｓMash アプリケーションを保護する

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 初級

Todd Kaplinger (todkap@us.ibm.com), Project Zero Architecture & Development, IBM　
Gang Chen (gangchen@us.ibm.com), IBM Software Services for WebSphere, IBM　

2008年 2月 19日

アプリケーション・リソースのアクセス制御ベースのセキュリティーは、Project Zero のコア機能のうちの 1 つです。OpenID はインターネット上で分散認証を行うための、オープンソースの新しいセキュリティー技術で、Web コミュニティーではこの技術への関心が次第に高まってきています。Project Zero ではこの新技術を導入し、セキュリティーの一部として提供しています。連載最終回となるこの第 3 回目の記事で、Project Zero Security の詳細、そして OpenID 認証を利用してアプリケーションに対してセキュリティー・ルールを定義し、ユーザー・レジストリーを拡張する方法を学んでください。

編集者からの注記: IBM® WebSphere® sMash および IBM WebSphere sMash Developer Edition は、非常に高い評価を受けた Project Zero のインキュベーター・プロジェクトをベースにしています。Project Zero は WebSphere sMash の開発コミュニティーであり、最新のビルドや、最新の機能、そしてコミュニティーのサポートを利用したアプリケーションを開発するための無料のプラットフォームを今後も提供していきます。

はじめに

OpenID 認証を紹介する前に、Project Zero についてざっとおさらいしておきます。以下の説明は、Project Zero Web サイトからの引用です。

Project Zero は IBM 内で始まったインキュベーター・プロジェクトで、その焦点は次世代の動的 Web アプリケーションのアジャイル開発に置かれています。Project Zero は、代表的な Web 技術をベースにアプリケーションを作成し、組み立て、実行するための単純な環境を導入します。Project Zero の環境には、Groovy および PHP のスクリプティング・ランタイムが組み込まれ、REST スタイルのサービス、統合マッシュアップ、そしてリッチ Web インターフェースを作り出すことを目的に最適化されたアプリケーション・プログラミング・インターフェースが備わっています。

この記事の内容 3 回連載の最終回となるこの記事では、Project Zero Security の詳細を探り、OpenID 認証を利用してアプリケーションに対してセキュリティー・ルールを定義し、ユーザー・レジストリーを拡張する方法を説明します。この記事では、読者が Project Zero をダウンロード済みであること、そして初心者向け演習の手順を完了しているか、または単純なアプリケーションを自分自身で作成した経験があることを前提とします。

Project Zero が主に対象としているのは次世代の動的 Web アプリケーション (一般に Web 2.0 の傘下に分類されるアプリケーション) であるため、その重点はマッシュアップ、ウィキ、ブログといったユーザー提供のコンテンツを利用する対話型 Web アプリケーションに置かれています。このようにユーザーが生成するコンテンツを重視する Web 2.0 の時代のなかで、Web サイトのセキュリティーはますます重要になってきています。このように重要性が高まっているセキュリティーに欠かせない要件の 1 つは、サイトのユーザーを認証することです。従来は Web サイトのそれぞれが、ユーザー・レジストリーの提供からエンド・ユーザーのデジタル ID の保管までを含め、独自の認証システムを内部で維持管理していました。

そこに登場したのが OpenID です。分散認証モデルを提供する OpenID 技術はインターネットへのシングル・サインオン (SSO) を可能にし、エンド・ユーザーが 1 つのデジタル ID を Web 全体で使用できるようにします。OpenID ではエンド・ユーザーが保護したい情報 (個人の E メール・アドレスなど) を外部に公開することなく、自分の ID を持つことができます。図 1 に、OpenID 認証アーキテクチャーに含まれる主なエンティティーを示します。

OpenID とは? OpenID Foundation では OpenID のことを、ユーザーを主体としたデジタル ID のための公開された分散型の無料のフレームワーク、と説明しています。OpenID は既存のインターネット技術 (URI、HTTP、SSL、Diffie-Hellman) を利用し、個人がブログ、フォトストリーム、プロファイル・ページなどで自分の ID をすでに作成しているということを認識します。OpenID では、このような既存の URI のいずれかを、OpenID ログインをサポートするあらゆるサイトで使用可能なアカウントに簡単に変換することができます。

OpenID プロバイダー (ID プロバイダーと呼ばれることもあります) は、ユーザー ID の登録サービスおよび OpenID 認証サービスを提供します。応答側は、ユーザーを認証する必要がある Web サイトです。ユーザーはいつものようにユーザー名とパスワードのペアを使うのではなく、単一の OpenID の ID を使ってサイトにアクセスします。この ID は通常、URL (Uniform Resource Locator) または XRI (eXtensible Resource Identifier) として使用されます。

この分散認証モデルをサポートするため、Project Zero では OpenID コンシューマー・ライブラリーを用意しています。アプリケーションはこのライブラリーを使用して、サード･パーティーである OpenID ID プロバイダーに対して認証を行います。このような分散認証モデルでは、アプリケーション開発者はユーザー・プロファイルを管理する作業をサード・パーティーの信頼できるリソースに任せ、アプリケーションの開発に専念することができます。

サンプル・アプリケーションについて

Project Zero での OpenID 技術を説明するとともに実際にこの技術を体験してもらうため、この記事ではダウンロード可能なサンプル・アプリケーションに関連付けて手順を説明します (「参考文献」を参照)。これらのサンプル・アプリケーションは少しずつ複雑さを増していくユース・ケースに従いながら、以下の一般的な OpenID の使用シナリオを取り上げています。

1. サンプル・アプリケーション 1 は、OpenID を認証タイプとして構成する基本的なアプリケーションです。
2. サンプル・アプリケーション 2 では、サンプル・アプリケーション 1 をベースに、さまざまなフォーマットの openid_url を処理できるようにカスタム・ユーザー・レジストリーを提供します。
3. サンプル・アプリケーション 3 では、サンプル・アプリケーション 2 をベースに、アプリケーションで使用するための OpenID プロバイダーの「優良リスト」を提供するようにします。

サンプルに従ってください Project Zero の OpenID 技術をより理解するには、この記事で使用するサンプル・アプリケーション、openid.demo を Project Zero Catalog からダウンロードしてください。

OpenID アカウントについて

最初に完了しておかなければならないステップは、OpenID アカウントの登録です。よく利用される OpenID プロバイダーのリストについては、「参考文献」セクションに記載している OpenID.net へのリンクを参照してください。この記事では、最も一般的な OpenID プロバイダーの 1 つである myopenid.com、そして IBM で OpenID の概念実証として使用しているテスト OpenID プロバイダーを使用します (この記事で説明するアプリケーションは、OpenID 仕様をサポートする OpenID プロバイダーであれば、どのプロバイダーを使っても機能します)。

サンプル・アプリケーション 1: OpenID 認証の有効化

Project Zero の OpenID 技術をよく理解するには、この記事で使用するサンプル・アプリケーション、openid.demo を Project Zero Repository からダウンロードし、このアプリケーションを参照しながら説明を読んでください。Project Zero では、zero.security.openid ライブラリーによって OpenID をサポートします。このライブラリーは、アプリケーションの依存関係の 1 つとして ivy.xml ファイルにあらかじめ構成されており、OpenID を初めて使用する際に、Project Zero がリポジトリーにダウンロードしてくれるはずです。

コマンドラインを使用する場合:

• WebSphere sMash Web サイトの指示に従って、IBM WebSphere sMash コマンドライン・ユーティリティーをインストールしてください (「参考文献」参照)。
• zero create openid.demo from zero:openid.demo と入力し、WebSphere sMash リポジトリーから OpenID デモ・アプリケーションをインストールしてください。
• zero start と入力してアプリケーションを起動します。

アプリケーション・ビルダーを使用する場合

• WebSphere sMash Web サイトの指示に従って、IBM WebSphere sMash コマンドライン・ユーティリティーをインストールしてください (「参考文献」参照)。
• CLI がインストールされている zerodirectory までナビゲートして startAppBuilder スクリプトを実行することで、アプリケーション・ビルダーを起動します。
• アプリケーション・ビルダーの左側にある、リポジトリーからコピーするためのリンクを利用して WebSphere sMash リポジトリーから OpenID デモ・アプリケーションをインストールします。(コピーするモジュールは zero:openid.demo です。)
• openid.demo アプリケーションに関連付けられている実行ボタンをクリックすることで、アプリケーションを起動します。

このサンプル・アプリケーションには 2 つの Web ページしかありません (Project Zero の徹底的な簡易化を示す一例です)。最初のページはインデックス・ページで (図 2 を参照)、ここにはユーザーがコメントを投稿できるテキスト域があります。 コメントが投稿されると、アプリケーションは Ajax 技術によって RESTful なリクエストをサーバーに送信することで、メッセージを送信します。続いてアプリケーションは別の Ajax 呼び出しを行って、サーバーからブラウザーに送られるメッセージを取得します。特別便利なアプリケーションとは言えませんが、Project Zero の中で OpenID がどのように機能するかを説明するには、このアプリケーションが提供する機能で十分です。サーバー・コンポーネントが立ち上がったら、ブラウザーで http://localhost:8080 にアクセスしてサンプル・アプリケーションのテストを行います (図 2 を参照)。

このサンプル・アプリケーションは、groovy コンポーネント (リスト 1 の comment.groovy) を使用して投稿とコメントの取得を処理します。

                


def onCreate(){
	def commentJSON = zero.json.Json.decode(request.input[])
	def comment = commentJSON["comment"]
	if(comment != null || comment == ""){ // user submitted a comment with content
	    def commentId = "Comment_" + System.currentTimeMillis()
    	    request.headers.out.Location =  
    	    zero.core.utils.URIUtils.getRequestedUri(false) + "/" + commentId
	    user.commentId = comment;
    	    request.status = java.net.HttpURLConnection.HTTP_NO_CONTENT
	}
}

def onRetrieve(){
	def commentId = request.params.commentId.get()
	def comment = user.commentId.toString();
	def result = [commentId : comment]
	request.view='JSON'
	request.json.output = result
	zero.core.views.ViewEngine.render()
}

サンプル・アプリケーションのセキュリティーを構成する

サンプル・アプリケーションが実行可能な状態になったら、次は、認証されていないユーザーがこのサイトにアクセスしないようにリソースを保護する必要があります。ユーザーがアカウント (ユーザー ID およびパスワード) を作成して保管できるようにするための、Web ページとユーザー・レジストリーを作成して維持管理しなくてもいいように、認証をサード・パーティーに任せることにしました。それと同時に、サイトをセキュアな状態に維持できるようにもしなければなりません。この目的を果たし、適切なセキュリティー・ルールの構成について考えるために利用するのが、Project Zero が提供する OpenID サポートです。

OpenID 認証を有効にするには、アプリケーションの zero.config ファイルに、表 1 に要約した 2 つの構成スタンザを指定します。最初の構成スタンザは、アプリケーション全体に共通しています。表 1 に記載する 2 つの構成キー (openidLoginPage および allowedOpenidDomains) はいずれもオプションです。

サンプル・アプリケーションで OpenID 認証を有効にするための最初のステップは、アプリケーションの zero.config グローバル構成を設定することです。以下のスタンザでは、ユーザーが認証用の openid_url (ID) を入力する OpenID ログイン・ページだけを定義しています。

                
# specify the OpenID loginPage
@include "openid/rule.config"{
	"openidLoginPage": "/openidlogin.gt"
}

次のステップは、セキュリティー制約を適用するリソースを構成することです。以下のように、3 つのスタンザそれぞれに個別の構成設定を定義します。

• スタンザ 1: ロールの定義
  スタンザ 1 ではロールを定義しています。ロールが出てくるのはこの記事では初めてですが、これは Project Zero Security にとっては高度な話題です。定義するのは OPENID_ROLE というロールで、このグループのメンバーであるすべてのユーザーは VALID_OPENID_USER と呼びます。
• スタンザ 2: OpenID に対するセキュリティー制約の定義
  スタンザ 2 で定義しているのは、アプリケーションのエントリー・ポイントである index.gt のセキュリティー制約です。制約として、最初のスタンザで定義したロールをこのリソースにアクセスするために必要なロールとして一覧にしています。このリソースの authType として定義されているのは、RP です (RP は Relying Party の略で、現在サポートされる RP タイプは OpenID のみです)。リソースが authType として RP を指定して保護されている場合、ユーザーがログイン済みであると認められなければ、そのユーザーは認証を行うためのログイン・ページにリダイレクトされます。
• スタンザ 3: RESTful なサービスに対するセキュリティー制約の定義
  スタンザ 3 で定義しているのは、このアプリケーションの AJAX サービスを処理する RESTful なリソースである comment.groovy のセキュリティー制約です。この制約では、最初のスタンザで定義した OPENID_ROLE をこのリソースにアクセスするために必要なロールとして一覧に記載しています。このリソースの authType は SSO (シングル・サインオン) です。このリソースを SSO で保護するわけは、便宜上の理由とスタイルのためです。このリソースを authType として RP を指定して保護したとすると、セキュリティー・トークンの有効期限が切れた場合、AJAX リクエストはログイン・ページにリダイレクトされることになります。このようなリダイレクトは AJAX 以外のリクエストの場合には許容されますが、AJAX スタイルのリクエストとしては優れたユーザー・エクスペリエンスにはなりません。そのため、このリソースにアクセスしようとするユーザーが認証されない場合には、そのユーザーはステータス・コード 401 を受け取り、アプリケーションがこの状態を処理する特殊なエラー・ハンドラーを提供できるようにしています。

                
## define a role named OPENID_ROLE that only the group VALID_OPENID_USER is a member
/config/security/roles/OPENID_ROLE/groups=["VALID_OPENID_USER"]

#specify the security constraints
#protect index page
@include "security/rule.config"{
	"conditions" : "/request/path =~ (/|/index.gt(/.*)?)",
	"authType" : "RP",
	"csrfProtect" : false,
	"roles" : ["OPENID_ROLE"]
}

#protect RESTful resource with SSO so no redirects
#to login page for the case of expired tokens.
@include "security/rule.config"{
	"conditions" : "/request/path =~ /resources/comment(/.*)?",
	"authType" : "SSO",
	"csrfProtect" : true,
	"roles" : ["OPENID_ROLE"]
}

セキュアなリソースにアクセスする

ユーザー ID が作成されていれば (「OpenID アカウントについて」のセクションを参照)、アプリケーションにアクセスする準備は万端です。最初のステップとして、ブラウザーを開いてアプリケーションのメイン・エントリー・ポイントである http://localhost:8080/index.gt にアクセスしてみてください。このリソースは authType を RP にしてセキュアにされているため、Zero Security ランタイムはリソースが保護されていることを認識し、ユーザーを上記で定義した openidLoginPage にリダイレクトします。ブラウザーには以下の画面が表示されるはずです (図 3 を参照)。

このログイン・フォームにはリスト 4 に記載するコード・フォーマットが含まれ、openidlogin.gt という名前が付けられています。

                
<form name="input" action="" method="POST">
	<table>
		<tr>
			<td class="header">OpenID URL: </td>
			<td><input type="text" name="openid_url" value=""></td>
		</tr>
		<tr>	
			<td colspan="2" align="center">
				<input type="submit" name="submit" value="Login">
			</td>
		</tr>
	v/table>
</form>

ここで、myopenid.com が指定する openid_url (todkap.myopenid.com) を使ってログインしてみます。すると、OpenID によってログインのリクエストが myopenid.com サイトにリダイレクトされ、このサイトで、適切な opened_url とパスワードを使って認証プロセスが開始されます (図 4 を参照)。

OpenID プロバイダー (myopenid.com) での認証が成功すると、OpenID プロバイダーはクライアントを最初に要求されたページ (http://localhost:8080/index.gt) にリダイレクトします。このページは、RemoteUser、グループ、ユーザーのロールを表示するように拡張済みで、RemoteUser にはログインに使用された openid_url、グループには VALID_OPENID_USER という 1 つのグループ、そしてロールには OPENID_ROLE が設定されるはずです。このような設定でなければ、ユーザーは認証されません。このリソースへのアクセスが許可されるのは、ロールが OPENID_ROLE のユーザーのみだからです。認証が成功するとブラウザーには、図 5 の画面が表示されます。

これで、「今日は気分のいい日だ」といったコメントを安全に投稿することができます。

サンプル・アプリケーション 2: Project Zero による OpenID サポートの拡張

基本的な OpenID サポートは有効になっているので、今度はデフォルト・イベント・ハンドラーとデフォルト・ユーザー・レジストリーの実装を拡張して、OpenID アカウントを、サポートされる Project Zero ローカル・アカウントに変換できるようにします。このような拡張は、インターネット SSO を企業のイントラネット・セキュリティー・システムに接続する場合に極めて有効です。

カスタム resolveFederatedId イベント・ハンドラーを定義する

resolveFederatedId イベント・ハンドラーは、リクエストを処理する際にセキュア・イベントと許可イベントの間で起動されます。このイベント・ハンドラーは、ユーザーがフェデレーテッド ID (openID など) を使ってログインした場合を対象として追加されています。場合によっては、ユーザー ID を変更 (あるいは変換) してサード・パーティーの認証子と Project Zero のユーザー・レジストリーの両方で使えるようにしなければなりません。openid_url を内部 OpenID プロバイダーが所有している場合 (例えば IBM の内部 OpenID 認証では、「blueid.bluehost.ibm.com」)、参照できるのは E メール・アドレスのみです。IBM では、IBM ディレクトリーの処理だけでなく、他のさまざまな SSO ソリューションにも E メール・アドレスを使用します。リスト 5 に記載しているのは、OpenIDResolver のデフォルト実装を継承するハンドラーです。OpenIDResolver のデフォルト実装は、初期ログインの後、セキュアなリクエストに対してクライアントを識別するために使うトークンを作成するために呼び出されますが、このハンドラーは、この際に呼び出される attachUserToken メソッド呼び出しをオーバーライドします。オーバーライドされた attachUserToken は認証されたユーザー名を引数として取り、そのユーザー名がTRUSTED_OPENID_SERVER 変数で始まっているかどうかをチェックします。この条件に一致する場合には、ユーザー名の先頭からこの変数を除去します。

                
package zero.security.example.openid;

import zero.core.security.relying.party.openid.OpenidResolver;

public class ExampleOpenidResolver extends OpenidResolver{

    private static final String TRUSTED_OPENID_SERVER = 
	"http://blueid.bluehost.ibm.com/?user=";

    @Override
    public void onResolveFederatedId() {
        super.onResolveFederatedId();
    }

    @Override
    protected void attachUserToken(String username) {
        if (username.startsWith(TRUSTED_OPENID_SERVER)){
 	    // consider this user trusted for this app and 
  	    //just use the userid in token and remoteUser
            username = username.substring(TRUSTED_OPENID_SERVER.length());
        }
        super.attachUserToken(username);
    }

}

以下の構成スタンザ (リスト 6 を参照) は、カスタム resolveFederatedId ハンドラーの構成方法を定義しています。ダウンロードしたサンプル・アプリケーションでは、この 3 行がコメント･アウトされているので、必ずこれらの構成項目のコメントを外してから、ご使用の環境でテストしてください。

                
/config/handlers += [{
	"events" : "resolveFederatedId",
	"handler" : "zero.security.example.openid.ExampleOpenidResolver.class"
}]

カスタム UserService 実装を定義する

カスタム resolveFederatedId の追加方法に加え、カスタム UserService を作成する方法も説明しておきます。リスト 7 は、OpenID 認証に使用するデフォルトの UserService 実装を継承するサンプル・コードです。このカスタム実装クラスでは、getUser のデフォルト実装を呼び出してログインし、適切なユーザー・プリンシパルのセットを取得します。次に DWExampleGroup というカスタム・グループを追加して、特定ユーザーにグループを追加する方法を示しています。カスタム resolveFederatedId の場合は内部 IBM OpenID プロバイダーだけをチェックしていますが、カスタム UserService は OpenID プロバイダーとは関係なくこのカスタム・グループを追加します。

                
package zero.security.example.openid;

import java.security.Principal;
import java.security.acl.Group;
import java.util.Set;

import zero.core.security.GroupImpl;
import zero.core.security.relying.party.openid.OpenIDUserService;
import zero.core.security.userservice.UserServiceException;

public class ExampleUserService extends OpenIDUserService{

    private static final Group DW_GROUP = new GroupImpl("DWExampleGroup");
    
    @Override
    public Set<Principal> getUser(String username) 
	    throws UserServiceException {
        Set<Principal> principals =  super.getUser(username);
        if(principals.isEmpty() == false) {     // user was logged in via openID
            principals.add(DW_GROUP);  // add developer work group
        }
        return principals;
    }

    @Override
    public Set<Principal> login(String username, String passwd) 
	    throws UserServiceException {
        Set>Principal< principals =  super.login(username, passwd);
        if(principals.isEmpty() == false) {   // user was logged in via openID
            principals.add(DW_GROUP);   // add developer work group
        }
        return principals;
    }
}

カスタム UserService の構成方法は、リスト 8 に記載する構成スタンザが定義します。

                
registryImplStr="zero.security.example.openid.ExampleUserService" 	
/config/security/userservice/registryType="exampleUserService"
# must implement zero.core.security.userservice.UserService
/config/security/userservice/registryImpl/exampleUserService=${registryImplStr}

サンプル・アプリケーション 2 を実行する

カスタム resolveFederatedId 実装とカスタム UserService 実装を使用したアプリケーションの構成が完了しました。この構成を有効するには、アプリケーションを再起動する必要があります。再起動したら、セキュアなアプリケーションにもう一度アクセスしてみます。前の例では todkap.myopenid.com を openid_url として使いましたが、今回は openid_url に http://blueid.bluehost.ibm.com/?user=todkap@us.ibm.com を使用して新しい構成の機能のデモを行います。

始めに着手するのは前と同じログイン・フォームです。ただし今回は、IBM OpenID サービスの http://blueid.bluehost.ibm.com/?user=todkap@us.ibm.com を openid_url として使ってログインします。この場合、ユーザーは OpenID プロバイダーのログイン・ページにリダイレクトされることになります (図 6 を参照)。

認証要求は myopenid.com ではなく、IBM イントラネットの OpenID サイトである blueid.bluehost.ibm.com にルーティングされます。前回と同じように、OpenID プロバイダーでの認証が成功すると OpenID プロバイダーがクライアントを最初に要求されたページ (http://localhost:8080/index.gt) にリダイレクトします。このページも、RemoteUser、グループ、ユーザーのロールを表示するように拡張されています。今回何が違うかと言うと、リモート・ユーザーにはログインの際に使用された openid_url の変更バージョンが表示されるという点です (注: このユーザー ID は、ユーザーの E メール・アドレスだけになるように resolveFederatedId によって変更されています)。また、グループには元の「VALID_OPENID_USER」と、UserService によって新しく追加された「DWExampleGroup」の 2 つのグループが含まれます。その一方、ロールとして表示されるのは OPENID_ROLE です。このリソースにはロールが OPENID_ROLE のユーザーしかアクセスが許可されないため、この設定でないユーザーは認証されません。認証が成功するとブラウザーには、図 7 の画面が表示されます。

これで、「今日は特に気分がいい日だ」とコメントすることができます。

サンプル・アプリケーション 3: 信頼できる OpenID プロバイダーのみを使用する制限

これまで OpenID の使用方法を 2 つの一般的なシナリオで説明してきましたが、OpenID の欠点の 1 つは、OpenID プロバイダー・サービスを公開しているサイトであれば、どのサイトでもユーザーの ID が有効であると主張できることです。そのため、OpenID プロバイダー・サービスを公開しているあらゆるサイトの主張すべてを応答側 (使用している Web サイト) が信頼してしまうという問題があります。公開サイトを無条件に信頼するのを避けるため、Zero ではアプリケーションに OpenID プロバイダーとして信頼してよいサイトを限定するための構成オプションを用意しています。リスト 9 の例にこの構成を有効にする方法を示すともに、指定された openid_url が信頼できないドメインのものである場合の動作を説明します。このような構成は JavaScript コードを使用してクライアント・サイドで行うこともできますが、クライアント上で起こりうる迂回を防ぐためにはサーバー・サイドでの検証も必ず必要となります。

                
@include "openid/rule.config"{
  "openidLoginPage" : "/openidlogin.gt",
  "allowedOpenidDomains" = ["myopenid.com","verisignlabs.com","blueid.bluehost.ibm.com"]
}

このオプションを構成したらアプリケーションを再起動し、信頼できない OpenIDProvider を試してみてください。この例では、「http://myuntrusteduser.someunknownsite.com」という架空の openid_url を使用します。その結果、以下のように openid_url プロバイダーが allowedOpenidDomains のリストに含まれていない場合の例外がクライアントのログに記録されます (図 8 を参照)。

まとめ

OpenID は、アプリケーションでサード・パーティーの認証プロバイダーを利用して認証を行えるようにすることによって、アプリケーションのデプロイメントに一層の柔軟性をもたらします。OpenID のようなプロバイダーがとても盛んに使われるようになったのは、ブログやウィキ、そしてその他のソーシャル・ネットワーキング・アクティビティーを目的とした複数のサイトで 1 つのユーザー・プロファイルを共通して使用したいというユーザーが増えているためです。さらに、ユーザー･クレデンシャルが有効であることを確認するためだけに、ユーザーに同じプロファイル関連の情報を繰り返し提供させることを好まない Web サイトも数多くあります。この連載最終回の記事が Project Zero プラットフォームで OpenID 技術を使用して分散認証を実現する方法を習得するのに役立ったこと、そしてこの連載を通して Zero アプリケーションに重要なすべてのセキュリティー機能を組み込むためのベスト・プラクティスを理解していただけたことを望みます。急速に展開するユーザー主導型 Web 2.0 アプリケーションの開発者であれば、セキュリティーがカスタマーとビジネスの両方にとっていかに重要であるかはご存知のはずです。

参考文献

• OpenID Foundation にアクセスして、認証についての情報、そしてオープン・ソース・コミュニティーのなかで OpenID Foundation が目指している目標を調べてください。
  
  
• この記事では、最もよく利用されている OpenID プロバイダーの 1 つである http://www.myopenid.comと、IBM で OpenID の概念実証として使用されているテスト OpenID プロバイダーを使いました。
  
  
• OpenID.net では、一般的に使用される各種 OpenID プロバイダーをリストしています。
  
  
• 「XML-RPC で C++ アプリケーションを Web サービス対応可能にする」(developerWorks、2006年6月) では、C++ メソッドをサービスとして公開する手順をステップバイステップで案内しています。
  
  
• developerWorks の Architecture エリアで、アーキテクチャー分野でのスキルを伸ばすために必要な資料を入手してください。
  
  
• テクノロジーのブックストアで、この技術やその他の技術に関する本を探してください。
  
  
• Project Zero のセキュリティー構成についての詳しい説明は、Project Zero Developer's Guide を参照してください。
  
  
• この記事では、Eclipse Update Site の適切な Project Zero プラグインがインストール済みであること、そして Eclipse 内で Project Zero アプリケーションを作成する方法を理解していることを前提としています。この前提に当てはまらない場合は、Developer's Guide の「Core Getting Started」ページを参照してください。
  
  
• Project Zero コミュニティーに参加して、この話題のプロジェクトの全容を理解してください。
  
  
• developerWorks Web development ゾーンで、今すぐ Web 2.0 アプリケーションの開発を始めるためのツール、コード、資料を見つけてください。
  
  
• developerWorks Ajax resource center には、Ajax をアプリケーションに組み込んでユーザーの Web エクスペリエンスを劇的に改善するのに役立つ初心者、中級者、上級者向きの情報が豊富に揃っています。
  
  

• WebSphere sMash DE をダウンロードしてください。WebSphere sMash DE には、アプリケーションの開発やテスト、そして限定デプロイメントをサポートするために、App Builder と安定したランタイムが含まれています。
  
  
• IBM 製品の評価版をダウンロードして、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。
  
  
• Project Zero をダウンロードして、この記事で学んだスキルを早速実践してください。
  
  

• ディスカッション・フォーラムに参加してください。
  
  
• developerWorks blogs から developerWorks コミュニティーに加わってください。

著者について

		Todd Kaplinger は IBM Software Group のシニア・ソフトウェア・エンジニアで、現在 Project Zero のセキュリティー・チームでアーキテクト兼チーム・リーダーを務めています。JSP、Servlet、PHP などの Web ベースの技術を専門とする彼は、最近では新たな Web 2.0 技術と企業におけるその影響に注目しています。現在 JSR 223: Scripting for the Java Platform のエクスパート・グループのメンバーであり、さらに Open AJAX Alliance のメンバーとして各種 Ajax フレームワーク実装でのセキュリティーに関するインターオペラビリティーにも取り組んでいます。過去に IBM WebSphere Webcontainer and RRD (Remote Request Dispatcher) プロジェクトのチーム・リーダー兼アーキテクトとして活躍し、Servlet Expert グループの IBM 代表として JSR 154 Servlet 2.5 仕様に関わった経験もあります。彼の連絡先は、todkap@us.ibm.com です。

		Gang Chen は、ISSW (IBM Software Services for WebSphere) の認証コンサルタント I/T スペシャリストです。企業の顧客が e-business アプリケーションを設計、実装する際の支援を専門とする彼は、最近では企業顧客に利益をもたらす新たな Web 2.0 技術に注目しています。IBM Redbook「IBM WebSphere Application Server V6 Scalability and Performance Handbook」の共著者でもあります。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する はてなブックマーク livedoorクリップ del.icio.us Buzzurl（バザール） Choix！ Saafブックマーク FC2ブックマーク MM/memo ニフティクリップ Yahoo!ブックマーク CZブックマーク newsing

上に戻る