Building Scalable and Secure API-Driven Applications and Experiences
Mike: As Kevin mentioned, I'm Mike Rogers. I'm a product manager at Allergan, and my product is the True Tear app, which is Allergan's digital health companion to the True Tear medical device. Today, I'm going to give a little bit of background on True Tear, and then talk about our customer facing iOS app in the back end. Sound good? Before we get started, just a little bit on Allergan. I know this is a tech conference, but of course it's much more than just tech companies that are using Optive's products and services. If you know Allergan, you may know us from our most popular product Botox, which as you can see, works very well. I'm actually seventy-five years old. In actuality, Allergan serves in over a hundred countries and has multiple products in seven major therapeutic areas. Those areas are eyecare, medical aesthetics, gastroenterology, CNS, women's health, anti-infectives, and urology. As you can see, we have quite a few products on the market. Even though Allergan has traditionally been a pharmaceutical company with branded drugs, biologics, and regenerative medicine products, with the recent acquisition of True Tear and Cool Sculpting, we have quickly gone into electronic medical device space. A little bit about True Tear, True tear is the commercial name for the medical device that came out of Oculeve, which is the company which I previously worked for. Oculeve came out of the Stanford bio design program, which looks to find novel solutions to healthcare problems. It turns out we found a pretty novel solution to something called “Dry Eye Disease”. In fact, it was so novel that Allergan, who is one of the leaders in eyecare and owns the leading treatment for dry eye disease, bought us.
Dry eye disease is a condition where people are unable to produce sufficiently lubricating tears to nourish their eye. It's exceedingly common, particularly among women. There are about three million new cases per year. There is a treatment for it. The current standard of care is a prescription ointment, which works, but, it can burn and kind of blurs your vision when you apply it. Beyond that, it takes about six weeks of daily use to start seeing results. There is something, but it's not ideal. In any case, what happened back at Stanford was an electrical engineer and a neuroscientist got together and found out that if you stimulate a particular set of nerves in your nose, that you can trick the brain into thinking you need to produce tears. This actually turned out to be a brand new way of treating dye eye. After a couple years working with the FDA, we got clearance for the True Tear device about a year ago. The device itself is handheld, rechargeable, medical device. It is, I would say, unique for a couple of reasons. One, is the form factor. It's kind of purely distinct from other medical products you might see. It has a packaging and form factor, probably closer to that of a consumer electronic device. It's sort of the Apple of devices that you stick in your nose. The second thing is that it's an IOT device with a full Bluetooth energy chip set. Currently in the pharmaceutical space, data is pretty sparse, so it may seem arcane, but, the only data we really can collect about prescriptions and patients is we can know if a prescription is written, and if a patient picked it up. That's pretty much it. Of course, with this device, we can see how long the patient was using the device for, how often, when they were doing it, for what intensity level. Obviously a lot of really good data that can help us optimize treatments, not only for the patients, but the product itself.
The True Tear app allows us to show some of this usage data, to both the patient and to us, of course. It needs to be in a user friendly fashion, because it is consumer facing. As you saw previously, the user interface on the device itself is pretty limited, so this app helps show patients things like the battery level of the device, if they're running up against their daily usage limit, and what intensity level they're using the device at. It also graphs the usage so that patients can track how often they're using the device and also show that to their doctor during follow ups so that they can make sure they're using it as prescribed and getting the most out of it. This is an architecture diagram of the back end. We're using an AWS micro services architecture. We chose that for a few different reasons. One is that there's obviously no infrastructure to manage. No load balancing to configure or EC2 instances to update, which is really nice. The second is- it's really easy to develop on and create new micro services and new features for the product, which I would say, if you're working in the consumer space is pretty much something you have to do. Be able to work and change quickly. The final thing is, what was the final thing? Obviously, this was a brand new product, so we had pretty rough estimates of what our utilization would be. With AWS lambda, we can pretty much scale up and down on demand without having to pay for idle resources.
Since we're in the pharmaceutical space, basically the biggest concern for us was always security. We wanted to make absolutely sure that all communications were secure and encrypted, and that any personally identifiable or personal health information was compartmentalized and stored in a HIPPA compliant way. Using Amazon and Okta made that HIPPA compliance a lot easier. Of course, since we were in the user world, since it's the customer facing app, the usability is very important. We ended up using Okta for our identity access management and authentication. We chose that over say, Amazon's Cognito identity pools, for a few different reasons. One is that Okta, kind of out of the box, satisfies all of the security and privacy requirements. The second is that in order to have a HIPPA compliant architecture, if we would have used Cognito to manage our identities, we would've had to have that Cognito in a separate cloud, away from any other infrastructure services. That was just something that would have been required by HIPPA. Since we're using Okta, we can just maintain that one VPC and have Okta store all the credentials and just reference them in AWS. Finally, we had an existing contract with Okta, we've worked with them for quite a while, and we certainly use Okta internally for our employees, sales reps, doctors, and other third party affiliates.
Now, I was just going to go over a little bit of the custom authentication solution that we came up with. As I mentioned, because this is a patient facing app, we wanted to make it as usable and native as possible. What you're seeing here is the account creation flow. This is what new users will see after they download the app and are prompted to sign up for an account. First of all, we didn't want to use a web view. We could've used a web view that would have taken the user outside the app to an Okta sign up flow, but as I mentioned, that would've taken the user outside the app and sort of disrupt the experience. We have this custom solution. What we do is, we start by first checking to see whether the user exists, just to make sure their email isn't already registered. Afterwards, we make a call using Okta's API to the create user would password and recovery question function. Would the standard profile attributes, and then we set the status of this new account to “provisioned,” instead of “active”.
Now, typically, when you create a new account, Okta will send a verification email automatically, but when you click on that verification link, it'll send you to an Okta success webpage. Again, we wanted to stay within the app, so we ended up creating our own custom verification email. After we create the account, we send an email to that user's email address with Amazon simple email service. Within that email, there is a verification link, which is tied to a lambda function. When you click on that lambda function, that lambda function calls Okta's API, which changes the account status from “provisioned” to “active”. At the same time, that lambda function had a callback function, which we hooked up to a custom URL schema that's connected to our app, so that when they click on the activation link, they are automatically redirected back into the app. Maintaining that native experience. That's pretty much a little overview of the architecture. Happy to talk more about it if anyone has any questions. This is just a little bit about the future plans. I know Okta is doing a lot for customer identity access management. I think things like password lists, entry or one-time passwords would be huge just to make it as easy as possible. That's pretty much all I got, so thank you.
Kevin: Thank you Mike. Next I'd like to ask Mark Burns and also Frederick Lee will join him shortly, from the custom fleet team. They're on the security architecture and infrastructure team that will speak to how as part of they already have an internal work force use case. Almost concurrently with a separation from General Electric, they designed out a broad shared services infrastructure that allowed both their internal teams, but also third party developers to integrate and work with their existing infrastructure and develop a number of different applications on top of that. With that, Mark, I'll hand it to you.
Mark Burns: Okay. Thanks Kevin and thanks everyone for the opportunity to speak with you today. It has been a great conference, I've learned quite a lot this week, as well as obviously seeing Obama last night. What I wanted to share with you today is a little bit around Custom Fleet and our vision on the future of fleet management. As Kevin mentioned, my name is Mark Burns, so that's Mark Burns ...
Mark Burns: As Kevin mentioned my name is Mark Burns, so that's Mark Burns for all of our American friends. Not Mike, not Matt. I'm the IT Security and Architecture and Infrastructure Leader at CustomFleet, and I'll be joined on stage shortly by Frederick Lee who is the Infrastructure and Security Operations Lead. Just a little bit about CustomFleet. So, CustomFleet is a 40 year old company established in 1978 and during that period of time, we've been bought and sold on various occasions, but we're the leaders in fleet management in Australia and New Zealand.
Up until 2015, we're actually owned by General Electric. As part of GE's global restructuring and to sell off their capital businesses, they sold their fleet management business, which included CustomFleet to our now parent company Element Fleet Management. Luckily we've got about 400 employees and around 100,000 vehicles. Globally we have 2,800 employees and around a million vehicles, predominantly in Canada, North America, and Mexico. Just want to share with you our future focus and also the future of fleet management as we see it today. Prior to now, the focus of fleet management companies has really been around financing vehicles. That would be where we would purchase a vehicle and then lease it out to a customer. Then we wrap around that a bunch of services such as fuel and tires and maintenance and accident management services as well as provide basic usage reporting.
We've recognized that our customers want more. They want more detailed data. They want to understand how can they utilize their vehicles. If you've got a few million dollars wrapped up in vehicles, you want to make sure you're utilizing them properly. As well as we're also looking at our own opportunities to be able to introduce new services into the marketplace and also looking at how we can connect vehicles to their drivers, connect their customers to their suppliers, and create, what we're calling, this connected ecosystem. We're also heavily invested in data and analytics, so being able to provide greater insights to our customers. For example, if we get telematics data from a vehicle and we can overlay that with mapping and speed limit data, we might be able to demonstrate to our customer, "Hey, this driver is at a high risk of an accident because they're breaking harder, they're accelerating harder, et cetera, and maybe they're actually speeding on certain parts of roads.
We're also being partnered with other leading technology companies to look at how we can utilize emerging technologies such as connected vehicles as well as how we can connect those vehicles into the smart city grid. Most recently we're looking at how we can leverage blockchain to be able to simplify and automate some of our back end processes. For example, we have thousands of suppliers. Some of them we may only do one transaction with. Others we may do hundreds of transactions with per day. We're looking at how we can simplify that back end process from when the transaction originates through the payment, and being able to hook in with our suppliers for automated payments. Then we're looking at how we can also integrate with our equivalent of your DMV to do the vehicle registration and ownership as well, because that's quite a cumbersome and time consuming process from when a dealer gets a vehicle, registering it with a registration body, delivering that vehicle to an owner, and then even transferring that vehicle at the end of the lease when we go and re-sell that vehicle. Sorry. I think I pressed the wrong button. There we go. Now I'd like to take you on own journey with Okta and our implementation. Both from a single sign on point of view the federation and what's next for us.
As I mentioned before, CustomFleet was owned by GE up until the first of October 2015. As a result of the sale with Two Element, we entered into a transition services agreement by which we had 48 months to get off the GE network. GE offered us two options. One, they could build it, carve it off, and hand it over to us, or we could go and build our own [which would be environments and then we could then migrate that data at a later stage. So, we chose the latter because they gave us the ability to look at other products such as Okta, but also to simplify our environment as well. So, as part of that process we were looking at, we're even experiencing how difficult it was to work within a company with 300,000 plus employees. So, there's multiple single sign on solutions, you have to remember lots of different passwords, different complexity rules, changing at different times and we wanted to avoid that when we went into our new environment.
So, the first project we embarked on with Okta was to do single sign-on and that was initially only through Office 365. Since then we've expanded that to 21 additional applications and also ran 100 bookmarks as well and that's all linked back into AD. So as a person logs on, based on their ID group membership, the Okta portal will be customized specifically for them. So, certain applications they'll see and other applications they won't. We also started to use Okta's mobile device management solution as well. And that's for managing corporate devices, but also personal devices whereby a person has elected to have access to e-mail natively on that device. We've implemented multi-factor authentication as well. So whenever any of our staff or external want access the Okta portal, they must use multi-factor authentication and we also leverage it for more privileged access as well. So, any administrator that logs on to Okta whether internal or external must have MFA and also for administrators logging on to servers they also must have MFA.
So, our second, I've done it again, sorry. So, the second project that we embarked on about eight weeks after we cut out from GE, so we cut over on the 21st of November in 2016 and by the 20th of January we were embarking on our second project which was around implementing a customer single sign-on solution. When we migrated from GE we inherited their legacy on Identity access management solution as well as a legacy on-prem LDAP solution. It was both expensive, as well as, we had to maintain a unique skill set just to manage that solution. So as we had already worked with Okta, we decided to leverage their universal directory and migrated all of our customers for our fleet office application which is a front facing web app. From our on-prem solution up into Okta. And that took around eight weeks from when we actually started doing the development and semi find our web application to then actually sync in all of our customers back up into Okta.
So couple of benefits as a result of that was. It gave us a flexible authorization of authentication service. So not only were we able to simplify the process and remove things such as secret questions, and that as part of the authentication mechanism. But we could also look to expand that service later on. I'll touch on that in a moment. One of the immediate benefits was we could decommission our own prem infrastructure as well. So we actually had 17 servers, which probably doesn't sound like a lot for a lot companies but when you're only running at that point in time 150 servers, 10 percent of our fleet, we could get rid of straight away. And we also saved in the vicinity of 300,000 dollars per person. Just by changing that service.
So then our third project was around customer federation. So leveraging on that single sign-on, to then look at how we could integrate with our customers. So early this year we went live with our first federated customer. And what that involved us doing was actually working with Okta and how we could take that customer and on board them in an automated fashion and be able to manage the user access and their permissions and also the account set-up on an ongoing basis in an automated fashion.
So we decided to set up a separate Okta tenancy. And Fred will touch on a little bit more around this in a moment. But effectively what we created was three tenants. We had our corporate tenant, we then had out customer tenant where we basically lumped everyone else into and then we had this federated tenant. And that federated tenant is used specifically for that customer. And what that allowed us to do was then take a direct sync from them on a weekly basis. We can then flush out people that have left and add new people. So as a result, we were able to onboard 13,000 of their staff in one evening. Took about five hours to upload that many people. To put it into context, prior to doing that, we were running at around 12,500 predominately B2B users in our system and overnight we went to 27,000.
And then, the other benefit of it is that it also simplifies the log-on process. So now our customers, whenever they want to access the application, there is an icon sitting on their Internet. They click on that link. They're authenticated by their Azure ID and automatically logged back into our fleet office application. As a result, if their account is actually disabled in AD, so even outside of the sync process, they lose access into our fleet office application. Which is great from a security point of view I did it again. So the next part of this broader project is creating what we call a new connective eco-system. It's not dissimilar to what Okta is undertaking at the moment as well. So what does that look like? So, obviously a little bit busy but what we're looking to do is continue to expand on the number of federated customers that we work with. So we want to have that integration. We don't want to have to deal with that on-boarding, off-boarding process and neither do our customers. So we want to increase that and then even things such as the logon with Okta will definitely be something we'll look at in the coming weeks as well.
We're also ripping apart our fleet office application. So prior to this, it was quite a monolithic application. That did try to do everything for all people. So it did all the authentication, all the authorization, provided all the functionality. But one of the challenges it created for us was that we had multiple dev teams trying to develop on the same application. So your mates going back to their mainframe and timeshare and that kind of stuff.
So what we've done is we've also then split our application into modules. And each application in itself will also be able to do its own authentication and authorization. We're looking to leverage SAML too. As well as Open ID Connect. And we're going to extend that to our externally connected third party applications as well as any externally hosted cloud based applications as well. We're actually making it a requirement moving forward that if you want to do business with us you must support at least Semel but ideally Iwarth and open ID as well. And then finally, we're expanding automation integration services layer. So at the moment, we've got a small number of services. But looking to expand that and this is what helps us crack the CK system. We want to make it easy for not only our mobile app to talk back through to the back end.
But we want to make it easy for our customers and suppliers and third party integrators to actually hook back in and talk through APIs back through to the customer fleet's back end. So we collect lots of data, whether it's motor vehicles, whether it's supplies around tires and maintenance, fuel consumption of vehicles. So that type of thing. So we know what it costs to run a vehicle. We know what kinds of behaviors are normal. We want to be able to see how we can use that data and tap into our customers and suppliers for sharing that. Excuse me. So now, I'd like to hand over to Fred Lee. He's going to talk around some of the technology challenges that we've encountered, as well as some of the key learning.
Fred Lee: Thanks Mark. Thanks to Okta as well for the opportunity. Thank you to Okta as well for the opportunity to present at this exciting event. Hello everyone. Today I'll take you through some of the techno considerations we've been through while implementing, staff single sign-on, customer authentication, customer federation and finally API of authentication.
Let's start with staff single sign-on. So you have the clicker, right? So we use active directory and I split off into best practice. At least two active, Okta active agent and Okta desktop single sign-on agents were deployed to provide connective to Okta. As well as single sign on for staff to Okta. I'll use non-privileged users and groups that are synced up to Okta. And the groups are then used to assign applications. We avoid using users to assign applications directly. As Okta is delegating authentication to AD, AD verification delay becomes an issue for day to day operations. To avoid our users being impacted by that. We decided to host two AD agents in our primary data center and a standby agent on a secondary data center for a high validity solution, even though it's a bit manual. So since we started, Okta has been really busy implementing a lot of features. Some of them go out straight away to general availability while others are on an early access manner. So for today, I'd like to touch up on two of them. The early access feature and profile mastery and use a life cycle management enhancements has been really beneficial for us when restoring a user. Whereby we reduce the number of steps from four and tools down to just 180 sync. The other early access feature Okta device trust for, early access sync, allows our users on native iOS devices to access-
Fred Lee: Native OS devices to access the Office 365 email without using their passwords. So not only does that improve user experience but also allows us to secure Office 365 by removing the need for trusted devices to actually access it. And finally, the most important congregation we did on our tenant was to enable multi-factor authentication. Every of our users that must access it externally, must be MFA registered. And they can only register for MFA when they are on our network. And administrators, such as myself, always are prompted for MFA regardless of where we are. Moving onto customer authentication. So as Mark mentioned, we had an on-premise LDAP server and we wanted to migrate to OPTRUD, however the primary consideration was that we didn't want our changes to staff impacting our customers and vice versa. So the most simplest way to do that was to use two separate tenants. So now how do we get our users across?
So Okta provides multiple bulk load ways for us. In this case, CSV, API and even an [inaudible] agent we can have landed. However our customers passwords in that were hashed, so none of the methods provided before can actually support this. So in the end we decided that we would bulk load using CSV, not activate the user, and then we'll make a small change to office login module, whereby we capture the users unencrypted password and we'll push that to their Oct UD account. That activates the account, and a flag is then set on the user's account on the application database to then say they've been migrated to Okta and go to Okta for authentication. So unlike this week's announcements, we went to a lot of pains to actually mask Okta from our customers, purely from a user experience point of view. So in that case, in that end, we actually host our own login module and we leverage a lot of the Okta SD case for authentication as well as user access management behind the scenes.
And finally we also had, to continue the theme of single sign-on for our staff, we wanted our staff to actually be able to access through Office internally without actually logging on, like our customers. But we didn't want to really spend all the efforts to rewrite the whole thing as a SAML, unlike we do now. So the answer to that would be Okta tenant to tenant for direction, whereby our customer tenant becomes a service provider, our staff is the admin provider and the moment that our staff try to access the internal application, they get directed to the internal Okta tenant which redirects them and signs them on to the customer tenant and then back down to the application. And that actually leads us on our journey to our customer federation. So as you've already seen, we kind of extended the method that we use for staff federation onto our customers, if not for two major issues. The first being that Okta needed to have IDP discovery functionality, and the second was that there was a high risk when we were doing the federation changes of impacting all our customers, at that point being thirteen thousands of them. So the solution there was to use Okta subtenant. So as Mark mentioned, each subtenant is basically a copy of our customer tenant. But it's dedicated to a federation customer. Thereby, that removes a need to have IDP Discovery as that tenant is always federate to just one customer and it also allows us to have different policy settings or any other configuration specific to that customer, should they need it as well.
A couple of downsides. One is our application now needs to support multiple IDP's so Identity Providers, which is not too bad. All developers need to discover that for themselves, and the second being all the management overhead for me and my team. And lastly, as Mark mentioned, we currently get a flat file feed from our customer and we use API's to actually go and create, update, and delete the users. But since they've got their own federated tenant, what we want to move to is for a more automated UEM, such as maybe an LDAP or even active directory agent. So that's something we're working with our customers to see if they've got any appetite for that. And now our future road map is also SCIM, as well, if our customer would like to use that themselves for N to N provisioning.
And that actually leads us on to our final one, which is API authentication. So API authentication for us is a new journey. As part of our new foundation, project, where we're building all the modules, we wanted to leverage mod authentication, in this case being OAuth 2.0 compliant. And fortunately for us, Okta had in the last year or so released an API management capability, which we are really looking forward to leveraging. And we're also looking forward to leveraging our existing F5 partner as well. It's really exciting to see that Okta and F5 have done a lot of integrations together. So for us, what we'd like to do is all of the API's will be authenticated by Okta, with Okta acting as our authorization server, and as we've got a combination of internal API's, business to business, and business to consumer API end points, they'll be a few different types of flows that we'll be leveraging. And on that note, I really look forward to working with Okta to best leverage the API management capability and get a really nice API framework going. Thank you for your time, and I'll hand back to Mark to close out.
Mark Burns: Thanks Fred. So look, I just wanted to close out with just a couple of rules that we operate by within Custom Fleet. A thing that's allowed us to be able to move so quickly with not only moving out of the GE environment, but being able to get rid of a whole bunch of legacy infrastructure, as well as being able to then move into doing things such as federation.
So the key thing for us was to listen to our customers. Our customers were complaining about how hard it was to actually create an account within our Fleet office application and also if you've got a work force of thirteen and a half thousand staff, how do you manage that manually? Right? And that's near impossible. And as a result of that, we've got to be then prepared to change direction, so Custom Fleet being a forty year old company, being bought and sold a few times, we had our fair share of legacy infrastructure and applications that I mentioned before, and those business decisions that were made as part of a global company, a three hundred thousand seat company, there are certain types of technologies that were purchased that were then thrust upon what is fairly a small business in comparison to the overall GE organization. So again for us, being able to separate, we're now able to change direction very quickly and through that rearchitecting our Fleet Office application, we're also now able to introduce new features at a quicker pace as well and embrace methodologies such as AGILE and sprint practices to help shorten the release cycle.
The other key thing for us is to only have one strategy. So there's no point having a business strategy and an IT strategy, pulling the organization into two different directions. So we're very cognizant of making sure we work closely with our executive team as well as obviously the input from our customers and be able to develop a strategy that is an organization-wide strategy. So as an IT function and running the architecture function, we always have front of mind, what's the business's strategy, and overall what's the organizational strategy? And fourthly, it's partnered with the best organizations and for us, Okta is obviously a leader in this space and I think to add to that is obviously to get in the best people you can afford as well. So again, for us, I think we were able to, with the initial single sign-on, that was four weeks. But that was only an hour here and there because we were also building our entire environment. The customer's single sign-on, that process took eight weeks, and that included the design work, the development work, the testing, and then the final migration, and then with the federation, that took a little bit longer because we had to coordinate with our external customer. But still the time to market was quite quick and now it's a reusable model that we will continue to use for any further customers.
And then lastly, a key manager for us is to automate, automate, automate at all levels, so it doesn't matter whether it's at an operations level, where we're looking at leverage technology such as robotic process automation, expanding our API architecture, but also at the IT level, so whether it's testing, development, or even from being able to build a server, we're working on automating at all those levels. So on that point, I would...we've got a few minutes left, Kevin? Yeah? So at that point, I'll hand back over to Kevin and if you've got any questions, please feel free to ask.
Kevin: Actually, if I could ask Mike and Frederick to come up, I think we have enough time left for perhaps two or three questions if anybody in the group has any questions for anybody in the group.
Speaker 1: We got into position to go between Cognito and CIAM with Okta. You mentioned about HIPAA. Are there any other factors that led to deciding to go with Okta instead of Cognito?
Mike: Yeah, I think as I mentioned, HIPAA was a big factor. I think one of the biggest things is that we've been using Okta internally and we just kind of had a relationship. Their project management team was super helpful and walked us through everything. If we had any issues, we could call them up. We also are in San Francisco so we could just kind of walk down the street and that was pretty convenient.
Speaker 2: I also had a question related to HIPAA. I was just wondering if you'd gone through the experience of having the security audited and what that process was like if so.
Mike: That's a good question. We haven't had it audited by like a governing body like the FDA or anything, but we kind of just try to adhere to industry standards, so we've done like penetration tests and binary static analysis and yeah. Again, Amazon and Okta are very helpful in looking over your architecture designs, making sure things are well architected and secure, but yeah. Fortunately we haven't gotten attacked yet, so I'll let you know what happens when that happens.
Speaker 3: With the custom activation email that you had mentioned that you did rather than using I guess what Okta does behind the scenes, that I can understand, but how does your native app, the IOS app, handle the recovery flow for a user when they forget their password? Do you have a custom email process that handles that or is that taken online?
Mike: So, if they lost their password?
Speaker 3: Yeah. To initiate the recovery flow for a user. Is there a forgot password built into that native app or is that...?
Mike: There's not a password built in, but I mean, we just...Okta has a bunch of different API's for create user. Or when you create users, you can specify whether it has MFA or recovery questions or forgot your password, so we just use those API calls. But we can stay within the app.
Speaker 3: Oh, okay. I was just curious because I'm heading down the path of implementing my own API set of calls for the recovery flow and it's a bit challenging and I just didn't know if you came across it. Also, you mentioned about the federated...you used the term sub-tenant. Is that an actual...is it differentiated differently by a regular tenant or is that just...?
Fred Lee: It's similar to a normal tenant, how it basically hangs off your...
Speaker 3: So it is different?
Fred Lee: It is a separate thing altogether with a separate URL and actual domain. However, from Okta's perspective, it's all under the one tenant, which is our customer tenant.
Speaker 3: Oh, okay.
Fred Lee: I think it's more of a management point, but you might want to clarify with your manager.
Mike: If I could just add one thing to your question about password reset, there are natural configurations from inside of the console that Mike talked about that you can also leverage as well.
Kevin: So I think that takes us to the end of the session. Mark, Mike, Fred, thank you so much for your time.
Watch as Okta customers Allergan and Custom Fleet describe how they used Okta's API and UD to build a centralized storage of customer credentials and personal information information alongside with complete HIPAA compliance.