Solution Pattern

User

Defines the data structure and persistence of the authentication credentials of each user of a system. It optionally provides an alternative means of authenticating without a password.

[IMAGE]

Background

Every system that has users and needs to grant unique and secure access to its resources and services has to maintain a set of credentials for each individual user. This involves defining the information and structure necessary to support the approval of system access.

Value and Benefits

The User pattern defines the data necessary to secure system/application access to approved users. A user is granted access to the system if they are able to exactly match one of the registered usernames and passwords. Alternatively they are also be granted access if they provide a username, and then responded correctly to a special question as specified by this pattern’s alt-question and alt-answer. Additionally a second-level security property may also be supported. This is the PIN, or personal identification number.

The Sign On (page #) pattern provides a more sophisticated means of restoring access to the system when a password cannot be provided. However, since the Sign On (page #) pattern will not necessarily have use of the Fundamental Identity (page #) pattern, necessary information (the user’s email address) may not be available to implement that strategy. In such cases the Sign On (page #) pattern may use a less sophisticated and secure strategy supported by the question/answer data defined herein.

Separating the structure, persistence, and access of authentication credentials from the individual user’s personal information and the sign on behavior has its advantages. Privacy is a factor. By separating concerns the user’s personal information need not be accessed in order to authenticate them. The system may support authentication without ever collecting personal information at all. Thus, the Fundamental Identity (page #) pattern may not be required. The behavior of signing on may change over time as new user interface trends appear. Separating the definition structure, persistence, and access of user credentials allows sign on behavior to change without having an impact on the business end of the system.

Putting It to Work

Similar to the Fundamental Identity (page #) pattern, the User pattern focuses on information and structure, not behavior. As you can see from the domain object presented in the pattern summary it maintains user credentials.

Five attributes are obtained from the system consumer: username, password, pin, altQuestion, and altAnswer. The last three attributes are optional. These are collected through Registration (page #) pattern, which is the same pattern used to collect data for Fundamental Identity (page #). Some businesses require general usernames and/or passwords to be assigned by the system. In that case you will not need registration. You will always need to support the Sign On (page #) pattern to challenge the user to submits credentials for authentication.

The PIN is a user-provided value that is analogous to those supported by a bank ATM. Using a PIN along with a password in effect adds a second-level password. The PIN is a number that the user is familiar with, perhaps even more so than the chosen password.

If you decide to support the alternative question and answer means of authentication, you will want to weigh carefully what kind of questions to support. If the question, for example, is “What is your favorite color?” no doubt any malicious person will have little trouble eventually coming up with correct answers for nearly any random user. You may choose to provide a set of canned questions that the user selects one of when registering. Some users will not feel comfortable with your canned questions, so you may allow the user to define their own question. There are both security and usability issues to consider.

Compositon of Associated Objects

If you make use of Fundamental Identity (page #), you should add the associated Person to the User domain object, as specified in the associate pattern. The first opportunity for these separate concerns to be composed as one logical unit will be at registration time. From then on when instantiating the User domain object the Person object may be instantiated along with the User object’s standard attributes using appropriate data. Of course the rules of lazy-loading techniques are in force, if applicable. The following class diagram illustrates the composition of objects associated with the User:

[IMAGE]

In order to address privacy concerns you can support a “lite user” for authentication purposes. A “lite user” is a domain object that contains only the data necessary for authentication, and nothing more.

Technology Considerations

If possible you will want to use the same technology to back this pattern as you do (or would use) for Fundamental Identity (page #). If you determine that a directory service (such as LDAP) is best for your implementation, then the username, password, and optional PIN and question attributes would be stored there. If, however, you decide to use a database, such as a relational database, then the same attributes can be stored there. On the other hand, there is nothing preventing you from using a relational database, for example, to persist data associated with this pattern, and using LDAP for persisting Fundamental Identity (page #) information.

Examples

The J2EE implementation of the User domain object can be found in the following package, which includes the listed supporting classes. This is part of the implementation provided with the rest of Identity and Access Management (page #), and is posted on my Web site. This implementation, like the others within Identity and Access Management (page #), uses LDAP via JNDI. First I present interface UserIF followed by its implementer, class User:

[CODE]

The more interesting class is UserDirectorySession, which interacts with class DirectoryService as noted in the overarching pattern:

[CODE]

I chose not to provide the PIN or alternate question/answer support for my User/Sign On pattern combination. The PIN is easily added if you choose to support it. In the case of an unavailable password, I favored the email forgotten password strategy. Hence the corresponding attributes are missing from the above listing. Because I have implemented the Fundamental Identity (page #) pattern, I have included references in the User domain object to the corresponding Person object. For the purposes of simplicity I do not support a “lite user” object.

Consequences

You will find tradeoffs among the following competing forces within the User solution pattern.

Assigning Roles to Users: For details see the corresponding consequence under the Identity Grouping (page #) pattern.
Use PIN In High-Security Domains: The PIN is an added level of security. If you support an enterprise that demands high security, adding a PIN along with the username and password will make the system and its users more secure. There are few negative consequences in this case, other than the user needing to remember one more password. If you support single sign on within a corporate portal, for example, trading in many usernames and passwords for one the additional password is a small price to pay for security.
Use Alternative Authorization, Or Not: You will have to determine whether or not system access should be granted via alt-question and alt-answer, and if so how it will be implemented. Bear in mind the caveats stated above.
Standardize Across the Board: Again, your technology decisions are key. In this case putting all your eggs in one basket actually has a higher pay back. If you have no choice on selection then ignore this tradeoff.

Related Patterns

The following are the solution patterns that may be used in conjunction with the solution patterns key to the User pattern.

User Account (page #): The User pattern provides a bridge between Fundamental Identity (page #), Role (page #), (and other identity and access management patterns for that matter) and User Account (page #).

[EOF]