Elevate Your Enterprise With Intelligent Access Management

Hello, everyone. Welcome to today's KuppingerCole webinar, Elevate Your Enterprise With Intelligent Access Management. My name is Nitish Deshpande, Research Analyst at KuppingerCole Analysts.

And today, I'm joined by Todor Petrov, Senior Vice President at ROIABLE, and Bo Baade-Pedersen, Business Development Expert at SAP. In today's webinar, we will tackle the issue around the SAP IDM end of maintenance. We will also take a look at what are the key success factors for a successful IAM project. And Todor will also provide us with his approach on how ROIABLE tackles this issue. But before we begin, here are some quick housekeeping rules. So you all are centrally muted, so you don't need to mute or unmute yourself.

As always, we like to keep these webinars very interactive. So we will be running a couple of polls in this webinar, and I would like to encourage all our attendees to participate in this poll and provide us with your input. We will discuss the results of this poll during the final Q&A session, which will be at the end of the webinar. But if you have any questions, you can enter them at any time using the Livestorm Control Panel, and we will try to answer as many questions as possible towards the end.

And finally, we are also recording this webinar, so the slide deck and the recording will be made available for download in the coming days. Here's a quick look at the agenda.

So first, we will take a look at what's next for SAP IADM migration, the key success factors for a successful IAM project. And also, we will take a look at some of the options that are available as well. And then I will hand it over to Todor for giving us how ROIABLE takes this approach and the Q&A session. But before we begin, a quick poll for everyone. So this is a bit of a different poll. You can select multiple answers. So what is of strategic importance for your organization when the topic is IAM?

Is it A, avoidance of data transfer for sensitive security artifacts? Is it B, seamless integration with SAP GRC?

Is it C, having one central solution for cross-phase analysis for SAP and non-SAP systems? Is it D, is it staying within the domain of SAP solutions and platforms?

Is it E, having an intuitive and configurable self-service for end users, security administrators? Is it F, flexible connectivity and mapping options? Or is it something else? So we will have this poll running in the background. You can select the answers based on your priority. It will be running in the background for the entire duration of the webinar. So I look forward to seeing the results of our discussion about this with Todor and Bo.

Right, so I would like to jump in straight into 2030. You know, it feels far away, but it's quite nearby. So if you want to modernize your IAM or move away from SAP IDM in a controlled, low-risk way, I would say this is the time. And the time is, the first phase is basically having strategy.

Now, ideally, you should have already started with the strategy phase in 2025, but you can also approach this in the coming year. And it's all about strategy. It's about understanding what should be your next tool. It's about defining your overall IAM and IT strategy. It's understanding what your future identity fabric should look like, and overall aligning with your application and access governance approach. Once you have finalized your strategy, then comes the planning phase in around 2027.

This phase is basically about creating a blueprint and a roadmap for your vision, for defining your architecture, gathering your important stakeholders from the technical team, operations team, business team to have requirements specified. And then finally, coming towards the tools choice, which involves shortlisting the tools, having a trial approach as well, based on what works for you. And once you have done that, then comes the implementation phase. So it doesn't really start until, let's say, a couple of years since the strategy phase has started.

So once you have now in the implementation phase, it's about building the new environment. It's about migrating in phases, in stages. And then finally, it's about the completion where you are doing testing and optimizing the system. After 2030, it's all about continuous optimization. You have to remember that this is not a project, it's a program. It's about continuous optimization. It's about having a project that evolves with business. So that's an important thing to take away from here is that the migration approach will take some time.

So if you have not started yet, I would say right now should be the right time to begin with that. And so what do we need for a successful IAM project? But here are some key success factors which we have outlined here. So maybe I'd like to invite Bo and Nitish for this slide as we would like to make it a bit of a discussion around here. So Bo and Todor, welcome to the webinar. Before we begin, maybe would you like to introduce yourselves?

Sure, I can go ahead, very good. Thanks, Nitish.

So yeah, Bo Babade-Pedersen, part of our solution advisor, working with, let's say, our governance risk and compliance solutions and trying to drive, let's say, the business around that. So yeah, thank you very much for the invite.

Hello, also from my side, Todor Petrov, as you mentioned, senior vice president at Roybal, being in the topic for about 15 years. So super excited for this discussion.

Perfect, thank you. Thank you for joining us. We have this very interesting slide in front of us is about key success factors. Maybe I would like to first start with maybe asking a question.

Let's say, what are the enablers that you are seeing as that can accelerate your IAM journey? Maybe Bo, would you like to tackle this one?

Yeah, absolutely. Well, I think, I mean, when we look at enablers in general, right, it's a matter of, you know, understanding what you already have and where you want to be going forward, right? So some of these, let's say, tools that you need to have in that kind of transition phase is to get transparency as to, you know, where do your users come from, right? So making sure that you have a good structure around the source data, making sure that you have, let's say, the right processes, right, for managing, let's say, the identity lifecycle management around it.

