Cloudification of Access Management – Lessons Learned from the Migration of a Large-scale Production System

Thanks. Thanks Martin. Thank you. Yeah. Hi. Hi everyone. And welcome to our two talk clarification of access management. And I don't repeat the title entirely to save a couple of minutes.

As, as Martin Martin said, my name is Hala from IC consult. I'm now responsible for marketing and sales, but have a back big background in consultancy. And I'm very happy to have today. SGA from BMW with me, we have a good working relationship for more than 10 years now. So time is going by very quickly. And now we are happy to share a couple of lessons learned. We have. Thank you. And welcome to our presentation here. We would like to give you a little bit of an overview.

What we have done the last couple of years, I guess around three years, we needed in order to be there where we are at the moment. So what we are talking about, we are talking about access management and BMW and how to get there. What do you need to do in order to make everything available for an enterprise access management? So what we are doing is we would like to introduce a central IDP identity provider to grant the possibility of an access and sector access to all applications. And I would like to start a little bit with some numbers here.

So dealing with BMW means that you have a lot of applications where you have to take care of. So we are dealing with around 1,500 applications.

1,500 applications is not that much, but it depends on how often they're integrated in your system. And with this, we have 12,000 integrations at the moment, and this is depending on the single sign on context that we have with BMW. Cause you have different purposes where you want to log in. You're an employee, you are a dealer, you're a vendor, and this is something where we have to take care of. So at the end with BMW, we are dealing with around 20 million identities that we have to take care of. So a little bit of a larger number.

So technologies that we are using with BMW are we are trying to get to standards. Standards are in my perspective, O I D C or a Sam and web agents, but you have to go, but you have to get there. Cause we have started around three years ago with an application landscape that was set up in that kind a little bit. So just for an explanation, what do I mean with that? The C is for cookie based authentication. The O is for O IDC and thes is for Sam in the past. We had three different products in order to get there and to have the possibility to provide these technologies.

And this is depending on the time where we have set it up. So three years ago, we didn't have the possibility to have just one product that is covering all the needs that we had. So we have to start somewhere. And most of the times you start with web agents, you gonna start with cookie based authentication, K based authentication. And all of these things are standards and so easy to integrate. This is what you think of. If you're gonna have heard this for the first time, I was starting with this impression too.

But then I learned from all my applications that I had, it's not just standards, what we have here. We have a lot of integrations that were customized in order to fit the needs that we had at the beginning of this journey. And coming back to this beautiful picture in the middle, the lines that you're gonna see, there is individual code that we had to implement to combine this technologies and this products to work together in order to get a central IDP, you need to combine them so that you can grant a single on all over this technologies.

So a cookie based authentication, starting with needs to have the possibility, also connecting to an application that it is integrated with O IDC. And how do I do it? If you're gonna have to product, you have to combine it somehow. And this was only possible with custom code and to deal with custom code. I guess this is an experience that you all have is very complex and okay, we are talking about a journey to cloud. Why I'm starting with that? Yes. Before. So going to the cloud, you have to consolidate what you have at the moment.

Cause just bringing everything to the cloud, just lift and shift is not solving your issues. It's just putting it to another dimension. And in the cloud, it's not easier. It's more complex. So the first thing that we were trying was to simplify everything. And for this, we have to first search for a product that is giving us the opportunity to bring all these things together. So Come on, I guess it won't switch to the next one. There was a message before maybe it was just switching to the next program. Sorry About that. Okay. So BMW car is more reliable Than That's.

That's how we're trying to build it up. Okay. So if you want to invest in these things, you have to convince your management that what you're doing, investing money is usable for them. Okay. What do you want to sell to your management? You want to support standards. Giving back, going back to standards would mean it is more simple to integrate things and more easy to deal with additional requirements. You want to have a tool or a functionality where it is very easy to integrate additional applications.

Cause if you think of our around 12,000 integrations, if you want to do them manually, you have a long way. Okay. Singers. And on context, we have a lot of them and all needs to be supported and they need to be supported in a way that you don't have one single sign on context, you have this product, then you have this product for the next single sign on context. And so on. This is increasing complexity that you don't want. And of course you have to support the cloud. But before moving to cloud, you have to all everything on premise, you have to support this tool.

