| Oracle® Fusion Middleware WebCenter Sites開発者ガイド 11gリリース1 (11.1.1.8.0) E49681-03 |
|
 前 |
 次 |
アプリケーション開発者の環境は、RESTサービスを介してWebCenter Sites上で実行されるWEMフレームワークで構成されます。WebCenter SitesへのRESTコールは、アプリケーションで任意の言語で記述することで実行できます。カスタム構築アプリケーションは、プラットフォームのアプリケーション・サーバー以外のアプリケーション・サーバーにデプロイ可能であるため、プラットフォームのデプロイメント・インフラストラクチャとは別に記述できます。
この章には次の項が含まれます。
アプリケーション開発のサポートは、次のコンポーネントで行われます(この章のそれぞれの項も参照してください)。
RESTサービス: WebCenter Sitesオブジェクトへのアクセスを提供する一連のプログラム・インタフェース。
UIコンテナ: 登録済アプリケーションを公開します。登録によって、アプリケーションのインタフェースのレンダリングが可能になります。また、UIコンテナは、アプリケーションでログイン済ユーザーや現在のサイトに関する詳細情報をWEMフレームワークから取得するために使用する、WEMコンテキスト・オブジェクトもサポートしています。
シングル・サインオン(SSO): 認証されたユーザーが1回ログインするのみで、そのセッション中に許可されるすべてのアプリケーションにアクセスできるようになります。(WebCenter Sitesインストール・プロセスでは、WEMのシングル・サインオンをサポートするCentral Authentication Service Webアプリケーションがインストールされます。)
REST認可モデル: グループ・メンバーシップに基づいて、RESTリソースへの詳細なアクセス制御を提供します。アプリケーション開発は、事前定義済ユーザーがコードで指定されている場合を除き、(WEM AdminおよびWebCenter Sites Adminインタフェースでグラフィカルに構成されている)認可には直接関係していません。
WEM AdminもWEMフレームワークの一部ですが、アプリケーション開発に使用されることはほとんどなく、主に、アプリケーション登録プロセスの結果をテストしたり、サイト、ユーザー、グループ、ロールに関する管理情報を取得したりするために使用されます。WEM AdminおよびWebエクスペリエンス管理フレームワークの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。
REST APIでは、次のWebCenter Sitesデータ・モデルが公開されます。
ベーシック・アセット・タイプおよびベーシック・アセット(読取り/書込み)
フレックス・アセット・タイプおよび定義(読取り専用)
フレックスの子と親(読取り/書込み)
索引付けによるアセット検索のサポート
次のオブジェクトも、REST APIで公開されます。これらのオブジェクトは、主に認可プロセスで管理者が使用します(オブジェクトはWEM Adminインタフェースに表示されます)。
サイト(読取り/書込み)
ユーザー(読取り/書込み)
ロール(読取り/書込み)
ACL(読取り専用)
グループ(読取り専用): RESTレイヤーへのアクセスを制御するためにこのリリースで導入されました。
補助サービス: ユーザー・ロケールおよびサーバーのタイムゾーン
(サイト、ロールおよびユーザーはWEM Adminで構成できます。ACLおよびグループは、読取り専用アイテムとしてWEM Admin(「ユーザー」の下)に公開されます。それらは、WebCenter Sites Adminインタフェースで構成する必要があります。)
WebCenter Sitesのオブジェクトは、WEM内のRESTリソースにマップされます。パブリッシュ、ワークフロー、データベース管理ツール、ページのキャッシングなど、他のすべての機能には、WebCenter Sites AdminインタフェースからまたはJSPやXMLタグを介してアクセスする必要があります。
一般管理者が管理する認可オブジェクトの中で、サイトおよびロールが、要件によってはアプリケーション管理の候補となる可能性が高いです。また、管理者の認可タスクを簡素化するために、事前定義済ユーザーを指定することもできます。
サイト: アプリケーション・コードでのサイトの使用は、アプリケーションのアセット・タイプとアセットをプログラムでインストールする必要がある場合の要件です。コードでアセット・タイプを有効にするサイトを1つ以上指定する必要があります(アセットへのサイト固有のアクセスを行うには、それらのアセット・タイプが1つ以上のサイトで有効になっている必要があります)。そうでない場合は、サイトを指定しないで、アセット・タイプを単にインストールできます。その後、管理者は、WebCenter Sites Adminインタフェースを使用して、独自に選択したサイト上でアセット・タイプとアセットを有効にします。
WEMのロール: アプリケーションへのアクセスを管理するために使用します。同じサイト上のユーザーとアプリケーションでロールを共有すると、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。アプリケーション・コードでロールを使用すると、Editなどの、インタフェース機能を保護できます。WebCenter Sites Adminインタフェースは、ロールで保護されたインタフェース機能を備えたアプリケーションの一例です。
ユーザー: アプリケーション・コードで指定する可能性のある唯一のユーザーは、管理者の認可プロセスを簡略化するための事前定義済ユーザーです。ユーザーの指定には、ユーザー名とパスワードのコーディングが含まれます。管理者は、すべてのアプリケーション・ユーザーをRESTレベルで個別に認可するかわりに、事前定義済ユーザーを認可します。事前定義済ユーザーに付与された権限は、ユーザーがアプリケーションにアクセスするとログイン済ユーザーに引き継がれます。事前定義済ユーザーおよび認可モデルの詳細は、第70.5項「認可モデル」を参照してください。
システム全体においてサイトとロールがどのように使用されているかを追跡するのは管理者のタスクですが、これにはアプリケーション開発者によるサポートが必要です。トラッキングは、WebCenter Sitesプラットフォームがステージング・システムとしても機能する場合に特に重要です。これは、WEMフレームワークがWebCenter Sitesデータベースを使用しているからです。たとえば、WEM Adminで作成されたサイトはデータベースに格納されます。それらはステージング用にWebCenter Sitesで使用されるとはかぎりませんが、WebCenter Sites Adminインタフェースで専用のCMサイトと一緒に公開されます。反対に、CM用途でWebCenter Sites Adminインタフェースで作成されたサイトは、WEM Adminで公開されます。ここで、その他のアプリケーションをそれらのサイトに割り当てることができます。ユーザーが適切に認可されるには、開発者はカスタム構築アプリケーションの性質を管理者に伝達する必要があります。そのような性質には、ユーザーが使用するリソース、ロールで保護されたインタフェース機能、事前定義済ユーザー(存在する場合)などが含まれます。
UIコンテナでは、登録済アプリケーションが公開され、コンテキスト・オブジェクトがサポートされます。コンテキスト・オブジェクトは、WEMフレームワークから情報を取得するためにアプリケーションで使用されます。
この項の内容は、次のとおりです。
アプリケーションを登録する目的は、管理者がアプリケーションを管理したり、他のユーザーに提供したりできるように、WEM Adminでアプリケーションを公開することです。登録を行うと、そのアプリケーションがアセットとして認識され、次のことが実行されます。
WEM Adminの「アプリケーション」ページにアプリケーションが一覧表示されます(図70-1)。
アプリケーションを表すために選択したアイコンが配置されます。
WebCenter Sitesのログイン・ページ、およびアプリケーションが割り当てられている各サイトのアプリケーション・バー(図70-1)にアプリケーションのアイコンが表示されます。
アプリケーションのアイコンが選択された際にアプリケーションのインタフェースがレンダリングされます。
アプリケーションの登録には、そのビューの登録が含まれています。複数の共有ビューがサポートされますが、単一の非共有ビューを使用するアプリケーションが一般的です(このガイドでも使用しています)。iframe、HTMLおよびJavaScriptタイプのビューを使用できます。
登録をサポートするために、WEMフレームワークには、ベーシック・アセット・タイプFW_ApplicationとFW_Viewが付属しています。いずれも、WebCenter Sitesインストール・プロセスでWEMオプションを選択した場合に作成されます。これらのアセット・タイプは、AdminSiteにおいてデフォルトで有効になります(WebCenter Sitesのインストール・プロセスでも作成されます)。
アプリケーションを登録するには(デプロイされている場合)、FW_Applicationのインスタンスの作成、各ビュー用のFW_Viewインスタンスの作成、およびFW_ApplicationインスタンスへのFW_Viewインスタンスの関連付けが必要です。他のサイトでアプリケーションを使用する場合でも、そのアプリケーションをAdminSiteで登録する必要があります。登録すると、アプリケーションを他のサイトに割り当てることができます。
アプリケーションは、REST APIのapplicationsサービスを介してプログラムで登録することも、WebCenter Sites Adminインタフェースから手動で登録することもできます。プログラムによる登録をお薦めします。例については、第71.2項「Articlesサンプル・アプリケーションの起動」を参照してください。一般的な手順については、第72.6項「登録コード」を参照してください。手動登録の例については、第78章「WEMフレームワーク: アプリケーションの手動登録」を参照してください。
UIコンテナは、コンテナ内のすべてのアプリケーションにJavaScriptコンテキスト・オブジェクト(WemContext)を提供します。コンテキスト・オブジェクトは、ログイン・ユーザーやサイトに関する詳細情報をWEMフレームワークから取得する際にアプリケーションで使用されます(たとえば、UIコンテナからの現在のサイトの名前など)。また、コンテキスト・オブジェクトは、アプリケーションでデータを共有する際に使用する様々なユーティリティ・メソッドも提供します。コンテキスト・オブジェクトは、WebCenter Sitesと同一ドメインまたは異なるドメインで実行されているアプリケーションで使用できます。詳細は、第72.5項「コンテキスト・オブジェクト: WEMフレームワークからのパラメータへのアクセス」を参照してください。
シングル・サインオンは、Central Authentication Service (http://www.jasig.org/cas)を使用して実装されます。サンプル「Articles」の例で示すように、WEMフレームワークに付属するサーブレット・フィルタは、Java Webアプリケーションとしてデプロイされたアプリケーションに対してすぐに使用できます。アプリケーションが別のテクノロジを使用して開発されている場合は、次のURLにある、選択したテクノロジに固有のCASクライアントを参照してください。
http://www.ja-sig.org/wiki/display/CASC/Official+Clients
ユーザーがCASで保護されているアプリケーションにアクセスしようとすると、認証システムが次の手順で応答します。
初回アクセス
ユーザーがCASで保護されているアプリケーションに最初にアクセスしようとすると、
ユーザーは、CASログイン・ページにリダイレクトされます。ログインに成功すると、
ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。CASログイン・ページのCookieが保存されます。
アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。(コンテンツ管理システムでは、CASはデフォルトでWebCenter Sitesデータベースに対して認証を行います。)
2回目以降のアクセス
CASで保護された別のアプリケーションにユーザーがアクセスしようとすると、ユーザーはCASログイン・ページにリダイレクトされます。
リクエストからCookieが取得されて暗黙的ログインが実行され、ログイン・ページは省略されます。
ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。
アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。
認可とは、アプリケーションへのアクセスをユーザーに付与するプロセスです。一般管理者は、図70-2に示すようにWEM Adminを使用してオブジェクトを結合することにより、認可を行う必要があります。開発者は、アプリケーションで事前定義済ユーザーをコーディングすることにより、管理者のタスクを簡素化できます。以降では、ユーザーを認可モデルに適合させる方法について説明します。
図70-2のサイト、アプリケーション、ユーザーおよびロールには、それぞれに対応するWEM Adminのメニュー・オプションがあります。ACLおよびグループは、各ユーザーのページで公開されます。
認可は3つのレベル(アプリケーション、RESTおよびデータベース)で管理されます。
アプリケーション・レベルの認可では、同じサイト上のユーザーとアプリケーションでロールを共有する必要があります。これにより、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。インタフェース機能がロールで保護されている場合、それらのロールもアプリケーション・ユーザーと共有されている必要があります。
RESTレベルの認可では、ユーザーがアプリケーションのリソースを操作するための権限を制限します(ACLが正しく割り当てられていることが前提です)。RESTレベルの認可では、RESTリソースにマップされるオブジェクトへの操作権限を持つグループを構成する必要があります。グループに割り当てられたユーザーにはグループの権限が付与されます。
開発者は、ログイン済ユーザーのプロキシとして動作するユーザーをアプリケーションで定義できます(ユーザー名とパスワードを指定する)。これにより、管理者がログイン済ユーザーごとにRESTセキュリティを構成する必要がなくなります。アプリケーションがデプロイおよび登録されると、一般管理者は次の方法で事前定義済ユーザーを認可します。1) WEM Adminで、アプリケーションにアクセスするための事前定義済ユーザーを構成し、2)アプリケーションのリソースの操作権限を持つグループを(WebCenter Sites Adminインタフェースで)構成して、3)事前定義済ユーザーを(WEM AdminまたはWebCenter Sites Adminインタフェースのいずれかを使用して)そのグループに割り当てます。グループの権限は事前定義済ユーザーに渡され、ログイン済ユーザーがアプリケーションにアクセスする際に、そのログイン済ユーザーに渡されます。サポートされるセキュリティ構成は、第75.3項「REST認可」で一覧表示して説明されています。WEMフレームワークに付属の「Articles」サンプル・アプリケーションでは、事前定義済ユーザーが指定されます。
データベース・レベルでは、そのユーザーのグループ・メンバーシップにかかわらず、ACLによって個々のユーザーのシステムへのアクセス(つまり、ログイン権限、データベースの操作権限)が決定されます。ACLでユーザーに適切な権限が割り当てられておらず、データベース表への権限が不足している場合、グループのメンバーシップによってそれらの権限が付与されることはありません。
デフォルトのACLでは、多くのデータベース表のオブジェクトに対してほぼ無制限の操作権限(手段ではない)がユーザーに提供されます。それらの権限を調整するには、RESTレベルで、ユーザーのグループ・メンバーシップによって直接調整するか(事前定義済ユーザーが存在しない場合)、アプリケーションの事前定義済ユーザーとそのユーザーのグループ・メンバーシップによって間接的に調整します。オブジェクトに対するグループの操作権限を変更すると、そのグループ・メンバーのリソースに対する操作権限も変更されます。WebCenter Sites側の同一ユーザーはグループ・メンバーシップによる影響は受けません。コンテンツに対する権限は、引き続きACLによって制限され、サイトとロールによって機能します。
WEMで開発されるカスタム・アプリケーションは、通常、コンテンツ管理プラットフォームに対して疎結合された形で実装されます。カスタム・アプリケーションは、WEMフレームワークで有効化されたREST API WebサービスとSSOメカニズムを利用するため、一般的にプラットフォームのアプリケーション・サーバー以外のアプリケーション・サーバーにデプロイされます。そのため、開発者はプラットフォームのデプロイメント・インフラストラクチャから完全に切り離してカスタム・アプリケーションを作成できます。ほとんどのカスタム・アプリケーションはリモートでデプロイされます(図70-3)。
カスタム・アプリケーションは、コンテンツ管理アプリケーションまたは配信アプリケーションとして実装できます。一般的に、コンテンツ管理側ではパフォーマンス・チューニングの手間がそれほどかからないため、コンテンツ管理側から着手することをお薦めします。
WEMフレームワークには、いくつかの軽量のサンプル・アプリケーションが付属しており、それぞれ専用アプリケーションを開発するためのモデルとして起動および分析できます。「Articles」は、コンテンツ管理アプリケーションを示しています。第71章「WEMフレームワーク: Articlesサンプル・アプリケーション」には、「Articles」を起動するための手順が含まれています。仕様については、第72章「WEMフレームワーク: アプリケーションの開発」を参照してください。ソース・コードはWebCenter Sites Misc/Samplesフォルダにあり、その他のサポート情報はREST APIリソースおよびBeanリファレンスに記載されています。SSOサンプル・アプリケーションはライブ・サイトでの認証用で、「Recommendations」アプリケーションはRESTリソースの作成方法を示しています。
すべてのREST POST/PUT/DELETEリクエストを有効であると認証するには、各リクエストには、X-CSRF-Tokenキーを持つヘッダーと、CASチケット(マルチまたはシングル)またはsessionidのいずれかの値が必要です。
