Staging & Release Management in IDM Environments

Good morning. Good to be back on stage ports is 100. So can we can start our topic today is staging and release management in identity management environments. And I have to first check, I think it was this one. Exactly. First I had that slide with all the bullet points and how many employees and so on.

I think I, I just checked our photo album about what we did in the past. And for example, we do support the European identity conference. I think that's 2014 or 2015 as a best sponsor evening reception sponsor for the thought what we are contributing to the Contrera initiative. We are a sale partner. We are a microfocused partner. We do enterprise identity management since 2001. So 20 years, I think our experience stands for itself, but let's just jump into the topic.

So, first of all, let's clarify what means staging. If you check Wikipedia, for example, we do have quite a few explanations or referential potential referentials and if you check those, you could come to the conclusion that staging always means to move something from development to production up staging, but on a closer look, especially for those two in the middle staging data and this staging, there's also staging the other way around. So from production to development. So why would you do that? We do have this ups and downs and staging environment based on the entities we do manage.

And for entities, we see it later. Again, it's, I'm not talking about identities itself, but the different artifacts, we do control to do that, or to have a good look to, to, to analyze what to do. We have identified six dimensions or categories you need to take into account, maybe short spoiler, which I have forgotten. What I can't do here is give you a blueprint on how to do that. Every environment is different and to understand what you can do and how you should do that. You have to check those dimensions.

First of all, we have people, all your, your, your, your team members, your identity management team, your, the other teams around, how are they set up? How do they talk to each other? How do they work to each other? Then we have code and conflict stands for itself in a staging environment processes. Very important identity management means process management. In the end, especially for enterprise identity management systems. We have the data itself that might need to be staged governance requirements. What is allowed, what is not allowed in that area and infrastructure in the end.

So all those six dimensions are interdependent to each other some more, some less, and we'll have a look out at most of that. I think this is something that looks familiar to you. Typical staging three tier environment where we do have a development or integration environment, staging or qualification, or however you call it. And in the end production P when I started, when, when we started consultancy for one of our still current customers, they only had one stage production when erroring was tested and done in production in P P like probe.

And it was one of the first things we, we did those days to modify that. And a typical identity management environment might like days you have different entry points, where data come in, we do have different consumers on the lower side and the identity management system itself. So how do you test and develop in a scenario like this to make it correctly and to support all the different teams you might to have need to have this.

So you have different areas where you have multiplied or have special situations, special versions from your SAPR entry, from SAP, C O I COA directories, active directory and so on to test all your different scenarios, modifications, and, and, and, and setups. Some of them could be simulated in, in some way, but you can't simulate everything. So you need to have some real systems over there. So why would you do that? We have one customer where they planned originally to have the qualification stage that in the middle as a final backup solution.

So in case of a total disaster, to part this visual over to that system, that means in that qualification stage is real data. Other landscapes might be again, Wikipedia. There were six local stage, the developers work station.

I mean, everyone has that most likely development, rank integration, testing, staging production life. So six potential tiers. There might be more, but I don't think anyone here has six tiers, no one tier at least.

And one, all of you who do have only one tier or six years, we should talk. We should really talk. So let's dive into the dimensions, people, the most important thing on, in, in staging or infrastructure or management, are people, your people, your team, how are they organized? Is it a dev structure, or do you have development teams and operating teams just moving together? And do I have a point over here?

No, it doesn't work. You have teams from, from, from providers and consumers. So SAP HR team, or the, the active directory team consuming data. And what you need to do is to get them all in line on, on, and together to talk about how to do this staging, how to do release management. So it's not a one team show.

It's, it's a more multi team approach. You have to follow, talk to them. Processes. Identity management means process management. It's not a technical discipline. It's a process management discipline. Everyone who has worked in identity management environments, especially for enterprise identity management, do know that you have different processes from different areas and from different areas. You might have service capabilities and residing data coming in different project method, methodologies out in governance requirements and so on. So processes are also important.

And depending on the processes, you might need to adjust and modify and align your staging strategy, place of birth. Where do the data originate? Usually when we think about staging, it is originated in development code and configuration. You start to develop code in development, configuration in development, you test it, then stage it up to, to qualification. And so on.

You might have business roles you need to define in development, you have internal structures like cost centers, departments, and so on, but you might also have production data, which you might need to stage and soon to lower stages. So you can develop with feasible data. That might be the identity itself, the person record, but also self-service elements like it, roads or hus that were created in production or vendor management, vendor handling. If you do have external organizations created in production. So that might go into the other direction.

What you can see here is that's a usual way to do that from development to staging, to production, and that's for many companies, quite new approach from production to stage to development. The question is, what are you allowed to do here? We'll see that later code and configuration usually goes from development to some pre-production areas to production code and configuration from development, internal work relations departments, internal organizations, roles, also same direction, direction, and who we have the term entities, which go might go into the other direction. So what means entity?

