第 6 章認証、ユーザー、およびサービスの管理

この章では、Sun Java^TM System Access Manager を使用して、認証、ユーザー、およびサービスを管理する方法を説明します。ここでは、Sun Java^TM System Portal Server に関係する側面に重点を置いています。Access Manager のすべての側面については説明していません。詳細については、Access Manager のマニュアルを参照してください。

Sun Java System Access Manager の概要

Sun Java System Portal Server (旧 Sun^TM ONE Portal Server) の実装では、認証方法の管理、ドメイン、ロール、およびユーザーの作成、プロファイルの属性やログなどのその他のデータの管理に、この製品を使用します。また、カスタムアプリケーションの開発には iPlanet Portal Server 3.0 API も使用します。

Portal Server 6 製品では、以前は iPlanet Portal Server 3.0 によって提供されていた Access Manager の管理機能と API を使用します。Access Manager は、Sun Java^TM System Directory Server の管理機能とセキュリティー機能を活用するツールセットです。Access Manager では、Sun Java System Directory Server を使用する組織に、ユーザーオブジェクト、ポリシー、およびサービスを管理するためのインタフェースが提供されます。

Sun Java System Directory Server による、データセキュリティーを向上させたユーザー認証およびシングルサインオンの実行。

管理者による、ロール (ユーザーエントリの属性として表現される、エントリのグループ化の仕組み) に基づくユーザーエントリ管理。

開発者による、デフォルトサービスおよびカスタムサービスの設定パラメータの定義と管理。

これらの機能には、Web ベースの Access Manager 管理コンソールによるグラフィカルユーザーインタフェースか、またはコマンド行インタフェース (amadmin) からアクセスできます。コマンド行インタフェースを使用すると、Directory Server でバッチ管理タスクを実行できます。

Access Manager の機能の概要

Access Manager には、次の管理コンポーネントがあります。従来は、これらのコンポーネントは Portal Server 3.0 のフレームワーク自体に含まれていました。

ユーザー管理: ユーザー関連オブジェクト (ユーザー、ロール、グループ、ピープルコンテナ、組織、サブ組織、部署のオブジェクト) を作成、管理します。これらのオブジェクトは、Access Manager コンソールまたはコマンド行インタフェースのいずれかを使用して、定義、変更、または削除できます。

認証: ユーザー認証のプラグインソリューションを提供します。特定のユーザーを認証するのに必要な条件は、Portal Server エンタープライズの各組織に設定された認証サービスに基づきます。Portal Server セッションへのアクセス許可を受ける場合、ユーザーはその前に認証に成功する必要があります。

シングルサインオン: ユーザーが認証されると、Access Manager のシングルサインオン (SSO) 用 API が、認証を継承します。認証されたユーザーが保護されたページへのアクセスを試みると、そのたびに SSO API は認証証明情報に基づいて、ユーザーが適切なアクセス権を持っているかどうかを判断します。ユーザーが有効であれば、追加認証なしでページへのアクセスが許可されます。無効であれば、ユーザーに再認証が求められます。

サービス管理: Portal Server 製品自体のサービス (ポータルデスクトップ、リライタ、検索、および NetMail) を含む、デフォルトサービスとカスタムサービスの設定パラメータを指定します。

ポリシー管理: ビジネスリソースへのアクセスを制御するルールを定義、変更、または削除します。ポリシーとは、これらのルールの総称です。ポリシーは、ロールまたは組織に基づき、アクセス権を与えたり、制約を定義したりすることができます。

Portal Server 3.0 と Portal Server 6.2 の比較

91 ページの表 6-1 は、Portal Server 製品の主な変更の概要を示しています。Access Manager には、Sun ONE Portal Server 3.0 (旧 iPlanet Portal Server 3.0) 製品の一部であった多くの特徴と機能が含まれています。この表では、1 列目に概念または用語を示し、2 列目に Portal Server 3.0 製品でのその用語の特徴や機能を定義し、3 列目で Portal Server 6.2 製品での対応する特徴や機能について説明します。

Portal Server 6.0 と Portal Server 6.2 の比較

96 ページの表 6-2 は、Portal Server 6.0 から Portal Server 6.2 への改訂で加えられた変更の概要を示しています。この表では、1 列目に概念または用語を示し、2 列目に Portal Server 6.0 製品でのその用語の特徴や機能を定義し、3 列目で Portal Server 6.2 製品での対応する特徴や機能について説明します。

Access Manager の制約

事前定義された Access Manager ロールは、複数の並列組織に割り当てることはできません。ただし、ロールは、ロールが関連する組織の子組織に属するユーザーに割り当てることができます。また、複数ドメインのリソースへのアクセスは、カスタムロールを作成し、また必要な ACI を定義して、必要な権限をロールに付与することにより可能になります。

ユーザーは、組織に属する必要があり、その組織にだけ属することができます。

階層型ロールはサポートされません。たとえば、ロール A およびロール B の合計に等しいものとしてロール C を作成することはできず、また、ロール C を持つユーザーは、明示的にロール A に割り当てられていないかぎり、ロール A のリソースにアクセスできません。

RoleAdministratorRole のアクセス権は、対応する ACI を直接編集した場合にのみ設定できます。

ロール管理者 (委任管理者) が Access Manager 管理コンソールにログインする場合、ロール管理者に修正する権限がない場合でも、同じ組織にあるロール、および関連するサービスとプロパティーのすべてを表示できます。

Access Manager インタフェース

Access Manager 管理コンソール

このブラウザベースのコンソールは、グラフィカルユーザーインタフェースを提供して、Portal Server サービスなどの Access Manager エンタープライズを管理します。管理コンソールには、サービス、ポリシー、およびユーザーの作成と管理に使用するさまざまなレベルの権限を持つデフォルトの管理者が含まれます (委任管理者を追加する場合は、ロールに基づいて管理者を作成できる)。詳細については、第 7 章「管理の委任の設定」を参照してください。

Access Manager 管理コンソールは、3 つのセクションに分割されています。ロケーションパネル、ナビゲーションパネル、およびデータパネルです。3 つのパネルを使用して、ディレクトリを移動したり、ユーザーおよびサービスの設定を実行したり、またポリシーを作成したりします。

Access Manager コマンド行

Access Manager コマンド行インタフェースは、サーバーを管理する amadmin です。また、amadmin は、XML サービスファイルをディレクトリサーバーにロードし、ディレクトリツリーでバッチ管理タスクを実行するのに使用します。iPlanet^TM Portal Server 3.0 のコマンド行インタフェース、ipsadmin および ipsserver は、現在、使用されていません。

amadmin については、Access Manager のマニュアルを参照してください。

Access Manager 管理コンソールへのログイン

Access Manager コンソールへは、次のどちらかの方法でログインできます。

固有の URL を使用する

HTTPS を経由する

管理コンソールにログインする場合、表示される機能は、ユーザーのアクセス権によって異なります。アクセス権は、ACI あるいはユーザーに割り当てられたロールによって決まります。たとえば、スーパーユーザーには、管理コンソールのすべての機能が表示されます。一方、代理管理者には、通常、サブ組織についてこの機能のサブセットだけが、またエンドユーザーには、自分のユーザー ID に関係するユーザー属性だけが表示されます。

管理コンソールへは、次のどちらかの URL でログインできます。

http://host:port/amconsole/

http://host:port/amserver/

URL /amconsole は、Access Manager 管理コンソールの HTML ページを明示的に要求します。/amconsole を使用してログインすると、管理コンソールが表示され、URL が /amserver/UI/login に変わり、ユーザーが認証を行えるようになります。設定に関係なく、この URL を管理コンソールへのアクセスに使用することができます。

