Cardinal Health: 60k Associates, 111 Apps, & 0 App Changes in Less Than 5 Months

Bill Dubois: Thanks. I'm Bill Dubois. We're here to talk to you about our journey with Okta. So, essentially, this is just part of it, so 60k associates, 111 apps migrated and zero app changes in less than five months. So, this is really our client journey in terms of moving all of our internal phasing apps over to Okta. So, here's the disclaimer once again. Hopefully, you've read it by now. Yeah, so it's me and Dave. We'll do quick introductions. There's a little shake 'n bake reference, so I'll be the shaking and the prep work, and Dave did all the cooking, which is good for all of us. 

A little about me. I am the manager of IAM build and strategy at Cardinal Health. I've been with Cardinal for about 10 years. Previously worked at Alliance and Liberty. I have three kids, an awesome wife, a molecular biology degree, so it goes to show that it has nothing to do with what you do. I'm actually a huge Buckeye fan, and somehow, I'm not sure how, we'll figure that out, there are some Buckeye pictures on here and they're gone. They were there Sunday, but they're gone now, so Michigan needs a win. So, we'll give it to Dave. You can do a quick intro.

Dave Fend: Yep. Thanks, Bill. Hello, everyone. My name is Dave Fend and I'm a senior services architect with Okta. I've been with Okta for just over two years now, and I do live in the Detroit, Michigan area, where I was born and raised. I am a graduate of the University of Michigan, and somehow or another, I keep getting assigned to these awesome projects in Buckeye territory, so with that, I'll pass it back to Bill. 

Bill Dubois: Great. So, a little bit about Cardinal Health, we are not an insurance company. We actually operate across the healthcare continuum, so we have 60,000 employees worldwide, number 15 on the Fortune 500, about 120 billion in revenue. We actually service in the acute setting, so think of healthcare systems, large retailers, right, retail independents. So, your small pharmacy down the street, et cetera, payers, manufacturers, and suppliers. We do a lot of logistics, so we have a lot of services that we offer, both to manufacturers and suppliers. Then, obviously, patients, and patient's all about connecting the patient with clinicians and giving them the information they need to make appropriate decisions around their healthcare.

A little about our business, so we actually operate in four domains. We have logistics and we have a huge history within logistics. We also do product, and that would be manufacturing, say, medical products. So, if you go to a surgery center, you might see Cardinal Health branded products within there, et cetera. We also do business services, and that might be third party logistic services, it might be inventory management, et cetera, and numerous services. Then, obviously, the patient services that we talked about briefly earlier. Right now, just within the healthcare industry, there's a lot of challenges that we're seeing, which is really driving a lot of momentum in our IAM space. So, global swell demands. We've grown globally, immensely, over the last two years. Huge global acquisitions. 

We're operating in 70 countries now from a manufacturing distribution sales perspective. The consumerization of healthcare, and I think this is probably impacting all of you. Customers want to make informed decisions around what they're doing with their healthcare. They want to rate the services that they're getting. It's no more about business, the business model that we've had historically. So, we need to make all of our services much more consumer-friendly. That's it, so that's a little about Cardinal in terms of what that means for IAM. So, with that, we've seen a lot of new challenges over the last few years in the IAM space. We've actually had an IAM program for probably 10 years at Cardinal, and it wasn't a huge program. It was built organically over time on an as-needed basis. It was primarily CA products, so CIBM from 10 years ago, SiteMinder, et cetera. 

Very customized, so we have immense customizations within our IAM platform historically, and what we are realizing as we started to grow, we had rapid expansion, we more than doubled. I think our IAM integration was two years ago. That trend seems to be continuing right now, is that we weren't able to keep up effectively. We're spending more time supporting our infrastructure than we are thinking about the needs of the business and getting out in front of those. The other thing is just ... We talked about customer usability and client usability. I know Todd talked about that as well. The expectations of our customers, both domestically and globally, are a lot higher right now than they've been historically, and that's driving a lot of call volume for us. So, when we think about ROI, that was one of the big drivers that we had for the IAM program, was to really improve that usability from a login, self-service perspective, et cetera. 

