With remote working and digital interactions becoming more and more common, it is essential for businesses to offer the best possible experience for day-to-day digital activities and collaboration with suppliers and partners. One way of providing a seamless and yet secure user experience is by employing and putting in place the necessary steps toward an Identity Control Tower model as described in this article.
The Workplace and its Collaboration Tools
It’s great to be able to work from anywhere, any device and having the technology work when you need it. More than a luxury, it’s a necessity in the current intensified remote working situation, or for international organisations with very mobile, distributed, fluid users. While so many changes happen during the crisis, your workplace should support your business reconfiguration through enabling staff, partners, suppliers to work with different applications, different teams, etc.
The word “Workplace” used in this context refers to more than the workstations and collaboration tools. It extends to wider areas such as enterprise architecture, application security & identity and access management. Arguably, we’re talking about the wider IT foundation/digital capabilities, to support and enable business needs – the workplace might just be the tip of the iceberg.
Legacy upon Legacy adds Complexity
On the user side, as soon as you go through multiple use-cases, e.g. accessing a legacy system on premise or a Software as a Service application, you are likely to require multiple accounts and therefore a cumbersome user experience.
On the IT operation side, it is equally a burden to make it work: workstations are still most of the time a physical device bound to a rigid corporate domain; they need to be configured, then shipped to remote staff or external parties, and accounts still need to be provisioned in target environments, with access rights set appropriately. All the above usually being different processes which are repeated for each supplier or partner, leading to as many devices and set ups.
More importantly, how secure is this disorganised and overlapping situation? Having visibility and control on who has access to what, end to end and for all environments, is a challenge because of the siloed use-cases. And as users join and leave, applications evolve, the security level likely decreases by lack of keeping accounts and rights accurate.
In our experience at Wavestone, all these challenges stem from the accumulation of new use-cases and technology, implemented in silo, for their own use or limited group of use-cases. The platform, which was first designed with one primary use, has now altered into a manifold use platform with an ill-fitting model and processes. Many organisations today can be proud to rely on a federated platform and modern access experience for cloud applications on one side – and a different, yet reasonably good, experience on internal applications side. However, often both are not integrated and therefore don’t get the benefits we described in the introduction. We believe this comes from the lack of a truly shared model/architecture to support a modern experience, across all use-cases.
.
Figure 1 – Example of a corporate model in which each entity manages identities and their access separately: duplicating processes
One Model for a streamline experience
For this reason and for the future of user experience, at Wavestone we believe in a model based on Identity Control Tower(s).
An Identity Control Tower is a platform to enforce your access policies. Its purpose is to verify access requests coming from trusted sources of identity and determine if that identity is allowed to access a target digital resource. For the metaphor, a pilot willing to get clearance for take-off will submit their flight plan using a trusted channel, and after its approval and other verification by controllers, the pilot can proceed to take-off. If we were to transpose this metaphor digitally, we would talk about a user: in order for said user to access X platform, (s)he would need to use a corporate process which itself is trusted by an Identity Control Tower. Said user would provide their “access plan” (e.g. session token) to the Identity Control Tower. After the Identity Control Tower has verified the authenticity of the “access plan” against its access policies it will perform other checks of context, such as: time of the request, location of origin of the access, trust level of the device etc, the user can then proceed to access the resources. Should these verifications highlight anything unusual or inconsistent in authenticating the user, additional requests can be made to allow the user in (re-authentication or step up).
The Identity Control Tower is under your control and holds the conditions of access i.e. access policies and accepts users from specific sources thanks to a pre-established trust relationship between organisations.
For instance, in the diagram below, imagine a situation in which a supplier is developing a new service in your cloud environment. Users from the supplier would keep their device and authentication process they use within their corporate environment, while the Identity Control Tower (ICT) would enforce access control to the cloud environment – without having to use and manage a different account and re-authenticate. For environments with very granular privileges like AWS, building a decoupled ICT is maybe not a realistic approach and the ICT is then probably the identity platform from Amazon that is managed by your organisation and linked to the identity provider of the supplier. The Identity Control Tower model is basically an extension of federation, implemented to cover all use-cases.
Figure 2 – Access of a Partner user to a Cloud Provider resource through an Identity Control Tower
In another scenario, as seen in this diagram, let’s consider an applicant applying for a job in your organisation, thanks to a recruitment portal you offer. They would initiate an application in your portal using their government-backed digital identity, and once they provide their consent to access their LinkedIn profile, you could obtain a digital CV. For the applicant, it is as simple as showing their ID and giving a copy of their CV, rather than filling-in registration form(s) asking once again for the same standard identity information and risking a typo in their contact details – or even having to send copies of sensitive documents like their passport.
Figure 3 – An alternative scenario presenting the trust relationship between a government ID platform and the corporate
One Model, Three Key Pillars
Using our knowledge and experience, we believe that this model should be built upon three key pillars: a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship.
A Unique Identity Architecture: this is achieved by following a simple rule: don’t duplicate identity data. The less identity records you create for the same physical person, the more streamline the digital experience will be – as cumbersome steps start to appear when an additional account, device or authentication action is required for the user to access the target resource. The key behind a unique identity data is to try reusing the data from its (authoritative) source instead of duplicating/copying it in your own systems. For instance, the suppliers or partners working with your organisation likely already have professional digital identities for their own IT use – what would be the conditions to leverage them instead of re-creating them?[1] The next two pillars contribute to answering this question.
A Common and Flexible Model: The second pillar is to use a common and flexible model to allow/restrict access to information. To provide flexibility, an attribute-based access control (ABAC) model enables granular rules and is well suited to a risk-based and adaptive approach. To make it work though, it is essential to define the “grammar” of the authorisation model: what are the actual attributes used to provide accesses that make sense at the enterprise level? How do they translate into “privileges”? What are their formats/values? When the Identity Control Tower is provided by a cloud provider (e.g. from a Cloud provider as Azure or AWS), the grammar is often determined by the said service. Furthermore, to make this model as widespread as possible across use-cases, both on the identity source side and on providing access on the target service side, we recommend implementing your platform following market standards to maximise inter-operability (SAML, OpenID Connect, OAuth, FIDO, etc.).
360° Trust Relationship: Finally, the last pillar is to ensure the establishment of a 360° Trust Relationship. In other words, perform due diligence and establish confidence thresholds to accept interconnection (“technical trust”) of identity platforms. The due diligence should extend to all upstream processes leading to feeding the platform with identities, for instance the HR/procurement processes to vet identities, up to the IT on-boarding process itself – because trusting an identity platform is a first step for these identities to access your digital resources, you need to be within tolerance of the risk it comes with. This trust relationship should then be implemented through security level expectations, auditability in contractual clauses, and enforced via the supplier service management governance. With such strong requirements, one organisation must be prepared to temporarily on-board suppliers or partners within the organisation’s own platform, while suppliers or partners remediate their processes and platforms to be compliant.
Two key success factors
In order to implement these three key pillars, Wavestone has identified two key success factors: being sponsored by appropriate level of management and building resilience and privacy by design. A transformation programme to establish this model would have implications and requirements in several of your organisation’s departments (HR, sourcing, legal, IT, risk, security etc.), hence should be sponsored by top-management and driven with a pan-organisation approach.
Additionally, as it should always be, the supporting platform should be designed and built with security, privacy and resilience considerations from the beginning.
Final Thoughts
As you have been able to understand throughout this article, looking at the user experience end to end and across use-cases is key to really streamline digital services. This can be achieved with a pan-organisation shift to enforce a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship with third parties.
To go further in your reflection on the subject and understand the current state of your organisation, think about these questions and try to answer them: picking users from different departments, what does the typical day to day digital experience look like? How long does my organisation take to on-board contractors and third parties? How does my organisation actually give access to its data and resources for external users? How many duplicate identities exist across my IT estate?
[1] A technical entry might still exist within your systems, for reference purposes – but from the user perspective there is no new account, no duplicate, if they don’t have to register a new login, credentials etc.
