46 WEMフレームワークとサービスの理解

アプリケーション開発者の環境は、RESTサービスを使用してWebCenter Sites上で実行されるWEMフレームワークで構成されます。WebCenter SitesへのRESTコールは、アプリケーションで任意の言語で記述することで実行できます。カスタム構築アプリケーションは、プラットフォームのアプリケーション・サーバー以外のアプリケーション・サーバーにデプロイ可能であるため、プラットフォームのデプロイメント・インフラストラクチャとは別に記述できます。

WEMフレームワークとサービスの詳細は、次の項を参照してください。

46.1 アプリケーション開発のサポート

WEMでアプリケーションを開発しているとき、RESTサービスを使用してWebCenter Sitesオブジェクトにアクセスし、UIコンテナを使用してアプリケーションを公開し、SSOを使用してユーザーを認証し、REST認可モデルを使用してRESTリソースへのアクセスを制御します。

アプリケーション開発のサポートは、次のコンポーネントで行われます(この章のそれぞれの項も参照してください)。

  • RESTサービス: WebCenter Sitesオブジェクトへのアクセスを提供する一連のプログラム・インタフェース。

  • UIコンテナ: 登録済アプリケーションを公開します。登録によって、アプリケーションのインタフェースのレンダリングが可能になります。また、UIコンテナは、ログイン済ユーザーや現在のサイトに関する詳細情報をWEMフレームワークから取得するためにアプリケーションで使用する、WEMコンテキスト・オブジェクトもサポートしています。

  • シングル・サインオン(SSO): 認証されたユーザーが1回ログインするのみで、そのセッション中に許可されるすべてのアプリケーションにアクセスできるようになります。(WebCenter Sitesインストール・プロセスでは、WEMのシングル・サインオンをサポートするCentral Authentication Service Webアプリケーションがインストールされます。)

  • REST認可モデル: グループ・メンバーシップに基づいて、RESTリソースへの詳細なアクセス制御を提供します。アプリケーション開発は、事前定義済ユーザーがコードで指定されている場合を除き、(WEM AdminおよびAdminインタフェースでグラフィカルに構成されている)認可には直接関係していません。

WEM AdminWEMフレームワークの一部ですが、アプリケーション開発に使用されることはほとんどなく、主に、アプリケーション登録プロセスの結果をテストしたり、サイト、ユーザー、グループ、ロールに関する管理情報を取得したりするために使用されます。WEM AdminおよびWebエクスペリエンス管理フレームワークの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

46.2 RESTサービス

REST APIでは、WebCenter Sitesデータ・モデルと、サイト、ユーザー、ロール、ACL、グループなどのオブジェクトを公開できます。

  • ベーシック・アセット・タイプおよびベーシック・アセット(読取り/書込み)

  • フレックス・アセット・タイプおよび定義(読取り専用)

  • フレックスの子と親(読取り/書込み)

  • 索引付けによるアセット検索のサポート

次のオブジェクトも、REST APIで公開されます。これらは、主に認可プロセスで管理者が使用します(オブジェクトはWEM Adminインタフェースに表示されます)。

  • サイト(読取り/書込み)

  • ユーザー(読取り/書込み)

  • ロール(読取り/書込み)

  • ACL (読取り専用)

  • グループ(読取り専用): RESTレイヤーへのアクセスを制御するためにこのリリースで導入されました。

  • 補助サービス: ユーザー・ロケールおよびサーバーのタイムゾーン

(サイト、ロールおよびユーザーはWEM Adminで構成できます。ACLおよびグループは、読取り専用アイテムとしてWEM Admin (「ユーザー」の下)に公開されます。それらは、Adminインタフェースで構成する必要があります。)

WebCenter Sitesのオブジェクトは、WEM内のRESTリソースにマップされます。パブリッシュ、ワークフロー、データベース管理ツール、ページのキャッシングなど、他のすべての機能には、Adminインタフェースから、またはJSPやXMLタグを介してアクセスする必要があります。