Then, agility. When you think about Okta and our legacy, customized platform, all of these projects ... If we do this, it'll break these three apps, and if we do this, it'll break these three apps, and we're spending an immense amount of time and money doing testing, trying to optimize this legacy platform. Finally, cost. All of that really ties into what I've said before. All these integrations were costing too much money, so we needed to find a way to create patterns and really optimize our delivery. We knew the business was going to need new things that we don't have capabilities. Before, my engineers would come to me and say, "We can't do that," so three years ago, prior to Okta, that was a common conversation with an engineer, like that won't work. Yeah, SiteMinder doesn't do that, or this doesn't do that. We're not hearing that anymore. 

So, really, cloud advantage is driving some of this as well, but that's the overall thing. Three years ago, we really moved into the cloud to kind of get in front of that customer space, and as we did that, we really saw that there's a lot of synergies in the client space that we could leverage to optimize our delivery of IAM services. So, what would success look like? This is just the high level stuff. There's a lot more, and Dave's going to kind of go into that, but effectively, we had to improve our client user experience. As we moved into that global market, we have a lot of ... We have 60,000 employees now. We probably had 35,000 three years ago. Many of them are global. Our IAM services just weren't easily consumed by those. 

We have over 150 applications that we leverage for SSO today, and we are getting a ton of call volume into our service center. Probably, most of you have experienced the same thing in the past. Additionally, no customizations. So, everything at Cardinal from an IAM perspective was very customized, historically. This was really more of a top-down edict, really, from our CIO that we're not to customize anything anymore. Our platforms, historically, have been highly customized, and given that we need to be agile and integrate quickly with so many applications, we really have to have standard patterns that we can roll out really quickly, test, and treat them more like products with services, versus your platform. 

Then, speed, speed, and more speed. We're just ramping up. We've had major acquisitions. There's more coming. I think we're doing at least three integrations a week right now to prod. So, as these acquisitions start to come in and exit their TSAs, we're going to see much more activity in terms of our IAM integrations. How did we get started with Okta? We actually started in the customer side, so direct-to-patient. It was our first real direct-to-patient app that we were going to consume, that we were going to protect with our IAM platform, and we realized that we could not do that with our on-prem solutions. They wouldn't scale appropriately, et cetera, and so that's where we first looked at Okta, and we really loved the tool, okay.

So, we started using that, got a lot of feedback, did a number of POCs of the team. Really did a discovery of all of our internal IAM services and decided that we really wanted to pursue moving this over quickly so we could get some of the value and ROI of improving that customer user experience and driving speed of those IAM integrations as fast as possible. So, we did a huge discovery phase, we built a business case. Okta was very much a part of that. We did most of the legwork, they helped tune it up a little bit, and then we kicked them out the door. Then, we obviously, put together a plan, and then after that, we arrived at this approach. 

So, essentially, wanted to do foundational activities, and I think of that as plumbing. Build all the plumbing. We wanted to do that as fast as possible, so all the new integrations that we have coming in, we could put into Okta right up front. We wouldn't have to wait for this huge migration project to end. Next, we would do coexistence, and this is really around driving improved usability and security for our clients. This is where we move authentication into Okta, okay, and login and self-service capabilities. We want to do that really rapidly, and we want to do it all at once for 60,000 users and for all of our apps. 

So, what that means is there's no OCM. The OCM is very limited in terms of hey, on this day, everyone's login page is going to change. All of your self-service is going to change globally for all of the apps that you access, so as opposed to doing it ... Here's two apps, and we communicate to 4,000 people and two more, and another 8,000. That's the coexistence. Then, finally, the app migration. We're moving into this right now. Again, it's a pattern-based approach. No customizations. So, that's the approach, and then just in general, our partnership with Okta, so Dave's obviously up here with me. We've had a great partnership, so from the very beginning, Okta's come in and told us what they can do, what they absolutely cannot do or should not do. 

They've connected us with great partners like you, in the audience, to understand what's worked for you and what hasn't worked for you in the field. They really helped with the business case. Then, we actually selected them for professional services, so because of the timeline that we were going after this and just the overall scope of the change, we actually did partner with professional services, and it was a great experience. So, with that, I'll turn it over to Dave, and he can walk you through the details. 

Dave Fend: Okay, thanks, Bill. So, yeah, we go to start this project and typically, before I kick off, we're going to get together, sit down with Bill, and find out what his requirements are to try to understand a little bit better. Bill looks at me and he's like, "Hey, Dave. We've got this legacy SiteMinder environment that we have that has a lot of applications on it, and we need to get off of that." That SiteMinder environment is built out on top of our LDAP infrastructure and it's using that for all of our authentication, and we want to get rid of that as well and we want to have Okta use that trajectory instead. 

