MemberRegistrationAttributes XML and DTD files
The MemberRegistrationAttributes.xml configuration file specifies attributes that can automatically be assigned to users and organizations during user and organization registration and some authentication scenarios. This file follows the format that is defined by the MemberRegistrationAttributes.dtd file.
Both the DTD and XML files are in the workspace_dir/WC/xml/member directory. This file might be overwritten when a store is published, however a backup copy is saved in the same directory.
This file is divided into four main sections:
- UserRoles
- Defines the roles that a user would automatically receive in an organization during registration.
- OrganizationRoles
- Defines the roles that an organization would automatically receive during registration.
- BusinessEntities
- Defines which organizations might automatically be defined as business entities when they are created. A business entity is an organization that can have business accounts.
- RegistrationParents
- Defines where to create new users or organizations for a particular registration type.
UserRoles
The UserRoles section contains User nodes. The role assignment algorithm iterates through the list of User nodes, and returns the first one that matches. This process is based on the following rules:
- registrationType
- The type of registration or authentication process. The valid values within the UserRoles section are:
- UserRegistration
- A user registers without specifying registrationType in the requestProperties of the command, for example, UserRegistrationAddCmd
- UserRegistrationToStoreGrandparentOrg
- A user registers by specifying registrationType=UserRegistrationToStoreGrandparentOrg in the requestProperties of the command, for example, UserRegistrationAddCmd. This allows the user to get a role at the store's grandparent organization.
- ResellerRegistration
- A user registers as part of ResellerRegistrationAddCmd
- BuyerRegistrationAdd
- A user registers as part of BuyerRegistrationCmd
- LDAPLogon
- A user authenticates using the Logon command when WebSphere Commerce is configured to authenticate against an LDAP server.
- SSO
- A user authenticates by using Single Sign-On
- memberAncestor
- The distinguished name (DN) of the organizational entity under which the new user is being created. The DN value in this file is case insensitive, but in the database, it must be in lowercase.
- storeAncestor
- The store to which the user is registering must be owned by an organization that is a descendant of the specified ancestor organization. The ancestor organization is identified by its distinguished name.
If all of the preceding criteria are satisfied by the current registration scenario, roles are automatically assigned to the user as specified in the role subelements. Each role element consists of the following items:
- name
- The name of the role to assign.
- roleContext
- Specifies for which organization the user's role might be assigned. It can have the following values
- userParent - The role is applied to the organization that is the user's immediate parent.
- storeOwner - The role is assigned to the organization that owns the store to which the user is registering.
- storeGrandparentOrg - The role is assigned to the parent organization of the organization that owns the store to which the user is registering.
- explicit - The role is assigned for the organization that is explicitly specified by the DN attribute.
- DN
- If roleContext = "explicit", then the DN represents the distinguished name of the organization where the user is assigned a role. If roleContext = "userParent" or "storeOwner", then the organization that is represented by the roleContext must be equal to, or a descendant of, the organization that is represented by the DN.
An example for UserRoles:
<UserRoles> <User registrationType="UserRegistration" memberAncestor="o=Default Organization,o=Root Organization" storeAncestor="o=Root Organization"> <Role name="Registered Customer"roleContext="storeOwner" DN="o=Reseller Organization,o=Root Organization"/> <Role name="Registered Customer" roleContext="storeOwner" DN="o=Seller Organization,o=Root Organization"/> </User> <User registrationType="UserRegistrationToStoreGrandparentOrg" memberAncestor="o=default organization,o=root organization" storeAncestor="o=root organization"> <Role name="Registered Customer" roleContext="storeGrandparentOrg"DN="o=root organization"/> </User> ... </UserRoles>
In this example, WebSphere Commerce scans down the list of User nodes until it finds one that matches. The matching is determined by the following rules:
- The registrationType (thus, the system is starting a standard UserRegistrationAdd command).
- The member's ancestor (in this case, the user's parent organization must be somewhere under the default organization).
- The store's ancestor (in this case, the system matches on any store, because the store ancestor is defined as the root organization, which is an ancestor of every store).
After WebSphere Commerce locates a matching role group, it attempts to assign the roles from that group. In this case, there are two roles that are defined in the group. Both are registered customer roles to be applied at the organization that owns the store to which the user is registering. The roles are qualified by the ancestor of the store (meaning that WebSphere Commerce only applies the role if the store is somewhere under the DN specified).
OrganizationRoles
The OrganizationRoles section is similar to the user roles section, except that this is where the roles for new organizations are defined. One difference pertains to the registrationType attribute of the Organization element. It is defined as follows:
- registrationType - The type of registration that this applies to. The valid values within the OrganizationRoles section are as follows:
- OrganizationRegistration - An organization registers without specifying registrationType in the requestProperties of the command, for example, OrgEntityAddCmd
- ResellerRegistration - An organization registers as part of ResellerRegistrationAddCmd
- BuyerRegistration - An organization registers as part of BuyerRegistrationAddCmd
Another difference is that the Role element only requires the name attribute to be defined.
An example for OrganizationRoles:
<OrganizationRoles> <Organization registrationType="ResellerRegistration" memberAncestor="o=Supplier Organization,o=RootOrganization" storeAncestor="o=Root Organization"> <Role name="Seller"/> <Role name="Category Manager"/> <Role name="Logistics Manager"/> <Role name="Marketing Manager"/> <Role name="Sales Manager"/> <Role name="Seller Administrator"/> <Role name="Registered Customer"/> </Organization> </OrganizationRoles>
This example shows that if an organization that matches on the outer criteria (registrationType, memberAncestor, and storeAncestor) is created, then all of the roles listed are created for that organization.
BusinessEntities
The BusinessEntities section follows the same structure as the OrganizationRoles section and is used to list the organizations that act as business entities in the system. Business entities are organizational entities that can have business accounts.
An example for BusinessEntities:
<BusinessEntities> <Organization registrationType="" memberAncestor="o=Supplier Organization,o=RootOrganization" storeAncestor="o=Root Organization"/> </BusinessEntities>
When creating an organization, the SetBusinessEntityCmd task command marks the organization as a business entity if it satisfies the criteria specified in the BusinessEntities section. The example specifies that any organization created under Supplier Organization is to be marked as a business entity.
Note: The BusinessEntities section does not define roles.
RegistrationParents
The last section is the RegistrationParents section. This is where WebSphere Commerce defines the parent organization for new users and organizations. Although many of the WebSphere Commerce commands still allow the programmatic assignment of parent, certain business models require that the parent be fixed. If so, WebSphere Commerce fixes the parents in this file.
An example for RegistrationParents:
<RegistrationParents> <Organization registrationType="ResellerRegistration" memberAncestor="o=Supplier Organization,o=RootOrganization" storeAncestor="ou=Supplier HubOrganization,o=Supply Chain Management Organization,o=Root Organization"/> </RegistrationParents>
Related concepts
Users
Member groups
Roles
Membership hierarchy
Member subsystem
Membership profile management
Range-based customer registration information
Member subsystem roles
Related tasks
Defining custom attributes for member URLs
Enable single sign-on