サービス指向セキュリティ -...

開発者と ID サービス-ID ハブによる ID データへの取組み

Oracle ホワイト・ペーパー 2008 年 9 月

開発者と ID サービス -ID ハブによる ID データへの取組み

概要 ...................................................................................................................... 3 はじめに .............................................................................................................. 3 ID データ関連の開発 – 困難な課題 ............................................................... 4

ID ストア ....................................................................................................... 4 ID プロトコル ............................................................................................... 4 ID スキーマ ................................................................................................... 5 ID データのセキュリティ............................................................................ 5 ID のプライバシと保護................................................................................ 6

ID ハブ – ミッシング・リンク ....................................................................... 7 配置環境の抽象化......................................................................................... 7 セキュリティ機能......................................................................................... 8

Oracle Virtual Directory による ID ハブの実装................................................. 8 Identity Governance Framework による ID 要件の宣言 ................................... 9 結論 .................................................................................................................... 11


2

Oracle Corporation 発行「Developers and Identity Services -Tackling Identity Data with Identity Hub 」の翻訳版です。

開発者と ID サービス -ID ハブによる ID データへの取組み

概要

サービス指向セキュリティ（Service-Oriented Security、SOS）は、Oracle Fusion Middleware プラットフォーム全体に対応する総合的なアプリケーション・セント

リック・アプローチと連携して機能します。その目的は、開発者が扱いやすい包

括的な標準ベースのプラットフォームを提供することです。SOS では多くの一般

的な ID サービスが活用および共有されるので、開発者は、もっとも重要な作業、

つまりアプリケーション・ロジックそのものに集中できます。しかし、ID 管理に

従来から使用されてきた縦割り型手法から本当に脱却するには、ID 対応のアプリ

ケーションを作成する開発者が ID サービスの利点に目を向け、これらのサービス

をアプリケーション設計でいつどのように使用するかを理解する必要があります。

これは、『開発者と ID サービス』ホワイト・ペーパー・シリーズの第 1 弾です。

各ホワイト・ペーパーでは、ID サービスの特定の領域について開発者の観点から

取り上げます。各ホワイト・ペーパーの説明内容は、ホワイト・ペーパー『サー

ビス指向セキュリティ – アプリケーション・セントリックな観点からの ID 管理』

ですでに定義されている ID サービスと ID の外部化に基づいています。以下の

URL を参照してください。 "ID 管理に従来から使用されてきた縦

割り型手法から本当に脱却するには、

ID 対応のアプリケーションを作成す

る開発者が[ID サービス]の利点に目を

向け、これらのサービスをアプリケー

ション設計でいつどのように使用す

るかを理解する必要があります。"

http://www.oracle.com/technology/global/jp/products/id_mgmt/doc/serv_oriented_sec.pdf

このホワイト・ペーパーでは、現時点での ID データのアクセス形態に関連する問

題、および開発者に提供されるべき SOS の理想的な ID ハブについて、詳しく説

明します。

はじめに

ID サービスの各タイプおよびそれに関係するユースケースを理解することは、実

装そのものと同じくらいに重要です。すべての ID に関連した作業の中で、開発者

の観点で見た場合、ID 対応アプリケーションのもっとも基本的な部分は、ID デー

タにアクセスする機能です。しかし、それは単純な作業ではありません。ID デー

タの多くの特徴と性質は、開発者に多くの難しい課題をもたらします。一般的に、

ID データを格納、分散、および使用する方法は、デプロイに依存します。開発者

は、アプリケーションが原因で顧客の環境に不要な制限が加えられるのを避ける

ために、これらの変動要因について十分に検討する必要があります。また、ID デー

タは非常に機密性が高いものです。セキュリティは、ID ソースにアクセスするア

"すべての ID に関連した作業の中で、

開発者の観点で見た場合、ID 対応アプ

リケーションのもっとも基本的な部

分は、ID データにアクセスする機能で

す。"


3