When we talk about digital identities, people tend to see digital identities as person records only, but entities and entity management in enterprise identity management also means roles, department code, configurations, any item you might have as something you need to manage. And that can go into the other direction as well, for sure, in both directions, depending on your, on your infrastructure and how you do that, you might have contract containerizations. So container runnings or microservices, no microservices and containers are not the same. Sorry.

You might have stage isolation definitions so that you are not allowed to have a, at least even a connection between production system and qualification system. So that might be a challenge as well. The code flow Haji move code from the different stages, how to move the configuration from the different stages. And so on. Also a dimension that needs to be taken into account governance. We already talked about entities depending on the type of entity you have. You might have different governments, governance, audit requirements on how to manage them.

And based on those requirements and type of entities, you might need to can them up or down, and you might have static or dynamic objects like static role or static role definitions and different flows. And for governance, you might also have the requirement to do sortation so that you do not, that you do have real data in staging or development, but not with the same name. So example, my identity is named Muller in the staging below. You can do that during the staging process, I would show you a way on how to do that. Internal users, external users, also big question.

So where are your developers developing? Are they at home? Are they working in a, in a closed environment where no one can access that sort ized or even real data? So what we do see here is, again, a typical connected tier situation with four stages, local development, local Def development station production, you know, all this and two ways to do that the other way around, if you need to do that from production to staging, to development, to deaf.

So in a chain or in parallel from production to staging and from production to development, if you do the first one, be aware, this is the living system you work on. So it's not the digital copy of a copy that doesn't change. You might move data from here, entities from here to here, then staging should do something with that. And then you have a modified version for development. So that's a chain and chaining is not a good idea in that area. We had a customer who was doing it that way, but they switched after a few painful years, Jesus model, a stage think approach. How could that look like?

So given the, the, the situation, the idea is that we do have a requirement to synchronize entities, whatever kind from production to development. And the other way around, we do propose a stage syncer functionality. I will show you a few slides here in a second about that, where we do have a three, A three stages approach, three step approach. The first qualify is that entity something I would like to think we normalize removing ideas, for example. And then we have a rule engine, which says, okay, that entity, that normalized entity goes to that direction.

So maybe development or production, or where, same for the other way around, usually for the lower stages code and configuration from the lower stages for the upper stages, for other entities, Identity, data self-service roles, whatever it can go. The other way, we solved that or made a, created a plugin for the SalePoint identity IQ environment.

We, we also make use of two other plugins available in the SalePoint world. One is the push plugin, which is the kind of simulated application and the dev tech API, the Swiss army knife, where you can do have a rest interface to modify whatever object that was my plan to have a real demo here to show you that unfortunately, time and, and, and setup doesn't allow for that.

So I do have the backup slides, which if you, with a few conceptional pages and interviews, first of all, the general concept, we talked about that we have some stage, whatever it is, production development, whatever, and we have product source or the identity IQ or identity database. And from there, we do pick up using a qualification rule, the entities that are allowed to be sent from this stage two somewhere else, we have normalization again, where we remove identifiers, where we can sort normalize and change values, last name, first name, IDs, whatever.

And then we have routing routine information where it's okay. This entity with that set that anonymized normalized and qualifi qualified entity will go to development. For example, we write that into a station.

So, and then based on automatic tasks, manual task, checking tasks, whatever, you can automatically remove that up to the next one. You can do that live. There's no need to redeploy. There's no need to, for, for any downside down times where the system is down. And that looks, for example, like this that's my identity. I was created using a user interface and I got an ID and that identity is then synced down to the next stage.

That's, that's the, the lower stage where we do have another application defined by our staging application. And where do you see, okay, that's, that's the same ID. That means I can with my real account and with a help from other teams as well. I do test and work in a staging environment where I do not only have the identity management system staged, but also a full system setup stage where I can check up changes in Azures in Azure clouds. If I do have a tenant over there, changes in the SAP system, whatever. So I can do that in real life or with real systems.

The other way around example here for a role, a role definition was created in development was tested. The service owner has, was able to test it in the real system with the real setup exactly. As it will look like in the, in the future in production. And he's just clicking it, I say, okay, I'm fine. I'm fine. I can sync it up, check, and then it will.

Yeah, it's, it's, it's basically the same, but it's, it's, it's, it's a different screenshot, but really the same it's then in the next stage, where can tested again and say, okay, fine. I've tested that it works to bomb.

Ready, done. If you're interested, we do have the concept for other enterprise management system as well, currently in beta phase, but already live for one customer. And that's, it may thanks.