| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.3) E59413-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.3) E59413-03 |
|
前 |
次 |
この章の情報はJava SEアプリケーションにのみ適用され、Java SEアプリケーションの開発者を対象読者としています。
Java EEアプリケーションについての同様の情報は、第24章「OPSSを使用するためのJava EEアプリケーションの構成」を参照してください。
この章の内容は次のとおりです。
Java SEアプリケーションでOPSSを使用するためには、開発者は次のことを理解する必要があります。
jps-manifest.jarファイルがクラスパスに存在している必要があります。
初期化の際に、アプリケーションはJpsStartup.start()をコールする必要があります。詳細は、「クラスJpsStartup」を参照してください。
次のシステム・プロパティを設定する必要があります。
oracle.security.jps.config。jps-config-jse.xmlファイルへのファイル・パス。
common.components.home。oracle commonディレクトリへのパス。
java.security.policy。java.policyファイルへのファイル・パス。
opss.audit.logDirectory。JSE用の監査レコードが書き込まれる、書込み可能なディレクトリへのパス
その他の設定可能な(オプションの)システム・プロパティの詳細は、第F.1項「OPSSシステム・プロパティ」を参照してください。
JVMオプション-Djava.security.policyは、Oracle WebLogic Serverポリシー・ファイルweblogic.policyの場所を指定します。通常、wl_home/server/libディレクトリに存在します。
次のサンプル・スニペットで示すように、アプリケーションはOPSSクラスAppSecurityContextを使用します。
|
注意: このサンプル・スニペットは、CSF/KSS機能のみを開発および使用する場合には必要ありません。 |
String appID = AppSecurityContext.getApplicationID();
try {
setApplicationID(appName);
.....
} finally {
setApplicationID(appID );
}
}
private static void setApplicationID(final String applicationID) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
AppSecurityContext.setApplicationID(applicationID);
return null;
}
});
}
AppSecurityContext.setApplicationIDコールには、次のようなコードソース・パーミッションが必要です。
<grant>
<grantee>
<codesource>
<url>myJavaSEapp/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>AppSecurityContext.setApplicationID.myAppStripeID</name>
</permission>
</permissions>
</grant>
OPSSセキュリティ・ストアを構成する方法の詳細は、第9章「OPSSセキュリティ・ストアの構成」を参照してください。
この項では、クラスJpsStartupに対するの次の拡張機能について説明します。
メソッドJpsStartup.start()のOPSS状態セット
メソッドJpsStartup.start()のランタイム・オプションの一部
クラスJpsStartupの新しいコンストラクタ
メソッドJpsStartup.getState()
このクラスに関する詳細は、『Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services』を参照してください。使用例については、「OPSS起動例」を参照してください。
この項の内容は次のとおりです。
JpsStartup.start()の遷移状態は、次の定数で定義されます。
UNINITIALIZED - JpsStartup.start()が呼び出される前のデフォルトの状態。
INITIALIZING - JpsStartup.start()が呼び出された後、この状態に遷移します。
FAILURE - INITIALIZINGの状態でなんらかの障害が発生した場合、この状態に遷移します。
ACTIVE - すべてのサービスが障害なく起動された場合、つまりINITIALIZING状態で何も障害が発生しなかった場合にはこの状態に遷移します。
INACTIVE - JpsStatup.stop()を呼び出すと、この状態に遷移します。
次の表は、クラス・コンストラクタjpsStartup()を呼び出すときに使用できるランタイム・オプションをまとめたものです。
表25-1 JpsStartupのランタイム・オプション
| オプション | 値 | デフォルト | 説明 |
|---|---|---|---|
|
ACTIVE_CONTEXT |
アクティブ・コンテキストの名前または文字列"default"。 |
"default" |
渡された場合は、指定されたコンテキストを使用。それ以外の場合は"default"コンテキストを使用。 |
|
ENABLE_JAVA_POLICY_PROVIDER |
TRUEまたはFALSE |
TRUE |
Java2ポリシー・プロバイダを使用する場合はTRUEに、それ以外の場合はFALSEに設定。 |
|
ENABLE_AUDIT_SERVICE_EXT |
TRUEまたはFALSE |
TRUE |
監査モニタリングと監査ローダーとともに監査サービスを起動する場合はTRUEに、それ以外の場合はFALSEに設定。 |
|
ENABLE_POLICY_STORE_SERVICE_EXT |
TRUEまたはFALSE |
TRUE |
ポリシー変更スキャナ・スレッドとともにポリシー配布ポイント(PDP)を起動する場合はTRUEに、それ以外の場合はFALSEに設定。 |
|
ENABLE_DEPLOYMENT_HANDLING |
TRUEまたはFALSE |
TRUE |
デプロイメント・ハンドラを作成する場合はTRUE、それ以外の場合はFALSEに設定します。 |
|
RUNTIME_MODE |
DEFAULTまたは SCRIPT |
DEFAULT |
ENABLE_JAVA_POLICY_PROVIDER、ENABLE_AUDIT_SERVICE_EXT、ENABLE_POLICY_STORE_SERVICE_EXT、ENABLE_DEPLOYMENT_HANDLINGオプションをFALSEに設定する場合はSCRIPTに設定。それ以外の場合はDEFAULTに設定。 |
|
JPS_CONFIG |
ファイルjps.config.xmlへのパス |
oracle.security.jps.configプロパティで指定されたパス |
渡された場合は、指定されたパスを使用。それ以外の場合は"default"パスを使用。 |
このクラスに次のコンストラクタが追加されました。
JpsStatup(java.lang.String platformType,
java.util.Map<java.lang.String,
ContextConfiguration> ctxtCfgs,
java.util.Map<java.lang.String,?> options)
引数ContextConfigurationは、構成ファイルjps-config-jse.xmlの<jpsContext>内のコンテキストに関する詳細を保持します。JpsStartupを呼び出す前にContextConfigurationを取得する方法については、「OPSS起動例」の例3と4を参照してください。
"default"コンテキストに加えて複数のコンテキストを起動するには、複数のコンテキスト情報を渡します。詳細は、「OPSS起動例」の例4を参照してください。"default"以外のコンテキストを起動するには、目的のコンテキスト名を渡します。何も渡さなかった場合はデフォルトのコンテキストが起動されます。
引数optionsには、OPSSの起動に使用される起動プロパティをすべて指定できます。利用可能なオプションの一覧については、表25-1を参照してください。
このコンストラクタは通常、ContextConfigurationの詳細を指定してOPSSを起動したときに呼び出されます。「OPSS起動例」の例3を参照してください。
このメソッドは、呼び出し時のOPSSの状態として、INITIALIZING、UNINITIALIZED、FAILURE、ACTIVEまたはINACTIVEのいずれかを返します。
次のコードは、一般的な起動シナリオでクラスJpsStartupを使用した例です。
例1
次のコードは、特にパラメータを指定せずにOPSSを起動する方法の例です。
JpsStartup jpsStartUp = new JpsStartup(); jpsStartUp.start(); jpsStartUp.getState(); jpsStartUp.stop();
例2
ここでは、次の構成でOPSSを起動する方法の例を示します。
default1は、contextConfigマップの一部として渡されるデフォルト・コンテキストです。
監査ローダーや監査モニタリングなどの監査ランタイム・サービスを無効化するには、パラメータ"ENABLE_AUDIT_SERVICE_EXT"を"FALSE"に設定して渡します。デフォルトではこのパラメータは有効化されていますので注意してください。
ポリシー変更スキャナ・スレッドなどのランタイム・サービスを無効化するには、パラメータ"ENABLE_POLICY_STORE_SERVICE_EXT"を"FALSE"に設定して渡します。デフォルトではこのパラメータは有効化されていますので注意してください。
ConfigurationServiceProvider prov = ConfigurationServiceProvider.newInstance();
ConfigurationService configService = prov.getConfigurationService();
ContextConfiguration configuration = configService.getContextConfiguration("default1");
Map<String, ContextConfiguration> contextConfig = new HashMap<String, ContextConfiguration>();
contextConfig.put(JpsConstants.DEFAULT_CONTEXT_KEY, configuration);
Map<String, Object> option = new HashMap<String, Object>();
option.put(JpsConstants.ENABLE_AUDIT_SERVICE_EXT, "FALSE");
option.put(JpsConstants.ENABLE_POLICY_STORE_SERVICE_EXT, "FALSE");
JpsStartup jpsStartUp = new JpsStartup("JSE", contextConfig, option);
jpsStartUp.start();
jpsStartUp.stop();
例3
ここでは、ContextConfigurationsの詳細を指定してOPSSを起動する方法の例を示します。
Map<String, Object> startupOption = new HashMap<String, Object>();
ConfigurationServiceProvider prov = ConfigurationServiceProvider.newInstance();
ConfigurationService configService = prov.getConfigurationService();
ContextConfiguration configuration = configService.getContextConfiguration("default1");
Map<String, ContextConfiguration> contextConfig = new HashMap<String, ContextConfiguration>();
contextConfig.put(JpsConstants.DEFAULT_CONTEXT_KEY, configuration);
JpsStartup jpsStartUp = new JpsStartup("JSE", contextConfig, startupOption);
jpsStartUp.start();
jpsStartUp.stop();
例4
次のコードは、複数のコンテキストを使用したOPSSの起動方法の例です。ここでは、jps.config.xmlファイルに次のコンテキストが含まれていると仮定しています。
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="credstore"/> ...
</jpsContext>
<jpsContext name="default1">
<serviceInstanceRef ref="idstore.loginmodule"/> ...
</jpsContext>
<jpsContext name="default2">
<serviceInstanceRef ref="keystore"/> ...
</jpsContext>
<jpsContext name="default3">
<serviceInstanceRef ref="policystore "/> ...
</jpsContext>
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.credstore"/>
</jpsContext>
</jpsContexts>
ConfigurationServiceProvider prov = ConfigurationServiceProvider.newInstance();
ConfigurationService configService = prov.getConfigurationService();
ContextConfiguration configuration1 = configService.getContextConfiguration("default1");
ContextConfiguration configuration2 = configService.getContextConfiguration("default2");
ContextConfiguration configuration3 = configService.getContextConfiguration("default3");
Map<String, ContextConfiguration> contextConfig = new HashMap<String, ContextConfiguration>();
contextConfig.put(JpsConstants.DEFAULT_CONTEXT_KEY, configuration);
contextConfig.put(("default1", configuration1);
contextConfig.put(("default2", configuration2);
contextConfig.put(("default3", configuration3);
Map<String, Object> startupOption = new HashMap<String, Object>();
startupOption.put(JpsConstants.ACTIVE_CONTEXT, "default");
JpsStartup jpsStartUp = new JpsStartup("JSE", contextConfig, startupOption);
jpsStartUp.start();
jpsStartUp.stop();
パラメータ"ACTIVE_CONTEXT"は、デフォルトとして使用するコンテキストを示します。マップの一部としてJpsConstants.DEFAULT_CONTEXT_KEYを渡さなかった場合、startupOptionマップの一部として"ACTIVE_CONTEXT"キーが渡されていなければ、デフォルトでは"default"コンテキストが起動されます。
例5
次のコードは、"SCRIPT"モードでOPSSを起動する方法の例です。このモードは通常、移行やアップグレードの間、ランタイム・サービスを起動する必要がない場合に使用されます。
Map<String, Object> startupOption = new HashMap<String, Object>();
startupOption.put(JpsConstants.RUNTIME_MODE, "SCRIPT");
JpsStartup jpsStartUp = new JpsStartup("JSE", startupOption);
jpsStartUp.start();
jpsStartUp.stop();
この項では、Java SEアプリケーションのOPSSサポートについて、サービスごとに説明します。
この項では、Java SEアプリケーションに対するアイデンティティ・ストアのサポートについて説明します。内容は次のとおりです。
認証とは、コール元が特定のユーザーまたはシステムの代理として機能していることを証明するメカニズムです。認証では、名前とパスワードの組合せなどのデータを使用して、相手がだれであるかという質問への回答が提供されます。アイデンティティ・ストアという用語はアイデンティティ・データの格納場所を表し、認証プロバイダはアイデンティティ・ストアにアクセスするための手段です。
アプリケーションによるOPSSセキュリティ・ストア(アイデンティティ・ストア、ポリシー・ストアまたは資格証明ストア)からの情報の取得と、そのコンテンツの管理には、OPSS APIが使用されます。次の図はこれを示したものです。
Java SEアプリケーションは、次のスニペットに示すように、<serviceProvider>、<serviceInstance>および<jpsContext>の各要素を含むファイルjps-config-jse.xmlに構成されたLDAPベースのアイデンティティ・ストアを使用できます。
<serviceProviders>
<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider" class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>Prototype LDAP-based ID store</description>
</serviceProvider>
</serviceProviders>
<serviceInstances>
<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
<property name="idstore.type" value="OID"/>
<property name="max.search.filter.length" value="500"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
</serviceInstance>
</serviceInstances>
<jpsContexts default="ldap_idstore">
<jpsContext name="ldap_idstore">
<serviceInstanceRef ref="idstore.ldap"/>
</jpsContext>
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
</jpsContexts>
次の点に注意してください:
<serviceInstance>の名前(この例では<idstore.ldap>)には任意の値を指定できますが、要素<serviceInstanceRef>で参照されるインスタンスと一致している必要があります。
<serviceProvider>の名前(この例では<idstore.ldap.provider>)には任意の値を指定できますが、要素<serviceInstance>内のプロバイダと一致している必要があります。
指定したスクリプトを使用してプロバイダ・インスタンスにプロパティを追加するには、付録E「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。
ログイン・モジュールは、ユーザーを認証し、サブジェクトにプリンシパルを移入するコンポーネントです。このプロセスは、2つの異なる段階で行われます。第一段階では、ログイン・モジュールによって要求元のユーザー(必要に応じて名前、パスワードまたはその他の資格証明データ)の認証が試みられます。第一段階が成功した場合にのみ、第二段階が呼び出されます。第二段階では、ログイン・モジュールによって、関連プリンシパルがサブジェクトに割り当てられ、最終的にそれが権限が付与されたアクションを実行するために使用されます。
サポートされる任意のログイン・モジュールで、次のプロパティを設定できます。
enable.anonymous (default: false) remove.anonymous.role (default: true) add.application.roles (default: true) add.authenticated.role (default: true)
サンプル構成は、「<serviceInstance>」を参照してください。
サポートされるログイン・モジュールは、次のとおりです。
|
注意1: ユーザー認証のログイン・モジュールとユーザー・アサーションのログイン・モジュールは、Java EEとSEの両方のアプリケーションで使用できます。 |
|
注意2: Java SEアプリケーションでは、ユーザー認証のログイン・モジュールとユーザー・アサーションのログイン・モジュールは、デフォルト・アイデンティティ・ストア・サービスがサポートしています。 |
Java SEアプリケーションではログイン・モジュールのスタックを使用してユーザーを認証でき、各モジュールではスタック内の他のモジュールとは無関係に独自の計算を実行できます。これらのサービスおよびその他のサービスは、ファイルjps-config-jse.xmlで指定されます。
OPSS APIには、インタフェースoracle.security.jps.service.login.LoginServiceが組み込まれており、これによってJava SEアプリケーションはスタック内のすべてのログイン・モジュールを呼び出せるのみでなく、それらのサブセットを指定の順序で呼び出すことができます。
LoginServiceインタフェースのメソッドLoginContextに渡されるjpsコンテキスト(構成ファイルjps-config-jse.xmlに定義されたもの)の名前によって、アプリケーションが使用するログイン・モジュールのスタックが判別されます。標準のJAAS API LoginContextを使用して、デフォルトのコンテキストで定義されたログイン・モジュールを呼び出すこともできます。
JPSコンテキストによってスタックにログイン・モジュールがリストされる順序は重要です。それは、認証アルゴリズムでは、モジュールのセキュリティ・レベルを特定するフラグ(required、sufficient、requisite、optional)などのデータに加えてこの順序が考慮されるためです。
すぐに使用できるアイデンティティ・ストア・サービスはファイルベースであり、そのコンテンツはファイルsystem-jazn-data.xmlでプロビジョニングされています。そのサービスを再構成して、LDAPベースのアイデンティティ・ストアを使用することも可能です。
OPSSでは、Java SEアプリケーションのアイデンティティ・ストア・ログイン・モジュールがサポートされており、次の項の説明に従って、認証またはアイデンティティ・アサーションに使用できます。
アイデンティティ・ストアのログイン・モジュール
このログイン・モジュールに関連付けられているクラスは、次のとおりです。
oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule
このモジュールのインスタンスは、次のフラグメントに示すように、ファイルjps-config-jse.xmlに構成されます。
<serviceInstance name="idstore.loginmodule" provider="jaas.login.provider"> <description>Identity Store Login Module</description> <property name="loginModuleClassName" value="oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule"/> <property name="jaas.login.controlFlag" value="REQUIRED"/> </serviceInstance>
このログイン・モジュールに固有のプロパティは、次のとおりです。
remove.anonymous.role (defaults to true) add.application.role (defaults to true)
この項では、基本的なユーザー名とパスワードの認証のためのアイデンティティ・ストア・ログイン・モジュールの使用方法を示します。
IdStoreLoginModuleの起動
次のフラグメントは、コールバック・ハンドラとコンテキストの設定方法を示しています。
import javax.security.auth.Subject; import javax.security.auth.login.LoginContext; Subject sub = new Subject(); CallbackHandler cbh = new YourCallbackHandler(); LoginContext context = new LoginContext(appName, subject, cbh); context.login();
コールバック・ハンドラでは、NameCallbackとPasswordCallbackを処理できる必要があります。
jps-config-jse.xmlの構成
次のjps-config-jse.xmlの断片は、コンテキストappNameの構成を示しています。
<jpsContext name="appName">
<serviceInstanceRef ref="jaaslm.idstore1"/>
</jpsContext>
<serviceProvider type="JAAS_LM" name="jaaslm.idstore"
class="oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule">
<description>Identity Store-based LoginModule
</description>
</serviceProvider>
<serviceInstance name="jaaslm.idstore1" provider="jaaslm.idstore">
<property name="jaas.login.controlFlag" value="REQUIRED"/>
<property name="debug" value="true"/>
<property name="addAllRoles" value="true"/>
</serviceInstance>
コールバック・ハンドラの書込み
次のコード・スニペットは、コールバック・ハンドラで名前とパスワードのコールバックを処理できることを示しています。
import javax.security.auth.callback.*;
import java.io.IOException;
public class SampleCallbackHandler implements CallbackHandler {
//For name/password callbacks
private String name = null;private char[] password = null;
public SampleCallbackHandler(String name, char[] pwd) {
if (name == null || name.length() == 0 )
throw new IllegalArgumentException("Invalid name ");
else
this.name = name;
if (pwd == null || pwd.length == 0)
throw new IllegalArgumentException("Invalid password ");
else
this.password = pwd;
}
public String getName() {
return name;
} public char[] getPassword() {
return password;
}
public void handle(Callback[] callbacks)
throws IOException, UnsupportedCallbackException {
if (callbacks != null && callbacks.length > 0) {
for (Callback c : callbacks) {
if (c instanceof NameCallback) {
((NameCallback) c).setName(name);
}
else
if (c instanceof PasswordCallback) {
((PasswordCallback) c).setPassword(password);
}
else {
throw new UnsupportedCallbackException(c);
}
}
}
}
}
アイデンティティ・ストアのログイン・モジュールをアサーションのために使用するには、開発者は次の処理を行う必要があります。
コール元が保護されたメソッドsetIdentityを実行するための適切なパーミッションを提供します。これには、IdentityAssertionという名前を持つパーミッションoracle.security.jps.JpsPermissionを付与することが必要になります。
次のコード・サンプルに示すようなクラスoracle.security.jps.callback.IdentityCallbackを使用するコールバック・ハンドラを実装します。
この2つの要件を次の構成およびコード・サンプルに示します。
JpsPermissionのプロビジョニング
次の構成サンプルでは、必須JpsPermissionがアサーション・ログイン・モジュールの保護されたメソッドを実行できるようにコードMyAppに権限を与えています。
<grant>
<grantee>
<codesource>
<url>file:${soa.oracle.home}/application/myApp.ear</url>
<--! soa.oracle.home is a system property set when
the server JVM is started -->
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
</permission>
</permissions>
</grant>
次の構成サンプルでは、必須JpsPermissionがアサーション・ログイン・モジュールを実行できるようにプリンシパルjdoeに権限を与えています。
<grant>
<grantee>
<principals>
<principal>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>jdoe</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
</permission>
</permissions>
</grant>
CallbackHandlerの実装
次のコード部分は、コールバック・ハンドラの実装を示しています。
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
import oracle.security.jps.callback.IdentityCallback;
public class CustomCallbackHandler implements CallbackHandler {
private String name = null;
private char[] password;
public CustomCallbackHandler(String name) {
this.name = name;
}
public CustomCallbackHandler(String name, char[] password) {
this.name = name;
this.password = password;
}
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
for (Callback callback : callbacks) {
if (callback instanceof NameCallback) {
NameCallback nc = (NameCallback) callback;
nc.setName(name);
}
else if (callback instanceof PasswordCallback) {
PasswordCallback pc = (PasswordCallback) callback;
pc.setPassword(password);
}
else if (callback instanceof IdentityCallback) {
IdentityCallback idcb = (IdentityCallback)callback;
idcb.setIdentity(name);
idcb.setIdentityAsserted(true);
idcb.setAuthenticationType("CUSTOM");
} else {
//throw exception
throw new UnsupportedCallbackException(callback);
}
}
}
}
次のコード部分は、ログイン・モジュールの実装を示しています。
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.LoginContext;
import oracle.security.jps.service.JpsServiceLocator;
import oracle.security.jps.service.login.LoginService;
public class LoginModuleExample {
private static final String CONTEXT_NAME = "JSE_UserAuthnAssertion";
public LoginModuleExample() {
super();
}
public Subject assertUser(final String username) throws Exception {
CallbackHandler cbh =
AccessController.doPrivileged(new PrivilegedExceptionAction<CallbackHandler>() {
public CallbackHandler run() throws Exception {
return new CustomCallbackHandler(username);
}
});
Subject sub = new Subject();
LoginService ls =
JpsServiceLocator.getServiceLocator().lookup(LoginService.class);
LoginContext context = ls.getLoginContext(sub, cbh);
context.login();
Subject s = context.getSubject();
return s;
}
public Subject authenticate(final String username, final char[] password) throws Exception {
CallbackHandler cbh = new CustomCallbackHandler(username, password);
Subject sub = new Subject();
LoginService ls =
JpsServiceLocator.getServiceLocator().lookup(LoginService.class);
LoginContext context = ls.getLoginContext(sub, cbh);
context.login();
Subject s = context.getSubject();
return s;
}
public static void main(String[] args) {
LoginModuleExample loginModuleExample = new LoginModuleExample();
try {
System.out.println("authenticated user subject = " +
loginModuleExample.authenticate("testUser",
"welcome1".toCharArray()));
System.out.println("asserted user subject = " +
loginModuleExample.assertUser("testUser"));
} catch (Exception e) {
e.printStackTrace();
}
}
}
ユーザー認証のログイン・モジュールは、ユーザー名とパスワードからユーザーを認証するために、Java EEアプリケーションとJava SEアプリケーションの両方で使用できます。このログイン・モジュールは、出荷時に構成されています。このログイン・モジュールは、ドメイン・アイデンティティ・ストアに対して認証を行います。
次のコードは、このモジュールを使用したプログラム認証を示しています。
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
public class MyCallbackHandler extends CallbackHandler {
private String name = null;
private char[] password = null;
public MyCallbackHandler(String name, char[] password) {
this.name = name;
this.password = password;
}
public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
for (Callback callback : callbacks) {
if (callback instanceof NameCallback) {
NameCallback ncb = (NameCallback) callback;
ncb.setName(name);
}
else if (callback instanceof PasswordCallback) {
PasswordCallback pcb = (PasswordCallback) callback;
pcb.setPassword(password);
}
else {
throw UnsupportedCallbackException(callback);
}
}
}
}
JpsLoginModuleFactory factory = JpsLoginModuleFactory.getLoginModuleFactory();
CallbackHandler cbh = new MyCallbackHandler("name", "password".toCharArray());
LoginContext ctx = factory.getLoginContext(JpsLoginModuleType.USER_AUTHENTICATION, null, cbh);
ctx.login();
Subject s = ctx.getSubject();
ユーザー・アサーションのログイン・モジュールは、ユーザー・アイデンティティをアサートするために、Java EEアプリケーションとJava SEアプリケーションの両方で使用できます。このログイン・モジュールは、ドメイン・アイデンティティ・ストアに対してアサートを行い、コールバックoracle.security.jps.callback.IdentityCallbackの実装を必要とします。さらに、このログイン・モジュールの実行では、oracle.security.jps.JpsPermissionにIdentityAssertionパーミッション(アクションとして実行)が要求されます。
ユーザー・アサーションのログイン・モジュールをプログラムのアサーションのために使用するには、開発者は次の処理を行う必要があります。
コール元がログイン・モジュールで保護されたメソッドを実行するための適切なパーミッションを提供します。これには、IdentityAssertion (およびアクション実行)という名前を持つパーミッションoracle.security.jps.JpsPermissionを付与することが必要になります。
クラスoracle.security.jps.callback.IdentityCallbackを使用するコールバック・ハンドラを実装します。プログラムのアサーション・コードを実行します。
これらの要件を次の構成およびコード・サンプルに示します。
次の構成サンプルでは、必須JpsPermissionがユーザー・アサーション・ログイン・モジュールを実行できるようにプリンシパルjdoeに権限を与えています。
<grant>
<grantee>
<principals>
<principal>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>jdoe</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
<action>execute</action>
</permission>
</permissions>
</grant>
コードソースの例は、第24.6.6項「サポートされているパーミッション・クラスの使用」の付与サンプルを参照してください。
次のコード部分は、コールバック・ハンドラの実装を示しています。
import oracle.security.jps.callback.IdentityCallback;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
import java.io.IOException;
public class AssertCallbackHandler implements CallbackHandler {
private String name = null;
public AssertCallbackHandler(String name) {
this.name = name;
}
public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
for (Callback callback : callbacks) {
if (callback instanceof IdentityCallback) {
IdentityCallback nc = (IdentityCallback) callback;
nc.setIdentity(name);
}
else {
throw new UnsupportedCallbackException(callback);
}
}
}
}
次のコード部分は、ユーザーのアサート方法を示しています。
import oracle.security.jps.callback.IdentityCallback;
import oracle.security.jps.internal.api.jaas.module.JpsLoginModuleFactory;
import oracle.security.jps.internal.api.jaas.module.JpsLoginModuleType;
import javax.security.auth.Subject;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
import javax.security.auth.login.LoginContext;
import java.io.IOException;
import java.security.AccessController;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
Subject subject = AccessController.doPrivileged(new PrivilegedExceptionAction<Subject>() {
public Subject run() throws Exception {
JpsLoginModuleFactory f = JpsLoginModuleFactory.getLoginModuleFactory();
CallbackHandler cbh = new AssertCallbackHandler(name);
LoginContext c = f.getLoginContext(JpsLoginModuleType.USER_ASSERTION, null, cbh);
c.login();
return c.getSubject();
}
});
多くの場合、アプリケーションは、ユーザーが操作を実行したようにアクションを実行する、つまり、実行操作を起動する必要があります。OPSSでは、アサートされたユーザーのサブジェクトを使用して、ユーザーが実行したようなアプリケーション・ロジックの実行をJava EEアプリケーションおよびJava SEアプリケーションに許可することにより、この問題を解決します。この機能は、OPSSクラスSubjectSecurityでカプセル化され、Oracle WebLogicプラットフォームでサポートされています。
この項では、次の項目について説明します。
プログラミング課題の解決にSubjectSecurityクラスを使用できる例をいくつか次に示します。
UC1 - スケジューラはジョブの送信と実行を可能にします。通常これらのジョブは一度に送信され何回かに分けて実行されるため、ユーザーのアイデンティティをアサートし、ユーザーのセキュリティ・コンテキストでスケジュールされたジョブを実行する必要があります。
UC2 - スケジュールされたジョブはエンティティBeanにより実行され、さらに、ジョブを完了するためにその他のエンティティBeanをコールする場合があります。ジョブを完了するためのすべてのコードは、ユーザーのセキュリティ・コンテキストで実行する必要があるため、このコンテキストはパスをコールことにより、エンティティBean間で伝播される必要があります。
UC3 - スケジュールされたジョブを実行するパーミッションは、ユーザーのアプリケーション・ロールに基づいています。この場合は、エンティティBean間のコード・パスにかかわらず、ユーザーのセキュリティ・コンテキストはユーザーに付与されたアプリケーション・ロールを認識する必要があります。
UC4 - 認証されていないユーザーがジョブを送信する場合は、ジョブ・メタデータは匿名ユーザーを保持する必要があります。その結果、ジョブは匿名ユーザーにより実行される必要があります。
UC5 - アプリケーションで実行するMBeanは、MBeanサーバー経由でUIから起動されます。MBean操作は、特定のユーザーとして実行する必要のある一連の診断テストを起動します。
UC6 - ユーザー・アイデンティティはユーザー・アサーションAPIによりアサートされており、該当のユーザーとして操作を実行するために使用できるユーザーのセキュリティ・コンテキストを作成します。
SubjectSecurity APIにより、事前計算されたサブジェクトが使用可能な場合(ユースケースUC6と同じ)、またはユーザーが最初にアサートされる必要がある場合は、ユーザーはコードを実行できます。アプリケーションのセキュリティ・コンテキストが設定されていない場合は、SubjectSecurity APIを使用する前に、アプリケーションはアプリケーションのIDを次のように設定する必要があります。
AppSecurityContext.setApplicationID(applicationID)
たとえば、ユースケースUC1、UC2、UC3、およびUC5と同様のシステムMbeanの場合は、アプリケーションIDをsetApplicationIDに設定する必要があります。アプリケーションのセキュリティ・コンテキストが設定されている場合は、setApplicationIDに対するコールはオプションです。
SubjectSecurityクラスを使用する場合の一般的な推奨事項を次に示します。
サブジェクトをすでに取得しており、サブジェクトを使用して操作を実行する場合は、SubjectSecurity.getActionExecutor(subject)を使用します。サブジェクトの取得方法によって、次のケースがあります。
コンテナ認証が実行され、SubjectUtil.getCurrentSubject()を使用してサブジェクトが取得された場合は、サブジェクトはコンテナ・セキュリティおよびOPSSセキュリティとともに動作し、アプリケーション・ロールが検討されます。
JpsLoginModuleFactoryを使用し、プログラム認証を介してサブジェクトが取得された場合は、サブジェクトはコンテナ・セキュリティおよびOPSSセキュリティとともに動作します。
ユーザー名のみが使用可能で、そのユーザーとして操作を実行する場合は、SubjectSecurity.getActionExecutor(userName)を使用します。このメソッドでは、アイデンティティ・アサーションを含む権限の操作を実行します。必要なパーミッションを得るためのコードのコールを要求してこれらの操作を起動します。このため、このメソッドを使用するアプリケーションでは、次のようなコードベースのパーミッションが必要です。
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/myApp.ear/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
<actions>execute</actions>
</permission>
</permissions>
</grant>
<url>は、メソッドをコールするコードの場所を指定します。
ActionExecutor.execute(PrivilegedAction)は、ユーザーのJAASサブジェクトおよびアプリケーションのPrivilegedActionを使用してSubject.doAs()を呼び出します。
SubjectSecurity.executeAs(Subject subject, PrivilegedAction<T> action)を使用して、アクションを即時に実行します。
SubjectSecurity.executeAs(Subject subject, PrivilegedExceptionAction<T> action)を使用して、アクションを即時に実行します。このメソッドは、getActionExecutor(subject)を使用してアクション・エグゼキュータを取得し、アクションを実行します。
クラスoracle.security.jps.runtime.SubjectSecurityおよびインタフェースoracle.security.jps.runtime.ActionExecutorの詳細は、Oracle Fusion Middleware Oracle Platform Security Services Java APIリファレンスを参照してください。
次のサンプル・コードは、SubjectSecurity APIを使用し、jdoeという名前のアサートされたユーザーとして実行することを示しています。
// get a SubjectSecurity instance
final SubjectSecurity subjectSecurity = SubjectSecurity.getInstance();
String username = "jdoe";
// create ActionExecutor with subjectSecurity getActionExecutor(String username)
ActionExecutor executor =
AccessController.doPrivileged(new PrivilegedExceptionAction<ActionExecutor>() {
public ActionExecutor run() throws AssertionException {
return subjectSecurity.getActionExecutor(username);
}
}, null);
// When OPSS subjects are available,
// create ActionExecutor with SubjectSecurity getActionExecutor(Subject subject)
Subject opssSubject = SubjectUtil.getCurrentSubject();
ActionExecutor ececutor = subjectSecurity.getActionExecutor(opssSubject);
//run privilegedAction
PrivilegedAction action = new MyPrivilegedAction();
executor.execute(action);
//run PrivilegedExceptionAction
PrivilegedExceptionAction exceptionAction = new MyPrivilegedExceptionAction();
try {
executor.execute(exceptionAction);
} catch (PrivilegedActionException e) {
// handle PrivilegedActionException
}
Java SEアプリケーションでログイン・モジュールをプログラムによって呼び出すには、インタフェースoracle.security.jps.service.login.LoginServiceのメソッドgetLoginContextを使用します。
標準JAAS APIのメソッドLoginContextと同様に、getLoginContextは、ユーザーを認証するために使用できるLoginContextオブジェクトのインスタンスを返しますが、これによって、任意の順序で任意の数のログイン・モジュールを使用することもできます。これらのログオン・モジュールのみに対して、それらが渡された順序で認証が実行されます。
次のフラグメントは、ログイン・モジュールのサブセットに対するユーザー認証が、指定された順序で、getLoginContextを使用して実行されることを示しています。
import oracle.security.jps.service.ServiceLocator;
import oracle.security.jps.service.JpsServiceLocator;
import oracle.security.jps.service.login.LoginService;
//Obtain the login service
ServiceLocator locator = JpsServiceLocator.getServiceLocator();
LoginService loginService = locator.lookup(LoginService.class);
//Create the handler for given name and password
CallbackHandler cbh = new MyCallbackHandler("name", "password".toCharArray());
//Invoke login modules selectively in a given order
selectiveModules = new String[]{"lmName1", "lmName2", "lmName3"};
LoginContext ctx = loginService.getLoginContext(new Subject(), cbh, selectiveModules);
ctx.login();
Subject s = ctx.getSubject();
selectiveModulesは、(ログイン・モジュールの)名前の配列であり、認証では、その配列内で名前を指定されたログイン・モジュールが配列内にリストされた順序で使用されます。配列内のそれぞれの名前は、ファイルjps-config-jse.xmlのデフォルトのコンテキストにリストされたサービス・インスタンスの名前にする必要があります。
次のフラグメントは、2つのログイン・モジュールからなるスタックの構成を示しています。
<serviceProvider type="LOGIN" name="jaas.login.provider" class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider">
<description>Common definition for any login module instances</description>
</serviceProvider>
<serviceInstance name="auth.loginmodule" provider="jaas.login.provider">
<description>User Authentication Login Module</description>
<property name="loginModuleClassName" value="oracle.security.jps.internal.jaas.module.authentication.JpsUserAuthenticationLoginModule"/>
<property name="jaas.login.controlFlag" value="REQUIRED"/>
</serviceInstance>
<serviceInstance name="custom.loginmodule" provider="jaas.login.provider">
<description>My Custom Login Module</description>
<property name="loginModuleClassName" value="my.custom.MyLoginModuleClass"/>
<property name="jaas.login.controlFlag" value="REQUIRED"/>
</serviceInstance>
<jpsContexts default="aJpsContext">
<jpsContext name="aJpsContext">
<serviceInstanceRef ref="auth.loginmodule"/>
<serviceInstanceRef ref="custom.loginmodule"/>
</jpsContext>
</jpsContexts>
この項では、Java SEアプリケーションを使用してイベントを監査するために共通監査フレームワーク(CAF)を活用し始めるのに必要な予備知識を提供します。Java SEクライアントのために基本要件を説明し、共通監査使用シナリオをいくつか説明します。この項の内容は、次のとおりです。
この項では、役に立つ監査の概念について説明します。
監査構成プロパティ
第25.1項で説明しているように、監査構成はjps-config-jse.xmlファイルに格納されます。
次に示すのはそのファイルの記述例で、監査プロパティを示しています。
<serviceInstance provider="audit.provider" name="audit"> <property value="Medium" name="audit.filterPreset"/> <property value="0" name="audit.maxDirSize"/> <property value="104857600" name="audit.maxFileSize"/> <property value="" name="audit.specialUsers"/> <property value="" name="audit.customEvents"/> <property value="Db" name="audit.loader.repositoryType"/> <property value="file" name="auditstore.type"/> </serviceInstance>
監査サービスおよびプロセス
監査ランタイム・サービスにより、アプリケーションは、(監査ストアに格納されている)監査メタデータで指定される条件によって規定される様々なイベントを監査し、各イベントをバスストップ・ファイル内に記録します。
その他注目すべきプロセスには、バスストップ・ファイルからデータベースにデータを移動する監査ローダーが含まれます。
バスストップ・ファイル
これらのファイルは、新たに生成された監査レコードを保持するよう明示的に設計されています。監査ログと間違われて参照されることもありますが、システム・ログ・ファイルとは混同しないでください。
次の項では、JavaSE環境の要件および推奨事項を含む監査操作の側面をさらに詳細に説明します。
|
注意: 11gリリース1 (11.1.1.9)以降、バスストップ・ファイルの名前の形式は次のように変わりました。$hostname_$processId_audit_$majorVersion_$minorVersion.log 例: example.myhost.com_12345_audit_1_0.log |
Java SEクライアントは、監査バスストップ・ファイルを書き込むための書込み可能なディレクトリを指定する必要があります。このディレクトリを構成する手順は次のとおりです。
setAuditRepository() WLSTコマンドを使用して、監査サービス・プロパティ(ファイルjps-config-jse.xml内の"audit.logDirectory")として設定します。例:
setAuditRepository(logDirectory="/Audit")
または
システム・プロパティ"opss.audit.logDirectory"または"oracle.instance"をJVMに渡します。
|
警告: 実行時プロセスが書込み可能なディレクトリを特定できない場合、監査サービスは停止する可能性があります。 |
このディレクトリは、次の場合にはJavaSEクライアント・プロセスと共有することができます。
jps-config-jse.xmlファイルでaudit.logDirectoryサービス・プロパティを使用してディレクトリを設定し、環境内のすべてのJava SEクライアント/プロセスが同じjps-config-jse.xmlを使用する場合
または
バスストップ・ディレクトリの同じ値がシステム・プロパティとしてすべてのJava SEクライアントに渡される場合。
監査データ・ローダーは、バスストップ・ファイルからデータベースへデータをプッシュするスレッド/プロセスです。
|
注意: audit.loader.repositoryTypeプロパティを'Db'に設定することは、JavaEEおよびJavaSEの両環境における監査ローダーのデフォルト要件です。 |
JavaSEアプリケーションには2種類のローダーがあります。
1つ目はJavaSE監査サービス・ローダーです。これはランタイムOPSS監査サービスによって開始されたスレッドです。
デフォルトでは、この監査ローダーは無効になっています。有効にするには、JVMに"audit.loader.enable=true"を渡します。
2つ目のローダーはスタンドアロンJavaSEアプリケーションです。これはこの環境に、特に第25.4.2項で示している共有ディレクトリを使用している場合に推奨されるローダーです。
スタンドアロン・ローダーを開始する詳細は、第14.2.4.2項および第25.4.4.1項の最後の手順を参照してください。
この項では、Java SEで監査を実装する一般的なシナリオをいくつか説明します。
同じ環境にOracle WebLogic Serverが配置されている環境と配置されていない環境の両方を考慮します。
ドメインを設定後、管理者として次の手順を実行します。
setAuditRepository() WLSTコマンドを実行して、またはFusion Middleware Controlを使用して監査ローダー構成を設定します。
|
注意: setAuditRepositoryはオンライン・コマンドです。 |
この手順では、jps-config.xmlファイルおよびjps-config-jse.xmlファイル内の適切なプロパティも更新し、Java SEおよびJava EEシナリオの両方を有効化します。WLSTスクリプトは、次の例と類似しています。
# logDirectory is the location of the audit log directory # jdbcSring is the connect string # user and pass refer to the IAU append schema user and password
# (These get stored in bootstrap credential store) setAuditRepository(switchToDB = "true",dataSourceName = "jdbc/AuditDB",interval = "20", timezone="utc", logDirectory="/foo/bar", jdbcString="jdbc:oracle:thin:@host:1521:sid", dbUser="test_iau_append", dbPassword="password");
|
注意: JavaSEプロセスの書込み可能な監査ディレクトリがOracle WebLogic Server のログ・ディレクトリと同じディレクトリ(DOMAIN_HOME/servers/AdminServer/logsなど)に設定されている場合、スタンドアロン監査ローダーは必要ありません。コンテナの監査ローダー・プロセスがこのタスクを行います。 |
JavaSEプロセス間で別々の書込み可能な監査ディレクトリを選択した場合、スタンドアロン監査ローダーを開始してこれらのレコードをデータベースにプッシュします。システム・プロパティの1つを渡し、バスストップ・ディレクトリの値に設定します。次の例では、oracle.instanceが使用されています。
$JAVA_HOME/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_11.1.1/jps-manifest.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1./fmw_audit.jar
-Doracle.instance=$ORACLE_INST
-Doracle.security.jps.config=path_to_jps-config-jse.xml
oracle.security.audit.ajl.loader.StandaloneAuditLoader
ここでは、ミドルウェア・ホームが有効で、Oracle WebLogic Serverが実行されていないことを想定しています。そのため、Fusion Middleware ControlまたはsetAuditRepository()などのオンラインWLSTコマンドは使用できません。
手順は次のとおりです。
デフォルトでは、書込み可能ディレクトリがJVMに指定されている場合、監査ランタイムがJavaSEで有効化されます。
audit.logDirectoryサービス・プロパティはデフォルトではjps-config-jse.xmlファイルで有効ではないため、バスストップ・ディレクトリを指定するためにopss.audit.logDirectoryまたはoracle.instanceのシステム・プロパティを設定することをお薦めします。
管理者として、次にaddBootStrapCredential( ) WLSTコマンドを使用して、jps-config-jse.xmlファイルに定義されているようにブートストラップ資格証明をブートストラップ資格証明ストアに追加します。
addBootStrapCredential(jpsConfigFile='../../../user_projects/domains/base_domain/config/fmwconfig/jps-config-jse.xml', map='AuditDbPrincipalMap', key='AuditDbPrincipalMap', username='TEST_IAU_APPEND', password='password')
JavaSEプロセスが共有監査ディレクトリを使用する場合、スタンドアロン監査ローダーを開始してこれらのレコードをデータベースにプッシュします。
最後に、関連する監査ローダーが操作可能であることを確認します。2つのシナリオがあります:
監査ディレクトリは共有されていない(つまり、すべてのJavaSEプロセスはそれ自体の監査ディレクトリに書き込みます)。
この場合、audit.loader.enable=trueを指定することで単純にランタイム・サービスの監査ローダーを有効にします。
監査ディレクトリは共有されている(つまり、複数のJavaSEプロセスが同じ監査ディレクトリに書き込みます)。
この場合、第25.4.4.1項で示しているようにスタンドアロン監査ローダーを開始します。
|
注意: スタンドアロン監査ローダーはディレクトリが共有されていないときにも使用できます。 |
この項では、次のアーティファクトの構成を示します。
XMLのポリシー・ストアおよび資格証明ストア
XMLおよびLDAPのアイデンティティ・ストア
ログイン・モジュールのプリンシパル
XMLのポリシー・ストアおよび資格証明ストアの構成
次のスニペットは、XMLベースのポリシー・ストアおよび資格証明ストアの構成を示しています。XMLベースのポリシー・ストアのコンテンツは、ファイルsystem-jazn-data.xmlに指定されています。XMLベースの資格証明ストアのコンテンツは、ファイルcwallet.ssoに指定されています。
<serviceProviders> <serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE"> <description>XML-based PolicyStore Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE"> <description>SecretStore-based CSF Provider</description> </serviceProvider> </serviceProviders> <serviceInstances> <serviceInstance location="./" provider="credstoressp" name="credstore"> <description>File-based Credential Store Service Instance</description> </serviceInstance> <serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml"> <description>File-based Policy Store Service Instance</description> </serviceInstance> </serviceInstances>
XMLのアイデンティティ・ストアの構成
次のスニペットは、XMLベースのアイデンティティ・ストアの構成を示しています。XMLベースのアイデンティティ・ストアのコンテンツは、ファイルsystem-jazn-data.xmlに指定されています。
<serviceProvider class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" name="idstore.xml.provider" type="IDENTITY_STORE"> <description>XML-based Identity Store Service Provider</description> </serviceProvider> <serviceInstance location="./system-jazn-data.xml" provider="idstore.xml.provider" name="idstore.xml"> <description>File Based Identity Store Service Instance</description> <property value="jazn.com" name="subscriber.name"/> </serviceInstance>
LDAPのアイデンティティ・ストアの構成
次のスニペットは、LDAPベースのアイデンティティ・ストアの構成を示しています。このアイデンティティ・ストアには、LDAPサーバーにアクセスするためのブートストラップ資格証明の必須構成が含まれています。サービス・インスタンス・プロパティidstore.typeでは、使用するLDAPに応じて、次の値を設定できます。
表25-2 Idstoreのタイプ
| サポートされているLDAP | Idstore.typeの値 |
|---|---|
|
Oracle Internet Directory 10gおよび11g |
OID |
|
Oracle Virtual Directory 10gおよび11g |
OVD |
|
Sun Java System Directory Server 6.3 |
IPLANET |
|
Active Directory 2003、2008 |
ACTIVE_DIRECTORY |
|
Novell eDirectory 8.8 |
EDIRECTORY |
|
Oracle Directory Server Enterprise Edition 11gR1 (11.1.1.3+) |
IPLANET |
|
IBM Tivoli DS 6.2 |
OPEN_LDAP |
|
OpenLDAP 2.2。 |
OPEN_LDAP |
<serviceProvider
class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider"
name="idstore.ldap.provider" type="IDENTITY_STORE">
<description>LDAP-based Identity Store Service Provider</description>
</serviceProvider>
<serviceProvider
class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider"
name="credstoressp" type="CREDENTIAL_STORE">
<description>SecretStore-based CSF Provider</description>
</serviceProvider>
<serviceInstance name="idstore.oid" provider="idstore.ldap.provider">
<property name="subscriber.name" value="dc=us,dc=oracle,dc=com"/>
<property name="idstore.type" value="OID"/>
<property value=ldap://myOID.com:3555 name="ldap.url"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<property name="username.attr" value="uid"/>
<propperty name="group.attr" value="cn"/>
</serviceInstance>
<serviceInstance location="./bootstrap" provider="credstoressp"
name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>
ログイン・モジュールのプリンシパル
出荷時のjps-config-jse.xmlには、次のプロパティが設定されています。
<property name="oracle.security.jps.enterprise.user.class"
value="weblogic.security.principal.WLSUserImpl"/>
<property name="oracle.security.jps.enterprise.role.class"
value="weblogic.security.principal.WLSGroupImpl"/>
どのようなログイン・モジュールでも、前述のプロパティを使用する必要があります。これは、アイデンティティ・ストア内のユーザーおよびグループを表すプリンシパルが、次のとおりであることを意味しています。
weblogic.security.principal.WLSUserImpl weblogic.security.principal.WLSGroupImpl
