Oktane18: Convergence of IAM and CIAM -- Leveraging a Shared Identity Infrastructure

Speaker 1: Good afternoon everyone. I am really excited for this afternoon session. This is actually a trend that we are seeing amongst a lot of our prospects and customers. That's around traditional, identity and access management, and the requirements that go along with that. Now, being required also in customer identity and access management. Historically, it's been seen almost as two different sets of requirements for two different sets of audiences. As we see the overlap of audiences, as we see the requirements get more complex as we expect our customers to have really modern, seamless, omnichannel experiences, it's more important than ever to have that shared infrastructure that can serve any set of users. We're going to kick it off first with [Chris Gustafson 00:00:48] who is a principal enterprise architect with Imagine.

Chris Gustafson: That, I don't need anything.

Speaker 1: Oh, that's right.

Chris Gustafson: Thank you. Good afternoon. I also am very excited to be here and appreciative to have the opportunity to share a bit of our story. I call this starting with who. It's primarily a discussion of what we've had to go through and actually not so much getting to a shared identity platform but even getting to the step before that. The step where you can convince people that it is necessary to get to a shared identity platform. For me, that really becomes an identity first discussion, but first a little bit about where I call home. Imagine Company is in the Minneapolis area. We're a merger and acquisition company and we work, as it says there, as brand guardians. In reality, what we're doing is creating a lot of marketing collateral, point-of-purchase, decor, packaging, as well as digital distribution for primarily the retail markets, restaurant markets, as well as film industry, financial industry, and you'll notice Netflix there as well. Sort of the new and emerging areas in that space. Our team is made up of me to begin with. I have the architecture teams and the cyber security teams. I'm the thought leader and I guess the term is evangelist, though I don't like that term, but I guess it fits if you look at the classical definition. We have small teams of developers and we work in an agile fashion that's really necessary for us. Because as a merger and acquisition company and also with our customers having to change with their changing universe, we have to be able to pivot very quickly to their needs, so agile works well for us.

We're a cloud hybrid as well and I think we'll always be cloud hybrid as long as we're still acquiring companies because at all times, we're in a state of change, we're in a state of transition at all times. With that, you can see the brand flags there that we have for our technologies. We have a lot of different technologies that we need to support and make work and integrate. In fact, some of those are ones we've standardized on and some are those that we've actually acquired. The first step in this process really is trying to get alignment. I think the best way to describe some of that for us is what we've done in the context of our business. Most of our customers are retail in nature. As a result, they were really affected by the retail apocalypse, the change of moving into the digital space, the pressures that they were feeling as a brick-and-mortar company. Our customers have been demanding more from their vendors and not just more in terms of our servies, but having us perform more services for them. They don't actually want to see us only constrained to one or two things. They want to get more value out of that relationship, which works well for us too, because we want to get more value out of that relationship as well.

With that deeper integration though, they require much more security from us. Whether it is in the retail space, certainly the financial space, certainly the entertainment and gaming space, there are very heavy demands on intellectual property and securing that property, so we've had to stay in step with security. As a result of that, our IT footprint had to become much more strategic and less operational obviously from the sales side. If we're having a deeper relationship with our customers, that means we're getting involved more deeply in that relationship building, that thought partnership process. From the perspective of the security side of it and the delivery and execution side of it ,we've also had to become more strategic because we're no longer supporting our business, we're actually becoming a very strong part of our outward-facing business.

To do that, we've also built teams that are no longer based on a marketing background or a print background or a creative services. In fact, a lot of our teams are coming from the same industries that we're now serving. They're just really good at the skills that we've hired them to do. Making the argument to our leaders in terms of getting to an identity first standpoint has really been, first of all, tactically about the fact that security can't be a redo. There's no way to actually go back in and plant better security later. It really has to become an attribute of every single feature that we work on. All of our projects now have a security characteristic as a part of them regardless of how big or small. It can't be a feature that you compromise on at the end.