http://www.oracle.com/technology/global/jp/products/id_mgmt/doc/serv_oriented_sec.pdf

プリケーション機能および ID データの処理と管理をおこなうアプリケーション

機能の両方において課題となっています。また、ID データの機密性のために、現

在では、企業が遵守しなければならないプライバシに関するさまざまな規制が設

けられています。

ID データ関連の開発 – 困難な課題

ID データがアプリケーションによってどのように使用されるかは、ID 対応アプリ

ケーションの開発におけるもっとも困難な課題の 1 つです。ID データは通常のア

プリケーション・データとは異なり、ポリシー、プライバシ、セキュリティ、お

よび配置といった多くの事項について検討する必要があります。

ID ストア

従来のアプリケーションは多くの場合、実行時の主要な ID データ・プロバイダ

として、そのアプリケーション専用のストレージに依存していました。一般的

に ID データのソースは分散されているので、同期は、このアプローチでローカ

ルのストアを新状態に保つための重要な要素になります。複数のアプリケー

ションで共有できる外部の一元化された ID リポジトリに ID データを移動する

と、個々のアプリケーションで必要な同期操作が減少することにより簡略化す

ることはできます。しかし、一元化されたストアでも、同期の必要性がなくな

ることはありません。実際にはすべてを一元化できるわけではなく、開発者は

複数の ID リポジトリを協調して動作させる必要があります。たとえば、人事管

理システム（HRMS）では、HRMS の外部にある他のアプリケーションによって

情報が必要とされる場合でも、従業員の給与や社会保障番号を外部ソースと同

期するべきではありません。

"実際にはすべてが一元化できるわけ

ではなく、多くの場合、開発者は複数

の ID リポジトリを協調して動作させ

る必要があります。"

"信頼性"が、アプリケーション・データと一元化されたデータを分離する理由に

なることはよくあります。特定のアプリケーションが特定の ID 属性を提供する唯

一の供給源ととらえる場合は、その属性の"権限"はそのアプリケーションにある

と考えられます。したがって、HRMS には、従業員の給与または社会保障番号に

関する権限があります。つまり、アプリケーションを機能させるのに必要な単一

ID の完成イメージを作成するために、開発者は複雑なプロセスを使用して ID レ

コードを複数のストアに関連づける必要があります。これは、ID を構成するさま

ざまな属性が複数の ID ストアに分散しているからです。

ID プロトコル

RDBMS または LDAP 形式の ID リポジトリは、ID データの提供において中心的

な役割を果たしてきました。リポジトリのタイプが異なれば、別の種類のプロト

コルが使用されます。現在の開発者は、さまざまな種類のプロトコルのあらゆる

面に対応するための準備として、各種の接続情報（データベース接続文字列また

は LDAP URL）を格納する方法から、情報を取り出す JDBC や JNDI などのさま

ざまなプロトコルの使用方法まで理解しておく必要があります。SAML、WS-*、SOAP などの連携プロトコルや Web ベースのプロトコルの登場によって、これら

のプロトコルの性質と利用方法はますます多様で複雑になるばかりです。


4


ID スキーマ

開発者は、適切なプロトコル・セットを使用してバックエンド・データにアクセ

スし、さまざまな種類の ID スキーマを検索し、データをリクエストして抽出する

ことが必要になりました。ユーザーの電子メールは、企業の RDBMS にある特定

の表の特定の列から取得する場合があります。一元化された LDAP を ID データに

対して使用している企業の場合、開発者は JNDI 問合せを使用して、ユーザーの

LDAP 識別名から"mail"属性を取得できます。LDAP では、ユーザー、グループ、

および組織などの一般的なオブジェクト用に標準 LDAP スキーマ・セットを定義

する"objectclasses"が提供されます。ただし、カスタム LDAP スキーマが使用され

ている場合は、クライアント・アプリケーションの処理をそれに適したものにし

なければならないことがあります。また、SAML が使用されている場合は、ユー

ザーの SAML アサーション内で、email を含む一連のユーザー・プロファイル属

