The following topics provide guidance for maintaining the Mobile Security Access Server (MSAS) repository:
Understanding the Different Mechanisms for Exporting and Importing Application Metadata
Exporting and Importing MSAS Application Metadata Using WLST
Migrating MSAS Application Metadata Between Application Environments
Mobile Security Access Server uses an MDS repository to store MSAS application metadata, including policies, assertion templates, schemas, and so on.
For policies stored within the MSAS repository, each policy has a URI that is evaluated to form a path in which to locate a particular XML document containing the policy. MSAS does not use the MDS customization feature, so all policies are stored as complete documents. Although MDS supports the ability to store multiple versions of a given document, MSAS only accesses the latest version during policy enforcement.
You can use the MSAS console pages in the OAM console or WebLogic Scripting Tool (WLST) commands to export and import application metadata from and to the MSAS repository.
You can use the MSAS console to selectively export and import one policy at a time. The procedures for exporting and importing policies using the MSAS console are described in the following sections:
You can export and import MSAS applications using the MSAS console as described in the following sections:
You can also use the WLST commands exportMSASAppMetadata and importMSASAppMetadata to facilitate exporting and importing MSAS application metadata directly from and to the MSAS repository. For details about using these commands, see "Exporting and Importing MSAS Application Metadata Using WLST".
You can export and import MSAS applications to and from the MSAS repository using the exportMSASAppMetadata and importMSASAppMetadata WLST commands as described in the following sections:
For more information about the WLST commands and their arguments, see "Repository Commands" in WebLogic Scripting Tool Command Reference for Identity and Access Management.
To export MSAS applications from the MSAS repository to a supported ZIP archive file, use the exportMSASAppMetadata command.
exportMSASAppMetadata(archiveFileName,[instanceName=None],[applicationName=None],[includeShared='false'])
Note the following:
If the archive specified using the archiveFileName argument already exists, you can choose to merge the content into the existing archive, overwrite the existing archive, or cancel the operation. If you choose the overwrite option, the original archive is backed up and a message describes the location of the backup archive.
For example, the following command exports the metadata for all the MSAS applications across all MSAS instances into an archive named MSASApplications.zip.
wls:/mydomain/serverConfig> exportMSASAppMetadata('/tmp/MSASApplications.zip')
Use the optional instanceName argument to specify the name of the MSAS instance from which you want to export the metadata of one or more MSAS applications. The MSAS instance name is case-sensitive.
For example, the following command exports the metadata for all applications across all MSAS instances that begin with MSAS into the MSASApplications.zip archive.
wls:/mydomain/serverConfig> exportMSASAppMetadata('/tmp/MSASApplications.zip','MSAS%')
Use the optional applicationName argument to specify the name of the MSAS applications for which you want to export the metadata. The application name is not case-sensitive.
For example, the following command exports the metadata for all applications that begin with virtual across all MSAS instances into the MSASApplications.zip archive.
wls:/mydomain/serverConfig> exportMSASAppMetadata('/tmp/MSASApplications.zip','',['virtual%'])
If no MSAS instance name is specified, but a valid MSAS application name is specified, then the metadata for all MSAS instances containing this MSAS application is exported. When neither the MSAS instance nor MSAS application name is specified, then the metadata for all the MSAS applications across all MSAS instances is exported.
For example, the following command exports the metadata for all applications that begin with virtual across all MSAS instances into the MSASApplications.zip archive.
wls:/mydomain/serverConfig> exportMSASAppMetadata('/tmp/MSASApplications.zip','',['virtual%'])
Use the includeShared argument to specify whether the shared documents (access policies referenced by MSAS applications) should be included in the export.
For example, the following command exports the metadata for all applications that begin with virtual, including the application's shared resources, on the MSAS-123456 instance into the MSASApplications.zip archive.
wls:/mydomain/serverConfig> exportMSASAppMetadata('/tmp/MSASApplications.zip','MSAS-1234561',['virtual%'],true)
To import MSAS application metadata from the MSAS repository to a supported ZIP archive file, use the importMSASAppMetadata command.
importMSASAppMetadata(archiveFileName,[instanceName=None],[applicationName=None],[includeShared='false'])
Note the following:
Use the optional mapFileName argument to specify the location of an input map file that describes how to map physical information from the source environment to the target environment.
For example, the following command imports application metadata from the specified MSASartifacts.zip archive according to the MSASmapfile.txt map file.
wls:/mydomain/serverConfig> importMSASAppMetadata('/tmp/MSASartifacts.zip','/tmp/MSASmapfile.txt')
You can generate a new map file by setting the generateMapFlag argument to true. If the map file already exists, it will be overwritten; however, no MSAS application metadata is modified when this argument is set to true, only a map file is generated. If you specify a map file without setting the generateMapFlag, or setting it to false, and the map file does not exist, the operation fails and an error is displayed.
For example, the following command generates a map file named myMapfile.txt. If the specified map file already exists, it will be overwritten.
wls:/mydomain/serverConfig> importMSASAppMetadata('/tmp/MSASartifacts.zip','/tmp/myMapfile.txt', true)
MSAS application metadata can be migrated through the different stages of the application development and deployment cycles, such as from development to production. Oracle recommends using the exportMSASAppMetadata and importMSASAppMetadata commands for policy migration, as described in "Exporting and Importing MSAS Application Metadata Using WLST".
To replace the MSAS application target host and port values, use the migrateMSASAppHostports command.
migrateMSASAppHostports(instanceName,applicationName,mapFileName,[generateMapFlag='false'])
Note the following:
Use the instanceName argument to specify the name of the MSAS instance. In this case, a wildcard character is not accepted. The MSAS instance name is case-sensitive.
Use the applicationName argument to specify the MSAS application whose referenced back-end service host:port information needs to be migrated or replaced. A wildcard '%' is allowed. If this argument is set to None, empty '', or '%', then all applications in the specified MSAS instance are searched. The application name is not case-sensitive.
Use the mapFileName argument to specify the location of a input map file that describes how to map source MSAS host:port values to a target host:port.
For example, the following command migrates the host:port values for all applications that begin with myApp on the MSAS-1234 instance according to the myMapfile.txt map file.
wls:/mydomain/serverConfig> migrateMSASAppHostports('MSAS-1234', 'myApp%', '/tmp/myMapfile.txt')
You can generate a new map file by setting the generateMapFlag argument to true. If the map file already exists, it will be overwritten; however, no migration takes place in the MSAS repository. If you specify a map file without setting the generateMapFlag, or setting it to false, and the map file does not exist, the operation fails and an error is displayed.
For example, the following command collects all host:port values for the myApp application on an instance named MSAS-1234, and puts it into a newly-generated map file named generatedMapfile.txt. (Note that if a specified map file already exists, it will be overwritten).
wls:/mydomain/serverConfig> migrateMSASAppHostports ('MSAS-1234','myApp','/tmp/generatedMapfile.txt',true)