When we start to look at that as an identity focus specifically, a nice way that we found to argue that point back is to say that it really becomes a customer focus very quickly. As soon as we're focusing on identity first, we're actually finding out more about our users, more about our customers, what they need and that just helps us build a better and longer relationship with those customers. Another side effect of that is these design footnotes like culture and localization and things like that, that used to be designed footnotes. Come very much early in the process now because we have to know if we're dealing with people who are multilingual or if they're in geographically diverse areas of the country or the globe. Identity first is probably easiest to look at by saying what it's not. Functionality first for the several decades that I was a developer was really how we built applications. We've designed the screens, we figure out all the things we had to do. We made them fit nicely on the page, but we didn't really think much about the audience.

In reality, that forced our audiences to have to change what they did to match the functionality. One of my things that I always talk to our teams about is the fact that I don't want my customer to have to know how I do business to do business with us. I want to make it much easier and much more approachable for them to actually come to us and want to work with us. To study our audiences first allows us to be much more aware of what those audiences are and what their audience needs are. In the early days, if we had any shared audiences across application, it was really an accident if we knew that. One application might make a change and impact another and that was just anecdotal the fact that those audiences might be shared.

In today's world now, we can know that at the beginning and we might re-tailor our product offering because we know we're hitting two different diverse groups once we've done our analysis properly. We also, in the past, done some things with personas where if you're not familiar where you might give something a human-like name and you've defined six or seven characteristics that you're going to come up with and they're going to use that to build your unit tests or your test cases and things of that nature. Maybe that's how you build your documentation even At the end of the day, that really only serves as an analog for a large group of people and it requires you to make assumptions based on that large group. If you didn't figure your groups out right, now you start to make compromises later in the process elevating smaller groups into bigger groups simply because you didn't account for certain things that, that group required.

Instead, making an identity data-driven application approach is a better approach because now you're actually looking at what the identities are and driving those as data points into your application design. Rather than looking at personas, you're looking at specific things about individuals and then driving your audience definition accordingly. Doing that, your applications become more personal. They have to be because they have to become more responsive. They have to become more dynamic. They have to really understand who the individual users are that are interacting with them on a response by response basis. It's no longer good enough to just log them in and then make assumptions. They actually have to look at every action that users making and decide if that user can make that decision.

To do all of that requires you to do that identity first analysis at the beginning, which I think makes you decide that you want to have that as an asset that's essential to your architectural designs. That really becomes an asset. It also, by the way, incense the user to keep that information current. Because if you know you can keep your information current in one place and have that be populated or at least visible and accurate in all the other places with which you have interaction with my business, they're more likely going to keep it accurate. Some benefits of this approach. Our business logic and security is improved. Our developers aren't making a lot of assumptions in the code and building out really large, complicated schemes to address very minimalistic definitions of people. Instead, we're having very specific understandings of who people are and then coding directly to those specific understandings.

Then as I said before, culture and localization are brought into the design conversations very early. I've been in many conversations where people have said, "Well, it's okay, this is only going to be for North America anyway, so we don't have to think too much about culture and localization." I know in our factory floor in Minneapolis ... I just hit my mic. Our factory floor in Minneapolis, there's 12 languages spoken. Culture and localization matter much more than at the macro scale. Once you start looking specifically at who you're serving, there's actually a real good reason to dig deeper into that.

Some talking points. From a role perspective. If you're an architect, like I am, technically there are some things that you can do when you're discussing this with your leadership or maybe with your colleagues to address why you get some benefit out of an identity first orientation. First of all, if you have employees and you have customers, you have vendors, you have partners, whomever those roles are in your organization or in your business, if they're all using the same application, it's best to actually treat them the same way.

In a lot of cases, we've seen back doors put in the applications. Maybe your employees are going to access via active directory and your customers with a username and password. Well, now, you've got two draw bridges to guard. You've got two different flows to document, two different test paradigms to follow. It's much better to have a minimalistic approach to how you're actually going to bring and invite users into your functionality. That's much easier to protect.

