Security in the API Economy

Announcer:  Please welcome Okta Senior Developer Evangelist, Keith Casey.

Keith Casey:  Hey everybody, I'm Keith Casey. It's great to be back in DC, I actually started my career here over at the Library of Congress. After that, I went to the DOJ, so that's away from the DOJ earlier, and I went to the FBI, I work for the JMDPMO and joined the larger IC after that. If you don't know what those terms are, welcome to DC. 

I actually got tired of acronyms though, so I started working for an SF company, working for APIs. Oh. Wait a second. All right so, today I'm here to talk about security in the API economy. I've been working with APIs actually since the Library of Congress, so about 15 years now. Living and breathing some way, shape or form.

And in the last couple years, you've seen this explosion of APIs and it's happened for a variety of reasons. It's sort of throws out this term the API economy and so, it's the idea that we're making APIs available to plug in features or functionality from other systems into ours.

Now this kind of introduces some weird ideas but, the primary thing is that there are features and functionality that we do better than everybody else, and as a result of that, we want to make these data, these features, these tools available to other people to embed in their apps.

There's a couple different ways to look at this but, if you're not familiar with what API is in itself, it's how one piece of software talks to another piece of software. There's a lot of nuances, a lot technical details on top of that. Realistically, it does not matter.

An API is how one piece of software talks to another piece of software. It could be as simple as sending an email, there are APIs for sending email pretty easily. It could be a little bit more complex of sending a text message it, could be even more complex of sharing identity information back and forth between trusted systems.

Those are all APIs, it's a pretty straightforward approach of doing it. But really, the fundamental value to an API is really simple. Paul Graham puts it well, an API is self-service biz dev. It's the idea that by putting this tool out there, people can plug it into their applications, they can go ahead and they can accomplish things they can do a proof of concept, they can say, "Will this solve my problems?" And they get a yes or no, or they get a maybe quite possibly and then, they contact you. Because they say, "Wow. This is pretty close to what I needed to do. Let me go ahead and engage with this organization and say, does this solve my problems?"

We see this a lot. DC for quite a while had a system where you could pull out your phone and take a picture of a pothole, and then text that into a number and would send the GO location along with it. So, now DC traffic could say, "Oh. There's a pothole right here. We've got a picture of it, we know where it is down to the... Within like two meters of where we need to find it, and we know everything about it." That's an incredibly powerful use of a very simple API. 

It's a picture and it's a loud and long location that's about it. It's a pretty simple powerful use. But really, the main thing pushing APIs are these, are mobile devices because, stop and think about your mobile device, regardless of what device you have even if you've upgraded to the latest IOS whatever.

Fundamentally, this device has a flaky Internet connection, you get it in the metro stations but not between the Metro stations. You have a very limited processing power, you have very limited storage space, you have very limited memory, all these limitations. If we were expecting this device to do a lot of work for us, we're in for a bad result.

There is no way we're going to be able to map locations very easily because, this just doesn't have the ability to store all the maps of really everywhere, to be able to find where we are. So, APIs enabled that, the API for Google Maps says, "Here, your phone says here's where I am. I'm downtown at the Ronald Reagan Building and I want to go to Dulles."

And then so, we send those two locations off via an API to Google, and Google says, "Well, based on the traffic, based on the maps, based on all these information, here's the recommended route. And in fact here's not just a recommended route, here are a couple alternate routes just in case traffic gets terrible."

That's an incredibly powerful thing to do. Our phones can't do it, they can't do it by themselves, there's just no way we can do that. APIs make all these available, API's open up this world of processing power, of data, of functionality, that we can't embed on these devices in any reasonable manner.

But it actually goes a little bit further than that. APIs are not just about sharing data, it's about a customer experience. It's the thing that when you're outside at the networking event later today, and somebody mentions a documentary on Netflix, it lets you pull up the phone, pull out your phone and add that movie to your queue.

It's the thing that later on when you're on the Metro on the way back, you can pull out your iPad and start watching that movie. And then, when you get home and you fire up your smart TV, it's the thing that lets you start the movie exactly from where you left off on the train, that's kind of amazing. 

That's what APIs are for, they're about meeting your customer when and where they need, and the best experience possible. So, the other analogy I use quite a bit for API's is an ATM because, I love acronyms obviously. If you think about it, a bank is really good at a number of things, and one of them is giving you money.

