Meet Juhi Bagaria, Your Okta API Expert

James Flores: Welcome to the Meet Your Okta Identity Experts Podcast, a podcast dedicated to bringing Okta's professional service experts to you. My name is James Flores with the product marketing team, and here at Okta my focus is on customer identity products, specifically our B2B offering and helping users get migrated into Okta.

James Flores: For today's podcast, we're going to be discussing exactly that, Okta's B2B solution, including: migrating users, using the Okta API, architecting for different user types, as well as modern federation. And this wouldn't be an episode of Meet Your Okta Identity Experts if I didn't have an expert joining me.

James Flores: Today, it is my pleasure to have with us Juhi Bagaria live from our Toronto office. Juhi, first off, welcome to the show and let me be the first to tell you how excited I am for you to share your knowledge and your experiences with us. I'm really looking forward to hearing about how you've helped manage our customer identities in today's landscape.

Juhi Bagaria: Hey James, thank you for having me today.

James Flores: Great. Awesome. I'm glad you're here. Now, before we get into some of the deep dive technical aspects of what you do, I want to first learn a little bit about you. Can you, can you tell us a bit about your background and how you came to Okta in your current role?

Juhi Bagaria: Sure. So I was completing a Masters in San Francisco in engineering and I used to attend a lot of meetups for women coders. And these meetups used to be held at various tech companies in the city. And one such was actually held at Okta. And that is when I met a lot of great leaders and people who worked here who inspired me to join Identity and introduced me to the professional services team. And I joined as a technical consultant. So since then, my journey for Identity started.

James Flores: Oh wow. So you started here in San Francisco, you got into Okta through the meetups, and you should also note that we also do have like an internal employee group dedicated for women in tech. So it's pretty awesome that you found Okta through those resource groups. And now you're based out of Toronto, which that's pretty cool that you came here through San Francisco, which is where I am. And now you're over there in Toronto. All that time you spend here at Okta, I assume you've worked on so many projects, you've seen the product evolve over all these years. Can you tell me, with all that time spent here at Okta, what makes you an Okta Identity expert, one that our customers can trust?

Juhi Bagaria: Right. So, I think when you walk into the doors saying you work for Okta, and Okta as a company name and as a brand name establishes that first true trust relationship with the customer. And from there, I believe it's mostly about demonstrating expert knowledge along with delivery. And I've been here at Okta since the last four years, so I know Okta as a product, its implementation details. So telling the same do the customers with confidence about what is the best solution for them and why and how it will cater to all of their use cases. That's what I think earns the customer trust easily.

James Flores: Wow. Well you've been here you said four years. What is that, like 12 years in tech years? Yeah. And you're right, it does give you a bit of notability. Helping all these customers with your current role, I'm sure you've gained a whole ton of experiences. Can you tell me what types of customers have you helped in your time here at Okta?

Juhi Bagaria: Right. So I work in the commercial space of professional services, and that means all of us handle around a hundred plus projects every quarter. And when you have such a large number of projects, so many customers, it's easy to juggle between a good mix of your customers. I've worked for all kinds of customers, ranging from out of the box solutions to solving very complex platform projects using APIs. And this also means having to work with as few as a hundred users to as large as a million users. And since I'm a developer, I get usually pulled into a lot of custom API projects, which requires building Okta's Identity layer from the scratch using SDKs and APIs. And like you said, been here for so long, I've seen the product transition. So naturally, our offerings for SDKs and APIs have expanded as well. So just keeping updated with the latest offerings, latest products and helping the customers build that.

James Flores: Well, so you said 150 projects per quarter, so that's what, 600 per year? Over nearly four years, that's almost about 1200 projects. That's a ton of projects, when you think about the scope of the things that you have to do for each project. And for many of our customers out there, maybe they'll do one project where they do a migration for the workforce and maybe one project for their customer identity. But you're saying you've done nearly 1200 projects and that's really impressive. And for our customers, I think that's what they look for. When they reach out to us for professional services, they need somebody who has done this over and over and over, and who can help them kind of develop that foundation and give them the guidance.

James Flores: So when, when you talk about Identity layer, you're talking about a lot of these companies are making a shift from older technologies, older methods of developing software and they're actually implementing like an additional layer, if you think about OSI models or LAMP stack or whatnot. You add an additional layer into your stack, which is Okta and use that as your identity for everything. So on top of your infrastructure, you put Okta. And then on top of that you put all your applications and that's how you protect everything. And in that sense, everything is kind of hidden behind the scenes. All accessible by the APIs.

James Flores: So with all these customers that you worked with, I guess since we're talking about customers now, can you give me an example of how a typical customer engagement works, especially for our customer identity project? Let's start with, let's say like, what are the problem they're trying to solve with Okta?