Likewise, once you've done that, now you can build an actual universal identity core, a repository that becomes an asset to your organization. You can look at your employees and you can look at your customers and you can understand where those audiences, again, are shared and what they have in common and serve them accordingly. Later on in the process, if you've done this and you've offloaded that identity and that core authorization process to a something that's central, all of the applications that rely on that now can have a longer life because as you need to enhance them, as you need to add new things to them for regulatory reasons or for new customer features, you can do that without having to redeploy.

Identity data-driven applications have to be much more dynamic. I referenced that earlier, but if you're talking to your application developers, that's really the mindset they have to have their mind on. It's about building something that's dynamic, that's unique to the session of the individual that's logged in at that point in time. I have to focus their time that I'm going to be implementing security on everything I do, because they can't go back and implant it later. It's impossible to go back and edit later with any high degree of success. The last point there is really about the user experience. The user experience really, with an identity first and a more dynamic approach, doesn't have to be dictated by your business. For instance, a dashboard or a portal. You can decide to have those things if you think that makes sense, but in the case of this case study here, we implemented what's called a floating panel or floating portal at Imagine.

Essentially, what that floating portal is, is nothing new. Google has one. Microsoft has one. They'll have the waffle where they can see all their services. Whether you're an employee or you're a customer or you're a vendor of ours, what hides beneath that waffle is going to be unique to you in what services you can do. We're not really restraining our customers to say you have to start on this page, you have to start in this service. In fact, if we've had customers who've grown with us over time and had more and more services added, one customer may learn to start on service A, B and C and another might start with C, B and A.

In those cases, to them start, start is relative to their experience with us. We don't need to mandate that or dictate it, unless of course your business requires that you do so. In these cases, no customer really has their own beginning or has to have their own beginning and their own end. They can all have one that's unique to whatever their needs are.

This is a diagram that basically structures how we've addressed that with a two-tenant model. It's funny. As I've walk through this week's event, I've talked to more people who've ended up in this sort of alignment with a multiple tenant view when you have both customer and employees that you're protecting and supporting.

We have our employees in the purple cloud. Yeah, it came through purple up there. In those cases, we have those customers are coming through and they're connecting either with SSO or username and passwords and being stored in that tenet. Our customer facing applications are protected there.

Our employees are coming from the other side who are synchronized from their various different companies in different configurations. Then we can provide them access to customer facing applications if we wish. Specifically, customers-facing applications for specific customers after that.

What helps us here is the fact that in the old models of doing things, often our users would have an account under each and every application that the customer had. If we had 50 customers, that individual support person for instance had 40 different accounts. When that person left, we had 40 different orphaned accounts that we didn't know how to delete, couldn't find. Perhaps they never got deleted. Perhaps there were a security hole.

Now, when we delete that users active directory account, that user no longer has access to any of his services or any of the customer accounts that he had access before. The idea of shadow accounts goes away. Employees can access their applications the same way as the services that they use. Whether it's their HR system, their ITSM system, their email or it's that customer-facing application that we've provided, they go to one place to do it now. We're treating our employees just like we're treating our customers.

So, finally when our market was strained and our customers were having trouble, they looked to us to actually dig deeper in and help them with more use cases. I think having that common and very detailed identity first mindset gave us the opportunity to look at our customers as individuals and our customers as individual use cases and understand how we can serve those use cases specifically. Understanding them let us know what they really needed for us and where we can fill those gaps and still stay within our business mission.

Once we started to define an identity first mindset with our development teams and with our product managers, we started to create a much more seamless experience. It made much more sense for all of the user interfaces and all the branding to match because we knew who our audience was and once you knew who your audience was, it made sense for you to actually be congruent in how you're communicating with them.

I think the most important thing that pay dividends to me I know when I talked to leadership is we now have an asset at the center of organization in terms of understanding who our users are, who our customers are, how they use our system, what they rely upon and how they structure their own users within a customer to access Imagine. So, what that, thank you and I'll turn it over to Tony.

Speaker 1: Thank you so much Chris. That is a great story and I think it aligns a lot with what Todd McKinnon spoke about this morning around taking identity mainstream but also what Joe Diamond mentioned on stage about how you know there's not this dichotomy between security and usability. So, taking this identity first approach and really understanding your user and putting that at the forefront of thinking about how you're going to develop your applications is really critical in getting both security and usability. So, to give another perspective on this, I wanted to invite another customer speaker up. This is one of our most innovative organizations. So, I wanted to introduce a director of enterprise architecture for a National Marrow Donor program Tony McAllister.

