8 OPSS Authorization and the Policy Store

The domain policy store is the repository of system and application-specific policies. In a given domain, there is one store that stores all policies (and credentials) that all applications deployed in the domain may use.

When a domain is setup to use policies based on the Policy Store, as explained in this chapter, then JACC policies and the Java Security Manager become unavailable on all managed servers in that domain.

Important:

All permission classes used in policies must be included in the classpath, so the policy provider can load them when a service instance is initialized.

8.1 Configuring a Domain to Use an LDAP-Based Policy Store

An LDAP-based policy store is typically used and recommended in production environments. The LDAP servers supported in this release are the Oracle Internet Directory and the Oracle Virtual Directory.

The characteristics of the domain policy store and the domain credential store are tightly correlated: both must be of the same kind (file-based or LDAP-based), and in case of LDAP-based repositories, both must use the same type of LDAP server. Out-of-the-box, the policy and credential stores are file-based.

To use a domain LDAP-based policy store the domain administrator must configure it, as appropriate, using Oracle Enterprise Manager Fusion Middleware Control or WLST commands.

8.1.1 Multiple-Node Server Environments

In domains where several server instances are distributed across multiple machines, it is highly recommended that the domain policy and credential stores be LDAP-based, so that all policy and credential data is kept and maintained in one centralized store.

Typically, applications do not change policy data. When they do, however, it is crucial that these changes be correctly propagated to all managed servers in a domain and, therefore, any such changes should always be performed by the domain administration server (and not by managed servers).

In a single-node server domain, the propagation of local changes to security data is irrelevant: in this scenario, local changes are equivalent to global changes.

In a multiple-node server domain, however, the JMX framework propagates local changes to a file-based policy to each runtime environment, so that the data is refreshed based on caching policies and configuration.

To summarize, in a multiple-node server environment, it is recommended that:

Either the domain policy and credential stores be centralized in a LDAP-based store.

Or, if they are file-based, then local changes to policy or credential data be performed only by the domain administration server to ensure that they are correctly propagated from the administration server to all managed servers in the domain.

8.1.2 Prerequisites to Using an LDAP-Based Policy Store

In order to ensure the proper access to an LDAP server directory (Oracle Internet Directory or Oracle Virtual Directory), you must set a node in the server directory.

The distinguished name of the root node (illustrated by the string jpsroot above) must be distinct from any other distinguished name. Some LDAP servers enforce case sensitivity by default. One root node can be shared by multiple WebLogic domains. It is not required that this node be created at the top level, as long as read and write access to the subtree is granted to the Oracle Internet Directory administrator.

Import this data into the LDAP server using the command ldapadd, as illustrated in the following example (there should be no line break in the command invocation):

If you are using an LDAP-based Oracle Internet Directory policy store, you can skip the following section (about Oracle Virtual Directory configuration) and continue on directly to reassociating the policy store as explained in Reassociating the Domain Policy Store.

Configuring an Oracle Virtual Directory Server with a Local Store Adapter

Oracle Virtual Directory provides Internet and industry-standard LDAP and XML views of existing enterprise identity information, without synchronizing or moving data from its native locations. The configuration explained in this section is performed by the Oracle Virtual Directory administrator.

To configure Oracle Virtual Directory to use a file to store the policies with an LSA, proceed as follows:

Start the Oracle Directory Services Manager.

Select the tab Adapter.

Choose to create an adapter, to display the dialog New Adapter Wizard illustrated in the following graphic:

In the Type phase of that wizard, (a) set Adapter Type to Local Store; (b) set the Adapter Name to a unique name; and (c) set Adapter Template to Opss.

Click Next, to display the Settings phase of the New Local Store Adapter Wizard as illustrated in the following graphic:

In the Adapter Suffix/Namespace text box, enter the root name for the adapter you are creating (this value should match the dn of the node in the OVD). Retain default values in all other fields.

Click Next to view all settings in the Summary phase of the wizard, and, when satisfied with them, commit your input.

8.2 Reassociating the Domain Policy Store