So that means you need to have some level of a very good understanding of the process, right, for managing identities across your different solutions and making sure that that's documented, that you have clarity as to, you know, who's responsible for what during what part of onboarding or offboarding or changing a person's position within the organization.

So I think it's about having, you know, clarity and transparency as to what the end goal must be and how you actually efficiently can get to that, making sure that the data quality, right, is present and making sure that you have full visibility into all the, you know, different areas of your business as to where do we need to have access management, where do we need to have, let's say, identity processing, going from a physical person to an identity and then provisioning them with the right business logic.

I think those type of enablers is absolutely key that you have that way of consolidating. Perfect, thank you so much.

So, I mean, let's maybe, I would say that implementation is not the focus in this process. It's about just the strategies, the planning, requirement, gathering the requirements and having an overall organizational alignment with the people's processes and policies as well, basically, right? Absolutely.

Well, and I think that kind of ties very well together, you know, in terms of the whole setup, right? When you look at it that way, so personally, right, I would say, you're right, you know, we can't look at the project initially, but you still need to look at, you know, the end goal in terms of what is it that you want to achieve, even from a strategic perspective and to make sure that you kind of have those, let's say, requirements put out in very clear language upfront, right, that you have, you know, what are the different, let's say, policies or procedures that you need to comply with.

You need to understand all of these different requirements upfront before you actually start engaging it. And part of that, right, is I would think in many cases is business and conducting business as you've already done, you know, in the past, but now you need to kind of have a tool that goes in and actually automates part of that process. So where can automation actually help you, you know, take out a manual effort, right, that is no longer needed?

I mean, nobody wants to do, in my view, nobody wants to do an IAM project if there's no efficiency gain at the end of the project. So from that perspective, I think, yeah, it depends, but I think there's a lot of tools out there that can help you. Let's understand the processes, understand the flows, understand, you know, where the source data comes from and how you need to analyze that, but you need to put it into the right context.

Perfect, thank you so much. And maybe I want to touch a bit around the architecture as well as that is involved in the planning, budgeting phase as well. So do you think the future of architecture of IAM is pure cloud or do you think there's still some, let's say, an instance to stay on-premise or having a hybrid approach? So from my perspective, I think at some point in time, right, I mean, not all businesses will be able to, you know, go full cloud, right? I think that's just how, that's reality, right?

But I do feel that when we look at where the majority of customers are going and the services that they will be consuming, you know, going forward, absolutely, I think, you know, cloud is what needs to be in the center of all the different, let's say, IAM structures or need to be thought into that whole process, right? But that also changes a lot of, let's say, the strategy around how you want to develop your IAM cases because you're going to have different security concepts based on where your different solutions reside and how you want to approach that.

But to the main question, it is, I think, you know, do we believe that it's going to end up in cloud? Maybe, you know, longer term?

Yes, absolutely. But there will be a long transition phase and this is not, you know, this is not easy, right? That's the main thing. Absolutely, I agree with you, yes. So I think that brings me to the next slide about talking about the transition and the replacement as well is, we have these three pilot phases which customers need to decide between. Is it first the stack along with the SAP IDM or be involved in the code selection or the migration phase?

So apart from these three phases, do you really see customers having a different plan, a plan B or you would say this is where the customers need to decide between? Well, so two things right to this one. If we look at SAP IDM, I don't think there is a plan B. So you need to transition. So it's not a matter of whether or not we can sit and wait and then something is going to happen. We are talking about a solution that from an SAP perspective is no longer supported, is no longer being developed, is no longer being offered to customers.

Customers that are on the platform, they can definitely continue using it until let's say end of life. But I do feel that there was a, you really need to consider like what is the next phase for you from an IAM perspective? What are you going to substitute your existing SAP IDM solution with going forward? What are the integration points and how can you do that? How can you make a transition that is going to have the least impact on your business, but still deliver all the functionality that you've been used to in the past?

And I think that's where, at least from my perspective, at least we see different opportunities that are available. But we look at partners like Weibo where there is alternatives to the SAP IDM platform. And I think if you need to switch and you want to sustain, let's say the skills and the capabilities that you have in-house, you might want to pick a platform or a solution that's close to what you already know.

And then looking at, let's say the tools selection or the migration is that, well, what is going to have the biggest impact with the least amount of resources for an organization to sustain the level of automation and the features available in the solution? How can we make the integration to the new platforms that we might be acquiring the short-term and long-term, but also you need to have a platform that you can grow with going forward. So I think that's absolutely key.

And I think some of it, you have here as risk and disadvantages, it is an investment, and that investment needs to be long-term. There's not a band-aid, quick fix solution to this. Absolutely, I agree with you. I think maybe I'd also like to bring Todor here as well as from Roybal's perspective, what are the trends they are seeing because for us, for PingerCoal, we are seeing some trends, but let's say for Roybal, what do you see? Do you have something to add on this one?