Paramount to that is we need to deploy this new login experience that Bill was just talking about. It's really important when we bring out this login experience that we introduce some better password recovery experiences. That's one of their bigger problems, is how they handle password recovery and unlock account situations. It's like, oh, by the way, we have over 100 applications and we can't make any changes to any of those apps. I don't own those business teams, I can't force them to make changes on my timeline. No customizations, he's already mentioned that a little bit earlier, but did that with SiteMinder. We're not going to do that again, so we need to make sure, as we're designing this out, that we're not customizing Okta to any nth degree here. 

We want to make this seamless to our end users. We don't want to even have to tell them that it's happening. They shouldn't even know about it, it should just be happening behind the scenes for them. Then, lastly, you know, we're international. We have 12 languages that we support today. We need to have that in place for day one. So, sounds pretty easy, right? How do you go about something like that? Well, you know, I'm part of the customer first team at Okta, and we have our playbook that's proven for success for situations just like this, and looking at our playbook, the first thing that comes up is learn. Learn starts with education. Educating Cardinal on Okta and everything about how to utilize Okta for success, and so when we were looking at it, we looked at the Okta admin training, Okta help desk training, and Okta developer training that we thought would be paramount to success so that when they go live, they're ready and able to support the new solution that's in place. 

Then, the next stage of our playbook is to move into deploy, and that's what I'm going to focus the majority of this discussion here in the presentation. Deploy starts really, typically, with a design workshop, right, an architecture workshop. Since I'm an architect, that's typically where I get engaged to come in, sit down, talk with you to try and understand your current state architecture, understand your business needs, your objectives, your visions, where you're trying to get, and we're going to work on kind of, hopefully, a phase rollout plan where we can kind of get some quick wins as soon as possible, but ultimately, meet your end goals and lay out for you how we're going to do that. 

Then, Okta PS can work with you. As Bill mentioned, we partnered with them to work with them all stages of the project, all the way up to go live so that they're ready for that. But we can be as hands-on or hands-off as you desire us to be. Next is adopt. Adopt is really kind of where Cardinal is today, and it's really a critical step in the process, but it's often overlooked early on. You've spent all this time and money investing in this solution, and you're not going to see the ROI if your users aren't using it. In Cardinal's case, if their users aren't enrolling in different, faster recovery factors so that they can utilize these new factors that we have in place. Then, finally, the last step of our project is going to be grow. You've got the solution out there, we want to work with Cardinal to expand their architecture and specifically get them to now begin to migrate all their applications off of SiteMinder. Let's take a little bit deeper dive into that deploy stage that we're talking about and how we went about it specifically with Cardinal. The first step was to take a look at their inventory, the 100-plus applications that they have in place today. As we're looking at these different applications we want to look for commonalities and different ways that ... All the different ways that the applications are integrated with SiteMinder, and that users are using them, and different flows that they're supporting today.

With that, we want to be able to identify patterns, right? Take those patterns and identify them and see if we can come up with a current state pattern of how it's working today and then also identify a coexist pattern, where Okta and SiteMinder can play nicely together, and live in tandem, and then ultimately look for a future state pattern that involves no more SiteMinder to be there. Once we have those patterns designed out, the next stage was to build out in the lab, take one to two applications per pattern and get them hooked up in a lab environment using real applications and prove out each pattern to see that it works and look for any issues we may have encountered. 

After that, we need to work on the foundation. The foundation in this case is working on items such as our Okta sign on widget, Okta redirectors to make all the flows and magic happen, as well as some changes that are going to be necessary to SiteMinder. With the SiteMinder changes, in this case, we're looking at new OS schemes that are going to have SiteMinder redirect to Okta, as well as the federation relationships that are necessary between Okta and SiteMinder specifically. Then last, we need to deploy all this. Cardinal wanted to have a quick turnover. Basically, one weekend we all get together, get in a room, and cut over all 100-plus applications at one time.

In order to do that, we built out a mass conversion utility that was able to take that inventory of applications that we had for them, script them through and create all those applications in Okta with all the configurations necessary in just a matter of minutes and have them live almost immediately. Let's take a quick look at what their original state architecture was when first showed up out there. Obviously, one of the key foundational pieces that they have in place is their SiteMinder infrastructure. On top of that, you'll notice that they have an active directory and an LDAP. Active directory was being used as the authoritative source of truth for all their Microsoft applications and LDAP was being used as their source of truth for all their SiteMinder web-based applications that they're having. Then they have the synchronization that's going on between the two directory services.

