レベル: 中級 Todd Kaplinger (todkap@us.ibm.com), Project Zero Architecture & Development, IBM
Simon Kapadia, Security Lead, ISSW EMEA, IBM
Nell Gawor (ngawor@us.ibm.com), Advisory Software Engineer, IBM
2007年 11月 20日
2008年 6月 13日 更新 アプリケーション・リソースのアクセス制御ベースのセキュリティーは、Project Zero のコア機能のうちの 1 つです。Project Zero Security の開発者たちは徹底的に単純化することを念頭に、セキュリティーを素早く簡単に実現できるように務めました。この記事から、Project Zero Security の概要、そしてユーザー・レジストリーを作成する方法、アプリケーションのセキュリティー・ルールを定義する方法、もっともよく使われるベーシック認証とフォーム認証という 2 つのタイプの認証を利用する方法を学んでください。この記事を読み終える頃には、Project Zero アプリケーションにセキュリティーを組み込むために必要なすべての手段が身についているはずです。
編集者からの注記: IBM® WebSphere® sMash および IBM WebSphere sMash Developer Edition は、非常に高い評価を受けた Project Zero のインキュベーター・プロジェクトをベースにしています。Project Zero は WebSphere sMash の開発コミュニティーであり、最新のビルドや、最新の機能、そしてコミュニティーのサポートを利用したアプリケーションを開発するための無料のプラットフォームを今後も提供していきます。
Project Zero のセキュリティーの概要
Project Zero は認証と許可を実装します。アプリケーション開発者が Zero のセキュリティーを利用するには、セキュリティー・ルールを定義する必要があります。セキュリティー・ルールとは、保護対象のリソースとその保護手段、そしてリソースへのアクセスを許可するユーザーとグループを決定する一連のルールのことです。Zero が実装する認証は JAAS (Java™ Authentication and Authorization Service) に基づいているため、認証モデルを変更しなくても各種のログイン・モジュールを追加することができます。
セキュリティーは Project Zero に備わっているコア機能の 1 つです。そのため、ユーザー・サービス・レジストリー関連の構成を正しく設定し、保護するリソースそれぞれに適切なルールを関連付けるだけでセキュリティーを有効にすることができます。この記事は Project Zero をすでに十分理解している中級開発者を対象としているので、Project Zero のセキュリティーを構成することに関するひととおりの概説はDeveloper's Guide を参照してください (「参考文献」にこのガイドへのリンクを記載しています)。
 |
