Identity Management for an Extended Enterprise

If you follow this blog you might have come across this article which focussed on different aspects of implementing a centralised Identity Governance and Administration (IGA) Infrastructure.

This vision was carried and implemented at Michelin, bringing together Sources of Personal Identities and use them as input to create Digital Identities in Target Systems where they are used or consumed.

The diagram below represents the system, with Personal Identities flowing from the left into the IGA system and IGA governing these Digital identities and their accesss in the target systems on the right.

With the different design choices, we decided to implement the design with an on-premise solution that responded to both the functional and non functional requirements at that time.

Flavours of Mergers

In a typical world there are 3 basic types of mergers when a Company A buys a Company B.

1. Core IT resources of Company B completely merges into Company A, this often involves integrating the networks and computing devices.
2. Core IT resources of Company A and B interact with each other, without requiring the users of one company to access the systems of the other company
3. Core IT resources of Company A and B remain disconnected, requiring user to access applications across their company boundaries.

Let us focus on the 3rd scenario, it normally has some variations. One common element for all the variations under 3rd scenario is that, Company A would have to give access to some users of Company B.

Depending on the type of IT resource, different approaches and technologies may be used. There are also some software providers who are concious of such needs and are providing support to share natively. One good example is Microsoft that proposes different kind of options to its customers when it related to its Office 365 line of collaborative tools and products. Then there are solutions like VDI (Virtual Desktop Infrastructure) that takes sharing to a different level.

However, many companies like Michelin use a wide variety of products and solutions that do not have capabilities that allow sharing securely across company boundaries.

For the sake of this article, I will use the phrase "Standalone" users and companies to describe users and companies that are not fully integrated with the Michelin IT systems. The focus is only the Identity management of B2E users.

Lets do Quick and Dirty

When the need to access Michelin resources by users from newly integrating companies started coming around 2018, I along with few other members from the team decided to do something that was Quick & Dirty.

It required manual actions from requesters and fulfillers, some workaround to be applied by the users, need for specific IT assets for accessing Michelin resources.

It required:

• All the actions around creation, update and deletion of Digital Identities of Integrating companies to be managed by some Key Users who were part of Michelin Group, who often had not idea of the real users behind.
• There was limited to no traceability on who is requesting, approving the users.
• Reviews of such users had to be done manually, often using offline methods like email or excel files.

We were aware of it being Quick & Dirty, but we treated it as something that would not be a repetitive need. Overall, it had moderate to low levels of satisfaction but it worked.

Little did we know what is coming in the coming years.

Only Constant in Life is Change

In 2021, Michelin announced its People-Planet-Profit approach as part of its "Michelin in Motion" strategic plan. One of the elements that came out was the need to have diversification of the Michelin's portfolio and acquisitions.

If you have worked around Mergers & Acquisitions, you know that it is a time consuming process and takes a significant amount of time from the perspective of both business and IT.

With the shift in strategy of the company there was a need to reduce the friction of access to resources that needed to be shared.

We decided that we need to go back to the drawing board and listen to our users and different stakeholders on their needs.

Here is the 3 principles needs that we gathered.

• User experience : To be able to get access rapidly.
• Security : Access must be secured with the same level of security measures whether it is access by Michelin users or Stand Alone Users.
• Cost and Maintenance : Avoid introducing additional systems for IAM

First things first

Identity and Access Management (IAM) is more about principles and processes than just tooling. Having good design and architectural principles are key to responding to needs of the users and enterprise.

We realized that we need to define some golden rules around management of Digital Identities of Stand Alone Companies to guide both design and implementation of both tools and processes. It would eventually be the first baby steps towards IAM for an Extended Enterprise.

Working together with the business, Enterprise Architecture and IAM, the below set of principles were defined:

