Where to Begin?
Most organizations have legacy identity management systems in place, and they’re never easy to change. Regardless of vintage, the identity system must deal with both modern and old protocols, making expeditious decisions a reality of almost every large deployment. Inventive architecture can attach most systems and protocols to older identity systems, adding a lot of functionality without a major project. The long-term maintenance burden may even be less.
Other circumstances augur for a complete replacement and ensuing transition, which must be meticulously planned and executed. Be deliberate in selecting an identity product or IdaaS. The offerings can seem superficially similar, but they often operate on entirely different principles.
Larger identity companies focus on integration with the most prominent services, design for simplicity, and constrain features to benefit from mass markets and economies of scale. We believe one size rarely fits all, and we recommend the use of flexible software that will not lock you in.
User identity data must be carefully curated through a clear life-cycle. Identity management systems need to handle this entire lifecycle, and that becomes much more difficult when federated identity is involved because the identity has become distributed. You will likely have numerous lifecycle processes to accommodate, as organizations typically work with individuals in a wide variety of contexts and timeframes.
Clean and efficient procedures for adding and removing personnel are obviously critical, but during separation, be sure to consider all the destination systems the user has been provisioned to. Removing someone’s personal data entirely is fairly difficult. Most IdP’s elect to just block authentication, which at least prevents access. It’s also common to delete data where possible. It’s unlikely that you will be unable to fully clear a user at the end of their lifecycle.
Deprovisioning user data will become more important as data breaches continue occurring and people become further aware of the fragility of some digital security. We take security seriously, and to do so requires an efficient deployment system that is capable of handling upgrades elegantly. Signet specializes in ensuring minimal data release and knows the basic cryptographic principles necessary.
It’s important to define your person schema well and leverage existing standards where possible. The old X.520 attributes are by far the most widely used, but you will likely want to create custom attributes because your scenario is likely unique. Define your attributes clearly in a namespace you control so that any recipient can clearly identify what they get.
Avoid reassigning anything used as an identifier if at all possible. This can be a username, an employeeID, an email address, anything. If it is the primary key used to access an account or data, then its reassignment could result in the new person seeing the old person’s data.
The primary identifier for the user in your principal data registry should always be independent of the various unique identifiers generated in upstream systems to make changing those systems plausible. You may have to work with some applications to help them understand the variety of identifiers used in federated identity.
Secrecy and privacy are actually synonyms on the wire, and they can be achieved through various means. Please consult with us if you are protecting particularly sensitive personal data to make sure your data is secure from end to end.