[MUSIC PLAYING] Hello and welcome. My name is Abdullah Ahmad. I'm Senior Solutions Architect at One Identity. Today, we will discuss the integration capabilities between One Identity Manager and ServiceNow.
I have here a short agenda. First of all, we will have a look and discuss the business consideration and feasibility. Then we will go to the step-by-step configurations and discuss different use cases, how can they be configured.
So this is consideration and feasibility. ServiceNow Service Portal for end users bit. Let's start here. So a lot of companies may have decided to use ServiceNow Service Portal as an end user portal for the end users so that the business users can go there and request access, request some items, hardware, whatever they need.
And for that reason, we are bringing the integration capabilities with the ServiceNow Service Portal and the customers will benefit from these enhanced integration capabilities. The catalog integration delivers a consistent and unified experience for the end users and, of course, and a compliant and governance for IT managers, as you can perform manager approval or any additional approval step within the ServiceNow, but also you can perform SoD checks within the ServiceNow.
So security and governance is achieved, of course, with a very flexible policy-based approval process that supports also the approval workflows and segregation of duties, or so-called SoDs. We have multiple combination and options for approvals and SoD checks.
You can, for example, perform only approvals within ServiceNow, you can only perform approvals within the Identity Manager, you can use a hybrid scenario, the combination of both-- for example, to use and manager approval within ServiceNow and additional approval steps within Identity Manager, but also you can use self-services without approval processes for non-critical objects.
Customer specific requirements, of course, can be fulfilled by, for example, using the catalog integration add-on as copy template. You don't need to start at scratch by a [? greenfield, ?] so you can use the catalog integration add-on as a copy template. A lot of use cases have been implemented already there. But if there are specific requirements from customer side, so you can, of course, use that and enhance those functionalities or copy them to fulfill the requirements of your customers.
So what you can do and what not, of course, you should be aware that you can create access to requests in ServiceNow. You can perform approvals, SoD checks in ServiceNow, but you should also be aware that the provisioning and the provisioning will be handled by Identity Manager.
We are delivering already an on-web portal for different purposes with different functionalities like certification, attestation, delegation, and so on and so on. Maybe you have then to decide which functions should be implemented in ServiceNow and which functions can be used from the standard portal of Identity Manager.
As always, it's a question of investment, of course, and resources, which is needed to implement all those already existing functions in ServiceNow again. Yes, and the complexity of technique is, of course-- it gives to the mutual customers very complementary Identity Access Governance tool in Service Management, and they are able, of course, to fulfill with that combination of IDM or Identity Manager answers. Now, whatever requirements they have, whatever complex it might be, it can be then, of course, handled.
So let's start with one of those topics. In governance, so providing Sterling Connect Connector as SaaS service, as application service for our customers. And the Sterling Connect Connector provides a connector for ServiceNow where we can use this connector in combination with Identity Manager to fulfill the IGA use cases. So like lifecycle management, access reviews, SoD checks, and password managements.
The business value is, of course, using that connector that you get complete visibility of ServiceNow access-- who has access to ServiceNow, with which permission? Who has approved that? How he should get access to ServiceNow, whatever-- or which functionalities. And of course, you have a very strong compliance and security controls there.
Here are a few use cases which can be handled by that standard connector, which we are providing, installing, is the creating of user accounts in ServiceNow, for example, as part of joiner-mover-leaver processes. We can give the correct authorization or permissions to those ServiceNow accounts, and, of course, in case of a user is moving from one department to another, we can automatically change the ServiceNow permissions of that user if it's necessary.
Of course, we offer also the additional ability for the end users or ServiceNow users to request more access or permissions if it is needed. And we can automatically disable, deactivate, or remove user accounts from ServiceNow-- in ServiceNow as part of the joiner-mover-leaver process. In case the user will leave the company, he can also be automatically disabled. So you will never have had a lack of mismatch there.
But the ticket management, we are providing an out-of-the-box module for ticket integration between Identity Manager and ServiceNow. From the IGA use case scenario you can automatically create a service request tickets as part of workflow, for example, or process, and some steps may be done or performed manually via the ServiceNow tickets, and the ticket's status can be tracked and monitored by Identity Manager. Once the tickets have been closed, we can pull these results.
From the business value perspective, of course, you have the automation of ServiceNow desk ticket creations, which save a lot of time for your employees. And of course, you will be able to extend the governance over manually fulfilled requests.
So use cases can be, for example, creating ServiceNow tickets to trigger a manual provisioning-- or the provisioning of user accounts and applications that are not connected directly to Identity Manager, but you can also handle those applications with Identity Manager if they are not connected with IDM.
You can create those unconnected applications in Identity Manager and assign or create or import the existing authorizations from the backend system, and from that point, once you are assigning those authorizations to the user, the ticket will be create a person or admin, one of the colleagues will assign this authorization to the accounts or creating the accounts, updating the ticket, closing the ticket, and of course, IDM can get that result back. And you will see all those information who has fulfilled that request in the backend. That can be done part in the workflow documented.
Of course, you can define users and groups for those that application IDM should be run. And when provisioning-- or the provisioning of the users are rights are needed, a ticket will automatically created and monitored, of course, until that ticket-- that process has been fulfilled.
So here's just an example how it can look like. For example, a user account has been requested in Identity Manager. Identity Manager has created a ticket in ServiceNow to say the user Tyler, he needs an account-- an example, application here, sales report. And IDM will automatically monitor the status of that ticket, and once that ticket has been closed, then the IDM team can pull this data and put in the workflow to say, OK, the user-- in that example, user admin has closed that ticket number.
So the use case is the catalog integration. We have a native ServiceNow application add-on to Identity Manager. With that add-on, we are able to get access in IT-Shop catalogs or web portal of Identity Manager in real-time from ServiceNow.
We are using the REST APIs of Identity Manager by ServiceNow and pulling the existing available objects for selected user, but also we can create access requests, whether they were performing them from ServiceNow, and Identity Manager. And we can also enforce or perform SoD checks within Identity Manager, but from ServiceNow.
Approvals can be handled by a Identity Manager, by ServiceNow, or a combination of both. Provisioning is always handled by Identity Manager to the backend systems. If you are going to the store ServiceNow.com, you can search for One Identity Manager for a service catalog. You will get the highest or newest version which is available. You can see under the compatibility if your version is-- or your instance version is also compatible to your instance and you can download that.
Once you have click the Request App and you have to contact your seller, your sales account manager from our company, and you will get them access to that app. In the step-by-step configuration, we will go through those processes and see how can we configure and handle all those use cases which we now discussed.
Once you have installed and configured that app, the end users getting that access request functionality here, a user can select himself and manager can select himself, and all is direct reports. And an administrator or HR admin with the permissions is able to select anybody and create access request on behalf of them if it's necessary.
So here, we're selecting a person. You're selecting a service category, which is the IT-Shop Service category from the IDM. And within service category, you may find one or multiple service items. So you are selecting one or multiple service items. You can add optionally a limited date from and until, and a reason why you are requesting that, and just submit it.
Depending on your configuration, if there is an approval workflow in place or not, it can be then approved by ServiceNow workflow or Identity Manager workflow, and after approval is finished, the provisioning will be then handled by Identity Manager.
Another function is person onboarding. In that case, you are able to create internal or external employees. Mostly it's external employees, consultants, and so on. Those colleagues are usually not handled by a HR team and you may need to create them manually.
For that reason, using this form, you can create those persons, putting first name, last name, contact email address, and so on, selecting the primary department, selecting the cost center, whatever adding a responsible person, person sponsor, or, manager and if it's necessary, you can add their entry date, birth date, and employee type. And then just submit that request and you will create a new person-- employee entry in your Identity Manager system.
We have a few additional functions here. These are currently not yet released to customers as they are lab preview during this recording of that session. So one of them is, of course, mark a user as security risk in case there is any kind of emergency and you want to deactivate a user immediately in every system and every session. Maybe you'll call the desk or security team or you're creating a ticket and creating an incident, whatever.
So this function can be, for example used by admins or security team or helpdesk to say, OK, the user Christoph in that example is a security risk, and therefore, he will be marked as security risk in Identity Manager. As soon as he is flagged as security risk, he will immediately be locked off from any system. He will be deactivated, and the security colleagues can then, of course, starting forensic research to find out what is wrong or whatever needed.
Additional functionality is password reset. Maybe the users have not any other chance to visit their password because they don't have access to your password portal or to the company portal and network.
Maybe the last chance is just to call the help desk or creating from the outside somehow a ticket or calling the helpdesk, and helpdesk colleagues, they can reset-- or set a password, an initial password for the user, or the user themselves may also get somehow access to the ServiceNow and creating that access request to reset their password. So then, of course, in that case, the password of the user will be received in all the connected systems.
So, now we are going to the step by step configuration. First of all, we will see how to Connect ServiceNow as target system to Identity Manager. For that reason, we will create an installing Connect Connector to ServiceNow. We will create SCIM and UCI synchronization projects in Identity Manager and run the synchronization project. And we will create account definition for ServiceNow.
We will assign the ServiceNow account definition also to managers to make sure we can perform approvals in or within ServiceNow. And the last use case will be we will open ServiceNow and show you that the new user, which have been added to ServiceNow in Identity Manager, that user has been created in ServiceNow and is done already in ServiceNow is able to log in there. So that's the use case. We will start with the first step here.
So you see here our Starling Connect platform. Once we are registered there and have access to the Starling platform, you are able to connect different systems. And in our example, we are creating a ServiceNow additional system here, which we want to connect.
So we are adding here our username, password of our ServiceNow instance, and adding the name of our instance to that configuration part. So we are testing our connection and we will see that it has been successful connected. That's the first step.
You can select or connect to type of production. Development, of course, and we will get the SCIM URL and legacy SCIM URL. And our roadmap will be shown to us, and we can use them.
So, from that new connector, we are able, of course, to disabled certain attributes. If you don't want to synchronize that, we can click to the Edit button and then deactivate all those attributes from all those different objects and tables if we don't need them. But we are also able to add here additional custom attributes if it is necessary.
So you see, we have different options here, and can, of course, shrink the number of attributes. What we need is here, of course, to copy the SCIM client ID, the SCIM client secret and the SCIM token endpoint which we will use in the next step to connect to the Starling Connect Connector to the ServiceNow.
So, now we are in the Synchronization Editor of Identity Manager. Here, we are creating, first of all, SCIM Connector. ServiceNow Connector depending on how you configure your system. And here, we can add the URL and all those SCIM data which we have already copied in Note or text file. So now we are just adding here those part of that SCIM service and endpoints and protocol that we are needing here. We are adding them there, we are selecting the application, putting here the application endpoint URL.
And what we are performing currently here, it is, then, of course, you can use that for any connector which you want to use, the Sterling Connect platform to connect them with Identity Manager. So we are adding here the client secret and adding the next step, the application client ID. And then we should be able to connect to the ServiceNow backend system we are installing from Identity Manager.
So now we have successful connections. We will note the schema, resource types, and service provider config. You see, everything has been uploaded. We can here configure some config parameters. We have here the server time, which we can select, and timeouts. We can have their additional settings.
And of course, we have here two different target products. SCIM in general as SCIM Code Version 2 or One Identity Sterling. We can select Starling, of course. And once we have selected Sterling, we will get the predefined template for that connector. That means we will get the mappings of different attributes out of the box. There, we don't need to map them manually by yourself. You can do that directly.
So, now we have created the SCIM Connector. Once we have created that SCIM Connector, it will be able then, of course, to synchronize that first, and then, of course, the next step will be to create a UCI connector to synchronize-- to be able to synchronize between ServiceNow, Sterling IDM.
So, loaded successfully the schema from the ServiceNow and Identity Manager, and we will be able now to select the correct synchronization template, and that's on the Identity Manager-Sterling synchronization template, which will give us the predefined mapping. We are selecting this synchronization server and service server. And of course, the end of that, we will have that connection configured.
So, of course, if there's any consistency problem, the system can also perform consistency checks. You can click to verify projects, find them out if there's any and so on. So we are selecting our SCIM, and we can also find out if there's any consistency problem, we can then fix them. And can, of course, after that, once the consistency check is clean or fulfilled, so we can then execute the synchronization and getting the data.
So you can see, currently the system is not there. Now we will start to have the data in that system. So it's yet empty, but after a few seconds and minutes, we will see that will be then, of course, filled with data, which we will get during the synchronization from the backend system.
So, the next step will be to create the UCI connector, the Universal Cloud Interface connector. To have the second part of that synchronization project, for the installing Connect Connectors, you usually need to create two synchronizations.
One of them is the SCIM synchronization or Sterling synchronization, which it-- yeah, bringing the data from the cloud to your local system, but that's in RAID-only mode. And the second synchronization from UCI will give you the capability, of course, to connect with that SCIM tables and load the data and write more to your Identity Manager tables. So that's just, for security reasons, an additional layer of security. So now we have here, you see selected there.
You see, I will have selected the dedicated SCIM project, and now we have selected the job service, activated the project. And once we are done, we will have an UCI project also to that SCIM project, and we can then start with the synchronization.
So we have now a cloud-powered system. One of them is a here, SCIM. You see, it is-- currently it is empty. We are adding some conflict steps here. And once we are ready, we can start the synchronization. So we're saving our change. So now we are going to the synchronization and we are going to run the synchronization, and after a few minutes, we will get the report that the synchronization has been successfully executed.
We will get all those ServiceNow accounts and permissions. It is in the backend system. So now we have the synchronization between ServiceNow and Identity Manager. The last step will be to execute the dedicated UCI connector also to synchronize that. That's it.
So after that, synchronization with the UCI is also performed. So you'd see that 12 seconds, and now, it will be able to create an account definition and assign that account definition to the users. So you see, they have 620 users, 45 groups, and 373 entitlements from the ServiceNow instance.
So, we create an additional account definition here for our new system, ServiceNow system, which we have now connected, and we will get that system-- or that account definition, then, assigned to employees. So for that reason, we are giving a name, selecting our target systems. And we are selecting the Manage Level. And, of course, you can decide if the account definition should retain the users in case the user is permanently or temporarily deactivate.
So you can also bring that account definition to web portal, to IT-Shop so that this is also for the users available to be requested via the portal if it's necessary.
So here is, of course, the steps of how can we add that to the portal. Most of the details, you may know that-- so once we have the account definition, we can then assign that account definition to the end users. So that account definition sits in the portal, of the portal, and we can assign that account definition directly to an employee or, of course, by request.
So let's select a person here, an employee. In our example, that's Ben. And we are using the Tool Manager to assign that account definition directly to that employee Ben. So we are selecting Assign Account Definition and taking that new account definition, which we have just now created, and we will assign that to the user.
So, the provisioning will immediately start and the user will get access to ServiceNow. And in the same way, we can also, of course, go to the web portal of Identity Manager and create a request of that account definition to get access to ServiceNow.
So now we have logged in as Admin in the portal, in the ServiceNow portal. Just to make sure, under the User Administration, that our newly-created user then-- should be-- then should be created in ServiceNow. So the provisioning is running in the background. So now you can see, that user has been created, and we can see that user Ben is now in ServiceNow.
So, now we have seen the first use case with the very detailed step-by-step configurations. You have created installing Connect Connector to ServiceNow. We have created SCIM and UCI synchronization projects in Identity Manager. And we have run synchronization project.
We have been able to pull or import the currently existing data from ServiceNow. We have created an account definition, we have assigned account definition to a user. And we have been able to go to the ServiceNow and see if that new user have been created in ServiceNow. Which means that, yeah, the first use case in general have been demonstrated.
So our next step-by-step configuration will be the catalog integration so how to Connect Service Catalog Integration with One Identity Manager. For that reason, we will go through the installation, initialization, and configuration of ServiceNow Catalog Integration of the add-on.
We will create access requests in ServiceNow Portal. We will approve that access request in ServiceNow Portal. We will show the request history via the IT-Shop of Identity Manager. We will show, of, course also the user account and the SAP system. So we will create access from ServiceNow through Identity Manager in an SAP system.
And then it will go to the workflow in ServiceNow and in Identity Manager, show different of the configuration options, and, of course, discuss a little more there.
In the Service Portal, once you have requested in the ServiceNow store and you have installed that add-on, you will see under plug-ins One Identity Manager add-on. First step you have to go to the Designer, create a dedicated account, dialog user and designer with service account permission.
And that information, that user will be used as service user for the communication between Identity Manager and ServiceNow. And you have, of course, to configure and open your SSL port to your application server because the communication is inbound from ServiceNow to Identity Manager. And you may install your app server or one of your app server and the DMZ zone to make sure you're able to call from ServiceNow IP range inbound calls to your app server.
So once you have created a user, you have to go to the app server and log in with that user to make sure you have access to the app server for that user. So, the first step has been done. Now we are going to the ServiceNow standard. And there, we can search for One Identity. And we will find our add-on there.
And you have here different tables. One of them is the configuration parameters. If you're clicking the config parameters, you will see that you have here a lot of conflict parameters where you can change the behavior of the system.
So, config parameters containing the name REST. Means REST API. You have to maintain the URL to your app server, the URL, which is reachable from the ServiceNow to the app server, you have to put there your REST API username. We have already now tested our new user. That's why I am slow user.
And of course, you have to add the password there. For that reason, you have an Encrypted Password field. So the Config value should be empty. The Config Encrypted field should contain the password. Now you will be able, of course, to run the background synchronization job to pull the data to do an initial synchronization with Identity Manager.
For that reason, you're going to the system definition, scheduled jobs, and searching for an Identity Manager job name, which is the initialized configuration parameter and load data. And you can, of course, activate that jobs to be executed daily or every few hours, but now we are executing that manually to make sure we are getting the results from the backend.
We see the status of that execution jobs is currently running. And after a few seconds, we will get all those cables, which we want to get, from the backend system here. Here, you see the table at person, users. Then we have here organizations or departments, business roles, and so on. You see, of course, the unique user IDs, the unique keys of those tables and elements. And here, you see the IT-Shop service items and the IT-Shop service categories, which is existing in that demo and test system.
So, of course, if you select a user, the data of the selected user will be then loaded immediately and will be then saved in that Service Items User's table to make sure you can get access to that.
Now we are going to the Service Portal. And in the IDM-- in the ServiceNow Service Portal, you are going to select to request something, and in the standard, you should find these applications. Two of the functionalities have been released to customers. One of them is create an for onboarding persons, the second one is, of course, create access requests.
Going back to the conflict parameters to discuss a little more which config options you have there. For example, do you want to perform manager approval, the first config parameter? Or should we activate the delta loads for different tables like personal service items and so on and so on?
Here, you can see the minimum number of characters, which is required for certain service items for certain user, for selected users. In case you have a very huge system, maybe useful. You can decide in that config parameter which of those two systems is your alternative system for your manager approval-- for example, for your workflow to be used. So which Manager is the correct one if you have a mismatch between your data maintained in ServiceNow and Identity Manager?
And, of course, you have your fallback approvers, you have some additional side of conflict parameters. You can put here, for example, compliance officers. If we are performing the issued checks within ServiceNow, who should approve that, for example? And so on.
So we are searching for perform. We see manager approval should be performed. Example, we don't want currently to execute the SoD checks, and, therefore we have deactivated them.
So the request validity, for example, is by default for one year. And we can change it and say, every request should be, for example, for 90 days or three months. So if the user is not explicitly asking for more than three months or so on, he will automatically get that validity of 90 days for his request.
So we are using the central account of the user to match with the user ID in ServiceNow, but you can also add an additional attribute from the Identity Manager to match them with the user ID of ServiceNow.
So now we are going to the Service Portal of ServiceNow and log in with an end user. In that example, we have the user Boris, and is logging in the Service Portal. And he is going to request something. And as you will see, is able only to execute one of those two applications as he doesn't have the necessary authorizations.
And currently, he is also not a manager, so you can only see himself. So he has selected himself and he can select the current service categories. He can put character, A, B, C from alphabet, or maybe you can also add a wild card there in case you want to go through all the service categories if it's necessary.
So he is selecting for example, Accounts. And again here, adding A for accounts or a wildcard, a star, and getting all those service items within that service category. And we are selecting in that example and SAP account. For example, we can also select any other account definitions within that service Category
So we can add here reason why we need access to that system and-- yeah. Because that will be done for the purpose necessary why a user has access to certain application or certain permission.
So is able now to submit that request but is able also to add validity or add additional service items to that request. So you can also now search for additional service categories and select their other kind of permissions if it is needed, and we can request for them. Let's go for the Active Directory groups as example here, and we can add Active Directory groups additional to our SAP account.
Just an example to show you that it's possible to select multiple service items and create the request in one step, and the system will create from that basket multiple requests for approval, and the approvers will be able to accept or decline on the item level, on the service item level-- that means one-by-one.
So now the system has created those three access requests, and we will see that we have activated the manager approval in that system, in that ServiceNow. And within this ServiceNow, the user Ben should now approve that as Ben as the Manager of Boris in that example, he will now go to the system, to the portal. He will be somehow notified by ServiceNow. And we can see there are three requests.
So you can go to the options to see for which user, which authorization, for how long. You remember, we have changed that to 90 days and we see also the reason why he has requested. So now we can one-by-one approve or reject those requests.
So, we have seen the adding group 1, adding group 2, and a CP account to the system 400, and we will start just to approve them. And as soon as we will approve them, the system will immediately communicate this decision to the Identity Manager and the provisioning in Identity Manager will start.
So here, we are changing to the job queue of Identity Manager, and we will see immediately that the process [INAUDIBLE] has started. So as you know, [INAUDIBLE] is exactly that table which contains the objects which have been ordered by the IT shop.
So now our order process is outside of IDM, but we are using the REST API of IDM to perform exactly the same steps, but from the outside-- or from the IT shop or portal of Identity Manager. So you see, an SAP user will be created by the how to Auto-Create SAP User Account, and after a few seconds and minutes, we will see that that user has now access to SAP system.
So our user is Boris. Boris is now logged in in the web portal. And he will go to his request history, and in the request history, he is able to see his request for that SAP count. And here, you can see his request number and request item number. And we see also the reason he added.
So in the workflow, we have used an calculated decision to check if that request has been executed by ServiceNow, and if it is performed by ServiceNow, created by ServiceNow, we don't need additional approval steps. It's just an example. You may have another kind of use cases or requirements which can be done, of course, also handled and, yeah, configured.
So we are going to the SAP system, we are searching for our user Boris here, and we should get that user. That's our first. And he is one of that new user that has been created by that service user, one IM service user. And he has all those necessary attributes which belongs to him to create user account in the SAP system.
And now we will discuss the workflows, how it is configured and working within the ServiceNow, and how the workflow is configured within an Identity Manager. Just giving you a more feeling here, we are going to the ServiceNow, looking for Workflow Editor, opening that, and searching for our namespace, our application.
You see, we have here that workflow. Clicking to that, and we can immediately see all those steps within that Workflow Editor. We can-- if it is necessary, you can copy the existing workflow, copy template, and change any steps or add additional steps or delete steps if it's not needed, whatever. And you see, we have also all those config parameters you have seen before. We can change the behavior of the workflow with the conflict parameters.
So we can get the result of the config parameter. Should we perform an SoD check? Should we perform an HR approval? Is there a conflict there? If yes, go for approval within the Identity Manager or within the Service Portal of ServiceNow. And do you want to perform manager approval within ServiceNow? And if yes, go to the Manager Approval. If not, go to the next step, and so on.
So all those steps are, of course, in very details here. And you can click to any of them and find out the details how we are getting access to config parameters, how we are selecting them, how we performing regarding those values of the config parameter or selected approvers, current. How can we find out or decide who is the approver of a user-- for example, the manager or fallback approvers and so on.
So that's that, what I mentioned as copy template if you want to do things by yourself or for your customers. So just take that add-on as copy template and you have everything you need. As a very good example here, you can enhance that, of course, to fulfill any requirements from the customer side if it's needed.
So, you see, we have seen the first step and the last step is just on the end of the workflow, and we can follow always the steps. We are on step as encoding. And yes. Now we are changing to Manager, of Identity Manager, and we are opening that custom workflow which we have created for that scenario for that session.
And you see, first of all, we're using the calculated decision and checking the order detail 1 attributes for the [INAUDIBLE] object, if it contains the string ServiceNow, and if yes, and we don't want to show that in the approval history, we can add there an approval reason and approval rejection reason, of course.
But we will not show that step in the workflow. And in the next step, you will see that we are adding, again, a calculated decision, but this time, exactly with the same condition, but this time, we are showing that in the approval history. That's for that reason, that in both cases, if it's coming from ServiceNow or coming from Identity Manager, you should not always have a red flag there that the request has not come from ServiceNow.
So if you now create an access request from IT shop, from web portal, or Identity Manager, it's immediately going to the manager approval and to the SoD check here and vice versa. If it's coming from ServiceNow, it is going to the left side of the green path, and automatically, it is going to be approved automatically.
So you can, of course, also have different order of your workflow. Our first example now was first the manager approval on the right side, then the exception approval. Now we have the check, and then the manager.
So, we have now seen the configuration steps, how we have installed, initialized, and configured the ServiceNow add-on for Identity Manager. We have created an access request in Service Portal. We have approved that with the user. And then, you remember, then we have logged in as Boris and the IT Shop in the web portal of Identity Manager. We could see the request history and we have been also to see that that user has an account-- a new account and an SAP backend system.
So the last part of that step-by-step configuration was to show the workflow in ServiceNow, how it is configured, and show the workflow in Identity Manager, and which options you can have there and which capabilities.
So our next and last use case will be the configuration of the ticketing capabilities and show how the ServiceNow module can be configured and used within Identity Manager to create tickets in a manual provisioning process. So for that reason, we will request manual provisioning via ServiceNow. We will show ni Manager the legacy repository and details. Manual provisioning flag will be set to our repository. We will show in the UCI web portal the request after the approval.
And of course, we will show in the Designer the config parameters regarding the ServiceNow connection and all those details. And of course, we will have a look at the Designer to the process tasks of the SCN or ServiceNow module.
The last step, have a look in the Designer to see the capabilities of the custom processes to create tickets in ServiceNow and pulling the result back.
We start here as an end user is logging to the portal, to the Identity Manager portal, and he's asking or requesting access to a system which is not connected to Identity Manager. So that's the manual provisioning via ServiceNow. We have here two groups. Let's call this system Legacy System. We have legacy groups. You can add them to the shopping cart, and the system can recognize that you don't have any account in that legacy system.
You want to add that account to your basket. You take also that account definition. Now you have here three entries. You want to request them. So, our user Volker is an example user here. He is needing access to that legacy system, and he can request that such as any other backend systems requirements or permissions. So you can also add their validity and so on and so on.
So we can see the workflow will start. And after a few minutes, we will, of course, see the results. So now we can see the compliance check have been performed. There is no conflict compliance. And the manager of that user should approve. In our example, that's the manager Elisa. Elisa will now log into the system and approve that request. This is just like any other request which we usually have.
So as manager, she has to approve that request, and the system will create tickets in ServiceNow. That's what we are expecting now. So here is the UCI portal. You see, there is no tickets currently to be processed. You can, of course, use the UCI portal themselves as ticketing system for manual activities, but the UCI portal has been, in that example, integrated or connected with the ServiceNow. And we are also creating tickets automatically in ServiceNow if a ticket or request has been created in UCI Portal.
So, now the Manager Elisa, she has approved that request, the system will now-- if we are going now to the job queue [INAUDIBLE] as administrator, we will immediately see that some actions will be now performed. So, the provisioning process here in the UCI Portal, you can see that you will get some kind of pending provisioning processes.
And they will come one by one. First of all, we will get done the access to the account. Once the account is created, we will get the rest. So now we will log into the ServiceNow in the meantime and just make sure we can then see that access request ticket in ServiceNow, which will be done automatically created by Identity Manager.
So you can see the user Volker has requested an account in Legacy System ABC, and the administrator or helpdesk, whoever, he can then go to the activities to the details and have a look on the attributes-- attribute values and so on.
So here, if we are refreshing, you should then see exactly also that user account and we can perform the activities by ourselves or by those admin users, and they can click to mark as done. Of course, in this ServiceNow, they will solve that problem, create that account in the legacy system, and close that ticket to say, OK, that ticket has been resolved.
So, we see also that there's a second ticket which is asking for the user Volker access to a membership, to a group, and in that case, that's the Legacy Group number 2 in the System Legacy ABC, which should be assigned to the user Volker.
So again, here, we can see all those details. Account Name and Group Name. And User and Administrator, it can go to the backend system, to that legacy system, perform those activities manually, and close that ticket.
So, now we will see, OK, we have here three of those items and they will be done one-by-one, sent to ServiceNow, and of course, monitored by Identity Manager.
So, the provisioning will be done. So now we are going to the Designer and have a look and the configuration options. If you are going to the cloud target system, you see, we have here a system which is calling Legacy System ABC. And that system has user accounts and groups and so on, but that system is not really existing in IDM. It's not connected.
You see, we have a manual provisioning flag, here and we will use that flag to understand and trigger the manual processes or ticketing creation processes within the Designer. So on the process components, you can see that SCN component once you have installed the ServiceNow module in your system. And you see, we have different operations here right like Create Ticket, Get Ticket Status, Update Status, and so on and so on.
And those process tasks have been used in our custom processes to perform all those activities which we already now seen in the ServiceNow as ticket. So for example, if you're taking that UCI account insert update, we have their trigger on that table, and then we are checking if it's an insert or update. And as you can see, we have here different steps in that workflow, and we can, then, regarding the duration condition, we can go to the left or right and perform an update or creating operation by creating the tickets by using of those process components or tasks from the SCN model.
So with that, we are at the end of that use case. We have requested a manual provisioning via ServiceNow. We have seen that end user has requested in the IT Shop possession, assignment to legacy system. We have seen that that legacy system has been flagged as manual provisioning. We have seen that the UCI Web Portal has created a ticket, but we have also pulled that ticket and sent to ServiceNow to create the ticket in ServiceNow to be fulfilled there.
We have monitored the result of that ticket and updated the UCI. Request, of course, and closed that automatically in the Designer. We have seen the config parameters, the SCN module, and of course, the custom process capabilities, which can be then used to create all those necessary steps like create accounts, update accounts, create assignments, revoke authorizations, and so on.
So with that, we are at the end of this session. And I thank you for your attention and your time. Have a good day.
[MUSIC PLAYING]