Business Process and Technical Requirements
The first question that should be addressed when considering a system for managing external users is how to identify them.
- A government providing e-services to tax payers.
- A University providing services to students.
- Airline passengers accessing frequent flyer programs.
- Bank customers accessing their accounts.
Best PracticeUse existing identifiers if the users are already known.
Where an organization is enrolling new users, with whom there is no pre-existing relationship, an identifier will have to be issued to each user. The best identifier is typically the user's own, pre-existing e-mail address, for reasons that will be discussed below. Examples of this scenario include:
- Consumers registering to get technical support from a manufacturer.
- Buyers enrolling for services with an online store.
Best PracticeE-mail addresses are recommended identifiers for users new to the organization, for several reasons:
- Users already know them, and are unlikely to forget them.
- A fully qualified SMTP address is guaranteed to be unique.
- The user's login ID can be used to contact the user in addition to logging the user inn.
Best PracticeWhenever sending a user an e-mail, include the e-mail address in the body of the e-mail, not just in the To: mail header. Users often have mail redirectors and may not know which of their addresses is their login ID.
Ancillary User Data
In addition to assigning unique identifiers to all users, typically additional information is required.
Each application will have its own requirements in this regard, but it is important to consider some best practices regarding user enrollment:
Best PracticeCollect only the data required and nothing more.
- Users don't like to fill in forms.
- A minimal data set reduces the attractiveness of the system to intruders.
Best PracticeProtect the privacy of collected data, and publish a privacy statement describing the protections.
Best PracticeHash or encrypt data wherever feasible.
Most Extranet applications use passwords to authenticate users. Passwords are chosen because they cost nothing to provision and relatively little to support. Stronger authentication technologies, such as tokens, smart cards and biometrics, rarely make sense in Extranet deployments, unless compromise of the system represents significant business risk.
Passwords are intended to reliably establish a user's identity. The extent to which they are reliable is directly proportional to the difficulty of guessing them, so it makes sense to require long passwords, block use of dictionary words, require periodic changes, require both letters and digits, etc.
Best PracticeThe strength of the password policy should be based on the business risk of the Extranet application. Passwords to a bank site represent more risk and should be more complex than passwords on a Internet photo sharing site.
There are two options to providing initial user passwords:
- Assign a random password.
- Ask the user to choose a password.
Best PracticeIt is always better to ask users to choose their own passwords.
Bad IdeaSystem-assigned passwords are much harder to remember and consequently cause support problems.
Best PracticeThe system should require users to choose passwords that comply with the password policy.
Best PracticeThe password policy should be displayed to the user whenever a user is asked to choose a new (or initial) password. In the event that a user chooses a weak password, the error message should explain what was wrong with the password, not just say that it was unacceptable.
Password Reset vs Retrieval
Inevitably, users will forget their passwords. When this happens, it is important to enable them to repair the problem using self-service, since human customer support for large user populations is very expensive.
There are several options for supporting users who forget their passwords:
- Send them their original password by e-mail.
- Send them a new, random password by e-mail.
- Send them a randomized URL by e-mail which they can click to access a form where they can choose a new password.
- Authenticate the user directly on the web site and then
enable the user to choose a password. Authentication may use
a number of methods:
- Ask the use to answer personal questions, answers to which were enrolled when the user profile was first setup.
- Send a random number to the user's e-mail address and ask the user to type it in.
- Send a random number to the user's SMS cell phone address and ask the user to type it in. This may be more secure than a normal e-mail, as it asks the user to demonstrate possession of a physical item (the phone), rather than just of an electronic account (the e-mail address).
Bad IdeaStoring passwords increases the security vulnerability of a system, and should be avoided. Consequently, the "send the user his old password" option is a bad idea.
Bad IdeaRandomly generated passwords create new user support problems so should be avoided.
Each of these options has an impact on user enrollment:
- An e-mail address is generally required (preferably as the primary ID, as described above).
- Personal questions and answers.
- An SMS-enabled cell phone number, from a vendor that provides an e-mail-to-SMS gateway.
Onboarding / User Registration
There are basically just two forms of onboarding processes in Extranet applications:
- Provisioning users that are already represented in a pre-existing system or application.
- Provisioning brand new users, who are not already known to the organization.
The business process in either case is likely to be:
- Relatively simple:
- Typically a single web form.
- Some form of identity validation may be required.
- Very specific to the needs of the organization:
- Contrast enrollment of a bank customer with signing up a new user at an online retailer.
In general, onboarding is performed using self-service, to lower the cost of the process by eliminating the need for a central help desk.
Self-service web forms are subject to abuse by robots, so it is important to incorporate a "Captcha" to differentiate between human visitors and malicious software agents.
Best PracticeCombining the above information, onboarding should proceed as follows:
- Verify that the prospective new user is a human being, using a Captcha.
- Ask the new user for a login ID. This will either be an existing identifier related to an association the user has with the organization, or the user's e-mail address.
- Collect a minimal amount of personal information from the user, some of which will be hashed or encrypted, possibly in the user's web browser.
- If required, validate the identifier and other data provided by the user.
- Get an initial password from the user.
- Collect any ancillary authentication information from the user, for purposes of authentication in the event that a password reset is required.
- Create a new user object in the Extranet's directory.
Directory Scrubbing / User Deactivation
Extranet applications may attract large numbers of registrants and over time users may lose interest in the site and never return. Alternately, users may change their e-mail addresses and be unable to login, or may create multiple user profiles on the site.
In any of these scenarios, orphan accounts remain on the Extranet directory, and over time these cause the directory to grow and become increasingly costly to maintain.
It makes sense to remove old accounts, to keep the directory "clean:"
Best PracticeRecord a time stamp whenever a user successfully logs into the system.
This makes it possible to distinguish between active and inactive users.
Best PracticeSend inactive users a warning e-mail.
This allows them to refresh their account and provides a reason for marketing to contact users.
Best PracticeUse a long timeout interval -- for example, a year of inactivity.
This avoids unnecessary nuisance for infrequent users.
Best PracticeRemove accounts that have been inactive for a long time.
In addition to automated directory scrubbing, users should be allowed to remove their accounts from the system.
Best PracticeAlways provide a mechanism whereby users can remove their accounts from the Extranet directory.
A common complaint of visitors to web sites is that once they sign up, they cannot remove themselves. Failure to provide an unsubscription option can create a small but vocal community of irate users.
Best PracticeUsers should be able to change their passwords at any time, after authentication.
Users may want to change passwords because they believe there has been a compromise, or simply to make them harder to attack.
If the Extranet application represents sufficient business risk, users should be automatically reminded, and perhaps forced to change passwords regularly (example: every 90 days).
In some applications, it makes business sense to allow users who have difficulty with the system to call a central help desk for human (i.e., not self-service) assistance. In these cases, the following must be considered:
- How will the help desk staff authenticate themselves to a support application?
- How will the help desk authenticate the caller? (Example: challenge/response).
- What will the help desk staff be able to see and do? (Examples: lookup user profiles, reset passwords, change profile data).
- Will support actions be logged, and if so will the logging be manual or automated?
Scalability and Reliability
Extranet applications typically must support:
- 24x7 operation.
- Millions of users.
- Enrollment and identity / authentication profile changes at any time.
- Reliability in the event of a local network outage.
These requirements lead to some specific technical requirements:
- No single point of failure.
- Support for geographically distributed components.
- Ability to add and load balance servers as usage grows.
Application components of the Extranet, including identity management components, should be stateless if possible, to simplify load balancing and server distribution.