Any time you're dealing with synchronization between two directory services, for anyone that's ever done that, you know it's a very complicated and troublesome endeavor to try and support and keep going in the meantime. A lot of the challenge that they had with this architecture was around that login experience that we talked about, as well as the password recovery. From a password recovery and unlock account experience, what we discovered was that the only thing that Cardinal was able to support at that time with SiteMinder was challenge questions and answers and actually multiple challenge question and answers, which we found actually only results in multiple answers that people are going to forget, which leads to frustration and challenges with being able to do that.

As well as, hey, you login on your Microsoft account and you're having an issue there so you change your password. Then you suddenly run over to an LDAP-based application and that new password isn't working because it hasn't synced yet, or maybe the sync failed altogether, which leads to more user frustration, and more help desk calls, and it's all costly and frustrating for everybody involved. We've talked about this pattern-based approach a little bit and I thought it might be helpful to kind of take a step back and say, "Why did we take a pattern-based approach?" Well, to start with, what is a pattern? A pattern is really nothing more than a repeatable solution to a commonly occurring problem. In our particular case here, we had 111, 120-type applications that we're dealing with.

What we were able to do when we look for these patterns is pair them down to about seven distinct patterns that we discovered them to find out. Now what we're doing is we're designing and modeling against just seven patterns, instead of designing and modeling for 111 individual applications. Then we're testing against the patterns, instead of each individual application, and able to prove that out in a lot less time and a lot less cycles so that hopefully it's easy to see the advantages of a pattern-based approach. Let's take a moment and take a look at just one of these patterns that we have. For this one, we chose a particularly simple one, right? It's a traditional SaaS-based application that supports SAML. We're going to talk about it from a SP initiative flow standpoint.

In this case, what you have is you have your employee who's going to try and access the application that's in the cloud. That cloud is going to be configured to do a SAML integration with your on-premise SiteMinder integration. It's going to redirect back to a protected page by SiteMinder. Siteminder's going to ship that user up to the Cardinal Enterprise login page here, in this case. It's going to get that user logged in, send them over to the SiteMinder Federation Services, and then get them back to that cloud application. That's where we started from. That's kind of the current state. Now, the next step is to come up with this coexist model. How do we get the user to be able to use Okta for just the authentication necessary, but cooperate with SiteMinder in the process?

It's important to point out the reason that we went with the coexist model here, which is a little bit more complicated from a flow standpoint, was the desire to not have to change any of these applications immediately, right? No application changes required here. To do that, we have to leverage the existing SiteMinder integration that's already in place. In this case, all we're going to do is introduce a new sign on page that's powered by the Okta sign on widget and handles the password recovery for you, and leverage Okta authentication. When the user initially tries to access the cloud-based application, they're going to get redirected back to SiteMinder just like they were, but SiteMinder’s going to be configured to redirect to Okta for authentication, instead of the old authentication scheme. 

You'll have that Okta powered authentication and then we'll introduce that new federation relationship between Okta and SiteMinder. Okta will send the user back down to SiteMinder. SiteMinder’s going to issue that session, and then SiteMinder will generate the same sample that it would've before back to that cloud app, and that gets that user in. The next step is to look at future state, right? We want to get rid of SiteMinder ultimately. That is our end goal here. We have to pattern out where we're going to try and move to. Obviously, this pattern is very straightforward. It's far more simplistic than the ... Not only the coexist, but even the original state architecture that we had here. This is a pattern that for anybody that's used Okta to get to any of the cloud-based apps out there, you should be extremely familiar with, because it's what you're doing today.

It's nothing more than changing your cloud-based application to have that federation relationship between the cloud application and Okta, right? The user attempts to access the cloud app, the cloud apps configured to use Okta. It redirects the user to Okta, which sends it to your login page. User gets logged in and then Okta generates a SAML that is sent back to that cloud application and everybody's happy. Once we get this in place we're able to look at each of these patterns. Now that we're in this coexist model with Cardinal, what they're able to do is they're able to work with their application teams and each of their application team's schedules and coordinate with them based on when their availability to make this last change to the future state. Once we get all these applications switched over to the future state model, they'll be able to sundown their SiteMinder environment altogether.