Tony M.: Thank you. Thanks, Jiong. Good afternoon everybody. I'm Tony McAllister, the director of enterprise architecture at Be The Match. We actually have a bit of a dual brand, dual name so Jiong mentioned the National Marrow Donor Program that is technically the organization's name, but we have a public facing brand Be the Match and that's how we refer to ourselves generally when we're out talking to the public. Something that can help folks identify a little bit more about the mission that we have at Be The Match.

So, Be The Match is the United States Registry for bone marrow transplant. Bone marrow transplant is potentially curative therapy for about 70 different diseases. Most commonly its used to treat blood cancers like leukemia and lymphoma. The organization has been around for over 30 years. In that time we facilitated over 80,000 transplants. Last year we did right 6,200 transplants.

So, the key operations of Be The Match to help fulfill our mission are we recruit donors to join the registry here in the United States. We DNA type those donors when they join the registry. So, if you sign up to join the registry, you would get what is called a buccal swab which looks like a big Q-tip. You swab the inside of your mouth, send it back to us, we send it off to a lab and we get the DNA results. Specifically, there's a subset of DNA that we're interested in that tells us the characteristics of the donor's immune system and that's how we match with the patient. We're looking for the most compatible match between patients and donors.

After we've collected that information from the donor then we're obviously managing and maintaining this database of all the donors and then we work with the hospitals that are treating patients in need of a transplant. So, we provide them technology platforms so they can access our applications and search the database of all available donors. In the United States, we have about nine million donors and then we also partner with all the other registries around the world. So, there's a lot of international collaboration that goes on within the bone marrow industry. So, in total we have access to roughly 30 million donors worldwide.

So, when the hospitals that are treating patients interact with us, they enter their patient details and then they can search across all 30 millions of these donors. We return the results back to them. The physician at the hospital makes a decision about what is the right match for their particular patient. They select that donor and then we go through the process of what we call working up that donor. There are a number of different tests that have to be executed, some additional typing that has to be done on that donor and then ultimately resulting in the collection of the bone marrow or stem cells from the donor and the transportation of those cells to the patient. So, that's what we do with Be The Match.

There's a picture here of a donor and two recipients. So, this donor is a gentleman named Ingo who lives in Germany who I mentioned there's a lot of international collaboration. These two girls had a rare blood condition and needed a transplant. So, when they were three years old, they identified Ingo as the best donor for the girls. They actually did two different collections and infusions. One girl when she was three and then the second one when she was four. These two girls are twin sisters. They live in Minnesota and they're now 10 years old and leading a very happy and healthy life. So, it's a great example of the kind of work that we help enable at Be The Match.

One of the challenges that we face in building this registry to meet the needs of patients in the United States is having a diverse registry that will help us support all the patients that are in need. So, as the population is growing more and more diverse, we need to build a registry that reflects the diversity of patients. We don’t necessarily know what that's going to be but we want to help support all patients that are in need of a transplant. Right now we're really facing a challenge in helping meet the needs of minority patients. We don't have the correct diversity that we need in the registry.

So, here's a picture of a patient. Her name is Cameron. She's 11 years old and has sickle cell anemia. She can't find a donor that's a match for her on the registry. So, I'm going to have a slide at the end, a bit of a call to action if you're interested in helping to participate in fulfilling the mission of Be The Match, I'll talk about different ways that you can do that, but I would ask all of you … encourage you to think about joining the registry and then certainly helping to engage in any way that you can to help increase the diversity of our registry as well.

All right, now on to identity and access management. So, with Be The Match, we're facing several challenges and opportunities around identity and access management. I suspect that there some of the same challenges and opportunities that you all face in your organizations on a daily basis. I want to run through the key items that we were facing needing to address in IAM.