性を属性アサーションを通して使用できることがあります。さらに、email 値を実

際に保持する属性および値がどのように表現されるかは、使用される SAML のタ

イプによって異なります。この SAML のタイプは、SAML ID プロバイダと SAMLサービス・プロバイダ間のハンドシェイクがどのように構成されているかによっ

て決まります。ID 情報の更新のために情報を書き込む必要があるアプリケーショ

ンについては、ID スキーマを理解することがますます重要になっています。

詳しく調べると、リポジトリ、プロトコル、およびスキーマの領域で確認されて

いる問題のほとんどは、配置時に関係しています。終的に、データがどのよう

に格納され、またどのように表現されるかは、顧客のデプロイ環境によって変わ

ります。これは、強力な相互運用性を備えた標準の利点を活用したとしても同じ

です。また、ID リポジトリ、ID プロトコル、および ID スキーマにさまざまな選

択肢がある場合、より簡素化された管理しやすいソリューションで工程を短縮せ

ざるを得ないこともよくあります。単一の API を使用して単一のプロトコル経由

でアクセスできる単一のプライベート・ストアに限定し、ID データはよく知られ

ているスキーマ、場合によっては独自のスキーマで表現されることもあるかもし

れません。このようにして、絶対に避ける必要があるアプリケーション固有の縦

割り型手法に逆戻りすることになっていました。

"最終的に、データがどのように格納され、またどのように表現されるか

は、顧客のデプロイ環境によって変わ

ります。これは、強力な相互運用性を

備えた標準の利点を活用したとして

も同じです。"

ID データのセキュリティ

アクセス制御

開発者が ID データのアクセスに関する問題を解決したあとにくる次のハードル

は、データへのアクセスを制御することです。リポジトリ・レベルには、必ず何

らかの形式の固有のセキュリティがあります。このセキュリティは、データのア

クセス制御をおこなうために格納メカニズムそのものに実装されています。ただ

し、固有のアクセス・ポリシーを定義するためには、固有のストアは、そこにア

クセスするエンティティ（ユーザーやアプリケーション、またはその組合せ）を

認識できなければなりません。たとえば LDAP を使用している場合は、LDAP ア

クセス制御を介してアプリケーション用のアクセス制御を定義するために、アプ

リケーションは識別名（DN）形式で認識可能なエンティティである必要がありま

す。また、この識別名は、LDAP に対するバインドおよび問合せに使用できるも

のでなければなりません。つまり、アプリケーションのフットプリントが存在し

ている必要があります。RDBMS にも同じことが当てはまります。RDBMS では、

データベース・ユーザーが定義された後にテータベース内でネイティブにアクセ

ス・コントロールが定義されます。

"ただし、固有のアクセス・ポリシーを

定義するために、固有のストアは、そ

こにアクセスするエンティティ（ユー

ザーやアプリケーション、またはその

組合せ）を認識できなければなりませ

ん。"


5


アプリケーションを頻繁に入れ替えると、深刻および潜在的なセキュリティ・ホー

ルができてしまいます。これは、一般的にこのようなアプリケーション固有のセ

キュリティ要件を歓迎しない ID ストア管理者にとって大きな問題となります。場

合によっては、アプリケーションとユーザー・コンテキストの両方に基づいたセ

キュリティが必要なのにもかかわらず、それに対処する LDAP などのプロトコル

がまったく準備されていないことがあります。たとえば、給与アプリケーション

と HR アプリケーションでは、アプリケーションでどのユーザー属性を取得でき

るかという点で、ログイン・ユーザー・データへのアクセスが異なります。必要

なバックエンドのサポートがないと、これは、開発者の観点からは解決が非常に

難しい問題となります。

委任

委任は、開発者が悩まされるもう 1 つの扱いにくいユースケースです。たとえば、

マネージャーが休暇中の直属の部下に代わって特定のタスクを実行すると仮定し

ます。これらのタスクに必要な的確な委任とアクセス制御を正確に取り込むのは、

