And yet in our world, everybody thinks of changing humanity and nobody thinks of changing himself.
—Leo Tolstoy, from “Three Methods of Reform”
It may be true, as suggested by Tolstoy, that people are unwilling to make deep internal changes, but when it comes to identity information, it is quite common for there to be changes! In this chapter, we’ll cover the need to support changes to an identity and its attributes over time.
Identity Attributes
A user’s identity information may change over time for multiple reasons. Some updates will come from users themselves. You should assume that users may need to change almost any attribute in their profile such as their email address, street address, phone number, and even their name. Many privacy regulations, including Article 15 of the GDPR (EU General Data Protection Regulation), mandate that users must be able to access and correct data about themselves held by a data controller.i If you are a data processor, you may need to help provide this capability to the data controllers who use your service.
The need to support identity profile changes depends on where the information is managed. If your application delegates authentication to social providers, the user may need to update some profile attributes at the social provider. Similarly, if your application delegates authentication to an enterprise provider, the user may need to update identity information there. In addition to updates made by users themselves, administrators or automated administrative processes may make updates to user identities. These updates often impact attributes that are controlled by the owner of the identity provider instead of the user and may involve attributes used for access control decisions in applications such as a job level, department, and roles or group memberships.
If user profile data in an application comes from multiple sources, it must be clear how and where to update each attribute. An application may pull some user attributes from an identity provider and augment that data with additional data that is collected and managed by the application. In this case, users need to know where to update different attributes. Any administrative or support processes for the application will also need to know how and where to update each attribute.
When user profile data from an identity provider is cached by an application, the necessary frequency for updating the cache must be considered. When a user authenticates, the application may receive user profile attributes from the authenticating identity provider. The application will have the information during a user’s login session and can cache the information in its own repository for use when the user is offline. A cache, however, will become stale if information changes at the identity provider and users do not log in frequently. If up-to-date information is needed in between user logins, it may be possible for an application to query an API for updated information. Otherwise, periodic synchronization may be needed. Historically, such synchronization has been done with proprietary solutions, but the System for Cross-domain Identity Management (SCIM) protocol ii was created to standardize the synchronization of identity updates across domains, typically between corporate identity providers and relying parties.
A special case to accommodate is the situation where a user needs to update the attribute which serves as an identifier for their account at a remote identity provider. If a remote provider identifier is changed, the next time the user logs in, the application will receive the new identifier. If the application account or data is tied to the old identifier, and the user logs in with a new identifier, the user may not be able to access the account or data associated with the old identifier. The issue can be avoided if the identity provider delivers to applications an internal identifier that never changes, in addition to other user profile attributes. Alternatively, if explicit account linking is used, as described in Chapter 18, a user may be able to unlink the old identity before the change and relink to the new identity after the change, but this requires forethought on the part of a user which may not be realistic!
Credential Reset
Users may also need to update their credentials from time to time. An application that delegates authentication to an identity provider does not have to store credentials or implement credential reset functionality because the credentials are at the identity provider. An application can simply provide a link or instructions that point to the credential reset function at the appropriate provider. If you use an identity provider service, you should be sure to select one that supports self-service credential update and account recovery.
Account Recovery
A user may forget or lose the credential to an account. In the case of a password, the user may forget it. In the case of authenticators such as a phone or hardware security token, they may be lost, stolen, damaged, or broken. If this occurs, a user has to prove they are the owners of an account, via some mechanism other than the original credential, before being allowed to set a new credential.
In many cases, an application relying on an identity provider may be able to leverage account recovery mechanisms provided by the identity provider. It then becomes important to select provider(s) with reasonably secure self-service account recovery mechanisms. Solutions that prompt a user for answers to previously established security questions are problematic as the answers can often be looked up or guessed. They also depend on the user remembering the answers, which is not always the case. Schemes that require users to download recovery codes rely on users saving the codes in a secure place, which also may not be dependable.
A solution that sends a password reset link to an email address previously registered with the account avoids the drawbacks of the previous schemes. This depends, however, on the owner of the account being able to access the email for the email address associated with the account. Sending a one-time code via SMS to a previously registered cellphone number in the user’s profile relies on the number being current and the security of SMS messages. At the time of writing, vulnerabilities persist in Signaling System 7, which connects different phone networks, that have enabled some researchers and hackers to intercept SMS messages. Project owners should evaluate the current state of that issue before deciding to use SMS messages. Enabling users to set up a primary and one or more backup authentication mechanisms may provide the best defense against any one of them becoming broken or compromised.
Password Guidance
If passwords are used, you may wish to provide guidance to your users on what constitutes a good password and, where you have a choice, select identity providers that enforce stronger password policy. Interesting new research by NIST has examined the effectiveness of previous password guidelines.iii Security advice in the past has recommended a mixture of lowercase and uppercase characters, numbers, and special characters, the longer the better. Users were also advised to change their password on a regular interval. This advice was designed to make a password hard to guess by humans or discover by a brute force password guessing approach and mitigate risk from compromised passwords. This research by NIST suggests that some elements of the past guidance may not have been as effective as expected.
Their new guidance suggests that the size of a password matters more than the password complexity as user-selected password complexity is somewhat predictable, and rate limiting on failed password attempts may be a more effective approach. Users are recommended to select a long passphrase that consists of several words but is not a common or guessable phrase. Users are recommended to change a password if there is evidence it has been compromised but rate limits on failed passwords and checking for breached passwords may be more effective than forced periodic password resets. Authentication services should implement rate limiting on failed login attempts and check username/password combinations against databases of known breached passwords to protect against brute force attacks and compromised passwords. You’ll want to use identity providers that offer such features.
Helpdesk Reset
A manual, helpdesk-assisted credential reset process is expensive to provide and can expose sensitive information. It requires the helpdesk staff to have knowledge of secret information with which to validate an account owner. Examples of secrets that have been used in the past are a portion of a government-issued identity number, information on recent transactions, or answers to secret questions. This process has the advantage of providing human assistance, but may expose sensitive information to risk of compromise. If the sensitive information used to validate an account owner is used at other sites, a compromise of the information at one site may allow a malicious actor to take over a person’s accounts elsewhere. For both cost savings and security, self-service credential reset capability should be preferred for most scenarios.
Summary
Identity information may need to be updated over time. Privacy regulations often require that users have the ability to view and correct personal information held about them. Account updates can be handled by identity providers for information managed by them. If identity information is maintained in both an identity provider and an application, account update mechanisms must help users make updates in the right place. Changes to the primary identifier for a user at an identity provider may impact a user’s ability to access application accounts tied to the old identifier. Credentials need to be reset if compromised, forgotten, or rendered inoperable, but a user must be validated before being allowed to reset credentials. An application may delegate credential reset and account recovery features to an identity provider, but the integrity of the mechanisms used by the provider should be validated. This brings us in the next chapter to the final event in the life of an identity, which is deprovisioning.
Key Points
User identity attributes may need to change over time.
Privacy regulations may mandate a process for users to update identity information.
Account management may be delegated to identity providers when the attributes to be changed reside at the identity provider.
If a user changes their identifier at an identity provider, it may impact their ability to access application accounts tied to an old identifier unless a solution is provided for this scenario.
Credential reset and account recovery may be delegated to identity providers for many common scenarios, but exceptional cases such as account takeover may need to involve application owners as well.