URL /amserver は、Access Manager サービスの HTML ページを要求します。Portal Server のインストールの際にセットアップされるデフォルトでは、この URL にリダイレクトして管理コンソールにログインすることになっていますが、URL /amserver は、Access Manager サービスにアクセスするため、この URL はコンソール以外のその他のサービスを利用可能にするために使用できます。たとえば次のように指定します。

ユーザーが無効なセッションを持つアプリケーションにアクセスする場合、アプリケーションは、URL /amserver 要求を goto パラメータで amserver/UI/login に転送する場合があります。たとえば、Portal Server デスクトップは、Access Manager エージェントと同様にこの転送を行います。

顧客は、アプリケーションまたはポータルへの開始位置として amserver/UI/login にユーザーを転送する場合があります。また、デフォルトのリダイレクト URL が、ポータルアプリケーションまたはカスタムアプリケーションになる場合があります。

カスタムアプリケーションが、amserver/UI/login を直接呼び出し、認証する場合があります。

Access Manager 管理コンソールにログインするには次のようにします。

固有の URL を使用する:
http://host:port/amserver/ を入力します。
または
http://host:port/amconsole/ を入力します。

HTTPS を使用する:
https://host:ssl_port/amconsole/ を入力します。

IP アドレスを使用した管理コンソールへのログインの設定

サーバーの IP アドレスを使用して Access Manager 管理コンソールにログインすることはできません。これは Access Manager での cookie のドメイン設定によるものです。

ただし、管理コンソールの「Cookie ドメイン」リストに、ローカルホストの IP アドレスを追加することはできます。

ロケーションパネルで「サービス設定」を選択します。

「プラットフォーム」をクリックします。

「グローバル」にローカルホストの IP アドレスを追加します。

これで、ドメイン名ではなく IP アドレスで管理コンソールにアクセスできます。

基本情報の表示

スクリプトにより、jar ファイルのバージョンおよびビルドの日付だけでなく、Portal Server のバージョンやビルドの日付など、製品についての基本情報を表示することができます。バージョンスクリプトは、PortalServer-base/SUNWps/bin ディレクトリにインストールされます。ここで PortalServer-base は、Portal Server をインストールしたベースディレクトリです。デフォルトは /opt です。

製品情報を表示する

スクリプトがインストールされているディレクトリに移動します。次のように指定します。

cd PortalServer-base/SUNWps/bin

Portal Server についての情報を表示するには、次のように入力します。

./version

Portal Server の jar ファイルについての情報を表示するには、次のように入力します。

./version jar-file

ここで jar-file は jar ファイルの名前です。

Portal Server の起動と停止

ここでは、Portal Server の停止および起動方法について説明します。それぞれの Web コンテナ用のスクリプトを使用して、その Web コンテナインスタンスを再起動する必要があります。

これらの操作は、Web コンテナによって異なります。詳細については、Web コンテナのマニュアルを参照してください。

Portal Server は、さまざまなプラットフォームのロケールをサポートしています。Portal Server をインストール済みのデフォルト値以外で起動する方法については、『Sun Java System Portal Server 6 2005Q4 Developer不 Guide』を参照してください。

Sun Java System Web Server インスタンスを起動する

Sun Java System Web Server インスタンスを停止する

Sun Java System Application Server を起動する

Access Manager サービスの管理

ここでは、Portal Server が使用する Access Manager サービスについて説明します。詳細については、Access Manager のマニュアルを参照してください。

インストールおよび Sun Java System Web Server パッケージ

Portal Server インストーラは、Access Manager がインストールされていない場合、Access Manager インストーラを実行します。

Portal Server は、Access Manager と Web コンテナを共有します。Web コンテナは、並行性、配備、ライフサイクル管理、セキュリティー、トランザクション、その他のサービスを含む Web コンポーネントの実行時環境を指定します。

Portal Server は、Java^TM 仮想マシン (JVM^TM ソフトウェア) および Access Manager が提供するその他のコンポーネントを使用します。

ユーザー管理

Portal Server は、Access Manager API を使用して、自身のプロファイル情報を Access Manager に格納します。

Portal Server は、Access Manager の複数ロールサポートを活用します。

Portal Server は、たとえば、givenName など、オープンで所有者のいない標準のスキーマの属性を使用します。

Access Manager は、LDAP ディレクトリへの直接アクセスを提供します。

シングルサインオン / 認証

Portal Server の認証は、Access Manager によって管理されます。

Access Manager は、すべての認証モジュールを提供します。

Portal Server は、Access Manager のポリシー属性を使用して、アクセスを制限します。

サービス管理

デスクトップ: ポータルフロントエンドを提供する、ポータルへのプライマリエンドユーザーインタフェース。ポータルデスクトップのセットアップおよび管理については、第 8 章「ポータルデスクトップサービスの管理」を参照してください。

NetMail: インターネット上で IMAP および SMTP メールサーバーにアクセスし、ポータルを通じてユーザーが電子メールにアクセスできるようにします。NetMail のセットアップおよび管理については、第 11 章「NetMail サービスの管理」を参照してください。

リライタ: 管理者によってセットアップされるルールを実装し、適切にアクセスできるように URL をリライトします。リライタのセットアップおよび管理については、第 12 章「リライタサービスの管理」を参照してください。

検索: 使用可能なドキュメントの基本および詳細検索チャネルなどの検索機能を Portal Server に提供します。検索サービスのセットアップおよび管理については、第 13 章「検索エンジンサービスの管理」を参照してください。

Portal Server ユーザーの管理

ディレクトリ情報ツリー (DIT) では、ユーザー、組織、サブ組織などが論理構造または階層構造に編成されます。これによって、これらのロールを想定しているユーザー、または組織内に属しているユーザーへの適切なアクセスを効率的に管理し、割り当てることができるようになります。

この節では、組織、サブ組織、およびロールの機能と性能についての情報を説明し、また、組織、ロール、およびユーザーの作成と管理の手順を示して、Portal Server の実装の基本となるディレクトリ構造またはツリーの設計に役立つ情報について説明します。

Access Manager の組織ツリーの最上位は、インストール時に指定されます。インストール後に、追加の組織を作成して、別の企業を管理することができます。作成された組織はすべて最上位組織の下に配置されます。これらのサブ組織内で、ほかのサブ組織を入れ子にできます。入れ子の構造の深さに制限はありません。

ロールは、より効果的に、またより簡単にアプリケーションを使用するように設計された新しいグループ化の仕組みです。それぞれのロールはメンバー、あるいはロールを保有するエントリを持ちます。グループの場合と同じく、ロールのメンバーは明示的またはダイナミックに指定できます。

ロールの仕組みにより、そのエントリがメンバーになっているすべてのロール定義の DN を含む nsRole 属性が自動的に生成されます。各ロールは、1 人または複数のユーザーに付与できる、単一の権限や権限のセットを含んでいます。複数のロールを 1 人のユーザーに割り当てることができます。

ロールの権限はアクセス制御命令 (ACI) で定義されます。Portal Server には、いくつかのロールが事前に定義されています。Access Manager コンソールを使用してロールの ACI を編集し、ディレクトリ情報ツリー内でアクセス権を割り当てることができます。用意されている例には、Top-level Admin Role および Top-level Help Desk Admin Role が含まれます。組織間で共有できるその他のロールを作成することもできます。

組織、サブ組織、およびロールの設計

DIT の構造を設計する場合、階層を持つツリー構造にするかフラットなツリー構造にするかを決めることが必要です。一般的には、作成するツリーをできるかぎりフラットにするようにします。ただし、ユーザーアクセスの付与および管理を容易にするには、組織の成長の大きさに合わせて、ある程度の数の階層があることが重要になります。

DIT 構造を構築するために必要な Access Manager の主要な 3 つのキー構造エンティティーは、組織 (サブ組織) 、ロール、およびユーザーです。構造を設計する前に、これらの各エンティティーの機能、特性、および相互関係について理解する必要があります。

組織およびサブ組織