So, you can walk into the bank and you can say, "Hey, I want to make a withdrawal from my account." They say, "How much?" Goes through that process. The problem is getting to the bank. How many people have been to the bank in the last month? Very few. We don't go to banks, what do we do? What do we do?

Audience:  We go to ATMs.

Keith Casey:  Okay. We go to ATM's or we pull out our phones, which are also powered by APIs. We go to an ATM and so, we go to that ATM and we put our card in just like we would at the bank, and we're able to get money out. If you think about it, that bank is making this functionality and this data available to us, where we happen to be. At the gas station, at the Metro station, whatever.

So really, an ATM is an API for the bank. It's giving us access to their features and functionality in the way we want, not the way the bank wants. That's a pretty powerful concept. We can meet the customers where they want, when they need us, that's very useful. So, this is what it all boils down to, we want to have these digital experience, we want to open up the features and functionality of what our customers need to do, wherever they are, whenever they're trying to use us, however they want to use us, and this all APIs.

Now, there's a scary question in here because remember, we've spent how many years securing our system and not letting anybody in? Right? We don't even let our employees in if we can get away with it, right? We don't want them, we don't trust them. In fact Sammy was talking about that earlier, something like 75% of breaches come from internal people, this is a problem.

So, how do we do this? How do we enable this? Now, we have to rethink how we're approaching things a little bit. We have to look at in an API and say, "Look, an API isn't just sharing data and functionality. It's sharing the right data, the right functionality, with the right person at the right time." 

And all these comes down to what happened on my borders, the thing we've been sort of enforcing for decades at this point, of being able to say, "No. We're going to keep everybody out unless they're on our network, and they have our device, and they're on a trusted computer, and all these sorts of things." Those things quickly dissolve.

I spent a couple years with a company called Twilio, they do an API for sending text messages and making phone calls, and this was exactly the scenario of, we're opening up this functionality to literally anyone who hits the website. That's a criteria, you also need an email address.

So, it's a pretty high bar right? We're opening up this functionality to literally anyone who hits our website, and can figure out how to type their email address and create a password. So, we're literally just getting rid of our border in a lot of cases. But the thing is, when we're thinking about this and with a security context, it's not that we're just getting rid of the borders, it's actually not that at all.

What we're doing is, we're shifting it and we're shifting how we think about it, it's no longer, "We're just enabling that team down the hall," it's, "We're enabling that team that wants to accomplish something," regardless of where they are, regardless of how they want needs to accomplish it, regardless of who they are, we're trying to enable that team.

And that's a little bit of a shift because, the way we've designed and built APIs to date, I think is fundamentally broken. So, who are my developers in the audience? Do we have a few? All right? If you want to demoralize the development team faster than anything, what you do is, you have them build something useful, and put it on the shelf.

If you need to hire a new development team, you can get rid of the old team by doing that, right? Because that's what developers love doing, they love spending their time building something and then, for you to tell them, "Look, this isn't valuable. Thanks for your hard work, we're going to ignore all the work you did." That's the fastest way to get rid of them.

Now flip that around, the fastest way or the most important thing a developer wants to do at the end of the day is, they want to do their job, build something useful, and go home. That's kind of number one and number two priorities, right? I've gotten a head nods from the handful developers here. That's great.

We want to build useful things and then, we want to go home. Well, on the other side of this graph, we have the integration architects and guess what? The integration architects have two priorities. What are they? Any guesses? They want to build useful things and go home. That's it.

Now the security team has a different set of priorities; they want to say no and go home. No wait, we've set up this situation though, right? We've set up this situation where the security team, their main task, their main job in life is to say no to everybody, and everyone hates the security team, right?

If you're part of the security team, I'm sorry, but you know it's true; you're hated. All my colleagues in the front row are cracking up. You're hated because you're the team that always has to say no, you're the team that takes that developer's hopes and dreams and crushes them every day.

And we've set up this really bad situation, so you're hated for no good reason, you're hated for doing your job, which fundamentally we need you to do your job. So, we have to rethink this and so, sort of our approach and my approach in building APIs is the vast majority time. We have developers who want to build that something useful and go home.

And then since there's not any real guidance or approach or standard process for securing that properly, they end up doing this thing of adding a user's table. And then, they manage the identity, they manage the access, they say, "Well, if you can log into our system, you obviously have access. We're good to go." 

and so what happens is that, the development team when they're finally ready to launch their project, they forget to CC the security team, and they just announce it. And so, now you've got this rebel group that's launching applications, launching systems and now everybody's responsible for, that could go on for literally years. 

