Store-level Registration in WebSphere Commerce 5.5

This article introduces the concept of store-level registration in WebSphere Commerce 5.5, discusses the Hosting business model, and gives a high-level description of the implementation that includes commands and runtime infrastructure.

Share:

Darshanand Khusial (dkhusial@ca.ibm.com), Security Architect, IBM WebSphere Commerce Toronto Lab, Canada

Darshanand Khusial is a WebSphere Commerce Security Architect at the IBM Toronto Lab, Ontario, Canada. He works on security and member components of WebSphere Commerce. You can reach him at dkhusial@ca.ibm.com .



Ross McKegney (rmckegne@ca.ibm.com), Software Engineer, IBM WebSphere Commerce Toronto Lab, Canada

Ross McKegney is a Software Engineer at the IBM Toronto Lab, Ontario, Canada. He works on member and approvals components of WebSphere Commerce. You can reach him at rmckegne@ca.ibm.com.



22 July 2003

© Copyright International Business Machines Corporation 2003. All rights reserved.

Introduction

Previous versions of WebSphere® Commerce supported user registration at the site level that allowed customers to have the same level of access for all stores operating within the site. This works well for simple business models, but proves limiting to customers wishing to exploit the full power of the product. With version 5.5, the security model has been enhanced to support not only site level registration, but also store level registration. This allows you to assign roles to shoppers at the site level and for individual stores. This article introduces the concept of store level registration, discusses the Hosting business model, and gives a high-level description of the implementation that includes commands and runtime infrastructure.


Site and Store Level Registration

This section briefly describes the limitations of WebSphere Commerce 5.4, which used a user attribute to provide site level registration. This scheme has been extended in WebSphere Commerce 5.5 to also support store level registration.

Site Level Registration in WebSphere Commerce 5.4

In WebSphere Commerce 5.4, when a customer self-registers to a store, they are implicitly registered to all the stores of the site. This is termed site level registration.

To indicate that a user is registered in WebSphere Commerce, the RegisterType flag of the USERS table is populated with the R flag. This RegisterType flag is not associated with any store. When a check is made in a store as to whether a user is registered or not, the RegisterType flag is inspected. If the user had already registered in another store, this flag is set so that the current store treats the user as registered. During the self-registration process, the commands do not assign the users any roles in the system, thus the customers for all the stores have the same authorization throughout the site.

Limitations of the WebSphere Commerce 5.4 Model

With sites that host a single store or a small set of related stores, the 5.4 implementation for identifying registered customer suffices. However, WebSphere Commerce 5.4 allows multiple stores, each with significantly different capabilities. Consider a site that sells shoes, but targets two different sets of demographics - children and adults. You can implement this as two different stores, one with an array of bright colors and featuring famous cartoons characters to entice the children, and the other with a sleek layout and great deals to lure the adults. While customers can see two different stores, in WebSphere Commerce 5.4 the merchant is limited to managing the customers for both stores in an identical manner because the registration process does not distinguish between the users of different stores. This poses a number of problems for the merchant:

  • You cannot setup promotional email campaigns to target shoppers who have registered in a given store. An example is a ten percent discount to all shoppers who registered to the adult store.
  • You cannot collect analytical information on a user and store basis, such as how many customers have registered in the children store versus the adult store.
  • Administrators cannot segregate on a user and store basis. That is, you want a customer service representative to manage users of one store, but not that of another store.
  • You cannot treat a registered user in one store as a guest in another store. That is, you want the customer registered in the children store to be treated as a guest in the adult store.

Store Level Registration in WebSphere Commerce 5.5

Although you can work around the limitations above by creating separate WebSphere Commerce instances, this is not always a viable alternative. Each instance is like having a mutually exclusive install of WebSphere Commerce on the same machine, with its own database, IP address, and other system resources. This is an expensive solution from the machine resources standpoint and an administration perspective.

A better solution is to use the existing infrastructure of access control roles in WebSphere Commerce. Instead of setting an attribute in the USERS table, assign the customer a unique role in an organizational ancestral branch that owns the store. Assigning customers roles instead of giving them special attributes is a better authorization model because all users in the system are only given authority in the system based on a single concept.

WebSphere Commerce 5.5 introduced the "Registered Customer" role to indicate that a user is registered to a store. Because roles are played in an organization (not a store), a user is registered to a store by assigning the user the Registered Customer role in the organization that owns the store, or an ancestral organization of the store's organization. This works because roles are inherited.