所属する企業や組織の階層に対し、それを表現し形取った階層関係の作成を可能にします。

対応する管理者によって作成される特定のユーザーを含めることができます。これにより、管理およびアクセス制御の目的で、ユーザーをグループ化する方法が提供されます。通常、同じような必要性を持つユーザーをグループ化すると、アクセスの管理および制御がより簡単になります。

管理者が管理コンソールを使用して、親組織またはサブ組織を簡単に作成したり、削除したりすることができます。ただし、削除されると、すべてのサブ組織およびユーザーも削除されます。したがって、名前や構造を変更する可能性がある場合には適していません。

ロール

1 人または複数のユーザーへ、単一の権限や権限のセットを割り当てることを可能にします。組織内では、複数ロールを定義して特定の権限をユーザーに設定することができます。

直接編集する必要があるアクセス制御命令 (ACI) を通じて許可を定義します。一度定義すると、ACI を組織、サブ組織、またはユーザーに割り当てたり、割り当てを取り消すことが簡単にできます。1 つのエンティティーからのロールの割り当ての取り消しは、そのエンティティーにだけ適用されます。ロールは引き続き存在し、割り当てられたままでほかのエンティティーに割り当て直すことが可能なため、アクセスの変更が頻繁に必要な組織により適しています。

チャネルの可視性およびユーザーのチャネル上書き機能を制御します。XML ディスプレイプロファイル内で、XML ドキュメントのチャネルの可視または不可視をデフォルトに設定できます。また、XML ドキュメントのデフォルトのチャネルが上書きされないようにすることもできます。

ユーザー

人物の ID を表します。管理者が、組織またはサブ組織内に作成できます。

複数のロールに関連付けることができますが、ロールの範囲内にある必要があります。またユーザーは、サブ組織から属性を継承します。

1 つの組織またはサブ組織のみに属します。管理者に権限があれば、ユーザーをある組織から別の組織に簡単に移動できます。

チャネルの可視性をパーソナライズできます。

シナリオ 1: サブ組織とロールから構成される階層構造

構造をできるだけフラットにする必要はありますが、階層によっては、必要なグループ化を行うのに役立ちます。階層構造を作成するための手順の概要は次のとおりです。

最上位組織を作成します。

企業のユーザーの機能グループまたは組織グループをすべて識別し、DIT 構造エンティティーを作成するのに必要なグループ、すなわち固有の権限を持つ必要があるグループを決定します。通常、これは企業で唯一最大の下位部門で、管理者が管理する必要があります。一般的または機能的な名前を使用して、再編成および名前の変更に問題が発生しないようにします。

最上位組織となんらかの関係がある各 DIT エンティティーについて、そのエンティティーにサブ組織 (つまり、Access Manager 内に存在する別の組織のサブ組織)、またはロールを作成します。

次のガイドラインを使用して、サブ組織またはロールを使用するかどうかを判断します。

同様のアクセスの必要性を持つユーザーのグループ化を含むエンティティーにサブ組織を定義します。通常、これは、単一組の許可を割り当てることができる広範囲な機能エンティティー、または組織エンティティーです。

子組織のユーザーがこのロールを持つ必要があり得る場合は、ロールを定義します。すべてのユーザーは、1 つの組織またはサブ組織に属します。割り当てられたロールがない場合は、常駐する組織から許可を継承します。このため、属する組織および任意の親組織の両方の属性をユーザーが保有するようにする場合は、ロールの仕組みを使用して、複数のロールを割り当てる必要があります。

ロールごとに、RoleAdministratorRole を定義してロールを管理します。次に ACI を適切に設定します (管理権限: ユーザーの追加および削除、ロール属性の修正など)。

企業にアクセスするユーザーを定義します。ユーザーが組織の権限を継承している場合は、ユーザーを適切な組織に配置します。ユーザーがロールの割り当てを通じて権限を受け取る場合は、ロールの範囲内、つまり組織内に入るか、ロールが定義されている組織の子になるように配置する必要があります。

図 6-1 は、階層型ディレクトリ構造を示しています。この図では、最上位組織は Sesta.com です。最上位の 1 つ下には、組織と Corporate と Partners のサブ組織を管理する SestaAdminRole が置かれます。

Corporate 組織には、Finance、Operations、および Sales の 3 つのサブ組織があります。Sales 組織には、複数のタイプのユーザーが属するため、SalesRole1 および SalesRole2 の 2 つのロールが定義されています。Partners 組織には、Partner1、Partner2、および Partner3 の 3 つのサブ組織があります。これらの組織にはそれぞれ独自の管理者が必要であるため、3 つのロールが定義され、それぞれが適切な組織に関連付けられています。パートナロールは、PartnerAdmin1、PartnerAdmin2、および PartnerAdmin3 です。

シナリオ 2: フラットなツリー構造

組織を頻繁に変更する場合は、よりフラットな、あるいは全体として一様にフラットなツリー構造が適しています。1 つのピープルコンテナを含む 1 つの組織と、すべてが同じレベルのロールとから構成される構造は、企業を頻繁に変更する際に役立つことがあります。

組織が 1 つの場合は、企業の変更が DIT に影響を及ぼすことはありません。すべてのアクセス権が、ロールを使用して定義されます。すべてのユーザーが単一のピープルコンテナに格納され、またすべてのロールが同じレベルにあるため、任意のユーザーに任意のロールを割り当てることができます。

図 6-2 は、フラットなディレクトリ構造を示しています。この図で、最上位かつ唯一の組織は Sesta.com です。すべてのエンティティーは、この最上位組織の下に直接定義されます。これらのエンティティーには、SestaAdminRole があり、組織や、Finance、Operations、Sales1、および Sales2 ユーザーが必要とするさまざまな企業機能の 4 つのロール、およびパートナが必要とするユーザー機能の 6 つのロール、Partner1Role、Partner2Role、Partner3Role、Partner1AdminRole、Partner2AdminRole、および Partner3AdminRole を管理します。

新しい組織およびサブ組織の設定

組織とサブ組織を使用すると、管理およびアクセス制御を目的としてユーザーを構造化およびグループ化できます。企業の階層または構造を決定したあと、それを実装するために必要な組織とサブ組織を作成する必要があります。組織またはサブ組織を新しく作成する場合、デフォルトで定義されるサービス、ポリシー、ユーザー、およびロールはありません。このため、新しい組織またはサブ組織を作成する場合は、常に、次の手順で設定を行う必要があります。

組織で有効にするサービスをすべて追加します。詳細については、110ページの「サービスを追加する」を参照してください。通常、少なくとも次のサービスを追加します。

認証。コア認証サービスおよび組織のユーザーが認証に使用する任意の認証サービス (LDAP、匿名)。詳細については、125ページの「認証の設定」を参照してください。

URL ポリシーエージェント。

ユーザー。

Portal Server の設定。組織のユーザーに対して有効にする Portal Server の任意のサービス (デスクトップおよび NetMail)。

追加された各サービスにテンプレートを作成します。詳細については、110ページの「サービスのテンプレートを作成する」を参照してください。

組織内のユーザーにアクセス権限を付与する必要のあるポリシーを作成します。ポリシーの使用方法については、137ページの「Portal Server によるポリシー管理の使用法」を参照してください。

ユーザーを組織に追加します。詳細については、111ページの「新規ユーザーを追加する」を参照してください。

組織で必要な任意のロールを作成し、割り当てます。詳細については、113ページの「新規ロールを作成する」および114ページの「ロールをユーザーに割り当てる」を参照してください。

組織で有効なサービスを設定します。デスクトップの設定については、第 8 章「ポータルデスクトップサービスの管理」を参照してください。NetMail の設定については、第 11 章「NetMail サービスの管理」を参照してください。

新規の組織またはサブ組織を作成する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルには作成済みのすべての組織が表示されています。

