The identity management conundrum
In the first of a series of three articles on identity management, Graham Williamson looks at the concept of identity, and the delicate balance between protection and facilitation.
Some time ago, I accompanied a high-level manager from Australia on a “study tour” to Europe to learn more about the use of smartcards for identity purposes. One day, at the Microsoft Executive Briefing Centre in Reading in the UK, we had a presentation from a Microsoft employee who had worked on the national identity card in Belgium. At the end of the presentation, a UK-based Microsoft staff member who was attending the presentation was quite incredulous; he turned to the presenter and said, “You mean everybody in Belgium has to carry one of these cards? We would never go for that in the UK”, to which the Belgian replied, “That’s why you’re getting all our refugees”.
Identity management has a chequered past. History dictates that different communities will approach the subject of identity management from different perspectives.
Some nationalities are quite content with government tracking of their identities. In World War II, the citizens of many countries were required to ‘carry papers’ to substantiate their citizenship. In many Asian countries, it is a requirement that you must carry documents to identity yourself to the authorities on-demand. But in other countries, the tracking of individuals and the need to carry identification papers is seen as something more akin to a police state, to be avoided at all costs. In 1987, the proposal for a national identity card in Australia, to manage delivery of government services, was soundly defeated. On the positive side, people’s identity details are not stored in any single repository and the government has limited ability to monitor citizens; on the negative side, fraudulent claims on government services continue to flourish.
At the company level similar situations exist. Identity data is typically stored in multiple repositories with little ability to join the identity stores in order to form a comprehensive picture of a person’s identity and access rights. This considerably frustrates the organisation’s ability to meet increasingly stringent governance constraints being placed on companies by industry and government.
With the advances in the use of technology and the increased use of online service delivery by both government and commercial organisations, it is becoming more important that we have the privacy discussion to determine the degree to which we want to allow electronic tracking of our identities. The less we want to accommodate this, the more we must accept inefficient service delivery.
The identity management environment is now very advanced. Most organisations are adopting a corporate directory approach either through the installation of a single monolithic directory service or via a virtual directory service that provides a single point of contact for access into the multiple identity repositories in their organisations. There is increased use of automated processes to provision identity information into these repositories and an interest in workflow technology to manage the approval processes.
It is now technically possible to identify a person electronically to a very high level of authentication. The trick is to match the requirement to the technology. Too little technology – and you’re not protecting your assets. Too much technology – and you’re paying for protection you don’t need.
What is ‘identity’? The concept of a digital persona
A person’s identity is a nebulous concept. We perceive a person’s identity as an innate definition of a person that uniquely describes them as an individual.
In reality our understanding of a person’s identity is built upon an incomplete set of attributes that we deem sufficient in order to differentiate one person from everyone else – but it is generally far from complete, and at an insufficient level of granularity to uniquely define them. We typically rely on some level of human recognition that we deem sufficient. If we meet someone in person, we typically rely on our visual recognition of the person. If we have not met them for several years, we make allowances for the fact that they are going to look older. We still might be surprised if they have aged significantly since our last meeting but in general we are able to ‘identify’ them.
If we only talk to a person on the telephone, we rely on our auditory recognition of their voice. We expect their accent, speech patterns and voice inflections to match our recollection of the last time we talked to them. Again, we must make allowances for aging, particularly if the person is young, and we must compensate for poor telecommunications services. In effect, we are content to make compromises in our determination of a person’s identity.
While this human recognition cannot occur in the online world, recognising a person’s ‘digital persona’ must similarly make compromises. We must be willing to proceed to offer our online products and services on the basis that a person’s identity definition is ‘good enough’ for the purpose to which we are going to use it. We accept a level of risk that matches the application.
What are the components of a person’s identity?
An ‘identity’ (a person or business) refers to the unique entity defined by a number of ‘attributes’ such as name, age, hair colour etc.
A person or business can only have one identity in an identity ‘domain’. A domain is typically the environment in which they have an identity definition. A domain might have one, or multiple, identity stores.
An identity is typically defined by a combination of:
• generic attributes such as name, address, contact details;
• one or more specific attributes that are meaningful to the organisation maintaining the identity details.
Generic attributes typically apply across identity domains; specific attributes apply within a domain. An identity is typically unique within an identity domain.
For instance, a bank will store account details, a company will store payroll number, and a town council will store property definitions. Each of these represents an identity domain and they will each have one or more identity stores. The specific attributes will typically make the identity unique.
What about dual identities in a domain?
It is quite possible for a person to play two different roles within an identity domain; and it is here that many identity management environments become unstuck.
For instance, a teacher has an identity within their school. But they might also be the parent of a son or daughter at the school. In some cases, the school might define two identity domains, one for teachers and one for parents, and maintain separate identities in each, but this will reduce the effectiveness of the identity management system. For instance, there might be computer system access that is permissible for a teacher but not for a parent. If the school is defined as a single identity domain, the policy prohibiting a parent from accessing a computer can be enforced; if the system cannot identify a teacher as being a parent, it cannot. Best practice in situations such as this is for the identity management system to maintain a single identity for the person but attach two roles to the identity.
This is an extract from the book Identity Management – A Primer, co-authored by Graham Williamson.
Identity Management – A Primer is available for purchase through Amazon at www.amazon.com