一般管理者が管理する認可オブジェクトの中で、サイトおよびロールが、要件によってはアプリケーション管理の候補となる可能性が高いです。また、管理者の認可タスクを簡素化するために、事前定義済ユーザーを指定することもできます。

  • サイト: アプリケーション・コードでのサイトの使用は、アプリケーションのアセット・タイプとアセットをプログラムでインストールする必要がある場合の要件です。コードでアセット・タイプを有効にするサイトを1つ以上指定する必要があります(アセットへのサイト固有のアクセスを行うには、それらのアセット・タイプが1つ以上のサイトで有効になっている必要があります)。そうでない場合は、サイトを指定しないで、アセット・タイプを単にインストールします。その後、管理者は、Adminインタフェースを使用して、独自に選択したサイト上でアセット・タイプとアセットを有効にします。

  • ロール: WEMでは、ロールはアプリケーションへのアクセスを管理するために使用します。同じサイト上のユーザーとアプリケーションでロールを共有すると、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。アプリケーション・コードでロールを使用すると、Editなどの、インタフェース機能を保護できます。Adminインタフェースは、ロールで保護されたインタフェース機能を備えたアプリケーションの一例です。

  • ユーザー: アプリケーション・コードで指定する可能性のある唯一のユーザーは、管理者の認可プロセスを簡略化するための事前定義済ユーザーです。ユーザーの指定には、ユーザー名とパスワードのコーディングが含まれます。管理者は、すべてのアプリケーション・ユーザーをRESTレベルで個別に認可するかわりに、事前定義済ユーザーを認可します。事前定義済ユーザーに付与された権限は、ユーザーがアプリケーションにアクセスするとログイン済ユーザーに引き継がれます。事前定義済ユーザーおよび認可モデルの詳細は、「認可モデル」を参照してください。

システム全体においてサイトとロールがどのように使用されているかを追跡するのは管理者のタスクですが、これにはアプリケーション開発者によるサポートが必要です。トラッキングは、WebCenter Sitesプラットフォームがステージング・システムとしても機能する場合に特に重要ですが、これは、WEMフレームワークがWebCenter Sitesデータベースを使用しているからです。たとえば、WEM Adminで作成されたサイトはデータベースに格納されます。それらはステージング用にWebCenter Sitesで使用されるとはかぎりませんが、Adminインタフェースで専用のCMサイトと一緒に公開されます。反対に、CM用途でAdminインタフェースで作成されたサイトは、WEM Adminで公開され、その他のアプリケーションをそれらのサイトに割り当てることができます。ユーザーが適切に認可されるには、開発者はカスタム構築アプリケーションの性質を管理者に伝達する必要があります。そのような性質には、ユーザーが使用するリソース、ロールで保護されたインタフェース機能、事前定義済ユーザー(存在する場合)などが含まれます。

46.3 UIコンテナ

UIコンテナでは、登録済アプリケーションをWEM Adminで公開します。管理者は、これらのアプリケーションを管理して、他のユーザーが使用できるようにします。このコンテナを使用して、コンテキスト・オブジェクトをサポートします。これらのアプリケーションでは、ログイン・ユーザーやサイトに関する詳細情報(たとえば、UIコンテナからの現在のサイトの名前など)をWEMフレームワークから取得するために、およびアプリケーションでデータの共有に使用するユーティリティ・メソッドの取得のために、このオブジェクトが必要です。

トピック:

46.3.1 登録

アプリケーションを登録する目的は、管理者がアプリケーションを管理したり、他のユーザーに提供したりできるように、WEM Adminでアプリケーションを公開することです。登録を行うと、そのアプリケーションがアセットとして認識され、次のことが実行されます。:

  • WEM Adminの「アプリケーション」ページにアプリケーションが一覧表示されます

  • アプリケーションを表すために選択したアイコンが配置されます

  • WebCenter Sitesのログイン・ページ、およびアプリケーションが割り当てられている各サイトのアプリケーション・バーにアプリケーションのアイコンが表示されます

  • アプリケーションのアイコンが選択された際にアプリケーションのインタフェースがレンダリングされます

    図46-1 UIコンテナの登録済アプリケーション

    図46-1の説明が続きます
    「図46-1 UIコンテナの登録済アプリケーション」の説明

アプリケーションの登録には、そのビューの登録が含まれています。複数の共有ビューがサポートされますが、単一の非共有ビューを使用するアプリケーションが一般的です(ガイドのこの部分でも使用しています)。iframe、HTMLおよびJavaScriptタイプのビューを使用できます。