Juhi Bagaria: Right, so we can talk about this healthcare organization that recently started using Okta. And the way we handle a PS engagement is we had a one day onsite workshop where we tried to understand what were their pain points, what issues they were trying to solve, and then we'd get into technical sessions configurations. So we realized that their main goal was to move away from their in-house legacy identity provider and improve the log in experience of their business partners, investors, and customers. So basically, we were handling both B2B and B2C use case. And so this involved heavy dependency on a very smooth data migration from their existing database, their on-premise database, into cloud. Other concerns they had were that most of their users were senior citizens or some old aged care representatives. So any major changes you brought about in their day-to-day login, to the portal, would receive a huge pushback. So our idea was to consolidate the login experience for both B2B and B2C together and just aim for a smooth transition into Identity, create an Identity stack, without compromising their end user experience.

James Flores: So for this implementation, what were they looking for for you throughout the project? Like ,what type of advice did they see from you guys? Because I assume they kind of went through it themselves, they kind of understand their network, they understand what they want when they said, "Okay, Okta come in and help us." What was their ask of you?

Juhi Bagaria: So what I've seen from my time here at PS is thought leadership is one of the key things that customers are looking to get from their PS engagement. Because clicking buttons, making modifications, configurations, or writing code is not the hard part. It's the strategy behind pre-deployment assessments or how you mitigate any unexpected changes. And then, also taking into account their future migrations. This is what PS brings to the table when we go onsite with them or when we work throughout their Identity journey. So, you try to understand their current pain points, their current state and future state. And then we hand hold them throughout their entire journey. And along this process, you're not just giving them a custom solution that is tailored around their use case, but you're also them with best practices.

James Flores: Awesome. I think you hit it on the nail there, where configuration is not hard. Because at the end of the day it is just a bunch of check boxes, wizards, config files you save, things you import. But the strategy is what's really important here. Planning for this project, but also what's next, and what's next, and what's happening five years down the road. So for this healthcare organization, ultimately what was the solution that Okta provided for them?

Juhi Bagaria: So this healthcare organization was a big Microsoft and ADOTNet shop, so we tried to give them a custom solution that was built using Okta's dot net SDK. And we started off by developing the solution to migrate their data to cloud. We wrote a custom connector to import users from their on premise directories and then import hash passwords as well, because at the end of the day they didn't want to go through any password changes. And once we had everything in cloud, then we started talking about their login process. So we decided to host a Okta custom sign-in widget on their website. And the sign-in widget was one single point of entry for both B2B and B2C. And the sign-in widget, their website was protected using a single sign-on protocol called OpenID Connect.

Juhi Bagaria: So what that meant is once an Okta session was established, after their authentication policies, we could them to different landing pages with their own sets of application access. And we also developed some admin and self service password experience because they wanted their end users to be able to reset, unlock and do forgotten password on their own. These factors are easy to forget, but this is something that changes the phase of Identity layer when their users start using it.

James Flores: So, when you're working with customers, like this healthcare a company, what are some of the precautions you take when you want to migrate some of those, or I guess, to mitigate some of those potential migration issues?

Juhi Bagaria: Right. So as you mentioned, data is very sensitive when it comes to incorporating Identity posture. And what we try to do at Okta is try to make sure that data migration doesn't become a huge event. So we have multiple sessions where we talk about precautions and try to understand their current current stack. To start off, we try to understand their workflow. So starting by how many users are we talking about? Is it a million users or is it like upwards of 10 million users? And then what kinds of users are these? Is it their employees, their business partners, or both, or their customers? So once we have identified what users are we moving to cloud and what phases are we doing it in, we try to understand if there is any data that is external facing or has any regulation or some privacy standards that we need to take care of and any other downstream impacts it might have. Once we have all of these values understood, we try to come up with a good solution.

James Flores: Cool. So it sounds like you kind of tracked all the information, all the different variables, everything that you're going to have to deal with with the migration and then once you're kind of at this phase and you went through all those intricate details, how do you pick the best migration path? Like, how do you go through and decide we need to move the users this way, we need to do an import, or we got to do some type of auth proxy or some type of... Like how do you decide that and who do you discuss that with?

Juhi Bagaria: Sure. So we look at the results of our testing phase and understand what kind of migration technology are they looking for. If we can do something off the shelf, like just do an out of the box CSV and board or are we just loading users from their on-premise active directory or LDAP, where Okta has an out of box solution, or we try to see if we can build a custom solution. And that is more predominant when it comes to a B2B or B2C use case. We try to build a custom sequel or a CSV importer in whatever platform the customer is comfortable in and whatever platform their technology stack uses.