サブ組織を作成する場合は、ナビゲーションパネルを使用して、サブ組織を作成する組織を選択します。

ナビゲーションパネルで「新規」をクリックします。

「新規組織」ページがデータパネルに表示されます。

「新規組織」ページで、組織またはサブ組織の名の値を入力します。

「アクティブ」または「非アクティブ」の状態を選択します。

デフォルトは「アクティブ」です。状態は、組織またはサブ組織が存在する間、プロパティー矢印を選択していつでも変更できます。「非アクティブ」を選択すると、組織またはサブ組織へのログインが無効になります。

「了解」をクリックします。

新規の組織またはサブ組織がナビゲーションパネルで表示されます。

「表示」メニューから「サービス」を選びます。

「新規」をクリックします。

新しい組織のデスクトップサービスを有効にします。

ロケーションパネルで「アイデンティティー管理」を選択します。

「表示」メニューから「組織」を選択します。

新規作成された組織を選択します。

「表示」メニューから「サービス」を選択します。

「ポータルデスクトップ」を選択します。

「デフォルトチャネル名」の値を「DummyChannel」から「JSPTabContainer」(または新しい組織で使用する最上位コンテナの名前) に変更します。

「ポータルデスクトップのタイプ」の値をデフォルトから「sampleportal」(または新しい組織で使用するデスクトップタイプ) に変更します。

サービスを追加する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

サービスを追加する組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

「表示」メニューから「サービス」を選びます。

「新規」をクリックします。

データパネルから追加する 1 つまたは複数のサービスを選択して、「了解」を選択します。

サービスのテンプレートを作成する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

追加したサービスがある組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

「表示」メニューから「サービス」を選びます。

追加したサービスの隣にあるプロパティー矢印をクリックします。

サービスのデフォルトの属性値を使用するか、変更し、「保存」をクリックします。

Access Manager 固有のサービス属性の設定については、『Access Manager 管理ガイド』を参照してください。Portal Server 固有のサービス属性の設定についての詳細は、このマニュアルの該当する付録を参照してください。

新規ユーザーを追加する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

ユーザーの作成先である組織またはサブ組織に移動します。

「表示」メニューから「ユーザー」を選択し、「新規」をクリックします。

「新規ユーザー」ページがデータパネルに表示されます。

ユーザーに割り当てるサービスを選択して、「次へ」をクリックします。

一般に、ほとんどのユーザーには少なくともポータルデスクトップ、認証設定、および登録の各サービスを追加します。

ユーザー情報を入力して、「終了」をクリックします。

新規ユーザーがナビゲーションパネルに表示されます。

ユーザーにサービスを追加する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

ユーザーの作成先である組織またはサブ組織に移動します。

「表示」メニューから「ユーザー」を選択します。

ナビゲーションパネルでユーザーを選択し、プロパティーの矢印をクリックします。

「表示」メニューから「サービス」を選択します。

「新規」をクリックして、ユーザーに割り当てるサービスを選択します。

サービスにチェックマークを付け、「了解」をクリックします。

一般に、ほとんどのユーザーには少なくともポータルデスクトップ、登録の各サービスを追加します。

新規ロールを作成する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

ロールの作成先である組織またはサブ組織に移動します。

「表示」メニューから「ロール」を選択し、「新規」をクリックします。

「新規ロール」ページがデータパネルに表示されます。

ロール情報 (名前、説明、ロールタイプ、アクセス権) を入力し、「終了」をクリックします。

新規ロールがナビゲーションパネルに表示されます。

ロールをユーザーに割り当てる

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

ロールの作成先である組織またはサブ組織に移動します。

「表示」メニューから「ユーザー」を選択します。

ロールの割り当て先であるユーザーの隣にあるプロパティーの矢印を選択します。

データパネルにユーザープロファイル情報が表示されます。

データパネルの「表示」メニューから「ロール」を選択します。

「ロールを追加」ページが表示されます。

割り当てるロールの隣にあるチェックボックスにチェックマークを付けて、「保存」をクリックします。

このユーザーのロールを表示するボックス内が、割り当てられたロールで更新されます。

「保存」をクリックし、変更内容を保存します。

既存のユーザーの Portal Server へのアクセスを有効化する

Access Manager の既存のインスタンスに Portal Server をインストールする場合、ユーザーは、Portal Server デスクトップを使用するように追加されていません。ユーザーがデスクトップにアクセスできるようにするには、ユーザーを有効にする必要があります。次の手順を使用して、デフォルトの組織または別の組織のユーザーを有効にします。

デフォルト組織のユーザーを有効化する

開始する前に、いくつかの設定情報を取得する必要があります。設定の詳細が一部不明な場合は、/var/sadm/pkg/SUNWps/pkginfo ファイルからスクリプトを使用して情報を取り出すことができます。

/var/sadm/pkg/SUNWps/pkginfo ファイルから、次の情報を確認または取り出します。

ディレクトリマネージャの識別名 (DS_DIRMGR_DN/ と指定)。デフォルト値は cn=Directory Manager です。

ディレクトリマネージャのパスワード (DS_DIRMGR_PASSWORD/ と指定)。

ディレクトリサーバーの完全修飾ドメイン名 (DS_HOST/ と指定)。

ディレクトリサーバーが実行するポート (DS_PORT/ と指定)。デフォルト値は 389 です。

ディレクトリツリーのルートサフィックス (DS_ROOT_SUFFIX/ と指定)。デフォルト値は dc=orgname,dc=com (dc=sun,dc=com など) です。

Portal Server インストールのデフォルトの組織 (DS_DEFAULT_ORG/ と指定)。デフォルト値は o=domain-name です。

Portal Server インストールのベースディレクトリ。デフォルト値は /opt です。

設定情報が不明な場合は、次のスクリプトを実行して出力を参照し、この手順を完了するのに必要な情報を取得してください。

ディレクトリを Access Manager ユーティリティーのディレクトリに変更します。たとえば、ベースディレクトリが /opt の場合は、次のように入力します。

cd /AccessManager-base/SUNWam/bin

ディレクトリサーバーとデフォルトの組織のルートサフィックスが同じでない場合は、次のコマンドを実行します。

./ldapsearch -h /DS_HOST/ -p /DS_PORT/ -D /DS_DIRMGR_DN/ -w /DS_DIRMGR_PASSWORD/ -b "ou=People,/DS_DEFAULT_ORG/,/DS_ROOT_SUFFIX/" "(uid=*)" dn | /usr/bin/sed 's/^version.*//�> /tmp/.tmp_ldif_file1

ディレクトリサーバーとデフォルトの組織のルートサフィックスが同じである場合は、次のコマンドを実行します。

./ldapsearch -h /DS_HOST/ -p /DS_PORT/ -D /DS_DIRMGR_DN/ -w /DS_DIRMGR_PASSWORD/ -b "ou=People,/DS_ROOT_SUFFIX/" "(uid=*)" dn | /usr/bin/sed 's/^version.*//' > /tmp/.tmp_ldif_file1

次のコマンドを実行します。

grep "^dn" /tmp/.tmp_ldif_file1 | awk '{
print $0
print "changetype: modify"
print "add: objectclass"
print "objectclass: sunPortalDesktopPerson"
print "objectclass: sunPortalNetmailPerson¥n" }' >
/tmp/.tmp_ldif_file2

次のコマンドを実行します。

./ldapmodify -c -h DS_HOST -p DS_PORT ¥ -D DS_DIRMGR_DN -w DS_DIRMGR_PASSWORD -f /tmp/.tmp_ldif_file2

すべての一時ファイルを削除します。

rm /tmp/.tmp_ldif_file1 /tmp/.tmp_ldif_file2

デフォルト以外の組織のユーザーを有効化する

/var/sadm/pkg/SUNWps/pkginfo ファイルから、次の情報を確認または取り出します。