I did mention that there were seven patterns, so these are the six additional patterns that we defined out here. I'm not going to go into detail on each of them. I don't have time for that. I think everyone's probably hungry and getting ready for lunch and I don't want everybody falling asleep on me as we go into that level of detail. But I did want to point out before I jump into the flow diagram that while we have seven coexist patterns to find, we're actually looking at three to four future state patterns that we're going to actually support going forward. Those seven coexist patterns are getting mapped into three to four future state patterns and they're going to be supported by Cardinal going forward, which is going to further reduce the complexity of the integrations that they have in their environment, saving them time, and cost, and energy as well.

Also, while they're in this coexist model all new applications are able to go with the future state patterns immediately and not any need to wait for SiteMinder to slow them down. I thought it might be helpful to go into a deep dive on one of the patterns and how this exact coexist magic is working, so I'm going to walk you through it in detail. With this case, what we've chosen as a legacy application that is protected by SiteMinder web agent, so it's an on-premise application and we are going to talk about it from a SP initiative flow again as well. In that case what it means is that the employee attempts to access that application that's on premise. Since it's a web agent protected application, the web agent's going to intercept that request and look at it and see that that user doesn't have session, call back to the policy server to try and find out where the OS scheme is for this. 

It's going to talk with the LDAP that's on premise and ultimately respond back to the agent saying, "Hey, this user actually logs in at the Okta OS scheme," which we've defined. It's going to end up redirecting that user to R1. R1 is actually an Okta redirector that we built out with the Cardinal team that handled some of this magic for us. It does two key things for us here, right? The first thing it's going to do is check the header, okay? It's going to look at the header, because SiteMinder’s going to put in the header an SM target. That SM target is actually telling us where the user was trying to go, the original application that requested in the first step. We'll grab that SM target, and we're going to put it into a cookie, and we're going to save it off so when we come back later we can remember that. That's always an important step, how to remember where that user originally is trying to go as we kind of move through these things here.

The other thing that the R1 redirector is going to do is it's going to try and take and do a mapping. It works through a mapping of all the different applications that Cardinal has and it's going to figure out based on the SM target which application does that map to in Okta, because we want to redirect them to that application that's specific and so that's what it's going to do once it figures out from the mapping file, "Okay, it's this application here. Let me ship it up to Okta to redirect to that application." Okta's going to get that request and it's going to look at it and say, "Okay, he's trying to go to this application. He's not signed into Okta yet, so he doesn't have session. 

What we need to do now is figure out where to send him in." In their case, what we have is we have a custom login page to find, so we send them back to the Cardinal Enterprise login page that's on premise. It's using the Okta sign on widget. The Okta sign on widget's going to actually end up back at the user's browser, wherever they happen to be running it from, and so they'll see the login page. That user's going to submit their ID and password into the login page, which will then send it back to Okta through a traditional authentication request. Of course, as you know, if you have your active [D-agents 00:26:05] installed, then they're going to be ready, and listening, and pulling Okta for requests, so it's going to pick that request up for authentication. It's going to check with AD, "Is this ID and password valid?" Then it's going to respond back to Okta and that authentication request is going to finally respond back to the login page saying, "Hey, yep, all good." 

Now, we might have some multi-factor here, in which case it's going to switch over to do some multi-factor authentication. We're going to kind of skip that for this particular flow and the sign on widget, after a successful authentication, is going to redirect the user back to that original application target in Okta, which is going to be defined to have a federation relationship with SiteMinder. It's going to ship them back to the SiteMinder Federation Services, posting a SAML document in the browser. The SiteMinder Federation Services is going to validate that SAML assertion. It's going to look at it, make sure everything looks good. Then within SiteMinder, it has a relay state defined. 