So you have to set up a, a possibility where you have to run this in parallel. And of course the most important thing, it needs to be safe and secure. Why do you want to have an excess management? If it's not secure, it needs to cover and secure your data. So what we thought of is an architecture that it is covering the technologies that we would like to have in all so that you combine different user stores and different technologies and exchange the tokens without having a complexity and without having the necessary to have different products in a row.

So we found that with a partner, it is for truck that we have with BMW now where we have the possibility to integrate it. So what we have done in the last three years is moving everything to our new product. We call it internally, web em next. And now we are back to the 1,500 applications with the special requirements. So the most important thing he was while migrating them to our new product is leading them back to the standards. So all the special requests that they had, all the special functionality needs to be taken out and needs to be covered back to standards.

And this was from my perspective, then the, the most important thing that we have achieved with this migration, we are now back to the standards and have the possibility to exchange things much more easily without special requirements, without taking care of special functionality, that it just not supported with the standard. And this is keeping us away from having a possibility to yeah.

To, to interacting with other applications. So these are the mine things from my perspective here and the way that we now have with us, we are now on the left side, we have everything migrated to next and we are able to support all the application also for on premise and for hyperscalers. I have just two on that. It's Azure and AWS. But if you imagine going to China or somewhere else, you will have Ali cloud and other things. And also you have to have the possibility to integrate applications that are integrated into this clouds. Okay?

Now, having everything on premise needs, everyone has to phone Munich in order to get an authentication. It's not that the best scenario in, in the end. It's not that reliable where we want to have it. So the next step that we're gonna do is putting it on the right side. So we want to move our web next now from OnPrem to cloud. Cause this is the next step where we have the possibility that cloud integrated applications that are growing services and internet of things and everything that are hosted in the cloud can directly access IBM next without passing Munich.

Cause this is a prerequisite for the functionality that we want to improve in the next years. Cause with this, we have not a geographical distribution with that. The next step would be not just having it in one cloud, maybe in Europe, but you want to go, for example, to us, you want to go to China. You want to go somewhere else in Asia, you want to go to South Africa. And for all of this, you want to reduce latency and you want to have a reliability and you can ensure this with building up a redundancy on a geographical level.

So if, for example, you're struggling with EMEA. So Europe, then you have to have the possibility immediately switch to another hub. Now this is what we want to have here. We need to have a reliable solution that is granting us the possibility to be always on. Cause this is something that my boss told me, your product, yes, it's this important product. Yes. And we need it. And there's just one requirement then to have, it needs to be available 360 days and 24 hours. So a hundred percent, this is the minimum of availability that I'm expecting from this product.

Cause think of, if you can't log in, you can't use your product. And this is very important for this. And this is why reliability is a key here and how we will achieve this. Haku will explain you.

Yeah, thanks. S yeah. I'll line out a bit. The aspect of enterprise readiness for IM. So lessons learned we had with this migration project, but also with migration projects from other customers to see how we can scale up an identity management on BM fitting, such big numbers of BMW had. So just remember one and a half thousand integrated applications, 12,000 integrations spent in million digital identities. So that's a huge amount and you have to take care and you have to provide special features and requirements and services in order to support us.

But let me first come back on how we support Fort shock and BMW in order to move forward on, on that. So basically we are providing web next as identity and access management as a managed service.

So that's, I am just up and running all the time for a great customer experience. We took a best of breed product that's for truck, we build around infrastructure is code. So in order to have a very high grade of automation and to ensure deployments in a couple of minutes around the world, in the oil cloud areas, we are a hundred percent follow the pattern configuration as code.

So the times where you lock in, in your administrative UI and click and click and click and do a wrong click, and then you have the deployment and then you lock in into a test or integration environment and you click again and then you do the same click stream in production. This times are completely over. And probably a couple of you can remember the times back 10 years ago, 15 years ago, where this has been kind of usual, where you had an operations manual, showing screenshots with click streams for certain products on how to stage a product.

And you can for sure understand how cumbersome this kind of process and how error pro this kind of processes. And so a hundred percent of automation is one very important criteria for success to deliver, especially those requirements, customers like BMW have I'm copying the picture from, from BMW and watch Stephans already has shown. And I've put in where we came to play. That's the kind of service layers piece. So we did the on brand piece as well, and basically laid the foundation to make the smooth trans transformation.

