Family Accounts

With services that can be shared between members of a household, such as movie streaming, it may be necessary to associate multiple family members with a family account. This requirement can apply to insurance, digital libraries, cellular service providers, healthcare, or other services traditionally shared among members of a family or household. In addition, one family member may need to be informed about, or communicate on behalf of, another person such as a minor child or an elderly adult. For such family-oriented services, applications may need to recognize all family members associated with an account as well as what each family member can do for others.

Temporary Positions

In corporate settings, temporary accounts are sometimes needed for contractors, interns, or partner workers. If temporary accounts are not governed by a company’s normal account management processes, they might not be terminated when the temporary working relationship is over. A best practice is to set an expiration date for temporary accounts and require the manager of a temporary worker to periodically approve renewal of the temporary account. If the account is not renewed, it should be disabled. The sensitivity of the privileges allowed by the temporary account’s access can determine the appropriate frequency for account review and renewal.

Status Transition

Another corporate requirement involves a person who transitions from working in one capacity to another, such as a temporary contract worker transitioning to full-time employee status or vice versa. If temporary workers are registered and administered separately from employees, but all sources feed into one identity provider, it might be possible for two accounts for the same person to exist at the same time which might cause ambiguity at best, or unauthorized access at worst. If a person can transition from one status to another, processes should be designed to avoid duplicate accounts for the same person.

No Email Address

Many applications expect an email address attribute in a user’s profile. There may be cases, however, where users don’t have email addresses. Some businesses do not issue email addresses to employees who have no need to read email on the job. Parents of younger children may not allow them to have an email address. Some organizations may provide their users an email address but have privacy guidelines that prohibit the use of email addresses as account identifiers. Applications may need to accommodate users who do not have email addresses or restrictions on where an email address can be used.

Identity Defederation

It may be necessary to support account defederation while otherwise leaving an account intact. For example, when a person terminates their relationship with an employer, they may need to use a personal account to access resources that they previously accessed via an account at the employer’s identity provider. If a company provides to employees a pension program, employees might sign in to the external pension web site via their employer’s chosen identity provider. If an employee quits their job, however, their account at the corporate identity provider will cease to exist. The user will need their account at the pension system to be defederated from their employer’s identity provider so they can log in with an individual account local to the pension system. In general, defederation is needed when a user can sever a relationship with an organization, but is still entitled to access resources there that they previously accessed via a federated identity.

Mergers and Acquisitions

Mergers and acquisitions can create identity management challenges. It is advantageous for a company to have a single identity repository against which all users are authenticated. When a company acquires or merges with another company, it is common for the identity repositories of the two companies to be merged, which may require resolving duplicate usernames to achieve username uniqueness in the new merged entity.

Changing usernames to eliminate duplicates may impact applications. When a user is authenticated by a centralized identity provider, an identifier for the user is passed to applications. If an application maintains a user profile or data records that contain the user’s identifier, the identifier passed to the application from an identity provider must match the identifier for the user in the application. If a user’s identifier is changed as part of a merger, ([email protected] becomes [email protected] or “mary” becomes “mary.smith”), an identity provider may need to translate identifiers so the user can authenticate with a new identifier but have their former identifier passed to legacy applications still using the old identifier.

Alternatively, user identifier changes can be implemented in applications. This should be done with care, however, as it may require updating data records within the application besides the user’s profile. This can become complicated, so it may be easiest to have an identity provider pass old usernames to legacy applications until the legacy systems are replaced.

Account Linking

Applications typically want to remove as many barriers to usage as possible. Allowing a user to log in via a remote identity provider means the user can log in with credentials they may use frequently and are more likely to remember than an application-specific credential. Furthermore, if the user has an existing authentication session with the identity provider when they access the application, the user may get right into the application via single sign-on, for even more convenience.

In this example, the linking steps establish a link between a user’s account at a social identity provider and their previously established, local account in an application. The user must authenticate to both accounts to prove ownership of them and give the application the user’s identifier at the remote identity provider. The authentication to the accounts to be linked can be done in any order, but it must be done in order to prevent the risk of account takeover via account linking. It’s important to note that automatic linking of accounts that have the same value for a profile attribute such as email address, without the explicit dual authentication step, should be avoided, to prevent the possibility of unauthorized account takeover. If automatic account linking is done between accounts with unvalidated attributes, such as an email address, accounts could be erroneously linked that belong to different people. Lastly, if account linking is implemented, it should be possible for users to unlink accounts they have previously linked, in case the user wishes to stop using a linked account for some reason. Implemented properly, account linking can provide a convenience for users to log in via different identity providers and still access the same account.