Reassociating the policy store consists in migrating policy data from a file- or LDAP-based repository to an LDAP-based repository, that is, reassociation changes the repository preserving the integrity of the data stored. For each policy in the source policy store, reassociation searches the target LDAP directory and, if it finds a match, it updates the matching policy as appropriate. If none is found, it simply migrates the policy as is.

At any time, after a domain policy store has been instantiated, a file- or LDAP-based policy store can be reassociated into an LDAP-based policy store storing the same data. To support it, the domain has to be configured, as appropriate, to use and LDAP policy store.

Reassociation is carried out using either Fusion Middleware Control or the WLST command reassociateSecurityStore. This operation is typically performed when setting a domain to use the an LDAP-based domain store instead of the out-of-the-box file-based store.

Important:

The repositories for the policy store and the credential store must both be file-based or both LDAP-based. Moreover, in the LDAP-based case, both stores must use the same kind of LDAP server. To preserve this coherence, note that reassociating one store implies reassociating the other one.

8.2.1 Reassociating Domain Stores with Fusion Middleware Control

The reassociation of security stores migrates policies and credentials from one repository to another, thus reconfiguring those security store providers; this reconfiguration is typically performed when, for example, transitioning from a test environment to a production environment. OPSS supports LDAP- to LDAP-based or file- to LDAP-based reassociation, where the LDAP servers are Oracle Internet Directory or Oracle Virtual Directory. LDAP- to file- based reassociation, however, is not supported.

This section explains the steps you follow to reassociate policies and credentials to an LDAP-based storage using Oracle Internet Directory or Oracle Virtual Directory servers.

If reassociation is to use a one-way SSL, follow the instructions in Setting Up a One- Way SSL Connectionbefore initiating the reassociation (with either Fusion Middleware Control or the WLST command reassociateSecurityStore).

To reassociate both the policy and the credential stores in a given domain to a new LDAP repository with Fusion Middleware Control, proceed as follows:

Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration, to display the Security Provider Configuration page. This page is partially shown in the following graphic:

The table underneath the button Configure... shows the characteristics of the current provider configured in the domain.

Click the button Configure... in the area Policy and Credential Store Providers to display the page Set Security Provider. In this page, enter details and connection information about the target LDAP server.

Select the type of LDAP server from the menu: if Oracle Virtual Directory is configured with the local store adapter, select Oracle Virtual Directory; otherwise, select Oracle Internet Directory.

Enter the host name and port number of your target LDAP server.

Optionally, check the box Use SSL to Connect to establish an anonymous SSL transmission to the LDAP server.

When checking this box, keep in mind the following points:

The port of the target LDAP server must be configured to handle an anonymous SSL transmission; this port is distinct from the default (non-secure) LDAP server port.

If the reassociation is to use a one-way SSL, be sure to follow the instructions in Setting Up a One- Way SSL Connectionbefore completing this step. Among other things, that set up identifies the port to support a one-way SSL channel, and it is that port that should be specified in this step. Reassociation through a two-way SSL channel is not supported in this release.

Fusion Middleware Control modifies the file weblogic.policy by adding the necessary grant to support the anonymous SSL connection.

In the text box User DN, enter the full distinguished name, a string containing between 1 and 256 characters. For example, cn=orcladmin,dc=us,dc=oracle,dc=com.

In the box Password, enter the user password, also a string containing between 1 and 256 characters.

In the JPS Root Node Details area, enter the root DN in the box JPS Root DN. This node denotes the top of the tree that contains the data in the LDAP repository. The WebLogic Domain Name defaults to the name of the selected domain. To solve most common errors arising from the specifications in these two fields, see Section I.2, "Reassociation Failure."

Optionally, enter properties for the service instance: click Add and then, in the Add New Property dialog, enter strings for Property Name and Value; click OK. The added property-value pair is displayed in the table Custom Properties.

These properties are typically used to initialize the instance when it is created.

A property-value pair you enter modifies the domain configuration file jps-config.xml by adding a <property> element in the configuration of the LDAP service instance.

To illustrate how a service instance is modified, suppose you enter the property name foo and value bar; then the configuration for the LDAP service instance changes to contain a <property> element as shown in the following excerpt:

When finished entering your data, click OK to return to the Security Provider Configuration page. The system displays a dialog notifying the status of the reassociation. The table in the Policy and Credential Store Providers area is modified to show, as the current provider, the provider you have just specified.

Restart the Oracle WebLogic Server. Changes do not take effect until the server has been restarted.

Reassociation modifies the domain configuration file $DOMAIN_HOME/config/fmwconfig/jps-config.xml: it deletes any configuration for the old provider and inserts a configuration for the new store provider, so, when the server is restarted the new configuration takes effect.

8.2.1.1 Setting Up a One- Way SSL Connection

This section describes how to set up a one-way SSL channel between the Oracle WebLogic server and a target LDAP Oracle Internet Directory store to reassociate domain stores. This setup should be in place before using Fusion Middleware Control or the WLST command reassociateSecurityStore.

Use the WebLogic Administration Console to set, in the appropriate domain, a truststore that points to the file myKeys.jks, as follows:

Navigate to Environment > Servers.

Select the name of the administration server in your domain.

Select the tab Keystore.

Change the keystore mode from Demo Identity and Demo Trust to Custom Identity and Custom Trust.

In the Trust section enter data as follows: in the field Custom Trust Keystore, enter the absolute path name of the keystore file myKeys.jks; in the field Keystore Type, enter JKS; in the fields Custom Trust Keystore Passphrase and Confirm Custom Trust Keystore Passphrase, enter the keystore password.

Modify the script (typically startWebLogic.sh) that starts your server to include a line like the following, and then restart the server:

-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>

8.2.1.2 Securing Access to Oracle Internet Directory Nodes

The procedure explained in this section is optional and performed only to enhance the security to access an Oracle Internet Directory.

An access control list (ACL) is a list that specifies who can access information and what operations are allowed on the Oracle Internet Directory directory objects. The control list is specified at a node, and its restrictions apply to all entries in the subtree under that node.

ACL can be used to control the access to policy and credential data stored in an LDAP Oracle Internet Directory repository, and it is, typically, specified at the top, root node of the store.

To specify an ACL at a node in an Oracle Internet Directory repository, proceed as follows:

Domain stores can also be manually reassociated with the WLST command reassociateSecurityStore. For details about this command, see reassociateSecurityStore.

8.3 Migrating Policies to the Domain Policy Store

A domain includes one and only one policy store. Applications can specify their own policies, but these are stored as policies in the domain policy store when the application is deployed to a server. Thus, all applications deployed in a domain use a common policy store, the domain policy store. The domain policy store is logically partitioned in stripes, one for each application name specified in the file $DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml under the element <applications>.

During application development, an application specifies its own policies, and these can be migrated to the domain policy store when the application is deployed with Fusion Middleware Control. Policies can also be migrated manually; in addition, each application component can specify the use of anonymous user and role, authenticated role, and JAAS mode.

The configuration of the domain policy store is performed by the domain administrator.

8.3.1 Migrating Application Policies with Fusion Middleware Control

Application policies are specified in the application file jazn-data.xml and can be migrated to the domain policy store when the application is deployed to a server in the WebLogic environment with Fusion Middleware Control; they can also be removed from the domain policy store when the application is undeployed or be updated when the application is redeployed.

All three operations, the migration, the removal, and the updating of application policies, can take place regardless of the type of policy repository, but they do require particular configurations.

8.3.2 Migrating Policies with the Command migrateSecurityStore

Application-specific policies or system policies can be migrated manually from a source repository to a target repository using the WLST command migrateSecurityStore.

This command is offline, that is, it does not require a connection to a running server to operate; therefore, the configuration file passed to the argument configFile need not be an actual domain configuration file, but it can be assembled just to specify the source and destination repositories of the migration.

The meaning of the arguments (all required except overWrite) is as follows:

configFile specifies the location of a configuration file jps-config.xml relative to the directory where the command is run. Typically, this configuration file is created just to be used with the command and serves no other purpose. This files contains two jps-contexts that specify the source and destination stores.

In addition, if the migration involves one or two LDAP-based stores, then this file must contain a bootstrap jps-context that refers to the location of a cwallet.sso file where the credentials to access the LDAP based involved in the migration are kept. See second example below.