Figure 1 illustrates the Registered Customer role. Organizations are depicted as ovals, stores as pyramids, and users as boxes. When a shopper registers to a store, like in WebSphere Commerce 5.4, the user represents this shopper under the Default Organization. However, the self-registration command performs on extra step, which is to assign the user a role in the store's organization or one of its ancestors. When a shopper of the Children Shoe Store self-registers, he or she is given the Registered Customer role in the Children Shoes organization. Or, instead of giving the shopper the Registered Customer role in the Children Shoes organization, he or she is given the role in the Shoe Seller organization. The second option treats the shopper as a registered customer both in the Children Shoe Store and Adult Shoe Store by virtue of role inheritance.

The above scheme resolves the issues listed with the WebSphere Commerce 5.4 registration process.

  • To target promotional campaigns for registered customers of the Adult Shoe Store, determine all the registered customers of the Adult Shoe Store by checking for users who play the Registered Customer role in either the "Adult Shoes", "Shoe Seller" or "Root Organization". This user-role-organization relationship is stored in the MBRROLE table. After determining all the registered customers of the Adult Shoe Store, you can obtain their email addresses from the self-address stored in the ADDRESS table to send out the campaign notices.
  • To determine analytical information, such as the number of users registered to the Children Store, you can count all the users who play the Registered Customer role in either the "Children Shoes", "Shoe Seller" or "Root Organization".
  • To segregate customer service administrators, such that an administrator for the Children Store can only manage users in the Children Store, you can give the administrator the Customer Service Representative role in the "Children Shoes" organization. You can then construct access control policies that limit this administrator to only managing users who play the Registered Customer role in his organization, the Children Shoes organization.
  • You can treat a registered customer as a guest shopper in another store. If the user plays the Registered Customer role in the Children Shoe Store organizational branch, but not in the Adult Shoe Store organizational branch, then when the shopper visits the Children Shoe Store, the access control system recognizes the shopper as a registered customer. When the shopper visits the Adult Shoe Store, the access control system recognizes the shopper as a registered customer.
Figure 1. A sample scenario shopper registration
A sample scenario shopper registration

Commands and Runtime Infrastructure

Store level registration was implemented by leveraging infrastructure developed for previous versions of WebSphere Commerce, with a few enhancements. The registration process has been extended to support role assignment based on policies defined in an XML-based configuration file. The session management has been extended to allow for the same user to store and dynamically migrate between identities defined for different stores.

User Registration

For the most part, the member registration commands work the way they did with WebSphere Commerce 5.4. You can still perform authentication to a database user repository or a Lightweight Directory Access Protocol (LDAP) server, and you can still migrate between a guest user and a registered user (either through logon or registration). What has changed is an additional step, whereby roles are assigned to a user based on the policies specified in a registry. This in turn is populated by the customer defined in MemberRegistrationAttributes.xml. Based on the type of registration being performed, the organization to which the shopper is registering, and the store from which the shopper is registering, the system determines which roles to assign based on the policies specified in this XML file.

Example 1: Registering the shopper to a single store: Consider the user registration for the Children Shoes Store described above. The UserRegistrationAddCmd controller command creates the user with all of the associated profile information and security credentials. It then assigns roles based on what was defined in MemberRegistrationAttributes.xml. Assuming that users get the registered customer role only in the store to which they are registering, this XML file looks like the following:

<MemberAttributes> 
 <UserRoles> 
  <User registrationType="UserRegistration"  
     memberAncestor="o=Default Organization,o=Root Organization"  
     storeAncestor="o=Shoe Seller,o=Root Organization "> 
   <Role name="Registered Customer"  
      roleContext="storeOwner"  
      DN="o=Shoe Seller,o=Root Organization">  
   <Roles/>  
  </User> 
 . . .  
 <UserRoles> 
 . . . 
</MemberAttributes>

Assuming that the new user was created under the default organization (as depicted in the figure above), the role assignment algorithm traverses up the organization tree and attempts to assign roles for each ancestor. This ancestor list includes the default organization and the root organization. For each ancestor, you look for matches in the XML file that have this organization as the memberAncestor attribute, the registrationType attribute specified, and where the store is registered to as a descendant of the storeAncestor attribute. When a match is found, WebSphere Commerce attempts to apply all of the roles defined.