Juhi Bagaria: And from there, we try to optimize the code to not hit the rate limits. So our idea is to have multi threading and reduce the time but still maintain efficiency. In that case, what we have as a final result is you don't wait weeks for 4 million users, you can do it in two days. But the import of thousands of records can be optimized using these data loaders. We also talk about importing their passwords. So Okta supports some of the encryption algorithms. If the customer has one of those encryptions, we can import their password as well in Okta, using the same technology and methods.

James Flores: And now I want to talk about the Okta API. A lot of your customer identity projects, they all require this under the hood work. There's no Okta UI, there's no admin UI. The end consumer is not going to log in and see some type of dashboard because everything's built using the Okta API. So talk to me about using the update API to fulfill these use cases.

Juhi Bagaria: Right, so when it comes to customer identity or when it comes to hiding Okta under the hood, one of the important things that we take care of is really an identity layer without compromising the user experience, like you said. And we start off by, again, understanding their login process, which is their first point of entry. And from there, we kind of branch out into two things. One, if they want to continue using their current login and just call Okta's authentication APIs in the background. This way, their login screen sees no UI changes. The next day the users can come, login, they see no changes, everything is done in the background. But this does require their developers to write the authentication and authorization layer completely from the scratch.

Juhi Bagaria: The other solution that we typically offer, is our sign-in widget, which is just a javascript trapper. And it gives them a standard login box that can be rendered anywhere on the screen. So once they have the UI fixed, this can be hosted anywhere, either on Okta or on their internal servers. But what this offers is, it has in-built functionalities that supports most of the login flows. So it heavily reduces the dependency on the developers. And at the end, our idea is to use OpenID Connect to protect the website. So when the users start logging in, their login is protected, their password is not compromised, and it gives them the cleanest experience without seeing multiple redirects into different websites.

James Flores: Okay, cool. Very cool. All right, so let's do a little shift here, right? So we've already talked about bringing people in, building out a project, custom branding, basically hiding everything behind the Okta API. I want to talk now and switch gears and talk about users. In the customer identity space, there tends to be like these different types of users, not just employees. As we already noted, there's B2C and there's B2B use cases. So in your experience with working with all these customers, what are the different types of users you're seeing?

Juhi Bagaria: Right. So we see a lot of different user types. For example, the employees, like you mentioned. The customers, partners, business partners, on-trackers, or some special admins. And some complex use cases arise when you have a single user that can exist in multiple states or different states across different layers of the databases. What that means, is I can work for organization A and be part of Group A and have some special rights inside my organization. But I have so many data stacks and data layers, I can switch to another data type. Maybe I'm moving from my active directory to SQL database and I can be an admin when I come from an active directory login. But I could be a regular developer if I log in from a SQL database. Or if I log in from another SQL database, I could have special access like impersonation or AWS privileged rights.

James Flores: Okay, I see. Okay. So with all these different user types, I'm sure a lot of questions arise such as these, like how do you give access? How do you do delegated authentication or delegated admin permissions? Who's the profile master? Who comes from where? Who's the IDP? As well as a user segregation. I assume with all these different sets of users comes like these different sets of requirements. So what are some of the solutions that you've implemented for these various user types?

Juhi Bagaria: Right. So for these solutions, what I like to do is take a top down approach. And that means start by understanding that every policy in Okta, every authentication policy, everything you want to do with authentication is wrapped around groups. And in order for us to create these multiple authentication policies, we need to start segregating your millions of users into groups. The way we do this is we try to find a defining factor for different user types. So for example, if you are User A, you can have a defining factor, a special attribute. But if your User B, maybe that attribute doesn't apply to you. So we come up with different logic rules and create groups based on these multiple roles. Once we have that, we wrap authentication policies. So different types of users, different types of groups can experience and honor different authentication methods in Okta.

James Flores: Okay. So that's groups in a single [inaudible 00:19:24]. I want to bring up something that we haven't really talked about and that's having multiple Okta organizations, or multiple IDPs. In some instances, we're seeing customers, they'll have their workforce in one Okta tenant and they'll create a completely different Okta tenant for their customers. And maybe they have a partner that's using, I don't know, some other identity provider that they want to give access to their a partner application. Are you seeing a lot of movement in the space of customers having multiple Okta tenants? Or yeah, just basically that. Just the customers who need a bunch of different Okta tenants.

Juhi Bagaria: Yeah. We see this a lot with organizations where they have a structure of a parent organization and child organization. So for example, if you are the main organization, you work with multiple affiliates across the country or across the globe, you want to connect these different organizations, these different partners to your main tenant. And the reason is because you don't want to shoulder the responsibility of your business partners, their users, their life cycle management. All you want to do is share your application or share their application with your users, or share your application with their users. At the end of the day, what we're trying to do is solving B2B and B2C use cases with allowing all these customers and business partners to have their own identity system. They may or may not be using Okta, but you can still connect. You can still use a hub and spoke model to share user resources and data.

