Is your organization using more than one account username conventions for your different systems and applications? If so, your organization isn’t alone. Since there is no one-size-fits-all naming convention, creating a single, enterprise-wide account username convention is easier said than done. However, using the right methodology, it is not only possible to create an enterprise-wide account username convention, but one that is an optimal fit for your organization.

Now that we’ve built a base knowledge of multi factor authentication (MFA) and discussed the reasons why your organization might need and benefit from it, it’s time to talk about what to take into consideration when selecting and implementing an MFA solution.

In part 1 of our MFA 101 series, we talked about what multi factor authentication is and many of the common terms and factor types. Now that we’ve covered the basics of multi factor authentication, it’s important to consider the WHY. As in, what motivates an organization to implement multi factor authentication?

Multi factor Authentication (MFA) is an extremely hot topic among enterprises, education organizations, and consumers alike. Almost daily, we hear about a data breach being discovered in the news. Often, the response to such an intrusion is for the impacted users to change their passwords and enable some type of multi factor authentication on their accounts.

At the highest level, identity management systems are typically composed of three major elements: users, systems/applications, and policies. Policies define how the users interact with the different systems and applications.

When organizations start or plan to start a new IAM initiative, one of the first steps they take is some form of requirements gathering. The idea is that the requirements represent the functional and nonfunctional (IAM) needs of an organization. Then, typically through some form of procurement, the organization attempts find a solution/service/product(s) that best aligns with those requirements.

Whenever I am involved in the initial discovery phase of an Identity and Access Management (IAM) project, the term Single Sign-On (SSO) always comes up. SSO is often desired or a hard requirement of customers, which inevitably prompts a clarification discussion around just exactly what SSO means to them.

The customer’s definition of SSO is usually something along the lines of “customers have one set of login credentials for all of their web applications instead of a different set for each.” For example, a single “scarter” account and password can get me access to Salesforce and Google Apps versus having a separate “scarter1” account for Salesforce and then an “scarter2” account for Google Apps.  

However, this interpretation of what SSO means is actually only half correct.