レベル: 初級 Todd Kaplinger (todkap@us.ibm.com), WebContainer and RRD Architect, IBM
Hiroyuki (Hiro) Tarusawa (hirot@jp.ibm.com), Project Zero Technical Consultant, IBM Japan, Ltd.
Simon Kapadia, Technical Team Lead, IBM
2008年 2月 05日 アプリケーション・リソースのアクセス制御ベースのセキュリティーは、Project Zero のコア機能のうちの 1 つです。Project Zero Security の開発者たちは徹底的に単純化することを念頭に、セキュリティーを素早く簡単に実現できるように努めました。3 回連載の第 2 回目となるこの記事では、Project Zero Security の詳細を掘り下げ、ユーザー・レジストリーを作成する方法、アプリケーションにセキュリティー・ルールを定義する方法、そして LDAP ユーザー・レジストリーを利用する方法を説明します。
編集者からの注記: IBM® WebSphere® sMash および IBM WebSphere sMash Developer Edition は、非常に高い評価を受けた Project Zero のインキュベーター・プロジェクトをベースにしています。Project Zero は WebSphere sMash の開発コミュニティーであり、最新のビルドや、最新の機能、そしてコミュニティーのサポートを利用したアプリケーションを開発するための無料のプラットフォームを今後も提供していきます。
LDAP を利用した高度なユーザー・レジストリー
Project Zero は認証と許可を実装します。アプリケーションで Zero のセキュリティーを利用するには、セキュリティー・ルールを定義する必要があります。セキュリティー・ルールとは、保護対象のリソースとその保護手段、そしてリソースへのアクセスを許可するユーザーとグループを決定する一連のルールのことです。Zero が実装する認証は JAAS (Java Authentication and Authorization Service) に基づいているため、認証モデルを変更しなくても各種のログイン・モジュールを追加することができます。
セキュリティーは Project Zero に備わっているコア機能の 1 つです。この Zero Security というコア機能により、ユーザー・サービス・レジストリー関連の構成を適切に行い、保護するリソースそれぞれに該当するルールを関連付けるだけでセキュリティーを有効にすることができます。この記事は Project Zero をすでに十分理解している中級開発者を対象としているので、Project Zero についての予備知識が必要な方、あるいは基礎知識を増やしたいという方は、Project Zero Security の構成に関するひととおりの概要が記載されている Developer's Guide、または連載第 1 回目の「認証と許可」を参照してください。今回の記事では、LDAP をユーザー・レジストリーとして使って Project Zero のセキュリティーを利用するようにアプリケーションを構成する方法を詳しく説明していきます。
 |
