Data Driven Implementation of IGA

I've been talking about this subject for a long time on LinkedIn. Now we actually preaches what we do ourselves. So this is our own case, not just conceptual. So without any further ado, first of all, we are going through a, nothing much happens here. Okay? We'll be going through an introduction first. Can we get this one to work? Thank you. Okay. We are going through five points.

First, the setting the concept, it's what we are doing here is, is is IGA as its finest call. We are governing our identity policies. So to understand our case, we need to deep dive into, I've picked three policies. They have been generic written, but they are reflecting the policies that we're having.

Oh, it works now. Perfect, but a little bit about me. Not only have I been working in this field for 15 years privately, yeah, this is me. I'm trying to do a little bit of gymnastics. My 41 years old body feels that, so that not so much anymore, unfortunately.

However, IGA, what is IGA? You have hearing for IGA for several years on EIC, Gardner, other conferences, other passwords and articles. At its core then it is governing your identity policies, many who implement their things, policies technically. So I implement policies of access in this product or application or whatever. I take it a little more literal policy in my book is at the highest ulence of the organization. So the lifts alongside your security policies, your anti-money laundering policies, your fraud protection policies and ev, everything like that.

So they're owned by the board of directors. So they tend to become fluffy. Many of these are high level meaning that, well, we need to know anyone who access our assets.

Okay, what does that mean? Anyone with a user account or credential needs to have an owner.

Okay, also fair enough, very easy to understand. Then the four I principles, access, certifications, whatever we need to at least have to prove to persons who certifies or approves something.

Well, it sounds very easy when you write these and everyone in here who's been working in this field knows that implementing these, there's a lot of downfalls and pitfalls and you're getting a platform. Can it integrate? Can it not integrate? What do we have to manage in this? Do we have to manage everything offline and so on and so forth? When it comes to this, IGA is not covering only. What you can integrate to it is you need to actually use this tool to be I to be able to identify, monitor, report, and govern all of these policies.

So just because you cannot integrate to it doesn't mean that you should not visualize it to make this case a little more complex. In our business, this is how we are organized. We are the red of, for those who does who are travel colors, we are the subsidiary two in our group, our IGA scope legally and organ organizational is only coverings of CD O2. Our authority source, the HR system covers the entire group. So all data in there is from the entire group and now we starts coming into these PII regimes all around the world.

So we have EU GDPR for everything in eu we have the US PII protection rules over there who are almost as rigid as EU GDPR for US citizens. So how do we come about this integration to a source where we need to filter this because there's all sorts of things.

Oh, this guy, he works in group well, he needs to have access in our systems because he needs to help us, okay? But we need to have them in our identity and management system or IGA system because that's our policy. We need to know them. How do we do that? How do we fill the data? Only when we needed some of these things came into early identified challenges. The first one we just spoke about that. So how do we filter that?

Well, one of the other policies that we had was that we never changed this personal account. So usernames, we prefixed this an external with an X, it must never change, but when you move from intern to external, you are actually changing from to another rule. So that's a contradicting policy upholding the forest principles. So if we un onboard someone from us into our system, his manager from the HR system fed by our HR system is someone in the us. He's not onboarded in our system or he's not onboarded with accounts. He cannot log into certify. He cannot log into a proof.

So I very quickly turned into this. I've been preaching for many years that why don't we tackle this from governance first, data first, analytics first and to enable to make decisions. We need to have transparency. To have transparency, we need to have context and to context, we need to build that context with analytics based on data. So how do we do that in a product we have Joseph Sian, which is a cloud platform. So it works in a certain way. We cannot customize much in that platform, so we cannot granulate access inside the platform.

If there's an identity and you can see identity, you could see everything on identity. So how did we do this? Then I went back to one of the concepts that they had a couple of years ago where, well, why don't we just treat all sources? Also author sources as just an endpoint import. This is accounts we don't even have to match them to identities, just import them.

The second that I have the data in my system, I can do an analytics, I can do calculations decisions inside the platform and the good thing about endpoints is I can show only a few people who's allowed to see this data can have access to the endpoint and endpoint is such a funny word because an endpoint is we talking about a physical system, but inside an iga it's just an isolated database. It acts like I was integrated to this, but basically it's just a virtual container where we dump data. By doing this, using our analytics, we were able to do with something very simple.

