So, like I said, my name is Claus Nørklit. I'm working as an IAM expert in the IAM team at PwC Denmark.
And, as an IAM consultant, I very often hear from clients that they want to use their ITSM solution as what we call a one-stop-shop solution, including requests for access rights. Of course, this would normally be performed in the IAM solution, and there are pros and cons for using ITSM for requesting access rights. Hence this slightly provocative title of the session, Are We Working With or Against Our ITSM Colleagues?
So, many of your stakeholders think that a one-stop solution using the ITSM solution is just a natural thing. And seen from the end-user perspective, it makes perfectly sense.
But, as you know, there lies the detail, and this is also true for this matter. In this presentation, I will use experience from practical work with clients, but I will not mention any specific ITSM or IAM solutions, but the experiences are bound to certain products.
So, before going to this, let's start by looking at this process framework. We normally use this when we talk to clients and start IAM projects. As you can see, it covers the main processes going from identity lifecycle to access management enforcement and VM operations and support. And you can see that I've highlighted access request management as the main topic, of course, that ITSM will be able to take over, but also the account lifecycle management being the provisioning, which ITSM partly can take over.
This will normally mean that it's systems, like we just heard from Quira, with limited integrations, meaning all changes are carried out using tickets to the system owner. Sometimes we even see that the roles are defined directly in the ITSM solution. I will not recommend that model, though, so be aware of that. Let's look into how do we actually have the access request process in the IAM solution. And remember that even what I have on this board here is a very simplified model of an access request process.
Of course, it can be made in very different ways in different vendor products. So I'm just using this to highlight the intelligence that lies within the IAM products, and which is being used during the access request process. So I have two different models. The first one is a manager searching for access for an employee, and we could say it's an AI-like request. So which accesses do you typically have in Department A? The IAM solution can do so because it knows all about all entitlements and roles for all onboarded applications. Does the ITSM solution know that?
Further, the IAM solution knows on behalf of which employee the request is made. So it can look for other employees in the same department and suggest what is common accesses for those employees, or using the same job function or any other available attribute that you have on the employees. Or the number two below, the manager can simply ask for a relevant role catalog for the department, for the job function, or any other relevant attribute.
Of course, using that kind of search, the manager is at risk of getting quite a lot of roles to scroll through. If the IAM solution has a self-serve interface that you have enabled, the employee, of course, can basically do the same access request type as mentioned here. The only difference being that there will normally be an approval step included performed by the manager, or the application owner, or both. And the IAM solution will know all about this information, where to send the approvals. Will the ITSM solution be able to do that? You can question that.
So the next step in the request process, when the manager has selected the relevant accesses, they are sent for further processing in the IAM engine. First check is typically for segregation of duty rule sets, and IAM knows which other accesses the employee has, and can report any violations back to the manager for approval or decline. As a part of this, the manager can write the reason for approving an SOD, and eventually this can be sent to the approval with the application owner. Will ITSM be able to do all of this?
So IAM checks whether or not there are further approvals that have to be carried out. How would that be done in ITSM? IAM sends notification to the manager and to the employee. If there are more approvals, and they do not react within a set time frame, IAM can send out reminders. ITSM? And if the approver is on vacation, there might be an approval forwarding rule, meaning that IAM sends the approval to the substitute approver, or the approver has set a permanent substitute for approvals.
Again, ITSM? So the next step in my presentation will be to look at the different integration types that you have between IAM and ITSM. The first one on the left side is what I would call the basic integration, like for any other application, that you need to maintain the join-move-leap processes for accounts, as well as access rights. And to be able to perform the governance processes, the IAM solution must also be able to read back the access rights and the accounts from the ITSM solution, which is why you can see I have arrows in both ends. This is a double, two-way integration.
The second integration, of course, is what we call the catalog integration, which is required that the ITSM solution needs to know which access rights or entitlements should be requestable within the ITSM product. And this normally requires that the whole catalog from the IAM solution is synchronized between IAM and ITSM. The IAM solution will know who the application owner is and whether or not this is metadata on the role itself or it's done in any other way, is of course vendor-dependent and implementation-dependent.
But ITSM will have a hard time to do the SOD check and also to send approval to the application owner. So for the ITSM solution to be able to know the relation between the manager and the employee, like I'm talking about, it might also be required to synchronize the organization hierarchy from IAM to ITSM. So can you feel that the complexity in the integration is growing now? The last integration that we have, the third integration, is the so-called ticket integration or provisioning of accounts and access rights.
So the tickets will typically be sent from the IAM solution, which in turn will pass on the tickets to the IAM provisioning engine. If you're not doing it this way, then the IAM solution will not know which roles have been assigned to the employee and the access governance process will fall apart because you don't know which access has. And it will require another form of data flow back from the application to the IAM solution. So be very careful when you write in your RFP or your change requests that you need an ITSM integration. We see that very often, ITSM integration.
It can be very many different ways. So you need to specify what you are actually looking for, which kind of integrations do you need. Now let's look into how can you actually make these integrations. So on all the slides I have the ITSM on the left side and the IAM on the right side. And I will show you three different ways of integrations. This is what I call a lookalike interface. And I will not show the basic integration, the first one I talked about because we see that as a standard integration.
This integration here uses deep links from the ITSM via what you could call a custom built ITSM application to the IAM solution access request API. Meaning that you are mimicking the IAM processes but within the GUI frames of the ITSM product. The user experience is of course that access requests can be selected within the IAM solution and hence giving you a one-stop-shop effect. But all the further processing will be performed within the IAM solution. Access via deep links from the ITSM.
As you can see below when a ticket has been started we need some way to understand should we just fire that ticket to the IAM solution? Should we have feedback? That's another complication in the integration. But this basic type here is what we call the catalog integration and use the IAM API. So the next integration type that I will show you is also a lookalike integration. I would call it the cheating integration because what we do here is that we use iframes to show the IAM GUI web pages.
Meaning that the user gets a virtual one-stop-shop experience since the user only needs to have the ITSM app on the desktop. But as soon as the user chooses to request accesses within ITSM user is kind of transferred to the IAM solution which handles all the functionality. This is of course by far the simplest way to integrate IAM and ITSM. But of course you might end up with different graphics in the two solutions different way of working with shortcuts so it's not a perfect way to make integrations.
However, our experience shows that this integration type requires the least effort and still gives the end user the one-stop-shop experience. There is one more option, I haven't made a slide for that but that's simply to place a link in the ITSM solution that just brings the user over to the IAM solution of course. The last one is the full-featured integration. It means that you basically program everything that is required to make access requests. You program that within the ITSM solution.
Again, using data of course from the IAM solution but the functionality is placed within the ITSM solution. The user will experience a true one-stop-shop for access requests but it might be with limited functionality compared to access requests direct in the IAM for the reasons that I mentioned in the beginning of the presentation. The more functionality, IAM functionality you want to have in the ITSM solution the more complex the custom programming gets and the complexity of integration is highly increased.
Always remember to ask your IAM vendor which kind of ITSM integration is available for which ITSM products and what kind of functionality is actually delivered through that integration. If you look at the complexities and considerations always consider what was the actual purpose of requesting access within ITSM and how far do you want to go in terms of functionality and what is the cost of doing so. Should approvals be performed in ITSM or in IAM? And if it is within ITSM, as I said, you need to have a knowledge about the organizational hierarchy in the ITSM solution.
Like I said, will the role composition take place in ITSM or in IAM? And how is the tracking of tickets fed back from the IAM to the ITSM so the ITSM can close a ticket again? Alternatively, consider what we call fire and forget just send a ticket and close a ticket at the same time.
Of course, upgrading either the ITSM or the IAM product can lead to malfunctioning integration so you need to consider this as well. Access requests via AI or SOD checks require knowledge about any existing accesses that the user might have and you do not have that by native, of course, in the ITSM solution so you need to be aware of that. And remember to ask your IAM software vendor, like I said, what depth of integration they actually have in their integration types and possibly how many clients are using it because is it properly maintained when there are new releases of the ITSM product.
But also remember that the more mature the IAM solution gets the more birthrights as well as specific accesses for the employee individual will be assigned automatically through rule sets. That is what we want, right? And this means that the manual access request process in the ITSM solution will be fewer and hence the ITSM integration will be used less. So where do you want to spend your time and money to mature the IAM solution or to make a complex and expensive and perhaps short-term integration between IAM and ITSM? This actually leads to my wrap-up slide.
You need to map all your access request processes in detail. If you do not do that, you do not know what should be transferred to the ITSM solution. That is very paramount. And always consider the complexity that you have in such an ITSM integration like you've seen in my presentation. Consider the business value of actually requesting access in ITSM. Is this just the ITSM team that wants this or is this really a business need? Always ensure backup from management level if you do this. And make ITSM system owners your best friends because you will really need it. That's all from me.
Thank you, Klaus. We have a question from the audience. Thanks so much. So first of all, it seems to be one of the best received and well attended talks here.
Very, very important. So would it be okay if I quote you that you rather prevent doing all the access request and approval workflow as one of the priorities because assigning entitlements and accounts in an automated way through birthrights and through roles is the better way to do it?
Yeah, I think. Thanks so much. That's what I wanted to bring out. I agree. Don't do it. So we have maybe a couple more questions.
Yeah, we have some in the app. So let's see. Here's a good one. Our fulfillments are near to real time. What would you recommend? To integrate with our ITSM or let it stay in IAM in that circumstance? Can I read it?
Yeah, near to real time. Yeah, sorry. Sorry. Which one was it? The middle one here.
Oh, fulfillment. What do you recommend?
Yeah, I would again recommend it to come direct from the IAM solution because, I mean, if you start to have integration between the ITSM solution and the applications that you have, you need to have multiple integration because, like I said, for the governance processes, you need anyway to feedback the access and the account data from the applications to the IAM solution or the ITA solution. So I would for sure say IAM. Okay. I think we have time for one more quick one. There's a known issue with fire and forget. It means the ITSM is unaware of failures, or at least partly so.
How should we plan for auto retry or self-remedy in that case? Good question. I think this is, again, back to the IAM vendor and how they have made the integration between the ITSM and the IAM solution, how well is this done, and how good is the ITSM solution actually to understand via the API, to understand the request that can come back from the IAM solution. So back to your vendor asking about how good is your ITSM integration actually and see it work live. That's always a good thing to do.
Thank you, Klaus. Okay. Thank you much.