Oracle WebLogic Serverセキュリティのプログラミング

12cリリース1(12.1.1)

B65926-02(原本部品番号:E24485-02)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープ

- このガイドの対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

- WebLogic Server配布キットのセキュリティ・サンプル

- このリリースでのセキュリティの新機能と変更点

2 WebLogicセキュリティ・プログラミングの概要

- セキュリティとは

- 管理コンソールとセキュリティ

- WebLogic Serverでサポートされているセキュリティのタイプ

- 認証

- 認可

- Java EEセキュリティ

- セキュリティAPI

- JAASクライアント・アプリケーションAPI

- Java JAASクライアント・アプリケーションAPI

- WebLogic JAASクライアント・アプリケーションAPI

- SSLクライアント・アプリケーションAPI

- Java SSLクライアント・アプリケーションAPI

- WebLogic SSLクライアント・アプリケーションAPI

- その他のAPI

3 Webアプリケーションの保護

- Webブラウザでの認証

- ユーザー名およびパスワードの認証

- デジタル証明書の認証

- 複数のWebアプリケーション、Cookie、および認証

- セキュアなCookieを使用したセッション盗難の防止

- セキュアなWebアプリケーションの開発

- BASIC認証Webアプリケーションの開発

- HttpSessionListenerを使用したブラウザによる資格証明のキャッシングの報告

- リソースが非セキュアな場合のBASIC認証について

- enforce-valid-basic-auth-credentialsフラグの設定

- WLSTを使用してenforce-valid-basic-auth-credentialsの値の確認

- FORM認証Webアプリケーションの開発

- Webアプリケーションの認証にIDアサーションの使用

- Webアプリケーションの認証に双方向SSLの使用

- 認証方式に対するフォールバック・メカニズムの提供

- 構成

- Swingベース認証Webアプリケーションの開発

- Webアプリケーションのデプロイメント

- Webアプリケーションでの宣言によるセキュリティの使用

- Webアプリケーションのセキュリティ関連のデプロイメント記述子

- web.xmlデプロイメント記述子

- auth-constraint

- security-constraint

- security-role

- security-role-ref

- user-data-constraint

- web-resource-collection

- weblogic.xmlデプロイメント記述子

- externally-defined

- run-as-principal-name

- run-as-role-assignment

- security-permission

- security-permission-spec

- security-role-assignment

- Webアプリケーションでのプログラムによるセキュリティの使用

- getUserPrincipal

- isUserInRole

- プログラムによる認証APIの使用

- ログイン時のユーザー・セッションの変更

4 JavaクライアントでのJAAS認証の使用

- JAASとWebLogic Server

- JAAS認証の開発環境

- JAAS認証API

- JAASクライアント・アプリケーション・コンポーネント

- WebLogic LoginModule実装

- JVM全体のデフォルト・ユーザーとrunAs()メソッド

- JAAS認証を使用するクライアント・アプリケーションの作成

- JNDI認証の使い方

- JavaクライアントのJAAS認証サンプル・コード

5 JavaクライアントでのSSL認証の使用

- JSSEとWebLogic Server

- JNDI認証の使い方

- SSL証明書認証の開発環境

- SSL認証API

- SSLクライアント・アプリケーション・コンポーネント

- SSLを使用するアプリケーションの記述

- WebLogic Server間の安全な通信

- SSLクライアントの作成

- SSLClientサンプル

- SSLSocketClientサンプル

- 双方向SSL認証の使用

- JNDIを使用した双方向SSL認証

- ユーザー名マッパーの作成

- WebLogic Serverインスタンス間で双方向SSL認証の使用

- サーブレットで双方向SSL認証の使用

- カスタム・ホスト名検証の使い方

- トラスト・マネージャの使い方

- 証明書パス・トラスト・マネージャの使い方

- ハンドシェーク完了リスナーの使い方

- SSLContextの使い方

- URLを使用したアウトバウンドSSL接続

- SSLクライアントのサンプル・コード

6 Enterprise JavaBeans (EJB)の保護

- Java EEアーキテクチャ・セキュリティ・モデル

- 宣言による認可

- アノテーションを使用した宣言による認可

- プログラムによる認可

- 宣言による認可とプログラムによる認可

- EJBでの宣言によるセキュリティの使用

- メタデータ・アノテーションを使用した宣言によるセキュリティの実装

- セキュリティ関連アノテーションのコード例

- デプロイメント記述子を使用した宣言によるセキュリティの実装

- EJBのセキュリティ関連のデプロイメント記述子

- ejb-jar.xmlデプロイメント記述子

- method

- method-permission

- role-name

- run-as

- security-identity

- security-role

- security-role-ref

- unchecked

- use-caller-identity

- weblogic-ejb-jar.xmlデプロイメント記述子

- client-authentication

- client-cert-authentication

- confidentiality

- externally-defined

- identity-assertion

- iiop-security-descriptor

- integrity

- principal-name

- role-name

- run-as-identity-principal

- run-as-principal-name

- run-as-role-assignment

- security-permission

- security-permission-spec

- security-role-assignment

- transport-requirements

- EJBでのプログラムによるセキュリティの使用

- getCallerPrincipal

- isCallerInRole

7 ネットワーク接続フィルタの使い方

- ネットワーク接続フィルタを使用する利点

- ネットワーク接続フィルタAPI

- 接続フィルタのインタフェース

- ConnectionFilterインタフェース

- ConnectionFilterRulesListenerインタフェース

- 接続フィルタのクラス

- ConnectionFilterImplクラス

- ConnectionEventクラス

- 接続フィルタ・ルールの作成ガイドライン

- 接続フィルタ・ルールの構文

- 接続フィルタ・ルールの種類

- 接続フィルタ・ルールの評価方法

- WebLogic接続フィルタの構成

- カスタム接続フィルタの開発

8 Javaセキュリティを使用したWebLogicリソースの保護

- Java EEセキュリティを使用したWebLogicリソースの保護

- Javaセキュリティ・マネージャを使用したWebLogicリソースの保護

- Javaセキュリティ・マネージャの設定

- 全体的に使用するweblogic.policyファイルの修正

- アプリケーション型のセキュリティ・ポリシーの設定

- アプリケーション固有のセキュリティ・ポリシーの設定

- セキュリティ・マネージャのプリントの使用

- セキュリティ・マネージャのプリントの起動引数

- セキュリティ・マネージャのプリントを使用するWebLogic Serverの起動

- 出力ファイルの書込み

- Java Authorization Contract for Containersの使用

- WebLogic JACCプロバイダとWebLogic認可プロバイダの比較

- WebLogic JACCプロバイダの有効化

9 SAML API

- SAML APIの説明

- カスタムPOSTフォーム・パラメータ名

- 非WebLogic SAML 1.1リライイング・パーティ用アサーションの作成

- カスタムSAML名マッパーの作成の概要

- 複数のSAMLCredentialAttributeMapper実装が必要な場合

- クラス、インタフェース、およびメソッド

- SAMLAttributeStatementInfoクラス

- SAMLCredentialAttributeMapperインタフェース

- 例として使用するカスタムSAMLCredentialAttributeMapperクラス

- コンソールでカスタムSAMLCredentialAttributeMapperクラスを使用可能にする

- SAML SSO属性サポートの構成

- SAML SSO属性とは

- SAML属性用の新規API

- 必須のSAML 2.0基本属性プロファイル

- 複数の属性のSAML資格証明マッパーへの受け渡し

- SAML属性を実装する方法

- SAML 2.0属性インタフェースの例

- カスタムSAML 2.0資格証明属性マッパーの例

- カスタムSAML 2.0 IDアサーション・プロバイダ属性マッパー

- SAML 1.1属性インタフェースの例

- カスタムSAML 1.1資格証明属性マッパーの例

- カスタムSAML 1.1 IDアサーション・プロバイダ属性マッパー

- コンソールでカスタムSAML資格証明属性マッパーのクラスを使用可能にする

- コンソールでカスタムSAML IDアサーション・プロバイダ・クラスを使用可能にする

10 証明書パスの作成と検証

- 証明書パスの作成

- CertPathSelectorのインスタンス化

- CertPathBuilderParametersのインスタンス化

- JDK CertPathBuilderインタフェースの使用

- 証明書チェーンの検索のコード・フロー例

- 証明書パスの検証

- CertPathValidatorParametersのインスタンス化

- JDK CertPathValidatorインタフェースの使用

- 証明書チェーンの検証のコード・フロー例

A 非推奨のセキュリティAPI

Oracle® Fusion Middleware

Oracle WebLogic Serverセキュリティのプログラミング

12cリリース1(12.1.1)

B65926-02(原本部品番号:E24485-02)

2012年1月

このドキュメントでは、Oracle Weblogic Serverセキュリティのプログラミング機能の使用方法を説明します。

Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング, 12cリリース1(12.1.1)

B65926-02

Copyright © 2007, 2012, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic Serverセキュリティのプログラミング』で使用されるドキュメントのアクセシビリティ機能と規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

以下の節では、このガイド - WebLogicセキュリティのプログラミング - の内容と構成について説明します:

- ドキュメントのスコープ

- このガイドの対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

- このリリースでのセキュリティの新機能と変更点

ドキュメントのスコープ

このドキュメントでは、WebLogic Serverのセキュリティ・プログラミング機能の使用方法を説明します。

WebLogic Serverのセキュリティに関するその他のドキュメントについては、「関連情報」を参照してください。

このガイドの対象読者

このドキュメントは、以下の読者を対象としています。

- アプリケーション開発者
クライアント・アプリケーションの開発と、WebアプリケーションおよびEnterprise JavaBeans (EJB)へのセキュリティ機能の付加を主な業務とするJavaプログラマです。他のエンジニアリング・チームや品質保証(QA)チーム、データベース・チームと連携して、セキュリティ機能を実装します。アプリケーション開発者は、Java(サーブレットやJSPなどのJava Platform, Enterprise Edition (Java EE)コンポーネントとJSEE)、およびJavaセキュリティについて実用的かつ深い知識を備えています。

アプリケーション開発者は、WebLogicセキュリティとJavaセキュリティ・アプリケーション・プログラミング・インタフェース(API)を使用してアプリケーションのセキュリティを確保します。したがって、このドキュメントはWebアプリケーション、Javaアプリケーション、およびEnterprise JavaBeans (EJB)のセキュリティを確保するためにそれらのAPIを使用する手順を紹介します。

- セキュリティ開発者
WebLogic Serverに統合されるセキュリティ製品のシステム・アーキテクチャとインフラストラクチャの定義と、WebLogic Serverで使用するカスタム・セキュリティ・プロバイダの開発を主な業務とする開発者です。アプリケーション設計者と連携して、セキュリティ・アーキテクチャを、確実に設計に従ってセキュリティ・ホールが発生しないように実装します。また、セキュリティが確実に正しく構成されるよう、WebLogic Serverの管理者とも連携します。セキュリティ開発者は、認証、認可、監査(AAA)、Java Management eXtension (JMX)などのJavaに対する深い知識、およびWebLogic Serverとセキュリティ・プロバイダの機能に対する実践的な知識をはじめとしたセキュリティ概念をしっかりと理解しています。

セキュリティ・ベンダーは、セキュリティ・サービス・プロバイダ・インタフェース(SSPI)を使用してWebLogic Serverで使用するカスタム・セキュリティ・プロバイダを開発します。このタスクについてはこのドキュメントで扱いません。SSPIを使用してカスタム・セキュリティ・プロバイダを開発する方法の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

- サーバー管理者
アプリケーション設計者と密接に連携しながら、サーバーおよびサーバー上で動作するアプリケーションのセキュリティ方式の設計、潜在的なセキュリティ・リスクの特定、およびセキュリティ上の問題を防止する構成の提案を行う管理者です。関連する責務として、重要な本番システムの保守、セキュリティ・レルムの構成と管理、サーバー・リソースとアプリケーション・リソースへの認証および認可方式の実装、セキュリティ機能のアップグレード、およびセキュリティ・プロバイダのデータベースの保守などが含まれる場合もあります。WebLogic Serverの管理者は、WebアプリケーションとEJBのセキュリティ、公開鍵セキュリティ、およびSSLを含む、Javaセキュリティ・アーキテクチャについて深い知識を備えています。

- アプリケーション管理者
アプリケーション管理者は、WebLogic Serverの管理者と連携してセキュリティ構成、認証および認可方式を実装および管理したり、定義されたセキュリティ・レルムでデプロイされたアプリケーション・リソースへのアクセスを設定および管理したりします。アプリケーション管理者は、セキュリティの概念やJavaセキュリティ・アーキテクチャの一般的な知識を備えています。また、Java、XML、デプロイメント記述子を理解し、サーバー・ログおよび監査ログでセキュリティ・イベントを特定できます。

管理者は通常、アプリケーションを実際に稼働させるときに、管理コンソールを使用してアプリケーションのデプロイ、構成および管理を行いますが、アプリケーション開発者も管理コンソールを使用して実際の本番前にアプリケーションをテストする場合があります。アプリケーションをテストするときには、最低でも、アプリケーションがデプロイされて構成されている必要があります。このドキュメントではセキュリティに関連した管理のいくつかの側面を取り上げていません。管理コンソールを使用してセキュリティ・タスクを行う方法の説明については、『Oracle WebLogic Serverの保護』、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』、およびOracle WebLogic Server管理コンソール・ヘルプを参照先として示します。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- 第2章「WebLogicセキュリティ・プログラミングの概要」では、セキュリティの必要性について解説し、WebLogicセキュリティのアプリケーション・プログラミング・インタフェース(API)について説明します。

- 第3章「Webアプリケーションの保護」では、Webアプリケーションにセキュリティを実装する方法について説明します。

- 第4章「JavaクライアントでのJAAS認証の使用」では、JavaクライアントにJAAS認証を実装する方法について説明します。

- 第5章「JavaクライアントでのSSL認証の使用」では、JavaクライアントにSSL認証とデジタル証明書認証を実装する方法について説明します。

- 第6章「Enterprise JavaBeans (EJB)の保護」では、Enterprise JavaBeansにセキュリティを実装する方法について説明します。

- 第7章「ネットワーク接続フィルタの使い方」では、ネットワーク接続フィルタを実装する方法について説明します。

- 第8章「Javaセキュリティを使用したWebLogicリソースの保護」では、Javaセキュリティを使用してWebLogicリソースを保護する方法について説明します。

- 第9章「SAML API」では、WebLogic SAML APIについて説明します。

- 第10章「証明書パスの作成と検証」では、証明書パスを作成および検証する方法について説明します。

- 「付録A 非推奨のセキュリティAPI」では、APIが非推奨になったweblogic.securityパッケージの一覧を示します。

注意:

このドキュメントは、WebLogic Serverで使用するカスタム・セキュリティ・プロバイダを記述しようと考えている開発者向けではありません。カスタム・セキュリティ・プロバイダの開発の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

関連情報

このドキュメント『WebLogicセキュリティのプログラミング』に加え、以下のドキュメントでもWebLogicセキュリティ・サービスについて説明しています。

- 『Oracle WebLogic Serverのセキュリティの理解』: WebLogicセキュリティ・サービスの特長を要約し、WebLogicセキュリティ・サービスのアーキテクチャと機能について概説します。このドキュメントはWebLogicセキュリティ・サービスを理解する上で基本となるものです。

- 『Oracle WebLogic Server本番環境の保護』: WebLogic Serverを本番環境にデプロイする前に検討すべき重要なセキュリティ対策について説明します。

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』: セキュリティ・ベンダーとアプリケーション開発者に対して、WebLogic Serverで使用できるカスタム・セキュリティ・プロバイダを開発するために必要な情報を提供します。

- 『Oracle WebLogic Serverの保護』: WebLogic Serverのセキュリティの構成方法、および互換性セキュリティの使用方法について説明します。

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』: 様々なタイプのWebLogicリソースを紹介し、WebLogic Serverを使用してそれらのリソースを保護するための情報を提供します。

- Oracle WebLogic Server管理コンソール・ヘルプ: 管理コンソールを使用してセキュリティ・タスクを実行する方法について説明します。

- Oracle WebLogic Server APIリファレンス - WebLogic Serverソフトウェアで提供およびサポートされているWebLogicセキュリティ・パッケージのリファレンス・ドキュメントです。

セキュリティのサンプルとチュートリアル

「関連情報」に示したドキュメントの他にも、様々なコード・サンプルが開発者向けに用意されています。

WebLogic Server配布キットのセキュリティ・サンプル

WebLogic Serverでは、任意でAPIサンプル・コードをWL_HOME\samples\server\examples\src\examples\securityにインストールできます。WL_HOMEはWebLogic Serverのインストール先の最上位ディレクトリを示します。WebLogic Serverのスタート・メニューからサンプル・サーバーを起動して、サンプルとその実行手順に関する情報を確認できます。

WebLogicのセキュリティ機能については、次のサンプルを参照してください。

- Java認証および認可サービス

- 発信および双方向SSL

このドキュメント内のセキュリティ・タスクおよびサンプル・コードでは、カスタム・セキュリティ・プロバイダではなく、WebLogic Server配布キットのWebLogicセキュリティ・プロバイダを使用することを前提にしています。カスタム・セキュリティ・プロバイダを使用する場合、WebLogicセキュリティAPIの使い方は同じですが、カスタム・セキュリティ・プロバイダの管理手順が異なります。

注意:

このドキュメントでは、WebLogicセキュリティ・プロバイダまたはカスタム・セキュリティ・プロバイダの構成方法について幅広く説明してはいません。WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダの構成の詳細は、『Oracle WebLogic Serverの保護』を参照してください。

このリリースでのセキュリティの新機能と変更点

このリリースで導入されたWebLogic Serverの新機能の一覧については、『Oracle WebLogic Serverの新機能』を参照してください。

2 WebLogicセキュリティ・プログラミングの概要

この項では、WebLogicセキュリティのプログラミングの概要を示します。

この節では、以下の内容について説明します。

- セキュリティとは

- 管理コンソールとセキュリティ

- WebLogic Serverでサポートされているセキュリティのタイプ

- セキュリティAPI

セキュリティとは

セキュリティとは、コンピュータに保存されているデータまたはコンピュータ間でやりとりされるデータが危険にさらされないことを保証する技術です。ほとんどの場合、セキュリティ対策では証明データとデータ暗号化を利用します。一般に証明データは、ユーザーに特定のアプリケーションまたはシステムへのアクセスを許可する秘密の単語または句です。データ暗号化とは、その秘密の単語または句を保持しているか提供しなければ解釈できないような形式にデータを変換することです。

電子商取引(e- コマース)向けアプリケーションなどの分散アプリケーションでは、悪意のある何者かがデータを横取りし、処理を混乱させ、不正な入力を行う起点となるような多数のアクセス・ポイントが提供されます。ビジネスの分散化が進むにつれて、セキュリティが侵害される可能性も大きくなります。したがって、アプリケーションの分散に伴い、その基盤となる分散コンピューティング・ソフトウェアによってセキュリティを実現することがますます重要になります。

アプリケーション・サーバーは、エンド・ユーザーと貴重なデータやリソースとの間の重要なレイヤーに位置しています。WebLogic Serverは、これらのリソースを保護するために認証、認可、および暗号化サービスを提供します。しかし、こうしたサービスでは、デプロイメント環境の弱点を見つけ出して悪用することでアクセスを取得した侵入者から、リソースを守ることはできません。

したがって、インターネットまたはイントラネット上でWebLogic Serverをデプロイする場合には、独立したセキュリティ専門家に依頼して、セキュリティ・プランと手順を検討してもらい、インストール済みシステムの監査を受け、改善点のアドバイスを受けるとよいでしょう。

