Well, we're going to jump right into it. So we can get you out of here on time. Again, I'm Bruce Esposito, a strategist here. We're going to talk a little bit about Identity Manager and what your options are when it comes to the cloud with Identity Manager. There's many options.
This is kind of a high level. I'll reference at the end there's actually a more deep dive session being done tomorrow. And so we'll talk about that a little bit here today, too.
But I start with this one. Who remembers-- now, you probably all know what these are. But who remembers actually using these? OK, everybody does.
Now, how many of you honestly-- now, I know I remember using the 3 and 1/2 inch. And I remember the first ones I actually used was a 5 and 1/4. I never actually used an 8 inch. I saw the 8 inch, but I never used the 8 inch. Anybody here actually use 8-inch floppies? You guys are pretty old.
And the reason I say that-- what's interesting about this, because we all remember using these things-- this is the amazing thing. It wasn't until 2019, October 2019, that the US nuclear weapons, all the nuclear bomb arsenal in the United States was still run on 8-inch floppy disks up until October 2019 when they finally went to solid state drives.
And the reason they did, they said because it was unhackable. It's unhackable, because there was nothing connected to it. And they literally would send the launch codes on a regular basis on an 8 and 1/2-inch floppy disk, and that's what they would plug in to the ICBM systems for launching all the nuke codes. So it's amazing.
So the point is-- and I use this-- what does this have to do with Identity Manager? Well, if you've been using Identity Manager for a while, or even an IGA solution. Maybe you don't have Identity Manager. Maybe you've got a competitor's product.
The reality of it is sometimes IGA systems are kind of like nuclear systems, that they're really complicated. They take a long time to get going. And once they're working, it's hard to even mess with it anymore. You feel like, let's just keep it going.
And we see that all the time. We get RFPs on a regular basis for customers that have been using our competitor's IGA system for 8, 10 years. And they're finally at a point to where they have to get rid of their 8 and 1/2-inch floppies, or in this case here, they've got to make a change.
And maybe you're at that point. Maybe you're at a point. You've had an on-premise Identity Manager or another product for a long time, but you're finally going to make that step and say, we've got to make a change now. We've got to upgrade-- maybe go to a newer version. We've got to look at something.
And the big one-- obviously, almost every RFP I see now from organizations, with the exception of a few really large customers, most customers are saying, for our next big change in IGA, it's going to be cloud-based. That's what we're going to build that into it.
But when you say go to the cloud, you get all kinds of questions. What is the impact of going? What does it mean when I go to the cloud? Are we going to go SaaS? Are we going to go private cloud? What are my options when I do that? How does it change the architecture? What's the process to migrate from on premise to the cloud? All these questions come up.
And so what we're going to try to do today is kind go through what are your choices, what are some questions you're going to need to answer to give you an idea of what it means to take Identity Manager from on premise to what are your options to deploying it in the cloud.
So this is one of the things that OneLogin separates-- or One Identity separates us from our competitors in this space. The vast majority of our competitors do not provide this path to the cloud that we do. And the reality of it is at One Identity we're all about this idea of cloud without compromise, that whether you're on premise today and where you want to go on your cloud journey, you can do it with Identity Manager. And you can do it with the same version all the way across.
So if you want to go to a hybrid environment, odds are a lot of you might already be hybrid. You want to go to a private cloud. You want to go SaaS. Anywhere you want to do that, we offer you the flexibility to choose these options, and how you choose it. We have packaged services at these different points that we're going to talk about a little bit.
And the investments you make can be preserved from one to the other. And that's a big one. You've invested all this effort on premise. Now you go to the cloud. You've got to relearn and redo everything. Well, that's not true with Identity Manager.
So let's take each one of these. We'll start with hybrid. Now, what do I mean when I say hybrid? Hybrid means that you probably are on premise, but you're connecting to a lot of cloud stuff. So a portion of what you're interfacing with is cloud, but your basic IGA system is on premise.
And of course, we've had this for a while now, but to help you make that transition is Starling Connect. You may be familiar with it, maybe not. Maybe it's new to you.
Starling Connect is our solution for a hybrid environment. And it is, I have on premise, but I've got a lot of systems now that I'm deploying in the cloud I've got to connect to all these SaaS systems with my on-premise IGA.
This actually started out of a project we had for one of our larger customers that had hundreds of SaaS-based applications. And the challenge was they were adding new ones all the time. And they had a very large identity, or they have a very large Identity Manager implementation. And the challenge was every time you add a new SaaS application, it's adding another connector into my environment. So they had this huge hub and spoke environment. And they were like, what can we do to simplify that?
So looking at the architecture with Starling Connect is-- the way we solved that is let's say let's manage all the connections to SaaS-based connectors through an external microservice SaaS architecture as a separate hub from my on-premise applications. And it simplifies it tremendously.
So in short, this is kind of the architecture you get. It's straightforward. You have your Identity Manager on premise, but all of your SaaS-based applications or the vast majority don't have direct connectors to your on premise. Instead, they connect to this service called Starling Connect. It's a SaaS-based microservice subscription that we can provide.
What you do is you take your on premise. You connect it to Starling Connect with a connector, a single connector. It's based on SCIM. And that provides the one hub connecting to the other hub. And then Starling Connect is a web-based service that you can go in and add all the various cloud connectors we have. And we have lots up there.
And these are full bidirectional, for the most part, provisioning connectors with all the features, whatever's provided by the API or the SaaS provider we're providing. So now what you do is it's very simple to add one. You literally go to our web application, Starling Connect. You go click on the one you want to do. Fill out the requirement's configuration. And then, boom, you now have the connector. And that's already connecting back to your on premise to do that.
So it becomes a very simple, easy way to manage a lot of SaaS connections through this separate service called Starling Connect outside of on premise. And again, that provides that simple hybrid, that first step of, yeah, we've got lots of SaaS applications we're adding into our IGA, even though our IGA is still on premise.
The next option is private cloud. And so this is a big one. This private cloud says, OK, I've got Identity Manager on premise, but now we want to start deploying it into a private cloud. And so several choices we have to make-- first of all, which private cloud do you want to put it on? Typically, the big three are Azure, AWS, and Google Cloud, all of which we support. So you can pick which one of those you want to deploy it on, and you can deploy it up there as well.
And then, of course, the other question you're going to ask yourself is, when I deploy this, how do I want to deploy it? And we support both options, either deploying it as a virtual machine. That, in some ways, is the most simplistic way to do it, not necessarily the best way to do it. But it's more similar to managing an on premise, but just with virtual machines in one of our providers.
Or you can go to Docker containers. And containerization offers several unique features that go beyond our discussion here today. But we support all these options when you decide to do that.
One of the ones that-- while all of them are equally supported to go through there, there's several that we use, which I'll talk about in a minute. Our own SaaS, we prefer Azure to do it, because of several features we like that we get with Azure.
A couple of things, well, first of all, about containerization. If you decide to go the containerization route, you can go to the Docker hub today. You can search on One Identity. And you'll see all of our vendor supported, vendor provided containers.
This is another thing that, actually, separates us from some of our competitors. We have competitors that support containerization, but they don't give you containers. You've just got to go make them yourself to do that, or you've got to go find somebody else who's built a container and sharing it on Docker.
But these are all provided by One Identity. And these are our containers that we support. So you kind of have that behind you if you go the Docker container route.
When you go to Azure-- you'll find one interesting thing when you go to Azure, you'll find it is available on the marketplace. Now, there's a good and bad about this, about Identity Manager on the marketplace. Identity Manager is a little more complex app that it's not as simple as saying, go to the marketplace, like you would with some Azure apps. And you say, buy now, and you just click Buy Now. And then you go in, and it downloads into your tenant, and you're kind of ready to go and you start configure it, and going.
Identity Manager does not do that. In fact, you'll see on there when you go look at it, it says Contact US. You're like, ugh, OK. But there's the good news why it's on the marketplace. So the marketplace isn't going to make it easy for you to just drop in your tenant. You're still going to have to deploy it in your tenant, a manual process, or through Docker, or something like that.
But what this tells you is that this is actually supported for the Microsoft Azure Consumption Commitment, the MACC. So if you're a big Azure customer, you probably have a MACC. You've made a commitment to Microsoft to spend so much money with Microsoft Azure each year.
Because One Identity Manager is available in the Azure marketplace, your purchase of One Identity can apply toward your MACC. So that's a good thing. So you can actually get it through Microsoft through your MACC commitment to do that. So that's a plus of having it up there.
It's a couple of the options that you have when you go in there. One of them is the database you're going to choose to put it on. You can obviously put it in virtual machines, or just use a regular Azure or SQL database. But Azure offers two different versions of SQL that'll offer some unique advantages, particularly for Identity Manager. There's Azure SQL, which we now support, and Azure SQL Managed Instance. Both are very similar.
Again, you can look at it. And Microsoft has all kinds of features you'll learn about it. But it's highly fault tolerant, highly available. It can be redundant. It's autoscaling. There's a lot of unique capabilities that the Azure SQL provides. And we recommend deploying it on Azure SQL, particularly if you're a larger size customer.
A couple of the basic differences between, do I pick Azure SQL database or Azure SQL Managed Instance? Both are very similar. They both offer a lot of the same features, but there's one basic difference to consider one or the other.
Azure SQL database is autoscaling, and it's kind of pay as you go, which means you only pay for what you use on it. Azure SQL Managed Instance, generally, is you're picking out your resources that you need, and you're getting a specific size database that you're doing. So it can be more expensive.
And generally, what we have found is that it's often best to go with an Azure SQL database to determine what your needs are. You'd be surprised. We were surprised that we didn't need as many resources on the Azure SQL database as we initially thought we might, deploying it on there.
So we do that. It autoscales. As you begin to increase, you need more load, or if your load varies throughout the year, as far as the database goes, the Azure SQL database will auto scale with that and will only charge you what you're using. If you're a larger customer, if you know you have consistent needs and you've already figured that out, then the Azure SQL Managed Instance may be the way to go, because you can know that you've got a set performance established, set resources established. It's always available at that, instantly at all times.
So for some of our larger scale customers, we often will recommend just going ahead with the Azure SQL Managed Instance because it kind of gives you that horsepower right, ready to go at all times. And you're kind of consistent, what you're going to get. But both work pretty well. And we're very happy with using them for the database.
Of course, the other side you're going to have is if you go containerization, which is what we do internally, you can put Docker, of course, inside of Kubernetes. And then with that, you have the Azure Kubernetes service, which offers, again, some of the easy management autoscaling, auto deployment capabilities that provides, and managing the container, Docker containers for Kubernetes. So that's another unique feature of having that is using that Kubernetes service inside of Azure.
So again, a lot to think about. This, you're probably have tons of questions on. Tomorrow-- I'll give you more details at the very end. But tomorrow, we have an hour and a half long deep dive session on this. So if you want to know, what are all my options? What do I do? How do I deploy it on Azure? What's the best way to do it? We have a whole session tomorrow. We're going to deep dive and go into the details of deploying Identity Manager on top of Azure.
And then the last one we talk about is SaaS. This is our newest version. It's been out for several years now. But we have Identity Manager On Demand. The current one is called Starling Edition.
What is Identity Manager On Demand? It is the same Identity Manager you would use on prem. But it is deployed as a SaaS service. So what we do is we deploy it for you, the customer, inside of an Azure tenant. So it's just the same as if you deploy it yourself, except the difference is we take responsibility for that.
So One Identity will actually deploy it for you. We'll create the Azure tenant for you. We have the whole architecture. We spin it up for you-- get everything running for you. You're still responsible for configuration. You're still responsible for day-to-day usage, and adding all the connectors, and configuring all that information.
But the basic environment will be run by us. We take responsibility for that. We oversee its performance, its scaling to make sure it's all meeting your needs at that time. We also take responsibility for upgrades, and patches, and fixes. So the basic environment, our ops team will run for you. And it's, obviously, SaaS is done as a subscription model. So you pay as you go on an annual basis, based on the number of users you have.
This is kind of a basic idea of what the architecture looks like. It pretty much is, I mentioned before, we use the Azure SQL server. It's going to be what we're going to deploy. We're going to create a custom tenant just for you, your own tenant with your own Azure SQL database. We're going to put the other servers, the web server, app server, API server, job servers all within a Kubernetes cluster, running on top of Docker containers.
And then we're going to connect that back to on premise through a job server. So you're going to deploy an on premise. We have an image we give you. You can deploy a job server on premise. It will connect back up into your Azure SQL using HTTPS. That will give the connectivity to all on premise applications. And you can deploy all the on premise side to do that.
So that's kind of the way we deploy the basic architecture. It'd be similar if you wanted to deploy it yourself to do that. But again, it's providing a service that we provide for you.
One thing to talk about when we talk about this is because our competitors seem to like to talk about it a lot is multi-tenant versus single tenant for IGA. Some of our competitors, their SaaS IGA solution is multi-tenant. And so they love to tout that they're multi-tenant, which means they're more modern, and they're better for IGA. And anybody-- hint, hint-- One Identity, that single tenant is somehow inferior to multi-tenancy when it comes to IGA.
And I want to dispel that notion here once and for all. Now, I'm not here saying that multi-tenant is not as good as single tenant and vice versa, by any means, right? There are times and reasons to use multi-tenancy for SaaS versus single tenancy. We do. For example, OneLogin is a multi-tenant service we provide. Starling Connect is a multi-tenant microservice that we provide. So we do deploy things multi-tenancy where it makes sense.
For an IGA application, particularly one like One Identity's Identity Manager, we've personally found at this point, because of the architecture and our customers' requirements, it's superior to have it as a single tenant versus multi-tenancy. And why do I say that? Well, here's my list of why to understand it.
First of all, I want to define what multi-tenancy is. And this is multi-tenancy as defined by AWS. Multi-tenancy is a SaaS service that shares all of its resources, compute, and storage with all of its customers. So in short, multi-tenancy means that all the customers are running in a shared tenant environment, usually built on top of microservices that do that.
Single tenancy is the opposite of that. It is a tenancy that's created an environment just for you with all the resources, all the storage is in there just for you. And that's the single tenant environment. That's the way we deploy it.
Now, our single tenancy is what we refer to as single tenancy, but multi-instance. So your single tenant that's deployed for you in Azure actually has several instances. You get two by default. You have your production and pre-production, both sitting inside the same instance, or same tenant, but multi-instance.
By the way, this is exactly the same architecture, for example, ServiceNow uses. So if you do ServiceNow, you'll find that you have a single tenant multi-instance version of ServiceNow. They have a similar architecture.
Now, what are the differences between the two? Why do I care? A couple quick things-- multi-tenant versus single tenant, cost, cost to vendor-- multi-tenancy is generally cheaper for the vendor than single tenancy is. If I can put a lot of customers in a shared environment, it's cheaper for me per customer than it is to try to create a separate environment for every customer. It's cheaper to manage, cheaper to deploy. So me as a vendor, I prefer multi-tenancy from a cost perspective, because generally it's cheaper.
Now, just because it's cheaper for the vendor doesn't necessarily mean it's cheaper for you the customer. We have found that there's been no case where I found a competitor pricing that we could not match or be competitive with, whether they were multi-tenancy or not. So our ability to provide good pricing to meet your budgets is not affected by multi-tenancy or single tenancy in our perspective. But it definitely affects the vendor's choice, which one they choose.
In a multi-tenant environment, they use a shared database. So if you're a multi-tenant IGA vendor, your data is in a giant data store with everybody else's. Now, they use partitioning and encryption to protect it and separate and isolate, but you're all in a shared database environment. So that's a concern. You have to worry about is that a concern for you or not. Obviously, for us, your data is stored in a dedicated isolated database just for you. That's one thing that's done.
Interruptions-- obviously, if a service is interrupted in multi-tenant, it can affect everybody. A service interruption inside of a single tenant only affects that user. So obviously, if one user goes down, it only affects that person. It doesn't affect all the other users trying to share the same resources in that environment.
Multi-tenancy-- one of the things that they like-- and it could be an advantage for you, or maybe not-- is constant upgrades. So a multi-tenant IGA solution means you're constantly getting upgrades. In fact, a lot of times it's almost daily you will have new features, patches, fixes applied. Everybody's running the same latest version all the time, and that version is constantly updated. That does not work in a single tenant environment.
For our environment, you do get regular scheduled patches, fixes, and upgrades. So the way we do it is several times a year we'll contact you with whatever, whether it's a patch or an upgrade. We'll let you know in advance that this is the next one we'll be rolling out, when we would like to roll it out inside your tenant.
We schedule it to work with you to roll it out. We roll it out in pre-production-- allow you a period of time to test it and evaluate it. When you say you're happy, then we schedule to roll it out in your production instance. So you have this change control environment. Some organizations actually require or prefer to have change control versus an environment that's constantly changing. But that is different, and something to be concerned about.
I talked about the scheduled upgrades. Limited customization versus flexible customizations-- this is another big question we get asked. Generally, multi-tenant IGA vendors basically say you get very little you can customize.
The reason is because everybody is sharing the same version environment all the time. It's changing. You can't allow everybody to make lots of different customizations. You all pretty much have to run the same thing to do that.
That's not true. When you use Identity Manager in our SaaS environment, we allow you to make customizations. You can customize it. What does that mean? Well, there's kind of a warning in there to do that. And this is basically what the customization means in our environment.
We don't prevent you from doing any customizations in your environment. You can do whatever you want to customize it. But that comes with a risk. The risk is, just like on premise, when you make customizations to the environment, should you break it, or should a future upgrade be affected by the customization you make, you know who's responsible? You are.
You made the customization. You'll have to go figure out-- or we can help you through support to figure out the problem that needs to be resolved before we can do an upgrade, or a patch, or a fixer like that. But ultimately, while we allow you a lot of flexible customization, there still is responsibility to do that.
That really isn't a big factor, we've found, for most customers now, because, for example, a lot of the customizations that were done were on the web side. And with the latest version, we use Angular for all the web development. That generally isn't affected by any upgrades or anything like that. So the customizations generally don't affect upgrades or anything like that in the future.
Another one, too-- obviously, a shared environment, there's concern about increased risk for security. Everybody's kind of running off the same shared environment. Isolated environment, we're able to secure it just for you. Each environment kind of has its own separate security model.
Performance/scalability-- shared environment, everybody's running and being scaled together. In an isolated environment, in our environment here, the performance and scalability is tuned just for you. Your database will scale for you and your needs as you need it. It's not relied upon looking at everybody and scaling it as one giant behemoth, as we do that.
And the biggest difference you'll notice, too, is if you have an on-premise architecture today-- for example, if you have Identity Manager on prem today, and you go to our SaaS, it's the same product. That's not true for our competitors.
If, our competitors, you have their on-premise product today, and you want to go to their SaaS product tomorrow, it's a completely different product. Architecture, configuration, everything is very different. So it really is a rip and replace to migrate from one to the other. That's not true for us.
Now, there still is a migration process. It's not as simple as saying, I'm just going to copy it all up to the On Demand instance. But the beauty of it is if you have on prem today, and you move to our SaaS is you preserve all the work you've done. So all of your training-- you don't have to learn a new product. Your users don't have to learn a new product. A lot of the efforts you've made in architecture and configuration, a lot of that can be preserved and redone inside of the SaaS environment. So you preserve a lot in doing that that you wouldn't if you tried to go to a multi-tenant environment.
So that's just kind of a high level over that thing through there. Again, I'll reference some of this information later that you can look at in more deep dive.
Another area, too, that we've just released recently is packaged implementation services offering for our SaaS. So a lot of customers say, hey, we want to move to SaaS. And I just want a price. We want this basic done in phase one. Give me a fixed price and a set number of time to do that. And so we've set up these packages to provide a basic idea of what it's going to cost you. And we have these bronze, silver, and gold packages, each one kind of building on the other one.
So the bronze is the basic one. If you want silver, you end up getting everything in the bronze, plus the additional silver. And each one kind of adds a little more components. If you want just Joiner, Mover, Lever, that's bronze. If you want to add Self-Service and Governance, that's silver. If you want to add Compliance and additional connectors, that becomes the gold.
So each one of these has a fixed amount of time we apply to it and a fixed cost. So it makes it very easy to budget and determine what you want to accomplish and how much you'll accomplish. There's also additional add-ons to it. So for example, you might start with the bronze, but you might need one or two additional connectors. We have little add-on packages to add on a third or fourth connector to it or something like that to do that.
But I think this is going to help, particularly, a lot of customers that want to figure out what's it going to cost me to go to SaaS. They want to have a good solid budget to find. This can help you do that with these fixed cost packages that we provide for deployment.
Where can I get more information afterwards? Well, a couple of things here-- more information about the single tenant versus multi-tenant, if that's of interest to you. We have a blog. If you go up to the One Identity blog, you'll see a reference article, which kind of goes into more detail of some of the things I just mentioned there.
If you want to find more information about hybrid, about Starling Connect, we have a white paper that deals with the advantages of using a hybrid environment. There's a video also up on our website called Your Secure Path to the Cloud that kind of becomes an overview of a lot of what I just mentioned here.
And the last one is, for those of you who want more detailed information about how you deploy Identity Manager in Azure, which database, do I use Docker, all that information, how's Kubernetes apply, again, tomorrow from 3:30 to 5 o'clock, there's the session "One Identity Products Deployed on Azure," which I think is going to be in here. And I think it's pretty full.
But anyways, you'll try-- you can go check that one out. And we'll have our experts here tomorrow to go through that in more detail about deploying it on Azure and a little bit about what we've done and we've learned deploying on Azure ourselves.
So anyways, that's it. We appreciate the time. I'll take a minute or so for questions, if you have any questions at this point-- a question right up here on the front. You got a mic?
1, 2, 1, 2.
1.
There we go.
Yes. Yes, I have a question. You were talking about having a pre-production and production environment on the single tenant. One Identity generally recommends three stages. So where's the third stage there? And can you say something to this [INAUDIBLE]?
Yeah, excellent question. That's very good. We've had-- so the reason we provide two, we have found that our small to mid-sized customers, two is generally enough. But you go to mid-size to large, they want three. So what we do is the third stage is a la carte. You can purchase a third test stage, if you want it, as just a separate additional subscription price on it. It's a flat fee every year to add a third stage.
OK. Then the next question directly concerned is this. Why is the third stage not implemented on the same tenant? Because my customer has it on a shared instance then, and he didn't want that.
So there's a long technical history behind that, but short is it now is in the same tenant. So any new customer going forward, it is. When we first rolled it out, we rolled our product on top of the SSMI database. And because the SSMI database, the way it was, it was this big, huge database, very expensive. It didn't make sense trying to also deploy a small test environment on a big SSMI database.
We've since changed that. We've gone to Azure SQL, because of that with the Azure SQL environment, or whatever. So if your customer right now has a challenge, we can talk about that offline. But any customer moving forward, the third one is in the same tenant, which makes sense.
OK. And then the customizations, that was in the same direction, because having the customers on the shared tenant with the [INAUDIBLE] environment, you have the problem, right?
100%, yes.
We should definitely change the tenant.
Yes. So we fixed that now. But you're right.
Thank you.
Yeah, thank you so much. Other question-- question over here.
One of the questions we frequently face nowadays is pen testing. People want-- any RFQP asks for a pen test report. So does One Identity provide a pen test for the standard, like, a sample environment?
So we-- so yes and no. And we actually have a whole set of the environments we do. It's all the ISO certified, all the different things that we do and we regularly run. So we can give you the details of what we do. But our environments run on top of Azure. So a lot of the thing is whatever Azure provides for us.
So while we have a lot of our stuff, pen test or whatever, your specific environment won't be pen tested. We won't pen test yours. But we do have our whole data center, our DevOps, the overall operations goes through all the certifications. It also goes through regular pen testing.
But as far as your On Demand, it would not be pen tested, just because it's a unique environment to you. But we can actually give you-- there's a whole bunch of details we can provide you on that. And I don't know if anybody-- is Will if he has any more information to add to what I've just said there. But we actually have a document we do, which kind of outlines all the things we do for all of our SaaS products, and the certifications, and process we go through, including pen testing that has been part of that. We've done that.
I don't know if anything else-- is he here? Or did I lose Will? Anything else to add to that, Will?
Go to your Account Manager. You can get an executive summary.
There you go. He's talking about the document that I mentioned.
If you go to your Account Manager. You can get an executive summary of a pen test that we run every year.
There you go.
Document? Which document?
A document from the pen test, yes.
There you go.
[INAUDIBLE]
Well, he's the man we'll have to get to. So [INAUDIBLE]. Yeah, go to your Account Manager, and say, hey, talk to Will. But we can help you get that.
[INAUDIBLE]
And again, if you have additional questions, find us tomorrow, or find me around between now and then, but thank you all.
[APPLAUSE]