src specifies the name of a jps-context in the configuration file passed to the argument configFile.

dst specifies the name of another jps-context in the configuration file passed to the argument configFile.

overWrite specifies whether a target policy matching a source policy should be overwritten by or merged with the source policy. Set to true to overwrite the target policy; set to false to merge matching policies. Optional. If not specified, defaults to false.

The contexts passed to src and dst must be defined in the passed configuration file and must have distinct names. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

To migrate just system policies, use the script (first) or interactive (second) syntaxes (arguments are written in separate lines for clarity):

The meanings of the arguments configFile, src, dst, and overWrite are identical to the previous case. The meanings of other three arguments are as follows:

srcApp specifies the name of the source application, that is, the application whose policies are being migrated.

dstApp specifies the name of the target application, that is, the application whose policies are being written. If unspecified, it defaults to the name of the source application.

migrateIdStoreMapping specifies whether enterprise policies should be migrated. The default value is True. To filter out enterprise policies from the migration, that is, to migrate just application policies, set it to False.

If the input does not follow the syntax requirements above, the command execution fails and returns an error. In particular, the input must satisfy the following requisites: (a) the file jps-config.xml is found in the passed location; (b) the file jps-config.xml includes the passed jps-contexts; and (c) the source and the destination context names are distinct.

To avoid unexpected authorization failures and to manage policies effectively, note the following important points:

Important Point 1:

Before deleting a user, revoke all permissions, application roles, and enterprise groups that have been granted to the user. If you fail to remove all security artifacts referencing a user to be deleted, they are left dangling and, potentially, be inadvertently inherited if another user with the same name or uid is created at a later time.

Similar considerations apply to when a user name or uid is changed: all policies (grants, permissions, groups) referring to old data must be updated so that it works as expected with the changed data.

Policies use case sensitivity in names when they are applied. The best way to avoid possible authorization errors due to case in user or group names is to use the spelling of those names exactly as specified in the identity store.

It is therefore recommended that:

When provisioning a policy, the administrator spell the names of users and groups used in the policy exactly as they are in the identity repository. This guarantees that queries into the policy store (involving a user or group name) work as expected.

When entering a user name at run-time, the end-user enter a name that matches exactly the case of a name supplied in the identity repository. This guarantees that the user is authorized as expected.

8.4.1 Managing Policies with Fusion Middleware Control

Fusion Middleware Control allows the management of system and application policies in a WebLogic domain, regardless of the type of policy store provider used in the domain, as explained in the following sections:

8.4.1.1 Managing Application Policies

This section explains the steps you follow to manage the policies of a deployed application with Fusion Middleware Control, such as, for example, to change the permission grants of an existing application role. To manage system policies, see Managing System Policies.

Note:

If multiple applications are to share a permission and to prevent permission check failures, the corresponding permission class must be specified in the system classpath.

Log in to Fusion Middleware Control and navigate to Application > Security > Application Policies, to display the Application Policies page for the selected Application. This page is partially shown in the following graphic:

The area Policy Store Provider is read-only and, when expanded, displays the policy store provider currently in use in the domain where the application is deployed.

Note:

If the page does not initially display policies and roles, click the blue button to display all items.

To display existing application policies matching a given principal or permission, expand the Search area, as necessary, enter the data to match (a principal or a permission or both), and click the blue button. The results of the search are displayed in the table at the bottom of the page.

To create an application policy, click Create to display the Create Application Grant page. The top area Grant Details displays read-only information about the application.

To add permissions to the policy being created, click Add in the Permissions area to display the Add Permission dialog.

Using the Search to identify permissions matching a class or resource name, determine the Permission Class and Resource Name of the permission. Optionally, use the Customize area to further qualify the permission.

When finished, click OK to return to the Create Application Grant page. The permission you created is displayed in the table in the Permissions area.

To add a user to the policy being created, click the button Add User in the Grantee area to display the dialog Add User.

Using the Search, identify users names matching a string; the result of the query is displayed in the Available Users box.