セキュリティ問題と適切なセキュリティ対策についてできるかぎり知識を増やすことも重要です。ドキュメント『Oracle WebLogic Server本番環境の保護』では、WebLogic Serverを本番環境にデプロイする前に検討すべき重要なセキュリティ対策について説明します。ドキュメント『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』では、様々なタイプのWebLogicリソースを紹介し、WebLogic Serverを使用してそれらのリソースを保護するための情報を提供します。Webサーバーの保護に関する最新情報を得るために、カーネギー・メロン大学が運営するCERT(tm) Coordination Centerが公開している『Security Improvement Modules, Security Practices, and Technical Implementations information』(http://www.cert.org/)にも目を通すことをお薦めします。

Oracleのセキュリティ勧告で推奨されている対策は是非、実行してください。Oracle製品に関して問題が発生した場合には、Oracleから、その報告と適切な対策を示した指示が配信されます。サイトのセキュリティ関連の問題を担当されている方は、今後、通知を受け取れるように登録を行ってください。

管理コンソールとセキュリティ

セキュリティに関しては、Webアプリケーション、EJB、Java EEコネクタ、およびエンタープライズ・アプリケーションのデプロイメント記述子の定義および編集に、管理コンソールを使用できます。このドキュメント『WebLogicセキュリティのプログラミング』では、管理コンソールを使用したセキュリティの構成方法については説明しません。管理コンソールを使用してデプロイメント記述子を定義および編集する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』および『Oracle WebLogic Serverの保護』を参照してください。

WebLogic Serverでサポートされているセキュリティのタイプ

WebLogic Serverでは次のセキュリティ・メカニズムがサポートされます。

- 認証

- 認可

- Java EEセキュリティ

認証

認証とは、呼出し側とサービス・プロバイダが、特定のユーザーまたはシステムのかわりに動作していることを証明する際に使用するメカニズムのことです。認証は、資格証明を使用して「あなたは誰」という問いに答えます。証明が双方向で行われる場合、相互認証と呼ばれます。

WebLogic Serverは、ユーザー名およびパスワードによる認証と証明書による認証をサポートしています。WebLogic Serverは、証明書認証について一方向と双方向のSSL (Secure Sockets Layer)認証を両方ともサポートしています。双方向のSSL認証は、相互認証の一形態です。

WebLogic Serverでは、ユーザーまたはシステム・プロセスのIDを証明するために認証プロバイダを使用します。認証プロバイダでは、ID情報を記憶したり、トランスポートしたり、その情報が必要な場合に(サブジェクトを通じて)システムの様々なコンポーネントで利用できるようにしたりします。認証プロバイダは、WebアプリケーションおよびEJBデプロイメント記述子ファイル、または管理コンソール、あるいはその両方を使用して構成できます。

認可

認可とは、ユーザーのIDなどの情報に基づいて、ユーザーとWebLogicリソースとのやり取りを管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。

WebLogic Serverでは、WebLogic認可プロバイダはユーザーとWebLogicリソースとの対話を制限して、整合性、機密性、および可用性を確保します。認可プロバイダは、WebアプリケーションおよびEJBデプロイメント記述子ファイル、または管理コンソール、あるいはその両方を使用して構成できます。

WebLogic Serverでは、プログラムによる認可(このドキュメントではプログラムによるセキュリティともいう)を使用してユーザーとWebLogicリソースとの対話を制限することもできます。

Java EEセキュリティ

ユーザー認証とユーザー認可を実装および使用するために、WebLogic Serverでは、Java EE Development Kit 6.0(JDK 6.0)のセキュリティ・サービスが利用されます。他のJava EEコンポーネントと同様、セキュリティ・サービスも標準化されたモジュール・コンポーネントに基づいています。WebLogic Serverは、標準に従ってこれらのJavaセキュリティ・サービス・メソッドを実装し、追加のプログラミングを必要とせずに、細かなアプリケーションの動作を自動的に処理する拡張機能を追加します。

セキュリティAPI

ここでは、WebLogic Serverが実装およびサポートしているセキュリティ関連のパッケージとクラスについて説明します。これらのパッケージを使用して、WebLogic Serverとクライアント・アプリケーション、Enterprise JavaBeans (EJB)、およびWebアプリケーションとの間の対話を保護します。

注意:

WebLogicセキュリティ・パッケージ、クラス、およびメソッドの中には、WebLogic Serverのこのリリースでは非推奨となっているものがあります。非推奨となったパッケージおよびクラスの詳細は、「付録A 非推奨のセキュリティAPI」を参照してください。

この節では、以下の内容について説明します。

- JAASクライアント・アプリケーションAPI

- SSLクライアント・アプリケーションAPI

- その他のAPI

JAASクライアント・アプリケーションAPI

JAAS認証を使用するクライアント・アプリケーションを作成するには、Java APIおよびWebLogic APIを使用します。

この節では、以下の内容について説明します。

- Java JAASクライアント・アプリケーションAPI

- WebLogic JAASクライアント・アプリケーションAPI

Java JAASクライアント・アプリケーションAPI

JAASクライアント・アプリケーションの作成には、以下のJava APIを使用します。このAPIはhttp://download.oracle.com/javase/6/docs/api/index.htmlから入手できます。

- javax.naming

- javax.security.auth

- javax.security.auth.callback

- javax.security.auth.login

- javax.security.auth.spi

これらのAPIの使い方については、「JAAS認証API」を参照してください。

WebLogic JAASクライアント・アプリケーションAPI

JAASクライアント・アプリケーションの作成には、以下のWebLogic APIを使用します。

- weblogic.security

- weblogic.security.auth

- weblogic.security.auth.callback

これらのAPIの使い方については、「JAAS認証API」を参照してください。

SSLクライアント・アプリケーションAPI

SSL認証を使用するクライアント・アプリケーションを作成するには、Java APIおよびWebLogic APIを使用します。

この節では、以下の内容について説明します。

- Java SSLクライアント・アプリケーションAPI

- WebLogic SSLクライアント・アプリケーションAPI

Java SSLクライアント・アプリケーションAPI

SSLクライアント・アプリケーションの作成には、次のJava API(http://download.oracle.com/javase/6/docs/api/index.html)を使用します。

- java.security

- java.security.cert

- javax.crypto

- javax.naming

- javax.net

- javax.security

- javax.servlet

- javax.servet.http

WebLogic Serverは、javax.net.SSL API(http://download.oracle.com/javase/6/docs/api/index.html)もサポートしていますが、WebLogic ServerでSSLを使用する際にはweblogic.security.SSLパッケージを使用することをお薦めします。

これらのAPIの使い方については、「SSL認証API」を参照してください。

WebLogic SSLクライアント・アプリケーションAPI

SSLクライアント・アプリケーションの作成には、以下のWebLogic APIを使用します。

- weblogic.net.http

- weblogic.security.SSL

これらのAPIの使い方については、「SSL認証API」を参照してください。

その他のAPI

さらに、以下のAPIがWebLogic Serverアプリケーションの開発に使用されます。

- weblogic.security.jacc
このAPIはRoleMapperインタフェースを提供します。JACC (Java Authorization Contract for Containers)を実装する場合は、このパッケージをjavax.security.jaccパッケージ(http://download.oracle.com/javaee/6/api/javax/security/jacc/package-summary.html)とともに使用できます。WebLogic JACCプロバイダの詳細は、「Java Authorization Contract for Containersの使用」を参照してください。JACCプロバイダの開発については、http://www.oracle.com/technetwork/java/javaee/javaacc-138697.htmlを参照してください。

- weblogic.security.net
このAPIはネットワーク接続フィルタの実装に使用されるインタフェースおよびクラスを提供します。ネットワーク接続フィルタは、ネットワーク接続を開始したクライアントのIPアドレス、ドメイン、またはプロトコルなどの属性に基づいてWebLogic Serverへの接続を許可または拒否します。このAPIの使い方の詳細は、第7章「ネットワーク接続フィルタの使い方」を参照してください。

- weblogic.security.pk
このAPIは、証明書パスを作成および検証するためのインタフェースとクラスを提供します。このAPIを使用して証明書チェーンを作成および検証する方法については、第10章「証明書パスの作成と検証」を参照してください。

証明書および証明書パスに関する追加情報については、java.security.certパッケージ(http://download.oracle.com/javase/6/docs/api/java/security/cert/package-summary.html)を参照してください。

- weblogic.security.providers.saml
このAPIは、ユーザーおよびグループ情報からSAML (Security Assertion Markup Language)アサーションへのマッピングや、SAMLアサーションのキャッシュおよび取得に使用するインタフェースとクラスを提供します。

SAMLは、セキュリティ情報をやり取りするためのXMLベースのフレームワークです。WebLogic Serverでは、SAML V2.0およびV1.1(ブラウザ/POSTプロファイルおよびブラウザ/アーティファクト・プロファイルを含む)がサポートされます。SAML認可はサポートされません。

SAMLの詳細は、http://www.oasis-open.orgを参照してください。

- weblogic.security.service
このAPIには、セキュリティ・プロバイダをサポートするインタフェース、クラスおよび例外が含まれます。WebLogicセキュリティ・フレームワークは、このAPIで提供されるインタフェース、クラスおよび例外からなります。このAPIのインタフェース、クラスおよび例外は、weblogic.security.spiパッケージのインタフェース、クラスおよび例外と関連付けて使用します。このAPIの使用方法の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

- weblogic.security.services
このAPIはサーバー側の認証クラスを提供します。このクラスは、サーバーへのローカル・ログインの実行に使用されます。ユーザーを認証し、デフォルトのセキュリティ・レルムを使用して資格証明を返すためのCallbackHandlersと共に使用されるログイン・メソッドを提供します。

- weblogic.security.spi
このパッケージはセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を提供します。カスタム・セキュリティ・プロバイダの開発に使用されるインタフェース、クラスおよび例外を提供します。多くの場合、これらのインタフェース、クラスおよび例外は、weblogic.security.service APIのインタフェース、クラスおよび例外と関連付けて使用します。このパッケージからのインタフェース、クラスおよび例外を実装することで、セキュリティ・プロバイダの実行時クラスを作成できます。SSPIの使用方法の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

- weblogic.servlet.security
このAPIは、サーブレット・アプリケーション内からプログラムによる認証をサポートするサーバー側APIを備えています。このAPIの使い方の詳細は、「プログラムによる認証APIの使用」を参照してください。

3 Webアプリケーションの保護

WebLogic Serverは、Webアプリケーションを保護するJava EEアーキテクチャ・セキュリティ・モデルをサポートしています。これには、宣言による認可(このドキュメントでは宣言によるセキュリティとも呼びます)とプログラムによる認可(このドキュメントではプログラムによるセキュリティとも呼びます)のサポートが含まれます。

この節では、以下のトピックを取り上げます。

- Webブラウザでの認証

- 複数のWebアプリケーション、Cookie、および認証

- セキュアなWebアプリケーションの開発

- Webアプリケーションでの宣言によるセキュリティの使用

- Webアプリケーションのセキュリティ関連のデプロイメント記述子

- Webアプリケーションでのプログラムによるセキュリティの使用

- プログラムによる認証APIの使用

注意:

Webアプリケーションの保護には、デプロイメント記述子ファイルと管理コンソールを使用できます。このドキュメントでは、デプロイメント記述子ファイルを使用する方法について説明します。管理コンソールを使用したWebアプリケーションの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

WebLogic Serverは、Webアプリケーションにおけるプログラムによる認可を実装するために、HttpServletRequest.isUserInRoleメソッドとHttpServletRequest.getUserPrincipalメソッドの使用、およびデプロイメント記述子でのsecurity-role-ref要素の使用をサポートしています。

Webブラウザでの認証

Webブラウザは、HyperText Transfer Protocol (HTTP)ポートまたはHTTP with SSL (HTTPS)ポートを介してWebLogic Serverに接続できます。HTTPポートではなくHTTPSポートを利用するメリットは2つあります。HTTPS接続を利用するメリットは以下のとおりです。

- Webブラウザとサーバーの間で行われるすべての通信が暗号化されます。ユーザー名とパスワードを含め、通信がクリア・テキストで行われることはありません。

- 最低限の認証要件として、サーバーは身元を証明するためにWebブラウザ・クライアントに対してデジタル証明書を提示する必要があります。

双方向SSL認証を行うようにサーバーが構成された場合は、サーバーとクライアントの両方が互いにデジタル証明書を提示して、身元を証明する必要があります。

ユーザー名およびパスワードの認証

WebLogic Serverでは、ユーザーがWebブラウザを使用してHTTPポート経由でサーバーに接続するときにユーザー名とパスワードの認証が行われます。その場合、ブラウザとWebLogic Serverのインスタンスは次のように対話してユーザーを認証します(図3-1を参照)。

1. ユーザーは、WebブラウザでWebLogicリソースのURLを入力して、WebLogic ServerのWebLogicリソースを呼び出します。そのHTTP URLでは、たとえばhttp://myserver:7001のようにHTTPリスニング・ポートを指定します。

2. WebLogic ServerのWebサーバーはリクエストを受け取ります。

注意:

WebLogic Serverでは独自のWebサーバーを用意していますが、Apache Server、Microsoft Internet Information Server、およびJava System Web ServerもWebサーバーとして使用できます。

3. Webサーバーは、リクエストされたWebLogicリソースがセキュリティ・ポリシーによって保護されているかどうか判別します。WebLogicリソースが保護されている場合、Webサーバーは確立されているHTTP接続を使用して、ユーザーのユーザー名とパスワードをリクエストします。

4. ユーザーのWebブラウザがWebサーバーからのリクエストを受け取ると、ユーザーに対してユーザー名とパスワードを要求します。

5. Webブラウザは、Webサーバーに対してユーザー名とパスワードと一緒にリクエストを再送信します。

6. WebサーバーはリクエストをWebサーバー・プラグインに転送します。WebLogic Serverでは、Webサーバー用に以下のプラグインを提供します。

- Apache-WebLogic Serverプラグイン

- Java System Web Serverプラグイン

- Internet Information Server (IIS)プラグイン

Webサーバー・プラグインは、HTTPプロトコルを使用して、ユーザーから受け取った認証データ(ユーザー名とパスワード)と一緒に認証リクエストをWebLogic Serverに送信することで認証を行います。

7. 認証に成功すると、WebLogic Serverは、ユーザーがそのWebLogicリソースへのアクセスに必要な権限を持っているかどうかを調べます。

8. WebLogicリソースに対してメソッドを呼び出す前に、WebLogic Serverインスタンスはセキュリティ認可チェックを実行します。サーバーは、このチェックで、ユーザーの資格証明をセキュリティ・コンテキストから取り出し、ユーザーのセキュリティ・ロールを特定して、そのユーザーのセキュリティ・ロールを、リクエストされたWebLogicリソースのセキュリティ・ポリシーと照らし合わせ、ユーザーがWebLogicリソースに対してメソッドを呼び出す認可を持っていることを確認します。

9. 認可が成功すると、サーバーがリクエストを遂行します。

図3-1 Webブラウザのセキュア・ログイン

「図3-1 Webブラウザのセキュア・ログイン」の説明

デジタル証明書の認証

WebLogic Serverは、WebブラウザのユーザーがHTTPSポート経由でサーバーに接続する場合に暗号化とデジタル証明書の認証を使用します。その場合、ブラウザとサーバーは次のように対話してユーザーを認証および認可します(図3-1を参照)。

1. ユーザーは、WebブラウザでWebLogicリソースのURLを入力して、WebLogic ServerのWebLogicリソースを呼び出します。そのHTTPS URLでは、たとえばhttps://myserver:7002のようにSSLリスニング・ポートを指定します。

2. WebLogic ServerのWebサーバーはリクエストを受け取ります。

注意:

WebLogic Serverでは独自のWebサーバーを用意していますが、Apache Server、Microsoft Internet Information Server、およびJava System Web ServerもWebサーバーとして使用できます。

3. Webサーバーは、WebLogicリソースがセキュリティ・ポリシーによって保護されているかどうかチェックします。WebLogicリソースが保護されている場合、Webサーバーは確立されているHTTPS接続を使用して、ユーザーのユーザー名とパスワードをリクエストします。

4. ユーザーのWebブラウザがWebLogic Serverからのリクエストを受け取ると、ユーザーに対してユーザー名とパスワードを要求します。この手順は省略可能です。

5. Webブラウザは、ユーザー名とパスワードと一緒にリクエストを再送信します(サーバーからリクエストされた場合のみ供給されます)。

6. WebLogic Serverは、Webブラウザにデジタル証明書を提示します。

7. Webブラウザは、URLで使用されているサーバーの名前(たとえばmyserver)がデジタル証明書の名前と一致すること、そしてデジタル証明書が信頼できる第三者(信頼性のあるCA)によって発行されたものであることをチェックします。

8. 双方向SSL認証を使用するよう設定されている場合、サーバーはクライアントのデジタル証明書をリクエストします。

注意:

1.0 Webサーバー・プロキシ・プラグインを使用して完全な双方向SSLハンドシェークを強制するようにWebLogic Serverを構成できなくても、必要に応じてクライアント証明書をサーバーに提供するようにプロキシ・プラグインを構成できます。そのためには、HTTPヘッダーのクライアント証明書をWebLogic Serverに対してエクスポートするように、プロキシ・プラグインを構成します。クライアント証明書をWebLogic Serverにエクスポートするようにプロキシ・プラグインを構成する手順については、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』でご使用のプラグインに関する構成情報を参照してください。

バージョン1.1プラグインがクライアントIDを検証するため双方向SSLサポートを提供します。ハンドシェイク・プロセス中にWebLogic Serverがクライアント証明書をリクエストすると双方向SSLが自動的に強制されます。『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』のプラグインとWebLogic Server間の双方向SSLの構成に関する項を参照してください。

9. WebサーバーはリクエストをWebサーバー・プラグインに転送します。セキュアなプロキシが設定されていれば(HTTPSプロトコルが使用されている場合には設定されています)、Webサーバー・プラグインはまた、HTTPSプロトコルを介して、ユーザーから受け取った認証データ(ユーザー名とパスワード)と一緒にリクエストをWebLogic ServerのWebLogicリソースに送信することによって認証を実行します。

注意:

双方向SSL認証を使用していれば、クライアントの証明書に基づいてIDアサーションを行うようにサーバーを構成することもできます。この場合、ユーザーがユーザー名とパスワードを提供するのではなく、サーバーはクライアントの証明書からユーザー名とパスワードを取り出します。

10. 認証に成功すると、WebLogic Serverは、ユーザーがそのWebLogicリソースへのアクセスに必要な権限を持っているかどうかを調べます。

11. WebLogicリソースに対してメソッドを呼び出す前に、サーバーはセキュリティ認可チェックを実行します。サーバーは、このチェックで、ユーザーの資格証明をセキュリティ・コンテキストから取り出し、ユーザーのセキュリティ・ロールを特定して、そのユーザーのセキュリティ・ロールを、リクエストされたWebLogicリソースのセキュリティ・ポリシーと照らし合わせ、ユーザーがWebLogicリソースに対してメソッドを呼び出す認可を持っていることを確認します。

12. 認可が成功すると、サーバーがリクエストを遂行します。

詳細については、以下のドキュメントを参照してください。

- 『Oracle WebLogic Serverの保護』

- Apache HTTP Serverプラグインのインストールと構成

- Microsoft IISプラグインのインストールと構成

複数のWebアプリケーション、Cookie、および認証

デフォルトでは、WebLogic ServerはすべてのWebアプリケーションに同じCookie名(JSESSIONID)を割り当てます。同じCookie名を使用するWebアプリケーションでは、どの種類の認証を使用する場合でも、認証用に1つのサインオンを使用します。ユーザーが認証されると、その認証は、同じCookie名を使用するすべてのWebアプリケーションへのリクエストに対して有効になります。ユーザーは再び認証を要求されることはありません。

Webアプリケーションごとに個別の認証が必要な場合は、Webアプリケーションに一意のCookie名またはCookieパスを指定できます。CookieNameパラメータでCookie名を指定し、CookiePathパラメータでCookieパスを指定します。これらのパラメータは、WebLogic固有のデプロイメント記述子のweblogic.xmlの<session-descriptor要素で定義されます。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のsession-descriptorに関する項を参照してください。

Cookie名を保持しつつWebアプリケーションごとに別々の認証が必要な場合は、WebアプリケーションごとにCookieパス・パラメータ(CookiePath)を変えることができます。

WebLogic Serverでは、セッション・データを失うことなく、HTTPを使用して開始されたセッションでHTTPSリソースにユーザーが安全にアクセスできます。この機能を利用すると、Webサイトの設計者はセッションの盗難を防止できます。この機能の詳細は、「セキュアなCookieを使用したセッション盗難の防止」を参照してください。

セキュアなCookieを使用したセッション盗難の防止

Webセキュリティの一般的な問題は、セッションの盗難です。この問題は、通常はCookieがネットワーク経由で転送されている間に、攻撃者がセッションCookieのコピーを取得しようとしたときに発生します。この問題は、データがクリア・テキストで(つまり、Cookieが暗号化されずに)送信されている場合にのみ発生します。

WebLogic Serverでは、セッション・データを失うことなく、HTTPを使用して開始されたセッションでHTTPSリソースにユーザーが安全にアクセスできます。この機能を有効にするには、config.xmlのWebServer要素にAuthCookieEnabled="true"を追加します。

<WebServer Name="myserver" AuthCookieEnabled="true"/>

AuthCookieEnabledをtrue(デフォルト設定)に設定すると、新しいセキュアなCookie(_WL_AUTHCOOKIE_JSESSIONID)が、HTTPS接続を介した認証時にブラウザに送信されるようになります。一度セキュアなCookieが設定されると、セッションはそのCookieがブラウザから送信された場合しかセキュリティ制約のある他のHTTPSリソースにアクセスできません。

このように、WebLogic Serverでは2つのCookie(JSESSIONIDCookieと_WL_AUTHCOOKIE_JSESSIONIDCookie)が使用されています。デフォルトでは、JSESSIONIDCookieはセキュアではありませんが、_WL_AUTHCOOKIE_JSESSIONIDCookieは常にセキュアです。セキュアなCookieは、暗号化された通信チャネルが使用されている場合のみ送信されます。標準のHTTPSログインを想定した場合(HTTPSは暗号化されたHTTP接続)、ブラウザは両方のCookieを取得します。

それ以降のHTTPアクセスでは、有効なJSESSIONIDCookieがあれば認証済みと判断されますが、HTTPSアクセスの場合は、両方のCookieがないと認証済みとは見なされません。JSESSIONIDCookieしかない場合は、再び認証する必要があります。

この機能が有効な場合は、HTTPS経由で一度ログインすると、セキュアなCookieはネットワーク上を暗号化された状態でしか送信されません。したがって途中で盗まれることはありません。ただしJSESSIONID Cookieは、それでも途中で盗まれる恐れがあります。したがって、Webサイトの設計者はすべての機密データでHTTPSが必須となるようにすることでセッションの盗難が起こらないようにできます。HTTPセッションCookieはまだ盗用に対して脆弱ですが、すべての機密を扱う処理で_WL_AUTHCOOKIE_JSESSIONID (盗まれない)が必須となっているので、それらの処理は保護されます。

weblogic.xmlデプロイメント記述子の<session-descriptor>要素で定義するCookieNameパラメータを使用して、JSESSIONIDまたは_WL_AUTHCOOKIE_JSESSIONIDのCookie名を指定することもできます。次に例を示します。

<session-descriptor>
<cookie-name>FOOAPPID</cookie-name>
</session-descriptor>

この場合、Weblogic ServerではJSESSIONIDと_WL_AUTHCOOKIE_JSESSIONIDは使用されず、かわりにFOOAPPIDと_WL_AUTHCOOKIE_FOOAPPIDが使用されます。以上を表3-1にまとめます。

表3-1 WebLogic ServerのCookie

デプロイメント記述子でのユーザー指定

HTTPセッション

HTTPSセッション

いいえ - デフォルトのJSESSIONIDを使用します

JSESSIONID

_WL_AUTHCOOKIE_JSESSIONID

はい - FOOAPPIDとして指定されます

FOOAPPID

_WL_AUTHCOOKIE_FOOAPPID

セキュアなWebアプリケーションの開発

WebLogic Serverは、Webブラウザに関して以下の3タイプの認証をサポートしています。

- BASIC

- FORM

- CLIENT-CERT

以下の節では、これらのタイプの認証を使用する様々な方法を紹介します。

- BASIC認証Webアプリケーションの開発

- リソースが非セキュアな場合のBASIC認証について

- FORM認証Webアプリケーションの開発

- Webアプリケーションの認証にIDアサーションの使用

- Webアプリケーションの認証に双方向SSLの使用

- 認証方式に対するフォールバック・メカニズムの提供

- Swingベース認証Webアプリケーションの開発

- Webアプリケーションのデプロイメント

BASIC認証Webアプリケーションの開発

BASIC認証の場合、WebブラウザはWebLogicリソースのリクエストに応じてログイン画面を表示します。そのログイン画面は、ユーザー名とパスワードの入力をユーザーに要求します。図3-2は典型的なログイン画面を示します。

図3-2 認証のログイン画面

「図3-2 認証のログイン画面」の説明

注意:

非セキュアなリソースの処理に関する重要な情報については、「リソースが非セキュアな場合のBASIC認証について」を参照してください。

BASIC認証を提供するWebアプリケーションを開発するには、次の手順を実行します。

1. web.xmlデプロイメント記述子を作成します。このファイルには、以下の情報を含めます(例3-1を参照)。

1. ウェルカム・ファイルを定義します。ウェルカム・ファイルの名前はwelcome.jspです。

2. 保護する予定のWebアプリケーション・リソース、つまりURLリソースの各セットについてセキュリティ制約を定義します。リソースの各セットは共通のURLを共有します。HTMLページ、JSP、サーブレットなどは最も一般的に保護されるURLリソースですが、他のタイプのURLリソースもサポートされています。例3-1では、URLパターンはWebアプリケーションの最上位ディレクトリに位置するwelcome.jspファイルを指しており、URLリソースへのアクセスが許可されるHTTPメソッドはPOSTとGET、セキュリティ・ロール名はwebuserとなっています。

注意:

セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。

- セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken)。

- スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。

- セキュリティ・ロール名では大文字と小文字が区別されます。

- 推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。

3. <login-config>タグを使用して、使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。例3-1では、BASICタイプが指定されており、レルムはデフォルトのレルムとなっています。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。

4. 1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロールwebuserのみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています(例3-1の<security-role>を参照)。ただし、セキュリティ・ロールは必要なだけ定義できます。

例3-1 BASIC認証のweb.xmlファイル

<?xml version='1.0' encoding='UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/welcome.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webuser</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>webuser</role-name>
</security-role>
</web-app>

2. weblogic.xmlデプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。例3-2は、weblogic.xmlファイルの<security-role>タグで定義されているwebuserセキュリティ・ロールをmyGroupというグループにマップするサンプルweblogic.xmlファイルです。プリンシパルは、ユーザーにもグループにもできるため、<principal-tag>はどちらにも使用できます。この構成の場合、WebLogic ServerはmyGroupユーザーのみに、保護されたURLリソースwelcome.jspへのアクセスを許可します。

注意:

バージョン9.0からは、ロール・マッピングのデフォルト動作によって、weblogic.xmlに何も指定されていないと空のロール・マッピングが作成されるようになりました。バージョン8.xではweblogic.xmlファイルを含めなかった場合や、ファイルを含めたがすべてのセキュリティ・ロールのマッピングは含めなかった場合、マップされていないセキュリティ・ロールはすべて、デフォルトで、ロール名に一致する名前を持つユーザーまたはグループに設定されていました。ロール・マッピングの動作および下位互換性の設定の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ロール・マッピングの組合せを有効化」設定の理解に関する項を参照してください。

例3-2 BASIC認証のweblogic.xmlファイル

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>

3. ユーザーがユーザー名とパスワードを入力してアクセスが許可されたときに表示される「ようこそ」画面を生成するファイルを作成します。例3-3は、サンプルのwelcome.jspファイルです。図3-3は、「ようこそ」画面を示しています。

例3-3 BASIC認証のwelcome.jspファイル

<html>
<head>
<title>Browser Based Authentication Example Welcome Page</title>
</head>
<h1> Browser Based Authentication Example Welcome Page </h1>
<p> Welcome <%= request.getRemoteUser() %>!
</blockquote>
</body>
</html>

注意:

例3-3において、JSPがログインしたユーザーの名前を取得するためにAPI (request.getRemoteUser())を呼び出していることに留意してください。かわりに、別のAPI (weblogic.security.Security.getCurrentSubject())を使用することもできます。このAPIを使用してユーザーの名前を取得するには、次のようにSubjectUtils APIと共に使用します。

String username = weblogic.security.SubjectUtils.getUsername
weblogic.security.Security.getCurrentSubject());

図3-3 「ようこそ」画面

「図3-3 「ようこそ」画面」の説明

4. WebLogic Serverを起動し、URLリソースにアクセス可能なユーザーおよびグループを定義します。weblogic.xmlファイル(例3-2を参照)では、<principal-nameタグで、welcome.jspにアクセス可能なグループとしてmyGroupが定義されています。したがって、管理コンソールを使用してmyGroupグループを定義し、ユーザーを定義して、そのユーザーをmyGroupグループに追加します。ユーザーとグループの追加の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

5. Webアプリケーションをデプロイし、前の手順で定義したユーザーを使用して保護されたURLリソースにアクセスします。

1. デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。

2. Webブラウザを開き、次のURLを入力します。

http://localhost:7001/basicauth/welcome.jsp

3. ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。

HttpSessionListenerを使用したブラウザによる資格証明のキャッシングの報告

ブラウザはユーザーの資格証明をキャッシュし、それらをサーバーに対して高い頻度で自動的に再送信します。これによって、ログアウトまたはタイムアウト後もWebLogic Serverセッションが破棄されていないように見えます。資格証明は、ブラウザに応じて、現在のブラウザ・セッションでのみキャッシュしたり、複数のセッションにまたがってキャッシュすることができます。

WebLogic Serverのセッションが破棄されたことを確認するには、javax.servlet.http.HttpSessionListenerインタフェースを実装するクラスを作成します。このインタフェースを実装すると、Webアプリケーションにおけるアクティブ・セッションのリストへの変更が通知されます。通知イベントを取得するには、対象Webアプリケーションについて、web.xmlのデプロイメント記述子で実装クラスを構成する必要があります。

セッション・リスナー・クラスを構成するには:

1. セッション・リスナー・クラスを作成するWebアプリケーションのweb.xmlデプロイメント記述子をテキスト・エディタで開きます。web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。

2. web.xmlデプロイメント記述子のlistener要素を使用してイベント宣言を追加します。イベント宣言は、イベントが発生するときに起動されるイベント・リスナー・クラスを定義します。例:

<listener>
<listener-class>myApp.MySessionListener</listener-class>
</listener>

詳細およびガイドラインは、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のイベント・リスナー・クラスの構成に関する項を参照してください。

セッション・リスナー・クラスを作成し、デプロイします。例3-4のサンプルでは、単純なカウンタを使用してセッション数をトラッキングしています。

例3-4 セッション数のトラッキング

package myApp;
import javax.servlet.http.HttpSessionListener;
import javax.servlet.http.HttpSessionEvent;
public class MySessionListener implements HttpSessionListener {
private static int sessionCount = 0;

public void sessionCreated(HttpSessionEvent se) {
sessionCount++;
// Write to a log or do some other processing.
}
public void sessionDestroyed(HttpSessionEvent se) {
if(sessionCount > 0)
sessionCount--;
//Write to a log or do some other processing.
}
}

リソースが非セキュアな場合のBASIC認証について

WebLogic Serverバージョン9.2以降では、ターゲット・リソースにおいてアクセス制御が有効になっていない場合でも、HTTP BASIC認証を使用するクライアント・リクエストはWebLogic Server認証を通過しなければなりません。

この動作は、セキュリティ構成MBeanフラグenforce-valid-basic-auth-credentialsで指定します。(DomainMBeanを使用すると、そのドメインの新しいセキュリティ構成MBeanを取得できます)。このフラグは、非セキュアなリソースへのアクセスにおいて、無効なHTTP BASIC認証資格証明によるリクエストを許可するかどうかを指定します。

注意:

セキュリティ構成MBeanは、ドメイン全体のセキュリティ構成情報を提供します。enforce-valid-basic-auth-credentialsフラグは、ドメイン全体に影響します。

デフォルトでは、enforce-valid-basic-auth-credentialsフラグはtrueに設定されており、WebLogic Server認証が実行されます。認証に失敗すると、リクエストは拒否されます。したがって、ユーザーおよびパスワードの情報がWebLogic Serverに保持されている必要があります。

別の認証メカニズムを使用する場合のように、このデフォルトの動作を変更したい場合もあります。たとえば、バックエンドのWebサービスを使用してクライアントを認証する場合は、ユーザー情報をWebLogic Serverに保持する必要はありません。ただし、デフォルトの認証実施が有効になっている場合は、先にWebLogic Server認証に成功していないと、Webサービス独自の認証を実行することできません。

enforce-valid-basic-auth-credentialsフラグを明示的にfalseに設定すると、ターゲット・リソースでのアクセス制御が有効になっていないHTTP BASIC認証クライアント・リクエストのWebLogic Server認証は実行されません。

先に挙げたバックエンドWebサービスでクライアントを認証する例であれば、WebLogic Serverにユーザーに関する情報が保持されていなくても、Webサービス独自の認証を実行できます。

enforce-valid-basic-auth-credentialsフラグの設定

enforce-valid-basic-auth-credentialsフラグを設定するには、次の手順に従います。

1. config.xmlの<security-configuration>要素内に<enforce-valid-basic-auth-credentials>要素を追加します。

:
<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials>
</security-configuration>

2. ドメイン内のすべてのサーバーを起動または再起動します。

WLSTを使用してenforce-valid-basic-auth-credentialsの値を確認する

enforce-valid-basic-auth-credentialsフラグの設定は、管理コンソールには表示されません。しかし、WLSTを使用すると、実行中のサーバーでの値を確認できます。enforce-valid-basic-auth-credentialsがドメイン全体の設定である点には注意してください。

例3-5に実行中のサンプル・サーバーでenforce-valid-basic-auth-credentialsの値を確認するためのWLSTセッションを示します。

例3-5 enforce-valid-basic-auth-credentialsの値の確認

wls:/offline> connect('weblogic','weblogic','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'examplesServer' that belongs to domain '
wl_server'.
wls:/wl_server/serverConfig> cd('SecurityConfiguration')

wls:/wl_server/serverConfig/SecurityConfiguration> ls()
dr--   wl_server
wls:/wl_server/serverConfig/SecurityConfiguration> cd('wl_server')
wls:/wl_server/serverConfig/SecurityConfiguration/wl_server> ls()
dr--   DefaultRealm
dr--   Realms
-r--   AnonymousAdminLookupEnabled                  false
-r--   CompatibilityConnectionFiltersEnabled        false
-r--   ConnectionFilter                             null
-r--   ConnectionFilterRules                        null
-r--   ConnectionLoggerEnabled                      false
-r--   ConsoleFullDelegationEnabled                 false
-r--   Credential                                   ******
-r--   CredentialEncrypted                          ******
-r--   CrossDomainSecurityEnabled                   false
-r--   DowngradeUntrustedPrincipals                 false
-r--   EnforceStrictURLPattern                      true
-r--   EnforceValidBasicAuthCredentials             false
:
:

FORM認証Webアプリケーションの開発

WebアプリケーションでFORM認証を使用する場合は、Webアプリケーション・リソースのリクエストに応じてWebブラウザが表示するカスタム・ログイン画面とログインが失敗した場合に表示されるエラー画面を用意します。ログイン画面はHTMLページ、JSP、またはサーブレットを使用して生成できます。フォームベースのログインのメリットは、これらの画面を完全に管理できるので、アプリケーションやエンタープライズ・ポリシー/ガイドラインの要件にあわせてそれらを設計できることです。

そのログイン画面は、ユーザー名とパスワードの入力をユーザーに要求します。図3-4は、JSPを使用して生成される典型的なログイン画面を、例3-6はソース・コードを示しています。

図3-4 フォームベースのログイン画面(login.jsp)

「図3-4 フォームベースのログイン画面(login.jsp)」の説明

例3-6 フォーム-ベースのログイン画面(login.jsp)のソース・コード

<html>
<head>)
<title>Security WebApp login page</title>
</head>
<body bgcolor="#cccccc">
<blockquote>
<img src=Button_Final_web.gif align=right>
<h2>Please enter your user name and password:</h2>
<p>
<form method="POST" action="j_security_check">
<table border=1>
<tr>
<td>Username:</td>
<td><input type="text" name="j_username"></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="j_password"></td>
</tr>
<tr>
<td colspan=2 align=right><input type=submit
value="Submit"></td>
</tr>
</table>
</form>
</blockquote>
</body>
</html>

図3-5は、HTMLを使用して生成される典型的なログイン・エラー画面を、例3-7はソース・コードを示しています。

図3-5 ログイン・エラー画面

「図3-5 ログイン・エラー画面」の説明

例3-7 ログイン・エラー画面のソース・コード

<html>
<head>
<title>Login failed</title>
</head>
<body bgcolor=#ffffff>
<blockquote>
<img src=/security/Button_Final_web.gif align=right>
<h2>Sorry, your user name and password were not recognized.</h2>
<p><b>
<a href="/security/welcome.jsp">Return to welcome page</a> or
<a href="/security/logout.jsp">logout</a>
</b>
</blockquote>
</body>
</html>

FORM認証を提供するWebアプリケーションを開発するには、次の手順を実行します。

1. web.xmlデプロイメント記述子を作成します。このファイルには、以下の情報を含めます(例3-8を参照)。

1. ウェルカム・ファイルを定義します。ウェルカム・ファイルの名前はwelcome.jspです。

2. 保護する予定のURLリソースの各セットについてセキュリティ制約を定義します。URLリソースの各セットは共通のURLを共有します。HTMLページ、JSP、サーブレットなどは最も一般的に保護されるURLリソースですが、他のタイプのURLリソースもサポートされています。例3-8では、URLパターンは/admin/edit.jspを指しており(したがって、Webアプリケーションのadminサブディレクトリに配置されたedit.jspファイルが保護されます)、URLリソースへのアクセスが許可されるHTTPメソッド(GET)が定義され、セキュリティ・ロール名adminが定義されています。

注意:

セキュリティ・ロール名でハイフンは使用しないでください。ハイフンのあるセキュリティ・ロール名は管理コンソールで修正できません。また、推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。

3. 使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。この場合は、FORMタイプが指定されており、レルムは指定されていないのでデフォルトのレルムになります。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。

4. 1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロールadminのみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています。ただし、セキュリティ・ロールは必要なだけ定義できます。

例3-8 FORM認証のweb.xmlファイル

<?xml version='1.0' encoding='UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>AdminPages</web-resource-name>
<description>
These pages are only accessible by authorized
administrators.
</description>
<url-pattern>/admin/edit.jsp</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>
These are the roles who have access.
</description>
<role-name>
admin
</role-name>
</auth-constraint>
<user-data-constraint>
<description>
This is how the user data must be transmitted.
</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/fail_login.html</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description>
An administrator
</description>
<role-name>
admin
</role-name>
</security-role>
</web-app>

2. weblogic.xmlデプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。例3-9は、web.xmlファイルの<security-role>タグで定義されているadminセキュリティ・ロールをsupportGroupというグループにマップするサンプルweblogic.xmlファイルです。この構成の場合、WebLogic ServerはsupportGroupグループのユーザーのみに、保護されたWebLogicリソースへのアクセスを許可します。ただし、管理コンソールを使用すると、他のグループも保護されたWebLogicリソースへのアクセスが許可されるようにWebアプリケーションのセキュリティ・ロールを修正できます。

例3-9 FORM認証のweblogic.xmlファイル

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<weblogic-web-app>
<security-role-assignment>
<role-name>admin</role-name>
<principal-name>supportGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>

3. ユーザーがURLを入力して保護されたWebアプリケーション・リソースをリクエストしたときに「ようこそ」画面を生成するWebアプリケーション・ファイルを作成します。例3-10は、サンプルのwelcome.jspファイルです。図3-3は、「ようこそ」画面を示しています。

例3-10 FORM認証のwelcome.jspファイル

<html>
<head>
<title>Security login example</title>
</head>
<%
String bgcolor;
if ((bgcolor=(String)application.getAttribute("Background")) ==
null)
{
bgcolor="#cccccc";
}
%>
<body bgcolor=<%="\""+bgcolor+"\""%>>
<blockquote>
<img src=Button_Final_web.gif align=right>
<h1> Security Login Example </h1>
<p> Welcome <%= request.getRemoteUser() %>!
<p> If you are an administrator, you can configure the background
color of the Web Application.
<br> <b><a href="admin/edit.jsp">Configure background</a></b>.
<% if (request.getRemoteUser() != null) { %>
<p> Click here to <a href="logout.jsp">logout</a>.
<% } %>
</blockquote>
</body>
</html>

注意:

例3-3において、JSPがログインしたユーザーの名前を取得するためにAPI (request.getRemoteUser())を呼び出していることに留意してください。かわりに、別のAPI (weblogic.security.Security.getCurrentSubject())を使用することもできます。このAPIを使用してユーザーの名前を取得するには、次のようにSubjectUtils APIと共に使用します。

String username = weblogic.security.SubjectUtils.getUsername
weblogic.security.Security.getCurrentSubject());

4. WebLogic Serverを起動し、URLリソースにアクセス可能なユーザーおよびグループを定義します。weblogic.xmlファイル(例3-9を参照)では、<role-nameタグでadminがedit.jspファイルにアクセス可能なグループとして定義され、ユーザーjoeがそのグループのメンバーとして定義されています。したがって、管理コンソールを使用してadminグループを定義し、ユーザーjoeを定義して、joeをadminグループに追加します。他のユーザーを定義してグループに追加することもでき、その追加ユーザーも保護されたWebLogicリソースにアクセスすることができます。ユーザーとグループの追加の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

5. Webアプリケーションをデプロイし、前の手順で定義したユーザーを使用して保護されたWebアプリケーション・リソースにアクセスします。

1. デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。

2. Webブラウザを開き、次のURLを入力します。

http://hostname:7001/security/welcome.jsp

3. ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。

Webアプリケーションの認証にIDアサーションの使用

WebアプリケーションでIDアサーションを使用すると、認証を目的としてクライアントのIDを検証できます。IDアサーションを使用するときには、以下の要件を満たす必要があります。

1. 認証のタイプはCLIENT-CERTに設定する必要があります。

2. サーバーにIDアサーション・プロバイダが構成されている必要があります。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストする場合、WebLogic ServerはWebブラウザまたはJavaクライアントがIDを持つことを要求します。WebLogic IDアサーション・プロバイダは、WebブラウザまたはJavaクライアントからのトークンをWebLogic Serverセキュリティ・レルムのユーザーにマップします。IDアサーション・プロバイダの構成方法の詳細は、『Oracle WebLogic Serverの保護』のIDアサーション・プロバイダの構成に関する項を参照してください。

3. トークンの値に対応するユーザーは、サーバーのセキュリティ・レルムで定義されていなければなりません。定義されていない場合、クライアントは保護されているWebLogicリソースにアクセスできません。サーバーにおけるユーザーの構成の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

Webアプリケーションの認証に双方向SSLの使用

Webアプリケーションで双方向SSLを使用すると、クライアントが、それがそうであると主張するクライアントであることを検証できます。双方向SSLを使用するときには、以下の要件を満たす必要があります。

1. 認証のタイプはCLIENT-CERTに設定する必要があります。

2. サーバーは、双方向SSLに合せて構成する必要があります。SSLとデジタル証明書の使用の詳細は、第5章「JavaクライアントでのSSL認証の使用」を参照してください。サーバーにおけるSSLの構成の詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

3. クライアントは、サーバーのWebアプリケーションにアクセスするためにHTTPSを使用する必要があります。

4. サーバーにIDアサーション・プロバイダが構成されている必要があります。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストする場合、WebLogic ServerはWebブラウザまたはJavaクライアントがIDを持つことを要求します。WebLogic IDアサーション・プロバイダを使用すると、WebブラウザまたはJavaクライアントのデジタル証明書をWebLogic Serverセキュリティ・レルム内のユーザーにマップするユーザー名マッパーをサーバーで使用できます。セキュリティ・プロバイダの構成方法の詳細は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項を参照してください。

5. クライアントのデジタル証明書のSubject's Distinguished Name (SubjectDN)属性に対応するユーザーは、サーバーのセキュリティ・レルムで定義されている必要があります。定義されていないと、クライアントには保護されたWebLogicリソースへのアクセスが許可されません。サーバーにおけるユーザーの構成の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

注意:

SSL認証を使用する場合、サーバーのSSL構成を管理コンソールで指定するので、web.xmlおよびweblogic.xmlファイルを使用してサーバーの構成を指定する必要はありません。

認証方式に対するフォールバック・メカニズムの提供

Servlet 3.0仕様(http://jcp.org/en/jsr/detail?id=315)では、Webアプリケーションで使用する認証方法(BASIC、FORM、その他)を定義できます。WebLogic Serverはauth-methodセキュリティ・モジュールを提供しています。このモジュールを使用すると、複数の認証方式を(カンマ区切りのリストとして)定義できるため、コンテナはフォールバック・メカニズムを提供できます。認証は、auth-methodリストで値が定義されている順序で試行されます。

たとえば、web.xmlファイルのlogin-config要素に次のauth-methodリストを定義できます。

<login-config>
<auth-method>CLIENT-CERT,BASIC</auth-method>
</login-config>

コンテナは最初に、CLIENT-CERT値を確認して認証を試みます。これに失敗すると、コンテナはBASIC認証のユーザー・エージェントを再試行します。

FORMまたはBASICのいずれかが構成される場合、これらはユーザーとの往復の対話が必要なため、リストの最後に指定する必要があります。ただし、FORMとBASICの両方をauth-method値のリスト内に一緒に指定することはできません。

構成

auth-method認証のセキュリティは、以下の2つの方法で構成できます。

- web.xmlファイルのlogin-config要素にauth-method値をカンマ区切りのリストとして定義します。

- auth-method値をRealmMBean上でカンマ区切りのリストとして定義し、web.xmlのlogin-config要素でREALM値を使用します(このようにすると、Webアプリケーションはセキュリティ・レルムから認証方式を取得します)。

WebLogic Java Management Extensions (JMX)を使用すると、RealmMBeanにアクセスしてセキュリティ・リソースを作成および管理できます。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。

Swingベース認証Webアプリケーションの開発

Webブラウザでは、JFC (Java Foundation Classes)のSwingコンポーネントを使用して開発されたグラフィカル・ユーザー・インタフェース(GUI)を操作することもできます。

Swingコンポーネントを使用してアプリケーションおよびアプレットのGUI (グラフィカル・ユーザー・インタフェース)を作成する方法については、JFC/SwingによるGUIの作成のチュートリアル(Swingチュートリアルともいいます)を参照してください。このチュートリアルは、Web(http://download.oracle.com/javase/tutorial/uiswing/)で入手できます。

SwingベースのGUIを開発したら、「FORM認証Webアプリケーションの開発」を参照し、Swingベースの画面を使用して、FORM認証を提供するWebアプリケーションの開発に必要な手順を実行します。

注意:

SwingベースのGUIを開発する場合、swingイベント・スレッドの子スレッドにJava仮想マシン全体のユーザーを使用しないでください。これはJava EEに準拠していないので、通常はシン・クライアントやIIOPでは動作しません。かわりに、以下のいずれかの方法を用います。

- Swingアーティファクトの前にInitialContextを作成します。

- または、Java Authentication and Authorization Service (JAAS)を使用してログインしてから、Swingイベント・スレッドとその子でSecurity.runAs()メソッドを使用します。

Webアプリケーションのデプロイメント

開発モードで動作しているサーバーにWebアプリケーションをデプロイするには、次の手順を実行します。

注意:

開発モードまたは本番モードでのWebアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。

1. Webアプリケーションのファイルのディレクトリ構造を構築します。図3-6は、basicauthというWebアプリケーションのディレクトリ構造を示しています。最上位ディレクトリにはWebアプリケーションの名前を割り当て、サブディレクトリはWEB-INFという名前にする必要があります。

図3-6 Basicauth Webアプリケーションのディレクトリ構造

「図3-6 Basicauth Webアプリケーションのディレクトリ構造」の説明

2. 展開ディレクトリ形式、つまりJavaアーカイブ(jar)ではない形式のアプリケーションをデプロイするには、ただ単純にディレクトリをサーバー上のapplicationsディレクトリに移動します。たとえば、basicauth Webアプリケーションは次の位置にデプロイします。

WL_HOME\user_projects\domains\mydomain\applications\basicauth

WebLogic Serverインスタンスが動作している場合、アプリケーションは自動デプロイされるはずです。管理コンソールを使用すると、アプリケーションがデプロイされたことを確認できます。

WebLogic Serverインスタンスが動作していない場合は、サーバーを起動するとアプリケーションは自動デプロイされます。

3. まだしていない場合は、管理コンソールを使用して、Webアプリケーションにアクセスできるユーザーおよびグループを構成します。保護されたWebLogicリソースへのアクセスを許可されるユーザーおよびグループを判別するには、weblogic.xmlファイルを調べます。たとえば、basicauthサンプルのweblogic.xmlファイル(例3-2)では、myGroupがwelcome.jspファイルにアクセスできる唯一のグループとして定義されています。

セキュアなWebアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。

Webアプリケーションでの宣言によるセキュリティの使用

宣言によるセキュリティは、以下の3つの方法で実装できます。

1. 管理コンソールを介したセキュリティ・プロバイダ: 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明されています。

2. JACC (Java Authorization Contract for Containers): 「Java Authorization Contract for Containersの使用」で説明されています。

3. デプロイメント記述子 - この項で説明します。

これら3つのうちどの方法を使用するかは、JACCフラグとセキュリティ・モデルによって定義されます。(セキュリティ・モデルについては、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。)

Webアプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子(web.xmlおよびweblogic.xml)を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット・コンテナがセキュリティ定義を使って、要件を実施します。デプロイメント記述子の使い方については、「セキュアなWebアプリケーションの開発」を参照してください。

デプロイメント記述子およびexternally-defined要素を使用してWebアプリケーションのセキュリティを宣言によって構成する方法については、「externally-defined」を参照してください。

管理コンソールを使用してWebアプリケーションのセキュリティを構成する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

Webアプリケーションのセキュリティ関連のデプロイメント記述子

以下のトピックでは、Webアプリケーションのセキュリティ要件を定義するためにweb.xmlおよびweblogic.xmlファイルで使用されるデプロイメント記述子の要素について説明します。

- web.xmlデプロイメント記述子

- weblogic.xmlデプロイメント記述子

web.xmlデプロイメント記述子

以下のweb.xmlのセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。

- auth-constraint

- security-constraint

- security-role

- security-role-ref

- user-data-constraint

- web-resource-collection

auth-constraint

省略可能なauth-constraint要素では、このセキュリティ制約で定義されたWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。

注意:

auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含むuser-data-constraint要素でも保護する必要があります。

INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。

「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID Cookieの2つが使用されます。

次の表では、auth-constraint要素内で定義できる要素について説明します。

表3-2 auth-constraint要素

要素

必須/省略可能

説明

<description>

省略可能

このセキュリティ制約の説明文。

<role-name>

省略可能

この<security-constraint>で定義されたリソースにアクセスできるセキュリティ・ロールを定義します。セキュリティ・ロール名は、<security-role-ref>要素を使用してプリンシパルにマップされます。security-role-refを参照してください。

使用される場所

auth-constraint要素は、security-constraint要素内で使用されます。

例

web.xmlファイルでauth-constraint要素を使用する例については、例3-11を参照してください。

security-constraint

security-constraint要素は、web-resource-collection要素で定義されたリソースの集合へのアクセス権限を定義するためにweb.xmlファイルで使用されます。

注意:

auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含むuser-data-constraint要素でも保護する必要があります。

INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。

「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID Cookieの2つが使用されます。

次の表では、security-constraint要素内で定義できる要素について説明します。

表3-3 security-constraint要素

要素

必須/省略可能

説明

<web-resource-collection>

必須

このセキュリティ制約が適用されるWebアプリケーションのコンポーネントを定義します。詳細については、以下を参照。web-resource-collection

<auth-constraint>

省略可能

このセキュリティ制約で定義されるWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。詳細については、「auth-constraint」を参照してください。

<user-data-constraint>

省略可能

クライアントとサーバー間でやり取りされるデータの保護方法を定義します。詳細については、user-data-constraintを参照してください。

例

例3-11は、security-constraint要素を使用して、web.xmlでSecureOrdersEastリソースのセキュリティを定義する方法を示しています。

例3-11 セキュリティ制約の例

web.xml entries:
<security-constraint>
<web-resource-collection>
<web-resource-name>SecureOrdersEast</web-resource-name>
<description>
Security constraint for
resources in the orders/east directory
</description>
<url-pattern>/orders/east/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>
constraint for east coast sales
</description>
<role-name>east</role-name>
<role-name>manager</role-name>
</auth-constraint>
<user-data-constraint>
<description>SSL not required</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
...

security-role

security-role要素には、セキュリティ・ロールの定義が指定されます。定義は、セキュリティ・ロールの説明(オプション)とセキュリティ・ロール名から成ります。

次の表では、security-role要素内で定義できる要素について説明します。

表3-4 security-role要素

要素

必須/省略可能

説明

<description>

省略可能

セキュリティ・ロールの説明文。

<role-name>

必須

ロール名。ここで使用する名前は、WebLogic固有のデプロイメント記述子weblogic.xmlに対応するエントリが必要になります。weblogic.xmlによって、ロールはセキュリティ・レルムにあるプリンシパルにマップされます。詳細については、「security-role-assignment」を参照。

例

web.xmlファイルでsecurity-role要素を使用する例については、例3-14を参照してください。

security-role-ref

security-role-ref要素は<security-role>で定義されたセキュリティ・ロール名を、サーブレットのロジックでハード・コード化される代替ロール名にリンクします。この特別な抽象化レイヤーによって、サーブレット・コードを変更しなくてもデプロイメント時にサーブレットを構成できるようになります。

次の表では、security-role-ref要素内で定義できる要素について説明します。

表3-5 security-role-ref要素

要素

必須/省略可能

説明

<description>

省略可能

ロールの説明文。

<role-name>

必須

サーブレット・コード内で使用されるセキュリティ・ロールまたはプリンシパルの名前を定義します。

<role-link>

必須

後にデプロイメント記述子内の<security-role>要素で定義されるセキュリティ・ロールの名前を定義します。

例

web.xmlでsecurity-role-ref要素を使用する例については、例3-17を参照してください。

user-data-constraint

user-data-constraint要素は、クライアントとサーバー間でやり取りされるデータの保護方法を定義します。

注意:

auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含むuser-data-constraint要素でも保護する必要があります。

INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。

「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID Cookieの2つが使用されます。

次の表では、user-data-constraint要素内で定義できる要素について説明します。

表3-6 user-data-constraint要素

要素

必須/省略可能

説明

<description>

省略可能

説明文。

<transport-guarantee>

必須

クライアントとサーバー間でやり取りされるデータのセキュリティ要件を指定します。

指定できる値:

- NONE - トランスポートの保証が不要な場合に指定します。

- INTEGRAL - クライアントとサーバーの間で、転送中にデータが変更されない方法でデータを転送する必要がある場合に指定します。

- CONFIDENTIAL - 転送中にデータの中味を覗かれないようにデータを転送する必要がある場合に指定します。

INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。

使用される場所

user-data-constraint要素は、security-constraint要素内で使用されます。

例

web.xmlファイルでuser-data-constraint要素を使用する例については、例3-11を参照してください。

web-resource-collection

web-resource-collection要素は、セキュリティ制約を適用するWebアプリケーションのリソースおよびHTTPメソッドのサブセットを識別するために使用します。HTTPメソッドが指定されていない場合、セキュリティ制約はすべてのHTTPメソッドに適用されます。

次の表では、web-resource-collection要素内で定義できる要素について説明します。

表3-7 web-resource-collection要素

要素

必須/省略可能

説明

<web-resource-name>

必須

Webリソースの集合の名前。

<description>

省略可能

Webリソースの説明文。

<url-pattern>

必須

Webリソースの集合のマッピング、つまり場所。

URLパターンには、Javaサーブレット仕様(http://jcp.org/en/jsr/detail?id=315)に定義されている構文を使用する必要があります。

パターン<url-pattern>/</url-pattern>では、Webアプリケーション全体にセキュリティ制約が適用されます。

<http-method>

省略可能

クライアントがWebリソースの集合にアクセスしようとするときにセキュリティ制約を適用するHTTPメソッド。HTTPメソッドが指定されていない場合、セキュリティ制約はすべてのHTTPメソッドに適用されます。

ここでHTTPメソッドを指定した場合、セキュリティ制約の範囲が制限されます。HTTPメソッドを特に指定する必要がある場合を除き、セキュリティ上の理由からこの要素は設定しないでください。

使用される場所

web-resource-collection要素は、security-constraint要素内で使用されます。

例

web.xmlファイルでweb-resource-collection要素を使用する例については、例3-11を参照してください。

weblogic.xmlデプロイメント記述子

以下のweblogic.xmlのセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。

- externally-defined

- run-as-principal-name

- run-as-role-assignment

- security-permission

- security-permission-spec

- security-role-assignment

weblogic.xmlデプロイメント記述子の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のXMLデプロイメント記述子に関する項を参照してください。

weblogic.xml要素の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。

externally-defined

externally-defined要素を使用すると、web.xmlデプロイメント記述子のrole-name要素によって定義されたセキュリティ・ロールが管理コンソールで指定したマッピングを使用するよう指定できます。この要素を使用することで、特定のWebアプリケーションのデプロイメント記述子に定義されたセキュリティ・ロールごとに特定のセキュリティ・ロール・マッピングを指定する必要がなくなります。このため、同じセキュリティ・レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、管理コンソールを使用して他のアプリケーションのセキュリティを指定および変更できます。

サーバーのロール・マッピングの動作は、管理コンソールでどのセキュリティ・デプロイメント・モデルを選択したかによって異なります。セキュリティ・デプロイメント・モデルの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。

注意:

セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。

- セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken)。

- スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。

- セキュリティ・ロール名では大文字と小文字が区別されます。

- 推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。

使用される場所

externally-defined要素は、security-role-assignment要素内で使用されます。

例

例3-12と例3-13は、weblogic.xmlファイルでexternally-defined要素を使用する方法を比較して示しています。例3-13で、weblogic.xml内の「webuser」のexternally-defined要素は、セキュリティがgetReceiptsメソッドにおいて正しく構成されるには管理コンソールでwebuserに対応するプリンシパルが作成される必要がある、ということを意味します。

注意:

大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。

例3-12 web.xmlファイルとweblogic.xmlファイルを使用したセキュリティ・ロールとプリンシパルのセキュリティ・レルムへのマッピング

web.xml entries:
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
<weblogic.xml entries:
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Mary</principal-name>
</security-role-assignment>
</weblogic-web-app>

例3-13 Webアプリケーションのデプロイメント記述子でのexternally-definedタグの使用

web.xml entries:
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
<weblogic.xml entries:
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<externally-defined/>
</security-role-assignment>

管理コンソールを使用してWebアプリケーションのセキュリティを構成する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

run-as-principal-name

run-as-principal-name要素では、対応するweb.xmlファイルのrun-as要素で定義されるセキュリティ・ロールに使用するプリンシパル名を指定します。

使用される場所

run-as-principal-name要素は、run-as-role-assignment要素内で使用されます。

例

run-as-principal-name要素を使用する例については、例3-14を参照してください。

run-as-role-assignment

run-as-role-assignment要素は、対応するweb.xmlファイルのrole-name要素で定義されるロール名をシステム内の有効なユーザー名にマップします。この値は、servlet-descriptorのrun-as-principal-name要素によって任意のサーブレットについてオーバーライドできます。ロール名のrun-as-role-assignment要素がない場合は、security-role-assignment要素に定義されている最初のprincipal-nameをWebアプリケーション・コンテナが選択します。

次の表では、run-as-role-assignment要素内で定義できる要素について説明します。

表3-8 run-as-role-assignment要素

要素

必須/省略可能

説明

<role-name>

必須

対応するweb.xmlファイルのrun-as要素で指定されるセキュリティ・ロール名を指定します。

<run-as-principal-name>

必須

対応するweb.xmlファイルのrun-as要素で指定されるセキュリティ・ロール名に対するプリンシパルを指定します。

例

例3-14は、run-as-role-assignment要素を使用して、SnoopServletを常にユーザーjoeとして実行させる方法を示しています。

例3-14 run-as-role-assignment要素の例

web.xml:
<servlet>
<servlet-name>SnoopServlet</servlet-name>
<servlet-class>extra.SnoopServlet</servlet-class>
<run-as>
<role-name>runasrole</role-name>
</run-as>
</servlet>
<security-role>
<role-name>runasrole</role-name>
</security-role>
weblogic.xml:
<weblogic-web-app>
<run-as-role-assignment>
<role-name>runasrole</role-name>
<run-as-principal-name>joe</run-as-principal-name>
</run-as-role-assignment>
</weblogic-web-app>

security-permission

security-permission要素は、Java EE Sandboxと関連するセキュリティ許可を指定します。

例

security-permission要素を使用する例については、例3-15を参照してください。

security-permission-spec

security-permission-spec要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ許可を指定します。セキュリティ許可仕様の実装については、次のURLを参照してください。

http://download.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#FileSyntax

注意:

オプションのcodebaseおよびsignedBy句は無視してください。

使用される場所

security-permission-spec要素は、security-permission要素内で使用されます。

例

例3-15は、security-permission-spec要素を使用して、java.net.SocketPermissionクラスに許可を付与する方法を示しています。

例3-15 security-permission-spec要素の例

<weblogic-web-app>
<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec>
<!--
A single grant statement following the syntax of
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax,
without the "codebase" and "signedBy" clauses, goes here. For example:
-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>
</weblogic-web-app>

例3-15では、permission java.net.SocketPermissionは許可クラス名を、"*"はターゲット名を、resolveはアクション(host/IP名サービスのルックアップを解決する)を示します。

security-role-assignment

security-role-assignment要素は、セキュリティ・ロールとWebLogic Serverセキュリティ・レルムの1つまたは複数のプリンシパルとのマッピングを宣言します。

注意:

エンタープライズ・アプリケーションのweblogic-application.xmlデプロイメント記述子でsecurity-role-assignment要素を使用する方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

例

例3-16は、security-role-assignment要素を使用してプリンシパルをPayrollAdminロールに割り当てる方法を示しています。

注意:

大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。

例3-16 security-role-assignment要素の例

<weblogic-web-app>
<security-role-assignment>
<role-name>PayrollAdmin</role-name>
<principal-name>Tanya</principal-name>
<principal-name>Fred</principal-name>
<principal-name>system</principal-name>
</security-role-assignment>
</weblogic-web-app>

Webアプリケーションでのプログラムによるセキュリティの使用

サーブレットを記述して、そのサーブレット・コードでプログラム的にユーザーとセキュリティ・ロールにアクセスできます。そのためには、サーブレットのコードでjavax.servlet.http.HttpServletRequest.getUserPrincipalおよびjavax.servlet.http.HttpServletRequest.isUserInRole(String role)メソッドを使用します。

getUserPrincipal

getUserPrincipal()メソッドは、Webアプリケーションの現在のユーザーを特定するために使用します。このメソッドは、1ユーザーが存在する場合にWLSUser Principalを返します。WLSUser Principalが複数の場合、このメソッドは、Subject.getPrincipals().iterator()メソッドで指定された順序の1番目を返します。WLSUser Principalが存在しない場合、getUserPrincipal()メソッドはWLSGroup Principal以外の1番目を返します。Principalが存在しない場合、またはすべてのPrincipalがWLSGroup型の場合、このメソッドはnullを返します。この動作は、weblogic.security.SubjectUtils.getUserPrincipal()メソッドのセマンティクスと同じです。

getUserPrincipal()メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。

isUserInRole

javax.servlet.http.HttpServletRequest.isUserInRole(String role)メソッドは、認証されたユーザーが、指定された論理セキュリティ「ロール」を付与されているかどうかを示すブール値を返します。ユーザーが認証されていない場合、このメソッドはfalseを返します。

isUserInRole()メソッドは、セキュリティ・ロールをセキュリティ・レルムのグループ名にマップします。例3-17は、web.xmlファイルでセキュリティ・ロールを定義するために<servlet>要素と一緒に使用される要素を示しています。

例3-17 isUserInRoleのweb.xmlおよびweblogic.xmlの要素

Begin web.xml entries:
...
<servlet>
<security-role-ref>
<role-name>user-rolename</role-name>
<role-link>rolename-link</role-link>
</security-role-ref>
</servlet>
<security-role>
<role-name>rolename-link</role-name>
</security-role>
...
Begin weblogic.xml entries:
...
<security-role-assignment>
<role-name>rolename-link</role-name>
<principal-name>groupname</principal>
<principal-name>username</principal>
</security-role-assignment>
...

文字列roleは、web.xmlデプロイメント記述子の<servlet>宣言の<security-role-ref>要素の中にネストされた<role-name>要素で提供される名前にマップされます。<role-name>要素は、サーブレット・コードで使用されるセキュリティ・ロールまたはprincipal(ユーザーまたはグループ)の名前を定義します。<role-link>要素は、weblogic.xmlデプロイメント記述子の<security-role-assignment>要素で定義された<role-name>に対応します。

注意:

セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。

- セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken)。

- スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。

- セキュリティ・ロール名では大文字と小文字が区別されます。

- 推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。

たとえば、クライアントがmanagerというセキュリティ・ロールのBillというユーザーでログインに成功している場合、次のメソッドはtrueを返します。

request.isUserInRole("manager")

例3-18は例を示しています。

例3-18 セキュリティ・ロール・マッピングの例

Servlet code:
out.println("Is the user a Manager? " +
request.isUserInRole("manager"));
web.xml entries:
<servlet>
. . .
<role-name>manager</role-name>
<role-link>mgr</role-link>
. . .
</servlet>
<security-role>
<role-name>mgr</role-name>
</security-role>
weblogic.xml entries:
<security-role-assignment>
<role-name>mgr</role-name>
<principal-name>bostonManagers</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Ralph</principal-name>
</security-role-ref>

プログラムによる認証APIの使用

一部のアプリケーションでは、プログラムによる認証を使用するのが適切です。

WebLogic Serverは、サーバー側のAPIとしてweblogic.servlet.security.ServletAuthenticationを備えています。このAPIは、サーブレット・アプリケーション内からプログラムによる認証をサポートします。weblogic.servlet.security.ServletAuthentication APIを使用すると、ユーザーを認証してログインできます。

いったんログインが完了すると、標準のメカニズムを使用してログインしたかのように感じられます。

ServletAuthentication APIと一緒にWebLogicが提供するweblogic.security.SimpleCallbackHandlerクラスまたはweblogic.security.URLCallbackHandlerクラスのうちいずれかを使用できます。これらのクラスの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

例3-19は、SimpleCallbackHandlerを使用する例を示しています。例3-20は、URLCallbackHandlerを使用する例を示しています。

例3-19 SimpleCallbackHandlerクラスを使用したプログラムによる認証コードの一部

CallbackHandler handler = new SimpleCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.

例3-20 URLCallbackHandlerクラスを使用したプログラムによる認証コードの一部

CallbackHandler handler = new URLCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.

ログイン時のユーザー・セッションの変更

HttpSessionがサーブレットで生成されると、一意のIDと関連付けられます。ブラウザは、このセッションIDをそのリクエストに付与し、サーバーが再びセッション・データを見つけられるようにする必要があります。

「セッション固定化」と呼ばれる種類の攻撃を回避するには、ログイン時にユーザーのセッションを変更する必要があります。これを実行するには、loginメソッドを呼び出した後、weblogic.servlet.security.ServletAuthenticationのgenerateNewSessionIDメソッドを呼び出します。

generateNewSessionIDメソッドは、現在のすべてのセッション情報IDを完全に別のセッションIDに移動し、当該セッションを新しいIDに関連付けます。

注意:

セッション自体に変更はなく、その識別子のみが変更されます。

レガシー・アプリケーションは、ログイン前後に残っているIDと同一のセッションIDに依存できます。generateNewSessionIDを呼び出すと、このようなアプリケーションが壊れてしまいます。このような依存関係はアプリケーションに構築しないことをお薦めします。ただし、構築する場合またはこの種類のレガシー・アプリケーションを処理する場合は、SSLを使用してアプリケーションに対するすべてのアクセスを保護することをお薦めします。

デフォルトでは、WebLogicコンテナはプログラム以外によるログインのIDを自動的に再生成します。

generateNewSessionID()メソッドに関する追加情報は、ServletAuthenticationを参照してください。

4 JavaクライアントでのJAAS認証の使用

この項では、JavaクライアントでのJAAS認証の使用について説明します。

この節では、以下の内容について説明します。

- JAASとWebLogic Server

- JAAS認証の開発環境

- JAAS認証を使用するクライアント・アプリケーションの作成

- JNDI認証の使い方

- JavaクライアントのJAAS認証サンプル・コード

これらの節で参照するサンプル・コードは、WebLogic Server配布キットの次の場所から入手できます。

SAMPLES_HOME\server\examples\src\examples\security\jaas

jaasディレクトリには、instructions.htmlファイル、antビルド・ファイル、sample_jaas.configファイル、および以下のJavaファイルが含まれています。

- BaseClient.java

- BaseClientConstants.java

- SampleAction.java

- SampleCallbackHandler.java

- SampleClient.java

- TradeResult.java

- TraderBean.java

以降の説明は、実際のサンプルを見ながら読み進めてください。

JAASとWebLogic Server

Java Authentication and Authorization Service (JAAS)は、Java EE Development Kitのセキュリティに対する標準拡張です。JAASでは、ユーザーのIDに基づいてアクセス制御を実行できます。JAASは、JNDI認証メカニズムのかわりとしてWebLogic Serverで提供されています。

WebLogic Serverクライアントは、標準のJAASの認証部分だけを利用します。JAAS LoginContextは、構成されているすべての認証プロバイダのLoginModuleインスタンスを順番どおりに実行し、構成されている各プロバイダの完了ステータスの管理を行います。

Javaクライアントに対してJAAS認証を使用する場合は、次のことに注意してください。

- WebLogic Serverクライアントは認証にJNDIログインまたはJAASログインのいずれも使用できますが、JAASログインのほうが望ましい方法です。

- JAASは認証方式として望ましい選択肢ですが、WebLogic提供のLoginModule(weblogic.security.auth.login.UsernamePasswordLoginModule)はユーザー名とパスワードの認証しかサポートしていません。したがって、クライアントの証明書認証(双方向SSL認証ともいう)ではJNDIを使用します。クライアントの証明書認証にJAASを使用するには、証明書の認証を行うカスタムLoginModuleを記述する必要があります。

注意:

WebLogic Serverクライアントで使用するLoginModuleを自分で作成する場合は、weblogic.security.auth.Authenticate.authenticate()を呼び出してログインを実行するように記述します。

- リモートのJavaクライアントからJAASログインを実行する(つまり、JavaクライアントがWebLogic Serverクライアントではない)場合には、WebLogic提供のLoginModuleをログインの実行に使用できます。ただし、WebLogic提供のLoginModuleを使用せずに自分で作成することを選択した場合は、weblogic.security.auth.Authenticate.authenticate()メソッドを呼び出してログインを実行するように記述する必要があります。

- Security Assertion Markup Language (SAML)などリモートまたは境界のログイン・システムを使用する場合は、weblogic.security.auth.Authenticate.authenticate()を呼び出す必要はありません。WebLogic Serverを使用してログインを実行する場合は、authenticate()メソッドを呼び出すだけで済みます。

注意:

WebLogic Serverは、JAAS認証に対して完全なコンテナ・サポートを提供し、アプリケーション・コードにおけるJAASの認証と認可の完全な使用をサポートしています。

- WebLogic Serverでは、ログインの実行にJAASが呼び出されます。LoginModuleは各認証プロバイダに含まれています。これは、JNDIまたはJAASを介してのJavaクライアントのログインだけでなく、サーブレットのログインについても当てはまります。WebLogic ServerがJAASログオンを実行するために内部で呼び出すメソッドは、weblogic.security.auth.Authentication.authenticate()です。認証クラスを使用する場合、ヘルパー・クラスとしてはweblogic.security.SimpleCallbackHandlerが有用であると考えられます。

- WebLogic ServerはJAAS認可を使用してリソースを保護することはしませんが(WebLogicセキュリティを使用)、アプリケーション・コードでJAAS認可を使用してアプリケーションの独自のリソースを保護することはできます。

JAASの詳細は、JAASドキュメント(http://www.oracle.com/technetwork/java/javase/jaas/index.html)を参照してください。

JAAS認証の開発環境

クライアントがアプリケーション、アプレット、Enterprise JavaBean (EJB)、または認証が必要なサーブレットのどれであるかに関係なく、WebLogic ServerはJAASのクラスを使用して安全かつ確実にそのサーバーに対して認証を行います。JAASは、プラガブル認証モジュール(PAM)フレームワークのJavaバージョンを実装します。このフレームワークにより、アプリケーションは基底の認証技術から独立することができます。このため、PAMフレームワークを利用することで、Javaアプリケーションに修正を加えることなく新しいまたは最新版の認証技術を使用することができます。

WebLogic Serverは、リモートのJavaクライアントの認証および内部の認証でJAASを使用します。したがって、JAASに直に関与する必要があるのは、カスタム認証プロバイダの開発者とJavaクライアント・アプリケーションの開発者だけです。Webブラウザ・クライアントのユーザーまたはコンテナ内のJavaクライアント・アプリケーション(サーブレットからEJBを呼び出すものなど)の開発者は、JAASを直接使用したり、その知識を身につけたりする必要はありません。

注意:

WebLogicクライアントでセキュリティを実装するためには、JavaクライアントでWebLogic Serverソフトウェア配布キットをインストールする必要があります。

この節では、以下の内容について説明します。

- JAAS認証API

- JAASクライアント・アプリケーション・コンポーネント

- WebLogic LoginModule実装

JAAS認証API

WebLogic ServerでJAAS認証を使用するJavaクライアントを実装するには、Java EE アプリケーション・プログラミング・インタフェース(API)とWebLogic APIを組み合せて使用します。

表4-1では、JAAS認証の実装に使用されるJava APIパッケージについて説明します。表4-1の情報はJava APIのドキュメントから取られており、WebLogic Server固有の情報がコメントで追加されています。Java APIの詳細は、http://download.oracle.com/javase/6/docs/api/index.htmlおよびhttp://download.oracle.com/javaee/6/api/のJavadocを参照してください。

表4-1では、JAAS認証の実装に使用されるWebLogic APIについて説明します。詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

表4-1 Java JAAS API

Java JAAS API

説明

javax.security.auth.Subject(http://download.oracle.com/javase/6/docs/api/index.html)

Subjectクラスは、リクエストのソースを表し、個々のユーザーでもグループでも使用できます。Subjectオブジェクトは、サブジェクトのログインが正常に完了した後でのみ作成されます。

javax.security.auth.login.LoginContext(http://download.oracle.com/javase/6/docs/api/index.html)

LoginContextクラスは、Subjectの認証に使用される基本メソッドを記述し、基底の認証テクノロジから独立したアプリケーションを開発する方法を提供します。Configurationでは、特定のアプリケーションで使用する認証テクノロジまたはLoginModuleを指定します。したがって、アプリケーション自体を変更せずに、異なるLoginModuleをアプリケーションに組み込むことができます。

呼出し側は、LoginContextをインスタンス化した後、loginメソッドを呼び出してSubjectを認証します。このloginメソッドは、呼出し側で指定した名前について構成されたLoginModuleの各々からのloginメソッドを呼び出します。

loginメソッドが例外をスローすることなく返れば、認証は総合的に成功したことになります。呼出し側はその後、getSubjectメソッドを呼び出すことによって、新しく認証されたSubjectを取得できます。Subjectと関連付けられたプリンシパルおよび資格証明は、SubjectのgetPrincipals、getPublicCredentials、およびgetPrivateCredentialsメソッドをそれぞれ呼び出すことで取得できます。

Subjectをログアウトさせるには、呼出し側がlogoutメソッドを呼び出します。loginメソッドの場合と同じく、このlogoutメソッドはこのLoginContextについて構成された各LoginModuleに対しlogoutメソッドを呼び出します。

このクラスの実装サンプルについては、例4-3を参照してください。

javax.security.auth.login.Configuration(http://download.oracle.com/javase/6/docs/api/index.html)

これは、アプリケーションにおけるLoginModuleの構成を表す抽象クラスです。Configurationでは、特定のアプリケーションについて、使用するLoginModule、およびLoginModuleを呼び出す順番を指定します。この抽象クラスは、実際の構成を読み取ってロードする実装を提供するようサブクラス化する必要があります。

WebLogic Serverでは、このクラスのかわりにログイン構成ファイルを使用します。サンプルの構成ファイルについては、例4-2を参照してください。デフォルトでは、WebLogic Serverは構成ファイルから読取りを行う構成クラスを使用します。

javax.security.auth.spi.LoginModule(http://download.oracle.com/javase/6/docs/api/index.html)

LoginModuleは、認証テクノロジ・プロバイダによって実装されるインタフェースを記述します。LoginModuleは、特定のタイプの認証を提供するためにアプリケーションに組み込まれます。

アプリケーション開発者はLoginContext APIに書き込み、API認証テクノロジ・プロバイダはLoginModuleインタフェースを実装します。Configurationでは、特定のログイン・アプリケーションで使用するLoginModuleを指定します。したがって、アプリケーション自体を変更せずに、異なるLoginModuleをアプリケーションに組み込むことができます。

注意: WebLogic Serverは、LoginModuleの実装(weblogic.security.auth.login.

UsernamePasswordLoginModuleです)を提供します。WebLogic ServerのJavaクライアントでは、このJAAS認証の実装の使用が望ましいですが、独自のLoginModuleを開発することも可能です。

javax.security.auth.

callback.Callback(http://download.oracle.com/javase/6/docs/api/index.html)

このインタフェースの実装はCallbackHandlerに渡されます。それにより、基底のセキュリティ・サービスは呼出し側アプリケーションと対話して、ユーザー名やパスワードなど特定の認証データを取得したり、エラーや警告メッセージなど特定の情報を表示できるようになります。

Callback実装では、基底のセキュリティ・サービスによってリクエストされた情報の取得または表示は行いません。Callback実装は、単にそのようなリクエストをアプリケーションに渡す手段と、アプリケーションがリクエストされた情報を基底のセキュリティ・サービスに返す手段を提供します。

javax.security.auth.

callback.CallbackHandler(http://download.oracle.com/javase/6/docs/api/index.html)

アプリケーションは、CallbackHandlerを実装し、それを基底のセキュリティ・サービスに渡すことで、それらのサービスがアプリケーションと対話してユーザー名やパスワードなど特定の認証データを取得したり、エラーや警告メッセージなど特定の情報を表示したりできるようにします。

CallbackHandlerは、アプリケーションに依存する形で実装されます。

基底のセキュリティ・サービスは、個々のCallbacksをCallbackHandlerに渡すことによって様々なタイプの情報に対するリクエストを行います。CallbackHandler実装は、渡されたCallbacksに応じて情報を取得したり表示したりする方法を決定します。たとえば、基底のサービスがユーザーを認証するためにユーザー名とパスワードを必要としていれば、NameCallbackおよびPasswordCallbackを使用します。その後、CallbackHandlerは逐次的にユーザー名およびパスワードの入力を求めるか、または単一のウィンドウで両方の入力を求めるかを選択できます。

表4-2 WebLogic JAAS API

WebLogic JAAS API

説明

weblogic.security.auth.Authenticate

ユーザー資格証明の認証に使用される認証クラス。

LoginModuleのWebLogic実装(weblogic.security.auth.login。

UsernamePasswordLoginModule)では、このクラスを使用してユーザーを認証し、PrincipalsをSubjectに追加します。LoginModuleを記述した場合は、同じ目的でこのクラスを使用する必要があります。

weblogic.security.auth.Callback.ContextHandlerCallback

基底のセキュリティ・サービスでは、このクラスを使用してContextHandlerCallbackをインスタンス化し、CallbackHandlerのinvokeCallbackメソッドに渡して、このセキュリティ操作に関係するContextHandlerを取得します。この操作にContextHandlerが関連付けられていない場合は、javax.security.auth.callback.UnsupportedCallbackexceptionがスローされます。

このコールバックによって、ContextHandlerがLoginModule.login()メソッドに渡されます。

weblogic.security.auth.Callback.GroupCallback

基底のセキュリティ・サービスでは、このクラスを使用してGroupCallbackをインスタンス化し、CallbackHandlerのinvokeCallbackメソッドに渡して、グループ情報を取得します。

weblogic.security.auth.Callback.URLCallback

基底のセキュリティ・サービスでは、このクラスを使用してURLCallbackをインスタンス化し、CallbackHandlerのinvokeCallbackメソッドに渡して、URL情報を取得します。

Login Module のWebLogic実装(weblogic.security.auth.login。

UsernamePasswordLoginModule)ではこのクラスを使用します。

注意:アプリケーション開発者は、URL情報の取得にこのクラスを使用すべきではありません。かわりに、weblogic.security.URLCallbackHandlerを使用します。

weblogic.security.Security

このクラスはWebLogic ServerクライアントのrunAsメソッドを実装します。クライアント・アプリケーションは、実行するPrivilegedActionまたはPrivilegedExceptionActionとSubject IDを、runAsメソッドを使用して関連付けます。

サンプルの実装については、例4-5を参照してください。

weblogic.security.URLCallbackHandler

アプリケーション開発者がusername、password、およびURLを返すために使用するクラス。アプリケーション開発者は、このクラスを使用してURLCallbackを処理し、URL情報を取得します。

JAASクライアント・アプリケーション・コンポーネント

JAAS認証クライアント・アプリケーションには、少なくとも以下のコンポーネントが含まれます。

- Javaクライアント
JavaクライアントはLoginContextオブジェクトをインスタンス化し、オブジェクトのlogin()メソッドを呼び出すことでログインを呼び出します。login()メソッドはLoginModule内のメソッドを呼び出して、ログインおよび認証を実行します。

LoginContextはまた、新しい空のjavax.security.auth.Subjectオブジェクト(認証されているユーザーまたはサービスを表す)をインスタンス化し、構成されたLoginModuleを作成し、それをこの新しいSubjectおよびCallbackHandlerで初期化します。

LoginContextは、その後LoginContextのgetSubjectメソッドを呼び出すことで、認証されたサブジェクトを取得します。LoginContextはweblogic.security.Security.runAs()メソッドを使って、ユーザーIDにかわって実行されるPrivilegedActionまたはPrivilegedExceptionActionとSubjectのIDを関連付けます。

- LoginModule
LoginModuleはCallbackHandlerを使用して、ユーザー名およびパスワードを取得し、そのユーザー名とパスワードが要求どおりのものであるかどうかを判別します。

認証に成功すると、LoginModuleは、ユーザーを表すプリンシパルをサブジェクトに格納します。LoginModuleがサブジェクトに格納するプリンシパルはPrincipalのインスタンスであり、java.security.Principalインタフェースを実装するクラスです。

LoginModuleファイルは、ユーザー名およびパスワードの認証や証明書の認証など、様々なタイプの認証を実行するように記述できます。クライアント・アプリケーションに含めるLoginModuleは、1つ(最低要件)でも複数でもかまいません。

注意:

WebLogic ServerアプリケーションでJAAS javax.security.auth.Subject.doAsメソッドを使用する場合、サブジェクトとクライアント・アクションは関連付けられません。doAsメソッドを使用してWebLogic ServerアプリケーションにJava EEセキュリティを実装することは可能ですが、この場合でもSecurity.runAs()メソッドを使用する必要があります。

- Callbackhandler
CallbackHandlerは、javax.security.auth.callback.CallbackHandlerインタフェースを実装します。LoginModuleは、CallbackHandlerを使って、ユーザーと対話し、ユーザー名やパスワードなどのリクエストされた情報を取得します。

- 構成ファイル
このファイルでは、アプリケーションで使用するLoginModuleを構成します。LoginModuleの場所と、複数のLoginModuleがある場合は、実行する順番を指定します。このファイルを使うと、JavaアプリケーションはLoginModuleを使って定義および実装される認証テクノロジから独立を保つことができます。

- アクション・ファイル
このファイルでは、クライアント・アプリケーションが実行する処理を定義します。

- ant構築スクリプト(build.xml)
このスクリプトは、アプリケーションに必要なすべてのファイルをコンパイルし、それらをWebLogic Serverのアプリケーション・ディレクトリにデプロイします。

ここで説明しているコンポーネントを実装する完全な実践的JAAS認証クライアントについては、WebLogic Serverで提供されているSAMPLES_HOME\server\examples\src\examples\security\jaasディレクトリのJAASサンプル・アプリケーションを参照してください。

JAAS認証の基本の詳細は、「JAAS Authentication Tutorial」(http://download.oracle.com/javase/6/docs/technotes/guides/security/jaas/tutorials/GeneralAcnOnly.html)を参照してください。

WebLogic LoginModule実装

LoginModuleクラス(UsernamePasswordLoginModule.class)のWebLogic実装は、WebLogic Server配布キットにおいて、WL_HOME\server\libディレクトリのweblogic.jarファイルで提供されています。

注意:

WebLogic Serverは、JAASで定義されているすべてのコールバックのタイプだけではなく、JAAS仕様を拡張するコールバックのタイプもすべてサポートしています。

WebLogic ServerのUsernamePasswordLoginModuleは、実行に先立ってシステム・ユーザーの認証定義が存在するかどうかを調べ、すでに定義されている場合は何も行いません。

JAAS LoginModuleの実装の詳細は、LoginModule開発者ガイド(http://download.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASLMDevGuide.html)を参照してください。

JVM全体のデフォルト・ユーザーとrunAs()メソッド

LoginModuleのWebLogic Server実装(weblogic.security.auth.login.UsernamePasswordLoginModule)を初めて使用してログインすると、指定されたユーザーがJVM (Java仮想マシン)に対するマシン全体のデフォルト・ユーザーとなります。weblogic.security.Security.runAs()メソッドを実行すると、このメソッドは指定されたSubjectと現在のスレッドのアクセス許可を関連付けてから、アクションを実行します。指定されたSubjectが権限を持たないユーザー(グループに割り当てられていないユーザーは権限を持たないと見なされる)を表している場合、JVM全体のデフォルト・ユーザーが使用されます。したがって、runAs()メソッドでは必要なSubjectを指定することが重要です。それには、以下のオプションがあります。

- オプション1: クライアントがmain()の制御を持つ場合は、例4-1で示されているラッパー・コードをクライアント・コードで実装します。

- オプション2: クライアントがmain()の制御を持たない場合、例4-1に示したラッパー・コードを各スレッドのrun()メソッドに実装します。

例4-1 runAs()メソッドのラッパー・コード

import java.security.PrivilegedAction;
import javax.security.auth.Subject;
import weblogic.security.Security;

public class client
{
public static void main(String[] args)
{
Security.runAs(new Subject(),
new PrivilegedAction() {
public Object run() {
//
//If implementing in client code, main() goes here.
//
return null;
}
});
}
}

JAAS認証を使用するクライアント・アプリケーションの作成

WebLogic Server JavaクライアントにおいてJAASを使ってサブジェクトを認証するには、以下の手順を実行します。

1. WebLogic Serverで使用する認証メカニズム用のLoginModuleクラスを実装します。認証メカニズムのタイプごとにLoginModuleクラスが必要です。1つのWebLogic Serverデプロイメントに対して複数のLoginModuleクラスを割り当てることができます。

注意:

ユーザー名およびパスワードの認証には、WebLogic Server提供のLoginModuleの実装(weblogic.security.auth.login.UsernamePasswordLoginModule)を使用することをお薦めします。ユーザー名およびパスワードの認証用に自分でLoginModuleを作成することもできます。しかし、WebLogic ServerのLoginModuleを修正して再利用しようとはしないでください。LoginModuleを自分で作成する場合は、ログインを実行するためにweblogic.security.auth.Authenticate.authenticate()メソッドを呼び出すように記述します。SAMLなどのリモート・ログイン・メカニズムを使用している場合は、authenticate()メソッドを呼び出す必要はありません。WebLogic Serverを使用してログインを実行する場合は、authenticate()を呼び出すだけで済みます。

weblogic.security.auth.Authenticateクラスは、表4-1で説明されているように初期コンテキストとしてJNDI Environmentオブジェクトを使用します。

2. LoginModuleがユーザーと対話し、ユーザー名、パスワード、URLなどのリクエストされた情報を取得するために使用するCallbackHandlerクラスを実装します。URLにはWebLogicクラスタのURLも指定でき、その場合クライアント側でサーバーのフェイルオーバーによるメリットを得られます。WebLogic Server配布キットには、JAASクライアント・サンプルで使用するSampleCallbackHandlerが含まれています。SampleCallbackHandler.javaコードは開発キットとしてSAMPLES_HOME\server\examples\src\examples\security\jaasディレクトリに含まれています。

注意:

独自のCallbackHandlerクラスを実装するかわりに、WebLogic提供による2つのCallbackHandlerクラス、すなわちweblogic.security.SimpleCallbackHandlerまたはweblogic.security.URLCallbackHandlerのいずれかを使用できます。これらのクラスの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

3. WebLogic Serverで使用するLoginModuleクラス、およびLoginModuleクラスを呼び出す順序を指定する構成ファイルを記述します。WebLogic Server配布キットで提供されるJAASクライアントのサンプルで使用されるサンプル構成ファイルについては、例4-2を参照してください。

例4-2 sample_jaas.configのサンプル・コード

/** Login Configuration for the JAAS Sample Application **/
Sample {
weblogic.security.auth.login.UsernamePasswordLoginModule
required debug=false;
};

1. Javaクライアントにおいて、LoginContextをインスタンス化するコードを記述します。LoginContextは、構成ファイルsample_jaas.configを調べて、WebLogic Server用に構成されているデフォルトのLoginModuleをロードします。LoginContextのインスタンス化の例については、例4-3を参照してください。

注意:

IDアサーション・プロバイダやWebLogic Serverのリモート・インスタンスなどの他の手段を使ってユーザーを認証する場合には、デフォルトLoginModuleはリモート・ソースによって決定されます。

例4-3 LoginContextのコードの一部分

...
import javax.security.auth.login.LoginContext;
...
LoginContext loginContext = null;
try
{
// Create LoginContext; specify username/password login module
loginContext = new LoginContext("Sample",
new SampleCallbackHandler(username, password, url));
}

1. LoginContextのlogin()メソッドを呼び出します。login()メソッドによって、ロードされたLoginModuleがすべて呼び出されます。各LoginModuleでサブジェクトの認証が試みられます。構成されているログイン条件が満たされない場合、LoginContextはLoginExceptionをスローします。login()メソッドの例については、例4-4を参照してください。

例4-4 login()メソッドのコードの一部分

...
import javax.security.auth.login.LoginContext;
import javax.security.auth.login.LoginException;
import javax.security.auth.login.FailedLoginException;
import javax.security.auth.login.AccountExpiredException;
import javax.security.auth.login.CredentialExpiredException;
...
/**
* Attempt authentication
*/
try
{
// If we return without an exception, authentication succeeded
loginContext.login();
}
catch(FailedLoginException fle)
{
System.out.println("Authentication Failed, " +
fle.getMessage());
System.exit(-1);
}
catch(AccountExpiredException aee)
{
System.out.println("Authentication Failed: Account Expired");
System.exit(-1);
}
catch(CredentialExpiredException cee)
{
System.out.println("Authentication Failed: Credentials
Expired");
System.exit(-1);
}
catch(Exception e)
{
System.out.println("Authentication Failed: Unexpected
Exception, " + e.getMessage());
e.printStackTrace();
System.exit(-1);
}

1. Javaクライアント内にコードを記述して、javax.security.auth.Subject.getSubject()メソッドを使用するLoginContextインスタンスから認証されたサブジェクトを取得し、アクションをサブジェクトとして呼び出します。サブジェクトの認証に成功したら、weblogic.security.Security.runAs()メソッドを呼び出すことで、そのサブジェクトに対してアクセス制御を設定できます。runAs()メソッドは、指定されたサブジェクトと現在のスレッドのアクセス許可を関連付けた後、アクションを実行します。getSubject()メソッドとrunAs()メソッドの実装例については、例4-5を参照してください。

注意:

WebLogic ServerアプリケーションでJAAS javax.security.auth.Subject.doAsメソッドを使用する場合、サブジェクトとクライアント・アクションは関連付けられません。doAsメソッドを使用してWebLogic ServerアプリケーションにJava EEセキュリティを実装することは可能ですが、この場合でもSecurity.runAs()メソッドを使用する必要があります。

例4-5 getSubject()メソッドとrunAs()メソッドのコードの一部分

...
/**
* Retrieve authenticated subject, perform SampleAction as Subject
*/
Subject subject = loginContext.getSubject();
SampleAction sampleAction = new SampleAction(url);
Security.runAs(subject, sampleAction);
System.exit(0);
...

1. サブジェクトが必要な権限を持っている場合にアクションを実行するコードを記述します。株式取引用のEJBを実行するjavax.security.PrivilegedActionクラスの実装例SampleActionが用意されています。SampleAction.javaコードは開発キットとしてSAMPLES_HOME\server\examples\src\examples\security\jaasディレクトリに含まれています。

2. LoginContextインスタンスのlogout()メソッドを呼び出します。logout()メソッドは、ユーザーのセッションをクローズし、Subjectをクリアします。login()メソッドの例については、例4-6を参照してください。

例4-6 logout()メソッドのサンプル・コード

...
import javax.security.auth.login.LoginContext;
...
try
{
System.out.println("logging out...");
loginContext.logout();
}

注意:

LoginModule.logout()メソッドはWebLogic認証プロバイダまたはカスタム認証プロバイダに対して呼び出されることはありません。これは、いったんプリンシパルが作成されサブジェクト内に入れられると、WebLogicセキュリティ・フレームワークはこのサブジェクトのライフサイクルを制御しなくなるからです。したがって、JAAS LoginContextを作成してログインおよびサブジェクトの取得を行うコードでも、ログアウトするためにLoginContextを呼び出す必要があります。LoginContext.logout()を呼び出すと、サブジェクトからプリンシパルがクリアされます。

JNDI認証の使い方

Javaクライアントは、Java Naming and Directory Interface (JNDI)を使用してWebLogic Serverに資格証明を渡します。Javaクライアントは、JNDI InitialContextを取得してWebLogic Serverとの通信を確立します。その後、InitialContextを使用して、WebLogic Server JNDIツリーで必要なリソースをルックアップします。

注意:

JAASは認証方法として望ましい選択肢ですが、WebLogic認証プロバイダのLoginModuleはユーザー名とパスワードの認証しかサポートしていません。したがって、クライアントの証明書認証(双方向SSL認証ともいう)ではJNDIを使用します。クライアントの証明書認証にJAASを使用するには、LoginModuleで証明書の認証を行うカスタム認証プロバイダを記述する必要があります。LoginModuleの作成方法については、http://download.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASLMDevGuide.htmlを参照してください。

ユーザーとユーザーの資格証明を指定するには、表4-1で示されているJNDIプロパティを設定します。

表4-3 認証に使用されるJNDIプロパティ

プロパティ

意味

INITIAL_CONTEXT_FACTORY

エントリ・ポイントをWebLogic Server環境に提供します。クラスweblogic.jndi.WLInitialContextFactoryはWebLogic Server用のJNDI SPIです。

PROVIDER_URL

ネーム・サービスを提供するWebLogic Serverのホストとポートを指定します。例: t3://weblogic:7001

SECURITY_PRINCIPAL

ユーザーがデフォルトの(アクティブな)セキュリティ・レルムに対して認証されているときのユーザーのIDを指定します。

SECURITY_CREDENTIALS

ユーザーがデフォルトの(アクティブな)セキュリティ・レルムに対して認証されているときのユーザーの資格証明を指定します。

これらのプロパティは、InitialContextコンストラクタに渡されるハッシュ表に格納されます。例4-7に、WebLogic Serverで実行されるJavaクライアントでのJNDI認証の使い方を示します。

例4-7 認証の例

...
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://weblogic:7001");
env.put(Context.SECURITY_PRINCIPAL, "javaclient");
env.put(Context.SECURITY_CREDENTIALS, "javaclientpassword");
ctx = new InitialContext(env);

注意:

JNDIコンテキストとスレッド、およびJNDIコンテキストの潜在的な問題を回避する方法の詳細は、『Oracle WebLogic Server JNDIのプログラミング』のJNDIコンテキストとスレッドに関する項およびJNDIコンテキストの問題の回避方法に関する項を参照してください。

WebLogic Server 9.0より前のバージョンでは、JNDIでIIOP以外のプロトコルを使用する場合、最初のユーザーは削除されず、他のユーザーが存在しない場合はデフォルト・ユーザーになります。これは適切な処理ではありません。ユーザー名と資格証明を指定しない以後のログインに対してデフォルト・ユーザーのIDが付与されるからです。

バージョン9.0以降では、このような動作は発生せず、デフォルト・ユーザーも存在しません。

以前の動作に戻すには、コマンド・ラインまたはweblogic.jndi.WLContext.ENABLE_DEFAULT_USERインタフェースでフィールドを設定する必要があります。

JavaクライアントのJAAS認証サンプル・コード

WebLogic Serverソフトウェアには、完全な実践的JAAS認証サンプルが付属しています。そのサンプルは、SAMPLES_HOME\server\examples\src\examples\security\jaasディレクトリにあります。このサンプルの説明と、構築、構成、および実行の手順については、サンプル・ディレクトリのpackage.htmlファイルを参照してください。このサンプル・コードは、修正して再利用できます。

5 JavaクライアントでのSSL認証の使用

この項では、JavaクライアントでのSSL認証の使用について説明します。

この節では、以下の内容について説明します。

- JSSEとWebLogic Server

- JNDI認証の使い方

- SSL証明書認証の開発環境

- SSLを使用するアプリケーションの記述

- SSLクライアントのサンプル・コード

これらの節で参照するサンプル・コードは、WebLogic Server配布キットの次の場所から入手できます。

SAMPLES_HOME\server\examples\src\examples\security\sslclient

sslclientディレクトリには、instructions.htmlファイル、antビルド・ファイル、および以下のJavaファイルとJavaServer Pageファイル(.jsp)が含まれています。

- MyListener.java

- NulledHostnameVerifier.java

- NulledTrustManager.java

- SSLClient.java

- SSLClientServlet.java

- SSLSocketClient.java

- SnoopServlet.jsp

以降の説明は、実際のサンプルを見ながら読み進めてください。

JSSEとWebLogic Server

JSSE (Java Secure Socket Extension)は、SSLとTLSプロトコルをサポートおよび実装し、それらの機能をプログラム的に利用可能にするパッケージのセットです。WebLogic Serverは、WebLogic Serverクライアントとサーバー、Javaクライアント、Webブラウザ、および他のサーバーの間で転送されるデータを暗号化するためにSecure Sockets Layer (SSL)をサポートしています。

注意:

WebLogic Serverバージョン12.1.1の時点で、JSSEはサポートされるSSL実装のみです。CerticomベースのSSL実装は削除され、WebLogic Serverでサポートされません。

WebLogicクライアントではWebLogic ServerによるJSSEの実装を使用できますが、これは必須ではありません。他のJSSEの実装も、サーバーの外側のクライアント側のコードで同じように使用できます。

WebLogicのサーバー側アプリケーションでSSLを使用する際には、以下の制限が適用されます。

- WebLogic Serverアプリケーションの開発における他の(サード・パーティの)JSSE実装の使用はサポートされていません。WebLogic Serverが使用するSSLの実装はサーバーの構成に対して固定であり、ユーザーのアプリケーションによって置き換えることはできません。

- JSSEのWebLogic実装はJCE暗号サービス・プロバイダ(Cryptographic Service Provider : CSP)をサポートしていますが、プロバイダのJCEに対するサポートが一定していないため、テストされていないプロバイダがそのまま機能するかどうかは保証されていません。以下のプロバイダではWebLogic Serverをテスト済みです。

- デフォルトのJCEプロバイダ(SunJCEプロバイダ)。SunJCEプロバイダの詳細は、http://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.htmlおよびhttp://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.htmlを参照してください。

- nCipher JCEプロバイダ。

その他のプロバイダはWebLogic Serverで機能する可能性はありますが、テストされていないプロバイダの場合、おそらくそのままでは機能しません。WebLogic ServerでサポートされているJCEプロバイダの使用の詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

WebLogic Serverでは、Secure Sockets Layer (SSL)で暗号化された通信にHTTPSポートを使用します。このポートはSSLにしか使用できません。

注意:

WebLogicクライアントでセキュリティを実装するためには、JavaクライアントでWebLogic Serverソフトウェア配布キットをインストールする必要があります。

JNDI認証の使い方

Javaクライアントは、Java Naming and Directory Interface (JNDI)を使用してWebLogic Serverに資格証明を渡します。Javaクライアントは、JNDI InitialContextを取得してWebLogic Serverとの通信を確立します。その後、InitialContextを使用して、WebLogic Server JNDIツリーで必要なリソースをルックアップします。

注意:

JAASは認証方法として望ましい選択肢ですが、認証プロバイダのLoginModuleはユーザー名とパスワードの認証しかサポートしていません。したがって、クライアントの証明書認証(双方向SSL認証ともいう)ではJNDIを使用します。クライアントの証明書認証にJAASを使用するには、LoginModuleで証明書の認証を行うカスタム認証プロバイダを記述する必要があります。

ユーザーとユーザーの資格証明を指定するには、表5-1で示されているJNDIプロパティを設定します。

表5-1 認証に使用されるJNDIプロパティ

プロパティ

意味

INITIAL_CONTEXT_FACTORY

エントリ・ポイントをWebLogic Server環境に提供します。クラスweblogic.jndi.WLInitialContextFactoryはWebLogic Server用のJNDI SPIです。

PROVIDER_URL

ネーム・サービスを提供するWebLogic Serverのホストとポートを指定します。例: t3s://weblogic:7002

(t3sはSSLのWebLogic Server独自のバージョンです。)

SECURITY_PRINCIPAL

ユーザーがデフォルトの(アクティブな)セキュリティ・レルムに対して認証されているときのユーザーのIDを指定します。

SECURITY_CREDENTIALS

ユーザーがデフォルトの(アクティブな)セキュリティ・レルムに対して認証されているときのユーザーの資格証明を指定します。

これらのプロパティは、InitialContextコンストラクタに渡されるハッシュ表に格納されます。

例5-1は、Javaクライアントで一方向SSL証明書認証を使用する方法を示しています。双方向SSL認証のコード例については、例5-4を参照してください。

例5-1 JNDIを使用する一方向SSL認証の例

...
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3s://weblogic:7002");
env.put(Context.SECURITY_PRINCIPAL, "javaclient");
env.put(Context.SECURITY_CREDENTIALS, "javaclientpassword");
ctx = new InitialContext(env);

注意:

JNDIコンテキストとスレッド、およびJNDIコンテキストの潜在的な問題を回避する方法の詳細は、『Oracle WebLogic Server JNDIのプログラミング』のJNDIコンテキストとスレッドに関する項およびJNDIコンテキストの問題の回避方法に関する項を参照してください。

SSL証明書認証の開発環境

この節では、以下の内容について説明します。

- SSL認証API

- SSLクライアント・アプリケーション・コンポーネント

SSL認証API

WebLogic ServerでSSL認証を使用するJavaクライアントを実装するには、Javaアプリケーション・プログラミング・インタフェース(API)とWebLogic APIを組み合わせて使用します。

表5-1では、証明書認証の実装に使用されるJava APIパッケージについて説明します。表5-1の情報はJava APIのドキュメントから取られており、WebLogic Server固有の情報がコメントで追加されています。Java APIの詳細は、http://download.oracle.com/javase/6/docs/api/index.htmlおよびhttp://download.oracle.com/javaee/6/api/のJavadocを参照してください。

表5-3では、証明書認証の実装に使用されるWebLogic APIについて説明します。詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

表5-2 Java証明書API

Java証明書API

説明

javax.crypto (http://download.oracle.com/javase/6/docs/api/index.html)

このパッケージは暗号操作のためのクラスとインタフェースを提供します。このパッケージで定義されている暗号操作には、暗号化、鍵の生成と照合、およびMessage Authentication Code (MAC)の生成が含まれます。

暗号化のサポートには、対称、非対称、ブロック、およびストリームの各暗号方式が含まれています。このパッケージは、セキュア・ストリームおよび暗号化されたオブジェクトもサポートしています。

このパッケージで提供されるクラスの多くは、プロバイダ・ベースです(java.security.Providerクラスを参照)。クラス自体では、アプリケーションを記述できるプログラミング・インタフェースが定義されています。独立したサード・パーティ・ベンダーは、必要に応じて、実装自体を作成し、シームレスに組み込むことができます。したがって、アプリケーション開発者は、コードを追加したり書き直したりしなくても、プロバイダ・ベースの実装をいくつでも利用できます。

javax.net (http://download.oracle.com/javase/6/docs/api/index.html)

このパッケージはネットワーク・アプリケーション用のクラスを提供します。ソケット作成用のファクトリが含まれています。ソケット・ファクトリを使うと、ソケットの作成と構成の動作をカプセル化できます。

javax.net.SSL (http://download.oracle.com/javase/6/docs/api/index.html)

このパッケージのクラスとインタフェースはWebLogic Serverでサポートされていますが、WebLogic ServerでSSLを使用するときにはweblogic.security.SSLパッケージの使用をお薦めします。

java.security.cert (http://download.oracle.com/javase/6/docs/api/index.html)

このパッケージは、証明書、証明書失効リスト(CRL)、および証明書パスの解析と管理を行うためのクラスとインタフェースを提供します。X.509 v3証明書およびX.509 v2 CRLのサポートが含まれています。

java.security.KeyStore (http://download.oracle.com/javase/6/docs/api/index.html)

このクラスは、鍵と証明書のメモリー内コレクションを表します。以下の2タイプのキーストア・エントリの管理に使用されます。

- キー・エントリ
このタイプのキーストア・エントリは暗号鍵情報を保持しています。これは不正アクセスを防ぐため、保護された形式で格納されます。

通常、このタイプのエントリに格納された鍵は、対応する公開鍵の証明書チェーンを伴う秘密鍵または秘密鍵です。

秘密鍵および証明書チェーンは、自動認証のための指定されたエンティティによって使用されます。この認証のためのアプリケーションには、ソフトウェアのリリースやライセンス付与の一環としてJARファイルに署名するソフトウェア配布組織が含まれます。

- 信頼性のある証明書エントリ
このタイプのエントリには、別の相手に属する単一の公開鍵証明書が含まれます。これは信頼性のある証明書と呼ばれます。その証明書内の公開鍵が、実際に証明書のサブジェクト(オーナー)によって識別されるIDに属するものであるとキーストアのオーナーが信頼するからです。

このタイプのエントリは、他の相手を認証するのに使用できます。

java.security.PrivateKey (http://download.oracle.com/javase/6/docs/api/index.html)

秘密鍵。このインタフェースには、メソッドまたは定数が含まれません。すべての秘密鍵インタフェースのグループ化(およびタイプ保証)を行う役割を持つのみです。

注意: 専用の秘密鍵インタフェースは、このインタフェースを拡張したものです。たとえば、java.security.interfacesのDSAPrivateKeyインタフェースを参照してください。

java.security.Provider (http://download.oracle.com/javase/6/docs/api/index.html)

このクラスは、Java Security APIの「暗号サービス・プロバイダ」を表します。プロバイダは、以下のようなJava Securityの一部または全部を実装します。

- アルゴリズム(DSA、RSA、MD5、SHA-1など)

- キーの生成、変換、および管理機能(アルゴリズム固有キーなど)

各プロバイダには名前とバージョン番号が付いており、インストールされる各実行時において構成されます。

暗号サービスの実装を提供するには、開発者チームまたはサード・パーティのベンダーが実装コードを記述し、Providerクラスのサブクラスを作成します。

javax.servlet.http.HttpServletRequest (http://download.oracle.com/javaee/6/api/index.html)

このインタフェースは、ServletRequestインタフェースを拡張して、HTTPサーブレットのリクエスト情報を提供します。

サーブレット・コンテナは、HttpServletRequestオブジェクトを作成し、サーブレットのサービス・メソッド(doGet、doPostなど)に引数として渡します。

javax.servlet.http.HttpServletResponse (http://download.oracle.com/javaee/6/api/index.html)

このインタフェースは、ServletResponseインタフェースを拡張して、レスポンス送信の際にHTTP固有の機能を提供します。たとえば、このインタフェースにはHTTPヘッダーおよびCookieにアクセスする方法が含まれます。

サーブレット・コンテナは、HttpServletRequestオブジェクトを作成し、サーブレットのサービス・メソッド(doGet、doPostなど)に引数として渡します。

javax.servlet.ServletOutputStream (http://download.oracle.com/javaee/6/api/index.html)

このクラスは、バイナリ・データをクライアントに送信するための出力ストリームを提供します。ServletOutputStreamオブジェクトは通常、ServletResponse.getOutputStream()メソッドを通じて取得されます。

これは、サーブレット・コンテナが実装する抽象クラスです。このクラスのサブクラスは、java.io.OutputStream.write(int)メソッドを実装する必要があります。

javax.servlet.ServletResponse (http://download.oracle.com/javaee/6/api/index.html)

このクラスは、クライアントにレスポンスを送信する際にサーブレットを支援するオブジェクトを定義します。サーブレット・コンテナは、ServletResponseオブジェクトを作成し、サーブレットのサービス・メソッド(doGet、doPostなど)に引数として渡します。

表5-3 WebLogic証明書API

WebLogic証明書API

説明

weblogic.net.http.HttpsURLConnection

リモートのオブジェクトにHTTP with SSL (HTTPS)を提示するのに使用されるクラスを提供します。このクラスは、クライアントとして機能しているWebLogic Serverから別のWebLogic ServerへのアウトバウンドSSL接続を確立するために使われます。

weblogic.security.SSL.HostnameVerifier

SSLハンドシェーク時のホスト名検証によって、URL内のホスト名がサーバーのID内のホスト名に一致するかどうかが検証されます。この検証は、介入者攻撃を防ぐために必要となります。

WebLogic Serverでは、HostnameVerifierの証明書ベースの実装がデフォルトで使用され、URLホスト名がサーバー証明書のCNフィールドと一致するかどうかが検証されます。

管理コンソールの「SSL」タブにある「詳細」ペインを使用すると、このデフォルトのホスト名検証をカスタム・ホスト名検証に変更できます。その場合、WebLogic SSL APIを使用しているサーバーで実行されているSSLクライアントのデフォルトに影響が生じます。また、HttpsURLConnectionやSSLContextなどのWebLogic SSL APIを使用すると、カスタムHostnameVerifierを明示的に設定できます。

weblogic.security.SSL.TrustManager

このインタフェースを使うと、ユーザーはピアの証明書チェーンでの何らかの検証エラーをオーバーライドし、ハンドシェークを継続できます。また、ピア証明書チェーンに対しさらに検証を実行し、必要に応じてハンドシェークを中断することもできます。

weblogic.security.SSL.CertPathTrustManager

このクラスは、構成済みのCertPathValidationプロバイダを使用して、失効チェックなどの追加的な検証を実行します。

デフォルトでは、CertPathTrustManagerはインストールされますが、CertPathValidatorsを呼び出さないように構成されています(InboundCertificateValidationおよびOutboundCertificateValidationのSSLMBean属性で制御します)。

カスタムTrustManagerをインストールするアプリケーションでは、CertPathTrustManagerが置き換えられます。カスタムTrustManagerを使用するアプリケーションでCertPathProvidersも呼び出したい場合は、カスタムTrustManagerからCertPathTrustManagerに委任できます。

weblogic.security.SSL.SSLContext

このクラスは、このコンテキスト下で作成されたすべてのソケットで共有されるすべての状態情報を保持します。

weblogic.security.SSL.SSLSocketFactory

このクラスは、SSLソケットを作成するためのAPIを提供します。

weblogic.security.SSL.SSLValidationConstants

このクラスは、コンテキスト要素名を定義します。SSLは、1つまたは複数のCertPathValidatorオブジェクトを呼び出して追加検証を実行する前に、一部の組込み検証を実行します。検証プロバイダは、実行済みの検証を検出することで、必要な検証の規模を縮小できます。

SSLクライアント・アプリケーション・コンポーネント

SSLクライアント・アプリケーションには、少なくとも以下のコンポーネントが含まれます。

- Javaクライアント
通常、Javaクライアントは以下の機能を実行します。

- クライアントID、信頼、HostnameVerifier、およびTrustManagerによるSSLContextの初期化

- キーストアのロード、および秘密鍵と証明書チェーンの取得

- SSLSocketFactoryの使用

- WebLogic Serverのインスタンスによって提供されるJSPに接続するためのHTTPSの使用

- HostnameVerifier
HostnameVerifierはweblogic.security.SSL.HostnameVerifierインタフェースを実装します。

- HandshakeCompletedListener
HandshakeCompletedListenerは、javax.net.ssl.HandshakeCompletedListenerインタフェースを実装します。このインタフェースは、SSLクライアントが、指定されたSSL接続に対するSSLハンドシェークの完了について通知を受け取るために使用します。

- TrustManager
TrustManagerは、weblogic.security.SSL.TrustManagerインタフェースを実装します。

ここで説明しているコンポーネントを実装する完全な実践的SSL認証クライアントについては、WebLogic Serverで提供されているSAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリのSSLClientサンプル・アプリケーションを参照してください。

JSSE認証の詳細は、『Java Secure Socket Extension (JSSE) Reference Guide』(http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。

SSLを使用するアプリケーションの記述

この節では、以下のトピックを取り上げます。

- WebLogic Server間の安全な通信

- SSLクライアントの作成

- 双方向SSL認証の使用

- カスタム・ホスト名検証の使い方

- トラスト・マネージャの使い方

- SSLContextの使い方

- URLを使用したアウトバウンドSSL接続

WebLogic Server間の安全な通信

URLオブジェクトを使用すると、クライアントとして機能しているWebLogic Serverインスタンスから別のWebLogic ServerインスタンスへのアウトバウンドSSL接続を確立することができます。weblogic.net.http.HttpsURLConnectionクラスを使用して、秘密鍵とデジタル証明書を含む、クライアントのセキュリティ・コンテキスト情報を指定できます。

weblogic.net.http.HttpsURLConnectionクラスは、ネゴシエーションされた暗号スイートの判別、ホスト名検証の取得と設定、サーバーの証明書チェーンの取得、および新しいSSLソケットを作成するためのSSLSocketFactoryの取得と設定を行うメソッドを提供します。

SSLClientのサンプル・コードでは、weblogic.net.http.HttpsURLConnectionクラスを使用してアウトバウンドSSL接続を確立しています。SSLClientのサンプル・コードは、SAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリのexamples.security.sslclientパッケージにあります。

SSLクライアントの作成

ここでは、様々なタイプのSSLクライアントを作成する方法を、サンプルを使って説明します。以下のタイプのSSLクライアントについて説明します。

- SSLClientサンプル

- SSLSocketClientサンプル

- 双方向SSL認証の使用

SSLClientサンプル

SSLClientサンプルでは、URLおよびURLConnectionオブジェクトによって発信SSL接続をWebLogic SSLライブラリを使用して確立する方法が示されています。スタンドアロンのアプリケーションからだけでなく、WebLogic Server内のサーブレットからこの処理を行う方法も示されています。

注意:

SSLクライアントとして機能するWebLogic Serverでは、発信SSL接続にサーバーのID証明書を使用します。WebLogic Serverで実行するアプリケーションで以前に記述されたSSL APIを使用している場合、デフォルトではサーバーのID証明書は共有されません(信頼のみ)。

例5-2は、SSLClientサンプルの抜粋です。このサンプルは、SSLClient.javaファイルのSAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリにあります。

例5-2 SSLClientサンプル・コードの抜粋

package examples.security.sslclient;

import java.io.*;
import java.net.URL;
import java.security.Provider;
import javax.servlet.ServletOutputStream;
...
/*
* This method contains an example of how to use the URL and
*  URLConnection objects to create a new SSL connection, using
*  WebLogic SSL client classes.
*/
public void wlsURLConnect(String host, String port,
String sport, String query,
OutputStream out)
throws Exception {
...
URL wlsUrl = null;
try {
wlsUrl = new URL("http", host, Integer.valueOf(port).intValue(),
query);
weblogic.net.http.HttpURLConnection connection =
new weblogic.net.http.HttpURLConnection(wlsUrl);
tryConnection(connection, out);
}
...
wlsUrl = new URL("https", host, Integer.valueOf(sport).intValue(),
query);
weblogic.net.http.HttpsURLConnection sconnection =
new weblogic.net.http.HttpsURLConnection(wlsUrl);
...

SSLSocketClientサンプル

SSLSocketClientサンプルでは、直接セキュア・ポートからWebLogic Serverのインスタンスによって提供されるJSPに接続し、その接続の結果を表示する方法を示します。以下の機能を実装する方法が示されています。

- クライアントID、HostnameVerifier、およびTrustManagerによるSSLContextの初期化

- キーストアのロード、および秘密鍵と証明書チェーンの取得

- SSLSocketFactoryの使用

- WebLogic Serverによって提供されるJSPに接続するためのHTTPSの使用

- javax.net.ssl.HandshakeCompletedListenerインタフェースの実装

- サンプルが接続するサーバーが目的のホスト上で稼働していることを確認するための、weblogic.security.SSL.HostnameVerifierクラスのダミー実装の作成

例5-3は、SSLSocketClientサンプルの抜粋です。このサンプルは、SSLSocketClient.javaファイルのSAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリにあります。(sslclientディレクトリにあるSSLClientServletサンプルは、SSLClientサンプルの簡単なサーブレット・ラッパーです)。

例5-3 SSLSocketClientサンプル・コードの抜粋

package examples.security.sslclient;

import java.io.*;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.cert.Certificate;
import javax.net.ssl.HandshakeCompletedListener;
import javax.net.ssl.SSLSocket;
import weblogic.security.SSL.HostnameVerifier;
import weblogic.security.SSL.SSLContext;
import weblogic.security.SSL.SSLSocketFactory;
import weblogic.security.SSL.TrustManager;
...
SSLContext sslCtx = SSLContext.getInstance("https");
File KeyStoreFile  = new File ("mykeystore");
...
// Open the keystore, retrieve the private key, and certificate chain
KeyStore ks = KeyStore.getInstance("jks");
ks.load(new FileInputStream("mykeystore"), null);
PrivateKey key = (PrivateKey)ks.getKey("mykey",
"testkey".toCharArray());
Certificate [] certChain = ks.getCertificateChain("mykey");
sslCtx.loadLocalIdentity(certChain, key);
HostnameVerifier hVerifier = null;
if (argv.length < 3)
hVerifier = new NulledHostnameVerifier();
else
hVerifier = (HostnameVerifier)
Class.forName(argv[2]).newInstance();

sslCtx.setHostnameVerifier(hVerifier);
TrustManager tManager = new NulledTrustManager();
sslCtx.setTrustManager(tManager);
System.out.println(" Creating new SSLSocketFactory with SSLContext");
SSLSocketFactory sslSF = (SSLSocketFactory)
sslCtx.getSocketFactory();
System.out.println(" Creating and opening new SSLSocket with
SSLSocketFactory");
// using createSocket(String hostname, int port)
SSLSocket sslSock = (SSLSocket) sslSF.createSocket(argv[0],
new Integer(argv[1]).intValue());
System.out.println(" SSLSocket created");
HandshakeCompletedListener mListener = null;
mListener = new MyListener();
sslSock.addHandshakeCompletedListener(new MyListener());
...

双方向SSL認証の使用

証明書認証では、WebLogic Serverは、リクエスト元のクライアントにデジタル証明書を送信します。クライアントは、デジタル証明書を調べて、本物かどうか、期限切れでないかどうか、認証元のWebLogic Serverインスタンスに一致しているかどうかを確認します。

双方向SSL認証(相互認証の一形態)を使用する場合は、リクエスト元のクライアントもデジタル証明書をWebLogic Serverに提示します。双方向SSL認証をするようWebLogic Serverのインスタンスを構成すると、指定した認証局からデジタル証明書を送信するようにリクエスト元のクライアントに要求できるようになります。WebLogic Serverでは、信頼性のある認証局によって署名されたデジタル証明書のみが受け付けられます。

双方向SSL認証を行うようWebLogic Serverを構成する方法の詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

以降の節では、双方向SSL認証をWebLogic Serverに実装する様々な方法について説明します。

- JNDIを使用した双方向SSL認証

- WebLogic Serverインスタンス間で双方向SSL認証の使用

- サーブレットで双方向SSL認証の使用

JNDIを使用した双方向SSL認証

Javaクライアントの双方向SSL認証でJNDIを使用する場合、WebLogic JNDI EnvironmentクラスのsetSSLClientCertificate()メソッドを使用します。このメソッドは、クライアント認証に対して、X.509デジタル証明書の秘密鍵と証明書チェーンを設定します。

デジタル証明書をJNDIに渡すには、DERエンコードされたデジタル証明書を格納するファイルで開かれているInputStreamsの配列を作成し、JNDIハッシュ表にその配列を設定します。配列内の最初の要素には、Javaクライアントの秘密鍵ファイルで開かれているInputStreamが格納されている必要があります。配列内の2番目の要素には、Javaクライアントのデジタル証明書ファイルで開かれているInputStreamが格納されている必要があります(このファイルにはJavaクライアントの公開鍵が含まれています)。追加要素として、ルート認証局のデジタル証明書、証明書チェーン内のデジタル証明書の署名者を格納できます。デジタル証明書がサーバーの信頼性のある認証局によって直接発行されない場合、WebLogic Serverは、証明書チェーンを使用してJavaクライアントのそのデジタル証明書を認証できます。

weblogic.security.PEMInputStreamクラスを使用すると、Privacy Enhanced Mail (PEM)ファイルに保存されているデジタル証明書を読み込むことができます。このクラスでは、base 64でエンコードされた証明書をPEMファイルからデコードするフィルタが提供されます。

例5-4は、Javaクライアントで双方向SSL認証を使用する方法を示しています。

例5-4 JNDIを使用する双方向SSL認証クライアントの例

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import weblogic.jndi.Environment;
import weblogic.security.PEMInputStream;
import java.io.InputStream;
import java.io.FileInputStream;
public class SSLJNDIClient
{
public static void main(String[] args) throws Exception
{
Context context = null;
try {
Environment env = new Environment();
// set connection parameters
env.setProviderUrl("t3s://localhost:7002");
// The next two set methodes are optional if you are using
// a UserNameMapper interface.
env.setSecurityPrincipal("system");
env.setSecurityCredentials("weblogic");
InputStream key = new FileInputStream("certs/demokey.pem");
InputStream cert = new FileInputStream("certs/democert.pem");
// wrap input streams if key/cert are in pem files
key = new PEMInputStream(key);
cert = new PEMInputStream(cert);
env.setSSLClientCertificate(new InputStream[] { key, cert});
env.setInitialContextFactory(Environment.DEFAULT_INITIAL_CONTEXT_FACTORY);
context = env.getInitialContext();
Object myEJB = (Object) context.lookup("myEJB");
}
finally {
if (context != null) context.close();
}
}
}

JNDIのgetInitialContext()メソッドが呼び出されると、JavaクライアントとWebLogic Serverは、Webブラウザが相互認証を実行してセキュリティ保護されたWebサーバー接続を取得するのと同じ方法で相互認証を実行します。デジタル証明書を確認できない場合やJavaクライアントのデジタル証明書をデフォルトの(アクティブな)セキュリティ・レルムで認証できない場合、例外がスローされます。認証されたユーザー・オブジェクトはJavaクライアントのサーバー・スレッドに格納され、保護されたWebLogicリソースへのJavaクライアントのアクセスを管理する許可のチェックに使用されます。

WebLogic JNDI Environmentクラスを使用する場合、getInitialContext()メソッドの呼出しごとに新しいEnvironmentオブジェクトを作成する必要があります。Userオブジェクトとセキュリティ資格証明を一度指定すると、ユーザーおよびユーザーに関連する資格証明はEnvironmentオブジェクトの設定に残ります。再設定を試みてJNDI getInitialContext()メソッドを呼び出した場合は、元のユーザーと資格証明が使用されます。

Javaクライアントによる双方向SSL認証を使用する場合、WebLogic Serverは、クライアントJVMごとに一意のJava仮想マシン(JVM) IDを取得し、JavaクライアントとWebLogic Serverの間の接続が切断されないようにします。処理がないために接続がタイムアウトになるまで、JavaクライアントのJVMが実行されている間は接続が続行されます。Javaクライアントが新しいSSL接続を確実にネゴシエーションできる唯一の方法は、そのJVMを停止してJVMの他のインスタンスを実行することです。

例5-4のコードでは、weblogic.security.providers.authentication.UserNameMapperインタフェースを実装するWebLogic IDアサーション・プロバイダの呼出しが生成されます。UserNameMapperインタフェースを実装するクラスは、デジタル証明書が有効な場合にユーザー・オブジェクトを返します。WebLogic Serverでは、この認証されたユーザー・オブジェクトはWebLogic Server内のJavaクライアントのスレッドに格納されます。格納されたユーザー・オブジェクトは、以降の認可リクエストで、スレッドがデフォルトの(アクティブな)セキュリティ・レルムで保護されているWebLogicリソースにアクセスする際に使用されます。

注意:

セキュリティ・プロバイダ・プラグインがシステム・クラスパスからロードされます。システム・クラスパスはカスタムweblogic.security.providers.authentication.UserNameMapperインタフェースの実装を指定する必要があります。

証明書ベースの認証を実行するIDアサーション・プロバイダが構成されていない場合、SSL接続のJVMで動作しているJavaクライアントは、新しいJNDI InitialContextを作成し、JNDI SECURITY_PRINCIPALとSECURITY_CREDENTIALSプロパティで新しいユーザー名とパスワードを指定することでWebLogic ServerユーザーのIDを変更できます。SSL接続後にJavaクライアントによって渡されたデジタル証明書は使用されません。新しいWebLogic Serverユーザーは、最初のユーザーのデジタル証明書でネゴシエーションしたSSL接続を使用し続けます。

証明書ベースの認証を実行するIDアサーション・プロバイダが構成されている場合、WebLogic Serverはデジタル証明書をJavaクライアントからUserNameMapperインタフェースを実装するクラスへ渡し、UserNameMapperクラスがデジタル証明書をWebLogic Serverユーザー名にマップします。したがって、証明書ベースのIDアサーションを使用していて新しいユーザーIDを設定する場合、そのIDは変更できません。この理由は、デジタル証明書は、EnvironmentごとにJVMからの最初の接続リクエストの時点でのみ処理されるからです。

警告:

双方向SSLとJNDIを使用している場合は、1つのクライアントJVMから複数のユーザーが同時にWebLogic Serverにログインすることはできません。異なるスレッドで複数のログインが実行された場合、その結果は確認不能であり、片方のユーザーのリクエストが別のユーザーのログインで実行され、ユーザーが別のユーザーのデータにアクセスできるようになることも考えられます。WebLogic Serverでは、1つのクライアントJVMからの証明書ベースの複数の同時ログインをサポートしていません。JNDIコンテキストとスレッド、およびJNDIコンテキストの潜在的な問題を回避する方法の詳細は、『Oracle WebLogic Server JNDIのプログラミング』のJNDIコンテキストとスレッドに関する項およびJNDIコンテキストの問題の回避方法に関する項を参照してください。

ユーザー名マッパーの作成

双方向SSLを使用している場合、WebLogic ServerはSSL接続を確立するときにWebブラウザまたはJavaクライアントのデジタル証明書を確認します。ただし、デジタル証明書はWebブラウザまたはJavaクライアントをWebLogic Serverセキュリティ・レルムのユーザーとしては認識しません。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストすると、WebLogic ServerはWebブラウザまたはJavaクライアントにIDを持つように要求します。このリクエストに対応するため、WebLogic IDアサーション・プロバイダは、WebブラウザまたはJavaクライアントのデジタル証明書をWebLogic Serverセキュリティ・レルムのユーザーにマップするユーザー名マッパーを、有効にできるようにします。ユーザー名マッパーは、weblogic.security.providers.authentication.UserNameMapperインタフェースの実装でなければなりません。

weblogic.security.providers.authentication.UserNameMapperインタフェースのデフォルト実装、DefaultUserNameMapperImplを使用することも、独自の実装を開発することもできます。

WebLogic IDアサーション・プロバイダは、以下のIDアサーション・トークン・タイプについて、UserNameMapperインタフェースの実装を呼び出すことができます。

- SSLハンドシェークを通じて渡されたX.509デジタル証明書

- CSIv2を通じて渡されたX.509デジタル証明書

- CSIv2を通じて渡されたX.501識別名

その他のタイプの証明書をマップする場合は、UserNameMapperインタフェースの独自の実装を記述します。

デジタル証明書をユーザー名にマップするUserNameMapperインタフェースを実装するには、次の処理を実行するUserNameMapperクラスを記述します。

1. UserNameMapper実装クラスをインスタンス化します。

2. UserNameMapperインタフェース実装を作成します。

3. mapCertificateToUserName()メソッドを使用して、クライアントから提示された証明書チェーンに基づいて証明書をユーザー名にマップします。

4. 文字列属性タイプを対応するAttribute Value Assertionフィールド・タイプにマップします。

セキュリティ・プロバイダ・プラグインがシステム・クラスパスからロードされます。システム・クラスパスはweblogic.security.providers.authentication.UserNameMapperインタフェースの実装を指定する必要があります。

WebLogic Serverインスタンス間で双方向SSL認証の使用

一方のWebLogic Serverインスタンスがもう一方のWebLogic Serverインスタンスのクライアントとして機能するサーバー間通信で双方向SSL認証を使用できます。サーバー間通信で双方向SSL認証を使用すると、一般的なクライアント/サーバー環境でない場合でも、信頼できる高度なセキュリティで保護した接続を利用することができます。

例5-5は、あるWebLogic Serverインスタンスで動作するサーブレットからserver2.weblogic.comという別のWebLogic Serverインスタンスにセキュリティで保護された接続を確立する方法を示しています。

例5-5 他のWebLogic Serverインスタンスへのセキュリティ保護された接続の確立

FileInputStream [] f = new FileInputStream[3];
f[0]= new FileInputStream("demokey.pem");
f[1]= new FileInputStream("democert.pem");
f[2]= new FileInputStream("ca.pem");
Environment e = new Environment ();
e.setProviderURL("t3s://server2.weblogic.com:443");
e.setSSLClientCertificate(f);
e.setSSLServerName("server2.weblogic.com");
e.setSSLRootCAFingerprints("ac45e2d1ce492252acc27ee5c345ef26");

e.setInitialContextFactory
("weblogic.jndi.WLInitialContextFactory");
Context ctx = new InitialContext(e.getProperties())

例5-5で、WebLogic JNDI Environmentクラスは以下のパラメータを格納するハッシュ表を作成します。

- setProviderURL - SSLサーバーとして機能するWebLogic ServerインスタンスのURLを指定します。SSLクライアントとして機能するWebLogic Serverインスタンスは、このメソッドを呼び出します。URLでは、SSLを基にした、WebLogic Server独自のプロトコルであるt3sプロトコルを指定します。SSLプロトコルは、2つのWebLogic Serverインスタンス間の接続および通信を保護します。

- setSSLClientCertificate - SSL接続に使用する秘密鍵と証明書チェーンを指定します。このメソッドを使用して、秘密鍵(配列内の最初の入力ストリーム)とX.509証明書のチェーン(配列内の残りの入力ストリームを構成する)から成る入力ストリーム配列を指定します。証明書チェーン内の各証明書は、チェーン内の前の証明書の発行元です。

- setSSLServerName - SSLサーバーとして機能するWebLogic Serverインスタンスの名前を指定します。SSLサーバーがデジタル証明書をSSLクライアントとして機能するWebLogic Serverに提示すると、setSSLServerNameメソッドを使用して指定された名前がデジタル証明書内の一般名と比較されます。ホスト名検証が成功するためには、名前が一致する必要があります。このパラメータは、介入者攻撃を防ぐために使用されます。

- setSSLRootCAFingerprint - 信頼性のある認証局のセットを表すデジタル・コード(つまり、信頼性のある証明書のフィンガープリントに基づく信頼)を指定します。SSLサーバーとして機能するWebLogic Serverインスタンスから受け取った証明書チェーンのルート証明書は、このメソッドで指定されたフィンガープリントのいずれかと一致しないと信頼を確立できません。このパラメータは、介入者攻撃を防ぐために使用されます。これにより、WebLogic Serverの信頼構成でWebLogic Serverで動作するクライアント用に指定されているデフォルト・レベルの信頼を補完できます。

注意:

JNDIコンテキストとスレッド、およびJNDIコンテキストの潜在的な問題を回避する方法の詳細は、『Oracle WebLogic Server JNDIのプログラミング』のJNDIコンテキストとスレッドに関する項およびJNDIコンテキストの問題の回避方法に関する項を参照してください。

サーブレットで双方向SSL認証の使用

Javaクライアントをサーブレット(または他のサーバー側Javaクラス)で認証するには、クライアントがデジタル証明書を提供したかどうかをチェックする必要があります。提供した場合は、証明書が信頼できる認証局で発行されたかどうかをさらにチェックします。サーブレットの開発者には、Javaクライアントが有効なデジタル証明書を持っているかどうかを尋ねる責任があります。WebLogic Servlet APIでサーブレットを開発する場合、HTTPServletRequestオブジェクトのgetAttribute()メソッドでSSL接続に関する情報にアクセスする必要があります。

以下の属性が、WebLogic Serverサーブレットでサポートされています。

- javax.servlet.request.X509Certificate

- java.security.cert.X509Certificate [] - X509証明書の配列を返します。

- javax.servlet.request.cipher_suite - HTTPSが使用する暗号スイートを表す文字列を返します。

- javax.servlet.request.key_size - 対称(バルク暗号化)キー・アルゴリズムのビット・サイズを表す整数(0、40、56、128、168)を返します。

- weblogic.servlet.request.SSLSession

- javax.net.ssl.SSLSession - 暗号スイートを含むSSLセッション・オブジェクト、およびSSLセッション・オブジェクトが作成された日付と最後に使用された日付を返します。

デジタル証明書に定義されているユーザー情報にアクセスできます。javax.servlet.request.X509Certificate属性を取得すると、情報はjava.security.cert.X509Certificate型の配列になっています。配列をその型にキャストして証明書を調べるだけで済みます。

デジタル証明書には、以下のような情報が指定されています。

- サブジェクト(保持者、オーナー)の名前と、そのサブジェクトのIDを一意に確認するために必要なその他の識別情報

- サブジェクトの公開鍵

- デジタル証明書を発行した認証局の名前

- シリアル番号

- デジタル証明書の有効期間(存続期間)(開始日と終了日で定義)

カスタム・ホスト名検証の使い方

ホスト名検証を使用すると、SSL接続先のホストが予定していた通信先、または許可された通信先であることを確認できます。ホスト名検証は、WebLogicクライアントまたはWebLogic Serverインスタンスが別のアプリケーション・サーバーのSSLクライアントとして動作している場合に便利です。介入者攻撃(man-in-the-middle attack)を防ぐのに役立ちます。

注意:

デモ用デジタル証明書はインストール時に生成されるので、WebLogic Serverソフトウェアがインストールされるシステムのホスト名を格納します。したがって、開発またはテスト目的でデモ用証明書を使用する場合は、ホスト名検証をオンのままにしておく必要があります。

WebLogic ServerのSSLハンドシェーク機能としてのデフォルトの動作は、SSLサーバーのデジタル証明書のサブジェクトDNにあるCNフィールドと、サーバーへの接続に使用するURL内のホスト名を比較することです。これらの名前が一致しない場合はSSL接続が中断されます。

SSL接続の中断は、サーバーのホスト名をデジタル証明書と照らし合わせて有効性を検証するSSLクライアントによって実行されます。デフォルト以外の動作が必要な場合は、ホスト名検証を無効にするか、カスタム・ホスト名検証を登録します。ホスト名検証を無効にすると、SSL接続は介入者攻撃に対して無防備な状態になります。

ホスト名検証は、以下の方法で無効にできます。

- 管理コンソールで、サーバー(たとえばmyserver)の「キーストア& SSL」タブの「詳細オプション」にある「ホスト名の検証」フィールドで「なし」を指定します。

- SSLクライアントのコマンド・ラインで、次の引数を入力します。

-Dweblogic.security.SSL.ignoreHostnameVerification=true

カスタム・ホスト名検証を記述できます。weblogic.security.SSL.HostnameVerifierインタフェースではコールバック・メカニズムが提供されるため、このインタフェースを実装することで、URLのホスト名への接続を許可するかどうかについてのポリシーを指定できます。ポリシーは、証明書ベースにすることも、他の認証スキームに依存させることも可能です。

カスタム・ホスト名検証を使用するには、weblogic.security.SSL.HostnameVerifierインタフェースを実装するクラスを作成し、サーバーのセキュリティIDに関する情報を取得するメソッドを定義します。

注意:

このインタフェースは新しいスタイルの証明書を受け取り、非推奨になったweblogic.security.SSL.HostnameVerifierJSSEインタフェースにかわるものです。

カスタム・ホスト名検証を使用する前に、以下の方法で実装するクラスを指定する必要があります。

- 管理コンソールで、サーバー構成の「SSL」タブの「詳細」にある「カスタム・ホスト名の検証」フィールドに、このインタフェースを実装するクラスの名前を指定します。指定するクラスには、引数を取らないパブリック・コンストラクタが必要です。

- コマンド・ラインに、次の引数を入力します。

-Dweblogic.security.SSL.hostnameVerifier=hostnameverifier

hostnameverifierの値は、カスタム・ホスト名検証を実装するクラスの名前です。

例5-6は、NulledHostnameVerifierサンプルの抜粋です。このサンプルは、NulledHostnameVerifier.javaファイルのSAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリにあります。このサンプル・コードには、比較のために常にtrueを返すNulledHostnameVerifierクラスが含まれています。このサンプルでは、WebLogic SSLクライアントは、サーバーのホスト名とデジタル証明書のSubjectDNとの比較に関係なく、どのSSLサーバーにも接続できます。

例5-6 ホスト名検証のサンプル・コードの抜粋

public class NulledHostnameVerifier implements
weblogic.security.SSL.HostnameVerifier {
public boolean verify(String urlHostname, javax.net.ssl.SSLSession session) {
return true;
}
}

トラスト・マネージャの使い方

weblogic.security.SSL.TrustManagerインタフェースは以下を可能にします。

- 特定の証明書検証エラーを無視します

- ピア証明書チェーンに対して追加の検証を実行します

注意:

このインタフェースは新しいスタイルの証明書を受け取り、非推奨になったweblogic.security.SSL.TrustManagerJSSEインタフェースにかわるものです。

SSLクライアントがWebLogic Serverのインスタンスに接続すると、サーバーは認証のためにデジタル証明書チェーンをクライアントに提示します。提示されたチェーンに無効なデジタル証明書が含まれている場合もあります。SSL仕様では、クライアントが無効な証明書を検出した場合、SSL接続が中断されることになっています。TrustManagerインタフェースのカスタム実装を使用すると、どのような場合にSSLハンドシェークを継続するか(または中止するか)を制御できます。トラスト・マネージャを使用することで、特定の検証エラーを無視(必要に応じてカスタム検証チェックを実行)してから、ハンドシェークを継続するかどうかを決定できます。

トラスト・マネージャを作成するには、weblogic.security.SSL.TrustManagerインタフェースを使用します。このインタフェースには、証明書検証で使用する一連のエラー・コードが含まれています。また、必要に応じて、ピア証明書での付加的な検証を実行したり、SSLハンドシェークを中断したりできます。デジタル証明書の検証が済むと、weblogic.security.SSL.TrustManagerインタフェースがコールバック関数を使用して、デジタル証明書の検証結果をオーバーライドします。トラスト・マネージャのインスタンスは、setTrustManager()メソッドを使用してSSLコンテキストに関連付けることができます。

トラスト・マネージャはプログラムでのみ設定できます。その使用は、管理コンソールやコマンド・ラインでは定義できません。

注意:

実行する検証によっては、トラスト・マネージャを使用するとパフォーマンスに影響します。

例5-7は、NulledTrustManagerサンプルの抜粋です。このサンプルは、NulledTrustManager.java ファイルのSAMPLES_HOME\server\examples\src\examples\security\sslclient ディレクトリにあります。SSLSocketClientサンプルでは、カスタム・トラスト・マネージャを使用します。SSLSocketClientでは、トラスト・マネージャでSSLコンテキストを使用して新しいSSL接続を設定する方法が示されています。

例5-7 NulledTrustManagerサンプル・コードの抜粋

package examples.security.sslclient;

import weblogic.security.SSL.TrustManager;
import java.security.cert.X509Certificate;
...
public class NulledTrustManager implements TrustManager{
public boolean certificateCallback(X509Certificate[] o, int validateErr) {
System.out.println(" --- Do Not Use In Production ---\n" +
" By using this NulledTrustManager, the trust in" +
" the server's identity is completely lost.\n" +                           " --------------------------------");
for (int i=0; i<o.length; i++)
System.out.println(" certificate " + i + " -- " + o[i].toString());
return true;
}
}

証明書パス・トラスト・マネージャの使い方

CertPathTrustManager(weblogic.security.SSL.CertPathTrustManager)は、デフォルトのセキュリティ・レルムの構成済み証明書パス検証プロバイダを使用して、失効チェックなどの追加的な検証を実行します。

デフォルトでは、サーバーのアウトバウンドSSLで使用するアプリケーション・コードからは、組込みのSSL証明書検証にしかアクセスできません。しかし、管理者がサーバーに構成した追加の証明書検証にアクセスするために、アプリケーション・コードでCertPathTrustManagerを指定することは可能です。アプリケーション・コードにおいて証明書パス検証プロバイダも実行する場合は、アプリケーション・コードでCertPathTrustManagerを使用する必要があります。

このクラスは、以下の3つの方法で使用できます。

- アウトバウンドSSLで検証プロバイダを使用することを示すスイッチがSSLMBeanに設定されている場合にのみ、Trust Managerが構成済みのCertPathValidatorsを呼び出します。つまり、管理者が構成したものに、検証を完全に委任することになります。この方法には、setUseConfiguredSSLValidation()メソッドを使用します。これがデフォルトです。

- Trust Managerが常に構成済みのCertPathValidatorsを呼び出します。この方法には、setBuiltinSSLValidationAndCertPathValidators()メソッドを使用します。

- Trust Managerは構成済みのCertPathValidatorsを呼び出しません。この方法には、setBuiltinSSLValidationOnly()メソッドを使用します。

ハンドシェーク完了リスナーの使い方

javax.net.ssl.HandshakeCompletedListenerは、指定されたSSL接続に対するSSLプロトコル・ハンドシェークの完了についてSSLクライアントが通知を受け取る方法を定義します。例5-8は、MyListenerサンプルの抜粋です。このサンプルは、MyListener.javaファイルのSAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリにあります。

例5-8 MyListener (HandshakeCompletedListener)サンプル・コードの抜粋

package examples.security.sslclient;

import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.FileInputStream;
import javax.net.ssl.HandshakeCompletedListener;
import java.util.Hashtable;
import javax.net.ssl.SSLSession;
...
public class MyListener implements HandshakeCompletedListener
{
public void handshakeCompleted(javax.net.ssl.HandshakeCompletedEvent
event)
{
SSLSession session = event.getSession();
System.out.println("Handshake Completed with peer " +
session.getPeerHost());
System.out.println("   cipher: " + session.getCipherSuite());
Certificate[] certs = null;
try
{
certs = session.getPeerCertificates();
}
catch (SSLPeerUnverifiedException puv)
{
certs = null;
}
if  (certs != null)
{
System.out.println("   peer certificates:");
for (int z=0; z<certs.length; z++)
System.out.println("      certs["+z+"]: " + certs[z]);
}
else
{
System.out.println("No peer certificates presented");
}
}
}

SSLContextの使い方

SSLContextクラスを使用すると、SSLをプログラムによって構成し、SSLセッション情報を保持できます。各インスタンスは、認証の実行に使用するキー、証明書チェーン、および信頼性のあるCA証明書を使用して構成できます。同じSSLContextで作成し、同じSSLサーバーへの接続に使用するSSLソケットは、SSLセッション情報を再利用できます。セッション情報が実際に再利用されるかどうかは、SSLサーバーによって異なります。

セッション・キャッシングの詳細は、『Oracle WebLogic Serverの保護』のSSLセッションの動作に関する項を参照してください。トラスト・マネージャ・クラスのインスタンスをSSLコンテキストと関連付けるには、weblogic.security.SSL.SSLContext.setTrustManager()メソッドを使用します。

SSLコンテキストは、プログラムでのみ設定できます。管理コンソールやコマンド・ラインでは設定できません。SSLContextオブジェクトは、Javaのnew式またはSSLContextクラスのgetInstance()メソッドで作成できます。getInstance()メソッドは静的で、指定されたセキュア・ソケット・プロトコルを実装する新しいSSLContextオブジェクトを生成します。SSLContextクラスの使用例は、SAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリのSSLSocketClient.javaのサンプルで提供されています。SSLSocketClientサンプルでは、SSLContextを使って新しいSSLソケットを作成する新しいSSLソケット・ファクトリを作成する方法が示されています。

例5-9は、getInstance()メソッドを使用したインスタンス化のサンプルです。

例5-9 SSLコンテキストのサンプル・コード

import weblogic.security.SSL.SSLContext;
SSLcontext sslctx = SSLContext.getInstance ("https")

URLを使用したアウトバウンドSSL接続

URLオブジェクトを使用すると、クライアントとして機能しているWebLogic Serverインスタンスから別のWebLogic ServerインスタンスへのアウトバウンドSSL接続を確立することができます。WebLogic Serverは、アウトバウンドSSL接続について一方向と双方向のSSL認証を両方ともサポートしています。

一方向SSL認証の場合は、java.net.URL、java.net.URLConnection、およびjava.net.HTTPURLConnectionクラスを使用して、URLオブジェクトを使用するアウトバウンドSSL接続を確立します。例5-10は、HTTPおよびHTTPSのURLを両方ともサポートし、これらのJavaクラスのみを使用する(つまりWebLogicクラスは不要)simpleURLクラスを示しています。WebLogic Serverで一方向SSL認証(HTTPS)にsimpleURLクラスを使用するための必要条件は、java.protocols.handler.pkgsのシステム・プロパティで「weblogic.net」が定義されていることだけです。

注意:

例5-10 simpleURLサンプルは、デフォルトで信頼性とホスト名をチェックするため、このサンプルでは信頼されていてホスト名チェックを通過する実際のWebサーバーにデフォルトで接続する必要があります。そうしない場合は、コマンド・ライン上で信頼性とホスト名チェックをオーバーライドする必要があります。

例5-10 Javaクラスのみを使用する一方向SSL認証URLアウトバウンドSSL接続クラス

import java.net.URL;
import java.net.URLConnection;
import java.net.HttpURLConnection;
import java.io.IOException;
public class simpleURL
{
public static void main (String [] argv)
{
if (argv.length != 1)
{
System.out.println("Please provide a URL to connect to");
System.exit(-1);
}
setupHandler();
connectToURL(argv[0]);
}
private static void setupHandler()
{
java.util.Properties p = System.getProperties();
String s = p.getProperty("java.protocol.handler.pkgs");
if (s == null)
s = "weblogic.net";
else if (s.indexOf("weblogic.net") == -1)
s += "|weblogic.net";
p.put("java.protocol.handler.pkgs", s);
System.setProperties(p);
}
private static void connectToURL(String theURLSpec)
{
try
{
URL theURL = new URL(theURLSpec);
URLConnection urlConnection = theURL.openConnection();
HttpURLConnection connection = null;
if (!(urlConnection instanceof HttpURLConnection))
{
System.out.println("The URL is not using HTTP/HTTPS: " +
theURLSpec);
return;
}
connection = (HttpURLConnection) urlConnection;
connection.connect();
String responseStr = "\t\t" +
connection.getResponseCode() + " -- " +
connection.getResponseMessage() + "\n\t\t" +
connection.getContent().getClass().getName() + "\n";
connection.disconnect();
System.out.println(responseStr);
}
catch (IOException ioe)
{
System.out.println("Failure processing URL: " + theURLSpec);
ioe.printStackTrace();
}
}
}

双方向SSL認証の場合は、weblogic.net.http.HttpsURLConnectionクラスを使用して、秘密鍵とデジタル証明書を含む、クライアントのセキュリティ・コンテキスト情報を指定できます。このクラスのインスタンスは、リモート・オブジェクトに対するHTTPS接続を表しています。

SSLClientサンプル・コード(例5-11)には、WebLogic URLオブジェクトを使用して、アウトバウンドSSL接続を確立する方法が示されています。例5-11のサンプル・コードは、SAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリのSSLClient.javaファイルからの抜粋です。

例5-11 WebLogic双方向SSL認証URLアウトバウンドSSL接続のサンプル・コード

wlsUrl = new URL("https", host, Integer.valueOf(sport).intValue(),
query);
weblogic.net.http.HttpsURLConnection sconnection =
new weblogic.net.http.HttpsURLConnection(wlsUrl);
...
InputStream [] ins = new InputStream[2];
ins[0] = new FileInputStream("clientkey.pem");
ins[1] = new FileInputStream("client2certs.pem");
String pwd = "clientkey";
sconnection.loadLocalIdentity(ins[0], ins[1], pwd.toCharArray());

SSLクライアントのサンプル・コード

WebLogic Serverソフトウェアには、完全な実践的SSL認証サンプルが付属しています。そのサンプルは、SAMPLES_HOME\server\examples\src\examples\security\sslclientディレクトリにあります。このサンプルの説明と、構築、構成、および実行の手順については、サンプル・ディレクトリのpackage.htmlファイルを参照してください。このサンプル・コードは、修正して再利用できます。

6 Enterprise JavaBeans (EJB)の保護

この項では、EJBの保護について説明します。

WebLogic Serverは、Enterprise JavaBeans (EJB)を保護するJava EEアーキテクチャ・セキュリティ・モデルをサポートしています。これには、宣言による認可(このドキュメントでは宣言によるセキュリティとも呼びます)とプログラムによる認可(このドキュメントではプログラムによるセキュリティとも呼びます)のサポートが含まれます。

この節では、以下の内容について説明します。

- Java EEアーキテクチャ・セキュリティ・モデル

- EJBでの宣言によるセキュリティの使用

- EJBのセキュリティ関連のデプロイメント記述子

- EJBでのプログラムによるセキュリティの使用

注意:

EJBの保護には、メタデータ・アノテーション、デプロイメント記述子ファイル、管理コンソールおよびJACCを使用できます。管理コンソールを使用したEJBの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。JACCの詳細は、「Java Authorization Contract for Containersの使用」を参照してください。

Java EEアーキテクチャ・セキュリティ・モデル

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3 Authorization」に次のような記述があります。

「J2EEアーキテクチャにおいて、コンテナはホストするコンポーネントとその呼出し側との間の認可境界として機能します。認可境界はコンテナの認証境界内に存在するので、正常に認証が実行される中で認可が考慮されます。着信呼出しの場合、コンテナは呼出し側の資格証明のセキュリティ属性と、ターゲット・コンポーネントのアクセス制御ルールを比較します。ルール要件が満たされていれば、呼出しは許可されます。それ以外の場合、この呼出しは拒否されます。

「アクセス制御ルールの定義には、能力と許可という2つの基本的アプローチが存在します。能力は呼出し側が実行できる操作、許可は操作を実行できるユーザーを焦点とします。許可では、何かをできるのは誰かに重点が置かれます。J2EEアプリケーション・プログラミング・モデルは、許可に焦点を当てます。J2EEアーキテクチャにおいて、デプロイヤの役割は、アプリケーションの許可モデルをその操作環境におけるユーザーの能力にマップすることです。」

同じドキュメントでは続けて、Java EEアーキテクチャを使用してアプリケーション・リソースへのアクセスを制御する2つの方法 - 宣言による認可とプログラムによる認可 - について説明しています。

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。

宣言による認可

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.1 Authorization」に次のような記述があります。

「デプロイヤは、J2EEアプリケーションと関連のコンテナによって実施されるアクセス制御ルールを設定します。デプロイヤは、デプロイメント・ツールを使用して、通常はアプリケーション・アセンブラによって供給されるアプリケーション許可モデルを、操作環境に固有のポリシーおよびメカニズムにマップします。アプリケーション許可モデルは、デプロイメント記述子で定義されます。」

WebLogic ServerはEJBにおいて宣言による認可を実装するためのデプロイメント記述子の使用をサポートしています。

注意:

宣言による認可は、このドキュメントでは宣言によるセキュリティとも呼ばれます。

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。

アノテーションを使用した宣言による認可

EJB 3.xでは、デプロイヤのタスクをより簡単にするために、アプリケーション開発者がセキュリティ・ロールを定義できます。開発者は、セキュリティ・メタデータ・アノテーションをEJB Beanクラスに直接指定して、EJBのすべてのメソッドまたはそのサブセットを呼び出すことができるロールを特定できます。

『Java EE 6 Tutorial』の「Securing an Enterprise Bean Using Declarative Security」で説明されているように、宣言によるセキュリティを使用すると、アプリケーション開発者はどのユーザーがエンタープライズBeanのどのメソッドにアクセスできるかを指定できます。また、これらのユーザーをBASIC認証またはユーザー名とパスワードの認証によって認証することもできます。多くの場合、エンタープライズ・アプリケーションの開発者は、そのアプリケーションのデプロイヤとは異なります。宣言によるセキュリティを使用してメソッドのパーミッションと認証メカニズムを定義するアプリケーション開発者は、EJB JARに含まれるエンタープライズBeanのセキュリティに関する見解をデプロイヤに伝えます。セキュリティに関する見解がデプロイヤに伝えられると、デプロイヤはこの情報に基づいてセキュリティ・ロールのメソッドのパーミッションを定義します。セキュリティに関する見解が定義されていない場合、デプロイヤは、どのユーザーに各ビジネス・メソッドの呼び出しを認可するかを決定するために、そのメソッドでどのような処理が実行されるかを確認する必要があります。

デプロイメントの実行時、デプロイヤはこれらのセキュリティ・ロールが存在しない場合は作成し、それらのロールにユーザーをマップします。このマッピングは、WebLogic Server管理コンソールでセキュリティ・レルムを更新することによって行います。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。デプロイヤは、weblogic-ejb-jar.xmlデプロイメント記述子を使用して、任意のセキュリティ・ロールをユーザーにマップすることもできます。

注意:

デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。

プログラムによる認可

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.2 Programmatic Authorization」に次のような記述があります。

「J2EEコンテナは、コンポーネントにメソッド呼出しをディスパッチする前に、アクセス制御の決定を行います。コンポーネントの論理または状態は、これらのアクセス決定を考慮に入れません。しかし、コンポーネントはEJBContext.isCallerInRole(エンタープライズBeanコード用)およびHttpServletRequest.isUserInRole(Webコンポーネント用)の2つのメソッドを使用して、きめ細かいアクセス制御を行うことが可能です。コンポーネントはこれらのメソッドを使用して、呼出しのパラメータ、コンポーネントの初期状態、または呼出しの時間などその他の要因に基づき、コンポーネントによって選択された権限が呼出し側に付与されているかどうかを判断します。

「これらの機能の1つを呼び出すコンポーネントのアプリケーション・コンポーネント・プロバイダは、すべての呼出しで使用されるあらゆる個別のroleName値を宣言する必要があります。これらの宣言は、デプロイメント記述子ではsecurity-role-ref要素として登場します。各security-role-ref要素は、アプリケーションにroleNameとして組み込まれた権限名をセキュリティ・ロールにリンクします。最終的には、デプロイヤはアプリケーションに組み込まれた権限名と、デプロイメント記述子で定義されたセキュリティ・ロールとの間のリンクを確立します。権限名とセキュリティ・ロールの間のリンクは、同じアプリケーション内でもコンポーネントごとに異なる場合があります。

「特定の権限をテストするだけでなく、アプリケーション・コンポーネントではEJBContext.getCallerPrincipalまたはHttpServletRequest.getUserPrincipalを使用して取得した呼出し側IDと、作成時の状態のコンポーネントに組み込まれている識別された呼出し側IDを比較できます。呼出し側IDが、識別された呼出し側IDに等しければ、コンポーネントは呼出し側に処理の続行を許可できます。等しくなければ、コンポーネントは呼出し側がそれ以上の対話を行わないようにできます。コンテナによって返される呼出し側のプリンシパルは、呼出し側が使用した認証メカニズムによって決まります。また、同じメカニズムによる同じユーザー認証に対してでも、異なったベンダーからのコンテナは異なったプリンシパルを返す場合があります。プリンシパルの形式の変動性を考慮に入れるため、コンポーネントのアクセス決定に識別された呼出し側の状態を適用することを選択した開発者は、同一ユーザーを表す複数の識別された呼出し側IDがコンポーネントと関連付けられることを許容する必要があります。これは特に、アプリケーションの柔軟性や移植性が優先される場合に、推奨されます。

WebLogic Serverは、EJBにおけるプログラムによる認可を実装するために、EJBContext.isCallerInRoleメソッドとEJBContext.getCallerPrincipalメソッドの使用、およびデプロイメント記述子でのsecurity-role-ref要素の使用をサポートしています。

注意:

プログラムによる認可は、このドキュメントではプログラムによるセキュリティとも呼ばれます。

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。

宣言による認可とプログラムによる認可

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.3 Declarative Versus Programmatic Authorization」に次のような記述があります。

「デプロイヤによって構成される外部アクセス制御ポリシーと、コンポーネント・プロバイダによってアプリケーションに組み込まれた内部ポリシーとの間にはトレードオフが存在します。アプリケーションが作成された後では、外部ポリシーのほうが高い融通性を持ちます。アプリケーションが記述されている過程では、内部ポリシーのほうが融通性の高い機能を提供します。また、外部ポリシーはデプロイヤにとって透過的で完全に理解可能であるのに対し、内部ポリシーはアプリケーションに埋め込まれており、これを完全に理解できるのはアプリケーション開発者のみである可能性があります。ある特定のコンポーネントとメソッドについて認可モデルを選択する際には、これらのトレードオフを検討する必要があります。

ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。

「アノテーションを使用した宣言による認可」で説明しているように、アプリケーション開発者は、デプロイヤのタスクをより簡単にするために、セキュリティ・メタデータ・アノテーションをEJB Beanクラスに直接指定して、EJBのすべてのメソッドまたはそのサブセットを呼び出すことができるロールを特定できます。ただし、デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドするため、デプロイヤが最終的な制御を行います。

EJBでの宣言によるセキュリティの使用

宣言によるセキュリティは、以下の3つの方法で実装できます。

1. 管理コンソールを介したセキュリティ・プロバイダ: 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明されています。

2. JACC (Java Authorization Contract for Containers): 「Java Authorization Contract for Containersの使用」で説明されています。

3. デプロイメント記述子およびメタデータ・アノテーション: ここで説明します。

これら3つのうちどの方法を使用するかは、JACCフラグとセキュリティ・モデルによって定義されます。(セキュリティ・モデルについては、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。)

メタデータ・アノテーションを使用した宣言によるセキュリティの実装

EJB 3.0の新機能と変更点に関する項で説明されているように、デプロイメント記述子ファイル(ejb-jar.xmlなど)を作成する必要がなくなりました。Beanファイル自体の中で、メタデータ・アノテーションを使用してメタデータを構成できます。

必要に応じて、引き続きXMLデプロイメント記述子をメタデータ・アノテーションに加えて、またはそのかわりに使用することもできます。

注意:

デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。

メタデータ・アノテーションを使用するには:

1. メタデータ・アノテーション機能を使用して、アノテーション付きのEJB Beanファイルを作成します。

2. デプロイメントの実行時、デプロイヤはこれらのセキュリティ・ロールが存在しない場合は作成し、それらのロールにユーザーをマップする必要があります。このマッピングは、WebLogic Server管理コンソールでセキュリティ・レルムを更新することによって行います。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。

アノテーションはjavax.security.annotationパッケージに含まれています。次のセキュリティ関連アノテーションを使用できます。

- javax.annotation.security.DeclareRoles - EJBの保護に使用するセキュリティ・ロールのリストを明示的に宣言します。

- javax.annotation.security.RolesAllowed - EJBのメソッドを呼び出すことができるセキュリティ・ロールを指定します。すべてのメソッドを呼び出すことができるロールはクラス・レベルで指定し、特定のメソッドのみを呼び出すことができるロールはメソッド・レベルで指定します。

- javax.annotation.security.DenyAll - どのロールでも呼び出すことができないメソッドを指定します。

- javax.annotation.security.PermitAll - どのロールでも呼び出すことができるメソッドを指定します。

- javax.annotation.security.RunAs - EJBを実行するロールを指定します。デフォルトでは、EJBはそれを実際に呼び出したユーザーとして実行されます。

セキュリティ関連アノテーションのコード例

『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEJBへのアクセスの保護に関する項では、すべてのセキュリティ関連アノテーションを使用する単純なステートレス・セッションEJBの例が示されています。

『Java EE 6 Tutorial』の「Specifying Authorized Users by Declaring Security Roles」では、アノテーションを使用してBeanクラスのメソッドに関するメソッド・パーミッションを指定する方法の説明、およびそれに付随するコード例も提供されます。

デプロイメント記述子を使用した宣言によるセキュリティの実装

EJBに宣言によってセキュリティを実装するには、デプロイメント記述子(ejb-jar.xmlおよびweblogic-ejb-jar.xml)を使用してセキュリティ要件を定義します。例6-1は、ejb-jar.xmlおよびweblogic-ejb-jar.xmlデプロイメント記述子を使用してセキュリティ・ロール名をセキュリティ・レルムにマップする例を示しています。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、EJBコンテナがセキュリティ定義を使って要件を実施します。

EJBデプロイメント記述子でセキュリティを構成するには、次の手順を実行します(例6-1を参照):

1. テキスト・エディタを使用して、ejb-jar.xmlおよびweblogic-ejb-jar.xmlデプロイメント記述子ファイルを作成します。

2. ejb-jar.xmlファイルに、ロール名、EJB名、およびメソッド名を定義します(太字テキストを参照)。

注意:

セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken)。

セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。

- スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。

- セキュリティ・ロール名では大文字と小文字が区別されます。

- 推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。

ejb-jar.xmlファイルでセキュリティを構成する方法の詳細は、Enterprise JavaBeans仕様2.0(http://java.sun.com/products/ejb/docs.html)を参照してください。

3. WebLogic固有のEJBデプロイメント記述子ファイルweblogic-ejb-jar.xmlにセキュリティ・ロール名を定義し、それをセキュリティ・レルム内の1つまたは複数のプリンシパル(ユーザーまたはグループ)にリンクします。
weblogic-ejb-jar.xmlファイルでセキュリティを構成する方法の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスに関する項を参照してください。

例6-1 ejb-jar.xmlおよびweblogic-ejb-jar.xmlファイルを使用したセキュリティ・ロール名とセキュリティ・レルムのマッピング

ejb-jar.xml entries:
...
<assembly-descriptor>
<security-role>
<role-name>manger</role-name>
</security-role>
<security-role>
<role-name>east</role-name>
</security-role>
<method-permission>
<role-name>manager</role-name>
<role-name>east</role-name>
<method>
<ejb-name>accountsPayable</ejb-name>
<method-name>getReceipts</method-name>
</method>
</method-permission>
...
</assembly-descriptor>
...
weblogic-ejb-jar.xml entries:
<security-role-assignment>
<role-name>manager</role-name>
<principal-name>al</principal-name>
<principal-name>george</principal-name>
<principal-name>ralph</principal-name>
</security-role-assignment>
...

EJBのセキュリティ関連のデプロイメント記述子

以下のトピックでは、EJBのセキュリティ要件を定義するためにejb-jar.xmlおよびweblogic-ejb-jar.xmlファイルで使用されるデプロイメント記述子の要素について説明します。

- ejb-jar.xmlデプロイメント記述子

- weblogic-ejb-jar.xmlデプロイメント記述子

ejb-jar.xmlデプロイメント記述子

以下のejb-jar.xmlデプロイメント記述子の要素が、WebLogic Serverでセキュリティ要件を定義するために使用されます。

- method

- method-permission

- role-name

- run-as

- security-identity

- security-role

- security-role-ref

- unchecked

- use-caller-identity

method

method要素は、エンタープライズBeanのホームまたはコンポーネント・インタフェースのメソッド、あるいはメッセージドリブンBeanの場合にBeanのonMessageメソッド(またはメソッドのセット)を示すために使用されます。

次の表では、method要素内で定義できる要素について説明します。

表6-1 method要素

要素

必須/省略可能

説明

<description>

省略可能

メソッドの説明文。

<ejb-name>

必須

ejb-jar.xmlファイルで宣言されているエンタープライズBeanのいずれかの名前を指定します。

<method-intf>

省略可能

エンタープライズBeanのホーム・インタフェースとコンポーネント・インタフェースの両方で定義されて同じ署名を持つメソッドを識別できるようにします。

<method-name>

必須

エンタープライズBeanのメソッド名またはアスタリスク(*)を指定します。アスタリスクは、要素がエンタープライズBeanのコンポーネントおよびホーム・インタフェースのすべてのメソッドを表す場合に使用します。

<method-params>

省略可能

Javaタイプのメソッド・パラメータの完全修飾名のリストが含まれます。

使用される場所

method要素は、method-permission要素内で使用されます。

例

method要素の使用例については、例6-1を参照してください。

method-permission

method-permission要素では、1つまたは複数のエンタープライズBeanメソッドの呼出しを許可されている1つまたは複数のセキュリティ・ロールを指定します。method-permission要素は、説明(オプション)、セキュリティ・ロール名のリストまたはメソッドが認可に関してチェックされない状態を示すインジケータ、およびメソッドの要素のリストから成ります。

method-permission要素内のセキュリティ・ロールは、デプロイメント記述子のsecurity-role要素で定義されており、メソッドは、エンタープライズBeanのコンポーネントまたはホーム・インタフェースで定義されているメソッドでなければなりません。

次の表では、method-permission要素内で定義できる要素について説明します。

表6-2 method-permission要素

要素

必須/省略可能

説明

<description>

省略可能

このセキュリティ制約の説明文。

<role-name> or <unchecked>

必須

role-name要素またはunchecked要素を指定する必要があります。

role-name要素には、セキュリティ・ロールの名前が含まれます。この名前は、NMTOKENの命名規則に準拠する必要があります。

unchecked要素には、メソッドがメソッド呼出しの前に認可のチェックを受けないことを指定します。

<method>

必須

エンタープライズBeanのホームまたはコンポーネント・インタフェースのメソッド、あるいはメッセージドリブンBeanの場合にBeanのonMessageメソッド(またはメソッドのセット)を指定します。

使用される場所

method-permission要素は、assembly-descriptor要素内で使用されます。

例

method-permission要素の使用例については、例6-1を参照してください。

role-name

role-name要素には、セキュリティ・ロールの名前が含まれます。この名前は、NMTOKENの命名規則に準拠する必要があります。

使用される場所

role-name要素は、method-permission、run-as、security-role、およびsecurity-role-ref要素内で使用されます。

例

role-name要素の使用例については、例6-1を参照してください。

run-as

run-as要素には、エンタープライズBeanを実行するためのrun-as IDを指定します。この要素には、省略可能な説明とセキュリティ・ロールの名前が含まれます。

使用される場所

run-as要素は、security-identity要素内で使用されます。

例

run-as要素の使用例については、例6-8を参照してください。

security-identity

security-identity要素には、エンタープライズBeanのメソッドを実行するために呼出し側のセキュリティIDを使用するか、または特定のrun-as IDを使用するかを指定します。この要素には、省略可能な説明と使用するセキュリティIDの指定が含まれます。

次の表では、security-identity要素内で定義できる要素について説明します。

表6-3 security-identity要素

要素

必須/省略可能

説明

<description>

省略可能

セキュリティIDの説明文。

<use-caller-identity> or <run-as>

必須

use-caller-identity要素またはrun-as要素を指定する必要があります。。

use-caller-identity要素には、エンタープライズBeanのメソッドを実行するためのセキュリティIDとして、呼出し側のセキュリティIDを使用することを指定します。

run-as要素には、エンタープライズBeanを実行するためのrun-as IDを指定します。この要素には、省略可能な説明とセキュリティ・ロールの名前が含まれます。

使用される場所

security-identity要素は、entity、message-driven、およびsession要素内で使用されます。

例

security-identity要素の使用例については、例6-3および例6-8を参照してください。

security-role

security-role要素には、セキュリティ・ロールの定義が指定されます。定義は、セキュリティ・ロールの説明(オプション)とセキュリティ・ロール名から成ります。

使用される場所

security-role要素は、assembly-descriptor要素内で使用されます。

例

assembly-descriptor要素の使用例については、例6-1を参照してください。

security-role-ref

security-role-ref要素には、エンタープライズBeanのコード内のセキュリティ・ロール参照の宣言が含まれます。この宣言は、省略可能な説明、コードで使用されているセキュリティ・ロール名、およびセキュリティ・ロールへのリンク(オプション)から成ります。セキュリティ・ロールが指定されていない場合、デプロイヤが適切なセキュリティ・ロールを選択する必要があります。

role-name要素の値は、EJBContext.isCallerInRole(String roleName)メソッドまたはHttpServletRequest.isUserInRole(String role)メソッドに対するパラメータとして使用されるStringでなければなりません。

使用される場所

security-role-ref要素は、entityおよびsession要素内で使用されます。

例

security-role-ref要素の使用例については、例6-2を参照してください。

例6-2 security-role-ref要素の例

<!DOC<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
<ejb-jar>
<enterprise-beans>
...
<session>
<ejb-name>SecuritySLEJB</ejb-name>
<home>weblogic.ejb20.security.SecuritySLHome</home>
<remote>weblogic.ejb20.security.SecuritySL</remote>
<ejb-class>weblogic.ejb20.security.SecuritySLBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<security-role-ref>
<role-name>rolenamedifffromlink</role-name>
<role-link>role121SL</role-link>
</security-role-ref>
<security-role-ref>
<role-name>roleForRemotes</role-name>
<role-link>roleForRemotes</role-link>
</security-role-ref>
<security-role-ref>
<role-name>roleForLocalAndRemote</role-name>
<role-link>roleForLocalAndRemote</role-link>
</security-role-ref>
</session>
...
</enterprise-beans>
</ejb-jar>

unchecked

unchecked要素には、メソッドがメソッド呼出しの前に認可のチェックを受けないことを指定します。

使用される場所

unchecked要素は、method-permission要素内で使用されます。

例

unchecked 要素の使用例については、例6-1を参照してください。

use-caller-identity

use-caller-identity要素には、エンタープライズBeanのメソッドを実行するためのセキュリティIDとして、呼出し側のセキュリティIDを使用することを指定します。

使用される場所

use-caller-identity要素は、security-identity要素内で使用されます。

例

use-caller-identity要素の使用例については、例6-3を参照してください。

例6-3 use-caller-identity要素の例

<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>SecurityEJB</ejb-name>
<home>weblogic.ejb20.SecuritySLHome</home>
<remote>weblogic.ejb20.SecuritySL</remote>
<local-home>
weblogic.ejb20.SecurityLocalSLHome
</local-home>
<local>weblogic.ejb20.SecurityLocalSL</local>
<ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
<message-driven>
<ejb-name>SecurityEJB</ejb-name>
<ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class>
<transaction-type>Container</transaction-type>
<security-identity>
<use-caller-identity/>
</security-identity>
</message-driven>
</enterprise-beans>
</ejb-jar>

weblogic-ejb-jar.xmlデプロイメント記述子

以下のweblogic-ejb-jar.xmlデプロイメント記述子の要素が、WebLogic Serverでセキュリティ要件を定義するために使用されます。

- client-authentication

- client-cert-authentication

- confidentiality

- externally-defined

- identity-assertion

- iiop-security-descriptor

- integrity

- principal-name

- role-name

- run-as-identity-principal

- run-as-principal-name

- run-as-role-assignment

- security-permission

- security-permission-spec

- security-role-assignment

- transport-requirements

client-authentication

client-authentication要素は、EJBがクライアント認証をサポートするか、または、必要とするかを指定します。

次の表では、指定可能な設定を定義しています。

表6-4 client-authentication要素

設定

定義

none

クライアント認証はサポートされません。

supported

クライアント認証はサポートされますが、必須ではありません。

required

クライアント認証は必須となります。

例

client-authentication要素の使用例については、例6-6を参照してください。

client-cert-authentication

client-cert-authentication要素は、EJBがトランスポート・レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。

次の表では、指定可能な設定を定義しています。

表6-5 client-cert-authentication要素

設定

定義

none

クライアント証明書認証はサポートされません。

supported

クライアント証明書認証はサポートされますが、必須ではありません。

required

クライアント証明書認証は必須となります。

例

client-cert-authentication要素の使用例については、例6-10を参照してください。

confidentiality

confidentiality要素は、そのEJBにおけるトランスポートの機密性の要件を指定します。confidentiality 要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバー間でデータが送信されるようになります。

次の表では、指定可能な設定を定義しています。

表6-6 confidentiality要素

設定

定義

none

機密性はサポートされません。

supported

機密性はサポートされますが、必須ではありません。

required

機密性は必須となります。

例

confidentiality要素の使用例については、例6-10を参照してください。

externally-defined

externally-defined要素を使用すると、weblogic-ejb-jar.xmlデプロイメント記述子のrole-name要素によって定義されたセキュリティ・ロールが管理コンソールで指定したマッピングを使用するよう指定できます。この要素を使用することで、特定のWebアプリケーションのデプロイメント記述子に定義されたセキュリティ・ロールごとに特定のセキュリティ・ロール・マッピングを指定する必要がなくなります。このため、同じセキュリティ・レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、管理コンソールを使用して他のアプリケーションのセキュリティを指定および変更できます。

注意:

バージョン9.0からは、何も指定されていない場合は空のロール・マッピングが作成されるのが、ロール・マッピングのデフォルト動作になりました。バージョン8.1のEJBでは、ロール・マッピングをweblogic-ejb-jar.xml記述子に定義しないと、デプロイメントに失敗していました。9.0では、空のロール・マッピングを作成する際のEJBとWebAppの動作の矛盾がなくなりました。

ロール・マッピングの動作および下位互換性の設定の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ロール・マッピングの組合せを有効化」設定の理解に関する項を参照してください。サーバーのロール・マッピングの動作は、管理コンソールでどのセキュリティ・デプロイメント・モデルを選択したかによって異なります。セキュリティ・デプロイメント・モデルの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。

セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。

- セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken)。

- スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。

- セキュリティ・ロール名では大文字と小文字が区別されます。

- 推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。

例6-4と例6-5は、weblogic-ejb-jar.xmlファイルでexternally-defined要素を使用する方法を比較して示しています。例6-5で、weblogic-ejb-jar.xml内の「manager」のexternally-defined 要素は、セキュリティがgetReceiptsメソッドにおいて正しく構成されるには管理コンソールでmanagerに対応するプリンシパルが作成される必要がある、ということを意味します。

例6-4 ejb-jar.xmlおよびweblogic-ejb-jar.xmlデプロイメント記述子を使用したEJBにおけるセキュリティ・ロールのマッピング

ejb-jar.xml entries:
...
<assembly-descriptor>
<security-role>
<role-name>manger</role-name>
</security-role>
<security-role>
<role-name>east</role-name>
</security-role>
<method-permission>
<role-name>manager</role-name>
<role-name>east</role-name>
<method>
<ejb-name>accountsPayable</ejb-name>
<method-name>getReceipts</method-name>
</method>
</method-permission>
...
</assembly-descriptor>
...
weblogic-ejb-jar.xml entries:
<security-role-assignment>
<role-name>manager</role-name>
<principal-name>joe</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Mary</principal-name>
...
</security-role-assignment>
...

例6-5 EJBデプロイメント記述子におけるロール・マッピング用のexternally-defined要素の使用

ejb-jar.xml entries:
...
<assembly-descriptor>
<security-role>
<role-name>manger</role-name>
</security-role>
<security-role>
<role-name>east</role-name>
</security-role>
<method-permission>
<role-name>manager</role-name>
<role-name>east</role-name>
<method>
<ejb-name>accountsPayable</ejb-name>
<method-name>getReceipts</method-name>
</method>
</method-permission>
...
</assembly-descriptor>
...
weblogic-ejb-jar.xml entries:
<security-role-assignment>
<role-name>manager</role-name>
<externally-defined/>
...
</security-role-assignment>
...

管理コンソールを使用したEJBのセキュリティ構成の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

identity-assertion

identity-assertion要素は、EJBがIDアサーションをサポートするかどうかを指定します。

次の表では、指定可能な設定を定義しています。

表6-7 identity-assertion要素

設定

定義

none

IDアサーションはサポートされません。

supported

IDアサーションはサポートされますが、必須ではありません。

required

IDアサーションは必須となります。

使用される場所

identity-assertion要素は、iiop-security-descriptor要素内で使用されます。

例

identity-assertion要素の使用例については、例6-6を参照してください。

iiop-security-descriptor

iiop-security-descriptor要素は、Beanレベルのセキュリティ構成パラメータを指定します。これらのパラメータにより、インターオペラブル・オブジェクト参照(IOR)に含まれるIIOPセキュリティ情報が決定します。

例

iiop-security-descriptor要素の使用例については、例6-6を参照してください。

例6-6 iiop-security-descriptor要素の例

<weblogic-enterprise-bean>
<iiop-security-descriptor>
<transport-requirements>
<confidentiality>supported</confidentiality>
<integrity>supported</integrity>
<client-cert-authorization>
supported
</client-cert-authentication>
</transport-requirements>
<client-authentication>supported<client-authentication>
<identity-assertion>supported</identity-assertion>
</iiop-security-descriptor>
</weblogic-enterprise-bean>

integrity

integrity要素は、そのEJBのトランスポートの整合性の要件を指定します。integrity要素を使用すると、クライアントとサーバー間で、データが途中で変更することなく転送されるようになります。

次の表では、指定可能な設定を定義しています。

表6-8 integrity要素

設定

定義

none

整合性はサポートされません。

supported

整合性はサポートされますが、必須ではありません。

required

整合性は必須となります。

使用される場所

integrity要素は、transport-requirements要素内で使用されます。

例

integrity要素の使用例については、例6-10を参照してください。

principal-name

Principal-name要素は、security-role-assignment要素で指定したロール名に適用する、ProductNameセキュリティ・レルム内のプリンシパルの名前を指定します。security-role-assignment要素には、最低1つのprincipalが必要です。各ロール名に対しては、複数のprincipal-nameを定義できます。

注意:

大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。

使用される場所

principal-name要素は、security-role-assignment要素内で使用されます。

例

principal-name要素の使用例については、例6-1を参照してください。

role-name

role-name要素は、EJBプロバイダが対応するejb-jar.xmlファイルで指定されたアプリケーション・ロール名を示します。スタンザの次のprincipal-name要素で、ProductNameプリンシパルを、指定したrole-nameにマップします。

使用される場所

role-name要素は、security-role-assignment要素内で使用されます。

例

role-name要素の使用例については、例6-1を参照してください。

run-as-identity-principal

run-as-identity-principal要素は、ejb-jarデプロイメント記述子で、security-identity run-as role-nameを指定したBeanのrun-asプリンシパルとして使用されるセキュリティ・プリンシパル名を指定します。run-as role-nameとrun-as-identity-principalまたはrun-as-principal-nameのマッピング方法については、「run-as-role-assignment」を参照してください。

注意:

非推奨: run-as-identity-principal要素はWebLogic Server 8.1で非推奨となりました。かわりにrun-as-principal-name要素を使用してください。

使用される場所

run-as-identity-principal要素は、run-as-role-assignment要素内で使用されます。

例

run-as-identity-principal要素を使用する例については、例6-7を参照してください。

例6-7 run-as-identity-principal要素の例

ebj-jar.xml:
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>Caller2EJB</ejb-name>
<home>weblogic.ejb11.security.CallerBeanHome</home>
<remote>weblogic.ejb11.security.CallerBeanRemote</remote>
<ejb-class>weblogic.ejb11.security.CallerBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
<ejb-ref><ejb-ref-name>Callee2Bean</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>weblogic.ejb11.security.CalleeBeanHome</home>
<remote>weblogic.ejb11.security.CalleeBeanRemote</remote>
</ejb-ref>
<security-role-ref>
<role-name>users1</role-name>
<role-link>users1</role-link>
</security-role-ref>
<security-identity>
<run-as>
<role-name>users2</role-name>
</run-as>
</security-identity>
</session>
</enterprise-beans>
</ejb-jar>
woblogic-ejb-jar.xml:
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>Caller2EJB</ejb-name>
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>Callee2Bean</ejb-ref-name>
<jndi-name>security.Callee2Bean</jndi-name>
</ejb-reference-description>
</reference-descriptor>
<run-as-identity-principal>wsUser3</run-as-identity-principal>
</weblogic-enterprise-bean>
<security-role-assignment>
<role-name>user</role-name>
<principal-name>wsUser2</principal-name>
<principal-name>wsUser3</principal-name>
<principal-name>wsUser4</principal-name>
</security-role-assignment>
</weblogic-ejb-jar>

run-as-principal-name

run-as-principal-name要素は、ejb-jarデプロイメント記述子で、security-identity run-as role-nameを指定したBeanのrun-asプリンシパルとして使用されるセキュリティ・プリンシパル名を指定します。run-as role-nameとrun-as-principal-nameのマッピング方法については、「run-as-role-assignment」を参照してください。

使用される場所

run-as-principal-name要素は、run-as-role-assignment要素内で使用されます。

例

run-as-principal-name要素の使用例については、例6-8を参照してください。

run-as-role-assignment

run-as-role-assignment要素は、ejb-jar.xmlファイルで指定される特定のsecurity-identity run-as role-nameをweblogic-ejb-jar.xmlファイルで指定されるrun-as-principal-nameにマップするために使用します。特定のrole-nameに対するrun-as-principal-name要素の値は、security-identityとして指定されたrole-nameを使用するejb-jar.xmlファイル内のすべてのBeanが対象となります。weblogic-ejb-jar.xmlファイルで指定したrun-as-principal-name要素の値は、そのBeanのweblogic-enterprise-bean要素の下でrun-as-principal-nameを指定することによって、個々のBeanレベルでオーバーライドできます。

注意:

特定のBeanに対して、run-as-principal-name要素がrun-as-role-assignment要素内またはBean固有のrun-as-principal-name要素内で指定されていない場合、EJBコンテナは、weblogic-enterprise-bean security-role-assignment要素内のセキュリティ・ユーザーの最初のprincipal-nameをrole-nameに対して選択し、そのprincipal-nameをrun-as-principal-nameとして使用します。

例

run-as-role-assignment要素の使用例については、例6-8を参照してください。

例6-8 run-as-role-assignment要素の例

In the ejb-jar.xml file:
// Beans "A_EJB_with_runAs_role_X" and "B_EJB_with_runAs_role_X"
// specify a security-identity run-as role-name "runAs_role_X".
// Bean "C_EJB_with_runAs_role_Y" specifies a security-identity
// run-as role-name "runAs_role_Y".
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>SecurityEJB</ejb-name>
<home>weblogic.ejb20.SecuritySLHome</home>
<remote>weblogic.ejb20.SecuritySL</remote>
<local-home>
weblogic.ejb20.SecurityLocalSLHome
</local-home>
<local>weblogic.ejb20.SecurityLocalSL</local>
<ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
<message-driven>
<ejb-name>SecurityEJB</ejb-name>
<ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class>
<transaction-type>Container</transaction-type>
<security-identity>
<run-as>
<role-name>runAs_role_X</role-name>
</run-as>
</security-identity>
<security-identity>
<run-as>
<role-name>runAs_role_Y</role-name>
</run-as>
</security-identity>
</message-driven>
</enterprise-beans>
</ejb-jar>

weblogic-ejb-jar file:

<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>A_EJB_with_runAs_role_X</ejb-name>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>B_EJB_with_runAs_role_X</ejb-name>
<run-as-principal-name>Joe</run-as-principal-name>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>C_EJB_with_runAs_role_Y</ejb-name>
</weblogic-enterprise-bean>
<security-role-assignment>
<role-name>runAs_role_Y</role-name>
<principal-name>Harry</principal-name>
<principal-name>John</principal-name>
</security-role-assignment>
<run-as-role-assignment>
<role-name>runAs_role_X</role-name>
<run-as-principal-name>Fred</run-as-principal-name>
</run-as-role-assignment>
</weblogic-ejb-jar>

例6-8の3つのBeanはそれぞれ、run asとして別々のプリンシパル名を選択します。

- A_EJB_with_runAs_role_X
このBeanのrun-as-role-nameはrunAs_role_Xです。使用するプリンシパルの名前のルックアップには、jarスコープの<run-as-role-assignment>マッピングが使用されます。<run-as-role-assignment>マッピングにより、<role-name> runAs_role_Xに対して、<run-as-principal-name> Fredを使用すべきであることが指定されます。したがって、使用されるプリンシパル名はFredです。

- B_EJB_with_runAs_role_X
このBeanのrun-as-role-nameもrunAs_role_Xです。このBeanは使用するプリンシパルの名前のルックアップにjarスコープの<run-as-role-assignment>を使用することはありません。なぜなら、この値はこのBeanの<weblogic-enterprise-bean> <run-as-principal-name>値であるJoeでオーバーライドされているからです。したがって、使用されるプリンシパル名はJoeです。

- C_EJB_with_runAs_role_Y
このBeanのrun-as-role-nameはrunAs_role_Yです。runAs_role_Yのrun-asプリンシパル名としての明示的なマッピングはありません。つまり、runAs_role_Yに対するjarスコープの<run-as-role-assignment>も、Beanスコープの<run-as-principal-name>も、このBeanの<weblogic-enterprise-bean>では指定されていません。使用するプリンシパル名を決定するには、<role-name> runAs_role_Yの<security-role-assignment>を検証します。ユーザー(つまり、グループではない)に対応する最初の<principal-name>が選択されます。したがって、使用されるプリンシパル名はHarryです。

security-permission

security-permission要素は、Java EE Sandboxと関連するセキュリティ許可を指定します。

例

security-permission要素の使用例については、例6-9を参照してください。

security-permission-spec

security-permission-spec要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ許可を指定します。

詳細は、セキュリティ・パーミッション仕様の実装を参照してください。

http://download.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#FileSyntax

注意:

オプションのcodebaseおよびsignedBy句は無視してください。

使用される場所

security-permission-spec要素は、security-permission要素内で使用されます。

例

security-permission-spec要素の使用例については、例6-9を参照してください。

例6-9 security-permission-spec要素の例

<weblogic-ejb-jar>
<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec>
<!
A single grant statement following the syntax of
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax,
without the codebase and signedBy clauses, goes here. For example:
-->
grant {
permission java.net.SocketPermission *, resolve;
};
</security-permission-spec>
</security-permission>
</weblogic-ejb-jar>

例6-9では、permission java.net.SocketPermissionは許可クラス名を、"*"はターゲット名を、resolve(host/IP名サービスのルックアップを解決する)はアクションを示します。

security-role-assignment

security-role-assignment要素は、ejb-jar.xmlファイル内のアプリケーション・ロールを、ProductNameで使用可能なセキュリティ・プリンシパル名にマップします。

注意:

エンタープライズ・アプリケーションのweblogic-application.xmlデプロイメント記述子でsecurity-role-assignment要素を使用する方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

例

security-role-assignment要素の使用例については、例6-1を参照してください。

transport-requirements

transport-requirements要素は、EJBのトランスポートの要件を定義します。

使用される場所

transport-requirements要素は、iiop-security-descriptor要素内で使用されます。

例

transport-requirements要素の使用例については、例6-10を参照してください。

例6-10 transport-requirements要素の例

<weblogic-enterprise-bean>
<iiop-security-descriptor>
<transport-requirements>
<confidentiality>supported</confidentiality>
<integrity>supported</integrity>
<client-cert-authorization>
supported
</client-cert-authentication>
</transport-requirements>
</iiop-security-descriptor>
<weblogic-enterprise-bean>

EJBでのプログラムによるセキュリティの使用

プログラムによるセキュリティをEJBに実装するには、javax.ejb.EJBContext.getCallerPrincipal()メソッドとjavax.ejb.EJBContext.isCallerInRole()メソッドを使用します。

getCallerPrincipal

getCallerPrincipal()メソッドは、EJBの呼出し側を特定するために使用します。javax.ejb.EJBContext.getCallerPrincipal()メソッドは、呼出し元のユーザーのSubjectに存在している場合にWLSUser Principalを返します。WLSUser Principalが複数の場合、このメソッドは、Subject.getPrincipals().iterator()メソッドで指定された順序の1番目を返します。WLSUser Principalが存在しない場合、getCallerPrincipal()メソッドはWLSGroup Principal以外の1番目を返します。Principalsが存在しない場合、またはすべてのPrincipalsがWLSGroup型の場合、このメソッドはweblogic.security.WLSPrincipals.getAnonymousUserPrincipal()を返します。この動作は、weblogic.security.SubjectUtils.getUserPrincipal()のセマンティクスとほぼ同じですが、EJBContext.getCallerPrincipal()はWLSPrincipals.getAnonmyousUserPrincipal()を返すのに対し、SubjectUtils.getUserPrincipal()はnullを返す点が異なります。

getCallerPrincipal()メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。

isCallerInRole

呼出し側(現在のユーザー)に割り当てられているセキュリティ・ロールにおいて、その実行スレッドでのWebLogicリソースに対するアクションの実行が許可されているかどうかを判定するには、isCallerInRole()メソッドを使用します。たとえば、現在のユーザーがadmin権限を持っている場合、javax.ejb.EJBContext.isCallerInRole("admin")メソッドはtrueを返します。

isCallerInRole()メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。

7 ネットワーク接続フィルタの使い方

この項では、ネットワーク接続フィルタの使用について説明します。

この節では、以下のトピックを取り上げます。

- ネットワーク接続フィルタを使用する利点

- ネットワーク接続フィルタAPI

- 接続フィルタ・ルールの作成ガイドライン

- WebLogic接続フィルタの構成

- カスタム接続フィルタの開発

ネットワーク接続フィルタを使用する利点

セキュリティ・ロールおよびセキュリティ・ポリシーを使うと、WebLogicリソースをドメイン・レベル、アプリケーション・レベル、およびアプリケーション・コンポーネント・レベルで保護できます。接続フィルタを使用すると、ネットワーク・レベルでアクセスを拒否できます。つまり、ネットワーク接続フィルタは、追加のセキュリティ・レイヤーを提供します。接続フィルタを使うと、個々のサーバー、サーバーのクラスタ、または内部ネットワークにあるサーバー・リソースを保護できます。

接続フィルタは、管理ポートでアクセスを制御する場合に特に便利です。ネットワーク・ファイアウォール構成によっては、接続フィルタを使用して管理アクセスをさらに制限できる場合もあります。一般的には、管理ポートへのアクセスを特定のドメイン内のサーバーやマシンのみに制限するために使用します。たとえ攻撃者がファイアウォール内のマシンにアクセスできた場合でも、許可されたマシンでない限り、管理操作を実行することはできません。

ネットワーク接続フィルタは、プロトコル、IPアドレス、およびDNSノード名に基づいてフィルタ処理するよう構成できる点において一種のファイアウォールです。たとえば、ユーザーの企業のネットワーク外部からの非SSL接続を拒否できます。これにより、インターネット上のシステムからのすべてのアクセスのセキュリティが確保されます。

ネットワーク接続フィルタAPI

この節では、weblogic.security.netパッケージについて説明します。このAPIは、ネットワーク接続フィルタを開発するためのインタフェースとクラスを提供します。またこれには、ネットワーク接続フィルタのすぐに使える実装である、ConnectionFilterImplクラスが含まれます。詳細は、このリリースのWebLogic ServerのOracle WebLogic Server APIリファレンスを参照してください。

この節では、以下のトピックを取り上げます。

- 接続フィルタのインタフェース

- 接続フィルタのクラス

接続フィルタのインタフェース

接続フィルタ処理を実装するには、接続フィルタ・インタフェースを実装するクラスを記述します。接続フィルタの実装用に、以下のweblogic.security.netインタフェースが提供されます。

- ConnectionFilterインタフェース

- ConnectionFilterRulesListenerインタフェース

ConnectionFilterインタフェース

このインタフェースでは、接続フィルタ処理を実装するために使用するaccept()メソッドが定義されています。接続フィルタ処理を実行するようにサーバーをプログラミングするには、このインタフェースを実装するクラスをインスタンス化し、管理コンソールでそのクラスを構成する必要があります。このインタフェースは、接続フィルタ処理に関する最低限の実装要件です。

注意:

このインタフェースを実装しただけでは、管理コンソールを使ってクライアント接続を制限するフィルタ処理ルールを入力および修正することはできません。他の方法(管理コンソールで定義するフラット・ファイルなど)を使ってルールを指定する必要があります。管理コンソールを使ってフィルタ処理ルールを入力および修正するには、ConnectionFilterRulesListenerインタフェースも実装する必要があります。ConnectionFilterRulesListenerインタフェースについては、「ConnectionFilterRulesListenerインタフェース」を参照してください。

ConnectionFilterRulesListenerインタフェース

サーバーはこのインタフェースを使って、管理コンソールの「ConnectionFilterRules」フィールドで指定したルールが有効であるかどうかを起動中および実行時に判断します。

注意:

このインタフェースを実装することも、WebLogic Server製品の一部としてすぐにそのまま使えるWebLogic接続フィルタ実装weblogic.security.net.ConnectionFilterImplのみを使用することもできます。

このインタフェースでは、接続フィルタ処理を実装するために使用する2つのメソッドsetRules()とcheckRules()が定義されています。ConnectionFilterインタフェースと共にこのインタフェースを実装すれば、クライアント接続を制限するフィルタ処理ルールを、管理コンソールを使って入力することができます。

注意:

管理コンソールで接続フィルタ処理ルールを入力および編集するためには、ConnectionFilterRulesListenerインタフェースを実装する必要があります。このインタフェースを実装しない場合は、フラット・ファイルなどの他の方法を使用する必要があります。

接続フィルタのクラス

接続フィルタの実装用に、2つのweblogic.security.netクラスが提供されます。

- ConnectionFilterImplクラス

- ConnectionEventクラス

ConnectionFilterImplクラス

このクラスは、ConnectionFilterおよびConnectionFilterRulesListenerインタフェースのWebLogic接続フィルタ実装です。いったん管理コンソールを使って構成されると、この接続フィルタはデフォルトですべての着信接続を受け入れ、また、サーバーが現在の接続フィルタを取得できるようにする静的なファクトリ・メソッドを提供します。この接続でアクセスを拒否するには、管理コンソールで接続フィルタ・ルールを入力するだけです。

このクラスは、WebLogic Server製品の一部として提供されます。このクラスを構成して使用するには、「WebLogic接続フィルタの構成」を参照してください。

ConnectionEventクラス

これは、すべてのイベント状態オブジェクトが派生する元のクラスです。すべてのイベントは、そのオブジェクト、つまり特定のイベントが最初に発生したオブジェクトであると論理的に見なされるソースを基準に作成されます。新しいConnectionEventインスタンスを作成するには、アプリケーションでこのクラスが提供するメソッド(getLocalAddress()、getLocalPort()、getRemoteAddress()、getRemotePort()、およびhashcode())を使用します。

接続フィルタ・ルールの作成ガイドライン

この節では、接続フィルタ・ルールの記述方法と評価方法について説明します。接続ルールが指定されていない場合は、すべての接続が受け入れられます。

接続フィルタ・ルールは、接続フィルタ処理の実装方法に応じて、フラット・ファイルで記述したり、管理コンソールで直接入力したりできます。

以下の節では、接続フィルタ・ルールを記述するために必要な情報とガイドラインを説明しています。

- 接続フィルタ・ルールの構文

- 接続フィルタ・ルールの種類

- 接続フィルタ・ルールの評価方法

接続フィルタ・ルールの構文

接続フィルタ・ルールの構文は以下のとおりです。

- 各ルールは、1行で記述する必要があります。

- ルールのトークンはスペースで区切る必要があります。

- シャープ記号(#)はコメント文字。シャープ記号から行末までの記述は無視されます。

- ルールの前後のホワイトスペースは無視されます。

- ホワイトスペースまたはコメントだけの行はスキップされます。

フィルタ・ルールの形式は、フィルタ・ルールを入力するフィルタ・ファイルを使用するか、管理コンソールでフィルタ・ルールを入力するかによって異なります。

- 管理コンソールでフィルタ・ルールを入力する場合、次の形式で入力します。

targetAddress localAddress localPort action protocols

- フィルタ・ファイルでルールを指定する場合、次の形式で入力します。

targetAddress action protocols

- targetAddressでは、フィルタ処理を行うシステムを1つ以上指定します。

- localAddressでは、WebLogic Serverインスタンスのホスト・アドレスを定義します。アスタリスク(*)を指定すると、すべてのローカルIPアドレスが返されます。

- localPortでは、WebLogic Serverインスタンスがリスニングしているポートを定義します。アスタリスク(*)を指定すると、サーバーで利用可能なすべてのポートが返されます。

- actionでは、実行するアクションを指定します。この値は、allowまたはdenyでなければなりません。

- protocolsは、一致するプロトコル名のリスト。http、https、t3、t3s、ldap、ldaps、iiop、iiops、およびcomといったプロトコルを指定できます。(giop、giops、およびdcomプロトコル名もサポートされていますが、リリース9.0以降、その使用は非推奨です。同等の機能を持つiiop、iiops、およびcomプロトコル名を使用する必要があります。)

注意:

SecurityConfigurationMBeanには、以前の接続フィルタとの互換性を維持するためのCompatibilityConnectionFiltersEnabled属性があります。

- プロトコルを定義しないと、すべてのプロトコルがルールに一致します。

接続フィルタ・ルールの種類

2種類のフィルタ・ルールが認識されます。

- ファスト・ルール
ファスト・ルールは、ホスト名またはネットマスク(オプション)を含むIPアドレスに適用されます。ホスト名が複数のIPアドレスに対応する場合は、複数のルール(順序は不定)が生成されます。ネットマスクは、数値またはドットで区切った4つの値の形式で指定できます。例:

dialup-555-1212.pa.example.net 127.0.0.1 7001 deny t3 t3s #http(s) OK
192.168.81.0/255.255.254.0   127.0.0.1 8001 allow   #23-bit netmask
192.168.0.0/16   127.0.0.1 8002 deny   #like /255.255.0.0

ファスト・ルールに対してホスト名を指定すると、WebLogic Serverインスタンスの起動時に1回だけルックアップされます。この方法は、接続時のオーバーヘッドの大幅な削減には有効ですが、ホスト名とアドレスの対応について古い情報をフィルタが取得する可能性があります。数値のIPアドレスを使用することをお薦めします。

- スロー・ルール
スロー・ルールは、ドメイン名の一部に適用されます。一致検査を実行するにはクライアント側で接続時のDNSルックアップが必要なので、スロー・ルールはファスト・ルールよりかなり遅くなる場合があります。また、スロー・ルールはDNSスプーフィング攻撃の対象になる可能性があります。スロー・ルールの指定方法は次のとおりです。

*.script-kiddiez.org 127.0.0.1 7001 deny

アスタリスクは、パターンの先頭に対してのみ使用できます。ルールの他の位置でアスタリスクを使用すると、パターンの一部として扱われます。アスタリスクはドメイン名の一部として認められていないので、このようなパターンはドメイン名と一致しなくなります。

接続フィルタ・ルールの評価方法

クライアントがWebLogic Serverに接続すると、記述されている順序でルールが評価されます。一致する最初のルールにより、接続の処理方法が決まります。一致するルールがない場合には、接続は許可されます。

サーバーの保護をさらに厳しくし、特定のアドレスからの接続だけを許可するには、最後のルールを次のように指定します。

0.0.0.0/0  *  *  deny

最後のルールをこのように指定すると、それまでのルールで許可されている接続だけが認められて、他の接続はすべて拒否されます。たとえば次のルールを指定したとします。

<Remote IP Address> * * allow https
0.0.0.0/0  *  *  deny

Remote IP Addressを持つマシンだけが、接続フィルタを実行するWebLogic Serverのインスタンスへのアクセスを許可されます。その他のシステムはすべて、アクセスを拒否されます。

注意:

デフォルトの接続フィルタの実装では、ターゲット・アドレス0 (0.0.0.0/0)を「ルールはすべてのIPアドレスに適用される」という意味であると解釈します。設計上、デフォルトのフィルタはポートやローカル・アドレスを評価せず、アクションのみを評価します。デフォルトのフィルタを使用する場合の制限を明確に指定するには、ルールを変更します。

この他に、カスタム接続フィルタを実装する方法もあります。

WebLogic接続フィルタの構成

WebLogic Serverには、そのまま使用できるネットワーク接続フィルタが用意されています。このフィルタは、管理コンソールで構成するだけで使用できます。接続フィルタの構成方法の詳細は、『Oracle WebLogic Serverの保護』を参照してください。

カスタム接続フィルタの開発

WebLogic接続フィルタを使用せず、独自に開発する場合は、weblogic.security.netパッケージで提供されているアプリケーション・プログラミング・インタフェース(API)を使用できます。このAPIについては、「ネットワーク接続フィルタAPI」を参照してください。

WebLogic Serverでカスタム接続フィルタを開発するには、次の手順を実行します。

1. ConnectionFilterインタフェースを実装するクラスを記述します(最低限の要件)。
または、管理コンソールを使用して接続フィルタ処理ルールを入力したり、既存のフィルタ処理ルールを直に変更したりする場合は、ConnectionFilterインタフェースおよびConnectionFilterRulesListenerインタフェースを実装するクラスを記述します。

2. ConnectionFilterインタフェースのみを実装してステップ1の最低要件を満たす場合、接続フィルタ処理ルールをフラット・ファイルに入力し、ConnectionFilterインタフェースを実装するクラスにそのファイルの場所を定義します。その後、管理コンソールを使用してWebLogic Serverにクラスを構成します。管理コンソールでクラスを構成する手順については、『Oracle WebLogic Serverの保護』の接続フィルタの使用に関する項を参照してください。

3. ステップ1で2つのインタフェースを定義した場合、管理コンソールを使用してクラスを構成し、接続フィルタ処理ルールを入力します。管理コンソールでクラスを構成する手順については、『Oracle WebLogic Serverの保護』の接続フィルタの使用に関する項を参照してください。

JavaクライアントまたはWebブラウザ・クライアントがWebLogic Serverインスタンスへの接続を試行する際に接続フィルタ処理を実装すると、WebLogic ServerインスタンスはConnectionEventオブジェクトを作成して、接続フィルタ・クラスのaccept()メソッドに渡します。接続フィルタ・クラスは、ConnectionEventオブジェクトを調べて、接続を受け付ける場合はオブジェクトを返し、接続を拒否する場合はFilterExceptionをスローします。

実装されたクラス(ConnectionFilterインタフェースのみを実装するクラスと、ConnectionFilterインタフェースおよびConnectionFilterRulesListenerインタフェースを実装するクラス)は両方とも、クライアント接続に関する情報を収集後に、accept()メソッドを呼び出す必要があります。ただし、ConnectionFilterインタフェースだけを実装している場合、収集される情報にはリモートIPアドレスと接続プロトコル(http、https、t3、t3s、ldap、ldaps、iiop、iiops、またはcom)が含まれます。どちらのインタフェースも実装している場合、収集される情報には、リモートIPアドレス、リモート・ポート番号、ローカル・ポート番号、および接続プロトコルが含まれます。

8 Javaセキュリティを使用したWebLogicリソースの保護

この項では、Javaセキュリティを使用したWebLogicリソースの保護について説明します。

この節では、以下のトピックを取り上げます。

- Java EEセキュリティを使用したWebLogicリソースの保護

- Javaセキュリティ・マネージャを使用したWebLogicリソースの保護

Java EEセキュリティを使用したWebLogicリソースの保護

WebLogic Serverは、URL (Web)、Enterprise JavaBeans (EJB)、およびコネクタのコンポーネントを保護するJava EEセキュリティをサポートしています。さらに、WebLogic Serverでは、デプロイメント記述子を使って追加のセキュリティ・ポリシーを指定するコネクタ・モデルが、URLおよびEJBのコンポーネントに拡張されています。

注意:

Java EEコネクタ・アーキテクチャ仕様と同じように、Java EEでは異なるアプリケーション・タイプ(Java EE仕様を参照)のJava 2セキュリティのデフォルト・パーミッションに対する要件が規定されています。

コネクタ仕様では、すでに次の例のように<security-permission>タグを使って追加セキュリティ・ポリシーを指定するデプロイメント記述子に対応しています(例8-1を参照)。

例8-1 security-permissionタグのサンプル

<security-permission>
<description> Optional explanation goes here </description>
<security-permission-spec>
<!--
A single grant statement following the syntax of
http://java.sun.com/j2se/1.4.2/docs/guide/security/PolicyFiles.html#FileSyntax
without the "codebase" and "signedBy" clauses goes here. For example:
-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>

rar.xmlファイルでの<security-permission>タグのサポートに加えて、WebLogic Serverではweblogic.xmlファイルとweblogic-ejb-jar.xmlファイルに<security-permission>タグを追加しています。これらは、コネクタ・モデルを他の2つのアプリケーション・タイプ(WebアプリケーションとEJB)に拡張し、すべてのコンポーネント・タイプでセキュリティ・ポリシーへのインタフェースを統一すると共に、将来のJava EE仕様の変更に備えるためのものです。

Javaセキュリティ・マネージャを使用したWebLogicリソースの保護

Javaセキュリティ・マネージャとWebLogic Serverを一緒に使用すると、Java仮想マシン(JVM)内で実行されているリソースのセキュリティを強化できます。Javaセキュリティ・マネージャは、任意のセキュリティ手順です。以下の節では、WebLogic ServerでJavaセキュリティ・マネージャを使用する方法について説明します。

- Javaセキュリティ・マネージャの設定

- セキュリティ・マネージャのプリントの使用

- Java Authorization Contract for Containersの使用

Javaセキュリティ・マネージャの詳細は、http://download.oracle.com/javase/6/docs/technotes/guides/security/index.htmlのJavaセキュリティに関するWebページを参照してください。

Javaセキュリティ・マネージャの設定

Java 2(SDK 1.2以降)環境でWebLogic Serverを実行する場合、WebLogic ServerはJava 2のJavaセキュリティ・マネージャを使用して、信頼性のないコードがJavaセキュリティ・ポリシー・ファイルによって制限されているアクションを実行しないようにできます。

Java仮想マシン(JVM)には、Javaセキュリティ・ポリシー・ファイルでコードに制約を設定するセキュリティ・メカニズムが組み込まれています。Javaセキュリティ・マネージャは、Javaセキュリティ・ポリシー・ファイルを使用して一連の許可をクラスに強制的に付与します。これらの許可を使用すると、JVMのインスタンスで実行される指定されたクラスに特定の実行時処理を許可するかどうかを設定できます。多くの場合、脅威モデルでは悪意あるコードがJVMで実行されることを想定していないため、Javaセキュリティ・マネージャは必要ありません。しかし、信頼されていないサード・パーティがWebLogic Serverを使用し、信頼されていないクラスが実行される場合、Javaセキュリティ・マネージャが役立ちます。

WebLogic ServerでJavaセキュリティ・マネージャを使用するには、WebLogic Serverの起動時に-Djava.security.policy引数と-Djava.security.manager引数を指定します。-Djava.security.policy引数は、Java 2セキュリティ・ポリシーを格納するファイル名を、相対パス名または絶対パス名で指定します。

WebLogic Serverには、編集および使用可能なサンプルJavaセキュリティ・ポリシー・ファイルが用意されています。このファイルは、WL_HOME\server\lib\weblogic.policyにあります。

注意:

このサンプル・ポリシー・ファイルは完全なものではなく、修正を加えてからでないとWebLogic Serverを起動できません。特に、WLSやすべてのアプリケーションが適切に機能するには、構成に基づいて各種の許可を追加する必要があります。

たとえば、WLSを正常に起動して管理コンソールからアプリケーションをデプロイするには、weblogic.policyに以下のように追加する必要があります。

permission java.util.PropertyPermission '*', 'read';
permission java.lang.RuntimePermission '*';
permission java.io.FilePermission ' <<ALL FILES>>', 'read,write';
permission javax.management.MBeanPermission '*', '*';

セキュリティ・ポリシー・ファイルを指定しないでJavaセキュリティ・マネージャを有効にする場合、Javaセキュリティ・マネージャでは、$JAVA_HOME\jre\lib\securityディレクトリのjava.policyファイルに定義されるデフォルトのセキュリティ・ポリシーを使用します。

Javaセキュリティ・マネージャのセキュリティ・ポリシーは、以下のいずれかの方法で定義します。

- 全体的に使用するweblogic.policyファイルの修正

- アプリケーション型のセキュリティ・ポリシーの設定

- アプリケーション固有のセキュリティ・ポリシーの設定

全体的に使用するweblogic.policyファイルの修正

WebLogic ServerデプロイメントでJavaセキュリティ・マネージャのセキュリティ・ポリシー・ファイルを使用するには、WebLogic Serverの起動時にJavaセキュリティ・マネージャにweblogic.policyファイルの場所を指定する必要があります。これを行うには、サーバーの起動に使用するJavaコマンド・ラインで次の引数を設定します。

- java.security.managerは、JVMにJavaセキュリティ・ポリシー・ファイルを使用するよう指示します。

- java.security.policyは、JVMに使用するJavaセキュリティ・ポリシー・ファイルの場所を指示します。この引数は、Javaセキュリティ・ポリシーの完全修飾名(この場合はweblogic.policy)です。

例:

java...-Djava.security.manager \
-Djava.security.policy==c:\weblogic\weblogic.policy

注意:

java.security.policy引数を指定するときには、Javaセキュリティ・マネージャによってweblogic.policyファイルだけが使用されるよう、= のかわりに == を使用します。== を使用すると、weblogic.policyファイルはデフォルトのセキュリティ・ポリシーをオーバーライドします。単一の等号記号(=)を使用すると、ポリシー・ファイルは既存のセキュリティ・ポリシーに付加されます。

CLASSPATHに追加のディレクトリがある場合、または追加のディレクトリにアプリケーションをデプロイしている場合は、それらのディレクトリに対する特定の許可をweblogic.policyファイルに追加します。

weblogic.policyファイルを使用する際には、次のような注意事項を考慮することをお薦めします。

- weblogic.policyファイルのバックアップを作成し、安全な場所に保管します。

- オペレーティング・システムを通じて、WebLogic Serverデプロイメントの管理者は読み書き権限を持ち、それ以外のユーザーはアクセス権を持たないように、weblogic.policyファイルに許可を設定します。

警告:

Javaセキュリティ・マネージャは、管理サーバーと管理対象サーバーの起動時に部分的に無効にされます。起動シーケンス中は、現在のJavaセキュリティ・マネージャが無効化され、checkRead()メソッドが無効化されたJavaセキュリティ・マネージャに置き換えられます。このメソッドを無効化した場合、起動シーケンスのパフォーマンスは飛躍的に向上しますが、セキュリティは最低レベルに下がります。WebLogic Serverのスタート・アップ・クラスは、この部分的に無効にされたJavaセキュリティ・マネージャと一緒に実行されます。このため、スタート・アップ・クラスを十分にチェックして、セキュリティ(ファイルの読取りなど)を検討する必要があります。

Javaセキュリティ・マネージャの詳細は、java.lang.SecurityManagerクラス(http://download.oracle.com/javase/6/docs/api/java/lang/SecurityManager.html)のJavadocを参照してください。

アプリケーション型のセキュリティ・ポリシーの設定

サーブレット、EJB、およびJava EEコネクタ・リソース・アダプタのデフォルト・セキュリティ・ポリシーを、Javaセキュリティ・ポリシー・ファイルで設定します。サーブレット、EJB、およびリソース・アダプタのデフォルト・セキュリティ・ポリシーは、以下のコード・ベースでJavaセキュリティ・ポリシーに定義します。

- サーブレット - "file:/weblogic/application/defaults/Web"

- EJB - "file:/weblogic/application/defaults/EJB"

- リソース・アダプタ - "file:/weblogic/application/defaults/Connector"

注意:

これらのセキュリティ・ポリシーは、WebLogic Serverの特定のインスタンスにデプロイされるすべてのサーブレット、EJB、およびリソース・アダプタに適用されます。

アプリケーション固有のセキュリティ・ポリシーの設定

特定のサーブレット、EJB、またはリソース・アダプタのセキュリティ・ポリシーを設定するには、セキュリティ・ポリシーをそれらのデプロイメント記述子に追加します。デプロイメント記述子は、以下のファイルに定義されます。

- サーブレット - weblogic.xml

- EJB - weblogic-ejb-jar.xml

- リソース・アダプタ - rar.xml

注意:

リソース・アダプタのセキュリティ・ポリシーはJava EE仕様に準拠し、サーブレットおよびEJBのセキュリティ・ポリシーはWebLogic ServerのJava EE仕様拡張に準拠します。

例8-2は、セキュリティ・ポリシーをデプロイメント記述子に追加するための構文です。

例8-2 セキュリティ・ポリシーの構文

<security-permission>
<description>
Allow getting the J2EEJ2SETest4 property
</description>
<security-permission-spec>
grant {
permission java.util.PropertyPermission "welcome.J2EEJ2SETest4","read";
};
</security-permission-spec>
</security-permission>

注意:

現時点では、<security-permission-spec>タグはweblogic-application.xmlファイルに追加できません。このタグを使用できるのは、weblogic-ejb-jar.xml、rar.xml、またはweblogic.xmlファイルの中だけです。また、<security-permission-spec>属性では変数はサポートされていません。

セキュリティ・マネージャのプリントの使用

セキュリティ・マネージャのプリントは、Javaセキュリティ・マネージャの拡張です。セキュリティ・マネージャをプリントすることにより、Javaセキュリティ・マネージャで実行しているJavaアプリケーションに対して必要となる許可のすべてを識別するために使用できます。一度に1つずつ必要な許可を識別するJavaセキュリティ・マネージャと異なり、セキュリティ・マネージャのプリントによって、介入せずに必要な許可のすべてを識別することができます。

Javaセキュリティ・マネージャの詳細は、http://download.oracle.com/javase/6/docs/technotes/guides/security/overview/jsoverview.htmlのJavaセキュリティに関するWebページを参照してください。

注意:

本番環境でセキュリティ・マネージャのプリントを使用しないでください。不足している許可を識別するための開発のみを目的としています。

信頼性のないコードの処理は防止されません。

セキュリティ・マネージャのプリントの起動引数

WebLogic ServerでJavaセキュリティ・マネージャを使用するには、WebLogic Serverの起動時に次の2つの引数を指定します。

- -Djava.security.manager=weblogic.security.psm.PrintingSecurityManager
Djava.security.manager引数は、どのJavaセキュリティ・マネージャを起動するかをWebLogic Serverに指示します。この場合、セキュリティ・マネージャのプリントを使用します。

- -Djava.security.policy
-Djava.security.policy引数は、Java 2セキュリティ・ポリシーを格納するファイル名を、相対パス名または絶対パス名で指定します。WebLogic Serverには、編集および使用可能なサンプルJavaセキュリティ・ポリシー・ファイルが用意されています。このファイルは、WL_HOME\server\lib\weblogic.policyにあります。

デフォルトでは、startWebLogic.cmd(sh)に-Djava.security.policy=$WL_HOME/server/lib/weblogic.policyプロパティが含まれているので、別のJavaセキュリティ・ポリシー・ファイルを使用しない限り、指定する必要はありません。

注意:

このサンプル・ポリシー・ファイルは完全なものではなく、修正を加えてからでないとWebLogic Serverを起動できません。特に、WLSやすべてのアプリケーションが適切に機能するには、構成に基づいて各種の許可を追加する必要があります。

詳細については、以下の各節を参照してください。

- 全体的に使用するweblogic.policyファイルの修正

- アプリケーション型のセキュリティ・ポリシーの設定

- アプリケーション固有のセキュリティ・ポリシーの設定

セキュリティ・マネージャのプリントを使用するWebLogic Serverの起動

セキュリティ・マネージャのプリントを使用するWebLogic ServerをUNIXシェルから起動するには、DOMAIN_HOMEにおけるstartWebLogic.shスクリプトに次の引数を渡します。この例は、startWeblogic.shからのデフォルトweblogic.policyのJavaポリシー・ファイルを使用します。

startWeblogic.sh
-Xbootclasspath/p:$MWHOME/modules/com.bea.core.weblogic.security.psm_1.0.0.0.jar
-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

UNIXシェルなしWindowsシステムのためにまず、JAVA_OPTIONSに起動オプションを設定し、DOMAIN_HOMEのstartWebLogic.cmdスクリプトを使用して、WebLogic Serverを起動します。この例は、startWeblogic.cmdからのデフォルトのweblogic.policyのJavaポリシー・ファイルを使用します。

$ set JAVA_OPTIONS=-Xbootclasspath/p:$MWHOME/modules/com.bea.core.weblogic.security.psm_1.0.0.0.jar
-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

$ DOMAIN_HOME\startWeblogic.cmd

出力ファイルの書込み

セキュリティ・マネージャのプリントは、コード・ソースおよびそれに関する許可をリストする出力を生成します。また、ポリシー・ファイルにコピー・アンド・ペーストするためのアクセスを付与するポリシーも発生します。

デフォルトで、System.outに出力します。次の2つの引数で出力ファイルを構成することができます。

- -Doracle.weblogic.security.manager.printing.file=psm_perms.txt

- -Doracle.weblogic.security.manager.printing.generated.grants.file=psm_grants.txt

最初のシステム引数の値は、セキュリティ・マネージャをプリントすることにより、不足している許可のメッセージのすべてを書き込むファイルです。2番目の引数の値は、セキュリティ・マネージャをプリントすることにより、不足しているポリシー付与を書き込むファイルです。

たとえば、UNIXシェルなしWindowsシステムのために、引数をJAVA_OPTIONSに追加します。

$ set JAVA_OPTIONS=-Xbootclasspath/p:$MW_HOME/modules/com.bea.core.weblogic.security.psm_1.0.0.0.jar
-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager
-Doracle.weblogic.security.manager.printing.file=psm_perms.txt

$ startWeblogic.cmd

出力ファイルのフルパスを指定しない場合、DOMAIN_HOMEに作成されます。

Java Authorization Contract for Containersの使用

Java Authorization Contract for Containers (JACC)はJava EEの一部です。JACCは、EJBおよびサーブレットに対するJava 2許可ベースのセキュリティ・モデルです。JACCは、JSR-115(http://www.jcp.org/en/jsr/detail?id=115)によって定義されます。

JACCは、WebLogic Serverドメイン内のEJBおよびサーブレット・コンテナに代替認可メカニズムを提供します。表8-2に示すように、JACCが構成されていると、WebLogicセキュリティ・フレームワークのアクセス決定、裁決、およびロール・マッピング機能は、EJBおよびサーブレットの認可判定には使用されません。

WebLogic Serverは、JSR-115に完全に準拠しているものの、WebLogic認可プロバイダほどには最適化されていないJACCプロバイダを実装します。Java JACCクラスは、アクセス決定を下す際に使用します。JSR-115はロール・マッピングに対処する方法を定義しないので、ロールとプリンシパルの間のマッピングにはWebLogic JACCクラスが使用されます。JACCプロバイダの開発については、http://www.oracle.com/technetwork/java/javaee/javaacc-138697.htmlを参照してください。

注意:

WebLogic Serverで使用されるJACCクラスには、決定を下すためのポリシー・オブジェクトの実装は含まれません。かわりに、JACCクラスは、java.security.Policyオブジェクト(http://download.oracle.com/javase/6/docs/api/java/security/Policy.html)に依存します。

この節では、以下のトピックを取り上げます。

- WebLogic JACCプロバイダとWebLogic認可プロバイダの比較

- WebLogic JACCプロバイダの有効化

表8-2には、JACCを有効にした場合に、どのプロバイダがロール・マッピングに使用されるかを示します。

表8-1 JACCを有効にした場合

ステータス

EJB/サーブレットの認可とロール・マッピングに使用されるプロバイダ

その他のすべての認可とロール・マッピングに使用されるプロバイダ

EJB/サーブレットのロールとポリシーを管理コンソールで表示および変更できるかどうか

JACCは有効です

JACCプロバイダ

WebLogicセキュリティ・フレームワーク・プロバイダ

いいえ

JACCは有効ではありません

WebLogicセキュリティ・フレームワーク・プロバイダ

WebLogicセキュリティ・フレームワーク・プロバイダ

設定によっては、はい

注意:

JACCは、ドメイン内のすべてのサーバーで有効にするか、またはすべてのサーバーで無効にしてください。これは、WebLogicセキュリティ・フレームワークがレルム/ドメイン固有であるのに対し、JACCはサーバー固有であるためです。WebLogic JACCを使用するか、独自のJACCプロバイダを作成(こちらを推奨)してJACCを有効にした場合は、EJBとServletの認可ポリシーをドメイン内で同期させる必要があります。たとえば、アプリケーションは、サーバーを起動するたびに再デプロイされます。JACCが構成されたサーバーを、コマンド・ラインにJACCオプションを指定せずに起動すると、EJBやServletのロール・マッピングおよび認可判定にデフォルトのWebLogic認可プロバイダが使用されます。

WebLogic JACCプロバイダとWebLogic認可プロバイダの比較

WebLogic JACCプロバイダは、JSR-115に完全に準拠していますが、動的ロール・マッピングをサポートしておらず、EJBおよびサーブレット以外のリソースの認可判定は行いません。セキュリティ機能のパフォーマンスと柔軟性を向上させるため、SSPIベースのプロバイダを使用することをお薦めします。

表8-2では、WebLogic JACCプロバイダとWebLogic認可プロバイダの機能を比較します。

表8-2 WebLogic JACCプロバイダとWebLogic認可プロバイダの比較

WebLogic JACCプロバイダ

WebLogic認可プロバイダ

JACC仕様(JSR-115)を実装します

付加価値の高いセキュリティ・フレームワーク

EJBおよびサーブレットのみデプロイメント/認可判定を行います

デプロイメント/認可判定を行います

java.security.Policyオブジェクトを判定に使用します

複数の認可/ロール・プロバイダで使用可能です

デプロイメント時の静的ロール・マッピング

動的ロール・マッピング

Java EE許可でアクセスを制御します

資格エンジンでアクセスを制御します

ロール・マッピングおよびロール/プリンシパル・マッピングは、デプロイメント記述子でのみ変更可能です

ロール・マッピングおよびロール/プリンシパル・マッピングは、デプロイメント記述子および管理コンソールで変更可能です

WebLogic JACCプロバイダの有効化

WebLogic JACCプロバイダをコマンド・ラインから有効にするには、以下のシステム・プロパティと値のペアを指定する必要があります。

- プロパティ: java.security.manager

- 値:不要

- プロパティ: java.security.policy

- 値:有効なweblogic.policyファイル(相対パス名または絶対パス名で指定)

- プロパティ: javax.security.jacc.PolicyConfigurationFactory.provider

- 値: weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl

- プロパティ: javax.security.jacc.policy.provider

- 値: weblogic.security.jacc.simpleprovider.SimpleJACCPolicy

- プロパティ: weblogic.security.jacc.RoleMapperFactory.provider

- 値: weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl

たとえば、適切に構成されたweblogic.policyファイルがあれば、次のコマンド・ラインでWebLogic JACCプロバイダが有効になります。

# ./startWebLogic.sh -Djava.security.manager\
-Djava.security.policy==<pathname>/weblogic.policy \
-Djavax.security.jacc.policy.provider=\
weblogic.security.jacc.simpleprovider.SimpleJACCPolicy \
-Djavax.security.jacc.PolicyConfigurationFactory.provider=\
weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl \
-Dweblogic.security.jacc.RoleMapperFactory.provider=\
weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl

注意:

デフォルトのセキュリティ・ポリシーをオーバーライドするには、-Djava.security.policy==<pathname>/weblogic.securityを使用します。単一の等号記号(=)を使用すると、ポリシー・ファイルは既存のセキュリティ・ポリシーに付加されます。

9 SAML API

この項では、WebLogic Serverで使用されるSAML APIについて説明します。

SAML (Security Assertion Markup Language)は、様々なエンティティの間でセキュリティ情報をやり取りするためのXMLベースのプロトコルです。SAML標準は、Web上のソフトウェア・エンティティの間でセキュリティ情報を交換するためのフレームワークを定義します。SAMLセキュリティは、アサーション側と依存側の対話に基づいています。

SAMLは、シングル・サインオン機能を提供します。1つの場所で認証されたユーザーは、あらためてログインしなくても、別の場所のサービス・プロバイダにアクセスできます。

WebLogic Serverは、SAMLバージョン2.0および1.1をサポートしています。WebLogic Server実装では、以下がサポートされます。

- SAML 1.1のWeb SSOのHTTP POSTおよびHTTPアーティファクト・バインディング。SAML 2.0では、Web SSOプロファイルのHTTPリダイレクト・バインディングが追加されます。

- SAML認証文とSAML属性文(SAML認可文はサポートされません)

WebLogic Server環境でのSAMLおよびSAMLアサーションの概要については、『Oracle WebLogic Serverのセキュリティの理解』のSecurity Assertion Markup Language (SAML)に関する項を参照してください。

SAML資格証明マッピング・プロバイダの構成の詳細は、『Oracle WebLogic Serverの保護』のSAML 1.1のためのSAML資格証明マッピング・プロバイダの構成に関する項およびSAML 2.0のためのSAML 2.0資格証明マッピング・プロバイダの構成に関する項を参照してください。

SAML仕様については、http://www.oasis-open.orgを参照してください。「Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1」(http://www.oasis-open.org/committees/download.php/6628/sstc-saml-tech-overview-1.1-draft-05.pdf)および 「Security Assertion Markup Language (SAML) 2.0 Technical Overview」(http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf)も参照してください。

この節では、以下のトピックを取り上げます。

- SAML APIの説明

- カスタムPOSTフォーム・パラメータ名

- 非WebLogic SAML 1.1リライイング・パーティ用アサーションの作成

- SAML SSO属性サポートの構成

SAML APIの説明

表9-1に、WebLogic SAML APIの一覧を示します。表9-2に、WebLogic SAML 2.0 APIの一覧を示します。詳細についてはJavadocを参照してください。

表9-1 WebLogic SAML API

WebLogic SAML API

説明

weblogic.security.providers.saml

WebLogic SAMLパッケージ。

SAMLAssertionStore

アーティファクト・プロファイルのアサーションを格納および取得するためのメソッドを定義するインタフェース。このインタフェースは非推奨であり、SAMLAssertionStoreV2が推奨されます。

SAMLAssertionStoreV2

SAMLAssertionStoreV2インタフェースはSAMLAssertionStoreインタフェースの拡張で、SAML ARSからのアサーションをリクエストする宛先サイトを特定および認証するためのメソッドが追加されています。

V2は、SAML仕様のバージョン2ではなく、WebLogic SAMLプロバイダの2番目のバージョンを表します。

SAMLCredentialAttributeMapper

サブジェクトからSAMLAssertionの属性へのマッピングを実行するためのインタフェース。

SAMLCredentialNameMapper

SAMLアサーションのフィールドにサブジェクト情報をマッピングするために使用するメソッドを定義するインタフェース。

SAMLIdentityAssertionAttributeMapper

SAML属性文から属性プリンシパルへのマッピングを実行するためのインタフェース。

SAMLIdentityAssertionNameMapper

SAMLアサーションの情報をユーザー名およびグループ名にマッピングするために使用するメソッドを定義するインタフェース。

SAMLUsedAssertionCache

POSTプロファイルの使用を1回に強制するため、アサーションIDをキャッシュするメソッドを定義するインタフェース。

このインタフェースを実装するクラスには、引数を取らないパブリック・コンストラクタが必要です。

SAMLNameMapperInfo

このクラスのインスタンスは、ユーザーおよびグループの情報を名前マッパーとやり取りするために使用します。このクラスによって、いくつかの便利な定数も定義されます。

SAMLAssertionStoreV2.AssertionInfo

SAMLAssertionStoreV2.retrieveAssertionInfo()によって返されるAssertionInfoクラス。このクラスには、取得したアサーションと、その関連情報が格納されます。SAMLAssertionStoreV2インタフェースの実装はこのクラスを返す必要があります。

SAMLAttributeInfo

SAMLAssertion AttributeStatementの1つの属性を表すクラス。

SAMLAttributeStatementInfo

SAMLAssertionのAttributeStatementを表すクラス。

SAMLNameMapperInfo

SAMLアサーションのユーザー名とグループ情報を表すために使用します。

SAMLCommonPartner

SAML 1.1パートナに共通の属性の抽象表現。

SAMLRelyingParty

SAMLリライイング・パーティ・レジストリ内のSAMLリライイング・パーティ・エントリを表します。

SAMLAssertingParty

LDAPアサーティング・パーティ・レジストリ内のSAMLアサーティング・パーティ・エントリを表します。

SAMLPartner

SAMLパートナの抽象表現。

注意:

SAML名前マッパー・クラスは、システム・クラスパスに含めなければなりません。カスタムのSAMLIdentityAssertionNameMapper、SAMLCredentialNameMapper、SAMLAssertionStore、またはSAMLUsedAssertionCacheを作成した場合は、それぞれに対応するクラスをシステム・クラスパスに含める必要があります。

表9-2 WebLogic SAML 2.0 API

WebLogic SAML 2.0 API

説明

com.bea.security.saml2.providers

WebLogicセキュリティ・レルムでSAML 2.0セキュリティ・プロバイダを構成、制御、およびモニターするためのインタフェースとクラスを提供します。

SAML2AttributeInfo

SAML 2.0 Assertion AttributeStatementの1つの属性を表すクラス。

SAML2AttributeStatementInfo

SAML 2.0アサーションのAttributeStatementを表すクラス。

SAML2CredentialAttributeMapper

サブジェクトからSAML 2.0 Assertionの属性へのマッピングを実行するためのインタフェース。

SAML2CredentialNameMapper

ユーザーとグループの情報をSAML 2.0アサーションにマッピングするために使用するインタフェース。

SAML2IdentityAsserterAttributeMapper

SAML 2.0属性文から属性プリンシパルへのマッピングを実行するためのインタフェース。

SAML2IdentityAsserterNameMapper

SAML 2.0アサーションに格納されたユーザー情報をローカル・ユーザー名にマップするために使用するインタフェース。

SAML2NameMapperInfo

SAML 2.0アサーションに格納されたユーザー名とグループ情報を表すために使用します。

com.bea.security.saml2.providers.registry

SAML 2.0 IDプロバイダおよびサービス・プロバイダ・パートナとメタデータの抽象インタフェース。

BindingClientPartner

バインディング・クライアント・パートナとは、バックエンド・チャネルの通信をサポートするパートナ。

IdPPartner

SAML 2.0 IDプロバイダ・パートナの抽象表現。

Endpoint

SAML 2.0サービス・エンドポイントの抽象表現。

IndexedEndpoint

このクラスは、アーティファクト解決サービスのエンド・ポイントのように索引化可能なエンド・ポイントを表します。

MetadataPartner

メタデータ・パートナは、主にSAML 2.0メタデータ・プロファイルで必要なパートナの連絡先情報を格納します。

Partner

SAML 2.0パートナの抽象表現。このインタフェースはパートナの必須情報を定義します。

SPPartner

SAML 2.0サービス・プロバイダ・パートナの抽象表現。

WebSSOIdPPartner

Web SSOプロファイルのSAML 2.0 IDプロバイダ・パートナの抽象表現。

WebSSOPartner

Web SSOプロファイルのSAML 2.0パートナの抽象表現。

WebSSOSPPartner

Web SSOプロファイルのSAML 2.0サービス・プロバイダ・パートナの抽象表現。

WSSIdPPartner

WSS SAMLトークン・プロファイルのSAML 2.0 IDプロバイダ・パートナの抽象表現。

WSSPartner

WSS SAMLトークン・プロファイルのSAML 2.0パートナの抽象表現。

WSSSPPartner

WSS SAMLトークン・プロファイルのSAML 2.0サービス・プロバイダ・パートナの抽象表現。特定の属性やメソッドはありません。

カスタムPOSTフォーム・パラメータ名

SAML POSTプロファイル処理のためにカスタムPOSTフォームを指定した場合、POSTフォームに渡されるパラメータ名は、どのSAMLプロバイダが構成されているかによって異なります。

- V2プロバイダを構成すると有効になるWebLogic Server 9.1以降のフェデレーション・サービス実装の場合は、表9-3を参照してください。

- V1プロバイダを構成すると有効になるWebLogic Server 9.0 SAMLのサービス実装の場合は、表9-4を参照してください。

これらの表には、返されたJavaオブジェクトをキャストするために必要なパラメータ名とそのデータ型を示します。

どちらの実装でも、SAMLレスポンス自体は、SAMLで指定されたパラメータ名を使用して渡されます。

SAMLレスポンス(文字列)は、base64でエンコードされたSAMLレスポンス要素です。

表9-3 SAML V2プロバイダのカスタムPOSTフォーム・パラメータ

パラメータ

説明

TARGET(文字列)

受信したサイト間転送サービス(ITS)リクエストで、問合せパラメータとして指定されるTARGET URL。

SAML_AssertionConsumerURL(文字列)

宛先サイト(フォームをPOSTする必要のあるサイト)のアサーション・コンシューマ・サービス(ACS)のURL。

SAML_AssertionConsumerParams(マップ)

このマップには、リライイング・パーティ用に構成されたアサーション・コンシューマ・パラメータの名前と値のマッピングが含まれます。名前と値は文字列です。

SAML_ITSRequestParams(マップ)

このマップには、ITSリクエストで受信した問合せパラメータの名前と値のマッピングが含まれます。名前と値は文字列です。マップが空の場合もあります。TARGETパラメータおよびRPID (Rich Presence Information Data)形式のパラメータは、マップがフォームに渡される前にマップから削除されます。

表9-4 SAML V1プロバイダのカスタムPOSTフォーム・パラメータ

パラメータ

説明

targetURL(文字列)

ITSリクエストで、問合せパラメータとして指定されるTARGET URL。

consumerURL(文字列)

宛先サイト(フォームをPOSTする必要のあるサイト)のACSのURL。

非WebLogic SAML 1.1リライイング・パーティ用アサーションの作成

ソース・サイトを構成するためにSAML 1.1資格証明マッピング・プロバイダ・バージョン2を使用しても、非WebLogic Serverプラットフォームに実装されているサードパーティのSAMLリライイング・パーティを構成する場合、WebLogic Serverによって生成されるSAMLアサーションは、構成済のサードパーティのSAMLリライイング・パーティによって要求されるすべての属性をサポートするわけではありません。この場合、アサーションの期待される特定の属性が使用できないため、リライイング・パーティはアサーティング・パーティと共に機能しない可能性があります。

SAMLCredentialAttributeMapper (WebLogic Serverによって提供される)を実装することによって、サードパーティのSAMLリライイング・パーティに要求される特定のSAML 1.1アサーション属性に対してサブジェクトをマッピングする、カスタムSAML名マッパーを作成できます。SAMLCredentialAttributeMapperの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

次の項では、カスタムSAML名マッパーを作成する方法を説明します。

- カスタムSAML名マッパーの作成の概要

- 複数のSAMLCredentialAttributeMapper実装が必要な場合

- クラス、インタフェース、およびメソッド

- 例として使用するカスタムSAMLCredentialAttributeMapperクラス

- コンソールでカスタムSAMLCredentialAttributeMapperクラスを使用可能にする

カスタムSAML名マッパーの作成の概要

SAMLCredentialAttributeMapperインタフェースのカスタム実装を作成するには、次の手順を実行する必要があります。

- 次に示すクラスを使用し、アサーションの属性データを記述します。

- SAMLAttributeStatementInfo

- SAMLAttributeInfo

- また、SAMLCredentialNameMapperインタフェースを実装します。SAMLCredentialAttributeMapperおよびSAMLCredentialNameMapperインタフェースは、同一の実装内に存在する必要があります。
SAMLCredentialNameMapperインタフェースも実装すると、後でWebLogic Server管理コンソールを使用して、NameMapperClassName属性をこのSAMLCredentialAttributeMapperインスタンスのクラス名に設定できます。

SAML資格証明マッピング・プロバイダ・バージョン2のユーザー名マッパー・クラス名属性を使用し、アクティブ・セキュリティ・レルムでカスタムSAML名マッパーを構成します。

複数のSAMLCredentialAttributeMapper実装が必要な場合

SAML資格証明マッピング・プロバイダ・バージョン2に構成する名前マッパー・クラス名は、「コンソールでカスタムSAMLCredentialAttributeMapperクラスを使用可能にする」で説明されているように、該当プロバイダのデフォルトとして使用されます。ただし、SAML資格証明マッピング・プロバイダ・バージョン2に構成されたリライイング・パーティのすべてまたはいずれかに特有の名前マッパー・クラス名を任意で設定できます。この方法で名前マッパー・クラス名を設定すると、デフォルト値はオーバーライドされます。構成済のSAMLリライイング・パーティに異なる属性が必要な場合、複数のSAMLCredentialAttributeMapper実装を作成できます。

クラス、インタフェース、およびメソッド

この項では、カスタムSAML名マッパー実装の作成時に使用する必要がある新しいクラス、インタフェース、およびメソッドを説明します。コードの例は、例として使用するカスタムSAMLCredentialAttributeMapperクラスを参照してください。

SAMLAttributeStatementInfoクラス

例9-1は、SAMLAttributeStatementInfoクラスのメソッドおよび引数を示します。埋込みコメントによって追加情報およびコンテキストが提供されます。

例9-1 SAMLAttributeStatementInfoクラスのリスト

/**
* A class that represents the attributes of an AttributeStatement
* in a SAML Assertion
*/

class SAMLAttributeStatementInfo {

/**
* Constructs a SAMLAttributeStatementInfo with
* no attributes. The SAMLAttributeStatementInfo
* represents a empty SAMLAttributeStatement. It is
* expected that SAMLAttributeInfo elements will be
* added to this instance.
*

Public SAMLAttributeStatementInfo();

/**
* Constructs a SAMLAttributeStatementInfo containing multiple
* SAMLAttributeInfo elements. The SAMLAttributeStatementInfo
* represents a SAML AttributeStatement with multiple Attributes.
*
*
* @param data SAMLAttributeInfo
*/

public SAMLAttributeStatementInfo(Collection data);

/**
* returns a Collection of SAMLAttributeInfo elements. The
* collection represents the Attributes contained by
* a single AttributeStatement of a SAML Assertion
*
* The returned Collection is immutable and may be empty.
*
* @return Collection
*/

public Collection getAttributeInfo();

/**
* adds a Collection of SAMLAttributeInfo instances to
* this SAMLAttributeStatementInfo instance, to the
* end of the existing list, in the order that the
* param Collection iterates through the Collection.
*
* See SAMLAttributeInfo(String, String, Collection)
* for information on parameter handling.
*
* @param data
*
*/

public void setAttributeInfo(Collection data);

/**
* Adds a single SAMLAttributeInfo instance to this
* SAMLAttributeStatementInfo instance, at the end of
* the existing list.
*
* See SAMLAttributeInfo(String, String, Collection)
* for information on parameter handling.
*
* @param info
*/

public void addAttributeInfo(SAMLAttributeInfo info);

SAMLAttributeInfoクラス

例9-2は、SAMLAttributeInfoクラスのメソッドおよび引数を示します。埋込みコメントによって追加情報およびコンテキストが提供されます。

例9-2 SAMLAttributeInfoクラスのリスト

/**
* A class that represents a single Attribute of a SAML Assertion
* AttributeStatement.
*/

class SAMLAttributeInfo {

/**
* Constructs a SAMLAttributeInfo instance with all null fields
*/

public SAMLAttributeInfo();

/**
* Constructs a SAMLAttributeInfo instance representing the SAML 1.1
* Attribute fields
*
* null elements of the Collection are ignored.
* Elements with null 'name' or 'namespace' fields
* are ignored; the resulting SAMLAttributeInfo will not
* be included in a created SAMLAssertion. Null
* attribute values are added as the empty string (ie, “”).
* @param name String
* @param namespace String
* @param values Collection of String values
*/

public SAMLAttributeInfo(String name, String namespace, Collection values;

/**
* Constructs a SAMLAttributeInfo instance representing the attribute fields
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param name String
* @param namespace String
* @param value String
*/

public SAMLAttributeInfo(String name, String namespace, String value);

/**
* sets the name and namespace of this attribute
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param name String, cannot be null
* @param namespace String, cannot be null
*/

public void setAttributeName(String name, String namespace);

/**
* returns the name of this attribute.
* @return String
*/

public String getAttributeName();

/**
* returns a String representing this attribute's namespace
* @return String
*/

public String getAttributeNamespace();

/**
* sets a Collection of Strings representing this attribute's values
* an empty collection adds no values to this instance, collection elements
* that are null are added as empty strings.
*
* @param values Collection
*/

public void setAttributeValues(Collection values);

/**
* adds a single String value to the end
* of this instance's Collection of elements
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param value String
*/

public void addAttributeValue(String value);

/**
* returns a Collection of Strings representing this
* attribute's values, in the order they were added.
* If this attribute has no values, the returned
* value is null.
*
* @return Collection
*/

public Collection getAttributeValues();
}

SAMLCredentialAttributeMapperインタフェース

SAML資格証明マッピング・プロバイダ・バージョン2は、カスタムSAML名マッパーが属性マッピング・インタフェースの実装であるかどうかを判断します。属性マッピング・インタフェースの実装の場合、属性マッピング・インタフェースのメソッドを呼び出し、生成されたSAMLアサーションに書き込むSAML属性の名前/値のペアを取得します。実装で属性マッピング・インタフェースをサポートしない場合、属性マッピングはそのまま省略されます。

SAML資格証明マッピング・プロバイダ・バージョン2は、カスタム属性マッパーから取得された属性名または属性値を検証しません。属性名および属性値は次のとおりに処理されます。

- NULL以外の属性名とネームスペースを持つ任意の属性がSAMLアサーションに書き込まれます。

- NULL属性名またはネームスペースを持つ属性は無視され、後続の同一Collection属性は通常とおりに処理されます。

- NULL値を持つ任意の属性が、""の値と共にSAMLAttributeInfoインスタンスに書き込まれます。結果のSAMLアサーションは、文字列<AttributeValue></AttributeValue>として書き込まれます。

例9-3 SAMLCredentialAttributeMapperインタフェースのリスト

/**
* Interface used to perform mapping of Subject to SAMLAssertions
* attributes.
* <p>
* To specify an instance of this interface to be used by the SAML
* Credential Mapper, set the <tt>NameMapperClassName</tt> attribute.
* <p>
* Classes implementing this interface must have a public no-arg
* constructor and must be in the system classpath.
*
* @author Copyright (c) 2008 by BEA Systems, Inc. All Rights Reserved.
*/

public interface SAMLCredentialAttributeMapper
{
/**
* Maps a <code>Subject</code> to a set of values used to construct a
* <code>SAMLAttributeStatementInfo</code> element for a SAML assertion.
* The returned <code>Collection</code> contains
* SAMLAttributeStatementInfo elements, each element
* of which will be used to
* construct a SAML <code>AttributeStatement</code> element for the SAML
* assertion.
*
* @param subject The <code>Subject</code> that should be mapped.
* @param handler The <code>ContextHandler</code> passed to the SAML
* Credential Mapper.
*
* @return A <code>Collection</code> of SAMLAttributeStatementInfo
* instances,or <code>null</code> if no mapping is made.
*/

public Collection mapAttributes(Subject subject, ContextHandler handler);

SAMLNameMapperInfoクラス用の新規メソッド

SAMLCredentialNameMapperは、SAMLNameMapperInfoクラスで新規メソッドを呼び出し、認証方式属性を取得してSAMLアサーションに書き込まれるように設定します。

新規メソッドは例9-4で示されています。埋込みコメントによって追加情報およびコンテキストが提供されます。

例9-4 SAMLNameMapperInfoクラスのリスト

public class SAMLNameMapperInfo
{
[ existing definition ]
/**
* Called by the SAML Credential Name Mapper implementation to set
* the authentication method attribute to be written to the SAML Assertion.
* See SAML 1.1 Assertions and Protocols, Section 7.1 for possible
* values returned.
*
* @param value the Authentication Method
*/

public void setAuthenticationMethod(String value);

/**
* Called by the SAML Credential Mapper to retrive the authentication
* method attribute to be written to the SAML Assertion. See SAML 1.1
* Assertions and Protocols, Section 7.1 for possible values returned.
*
* @return the Authentication Method
*/

public String getAuthenticationMethod();

例として使用するカスタムSAMLCredentialAttributeMapperクラス

例9-5は、SAMLCredentialNameMapperおよびSAMLCredentialAttributeMapperインタフェースの実装例を示します。

SAMLCredentialNameMapperの実装例が、サブジェクトに保存されたユーザー情報とグループ情報をマッピングする一方で、SAMLCredentialAttributeMapperの実装例はContextHandlerに保存された属性情報をマッピングします。

この例では、属性がContextHandlerに配置される仕組みは示されていません。

SAMLCredentialAttributeMapperを実装し、ContextHandlerではなくサブジェクトに保存された情報をマッピングできます。

埋込みコメントによって追加情報およびコンテキストが提供されます。

例9-5 例として使用するカスタムSAMLCredentialAttributeMapperクラスのリスト

import java.util.ArrayList;
import java.util.Collection;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.security.providers.saml.SAMLAttributeStatementInfo;
import weblogic.security.providers.saml.SAMLAttributeInfo;
import weblogic.security.providers.saml.SAMLCredentialNameMapper;
import weblogic.security.providers.saml.SAMLCredentialAttributeMapper;
import weblogic.security.providers.saml.SAMLNameMapperInfo;
import weblogic.security.service.ContextHandler;
import weblogic.security.service.ContextElement;
import weblogic.security.spi.WLSGroup;
import weblogic.security.spi.WLSUser;

/**
* @exclude
*
* The <code>CustomSAMLAttributeMapperImpl</code> class implements
* name and attribute mapping for the SAML Credential Mapper.
*
* @author Copyright (c) 2004 by BEA Systems, Inc. All Rights Reserved.
*/

public class CustomSAMLAttributeMapperImpl implements
SAMLCredentialNameMapper,SAMLCredentialAttributeMapper
{

/**
* Your logging code here
*/

private final static String defaultAuthMethod =
"urn:oasis:names:tc:SAML:1.0:am:unspecified";

private final static String SAML_CONTEXT_ATTRIBUTE_NAME =
"com.bea.contextelement.saml.context.attribute.name";

private String nameQualifier = null;
private String authMethod = defaultAuthMethod;

public CustomSAMLAttributeMapperImpl()
{
// make constructor public
}

/**
* Set the name qualifier value
*/

public synchronized void setNameQualifier(String nameQualifier) {
this.nameQualifier = nameQualifier;
}

/**
* Map a <code>Subject</code> and return mapped user and group
* info as a <code>SAMLNameMapperInfo</code> object.
*/

public SAMLNameMapperInfo mapSubject(Subject subject, ContextHandler handler) {

// Provider checks for null Subject...
Set subjects = subject.getPrincipals(WLSUser.class);
Set groups = subject.getPrincipals(WLSGroup.class);
String userName = null;

if (subjects == null || subjects.size() == 0) {
yourlogcode("mapSubject: No valid WLSUser principals
found in Subject, returning null");
return null;
}

if (groups == null || groups.size() == 0) {
yourlogcode("mapSubject: No valid WLSGroup pricipals
found in Subject, continuing");
}

if (subjects.size() != 1) {
yourlogcode("mapSubject: More than one WLSUser
principal found in Subject, taking first user only");
}

userName = ((WLSUser)subjects.iterator().next()).getName();
if (userName == null || userName.equals("")) {
yourlogcode("mapSubject: Username string is null or
empty, returning null");
return null;
}

// Return mapping information...
yourlogcode("mapSubject: Mapped subject: qualifier: " +
nameQualifier + ", name: " + userName + ", groups: " + groups);
return new SAMLNameMapperInfo(nameQualifier, userName,
groups);
}
/**
* Map a <code>String</code> subject name and return mapped user and group
* info as a <code>SAMLNameMapperInfo</code> object.
*/

public SAMLNameMapperInfo mapName(String name, ContextHandler handler) {

yourlogcode("mapName: Mapped name: qualifier: " +
nameQualifier + ", name: " + name);
return new SAMLNameMapperInfo(nameQualifier, name, null);
}

/**
* Returns the SAML AttributeName for group information.
*
* @return The AttributeName.
*/

public String getGroupAttrName() {
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAME;
}

/**
* Returns the SAML AttributeNamespace for group information.
*
* @return The AttributeNamespace.
*/

public String getGroupAttrNamespace() {
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAMESPACE;
}

/**
* set the auth method.
* @param method String
*/

public void setAuthenticationMethod(String method)
{
if (method != null)
authMethod = method;
}

/**
* get the auth method
* @return method String
*/

public String getAuthenticationMethod()
{
return authMethod;
}

/**
* maps a Subject/Context to a Collection of SAMLAttributeStatementInfo
* instances.
*
* @return <code>Collection</code>
*/

public Collection mapAttributes(Subject subject, ContextHandler handler)
{
yourlogcode("mapAttributes: Subject: "+subject.toString()+",
ContextHandler: "+handler.toString());

Object element = handler.getValue(SAML_CONTEXT_ATTRIBUTE_NAME);

yourlogcode("mapAttributes: got element from ContextHandler");
yourlogcode("mapAttributes: element is a:"+element.getClass().getName());
TestAttribute[] tas = (TestAttribute[])element;

/*
* loop through all test attributes and write a SAMLAttributeStatementInfo
* for each one.
*/

ArrayList statementList = new ArrayList();
for (int k = 0; k < tas.length; k++)
{
ArrayList al = null;
String[] values = tas[k].getValues();
if (values != null)
{
al = new ArrayList();
for (int i = 0; i < values.length; i++)
if (values[i] != null)
al.add(values[i]);
else al.add("");
}

SAMLAttributeInfo ai = new SAMLAttributeInfo(tas[k].getName(),
tas[k].getNamespace(), al);

SAMLAttributeStatementInfo asi = new
SAMLAttributeStatementInfo();
asi.addAttributeInfo(ai);
statementList.add(asi);
}
return statementList;
}
}

コンソールでカスタムSAMLCredentialAttributeMapperクラスを使用可能にする

SAML資格証明マッピング・プロバイダ・バージョン2がこのSAMLCredentialAttributeMapperインスタンスを使用するようにするには、WebLogic Server管理コンソールを使用して既存のNameMapperClassName属性をこのSAMLCredentialAttributeMapperインスタンスのクラス名に設定します。

つまり、名前マッパー・クラス名属性のコンソール制御を使用して、アクティブ・セキュリティ・レルムでSAMLCredentialAttributeMapperのクラス名を指定します。

次のいずれかの方法を使用してユーザー名マッパー・クラス名属性を構成できます。

- SAMLプロバイダ・バージョン2の場合は1回のみ実行

- 1つ以上のリライイング・パーティの場合は個別に実行

- SAML資格証明マッピング・プロバイダ・バージョン2の場合は両方を実行し、リライイング・パーティに対しては個別に実行します。

WebLogic SAML資格証明マッピング・プロバイダ・バージョン2を使用してカスタム・ユーザー名マッパーを使用するには、次の手順を実行します。

1. まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. 「セキュリティ・レルム」ページで、構成しているレルム名を選択します(たとえばTestRealm)。

3. 「プロバイダ」>「資格証明マッピング」を展開し、SAML資格証明マッピング・プロバイダ・バージョン2の名前を選択します。

4. 「プロバイダ固有」タブを選択します。

5. 「デフォルト名前マッパーのクラス名」フィールドで、SAMLCredentialAttributeMapper実装のクラス名を入力します。
クラス名はシステムのクラスパスに存在する必要があります。

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

7. チェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

SAMLリライイング・パーティを構成するとき、そのリライイング・パーティに固有の名前マッパー・クラスを任意で設定できます。このクラスは、デフォルトの名前マッパー・クラス名に対してここで設定したデフォルト値をオーバーライドします。

管理コンソールで名前マッパー・クラス名を設定する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ユーザー名マッパーの構成に関する項を参照してください。

SAML SSO属性サポートの構成

この項では、SAML SSO属性サポートおよび、それをSAML 2.0およびSAML 1.1と共に使用する方法を説明します。次のトピックが説明されています。

- SAML SSO属性とは

- SAML属性用の新規API

- 必須のSAML 2.0基本属性プロファイル

- 複数の属性のSAML資格証明マッパーへの受け渡し

- SAML属性を実装する方法

- SAML 2.0属性インタフェースの例

- SAML 1.1属性インタフェースの例

- コンソールでカスタムSAML資格証明属性マッパーのクラスを使用可能にする

- コンソールでカスタムSAML IDアサーション・プロバイダ・クラスを使用可能にする

SAML SSO属性とは

SAMLアサーションとは、サブジェクト上で実行された認可操作、サブジェクトの属性情報、または特定のリソースについてサブジェクトに適用している認可データのいずれかに関して、SAML認証局によって作成されたデータです。

SAML仕様(http://www.oasis-open.orgを参照してください)によって、特定のサブジェクトに関する不特定の追加情報を、アサーション内の属性文としてSAMLパートナ間で交換することが可能になります。そのため、SAML属性アサーションとは、サブジェクトの属性に関してサイトが決定した情報を伝達する特定のタイプのSAMLアサーションということになります。

以前のバージョンのWebLogic Serverでは、SAML 1.1資格証明マッピング・プロバイダは、アサーションに含まれるIDの所属先グループを指定するサブジェクト内に保存された属性情報をサポートしていました。

このリリースのWebLogic Serverでは、追加属性(グループ情報以外)を取得してSAMLアサーションに書き込んだり、着信SAMLアサーションからの属性のマップを可能にするカスタム属性マッパーの使用をサポートするために、SAML 1.1および2.0の資格証明マッピング・プロバイダとアイデンティティ・アサーション・プロバイダのメカニズムが強化されています。

これを実行するには:

- (SAML IDプロバイダ・サイト上の)SAML資格証明マッパーは、このカスタム属性マッパーの存在に基づいて属性をパッケージする方法を決定します。

- (SAML サービス・プロバイダ・サイト上の)SAML IDアサーション・プロバイダは、このカスタム名前マッパーの構成に基づいて属性を取得する方法を決定します。

- Javaサブジェクトは、アサーションから取得された属性をアプリケーションで使用できるようにするために使用されます。これには、SAML認証プロバイダが構成され、仮想ユーザーがSAMLパートナ上で有効化されている必要があります。

SAML属性用の新規API

このリリースには、SAML 2.0用の次に示す新規SAML属性のAPIが含まれます。

- SAML2AttributeInfo

- SAML2AttributeStatementInfo

- SAML2CredentialAttributeMapper

- SAML2IdentityAsserterAttributeMapper

SAML 1.1の場合、次の既存SAML属性のAPIをかわりに使用できます。

- SAMLAttributeInfo

- SAMLAttributeStatementInfo

- SAMLCredentialNameMapper
SAMLCredentialAttributeMapper

- SAMLIdentityAssertionAttributeMapper

次の項では、これらのSAML属性のAPIの使用について説明します。

必須のSAML 2.0基本属性プロファイル

SAML 1.1では、SAML属性の名前フォーマットを規定していません。

ただし、SAML 2.0基本属性プロファイルのみはSAML 2.0でサポートされています。SAML2AttributeInfoでurn:oasis:names:tc:SAML:2.0:attrname-format:basic名前フォーマットを持つ属性のみが、SAML 2.0アサーションに書き込まれます。

urn:oasis:names:tc:SAML:2.0:attrname-format:basic名前フォーマットはデフォルトなので、設定する必要はありません。

名前フォーマットをどうしても設定する場合、次に示すようにSAML2.AttributeInfo.setAttributeNameFormatメソッドでurn:oasis:names:tc:SAML:2.0:attrname-format:basicを指定する必要があります。

SAML2AttributeInfo attrInfo = new SAML2AttributeInfo(
"AttributeWithSingleValue", "ValueOfAttributeWithSingleValue");
attrInfo.setAttributeNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");
attrs.add(attrInfo);

複数の属性のSAML資格証明マッパーへの受け渡し

構成された属性マッパーが呼び出されると、Collection<SAML2AttributeStatementInfo>が返されます。複数の属性文を指定できます。それぞれの属性文には複数の属性が含まれ、それぞれの属性には複数の属性値が含まれる可能性があります。

この実行例は次のとおりです。

private Collection<SAML2AttributeStatementInfo> getAttributeStatementInfo(
Subject subject, ContextHandler handlers) {
Collection<SAML2AttributeInfo> attrs = new ArrayList<SAML2AttributeInfo>();

SAML2AttributeInfo attrInfo = new SAML2AttributeInfo(
"AttributeWithSingleValue", "ValueOfAttributeWithSingleValue");
attrInfo.setAttributeNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");
attrs.add(attrInfo);

ArrayList<String> v = new ArrayList<String>();
v.add("Value1OfAttributeWithMultipleValue");
v.add("Value2OfAttributeWithMultipleValue");
v.add("Value3OfAttributeWithMultipleValue");
SAML2AttributeInfo attrInfo1 = new SAML2AttributeInfo(
"AttributeWithMultipleValue", v);
attrInfo1.setAttributeNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");

attrs.add(attrInfo1);

SAML2AttributeInfo attrInfo2 = new SAML2AttributeInfo(
"AttributeWithInvalidNameFormat",
"ValueOfAttributeWithInvalidNameFormatValue");
attrInfo2.setAttributeNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified");
attrs.add(attrInfo2);

SAML2AttributeInfo attrInfo3 = new SAML2AttributeInfo(
"AttributeWithNullValue", "null");
attrInfo3.setAttributeNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");
attrs.add(attrInfo3);
:
:
Collection<SAML2AttributeStatementInfo> attrStatements = new ArrayList<SAML2AttributeStatementInfo>();
attrStatements.add(new SAML2AttributeStatementInfo(attrs));
attrStatements.add(new SAML2AttributeStatementInfo(attrs1));
return attrStatements;
}

SAML属性を実装する方法

この項では、SAML属性を実装するためにたどるプロセスを段階を踏んで説明します。

注意:

この項では、使用する例にSAML 2.0インタフェース名を使用します。SAML 1.1の使用法は、マッパー関連クラスとパートナ関連クラスのインタフェース名およびマッパーの構成に使用される属性名とメソッド名が異なる点以外は酷似しています。

SAML資格証明マッピング(IDプロバイダ)サイトから、

1. SAML2AttributeInfoおよびSAML2AttributeStatementInfoクラスをインスタンス化します。
SAML2CredentialAttributeMapperインタフェースを実装します。

また、同一の実装でSAML2CredentialNameMapperインタフェースを実装します。(SAML2CredentialAttributeMapperおよびSAML2CredentialNameMapperインタフェースは、両方とも同一の実装内に存在する必要があります。)

SAML2CredentialNameMapperインタフェースを実装すると、WebLogic Server管理コンソールを使用して、NameMapperClassName属性をSAML2CredentialAttributeMapperインスタンスのクラス名に設定できます。

2. WebLogic Server管理コンソールを使用すると、新しいカスタム属性マッパーを識別するためにSAML資格証明マッピング・プロバイダのNameMapperClassName属性を使用して、SAMLプロバイダ上または各パートナ上で新しいカスタム属性マッパーを構成できます。「コンソールでカスタムSAML資格証明属性マッパーのクラスを使用可能にする」を参照してください。

3. SAML資格証明マッピング・プロバイダは、構成済のカスタム名マッパーが属性マッピング・インタフェースの実装であるかどうかを判定します。実装である場合、このプロバイダはカスタム属性マッピング・インタフェースを呼び出し、生成されたSAMLアサーションに書き込むための属性値を取得します。

4. SAML資格証明マッピング・プロバイダは、カスタム属性マッパーから取得された属性名または属性値を検証しません。
NULL以外の属性名を持つ任意の属性がSAMLアサーションの属性文に書き込まれます。NULLまたは空の属性名を持つ属性は無視され、次の属性が処理されます。

属性に複数の値が含まれる場合、各値はSAML属性文で単一の<Attribute>の<AttributeValue>要素として表示されます。

SAML 1.1の場合、NULL値を持つ属性は空の文字列("")としてSAMLアサーションに書き込まれます。

SAML 2.0の場合、NULLまたは空の属性値はアサーションおよび『OASIS SAML V2.0用プロトコル2005年3月』 (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)に基づいて処理されます。

urn:oasis:names:tc:SAML:2.0:attrname-format:basic以外の名前フォーマットを持つ属性はスキップされます。

SAML IDアサーション(サービス・プロバイダ)サイトから:

1. 同一の実装でSAML2IdentityAsserterAttributeMapperおよびSAML2IdentityAsserterNameMapperインタフェースを実装します。(SAML2IdentityAsserterAttributeMapperおよびSAML2IdentityAsserterNameMapperインタフェースは、両方とも同一の実装内に存在する必要があります)
SAML2IdentityAsserterNameMapperインタフェースを実装すると、WebLogic Server管理コンソールを使用して、NameMapperClassName属性をSAML2IdentityAsserterAttributeMapperインスタンスのクラス名に設定できます。

2. WebLogic Server管理コンソールを使用して、「コンソールでカスタムSAML IDアサーション・プロバイダ・クラスを使用可能にする」で説明されているように、SAML IDアサーション・プロバイダを構成します。NameMapperClassName属性をカスタムSAML2IdentityAsserterAttributeMapperインスタンスのクラス名に設定します。
SAML IDアサーション・プロバイダは、受信側のSAMLアサーションの<AttributeStatement>要素を処理し、SAML属性文のコレクションを構築します。

3. SAML IDアサーション・プロバイダは、構成済カスタム名マッパーがSAML2IdentityAsserterAttributeMapperインタフェースを実装するかどうかを決定します。実装しない場合、SAML IDアサーション・プロバイダはmapAttributeInfoメソッドを呼び出し、SAMLアサーションの属性を取得します。
mapAttributeInfoメソッドは、SAMLアサーションで属性文の属性を示すSAMLAttributeStatementInfoインスタンスのCollectionを取得し、任意のアプリケーションに固有の方法で対象の属性にマッピングします。

4. SAML IDアサーション・プロバイダは、SAMLアサーションから取得した属性をJavaサブジェクトを介してコンシューマで使用できるようにします。これには、SAML認証プロバイダが構成され、仮想ユーザーがSAMLパートナ上で有効化されている必要があります。
マッパーから返された属性は、マッピングされた属性のクラス・タイプに応じて、サブジェクト・プリンシパルまたはプライベートな資格証明として保存されます。具体的には、マッパーがPrincipalオブジェクトのコレクションを返す場合、マッピングされた属性はサブジェクト・プリンシパル設定に保存されます。それ以外の場合、サブジェクトのプライベートな資格証明の設定は、マッピングされた属性を伝達するために使用されます。

消費コードは、例9-7で示されるように、マッパーがサブジェクトに追加される属性を表すのに使用するオブジェクトのクラス・タイプの情報を取得する必要があります。

5. SAML IDアサーション・プロバイダは、ContextHandlerおよび属性マッパーを確認します。(この段階説明では、手順4で説明されているように属性マッパーがあることを想定しています)。

注意:

ContextHandlerと属性マッパーの両方が存在して構成されている場合、『Oracle WebLogic ServerのWebLogic Webサービスの保護』で説明されているように、かわりに属性はContextHandlerを介してWebサービスに対して使用できるようになります。

SAML 2.0属性インタフェースの例

この項では、追加属性をSAMLアサーションに書き込めるようにするSAML 2.0属性インタフェースの実装例を説明します。

カスタムSAML 2.0資格証明属性マッパーの例

例9-6は、SAML2CredentialNameMapperインタフェースおよびSAML2CredentialAttributeMapperインタフェースの両方を実装する単一のクラス例を示します。

例9-6 SAML 2.0資格証明属性マッパー

public class CustomSAML2CredentialAttributeMapperImpl implements
SAML2CredentialNameMapper, SAML2CredentialAttributeMapper {
private String nameQualifier = null;

public Collection<SAML2AttributeStatementInfo> mapAttributes(
Subject subject, ContextHandler handler) {
return getAttributeStatementInfo(subject, handler);
}
/**
* same as SAML2NameMapperImpl
*/
public SAML2NameMapperInfo mapName(String name, ContextHandler handler) {
System.out
.println("CustomSAML2CredentialAttributeMapperImpl:mapName: Mapped name: qualifier: "
+ nameQualifier + ", name: " + name);
return new SAML2NameMapperInfo(nameQualifier, name, null);
}

/**
* same as SAML2NameMapperImpl
*/
public synchronized void setNameQualifier(String nameQualifier) {
this.nameQualifier = nameQualifier;
}

/**
* same as SAML2NameMapperImpl
*/
public SAML2NameMapperInfo mapSubject(Subject subject,
ContextHandler handler) {

// Provider checks for null Subject...
Set subjects = subject.getPrincipals(WLSUser.class);
Set groups = subject.getPrincipals(WLSGroup.class);
String userName = null;
Set<String> groupStrings = new java.util.HashSet();

if (subjects == null || subjects.size() == 0) {
System.out
.println("CustomSAML2CredentialAttributeMapperImpl:mapSubject: No valid WLSUser pricipals found in Subject, returning null");
return null;
}

if (groups == null || groups.size() == 0) {
System.out
.println("CustomSAML2CredentialAttributeMapperImpl:mapSubject: No valid WLSGroup pricipals found in Subject, continuing");
}
else{
java.util.Iterator<WLSGroup> it = groups.iterator();
while(it.hasNext()){
WLSGroup wg = it.next();
groupStrings.add(wg.getName());
}
}

if (subjects.size() != 1) {
System.out
.println("CustomSAML2CredentialAttributeMapperImpl:mapSubject: More than one WLSUser principal found in Subject, taking first user only");
}

userName = ((WLSUser) subjects.iterator().next()).getName();
if (userName == null || userName.equals("")) {
System.out
.println("CustomSAML2CredentialAttributeMapperImpl:mapSubject: Username string is null or empty, returning null");
return null;
}

// Return mapping information...
System.out
TRACE.info("CustomSAML2CredentialAttributeMapperImpl:mapSubject: Mapped subject: qualifier: "
+ nameQualifier
+ ", name: "
+ userName
+ ", groups: "
+ groups);

SAML2NameMapperInfo saml2NameMapperInfo = new
SAML2NameMapperInfo(nameQualifier, userName, groupStrings);
//SAML2NameMapperInfo saml2NameMapperInfo = new
SAML2NameMapperInfo(nameQualifier, userName, groups);

return new SAML2NameMapperInfo(nameQualifier, userName, groups);
}

private Collection<SAML2AttributeStatementInfo> getAttributeStatementInfo(
Subject subject, ContextHandler handlers) {
Collection<SAML2AttributeInfo> attrs = new ArrayList<SAML2AttributeInfo>();

SAML2AttributeInfo attrInfo = new SAML2AttributeInfo(
"AttributeWithSingleValue", "ValueOfAttributeWithSingleValue");
attrInfo.setAttributeNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");
attrs.add(attrInfo);

ArrayList<String> v = new ArrayList<String>();
v.add("Value1OfAttributeWithMultipleValue");
v.add("Value2OfAttributeWithMultipleValue");
v.add("Value3OfAttributeWithMultipleValue");
SAML2AttributeInfo attrInfo1 = new SAML2AttributeInfo(
"AttributeWithMultipleValue", v);
attrInfo.setAttributeNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");

attrs.add(attrInfo1);
:
:
Collection<SAML2AttributeStatementInfo> attrStatements = new ArrayList<SAML2AttributeStatementInfo>();
attrStatements.add(new SAML2AttributeStatementInfo(attrs));
attrStatements.add(new SAML2AttributeStatementInfo(attrs1));
return attrStatements;
}
}

「コンソールでカスタムSAML資格証明属性マッパーのクラスを使用可能にする」で説明されているように、WebLogic Server管理コンソールを使用して、マッパー実装の完全修飾クラス名にユーザー名マッパー・クラス名を構成します。

カスタム・マッパー実装によって返されたSAML2AttributeStatementInfoオブジェクトのコレクションでカプセル化された属性は、SAML 2.0資格証明マッピング・プロバイダによって生成されたアサーションに含まれます。

カスタムSAML 2.0 IDアサーション・プロバイダ属性マッパー

例9-7は、SAML2IdentityAsserterNameMapperおよびSAML2IdentityAsserterAttributeMapperの実装例を示します。

例9-7 カスタムSAML 2.0 IDアサーション・プロバイダ属性マッパー

public class CustomSAML2IdentityAsserterAttributeMapperImpl implements
SAML2IdentityAsserterNameMapper, SAML2IdentityAsserterAttributeMapper {
/**
* same as SAML2NameMapperImpl
*/
public String mapNameInfo(SAML2NameMapperInfo info, ContextHandler handler) {
// Get the user name ...
String userName = info.getName();
System.out
.println("CustomSAML2IdentityAsserterAttributeMapperImpl:mapNameInfo: returning name: "
+ userName);
return userName;
}
}
:
:
public Collection<Object> mapAttributeInfo0(
Collection<SAML2AttributeStatementInfo> attrStmtInfos,
ContextHandler contextHandler) {
if (attrStmtInfos == null || attrStmtInfos.size() == 0) {
System.out
.println("CustomIAAttributeMapperImpl: attrStmtInfos has no elements");
return null;
}

Collection<Object> customAttrs = new ArrayList<Object>();

for (SAML2AttributeStatementInfo stmtInfo : attrStmtInfos) {
Collection<SAML2AttributeInfo> attrs = stmtInfo.getAttributeInfo();
if (attrs == null || attrs.size() == 0) {
System.out
.println("CustomIAAttributeMapperImpl: no attribute in statement: "
+ stmtInfo.toString());
} else {
for (SAML2AttributeInfo attr : attrs) {
if (attr.getAttributeName().equals("AttributeWithSingleValue")){
CustomPrincipal customAttr1 = new CustomPrincipal(attr
.getAttributeName(), attr.getAttributeNameFormat(),
attr.getAttributeValues());
customAttrs.add(customAttr1);
}else{
String customAttr = new StringBuffer().append(
attr.getAttributeName()).append(",").append(
attr.getAttributeValues()).toString();
customAttrs.add(customAttr);
}
}
}
}
return customAttrs;
}

public Collection<Principal> mapAttributeInfo(
Collection<SAML2AttributeStatementInfo> attrStmtInfos,
ContextHandler contextHandler) {
if (attrStmtInfos == null || attrStmtInfos.size() == 0) {
System.out
.println("CustomIAAttributeMapperImpl: attrStmtInfos has no elements");
return null;
}

Collection<Principal> pals = new ArrayList<Principal>();

for (SAML2AttributeStatementInfo stmtInfo : attrStmtInfos) {
Collection<SAML2AttributeInfo> attrs = stmtInfo.getAttributeInfo();
if (attrs == null || attrs.size() == 0) {
System.out
.println("CustomIAAttributeMapperImpl: no attribute in statement: "
+ stmtInfo.toString());
} else {
for (SAML2AttributeInfo attr : attrs) {
CustomPrincipal pal = new CustomPrincipal(attr
.getAttributeName(), attr.getAttributeNameFormat(),
attr.getAttributeValues());
pals.add(pal);
}
}
}
return pals;
}

SAML 2.0 IDアサーション・プロバイダは、SAMLアサーションから取得した属性をサブジェクトを介してコンシューマで使用できるようにします。

「コンソールでカスタムSAML IDアサーション・プロバイダ・クラスを使用可能にする」で説明されているように、WebLogic Server管理コンソールを使用して、マッパー実装の完全修飾クラス名にユーザー名マッパー・クラス名を構成します。

仮想ユーザーがSAMLでログインすることを許可している場合は、SAML認証プロバイダのインスタンスを作成して構成する必要があります。詳細は、「SAML認証プロバイダの構成」を参照してください。

仮想ユーザーが有効化しており、SAML認証プロバイダが構成されている場合、カスタム属性マッパーによって返される属性がサブジェクトに追加されます。

マッパーから返された属性は、マッピングされた属性のクラス・タイプに応じて、サブジェクト・プリンシパルまたはプライベートな資格証明として保存されます。具体的には、マッパーがPrincipalオブジェクトのコレクションを返す場合、マッピングされた属性はサブジェクト・プリンシパル設定に保存されます。それ以外の場合、サブジェクトのプライベートな資格証明の設定は、マッピングされた属性を伝達するために使用されます。コード例では、両方のアプローチが示されています。

アプリケーション・コードは、サブジェクトに追加される属性を示すためにマッパーが使用するオブジェクトのクラス・タイプに関する情報を取得する必要があります。アプリケーションは、顧客属性マッパーが属性の表示に使用するクラス・タイプが付与されると、サブジェクトのプライベートな資格証明またはプリンシパルの設定からSAML属性を取得できます。

SAML 1.1属性インタフェースの例

この項では、追加属性をSAMLアサーションに書き込めるようにするSAML 1.1属性インタフェースの実装例を説明します。

カスタムSAML 1.1資格証明属性マッパーの例

例9-8は、SAMLCredentialNameMapperインタフェースおよびSAMLCredentialAttributeMapperインタフェースの両方を実装する単一のクラス例を示します。

例9-8 SAML 1.1資格証明属性マッパー

public class CustomCredentialAttributeMapperImpl implements
SAMLCredentialNameMapper, SAMLCredentialAttributeMapper {
private String nameQualifier = null;

public Collection<SAMLAttributeStatementInfo> mapAttributes(Subject subject,
ContextHandler handler) {
return AttributeStatementInfoGenerator.getInfos(subject, handler);
}
…
public SAMLNameMapperInfo mapSubject(Subject subject, ContextHandler handler) {

// Provider checks for null Subject...
Set subjects = subject.getPrincipals(WLSUser.class);
Set groups = subject.getPrincipals(WLSGroup.class);
String userName = null;
:
userName = ((WLSUser) subjects.iterator().next()).getName();
if (userName == null || userName.equals("")) {
System.out
.println("CustomCredentialAttributeMapperImpl:mapSubject: Username string is null or empty, returning null");
return null;
}
:
// Return mapping information...
System.out
.println("CustomCredentialAttributeMapperImpl:mapSubject: Mapped subject: qualifier: "
+ nameQualifier + ", name: " + userName + ", groups: " + groups);
return new SAMLNameMapperInfo(nameQualifier, userName, groups);
}
:
:
class AttributeStatementInfoGenerator {
static final String SAML_ATTR_NAME_SAPCE = "urn:bea:security:saml:attributes";

static Collection<SAMLAttributeStatementInfo> getInfos(Subject subject,
ContextHandler handlers) {
SAMLAttributeInfo info1 = new SAMLAttributeInfo("AttributeWithSingleValue",
SAML_ATTR_NAME_SAPCE, "ValueOfAttributeWithSingleValue");

ArrayList<String> v2 = new ArrayList<String>();
v2.add("Value1OfAttributeWithMultipleValue");
v2.add("Value2OfAttributeWithMultipleValue");
SAMLAttributeInfo info2 = new SAMLAttributeInfo("AttributeWithMultipleValue",
SAML_ATTR_NAME_SAPCE, v2);

SAMLAttributeStatementInfo stmt1 = new SAMLAttributeStatementInfo();
stmt1.addAttributeInfo(info1);
stmt1.addAttributeInfo(info2);

ArrayList<SAMLAttributeStatementInfo> result = new ArrayList<SAMLAttributeStatementInfo>();
result.add(stmt1);
:
:
return result;
}

「コンソールでカスタムSAML資格証明属性マッパーのクラスを使用可能にする」で説明されているように、WebLogic Server管理コンソールを使用して、マッパー実装の完全修飾クラス名にユーザー名マッパー・クラス名を構成します。

カスタム・マッパー実装によって返されたSAMLAttributeStatementInfoオブジェクトのコレクションでカプセル化された属性は、SAML 1.1資格証明マッピング・プロバイダによって生成されたアサーションに含まれます。

カスタムSAML 1.1 IDアサーション・プロバイダ属性マッパー

例9-9は、SAMLIdentityAssertionNameMapperおよびSAMLIdentityAssertionAttributeMapperの実装例を示します。

例9-9 カスタムSAML 1.1 IDアサーション・プロバイダ属性マッパー

public class CustomIdentityAssertionAttributeMapperImpl implements
SAMLIdentityAssertionNameMapper, SAMLIdentityAssertionAttributeMapper {

public String mapNameInfo(SAMLNameMapperInfo info, ContextHandler handler) {
// Get the user name ...
String userName = info.getName();
System.out
.println("CustomIdentityAssertionAttributeMapperImpl:mapNameInfo: returning name: "
+ userName);
return userName;
}

:
public void mapAttributeInfo(
Collection<SAMLAttributeStatementInfo> attrStmtInfos,
ContextHandler contextHandler) {
if (attrStmtInfos == null || attrStmtInfos.size() == 0) {
System.out
.println("CustomIAAttributeMapperImpl: attrStmtInfos has no elements");
return;
}
:
Object obj = contextHandler  .getValue(ContextElementDictionary.SAML_ATTRIBUTE_PRINCIPALS);
if (obj == null || !(obj instanceof Collection)) {
System.out.println("CustomIAAttributeMapperImpl: can't get "
+ ContextElementDictionary.SAML_ATTRIBUTE_PRINCIPALS
+ " from context handler");
return;
}
:
Collection<Principal> pals = (Collection<Principal>) obj;

for (SAMLAttributeStatementInfo stmtInfo : attrStmtInfos) {
Collection<SAMLAttributeInfo> attrs = stmtInfo.getAttributeInfo();
if (attrs == null || attrs.size() == 0) {
System.out
.println("CustomIAAttributeMapperImpl: no attribute in statement: "
+ stmtInfo.toString());
} else {
for (SAMLAttributeInfo attr : attrs) {
CustomPrincipal pal = new CustomPrincipal(attr.getAttributeName(),
attr.getAttributeNamespace(), attr.getAttributeValues());
pals.add(pal);
}
}
}
}

SAML 1.1 IDアサーション・プロバイダは、SAMLアサーションから取得した属性をサブジェクトを介してコンシューマで使用できるようにします。

「コンソールでカスタムSAML IDアサーション・プロバイダ・クラスを使用可能にする」で説明されているように、WebLogic Server管理コンソールを使用して、マッパー実装の完全修飾クラス名にユーザー名マッパー・クラス名を構成します。

仮想ユーザーがSAMLでログインすることを許可している場合は、SAML認証プロバイダのインスタンスを作成して構成する必要があります。詳細は、「SAML認証プロバイダの構成」を参照してください。

仮想ユーザーが有効化しており、SAML認証プロバイダが構成されている場合、カスタム属性マッパーによって返される属性がサブジェクトに追加されます。

マッパーから返された属性は、マッピングされた属性のクラス・タイプに応じて、サブジェクト・プリンシパルまたはプライベートな資格証明として保存されます。具体的には、マッパーがPrincipalオブジェクトのコレクションを返す場合、マッピングされた属性はサブジェクト・プリンシパル設定に保存されます。それ以外の場合、サブジェクトのプライベートな資格証明の設定は、マッピングされた属性を伝達するために使用されます。

アプリケーション・コードは、サブジェクトに追加される属性を示すためにマッパーが使用するオブジェクトのクラス・タイプに関する情報を取得する必要があります。アプリケーションは、顧客属性マッパーが属性の表示に使用するクラス・タイプが付与されると、サブジェクトのプライベートな資格証明またはプリンシパルの設定からSAML属性を取得できます。

コンソールでカスタムSAML資格証明属性マッパーのクラスを使用可能にする

SAML資格証明マッピング・プロバイダがSAML2CredentialAttributeMapper (SAML 2.0)またはSAMLCredentialAttributeMapper (SAML 1.1)インスタンスを使用するようにするには、WebLogic Server管理コンソールを使用して既存のNameMapperClassName属性をこのSAML2CredentialAttributeMapperまたはSAML2CredentialAttributeMapperインスタンスのクラス名に設定します。

つまり、名前マッパー・クラス名属性のコンソール制御を使用して、アクティブ・セキュリティ・レルムでSAML2CredentialAttributeMapperまたはSAMLCredentialAttributeMapperインスタンスのクラス名を指定します。

WebLogic SAML資格証明マッピング・プロバイダを使用してカスタム・ユーザー名マッパーを使用するには、次の手順を実行します。

1. まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. 「セキュリティ・レルム」ページで、構成しているレルム名を選択します(たとえばTestRealm)。

3. 「プロバイダ」>「資格証明マッピング」を展開し、SAML 2.0資格証明マッピング・プロバイダの名前またはSAML資格証明マッピング・プロバイダ・バージョン2を選択します。

4. 「プロバイダ固有」タブを選択します。

5. 「名前マッパーのクラス名」(SAML 2.0)または「デフォルト名前マッパーのクラス名」(SAML 1.1)フィールドで、SAML2CredentialAttributeMapperまたはSAMLCredentialAttributeMapper実装のクラス名を入力します。
クラス名はシステムのクラスパスに存在する必要があります。

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

7. チェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

コンソールでカスタムSAML IDアサーション・プロバイダ・クラスを使用可能にする

SAML IDアサーション・プロバイダがこのSAML2IdentityAsserterAttributeMapper (SAML 2.0)またはSAMLIdentityAssertionAttributeMapper (SAML 1.1)インスタンスを使用するようにするには、WebLogic Server管理コンソールを使用して既存のNameMapperClassName属性をこのSAML2IdentityAsserterAttributeMapperまたはSAMLIdentityAssertionAttributeMapperインスタンスのクラス名に設定します。

つまり、名前マッパー・クラス名属性のコンソール制御を使用して、アクティブ・セキュリティ・レルムでSAML2IdentityAsserterAttributeMapperまたはSAMLIdentityAssertionAttributeMapperインスタンスのクラス名を指定します。

WebLogic SAML IDアサーション・プロバイダを使用してカスタム・ユーザー名マッパーを使用するには、次の手順を実行します。

1. まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. 「セキュリティ・レルム」ページで、構成しているレルム名を選択します(たとえばTestRealm)。

3. 「プロバイダ」>「認証」を展開し、SAML 2.0 IDアサーション・プロバイダの名前またはSAML IDアサーション・プロバイダ・バージョン2を選択します。

4. 「プロバイダ固有」タブを選択します。

5. 「名前マッパーのクラス名」(SAML 2.0)または「デフォルト名前マッパーのクラス名」(SAML 1.1)フィールドで、SAML2IdentityAsserterAttributeMapperまたはSAMLIdentityAssertionAttributeMapper実装のクラス名を入力します。
クラス名はシステムのクラスパスに存在する必要があります。

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

7. チェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

管理コンソールで名前マッパー・クラス名を設定する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ユーザー名マッパーの構成に関する項を参照してください。

10 証明書パスの作成と検証

この項では、証明書パスの作成と検証の使用について説明します。

WebLogicセキュリティ・サービスは、X509証明書チェーンを検索および検証するためのCertificate Lookup and Validation (CLV) APIを提供します。

証明書パスは、メモリー内に証明書チェーンを格納するJDKクラスです。「証明書パス」という用語は、証明書チェーンを検索および検証するためのJDKアーキテクチャおよびフレームワークを指す場合にも使われます。このCLVフレームワークは、JDK CertPath機能を拡張および完了します。証明書パス・プロバイダは、WebLogicインタフェースとJDKインタフェースの緊密な統合に依存します。

アプリケーション・コードでの証明書チェーンの作成および検証には、WebLogic Serverに用意されたデフォルトの証明書パス・プロバイダか、カスタム証明書パス・プロバイダを使用できます。

この節では、以下の内容について説明します。

- 証明書パスの作成

- 証明書パスの検証

- CertPathSelectorのインスタンス化

- CertPathBuilderParametersのインスタンス化

- JDK CertPathBuilderインタフェースの使用

- CertPathValidatorParametersのインスタンス化

- JDK CertPathValidatorインタフェースの使用

証明書パスの作成

アプリケーションで証明書パス・ビルダーを使用するには、次の手順に従います。

1. CertPathSelectorのインスタンス化

2. CertPathBuilderParametersのインスタンス化

3. JDK CertPathBuilderインタフェースの使用

CertPathSelectorのインスタンス化

CertPathSelectorインタフェース(weblogic.security.pk.CertPathSelector)には、証明書パスを検索して検証するための選択条件が含まれています。証明書パスは様々な方法で検索できるため、選択条件ごとに派生クラスが実装されています。

各セレクタ・クラスには、選択データおよびコンストラクタを取得するためのメソッドが1つまたは複数あります。

CertPathSelectorインタフェースを実装するweblogic.security.pk内のクラスは、次に示すように、サポートされている証明書チェーン検索の種類ごとに1つずつあります。

- EndCertificateSelector - 目的の証明書がある証明書チェーンを検索および検証する場合に使用します。

- IssuerDNSerialNumberSelector - 目的の証明書の発行DNとシリアル番号から証明書チェーンを検索および検証する場合に使用します。

- SubjectDNSelector - 目的の証明書のサブジェクトDNから証明書チェーンを検索および検証する場合に使用します。

- SubjectKeyIdentifierSelector - 目的の証明書のサブジェクト・キー識別子(X509証明書の省略可能なフィールド)から証明書チェーンを検索および検証する場合に使用します。

注意:

サポートされるセレクタは、構成済みの証明書パス・プロバイダによって異なります。構成済みの証明書パス・プロバイダは管理者が決定します。

WebLogic証明書パス・プロバイダでは、EndCertificateSelectorセレクタのみを使用します。

例10-1に、セレクタの選択例を示します。

例10-1 証明書チェーン・セレクタの指定

// you already have the end certificate
// and want to use it to lookup and
// validate the corresponding chain
X509Certificate endCertificate = ...
// make a cert chain selector
CertPathSelector selector = new EndCertificateSelector(endCertificate);

CertPathBuilderParametersのインスタンス化

JDKのCertPathBuilder.build()メソッドに、CertPathBuilderParametersのインスタンスをCertPathParametersオブジェクトとして渡します。

次のコンストラクタとメソッドを利用できます。

- CertPathBuilderParameters

public CertPathBuilderParameters(String realmName,
CertPathSelector selector,
X509Certificate[]
trustedCAs,
ContextHandler context)

CertPathBuilderParametersを作成します。

レルム名を指定する必要があります。そのためには、ドメインのSecurityConfigurationMBeanを取得します。次に、SecurityConfigurationMBeanのデフォルトのレルム属性(レルムMBean)を取得します。最後に、レルムMBeanの名前属性を取得します。レルム名の取得には、実行時JMX MBeanサーバーを使用する必要があります。

selectorを指定する必要があります。weblogic.security.pk.CertPathSelectorインタフェースのいずれかの派生クラスを使用します。証明書パスを検索および検証するための選択条件の指定については、「CertPathSelectorのインスタンス化」を参照してください。

信頼性のあるCAがある場合は指定します。そうしない場合は、サーバーの信頼性のあるCAが使用されます。これらは、構成済みの証明書パス・ビルダーおよび証明書パス検証プロバイダに対する単なるヒントです。それらは、使用する検索/検証アルゴリズムによって、信頼性のあるCAを使用する場合と使用しない場合があります。

ContextHandlerは、構成済みの証明書パス・ビルダーおよび証明書パス検証プロバイダが、チェーンの検索と検証に使用する名前/値ペアのリスト(オプション)を渡すために使用します。他の種類のセキュリティ・プロバイダに渡されるコンテキスト・ハンドラと対称的です。コンテキスト・パラメータがないことを示すためには、コンテキストをnullに設定します。

- clone

Object clone()

このインタフェースのクローンは作成できません。

例10-2に、CertPathBuilderParametersのインスタンスを渡す例を示します。

例10-2 CertPathBuilderParametersのインスタンスを渡す例

// make a cert chain selector
CertPathSelector selector = new EndCertificateSelector(endCertificate);
String realm = _;
// create and populate a context handler if desired, or null
ContextHandler context = _;
// pass in a list of trusted CAs if desired, or null
X509Certificate[] trustedCAs = _;
// make the params
CertPathBuilderParams params =
new CertPathBuilderParameters(realm, selector, context, trustedCAs);

JDK CertPathBuilderインタフェースの使用

java.security.cert.CertPathBuilderインタフェースは、CertPathBuilderクラスのAPIです。JDKのCertPathBuilderインタフェースを使用するには、次を行います:

1. 静的なCertPathBuilder.getInstanceメソッドを呼び出して、CLVフレームワークのCertPathBuilderを取得します。呼出しに渡すアルゴリズム名として「WLSCertPathBuilder」を指定する必要があります。

2. CertPathBuilderオブジェクトが取得できたら、返されたCertPathBuilderで「build」メソッドを呼び出します。このメソッドが取る引数はCertPathParametersだけです。この引数は、どのチェーンを検索して、それをどのように検証するかを示します。
JDKのCertPathBuilder.build()メソッドにweblogic.security.pk.CertPathBuilderParametersのインスタンスをCertPathParametersオブジェクトとして渡す必要があります。詳細については、「CertPathBuilderParametersのインスタンス化」を参照してください。

3. 以上の手順を正常に完了すると、CertPathBuilderResultインタフェースを実装するオブジェクトに結果(作成された証明書パスを含む)が返されます。証明書パスをどこまで返すかはビルダーが判断します。

4. 正常に完了しなかった場合は、CertPathBuilderのbuildメソッドから例外がスローされます。パラメータがWebLogic CertPathBuilderParametersでない場合、構成済みのCertPathBuilderでセレクタがサポートされていない場合、およびレルム名がサーバー起動時のデフォルト・レルムのレルム名と一致しない場合は、InvalidAlgorithmParameterExceptionがスローされます。
証明書パスが見つからない場合や、見つかった証明書パスが有効でない場合は、CertPathBuilderのbuildメソッドからCertPathBuilderExceptionがスローされます。

証明書チェーンの検索のコード・フロー例

例10-3 証明書チェーンの検索

import weblogic.security.pk.CertPathBuilderParameters;
import weblogic.security.pk.CertPathSelector;
import weblogic.security.pk.EndCertificateSelector;
import weblogic.security.service.ContextHandler;
import java.security.cert.CertPath;
import java.security.cert.CertPathBuilder;
import java.security.cert.X509Certificate;
// you already have the end certificate
// and want to use it to lookup and
// validate the corresponding chain
X509Certificate endCertificate = ...

// make a cert chain selector
CertPathSelector selector = new EndCertificateSelector(endCertificate);

String realm = _;

// create and populate a context handler if desired
ContextHandler context = _;

// pass in a list of trusted CAs if desired
X509Certificate[] trustedCAs = _;

// make the params
CertPathBuilderParams params =
new CertPathBuilderParameters(realm, selector, context, trustedCAs);
// get the WLS CertPathBuilder
CertPathBuilder builder =
CertPathBuilder.getInstance("WLSCertPathBuilder");

// use it to look up and validate the chain
CertPath certpath = builder.build(params).getCertPath();
X509Certificate[] chain =
certpath.getCertificates().toArray(new X509Certificate[0]);

証明書パスの検証

アプリケーションで証明書パス検証プロバイダを使用するには、次の手順に従います。

1. CertPathValidatorParametersのインスタンス化

2. JDK CertPathValidatorインタフェースの使用

CertPathValidatorParametersのインスタンス化

JDKのCertPathValidator.validate()メソッドに、CertPathValidatorParametersのインスタンスをCertPathParametersオブジェクトとして渡します。

次のコンストラクタとメソッドを利用できます。

- CertPathValidatorParameters

public CertPathValidatorParameters(String realmName,
X509Certificate[] trustedCAs,
ContextHandler context)

CertPathValidatorParametersを作成します。

レルム名を指定する必要があります。そのためには、ドメインのSecurityConfigurationMBeanを取得します。次に、SecurityConfigurationMBeanのデフォルトのレルム属性(レルムMBean)を取得します。最後に、レルムMBeanの名前属性を取得します。レルム名の取得には、実行時JMX MBeanサーバーを使用する必要があります。

信頼性のあるCAがある場合は指定します。そうしない場合は、サーバーの信頼性のあるCAが使用されます。これらは、構成済みの証明書パス・ビルダーおよび証明書パス検証プロバイダに対する単なるヒントです。それらは、使用する検索/検証アルゴリズムによって、信頼性のあるCAを使用する場合と使用しない場合があります。

ContextHandlerは、構成済みの証明書パス・ビルダーおよび証明書パス検証プロバイダが、チェーンの検索と検証に使用する名前/値ペアのリスト(オプション)を渡すために使用します。他の種類のセキュリティ・プロバイダに渡されるコンテキスト・ハンドラと対称的です。コンテキスト・パラメータがないことを示すためには、コンテキストをnullに設定します。

- clone

Object clone()

このインタフェースのクローンは作成できません。

例10-4に、CertPathValidatorParametersのインスタンスを渡す例を示します。

例10-4 CertPathValidatorParametersのインスタンスを渡す例

// get the WLS CertPathValidator
CertPathValidator validator =
CertPathValidator.getInstance("WLSCertPathValidator");

String realm = _;

// create and populate a context handler if desired, or null
ContextHandler context = _;

// pass in a list of trusted CAs if desired, or null
X509Certificate[] trustedCAs = _;

// make the params (for the default security realm)
CertPathValidatorParams params =
new CertPathValidatorParams(realm, context, trustedCAs);

JDK CertPathValidatorインタフェースの使用

java.security.cert.CertPathValidatorインタフェースは、CertPathValidatorクラスのAPIです。JDKのCertPathValidatorインタフェースを使用するには、次を行います:

1. 静的なCertPathValidator.getInstanceメソッドを呼び出して、CLVフレームワークのCertPathValidatorを取得します。呼出しに渡すアルゴリズム名として「WLSCertPathValidator」を指定する必要があります。

2. CertPathValidatorオブジェクトが取得できたら、返されたCertPathValidatorで「validate」メソッドを呼び出します。このメソッドが取る引数はCertPathParametersだけです。この引数は、どのように検証を行うかを示します。
JDKのCertPathValidator.validate ()メソッドに、weblogic.security.pk.CertPathValidatorParametersのインスタンスをCertPathParametersオブジェクトとして渡す必要があります。「CertPathValidatorParametersのインスタンス化」を参照してください。

3. 以上の手順を正常に完了すると、CertPathValidatorResultインタフェースを実装するオブジェクトに結果が返されます。

4. 正常に完了しなかった場合は、CertPathValidator.validate()メソッドから例外がスローされます。パラメータがWebLogic CertPathValidatorParametersでない場合や、レルム名がサーバー起動時のデフォルト・レルムのレルム名と一致しない場合は、InvalidAlgorithmParameterExceptionがスローされます。
証明書パス内の証明書が順序付けされていない場合(目的の証明書が1番目でなければならない)や、証明書パスが有効でない場合は、CertPathValidatorのvalidateメソッドからCertPathValidatorExceptionがスローされます。

証明書チェーンの検証のコード・フロー例

例10-5 追加の検証の実行

import weblogic.security.pk.CertPathValidatorParams;
import weblogic.security.service.ContextHandler;
import java.security.cert.CertPath;
import java.security.cert.CertPathValidator;
import java.security.cert.X509Certificate;

// you already have an unvalidated X509 certificate chain
// and you want to get it validated
X509Certificate[] chain = ...

// convert the chain to a CertPath
CertPathFactory factory = CertPathFactory.getInstance("X509");
ArrayList list = new ArrayList(chain.length);
for (int i = 0; i < chain.length; i++) {
list.add(chain[i]);
}
CertPath certPath = factory.generateCertPath(list);

// get the WLS CertPathValidator
CertPathValidator validator =
CertPathValidator.getInstance("WLSCertPathValidator");

String realm = _;

// create and populate a context handler if desired, or null
ContextHandler context = _;

// pass in a list of trusted CAs if desired, or null
X509Certificate[] trustedCAs = _;

// make the params (for the default security realm)
CertPathValidatorParams params =
new CertPathValidatorParams(realm, context, trustedCAs);

// use it to validate the chain
validator.validate(certPath, params);

A 非推奨のセキュリティAPI

以下に挙げたWebLogicセキュリティ・パッケージに含まれるセキュリティ・インタフェース、クラス、および例外の中の一部またはすべては、WebLogic Serverのこの前のリリースから非推奨になりました。

- weblogic.security.service

- weblogic.security.SSL

各パッケージで非推奨になったインタフェース、クラスおよび例外については、Oracle WebLogic Server APIリファレンスを参照してください。

Copyright © 2007, 2012, Oracle and/or its affiliates. All rights reserved.