Architecting mature and functional IAM strategies for our clients requires us to frequently reflect on the approaches that we have seen organizations take to solve common (and sometimes mundane) problems. One such such problem is that of initial credential distribution for internal user constituents (employees, contractors, temp workers, etc). How an organization creates and communicates a new user’s credential is really one of the first steps in a chain of maintaining a good security posture in the space of identity provisioning.

At the core of this problem is the issue of non-repudiation. Basically, the ability to say that a given account owner was the only person who could utilize their credentials to access any given information system. More information on non-repudiation can be found here.

Over the years working in the IAM field, I’ve seen customers approach the problem of getting credentials to newly created users in different ways. Some (surprisingly many) choose to have their IT departments create new user accounts using a known password or formula (such as: <user_lastname><month><day>) in the newly created system. The issue with this approach is that there is no real guarantee that the account will not be used by a third party prior to or after distribution before the intended user begins to use them. This presents an obvious security issue that can be slightly mitigated by requiring a user to change their password after the 1st use. But, even forcing a user to change their password doesn’t completely solve this issue.

A more mature approach is to have a random password generated that complies with corporate password policies that is then communicated to the user through the IT department or the user’s manager. This still leaves the issue of non-repudiation, since whoever generates and communicates the credential to the user or manager also has knowledge of the credential. However, this approach limits the knowledge of this credential to only those in the chain of custody of the credential, instead of everyone who has been exposed to the ‘standard known password’ or password formula.

The most mature and effective way to address this issue usually involves implementing some sort of ‘account claiming’ mechanism. In this approach, a provisioning system or process generates a random system generated password that is never known to any person. Additionally, a system generated ‘claim token’  is generated that is then submitted to the user that can only be utilized once and within a specific time frame of issuance. The intended user is then directed to visit an internal account claiming site where they are asked for some personally identifying information (PII) along with their ‘claim token’. Once this information is verified, the user is directed to change their password, which is then communicated to the provisioning system and all downstream information systems. Identity provisioning platforms such as those from Oracle, IBM, and Sailpoint all make available the tools required to develop/configure this solution with minimal effort. This approach more effectively protects the integrity of the credential and greatly increases an organization’s IAM security posture with very little overall implementation effort.

This article is part 1 of a multi-part series that dives into specific concepts covered during our IAM MAP activities. More information about the Pathmaker Group IAM map can be found here.