The more identities a man has, the more they express the person they conceal.
—John le Carré, from Tinker, Tailor, Soldier, Spy (1974)
The first step in the life of an identity is its creation. If Descartes had lived in the time of Internet identity, he might have quipped, “Ego signati sursum, ergo sum” (I signed up, therefore I am). Provisioning is the act of establishing identities and accounts for your application. As defined in Chapter 2, an identity includes at least one identifier and various additional user profile attributes. An online account is associated with an identity and can be used to access protected online resources. The objective of the provisioning phase is the creation or selection of a repository of user accounts and identity information that will be used in the authentication and authorization of users as they access protected resources.
Provisioning Options
A user creates a new identity by filling out a self-registration form.
A special case of self-registration is sending select users an invitation to sign up.
User identities are transferred from a previously existing user repository.
An identity service with an existing repository of user identities is leveraged.
An administrator or automated process creates identities.
These approaches are not mutually exclusive; in some cases, a combination of approaches might work best. We’ll describe each in more detail along with some advantages and disadvantages for each.
Self-Registration
One option is to have users create a new account for your application and specify their identity information via self-service sign-up. This requires enticing users to your site, having them fill out a registration form and then storing the collected information. This is a common approach for consumer-facing sites and requires you to design and create the sign-up form(s). It also necessitates privacy notices about the information you are collecting and obtaining the user’s consent for the planned use of the information collected. You should keep the information requested to a minimum as users may abandon the registration process if too much data is required!
•Self-Registration
Advantages | Disadvantages |
|---|---|
•Ability to collect user attributes that don’t exist elsewhere. •Control over user registration experience. •Scalability through self-service. | •May deter some prospective new users from signing up. •Liability associated with storing login credentials. |
Progressive Profiling
You can reduce the information a user has to enter upon sign-up by using progressive profiling, the practice of building up user profile attributes for an identity over time, instead of requesting them all at once. With progressive profiling, a user is asked to provide minimal attributes when they sign up. If the user later performs a transaction that requires more information, it is collected at that time. Alternatively, additional information can be gathered after a certain amount of time has passed or a set number of logins. Progressive profiling reduces the sign-up friction that a lengthy initial sign-up form would present. It is used more often in conjunction with self-registration sign-up, but can be used with other provisioning options.
Invite-Only Registration
A variant of the self-service registration approach is the invite-only registration flow. In this scenario, specific users are invited to sign up. The invitation may be triggered by another user. Some social networking sites use this approach to have users invite their friends to join the site. The invited user gets a link which takes them to a sign-up form where they can register. An invitation may also be triggered by an administrator of a site. This case may involve a registration form for the user, or, if the administrator has already provided all account data needed, it might only involve email address validation and/or a password reset. This technique might be useful to invite specific users to test an early access (alpha) version of an application or release.
With an invite-only sign-up, access to the registration form is restricted to a select group of users who receive an invitation. The invitation can be delivered via channels such as email or text message and contains a link that allows the user to register. The registration page can lock the email address or phone number to that used in the invitation so it cannot be changed at the time of registration, if it is important to prevent an uninvited person from stealing someone else’s invitation and signing up as themselves. The link in the invitation can also have an expiration associated with it, if necessary, and each invitation is usually tracked so it can only be used once.
An invite-only flow can also be used for situations where you need to create an account in order to assign privileges to it before sending the invitation. This approach could be used to establish employee accounts for new hires or customer accounts for access to early access (alpha) application environments. An administrator or automated process can create the account, assign it privileges, and then trigger the sending of the invitation link to the new user. The user clicks the link and provides additional information in a registration form if needed. The information entered by the user can be associated with the previously created account. The account is then ready for the person to use and has the privileges previously assigned to the account by the administrator.
•Invite-Only Registration
Advantages | Disadvantages |
|---|---|
•Ability to collect user attributes that don’t exist elsewhere. •Control over user registration experience. •Some protection against registration by hackers and bots. •Scalability through self-service if users invite others. | •The work to implement invitation mechanism and control access to it. •The work to issue invitations. •May deter some prospective new users from signing up. •Liability associated with storing login credentials. |
Identity Migration
If identities already exist elsewhere, they can be moved from one repository, such as a legacy database, to another repository that can be used by the new application. The advantage is that users don’t have to provide information they already entered elsewhere, and the new repository can be quickly populated with users from the legacy repository. While most user profile attributes can be extracted and moved, passwords represent a challenge. Passwords are typically stored in a hashed format. Hashing converts them to a string of random characters and this cannot be reversed to get the original “cleartext” value. Each time the user logs in and enters their password, it is hashed and the hashed value is compared to the password that was hashed and stored when the user registered or last reset their password. Storing passwords in hashed format allows validation of entered passwords but prevents administrators with access to password repositories from seeing cleartext passwords and makes it difficult to use the passwords if the storage repository is compromised or stolen.
There are different algorithms for hashing passwords and different inputs passed to the hashing algorithms such as salts and iteration counts. As a result, a password hashed in one system cannot necessarily be imported and used by another system. If two different systems use different hashing algorithms or different inputs to the same algorithm, it is not possible to move a hashed password from one system to the other and have it be usable by the new system. In such circumstances, there are a few solutions to consider for migrating identities to a new system.
Support Legacy Hashing Algorithm
•Supporting Legacy Hashing Algorithms
Advantages | Disadvantages |
|---|---|
•Avoids need for password reset. •Transfers all accounts in a usable state. | •Work to implement legacy hashing algorithm(s). •Liability associated with storing login credentials. •Inherits any weakness associated with legacy hashing algorithms. |
Bulk Identity Migration
•Bulk Migration of Users
Advantages | Disadvantages |
|---|---|
•Transfers all users at once. •Enables immediate shutdown of legacy user repository. •No latency added at login time to check a legacy system for a user account. •Code to transfer identities can be independent of application code. | •Transfers all accounts, even inactive accounts, unless they are filtered out during the transfer. •Requires all users to set new password via account recovery, unless the new system can support the legacy hashed passwords. •Migrating all users at once can cause a widespread outage if things go wrong with the migration and there is no backup plan. •If multiple applications use the legacy repository, they must migrate at the same time if the legacy repository is to be shut off after migration. •Liability associated with storing login credentials. |
Gradual Migration of Users
An alternative to a bulk transfer of identities is to use a mechanism that transfers identities gradually as they log in. This requires a login mechanism that prompts users for credentials, validates them against the legacy repository, and if validated, retrieves identity information from the legacy repository and stores it and the entered credentials in the new repository. The password entered by the user, after validation against the legacy system, is hashed by the new system using its hashing algorithm and stored in the user’s new account. This option will only migrate users who log in and requires the new system to have direct access to the legacy system to validate the entered password and retrieve user profile information. This is more convenient for users because no password reset is required, but it means the legacy system must remain operational until the identities have been migrated. This solution will not transfer inactive accounts (users who don’t log in).
With the gradual migration approach, a subset of users may not log in and therefore not have their identity information migrated. You can set a cutoff date for the migration and decide what to do about any identities that have not been migrated by that date. One possibility is to declare the unmigrated accounts inactive and abandon them. A common approach is to use the bulk move option described previously on the inactive accounts so you can decommission the old system. You may want to migrate only a subset of identities that you have reason to believe will be active again in the future. If you do not migrate all remaining identities, you should consider reserving the account identifiers of unmigrated identities to prevent them from being used by new accounts in the future. Chapter 15 explains why.
•Gradual Migration of Users
Advantages | Disadvantages |
|---|---|
•Inactive accounts can be weeded out. •No password reset required (for users who log in during migration). •Spreads out risk of outages by migrating identities gradually (no big bang risk). •Can support continued use of previous sign-up mechanisms or applications that use the legacy identity repository during the gradual migration. | •Requires that legacy identity store is accessible from new application’s authentication mechanism. •Legacy identity store must remain accessible until enough identities are transferred. •Transfer mechanism must be maintained throughout the gradual migration. •A user’s first login after migration starts may have some latency as identity data is transferred from the legacy system. •Implementation work cannot be easily decoupled from the application team. •Liability associated with storing login credentials. |
Administrative Account Creation
The size of an organization
The frequency with which new users need to be added
Whether provisioning needs to be done across domains
The following sections provide a few variants of this solution to consider.
Manual Account Creation
Having an administrator manually create accounts for new identities will only be practical for very small organizations (low tens of users) with an infrequent need to add new users and few applications. For very small organizations, the work to implement account provisioning automation may not be justified. In the absence of automation, written procedures and checklists can be used to ensure necessary account provisioning steps are consistently followed. If passwords are used as credentials, the account provisioning procedures should ensure that administrators do not know the user’s password. This can be done by sending a password reset link to the user and/or requiring a password reset upon initial login. If the organization grows or starts to need more than a handful of applications, some form of automation will be beneficial for consistency, accuracy, security, and trackability.
Automated Account Creation
This approach is often used for employee identities. When a new employee joins a company, the company can automatically create an account for the employee using identity information from a Human Resources (HR) system. If large volumes of accounts need to be created on an ongoing basis, workflow software or specialized account provisioning software can be used to automate account creation and provide identity attributes for accounts.
Cross-Domain Account Creation
Maintaining employee accounts in external SaaS (Software as a Service) applications
Maintaining partner accounts in corporate identity repositories or applications
Maintaining business customer user accounts in business-facing applications
Maintaining guest professor or student accounts in collaborating universities’ systems
Applications are not designed to extract identity information from authentication tokens.
The identity profile information is too large to convey in authentication tokens.
User logins are not frequent enough to keep profile information sufficiently up to date.
When needed, the provisioning of accounts and identity information across domains is still commonly done using proprietary solutions, but an industry standard protocol, SCIM (System for Cross-domain Identity Management),i was created in 2015 to provide a more standard approach to sending and updating identity information from one domain to another.
•Administrative Account Creation
Advantages | Disadvantages |
|---|---|
•User doesn’t fill out registration form. •Administrator can assign privileges so account starts with needed permissions. •Can be automated via workflow or identity provisioning software. | •Time-consuming if not automated. •Requires care to ensure that only the user knows the password for the account created. •Liability associated with storing login credentials if stored locally. |
Leverage Existing Identity Service
It’s also possible to leverage an identity that already exists for a user in an identity provider service. This allows users to employ an account they already have such as at a social provider like Facebook or Google, a corporate identity provider service operated by their employer, or a government identity service. With this option, your application delegates responsibility for authenticating users to an identity provider and receives back a security token with information about the user’s authenticated session and, optionally, attributes about the user.
•Leveraging an Existing Identity Service
Advantages | Disadvantages |
|---|---|
•Better user experience if it reduces the data required to sign up. •Easier for user to remember password if identity provider account is used frequently. •You may not have to implement a login form or account recovery mechanism if all users authenticate via the identity provider service. •Less risk if you do not store user passwords. | •You may have to collect additional profile information not available from the identity provider service. •You need to evaluate the service and availability levels of the external identity service to ensure it meets your needs. •May require additional development or configuration work for each identity provider service to be used. •May require configuration work at each identity provider service for each application you have, unless you use an authentication broker service (described in Chapter 7). •May require collaborative troubleshooting with another organization when issues occur. |
In addition to existing identity provider services, you can of course set up your own, new identity provider service for use by your application. If you choose that route, many cloud services are available to facilitate the task, and any of the previous provisioning options could be used to populate the new identity provider service with users.
Selecting an External Identity Service
The validation of the information used to establish the identity
The identity’s implementation that prevents it from being forged or used by others
Recognition of certain issuers of identities as authoritative for a particular domain
•Characteristics of Strong vs. Weak Identities
Strong Identities | Weak Identities |
|---|---|
•Linked to a real person, who can be held accountable for actions taken with the identity. •Identity attributes are validated during account issuance process. •Issued by entity recognized as authoritative for a particular context. •Contains mechanisms to protect against forgery or unauthorized use. | •Anonymous, cannot be linked to a real person. •Little validation of identity attributes. •Issued by an entity with little recognized authority. •Few protections against forgery or unauthorized use. |
The strength of an identity is based on the trustworthiness of the issuer, the validation of identity data, the practices behind the issuing and distribution of the identity, and in some cases, agreements, either implicit or explicit, between the issuer and any entities trusting identity information from the issuer. The next sections provide examples.
Self-Registered Identities
A self-registered identity, such as a basic Gmail or Yahoo email account, is an example of a weak identity. You can sign up for these accounts using any identifier that has not already been taken, such as [email protected] or [email protected]. You do not have to supply true information in the sign-up form and the service provider does not validate most of the identity data. Several social providers have added security features to protect against unauthorized use of accounts, but self-registered accounts are typically not considered authoritative for identity information due to the lack of validation. Identity providers with self-registered accounts and little validation of attributes are most suitable for consumer-facing applications that do not require strongly validated identity data and would otherwise rely on self-registered information. Allowing users to authenticate via such providers gives users convenience and the ability to reuse a common profile.
Organization Identities
Many organizations, such as companies or universities, will issue an online identity for their members, such as employees or students, respectively. These identities meet some of the criteria for a strong identity. For example, in the United States, one must show government-issued identity when starting a new job. This enables validation of the identity attributes used to establish an online account within the company and ties the account to a real person. Most companies implement measures in their identity service such as minimum password length and possibly stronger forms of authentication, to protect an account against unauthorized use. The corporate identity service is authoritative for user login, at least within the domain of the issuing company. However, a user typically cannot log in via their corporate identity service and access services outside the organization and its contracted SaaS services. A user could not, for example, expect to log in via their corporate identity service and access a government site to buy stamps as the government site would not have any basis to trust the corporate identity service. Organization identity services are primarily suitable for use by applications selected by the organization to provide services to organization members.
Government Identities
A government-issued online identity, such as those issued by the United Kingdom’s GOV.UK,ii Belgian eID,iii or Estonian e-identity,iv is an example of a stronger identity. These require supplying information that is checked by a validation process. Some require applying in person at a government office, and some can be done online. Required documentation includes government-issued identity documents and photos that clearly show one’s face and may include fingerprints and financial questions. The resulting identity contains validated information and employs several security mechanisms to prevent unauthorized use.
The GOV.UK Verify service, for example, is used within the United Kingdom to access government services. The Belgian eID program issues an electronic identity that can be used for identification, digitally signing documents, and logging in to public services. Estonia issues a mandatory, secure national digital identity and card which Estonians use to travel within the EU, as well as access e-services such as voting and logging in to bank accounts, access medical records, file taxes, and sign documents with a digital signature. Government-issued identities provide more strongly validated identities, but may be limited to users from one country and may be limited to use at the issuing government’s services. Wider use would need international standards similar to those for passports as well as a model for funding the incremental service operation costs.
Industry Consortium Identities
The Belgian Mobile IDv project is a consortium of financial institutions and mobile network operators to provide a strongly validated identity for anyone with a Belgian-issued eID and a mobile phone. It’s used to register at services, digitally sign documents, and securely log in as well as confirm transactions. The service includes a mobile application, “itsme,” which is used to authenticate without the need for passwords. The service is used to access Belgian government services such as social security and tax services as well as telecom and e-banking applications.
Identity Provider Selection
If you are creating a consumer-facing application that does not require validated identity information, allowing users to authenticate via an existing self-registered identity, such as a social provider account, offers users convenience over signing up with the same self-registered information at multiple sites.
If you are creating an employee-facing application, however, relying on social identity provider accounts to access company applications can be problematic because the user owns their identity and account at these providers. The credential standards of the provider may not meet company needs, and when an employee leaves the company, you could not delete their account to terminate their access. If, on the other hand, a social provider account is linked to a local application account, to enable logging in to the application via the social provider identity, the link can be removed and the local account disabled if an employee leaves. In the absence of such account linking, access would often need to be removed within individual applications, and one or more applications might be missed. For employee-facing applications, therefore, it’s best to use an identity service where the employing organization owns the accounts. The same logic applies to other organizations, such as educational institutions.
An organization-controlled identity service provides a single place at which the organization can provision accounts as well as shut off accounts if an employee or member leaves the organization. It also gives a single point at which to enforce credential strength/policy and deploy multi-factor authentication as well as log authentication activity. There are several cloud vendors that offer an identity service on a subscription basis. Cloud services such as Google Apps, Azure AD, Auth0,1 Amazon Cognito, and Okta offer cloud-based identity services. Organizations can provision employees or members into these services and have complete control over the accounts including the ability to quickly terminate or disable the accounts of anyone who leaves the organization.
Identity Providers for Different Customer Types
Scenario | Most Common Type(s) of Identity Provider |
|---|---|
B2C: Business to consumer | Social Identity Providers2 Identity services such as Azure AD or Auth0 Application-specific repository |
B2E: Business to employee | Identity services such as Google Apps, Azure AD, Auth0 Any OIDC or SAML 2.0-compliant identity provider |
B2B: Business to business | Identity services such as Google Apps, Azure AD, Auth0 Any OIDC or SAML 2.0-compliant provider controlled by the business customer |
To recap, you should consider the target audience and strength of identity needed by your application. If a strong identity is required, it must be issued by a process which validates the information used to establish the identity and includes protections, such as strong password requirements or multi-factor authentication, to prevent unauthorized use of the identity. It must also be issued by an entity recognized as authoritative for the application’s domain.
Choosing and Validating Identity Attributes
The topic of provisioning invariably raises the contentious question of how to identify a user. Email addresses have been widely adopted as identifiers, but such use is not without issues. Using an email address as an identifier has the advantage that it includes a domain name and thus provides built-in uniqueness across domains. This eliminates the need for a user to find a name on each site that hasn’t been taken already. However, users may need to change their email address for several reasons and still retain access to their account. In addition, an email provider may reassign a previously used email address to a new owner. For business-facing applications, some businesses do not provide their employees with email accounts which can be an issue if an application assumes the availability of an email address. Similarly, applications marketed to children should recognize that some children may not have an email address.
Advantages and Disadvantages of Account Identifiers
Advantages | Disadvantages |
|---|---|
Email:Globally unique. No need to hunt for a name that isn’t taken already. May be easier to remember than a username. | Email: May need to be changed by user. May be reassigned by email provider to new user. May be reassigned by corporate provider to new user. Terminated by employer if user leaves. Not all companies issue email addresses. Children may not have email addresses. Family members may share an email address. May expose personal information (user’s name). Exposure as display name may result in spam email. |
Username: Easier to set up multiple accounts at a site. May be shorter to type on mobile devices. Can be used in searches, allowing other attributes with personal data to be encrypted. | Username: Only unique within an application domain. Merging user repositories problematic after acquisitions. May be harder for a user to remember which username was used at each site. A user may want to change a username over time. May expose personal information if used for display. |
Phone number: Globally unique (with country code). No need to hunt for a free identifier. May be easier for a user to remember than a username. | Phone number: Exposure as display name may cause spam calls. Might be reassigned to a new user over time. May involve a charge to obtain a phone number. More difficult to set up multiple accounts at same site. May be changed by user for various reasons. May be terminated by phone provider. |
Suggestions
Identifier for logging in
Display name
Notification/communication/account recovery
- Internal account implementation
Linking an identity/account to application records
Capturing user activity in log files
Continuous identifier for a user over time for audit purposes
- Avoid exposing identifiers that may contain personal data.
Use an internal account identifier in log files to avoid directly exposing personal data in logs.
Use an internal account identifier in application records.
Allow users to specify a display name for use on screens/printouts to protect privacy.
Identifiers/attributes for logging in, display, and notification should be distinct and changeable.
Allow setting multiple attributes for notification purposes, such as a primary and secondary email, in case one becomes inoperable.
Allowing a long username with special characters and which is changeable by users would enable flexibility, including use of an email address if that is easier for some users to remember, while allowing other users to use other values. A separate profile attribute besides the username should be used for notification/contact information.
Validating Critical Attributes
Authorization decisions
Account recovery
Delivery of sensitive information to the user
For example, if a user profile includes an email address, and the email address attribute is used in authorization decisions, you should implement email address validation. Similarly, email address attributes used for notification in account recovery or delivery of sensitive information should be validated. The same holds true if a phone number is used for such purposes. If you import identities from elsewhere, you should ensure email addresses or other critical attributes used for the listed functions have been validated before accepting them.
Security and privacy-related issues can arise with unvalidated attributes. If users can sign up using a fictitious, unvalidated email address and this attribute is used for authorization, their fictitious email address may match authorization rules that grant access to resources they are not really entitled to access. Validating email addresses also prevents accidental entry of an incorrect address. Incorrect email addresses could enable account takeover via account recovery mechanisms or result in the delivery of sensitive information to the wrong recipient. For these reasons, it is critical to decouple attributes for different purposes and validate any email addresses or other profile attributes that are used in authorization decisions, account recovery mechanisms, or to deliver sensitive information to users.
Summary
We’ve covered several approaches that can be used to establish accounts for the users of your application, including self-registration, progressive profiling, transferring users from elsewhere, administrative processes, and leveraging identity provider services. In selecting a provisioning approach, you will want to consider the strength and suitability of the identity offered by each option against the sensitivity and target audience of your application. Once you have an idea how your users will be created, you can start implementing authentication and access control. Modern applications are often designed starting with APIs, so we’ll start off in the next chapter with OAuth 2.0, which is designed for protecting APIs.
Key Points
Provisioning is the process of creating an account and associated identity information.
Applications can create new accounts for users or leverage identities in existing identity provider services.
Progressive profiling can be used to build up user profiles over time.
Email addresses and other attributes used for notifications to users must be validated.
Identities can be classified as weak or strong depending on a provider’s practices.
Weak identities are created with unvalidated information.
Strong identities are based on validated information, mechanisms to prevent forgery and unauthorized use and are issued via secure distribution mechanisms by authoritative providers.
In choosing identity providers, a service should match the strength of the identity offered by the provider with the identity validation and strength requirements of an application.
Application designers should decouple and designate appropriate user profile attributes for each of several purposes, including login, display, notification, and internal tracking.