So clicking again, to give you an understanding what's what's in the box, let's, let's unbox it a bit, basically. It's important. If you have a product, a product provides certain features. Most of the time, a product doesn't provide everything you need and providing identity and access management as a service, you expect a completely working identity and access management without taking care on backup and monitoring disaster recovery fail over high availability and so on.

And as Shans boss said, he wants to have next up and running all the time, 24 7 each day, a year in order to allow BMW employees, partners, and probably customers to use the services around the time. And you can imagine a company with hundred 20,000 employees that are starting tomorrow morning, their notebook, or the desktop accessing nearly everything in a digital way. They can't can't work anymore. Probably they can't even grab a coffee in the break.

Cause when the coffee machines are integrated into the network as well, they have only the way the possibility to go home in case the doors at the parking garage are, are opening. Otherwise it will probably be, be blocked in the building as well. So having a standard product for truck in, in the middle, we provide around all those things, unnecessary to having the possibility to have repetitive deployment around the world in different cloud providers.

So you, as a customer, you normally want, don't want to be locked into an AWS to a Microsoft or a Google cloud. You want to be flexible in case Microsoft is increasing the prices or Amazon is decreasing the quality, or you have to roll out for a user base into China, where there is probably not a cloud provider available. You prefer, then you have to use AWS China or the early cloud or something like that. And even some customers prefer to have a deployment in a kind of their private cloud be being provided by their data center.

Well, then it's doable. If you have Cub meters as the common denominator, and you can repeat your deployments everywhere, you can run and operate Kubernetes.

So providing a build and continuous integration and continuous delivery chain and ensures that all this pattern of a hundred percent configuration is code infrastructure is code can be managed in a highly professional way so that all cloud resources can be created in an automatic way that the configuration has to be, is able to, to be staged and with features around like building security, that you have a default configuration, which is secured by default, that you have trust to adapt fine grained settings that are probably customer-specific and monitoring on the operations capability, allowing our support and operations teams to proactively monitor and operate the, the full stack so that we have really a high availability.

And that only rarely, rarely seldom incidents are erased towards BMW. And with a couple of features, I will dive into details for them.

Very soon, we have an providing additional value on top of the product in order to provide an extensive enterprise readiness for customers. And I'd like to line out a couple of them. That's the application owner.

Porwal, that's the aspect of automation. That's the aspect of inheriting configuration, which is a really sexy feature. And the usage of templates. Let's start with the application on Porwal that hopefully makes it easy, like, like shopping.

So you, you know, the ratings like it shop web where you as an user probably are allowed to request your roles. You request your entitlements, you know, safe services from your private life, where you book your flight, your train.

So you, you are booking resources and integrating a lot of things by yourself. So you are the best assistance in person you, you have ever, ever had. And that's true for it. Application owners as well. If you want to integrate in an access management application, you have a couple of drivers. So use an application owner. You will have probably the intrinsic motivation to provide your users the best services. And they say, okay, I'm happy to join.

Cause I, now I have SSO. I have MFA, I have a environment and that's a benefit for my users cause they do not have to remember passwords or other ways to log in and are not outdated and can use the full flexibility of a single on other application owners. Probably the crampy ones would say, mm that's an extra workload for me. Can I move it to next year?

Probably, or the year after? And I don't care about Stefano's target. My system is up and running. My system is so old. I don't want to make any change, something, something like that. And then often in an enterprise, the end to end integration at the end to end release planning is complicated. So he isn't a dictator. So normally you can't say you have to roll it out in the next two months. Cause then there will be, I can give it a try, but normally, yeah, there are a lot of business requests that have to be prioritized re realized. And so it's really hard.

So I have to offer as HAAD service, whether I can do it with one click so that they don't have to have that much work on their side in order to ensure that they be integrated in a single. And so you have to give them advantages to that so that they can do it. And that they're gonna switch over easily App. Absolutely. And providing the Porwal that use an application owner are able to decide on your own when you have to integrate, you probably give them a very long deadline.

So please the application owner to the migration until the end of the next end of this year, then you are completely flexible to align this migration into a new access management or into the access management, whether it's today, tomorrow after your vacation, after your parent leave, after your big release, where you have to provide all the important features and it's completely up to you, and if you support the standard integrations and most of the application do that, you use myd connect.