Yeah, of course. Thank you, Nitish, for this question.

Well, the trends are clear, and that's what Bo also said. The time to act is very short. I would say it started beginning of this year or a little bit before that. And the span where you have really, you're able to maneuver for the first phase, even for a tool selection or the analysis is becoming smaller and smaller the more you are pushing it into the future. So I would say the time to act is now, and we see also customers moving this year and also starting from next year not only into the tool selection phase, but actually into the actual migration.

So yeah, and it will be interesting to hear actually what trends Kupinger is also seeing in that area. Yes, absolutely. I think for us as well, we have, I'll go to the next slide so that can give a bit of an idea of what trends we are seeing is, let's say if we talk about just the state of the solution deployments of these different IAM technologies, you have the IGA, Access Management, PAM, CIAM, CIEM, and ITDR as well.

So we did one survey at the start of this year, middle of this year, let's say, and from our responses, this is the result that we got is we asked them, like, what is the state of the solution deployment? As you can see, still several, let's say more than majority of the responses for IG and PAM, but they're still on-premise. So there needs to be some sort of, I guess, a slower shift or maybe not slower shift. As I mentioned, the time was to start at the start of this year, but there needs to be some sort of shift happening for these customers towards a more cloud solution.

And so this was our understanding of the current market right now, but it would be interesting to see what changes as well in the market in the next year when we do the survey as well, if there is a different change in this trend as well. I think next one, I would like to just hand it over to Bo for helping us understand the SAP Ion Reference Architecture.

So Bo, how does, let's say, SAP make it possible for any third-party identity provider to plug to the SAP Reference Architecture? And what steps is SAP doing in direction of making this architecture more accessible for customers? So maybe if you can share some thoughts on this one.

Okay, so first off, right, how do we make it possible for, let's say, any third-party IAM solution to kind of integrate into it? And I think historically, right, it's always been, I won't say difficult, but it would need some, let's say, level of skills, right, to integrate into the SAP landscape. And from that perspective, I think over the past many years, right, SAP has really done a lot to make the whole platform more open for external partners and other solutions to integrate with our solutions in general. And I would say within the IAM space, right, this is absolutely no exception.

So any customer that has a cloud solution will also have a cloud identity service up and running. And the cloud identity service is kind of the crank in the engine, right, for being able to manage access within the different SAP components that exist.

So from a IAM perspective, right, if you want to reach, let's say, our B2B systems or even the backend systems like S4 and others, we do have, and that's also what we have here in the picture on, let's say, in the center, we have a third-party identity provider, identity management solution kind of integration point, right, so we have APIs that can be leveraged from different, let's say, yeah, different vendors out there.

The idea is to say, well, the IA or the SAP landscape kind of changes, and sometimes it changes based on a new kind of direction or acquisition or something that SAP decides makes more sense for our customers in general, right, to create a platform up. So having an integration point for IAM solutions to kind of integrate with makes a lot of sense because then they don't need to have specific connectors to 1,500 different SAP applications in the backend, right, so you can kind of use it as a proxy.

So that's at least one way, right, to say, well, you know, leverage the, let's say, the standard APIs that exist, right, to get into kind of the SAP infrastructure.

And I know that's one part that, you know, you guys do very well as well, but then the other part is also we tend to put things on top, right, so which means that if you have your cloud identity services and you manage your SAP landscape around that, then the other services that kind of run on top of BTP or kind of are already in that, let's say, infrastructure, right, you would be able to manage with an external IAM solutions anyway.

So you don't need to sit there and, you know, decide on how do we, you know, do something different, right, because now there's a new solution from SAP that's been released, so that makes a lot of sense.

The other part, right, that you mentioned around how we make this available or, let's say, digestible from a customer perspective, I think there's a lot of things that, you know, SAP has done over, let's say, the last four or five years, right, where we've released, you know, the reference architecture like this one, right, so this reference architecture is the one that we kind of try to promote and say, well, from an SAP perspective, this is kind of the foundation for anything that happens, you know, from a IAM perspective.

And I think that was done, yeah, early, mid 2025, where we kind of, you know, formalized that. There was some attempts up until that time where there were different discussions, but we have that and it's listed in the, let's say, SAP Discovery Center, and there's also, you know, different, let's say, documentation and guides out there. I know there's a colleague of mine who's actually released kind of a whole series of blog posts, Gona Kirschner, who's delivered these on identity access management reference architecture, right?

So there's, if you look at our blog posts from SAP, you would find that Gona has released quite a lot of these blogs that kind of describes this in a lot of detail. But also, you know, just if you look at, on this slide as well, right, in terms of the light blue stuff, you have the BTP, right, the Business Technology Platform. So this is the integration layer that we have, right? So being able to integrate into a, you know, integration foundation, right, makes it, you know, all much more digestible and acceptable.

