This appendix describes several procedures to update security data. Specifically, it describes how to upgrade security data from a major release (10.1.3.x) to a major release (11.1.1), and how to upgrade data from a minor release (such as 11.1.1.2.0) to the current minor release in the following sections:
The OPSS script upgradeSecurityStore is used only to upgrade application security data from a previous major release (such as 10.1.1.3) to the current major release (11.1.1.1.0). To upgrade between minor 11g releases, use upgradeOpss as described in section Upgrading the OPSS Security Store with upgradeOpss.
If the target of the upgrading is an LDAP-based repository, then some setting up before running the script is required, as described in Section 8.3.1, "Prerequisites to Using an LDAP-Based Security Store."
The script is offline, that is, it does not require a connection to a running server to operate, and can be run in interactive mode or in script mode, on WebLogic, and in interactive mode only, on WebSphere. In interactive mode, you enter the script at a command-line prompt and view the response immediately after. In script mode, you write scripts in a text file and run it without requiring input, much like the directives in a shell script.
For platform-specific requirements to run an OPSS script, see note in Section 9.4, "Managing Application Policies with WLST Commands."
Script and Interactive Modes Syntaxes
The script syntax varies depending on the type of store being upgraded. Optional arguments are enclosed in square brackets; arguments in script mode syntax are written in separate lines for clarity of exposition.
To upgrade 10.1.3.x XML identity data to 11g Release 1 (11.1.1) XML identity data, use either of the following syntaxes:
updateSecurityStore -type xmlIdStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
-srcRealm jaznRealm
[-dst dstJpsContext]
updateSecurityStore(type="xmlIdStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", srcRealm="jaznRealm", [dst="dstJpsContext"])
To upgrade a 10.1.3.x XML policy data to 11g Release 1 (11.1.1) XML policy data, use either of the following syntaxes:
updateSecurityStore -type xmlPolicyStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
[-dst dstJpsContext]
updateSecurityStore(type="xmlPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", [dst="dstJpsContext"])
To upgrade a 10.1.3.x Oracle Internet DirectoryLDAP-based policy data to 11g Release 1 (11.1.1) XML policy data, use either of the following syntaxes:
updateSecurityStore -type oidPolicyStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznConfigFile srcJazn
[-dst dstJpsContext]
updateSecurityStore(type="oidPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznConfigFile="srcJazn", [dst="dstJpsContext"])
To upgrade file-based application policies from release 11.1.1.1.0 to release 11.1.1.2.0, use either of the following syntaxes:
updateSecurityStore -type xmlAppPolicies
-srcApp applicationStripeName
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
-dstJaznDataFile dstJazn
-resourceTypeFile resTypeJazn
updateSecurityStore(type="xmlAppPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", dstJaznDataFile="dstJazn", srcJaznDataFile="resTypeJazn")
To upgrade 11.1.1.1.0 application policies to 11.1.1.2.0 format, use either of the following syntaxes:
updateSecurityStore -type appPolicies
-srcApp applicationStripeName
-jpsConfigFile jpsConfigFileLocation
-dst dstContext
[-resourceTypeFile resTypeJazn]
updateSecurityStore(type="appPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", dst="dstContext" [, resourceTypeFile="resTypeJazn"])
This upgrade works in-place and involves the creation of specified resource types and resources corresponding to permissions in the grants.
Once the run completes, the policy store pointed to by the context passed in dst in the configuration file passed in jpsConfigFile has new resource types and new resources defined for application passed in srcApp. The resource types are read from the file specified in resourceTypeFile and resources are created corresponding to permissions in the application grants.
The meaning of the arguments is as follows:
type specifies the kind of security data being upgraded. The only valid values are xmlIdStore, xmlPolicyStore, oidPolicyStore, xmlCredStore, xmlAppPolicies, and appPolicies.
jpsConfigFile specifies the location of a configuration file jps-config.xml relative to the directory where the script is run. The target store of the upgrading is read from the context specified with the argument dst.
In case the type is xmlAppPolicies, the configuration file is not used to point to neither source nor destination, but to configure the audit service only. Note that the location must be passed even when the audit service is not specified in the jps-config.xml file.
srcJaznDataFile specifies the location of a 10.1.3.x jazn-data.xml file relative to the directory where the script is run. This argument is required if the specified type is xmlIdStore, xmlPolicyStore, or xmlCredStore.
In case the specified type is xmlAppPolicies, it specifies the location of the application 11.1.1.1.0 jazn-data.xml file, a file that does not include resource type specifications.
srcJaznConfigFile specifies the location of a 10.1.3.x jazn configuration file relative to the directory where the script is run. This argument is required if the specified type is oidPolicyStore.
users specifies a comma-delimited list of users each formatted as realmName/userName. This argument is required if the specified type is xmlCredStore.
srcRealm specifies the name of a realm in the file passed to the argument srcJaznDataFile that identifies the identities to be migrated. This argument is required if the specified type is xmlIdStore.
dst specifies the name of a jpsContext in the file passed to the argument jpsConfigFile where the destination store is configured. Optional. If unspecified, it defaults to the default jpsContext.
srcApp specifies the application stripe. It should match the application name present in the files srcJaznDataFile and resourceTypeFile. A stripe with this name is created in the file dstJaznDataFile.
dstJaznDataFile specifies the location of the application 11.1.1.2.0 jazn-data.xml file. This file includes resource type and resource instance specifications and is the replacement for the original jazn-data.xml specified in srcJaznDataFile.
resourceTypeFile specifies the location of the 11.1.1.2.0 jazn-data.xml file which includes resource type specifications.
dst specifies the destination context that points to the policy store to update.
The following sections contain examples that illustrate the use of the script upgradeSecurityStore in different scenarios:
Example 3 - Upgrading to Oracle Internet Directory LDAP-Based Policies
Example 4 - Upgrading File-Based Policies to Use the Resource Catalog
The following invocation illustrates the migration of 10.1.3 file-based identities to an 11g Release 1 (11.1.1) file-based identity store:
upgradeSecurityStore -type xmlIdStore
-jpsConfigFile jps-config-idstore.xml
-srcJaznDataFile jazn-data.xml
-srcRealm jazn.com
This use of the script assumes that: (a) the files jps-config-idstore.xml and jazn-data.xml are located in the directory where the script is run; (b) the default jpsContext in the file jps-config-idstore.xml references the target identity store; and (c) the file jazn-data.xml contains a realm named jazn.com.
Here are the relevant excerpts of the two files involved in the use sample above:
<!-- excerpt from file jps-config-idstore.xml -->
<serviceProviders>
<serviceProvider name="R11idstore" class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" type="IDENTITY_STORE">
<description>11g XML-based IdStore</description>
</serviceProvider>
</serviceProviders>
...
<serviceInstances>
<serviceInstance name="idstore.xml1" provider="R11idstore" location="./jazn-data-11.xml">
<property name="subscriber.name" value="jazn.com"/>
<property name="jps.xml.idstore.pwd.encoding" value="OBFUSCATE"/>
</serviceInstance>
</serviceInstances>
...
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="idstore.xml1" />
</jpsContext>
</jpsContexts>
<!-- excerpt from jazn-data.xml -->
<jazn-realm>
<realm>
<name>jazn.com</name>
<users> ... </users>
<roles> ... </roles>
</realm>
</jazn-realm>
Thus, the sample invocation above migrates every user in the element <users>, to the XML identity store R11idStore.
The following invocation illustrates the migration of a 10.1.3 file-based policy store to an 11g Release 1 (11.1.1) policy store:
upgradeSecurityStore -type xmlPolicyStore
-jpsConfigFile jps-config.xml
-srcJaznDataFile jazn-data.xml
-dst destContext
This use of the script assumes that: the files jps-config.xml and jazn-data.xml are located in the directory where the script is run; and the file jps-config.xml contains a jpsContext named destContext.
Here are the relevant excerpts of the two files involved in the use sample above:
<!-- excerpt from file jps-config.xml -->
<serviceProviders>
<serviceProvider type="POLICY_STORE" name="policystore.xml.provider" class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">
<description>R11 XML-based PolicyStore Provider</description>
</serviceProvider>
</serviceProviders>
...
<serviceInstances>
<serviceInstance name="policystore1.xml" provider="policystore.xml.provider">
<property name="R11PolStore" value="jazn-data1.xml"/>
</serviceInstance>
...
<jpsContexts default="default1">
<jpsContext name="default1"> ... </jpsContext>
<jpsContext name="destContext">
...
<serviceInstanceRef ref="policystore1.xml"/>
</jpsContext>
</jpsContexts>
<!-- excerpt from jazn-data.xml -->
<jazn-realm>
<realm>
...
<roles> ... </roles>
</realm>
</jazn-realm>
...
<jazn-policy> ... </jazn-policy>
Thus, the sample invocation above migrates every role in the element <roles> and every policy in the element <jazn-policy> to the XML policy store R11PolStore.
The following invocation illustrates the upgrading of a 10.1.4 Oracle Internet Directory LDAP-based policy store to an 11g Release 1 (11.1.1) Oracle Internet Directory LDAP-based policy store:
upgradeSecurityStore -type oidPolicyStore
-jpsConfigFile jps-config.xml
-srcJaznConfigFile jazn.xml
-dst destContext
The assumptions about the location of the two XML files involved in this example are similar to those in Example 2. In addition, it is assumed that (a) the file jps-config.xml contains the jpsContext destContext that points to the target Oracle Internet Directory LDAP-based policy store; and (b) the file jazn.xml describes the location of the Oracle Internet Directory LDAP server from where the policies are migrated.
Here is the relevant excerpt from the file jazn.xml:
<jazn provider="LDAP" location="ldap://myCompany.com:3843"> <property name="ldap.user" value="cn=orcladmin"/> <property name="ldap.password" value="!welcome1"/> <property name="ldap.protocol" value="no-ssl"/> <property name="ldap.cache.policy.enable" value="false"/> <property name="ldap.initctx" value="com.sun.jndi.ldap.LdapCtxFactory"/> </jazn>
The following invocation upgrades an application 11.1.1.1.0 file-based policy store to an application 11.1.1.2.0 file-based policy store.
updateSecurityStore -type xmlAppPolicies
-srcApp PolicyServlet1
-jpsConfigFile ./folder/jps-config.xml
-srcJaznDataFile ./11.1.1.1.0/jazn-data.xml
-dstJaznDataFile ./11.1.1.2.0/final-jazn-data.xml
-resourceTypeFile ./resCat/res-jazn-data.xml
The point of this upgrade is that the original 11.1.1.1.0 file does not use resource catalog elements, but the resulting 11.1.1.2.0 file does use resource type and resource instance elements.
The script basically takes the original application configuration file, along with another file specifying resource type elements, and it produces a new application configuration file that contains policies as in the original file, but modified to use resource catalog specifications.
The original and the new application configuration files provide identical behavior to the application.
The above invocation assumes that:
The source file ./11.1.1.1.0/jazn-data.xml contains policies for the application PolicyServlet1.
The resource type file ./resCat/res-jazn-data.xml contains resource type specifications for the application PolicyServlet1.
The configuration file ./folder/jps-config.xml is any valid configuration file that may or may not use an audit service instance. In any case, it must be specified.
The following samples illustrate the relevant portions of three data files: the input source jazn-data.xml and resource res-jazn-data.xml, and the output final-jazn-data.xml.
Input Source File jazn-data.xml
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<app-roles>
<app-role>
<name>myAppRole2</name>
<display-name>application role myAppRole</display-name>
<members>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole</name>
<display-name>application role myAppRole</display-name>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
<app-role>
<name>testrole_DATA</name>
<display-name>application role test</display-name>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>test-entrole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole_PRIV</name>
<display-name>application role private</display-name>
<description>app role private description</description>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole_PRIV</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>
oracle.adf.share.security.authorization.RegionPermission</class>
<name>dummyName</name>
<actions>view,edit</actions>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.lang.XYZPermission</class>
<name>newxyz</name>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>test-entrole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>newxy</name>
<actions>view,edit</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
Input Resource File res-jazn-data.xml
<jazn-data>
<jazn-realm default="jazn.com">
</jazn-realm>
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<resource-types>
<resource-type>
<name>FileResourceType</name>
<display-name>File Access</display-name>
<description>Resource Type Modelling File Access</description>
<provider-name>provider</provider-name>
<matcher-class>oracle.security.jps.JpsPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>delete,write,read</actions>
</resource-type>
</resource-types>
<jazn-policy>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
</jazn-policy>
</jazn-data>
Output Data File final-jazn-data.xml
<jazn-data>
<jazn-realm>
</jazn-realm>
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<app-roles>
<app-role>
<name>myAppRole2</name>
<display-name>application role myAppRole</display-name>
<guid>4341CC10EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole</name>
<display-name>application role myAppRole</display-name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
<app-role>
<name>testrole_DATA</name>
<display-name>application role test role</display-name>
<guid>4342B670EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>test-entrole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole_PRIV</name>
<display-name>application role private</display-name>
<description>app role private description</description>
<guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>
weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</member>
</members>
</app-role>
</app-roles>
<resource-types>
<resource-type>
<name>FileResourceType</name>
<display-name>File Access</display-name>
<description>Resource Type Modelling File Access</description>
<provider-name>provider</provider-name>
<matcher-class>oracle.security.jps.JpsPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>delete,write,read</actions>
</resource-type>
</resource-types>
<resources>
<resource>
<name>getClassLoader</name>
<type-name-ref>FileResourceType</type-name-ref>
</resource>
<resource>
<name>newxy</name>
<type-name-ref>FileResourceType</type-name-ref>
</resource>
</resources>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole_PRIV</name>
<guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>
oracle.adf.share.security.authorization.RegionPermission</class>
<name>dummyName</name>
<actions>view,edit</actions>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.lang.XYZPermission</class>
<name>newxyz</name>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
weblogic.security.principal.WLSGroupImpl</class>
<name>test-entrole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>newxy</name>
<actions></actions>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
</jazn-policy>
</jazn-data>
upgradeOpss is an offline script that updates 11.1.1.2.0, 11.1.1.3.0, 11.1.1.4.0, 11.1.1.5.0, 11.1.1.6.0, and 11.1.1.7.0 configurations and stores to a 11.1.1.9.0 OPSS security store.
Note:
If you need to update from a previous version to a later previous version, as for example from 11.1.1.2.0 to 11.1.1.4.0, you must use the 11.1.1.4.0 version of the commandupgradeOpss.The store to be upgraded can be file-, LDAP-, or DB-based and possibly be shared by several WebLogic domains, and the script upgrades several artifacts including system policies, application policies, and the files jps-config.xml and jps-config-jse.xml.
The OPSS binaries and the target policy store must have compatible versions; for details, see Section K.9.1, "Incompatible Versions of Binaries and Policy Store."
The behavior and use of the script is explained in the following sections:
The following list enumerates some details of the changes that upgradeOpss effects on artifacts and services.
Credential Store - Generates a BASE64 encoded encryption key in the credential store.
Audit Service - Enables the OPSS audit service in Java SE applications by introducing the following configutation, data, and schema changes:
The properties location, audit store type, loader user name, and password are added to the audit service configuration.
The attributes AuditUser and TenantId are added to the common attribute group.
The columns IAU_AUDITUSER and IAU_TENANTID are added to the tables IAU_BASE and IAU_COMMON.
The common group version changes from 1.0 to 1.1.
The extended table name is IAU_CUSTOM_01.
Trust Service - Modifies the configuration of the trust service in the file jps-config-jse.xml to enable the OPSS trust service in Java SE applications, by inserting the following elements:
The trust.provider.embedded propertySet
The trust.provider serviceProvider
A trust service instance
A reference to the instance in the default context
PDP Service - Modifies the configuration of the PDP service in the file jps-config-jse.xml to enable the OPSS trust service in Java SE applications, by inserting the following elements:
The pdp.service.provider serviceProvider
A pdp service instance
A reference to the instance in the default context
Attribute Service - Modifies the configuration of the attribute service in the file jps-config.xml and jps-config-jse.xml to enable the attribute service in Java EE and Java SE applications, by inserting the following elements:
The attribute.provider serviceProvider
An attribute service instance
A reference to the instance in the default context
Introduces other miscellaneous changes to synch-up the files jps-config-jse.xml and jps-config.xml.
The following list enumerates important facts about upgradeOpss.
It must be run on the system that hosts the administration server instance so that when the server comes up, the upgraded data is pushed to all managed servers in the cluster.
Before using it, make sure that you backup the store to be upgraded. For details, see Backing Up and Recovering the OPSS Security Store.
It does not change the repository type.
It applies to an existing domain, which need not be recreated.
If the target store has already been updated to 11.1.1.7.0, then running the script changes nothing.
In case of a LDAP-based store, the connection parameters to the store is read from the file jps-config.xml or, alternatively, passed as arguments to the script.
In case of a DB-based store, the connection parameters are passed as arguments to the script.
In case the security store to be upgraded is shared by several domains (by the join operation), then all domains pointing to that store must install new 11.1.1.7.0 binaries before the store is upgraded. Otherwise, the system may throw the exception PolicyStoreIncompatibleVersionException which indicates that the version of OPSS security store is later than the version of the OPSS binaries.
It checks whether the file {domain.home}/config/fmwconfig/audit-store.xml exists; if not found and the security store is file-based, it creates it; otherwise, if the security store is LDAP- or DB-based, it creates the necessary audit data in the store.
To upgrade from 11.1.1.2.0, 11.1.1.3.0, 11.1.1.4.0, 11.1.1.5.0, 11.1.1.6.0 or 11.1.1.7.0 to 11.1.1.9.0, proceed as follows:
Stop the application server.
Install new binaries.
In case of upgrading a DB-based store, use Oracle Fusion Middleware Patch Set Assistant to upgrade the DB schema as follows:
Navigate to the OPSS Schema page.
Enter data for Connect String, DBA User Name and Password, and Schema User Name and Password and then click Next.
Run upgradeOpss as described in section Script Syntax.
Note:
When upgrading from 11.1.1.7.0, you may receive a ”File Not Found” error message regarding theaudit-store.xml file; this error message can be safely ignored as that file is provided once upgradeOpss is run.Restart the application server.
To upgrade a file-, LDAP-, or DB-based store, use the syntax below; note that the connection arguments are not required in case of a file-based store, are optional in case of an LDAP-based store, and are required in case of a DB-based store:
upgradeOpss(jpsConfig="<full path to the old version jps config file>",
jaznData="<full path to the new version OOTB JAZN data file>",
[auditStore="<full path to the OOTB audit-store.xml file>"],
[jdbcDriver="<jdbc driver>",
url="<jdbc-ldap url>",
user="<jdbc-ldap user>",
password="<jdbc-ldap password>"],
[upgradeJseStoreType="true" or "false"]
[transformData="true" or "false"])
The meaning of the arguments is as follows:
jpsConfig specifies the full path to the location of the 11.1.1.2.0, 11.1.1.3.0, 11.1.1.4.0, 11.1.1.5.0, 11.1.1.6.0, or 11.1.1.7.0 jps-config.xml domain configuration file, which the scripts backs up in the same directory as a file with the suffix .bak appended to the its name; required; typically located in the directory $DOMAIN_HOME/config/fmwconfig. The file jps-config-jse.xml is assumed to be located in the same directory.
jaznData specifies the full path to the location of the 11.1.1.7.0 out-of-the-box system-jazn-data.xml file; required; typically located in the directory ${common_components_home}/modules/oracle.jps_11.1.1/domain_config.
auditStore specifies the full path to the location of the 11.1.1.7.0 out-of-the-box audit-store.xml file; optional; if unspecified, defaults to the file audit_store.xml located in the directory specified for jaznData.
jdbcDriver specifies the JDBC driver to the store; required in case of DB-based store.
url specifies the JDBC URL or LDAP URL in the format driverType:host:port:sid; required in both DB- or LDAP-based store; if not passed, it is read from the configuration file.
user specifies the JDBC user name or LDAP bind name; optional in case of LDAP-based store; required in case of DB-based store; if not passed, it is read from the configuration file. In case of LDAP-based store, the user performing the upgrade must have read and write privileges to the schema, the root node, and all nodes under cn=OPSS,cn=OracleSchemaVersion; in case of a DB-based store, perform the upgrade as the OPSS DB schema user.
password specifies the password of the passed user; that is, the JDBC password, in case of a DB-based store, or the JDBC bind password, in case of a LDAP-based store; optional in case of LDAP-based store; required in case of DB-based store; if not passed, it is read from the configuration file.
upgradeJseStoreType applies only if the store specified in the file jps-config.xml is LDAP- or DB-based, and it specifies whether to change the store type configuration (in the file jps-config-jse.xml) from file-based to LDAP- or DB-based, to the type specified in the file jps-config.xml. Must be set to true.
transformData performs some upgrade to improve DB performance enhancement; optional; default value: true; it is not recommended to change the default value.
This section describes how to backup and recover a domain's OPSS security store. The procedure varies according to the type of OPSS store to process (DB-based or OID-based).
In addition to backing up the security store, note that the following security store configuration and data files must also be saved for a possible recovery (a star stands for all files in the directory):
{domain}/Config/config.xml
{domain}/Config/Fmwconfig/jps-config.xml
{domain}/Config/Fmwconfig/jps-config-jse.xml
{domain}/Config/Fmwconfig/cwallet.sso
{domain}/Config/Fmwconfig/keystores.cml
{domain}/Config/Fmwconfig/audit-store.xml
{domain}/Config/Fmwconfig/system-jazn-data.xml
{domain}/Config/Fmwconfig/ids-config.xml
{domain}/Config/Fmwconfig/mbeans/jps_mbeans.xml
{domain}/Config/Fmwconfig/bootstrap/cwallet.sso
The above files are typically backed up as part of an Oracle WebLogic Server domain backup. For details about an Oracle WebLogic domain backup, see the following topics in the Administering Oracle Fusion Middleware:
This section contains the following topics:
The procedure described in this section uses the Oracle Database client Recovery Manager (RMAN) that allows active database duplication, a tool that is typically also used to automate backup strategies and recoveries. For full details about RMAN, see the following topics in the Oracle Database Backup and Recovery User's Guide:
Getting Started with RMAN
Performing Complete Database Recovery
The following procedure describes how to backup a domain DB-based security store instance in host A to an instance in host B; it assumes that the security store in host A has a jdbc url set to proddb, and the goal is to get that same domain to work with a (cloned) DB-based store with jdbc url set to testdb (in host B).
Under the above assumptions, to backup a DB-based security store, proceed as follows:
Prepare the instance testdb in host B, as follows:
Create a pfile for the new instance: that is, create the file inittestdb.ora with a contents as illustrated be the following lines:
# db_name=testdb #
Add testdb to listener.ora, as illustrated in the following line:
SID_LIST_LISTENER = (SID_LIST=(SID_DESC=(SID_NAME=testdb)(GLOBAL_DBNAME=testdb)(ORACLE_HOME=/ade/b/3882746433/oracle))
Add testdb/proddb in tnsnames.ora, as illustrated in the following lines:
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))
testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))
Restart the listener, as illustrated in the following line:
lsnrctl stop, lsnrctl start
Start the new instance using the pfile in nomount mode, as illustrated in the following lines:
$ export ORACLE_SID=testdb
$ sqlplus / as sysdba
SYS@testdb SQL>startup nomount pfile=/scratch/rdbms/dbs/inittestdb.ora
Use RMAN to clone proddb to testdb, as follows:
Add add testdb/proddb in tnsnames.ora, as illustrated in the following lines:
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))
testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))
Make sure that instance proddb is using the spfile. If this is not yet the case, generate a binary spfile from the init file by login in as sysdba and running "create spfile from pfile". Then, restart the server.
Restart the listener, as illustrated in the following line:
lsnrctl stop, lsnrctl start
Decide how to generate the names for the duplicate database files; specifically, decide how to name the control files, the datafiles, the online redo log files, and the tempfiles.
For example, if in proddb, the files on host A are in the directory /oradata/proddb, and you want the them to be saved in /oradata/testdb on host B, then you would specify DB_FILE_NAME_CONVERT '/proddb',' /testdb', as in the sequence below.
Run RMAN to clone proddb to testdb as illustrated in the following lines:
$rman
RMAN> CONNECT TARGET SYS@proddb
RMAN> CONNECT AUXILIARY SYS@testdb
RMAN> DUPLICATE TARGET DATABASE TO testdb
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT '/proddb','/testdb'
SPFILE
PARAMETER_VALUE_CONVERT '/proddb','/testdb'
SET LOG_FILE_NAME_CONVERT '/proddb','/testdb';
Make sure that the RMAN sequence above completes successfully.
(Optional) Verify the backed up DB instance testdb works as expected, by switching your domain to use the just backed up database as the OPSS security store:
Stop the Oracle WebLogic Server
Change the jdbc url from proddb to testdb in the files {domain}/config/fmwconfig/jps-config.xml and {domain}/config/jdbc/*xml
Restart the Oracle WebLogic Server
Ensure that the domain security works as expected
To backup a source Oracle Internet Directory store to a destination Oracle Internet Directory store proceed as follows:
In the system where the source Oracle Internet Directory is located, produce an LDIF file by running ldifwrite as illustrated in the following line:
>ldifwrite connect="srcOidDbConnectStr" basedn="cn=jpsnode" ldiffile="srcOid.ldif"
This command writes all entries under the node cn=jpsnode, c=us to the file srcOid.ldif. Then move this file to the destination Oracle Internet Directory file system so it is available to the commands that follow.
In the destination Oracle Internet Directory system, ensure that the JPS schema has been seeded.
In the destination Oracle Internet Directory system, verify that there are no schema errors or bad entries by running bulkload as illustrated in the following line:
>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
If duplicated DNs (common entries between the source and the destination directories) are detected, review them to prevent unexpected results.
Load data into the destination Oracle Internet Directory, by running bulkload as illustrated in the following line:
>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
It is recommended that the OPSS security store be backed up periodically, according to a schedule appropriate to your enterprise. In addition, an unscheduled backup is recommended soon after the following events:
a new encryption key has been (automatically) generated for the domain
new policies have been created
new binding credentials are set