And now you can never turn it off, right? Because you might have customers, you might have major partners that are now dependent on that. So, the approach that we have to have, to make this successful is, we have to break this problem in half, because you know what? The developers, they want to build things to go home, they don't care who has access.

Security team, that's their number one priority; who has access? When? What did they do? Those sorts of things. So, at Okta, we've kind of approach this by saying, "Look, by separating out the development from the identity and access management, we actually start with what this big ugly hairy scenario. We break it into two relatively simple ones."

Because developers, we know how to build API's, there's lots of tools and documentation and approaches for doing that, and we could figure that out pretty straightforward. And then, identity, our security team, our compliance team, they know how to deal with that and so by separating this, this actually becomes too relatively easy things, and people get back to their core responsibilities.

So, now the development team doesn't have to figure out the security team's policies. They can say, "Hey, does this person have access? Yes or no. What access do they have?" And the security team can say, "This is the access they have," and that's it. And so, security team gets a lot of insight into what's going on, they don't have to say no.

What they do is they say, "Here's the rules you have to adhere to." Which is actually a pretty good situation because you know what? Developers we love rules, we also love ignoring rules, but we love rules, and we try and stick to the rules most of the time. So, by shifting this mindset, we set up a situation where we can actually have people be successful on both sides, and then our security team isn't just a team that says no and go home.

They're a team that says, "Hey, here are the rules, stick to them or else," and then they go home. That's a much better situation. So, in terms of how we've done this on insider things, is we've approached this from two separate things. Actually, going to skip over this slide and go to the next one.

We've separated this with our API access management product, and this is what I live and breathe every day at Okta and we really separate this into two halves, and the product architecture represents those two halves. So, on one side we have the OpenID connect OAuth specifications. I don't mean it's OAuth like or OAuth friendly, it is vanilla OAuth. If you don't know what that is, we'll get to it in just a second.

On the other side, we have our flexible identity driven access policy system. So, it's some of what Sammy was talking about a few minutes ago. So, by separating these two things we can say, "Look developers, you're using OAuth." This is a standard and specification that you know and you understand, and you've used it on dozens of apps at this point.

So, that investment that you've already put in terms of training and tools and documentation, you can save that. On the other side, security team, this is a tool it's Okta, you already know it. As easily as you can provision applications, now you can provision APLS. It's couple of clicks, and you're a to go. And, all this is backed on the backend by our APLA. 

So, whatever provisioning apps you already have plugged in, like HR is a master if you're tied into something like ADP, or workday or anything along those lines, when you create a new employee, and you say this person is part of these teams, that automatically ripples across into the system, and you don't have to take additional steps.

So, let's dive in a little bit into OAuth. If you've never worked with OAuth, it seems kind of scary, it's actually kind of easy when we think about it the right way. Think about the last time you checked into your hotel. You presented them with credentials, called the driver's license or a passport, and with billing information called the credit card. 

They validate that information, then say, "Yes, this is correct, this is probably you," and they issue you a token, sorry a key card that expires after a certain number of days, and that key card gives you access to your room hopefully, potentially the executive lounge, the exercise room, the laundry room, it can give you access to a variety of different things.

And now, you can use that key card token however you want to think of it, to get access to all those individual things. That is OAuth. You present credentials, potentially billing information, you get a token that expires after a certain number of times, and that token gives you access to different resources or APIs. Now one sneaky little benefit of all this is that, your billing information is in exactly one place. 

It's not everywhere, it's at the front desk, in this case the front desk is Okta. So, it's with us, you don't have to worry about this information being leaked all over the place, you don't have to worry about sending it all over the place. So, just from a point of attack, there's not dozens of points of attack, there's one. So, now you know where to spend your time and effort thinking about how do we protect this, and we have people who live and breathe that every day, so that works out pretty well for us.

So, that's the external side. When we bring it to the internal side, we have our identity driven engine, so we can make restrictions or adaptive MFA, based on things like; who you are, where you are, what groups are you in, and what applications are you trying to get access to, should you be logging in from China three in the morning? Well, if you're a DOJ employee, probably not.

These are the kind of things that we can attack, that we can say, "Wow. Wait a minute. This is outside your normal behavior, let's go ahead escalate the multi-factor aspects." So, instead of just a username and password, now we're going to require an opt to verify push, or going to require an email link or something along those lines that say, "Is this really you?" That's a really powerful concept.