And I think a lot of our customers are using the BTP platform today, right, to develop new applications, new integrations, and so forth. So from that perspective, I think that definitely, you know, makes it easier for customers to get, let's say, involved and understand, you know, kind of the technicalities around that. And then I think, I mean, again, the continuous kind of, I don't know if you've been informed, but we have these kind of customer influence programs, right?

So if customers have a need for enhancements or improvements of our existing, you know, services and solutions, we have this customer influence program that runs where customers can actually interact and help, you know, suggest improvements in certain areas. So I think, you know, we really try to make this as, in quotes, open as possible, right, so that it can be leveraged by customers and they can quickly, let's say, adopt and, you know, use these solutions in the right context and the right ways.

So, yeah, I don't know if, I hope that answered the question, Ditesh, but that would be kind of my take on it. Perfect, perfect. Thank you so much, Bo. I think that brings me to the next question as well that we want to ask to our audiences. How prepared is your organization for IAM modernization in the next 12 to 24 months? You have the options here, A, B, C, D, if you find them in the livestock control panel, please select the answers that you prefer and we will discuss this in the Q&A session.

Now, without further ado, I would like to hand over to Todor for his presenting Roybal's approach in this segment. So, Todor, I'm handing it to you.

Okay, so the agenda today is pretty packed. We have a brief presentation of ROIAM. We also had a similar webinar last year where we presented it in detail. So this time we're not gonna spend that much time on it, but we're gonna focus on four different scenarios for which we have prepared very interesting presentations and demonstrations. At the end, I would like to close with some announcements we have to make. We are very proud of those. So I would like to bring them to your attention at the end.

Okay, so ROIAM, the gateway to SAP and beyond, that's how we code it as a subtitle. And there's a reason for it. What Bo mentioned as well, the SAP BTP platform is not something that is closed into the SAP context and closed for SAP applications in general. It's a pretty open platform that can actually integrate a lot of also non-SAP systems and this includes also their respective security aspects. ROIAM is completely and fully based on SAP BTP, which you can see also from the product architecture.

It encapsulates also a lot of different APIs and open standards like event-based communication or scheme-based communication, which is pretty common for every single security product out there. And of course, let's say in the heart of it, also we have a very tight integration into cloud identity services, which for sure will play a significant part in the future of SAP. As you can see, we're covering not only cloud, but also on-prem solutions through the connectivity and destination service.

And the two major services we are reusing from the SAP BTP would be the SAP Integration Suite and SAP HANA Cloud. Important here to mention, and I go back here to the question of Nitish about the future platform of IEM solutions. I fully agree that cloud must be part of it. And that's what you see also in the core of our solution. But our cloud is a bit of a different type of cloud where we're not offering the solution as a SaaS application, rather as a deployment on the customer sub-account and the customer BTP tenant.

This gives a lot of advantages, which we can discuss later in the presentation or during the Q&A. Now to the interesting part, scenario one, day one onboarding automation with Microsoft Entra and Raw IEM. For this scenario, the architecture is, I would say, rather simple.

We need, of course, a Microsoft Entra tenant and we need, of course, SAP BTP and Raw IEM running and Cloud Identity Services for the synchronization of identities from success factors. So both parts of the architecture on the left, Entra, and on the right, Raw IEM, are synced with the same master data of success factors. And on the left side, what you see additional to the existing services which Entra offers is the Raw IEM provisioning accelerator from Microsoft Entra.

This is a package which we deliver and this package is bringing up logic apps which are facilitating the event communication with Raw IEM, the provisioning, the calculation of the dynamic groups, and so forth. We're going to see that during the scenario. And now a little bit of a scenario use case. What we're going to show you is we're going to start in success factors and there's going to be an onboarding of a new employee.

This employee is going to be synced into Microsoft Entra and with the usage of dynamic groups and respective attributes mapping and our own provisioning framework which is deployed on Entra, we'll be able to give day one access in a matter of minutes to this new employee in this case, actually to two different systems which are assigned to the dynamic group on one side, Salesforce, on the other side, SAP S4. So now it's time for a demo. As we mentioned, we are starting in success factors with the employee that has the first name success factors.

And then we are syncing this employee manually in Entra because the automatic sync takes time and we don't have that luxury at the moment. And you see some attributes are being synced. We have the dynamic group which contains certain applications assigned to it. And in this case, those are, as I said, S4 and success factors. And we have two rows assigned to that dynamic group which means that the moment a certain person enters this dynamic group, they'll also inherit the assignments. The rule is simple. The department should be IT.

Of course, rules can vary and could be different. Our user is part of that group already. And what you see here is our configuration which is extremely easy and yeah, something everybody can do for our scheduler. So what we're doing here is we're just enabling the calculation of the dynamic groups and then we are running the scheduler. The scheduler is picking only the necessary jobs that have to run. And in this case, it identifies that the calculation of the dynamic groups needs to run.

