WebLogic Security の管理
PERMIT、DENY、ABSTAIN のいずれかです。複数の認可プロバイダの回答が一致しない場合にどうするかを決定するのが、裁決プロバイダの主な役割です。裁決プロバイダは、各認可プロバイダの回答に重みを割り当てることによって認可の衝突を解決し、最終決定を返します。
PERMIT および ABSTAIN 票をどのように処理するかが決まります。
PERMIT 票を投じなければ、裁決プロバイダは true を投じません。デフォルトでは、この属性は有効化されています。ABSTAIN 票は PERMIT 票としてカウントされます。[完全一致の許可が必要] 属性を無効にするには、対応するチェック ボックスをクリックします。
INFORMATIONWARNINGERRORSUCCESSFAILURE
DefaultAuditRecorder.log ファイルを作成する前に待機する分数を指定します。指定された時間が経過すると、監査ファイルが閉じられて新しい監査ファイルが作成されます。DefaultAuditRecorder.YYYYMMDDHHMM.log (例 : DefaultAuditRecorder.200405130110.log) という名前でバックアップ ファイルが作成されます。
WL_HOME\yourdomain\yourserver\DefaultAuditRecorder.log に保存されます。監査プロバイダはセキュリティ レルムごとにコンフィグレーションされますが、各サーバは監査データをサーバのディレクトリにある独自のログ ファイルに書き込みます。次の Java 起動オプションを使用すれば、コマンドラインで DefaultAuditRecorder.log の新しいディレクトリを指定することができます。
-Dweblogic.security.audit.auditLogDir=c:\foo
c:\foo\yourserver\DefaultAuditRecorder.log になります。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Admin ロールを持たなければ、WebLogic Server を起動して LDAP ディレクトリ内のユーザまたはグループを使用することができません。LDAP ディレクトリで、次のいずれかを行います。
Admin ロールに Administrators グループが含まれています。LDAP ディレクトリに Administrators グループを作成します。WebLogic Server を起動する LDAP ユーザがこのグループに含まれていることを確認します。 Administrators というデフォルト グループが存在します。WebLogic Server を起動するユーザを Administrators グループに追加し、[グループ ベース DN] 属性を定義して Administrators グループが見つかるようにします。
Administrators グループを作成しない場合 (LDAP ディレクトリが別の目的で Administrators グループを使用する場合など)、LDAP ディレクトリに新しいグループを作成 (または既存のグループを使用) して、WebLogic Server を起動するユーザをそのグループに追加します。次に、WebLogic Server Administration Console で、そのグループに Admin ロールを割り当てます。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TokenGroups 属性ルックアップ アルゴリズムを使用するかどうかを示す。
TokenGroups 属性には、ユーザの完全にフラットなグループ メンバシップが SID 値の配列として保持されている。この SID 値は Active Directory LDAP サーバにおいて特別な索引付けがされており、これによりルックアップの応答が高速になる。
TokenGroups 属性へのアクセスが必要になる (つまり、LDAP ディレクトリにアクセスするユーザには TokenGroups 属性の読み込み特権が必要になり、TokenGroups 属性はユーザ オブジェクトのスキーマになければならない)。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
user.dn.1, user.dn.2 のように指定できる。LDAP 認証プロバイダは、一致するユーザが見つかるまで各ルート以下を順番に検索する。
user.dn.n エントリのユーザ フィルタ (user.filter.n) を指定する必要がある。
|
|
|
[subtree] および [onelevel]。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[subtree] および [onelevel]。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
:」、「,」、「?」、および「/」を使用しないようにする。
|
directory.knowledge.com:1050 people.catalog.com 199.254.1.2
|
|
|
|
|
directory.knowledge.com:1050 people.catalog.com 199.254.1.2
directory.knowledge.com:1050 はダウン。
people.catalog.com はアクティブ。
199.254.1.2 はアクティブ。
|
|
|
|
|
|
|
directory.knowledge.com に接続しようとします。10 秒後、接続の試行はタイムアウトになり、WebLogic Server は [ホスト] 属性で指定された次のホスト (people.catalog.com) に接続しようとします。WebLogic Server は、この接続の LDAP サーバとして people.catalog.com を使用します。
|
|
|
|
|
directory.knowledge.com:1050 people.catalog.com 199.254.1.2
directory.knowledge.com:1050 はダウン。
people.catalog.com はアクティブ。
199.254.1.2 はアクティブ。
|
|
|
|
|
|
|
directory.knowledge.com に接続しようとします。1 秒後、接続の試行はタイムアウトになり、WebLogic Server は [ホスト] 属性で指定された次のホスト (people.catalog.com) と directory.knowledge.com に同時に接続しようとします。people.catalog.com への接続が成功した場合、WebLogic Server はこの接続の LDAP サーバとして people.catalog.com を使用します。WebLogic Server は、people.catalog.com との接続が成功した後に directory.knowledge.com への接続を取り消します。
tokenGroups 属性を使用して、Active Directory 認証プロバイダでグループ メンバシップのルックアップを行うようにコンフィグレーションする。tokenGroups 属性は、完全にフラット化されたユーザのグループ メンバシップを SID 値の配列として保持しています。この SID 値は Active Directory において特別な索引付けがされており、これによりルックアップの応答が高速になります。
tokenGroups 属性を使用するように Active Directory 認証プロバイダをコンフィグレーションするには、次の手順に従います。
tokenGroups 属性ルックアップ アルゴリズムを使用するかどうかを示します。デフォルトで、この属性は無効です。tokenGroups 属性へのアクセスが必要になります (つまり、LDAP ディレクトリにアクセスするユーザには tokenGroups 属性の読み込み特権が必要になり、tokenGroups 属性はユーザ オブジェクトのスキーマになければなりません)。
cn に設定します。
weblogic.security.acl.CertAuthenticator クラスの実装を使用できます。レルム アダプタ認証プロバイダには、X.509 トークンに基づく ID アサーションを提供する ID アサーション プロバイダが含まれています。WebLogic Server で CertAuthenticator を使用する方法については、「レルム アダプタ認証プロバイダ内の ID アサーション プロバイダのコンフィグレーション」を参照してください。
fileRealm.properties ファイルがあるかどうかをチェックします。fileRealm.properties ファイルが存在しない場合、WebLogic Server Administration Console はセキュリティ レルムにレルム アダプタ認証プロバイダを追加しません。
weblogic.security.SubjectUtils.isUserInGroup() メソッドを使用して、ユーザがグループに属するかどうかを調べます。レルム アダプタ認証プロバイダによって生成されるサブジェクトを使用する場合、ユーザが所属するすべてのグループを繰り返す方法はありません。
weblogic.security.acl.CertAuthenticator クラスの実装を使用することもできます。ID アサーション プロバイダでは X.509 トークンを使用して ID アサーションを実行します。
*) を使用して、すべてのクライアント プリンシパルを指定できます。この属性は、CSI v2 ID アサーションを使用する場合にのみ必須です。
CLIENT-CERT に設定した場合、WebLogic Server の Web アプリケーション コンテナは、リクエストのヘッダおよびクッキーの値に対して ID アサーションを実行します。ヘッダ名またはクッキー名が、コンフィグレーションされている ID アサーション プロバイダのアクティブなトークン タイプに一致していれば、値はプロバイダに渡されます。
<run-as> タグのあるサーブレットおよび EJB メソッドや、HTTPSession で ID アサーションが使用されるがキャッシュはされない他の場面 (XML ドキュメントの署名や暗号化など) のパフォーマンスが大幅に向上します。
-Dweblogic.security.identityAssertionTTL コマンドライン引数を使用してサブジェクトがキャッシュに存在できる最大秒数を設定します。このコマンドライン引数のデフォルトは 300 秒 (5 分) です。コマンドライン引数に指定できる値は次のとおりです。
CN=, ou=Acme, c=US
ou=people, cn=flintstone
uid=fred, CN=flintstone(username), usercert=cert
CN=fred, ou=Acme, c=US
ou=people, uid=fred
SN=flintstone(username), uid=fred,usercert=cert
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
$subj は、証明書の Subject 属性を示します。次に例を示します。CN=meyer.beasys.com, ou=CCE, o=BEASYS, L=SFO, C=US
|
|
|
|
|
CN=meyer.beasys.com, ou=fred, o=BEASYS, L=SFO, C=US でマッピングが ou=people, ou=$subj.ou の場合、WebLogic Server はユーザを特定するときに ou=people, ou=fred, o=BEASYS, c=US を DN として使用する。
|
|
|
uid 属性は、構文が次の場合、サブジェクト DN 属性に一致する。
LDAPATTRNAME=$subj.SUBJECDNATTRNAME
uid=$subj.DN
|
|
|
userCertificate] および [userCertificate;binary]。デフォルトは [userCertificate]。
ldapmodify -p 1155 -D Principal -w Password
dn: cn=support@bea.com, ou=Certs, dc=bea, dc=com
changetype: modify
add: UserCertificate
userCertificate;binary:: MIICxDCCAi2gAwIBAgIDIDANbgkqn...
userCertificate;binary が作成される。 この証明書にアクセスするには、[証明書の属性] を userCertificate;binary に定義すること。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
WL-Proxy-Client-<TOKEN> という形式の名前を持つヘッダ。<TOKEN> は、デフォルト セキュリティ レルムの ID アサーション プロバイダに対してコンフィグレーションされているアクティブなトークン タイプの 1 つ。
<TOKEN> という形式の名前を持つヘッダ。<TOKEN> は、デフォルト セキュリティ レルムの ID アサーション プロバイダに対してコンフィグレーションされているアクティブなトークン タイプの 1 つ。
<TOKEN> という形式の名前を持つクッキー。<TOKEN> は、デフォルト セキュリティ レルムの ID アサーション プロバイダに対してコンフィグレーションされているアクティブなトークン タイプの 1 つ。
FOO および BAR というトークンを持つようにコンフィグレーションされている場合 (次の例では、HTTP リクエストには ID アサーションに関連するものはアクティブなトークン タイプ以外、何も含まれていないものとする)、ID アサーションは次のように実行されます。
FOO ヘッダを持つリクエストが双方向 SSL 接続を使用して受信される場合、X.509 が ID アサーションに使用されます。FOO ヘッダを持ち、WL-Proxy-Client-BAR ヘッダを持つリクエストが受信される場合、BAR トークンが ID アサーションに使用されます。FOO ヘッダを持ち、BAR クッキーを持つリクエストが受信される場合、FOO トークンが ID アサーションに使用されます。
FOO ヘッダを持ち、BAR ヘッダを持つリクエストが受信される場合、FOO トークンまたは BAR トークンのいずれかが ID アサーションに使用されますが、どちらが使用されるかは指定されていません。FOO クッキーを持ち、BAR クッキーを持つリクエストが受信される場合、FOO トークンまたは BAR トークンのいずれかが ID アサーションに使用されますが、どちらが使用されるかは指定されていません。
weblogic.security.providers.authentication.UserNameMapper インタフェースの実装でなければなりません。このインタフェースは、必要に応じた方式に従って、トークンを WebLogic Server のユーザ名にマップします。デフォルトでは、WebLogic Server では weblogic.security.providers.authentication.UserNameMapper インタフェースのデフォルトの実装が提供されます。また、独自の実装を記述することもできます。
smith@bea.com) を WebLogic Server セキュリティ レルムのユーザ (smith) にマッピングするようにコンフィグレーションできます。
C、CN、E、L、O、および OU です。
weblogic.security.providers.authentication.UserNameMapper インタフェースの実装でなければなりません。
weblogic.security.providers.authentication.UserNameMapper インタフェースの実装のクラス名を入力します。
DeployableAuthorizationProvider セキュリティ サービス プロバイダ インタフェース (SSPI) を実装する必要があります。デフォルトで、この属性は有効になっています。ポリシー情報は、組み込み LDAP サーバに格納されます。
weblogic-ra.xml ファイル) からセキュリティ レルムに資格マップをインポートするかどうかを指定します。[資格マッピング デプロイメントを有効化] 属性をサポートするには、資格マッピング プロバイダは DeployableCredentialProvider SSPI を実装する必要があります。デフォルトでは、WebLogic 資格マッピング プロバイダではこの属性が有効になっています。資格マッピング情報は組み込み LDAP サーバに格納されます。
DeployableRoleProvider SSPI を実装する必要があります。デフォルトでは、この属性は有効になっています。ロール情報は組み込み LDAP サーバに格納されます。
WL_HOME\lib\mbeantypes ディレクトリに入れます。
Security_Provider_Type は、カスタム セキュリティ プロバイダの名前です。この名前は、MBean 定義ファイル (MDF) の MBeanType タグの DisplayName 属性から読み込まれます。