ディレクトリマネージャの識別名 (DS_DIRMGR_DN/ と指定)。デフォルト値は cn=Directory Manager です。

ディレクトリマネージャのパスワード (DS_DIRMGR_PASSWORD/ と指定)

ディレクトリサーバーの完全修飾ドメイン名 (DS_HOST/ と指定)

ディレクトリサーバーが実行するポート (DS_PORT/ と指定)。デフォルト値は 389 です。

ディレクトリツリーのルートサフィックス (DS_ROOT_SUFFIX/ と指定)。デフォルト値は dc=orgname,dc=com (dc=sun,dc=com など) です。

ユーザーを更新する Portal Server インストールの組織 (DS_ORG_TO_UPDATE/ と指定)。デフォルト値は " です。

Portal Server インストールのベースディレクトリ。デフォルト値は /opt です。

有効にする既存のユーザーを含む組織またはサブ組織のサービスを追加します。手順の詳細については、110ページの「サービスを追加する」を参照してください。

追加するサービスごとにテンプレートを作成します。手順の詳細については、110ページの「サービスのテンプレートを作成する」を参照してください。

サービスごとにポリシーを作成して割り当てます。詳細については、138ページの「ピアまたはサブ組織のポリシーサービスを追加する」、139ページの「ピアまたはサブ組織の参照ポリシーを作成する」、および140ページの「ピアまたはサブ組織の標準のポリシーを作成する」を参照してください。

認証ユーザーの組織からの転送先に URL を設定します。169ページの「ログインユーザーをポータルデスクトップ URL に正しくリダイレクトする」を参照してください。

cd /AccessManager-base/SUNWam/bin

組織内のユーザーまたは組織を有効にするには、次のどちらかを実行します。

DS_ORG_TO_UPDATE/ として定義された特定の組織内のユーザーだけを有効にするには、次のコマンドを使用します (1 行として入力する)。

./ldapsearch -h /DS_HOST/ -p /DS_PORT/ -D /DS_DIRMGR_DN/ -w /DS_DIRMGR_PASSWORD/
-b "ou=People,/DS_ORG_TO_UPDATE/,/DS_ROOT_SUFFIX/" "(uid=*)" dn |
/usr/bin/sed 's/^version.*//' > /tmp/.tmp_ldif_file1

すべての組織のユーザーを有効にするには、次のコマンドを使用します (1 行として入力する)。

./ldapsearch -h /DS_HOST/ -p /DS_PORT/ -D /DS_DIRMGR_DN/ -w /DS_DIRMGR_PASSWORD/
-b "/DS_ROOT_SUFFIX/" "(uid=*)" dn | /usr/bin/sed 's/^version.*//' > /tmp/.tmp_ldif_file1

次のコマンドを実行します。

./ldapmodify -c -h DS_HOST -p DS_PORT ¥ -D "DS_DIRMGR_DN" -w DS_DIRMGR_PASSWORD -f /tmp/.tmp_ldif_file2

すべての一時ファイルを削除します。

rm /tmp/.tmp_ldif_file1 /tmp/.tmp_ldif_file2

ディレクトリを Portal Server のユーティリティーのディレクトリに変更します。

cd /AccessManager-base/SUNWps/bin

次のコマンドを実行して、デフォルト以外の組織のディスプレイプロファイルをロードします。

./dpadmin modify -u "uid=amadmin,ou=people,DS_DEFAULT_ORG,DS_ROOT_SUFFIX" -w DS_DIRMGR_PASSWORD -d "NON_DEFAULT_ORG,DS_DEFAULT_ORG,DS_ROOT_SUFFIX" AccessManager-base/SUNWps/samples/desktop/dp-org.xml

別の組織のユーザーを有効にするには、手順 7 から手順 13 までを繰り返します。

ポータル組織の迅速な新規作成

次のタスクでは、組織を新規作成し、ポータル用途用に有効にする手順を説明します。デフォルトでは、ログイン時にロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

新しい組織を作成します。

「表示」メニューから「組織」を選択します。

「新規」をクリックします。

組織の作成ページがデータパネルに表示されます。

新規組織名を入力します。「組織の状態」を「アクティブ」にする必要があります。「了解」をクリックします。

ナビゲーションページに、新規作成した組織が表示されます。

新しい組織のサービスを追加します。

ナビゲーションパネルの「表示」メニューから「組織」を選択し、「組織」リストから新たに作成した組織をクリックします。

「表示」メニューから「サービス」を選択します。

「新規」をクリックします。

「サービスを追加」ページがデータパネルに表示されます。組織用に登録するサービスを選択します。少なくとも次のサービスを追加する必要があります。

コア

LDAP またはこの組織に利用する認証サービス

メンバーシップ

ポータルデスクトップ

この手順の目的では、次も登録する必要があります。

ポリシー設定

登録

ユーザー管理

新規に追加されたサービスがナビゲーションパネルに表示されます。

プロパティーの矢印をクリックして各サービスを設定します。設定属性を変更するときは、「作成」をクリックします。Portal Server に固有の設定以外の属性については、『Sun Java System Access Manager 管理ガイド』を参照してください。

親組織から新しい組織へ、デスクトップ参照ポリシーを作成します。

参照は、ルール内のリソースとして親組織を定義する必要があり、参照内の値として SubOrgReferral にサブ組織が含まれている必要があります。

ロケーションパネルで「アイデンティティー管理」を選択します。

親組織を選択します。

「表示」メニューから「ポリシー」を選択します。

「新規」をクリックし、新しいポリシーを作成します。

ポリシーの作成ページがデータパネルに表示されます。

「ポリシータイプ」で「参照」を選択します。

「名前」には、SubOrgReferral_デスクトップを入力します。「了解」をクリックします。

ポリシーが作成され、「ポリシー」の下に表示されます。

「SunOrgReferral_Desktop」の隣にあるプロパティーの矢印をクリックします。

データパネルの「表示」メニューから「ルール」を選択し、「新規」をクリックします。「ポータルデスクトップ」が選択されていることを確認し、「次へ」をクリックします。

ポータルデスクトップのルールに対する名前を指定し、「終了」をクリックします。

データパネルの「表示」メニューから「参照」を選択し、「追加」をクリックします。データパネルで「値」にサブ組織の名前が選択されていることを確認し、「作成」をクリックしてポリシーの設定を完了します。

新しい組織の通常のポータルデスクトップポリシーを作成します。

サブ組織に移動します。

「表示」メニューから「ポリシー」を選択します。

その組織のポリシーが表示されます。

ナビゲーションパネルで「新規」を選択します。「新規ポリシー」ページがデータパネルに表示されます。

「ポリシータイプ」で「標準」が選択されていることを確認します。

ポリシー用の名前を入力します。

「了解」をクリックします。

データパネルの「表示」メニューから「ルール」を選択し、「新規」をクリックします。「新規ルール」ページがデータパネルに表示されます。

ルールタイプを選択し、「ルールアクション」の下にある処理を選択します。「終了」をクリックします。

データパネルの「表示」メニューから「サブジェクト」を選択し、「新規」をクリックします。「サブジェクトを追加」ページがデータパネルに表示されます。

ポータルデスクトップポリシーが適用されるサブジェクトを選択し、「次へ」をクリックしてサブジェクトの設定を完了します。

「終了」をクリックして、ポリシーの設定を完了します。

新しい組織の新規ユーザーを作成します。

ロケーションパネルで「アイデンティティー管理」を選択します。

「表示」メニューから「組織」を選択します。

新規作成された組織を選択します。

「表示」メニューから「ユーザー」を選択します。

「新規」をクリックします。

ユーザー用に登録するサービスを選択します。

「次へ」をクリックします。

テキストフィールドにユーザーの詳細を入力します。

「終了」をクリックします。

新しい組織のデスクトップサービスを有効にします。

ロケーションパネルで「アイデンティティー管理」を選択します。