This on its behalf is starting the provisioning application to ROAM and we are already in the cloud where you see that events are incoming for different applications. One for Salesforce and one for the SAP S4. What is part of this event is actually interesting that the data of the event is purely and simply just one ID. But how is that possible? This ID is actually the GUID from Entra. And this is possible because our solution is adapting to any interface or infrastructure that sends events.

And what we are doing is a so-called enrich action where we call back Entra with the necessary attributes which are needed for the mapping. And we know what attributes are needed for the mapping. And basically using these attributes, we are processing further to the event.

Yeah, provisioning to the respective system. This event of course is mapped to an internal data model of ROAM but this is another story which we already explained in one of the previous webinars. If you look at the grant, the grant is not much different but there is one significant difference here is that the ID that this time Entra is sending back is the ID which we created in the previous event. How is this possible?

Through the callback logic app which we are also shipping with the provisioning accelerator and we are sending back the ID that ROAM created and respectively Entra uses this ID for any future provisioning which saves a lot of unnecessary data transfer of all the attributes because we already have them on our side, on one side. Of course, if those update, we're gonna get a modify event for that. But in this case, this is the grant event where we're just sending an access package or a row to be provisioned. And it has certain validity.

Okay, this is the callback app which was called on Entra side. And let's see what happens in Salesforce. This is the user that has been created and we will see also the assignment here.

Second, there is. We are now in S4 and we're gonna see the rows that have been assigned and that's the row that has been requested with the respective validity.

Of course, this needs to be reflected in Entra as well. So we are navigating to the necessary package and when we check the user is assigned to that package here. Same goals for success factors. We're looking for the access package that has been requested. And we can see that the user is also assigned to that respective package. Additionally, we have a, let's say a mini audit table on the side of Entra where we can track the life cycle of every single request. And you can see that it was creation in progress, but once we refresh, the status changes to completed.

All right, so much about this one. Let's move on with the presentation. Second scenario, self-service with SAP GUI. The architecture of this one is, yeah, looks rather simple, but yeah, technically, of course, for those who are aware, uses a lot of the existing services on SAP BTP of course, including SAP built and building dual skills there. What we have created here is a scenario where we are connecting two systems which anyhow know about each other. So that's the Entra and ROIAM. And we'll see what we managed to achieve using that integration in just a second.

Before that, the use case, either from your phone or from the browser, you can just ask for your existing access or if you have the right access, the right permissions, also for somebody else's access. And once you get the details, you don't need to bother about, is that now an access package? Is that a business role? Is that a permission?

Whatever, in a clear spoken language, you can just request something to do. And yeah, most of the time, it will understand what you mean and of course, start the necessary request. So let's see how this works in action. What happens is we are entering a request to give us the current access of a particular user. And this is a real time recording. So we didn't cut anything. This is the time that it takes to respond. So we see the current access of the user. What we can do, of course, we can view that access, but we'll do this in a second. We see there is no Salesforce access in currently.

That's why we are asking, okay, what repositories are there, which I can request for. We can see the repositories and click on the view, which goes to the ROIAM Landscape Navigator. And you can see the actual repository here with the details. And then you can say, okay, from this repository, please list me any access that has admin in it.

As I said, real time, okay. So the groups are listed here and that's not everything. We can also click on view, which shifts us again to ROIAM and we can see details about this particular permission, who has the permission, other details, like from which system it was loaded and so forth. Sounds about right. So we want just now to start a request for requesting this Salesforce permission to that user.

Okay, this takes a bit longer, but not that long. And there we go. The request has been started. And as you would expect, this is the background behind it. So it's not something that is mocked. It's a real application and it triggers actually the provisioning app on Entra. And we are in Entra right now because we started to enter a request. And this app respectively is sending an event and you can see here the details, a create event to the lock. We use the link directly from Drew to jump into the event lock. And from the event lock, we can see the created event for this specific occasion.

Again, we can open the details. You can see that's exactly the same structure using only the data, the ID, sorry, of the user. Then we enrich it and we are provisioning it to the backend. Once this is done, the last step is a callback. That's the one. And this callback, you can see it here, is sending back one particular field, which you can see in the entity, the ROAM permission ID.

So, and the necessary keys, which are then mapped to the configuration in Entra. For the grant, the request looks similar to the one before. We have again, some access requested. This time there's no validity because we didn't request such validity. And once the grant is also complete, we are checking again the status in the table in Entra on one side. And of course, we are checking also the access package for which was requested if the user is within that package. All right. And respectively, the user is there.

All right, of course, success factors. Last check, if the user is provisioned and the user is also provisioned in success factors.

Now, something interesting. We're going back to Jewel and asking, okay, please give me an updated state of the access. And after not so long, we get the updated state where you can see it's not anymore just SAP access, but also we have the Salesforce access and the account of Salesforce available and attached to the user. We can validate that in a different way as well. We are now in the ROAM cockpit, that's the home, and you can open the entity viewer. And from within the entity viewer, you can define a filter, search for the user.