Using the various buttons, move the users you want to grant permissions from the Available Users box to the Selected Users box.

When finished, click OK to return to the Create Application Grant page. The users you selected are displayed in the table in the Grantee area.

To add a role to policy being created, click the button Add Role in the Grantee area to display the dialog Add Role.

Using the Search, identify role names matching a type or name; the result of the query is displayed in the Available Roles box.

Using the various buttons, move the roles you want to grant permissions from the Available Roles box to the Selected Roles box.

When finished, click OK to return to the Create Application Grant page. The roles you selected are displayed in the table in the Grantee area.

At any point you can remove a selected item using the Delete button.

When finished, click OK to return to the Application Policies page. The principal and permissions of the policy created are displayed in the table at the bottom of the page.

To create an application policy based on an existing one:

Select an existing policy from the table.

Click Create Like, to display the Create Application Grant page. Notice that in this page all the permissions are automatically filled in with the data extracted from the policy you selected.

Modify those values and enter users and roles, as appropriate, as explained in the substeps of step 3 above.

8.4.1.2 Managing Application Roles

This section explains the steps you follow to manage the roles of a deployed application with Fusion Middleware Control. Management operations that control the access a user or group has to resources, include creating application roles, mapping an application role to users, groups, or other application roles, and managing the members in application roles.

Log in to Fusion Middleware Control and navigate to Application > Security > Application Roles, to display the Application Roles page. This page is partially shown in the following graphic:

The area Policy Store Provider is read-only and, when expanded, displays the policy store provider currently in use in the domain where the application is deployed.

Note:

If the page does not initially display application roles, click the blue button to display all items.

To display application roles matching a given name, enter the data to match in the box Role Name, and click the blue button. The results of a query are displayed in the table at the bottom of the page.

To redisplay the table of all current application policies, leave the Role Name blank and click the blue button.

To create an application role, click Create to display the Create Application Role page. Note that you must not enter data in all areas at once. For example, you could create a role by entering the role and display name, save your data, and later on specify the members in it. Similarly, you could enter data for role mapping at a later time.

In the area General, specify the following attributes of the role being created:

The name of the role, in the text box Role Name.

The name to display for the role, in the text box Display Name.

Optionally, a description of the role, the text box Description.

In the area Members, specify the users, groups, or other application roles, if any, into which the role being created is mapped:

Click Add Role, to display the Add Role dialog.

In this dialog, select the type of the role to be added from the menu next to Role Type; optionally, enter a role name in the text box Role Name; and then click the blue button to display, in the box Available Roles, the roles that match the entered criteria.

Select roles from the box Available Roles, as appropriate, and use the buttons in between the boxes to move them to the box Selected Roles.

When finished, click OK to return to the Create Application Role page. The selected roles are displayed in the table Roles.

In the area Users, specify the members of the role being created:

Click Add User, to display the Add User dialog.

The box Available Users displays all the available users. To display just the users with names matching a given string, enter that string in the box User Name and click the blue button.

Select users from the box Available Users, as appropriate, and use the buttons in between the boxes to move them to the box Selected Users.

When finished, click OK to return to the Create Application Role page. The selected users are displayed in the table Users.

Click OK to effect the role creation (or update) and to return to the Application Roles page. The role just created is displayed in the table at the bottom of that page.

8.4.1.3 Managing System Policies

This section explains the steps you follow to manage system policies for a domain with Fusion Middleware Control. To manage application policies, see Managing Application Policies.

The procedure below enables creating two types of system policies: principal policies and codebase policies. A principal policy grants permissions to a list of users or groups. A codebase policy grants permissions to a piece of code, typically a URL or a JAR file; for example, an application using the Credential Store Framework requires an appropriate codebase policy.

Log in to Fusion Middleware Control and navigate to Domain > Security > System Policies to display the page System Policies. This page is partially shown in the following graphic:

The area Policy Store Provider is read-only and, when expanded, displays the policy store provider currently in use in the domain.

To display application policies matching a given type, name, or permission, expand the Search area, enter the data to match, and click the blue button. The results of a query are displayed in the table at the bottom of the page.

