|
|
このガイドでは、ポータル アプリケーションを保護する方法について説明します。このガイドで説明されているセキュリティ技術を使用して、ポータル アプリケーションとアプリケーション リソースの機密性、整合性、および可用性を確保してください。
BEA WebLogic Portal® のセキュリティでは、BEA WebLogic Server のセキュリティ機能が利用されます。一方、WebLogic Server は J2EE セキュリティ サービスをサポートおよび拡張しています。このセキュリティ サービスは、その他の J2EE コンポーネントと同じく、標準化されたモジュラ コンポーネントに基づいています。WebLogic Server は、これらの Java セキュリティ サービス メソッドを標準に基づいて実装しています。また、追加のプログラミングをすることなく、アプリケーションの数多くの細かい動作を自動的に処理する拡張機能を追加しています。WebLogic Server のセキュリティの詳細については、『BEA WebLogic Server® 10.0 セキュリティ』を参照してください。
WebLogic Portal は、統合 WebLogic セキュリティ アーキテクチャの一部です。訪問者資格と委託管理を含む、WebLogic Portal 固有のセキュリティ拡張機能では、WebLogic セキュリティ サービス プロバイダ インタフェース (SSPI) が使用されます。すべての認可チェックは、共有アーキテクチャの一部である isAccesssAllowed メソッドを使用して実行されます。
図 1-1 に、統合 WebLogic セキュリティ アーキテクチャ内の WebLogic Portal を示します。
この節では、WebLogic Portal セキュリティ アーキテクチャのコンポーネントについて説明します。
WebLogic Server は J2EE のセキュリティ サービスを利用します。このセキュリティ サービスは、その他の J2EE コンポーネントと同じく、標準化されたモジュラ コンポーネントに基づきます。WebLogic Server は、これらの Java セキュリティ サービス メソッドを標準に基づいて実装しています。また、追加のプログラミングをすることなく、アプリケーションの数多くの細かい動作を自動的に処理する拡張機能を追加しています。WebLogic Server がデフォルトとして提供しているセキュリティ プロバイダを使用することもできますし、カスタム プロバイダを統合することもできます。
WebLogic Portal は、セキュリティの実施を統合し、セキュリティをサービスとして他の WebLogic Server コンポーネントに提供する WebLogic Security Framework を使用します。WebLogic Security Framework は、WebLogic セキュリティ サービス プロバイダ インタフェース (SSPI) のメソッドを呼び出して、セキュリティ操作を実行します。WebLogic SSPI は WebLogic パッケージのセットで、これを使用すると、セキュリティ プロバイダを開発したり、セキュリティ プロバイダを WebLogic サーバ セキュリティ サービスに統合したりできます。
これらのインタフェースは、WebLogic セキュリティ プロバイダおよびカスタム セキュリティ プロバイダが実装します。セキュリティ プロバイダはソフトウェア モジュールで、認証、認可、監査などのセキュリティ サービスをアプリケーションに提供する WebLogic Server セキュリティ レルムにプラグインすることができます。(サードパーティのセキュリティ ベンダまたはセキュリティ開発者が記述する) カスタム セキュリティ プロバイダは SSPI の実装であり、WebLogic Server には付属していません。
WebLogic Server は、JAAS (Java Authentication and Authorization Service) クラスを使用して安全確実にクライアントを認証します。JAAS は、Java Software Development Kit バージョン 1.4.1 のセキュリティに対する標準拡張機能です。WebLogic Portal などの WebLogic Server クライアントは、JAAS の認証部分のみを使用します。
JAAS は、アプリケーションを基礎となる認証技術から独立させた状態にできる、Pluggable Authentication Module (PAM) フレームワークの Java バージョンを実装しています。これにより、アプリケーションに変更を加えることなく、新しいまたは更新済みの認証技術を使用できます。
JAAS LoginContext は、すべてのコンフィグレーション済み認証プロバイダの順次実行をサポートしており、各コンフィグレーション済みプロバイダの管理を担当します。詳細については、「JAAS と WebLogic Server」を参照してください。
認証とは、身元の確認であり、「ユーザが、名乗っている本人かどうか」という質問に答えることです。
認証は通常、ログイン プロセスを使用して実行されます。ログイン プロセス中、ユーザはユーザ名とパスワードの組み合わせなど資格情報を提示します。ユーザが認証されると、一連の ID (ユーザ名、ユーザのグループ メンバシップなど) がそのユーザに関連付けられます。これらの ID は、プリンシパルとも呼ばれます。
認証プロバイダは、ユーザの身元を確認します。また認証プロバイダは、必要に応じて、その身元情報を記憶し、サブジェクト (認証情報のコンテナ) を介してシステムの各種コンポーネントに転送して使用できるようにします。認証プロセスでは、プリンシパル検証プロバイダが、サブジェクトに格納されたプリンシパルに署名し、その信頼性を検証することで、追加のセキュリティ保護を提供します。
WebLogic Server には、組み込み LDAP サーバ、外部 LDAP ストア、および外部リレーショナル データベース管理システム (RDBMS) 内のユーザ データおよびグループ データにアクセスできる、独自の認証プロバイダが用意されています。WebLogic Server は、デフォルトでは組み込みの LDAP サーバを認証プロバイダとして使用します。一方、WebLogic Portal は、デフォルトでは SQL 認証プロバイダを使用します。
| ヒント : | WebLogic Portal の以前のリリースには、WebLogic Portal 固有の RDBMS 認証プロバイダがありました。これは非推奨になりました。以前のリリースからアップグレードする場合、デフォルト認証プロバイダとして WebLogic SQL 認証プロバイダにアップグレードするか、既存のユーザ ストアを引き続き使用するか選択できます。ユーザ ストアのアップグレードについては、『WebLogic Portal 10.0 へのアップグレード』を参照してください。 |
WebLogic Portal は、認証に WebLogic Server を使用します。これは、1 つ以上の WebLogic 認証プロバイダを使用している場合も、WebLogic Server で使用するようにコンフィグレーションされた 1 つ以上のカスタム認証プロバイダを使用している場合も、WebLogic とカスタム プロバイダを組み合わせて使用している場合も同じです。
| ヒント : | WebLogic Server は、SQL 認証プロバイダ、読み込み専用の SQL 認証プロバイダ、カスタム RDBMS 認証プロバイダなどの RDBMS 認証プロバイダを提供しています。また WebLogic Server は、組み込みの LDAP サーバ用の認証プロバイダの他に、Open LDAP、Sun iPlanet、Microsoft Active Directory、Novell NDS LDAP サーバなどの外部 LDAP サーバ用の認証プロバイダも提供しています。 |
各認証プロバイダには JAAS LoginModule が必要です。LoginModules は、ポリシー ドメイン内のユーザの認証、およびサブジェクトと必要なプリンシパル (ユーザおよびグループ) の関連付けを担当します。また境界認証に使用されない LoginModules は、発行済みの証明マテリアル (たとえば、パスワード) も検証します。カスタム認証プロバイダ用の LoginModules の作成については、「LoginModule」を参照してください。
ID アサーション プロバイダは、認証プロバイダの特定のタイプで、ユーザまたはシステム プロセスがトークン (セキュリティ関連情報の表現) を使用して自身の身元を明示できるようにします。ID アサーション プロバイダは、境界認証を使用可能にし、シングル サインオン (SSO) をサポートします。たとえば、ID アサーション プロバイダは、デジタル証明書からトークンを生成できます。そのトークンはシステム内で順に回すことができ、ユーザが何度もサインオンを求められないようにすることができます。
| 注意 : | ID アサーション プロバイダの LoginModule を作成すると、認証プロバイダの代わりに ID アサーション プロバイダを使用できます。また、認証プロバイダの LoginModule を使用する場合、認証プロバイダに加えて ID アサーション プロバイダを使用できます。 |
Web アプリケーションは、通常、多数の異なるコンポーネントで構成されます。これらのコンポーネントはそれぞれ独自の認証スキーマまたはユーザ レジストリを持っている場合があります。SSO では、これらのアプリケーションのユーザが 1 回認証されれば、アプリケーションのすべてのコンポーネントにアクセスできるようになります。SSO コンフィグレーションに組み込まれている 1 つのサイトでユーザが認証されると、それらのユーザは SSO コンフィグレーションのその他のサイトに自動的にログインしたことになります。
WebLogic Server SAML ID アサータは、連合ポータル アーキテクチャのリモート ポートレットにアクセスできるようにする、Security Assertion Markup Language (SAML) アサーションを作成できます。詳細については、『連合ポータル ガイド』を参照してください。
| ヒント : | 以前のリリースでこの機能を提供していた WSRP ID アサータは、下位互換性のために現在でも利用できます。 |
JSP タグ <auth:login> および <auth:logout> を使用し、プログラムによって認証を実装できます。
| 注意 : | <ugm:login> および <ugm:logout> の 2 つの JSP タグは非推奨です。代わりに、<auth:login> および <auth:logout> の JSP タグを使用してください。属性とパラメータは同じです。 |
<auth:login> タグは、現在のセキュリティ レルムに対して (ユーザ名とパスワードの組み合わせの) 弱い認証を行い、認証されたユーザを現在の WebLogic ユーザとして設定します。<auth:logout> タグは現在のユーザの WebLogic Server セッションを終了します。これにより、ユーザは (すべてのシングル サインオン Web アプリケーション上にある) サーブレット セッションと、スレッドから削除されます。キャッシュされたユーザ プロファイルも削除されます。このタグは <auth:login> タグと組み合わせて使用してください。
これらのタグとその他の認可タグの詳細については、「JSP Tag Javadoc」を参照してください。
認可とは、リソースへのアクセスの制御であり、「ユーザはこの保護されたリソースへのアクセス権を持っているか」という質問に答えることです。ユーザとリソースとの対話は、ユーザ ID、またはその他の情報に基づいて制御されています。
WebLogic Portal では (WebLogic Server と同様に)、ポータル リソース、J2EE リソース、および管理ツールへのアクセスをロールで制御します。そのため、ユーザは、割り当てられたロールで許可されているリソースやツールにのみアクセスできます。WebLogic Portal では WebLogic Server のロールを使用し、ログイン時にユーザをロールに動的に結び付けることができます。
認可プロバイダは、ユーザとリソース間の対話を制御して機密性を確保します。アクセス決定は、認証プロバイダの LoginModule と同様に、認可プロバイダのコンポーネントであり、リソースへのアクセスが許可されるかどうかを判定します。具体的には、サブジェクトが指定のアクションを WebLogic リソースに対して実行するパーミッションを持っているかどうかを判断します。isAccessAllowed メソッドの実行時呼び出しによって、サブジェクトのセキュリティ ロールに基づいてこの判定が行われます。
ロール マッピングは、実行時にプリンシパル (ユーザまたはグループ) がセキュリティ ロールに動的にマッピングされるプロセスです。ロール マッピング プロバイダは、サブジェクトがリソースに対して操作を実行しようとしたときに、サブジェクトに適用されるセキュリティ ロールを決定します。この操作には、通常、リソースへのアクセス権の取得が伴うため、ロール マッピング プロバイダは一般に認可プロバイダと共に使用されます。
デフォルトのロール マッピング プロバイダは、WebLogic XACML ロール マッピング プロバイダで、組み込み LDAP サーバにロール ポリシーを個別に格納します。WebLogic XACML ロール マッピング プロバイダは WebLogic Portal に必須のロール マッピング プロバイダであり、大部分のニーズに対応できます。カスタム ロール マッピング プロバイダをコンフィグレーションする必要はまずありません。
セキュリティ ロールは、特定の条件に基づいてユーザまたはグループに付与される権限です。ロールを使用すると、リソースへのアクセスを付与するか拒否するかを決定したり、そのリソースの機能のうち、どれをユーザが使用できるようにするかを決定できます。ロールをユーザまたはグループに付与すると、ロールが付与されている限り、定義されたアクセス権限がそのユーザまたはグループに与えられます。1 つのロールを付与できるユーザまたはグループの数に制限はありません。
ロールの計算とユーザまたはグループへの付与は、ロール名とロール定義で構成されるロール ポリシーに基づいて動的に行われます。ロール ポリシーは動的なものであり、ユーザ名、グループ メンバシップ、ユーザ プロファイル プロパティ値、セッション属性とリクエスト属性、および日付と時刻の機能に基づくことが可能です。
常に WebLogic Server ドメイン全体にスコープ指定されるグループとは異なり、ロールは WebLogic Server ドメインの 1 つのアプリケーション内の特定の WebLogic リソースにスコープ指定できます。ロールのスコープ指定については、「グローバル ロールとスコープ ロールについて」を参照してください。
セキュリティ ポリシーとは、「ある WebLogic リソースにアクセスできるのは誰か」という質問に対する答えです。WebLogic リソースと 1 つまたは複数のユーザ、グループ、またはロールとの間に関連付けを定義すると、セキュリティ ポリシーが作成されます。したがって、ロール ポリシーがロールを定義し、そのロールに関連付けられる認可制約をセキュリティ ポリシーが定義します。
BEA では、ユーザやグループではなくロールに基づいてセキュリティ ポリシーを作成することをお勧めします。ロールに基づいてセキュリティ ポリシーを作成すると、ユーザまたはグループに与えられたロールに基づいてアクセスを管理できます。これにより、管理方法の柔軟性が向上します。
セキュリティ ポリシーは、認可プロバイダのストア (デフォルトでは組み込み LDAP サーバ) に保持されます。WebLogic リソースに対するデフォルトのセキュリティ ポリシーのリストについては、「デフォルトのルート レベルのセキュリティ ポリシー」を参照してください。
セキュリティ ポリシーをユーザまたはグループ ベースにする場合、そのユーザまたはグループが、デフォルトのセキュリティ レルムにコンフィグレーションされた認証プロバイダのユーザ ストア内に定義されている必要があります。セキュリティ ポリシーをロール ベースにする場合、そのロールが、デフォルトのセキュリティ レルムにコンフィグレーションされたロール マッピング プロバイダのストア内に定義されている必要があります。
J2EE プラットフォームでは、セキュリティ コントラクトの確立方法をデプロイメント記述子というドキュメントに定義します。デプロイメント記述子により、URL を使用して直接アクセスできるリソースへのアクセスを制限します。デプロイメント記述子を使用して、JSP やページ フローなどのポートレット リソースを保護する必要があります。これを行わないと、それらの URL を知っていれば誰でも直接アクセスできます。デプロイメント記述子に定義されるロールは、ユーザおよびグループ ベースです。
デプロイメント記述子によるポータル アプリケーション リソースの保護については、「ポータル アプリケーション リソースへの直接アクセスの防止」を参照してください。
ポータル アプリケーション リソースは、時間帯やユーザ プロファイル プロパティ値などの実行時制約に基づいて保護することもできます。ロール ベースのセキュリティ ポリシーによるこれらの実行時制約の設定については、「ロールベースの認可の設定」を参照してください。
この節では、ロール ベースのアクセス制御に関する WebLogic Portal 固有の拡張機能の概要を示します。2 種類のカテゴリのユーザに対して、ポータル リソースへのアクセスを制御できます。
ロール ベースのアクセス制御については、「ロールベースの認可の設定」を参照してください。
訪問者資格を使用して、ポータル アプリケーション内のリソースにどのユーザがアクセスできるか、そのリソースに対してユーザが何をできるかを決定します。アクセス権は、ポータル訪問者に割り当てられたロールに基づき、これによって柔軟なポータル リソース管理が可能になります。
たとえば、従業員レビューというポートレットがあり、マネージャのみがアクセスできるようにする場合、マネージャという訪問者資格ロールを作成して、そのロールを割り当てられたユーザのみがポートレットを表示できるように資格を設定できます。
ポータル訪問者には、ユーザ名、グループ メンバシップ、ユーザ プロファイル プロパティ値、セッション属性とリクエスト属性、および日付と時刻の機能に基づいてロールが割り当てられます。たとえば、マイレージ サービスの加入者で前年に 50,000 マイル以上搭乗した訪問者にゴールド メンバー ロールを割り当てることなどができます。ロールは、訪問者がサイトにログインしたときに動的に割り当てられます。この例のように、訪問者資格によるパーソナライゼーションも可能です。
| 注意 : | 訪問者資格ロールがない場合のデフォルトの動作では、すべての訪問者がポータルおよびポータル リソースにアクセスできます。 |
委託管理は、WebLogic Portal Administration Console へのセキュアな管理アクセスを提供します。管理者は WebLogic Portal Administration Console を使用して、ポータル、デスクトップ、シェル、ブック、ページ、レイアウト、ルック アンド フィール、およびポートレットを作成および管理できます。委託管理ロールは、ユーザ名、グループ メンバシップ、ユーザ プロファイル プロパティ値、セッション属性とリクエスト属性、および日付と時刻の機能に基づくポータル管理者の分類です。
組織では、管理者ごとに異なる管理タスクおよびリソースへの異なるアクセス権限を付与する場合があります。委託管理を使用して、WebLogic Portal Administration Console のアクセス権限をロールの階層内で伝播することができます。
たとえば、システム管理者には WebLogic Portal Administration Console のすべての機能にアクセスできる権限を与えます。次に、システム管理者が、ポータルの特定のデスクトップ ビューにあるポータル リソースのインスタンスを管理できる管理者用のポータル管理者ロールを作成します。またシステム管理者は、ポータル リソース ライブラリを管理できる管理者用のライブラリ管理者ロールを作成することもできます。
| 注意 : | WebLogic Portal には、1 件のあらかじめ定義された委託管理ロール「PortalSystemDelegator」があります。デフォルトでは管理者グループのすべてのメンバーが PortalSystemDelegator ロールに割り当てられています。PortalSystemDelegator ロールを割り当てられたメンバーは誰でも、エンタープライズ ポータル アプリケーション内にある任意の管理タスクに無制限にアクセスできます。その他の委託管理ロールは、アクセスが明示的に付与されているリソースのみにアクセスできます。 |
委託管理ロールは、セキュリティ ポリシーを使用してポータル リソースの管理機能にマッピングされます。管理者は、適切な特権を与えることにより、指定されたリソース機能を管理する特権と、委託される側がさらに委託を行う特権の両方を委託できます。
ポータル ライフサイクルの詳細については、「WebLogic Portal の概要」を参照してください。
図 1-2 に、セキュリティ機能がどのようにポータル ライフサイクルに当てはまるかを示します。
アーキテクチャ段階では、セキュリティ ポリシーとロールをどのように編成するか、またそれらをセキュリティ戦略全体にどのように適合させるかを計画します。WebLogic 認証プロバイダとカスタム認証プロバイダのうちどちらを使用するか決めます。また、訪問者資格を使用してどのようにアプリケーションを保護するか、委託管理とデプロイメント記述子を使用してどのようにアプリケーション リソースを保護するか決めます。
開発段階では、ポータル アプリケーションにログインおよびログアウト機能を追加できます。
また、isUserInRole メソッド (またはタグ) を使用して、アプリケーション ロジック内の特定のユーザのロール メンバシップを確認することができます。ポートレット、ブック、およびページにコード化された、プログラムに基づくこのタイプのセキュリティを使用すると、ポータル経由でユーザのパスをカスタマイズしたり、きめ細かい資格チェックを実行したりできます。
isAccessAllowed メソッド (またはタグ) を使用すると、アプリケーション ロジック内の特定のアプリケーション リソースへのアクセスを許可または拒否することができます。これは、ポータル リソースへのアクセスを決定するために、実行時フレームワークによって自動的に呼び出されるメソッドと同じです。
ステージング段階では、開発段階で作成した機能をテストできます。また、ロールとセキュリティ ポリシーを設定します。開発段階とステージング段階は、多くの場合、同時に進行します。これらの 2 つの段階間を繰り返し行き来して、開発および作成したアプリケーションのテストを行うことができます。開発段階に戻って変更を行う場合は、ステージング段階における変更を確認するために、ポータル アプリケーションを再デプロイする必要があります。複数の開発チームでポータルを作成する場合は、コードを結合して作成する方法を決定します。
ステージング段階でポータル アプリケーションをテストした後、プロダクション段階でプロダクション環境を完全な状態にします。たとえば、プロダクション段階では、WebLogic Portal Administration Console を使用して、認証プロバイダを変更したり、ロールやポリシーをわずかに変更したりするなど、ポータル アプリケーションに変更を加えたりします。
初めてポータル開発を行う場合は、ポータル ライフサイクルの詳細について WebLogic Portal の概要を参照してください。
ユーザ、グループ、およびユーザ プロファイルについては、『ユーザ管理ガイド』を参照してください。
WebLogic Server のセキュリティの詳細については、『BEA WebLogic Server® 10.0 セキュリティ』を参照してください。
  
|
