Secure Configuration and Operations for IM

I don't want to introduce myself again because it's my third session today. So most of you should have seen me already. But two guys who have the first presentation for today, so introduce yourself, please. Go ahead. Yeah. Hanno Bunjes. That's-- Now you're dead. Now I'm dead. No. No, it's working. It's working. Thanks. So Hanno Bunjes. I'm [AUDIO OUT] that-- [SIDE CONVERSATION] OK, Markus. Markus, go ahead, please. OK. I go ahead. My name is Markus Weiss-Ehlers. I'm a program manager consultant, and I work with Matthias Bauer in the Identity Manager team in Berlin. And we wait with Hanno until he's finished. So I will-- You can introduce-- Not wasting time. Otherwise, he shall say some words when he's starting his part. Or are you finished now? Are you OK? OK, let's wait. What we are talking about today is about how to securely configure-- as much as possible, at least-- Identity Manager infrastructure. And we're starting with the SQL server encryption, hashing, secure configuration, secure authentication suggestions, and some specifics how to integrate with our privileged account management tool Safeguard for some specific tasks. So I hope it will be interesting for you. Let's start with the encryption-setting session. That's me. First step would be securing the communication between the endpoint where the SQL client is running and the SQL server. And I guess yesterday, in Paula's presentation, she was talking about the famous acronym of TDR. And this is a way to really encrypt as well the connection between the endpoint, whether it's a [INAUDIBLE] client, a job service, an application server, an API server. Did I miss something? No. And the database. I don't want to go deep dive what you need to do on the SQL server side for it because Microsoft has documented that very well. And the only thing is, as a hint, you need to use certificates. And you need to switch in the connection string the flag to force encryption all the time. The second part is securing the storage of the database, which means using transparent data encryption or TDE. You can use that-- Microsoft is describing that very well again. But they are saying as well that there is some performance penalty because of course, when you're encrypting the files on the disk, there is some additional processor cycling required to decrypt it. At the moment, we are not supporting always encrypted for a couple of reasons. There are limitations on the Microsoft side. There are challenges for us with our generated procedures and stuff like that. So it's not supported. If you want to encrypt some fields, what we typically do for passwords that we store or anything else, we use our own encryption that comes with Identity Manager. Important as well for the communication FIPS mode, so encrypting with-- sorry-- FIPS-compliant algorithms is supported as well. This is all covered by the Microsoft operating system, and they are certified by Microsoft. So we don't have to certify anything that we are using because we are relying really just on the Microsoft stack for that. So this is fine for us at least. And what we created as well, because we certified version 8.0 and I think 8-- version 8.2 for common criteria. And for common criteria, you need to create a supplemental configuration guide, which is available on our support pages under knowledge base article, where you can download that configuration guide for-- that is sufficient for fulfilling common criteria requirements, basically. Encryption, how does it work in Identity Manager? We are encrypting database fields, configuration parameters, and job-run parameters. That's what we can encrypt. By default, our encryption uses the RSA algorithm with all the settings. And I don't know when it was. I think it was 8.0 when we changed from the old way of using only a key size of 1,024. We moved to a key size of more than 3,072 for some reasons. Number one, [INAUDIBLE] declared the 1,024 as hacked in a very short time. So it was hacked the first time I think in 2013 or so. And they were claiming that the 2,048 would be hacked or hackable in 2022. And so we decided to go even beyond that. And we decided not to use a full multiple of 1,024 because the most hacking tools start with the idea that somebody is choosing a 1,024, 2,048, 3,072 key lengths to start from there. If the field value becomes too long so we cannot store the result of the encryption, we add AS 260-- 56 to it, which we use as an envelope only, the encrypted value with RSA. So we stay within a certain field length, and it doesn't explode it within the database. Important is encryption is using the public key. Decryption is using the private key. And typically, the only endpoint that has that key is a drop server. So only the drop server can decrypt. It should never be available to fat clients to be secure and have it secure. Nobody else can decrypt a value. This is a recommendation. And that's how we initially install everything. The encryption of the fat clients is done by the data protection API. There is a kind of risk. And that's why we show later on, especially for the fat clients, an approach to better secure that as well using Safeguard. How should I put that carefully? And of course, you can not only do that with Safeguard. You can do that with other [INAUDIBLE] tools as well. Of course, we are shipping it and showing it with Safeguard as the [INAUDIBLE] solution. The web UI does the encryption of the web config mostly with, based on the local machine. And of course, we are using hashing as well. Hashing is used for passwords only. And there are just a couple-- some password-like fields. I know-- I think there are less than 10 fields that are using hashing in the database. And here we are using a pbkdf2 algorithm with a certain number of cycles and a certain length based on the .Net Implementation that is there, which is, at the moment, the most secure hashing algorithm, according to what we learned so far at least. For the configuration part-- I think it's my part. I hand it over to Markus. Your-- your mic. Maybe some introduction of Hanno beforehand. So I hope this works now, and you can all hear me. So hi. Hi, everyone. Hanno Bunjes. I'm working on the Identity Manager R&D team as team lead for everything to do with API and UI development and now, particularly on the Angular portal, mainly, for the last couple of versions. But now it's time for Markus and Identity Manager configuration. OK. So these are the topics we want to talk today. There may be more topics. But first thing is, if you ever heard about SQL injection, you probably-- many of you maybe do not know what is a blind SQL injection. And I'm going to show you how to avoid this. And one way to avoid this will be something like-- well, we call it predefined SQL statements. And I'm going to tell you about that. Then I'm showing you something about the job service authentication and two or three statements about what you should do, according to authentication in production environments. OK, so by OWASP, a blind SQL injection is something I'm not trying to inject data to change the data in the SQL database. But I'm trying to fetch information from the database by asking the query question, something like, true or false. And it can then form the result, true or false. I can get the information, hey, is there a table starting with S? OK. Is there a table starting with SA? Yes. Is there a table starting with SAP, and so on? And there are several ways into the-- things in the product that are trying to countermeasure blind SQL injection. And we enhanced the blind SQL injection in the latest versions. I think the 9.0 was a particular one the slide's referring to. And to do such blind injections, there are several statements in SQL that are potentially dangerous in that case. And the downside of this is that statements like, or greater than. And the thing is how-- these are normally statements-- if you take a look at your day when you work with the system, you want to use it well, right? Normally, a light statement, hey, show me all identities where the last name starts with E. Sounds like a valid query for me. The problem is that you can use that as well to do blind SQL injection. And that's why we started with 9.0 that not everybody is allowed to do, to run such a question that poses a potential risk. So not everybody in the Manager is able to run a query like, hey, give me all identities where the last name starts with E. How to do this, how to come around this thing, I'm going to show on a later slide. The web portals, they do need to use free queries. So if you go on the web portal and they do filtering, you search for a table, whatever, the web portals, especially the API portal, if you're talking about the new version, they need to be able to do risky queries, potentially risky queries. So that's why there's a way of configuring them as trusted client. But Markus, why isn't this a problem if I'm saying, hey, the web portal? The thing is that the web portal is normally not able to run free queries. The problem arises by blind SQL injection, not from executing a predefined query like my last name example, but if you are able to formulate your own query. So if I'm able to say, hey, last name E, blah is table name like S, whatever, true or false, whatever. These are the cases we want to prevent. So OK, our web portal is now configured as trusted client. Web portal save. The rich clients are not able to do risky queries anymore. What can I do in addition? There is another area, surface area where I have to look. And this is the public REST API. So the application server provides the public REST API. If you look at the REST API in the documentation, you see, hey, you are able to run three queries. So potentially, there is an issue from blind SQL injection attack. And as a countermeasure, we are able to turn that feature off. So the thing is, I would lose the ability to run a query at all, right? Because I cannot do my legitimate query, last name starts with E. So there is another feature-- again, predefined SQL statements. And you can turn that on and off on the application server. So the drawbacks, I think many things on the slide I already told you. So I can't use every feature in the Manager, for example, like testing dynamic roles. Dynamic roles, I provide a WHERE clause. What is my-- how are the members of my dynamic role defined? I cannot test it anymore. I can put it down inside of the tool, but I cannot test it. So for a specific set of users, I can allow them to run those queries. And the slide just highlights the program function that the permission set of a logged-in user needs to have to be able to run that query. And in addition, there's an Application Role, which already has that program feature assigned. So if I want to be completely sure, when I'm using that, I should probably think of using the protection via Safeguard or pump system if I want to secure my access to the system completely. This is here just for completeness. Hey, how do I solve this problem, those issues? So what is predefined SQL statement? A predefined SQL statement is-- there are two types of it, right? So the predefined SQL statements. We had introduced them-- oh, I think this version 7, wasn't it? Yep, it was from 6 to 7. Which is a complete, free SQL statement I can put in the database so that the application server is able to execute long, specialized SQL text without sending the SQL text from the client again over any mechanism to the application server. So we introduced the predefined SQL statements. What we did in version 9, we added a new type of predefined statement, which is exclusively for WHERE clauses. So if you do a project, a customization or an integration with our REST API and you do need to run a query that needs to use the potentially insecure statements. This is your way to go. So you formulate your workloads completely in that predefined SQL statements that are stored in the database. So the benefit here is that, without coming-- without the database, there is no way to inject some other additional SQL statement into that predefined SQL statement stuff. It supports parameters, of course. So you don't need, for any case, for my last name E example, right, I wouldn't say last name starts with E or like E. I would say, OK, last name like parameter. And then I could fetch the parameter from the outside. So how does it look like? These are just some examples. So of course, we added the predefined WHERE clauses to the REST API as well. I opted here to use Postman to show this. This is just for demonstration purposes. So I don't see that anybody needs to repeat that after me here. But we have here the same options you provide here, the name of the predefined WHERE clause. You can assign it by name or by GUID. And then you can provide parameters, including types. So if it's date type. It's an int. It's a string, whatever. And then you run the query. And you see here query parameters. And there's no additional SQL WHERE clause in that query if you look on the right-hand side, but the result is then coming as usual. And of course, you can do the same for the object layer itself. So if you do some coding and if you look at the line here, here's a WhereLimitedSQL. And I'm using here one of the SQL statements that are predefined in the product as well. So this is used by the job queue info tool. If there's a database journal, you can take a look into the database journal. And this is-- so the same SQL statement as well. So you can use it here to load your collections without having the WHERE clause in the code or if you have issues with otherwise blocks, risky statements. OK. Coming to job service authentication. I think everybody that uses the tool knows there's a famous HTTP status server web page for the job service. And in the past, there was no way to use authentication upfront before I'm able to see the page. So everybody could click on the job service page and then hey, this is a job service page. So we added the ability to use normal Identity Manager authentication modules to allow the access to the job server page. Again, this is just for protecting the data that is shown on the page. And of course, this is another one-- HTTP headers. So if your environment require specific HTTP headers to be set, then you can do this in the meantime as well. I think one or two customers asked us, hey, can I turn it off completely? Yes, you can do that as well. And the slide shows how to do that. If you don't need the information for debug purposes or for operational purposes, of course, there's an option to turn the HTML page off completely. So for synchronization, you could use the remote connection plugin. Who has used the remote connection plugin? OK, at least some. OK. The thing is, when I'm starting my synchronization editor for the other ones that doesn't know the tool, when I'm starting the synchronization editor, I maybe have not all the necessary libraries to access, for example, my SAP system. But I want to be able to, let's say, change a synchronization project. Normally, if you do that, you have the option to do a remote connection. So the connection itself to SAP is done by the job service. But you see the data on your synchronization editor, on your client. And in the past, you could use the remote connection. And you could secure it by SSL authentication. So my Active Directory credentials, you could specify an Active Directory group. And only members of that group were allowed to use the remote connection. What we're doing to 9.2, and this is heavily triggered by container usage, you can provide a secret. So you need to know the secret. And if you use a container thing-- that's why I'm mentioning it here-- the containers are all using HTTP, which is normal behavior for container startups. So you need to use a proxy up front that provides the HTTPS connection because otherwise, the remote connection will never function. So if you try to test this, hey, Markus has said there is the ability to use a secret in 9.2, and then I'm starting my container. It's not working if the container is not configured using a proxy for SSL or TLS. OK, so authentication production variants. Please let me know if all I'm saying here is obvious. I think it's obvious. I hope we agree. Recommendations are, don't use an authentication provider that authenticate you against data inside Identity Manager. This is-- again, we're talking about production environments for dev environments. So if you're using a syndication that uses identity authentication-- employee authentication was called in older versions-- or dialogue user authentication or something like that, these are valid authentications for dev environments. But please, please, please use an external authentication provider. Is it OAuth OpenID Connect? Is this Active Directory, whatever? We do the authorization, so what are your permissions in the system? But authenticate against an external authentication provider. Again, the same-- do not use authentication modules where authentication is done internally. So this is a little bit of duplication. And another one, deactivate all unnecessary, unused authentication modules so you can prevent that somebody uses a potential unsecure authentication mechanism without your knowledge, right? So in production environments, choose one of the external authentication providers and then turn off all the other ones that are not needed. OK, and I think my first part is ready. So, now-- Looks good. Thanks, Markus. Let me get that. Yeah, of course. I'll stand here so I can read this, what's on the screen here. So, OK. I want to take you on a little tour of the web.config file. Now, we get questions sometimes-- where are credentials stored? How does a server know which other server it needs to connect to, and how can I configure that, and how can I make sure that's securely encrypted? And all these informations are, when you look at the API server or the web designer component, that's part of a file called the web.config file. And you have that on an IS installation. You also have that in a Docker container. That's basically the same thing. It may be encrypted. As we mentioned before, you could have it, or you should absolutely encrypt it using the data protection API. And I'm looking forward to .Net 7 or .Net 8 when we will be able to natively use things like the Azure Key Vault to make that even more secure. And we'll have more options on there. But if you look at the web.config file, there's a couple of settings that we just need to make sure we understand. So first of all, the main connection that the application uses to connect to the database or the application server, that will be-- that's the default. Now that doesn't show. You can use an application server, or you can use a direct database connection. Either way, it will be stored in the default configuration setting. We used to have more parameters in there. We still have more parameters in there, especially around certificate pinning. Now the world has kind of moved away from using certificate pinning, but it's still there if you need it for any reason. The second one, subregister, is a special case that we need to have if you use self-registration in the web UI. If you register as a new user, there needs to be a way to enter that user, even if you're not authenticated yet, if you're not in the system. So this is a special credential string that basically tells the system which credentials it should use to connect to the database, authenticate, and enter the new identity, create the new identity record in the database. Now, there's been a small change in version 9.2, where we now have a default user for that with the right set of permissions. That's also been requested by quite a few people over the years. There's a new default user to do external registration. And during installation of the API server, if you try that in 9.2, you will see that you get an option to assign a password to that user and use that password, store it, both in the database and the web.config file. Moving on, so now we come to-- now we're linking back to what we said before about trusted SQL statements. Now, the web portal, the API server, needs to create some very flexible and dynamic SQL statements. Now, how can we tell that these SQL statements are trusted, and should be trusted, and they should not be rejected by any analysis? And to do that, we store a so-called trusted source key in the web.config file, which is to be treated like a password. So it should be encrypted, everything else. That's basically telling the system that this is a trusted application. And the SQL code that it generates is trusted. And it's very easy to tell when that doesn't work because very quickly, you will find out that nothing works in the web portal if you don't set this correctly. So-- and finally, another special case you will see, maybe you've wondered what the application token is. Now, that's kind of legacy. It's grown over the years. We maybe roll that into the trusted source key. But we have another special password for the password reset portal in order to further secure the queries that show the query and answer profile information because the problem in that regard is anybody can basically go to the system and say I am x, y, z. And I've lost my password. I need to-- I want to answer my password questions and my password Q&A profile. And for permission reasons, we wanted to have some more security around that, who can query that information. So there's a special password for the application token. And I'm sure some of you have seen also during installation of the web UI. You also get a chance to set that password once. OK, moving on, there's even more. So how does the-- how do we tell-- how do we keep apart, how do we distinguish configuration of several web applications? And that's the function of the base URL setting. That's basically the URL of the installation of your server, very simple. And that correlates to an entry in the QBM web application table in the database. So it needs to match exactly the URL in that table because that's where the configuration is stored. And we'll see in a minute how that is used for other things. Finally, I think it's the last setting-- the token certificate thumbprint. In here, you need to enter-- well, again, the installer does it for you. If you ever need to change that, here's what you do. It's the thumbprint of a certificate that the web application uses to encrypt and decrypt its sensitive information. That's used mainly for load-balancing purposes. So we'll talk about load balancing and more in a minute. But here's where the setting is. Here's where the configuration happens. Very important-- this is not the SSL certificate. This is something else. You can have a dedicated certificate just to encrypt the application-specific information and have the SSL certificate independent from that. OK, so moving on, let's talk about authentication modules for a bit. And I want to draw attention to one question that we get a lot. And it's maybe not quite as obvious where that configuration is. So every web application, every server in the system is linked to a program, what we call a program in the data model. A program can be the web portal. It can be the operations support web portal. It can be the Manager. So we have programs, and these programs themselves are linked to the authentication modules. In here, in designer, I get a chance to say which program can use which authentication module. So earlier, we saw that, of course, you should minimize, as always, the set of assignments here. The recommendation is to deactivate everything you don't need. And we kind of have some authentication modules active, maybe more than you will need in practice. That's why if you log in, if you try to log in to the web portal, at first, you will see a long list of authentication modules that the user can use. You can cut down that list to just the ones you need. And if you just activate the one for-- oh, no, that doesn't show. Sorry-- the one in here for OAuth, that's the one you will need. If you use Azure AD, for example, as your authentication for everything, if you just activate that one, the user won't even see the login screen. It will go straight to Azure AD and start the authentication flow for that. OK, let's move on. Configuration-- how do we configure these external identity providers? So I tried to come up with a little diagram for the data model behind this. So starting on the left-hand side with the server installations, already mentioned that we have the QBM application table that basically has one entry for each server installation that you have in your system. And the base URL setting that we saw before, that's how this gets correlated to the QBM application entry. And you can have several identity providers in the system. Each of the identity providers-- no, sorry, you can have several configurations for identity providers. So we split the definition of the OAuth provider on the right-hand side from the programs that use them because there's some cases where you need to have the same external identity provider but with different configurations. And we support that. And you can use several applications. So the server is linked to the application. Every application itself is linked to more than one identity provider-- to one identity provider, but you can have more than one. That's the correct turn of phrase. Can a server use more than one identity provider? No, at the moment, it cannot. That's something that we're thinking about, and we get some requests about it. But at the moment, it is a fixed relationship. And you can only use one-- for example. Azure AD. So when you talk about OAuth in particular and the options that-- and the authorization flows that OAuth supports, you need to make sure what we're talking about. And part one that I want to briefly talk about is something they call the authorization code grant. And that's targeted at browser-based clients, also known as human users that use web browsers to use web applications. So browser-based clients will authenticate to the application using OAuth. And you don't need to worry about obtaining access tokens, refresh tokens. The web browser and the application running inside the browser will do that for you. Now we're entering the world of web security and the constantly evolving fight between attackers and browser windows and people coming up with new standards, new settings. And one thing to know is that there is a setting called the SameSite setting that manages how cookies are set in your system. And to be secure by default, we ship the product with the setting of SameSite on strict mode. Now, it's very important to understand that strict mode is fundamentally incompatible with OAuth because of the way that you need to make cookies a bit more accessible if you have more than one website in your infrastructure because the web browser will first go to Identity Manager. Then it will go to the external identity provider. Then it will be going back to the Identity Manager site, so something to know. And the part in italic is basically quoted from OWASP that you can set SameSite to LAX. And you might need to argue why you need to lower that level of security, but it's basically consensus that this is acceptable for most scenarios. Plus, the strict setting doesn't work. So there's also an argument. In order for this to work, use HTTPS all the way. All the servers that participate in OAuth must use HTTPS. It's, unfortunately, not as obvious, going from what we see being done in the field. And also-- IP addresses. IP addresses is a famous one. Use IP addresses to connect. Doesn't work. Surprisingly, IP addresses don't work. So OK, and also the certificates must be trusted. So if anything breaks on that chain, your OAuth basically will not work. Users will not be able to authenticate. A typical symptom that we see-- sometimes it's endless redirection. The browser gets redirected to Identity Manager, to the external identity provider and back. And that's because cookies are lost along the way. That could be one of those things. Either the SameSite setting is too restrictive, or the certificates are not trusted, or it's a web developer running on localhost, not caring about HTTPS and just expecting things to work. And unfortunately, that's not how it's designed to work. So it could be any of those things. There is also another part of OAuth that we also support, the so-called client credentials grant. And that's not for humans, but applications accessing the system automatically. Because they cannot use a browser, they need something else. So application server and API server both support that mode as well. What you need to do is to enable the configuration parameter mentioned here, access token authentication. That tells the service to look for the authorization header in HTTP requests, according to the standard. And you can use that to authenticate securely any client, any service, any application that wants to use-- that wants to access that Identity Manager. OK, moving on. Let's talk about load balancing for a bit because we also get a few questions around that. Do we support load balancing? Is that supported? And the answer is yes, as long as we're talking about the new API server, including the Angular applications plus the application server. These server installations support running behind a load balancer. You need to-- the recommendation is to configure sticky sessions. What does that mean? That means that one user will always be directed to the same server inside the pool managed by the load balancer. And why is that? Of course, for best performance. If you're going to talk to-- if you're going to be directed to a server that doesn't know you, there's an overhead, there's a performance penalty because the session will need to be recreated. In order for that to work, in order for all servers in a load-balancing pool to be able to read and write the session information, they need to be configured with the same encryption certificate. Here's where the web.config setting we saw earlier about the token certificate is important. Basically, the service just can interchangeably read and write the session information. And you can scale up and down your service as needed. Integrating OneLogin, multifactor authentication. So I talked a bit about this yesterday. Do we support step-up authentication? So if we have a critical product, a critical attestation procedure, can we further have more security around the approval of these attestation cases? And we do that with OneLogin MFA at the moment. We can configure OneLogin as a further multifactor authentication provider to have on-demand step-up authentication. For every time that something critical action, some critical action is needed, is performed in the system, a call goes out to the OneLogin service. And if you previously registered your app or your cell phone number with OneLogin, you can use that to have another factor of authentication. This can be combined with any authentication module so you don't-- it's not restricted to having OneLogin as a primary mode of authentication. It works with other stuff, with other modules as well. And that brings me to the end of this section. Cool. Yep. Before we go forward, maybe-- we heard a lot now. So I would like to interrupt here before we show the rest for questions, if there are some. The new Gazelle, the new Gazelle. Is it possible to elevate authentication to request MFA for some tiles in web application, not for-- I mean, for some forms? So we have-- currently, we have it only for accepting terms of use. Wait, hold on. Accepting terms of use in the IT shop, approving IT shop requests, and approving attestations if you switch it on for those business objects. Now, we have the extensible model to have-- to be able to trigger a step-up authentication flow for any kind of action. Now, we need to work on providing sample code for that to have it. But it's fundamentally possible to do that. I'm not sure if that answers your question. Does it go into the right direction? [INAUDIBLE] triggers it? So what triggers, OK. So basically-- The trigger to have it. Yeah. Basically, you need to-- you will have to have some kind of UI customization because you need to integrate that in the UI. You need to show the OneLogin-- for example, the OneLogin components. And then the backend, you will have an API. You will have to make an API call that basically starts an authentication flow in the backend and basically waits. You can do polling, or you can do multiple things there. And wait until the user makes that authentication and completes that authentication flow in your system. So it's both UI and API customization that is needed there. Thank you. OK. Other questions? Other questions. Oh, in the back, come on. Is there also the possibility to use other MFA providers? Generally, yes. And I'm kind of guessing which one you would like to have. And the problem is that if we're talking about Azure AD, Azure AD at the moment does not support, to the best of our knowledge, triggering a multifactor authentication without going to the complete authentication flow again. OK. That's why we don't have Azure AD at the moment. Hopefully, that will change and we will have-- we will have that next year in some shape or form. And for other markets, companions to OneLogin, you would need to kind of write the same plugin as we did with OneLogin. More questions? Yep, right-- Question there. Yeah. I'm running high. Is it possible to use the step-up just as another authentication provider, different-- OAuth that you've already configured in One Identity. You can have multiple [INAUDIBLE]. OK, I'm not sure I quite understand the question. Could you just come again, please? Yeah. You authenticate with OAuth. And then you hit something you want to step-up on. You could have a different OAuth configuration that sends you to an MFA or does something, a different type of authentication. Is that possible? Yes. Once we support OAuth at all at that stage-- because currently we use OneLogin, which works differently. It does not use OAuth. So at the moment, we use OneLogin. And that's a different interface, different APIs. But OAuth doesn't give us-- as a standard, OAuth doesn't give us that option to say, I want to trigger a multifactor-- multifactor authentication. So you always need to look at what provider in particular you're talking to. [INAUDIBLE]. That's what I said. You need to-- we only have that API plugin implemented for OneLogin at the moment-- of course, for some obvious reasons. But if you would like-- I know that-- let's just name it Ping and Okta have same-- similar interfaces to just do the OTP token exchange. And then you just would need to have to implement that plugin that we implemented in the API for OneLogin. You would need to implement that for the other vendors. More, for the moment? Nope. OK, then Markus, I guess. OK. So the last topic we wanted to show you is how to use the Safeguard integration to protect my client connections from Identity Manager. And this is with courtesy of Dr. Stephan Hausmann, by the way. Is he here? Yeah. Did a lot of work to make that happen. Thank you, Stephan, for that. Not for the first part, but for the second part, obviously. So we're showing two integration scenarios. The first one is how to use Safeguard as a password vault because I heard the question-- the days, how can I protect my credentials I'm using to connect to external-- to the target systems, right? So obviously, we are encrypting the passwords or the access tokens or whatever you use to connect to an external target system. But maybe it would be better to store it in a password vault because I would get password rotation out of the box. I don't need to care about password rotation, changing all the synchronization variables. So how can I do that? And the second thing is, as I told before, how to secure the access to the administration tools of Identity Manager. Starting with the first one is there's an out-of-the-box solution for that. And what the out-of-the-box solution is doing is using the ATA mode of One Identity Safeguard. And another generic feature, the scripted variables. Who has used scripted variables before? OK, obviously. OK. So some of them. So if you look at the synchronization editor, normally the variables are fixed. And they're fixed when you set up the connection to a target system. But let's-- for other use cases than that one, it could be that you want to ask external servers or whatever to fetch the current value of a variable you are using in a synchronization project. And this is what we are doing here. So what the scripted variable is doing is using this certificate to call via A-to-A Safeguard, get me the password for my-- or get me the credentials to be generic for my specific system at the current time. So I'm doing a password checkout. And the nice thing about that is I get the current one. If I would store the-- let's assume I could do that as well. Yeah, I'm starting a job. In the job, job before the thing starts, and I'm fetching the password from somewhere else. Maybe at the meantime, before the first job has fetched the password, and the thing would run. The password has changed. The scripted variables will be executed at the time the synchronization engine tries to connect to the target system. So there's less likely the cause that the password has been rotated in the meantime. So technically, things-- what we're doing is just things that are publicly available on GitHub, for example, or how does the PowerShell website-- One comment here. When you are using the GitHub, the One Identity GitHub, for downloading the PowerShell and you contact our support, they will say this is not supported. Always use the package from the PowerShell gallery because this is officially supported. It's the same again. OK, it's the same code. It's the same tool, just packaged differently. And yeah. But PowerShell gallery is-- I've searched for the PowerShell gallery, it was. OK. And there are snippets in the Identity Manager out of the box that allow you to do that. And this is just a screenshot how it looks like. So we go into a variable. Then you use our snippets that we provide, snippets for those sake, one of the snippets. And then you just need to fill in here, the yellow marked items. Of course, you need to configure this in Safeguard as well. I'm not showing how this is going to be configured in Safeguard. You need to-- the certificate user that connects to Safeguard needs to have access to the specific password you're trying to check out, obviously. That's why he is-- you need to provide the API key and so on. And remember, this one here, again, API key and the other stuff is, again, encrypted, or you can encrypt the data here. OK, the second topic. Using Identity Manager tools with Safeguard. And again, thanks, Stephan. What can be protected? Two things you need to protect. You need to protect the database connection, or if you want to, you can connect the system user or the user that connects to the tools in general. Why are we talking about this? So let's face it. You can use an application server connection in an administration tool. Awesome. You don't need to configure SQL server connections. It's fine. But not every tool allows you or cannot do its work if you're doing an application server connection. For example, if you do want to have a schema extension and so on, you may need an SQL server connection to do so. And what we're doing here in that example is we're using the Safeguard for Privileged Passwords and Safeguard for Privileged Sessions to show you a way how to configure that how to protect your clients. So the goals of these use cases, as they were designed, were they should only be available on a dedicated server. So nobody else should be able to install and use the Identity Manager tools other than going to that server. The password to the database connection should be unknown. Sounds reasonable. Database authentication should use Windows-integrated authentication. And that-- of course, if I want to protect the password, I should use Windows Authentication because then, at that point in time, I don't have to specify it. And as a bonus, I can rotate the password because I don't have to change it on every client if I rotate the password. So we have three use cases prepared, the first one using just RDP. So if you look at those, you see one. You see two. You see three. They are getting better from the top to the bottom in terms of protection. So RDP, just to the dedicated server. And I'm going to start the video here. Does it start, or do I have to click again? I have to click again. Yes, no. OK, so I'm going here into Safeguard for Privileged Passwords, and I'm requesting the access. And here, you see here, I'm requesting an account. It's called called DBconnection01 for demonstration purposes. And there it is. One is in the queue. I'm now requesting the access and starting my RDP session. Now it's using Safeguard magic. And then I'm logged in the RDP session. And the thing to mention is we have to take a look at how I'm starting now the Identity Manager tool. So what I need to do-- so first of all, of course, I'm [INAUDIBLE] DBconnection1. I've requested the access. And I'm starting the launchpad. And now here, you can see that the connection is done using Windows Authentication. So I just protected, in the end, the connection because I don't have access to the connection other than using Safeguard. But I needed to provide my credentials here in the launchpad. And then I can use everything here in the launchpad. But I have a full RDP session. OK. There's one drawback by this solution. You need to ensure that there is no SQL Server Management Studio installed on that machine because otherwise, I could use the connection then to go to SQL Server Management Studio and do whatever I want. I have the permissions to or permissions for. OK. Next scenario-- I'm using the RDP application from the dedicated server. So what's the difference from RDP to RDP application? I'm not starting a full desktop session. I'm just starting my launchpad application. So this is the next step because when I'm starting the application, I can ensure that I'm not able to start, for example, SQL Server Management Studio. So here, we have prepared three of those connections. I'm saying we. Stephan prepared three of these connections. And again, we're having one in the queue. We start in this one here-- again, starting, starting, starting. And you can see here, he's starting launchpad. So just launchpad, no desktop session. That's the second step. Drawback here again. You have to provide your credentials. So the connection is not set up completely. I can start everything-- interesting, I can start everything that is configured in the launchpad and can start all the tools from the launchpad even while I'm using RDP applications. So it's not limited, in general, to that. So showing this in the privileged session section. So this is the SPS part now. You can see here, I do have the session as I'm seeing the user, and I'm seeing the mode user for the connection. OK. Look out. Look out. OK. OK. OK, now we're going to show-- and use another one. And I can see, if we do a new request, that one session is already occupied, of course. That's why we're having here three sessions. Terminate, terminate. OK, session terminated. I don't have access anymore. So now, coming to the last one, which is, again, using RDP applications over the-- if you look at the connection into the tools, we can see that I don't have to provide-- need to provide my credentials anymore. And if you ask for recommendation, if you do something with any PAM tool we show in this here for Safeguard, we would encourage you to use the last one because this is a secure way of doing it because you protect the database connection. You protect the login into the tools. We are by the topic before. And why are we doing that in general? Why is this here, is working? Let's see here. I'm admin A-- action. So I'm using, of course, here-- Active-- Windows Authentication here, Active Directory user account. For the login here, I'm authenticated. Referring back to Paula from yesterday, we told you, hey, we're using deep Microsoft APIs, data protection APIs to protect the OneLogin credentials, right? And if you watch the session from Paula, you can see data protection API, even if it's based on the user, you can do any-- you can get, have access to it. If you have access to the computer, restarting, doing some magic with our tools. So this is the next step to protect those settings. OK. Should be done. Is it done? Yes, it is. Questions? So I really like the scripted passwords being fetched by the sync editor. So if I were to put that in, for example, for every update job and I did 10,080 updates, would my Safeguard or my Identity Manager start to cry, or would it actually be able to handle that? So if I had it fetch the password-- First, firstly, are you going to answer, or should I? Go ahead. So the thing is, first of all, it shouldn't cry. And the second thing, even if you do 10,000 updates, the synchronization components do some connection reusage. So even if you have 10,000 jobs-- let's say update some properties in a D group or a D user, it will not reconnect 10,000 times. And this is another reason to-- by the way, this is another reason to use the scripted variables instead of setting the variables from the outside using a different job. Any other questions? No more questions. Then-- Hey, we're on time. Thank you for your time. Thank you for being here. Hope it was kind of interesting, and see you next time. [APPLAUSE] Thank you.