So, the first is the growth of our digital platforms for both internal and external use cases. Historically, the organization has been around for 31 years. People were at the front of the organization and IT was providing applications really just to help them conduct the business of the organization. They had all the customer interaction. Increasingly, our applications and APIs are becoming the products and services that we're now exposing directly to our suppliers and customers … their various partners that we work with. So, now we need to ensure that we can provide the right security as we're exposing those apps and APIs.

The second is this user experience expectations. As people of adopted more technology in their day-to-day life, they've got expectations about simplicity and ease of interacting across all the different applications that they use. We strive to ensure that they have a good experience using our applications at work both for our employees and then for all the customers. Facing increasing threats, there are bad actors out there and we've got information that we hold very seriously.

People have voluntarily provided this information about themselves, identifiable information and also some of their healthcare information so we take that very seriously. So, we want to ensure that we're protecting that. Then we're in the healthcare space since we're also subject to a number of different regulatory requirements. HIPAA certainly for healthcare privacy. FDA regulations because the products that we're actually collecting and transporting are being treated as biological products by the FDA. It's a global industry so things like GDPR apply to us as well. So, there's quite a few requirements out there that we need to make sure we can meet.

On the technical side as we're shifting to consuming more cloud solutions so SaaS solutions that our business users are using and our own applications as we're building those applications now on containers and we're building those with micro-services. We need to ensure that we can apply security at a more granular level. Then we want to adopt open standards to make it easy to apply that security across all the different components in our architecture. So, all that leading to an increased need for a unified program and platform to provide consistency, support scale and speed delivery.

So, now let me can map those challenges and opportunities, it's kind of more specific technical use cases that we face. So, the first, identity management. So, I told you that we're recruiting new donors to join our registry and we do that with the digital registration platform. Every year we recruit 600,000 to 700,000 that's kinds of the trend. We're growing that every year. So, right now, we're running about 600,000 to 700,000 new registrants via that platform. So, we need to provide a secure, reliable, seamless experience for those users to be able to go in and set up their identity to complete the digital registration process.

The second is API security. I mentioned we're deploying micro-services throughout our architecture. So, we need a robust API security layer to ensure the right data is provided only to those who have the rights to see it. Multifactor authentication, as a healthcare organization, we essentially are applying MFA across the board. So, anytime anyone is accessing an application that's going to allow them to see healthcare data, they have to MFA into that. So, for most of our employees and partners, that pretty much means every time they're logging in, they're going to MFA. Now that session lasts the whole day so it's not like every interaction requires an MFA, but every day they can expect to do a multifactor.

Enterprise single sign-on. So, we want to provide that seamless experience. As folks who are moving across all the different applications that they use on a daily basis, we've got a number of applications that we have developed ourselves internally over the years. We've got a number of cloud solutions or on print third-party solutions that we've procured and all of our users use on a regular basis. We've done quite a bit of custom application development ourselves just to meet the unique needs of a bone marrow registry. So, we've got that capability built up within our team, but there we're also obviously looking to easily plug-in third-party solutions.

Then finally, information security governance and reporting. So, information security team wants to have holistic visibility into everything that's going on with our identity and access management. So, we need to find a solution that would provide them a great place to manage and administer those rights and then see what's going on across all of our applications.

So, let me dig a little bit in to the three different segments of users. This is how we really approach our analysis around what we need for identity and access management. We were thinking about, "Okay, who are the folks that are going to be using our applications? What are their interactions? What are going to be their needs in terms of IAM?" So, the first is the general public. The most common use case here as I mentioned is when we've got people joining the registry, but we also have folks that are looking to make a financial contribution to the organization. We actually have a foundation as charitable arm of the organization where people can donate and then we use those funds to help patients or donors in that whole transplant process.

We have volunteers that help donate their time and they need interact with us and do scheduling activities etc. So, we needed an identity directory. We want a 360 degree view of all the interactions across our applications. We are looking for single sign-on for those users.

The second segment is network partners. So, as you heard me describe, what we do in bone marrow transplant, you probably start to understood that there's a lot of different participants involved in that complete process. So, we're at the hub coordinating these activities but we're dealing with the number of third-party partners, different suppliers whether there be collecting the cells or whether they're doing typing or testing or whether it's a physician in your particular market and you're going to get a physical exam from them.