Progressive Profiling

Progressive profiling can be used to avoid having to collect a lot of information from a user at once. A user can sign up for an application account with minimal information, and progressive profiling can then add to that data over time. The gathering of additional profile attributes can be done upon subsequent uses of the application or when it is needed for a specific type of transaction. A user can even sign in to an application using a remote identity provider, and the application can create a local account for them with information from the remote provider. A user can be prompted to supply additional profile attributes either before or after they are redirected to that identity provider, with information from both sources merged into the local application’s profile for the user.

Impersonation

Impersonation is defined as the ability of one person to log in to an application as if they were another person and perform any task as that person. The most common use case is the need for support personnel to log in to an application as another user and see what the user experiences in order to troubleshoot an issue. Unfortunately, such a capability has the potential to be abused, and it can be challenging to retrofit secure, restricted impersonation capabilities into an existing application. To reduce the risk of unauthorized activity by impersonators, a separate troubleshooting application can be created that restricts access to that needed for troubleshooting. For example, it could provide view access to customer account configuration and data, for troubleshooting, but not the ability to modify customer data. The application should log all activity and automatic monitoring of logs for anomalous activity should be implemented. Ideally, consent should be obtained from account owners before the troubleshooting application allows access to an account. Needless to say, the troubleshooting application should be protected with adequate security measures and granted only to authorized staff, with the list of authorized users reviewed frequently. This approach can reduce the risk of unauthorized insider activity.

Delegation

Another use case sometimes referred to as delegation is when one user needs to grant another user the ability to act on their behalf, for a specific subset of tasks or data. A busy executive, for example, may delegate some chores to an executive assistant. The executive’s assistant would be granted access to perform tasks on his or her behalf. A variant of this is when an employee goes on vacation and needs to delegate ownership of their tasks (such as support tickets) to another person while they are away. In both cases, one user needs to be granted access to perform specific actions on behalf of another user. Such capabilities are best designed into an application as the granting of delegation privileges is quite application specific. For example, an executive may wish to delegate to an assistant the ability to approve expense reports, but only up to a certain amount. Application logging should be delegation-aware so that all activity done by delegatees is logged and shows both the delegating and delegated identities involved, for a full audit trail. The task-specific nature of delegation and need for audit logging makes it best implemented within an application itself.

Shared Workstations

There are some environments where users log in to shared kiosks or workstations. Such environments provide a shared device that is used by many users. Examples can be found on manufacturing shop floors, medical offices, and point-of-sale systems. With the same device used by multiple people, it is important to have each user log in when they start a session and log off when they complete a session. Having users log in at the beginning of a session is easy enough, but ensuring that a user logs out is more challenging because users may get distracted and forget to log out before walking away. Implementing a session timeout after a short period of inactivity can help protect users. Bank ATM machines provide a good example, asking after every transaction if the user wants to do another, and if there is no response within a short period of time, the session is immediately terminated. For applications that run in a browser, it is helpful to use a browser that supports ephemeral sessions and to set browser policy to force ephemeral sessions so that information from previous users’ sessions is cleaned up. If your application may be used on shared devices, it’s also important to consider if information could be leaked through other means, such as temporary files, and mitigate any risks found. Such steps can prevent user sessions and data from being compromised on shared devices.

Identity Provider Discovery

If an application has multiple identity providers configured for authenticating users, these options can help determine the correct identity provider for a user.

Multitenant Applications

The first option may not be very convenient for users. The second option is often achieved by including the tenant name in the URL by which a user accesses the application or by providing a tenant selection mechanism for the user.

In addition to routing a user to a specific tenant, there may be a requirement to enable different authentication policies across tenants. For a business-facing application, it may be necessary to allow the administrators for each tenant to configure different identity-related preferences, such as password strength requirements, the identity provider(s) by which to authenticate users, or the allowed length of single sign-on sessions. It may also be necessary to support the ability of customers to retrieve log data but only for their tenant. In short, a multitenant application has to satisfy all the usual identity-related requirements, but may have to provide the ability for each tenant to have their own identity-related configuration settings.

Key Points