And within the user, you can get all kinds of different information related to their master data, to any groups or links they might have. And actually you can see here the different references which have been assigned to that user as well.

Wonderful, let's take a step back. Again, going back to the presentation. Next scenario would be SAP Jewelry as leading IAM for access requests with built-in risk analysis for both SAP and non-SAP systems. The architecture here is also rather simple. There's a connection between ROAM running on BTP and the SAP GRC solution.

And the interesting part here is that this connection is built on standard interfaces and also onboarding an SAP, sorry, onboarding any kind of repository, even non-SAP repository in SAP GRC is following exactly the same process as if you are onboarding a normal GRC, normal SAP repository. And we will see that in the demonstration. The use case for that, as you know, there is always an auditor at the door watching your every step. So we have to be careful what and how you're requesting from SAP GRC.

And of course, one of the things is it's pretty uncommon to request Salesforce permissions through GRC, but that's exactly what we're going to show you. Actually, how risk analysis is even possible for Salesforce is something we can discuss also in the Q&A. But in general, what ROAM allows and makes possible is a cross-system risk analysis of SAP and non-SAP applications, cloud and on-prem applications in one central cockpit, which is SAP GRC. Doesn't matter, of course, if it's the old GRC or the new one that comes in 2026.

Automated role sync, very important, because at the end, GRC needs to know what roles are available. And state-of-the-art request lifecycle for every single request you start on the GRC site.

And yeah, approvals could still happen on the SAP GRC site. And once they are approved, provisioning will be handled in ROAM within the SAP BTP. What this achieves is a happy auditor, happy person that started the request.

All right, let's see the demonstration how that works. All right, so we're starting with the event viewer, where we're checking what access is available for a particular Salesforce system. And we can see there are a number of roles. We can take a look at one role. And respectively, like we did it for the user before, there are certain details. You can see external ID from the system, who is assigned to it, and what is the type, in this case, permission set group.

Now back to GRC, and what we can see here is that the connection is established using a pretty standard RFC destination, which points, however, to the SAP API management, which from then transfers its request to the cloud integration. In the S-PRO, we are doing a pretty standard customization, which is to maintain the connection type. And we have our own connection type, which here is called Z-ROAM. Yeah. Then in the SWA manager, again, using a standard interface, which you're gonna see in a second.

Yeah, that's the GRAC Auth Management's web service. We are just configuring this service to call, again, the API management and, respectively, the cloud integration. And this is the key, for those of you who know what this service is doing, behind the different sync jobs, which are running, and basically delivering the necessary fine-grained risk analysis objects for any kind of application, which are existing on the site of ROIA. All right. And then we're just gonna start one access request. So this is not something unusual. You see it's a pretty standard procedure.

You're just requesting it the same way like you would request it for any SAP on-boarded applications, so there's no difference. We're using also here the Fiori interface, but of course you can use also the business plan, but not for long. Keep that in mind.

The data, the access that you're going to see now to be requested is synced from ROIA automatically. So you'll see it in a second. There you go. So you have the system and you have the role. And one thing you should, of course, keep in mind here, and this is, I think, common for those of you who know SAP IDM, is that the name of the system here differs from the name of the system in ROIA, but that's a common thing. Probably most of you also know it from the SAP IDM configuration, and that's okay.

I mean, for us, the two systems should not or must not have the same name. That's okay. You can follow your naming convention on the GRC site.

All right, and since we defined an approver, there's gonna be a workbox item for approver. The request is 484. Please mark that up because this request is also going to be visible in ROIA later.

Okay, and once we approve that request, we are going back to ROIA and looking at request 484 again, as you see here in the request ID, and we have two events, one for creation, one for granting access, which is exactly what we requested. The creation is related to the creation of an account. It's not actually creating a digital identity. It's creating an account for that user in Salesforce, and you can see this is the target repository name on our site, which is called Salesforce Test, but that has actually not much to do with the name, which was defined on GRC site.

All right, once those are done, we're going back to the Entity Viewer and looking for the username, which was provisioned. And what we can see, of course, is the full details about the master data and also at the bottom about the assigned groups, links, and so forth. This is the group that's assigned, and you can see a little bit more of technical information below, like the account and the permission technical name below in the reference.

All right, as always, that's not enough. We have to go back to GRC and validate that this user actually has the access, which we assigned because otherwise it wouldn't make sense. And what we see is that, indeed, this user has the access that has been granted. Then last check, success factors, and the user has the access. And that's the assigned group.

All right, moving forward. One last demonstration.

Right, okay. So last demonstration is our idea on how to gradually migrate SAP IDM to OAM. And this is again achieved with exactly the same connection between this time SAP Identity Management and SAP B2B OAM, where we are using three packages, one for connector, one for migration, and the analyzer. We'll see what we achieve with these three packages in the demonstration. The use case is clear.

