The issues described in my previous article call for a comprehensive solution combining Enterprise and Solution Architecture, but also organisational changes at the level of IT and Architecture Governance. Any experienced professional I am sure will agree that the problems faced by Identity Management are not due to the lack of technical expertise, but to organisational obstacles, ranging from the lack of Data Governance, to superficial requirements analysis and a tendency towards “tactical solutions.”
When considering these problems, the IAM Architecture teams have been conscious, for years, that a major change is necessary in how projects and programmes are conceived and configured. This change can be represented as a move from “product-based” to “requirements-based” Architecture. The following picture summarises the changes in that direction:
It is not correct, though, to see this transformation as a single, “clean cut” move from one type of design and delivery to the other: in fact, in a complex organisation this transition will be a large and laborious process, where the “product-centric” aspects need to be handled within a wider frame or context of transformation. The key idea we are leveraging is that of the different “time horizons” of these two aspects. The “system and product-centric” element should be focused for example within a time window of a maximum 18 months, while the “requirements-based” architecture can plan and deliver for a time span beyond that.
For sure that requires close cooperation and consensus, as well as dedicated Programme Management. Neither one nor the other “directions” can or should develop in isolation, but obviously a condition of this transformation is first the recognition that a “product-centric” architecture only increased the issues we are discussing in the IAM Forum and Lab. This is a problematic that can be found in any large organisation, public or private, and we share these insights conscious that many colleagues will recognise these problems from their own experience.
Now, where to begin to create consensus? How to give foundation to an integrated, well-balanced IAM Programme? We have thought for many years about this, and –together with the Data Architecture specialists and within our own Identity Area, we realised that most if not all the issues around “point solutions” and fragmented implementation of technologies are rooted in the lack of a comprehensive Identity Data Model, one that could reflect not only this or that limited “use case” or small set of users, but one that acted more as a rational classification of the User Journeys.
Obviously we had to blend in Information and Access Control criteria adequate for the NHS business processes and categories of users. A daunting task which took over three years. The resulting model –we can say confidently after testing it with hundreds of colleagues in the NHS and outside of it– is what we call the Modalities of Identity.
Here I offer a short explanation of the model, and a basic pictorial description. This will be further developed in the next article.
Understanding the ‘Modalities of Identity’
The Identity Modalities represent the ways individuals “appear” and/or approach NHS institutions and resources. Originally, we were using the term “Identity Classes” but now we shall reserve this term for the Data Model (see slide 37).
There Modalities describe how to manage different types of identities within the NHS context but also in the wider context of the NHS as a public institution and its own “business” ecosystem. It provides a structured approach to understanding how identities are verified, authenticated, authorised and controlled across the NHS and its collaboration ecosystem, ensuring that each identity is managed appropriately based on its origin, level of trust, and the access it requires.
How the Model is Structured
The model is presented in a table format, with six core Modalities, organised along two key dimensions:
• Identity Data Management Dimension: This dimension differentiates between identities where the organisation controlling the resource also manages the identity data—either as a primary (root) identity or as a secondary (stub) identity—and identities where the organisation does not manage the identity data at all. It is important to note that the NHS is a federation of commissioned organisations, each with legal control over its own resources (e.g. patient and employee records) and identities.
• Authentication and Origin Dimension: This dimension categorises identities based on whether they are NHS-originated or not, and the strength of the authentication.
Key Properties
•Managed Identity Data: Refers to identity data that is either fully controlled or partially controlled (as a stub) by the organisation that owns and controls the protected resource. For instance, in cases where a guest user is invited into the organisation’s directory (e.g., Azure Active Directory B2B Guest Access), the host organisation does not hold the primary identity but rather a stub identity. Stub identities can still be controlled by the organisation, such as by disabling or deleting the identity stub.
•Non-Managed Identity Data: Refers to identity data that is not managed in any form—neither as a root identity nor as a stub—by the organisation that controls the resource. This identity may come from another NHS organisation or an external entity. The host organisation relies entirely on federation (trust) with the originating organisation that manages the identity – there is no local record of the identity and therefore no control of the identity locally.
•NHS Originated: Identities that are initially created and authenticated by an NHS organisation. These identities are directly tied to the systems of that specific NHS organisation, which serves as the authoritative source for their verification.
•Not NHS Originated: Identities that originate outside any specific NHS organisation but may still require access to resources controlled by an NHS entity. These could include identities verified by external entities or federated identities from other trusted organisations (e.g. pharmacy).
•Authenticated: Refers to identities that have been authenticated through a trusted process, confirming that the individual is who they claim to be. This should include MFA and a high level of identity verification assurance, according to NHS policy.
•Weak or Not Authenticated: Refers to identities that either have not been authenticated through a trusted process or have minimal verification. These identities might only require basic access, such as public users accessing non-sensitive information.
These dimensions and properties generate the following diagram:
These six “modalities”, Verified, Managed, Direct-Trust, Indirect-Trust, Self-Certified and Anonymous, offer a wide, all-encompassing model, where user journeys and access control scenarios can be studied and classified. By putting the various Modalities in context, this also allows for a “big picture” where Solution Architecture may be articulated with the wider, longer term requirements beyond the tendency to base solutions and products on sub-sets of the user population while “forgetting” other ones or pushing them towards the “future”.
For sure, this model does not stop at this level; and we will dedicate the following articles to develop it in more detail.
You must be logged in to post a comment.