「表示」メニューから「組織」を選択します。

新規作成された組織を選択します。

「表示」メニューから「サービス」を選択します。

「ポータルデスクトップ」を選択します。

「ポータルデスクトップのタイプ」の値をデフォルトから「sampleportal」(または新しい組織で使用するデスクトップタイプ) に変更します。

新しい組織のデスクトップにアクセスします。

管理コンソールからログアウトします。

ブラウザページを開き、次のように入力します。

http://server:port/amserver/UI/login?org=neworg

ユーザーのデスクトップが表示されます。

認証の設定

ここでは、Portal Server 認証の構成について説明します。Access Manager が、認証のフレームワークを提供します。認証は、ユーザーの ID を確認するプラグインモジュールを通じて実装されます。Access Manager には、コア認証モジュールをはじめ 7 つの異なる認証モジュールがあります。

Access Manager 管理コンソールを使用して、デフォルト値を設定し、認証サービスを追加し、組織の認証テンプレートを作成し、サービスを有効化します。コア認証モジュールは認証のための設定全般を実行するため、特定の認証モジュールを設定する前に、コア認証モジュールを追加し、コア認証モジュールのテンプレートを組織別に作成しておく必要があります。

インストール中に、コア認証が追加され、デフォルトの組織にテンプレートが作成されます。また、インストールにより、次の認証モジュールが追加され、テンプレートが作成されます。

LDAP: LDAP 認証により、ディレクトリツリーの検索ベース内にある有効なユーザーはすべて、Portal Server にログインできます。これにより自動的にユーザーが特定のロールに割り当てられます。

メンバーシップ: メンバーシップ認証により、ユーザーはアカウントを作成し、管理者の補助がなくてもそのアカウントをパーソナライズできます。ユーザーはこの新しいアカウントを使用して、追加ユーザーとしてアクセスできます。

それぞれの新しい組織にコア認証サービスを追加します。サービスを追加する手順については、110ページの「サービスを追加する」を参照してください。

コア認証サービスにテンプレートを作成します。サービスにテンプレートを作成する手順については、110ページの「サービスのテンプレートを作成する」を参照してください。

各組織にサポートする認証サービスを追加します。サービスを追加する手順については、110ページの「サービスを追加する」を参照してください。

認証サービスに組織でサポートするサービステンプレートを作成します。認証サービスにテンプレートを作成する手順については、110ページの「サービスのテンプレートを作成する」を参照してください。サービスの属性の設定については、『Access Manager 管理ガイド』の第 5 章「認証オプション」を参照してください。

認証メニューを設定します。認証順序を設定する手順については、126ページの「認証メニューを設定する」を参照してください。

認証サービスの使用順序を設定します。認証順序を設定する手順については、127ページの「認証順序を設定する」を参照してください。

認証レベルによる認証

各認証モジュールには、認証レベルを表す整数値を関連付けることができます。認証レベルを割り当てるには、「サービス設定」で認証モジュールのプロパティーの矢印をクリックし、認証レベル属性の値を変更します。認証レベルが高いほど、1 つまたは複数の認証モジュールで認証されたユーザーの信頼度は高く定義されます。

認証メニューを設定する

ユーザーは、特定の認証レベルの認証モジュールにアクセスできます。たとえば、次の構文を使用して、一ユーザーとしてログインできます。

ユーザーが選択できる認証のメニューには、auth_level_value 以上の認証レベルが設定されたすべてのモジュールが表示されます。一致するモジュールが 1 つだけ見つかった場合は、その認証モジュールのログインページが表示されます。

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ログイン時にロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

認証を設定する組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

「表示」メニューから「サービス」を選択します。

コアの隣にあるプロパティー矢印をクリックします。

「組織」セクションの「組織認証モジュール」フィールドで適切な認証モジュールを選択して有効にします。

デフォルトでは、Portal Server のインストールにより、LDAP およびメンバーシップが有効になります。

各認証モジュールの「デフォルトの認証レベル」に値を入力します (デフォルト値は 0)。

認証メニューに表示するには、各認証モジュールの値が同じである必要があります。

「保存」をクリックします。

認証順序を設定する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

認証を設定する組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

「表示」メニューから「サービス」を選択します。

コアの隣にあるプロパティー矢印をクリックします。

「組織」セクションの「組織認証モジュール」フィールドで適切な認証モジュールを選択して有効にします。

デフォルトでは、Portal Server のインストールにより、LDAP およびメンバーシップが有効になります。

各認証モジュールの「デフォルトの認証レベル」に値を入力します (デフォルト値は 0)。

認証メニューに表示するには、各認証モジュールの値が同じである必要があります。

各認証モジュールの属性情報を指定するには、「組織認証設定」で「編集」を選択します。

「追加」をクリックして、認証モジュールをメニューに追加します。

認証メニューに表示される認証モジュールの順序を変更するときは、「並べ替え」をクリックします。

「保存」をクリックし、属性情報を保存します。

「保存」をクリックします。

次の URL を使用して、管理サーバーにログインし、認証メニューが適切な選択肢と一緒に表示されることを確認します。

http://host:port/amserver/UI/login

これがデフォルトの組織認証ではない場合には、次の URL を使用して組織の認証メニューを確認します。

http://host:port/amserver/UI/login?org=org_name

外部ディレクトリに LDAP 認証を設定する

Portal Server をインストールすると、インストールプログラムによりディレクトリインスタンスへの LDAP 認証が自動的に設定されます。インストールプログラムにより、ローカルサーバーにディレクトリの内部インスタンスをインストールし、その内部ディレクトリに対する LDAP 認証を設定、またはディレクトリの既存の外部インスタンスへの LDAP 認証を設定できます。

初期設定を行ったら、外部 LDAP ディレクトリへの認証を設定できます。たとえば、パフォーマンスまたはセキュリティー上の理由から、特定の組織の認証情報を専用の LDAP サーバーに分離することができます。

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

認証を設定する組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

「表示」メニューから「サービス」を選びます。

「Access Manager 設定」の「コア」の隣にあるプロパティーの矢印をクリックします。

「ダイナミックユーザープロファイル」メニューの「ダイナミック」を選択します。

「Access Manager 設定」メニューで「LDAP」の隣にあるプロパティーの矢印をクリックします。

サーバーに適切な LDAP 属性を設定します。次の例は、ポート 389 の LDAP サーバー ds-sesta1.sesta.com へのアクセスに検索開始位置 ou=people,dc=sesta,dc=com を設定し、root ユーザーによる cn=root,ou=people,dc=sesta,dc=com へのバインドを設定します。

プライマリ LDAP サーバーとポート: ds-sesta1.sesta.com:389
セカンダリ LDAP サーバーとポート: ds-sesta1.sesta.com:389
ユーザー検索の開始 DN: ou=people,dc=sesta,dc=com
root ユーザーバインド DN: cn=root,ou=people,dc=sesta,dc=com
root ユーザーバインドパスワード: root password
ユーザーネーミング属性: uid
ユーザーエントリ検索属性: employeenumber
ユーザー検索フィルタ: 空白
検索範囲: サブツリー
LDAP サーバーに対する SSL を有効: オフ
認証するユーザー DN を返す: オフ
認証レベル: 0

「保存」をクリックします。

匿名認証の設定

Portal Server は、匿名認証の実装について次の 2 つの方法をサポートしています。

認証なしのユーザー ID の属性を使用する。デスクトップ URL にアクセスしているユーザーは、自動的に認証され、デスクトップへのアクセス権を与えられます。

匿名ユーザーセッションを使用する。ユーザーは、認証メニューから「匿名」を選択して anonymous としてログインし、デスクトップへのアクセス権を与えられます。

匿名認証をサポートするため、Portal Server インストールプログラムは、ユーザーアカウント authlessanonymous を作成して、次の 2 つのポータルデスクトップサービスのグローバル属性で、このユーザーについてのアクセスを設定します。

