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 information center.
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.
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.
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.
org.eclipse.emf.ecore.EPackage.Registry.INSTANCE=com.ibm.ws.wim.util.VMMEMFGlobalDelegatorRegistryFor 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.
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.
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.
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.
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.
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.
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 information center.
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:
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 |
Domain level | domain_vmm_root/config | ||
Argus files | Global level | cell_vmm_root/config/authz | |
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 |
Virtual member manager data model extension files | Global level | cell_vmm_root/model | wimxmlextension.xml |
Domain level | domain_vmm_root/model | wimxmlextension.xml |
To configure virtual member manager in a multiple security domain, follow the steps described next.
$AdminTask configureAppWIMUserRegistry {–securityDomainName testDomain –realmName testRealm}
$AdminTask addFileRegistryAccount {-userId user_name -password my_password –securityDomainName testDomain}
$AdminConfig save