To redisplay the table of current application policies, select the type All and leave the name and permission boxes blank.

At any point, you can edit the characteristics of a selected policy by clicking the Edit button, or remove it from the list by clicking the Delete button.

To create a system policy:

Click Create to display the Create System Grant page.

In the area Grant Details, select type of policy to create. The valid types are Principal or Codebase. The UI differs slightly depending on the type chose. The steps below assume the selection Principal.

To add permissions to policy being created, click the button Add in the Permissions area to display the Add Permission dialog. In this dialog choose a permission to add to the policy being created.

Use the Search area to query permissions matching a type, principal name, or permission name. The result of the query is display in the table in the Search area.

To choose the permission to add, select a permission from the table. Note that, when a permission is selected, its details are rendered in the read-only Customize area.

Click OK to return to the Create System Grant page. The selected permission is added to the table Permissions.

At any point, you can select a permission from the table and use the button Edit to change the characteristics of the permission, or the button Delete to remove from the list.

To add users to the policy being created, click the button Add User in the Grantee area to display the Add User dialog.

Use the Search to display user names matching a pattern. The results of the query are displayed in the box Available Users.

Use the buttons in between the boxes to move users from the Available Users box to the Selected Users box.

Click OK to return to the Create System Grant page. The users you have selected are added to the table Grantee.

To add roles to the policy being created, click the button Add Role in the Grantee area to display the Add Role dialog.

Use the Search to display role names matching a type or role name. The results of the query are displayed in the box Available Roles.

Use the buttons in between the boxes to move users from the Available Roles box to the Selected Roles box.

Click OK to return to the Create System Grant page. The roles you have selected are added to the table Grantee.

Click OK to return to the System Policies page. An message at the top of the page informs you the result of the operation. If successful, the policy is added to the table at the bottom of the page.

To create a system policy based on an existing system policy:

Select a policy from the table.

Click Create Like to display the Create System Grant page. Notice that some entries in the page are filled in with data extracted from the policy selected in the previous step.

Follow the preceding procedure (to create a system policy) to modify those values and enter new ones, as appropriate.

8.4.2 Managing Policies with WLST Commands

If a domain administrator does not want to use Fusion Middleware Control to manage policies or wants to execute a frequent task automatically, the administrator can create a WLST script that invokes WLST security-related commands.

An online command is a command that, to perform, requires a connection to a running Oracle WebLogic Server. All commands below are online commands and operate on a domain policy store, regardless of whether it is file- or LDAP-based.

Read-only commands can be performed only by users in the following groups: Monitor, Operator, Configurator, or Admin. Read-write commands can be performed only by users in the following groups: Admin or Configurator. All WLST commands are available out-of-the-box with the installation of the Oracle WebLogic Server.

Unless otherwise explicitly stated, the commands listed below can be run in interactive mode or in script mode. In interactive mode, a command is entered at a command-line prompt and view the response immediately after. In script mode, commands are written in a text file (with a py file name extension) and run without requiring input, much like the directives in a shell script.

Important:

Before invoking a security-related WLST command in a shell, you must run the script wlst.sh, as illustrated in the following sample:

> sh $ORACLE_HOME/common/bin/wlst.sh

This ensures that the required JARs are added to the classpath. Failure to run the above script in a new shell renders the WLST commands unusable.

All class names specified in these commands must be fully qualified path names. The argument appStripe refers to the application stripe (application name) and identifies the subset of domain policies pertaining a particular application.

8.4.2.1 createAppRole

The command createAppRole creates an application role in the domain policy store with given application stripe and role name.

Script Mode Syntax

createAppRole.py -appStripe appName
-appRoleName roleName

Interactive Mode Syntax

createAppRole(appStripe="appName", appRoleName="roleName")

The meanings of the arguments (all required) are as follows:

appStripe specifies an application stripe.

appRoleName specifies a role name.

Example of Use

The following invocation creates an application role with application stripe myApp and role name myRole:

createAppRole.py -appStripe myApp -appRoleName myRole

8.4.2.2 deleteAppRole

The command deleteAppRole removes from the domain policy store the application role with given application stripe and role name.

Script Mode Syntax