登録をサポートするために、WEMフレームワークには、ベーシック・アセット・タイプFW_ApplicationFW_Viewが付属しています。いずれも、WebCenter Sitesインストール・プロセスでWEMオプションを選択した場合に作成されます。これらは、AdminSiteにおいてデフォルトで有効になります(WebCenter Sitesのインストール・プロセスでも作成されます)。

アプリケーションを登録するには(デプロイされている場合)、FW_Applicationのインスタンスの作成、各ビュー用のFW_Viewインスタンスの作成、およびFW_ApplicationインスタンスへのFW_Viewインスタンスの関連付けが必要です。他のサイトでアプリケーションを使用する場合でも、そのアプリケーションをAdminSiteで登録する必要があります。登録すると、アプリケーションを他のサイトに割り当てることができます。

アプリケーションは、REST APIのapplicationsサービスを介してプログラムで登録することも、Adminインタフェースから手動で登録することもできます。プログラムによる登録をお薦めします。一般的な手順は、「様々なビューを使用したアプリケーションの登録」を参照してください。手動登録の例は、「WEMフレームワークでのアプリケーションの手動登録」を参照してください。

46.3.2 WEMコンテキスト・オブジェクト

UIコンテナは、コンテナ内のすべてのアプリケーションにJavaScriptコンテキスト・オブジェクト(WemContext)を提供します。コンテキスト・オブジェクトは、ログイン・ユーザーやサイトに関する詳細情報をWEMフレームワークから取得する際にアプリケーションで使用されます(たとえば、UIコンテナからの現在のサイトの名前など)。また、コンテキスト・オブジェクトは、アプリケーションでデータを共有する際に使用する様々なユーティリティ・メソッドも提供します。コンテキスト・オブジェクトは、WebCenter Sitesと同一ドメインまたは異なるドメインで実行されているアプリケーションで使用できます。WEMフレームワークからのパラメータへのアクセスを参照してください。

46.4 シングル・サインオン

Webのシングル・サインオン・プロトコルであるCentral Authentication Service (CAS)を使用して、シングル・サインオンを実装します。CASは、ユーザーが1回ログインするのみで複数のアプリケーションにアクセスできるようにします。

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で保護されているアプリケーションにアクセスしようとすると、認証システムが次のステップで応答します。

  1. 初回アクセス

    1. ユーザーがCASで保護されているアプリケーションに最初にアクセスしようとすると、ユーザーはCASログイン・ページにリダイレクトされます。

    2. ログインが成功すると、ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。CASログイン・ページのCookieが保存されます。

    3. アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。(コンテンツ管理システムでは、CASはデフォルトでWebCenter Sitesデータベースに対して認証を行います。)

      図46-2 CASで保護されているアプリケーションへのアクセス

      図46-2の説明が続きます
      「図46-2 CASで保護されているアプリケーションへのアクセス」の説明
  2. 2回目以降のアクセス

    1. CASで保護された別のアプリケーションにユーザーがアクセスしようとすると、ユーザーはCASログイン・ページにリダイレクトされます。

    2. リクエストからCookieが取得されて暗黙的ログインが実行され、ログイン・ページは省略されます。

    3. ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。

    4. アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。

46.5 認可モデル

一般管理者は、WEM Adminを使用してアプリケーションへのアクセス権をユーザーに付与します。事前定義済ユーザーをコーディングすることにより、管理者のジョブを簡素化できます。

一般管理者はWEM Adminを使用してオブジェクトを連結します。アプリケーションに事前定義済ユーザーをコーディングします。以降では、ユーザーを認可モデルに適合させる方法について説明します。

次の図のサイト、アプリケーション、ユーザーおよびロールには、それぞれに対応するWEM Adminのメニュー・オプションがあります。ACLおよびグループは、各ユーザーのページで公開されます。

図46-4 WEM Adminメニュー・バー

図46-4の説明が続きます
「図46-4 WEM Adminメニュー・バー」の説明

