How To Have a Successful IDM Project

Pick up almost any book on project oversight and you’ll quickly see a pattern to advise about how to have a successful project. Certainly, all the usual advice, such as the items below, apply to identity-related projects.

• Ensure the project has clearly defined objective and scope
• Identify and obtain input from representative stakeholders
• Define clear ownership and roles for all parts of the project
• Create a realistic project plan based on stakeholder input
• Track progress regularly to quickly identify causes of any delays

That is excellent advice, but in order to create a realistic project plan, you have to know what typically needs to be done for a particular type of deployment. What if your project team does not have that knowledge? A frequent cause of project issues and delays is simply not accounting for certain requirements. Many an Identity Management project has been delayed by overlooking requirements at the beginning.

Have no fear — this post will outline several of the most common oversights and pitfalls for identity projects and how to avoid them. These can be grouped into roughly three categories:

• Identify requirements for the entire identity management lifecycle, not just logging in
• Plan for identity failure and change, so you are ready for such events
• Address security and compliance requirements

If you consider the above at the beginning of your project, you’ll have fewer surprises along the way to derail your project.

Guidelines to Identify IDM Project Requirements

The first thing to check is that your requirements specification takes into account the entire identity management lifecycle. I often tell people that they’ll spend more time on implementing how to log out than how to log in, so they should define how logging out should work early in the project and allow plenty of time in a project plan for testing and implementation. Beyond logging in and logging out, there are several other requirements which may lead to unpleasant surprises and delays if forgotten at the beginning. The following list may help you surface requirements early on:

How Will User Accounts Be Created?

Will users need to sign up or do they already exist somewhere else and need to be migrated? If users need to sign up, where will that occur, and will all information be collected at once or is progressive profiling needed? If users need to be migrated, consider that passwords are usually hashed and not transferable from one system to another as-is, necessitating a trickle-migration approach or password reset.

Will User Profiles Need to Be Synchronized?

Will user profile information need to be synchronized between a system of record (authoritative source) and other points, such as application user stores? It simplifies operations if synchronization can be avoided but legacy systems may require this.

Username Uniqueness

Identify the attribute used to identify users when logging in as well as across all applications and ensure that the username identifier will be unique for all users. You'll need to especially consider any mergers and acquisition activity that could occur. This will help identify if any mapping of identifiers might be needed across systems.

How Will Users Log In?

Okay, no one forgets this one, but the devil’s in the details. Be sure to think about what forms of authentication are appropriate for your use case: username and password? Passwordless forms of authentication? If your application deals with sensitive data or transactions, is multi-factor authentication appropriate?

Auth0 Passwordless is a drop-in authentication system based on Email or SMS, that improves security and user experience. Check it out at auth0.com/passwordless.

What Devices Will Be Used?

Authentication flows do not work identically across mobile and desktop types of devices. Sadly, in this day and age, this is still a thing. Security configurations, such as browser configuration for trusted sites or mobile device management software can impact the use of cookies, fingerprinting and such — all of which can impact authentication flows. Be sure to identify the devices that users will use and test across all of them early on in the development cycle.

Is Single Sign-On Needed?

If you offer multiple applications to users, should users be able to log in once and then access other applications without signing in again? If yes, be sure to consider whether all the applications in a single sign-on circle use the same authentication mechanism and user repository. If there are multiple user repositories, will authentication against any of them suffice for access to all the applications or are the requirements more granular?

Auth0 supports universal login on customer apps. In contrast to embedded login, this offers increased security and a shorter setup time.

Should Multi-Factor Authentication (MFA) Be Used and If So, When?

MFA offers a higher level of authentication for better protection of sensitive assets. Be sure to consider if it will be used upon initial authentication or only when the user accesses more sensitive content/transactions. There are many forms of MFA available, so be sure to experiment with several and select a form that is suitable for your user population. Be sure to test the usability of the initial registration, as well as any reset processes needed if users change devices, phone numbers or any other aspect of the MFA flow. Cumbersome processes can cause user frustration and support headaches.

Learn everything about Multifactor Authentication (MFA) and how you can start using it right now in your application.

What Should Happen When the User Decides to Log Out?

Handling clicks on the Logout button may be trickier than it seems, so pay attention to it early in the design. At a minimum, any session maintained by the application should be terminated. If an application delegates authentication to an external identity provider/authorization server, there may be additional sessions to terminate. Terminating those additional sessions, however, may pull the proverbial rug out from the user’s activity in other applications. Be sure to understand all the sessions that are created when a user authenticates as well as any other applications that depend on the same sessions, before finalizing desired logout behavior.