困難なことがよくあります。読取り専用として見た場合、マネージャーに許可さ

れる ID データへのアクセスは直属の部下と同じにするか、または少なくとも部下

に代わって操作を実行できるものにしなければなりません。ただし、それ以上の

アクセス権限は不要です。また、ID データまたはレコードに対しておこなわれた

操作または変更は、マネージャーのものとして記録される必要があります。この

ようなアクセスは、慎重に制御および監査される必要があります。さらに、これ

らのアクセス制御をアプリケーション側に実装するのは、開発者にとって困難で

す。これらのアクセス制御とポリシーを機能させる基準の多くは、マネージャー

と直属の部下の関係のように、ID レイヤーに存在している可能性があります。

"的確なアクセス・レベルの定義を難し

くしている原因の大部分は、的確なコ

ンテキストを定義する機能が欠如し

ていることです。"

的確なアクセス・レベルの定義を難しくしている原因の大部分は、的確なコンテ

キストを定義する機能が欠如していることです。現在のアクセス制御で対応可能

なのは、特定のユーザーまたはアプリケーションへのアクセスのような 1 次元の

コンテキストです。しかし、より複雑なセキュリティ要件がある場合は、アクセ

ス制御で多次元のコンテキストに対応しなければなりません。的確なアクセス・

レベルを見極めるには、ユーザー、アプリケーション、ターゲット、プロトコル、

目的などの組合せをふまえて完全なコンテキストを理解する必要があります。

ID のプライバシと保護

新しい規制とコンプライアンス要件によって、データ保護は、データ・ソースの

単純な保護だけではなくなりました。現在、開発者は、新しく出現した多くの要

件に悩まされています。これらの要件は、アプリケーションによる ID データの使

用方法と管理方法に関係しています。

ID データのライフ・サイクル

EU データ保護条令（European Union Directive on Data Protection）などの規制では、

不要になった情報や一定期間使用されなかった情報を破棄およびアーカイブする

ことが義務づけられています。この規制のため、開発者は情報をアプリケーショ

ン内に保持できる期間について意識する必要があります。

小情報アプローチ

ここでは、エンドユーザーが成人または未成年であるかを確認する必要があるア

プリケーションのユースケースについて考えてみます。1 つの選択肢は、ユーザー

の生年月日を取得して現在の日付から計算する方法で、開発者はその人物が成人

であるかどうかを判定するコードの記述が可能です。人物の生年月日は、その人

"新しい規制とコンプライアンス要件

によって、データ保護は、データ・ソー

スの単純な保護だけではなくなりま

した。"


6


物が成人であるかどうかの情報よりもはるかに慎重に扱わなければならないので、

生年月日の取得は小知識の原則に反するものです。もう 1 つの例は、人物の社

会保障番号の下 4 桁を照合することです。この場合も、その背景にある考え方（エ

ンド・ユーザーの観点からでも）は、エンド・ユーザーの ID を照合するのに、検

証者やソフトウェア・アプリケーションは完全な社会保障番号を知る必要がない

というものです。開発者にとって実装がもっとも簡単な方法は、完全な社会保障

番号を取得して、下 4 桁が正しいかを確認することです。しかし、この方法では

アプリケーションで必要とされる以上の情報を取得しています。

小情報アプローチはこの種のシナリオに対する取組みの 1 つで、開発者および

アプリケーションが必要な情報を得るために取得する情報量を小限にするとい

うものです。アプリケーションに、ユーザーが成人か未成年かがわかる情報（派

生属性または主張など）を渡したり、認証サービスなどによってプロバイダが社

会保障番号の下4桁を受け取って trueまたは falseを返したりするだけで十分です。

現時点では、この種のプライバシ問題の解決が非常に困難であることがわかって

います。その理由は、ほとんどの場合ネイティブ ID ストアである ID プロバイダ

自体に、これらのユースケースのサポートに必要な機能がないためです。