That relay state is going to be R2, which is our second redirector. That second redirector is really simplistic. All it's going to do is look for that cookie, if you remember back, that R1 created, and say, "Hey, can I find this cookie?" Grab that cookie. What was that application that user was trying to get to? Once it grabs that information out of the cookie, it's going to redirect that user back to that original application they wanted to get access to, which then displays for the user in their browser for them. It's actually a very simple 21 step process. I kid, but what's nice about it is it is a lengthy process when you go into the details of it. It's very interesting to look at to understand how it all works. But from a user's experience, all they see is a login page and then they get to the application. Everything else is happening magically behind the scenes. It's very transparent to them and it actually functions very quickly, so there's no frustrating experience for them at all. So let's take a quick second to look at the co-existence architecture as deployed at [Cardinal 00:28:06] today. And what you'll see, obviously, is that we have the Okta sign-in widget deployed up here, and it's handling all the authentication now for Cardinal, and all the password recovering, unlock account functionality. You'll also note that we deployed the active Okta AD agent, as I just mentioned, so we can do delegate authentication against active directory. We have the password sync agent installed as well. The password sync agent's actually listening for any password changes that might happen directly against AD. And we can ship those back up to Okta and have them send to [L-DAP 00:28:43] through our L-DAP agent, because for ... until Cardinal is ready to completely sundown L-DAP, which will be coming, we need to continue to synchronize the passwords between AD and L-DAP. So this is kind of a temporary stop-gap solution that we put into place to handle that. 

And of course you'll notice that site minder is still there. It's still present. It's still functioning today. That was kind of a key thing that we needed to do, so we can continue to leverage site minder, all the existing that it has in place, so that no application is disrupted. No disruption to end users trying to access the existing apps. 

So we talked a bit about a better login experience, right? And that was kind of really laid out as a key part of this project. The login experience, the password recovery experience, how can we make that better? How can we bring additional factors for password recovery?

And so we spent a lot of time in the original part of the project trying to talk about what are the requirements for the login experience? And you look up and you see this login screen, and you're like, "Eh, it's pretty simple, right? There's not much to it."

But it's not until you actually start talking to the requirements of what everybody wants there, that you start to see the complexities and the subtle things that are kind of hidden behind the scenes. Things like, "Hey, we want the application that the user's trying to log into to be displayed dynamically every time that they're logging in."

We got to make sure that we're always displaying the Cardinal logo and the Cardinal red every time we render this. 

We always want to display the important disclaimer verbiage to every user, so they understand the terms of usage. 

And we need to make sure that we're supporting Cardinal's password policy, and that's being enforced. 

Of course, we got to bring in that new password recover and unlock capabilities here, and so that needs to include SMS, voice call, as well as secondary email to be able to do password recovery and unlock accounts. 

And oh by the say did I mention it needs to be available in 12 languages, as well as have help links? And help links to help users out and have the help pages themselves be displayed in all 12 languages as well.

We're going to have to have dynamic copyright statements in there. So as it changes to 2019, that that statement's going to change as well. 

And we have to have quick links to the legal terms and conditions. 

Finally, a bitter mobile experience, right? Bill mentioned that mobile was important to Cardinal going forward as it's a key part of what they're looking at, to be able to have that. And so we want to make sure as we're designing this login page, that it's responsive in nature and it's going to display well on a tablet, on a mobile device, your phone, whatever it happens to be. 

Lastly, we'll take a quick look at final state architecture. And this is where we're trying to get to. And we're beginning to work on migrating those applications over to get there. As you can see when you look at this, it's greatly simplified, right? Not only is it much more simple than the co-exist architecture, but its' obviously a lot ... even more simpler than the original architecture that when we first arrived there. And one of the key things that's missing is that site minder is no longer there. 

With site minder no longer there, there's a huge removal of all this on premise infrastructure that Bill and his team were having to support, right? So that reduces the time and complexity of things that Bill and his team need to support, and it means that now that they're integrated with Okta, they can take advantage of new features as soon as Okta announces them. So as Todd's up on the big stage saying that there's a new feature coming today, Bill can go back, and he can just enable it in his org, and he can turn it on, and it's going to be there. He doesn't have to go through a costly expensive upgrade that's probably error-prone cycle trying to get site minder up to date. 

And this is huge for him. He can now focus on pushing the business forward and rapidly integrating all these new applications as he mentioned, that are coming to him today. 

The other things that you'll see in the future state architecture is now you have Okta's sign-on widget powering all the authentication, using AD as the authoritative source, and also using Okta for all SSO in place today. L-DAP is now removed completely from the picture.

And the last thing that we did, was we introduced this reverse proxy server here. This reverse proxy is kind of a key little piece of technology that gets added in, and that's there for your legacy on premise applications that can't support SAML, that were probably reliant on a web agent or a web proxy. And how do you secure them nicely with Okta and continue to have your users get there without having to make massive and costly application changes. 

