Multiple security domain support

In virtual member manager version 8.0, you can configure a separate instance of virtual member manager for each security domain in a multiple security domain environment.

When you create a security domain in WebSphere Application Server, you can configure the virtual member manager user registry at the domain level. In releases before version 8.0, you can have only one instance of virtual member manager and configure it only at the global (admin domain) level. For more information, read about Multiple security domains in the WebSphere Application Server documentation.

To support multiple instances of virtual member manager, the WebSphere security domain information is used to load the applicable configuration and data model schema. The new security domain is set up with the default virtual member manager configuration. The virtual member manager configuration is stored and managed independently for each domain and is not shared with the admin or global domain. Only users assigned to the administrator role in a particular domain can configure virtual member manager at that respective domain level.

Multiple security domain support for virtual member manager includes the aspects described next.

Schema extension

You can extend the globally-defined schema of the data model with domain-specific schema. Hence, in a multiple security domain environment, you can have a different profile data model for each domain. You can manage profile data without conflict or runtime issues in different security domains because separate instances of virtual member manager are created and domain-specific configuration and schema file paths are used during initialization.

Avoid trouble: Application domains that are set to use global schema share the same schema of the admin domain. Hence, if you extend the schema for an application in one domain, you must consider how that might affect applications of other domains as they are also bound by the same schema. For example, adding a mandatory property for one application might cause other applications to fail.

For more information, read about Schema loading process and schema extension in a multiple security domain environment and the setIdMgrUseGlobalSchemaForModel wsadmin command in the topic, IdMgrConfig command group for the AdminTask object.

If your application invokes virtual member manager APIs in local mode, you must set the following system property on the client JVM:

org.eclipse.emf.ecore.EPackage.Registry.INSTANCE=com.ibm.ws.wim.util.VMMEMFGlobalDelegatorRegistry

For more information, read the section, Getting the virtual member service and other common methods, in the topic Programming prerequisites.

For information about troubleshooting issues related to EMF, read about enabling trace for EMF classes in the topic, Logs and trace, and resolving Schema registry corruption or schema violation errors.

User registries

A domain-specific file registry is created for each security domain, if file repository is configured for that domain.

You can create the database, property extension, and entry mapping repositories in a specified name space to allow multiple such repositories within a single database instance. If no namespace is specified, the repository is set up in the default namespace, typically the namespace of the current database user.

Avoid trouble: Do not use the same name space for database, property extension, or entry mapping repositories across different domains, as it might result in inconsistent data.

For more information, read about Setting up an entry mapping repository, a property extension repository, or a custom registry database repository using wsadmin commands, IdMgrRepositoryConfig command group for the AdminTask object, and Manually setting up the property extension repository for federated repositories in the WebSphere Application Server information center.

Domain-specific configuration and user and group management

The wsadmin commands provide an optional securityDomainName parameter, which you can use when configuring virtual member manager and managing users and groups in a specific domain. If this parameter is not specified, the admin domain is used by default.

Deployment of virtual member manager through EJB

In an application development environment, you can call virtual member manager APIs through EJB for a specific domain. Virtual member manager provides SDO-based EJB APIs that you can use to manage virtual member manager entities. These EJB interfaces are implemented by a stateless session EJB that delegates the calls to the virtual member manager service provider.

If remote access is required for specific domains, you must deploy the same virtual member manager EJB implementation with different deployment descriptors for each virtual member manager domain-specific instance, as a user application. Follow the steps described in the topic, Installing virtual member manager.

Limitation: If a virtual member manager EJB is deployed on a managed node, it results in failure of configuration, schema, or file registry update operations.

Migration and compatibility with earlier versions

No updates are required to run your existing virtual member manager applications in a multiple security domain environment.

WebSphere Application Server supports upgrade from versions 6.1 and 7.0 to version 8.0, and virtual member manager supports the same. During upgrade, the existing configuration and data model extension is preserved. In a multiple security domain environment, configuration is supported for virtual member manager as the user registry for existing domains that were created in WebSphere Application Server version 7.0. During upgrade, new and updated schema and configuration files are copied to their respective locations.

Virtual member manager configuration files in a multiple security domain environment

When you create a security domain in WebSphere Application Server 8.0, all virtual member manager configuration files are created for that domain, regardless of whether virtual member manager is configured as the active user registry.

WebSphere Application Server provides an option to create a domain by copying a selected domain from a domain collection. Based on the options you specify while creating a domain, virtual member manager files are copied from the selected domain, the admin security domain, or default profile template location. This might also include copying the file repository if it exists in the source domain. For more information read about, Creating new multiple security domains, Configuring multiple security domains, and Configuring multiple security domains using scripting in the WebSphere Application Server documentation.

The domain-specific virtual member manager files are located under the app_server_root/profiles/$ProfileName/config/waspolicies/$PolicyName/securitydomains/$DomainName directory.

The files related to virtual member manager configuration and data model schema are listed in the following table.

The following directory conventions are used in the table:

app_server_root is the default installation directory for WebSphere Application Server
profile_root is app_server_root/profiles/$ProfileName
cell_vmm_root is profile_root/config/cells/$CellName/wim
domain_vmm_root is profile_root/config/waspolicies/$PolicyName/securitydomains/$DomainName/wim

Table 1. Virtual member manager configuration files
Description	Level	Directory	File name
Virtual member manager configuration schema file	One global copy for the whole system	`app_server_root/etc/wim/schema/config`	wimconfig.xsd
Virtual member manager configuration file	Global level	`cell_vmm_root/config`	wimconfig.xml
Virtual member manager configuration file	Domain level	`domain_vmm_root/config`	wimconfig.xml
Argus files	Global level	`cell_vmm_root/config/authz`
Argus files	Domain level	`domain_vmm_root/config/authz`
File registry that contains users and groups for the out-of-the-box file repository	Global level	`profile_root/config/cells/$CellName`	fileRegistry.xml Note: The fileRegistry.xml file is copied for a new domain only if the source domain contains this file.
	Domain level	`profile_root/config/waspolicies/$PolicyName/securitydomains/$DomainName`
Virtual member manager out-of-the-box data model schema files.	One global copy for the whole system	`app_server_root/etc/wim/schema/model` Note: The same files are also copied to `cell_vmm_root/model` as they are required for migration purposes.	wimdatagraph.xsd wimdomain.xsd wimschema.xsd xml.xsd
Virtual member manager data model extension files	Global level	`cell_vmm_root/model`	wimxmlextension.xml custom xsd
Virtual member manager data model extension files	Domain level	`domain_vmm_root/model`	wimxmlextension.xml custom xsd

Configuring virtual member manager in a multiple security domain

To configure virtual member manager in a multiple security domain, follow the steps described next.

Create a security domain using the steps described in the topic, Creating new multiple security domains or Copying multiple security domains.
Use the configureAdminWIMUserRegistry, configureAppWIMUserRegistry, or unconfigureUserRegistry commands to configure virtual member manager as the user registry for the domain. While configuring, you can also specify a new realm name for the domain. This realm name is set in the domain-specific wimconfig.xml and is unique across a virtual member manager instance.
Example:
```
$AdminTask configureAppWIMUserRegistry {-securityDomainName testDomain -realmName testRealm}
```
If the file repository is configured and the fileRegistry.xml file does not exist, create the fileRegistry.xml file, with a user and specify the domain name using the securityDomainName parameter. If the fileRegistry.xml file does exist, this step just adds the user to registry.
```
$AdminTask addFileRegistryAccount {-userId user_name -password my_password -securityDomainName testDomain}
```
Save your configuration changes.
```
$AdminConfig save
```