ID ハブ – ミッシング・リンク ID ハブは、企業シナリオとフェデレーテッド・シナリオの両方で、ID 属性に関し

て信頼できるさまざまなソースとアプリケーションの間でブローカとして機能し、

ID データをアプリケーションに提供します。上述のユースケースを調べた結果、

ID ハブを成功させるには、いくつかの重要な要件があることがわかりました。

"実際のデプロイ環境に依存しなくて

も済むように、開発者には、明確に定

義された ID ハブによって適切な抽象

化が提供される必要があります。"

デプロイ環境の抽象化

実際のデプロイ環境に依存しなくても済むように、明確に定義された ID ハブに

よって、開発者は適切な抽象化を実現できます。

- バックエンドに依存しない – 1 つまたは複数の ID ストアの統合とハン

ドシェイクは、ID ハブの内部で処理されるので、開発者からは遮断さ

れます。また、ID ハブには、環境内にある複数の ID ストアとネゴシエー

トできる機能、また単一の統合ビューを提供する機能があります。これ

には、各部分が複数のストアに分散されている ID を一体化する機能や

異なるリポジトリにあるさまざまな ID を集積する機能が含まれます。

- プロトコルに依存しない – 開発者は、単一のプログラミング・インタ

フェースを使用して単一の仮想 ID ハブを取り扱うことになります。こ

れによって、開発者は複数あるプロトコルのバランスを取る必要がなく

なり、顧客のデプロイ環境における拡張性が向上し、カスタマイズが容

易になります。

- スキーマに依存しない – 開発者は、ID ハブによってサポートされてい

る単一のスキーマを使用することになります。これで追加される ID ハ

ブ・レイヤーによって、特定のニーズに合わせて調整されたさまざまな

アプリケーションや産業の垂直業界に対して、異なるスキーマ・プロ

ファイルを定義できるようになります。さらに、属性レベルで適切な

マッピングを定義できるようになるので、開発者の作業はより簡単にな

ります。


7


セキュリティ機能

ID ハブに追加されるレイヤーは追加のセキュリティ機能にも対応しているので、

ID データをより確実に保護することが可能です。

- 追加のアクセス制御 – ID ハブでは、固有の ID ストアへの実装には適し

ていない、または実装が不可能な、追加のフィルタリングとアクセス制

御が提供されます。ここで重要な要件は、関係者が要求する情報のコン

テキストにセキュリティを連携させることです。これは、アプリケー

ションユーザー・コンテキストおよびほかの委任のユースケースをサ

ポートするために必要です。

"ID ハブでは、固有の ID ストアへの実

装には適していない、または実装が不

可能な、追加のフィルタリングとアク

セス制御が提供されます。"

- ID データのライフ・サイクル – ID データのライフ・サイクル要件は、

ID ハブの内部で定義できます。これで、ID ハブによって定義される一

元化されたポリシー・セットに対して、ローカル ID データの適切な取

扱いを強制的に適用できるようになります。

- 小情報 – ID ハブでは、そのスキーマを拡張して、これらのユースケー

スをサポートするより複雑な属性マッピングを提供できます。たとえば、

エンド・ユーザーの生年月日を返さなくても、成人確認ユースケース用

にブール・レスポンス（条件）を構築できます。さらに、成人はある国

では 18 才以上であり、また別の国では 21 才以上のこともあります。こ

れらのポリシーはアプリケーション・ロジックの中ではなく ID ハブの

中に存在するので、カスタマイズ、一律の実施、および遵守が簡単にお

こなえるようになります。

ID ハブを使用すると、アプリケーション開発者は ID データの複雑な処理の一部

をスタックに追いやり、アプリケーション・ロジック自体から切り離すことがで

きます。さらに、ID ハブでは、アプリケーションの要件をあらかじめ宣言してお

く機能が提供されているため、これらの要件を満たすための処理は ID ハブに任さ

れます。これによって、開発者はプロバイダに関する作業から解放され、アプリ