So if we take a step back and review where we started from here in the requirements that Bill laid out for us, let's see if we met them, right? We needed to get off site minder. It's completely gone. We needed to get rid of L-DAP. It's completely gone. We needed a better login experience, you know, a far better one with a new sign-on which is in place today. And the password recovery service and unlock account now supports SMS, voice, and secondary email. Much better, much easier, a lot less friction, a lot less help desk calls to be able to do that now.

Hundred applications that were converted over into this co-exist state. Zero application changes were made. So we hit that goal. We didn't do any customizations to Okta, specifically. We built around the Okta pieces, and we used standard-based integrations and protocols to do everything we did. It was seamless to the end user. A very clean experience. And it was available for 12 languages one day one. 

And with that, I'm going to hand it over to Bill for some final thoughts. 

Bill Dubois: Yay. That was easy. 

So. Yeah, so just bragging rights slide. So it says 111 apps. So as we were building this out, we migrated 111 over in one weekend. What's no listed here is we actually had 25 apps that we had rolled out while this was going on, and we moved them all to the new login functionality the same weekend. So we actually did like 135 apps in one weekend. It was like a four hour deployment. In a couple hours we're smart testing, so it was a great experience. 

60,000 users moved over all at once. Monday morning they came in. 40,000 users leveraged it in the first week. So obviously we had hyper care. This impacted our entire business. So we had a hyper care setup with the service center for that first week. 

Less than 700 calls, which is crazy. So we usually get 300. So that was pretty amazing. Less than 700 calls, 95% FCR. So the one thing I would say, and I think I reference it later, is just make sure you're partnering with your service center or help desk, whoever that is. They are a huge asset for our team. 

Zero app changes. So we didn't make a single app change throughout this, and no major incidents. So no SRTs, no outage calls, nothing. We've been on this for about a month. It's been really amazing.

And then the lessons learned, so kind of what would we do differently, right? So browser compatibility issues and the whole trusted sites, right? It's a pain. Just pay particular attention to it. We had a lot of issues with it, especially with the e-signature stuff, to be quite honest with you. But that trusted sites is a challenge when you're moving to HTPS versus maybe some of your legacy apps were not historically. Some of their content may not have been, historically. So things to watch out for. 

Language ... If you have language requirements, just plan in advance for that. As you're going through the iterations with branding and we're making small tweaks, all of those are translations that you've got to do. 

And believe it or not, google translate probably isn't what you want to use. So you think it might be good, but it's not, actually. 

Application and test account availability and stage, so we went in knowing this was going to be a problem, which is why we did co-existence, to be quite honest with you. But we found 11 apps that just no longer had their ... they no longer had a non-prod. So as you start to work more and more with SaaS applications, you'll probably find that, hey they go live. And the business is like, "We don't need that tenant anymore."

And they turn it off and it's gone, and there's no tenant. So luckily, they all worked, we didn't have to do anything. They fit into a pattern. We tested the pattern and it worked. 

And these last two are the big ones. If you have multiple directories and you're doing a directory consolidation, it's big. It's not a ... and we all knew it was big, but it's probably the most complex part. It's the one that took more time than we thought it was going to take. Your usage patterns for AD-based systems and web-based systems are completely different, oftentimes, and so identities may not always be in complete sync like you expect them to be. They're often managed separately. 

And then that password and directory synchronization is always fun, and I'm sure that we can all share horror stories around password and directory sync. 

So with that, this is the evening of our deployment. So this is the Okta team. We're not all from Okta. They actually got us some Okta hats, but ... So there's Tom Ryans on the back celebrating. So this again, it was like a four and a half hour deployment. This is just after we had all of our ... all 135 apps validate everything was good. So we were obviously really happy. 

So with that, let's go into QC, and ... QA, sorry. Q&A. So I think there's a mic, and this is being recorded, so if you want to ask a question, raise your hand-

Speaker 1: And quick reminder, if you can fill out the survey, drop it off in the back, that'd be excellent. 

Questions?

Speaker 2: What was the R1 R2 ... You had custom code that ... I'm sorry. 

You had the R1 R2. Was that custom code, and could you repeat what that did, again?

Dave Fend: So the R1 R2 is like ... I caught at least the first part of the question. They were things that were specifically built for the co-exist that will be removed in the future state. It's nothing more than HTML and JavaScript that does everything there. 

Speaker 1: That's it? Great. Thank you both. 

Bill Dubois: Thanks. 

Speaker 1: Appreciate it. 

Bill Dubois: Alright. Take care, everyone.