Flemming Hartwich: IGA - the Right Place for Identities?

The case I'm ten two present today is from a current project I'm working at, I'm working for a global green energy company that started the it security program more than two years ago. And as part of the, the security program, they initiated an IGA project for acquiring a, a new IGA platform.

I joined the project 18 months ago with the task of creating the framework, the processes, the governance, the policies, and also look into the identity data side of the, the project and started with the, with the HR department to look into the, the processes surrounding identity management, life cycle events, and also how they handle organizational changes.

We soon discovered that the, the identity management side of, of HR were fairly good, fairly automated lifecycle events, fairly accurate identity data for employees, but at the same time, diving into the processes about identity data lifecycle management, we found that across the entire enterprise identity data were created in many different applications across the different it environment, with no link to the E I P system and not using the EAP system as a authoritative data source.

So we came to realize that the, the external identities, and there are quite a lot of external identities in this company. They were created not only in D I P system, but in multiple applications and with very different governance and policies. So we needed to, to take a full enterprise perspective on data and look into the different processes and started a new analysis solely concerned with the identity data and ask the question, why do we create identities? What is the purpose of these identities that are created across the company?

One answer for that from HR, for people management and from the Ida project, they would say for access management and other business requirements and business processes turned up. When we asked the question across the, the enterprise, a new question then arose, that was where should identities reside? Because if there are so many different business needs who own an identity, who is the owner end to end of, of the life cycle for an identity turned again to HR, it said, well, we own identities, but only until data is updated in the IP system.

Then we have nothing to do with identities and external identities. We do not want to own external identities.

Again, taking the enterprise perspective. We, we started rec gathering all the business requirements and then realized that an identity that's not a terminology that is commonly used and known across the enterprise. So we needed to define what an identity is. Looking at the, the, this information model. This is one that we came from, that comes from the Danish agency for digitization. They created the information model implementing the national standard for identity assurance levels.

And it states that a physical person is an entity and that the identity that's a digital representation of that entity. It also shows that an entity can have multiple identities, and that is fairly accurate for what we, we came to learn, because if we take an employee within the, the energy company, they would have a corporate ID, but dealing with energy, you could also be a customer being an employee, and then you would have a private identity within the customer system.

So now the same person, physical person would be created with two independent identities with different attributes and different identity, sorry, identity identifiers, the unique identities were not being be the same. And looking at the different corporate identities from externals, they were also created differently across the company.

So we needed to, to go back and look at the enterprise perspective and say, well, if we need to be in control of the identities, we need to have a context approach to the identity creation, especially for our access management access management will be a context based concept. So we need to break, break these two concepts together.

Now, going back to our question, where should identities reside and, and why do we create identities? We started to look into different ways of, of handling these identities and connecting these identities to the organizational structures as well. So we started looking at the different organizational structures because their depiction of where people reside within the organization.

Now, an org chart is a good way of start to look at people management, who are your manager to do at the station and approval processes. But we came to, to, to that conclusion that this is just one way of looking at the identities relation within the organization. And that many business requirements were related to different organizational structures, such as the finance cost structure, but also projects and other ways of depicting organizational structures.

And as the company, and many other companies are getting more and more agile matrix structures is going to be the most predominant way to depict the relations between identities and different organizational structures, but matrix structures. We can't find any authoritative stores for matrix structures, and we would not build that kind of structure within the IGA platform. And going back to HR, they were saying, well, we are just own the data for people management purposes. If anyone wants to have any other organizational structures to need to create them themselves.

So we were like stuck in the middle between your so so-called authoritative data source from DEP system and the IGA platform needing all of the different structures to do access management. So we went back to the drawing board and started looking for inspirations from, from other projects or other business areas. And we looked into new municipalities in Denmark because the municipalities in Denmark are very complex and diverse organizations.

And they've been dealing with these issues, these complexities for many years, and they actually created five, 10 years ago, an open source platform that can handle the complexity between multi persona perspectives and multi organizational perspectives. So we created a new, a new addition to our identity model.

We would have the organization parts as well into our information model to get the relations between the identities and the different org units, to be able to do access management based on the different organization units as well, and be able to show compliance within the organization as well for, for where do identities reside? What are the purposes within these organizations?

What are the business purposes for using identities within these different organizational structures and, and building all of these capabilities that came out as a box with the open source solution from the community, sorry, municipalities in Denmark, the, their open source community. And, and we created a, a high level target architecture based on that open source solution called it the global identity repository.

Now building on top of the open source solution, we need new capabilities in order to, to, to be able to, to meet all the different business requirements and all the different business purposes using identities. If you look at the left side of you can see there's the onboarding process for employees, HR is always a hassle in my experience when it comes to, to onboarding processes for employees, they want to own the process. Fair enough. You can own the process for onboarding the, the employees, but we need to be able to handle the externals in, in a similar process.