In the example given, the user is registering to the Default Organization using registrationType="UserRegistration" for the store "Children Shoes". This is is under the organization of ou=Children Shoes,o=Shoe Seller,o=Root Organization. The XML fragment shown above illustrates a UserRoles node that matches based on these criteria, and contains a single role.

This role entry specifies the name of the role, the organization to apply it to, and the conditions under which the role should be applied. The first step in trying to apply the role is to resolve the organization. You can use the roleContext, which can take three values: storeOwner, userParent, or explicit. The example specifies storeOwner, which means applying the role to the organization that owns the store to which the user is registering. The other options are userParent, which means the direct parent organization under which the user is created, or explicit, which means to take the DN specified.

The last field in the role description is the DN. In the case of explicit role assignment, you can automatically apply the role to this DN. In the case of the storeOwner or userParent roleContext, apply the role only if the resolved is a descendant of this DN. For example, the resolved DN is the owner of the store or the user's direct parent.

In the example, the role section declares that you assign the role of RegisteredCustomer for this user in the organization that owns the store to which the user is registering, if that organization is a descendant of the Shoe Seller organization. Because the user is registering to the Children Shoes Store, which is under the Shoe Seller organization, the role is for the ou=Children Shoes, o=Shoe Seller, o=Root Organization because this is the store's parent organization.

Notice that this policy also works for users registering to the Adult Shoes Store. The role is applied to the ou=Adult Shoes, o=Shoe Seller, o=Root Organization. In fact, any store below the Shoe Seller organization inherits these policies.

Although you can configure roles to be assigned automatically on registration using the MemberRegistrationAttributes.xml file, the administrator can manually assign them using the Organization Administration Console.

Example 2: Registering the customer to all stores under a given organization: As another example, let's assume that you want shoppers who register to either Adult Shoes or Children Shoes Stores to be registered in both stores. You can implement this by assigning the Registered Customer role at the shoe seller organization because this organization is an ancestor of both stores. The MemberRegistrationAttributes.xml file looks like the following:

<MemberAttributes> 
 <UserRoles> 
  &tl;User registrationType="UserRegistration"  
     memberAncestor="o=Default Organization,o=Root Organization"  
     storeAncestor="o=Shoe Seller,o=Root Organization"> 
   <Role name="Registered Customer"  
      roleContext="explicit"  
      DN="o=Shoe Seller,o=Root Organization">  
   <Roles/>  
  </User> 
 . . .  
 <UserRoles> 
 . . . 
</MemberAttributes>

Given the same scenario as above, let's assign the roles listed under the User node given in this extract from the MemberRegistrationAttributes.xml file. This time, instead of assigning the role for the organization that owns the store, assign it explicitly for the shoe seller organization. The result is that the user is registered to any store under this organization.

You can also use MemberRegistrationAttributes.xml to define roles for new organizations, and for other types of registration beyond simple user registration (for example, to register a new buyer administrator). For more details, see the WebSphere Commerce 5.5 online help.

Roles and Access Control

The access control model of a WebSphere Commerce application has three primary concepts: users, actions, and resources. Users are the people that use the system. Resources are the entities that are maintained in or by the application. Actions are the activities that users can perform on the resources. Access control is the component of the e-commerce application that determines whether a given user can perform a given action on a given resource.

The WebSphere Commerce access control framework uses access control policies to determine if a given user is allowed to perform a given action on a given resource. WebSphere Commerce access control policies are 4-tuples with the following form:

AccessControlPolicy [UserGroup, ActionGroup, ResourceGroup, Relationship]

The elements in the 4-tuples access control policy specify that a user belonging to a specific user group is allowed to perform actions in the specified action group on resources belonging to the specified resource group, as long as the user satisfies the conditions specified in the relationship or relationship group.

Most conditions to include a user in a user group are based upon the user fulfilling a particular role. For example, there is an access control policy that allows all users that fulfill the Customer Service Representative role to perform customer management operations. Any user that has been assigned the Customer Service Manager role in the MBRROLE table is then implicitly included in the user group.

You can design access control policies to grant authority to a user based on their role in a particular organization. With the introduction of the Registered Customer role, you can now control on a per store basis what operations a registered customer can perform. For example, you can implement policies that dictate that guest and registered users are able to browse and buy from the Children Store, or that guest shoppers can browse, but only registered users can buy from the Adult Shoe Store.

