Express (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select a registry or repository > Manage realms in a federated repository > Virtual member manager > Component overview


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 WAS, 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.


Schema extension

We 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. We 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, 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 the application invokes virtual member manager APIs in local mode, 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 Program 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.

We 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 Set 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 set up the property extension repository for federated repositories in the WAS 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, 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, Install 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.

WAS 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 WAS v7. 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 WAS 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, Create new multiple security domains, Configure multiple security domains, and Configure multiple security domains using scripting in the WAS information center.

The domain-specific virtual member manager files are located under the WAS_HOME/profiles/profile_name/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:

Virtual member manager configuration files

Description Level Directory File name
Virtual member manager configuration schema file One global copy for the whole system WAS_HOME/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

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 WAS_HOME/etc/wim/schema/model

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
Domain level domain_vmm_root/model wimxmlextension.xml
custom xsd


Configure virtual member manager in a multiple security domain

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

  1. Create a security domain using the steps described in the topic, Create new multiple security domains or Copy multiple security domains.

  2. 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}

  3. 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}

  4. Save the configuration changes. 
    $AdminConfig save

Parent topic: Component overview


+

Search Tips   |   Advanced Search