Instead of having all the externals created in many different applications and it environments, we need to have the, the, the onboarding process for externals similar to the one in the EMP system. And that is going to be created within the global identity repository.

Now, if, if you look at our, our information model, you could see that we had the entity. So now we need to correlate the internal identity with the external identities, because as a big global company employees, they shift around being internal to external. They shift around different company, external companies. So we need to correlate data every time there's a new identity being created either in the EAP system or on the supplier side. Now compliance is, is a very big issue in the energy sector and, and new regulatory compliment are, are quite, are quite in focus right now.

And especially it's a processes about identity is, is a, is a very valid business requirement from, from especially the, the offshore sector and the, the suppliers in this case can connect their identity provider directly to our global identity repository through an API. So every time there's an event change in the identities at the supplier side, they can push the data to our identity repository. We can then do approval process. We can do core data correlation process, and then we can send that data to all the different applications who need the data for the different business purposes.

So we can send the data to the P system. We can send it to the IGA platform or other what we call grr clients. At the same time, we are going to open our database as well for the business units, the data steward. So they can create all the different matrix organizations and, and get the global identity repository to be the authoritative source for organizational structures as well, and connect these organizational structures to the Ida platform to do perform access management. We can also do reporting.

We can on all identities and all the organizational structures, and, and we can for audit purposes, document past, present, and future because the, the, the database is a by temporal database technology that we use. So we can show how should data look like? How is data in reality? And when did the change occur and do the, the data correlation on, on that side now going into a project like this data and data sources are going to be a critical factor, and we are working closely. Actually we working in parallel with the IGA implementation.

So when the IGA platform connects to new target systems, we import the data from the target systems, correlate the data against the, the database to ensure that we, we get the appropriate data that the attribute needed are maintained in the right place. If it's attributes needed, for all applications, we can maintain in the global identity repository, or they could be maintained within the application itself as more and more Dr. Clients will be onboarded during the, the next phases of the project. We'll also get more and more data eventually as with an IGA project. This is a life cycle event.

We are going to, to manage this for for many years and, and have a, a long perspective on data. So what we are trying to do right now is, is build the capabilities to correlate data from all the different sources into our information model, get the approval processes, get the adaptation processes, and get all the capabilities in place. And then start connecting applications, start building the, the data into the application, get the, the data accuracy, get the data quality heightened.

So if I just go back to my, my drawing, and if, if we, for instance, have a project that is initiated in the future, as part of the, the project start, a project manager will create the organizational structure within the global identity repository. So the project will be an, an op unit within the global ID repository, and the project manager will connect identities to that op unit. And now it updates to the identities. They will be reflected within that project organization.

And we could do attestation processes to help the manager remember to, to groom the, the organization and units, so to speak with the right members. So access management wise, we would always have the, the, as most, the most accurate data as we could from the, from the global identity repository, we could also use any other kinds of organizational structures and, and, and provide them to the IGA platform or the other different gr clients that we're going to have.

Again, based on our information model, we know who the physical persons are, and then we can correlate the identity data to the physical person. Now, in the process, we are also going to look into physical processes of identifying a person. So going back to the ANSYS, I showed you from the agency for digitization, the, the, the processes for identity proof is actually part of their assurance model.

And we are going to reuse some of the, the process steps to ensure that we know the physical person is validated for instance, for biometrical or passport with, with any unique and physical identifier. So we can create the digital identities. So we are looking for, from the physical identity proving process and into the digital processes as well.

Now, the object for, for our project here is that we need to be enterprise compliant on all these identities and all these processes. So we are going to build an enterprise model for policies, processes, and procedures to get the enterprise identity overview, which identities are created in which applications, for which purposes, and, and ensure that all processes derive from the identity repository. So we can increase data quality, both in timeliness and accuracy as well.

And that we can be regulatory compliant in the heavy, heavy, heavy regulatory areas of the company where identity management is a crucial part of the regulatory compliance perspective. One of the mission critical requirements states that within 24 hours of an identity change, the, the change should be depicted in all related applications to that identity. So getting the identity from the supplier into the grr, into the IGA platform and out into the application that should be done within 24 hours.

And we should be able to document the entire process from chains at the supplier to chains in the application at the end of the, the process. So this is what we're trying to, to achieve, and we should be go live third quarter this year in parallel with GIJ project. And I would say that the using open source in this case means that the code is actually going to be available at the GitHub. The current code from the Danish municipalities is ended up full documentation is available at the GitHub. So it is also a way to give back to the community that started the entire process as well.

I'm sorry for speaking this far. I know we are a bit late, but I'm at the end of my presentation. So any questions I would be glad to, to stay a, an answer.