許可されている認証なしユーザー ID

デフォルトの認証なしユーザー ID

Portal Server は、次の操作を実行できるという点において、認証なしと匿名認証の同時設定をサポートします。

認証なしモードでも機能するようにデスクトップを設定します。

選択肢の 1 つとして「匿名」が表示されるように、認証メニューを設定します。

ブラウザ A でデスクトップにアクセスします。この場合認証なしモードでのアクセスになります。

ブラウザ B で http:/server/amserver/UI/login にアクセスして「匿名」を選択し、デスクトップを表示します。

この時点では、ブラウザ A では認証なしモードを使用し、ブラウザ B では匿名モードを使用しています。

デスクトップへのアクセスは、次の 2 つの方法で行われます。一方の認証なしのアクセスは /portal/dt を直接参照する方法を用いますが、もう一方 (匿名) では間接的に /amserver/login を使用します。

Access Manager のメニューに匿名ログインのみを設定すると、Access Manager の「ログイン」メニューを省略することができます。

認証なしと匿名の両方の認証方式が同時にサポートされることはありません。このため、Access Manager セッションを開始せずに /portal/dt にアクセスする場合、次のどちらかだけが実行されます。

デスクトップは /amserver/UI/login にリダイレクトし、これによって自動的に匿名ログインが行われ、ユーザーが /portal/dt にリダイレクトされます。

デスクトップが認証なしモードで実行されます。

認証なしアクセスを使用する場合、匿名認証を無効にする必要はありません。ただし、上記の項目 a を実行する場合は、認証なしアクセスモードを無効にする必要があります。

匿名認証を設定する (匿名ユーザーセッション方式)

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

認証を設定する組織またはサブ組織に移動します。

作成したすべての組織がナビゲーションパネルに表示されます。

ロケーションパネルで「サービス設定」を選択します。

ポータルデスクトップサービスの隣にあるプロパティーの矢印をクリックします。

データパネルにポータルデスクトップの属性が表示されます。

「許可されている認証なしユーザー ID」属性でリストに表示された値を選択し、「削除」を選択します。

「デフォルトの認証なしユーザー ID」属性でリストに表示された値を選択し、「削除」を選択します。

「保存」をクリックします。

ロケーションパネルで「アイデンティティー管理」を選択します。

「表示」メニューから「組織」を選択します。

作成したすべての組織がナビゲーションパネルに表示されます。

認証を設定する組織またはサブ組織に移動します。

ロケーションパネルの「表示」メニューを使用します。

「表示」メニューから「サービス」を選択します。

匿名サービスを追加して、設定します。

詳細については、110ページの「サービスを追加する」および110ページの「サービスのテンプレートを作成する」を参照してください。

認証メニューに「匿名」を追加します。

詳細については、127ページの「認証順序を設定する」を参照してください。

anonymous ユーザーアカウントを作成します。

詳細については、111ページの「新規ユーザーを追加する」を参照してください。

匿名認証を設定する (認証なしアクセス)

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

作成したすべての組織がナビゲーションパネルに表示されます。

認証を設定する組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

パスワード authlessanonymous で authlessanonymous ユーザーアカウントを作成します。

詳細については、111ページの「新規ユーザーを追加する」を参照してください。

ロケーションパネルで「サービス設定」を選択します。

ナビゲーションパネルで「ポータルデスクトップ」を選択します。

「許可されている認証なしユーザー ID」属性に authlessanonymous ユーザーの完全識別名を追加します。たとえば、次のようになります。

uid=authlessanonymous, ou=People, dc=sesta, dc=com

「デフォルトの認証なしユーザー ID」属性で authlessanonymous ユーザーの完全識別名を指定します。

「保存」をクリックします。

ブラウザを閉じて再起動し、新しく設定した認証なしのユーザー ID 方式を使用してデスクトップにアクセスする必要があります。認証なしのユーザー ID 方式により、クエリー文字列でユーザーアカウントの UID を指定できます。デフォルトでは、認証なしの UID は desktop.suid です。プレフィックス desktop は、desktopconfig.properties ファイルの設定パラメータ cookiePrefix によって制御されます。たとえば、デフォルト組織 sestat.com からデスクトップにアクセスする場合は次の URL を使用します。

http://server:port/portal/dt?desktop.suid=uid=authlessanonymous, ou=People,dc=sesta,dc=com

連携ユーザー用の Portal Server の設定

Sun Java System Portal Server ソフトウェアは、Liberty Alliance 仕様に準拠した連携 ID を持つユーザーをサポートしています。Liberty シングルサインオンの連携ユーザーは、Portal Serverでパーソナライズされたデスクトップに 2 回目以降は認証なしでアクセスできます。

Liberty が有効な認証サービスについては、『Sun Java System Access Manager 管理ガイド』を参照してください。サービスプロバイダとして機能する Portal Server の設定例は、次の場所に用意されています。

連携ユーザーを設定する

デフォルトでは、連携ユーザーはサービスプロバイダとして機能する Sun Java System Portal Server にアクセスする権限を持ちません。Portal Server は、連携ユーザーを次のように扱えます。

Liberty シングルサインオンの連携ユーザーは、パーソナライズされたデスクトップにアクセスできます。

Liberty シングルサインオンではない連携ユーザーは、ID プロバイダの認証ページにリダイレクトされます。

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

ロケーションパネルで「サービス設定」を選択します。

ナビゲーションパネルで「ポータルデスクトップ」を選択します。

「連携を有効」をクリックします。

ホストプロバイダの ID を指定します。

「保存」をクリックします。

連携ユーザーの認証なしアクセスを設定する

デフォルトでは、連携ユーザーは認証なしポータルデスクトップにアクセスする権限を持ちません。

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

認証を設定する組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

ロケーションパネルで「サービス設定」を選択します。

ナビゲーションパネルで「ポータルデスクトップ」を選択します。

「連携ユーザーの認証なしアクセスを無効」のチェックマークを外します。

「保存」をクリックします。

UNIX 認証を設定する

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

「アイデンティティー管理」の「表示」メニューで、「組織」を選択します。

作成したすべての組織がナビゲーションパネルに表示されます。

ロケーションパネルで「サービス設定」を選択します。

ナビゲーションパネルの「UNIX」の隣にあるプロパティー矢印をクリックします (「Access Manager 設定」の下)。

サーバーに適切な UNIX 属性を設定します。

「保存」をクリックします。

認証を設定する組織またはサブ組織に移動します。

ナビゲーションパネルの「表示」メニューを使用します。

「表示」メニューから「サービス」を選びます。

ナビゲーションパネルで「新規」をクリックします。

データパネルの「認証」の下の「コア」をクリックします。

データパネルの「組織認証モジュール」メニューから「UNIX」を選択します。

「保存」をクリックします。

組織レベルの UNIX 認証を設定する

ブラウザの Web アドレスフィールドに http://fullservername:port/amconsole と入力し、管理者 (amadmin) として Sun Java System Access Manager 管理コンソールにログインします。

ログイン画面では、ユーザー ID として amadmin を入力し、インストール時に指定したパスワードを入力します。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

「アイデンティティー管理」の「表示」メニューで、「組織」を選択します。

作成したすべての組織がナビゲーションパネルに表示されます。

「表示」メニューから「サービス」を選びます。

「追加」を選択します。

右のパネルで「UNIX」にチェックマークを付けて、「了解」をクリックします。

「UNIX」の隣にあるプロパティーの矢印をクリックします。

「サービステンプレートの作成 (UNIX)」パネルで「はい」を選択します。

サーバーに適切な UNIX 属性を設定します。

「保存」をクリックします。

「コア」の隣にあるプロパティーの矢印をクリックします。

認証メニューで「UNIX」を強調表示し、「保存」を選択します。