deleteAppRole.py -appStripe appName -appRoleName roleName

Interactive Mode Syntax

deleteAppRole(appStripe="appName", appRoleName="roleName")

The meanings of the arguments (all required) are as follows:

appStripe specifies an application stripe.

appRoleName specifies a role name.

Example of Use

The following invocation removes the role with application stripe myApp and name myRole:

deleteAppRole.py -appStripe myApp -appRoleName myRole

8.4.2.3 grantAppRole

The command grantAppRole adds a principal (class and name) to a role with a given application stripe and name.

8.4.2.10 deleteAppPolicies

The command deleteAppPolicies removes all policies with a given application stripe.

Script Mode Syntax

deleteAppPolicies -appStripe appName

Interactive Mode Syntax

deleteAppPolicies(appStripe="appName")

The meaning of the argument (required) is as follows:

appStripe specifies an application stripe. If not specified, then the command works on just system policies.

Example of Use

deleteAppPolicies -appStripe myApp

8.4.2.11 reassociateSecurityStore

The command reassociateSecurityStore migrates, within a give domain, both the policy store and the credential store to a target LDAP server repository. The function of this command is equivalent to reassociating domain stores with Fusion Middleware Control.

The only kinds of LDAP server targets allowed are Oracle Internet Directory or Oracle Virtual Directory. The source repository can be file- or LDAP-based. This command uses and modifies the domain configuration file jps-config.xml, and it is supported in only the interactive mode.

admin specifies the administrator's user name on the LDAP server. The format is cn=usrName.

password specifies the password associated with the user specified for the argument admin.

ldapurl specifies the URI of the LDAP server. The format is ldap//:host:port, if you are using the default port, or ldaps://host:port, if you are using an anonymous SSL or one-way SSL transmission. The secure port must be configured to handle the desired SSL connection mode, and must be distinct from the default (non-secure) port.

servertype specifies the kind of the target LDAP server. The only valid types are OID (Oracle Internet Directory) or OVD (Oracle Virtual Directory).

jpsroot specifies the root node in the target LDAP repository under which all data is migrated. The format is cn=nodeName.

8.5 Configuring Property Sets with Oracle Fusion Middleware Control

This section explains features how to configure property and property sets with Fusion Middleware Control in the Security Provider Configuration page.

Note:

The area of the page Security Provider Configuration labeled Web Services Manager Authentication Providers pertains to the configuration of Login Modules and the Keystore for Web Services Manager only and is not relevant to ADF or JavaEE applications.

In regards to the Keystore: a Keystore configuration should not be modified; to change any settings for the Keystore, first remove the existing configuration (uncheck the box Configure Keystore and then click OK), and then continue to specify a new one. Failure to proceed this way leads to errors and unexpected behavior.

The elements <property> and <properySet> in the file $DOMAIN_HOME/config/fmwconfig/jps-config.xml are used to define property and property sets. Property sets can be referenced by the element <propertySetRef>.

To define a property or a property set using Fusion Middleware Control, proceed as follows:

Expand, if necessary, the area Advanced Properties at the bottom of the page, and click Configure to display the Advanced Properties page, in which you can enter properties and property sets.

To enter a property, click Add in the Properties area to display the dialog Add New Property, and enter a property name and value. When finished, click OK. The entered property appears on the Properties table.

To enter a property set, click Add Property Set in the Property Sets area to display the dialog Add Property Set, and enter the property set name.

To enter a property in a property set, select a property set from the existing ones, then click Add Property to display the dialog Add New Property, and then enter a property name and value. The entered property is added to the list of properties in the selected property set.

Use the button Delete to remove a selected item from any table. When finished entering or editing properties and property sets, click OK.

Restart the Oracle WebLogic Server. Changes do not take effect until the server has been restarted.

The addition or deletion of property sets modifies the domain configuration file $DOMAIN_HOME/config/fmwconfig/jps-config.xml; the changes do not take effect until the server is restarted.

The elements <property> and <propertySet> added by the previous procedure are inserted directly under the element <jpsConfig>.

Scripting on this page enhances content navigation, but does not change the content in any way.