この記事の内容
3 回連載の第 1 回目にあたるこの記事では、Project Zero アプリケーションでデフォルトの構成パラメーターを大々的に変更せずにアクセス制御ベースのセキュリティーを構成する方法について詳しく説明します。この記事では、読者が Project Zero をダウンロード済みであること、そして初心者向けチュートリアルの手順を完了しているか、または単純なアプリケーションを自分自身で作成した経験があることを前提とします。
Project Zero を経験するのは初めてですか? Project Zero は対話型 Web アプリケーションを素早く簡単に開発するための環境を提供します。このプロジェクトが目指しているのは、Web デプロイメントの完全なインフラストラクチャーを実現し、アプリケーション開発者がビジネス・ロジックに専念できるようにすることです。Project Zero の詳細を学ぶには、初心者向けチュートリアル「Get started with Project Zero and PHP」を参照してください (ダウンロード情報も記載されています)。
|
|
この記事では、Eclipse を使用して Project Zero アプリケーションを作成する例を説明します。前提として、Eclipse Update Site の適切な Project Zero プラグインがインストール済みであること、そして Eclipse 内で Project Zero アプリケーションを作成する方法を理解していることが必要です。この前提に当てはまらない場合は、Developer's Guide の「Core Getting Started」ページを参照してからこの記事を読んでください (「参考文献」セクションにリンクを記載)。
アプリケーションの背景
この記事で作成するのは StockTips という極めて単純なアプリケーションで、ごく基本的な株取引についての情報を公開するためのものです。このアプリケーションは「注目株」のリストを維持管理することで成り立っており、「注目株」は株取引のエキスパートによって追加され、管理されます。エキスパートは注目株が市場に新規公開されるとリストに追加し、企業が停滞気味になるとその株をリストから削除します。リストを見るのは投資家たちです。彼らはエキスパートの意見に興味を持ち、まさにその助言に基づいて株の売買を決定します。つまり、投資家のもうけになるかどうかは、エキスパートが適切な助言をできるかどうかに懸かっています!
アプリケーション・コードは、tips.groovy という groovy ファイル (リスト 1)、そして tips.gt というビュー (リスト 2) からなります。
リスト 1. tips.groovy
todos = app.todos.get();
if (todos == null) {
todos = [];
}
if (request.method.get().equals('POST')) {
def action = request.params.action.get();
if (action.equals("Add")) {
def items = request.params.item.get();
if (null != items){
item = zero.util.XMLEncoder.escapeXML(items);
if (null != item && item.size() > 0)
todos.add(item);
}
} else {
def selected = request.params.todos['*'];
for (i in selected)
todos.remove(i);
}
app.todos = todos;
}
request.view = 'tips.gt';
render();
|
リスト 2. tips.gt
<html>
<head>
<title>Stock Market Tips</title>
</head>
<body>
<b>Current hot stock tips:</b>
<br><br>
<form name="input" method="POST">
<% app.todos.get().each { %>
<input type="checkbox" name="todos" value="<%=it%>"> <%=it%> <br>
<% } %>
<br>
<input type="text" name="item">
<input type="submit" name="action" value="Add">
<input type="submit" name="action" value="Delete">
</form>
</body>
</html>
|
図 1 は、アプリケーションのメイン画面です。
図 1. 当初の株取引情報アプリケーション
鋭い読者は、このアプリケーションが Project Zero で最初に作成されたサンプル・アプリケーション、todo と実によく似ていることに気付いたと思います。それは、このコードはそのサンプル・アプリケーションから拝借したもので、ビューだけしか変更されていないからです。コストを削減するための常として、このエキスパートはサンプル・コードを再利用して、製品化するまでの時間を短縮したというわけです。その後、このサンプル・アプリケーションの公開は取りやめられたため、現在では入手できませんが、この記事の中ではそのコードの大部分が紹介されているので、その影響はないはずです。
問題点
残念ながら、todo アプリケーションをそのまま再利用するのは名案でなかったことが判明しました。todo アプリケーションの仕組みでは、アプリケーションの URL にアクセスする誰もが株式を追加したり、削除したりすることができます。最初、数人の友達の間でエキスパートの知恵を分かち合っているだけのうちは非常に有効な仕組みでしたが、投資家たちの輪が広がるにつれ、悪質な輩が現れはじめたのです (図 2 を参照)。この仕組みでは、悪質な投資家のそれぞれが注目株にアクセスして自分たちの利益になる情報を書き留め、それから有益な情報を削除して他人に知られないようにしたり、最悪の場合は情報をでっちあげる可能性さえあります。
図 2. 不当に改ざんされた株取引情報アプリケーション
エキスパートはこの問題に対処するため、Project Zero のセキュリティーについて調べることにしました。
ユーザー・レジストリー
ユーザーを認証するためには、ユーザー・レジストリーにユーザーのリストが保管されていなければなりません。Project Zero で用意している「ユーザー・サービス」ライブラリーは、ユーザー・レジストリーにアクセスするための拡張可能なフレームワークを提供します。サポートされるレジストリー・タイプにはテキスト・ベースのレジストリーや LDAP (ディレクトリー) レジストリーが含まれますが、カスタム・ユーザー・レジストリーを作成する必要がある場合にはユーザー・サービスを拡張することでその要件に対応することができます。どのレジストリー・タイプを選択するかは要件と環境次第です。
- テキスト・ベースのレジストリーは開発時のレジストリーに適しています。
- LDAP は、一段と強化された信頼性およびセキュリティーが重要となる実動環境に推奨されます。
- カスタム・ユーザー・レジストリーは他のレジストリー・システムとの統合に使用することができます。
この記事で使用するのは、ファイル・ベースのレジストリーです。
ファイル・ベースのユーザー・レジストリーを作成する方法
LDAP を構成するには時間がかかり、ある程度の専門知識も必要になることから、Zero では別の形でのユーザー・レジストリーを用意しました。それが、ファイル・ベースのユーザー・レジストリーです。テスト目的でユーザーを作成、更新、追加できるように、zero.core.webtools プロジェクトではユーザー管理用の Web ベースの管理コンソールを用意しています。また、Eclipse Webtools に馴染みがない場合に備え、zero.core.webtools パッケージには Zero アプリケーション開発者がアプリケーションを構築する際に使用できる便利なユーティリティー関数のセットが含まれています。Eclipse 内で Zero アプリケーションを作成すると webtools モジュールへの依存関係がデフォルトで組み込まれるので、アプリケーションを実動設定にデプロイする前に webtools を削除するか、コメント・アウトする必要があります。
アプリケーションを新規に作成した後は、Zero アプリケーションを展開して config ディレクトリーを調べ、zero.core.webtools への依存関係が存在することを確かめてください。config ディレクトリー内には、ivy.xml という名前のファイルがあるはずです。この ivy.xml ファイルをクリックすると、Eclipse にパッケージ情報をリストした ivy.xml のビューが表示されます。図 3 は、このビューの一例です。
図 3. ivy.xml に含まれる Zero.core.webtools
アプリケーションの依存関係のリストに zero.core と zero.core.webtools が含まれていれば、ファイル・ベースのユーザー・レジストリーの作成に取り掛かれます。
アプリケーションを起動するには、アプリケーションを右クリックして Run As > Project Zero Application を選択します (図 4 を参照)。
図 4. Project Zero アプリケーションの実行
アプリケーションが起動するとコンソールのログに情報メッセージが記録され、アプリケーションに関連付けられたポート番号が示されます (図 5 を参照)。
図 5. コンソールに書き込まれたネットワーク・ポート
これで、アプリケーションが HTTP リクエストを受け入れられる状態になりました。ユーザーの作成に取り掛かるには、マシンのホスト名、コンソールのログに記録されたポート番号、そしてサーバーの相対パス /zero/webtools/user/を使って Web ベースの管理コンソールにアクセスします。たいていの場合はデフォルト設定で操作するので、アプリケーションには通常、http://localhost:8080/zero/webtools/user/ でアクセスできます。ここからは、URL に指定するサーバー名とポート番号は、それぞれ localhost、8080 であることを前提とします。
注: この Project Zero アプリケーションのユーザー・サービス・アプリケーションに初めてアクセスすると、ユーザー・サービスが zero.users ファイルにアクセスできないというエラーがコンソールに表示されますが、まったく問題はありません。このファイルはユーザー・サービス・アプリケーションによって作成されるため、いったんファイルが作成されれば、このエラーは表示されなくなります (図 6 を参照)。
図 6. 初回アクセス時のエラーは無視すること
ユーザー・サービス・アプリケーションのコンソールが表示されます (図 7 を参照)。
図 7. ユーザー・サービス・アプリケーション
ユーザーとグループを作成する用意ができました。この例の目的に合わせ、ユーザーを何名か作成します。エキスパートに付けるユーザー名は wizard とします。アプリケーションを使用する投資家は彼の友達である、Alice、Bob、Charlie、Dave です。彼らのユーザー名には、ファーストネームだけを使います。ユーザー wizard は wizards というグループに入れ (IPO の後に簡単に wizards を追加できるようにするためです)、その他のユーザーは pundits というグループに入れます。
まずはユーザー wizard を作成してみましょう。Add User フォームの UserName に wizard と入力してパスワードを指定し (有効なパスワードを使うことを忘れないでください)、Groups には wizards を指定します (図 8 を参照)。
図 8. ユーザー「wizard」の追加
以上のステップを繰り返して残りのユーザーを作成します。ただし、この場合はユーザーを pundits というグループに入れてます。このようにして、Alice、Bob、Charlie、Dave のそれぞれにユーザー ID を作成し終わると、ユーザー・リストは図 9 のようになっているはずです。
図 9. 完成したユーザー・リスト
ユーザーおよびグループ
ユーザーとグループのメンバーを追加するということはつまり、もっとも基本的なレベルで言うと、zero アプリケーションの config ディレクトリーにある zero.users ファイルにデータを入力するということです。では、このファイルの内容を見てみましょう。
リスト 3. zero.users ファイル
wizard:5f4dcc3b5aa765d61d8application327deb882cf99:wizards
alice:6384e2b2184bcbf58eccf10ca7a6563c:pundits
bob:9f9d51bc70ef21ca5c14f307980a29d8:pundits
charlie:bf779e0933a882808585d19455cd7937:pundits
dave:1610838743cc90e3e4fdda748282d9b8:pundits
|
このファイルは、各行 3 つの値がコロンで区切られたリストでしかありません。この値はそれぞれ、ユーザー名、エンコードされたパスワード、ユーザーがメンバーとして属するグループを示します。「ファイル・レジストリー」はこのような 1 つのファイルでしかありません。ユーザーが大勢いたとしても、このファイルなら大きくならないはずです。
ユーザーとグループはこれでファイル・ベースのユーザー・レジストリーに作成されたので、今度はセキュリティー・ルールの定義に取り掛かります。
セキュリティー・ルールの定義
|
正規表現
特定の URI Stem を保護するという基本オプションの他、正規表現パターンと同じ URI 属性を設定してリソースを保護することも可能です。例えばアプリケーションの /protected ディレクトリー配下にあるすべてを保護対象にするには、"conditions" : "/request/path =~ /protected(/.*)?" のようにルールを記述します。構文で使用するのは、目的のストリング・パターンとの突き合せ手段として非常に強力な PRCE (Perl Compatible Regular Expressions) です。
正規表現の威力が原因で URI 空間の一部を保護しないルールを作成してしまう可能性があります。また、Project Zero のデフォルト・インデックスの機能による副次作用も見過ごしやすいものです。これは /foo/ にアクセスすると /foo/index.html (存在する場合) を提供する機能ですが、例えば "/request/path == /foo/index.html" というルールを作成してあるのに誰かが手動で /foo にアクセスすると、後者の /foo は同じリソースであるにも関わらず保護されません。このような理由から、保護リソースは共通エリアにグループ化し、共通エリアとそこに含まれるすべてのものを保護することをお勧めします。したがって、推奨されるパターンは常に "/request/path =~ /prefix(/.*)?" となります。こうすれば、保護が必要なすべてのリソースを確実に適用対象とすることができます。
|
|
エキスパートはユーザーとグループを追加しましたが、ユーザーがアプリケーションにアクセスするにはまずログインする必要があります。デフォルトでは許可には制約がなく、どのコンテンツも保護されていません。アプリケーション全体やその一部を保護するためには、セキュリティー・ルールを定義する必要があります。セキュリティー・ルールでは、保護対象のリソース、リソースを保護するための認証のタイプ、そしてアクセスを許可する対象のユーザーやグループ、それにロール (役割) を指定します。
条件 (conditions) 節を使用すると、ユーザーはリソースをセキュアにするためのさまざまな制約を定義できるようになります。この例では、グローバル・コンテキストである /request/path をキーとして使用しており、このキーがアプリケーションにアクセスする際にブラウザーに入力するコンテキスト相対パスになります。またこのキーは、Project Zero で保護できるリソースの基本レベルでもあります。アプリケーションのメイン・ページにアクセスするための URI を保護する場合、指定された一連の条件と一致するルールの定義が必要となります。それには、アプリケーションの config フォルダーに含まれる zero.config ファイルを開き、リスト 4 に記載された行をファイルに追加してください。
リスト 4. zero.config に追加する更新
@include "security/rule.config"{
"conditions" : "/request/path == /tips.groovy",
"authType" : "Basic",
"groups" : ["wizards", "pundits"]
}
|
最初の行は各ルールの前に置かれるもので、適切なテンプレートをインポートします。これにより、ランタイムはセキュリティー・ルールが構成されていることを認識します。2 行目の conditions はこのセキュリティー・ルールを適用する条件を実際に定義しています。上記の例では、パターンではなく、ある 1 つの URI を保護するように指定しています。3 行目の authType は使用する認証のタイプを指定する行です。追加構成が必要ないことから、この例では HTTP ベーシック認証 (次のセクションで詳細を説明) を使用します。最後の groups の行は、保護されたページへのアクセスが許可されるグループを指定します。この例では wizards および pundits グループすべてのメンバーにアクセス許可が与えられることになります。これまでに作成したすべてのユーザーはこの 2 つのグループのいずれかに含まれるため、その全員にアクセスが許可されるというわけです。更新し終わったらファイルを保存し、Zero サーバーを再起動して更新された構成が適用されるようにしてください。
Zero に組み込まれている認証タイプは、基本認証、フォーム認証、SSO 認証の 3 つです。この記事ではそのうちの 2 つ、ベーシック認証とフォーム認証について説明します。SSO 認証については、Zero の資料 (「参考文献」を参照) で詳細を調べてください。
ベーシック認証
注: HTTP ベーシック認証はユーザーを認証する方法として十分ではないため、実際の実動デプロイメントには使うべきではありません。その理由の 1 つとして、ユーザーが自分のユーザー名とパスワードを指定すると、この情報は単にエンコードされてサーバーに送られ (暗号化はされず、とても簡単にデコードできるようにエンコードされます)、それ以降はこのサーバーに対してリクエストを行うたびにエンコードされたユーザー名とパスワードが送られます。
これには二重の意味あいがあります。まず、該当するサーバーとの「セキュアな」トラフィックがインターセプトされるとユーザーの実際のユーザー名とパスワードが明らかになってしまいますが、ユーザー名とパスワードはユーザーが明示的に変更するまで無効になりません (これは、認証に cookie を使用する一般的な手法とは対照的です。cookie が有効なのは短時間の間 (通常は 1、2 時間) だけで、その後は役に立たなくなります)。さらに重要な点として、ベーシック認証でユーザーを認証した場合、そのユーザーをログアウトすることができなくなります。これは、認証済みユーザーが新しいリソースにアクセスするたびにブラウザーがそのユーザー名とパスワードを再度提供してしまうためです。ユーザーがログアウトするには物理的にブラウザーを閉じるしかありません。これはユーザーが取るべき当然の手段ですが、素直にこれを実行しないユーザーは大勢います。
クレデンシャル
現時点で StockTips アプリケーションのホーム・ページにアクセスしようとすると、ブラウザーはクレデンシャルを入力するよう求めてくるはずです。アクセス権を得るためには、指定されたいずれかのグループのメンバーである (users ファイルに含まれる) 有効なユーザーのユーザー名とパスワードを入力します (図 10 を参照)。
図 10. ベーシック認証のダイアログ
レルム
リソースがベーシック認証によって保護されている場合、ブラウザーはユーザーに対し、リソースへのアクセスに必要なクレデンシャルを提示するよう求めます。ベーシック認証は Zero に組み込まれている認証タイプのなかで追加構成が不要な唯一のタイプですが、/config/security/realm を使用すれば、ブラウザーが表示する「レルム」を明示的に指定することができます。リスト 5 はその一例です。
リスト 5. ベーシック認証のレルム名の構成
[/config/security]
realm=Private Hot Stock Tips
|
ブラウザーがユーザーにクレデンシャルを求めるときには、指定されたこのレルムが表示されます。
図 11. 「Private Hot Stock Tips」レルム
フォーム認証
フォーム認証では、フル・ページのフォームでログインを行います。この認証を実装するには、public フォルダーに login.html という名前の新規ファイルを追加してリスト 6 のテキストを貼り付けてください。
リスト 6. フォーム認証のログイン
<html>
<form method="POST" action="">
<input type="text" name="zeroUserName">Username</input><BR>
<input type="password" name="zeroPassword">Password<BR>
<input type="submit" value="Submit"/>
</form>
</html>
|
リスト 6 で重要なのは、ユーザー名とパスワードのフィールド名です。フォームが送信されると、Zero はこのフィールド名によって 2 つのフィールドを識別するからです。次に zero.config を編集します。リスト 7 のスタンザを追加して、作成したログイン・フォームの場所を指定してください。
リスト 7. フォームを参照するための zero.config の更新
@include "security/form.config"{
"formLoginPage" : "/login.html"
}
|
さらに、先ほど定義したセキュリティー・ルールで authType : "Basic" の行を authType : "Form" に変更した後、Zero アプリケーションを再起動して構成の変更を適用させます。これで、http://localhost:8080/tips.groovy を指定してアプリケーションにアクセスすると、作成したフォームが表示されるようになります。有効なユーザーのクレデンシャルをもう一度入力すると、ページにアクセスできるはずです。図 12 に、このログイン・フォームを示します。
図 12. ログイン・フォーム
フォーム認証は HTTP ベーシック認証に比べ、以下のようなさまざまな点で大きな利点があります。
- ログイン・ページのルック・アンド・フィールを構成することが可能です。つまり、ログイン・フォームは実際の Web ページなので、フォームの基本的な機能が維持されている限り、HTML を自在にカスタマイズできます。
- フォーム認証では、エンコードしたユーザー名とパスワードをリクエストのたびにクライアント・ブラウザーから送信させるのではなく、cookie を使用して認証を行うことになります。この cookie が有効なのはブラウザー・セッション中だけなので、cookie が盗まれたとしてもユーザー名とパスワードが明らかになることはありません。
- フォーム認証はあらゆる Web ページに組み込むことが可能で (アプリケーションの URI にサブミットするだけの HTML フォームでしかないため)、それによってユーザー・エクスペリエンスを改善することができます。
高度な許可
ここまでのところでエキスパートは StockTips アプリケーション用に認証を構成しました。そこで行われる許可は、ユーザーがアプリケーションにアクセスする際には認証が必要であるという単純なものです。しかし、現時点では情報を見たいだけのメンバーが含まれる「pundits」グループと、更新を行う必要があるメンバーが含まれる「wizards」グループはまったく区別されません。このような、グループによってアクションが異なる場合に許可の決定を行うには、アクションごとに異なる許可制約を指定し、表示内容を選択する際にプログラムがグループ・メンバーに応じて実際の許可を決定するようにします。
許可制約
前述したように URI をベースにアクセスを保護するだけでなく、HTTP メソッドを基準としてリソースを保護することも可能です。例えば、HTTP GET リクエストにはリソースを開放する一方、PUT、POST、DELETE リクエストに対してはリソースを保護したいという場合、(/request/method == [PUT|POST|DELETE]) の conditions 行 (条件は「and」節の場合は && で区切られ、「or」節の場合は || で区切られます) に条件節を追加すれば、このルールが該当するメソッドにだけ適用されます。
StockTips アプリケーションは GET リクエストによって情報を表示しますが、更新を受け入れるにはフォームの POST を使用します。この機能を利用すれば、正しいグループだけに情報の更新を許可することができます。それには、HTTP GET リクエストの使用をすべてのグループに許可し、HTTP POST リクエストの使用は wizards グループのみに許可するように zero.config ファイルを変更してください。zero.config ファイルの更新はこれが最後です。この更新を行うと、ファイル全体はリスト 8 のようになります。
リスト 8. 最終的な zero.config
[/config/http]
port=8080
[@include ${zero.core}/config/security/form.config]
formLoginPage=/login.html
[@include ${zero.core}/config/security/rule.config]
uri=/tips.groovy
authType=Form
methods=GET
groups=[wizards,pundits]
[@include ${zero.core}/config/security/rule.config]
uri=/tips.groovy
authType=Form
methods=POST
groups=[wizards]
[/config/security]
realm=Private Hot Stock Tips
|
この構成では、wizards および pundits グループの誰もがアプリケーションの URL (/tips.groovy) に対して GET を実行できますが、POST を実行できるのは「wizards」グループのメンバーだけとなります。したがって、変更を加えられるのは唯一 wizards だけです。特定のグループに対してアクセスを制限するだけでなく、特定のユーザーとロールに対してアクセスを制限することもできます (ロールについての詳細は、「参考文献」に記載している Project Zero 資料へのリンクを参照してください)。また、ALL_AUTHENTICATED_USERS という特殊なグループを使用すると、正常にログインしたすべてのユーザーにアクセスを与えることができます。
プログラムによる許可
この時点で、株取引情報を変更できるのはエキスパートに限られ、その情報を読めるのは指定した投資家だけに制限されました。このシナリオはほぼ完璧に近いものの、まだ完全とは言えません。なぜなら、投資家が実際に変更を加えることはできませんが、アプリケーションのインターフェースには Add や Delete などの変更を行うためのフィールドが含まれているためです。もちろん、wizards グループに属さないユーザーにはフォームの POST の実行が許可されないため、Add や Delete をクリックしてもフィールドは機能しませんが、機能しないフィールドは始めから表示しないに越したことはありません。
都合のいいことに、Project Zero ではプログラムによって認証済みユーザーを識別し、コード内でユーザー名、ユーザーが属するグループ、ユーザーに与えられたロールに基づいて決定を行うようにできます。認証が成功すると、以下のフィールドが Global Context 内で使えるようになります。
/request/subject['remoteUser']
/request/subject['groups']
|
StockTips アプリケーションでは、エキスパートがこの情報を使ってアプリケーションの Web ページ上で情報を追加、削除するためのグラフィカル･インターフェース・ウィジェットを表示するかどうかを決定することができます。request.view = 'tips.gt'; の行はリスト 9 の内容に置き換えてください。
リスト 9. グループごとに異なるビューを表示するための StockTips の更新
if(request.subject['groups'].contains("wizards")){
request.view = 'wizards.gt';
} else if(request.subject['groups'].contains("pundits")){
request.view = 'pundits.gt';
} else request.view = 'tips.gt';
|
今度は新しい 2 つのビューを追加します。1 つは元の tips.gt とまったく同じ wizards.gt、そしてもう 1 つは大幅に機能が削減された pundits.gt です (リスト 10 を参照)。
リスト 10. pundits.gt
<html>
<head>
<title>Stock Market Tips</title>
</head>
<body>
<b>Current stock tips:</b>
<br>
<ul>
<% app.todos.get().each { %>
<li><%=it%></li>
<% } %>
</ul>
<br>
</body>
</html>
|
これで wizards グループに属する wizard としてログインすると、株取引情報を追加、削除するためのボタンがすべて揃った完全なアプリケーションが表示されます (図 13 を参照)。
図 13. 「wizards」グループの wizard としてログインした場合
一方、pundits グループにしか属していない alice としてログインした場合は、機能が削減されたアプリケーションが表示されます (図 14 を参照)。
図 14. 「pundits」グループの alice としてログインした場合
まとめ
この記事では、Project Zero でセキュリティー･ランタイムを有効にしてアプリケーションを保護するために必要なすべてのステップを網羅しました。まず説明したのはユーザー・レジストリーを設定する方法、そして 2 つのユーザー認証方法 (ベーシック認証とフォーム認証) です。次にアプリケーション内からユーザー、グループ、ロールの情報を取得して、宣言による許可とプログラムによる許可を行うためのセキュリティー・ルールを定義しました。Project Zero Security で LDAP または OpenID を利用する方法をそれぞれ説明する第 2 回、第 3 回の連載もお見逃しなく。
参考文献 学ぶために
-
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 エクスペリエンスを劇的に改善するのに役立つ初心者、中級者、上級者向きの情報が豊富に揃っています。
製品や技術を入手するために
議論するために
著者について | 
| | 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 仕様に関わった経験もあります。 |
| 
| | Simon Kapadia は EMEA (Europe, Middle East, Africa) ISSW (IBM Software Services for WebSphere) のセキュリティー主任として、IBM の顧客を対象とした大規模な分散コンピューティング・システムの設計と実装に取り組んでいます。彼は英文戯曲で学士号、電子計算学で修士号を取得しました。6 歳の頃からコンピューターを持っていた彼は、この生涯の趣味を仕事にしています。IBM に入社する以前は、Bell Laboratories でデジタル交換機向けソフトウェアの開発、ISP でネットワークおよび Web アプリケーションの管理、そして Transarc Corporation で DCE、DFS、Encina のサポートとコンサルティングを行っていました。連絡先は simon.kapadia@uk.ibm.com です。または彼の公式 Web サイト、http://www.kapadia.pl からも連絡できます。 |
| 
| | Nell Gawor は、ノースキャロライナ州 Research Triangle Park にある IBM で Project Zero チームの顧問ソフトウェア・エンジニアを務めています。彼女は Urbana-Champaign のイリノイ州立大学でコンピューター・サイエンスの修士号を取得しました。 |
記事の評価
| 