You use Samuel, you just log into the Porwal, do a bit of configuration, providing some URLs, selecting grant types and so on, and then it's done and then it's done without any, any additional effort for you. And if you manage to convert your application owners in a kind of fan groups and fan boys and fan girls, it works out perfectly. We have had this with another customer who presented yesterday, probably you have been attending the talk that, that Siemens, they had nearly the same challenge. They had to migrate thousand 600 applications within a year.

And they managed at the end of the day's migration of more than 2000 application. Cause they have had this kind of fanboy fan girl principle, then that the user community, the end user community expect the convenience features of single sign on expected features of security. And then it's a kind of, self-fulfilling prophecy. If a couple of your it folks have a great user experience, they will recommend it if you force them. And if you can't convince them, then you have a lot of blockers, a lot of political enemies, and they will just slow down your, your projects.

The next enterprise feature is automation and, and continuous delivery said already a bit be before. So getting rid of manual work, saves time, saves money and increases your quality. Cause when you are following this kind of automation approach, you have everything as a source, a source called in an, in an versioning system, you're using it. Then you have a lot of advantages. So the system is always recoverable. You can completely install the system all the time.

Again, you have, you are pretty fast in, in setting up new environments. So typically use case you are creating a new project pilot in China, a pilot for a new business service in the one. And your development is asking, I'd like to have my own SI or my own web access instance to play around a bit and to do a, a bit of evaluation. And normally with aim, that's not possible. It's too expensive. It takes too much time. I don't have the capacity to deliver, or can you bring extra money with me here? It is. Trust and deployment.

So basically you can get an extra environment for the cost of the infrastructure that is consumed in the public cloud providers and with storing all configuration and re repository, you have any time, a quality insurance in place. As you can make, make releases, you can take releases, you can do a different configuration. So a lot of you that staged software into production, no, probably the, the process is when you are talking to your CSO, have you enabled encryption?

Yes, we have. Have you in enabled SSL settings, have you enabled this security desk? And basically you're saying yes and probably you're looking into the code, but do you do this every time you release? Do you do this every time you have probably an emergency release in a production cause you are fixing a buck. Can you ensure that all your clusters have the same configuration when you haven't semi automated or known as manual deployment? Probably not. If it's all automated, if it's all in the source code, you have the features, you can sign your releases.

You can even sign your releases into a hundred percent sure what code is in production and you have a full audit trail and this will be laughed by every CSO and security responsible within your organization. Flexibility. Multi-instance multi geography in, I think there is a buck in this slide. Can we go one slide back, probably the export in, in PDF. So imagine now a lot of deployments with different within different countries before this, this picture would have been, been shown. A big challenge is if you have to have a global deployment.

So as Stephano said, it's not enough that everyone is heading back to Munich and the Munich will probably be the bottleneck. You have latencies when you do an excess request from, from China and so on.

However, the public cloud itself doesn't solve the problem automatically. So if you are, if you're having your deployment in an Azure or Amazon data center in Frankfurt, then it's still Frankfurt. Then it's AWS, but it's in Frankfurt, not everything can be virtual. At least there has to be a computer somewhere in the world. And the computer is located in a data center and it looks, data center is located in a city, in a continent. So basically you have to use couple of regions, some in the us, some in Europe and probably one or two in Asia, depending on how you handle handle China.

And if you manage to reuse all the deployments, you can set up the systems immediately. You have a devoid configuration that you're setting up for your Munich system, which is basically considers kind of master. And then you can roll out it accordingly. And with the feature of inheriting configuration and utilizing templates, you can say, okay, we in Munich have defined the master system in China and in the us, there will be deviations from the standard or from the settings in Munich, but that's fine. You do not re have to reinvent the wheel. You can stay on this configuration.

You can just, just fork, fork, configuration, establish a new fork for your regions in Asia or the us, but also for different variations of development, integration and test system. Like my example before, if you have a developer community who wants to have a system playing around without another configuration, or you can just give them the default configuration, say, okay, feel free to change it, set it up. You can set it up in China, foreign POC when it comes to car sharing in a mega city or so on. And you can just play around.

And at the time when such an pilot or experiment has proven, proven, right, then you can easily integrate everything back. Cause the platform itself is the same. And you have just a small couple of deviations within the devoid configurations.

Yeah, 26. We have four minutes left for question and answers to Steva to me over the point. So No any questions from the audience, first of all,