James Flores: With all these different like a mixture of Okta orgs that will connect into each other separated by region or different business units, that kinda brings us to our next topic, which is how do you bridge these connections? How do you bridge one Okta tenant to another tenant and allow access to both of them?

Juhi Bagaria: Right. So there are a couple of things we can do to connect your current Okta tenant with your business partners or with your customers. We try to understand one, if they're using Okta. If they're using Okta, we have a connector in our library. It's called an inbound SAML and [inaudible 00:21:46] connector. Simple, out of the box solution. But also we try to give them a custom solution. And what that means is, let's say tomorrow you have a merger, you want to acquire a company. Or tomorrow you have a new business partner, you don't want your admin to go and complete that connection. You can train a simple script and it adds your new organization as a SAML connector in your organization. So you can easily share data, resources, and users, and your applications downstream or upstream.

James Flores: Cool. Very cool. So yeah, SAML's great. And it's actually been used for many, many years, like in the federation space and when it comes to the IDPs, on-premise, or in the cloud. But the interesting thing about SAML 2.0, which is the current standard, is it was created in 2005. And you know what didn't exist in 2005? This thing. I'm holding today's modern smartphone. It didn't exist in 2005. So back in 2005, to access a system, you sat at a computer, a desktop or a laptop, you opened up your browser and you got into whatever application. And that works well. I mean, SAML's good for that use case. But in today's landscape, access can be from your browser, it can be from an app on your smartphone, either Android or iPhone or one of those other phones that nobody uses, or any other simple devices, you think like the IoT stuff. And so, the problem we're seeing is that SAML's great, but it's not necessarily designed for today's federation use case. So what are you seeing out there in the field, in working with customers in this area?

Juhi Bagaria: That is absolutely correct. SAML was introduced in 2005. And now we have this new protocol, new single sign-on protocol called OpenID Connect. And this was recently introduced in 2015. and this is something that is still being developed and a lot of work is going on by OpenID. So what OpenID connect does, it caters to all your devices. We have a solution. There is an OpenID Connect authentication protocol that caters to your web browser authentication. We have an OpenID Connect protocol that caters to your devices. We can build a native mobile app and protect it with OpenID connect. And there's also a third use case, it's called a machine to machine app, where you're not even handling users daily, it's just a machine to machine resource handling. In all these cases, OpenID Connect gives you a solution that is easy to implement and manage. It also provides this feature [inaudible 00:24:29], protecting individual aspects of your website. So not your entire website needs to have OpenID Connect. You can have different access for different user groups.

James Flores: Okay, so that's great technology chat. It's been really helpful. So for anybody out there listening who maybe is interested in working with Okta for a customer identity project and working with PS, what kind of advice would you give them?

Juhi Bagaria: So I would say if you want to learn about Okta, you are already in the right place. But you can also get started by learning Okta developer, create a free developer account, and set up Identity for your own small group of users. That gives you a great foot in the door. And we recommend always reading the blogs and our knowledge articles. We have plenty out there, including short videos on our new, latest upcoming products. And make sure you attend Oktane.

James Flores: Yeah, Oktane was great this year. And we will also note that we have a new site available right now. It's called toolkit.okta.com. And toolkit.okta.com is essentially a showcase of existing code. So any developer out there, places like [St. Judy 00:25:47], or anybody out there developing their own systems can actually submit their code to this community showcase. And then anybody else can find it. It's all tied into GitHub. So you just add it to GitHub, you submit it to the website and you can automatically see this. So you think like, oh, maybe I'm new to Okta, maybe I've never developed against the Okta API, or I don't know how to use this SDK, you can actually go on there and find tons of sample codes that'll help you get started.

James Flores: Well, I think that's it for this episode of Meet Your Okta Identity Expert. Juhi, I want to thank you for being here, especially all the way from Toronto. And thanks for sharing your story with us.

Juhi Bagaria: Okay. Thank you for having me, James.

James Flores: And to everybody here listening. Thanks for listening. And Juhi, again, thank you for sharing your knowledge and experience. And I guess to summarize what we've learned today is Okta for customer identity has like a ton of unlimited use cases. When we're talking B2B space, B2C space, everything under the hood, everything accessible via API, everything extensible. We have hooks, we have the auth, the identity platform, we have the toolkit. All kinds of stuff out there.

James Flores: Second is federation. Federation is key to all these B2B connections. And it's changing. So if you're looking at setting something up with federation or building federation, be sure to reach out to our professional services because they're going to help you get on to the latest and greatest with OpenID Connect.

James Flores: And I guess finally, our Okta API. It's a powerful tool for migrating users and for all the backend stuff. To meet more of our Okta Identity Experts, be sure to visit okta.com/experts. We're going to continue to introduce you to new Okta Identity experts.