It’s that time of year again – time to take stock of what you could do differently, or better, in 2014. If you’re in IT you probably have dozens of things you would like to chuck or change. Cloud and mobile technologies are changing how you do business, and non-employees like customers, contractors and partners are likely accessing your applications at an unprecedented rate.
Darren Platt is the co-founder and CTO of Symplified
It’s that time of year again – time to take stock of what you could do differently, or better, in 2014. If you’re in IT you probably have dozens of things you would like to chuck or change. Cloud and mobile technologies are changing how you do business, and non-employees like customers, contractors and partners are likely accessing your applications at an unprecedented rate. Since Identity and Access Management (IAM) is my passion, I’ll help you narrow down your New Year’s Resolutions to three that will lead you to simpler, more secure and more effective identity management in today’s enterprise environment which seems to have no boundaries.
One: I will not create any new redundant user management systems.
One of the biggest challenges is making sure people have accounts for the services and applications they need and that they are allowed to access the appropriate data, and nothing more. This is due to the fact that almost all of the applications that were written in the 20th century were built requiring a local user account within their application for authenticating and authorizing users. Such procedures have led to an enterprise architecture where the same person has separate usernames and passwords for all of the different applications he or she uses in the course of work. The result is a system where users have very poor password ‘hygiene’ – they will do things like use a common password across many applications, write passwords down and leave them somewhere easily accessible, and use the weakest passwords that policies allow.
Multiple accounts like this also inevitably come out of sync for one reason or another, resulting in security violations. For example, when an employee leaves a company his manager and the IT department are supposed to remove him from all of the systems in which he had an account. If the employee had been given access to a system his manager and IT team didn’t know about, his credentials would remain active after he left the company. We call these “orphaned accounts,” and they can wreak havoc if a former employee takes advantage of them. Another example is when an employee’s role within an organization changes but his access privileges do not, and he’s still able to download things he shouldn’t.
If your enterprise already has a repository where its users’ information is maintained – the way we use Active Directory for employees today – then use that existing directory rather than create a new one for every application or use case.
Two: I will let my customers use existing online identities whenever possible.
Your users often have an existing account with an entity that can authenticate them for you – Google, LinkedIn, Microsoft, and Facebook are common examples. Wherever possible, let users leverage those other existing authentication systems rather than creating a new one. You’ll be giving them a simple user experience they’re already familiar with, and they won’t have to maintain a new credential.
When your customer is another company, let it authenticate users for you using standard federation protocols. While you might want to track information about end users, you can still enable a third party to authenticate them at runtime. Help desk savings will be significant.
Three: I will enable my Native Mobile Application developers with Identity tools.
Enterprises are quickly building out a portfolio of native mobile applications for their employees to use. If you’re one of these companies, you must leverage existing user accounts rather than creating new accounts within these applications. And don’t require your native application developers to develop the (security) code to authenticate users and handle the security token translation and processing needed to make REST API calls. Instead, provide them with a platform and/or APIs they can leverage for these functions and let them stick to their core strengths of building apps to support your business. Otherwise, you’ll end up with inconsistent and ultimately insecure app implementations.
About the Author:
Darren Platt is the Co-founder & Chief Technology Officer of Symplified
Before Symplified, Darren was one of Ping Identity’s first three employees, leading Ping’s technology strategy and its transition into enterprise software. At Ping, Darren was given product, development and team management responsibility for Ping’s conformance services and led the entire lifecycle of Ping’s SOA security product, PingTrust.
Prior to joining Ping in 2002, Darren was Securant’s first vice president of engineering in 1996. There he managed the first three releases of ClearTrust through 2000, and grew the engineering team to 40 people under tight bootstrap budgets in the hyper-competitive dot-com hiring boom. Darren co-authored AuthXML and represented Securant on the standards bodies. With the sale of Securant, Darren managed the transition of ClearTrust into RSA’s product portfolio and continued to represent RSA on the standards bodies.