認可は3つのレベル(アプリケーション、RESTおよびデータベース)で管理されます。

  • アプリケーション・レベルの認可では、同じサイト上のユーザーとアプリケーションでロールを共有する必要があります。これにより、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。ロールで保護されているインタフェース機能のロールは、アプリケーション・ユーザーと共有されている必要があります。

  • RESTレベルの認可では、ユーザーがアプリケーションのリソースを操作するための権限を制限します(ACLが正しく割り当てられていることが前提です)。 RESTレベルの認可では、RESTリソースにマップされるオブジェクトへの操作権限を持つグループを構成する必要があります。グループに割り当てられたユーザーにはグループの権限が付与されます。

    開発者は、ログイン済ユーザーのプロキシとして動作するユーザーをアプリケーションで定義できます(ユーザー名とパスワードを指定する)。これにより、管理者がログイン済ユーザーごとにRESTセキュリティを構成する必要がなくなります。アプリケーションがデプロイおよび登録されると、一般管理者は次の方法で事前定義済ユーザーを認可します。1) WEM Adminで、アプリケーションにアクセスするための事前定義済ユーザーを構成し、2)アプリケーションのリソースの操作権限を持つグループを(Adminインタフェースで)構成して、3)事前定義済ユーザーを(WEM AdminまたはAdminインタフェースのいずれかを使用して)そのグループに割り当てます。グループの権限は事前定義済ユーザーに渡され、ログイン済ユーザーがアプリケーションにアクセスする際に、そのログイン済ユーザーに渡されます。サポートされているセキュリティ構成は、「REST認可」に説明およびリストされています。WEMフレームワークで提供されているArticlesサンプル・アプリケーションでは、事前定義済ユーザーを指定します。

  • データベース・レベルでは、そのユーザーのグループ・メンバーシップにかかわらず、ACLによって個々のユーザーのシステムへのアクセス(つまり、ログイン権限、データベースの操作権限)が決定されます。グループのメンバーシップでは、適切なACLが割り当てられていないユーザー、およびデータベース表への権限を付与しません。

    デフォルトのACLでは、多くのデータベース表のオブジェクトに対してほぼ無制限の操作権限(手段ではない)がユーザーに提供されます。それらの権限を調整するには、RESTレベルで、ユーザーのグループ・メンバーシップによって直接調整するか(事前定義済ユーザーが存在しない場合)、アプリケーションの事前定義済ユーザーとそのユーザーのグループ・メンバーシップによって間接的に調整します。オブジェクトに対するグループの操作権限を変更すると、そのグループ・メンバーのリソースに対する操作権限も変更されます。WebCenter Sites側の同一ユーザーはグループ・メンバーシップによる影響は受けません。コンテンツに対する権限は、引き続きACLによって制限され、サイトとロールによって機能します。

46.6 カスタム・アプリケーション

WEMを使用すると、コンテンツ管理プラットフォームに対して疎結合された形で実装できるカスタム・アプリケーションを開発できます。開発するアプリケーションでは、REST API WebサービスおよびWEMフレームワークによって有効化されるSSOメカニズムが使用されます。これらのアプリケーションを、プラットフォームのアプリケーション・サーバーとは異なるアプリケーション・サーバーにデプロイします。そのため、プラットフォームのデプロイメント・インフラストラクチャから切り離してカスタム・アプリケーションを作成できます。

ほとんどのカスタム・アプリケーションはリモートでデプロイされます。

図46-5 リモートでのアプリケーションのデプロイメント

図46-5の説明が続きます
「図46-5 リモートでのアプリケーションのデプロイメント」の説明

カスタム・アプリケーションは、コンテンツ管理アプリケーションまたは配信アプリケーションとして実装できます。一般的に、コンテンツ管理側ではパフォーマンス・チューニングの手間がそれほどかからないため、コンテンツ管理側から着手することをお薦めします。

WEMフレームワークには、いくつかの軽量のサンプル・アプリケーションが付属しており、それぞれ専用アプリケーションを開発するためのモデルとして起動および分析できます。Articlesは、コンテンツ管理アプリケーションを示しています。仕様については、「WEMフレームワークでのアプリケーションの開発」を参照してください(ソース・コードはWebCenter Sites Misc/Samplesフォルダにあり、その他のサポート情報はREST APIリソースおよびBeanリファレンスに記載されています)。SSOサンプル・アプリケーションはライブ・サイトでの認証用で、RecommendationsアプリケーションはRESTリソースの作成方法を示しています。

46.7 RESTリソースの要件

RESTリクエストには、CASチケットまたはセッションIDのキーおよび値を持つヘッダーが必要です。

すべてのREST POST/PUT/DELETEリクエストを有効であると認証するには、各リクエストには、X-CSRF-Tokenキーを持つヘッダーと、CASチケット(マルチまたはシングル)またはsessionidのいずれかの値が必要です。