ケーション・ロジックに集中できます。しかし、もっとも重要なのは、カスタマ

イズ、構成、拡張を簡単に実現するための要件に関係した、よりいっそう複雑な

ID データを処理する媒体が ID ハブによって提供されることです。

Oracle Virtual Directory による ID ハブの実装

ID ハブによって、通常は分散環境内にある、信頼できるユーザー・データの単一

のビューが提供されることが理想です。この分散環境には、ユーザー・データは、

さまざまなディレクトリやデータベースを含む複数のリポジトリに分散されてい

ます。LDAP 対応アプリケーション用の ID ハブは、Oracle Virtual Directory（OVD）

を使用して簡単に実装できます。OVD の仮想化テクノロジーによって、複数の

ディレクトリを一元管理する機能が提供され、また LDAP でデータベースまたは

他の独自の ID データ・ストアにアクセスできるようになります。OVD でサポー

トされているアダプタでは、Oracle Internet Directory、Microsoft Active Directory、Novell eDirectory、IBM Tivoli Directory Service、Sun Java System Directory Server など、ほとんどのディレクトリ・サーバーに接続できます。また、OVD では、Oracle、IBM、および Microsoft 製のデータベースを含むリレーショナル・データベースに

接続するアダプタもサポートされています。

"LDAP 対応アプリケーション用の IDハブは、Oracle Virtual Directory を使

用して簡単に実装できます。"


8


図 1：OVD を使用した場合の典型的な配置

OVD を使用すると、ID データを一元管理するための作業と実行は開発者の手か

ら離れます。アプリケーションの開発者は、LDAPv3 インタフェース経由で（た

とえば、JNDI を使用して）仮想 ID ハブとのやり取りをおこない、個人の ID レコー

ドのリアルタイム統一ビューを取得できるようになります。

Identity Governance Framework による ID 要件の宣言 Identity Governance Framework（IGF）で、"アプリケーション ID ハブ"ハンドシェ

イクの適切なオープン標準を定義することによって、ID ハブ・ソリューションの

ために数多くの主要コンポーネントを使用することが可能です。アプリケーショ

ン側からは、IGF の Client Attribute Requirements Markup Language（CARML）によって宣言形式の方法が提供されるので、設計者と開発者は、"ID 要件"のロジッ

クをアプリケーション自体に組み込まなくてもその要件を伝達できるようになり

ます。CARML の重要な目的は、"ID データ"に関するプライバシ制約の表現を

WS-Policy の形式でサポートすることです。これによって、セキュリティ要件を定

義する言語が提供されます。このセキュリティ要件は、アプリケーション固有の

要件に合わせて調整できます。


9


"属性サービス API（エイリアス ID APIとも呼ばれる）を使用すると、外部化

された IDサービスが可能になります。

これは、意志決定を配置管理者と IDインフラストラクチャ管理者が適切

におこなうため、開発者が意志決定を

する必要がなくなるからです。"

図 2：高レベルの IGF アーキテクチャ

OVDアプローチを利用すると、現在のLDAP対応アプリケーションにソリュー

ションを適用できます。しかし、OVD単独では、完全にプロトコルに依存しない

ソリューションは提供できません。オラクルは、Arisプロジェクトとして知られ

ているオープン・ソースの取組み（www.openLiberty.org）をリードしてきました。

このプロジェクトの目的は、外部化されたIDデータを開発者が使用できるように

するAPIを開発することです。属性サービスAPI（エイリアスID APIとも呼ばれる）

を使用すると、外部化されたIDサービスが可能になります。これは、意志決定を

配置管理者とIDインフラストラクチャ管理者が適切におこなうため、開発者が意

志決定をする必要がなくなるからです。

この API によって IGF（Identity Governance Framework）標準が実装され、分離型

の開発が可能になります。この分離型の開発では、開発者は配置時に複雑なイン

フラストラクチャを配置しなくても、IDE 環境内で ID サービスの使用についての

完全なテストを実施できます。さらに、Aris API を利用して開発されたアプリケー