Tony M.: In your particular market and you're going to get a physical exam from them. So, we've got a bunch of different people that are need to have an identity and interact with our applications. And then there's all those global registries that I mentioned that we're exchanging data with and we want to make sure were doing that in a secure way.

So, these users need single sign on, multi-factor authentication, and API access management. And finally our employees contingent staff, and third party partners, and this also includes information security governments team. Here we're looking for single sign on both On-Prem and for cloud apps, multi-factor authentication, and then we'll bust reporting in administration.

So, it may not surprise you since I'm speaking here today that we selected Okta as our solution for identity and access management. So, this lays out essentially those used cases that we had by the different user segments, and then the products that we selected from Okta's portfolio, and how they map and help provide us solutions. So, the B to C scenario, the general public, we use universal directory and single sign on. Similar to what Chris was describing, we actually have two tenants. We have one tenant for our B to C scenario, and then for our B to B and B to E scenarios, we have a second tenant. So, the B to C here that universal directory is in the first tenant. For our B to B scenario, we need a single sign on, multi-factor authentication, API access management, and the ability for us to provide them then a custom user experience. And those are the same solutions that we employ for B to E, and again B to B and B to E on a second tenant.

Quickly, just want to reveal what that experience then looks like for these users. There's not much to see here, but to some extent that's kind of the point. So, first our digital registration platform where we're getting news is to join our registry. That's a mobile friendly application. It's responsive. It's going to work on desktop browsers, on tablets, and on phones, but we've been able to integrate the security APIs from Okta into that custom experience that we provide on the mobile platform. And then across our application portfolio, of which we have many custom built applications, this just reflects ... These are actually two different applications, but what this reflects is the consistency and the ease of authentication that we've been able to deliver. So, here we're using the act of widget. We've plugged that into our applications. Our general technology architecture is we're building single page applications with angular and then we're building restful microservices on the back end. So, we've plugged in the widget with open ID connect, and then we're using the 0Auth2 for our services on the back end.

So, the technology architecture of how all these pieces fit together. I'm not representing the two separate tenants here, but that Okta image on the screen you can think of as they're two separate tenants there, but what Okta has enabled us to do is to tie again all these different solutions into one platform. We can centralize the administration and the reporting out of that platform.

So, starting on the end we've got the different users using applications that we're providing to them over the internet generally, and that could be mobile or on a desktop. It could be signing into applications that are running in our data center or they could be signing into SaaS Solutions that are running out the cloud. We use the Salesforce service now WebEx. There are more as well, but those are some of the key applications that we've integrated with Okta into our environments. And then we've got single sign on and MFA that we're rapping around all the applications that we run internally. Many of those applications are custom built applications, so again we've built the Okta sign in and authentication and authorization into our apps. And then finally, API access management on the back end securing our microservices. Active directories or IDPs, so we use the Okta agent to connect to active directory right, then that loads those identities into the Okta platform.

We've deployed all this and have been running this architecture for about a year, year and a half now. It's been working well for us. It really has helped simplify that process and provide a very consistent experience for our customers, employees, all the different users that I've laid out. And it's also helped us to adopt the standards that we want to in terms of open ID connect, 0Auth2, and our custom application development.

In closing, the benefits that we've obtained from using Okta, IAM, at Be The Match. Summarizing really what I've already talked about. First, we've met the deeds of multiple user groups with one security platform. We've been able to custom build and adopt open standards. We've been able to deploy security onto third party applications that we're deploying in our own data center. And then also use that same Okta platform for cloud SaaS Solutions.

We've been able to build a modern, utilize modern IT standards in our application development. Microservices, using open ID connect, and 0Auth2. There's the possibility we don't have thousands, but there's the possibility through the Okta integration network to connect thousands of existing cloud and on print applications. And then finally for our information security team it provides essential solution for their identity and access management administration and reporting.