Portal Server によるポリシー管理の使用法

ここでは、Access Manager のポリシー管理機能の使用法について説明します。ポリシーを作成、変更、および削除する手順については、Access Manager のマニュアルを参照してください。

Access Manager のポリシーサービスにより、ルールを定義したり、リソースにアクセスしたりすることができます。ポリシーは、ロールまたは組織に基づき、権限の提供、あるいは制約の定義を可能にします。Portal Server には、次の 3 つのポリシーが内蔵されています。

Portal Server ポータルデスクトップ実行機能: ユーザーがデスクトップを表示できるようにします。

Portal Server NetMail 実行機能: ユーザーが NetMail を実行できるようにします。

デフォルトでは、ポリシー設定サービスは自動的に最上位の組織に追加されます。サブ組織は、親組織とは別にポリシーサービスを追加する必要があります。作成したポリシーサービスは、すべての組織に追加する必要があります。ポリシーを使用するための手順の概要は、次のとおりです。

組織のポリシーサービスを追加します。(インストールで指定した組織に自動的に追加)。サブ組織は、親サービスを継承しないため、サブ組織のポリシーサービスを追加する必要があります。詳細については、110ページの「サービスを追加する」を参照してください。

ピアまたはサブ組織の参照ポリシーを作成します。組織のポリシーに関する定義と決定を別の組織に委託することができます。または、リソースのポリシー定義を別のポリシー製品に委託することもできます。この、ポリシーの作成と評価に関するポリシー委任は、参照ポリシーによって制御されます。これは、ルールと参照自体から構成されます。リソースを必要としないアクションがポリシーサービスに含まれる場合、サブ組織の参照ポリシーを作成することはできません。詳細については、139ページの「ピアまたはサブ組織の参照ポリシーを作成する」を参照してください。

ピアまたはサブ組織の標準のポリシーを作成します。アクセス権の定義には標準のポリシーを使用します。標準のポリシーは、複数のルール、サブジェクト、および条件から構成されます。詳細については、140ページの「ピアまたはサブ組織の標準のポリシーを作成する」を参照してください。

ピアまたはサブ組織のポリシーサービスを追加する

ピアまたはサブ組織は、親サービスを継承しないため、ピアまたはサブ組織のポリシーサービスを追加する必要があります。

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

参照ポリシーを作成する組織またはサブ組織に移動します。

作成したすべての組織がナビゲーションパネルに表示されます。

ナビゲーションパネルの「表示」メニューから「組織」を選択し、「名前」メニューから適切な組織を選択します。

「表示」メニューから「サービス」を選択します。

「新規」をクリックします。

「サービスを追加」ページがデータパネルに表示されます。少なくとも以下のサービスのチェックボックスを選択し、「了解」をクリックします。

LDAP

メンバーシップ

ポリシー設定

ポータルデスクトップ

NetMail

新規に追加されたサービスがナビゲーションパネルに表示されます。

ピアまたはサブ組織の参照ポリシーを作成する

組織のポリシーに関する定義と決定を別の組織に委託することができます。この、ポリシーの作成と評価に関するポリシー委任は、参照ポリシーによって制御されます。これは、ルールと参照自体から構成されます。参照は、ルール内のリソースとして親組織を定義する必要があり、参照内の値として SubOrgReferral または PeerOrgReferral に組織名が含まれている必要があります。

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

参照ポリシーを作成するのに使用する組織またはサブ組織に移動します。

作成したすべての組織がナビゲーションパネルに表示されます。

「表示」メニューから「ポリシー」を選択します。

「新規」をクリックし、新しいポリシーを作成します。

ポリシーの作成ページがデータパネルに表示されます。

「名前」には、SubOrgReferral_organization または PeerOrgReferral_organization を入力します。「ポリシータイプ」で「参照」が選択されていることを確認します。「了解」をクリックします。

「サービス」からサービスのタイプを選択し、「次へ」をクリックします。

データパネルの「表示」メニューから「ルール」を選択し、「追加」をクリックします。「次へ」をクリックします。

「ルールを追加」テンプレートがデータパネルに表示されます。

「ルール名」にルールの名前を入力し、「終了」をクリックします。

データパネルの「表示」メニューから「参照」を選択し、「追加」をクリックします。

「参照を追加」テンプレートがデータパネルに表示されます。

「名前」に SubOrgReferralName と入力します。

データパネルで「値」にサブ組織の名前が選択されていることを確認し、「作成」をクリックしてポリシーの設定を完了します。

データパネルで「保存」をクリックします。

データが保存されると、「ポリシープロパティーが保存されました。」というメッセージが表示されます。

ピアまたはサブ組織の標準のポリシーを作成する

アクセス権の定義には標準のポリシーを使用します。標準のポリシーは、複数のルール、サブジェクト、および条件から構成されます。

Sun Java System Access Management Server 管理コンソールに、管理者としてログインします。

デフォルトでは、ロケーションパネルでは「アイデンティティー管理」が選択され、ナビゲーションパネルでは「組織」が選択されています。

ポリシーを作成する組織またはサブ組織に移動します。

作成したすべての組織がナビゲーションパネルに表示されます。

「表示」メニューから「ポリシー」を選択します。

その組織のポリシーが表示されます。

ナビゲーションパネルで「新規」を選択します。「新規ポリシー」ページがデータパネルに表示されます。

「名前」には、SubOrgNormal_organization または PeerOrgNormal_organization を入力します。「ポリシータイプ」で「標準」が選択されていることを確認します。「了解」をクリックします。

「サービス」メニューからサービスを選択し、「次へ」をクリックします。「ルール名」にルールの名前を入力します。適切なサービスの実行権限が与えられるように、適切なチェックボックスにチェックマークが付いていることを確認します。

データパネルの「表示」メニューから「ルール」を選択し、「追加」をクリックします。「ルールを追加」テンプレートがデータパネルに表示されます。

データパネルの「表示」メニューから「サブジェクト」を選択し、「追加」をクリックします。「サブジェクトを追加」ページがデータパネルに表示されます。

「終了」をクリックして、ポリシーの設定を完了します。

データが保存されると、「ポリシープロパティーが保存されました」というメッセージが表示されます。

Portal Server デスクトップへのログイン

サンプルポータルをインストールしている場合は、ユーザーはサンプルデスクトップにログインできます。また、Portal Server は、その他のユーザーにさまざまなログインをサポートしています。ここでは、Portal Server にログインできる、その他のいくつかの方法について説明します。

サンプルのポータルデスクトップにログインする

サンプルデスクトップにアクセスするには、次の URL を入力します。

サブ組織にログインする

ユーザーに組織へのアクセス権がある場合、組織内のサブ組織にログインすることもできます。たとえば、ユーザーがサブ組織 B を持つ組織 A にアクセスできる場合、次の URL を入力してサブ組織 B にログインします。

匿名認証を使用してログインする

次の URL を使用してログインします。

http://server:port/portal/dt

Access Manager 認証ページで、「匿名」をクリックします。

サンプルデスクトップが表示されます。

必要に応じて、またメンバーシップ認証モジュールが追加されている場合、ログイン画面でユーザー ID を作成し、追加します。

ロギングの管理

Portal Server は、Access Manager ロギングおよびデバッグ API を使用します。

デフォルトでは、Portal Server のログファイルおよびデバッグファイルは、次のディレクトリに格納されています。

/var/opt/SUNWam/logs

/var/opt/SUNWam/debug

Access Manager 管理コンソールにより、次のロギングの属性を定義できます。

ログの最大サイズ

履歴ファイルの数

ログの場所

ロギングタイプ

データベースユーザー名

データベースユーザーパスワード

データベースドライバ名

詳細については『Sun Java System Access Manager 2005Q4 管理ガイド』を参照してください。

前へ目次索引次へ
Sun Java System Portal Server 6 2005Q4 管理ガイド