1. Any user/identity of Standalone who needs access to Michelin Group resources must be governed by IGA system of Group and must use an account governed and managed by Group.
2. All mediums of authentication needed for accessing the resources must be managed by Group IAM systems
3. Standalone companies must have autonomy to manage the lifecycle of their respective users and personal information of their users
4. Resources that need to be shared with Standalone companies must be exposed to the internet directly or via indirect means
5. Limit the number of identifiers that the users from Standalone companies need to use for their daily work

Consequences of Principles

One key point that came of out of the principles was that we needed a referential for Standalone users who needed access to the Michelin resources.

Possibility to create a Master HR system for all users of the Michelin Group and its Standalone company is not yet considered. So we needed an additional IGA system to govern the users of the Stand Alone companies.

The key criteria of success would be the ability of Standalone companies to manage the access of their users with minimal friction. At the same time, it was required that this system does not act autonomously on the resources of Michelin Group.

So the additional IGA system must interact with the Group IGA system and direct its requests to the Group IGA system. The Group IGA system must be able to examine the requests and take decisions as required.

The Choices

While things were getting agreed and defined, everything was not clear. There was ambiguity on how far we want to go in the journey towards a truly governed extended enterprise but at the same time there was increased urgency on delivering a fairly robust solution that would respond to the business needs.

We needed an implementation that was :

• Flexible : That can be scaled up or replaced if the needs of business changes. We decided the integration between the two IGA systems must be done using a standard protocols like SCIM or REST.
• Ease and Speed of Implementation : We needed to ensure that the existing team has the skillset to implement and run the solution. We wanted to avoid a situation where we needed to integrate new skills within the existing team.
• Cost effective : As the needs would evolve, we needed something that was cost effective in terms of implementation, operation and if required replacement. This created a strong bias towards using a SaaS solution instead of trying to install an infrastructure for this need.

We narrowed down to 3 options that were available for implementing the need.

• Go OpenSource

We evaluated MidPoint solution for the need. The solution was lightweight and quick to implement for simple needs. However, at the time of our implementation it was missing some features like recertification that we would like to implement. The solution's capabilities has increased since. I think any new implementation of IGA must evaluate it before deciding.

• Build In House

This option was considered but very quickly discarded because the effort and cost required to do this did not align with other needs. It is also contradictory to our principle of Buy vs Build for IAM tools.

• Use an SaaS offering from the Incumbent provider

Our current IGA provider has a SaaS offering that could be consumed modularly. We chose this option. The choice was heavily influenced by speed of implementation, skill requirements for managing the solution and easy integration with the existing IGA Infrastructure.

What does the chosen one bring and do ?

• Accessibility : The solution is natively available on the internet and secured by the IAM systems.
• Interoperability : This was the biggest plus point of the choice. We were able to seamlessly connect the SaaS and On Prem solution via REST APIs. The fact that both solutions were from the same vendor allowed us to extract more value of the solution and get our needs prioritized with the solution editor.
• Autonomy and Delegated Administration : The solution allowed us to define Key Users by Standalone Companies. The Key users are responsible for the life cycle management of their respective users. It has been very easy to segregate user populations and provide delegated administration to the Key Users. At the same time the solution is administered by the same team that manages the group IGA solution.
• Access Governance : This model of integration allowed the life cycle management to Stand Alone users to the concerned teams, at the same time the access governance was still managed at the central IGA system that manages the target systems.
• Audit and Traceability : This model allowed that the central IGA system can be used for all audit and traceability needs.

Concluding Remarks

The current implementation has allowed us to move forward and remove some of the obstacles for smoother operations.

There are many questions that have come out of this implementation and everything else happening around us in terms of integration of companies. Most of the questions would probably would be answered only with time.

• Would the need to collaborate across company boundaries go beyond few applications ? We already see some use cases like the Annual "Moving Forward Survey" that needs to be used all users of Michelin Group and Standalone companies
• Would this prove to the first step in the direction of managing a true Extended Enterprise ?
• Should we think of meta directories and delegated federation of identities for the Extended Enterprise ?