In May 2014, Ian Glazer posted a draft of his Laws of Relationships (for Identity Management). In June he presented these at the IRM Summit. Ian is a member of the Kantara working group on Identity Relationship Management and he has ‘donated’ his Laws to that initiative. It is to Ian’s credit that he actually asked his audiences to turn on their ‘BS detectors’ and to challenge his thinking at will.
This post is the fourth in a series I am writing on the Laws.
This is post is an addendum to my last post which discussed Ian Glazer’s first Axiom from his Laws of Relationships.
That axiom states,
Clearly the future holds more of everything for identity management. Relationship management much be scalable in terms of the number of actors, relationships, and attributes. But those three axes are insufficient, we must also keep in mind scalability of administration.
In my previous discussion I stuck to the actors-and-relationships part of this proposition.
But Ian also lists attributes and administration as factors of relationship management that must scale.
I don’t think they are axiomatic per se as I don’t see them as definitive, or as foundations principles from which other functions or concepts are derived.
I do think they matter and are worth considering.
The administration of digital identity – and all that is entailed – is a discipline in its own right. And depending on the scale of your organisation, or the scope of the technology you are developing it can present a very complex set of challenges.
It is also a game in which I have quite a bit of skin. (1)
So allow me to cut straight to the chase.
Scaling administration is not a technical problem. It won’t be solved with new protocols, languages, standards, or software systems (though such things won’t hurt).
Scaling administration is first and foremost a business problem and requires a better management approach. You have to structure organisations to manage identity as you would any other capability.
If you are big enough to be an identity provider then you are too big to keep the management of digital identity in a single-function box. (2) Digital identity services are too complex in many organisations to be regarded as a simple back-office end-to-end system function. If you do that, your ‘administration’ will never ‘scale’.
Digital identity services need to be based on platform systems and services that are decomposed into discrete functions with effective operational independence.
In a factored functional business architecture for digital identity services each function,
- is responsible for a defined business object or activity,
- produces and maintains a set of data objects,
- provides a set of defined services to the other capabilities,
- collaborates with the other functions to produce cross-functional identity services.
Factoring identity services to reduces complexity, increase flexibility and scalability, and allows us to better organise the management of technology, processes, skills, responsibilities and budgeting.
Functional modularity allows the production of services that can be composed and tailored in different ways to meet different business requirements.
Services that have been too complex to manage effectively, such as entitlement provisioning, can be composed of more simple services and delivered through the orchestration and coordination of well defined sub-processes.
Such an approach clarifies governance and security requirements. It identifies the business objects, data and services for which each production cycle is responsible. It makes compliance with separation of duties, privacy, and repudiation easier by reducing the data access required to meet production needs.
Following Gartner, the Cloud Security Alliance, NIST, and a bunch of peer-reviewed authors (3) I advocate a four-capability production model:
Identity Information Management
Identity information management is responsible for the production of identity as a business asset.
It ensures that identity data is accurate, safe, controlled and appropriately available through technical and business services.
It defines the digital identity lifecycle and ensures that digital identity data reliably reflects the currents state of each identity holder’s relationship with the organisation.
Entitlement management is responsible for the production of access entitlements as a business services.
It discovers and analyses data about identities, identity domains, business roles, organisational affiliations, and application and service roles and privileges. It creates and maintains entitlement packages and access control models that define how identity holders may access resources.
Access management develops and maintains the infrastructure that provides authentication and authorisation services in access transactions.
It is also responsible for planning and implementing access control models, security policies, that are inputs for entitlement management.
It implements specialised services such as adaptive access control and versatile authentication services, mobile access services and token translation services.
Identity analytics monitors, analyses and reports on the use of identity across the University. It has two distinct areas of responsibility.
It provides business intelligence on the use of identity to ensure the operation of identity services is aligned to business requirements and inform planning.
It provides forensic analysis of improper uses of identity and ensures compliance with important governance objectives such as separation of duties, privacy, and repudiation.
The premise here, and I think it is sound, is that digital identity services are no different from any other in that once you have identified your business objects, you have to organise resources to produce them.
You need a production model that defines,
- business objects
When you consider the skills, information, processes, tools, methods and so on required to effectively execute – at scale – the capabilities I defined above, I hope you will agree you are unlikely to find them all rolled up and competently applied by one team, using one product funded out of one cost center in your ERP.
Producing and managing digital identity services – especially at scale – requires a cross-functional coordination of a range of professional capabilities – master data management, enterprise integration services, access management and security services, business intelligence and process management, and so on.
Anyway, the end of my vaguely ranty brain dump on administration end in this plea:
Please don’t think of administration in terms of some system jockey sitting in front of a management consoles choosing settings while a software engine automagically ‘onboards’ and ‘provisions’ and banishes production complexity to a set of cleverly crafted algorithms.
Scaling the management of digital identity is business problem, it will be for some time to come.
When asking about how attributes need to scale we need to be careful. There are actually a number of discussions in the offing. We can discuss what facts need to be collected. And we can start thinking about how they should be structured. And clearly the Laws of Relationships, which provide the foil for this post, is make the claim that attributes should describe relationships as well as agents. (Which in most implementations is already the case to some extent.)
At the outset I have to declare I don’t think scale is the most pressing issue. I think like administration most organisations will get more out of managing the production of attributes and often, as a result, reducing them. (Thanks to a friend of mine (4) who first showed me the boston-ish box I am about to share with you.)
All use-cases for identity rely on the existence of digital identity data. Some of which is encoded in attributes.
Reducing the cost and complexity of producing those data is a priority for the delivery of high quality identity services.
Ideally an identity information management capability will apply master data management principles identity data to ensure identity is maintained as a valued business asset. A master data approach to identity requires the establishment of a system of record that can provide a canonical, authoritative representation of every identity holder in the University.
However, the existence of a system of record for identity data does not automatically address the factors that drive the cost and complexity of maintaining identity data as a master data asset.
There are two factors that directly affect the complexity of managing identity within a system of record:
The number of attributes required to canonically represent an identity in the University, and to adequately support entitlement management activities.
The effort, and with it the cost, of using identity increases with the number of managed attributes.
The number of systems of entry where identities may be created. (5)
The cost and complexity of managing identity data increases with the number of systems of entry. Multiple systems of entry also increases the costs and complexity of managing identity attributes.
The product of these factors may be used to classify four basic approaches to managing identity data within an organisation:
Few managed attributes and only one system of entry.
Many managed attributes and only one system of entry.
Few managed attributes and more than one system of entry.
Many managed attributes and more than one system of entry.
The thing is, identity is not just about identification and assurance (access, authentication, authorisation, etc). It is equally about continuity and integration. Identity gives system a memory, and memory allows a relationship.
So it doesn’t matter how cleverly the information that oils an access request is produced. We may get some automagical big-data web-ontological wonder-protocol that can reliably bind, verify, and assure on the fly by simultaneously juggling shards from seven different social networks. We still have to collect and map our constituents, as identity providers and as service provides – and equally as communities.
I have seen first hand how how attributes grow when directories – and as a corollary identity records – are the ungoverned chew-toy of every system engineer and business process designer in the joint.
For most organisations the real problem is not how to scale attributes – but rather how to get rid of the buggers.
There, I’ve said it. The proverbial elephant.
Generally the more attributes, the less privacy – or at a minimum, the greater the risk to privacy. And incidentally, the greater the regulatory constraints in most jurisdictions.
On privacy grounds alone I am not convinced highly scalable identity attributes are a good thing.
Rather I would advocate for better governance, smarter use, and constraints on the growth of attributes.
I think we need to file this one under ‘user-centric’ identity management and opt for the kind of approach the Open Group’s Jericho Project advocated.
What we need are flexible and governable attributes.
Or to rephrase this in terms friendlier to Ian’s initial vision, scaling identity attributes in a ‘big-data’ world of relationship networks needs mechanisms that can intelligently filter facts about identities – and Ian covers this in his laws with the principle of ‘consent’.
We just haven’t got up to that one quite yet.
(1) I am currently leading an initiative to define a management framework for digital identity service in higher education. Higher education institutions, arguably, have the most complex identity management profiles there are. (So long as one does not confuse size with complexity. For size, government identity services win hands down – but surprisingly the management of civil identity and attendant services is relatively clear cut). A number of Universities in my region are collaborating on the framework and I hope we can publish it soon. Part one of this post is an extended summary of three teaser posts I have published on this blog.
(2) Size is an important caveat for my ‘argument’. Single service providers (relying parties or simple account providers), SMEs and other small scale entities are often in the identity game by virtue of poor systems. Personally I would recommend that below a certain size, you would be best talking to a good IDaaS provider.
(3) There are some IAM software tools and services out there that are well factored – and aren’t just adding features to directories – but my lips are sealed. (If, dear reader, we ever find ourselves sharing a beverage sometime I shall be happy to share.)
(4) jeff kennedy (LinkedIn) A enterprise architect, identity specialist and firm friend. (Blog. Twitter.)
(5) I include in this ‘systems of entry’ that are external to traditional WAN-based identity domains, and which may be providing identity over federated identity domains, or directly from SaaS based IdPs over protocols such as OpenAuth.