So, in closing a call to action for Be The Match. If you're interested in learning more about Be The Match and what we do as an organization, you can go to www.bethematch.org and there are multiple ways that you can engage with Be The Match. You can donate or you can join a registry if you're not already on the registry. You can make financial contributions to the organization so that we can help patients and donors in going through that process. You can volunteer your time, and these are all things that you can do in your local community because we do work across all of the United States.

Thank you very much.

Speaker 1: Okay. Great. We'll have time here for maybe two or three questions. Tammy is in the audience with the microphone if anyone has one.

Speaker 2: Hi, thanks for presenting today. One of the questions I had was related to the fact that both of you guys have decided to split out your B to B versus B to C tenants in Okta, and I'm curious to hear what it would take for you to combine them and why you went and decided to go that route of splitting up the tenants?

Tony M.: Want to go first?

Chris Gustafson: Sure. Combined them probably wouldn't be difficult. I mean, it's abstracted away already. We're just choosing to have two. I think we made it primarily for structural reasons. It made sense from a separation of duty standpoint to have different administration for our customer facing tenant than for our employee facing services. I also didn't like the idea of having customers and employees mingled in the same directory as a source of truth. But as far as combining the two, I don't think it would be too difficult, but it would be definitely a departure of planning and design. I think it was much more of a business decision to be honest than even a structural one or a technical one.

Tony M.: So, for us similar. We did not want to co-mingle our customers with our employees and network partners. For us also, it was a matter of scale. We're adding hundreds of thousands of identities to our B to C platform every year, so that's quickly going to grow into the millions. We did not want to store all of those internally, and finally we wanted to have the security comfort that we get from having Okta which is providing world class security because this is a key public facing application for us. So, we wanted them to be on the front lines of ensuring that all of our customer information was protected.

Speaker 1: And in both of your scenarios, are you leveraging on to org between the two tenants?

Tony M.: Not in us. No.

Speaker 1: Okay.

Chris Gustafson: We are.

Speaker 1: Okay. Got it. So, ort org is a way of essentially syncing the two tenants so that identities are always synced between the two of them.

Speaker 3: I think I can understand the user life cycle of the B to C. I can understand the user life cycle of the employees that you're managing through active directory. The one I'm struggling is the partners and the vendors. Specifically, how do you know when to de provision those users from accessing your internal applications?

Tony M.: I can take first-

Chris Gustafson: Please do.

Tony M.: So, our general provisioning life cycle and interactions of we're a service now, customer as well as an Okta user. So, the provisioning for us starts with service now requests, and then that integration into our IDP which is active directory and that integrates obviously into the Okta platform. And then the same thing for de provisioning those users that would be a request into active directory. Now, maybe the part of what you're also saying there is well how am I getting notice of when that individual is leaving that organization? That's a challenge. What we do with many of our partners is we have someone at that site who is a lightweight administrator. They don't have much in terms of administrative rights, but they're essentially responsibility at their site for their users. So, we hold them accountability for ensuring that they're de provisioning users and then we do have a regular entitlement process where we're holding our product donors internally accountability for going out and validating with those external users that the right people have access to the application. But, it's still a bit of a challenge.

Chris Gustafson: That answer stands. I'd of given almost the same answer. We're a service now client as well which all the provisioning goes through service desk tickets like that as well, and almost spot on. I would've said it the same way.

Speaker 1: And just to add on to that, one of the things that we see a lot of customers doing especially for partners is leveraging inbound federations. So, if your partner already has an existing IDP or perhaps that they have an existing directory, using that as essentially your source of truth for the partners so that when they're de provisioned as an employee there that flows through to your system as well. Some newer functionality that we have available is around knowing how long a user has been inactive for. So, you can track, hey, if this user has been inactive for let's say 60 days, perhaps we want to suspend that user as an example can run a report and then make decisions there.

Great. Maybe time for one last question. Okay.

Alright then. With that we'll close the session here. Got maybe a couple minutes here if you want to come up and ask questions directly. We also have a customer identity hub in the expo hall, if you'd like to ask some more questions. Great. Thank you everyone.

Tony M.: Thank you.