We started importing an account, just import them as they were. When we got that data and we realized several different things where we also had other identified challenges. One of them is that we did not get the employee ID directly of the manager of the identities, but what we did was we got their email address, but if this was an out of scope identity, he had another email inside the system that we would create him with in our active directory in our email systems. So we could not use that to match if it was on the identity, but on the HR data that email never changed.

So one of the things that we solved that we didn't even see as a challenge before we did this that we saw it was a challenge. Oh wait, it took me five minutes to realize, oh, but we just solved it by using the data we have on the endpoint. The good thing about SAVI is that all analytics you do is exposed with APIs. So just running analytics on the screen is not dangerous. I mean it's just outputting. You're just seeing a fancy report. You are building a lot of queries so you can build whatever you want. It's outputted on the screen, but it's available as an API.

All IGA systems can integrate with rest. So I go take that analytics data and directly just pump it in as identity data. Everything I'm able to do now I can base that on analytics, all decisions, all parts of the journey, everything on identity. I can do that on a, on ana analytics first and I can, I can build the analytics into production because just building analytics doesn't do anything. They're just reporting. It's only when that powers up to use that in a connector that it is dangerous for the system if we haven't tested this.

So basically all use cases, business cases, questions, wishes from the business. I can paste that on data. What does my data tells me? Is this a viable use case? Do we have the data that we need? Should we have another data? Who should then decide whether we should have that data from another legal entity? All of that is visible in my, in my data set, which these letters to this is what I hope that you could use because this is literally the list of phases and steps that we took in order to implement this. We did not have much in our development environment.

Actually only when the analytics works, we moved it to our development environment and we tested how it worked when we integrated it with to update the entities, but all the hard work was in the calculation and analytics. We could do that on production data. So it will never lie. It'll never have the issue where everyone experiences that. Now we have in one environment another environment and they're not completely the same. We didn't have that issue because all our validation of things was done on production data and this is basically it. At the end of the day, we are using pure standard.

There's nothing custom customized in this other than analytics and that's what the analytics tool for. You're building your own analytics, so that's not even considered customization. So we're doing nothing that is not out the box. This is an example of an analytics. You can see on the screen here. We have all of these are out of scope. We have a single one who's in scope right here. This guy has been manually brought into scope because someone says, oh, this guy here have a deviation approval. He needs to have an account.

Okay, fair enough. I grant him one token, that one token now marks him that my analytics says, oh, now I need to publish him with first name, last name, all of these kind of things because I need to know him in our system. All I did was add him one flag. Now he's in scope for everything. All his accounts is in our birthright rules.

All, everything runs through all our rules and all our policies. So assigning him roles, removing him from roles, move scenarios, everything like that is basically already following all the standard procedures that we're having. And I could verify this in a, in a interface like this before. I power power that into the entities. Which may leads me to the conclusion which has a little bit more than what you see here and I will come into towards is that it was very fast to implement. Actually we did this way before estimated time of implementation. We did this in budget.

We did this with one, not even full-time ft from the vendor and then me and my colleague who is also here today, in three months, we have full control of each of the steps of the join move lever process. We can do everything that, if that's a requirement, saying, okay, in a mover, the the former manager needs to approve and the current or the the future manager needs to approve something.

Well, I can see that in analytics. Analytics. I have the archives, so who was the former manager, who's the new manager, and each of the steps is where I can step in and say, should this change, We also enables that we can use production safely. We've already covered that, so we'll not get much into that many new business opportunities. One of the things was that our HR system is capable of providing historical records also future records, but what it does is that actually says on this employee ID, I give you all these 6, 7, 10, 17 unique records.

They're just only correlated on the employee id. So just importing those if it was identities means that we'll never be able to turn on because of do a lot of things to mitigate. That would destroy anything. But what I can do now is to analytics. I can say all these accounts belong to this identity. This one is in the past this, this has a secondary mark. This one is now, so this has a primary mark. This is the future, has another mark, and I can always use that in analytics to make decisions and I only have one minutes left, so I will not come in.

So we have a lot of other future business opportunities. I hope this gives a clear picture of using data. You are enabling so much more than you are realizing your platforms are capable of. Okay?