You can design policies to respect roles on the store's ancestral organizational branch. If you are accessing a resource in the Adult Shoe Store and the policy for that resource dictates that the user must have the Registered Customer role, you can design the policy to respect any Registered Customer role on the organization ancestral branch. If the user has the Registered Customer role only in the Shoe Seller organization, then the access control policy allows the user to browse and buy from the Adult Shoe Store.

Session Management

Now that roles have being created automatically as part of the registration process with an access control framework that checks roles as the user interacts with the system, the last piece you need is allowing a customer to maintain different identities for each of the autonomous stores in the site. In WebSphere Commerce 5.4, the same user can seamlessly navigate between stores on the same site, and keep their same profile. Now let's suspend the profile for the current store and activate the profile for the new store.

This concept is further elaborated by revisiting the two configurations discussed above:

  • The first configuration is the registration assigned the role of Registered Customer for a single store
  • The second configuration assigns the role of Registered Customer higher in the tree, effectively giving the shopper the role in both stores.

Example Configuration 1: Registered customer role assigned for a single store: In example 1 above, the registered customer role is applied to the organization owning the store, which effectively assigns the role only for a single store (for example, for the Adult Shoes or Children Shoes). This is an interesting scenario from a session management perspective.

A customer who is registered in one store navigates to another needs to switch his or her identity. When the customer navigates back to the store to which they are registered, change the identity back. As mentioned above, this is handled by keeping a list of identities in the WebSphere Commerce cookie, then traversing the list whenever you change stores until you find an identity with the required role. If no identity is found in the list (as would be the case when visiting a site for the first time within given a session), then either display the logon page or make the shopper a generic or guest user. A typical scenario given this configuration looks like the following:

Figure 2. Registered customer role assigned for a single store
Registered customer role assigned for a single store
  1. This is the initial state. The shopper navigates to the Adult Shoes store (storeId=1) and browses as a generic shopper (userid = -1002).
  2. The user registers (assigned unique userId=2030) and adds an item to the shopping cart with itemId=10003.
  3. The shopper navigates to the Children Shoes Store. Because the current active identity does not have a role in the store, you traverse the list of identities. You do not find an identity with the required role, so the active identity is set to the generic user (userId=-1002). Notice that the shopping cart is now empty.
  4. The shopper registers to the Children Shoes Store, and is assigned a unique userId=2057. Note that this identity is completely distinct from the one created at the Adult Shoes Store.
  5. The shopper navigates back to the Children Shoes Store. The current active user identity does not have a registered customer role in this store, so again traverse the list in the cookie until you come to the user identity with userId=2030. This has the registered customer role in this store, so you can set it as the active userId. Notice that the shopping cart that was created earlier in the scenario is now accessible again.

This scenario works with the shopper in Adult Shoes as a guest rather than registered because the cookie also stores the association between userId and storeId. When searching for an identity to use, you first look through the list for a match on the storeId (which finds a guest shopper if one had been created in the store). If a match is not found, search again looking for a user with the Registered Customer role in the store. If this is unsuccessful, then set the active identity to be the generic user.

Example Configuration 2: Registered customer role assigned to both stores: With example 2 above, when a shopper registers to either store, you create the registered customer role at the Shoe Seller organization. This effectively assigns the role for both stores because this organization is an ancestor to both of them.

Figure 3. Registered customer role assigned to both stores
Registered customer role assigned to both stores
  1. This is the initial state. The shopper navigates to the Adult Shoes store (storeId=1), and browses as a generic shopper (userId = -1002).
  2. The user registers (assigned unique userId=2030) and adds an item to the shopping cart with itemId=10003.
  3. The shopper navigates to the Children Shoes Store. Because the current active identity has the Registered Customer role in the Children Shoes Store, continue to use the same identity. Notice that the shopping cart still contains the item that was added in the Adult Shoes Store.
  4. The shopper navigates back to the Adult Shoes Store. The current active user identity has the registered customer role in this store, so continue to use it.

The fundamental difference between these two scenarios is that, because you assign roles in both stores to registered customers, these customers can freely navigate between the stores reusing the same profile and shopping cart between them. The customer can create orders containing items from both stores.


Hosting Business Model