So, now you can sort of have the security posture adjust and adapt, based on what you're seeing. And in fact, one nice aspect about this is, we've reached a scale so now we can see this across a lot of customers all at once. So, we see it in one customer, we can you know recommend options for other customers, to be able to say, "Hey, banking customers are seeing this, heads up."

So, and probably one of the most subtly powerful things in this is that, this will depend on the clients people use. So, if somebody is connecting with a mobile application to your device or to your API, you can actually have a different security posture than if somebody connects with a web application. So, now you can say, "Well, I'm a bank and if somebody connects via mobile app, maybe I'll let them check their balances but not send wire transfers."

You're going to appreciate that the next time you lose your phone in a cab, somebody can't just open up your phone and send money. That's a good thing. So with that, I'm actually going to dive into a demo, if everything works out well. Okay. Here's my Okta screen. You can see I've done a little bit of customization here. So, just like I said earlier that API access management, we architected the product to represent separating those two problems, of the developer's problem, the security teams problem.

So, once this decides to log in, we can actually go through the application, and we can configure APIX management to do exactly that. And sometimes, you just love internet access, don't you?

IT:  Yeah. Right. You don't want to go to demo one.

Keith Casey:  Switch to demo two?

IT:  You can go to demo two. Yeah.

Keith Casey:  Okay.

IT:  Let's just do one, two, three, four, five, six, seven, eight, then figure that. We'll see what happens.

Keith Casey:  All right.

IT:  Thank you for your patience.

Keith Casey:  No problem. So, what I was going to show here was that, we can configure the API access management just like we sort of separate the problems. So, the first side is; we set up an API connector, as in OAuth connector, OIDC, In fact if you're interested in that. And so, what you can do is, the developers that interact with your API, go through an OAuth flow, just like they would for any other API.

Everything from Uber to Twitter to Facebook; it's a familiar territory that they know. On the flip side, on the internal side, we can have what's called an authorization serve. And that authorization server, takes the incoming requests and says, "Okay, after they've authenticated, who are they? What are they trying to do?" So, we can actually have groups or permissions based on that.

So, you can say, "This person is part of our legal team, here's the permissions they're even allowed to request?" Forget what they're allowed to be granted. First, here's what they're allowed to request. If it's outside that list, we have a problem. And then, we can go ahead and we can set additional rules on top of that. So, you can say, "Well, when somebody makes a request with a mobile device, they get read only access. But when they make a request and they're part of this group and they connect with a web client, now you've got read write access to your API."

So, you'll end up with this powerful set of configurations that once again, the developers can use the front end. They don't need to know or understand the rules that security has put in place, but security can make sure that they're being enforced. The developers can't work around that, it's OAuth. It's OAuth behind the scenes and it's Okta in front of that.

So, that looks like the Internet didn't come up so, that keeps life a little exciting. So, normally I would go ahead and show an API of... Let's secure this using AWS itself. So, we can plug in directly into any API gateway if you're using AWS MuleSoft usher or whatever the case may be. We can plug in right out of the box and get you from an API with a separate user table and all that information, to something integrated with Okta, usually in about five minutes. It's a really quick and powerful integration.

So, that you can catch me after this in the break, but I'd like to invite Tony Real to the stage. Tony real is a...

Tony Real:  Thank you. Hello everybody. I'm painfully aware that I'm standing between you and the next break, so I'll try to keep it short and sweet. My name is Tony Real, I'm the director of application development and support for the Association of International Certified Professional Accounts, which is obviously quite a mouthful. Who are we? We're actually a combination as of January first of two different companies.

We mentioned before about companies being 100+ years old. The American Institute of CPA, which I joined three years ago, and the Chartered Institute of Management Accountants, which is also known as CIMA. CIMA is almost 100 years old, AICPA is about 130 years old. As of January first this year, we partnered together to form a new organization, this new association, and we are basically trying to empower the world's most highly skilled accountants both, CPAs and CGMA's, which is really just public accounting and management accounting, to really to meet the demands of the several changing world.

And to get an idea for sky's and scales here, we've got about 650000 members, we're in about 179 countries in the world, and over 150000 firms and businesses employ our members. So, really I joined the company about three years ago and when I joined, a lot of the same things you've heard present today, around authentication identity, these were things I identified immediately were critical for our organization.

In order for us to provide a personalized experience, to sell products to our members and to people who are non-members, we needed to have a way of knowing who they were. What we had at any management systems already, they weren't meeting our needs. And so, I identified pretty early on, this is a top priority, we're willing to spend money here, we're willing to make this happen.