How Will Browser Configuration Influence Sessions?

Be sure to understand the impact of browser configuration on sessions. Some browsers have configuration options to reconstitute previous sessions after the browser has been shut down and restarted. Do not rely on browser shutdown to terminate user’s login sessions. In troubleshooting user issues, support teams will need to be aware of such browser configuration options and how to instruct users to start a clean new session when troubleshooting. In addition, be sure to ask if your application will be accessed from shared devices and if so, consider how to protect users that forget to log out.

Session Timeouts

When users log in, for how long should their session remain valid? If they forget to log out, should their session be terminated after some period of time? You may want to have an idle timeout that occurs when a user has been inactive for some period of time, as well as a maximum timeout that occurs regardless of user activity. Don’t forget to consider the appropriate timeouts for MFA sessions and whether users should be allowed to bypass MFA from known or frequently used devices. Similarly, you should specify whether users should go through the MFA flow every time they log in or will be allowed to only do it periodically, such as every 30 days.

Learn more about how session timeouts are managed with Auth0.

Deprovisioning: What Happens When It’s Over?

Parting is such sweet sorrow… or not. You should consider whether there will be a need to terminate or suspend a user’s account. You should consider audit needs which may dictate that accounts be suspended, but not deleted so that if fraud is detected at a later time, you have sufficient information to tie a user ID in a log file back to a real person. You should also take into account your data retention policy - you do have one, right?

Last but not least, you should ensure specifications in this area align with any relevant privacy regulations, such as the GDPR, that apply to your target user population. Be sure to research and comply with any “right to be forgotten” clauses in privacy legislation for relevant jurisdictions.

Password Reset

Nothing lasts forever, and passwords are no exception. Be sure to design flows for users to reset passwords, both when they remember the old password and when they do not. You should also specify the requirements for password complexity and whether passwords should expire, requiring rotation, and if so, how often. There is now a debate about whether password expiration and rotation is helpful or not, so you should read up on that and consider the latest recommendations on that front. Forgotten password reset flows are a common attack vector for hackers, so be sure to include these flows in your security testing.

Additional reading: Easy Ways to Build a Better P@$5w0rd.

Source

Blocked Users

It’s a fact of life that, well… life happens. Be sure to consider whether there will be situations where users need to be suspended for a period of time. This could be due to delinquent bills or something as innocuous as someone being on temporary medical leave. Consider the situations that might arise and how to flag users impacted by such situations as well as the process to unblock them when the situation has ended.

Anomaly Detection

To protect your application you may want to automatically detect anomalous situations such as:

• A particular user having a large number of failed logins.
• A user logging in from two widely separated geographic locations within a short amount of time.
• Users whose credentials have been compromised and published on the internet in databases of hacked passwords, such as Troy Hunt’s haveibeenpwned.

Auth0 provides three built-in shields that detect anomalies among users in an app's system.

Privacy/Compliance Requirements

Be sure to dig into privacy and compliance requirements up front as they can be time-consuming to fully understand and can impact core processes such as user signup, use of user profile information, and data retention practices as well as logging and backups. There may be several processes you’ll need to implement to respond to user queries such as what information you hold about a user and processing a user’s request to be forgotten. Requirements differ somewhat by user location, so you’ll need to consider the jurisdictions that apply based on where your users are located.

Audit Logs

You will want to define your requirements for logging and ensure that you will be capturing the information needed for security and audit needs as well as any marketing analytics or charge-back purposes. Consider how long you need to keep logs, weighing audit, security and privacy needs. Logs are most useful when they are actually checked, so you’ll also want to consider how to export and analyze logs data with any of the powerful logs analytics tools that exist today.

Consider How Identity Information Might Change Over Time

Don’t forget to consider how identity information might change over time. Will usernames need to change for any reason such as legal name changes? Might a user’s status change, such as in the case of a temporary worker becoming a permanent employee and if so, will the process result in overlaps of state where the user has two profiles in existence at once?

Recap

Auth0 has written some guides for typical customer scenarios that may help you flesh out additional requirements:

• B2C scenario
• B2E scenario

The above list of points should give you a running start for what requirements to specify for an Identity Management project focused on authentication and authorization for your applications. By identifying and planning ahead for critical requirements, you’ll reduce the number of project delays caused by critical requirements surfacing part-way through the project. You can further reduce risk by identifying the requirements that will be hardest to meet or involve the most unknowns, and scheduling work on those areas early in the project plan.

In part 2, we will cover some things that can change over time or go wrong with the identity aspects of a project. Read How To Have a Successful IDM Project (Part 2)