WebSphere Commerce 5.5 introduces the concept of business models. Unlike WebSphere Commerce 5.4 where individual stores are shipped as samples, a business model sample is more than just a store. A business model sample consists of organizations, access control policies, and stores. A business model illustrates how a certain business scenario is laid out from a WebSphere Commerce architecture standpoint.

The store level registration model becomes even more important as it evolves to support more complex business models. The example is the Hosting model that is shipped as a sample with 5.5. In this scenario, an Internet Service provider may host the site. The stores on the site are owned by individual sellers who pay a fee to have their store hosted. The hosted stores are intended for the general public.

Model Topology

Figure 4 shows the organizational and store artifacts in the Hosting business model sample. The transparent artifacts are created during WebSphere Commerce instance creation and the publishing of the Hosting store archive file. The shaded artifacts are dynamically created when the site is live. Once the site is live, resellers can come to the site to setup their stores. Here is the typical sequence of events:

  1. Customer creates a new organization under which the store is to be created, and a user entity to represent the customer in the system.
  2. Site administrator approves the new organization and the new user, who will be the administrator for the organization.
  3. Newly created organization administrator logs on to the site, configures the store, and opens the store.
  4. Customers shop in the store.
Figure 4. Store and organizational layout of the Hosted Reseller sample
Store and organizational layout of the Hosted Reseller sample

A new seller proceeds to the Hosting Hub store to fill out an online form requesting to setup his or her shop on the site. Upon submission of the form, the ResellerRegistrationAdd command is called that creates a Seller Organization, example Seller A, with a user, example A's admin, that has the Seller Administrator role in addition to other roles. The roles assigned to the Seller A Organization and to the new user are defined in the MemberRegistrationAttributes.xml file. The smoothly shaded objects indicate what assets are created in the system during this stage.

Organization A's admin cannot logon to the system until he or she is approved by a site administrator. Once approved, the administrator can proceed to create the hosted store, for example the B2C Store A, using the Store Creation Wizard. The administrator does not create the entire store from scratch because the Store Creation Wizard sets up a store relationship from the store to the Hosted Asset Store to get most of the artifacts required to run this store. He or she can then use the Organization Administrator Console to create additional administrators in the Seller Organization that have specialized roles, such as a customer service representative. The cross-hatched shaded objects indicate the assets that are created at this stage.

After the store is live, customers from the general public can shop and register at this store. The customers fills in the user registration form, which calls the UserRegistrationAdd command to create the user under the Default Organization. By default, MemberRegistrationAttributes.xml is setup to give the customers the Registered Customer Role only in the store's immediate organization, for example, B2C Org. The fine-grained shaded objects indicate the assets that are created at this stage.

By using the store level registration feature in this Hosting business model, you ensure that each seller maintains autonomy over their customers. This configuration allows each seller to:

  • Setup new administrators to manage their own customers.
  • Setup email campaigns for their registered users.
  • Mine analytical information about their registered users
  • Have a user being treated as a new user in the store, even if the user had registered in another reseller store.

Other Business Models Supported in WebSphere Commerce 5.5

WebSphere Commerce 5.5 has four other sample business models: Consumer Direct, B2B Direct, Demand Chain, and Supply Chain.

  • Consumer Direct sample illustrates the scenario where a merchant sells directly to the general public.
  • B2B Direct sample demonstrates the model where businesses have a direct sales relationship between each other.
  • Demand Chain sample illustrates one flavor of a value chain. In this sample, a channel hub acts as the marketplace where consumer direct merchants buy products from distributors to resell to the general public. The consumer direct stores and distributors plus their relationships are dynamically created in this model.
  • Supply Chain sample illustrates another flavor of a value chain. In this sample, a supplier hub acts as the marketplace bringing together private suppliers and their buyers. The supplier stores and buyers plus their relationships are dynamically created in this model.

For more details on these models, see WebSphere Commerce 5.5 Sample Store Guide.


Conclusion

This article describes how to achieve both store level and site level registration in WebSphere Commerce 5.5. Using examples to illustrate business scenarios, it provides reasons why you need store level registration. It also describes the infrastructure changes to enable store level registration, and how to use this store level registration in the new WebSphere Commerce 5.5 Hosting business model sample.


Acknowledgements

We would like to thank Mark Hubbard and Anthony Tjong for their comments and suggestions in preparing this article.

Top of page

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=13704
ArticleTitle=Store-level Registration in WebSphere Commerce 5.5
publish-date=07222003