この記事の内容
3 回連載の第 2 回目となるこの記事では Project Zero Security の詳細を掘り下げ、ユーザー・レジストリーを作成する方法、アプリケーションのセキュリティー・ルールを定義する方法、そして LDAP ユーザー・レジストリーを利用する方法を説明します。この記事では、読者が Project Zero をダウンロード済みであること、そして初心者向け演習の手順を完了しているか、または単純なアプリケーションを自分で作成した経験があることを前提とします。 |
|
ユーザー・サービス
ユーザー・サービスとは、ユーザー・レジストリーにアクセスするための拡張可能フレームワークとなるライブラリーのことです。サポートされるレジストリー・タイプはテキスト・ファイルおよび LDAP (ディレクトリー) ですが、カスタム・ユーザー・レジストリーを作成する必要がある場合にはユーザー・サービスを拡張することでその要件に対応できます。どのレジストリー・タイプを選択するかは要件と環境によって決まります。
- テキスト・ファイルのレジストリーは開発時のレジストリーに適しています。
- LDAP は、一段と強化された信頼性およびセキュリティーが重要となる本番環境に推奨されます。
ユーザー・サービスは Project Zero セキュリティー・ランタイムとユーザー・レジストリーの間にある抽象化層で、zero.config ファイルの/config/security/userservice スタンザを編集すれば適切なユーザー・レジストリーを選択することができます。この記事では、ユーザー・サービスが LDAP ベースのユーザー・レジストリーにアクセスするように構成する方法を説明します。ファイル・ベースのユーザー・レジストリーについて学びたい場合は、ファイル・ベースのユーザー・サービスを利用した Project Zero セキュリティーの概要を説明している第 1 回の「認証と許可」を読んでください。
前回までのあらすじ
この記事は第 1 回目の記事「認証と許可」の続きなので、前回と同じく、Eclipse Update Site の適切な Project Zero プラグインがインストール済みであること、そして Eclipse 内で Project Zero アプリケーションを作成する方法を理解していることが前提となります。この前提に当てはまらない場合は、Developer's Guide の「Core Getting Started」ページを参照してからこの記事を読んでください。
前回の記事でも説明したように、この連載で取り上げるのは StockTips という極めて単純なアプリケーションで、ごく基本的な株取引についての情報を公開するためのものです。このアプリケーションは「注目株」のリストを維持管理することで成り立っており、「注目株」は株取引のエキスパートによって追加され、管理されます。エキスパートは注目株が市場に新規公開されるとリストに追加し、企業が停滞気味になるとその株をリストから削除します。リストを見るのは投資家たちです。彼らはエキスパートの意見に興味を持ち、その助言に基づいて株の売買を決定します。つまり、投資家のもうけになるかどうかは、エキスパートが適切な助言をできるかどうかに懸かっています。
アプリケーション・コードは、tips.groovy という groovy ファイル、そして tips.gt というビューからなります。この記事では主に Project Zero で LDAP を有効にする方法に注目するので、限られた数のスクリーンショットしか記載しません。コードの詳細については第 1 回目の記事を参照していただくことにして、今回はさまざまな方法で LDAP を利用するために必要な構成に焦点を絞ります。
第 1 回目の記事が掲載されてから、エキスパートの株取引情報サイトには新しい購読者が殺到しています。このサイトはかなりの評判となり、投資家の数も増えたことから、エキスパートはファイル・ベースのユーザー・レジストリーからエンタープライズ機能が強化された LDAP ユーザー・レジストリーに移行することに決めました。この移行により、今まで局所的に使用されていたアプリケーションを世界規模で使用されるアプリケーションに拡大するのが目的です。ユーザーはファイル・ベースのユーザー・レジストリーから LDAP ベースのユーザー・レジストリーにマイグレートされるだけなので、すべての投資家は以前と変わらず「pundit」という 1 つのグループに所属することになります。
ファイル・ベースのユーザー・サービスから LDAP ユーザー・サービスへのマイグレーション
LDAP ユーザー・サービスの構成を調べる前に、まずは LDAP ディレクトリー・サーバーにディレクトリーを用意する必要があります。最初の例で使用するのは、図 1 に示す単純なディレクトリーです。このディレクトリーでは、10 人のユーザーが「pundits」グループに属し (表 1 を参照)、「wizard」という特殊なユーザーは「wizards」のメンバーとなっています。ディレクトリーを作成するには、LDAP ディレクトリー・サーバーにルート・サフィックスdc=myco,dc=com を作成し、次に「ダウンロード」セクションからmyco.startingpoint.ldif という LDIF (LDAP Data Interchange Format) ファイルをダウンロードして LDAP ディレクトリー・サーバーにインストールします (LDAP サーバーにルート・サフィックスを作成する方法については、お使いの LDAP ディレクトリー・サーバーのマニュアルを参照してください)。LDIF ファイルのインポートには、Apache Directory Studio、JXplorer などの LDAP ツールを使用することができます (「参考文献」にダウンロード・サイトへのリンクを記載しています)。LDAP ユーザー・サービスは、特定の LDAP ディレクトリー・サーバーやツールには依存しません。
LDAP ディレクトリーに含まれるそれぞれの要素は、サブツリーの下で一意に決まる相対識別名 (RDN) によって識別することができます。さらに、各要素は識別名 (DN) を持っています。DN は末端の当該要素からルート要素まで、すべての RDN を連結したものなので、ディレクトリー全体で一意に決まります。つまり DN は、LDAP ディレクトリー内の完全修飾名となります。例えばuid=mary,ou=people,o=hq,dc=myco,dc=com は DN で、そのプリフィックスである uid=mary は RDN です。LDAP についてさらに調べるには、IETF Web サイト (「参考文献」を参照) にアクセスしてください。
表 1. 最初のサンプル・ディレクトリーでのユーザーとグループのマッピング
LDAP ユーザー・サービスはデフォルトで、オブジェクト・クラスinetOrgPerson を用いて定義されたエントリーをユーザー・エントリーと見なし、uid 属性の値をユーザー名と見なします。グループと見なすのは、オブジェクト・クラスgroupOfUniqueNames を用いて定義されたエントリーで、この場合、cn 属性の値をグループ名と見なします。「ダウンロード」セクションに記載された LDIF ファイル、myco.startingpoint.ldif が定義する内容は以下のとおりです。
- ou=people,o=hq,dc=myco,dc=com の下に定義された「pundits」グループのメンバーである、以下の 10 人のユーザー名とパスワード
- ユーザー名 mary とそのパスワード mary_pwd
- ユーザー名 dan とそのパスワード dan_pwd
- ユーザー名 ryan とそのパスワード ryan_pwd
- ユーザー名 baxter とそのパスワード baxter_pwd
- ユーザー名 bob とそのパスワード bob_pwd
- ユーザー名 steve とそのパスワード steve_pwd
- ユーザー名 tim とそのパスワード tim_pwd
- ユーザー名 john とそのパスワード john_pwd
- ユーザー名 ken とそのパスワード ken_pwd
- ユーザー名 michael とそのパスワード michael_pwd
- 特殊ユーザー「wizard」も同じく ou=people,o=hq,dc=myco,dc=com の下にありますが、このユーザーは「wizards」グループのメンバーです。
- ユーザー名 wizard とそのパスワード wizard_pwd
図 1. 最初の時点でのサンプル・ディレクトリー
zero.config は Project Zero の中核となる構成を保管するテキスト・ファイルで、<approot>/config に配置されます。Zero のセキュリティーを有効にして LDAP ディレクトリーでリクエストを認証するには、この zero.config ファイルに「/config/security/userservice」にある構成スタンザを追加してください (リスト 1 を参照)。
リスト 1. zero.config のスニペット－単純なサンプル・ディレクトリーの場合のユーザー・サービス構成
/config/security/userservice/registryType="ldap"
/config/security/userservice/ldap += {
"jndiProviderUrl":"ldap://localhost:10389/",
"jndiSecurityPrincipal":"uid=admin,ou=system",
"jndiSecurityCredentials":"<xor>LDo8LTor",
"ldapUserIdRdnPattern":"uid={0}",
"ldapUserIdBaseDn":"ou=people,o=hq,dc=myco,dc=com",
"ldapGroupBaseDn":"ou=group,o=hq,dc=myco,dc=com"
}
|
リスト 1 の詳細は以下のとおりです。
-
registryType は、使用するレジストリーのタイプを指定するパラメーターです。上記では LDAP レジストリーのタイプを使用するために「ldap」を設定しています。
-
jndiProviderUrl は、LDAP ディレクトリー・サーバーの URL のプロパティーです。この例では、LDAP サーバーはポート 10389 の「localhost」マシンで稼動しています。
-
jndiSecurityPrincipal は、ディレクトリー・サーバーに接続するために使用するプリンシパル (ユーザー名) を定義します。ここでのプリンシパルは、uid=admin,ou=system です。
-
jndiSecurityCredentials は、ディレクトリー・サーバーに接続するために使用するクレデンシャル (パスワード) を定義します。ここで使用するパスワードは xor でエンコードした値、LDo8LTor です。
-
ldapUserIdRdnPattern は、ディレクトリー・サーバーでユーザーを検索するために使用する RDN テンプレート・パターンを指定します。ユーザー・サービスは実行時に、リクエストのユーザー名をプレースホルダー「{0}」に入力します。その上でldapUserIdRdnPattern にldapUserIdBaseDN を連結して DN を作成し、ディレクトリーでユーザー・エントリーを検索します。上記の例では、ユーザーの検索にuid= プレースホルダーに埋め込まれたユーザー名とou=people,o=hq,dc=myco,dc=com (ldapUserIdBaseDn から取得) を組み合わせた文字列が使われることになります。
-
ldapUserIdBaseDn は、ユーザーの検索を開始する場所の LDAP DN です。検索ではこれを DN として使用します。
-
ldapGroupBaseDn は、グループの検索を開始する場所の LDAP DN です。グループの検索ではこれを使用します。
クレデンシャルについては、平文で指定する代わりに、正直者の心を惑わせることがないように上記の例のように xor エンコード方式でエンコードすることができます。ただし、これは実際に暗号化されたクレデンシャルではないので、パスワードを暴くのは簡単だということに注意してください。エンコードの目的は、平文ではないパスワードを保管して、誰かが管理者の肩越しにパスワードを盗み見ても記憶するには厄介だと思わせることです。ディレクトリー・サーバーが匿名のアクセスを許可する場合には、zero.config からjndiSecurityPrinciple およびjndiSecurityCredentialsパラメーターを削除することができます。その詳細については、この後、説明します。
zero.config ファイルに含まれる LDAP ユーザー・サービス関連のパラメーター
Zero では、zero.config ファイルの /config/security/userservice スタンザの下にあるパラメーターを使って LDAP ユーザー・サービスを構成することができます (以下を参照)。ただし、すべてのパラメーターを設定する必要はありません。一部のパラメーターに設定されたデフォルト値は、私たちの環境でそのまま使用できるからです。LDAP ユーザー・サービスを構成する上での重要なポイントについては、以降のセクションで説明します。
表 2. zero.config に含まれる LDAP ユーザー・サービスのプロパティー
注: 上記の表には、この記事を作成した時点でのすべての構成パラメーターを記載しています。最新のパラメーター・リストについては、Developer's Guide の「Configuring the LDAP user service in the zero.config file」セクションを参照してください。
LDAP へのマイグレーションを検証する方法
これまでのところで、任意のツールを使って LDAP リポジトリーを構成し、上記で説明したように構成を変更しました。ここで、これまで行った構成が適切に機能することを確認します。まず始めに使うのは、前回の記事で登録した既存のユーザー、Wizard です。アプリケーションを起動し、tips.groovy にアクセスしに行くことで、認証プロセスをもう一度開始します。Wizard が注目株の情報を追加、削除できることを確認してください (図 2 を参照)。
図 2. 「wizards」グループの Wizard としてログインした場合
ブラウザーを閉じ、再び tips.groovy にアクセスしに行くことで、ログイン・プロセスを開始します。ただし今回は、Alice (同じく前回の記事で登録したユーザー) としてログインします。Alice の場合に可能な操作は、注目株情報の表示のみであることを確認してください (図 3 を参照)。
図 3. 「pundits」グループの Alice としてログインした場合
ここまでのところで学んだ LDAP のまとめ
この時点で、LDAP リポジトリーを構成して既存のファイル・ベースのユーザー・レジストリーから既存のユーザーを移植する上での難しい部分は完了しました。ユーザーを新しいリポジトリーに移植しただけでなく、アプリケーションのユーザー・プロファイルと認証ストアにも LDAP リポジトリーが使用されるようにアプリケーションを構成する作業も済んでいます。
LDAP を使用した投資家のグループ分け
投資家の数が増えたことから、エキスパートはサイトのユーザーを、投資家に関連付けられた 5 つのグループにさらに分類することにしました。このようにすれば、エキスパートはユーザーが所属するグループに応じて、さまざまなサービス品質レベルを提供することができます。グループ分けのプロセスは前回投資家とエキスパートとを区別するために行っているので、それほど難しくないはずです。表 3 に、これから再構成する LDAP リポジトリーでのユーザーとグループのマッピング案を記載します。この記事の案に従う場合は、myco.simple.ldif という名前の LDIF (LDAP Data Interchange Format) ファイルをダウンロードして、LDAP ディレクトリー・サーバーにインポートしてください。
表 3. 単純なサンプル・ディレクトリーでのユーザーとグループとのマッピング
- ou=group,o=hq,dc=myco,dc=com の下には以下の 5 つのグループ名が定義されています。
- sages
- bards
- oracles
- savant
- master
- 各ユーザー名は 1 つのグループに属します。
- 「mary」と「dan」は「sages」に所属
- 「ryan」と「baxter」は「bards」に所属
- 「bob」と「steve」は「oracles」に所属
- 「tim」と「john」は「savant」に所属
- 「ken」と「michael」は「master」に所属
図 4. 単純なサンプル・ディレクトリー
新たに構成したグループを活用するため、ここでロールの概念を導入してリソースをセキュアにします。新しいグループはそれぞれに「pundits」に関連付けられているので、前回使ったグループという手段ではなくロールを使用することで、リソースをセキュアにするためにこのグループ分けを引き続き使用することができます。Project Zero でのロールは、一連のユーザーまたはグループを共通の名前で集約する手段として使われます。以下の構成には、2 つの小さな変更を加えました。最初の変更を加えた箇所は、以前、GET メソッドのセキュリティー・ルールを「pundits」グループまたは「wizards」グループいずれかのユーザーを対象にして構成した部分です。今回は、「wizards」グループのユーザーあるいは「pundits」ロールのユーザーを対象としたセキュリティー・ルールを構成します。「pundits」ロールは、「sages」、「bards」、「oracles」、「savant」、および「master」グループで構成されます。今後、ユーザーを「pundits」タイプの他のグループにさらに細かくサブグループ化する必要が出てきたら、「pundits」ロールを更新して、その新しいグループを zero.config に含めるだけで済みます。この場合、コードを変更する必要はまったくありません。
リスト 2. 新たにロールの概念を利用するように更新した zero.config
/config/http/port=8080
/config/security/realm="Private Hot Stock Tips"
/config/security/roles/pundits/groups=["sages", "bards", "oracles", "savant", "master"]
@include "security/form.config"{
"formLoginPage" : "/login.html"
}
@include "security/rule.config"{
"conditions": "(/request/path =~ tips.groovy(/.*)?) && (/request/method == GET)",
"authType":"Form",
"groups":["wizards"],
"roles": ["pundits"]
}
@include "security/rule.config"{
"conditions": "(/request/path =~ tips.groovy(/.*)?) && (/request/method == POST)",
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
"authType":"Form",
"groups":["wizards"]
}
|
以下のリスト 3 でも、グループの代わりにロールを使用するように groovy コードに小さな変更が加えられています。連載の前回の記事 (「プログラムによる許可」のセクション) では、「groups」と「remoteUser」というリクエスト・サブジェクトの 2 つのキー属性について概説しましたが、そのときに取り上げなかったリクエスト・サブジェクトの 3 番目の属性が「roles」です。この属性には、ユーザーがロールのメンバーである場合、そのユーザーがメンバーとなっているロールのリストが含まれます (「groups」にも同様のルールが適用されます)。
リスト 3. グループとロールに基づいて異なるビューを表示するように更新した株取引情報
if(request.auth.subject.groups[].contains("wizards")){
request.view = 'wizards.gt';
} else if(request.auth.subject.roles[].contains("pundits")){
request.view = 'pundits.gt';
} else request.view = 'tips.gt';
|
LDAP リポジトリーの再構成を検証する方法
任意のツールで LDAP リポジトリーを構成し、上記の説明に従って構成を変更したところで、再びこれまで行った構成が適切に機能することを確認してみましょう。現時点では、「Wizard」が注目株の情報を追加、削除し、「pundits」ロールのグループに属するすべてのユーザーが株のリストを表示できるはずです。記事を簡潔にするため、ここで行った変更が実際に機能することをまず検証してから、それぞれの変更がどのようにアプリケーションに影響するかに焦点を当てることを提案します。ここで行ったことの要点を、次の「ここまでのところで学んだ LDAP のまとめ」のセクションで取り上げた後、残りのセクションで今まで検討してきた概念を検証することにします。
ここまでのところで学んだ LDAP のまとめ
これで、ユーザーをデフォルト・グループ「pundits」以外にも関連付けるように LDAP リポジトリーを再構成する作業は完了しました。また、新しいユーザーのグループを「pundits」ロールのメンバーにするたびにアプリケーション・コードを更新しなくてもいいように、ロールの概念も導入しています。
複雑な LDAP ディレクトリー
図 2 に示した単純なディレクトリーでは、ユーザーとグループが同じサブツリーに配置されていますが、実際の本番システムでのディレクトリーがこのように単純であるとは限りません。そこで、このセクションでは多少複雑なディレクトリーを取り上げることにします。図 5 に示すサンプル・ディレクトリーは、myco.complicated.ldif という LDIF ファイルをダウンロードしてインポートすると作成することができます。前の単純なサンプル・ディレクトリーを基点として、これから wizards を LDIF ファイルが定義する別の検索グループに移動させます (表 4 を参照)。
-
ou=people,o=branch,o=hq,dc=myco,dc=com の下には 1 人のユーザーが定義されています。
- ユーザー名 wizard とそのパスワード wizard_pwd
-
ou=group,o=branch,o=hq,dc=myco,dc=com の下には 1 つのグループが定義されています。
- 「wizard」は「wizards」に属します。
リスト 2 に記載した LDAP ユーザー・サービス構成を使用する場合、前のサンプルに定義された 10 人のユーザーでログインすることはできても、「wizard」でログインすることはできません。その理由は、ldapUserIdRdnPattern で指定されているテンプレート「uid={0}」と ldapUserIdBaseDn で指定されている検索ルートou=people,o=hq,dc=myco,dc=com が、「wizards」グループに含まれる wizard の DN と一致しないためです。この場合、このディレクトリーには何を構成すべきなのでしょうか。
図 5. 複雑なサンプル・ディレクトリー
表 4. 複雑なサンプル・ディレクトリーでのユーザーとグループのマッピング
固定モードとフレックス・モード
|
LDAP ユーザー・サービスでのユーザーおよびグループ・エントリーのデフォルト定義
LDAP ユーザー・サービスではデフォルトで、ユーザー・エントリーのオブジェクト・クラスにはinetOrgPerson、ユーザー名の属性にはuid、グループ・エントリーのオブジェクト・クラスにはgroupOfUniqueNames、そしてグループ名の属性にはcn を使用します。ldapUserIdSearchFilterPattern、ldapGroupAttributeType、およびldapGroupSearchFilterPattern の 3 つの構成パラメーターは、これらのデフォルト設定に依存します。 |
|
ディレクトリー検索で「wizard」を見つけるには、リスト 4 に抜粋した zero.config のユーザー・サービス ldap のスタンザを使用する必要があります。ユーザー検索の場合には、ldapUserIdBaseDn パラメーターのみが必要で、ldapUserIdRdnPattern は必要ないことに注意してください。ユーザー・サービスは、o=hq,dc=myco,dc=com のデフォルト検索フィルターを使ってディレクトリーの枝葉まで検索するため、ou=people,o=branch,o=hq,dc=myco,dc=com の下にある「wizard」、そしてou=people,o=hq,dc=myco,dc=com の下にある 10 人のユーザーを見つけることができます。
検索フィルターとldapUserIdBaseDn による検索はフレックス (flex) モードと呼ばれ、ldapUserIdRdnPattern とldapUserIdBaseDn による検索は固定 (fixed) モードと呼ばれます。ユーザー検索の基本は固定モードです。ldapUserIdDnPattern の定義は直観的で単純なので、高度な LDAP の技術は必要ありません。固定モードでの検索は、すべてのユーザーが 1 つのディレクトリー内で定義されている単純なディレクトリーを検索するのには有効なものの、ユーザーが複数のディレクトリーに分散されて定義されているようなディレクトリーの検索には使用することができません。後者の場合には、フレックス・モードを使用します。フレックス・モードで zero.config に構成しなければならない必須パラメーターはldapUserIdBaseDn だけです。ただし、LDAP ディレクトリーがユーザーとグループの定義にユーザー・サービスのデフォルトとは異なるオブジェクト・クラスと属性を使用する場合には、ldapUserIdSearchFilterPattern パラメーターにカスタム検索フィルターを指定する必要があります。カスタム検索フィルターについては、この後のセクション、「zero.config の詳細」で説明します。
リスト 4. zero.config のスニペット－複雑なサンプル・ディレクトリーの場合のユーザー・サービス構成
/config/security/userservice/registryType="ldap"
/config/security/userservice/ldap += {
"jndiProviderUrl":"ldap://localhost:10389/",
"jndiSecurityPrincipal":"uid=admin,ou=system",
"jndiSecurityCredentials":"<xor>LDo8LTor",
"ldapUserIdBaseDn":"o=hq,dc=myco,dc=com",
"ldapGroupBaseDn":"o=hq,dc=myco,dc=com"
}
|
ここまでのところで学んだ LDAP のまとめ
ここまでで、ユーザーをデフォルト・グループ「pundits」以外にも関連付けるように LDAP リポジトリーを再構成し、さらに LDAP のフレックス・モードと固定モードの違いについても学びました。また、このセクションでは今までの例で見てきたような単純なバージョンよりも一般的な LDAP リポジトリーとして、複雑なディレクトリーに合わせた変更をサポートするように Zero 構成ファイルを構成する方法も説明しました。
LDAP ディレクトリーへの匿名アクセス
LDAP ディレクトリー・サーバーは、匿名アクセスを許可するように構成されることがあります。この場合、LDAP クライアントは管理者のプリンシパルとクレデンシャルを使わずに LDAP サーバーに認証を委任することができます。LDAP ユーザー・サービスは LDAP クライアントの実装なので、ディレクトリー・サーバーへの匿名アクセスが可能です。
例えば図 1 のようなディレクトリーを持つディレクトリー・サーバーが匿名アクセスを許可する場合、zero.config にはリスト 5 のユーザー・サービス構成を追加する必要があります。このリストはリスト 4 と同じですが、jndiSecurityPrincipal およびjndiSecurityCredentials のパラメーター定義はありません。このようにjndiSecurityPrincipal とjndiSecurityCredentials が構成されていなければ、ユーザー・サービスはディレクトリー・サーバーに対して匿名アクセスを使用します。
リスト 5. zero.config のスニペット－匿名ディレクトリー・アクセスの場合のユーザー・サービス構成
/config/security/userservice/registryType="ldap"
/config/security/userservice/ldap += {
"jndiProviderUrl":"ldap://localhost:10389/",
"ldapUserIdBaseDn":"o=hq,dc=myco,dc=com",
"ldapGroupBaseDn":"o=hq,dc=myco,dc=com"
}
|
ここまでのところで学んだ LDAP のまとめ
ここでは LDAP にアクセスする際に 2 番目によく使われる方法である、匿名認証について学びました。このようなバインディング手段は簡単にセットアップできますが、LDAP リポジトリーにアクセスするには認証が不要であることに注意してください。
zero.config の詳細
LDAP のオブジェクト・クラスは、エントリーがディレクトリーでどの属性を保持するかを定義するスキーマの一種です。これまで検討してきた 2 つのディレクトリーでは、ユーザー・サービスのデフォルト・オブジェクト・クラスを使ってユーザーとグループのエントリーを定義していましたが、実際の本番システムでは、オブジェクト・クラスは LDAP ディレクトリーの要件と設計によって異なります。したがって、必ずしもユーザー・サービスのデフォルト・オブジェクト・クラスを使用するとは限りません。そこで、このセクションではデフォルト以外のオブジェクト・クラスと属性を使用するディレクトリーでユーザー・サービスを構成する方法を説明することにします。
一例として、myco.complicated.mail.ldif という LDIF ファイル (記事に付属のダウンロードに含まれています) によって作成された図 3 のようなディレクトリーがあるとします。このディレクトリーでは、ユーザーとグループは表 5 のようにマッピングされています。
- ユーザー・エントリーはデフォルト・オブジェクト・クラスinetOrgPerson で定義されますが、ユーザー名はuid 属性ではなくmail 属性に保管されます。
- uid はユーザー・サービスでユーザー名を保管するために使用するデフォルト属性ですが、mail はデフォルトの属性ではありません。
- グループ・エントリーはオブジェクト・クラス groupOfNames で定義され、メンバー・ユーザーは member 属性で定義されます。
- ユーザー・サービスでグループ・エントリーのデフォルト・オブジェクト・クラスとなっているのは groupOfUniqueNames です。groupOfNames はデフォルトではありません。
- ユーザー・サービスでメンバー・ユーザーを保管するために使用するデフォルト属性は uniqueMember です。member はデフォルトではありません。
このディレクトリーは明らかに、デフォルトではないオブジェクト・クラスと属性を使って定義されています。このようにデフォルト以外の設定を持つディレクトリーにユーザー・サービスがアクセスできるようにするためには、zero.config で設定されているいくつかのパラメーターを変更しなければなりません。
ユーザー・エントリーにデフォルトではない設定を使用する場合は、ldapUserIdSearchFilterPattern パラメーターを変更してください。ldapUserIdSearchFilterPattern はユーザー・エントリーを検索するための検索フィルターを指定するパラメーターで、そのデフォルト値は(&(uid={0}) (objectclass=inetOrgPerson)) です。この検索フィルターは、その名前がuid 属性に保管されていて、エントリーがオブジェクト・クラスinetOrgPerson で定義されているユーザー・エントリーを検索しますが、この例ではユーザー名がmail 属性に保管されます。したがって、このパラメーターを変更して、例えばldapUserIdSearchFilterPattern=(&(mail={0}) (objectclass=inetOrgPerson)) のようにしなければなりません。
グループ・エントリーにデフォルト以外のオブジェクト・クラスと属性が使用される場合には、ldapGroupSearchFilterPattern パラメーターを変更します。これはグループ・エントリー検索の検索フィルターを定義するパラメーターで、デフォルト値は(&(uniqueMember={0}) (objectclass=groupOfUniqueNames)) です。このフィルターは JNDI に、メンバー・ユーザー名がuniqueMember属性で保管されていて、エントリーがオブジェクト・クラスgroupOfUniqueNames で定義されているグループを検索するように指示します。この例の場合、メンバー・ユーザー名はmember 属性で保管し、グループ・エントリーにはオブジェクト・クラスgroupOfNames を使用するため、このパラメーターを例えばldapGroupSearchFilterPattern=(&(member={0}) (objectclass=groupOfNames)) に変更します。
このディレクトリーを検索するためのサンプル構成のスニペットは、リスト 6 に記載してあります。
図 6. ユーザー名として mail 属性を使用し、グループの objectClass に groupOfNames を使用する複雑なサンプル・ディレクトリー
表 5. 複雑なサンプル・ディレクトリーでのユーザーとグループのマッピング
リスト 6. zero.config のスニペット - ユーザー名として mail 属性を使用し、グループの objectClass に groupOfNames を使用するディレクトリーの場合のユーザー・サービス構成
/config/security/userservice/registryType="ldap"
/config/security/userservice/ldap += {
"jndiProviderUrl":"ldap://localhost:10389/",
"jndiSecurityPrincipal":"uid=admin,ou=system",
"jndiSecurityCredentials":"<xor>LDo8LTor",
"ldapUserIdSearchFilterPattern :"(&(mail={0}) (objectclass=inetOrgPerson))"
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
"ldapUserIdBaseDn":"o=hq,dc=myco,dc=com",
"ldapGroupSearchFilterPattern":"(&(member={0}) (objectclass=groupOfNames))",
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
"ldapGroupBaseDn":"o=hq,dc=myco,dc=com"
}
|
ここまでのところで学んだ LDAP のまとめ
このセクションでは、E メール・アドレスを使用した場合とユーザー名を使用した場合の LDAP の構成方法を学びました。企業内では E メール・アドレスも固有識別子の 1 つの形式なので、このような構成も同じく一般的でよく使用されるものです。
まとめ
Project Zero でセキュリティー・ランタイムを有効にするために必要なすべてのステップ、そして LDAP を使ってアプリケーションを保護する方法を理解していただけたでしょうか。この記事では、ユーザー・レジストリーの設定方法と、ユーザー・サービス・レジストリーを拡張するいくつかの方法を説明しました。第 3 回では今回説明した概念を展開して、Project Zero をセキュアに使用できるようにお手伝いします。お楽しみに。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| Sample code for this application | wa-pz-security2.zip | 3KB | HTTP |
|---|
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | 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 です。 |
| 
| | Hiro Tarusawa は IBM Software Group の認定コンサルティング IT スペシャリストで、現在は Project Zero および WebSphere 製品の技術コンサルタントを務めています。それ以前は、IBM RTP Laboratory で Project Zero のセキュリティー機能の設計と開発に携わっていました。Java 技術において 10 年以上の経験を持つ彼は、Java EE の専門家です。これまで、数々の Java EE ベースのシステム開発を率先してきました。 |
| 
| | Simon Kapadia は英国 ISSW (BM 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/ からも連絡できます。 |
記事の評価
| 
