Portal Server ノード

必ずではありませんが、通常は、以下のさまざまなポータルノード (サーバー) Portal Server ソフトウェアを配備して、連携動作することによってポータルを実装します。

• Portal Server ノード。Portal Server が常駐する Web サーバーです。必要であれば、このノードに検索コンポーネントをインストールすることもできます。Access Manager もここに常駐可能です。

• Access Manager ノード 。Access Manager が常駐可能なサーバーです。Access Manager は、Portal Server と同じノードに常駐する必要はありません。

• 検索ノード 。オプションです。Portal Server の検索サービスで使用するサーバーです。Portal Server 検索サービスは、パフォーマンス、スケーラビリティー、および可用性を高めるために、独自のサーバーにインストールできます。

• ゲートウェイノード 。オプションです。Secure Remote Access ゲートウェイが常駐するサーバーです。ゲートウェイはポータルノードにインストールできます。ゲートウェイは DMZ に配置するので、分離されたポータル以外のノードにインストールされます。

• Netlet プロキシノード 。オプションです。ユーザーのイントラネットでアプリケーションを実行しているリモートデスクトップとサーバーの間で、アプリケーションをセキュリティー保護して実行するために使用されるサーバーです。

• リライタプロキシノード 。オプションです。ユーザーのイントラネットでアプリケーションを実行しているリモートデスクトップとサーバーの間で、アプリケーションをセキュリティー保護して実行するために使用されるサーバーです。

• Directory Server ノード 。Directory Server ソフトウェアを実行しているサーバーです。Directory Server はポータル以外のノードにインストールできます。

• その他のサーバー 。メールサーバーやファイルサーバーのようなサーバーおよび旧バージョンのサーバーは、バックエンドサポート、データ、およびアプリケーションをポータルユーザーに提供します。

異なるノードにある Portal Server と Access Manager

Portal Server と Access Manager は異なるノードに置くことができます。このタイプの配備には、次の利点があります。

• アイデンティティーサービスをポータルサービスとは別に配備できます。Portal Server は、アイデンティティーサービスを使用する多くのアプリケーションのうちの 1 つにすることができます。

• 認証サービスとポリシーサービスを、Portal Server 関連のアプリケーションを含むプロバイダのアプリケーションから分けることができます。

• 他の Web コンテナが Access Manager を使用して、そのポータルのカスタマイズの開発を支援できます。

Portal Server と Access Manager を異なるノードに置く場合、Access Manager SDK は Portal Server と同じノードに存在する必要があります。Web アプリケーションとサポートする認証デーモンは、Portal Server インスタンスとは別のノードに置くことができます。

Access Manager SDK は、次のコンポーネントから構成されています。

• アイデンティティー管理 SDK — ユーザー、ロール、グループ、コンテナ、組織、組織単位、およびサブ組織を作成および管理するための枠組みを提供します。

• 認証 API および SPI — 認証サービスのすべての機能へのリモートアクセスを可能にします。

• ユーティリティー API — システムのリソースを管理します。

• ロギング API および SPI — 数ある中でも、アクセスの承認、アクセスの拒否、およびユーザーの活動を記録します。

• クライアント検出 API — リソースへアクセスしようとしているクライアントのブラウザのタイプを検出し、適切にフォーマットされたページで応答します。

• SSO API — セッショントークンの検証と管理のインタフェース、またユーザー認証の資格を管理するインタフェースを提供します。

• ポリシー API — Access Manager のポリシーを評価および管理し、ポリシーサービスの追加機能を提供します。

• SAML API — 認証、承認決定、および属性の情報を交換します。

• 連携管理 API — Liberty Alliance Project 仕様に基づいた機能を追加します。

Portal Server システムの通信リンク

図 4–1 は、ソリューションの可用性に重要な Portal Server システムのプロセスおよび通信リンクを示しています。

図 4–1 Portal Server の通信リンク

