Solution Pattern

Registration

Furnishes an interface and workflow for establishing a user’s credentials and personal information with a system for unique and secure access.

[image]

Background

In order for users to interact with a system they must register with the system or be registered by a qualified individual such as an administrator. The resulting successful data submission uses the User (pg #) and Fundamental Identity (pg #) patterns to store the corresponding User and Person domain objects.

You will also need to validate a user following initially submitting their registration data, which allows you to have a higher degree of certainty that the user is who they claim to be.

Value and Benefits

This is the means of registering users, which is key to any business organization that wants to secure access to system resources only to those who have provided sufficient qualifying information about themselves.

This pattern is especially valuable if you provide a self-service (cusumer-facing) user interface. This will save your organization much time and effort in establishing the users of your system. If your administrators must perform all of the registration in behalf of your users, they may be heavily taxed by the ongoing work. This will especially be the case if you have many users. Bypass such frustration by putting this pattern to work.

Putting It to Work

If you are providing a web user interface such as the one I provide in the reference implementation, you need to make access to the registration form readily available. Generally page designers like to place a link right next to the sign on form as a prompt to register if it has not yet been done. That usually suffices to make registration stand out.

The registration form should provide all the basic input fields for both user and person information. Some systems want person data and user data to be entered separately, since a single person could have more than one user identification. If this is the case then you will need to allow the user to identify themselves with an existing person entity, perhaps by selecting themselves from among a list of registered persons. For self-service public sites, however, this method is fraught with error and may invite fraudulent activity. For self-service registration make the individual enter both user and person data together and save them as a unique data composition.

If your system allows or requires certain users to provide more than one contact entry for each of the common types (email address, phone number, and postal address), then you will need to provide an interface for adding multiple such entries. You will also need a way for the user to select, for example, which of their contact information entries of a specific type is the primary one among a list. You may also optionally allow the user to specify a description for each piece of contact data, which may also be canned and provided by your application. Using the phone number for example, you would allow the user to distinguish the home phone number from their office/work phone and their mobile/cell phone.

Once the user and person information have been composed and saved on the User (page #) and Fundamental Identity (page #) technology platform(s), you may choose to send the user an email message allowing them to confirm their registration. If you do so you should refuse the user access to your system via sign on until after they have confirmed. Generally the confirmation process sends an email to the newly registered user, followed by the user clicking on a link that is embedded in the email. This in turn causes the system to complete the registration process when the HTTP POST of the confirmation occurs at the business site. All users who fail to confirm their registration are considered stale after some predefined period of time. Their incomplete registration information is swept from the system once it reaches the timeout threshold.

Assuming that the user does confirm their registration, they are set as “members” of the system/application under their appropriate category (e.g. customer, employee, partner, etc.) and their registration completes successfully. This requires the use of the Identity Grouping (page #) pattern.

Next I present the strategies for the Registration pattern. All strategies are backed by standard architecture and design patterns outlined in respective works as noted throughout this and related solution patterns [PofEAA] [Core J2EE] [GoF]. The following diagram shows some detail on the components used by our reference implementation, and thereby provides an indication of the enterprise architecture patterns in use. Note, however, that some details is omitted, and especially from architectural aspects:

[image]

Helpful Links

When potential users of the system are presented with a sign on user interface, they will be unable to provide credentials since they have not registered. For such persons it is helpful to provide a prominent link (or a sub-dialog, for non-web GUIs) through which they can register. The Sign On (page #) solution pattern shares in providing this strategy.

Validate Registration Information

You want to make certain that the user’s specified and submitted username is absolutely unique. If it is not unique the registration process must fail and some indication of the failure should be shown to the user. Other data aggregated with the user, such as the person’s name and contact information, does not have to pass uniqueness validation. Nonetheless you may want to check such items as email addresses and phone numbers for format consistency. If any data is in error, including the username failing a uniqueness test, allow the user to change the data in error without having to re-enter everything over again. On the web this is usually accomplished by redisplaying the registration form with valid data in tact on the page, but this time with some error messages/explanations at the top of the page.

Persist User and Person Information

The user and person data should be preserved as a composed set of data under the storage facility of choice. I have recommended LDAP as storage mechanism, but it may just as well be a relational database, for example, that you use.

If you have determined that registration confirmation is a requirement for your system then you should reserve setting some data item in the storage medium until after confirmation is achieved. Our reference implementation uses “membership” as the confirmation flag. When the newly registered individual confirms their registration the system sets them as a specific and appropriate type of member of the system.

Send Confirmation Message, Validate Registration

This strategy specifies how to send a confirmation message to the newly registered user allowing them the chance to confirm that they are a serious and legitimate user of the system.

As in the reference implementations you can send an email message with embedded HTML, including a link back to the FrontController on your web site. When clicked, the link performs an HTTP POST back to your web site. The “feature ID” or “action URL” of the confirmation action and appropriate user data is sent back to the system via its controller. The controller delegates to the specific feature controller (ValidationController in our case), and the feature controller affects the confirmation completion process. What actually occurs is that a membership value is associated with the user’s registration data, which indicates that the registration is validated and official. From that time forward the user is allowed to sign on to the system/application.

Examples

I provide a J2EE reference implementation. This is part of the implementation provided with the rest of Identity and Access Management (page #), and is posted on my Web site.

Following a logical flow, let’s first see where the Helpful Links strategy fits in. Looking back to the sign on responsibility we see that a user may request to register with the system if they have not yet done so. This helpful link is found in the sign on page:

[code]

Once your user has clicked this link they will be shown the registration form:

[code]

My implementation is quite simple as it captures information for a simplified Fundamental Identity (page #) implementation. As I mentioned in that pattern you should use my simplified implementations to add on some more functionality. Above is a miniature view of my HTML form. The registering user’s unique email address also serves the purpose of their unique username/user-ID.

When a potential user has completed entering their identity information into the form, they should click the Register button. From that point you may follow the flow as depicted in the sequence diagram; that is, at least from a high-level perspective. Once the FrontController has delegated request handling to the RegistrationFeatureController the real work begins. The feature controller locates the IdentityManager session façade (not shown) and passes its UserIF Transfer Object [CoreJ2EE] created from data in the registration form on to the Enterprise JavaBean. Next the EJB session façade delegates its business logic to the RegistrationCoordinator. Finally the coordinator Application Service [CoreJ2EE] interacts with the User and Person domain model layer to determine if the user and person identities can be registered. If there is no such identity in the directory, persisting the temporary User/Person composition performs the registration. At this point visit the Fundamental Identity (page #) examples to see how the domain layer interacts with the directory service.

[code]

Still the registration is not fully completed. When the User/Person composition is first stored in the directory by the Fundamental Identity (page #) pattern, the identity is stored without membership to the system. Instead it is given a “candidate” status. With a successfully stored unique identity it’s now time to send an email notification message to the new user.

When the new user receives the email message they click on the embedded link that allows them to validate their registration. The HTTP link posts back to the web site’s FrontController, which in turn dispatches the validation request to the ValidationController, and so on. Ultimately the user’s membership attribute is set to “member” value. This completes the review of the core functionality of the J2EE reference implementation.

Consequences

I have provided a list of competing forces found in this solution pattern.

Match Your User and Fundamental Identity Definitions: You must be certain to audit your registration implementation against your data structures defined by the User (page #) and the Fundamental Identity (page #) patterns. Make sure you collect all the data needed by these supporting patterns.
Prefer Self-Service Over Administrator Controlled: You will have to determine if your system will allow all or most users to register via a self-service interface such as the one I provide in my reference implementation. While it will save much work for administrators, clearly this is out of the question for some businesses/organizations where security is very tight. On the other hand, you may prefer to have system administrators manage the registration of employee and partner identities, merely propagating the results out to appropriate computing nodes in your topology (both end-user workstations and servers).

Related Patterns

The following are the solution patterns that are be used in conjunction with this pattern.

User (page #): This pattern defines the structure for storing user-specific information.
Fundamental Identity (page #): Use this pattern to define the structure and storage of the primary person identity attributes.

Frameworks and Tools

Tools: Our reference implementation uses freely and commercially available tools such as OpenLDAP for storing user identities. In addition you may find my recommended suite of tools useful, including Tomcat and JBoss, if you are implementing your own solution.

[EOF]