Third part of the Series: “Identity Modalities and Personas”
In previous articles I described how the tendency towards “point solutions” and narrow “use cases” block the solution to long-standing identity and access management problems in NHS England (and –in reality– in most other institutions and organisations). It is evident that organisational and “cultural” factors have a role in this fragmentation of the IT infrastructure, and it is also obvious that the ways in which technology is adopted and implemented lead to and entrench that fragmentation. Many times, under the justification of obtaining “low cost results” and “quick wins” solutions are put in place which then become blockers for further development of the digital agenda, or which condem this path to interminable “upgrades” and tweaks of obsolete technologies.
For sure, attachment to given platforms and implementation patterns do have organisation and cultural roots, and –certainly– change has to take into account the complexity of these process, as well as the inevitable drag of legacy technologies. Change has to be negociated and staged with great care and persistence!
Point Solutions and their “data model”
On the other hand, these obstacles are not only organisational or purely based on the inertia of legacy implementations: in fact, in all point solutions and limited scope implementations, we also find deep conceptual problems, misconceptions which lie behind the ways in which technologies are adopted. While there are several such ideological limitations –the IT space has many aspects– one of those is particularly relevant for Identity and Access Management: point solutions and narrow scope implementations invariably share a specific Data Model, a particular way to conceptualise the “user” of a system, the “subject” which is authenticated, the “roles” which that individual may have, and the “person” who in the first place requests or access some data or resource.
In the conventional, “legacy” and product-bound data model. All these levels or instances of the user are conflated into one single data class, and –consequently– all functions and mechanisms are designed around that single “data type”. For the product-bound solution architecture the “user” is at the same time the actor in a “role”, the “subject” of the action and the “person” behind it all. This happens despite the long-standing industry and academic standards that cleanly separate those four moments or facets of the user interaction.
By binding the person to the subject, the actor (the subject in a role) and the user (the subject in a specific session), the conventional technologist creates a singular mix of Identification, Authentication, Authorisation and Permission. And, as it can easily be seen in every point and limited scope solution, the mechanisms which verify the identity are at the same time those that authenticate and authorise access and in many case also those that provide entitlements to particular applications and systems!
“Context-full” and “Context-less” authentication
We call this legacy pattern the “context-full authentication model” because through it staff and workers become segmented, separated into various access paths, and are forced to use many authenticators, passwords, user names and roles as they operate in the NHS environments. In other words, the “logon burden” and the loss of time and productivity caused by the fragmentation of the IT infrastructure ultimately correspond to a specific way in which technology is adopted and implemented in the NHS and other organisations.
To illustrate this, at a very high level, we show two diagrams comparing two situations: one where authentication is bound to authorisation -hence requiring multiple authentication mechanism, and another where authentication is separated from authorisation, allowing for a single authentication step for many classes of users. We call the second –somewhat provocatively– the “context-less authentication” – a theme that has been thoroughly discussed in the IAM Technology Forum and Lab this year.
Information Security specialists, among our colleagues and elsewhere, should not think we are somehow ignoring the notions of “policy-based” or “risk-based” security mechanisms: the approach described above –that of cleanly separating “who you are” from “what you can do” –is actually standard and well-founded. Elements of location, time-of-day, identity verification, etc. are perfectly compatible with the separation of the authentication and the authorisation steps. This requires further discusssion, but for now we will proceed with the description of the IAM Data Model we are proposing.
The Identity Data Model
As part of our work in the NHS Technology Forum and Lab, based on work done in the past four years through the NHS Identity Management Community of Practice and several discovery and standards development projects, we developed a Data Model which –crucially– enables the decoupling of the four moments or levels of the user journey, those of the Person, the Subject, the Actor and the User. While we have emphasised the separation of the Person and the Subject, our model supports further decoupling of the Identity Services especially between coarse-grained and fine-grained roles and entitlements, that is between the Actors (subjects in roles) and the Users (subjects in sessions).
Here is an overview of the resulting four Identity Data “classes” with indications of how they depend on each other and their connections with related data structures. The classes have been provided with indicative “attributes” and “operations” so these can be used as starting points for solution design at each of the corresponding data levels. The further one moves towards the right in the diagram the more concrete and specific the data classes are.
The next diagram, a simplified view, shows how effectively the Identity Data Model can be seen as based on the separation or distinction between the Individual (the Person) and the Aspects or Personas under which she or he appears to the organisation. The following diagram is also more “traditional” showing how basic concepts of Access Control map the the two main classes:
And finally, one more diagram shows how these ideas can be implemented both for patients and workers, with the same logic and the same security criteria. Among the benefits of this approach it is easy to anticipate the simplification and streamlining of large parts of the NHS identity management infrastructure.
Perhaps this last diagram is more difficult to understand for the non-specialist. For this reason, as always we remain available for any conversation or query from colleagues who are interested or even just curious as to how this Data Model might fundamentally change how we adopt and implement technologies, and how we move from a “product-centric” architecture to a true enterprise and ecosystem architecture where the point solutions and limited scope implementations are a thing of the past.
You must be logged in to post a comment.