ションは、SAML と WS-*を使用するフェデレーテッド環境でも、またはディレク

トリやデータベースを使用する企業内サービスでも、外部データを使用する準備

が完全にできた状態になります。

また、Aris は、IGF の CARML およびプライバシ制約の標準を実装するために開

発された、初の開発者向け API です。CARML の宣言形式の要件で定義された

セキュリティを使用すると、分離型の開発によって、属性サービス API で類似の

インタフェースと利用モデルを提供することが可能になります。したがって、開

発者が実装の違いを考慮する必要性がなくなり、複雑なプロトコル処理コードや

構成要件（JNDI など）が不要になります。さらに、CARML を使用している状況

では、追加のアクセス制御とプライバシ制約をバックエンドに依存しない方法で

定義して、アプリケーション固有の要件に基づいて ID データの保護を強化できる


10


http://www.openliberty.org/

ようになりました。

"CARML を使用している状況では、追

加のアクセス制御とプライバシ制約

をバックエンドに依存しない方法で

定義して、アプリケーション固有の要

件に基づいて ID データの保護を強化

できるようになりました。"

図 3：IGF でのデータ交換

Aris API を使用して構築されたアプリケーションでは、属性サービスに関する"プロバイダ"テクノロジーが数多くあり、オープン・ソース標準インタフェースに基

づいて選択することが可能です。たとえば、オラクルの顧客は、組込み済みの

Oracle Virtual Directory テクノロジーを使用するか、またはオラクルの競合他社や

オープン・ソース・コミュニティによる他の実装を使用して、デプロイできます。

（注：現在、オラクルは、Higgins IdAS をこの目的に適応させるために Higgins コミュニティと共同で作業をおこなっています。）

Identity Governance Framework の詳細については、次の Web サイトを参照してくだ

さい。

http://www.projectliberty.org/liberty/resource_center/specifications/igf_1_0_specs

結論

ID データのソースを識別することは、すべての ID 対応アプリケーションの設計

において重要です。適切な ID ハブを使用することで、開発者は、アプリケーショ

ンとバックエンド ID ストアを従来の方法で統合する際に直面していた困難な問

題の多くを切り離します。ID データ・プロバイダに関係する問題のほとんどはデ

プロイ時の問題であるため、分離型の開発では、ID ハブを適した位置にデプロイ

することにより、これまで開発者が対処できなかった問題に対応できるようにな

ります。

アプリケーションから ID ハブに要件を宣言形式で指示できるようになると、IDハブから新しいパラダイムが発生します。これによって、ID ハブでは、スキーマ・

マッピング、アクセス制御、およびプライバシ保護の分野で機能を提供すること

が可能になります。これらの機能を従来の手法を使用してアプリケーション・レ

ベルで実現することは、不可能ではないとしても困難な作業です。終的な結果

として、アプリケーションはより効率的、的確、および安全な方法で開発され、

ID データの処理と操作ができるようになります。

オラクルのセキュリティ･テクノロジーの詳細については、

http://www.oracle.com/lang/jp/security/security-solutions.htmlを参照してください。


11


http://www.projectliberty.org/liberty/resource_center/specifications/igf_1_0_specs

http://www.oracle.com/lang/jp/security/security-solutions.html

開発者と ID サービス – ID ハブによる ID データへの取組み 2008 年 9 月著者：Stephen Lee 共著者：Phil Hunt、Nishant Kaushik Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2008, Oracle Corporation and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告

なく変更されることがあります。本文書は、その内容に誤りがないことを保証する

ものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品

性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および

条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任

も明確に否認し、本文書によって直接的または間接的に確立される契約義務はない

ものとします。本文書はオラクルの書面による許可を前もって得ることなく、いか

なる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成

または送信することはできません。Oracle は米国 Oracle Corporation およびその子

会社、関連会社の登録商標です。他の製品名は、それぞれの所有者の商標です。

サービス指向セキュリティ -...

Technology