We get new requirements on a daily basis for SAP IDM, but these requirements do not necessarily need to be implemented in SAP IDM because after all, there's no sense to invest into a product without clear future. That's why we are presenting you ProAM, which we already have in the presentation, which offers you a future-proof architecture, high return on investment, and the same flexibility you are already knowing from SAP IDM. And in this picture here, you can see, and that's not overrated, this is pure reality, the clock is already at 5 p.m.

And you're actually gonna be able to migrate a repository from IDM to ProAM within the hour. And you see the person is happy after that, that he managed to achieve it. Let's see if that's really possible.

Okay, demonstration time. And part one, we are going to migrate an existing SAP IDM repository to ProAM.

Oops, yeah, right. Okay, so for that, what we need is, a repository called the hub. And the hub, you can think of it as a one-time setup repository, which will connect to ProAM. So we have a hub here, and that's our quality hub. You have to maintain certain credentials, certain connectivity options, the API management host, and so forth. And after that, we have jobs which are synchronizing between IDM and ProAM. And you can see that we have a pretty standard repository that is of type ABAP-specific application server.

So it's, I would say, a standard SAP IDM REPL. And this REPL, we want to migrate now to ProAM. So let's see. The only thing we need to do are actually two things.

One, to maintain what is the hub for this REPL. And you can see it here at the bottom. And the other one is what is the target repository name of this particular repository on the ProAM side. Because after all, if it's an existing repository, we don't want to change its name, obviously. We want to keep it as it is, but that doesn't mean that we have to stick to this naming convention also in ProAM. So what this achieves is, I would say, close to a miracle. But let me just show you in a second.

Okay, we go first to ProAM, and we want to find that repository. And you can see, actually, that the repository is there. And it's called SSF01, which is a completely different name from the one in IDM. Then let's start a new request, again, from IDM. Why we are doing it from IDM? Because until IDM is decommissioned, it still is the central authority for requesting authorizations and keeping track of who has access to what.

And yeah, so what happens is, we are triggering the standard Create plugins. And of course, there's a no master process as well. And the only slight difference you see here in the process of the Create plugin is that there is a deviation in the beginning, which takes care of repositories, which are handled by ProAM. But that is, of course, very neatly done, because this means that you can actually decide, based on a repository level, if one repository should be handled by ProAM, and another one should stay with IDM for now. So this gives you this flexibility to do that.

And what happens is that the Create process is the Create plugin is triggered. It goes into the right branch, and the right branch is doing an event call to ProAM. We've seen that already in the previous scenarios, and we are back at the same place, which is the event viewer. We see that the Create is triggered, and then it's almost complete. And then what happens is there is, again, a callback to IDM. This callback is reporting that the Create user was successful, and starts the assignment of the user membership. So that's another plugin, which you know pretty well.

Standard plugin, nothing special. Again, event is sent to ProAM. Event is received. We're again processing the event.

All right, and once we go back to the Entity Viewer, we can actually see that the user has the necessary, or the requested access provision. Yeah, there's a count, and there's a provision. We need the permission as well. And one interesting thing which I wanna show you is the data which is sent. If you remember, these data looked a bit different when we used an entry event. And since we're using an SAP IDM event this time, you see the data looks very, very standard for an SAP IDM system.

And here, the tricky part is that we don't expect the system connecting to us to actually change its data model, rather exactly the opposite. ProAM is adapting to the data model of the system that is sending the event. And of course, we can see the user has been created, and the role has been assigned.

All right, then part two would be a bit of a different scenario. We are going to onboard a repository from ProAM to IDM, but for a connector that doesn't exist in IDM. And this connector in this case is Salesforce. As you know, SAP IDM doesn't have a Salesforce connector. So let's see how easy is that. We first need to create a repository of type ProAM connector. And that's just like a repository type we're shipping with our package.

And again, the only two things we need to maintain, you see there are no connectivity here. There's no nothing, basically. They're just two attributes, the ProAM hub repository and the ProAM target repository. So those two has to be maintained. Salesforce test is our repository. Then we can start requesting access. The same way we do it also for ABAP. More or less the same procedure repeats itself.

Again, a create plugin is going to be triggered, but this time the create plugin is going to be from our own connector, which is not doing much different than just triggering directly the same create, which has been triggered for SAP ABAP as well. We just don't need anymore the split because obviously if it's a ProAM connector, every single repository of that type is going to trigger RoAM. Now let's see, okay, the create is there.

And again, going to the data, similar set of data like we've seen it in the previous example and there's no other way around it. The data structure of IDM is always the same for this particular system, of course.

Okay, once this is done, again, back to the IDM with the callback, the create is successful and respectively, this will trigger the assignment. Okay, assignment is also triggered. You can see actually the times. I want you to pay attention to that as well. It's a matter of some seconds where the processing takes place. So it's something which we didn't envision, but it just happened like that, that the provisioning in the cloud seems to be faster than in SAP IDM.