この図では、Web Server 技術で稼働する Portal Server インスタンスがボックスで囲まれています。このインスタンスには、5 つのサーブレット (認証、Portal Server 管理コンソール、ポータルデスクトップ、通信チャネル、および検索) と 3 つの SDK (Access Manager SSO、Access Manager ロギング、および Access Manager 管理) が含まれています。認証サービスサーブレットは、LDAP サービスプロバイダモジュールも利用します。

ユーザートラフィックは、適切なサーブレットにダイレクトされます。通信は、認証サービスの LDAP モジュールと LDAP 認証サーバー間、通信チャネルサーブレットと SMTP/IMAP メッセージングサーバー間、Access Manager SSO SDK と LDAP サーバー間、Access Manager 管理 SDK と LDAP サーバー間で行われます。

図 4–1 は、次のプロセスまたは通信リンクに障害が発生すると、エンドユーザーがポータルソリューションを利用できなくなることを示しています。

• Portal Server インスタンス。Web コンテナのコンテキストで実行されます。インスタンスに含まれるコンポーネントは、Java API を使用して JVM を介して通信します。インスタンスは、完全修飾ドメイン名と TCP ポート番号です。Portal Server サービスは、サーブレットまたは JSP^TM ファイルとして実装される Web アプリケーションです。

  Portal Server は、認証シングルサイオン (セッション) 管理、ポリシー、およびプロファイルデータベースアクセスのために Access Manager 上に構築されます。したがって、Portal Server は可用性と障害許容性に関して Access Manager のすべての利点 (および制約) を継承します。

  設計により、Access Manager のサービスは、ステートレス、またはサービスがコンテキストデータを共有できるのどちらかになります。サービスは、サービスに障害が発生した場合に前の状態に戻ることができます。

  Portal Server では、ポータルデスクトップはインスタンス間で状態データを共有しません。これは、インスタンスのリダイレクトによって、有効になったサービスに対してユーザーコンテキストが再作成されることを意味します。通常、リダイレクトされたユーザーはこれに気がつきません。これは、Portal Server サービスがユーザーコンテキストをユーザーのプロファイルから、また要求に格納されたコンテキストデータを使用することによって再作成できるためです。これは一般にインストール後即使用可能なサービスに当てはまりますが、チャネルやカスタムコードには当てはまらないことがあります。開発者は、インスタンスのフェイルオーバー時にコンテキストを失うのを避けるためにステートフルチャネルを設計しないように注意する必要があります。

• プロファイルデータベースサーバー 。プロファイルデータベースサーバーは、Directory Server ソフトウェアによって実装されます。このサーバーは厳密には Portal Server の一部ではありませんが、このサーバーの可用性とデータベースの完全性はシステムの可用性に欠かせません。

• 認証サーバー 。これは LDAP 認証のためのディレクトリサーバーです (通常、プロファイルデータベースサーバーと同じサーバー)。このサーバーには、プロファイルデータベースサーバーと同じ高可用性技術を適用できます。

• Secure Remote Access ゲートウェイとプロキシ 。Secure Remote Access ゲートウェイは、状態情報をエンドユーザーに透過に再作成できるため、ステートレスとみなすことのできるスタンドアロンの Java テクノロジプロセスです。ゲートウェイプロファイルは、Portal Server インスタンスのリストを維持し、ゲートウェイインスタンス間でラウンドロビン方式のロードバランスを行います。ゲートウェイの前ではセッション固定の必要はありませんが、セッションが固定されると、パフォーマンスが向上します。一方、Portal Server インスタンスに対するセッション固定は Secure Remote Access によって実施されます。

  Secure Remote Access には、Netlet プロキシとリライタプロキシと呼ばれるほかの Java テクノロジプロセスも含まれます。これらのプロキシを使用して、ファイアウォールの背後からセキュリティーの適用範囲を拡張し、DMZ の穴の数を制限できます。これらのプロキシは、別々のノードにインストールできます。