So, I touched upon this really briefly. We had a legacy system, something called Entrust GetAccess on premise system, unstable, out of support, super difficult to maintain, there's a memory leak in the application I found, we were doing nightly reboot of the application every night in order to keep system stable. And I would just say on a regular basis, we had staff that would wake up at five o'clock in the morning just to make sure the application worked.

And this is our identity platform for both internal authentication and for external members and customers, and it just really wasn't working for us. In addition, in our internal audit group, also identified we were out of compliance. The version of the product version 8.0 was out of support and 8.1 was the only version we could actually move up to.

I would just say that cost us well over $100000 to do the upgrade, and it wasn't working for us, we'd outgrown this application. So, I'll be the first to admit, I was wasn't the one that brought Okta into our organization. My boss of the time had said, "Hey, the first project I want you to work on right as you've come in is, Office 365. And you've got on prime exchange, I want you to move this over. We're two months into a four month project, we should be able to handle this in two months. No problem."

Well, I'd say probably seven to nine months later, we actually finished the project and while that project was in a lot of ways difficult to get through, the one piece that was a shining light in all of this was really the authentication, Okta just worked, and we only put a small amount of time in the project to work on this, it functioned properly, and we spent the rest of our times dealing and chasing other issues.

And so, that was a great experience for me. I was able to say, "Okay. Great Okta." Now for good things that work well for us, how can we expand upon this? And obviously already making the investment, we had in other systems, as we put a new HR system in place, a mobile device management, video conferencing, as well as our ticketing system.

And so, part of what made that a great experience for our users, was some feature called Desktop SSO. And so, most people are familiar in companies with Windows based authentication systems, people of Active Directory most companies have that, and so all these called application didn't have a direct hook in to actually sign people automatically to their applications, and by enabling Desktop SSO, which was simply just a couple of web servers in our environment, people would be automatically redirected there if they tried to access an Okta application.

It would sign them in with integrated authentication, and then it moves them right to the application, great experience for users. And you've seen that Okta dashboard in other presentations, we were able to put that in place and we found it was actually far easier just to redirect people to the Okta dashboard than remembering all the URLs and bookmarks for the other applications they were getting into.

So, being the AICPA, a big part of what we do is public accounting, and a piece of public accounting that's really near and dear to us is auditing, which I'm sure everybody loves. I'm actually subject between five and seven audits per year because to be frank, we have to eat our own dog food. We have to do what we recommend other people to do as well. 

And so, one of those audits came out that our help desk was actually not providing enough validation of who our end users were or to do things like reset passwords. And so, people were doing that because we had an application called Quest Password Manager, wasn't functioning well for us, it was kind of breaking from time to time.

And I was surprised to find out, since I hadn't actually sought out Okta in the first place, that that self-service functionality for password resets, solved a lot of problem for us in just a couple of days. I actually envisioned that Active Directory integration, which was one way, I didn't realize it was an additional sync back for passwords. That was huge for us.

And we talked about MFA in the prior presentations as well. We basically are internal audit and security and privacy groups came to me and said, "Look, you cannot implement anymore internal applications, unless it's using MFA." That's hard and I can imagine for most of your end users, they don't want to do MFA. It's difficult to do, it's cumbersome and we wanted to find a way to make it easier.

When we had purchased Okta in the first place, we actually had bought kind of their standard MFA products, and I thought about it how indecent it had been described and how SMS was not considered to be a great secure second factor. And I trying to think of how to make this as easy as possible for our end users.

And the reality is MFA, the act to verify with push application, was slick. I'd seen it from out Okta reps before, and I thought, we should spend just a little bit more money and add this feature in. In doing that, it made it really seamless experience for our end users. On top of that, we also choose to do location based policies.

So for our end users, whether they're on our VPN or they're actually part of our network, as long as they were on premise on that VPN, it didn't prompt them for that second factor. So, from the end user's point of view, almost nothing had changed other than a rolling once an MFA. 

They were essentially doing what they were doing before and it was only in unique scenarios where they were in the office, or for the limited applications where they were on a company asset, they were prompted for a second factor, and the second factor was easy to use. So for us, Okta enabled us to add that additional security in place, seamless experience for the end users in general, most people are happy with it. 

We've received little to no complaints about this. So, after having success with our internal users, we moved on to doing external authentication. And so, let me kind of paint a picture for you a little bit. A lot of our applications are mention here for instance, we had a lot of legacy applications not supporting SAML, Open ID things like that, they were just old applications.