Okay, for the data of the grant access, it looks a bit different, but it's more detailed and it contains a lot of data also from SAP IDM. This data, of course, could be used for other various decisions you make on the ROAM platform. While this is provisioned, what is left is, of course, to validate on IDM side, again, that the user is assigned and we can see that their status is okay. And additionally, of course, we need to check one more time in the Entity Viewer with the respective user.

All right, and the access is granted with a respective account in Salesforce. Last but not least, of course, Salesforce itself. The user is there and the assignment is also there.

All right, last but not least, one very small detail about the SAP IDM Analyzer, which we are providing as well. This is a tooling that can help you analyze out of the box your existing IDM implementation, then cutting a lot the analysis phase of every single migration by a lot because practically we are checking all the objects in the system and evaluating if they have been used since a certain date. And we can provide you also detailed estimations about those objects.

All right, then with this, the demonstrations are finished. And let me finalize this with a few announcements and then I'll hand it over to Nitish. As promised, the first one is we're very proud that our online documentation is from today available on roiam.rival.com. So feel free to browse it, ask questions, contact us on LinkedIn or yeah, and I think there's also a lot of information there. You will also find that it's part of this webinar as well.

Another is that we're also going to be at the SAP Insider event in Las Vegas next year, which is taking place between March 17 and 19, 2026 in Vegas. So feel free to join us there and we'll have a nice talk about IEM and SAP security in general. And last but not least, our collaboration with Kupinger Co brought an interesting white paper called Navigating SAP IEM End of Maintenance, Evaluating Migration Options. But I'll let Nitish also present it to you. So that's from my side. Thank you. Thank you. Thank you so much, Rudra. That was a great demonstration. We are right on time.

So maybe I'll quickly share some things as you mentioned about the announcements. Yeah, as mentioned by Rudra, the white paper is live. You can go on this link and read the white paper. But maybe I'll quickly discuss some of the poll results that we asked. So maybe the first poll that we asked was that, what is of strategic importance when the topic is IEM? And the answer is almost, you can say tied, you can say 22% have said flexible connectivity and mapping options, while 21% have said one central solution for cross-risk analysis.

While the third one is, please, these on the screen, just a second, is having an intuitive and configurable self-service for end users. So Bo and Pradog, you have some maybe quick comments on this result of this first poll. Do you think it aligns with your thoughts as well?

Yeah, I think very much. So I think we touched it during the session as well, but I agree. It's very much aligned with my perceptions.

Perfect, thank you so much. Yeah, same goes with me. Thanks everyone for taking the poll. Thank you so much. And the second poll was, how prepared is your organization for IEM modernization in the next 12 to 24 months?

Again, there's a tie. 33% have said they have a clear roadmap, but ongoing tool selection, while 33% have said not yet started.

While 20, oh, it's changed. We have new votes now. 38% is having clear roadmap, but ongoing tool selection, and 21% is not yet started. So that's the second most is that it's not yet started. What do you have to say? If you have to advise them two key points for the migration, what would you say for these people? I'll leave that to you, Todor.

Okay, yeah. I think we've said it multiple times during the webinar, that the time to start is now. The more you delay it, the less the options you're gonna have will be there. So we really are looking at the scarce of resources.

Also, very shifting layers, a lot of shifting layers, actually, in that area. So the moment you invest some time into that, you'll see, actually, how fast you can move through that and, yeah, achieve the migration in a good timeframe, yeah.

Perfect, thank you so much. We are just over time, so I'm afraid we do not have any time for Q&A sessions, I've been told. But do you want to maybe end this with some final statements so that our audience can look for you in somewhere on LinkedIn or something, go reach out to you?

Well, I would say, yeah, any questions, any comments, feel free to connect and I'll be happy to follow up, at least from an SAP perspective. I would say one thing that I did not mention in terms of how we make this available to our customers, but I think Todor, he did that very well in the demo.

Any user interaction, right, when you're looking at, let's say, having AI, like the digital assistant, you'll help out with these scenarios, I think that is definitely something that needs to be considered and needs to be, I would say, without bending anyone's arm, but that's something that customers and users will expect right from your IAM solution, that they can interact with these digital assistants, seamless, they don't need to have a advanced user interface where they don't know what's going on, they want to be able to do this kind of dialogue exchange and make sure that that's available.

And so have that as part of your solution roadmap when you go forward. But yeah, that would be the main comment from my side.

Perfect, thank you so much, Bob. Todor, do you have something to add to end the discussion?

Well, I totally joined the point that Bob made, AI is here to stay. Of course, the use case for security is just starting right now, it's going to explode, I guess, in the next couple of years. So for sure, putting a strong foundation and a future-proof foundation for your IAM in the future is one of the main things that have to be considered. And for me, SAP BTP is definitely the platform to do that. Thank you. Thank you so much, Todor, thank you so much, Bob. And I would like to thank all the attendees as well for staying until the end.

This was a very interesting session and hope you also enjoyed it. Look forward to seeing you at the next webinar. Thank you so much. Thank you. Thank you.