And we're struggling with the fact that we had to deal with both; bringing new applications to bear, but also supporting the old ones and having some sort of common identity management system. And so, I would say we had a lot of false starts, we deal with some third party to help us with this, all except Okta. And after a number of false starts, we ended up going to Okta professional services directly.

They were incredibly helpful and the solution we ended up doing was, creating a custom log in page that actually signed us into both the old system, and the new system concurrently, and based on generated token for both systems. In doing that, that was seamless for all of our end users, all these customers that we'd have to reach out to hundreds of thousands of people.

And, they had no idea they were logging in to two systems. We kept them in sync, we kept them going, and that allowed us to take basically a year and a half to migrate from the old systems to the new systems. And I would like to say, I finally feel accomplished that as of last month our last legacy system using our old systems out is gone and done. Thank you.

So, I guess about 600000 accounts unique in the system, about 200000 people logging in annually in there's many more that could be. So, what is identity like today at the AICPA? I painted a picture for you that we had to reboot servers at night, we're losing sleep, we're having problems. I would say that in the past I was... The number of times that Friday at six I was doing a log in problem was in, I don't probably 30, 40 times.

A lot of evenings were just problematic for people. And so now, Okta is now our standard. I work primarily in operations but, in our solutions and architecture group, I actually have one of our architects come to me and say, "Hey, I'm looking at these new applications but, a couple of them just aren't compatible with Okta."

And I came back to him and said, "I don't think you understand. Okta is our identity management system. If you're going to pick an application not compatible with Okta, Okta is compatible to a lot of things, compatible with modern standards. I would question your selection if it's not compatible with Okta."

And that really kind of turned them around in a lot of ways, and as a result, most of the systems we're picking aren't generally very modern, very good and work well with. We've spent a lot of time creating actually custom logging pages for our end users providing a better user experience, and for password resets and for everything else, and people are generally happier with it.

And I'd say overall, the employee member experience has dramatically improved. And I would just say this; authentication and SSO are stable. That is a big deal for me because, I mean the number of nights that I worked through the night with my teams, is consistent. I'll tell you a story that one of our busiest times of the year is around really December.

We sell continuing education credits most CPA's have to do CPE's to maintain their credentials and to be active. The first two years I was there both Decembers, we have log in problems all the time and it was actually as a result, was blamed for a loss in revenue and from poor customer experience as well, we're there to support our members.

And this December, we had zero log in problems. And there was a couple legacy platforms still on one of them but, enough systems had moved off of the old platforms that nothing happened, it was all just beautiful. So, it was a great December for me, I got to enjoy the holidays and that's a huge difference for me.

So, really what's next? A lot of my experience I talk about is with AICPA, which is where I've spent the majority of time as a company. As I mentioned as of January first, we're teaming up forces with CIMA. It's not technically a merger, but all the MNA activities are pretty much identical.

We of course want to have a single cohesive identity management system. It doesn't make sense for us to have multiple platforms, it's best for us to have economies of scale and put things together. Now, it came to surprised me at the time, but not after this actual event, that the ability for improving the efficiency of MNA activities is much better than I expected it to be.

I thought I'd be coming to Okta with a problem, and so when I talked to our support people and saying look, "We are tasked to bring together two active directory structures, but we're not going to have those together this time. There's data privacy issues, security group says we can't do this right now, but we're also tasked with bringing new applications to bear, that are going to be used for all employees across the association, which to me seemed like an unsolvable problem."

When I went to Okta, they said, "Wait a minute. You can point to active directory structures to the same Okta instance. It's not just a supported configuration, it's a very common use." And that just blew me away because, once again as I mentioned before, that I keep bringing the problems and Okta is the solution, over and over again.

That to me is tremendous because, it enables us to move things forward. I'm actually leading a project now for Internet site, and this is one of those dependencies I don't have to worry about because it already works. Just like with the 365 project, Okta is at the barrier in terms of moving me to completing different deliverables.

And so, we're expecting the next step to be for external authentication, to bring those CIMA members in as well. We don't have the plan fully laid out yet, there are some legacy applications there as well, but we're confident that, that ongoing partnership with Okta will bring us to the next stage, moving us forward and allow us to succeed. 

Thank you for your time. I know I'm between you guys and the break. So, if you have any questions for me, I'll be available during the break, in the networking reception at 5:30. Thanks a lot.