 Welcome to the Okta Workforce Identity Developer Podcast. This month I'm joined by Dan Marma, who's a Product Acceleration Principal Architect at Okta. Welcome, Dan. Thank you for having me out to the podcast. I'm looking forward to this. Yeah, and I've been looking forward to chatting with you about the work that you do. So for our listeners, what does a Product Acceleration Principal Architect do? In the title, obviously, we talk about taking products and making them roll out faster, cleaner, and really focused on a few different products right now. Myself, I'm focused on the Okta Identity Engine. We have a classic engine and we've made significant upgrades. And I'm working on making sure folks have a seamless transition to be able to adapt to the new technologies. But our team also works with a lot of new products and innovations and getting them out and up and running for customers. Yeah, so if I'm a developer who's trying to deploy workforce identity, I might work with somebody like you. Absolutely. Our focus is on the workforce identity side. However, there are significant folks that have some of our legacy platform or classic platform that needs to upgrade as well. But our primary focus is on making sure that everybody can get access. Yeah, and you gave a fantastic talk earlier this month at Dev Day 23 about the Enterprise MVP. And when we talk about developers, we're talking about a person who uses Okta's APIs and tools to manage their own work. But we're also talking about people who build the software that they provide to Okta customers, the software as a service that they sell to these enterprises. And so in your talk that Enterprise MVP, what is that MVP? Yeah, that was a great time to fly out to San Francisco as we all love to actually travel and get to meet people in real life again. But my key focus was around two main components. One was having internal continuity inside of your application. We all build applications and really building everything as futile. At the end of the day, you have your monolith in your application and you have other silos of everything from support to CRM to learning systems and whatnot. They need to integrate and have continuity as you move across so you can have a really nice application. So that was the first component that we really need to make sure you have that experience. You give the best experience. Plus it also gives your developers or yourselves that ability to focus on your application. You don't need to worry about the operational side of things. So you can use Best of Breed, you can use SaaS providers and cherry pick through the providers that are out there. The second piece of it was, was that an experience on being able to offer inbound federation or federation into your platform from the Enterprise? Because they've made heavy investments into the security architecture from identity and access management to having IDPs and maybe they have compliance and all types of requirements that are required for their business. And they've implemented and spent a lot of time and money on making it all work. And then if they turn around and your app only offers a user ID and password, it seems like more work for them to manage and more complexity and surface talk area at the end of the day. So really the two main things I spoke about were that continuity and that inbound federation becoming table stakes and making sure that you can address that enterprise. Absolutely. And if the enterprise has their own policies, whether it's their internal security team says we need this or whether it's external regulations that they are bound by because of the business that they do. If you don't offer appropriate security, they may just not be able to buy your app at all. Yeah, and it's I even use the example. There's been times when I've chosen an app or I've said, hey, we have a choice between a few apps. And then just had enough friction for me to not be able to log in or have to reset my password so often or I just moved on. And it seems very petty at the end of the day. But if you have that friction and you don't make it easy for your customers to get to it, that's at the end of the day how I say getting customers to love your application is get them in there and use the application, not try to figure out how to get to it. You're not going to get people there. Yeah, can you give an example of what the flow might look like for a new customer in an app that doesn't offer federation like this. You think about that, that if you don't offer that federation, you've been onboarded, you bring your brand new to the company. And you get handed about 1520 apps for you to get logged into between your email, your countering your. Hey, here's your Jira here's GitHub and all these these apps suddenly multiply. And then there's this other thing that everybody says hey this is the best at performing let's say it's a project management tool. And you get all of your, your, your stuff, your work orders, if you will, from that. And it's convoluted process to get you logged in for you to go about your business, you may not log into it all the time or needless to say, or is you just have that friction that that really makes it a pain, and you're not going to go and update you're not going to keep it current you're not going to use that into your daily tasks because it's just, it's pain, a huge pain point. And then you don't log into it maybe freak that frequently. You don't remember what your password was, you know, I, is it my first born. My second born was at a new pet, you know what I have to change my password so often and then you have to call help desk. It's, it really drives it drives you away from just getting in there and doing things, especially if you I needed to post something or do do something critical and now I forgot what it was because I just spent the last half hour trying to figure out what I had to get in there. It doesn't make any sense. It's a terrible experience for the user. If the company even buys those apps. Can you speak to what it looks for from the side of a company who's deciding whether or not they even want to purchase the software as a service at all. If it doesn't offer good federation. Yeah, one of my coworkers John actually spoke in detail about this, the buying patterns for him for how he surveys applications for octa, we'll call octa on octa for octa. Right. And in any case he he sits there and he'll make that that assessment I've heard it other times before and outside organizations even at our octane event where customers and administrators inside of the business technology team will only purchase products that they see that have a attract for integration because it becomes seamless it becomes almost mindless to getting folks into the system. They just need to add you to a group on application icon gets added to your dashboard and the way they go. They don't need to sit here and and pull out the instruction manual and try to figure out how the integration works. And it also just kind of gives a great. Partnership sign to your customer base that if you have this freely available. You know they know you're going to let people in and access your stuff you're not going to sit here and and nickel and dime them for all these little things. Oh, you wanted to have the windows on your house. You want to have your doors on your house. Yeah, we needed those. You know, think of it as a door to the to the business to that application making it freely and easy. So from a technical perspective, what standards is somebody going to be looking at when they're looking at implementing these federation capabilities. Well, if you haven't done it already 100% look at the OADC. And it is by far the easiest one to implement. We have lots of documentation on our site, but even on the internet on how to implement that. It's a very seamless approach and it's very consistent, especially when you're going from a web app. Maybe you're going to a mobile or native app. It can supply you with the right tools to be able to accommodate all those those experiences. And they also heard of the legacy SAML approach SAML right in that that approaches is been around for decades. It's very effective. However, there's a lot more involved with getting the implementation. So if you're starting today, 100% go go down the OADC path. You may hear also there's a SAML assertion that comes through and that's really like a header based approach where you get the all the information about the user inside the header, but now there's certificates and different endpoints that you need to support. And it's a little bit more complex to start especially since most of the the software packages have on the OADC package already sitting there waiting for you. Yeah, so if you're working Greenfield, you want to start with OADC. But if you're working on something legacy that's already using SAML, you're pretty okay to stick with it for now. Right. Yeah, I wouldn't say hey, let's go eradicate SAML from from the industry. But if you do have a cycle, it will simplify your life because now you have a much more consistent approach across all of your different applications. And maybe you. Centering into your application. It can also be used for authenticating against APIs. It could use from machine to machine. It, it's very versatile and it's a great evolution to the industry. Yeah. And so when you're selling to enterprises like this, one of the things that you're doing to make it really easy for someone to test out your application is offering it on an identity providers marketplace. And there's a bunch of these. Will OADC only get you into octas or will it get you into other places as well? It gets into all of them. Right. Obviously, if your, your customer has a great make some great buying decisions, they may use octa as their framework. But they can also use Microsoft. There's just systems or legacy companies that have Oracle. And other providers that are out there that they may have this stuff laying around. You know, because that's the, the fabric that's been moving into their company over the years. But using an approach of the OADC or using that Federation model, you should be able to get into virtually any of them. Yeah. And one thing that if you happen to be selling to customers who are already on octa, that you can let them build on top of your app with is octa workflows. Could you speak to what you have to do to support these workflows? What they gain for your customer? Absolutely. Let's worry that that follow on after the MVP, you know, taking to that next level. We did have some Aaron, our own Aaron Pricky actually got to speak, speak to that. And there's a, there's a few different components that think about externalizing some APIs to doing your common tasks, everyday tasks, maybe even beyond creating users, creating groups, updating users, removing them as they move along. There's standards for that. We can talk about the, the skim or, you know, the system for cross domain identity management. Again, we have some great documentation on that. And then there's other APIs that you may make available that are very specific to your daily duties as a, as a provider to be created. Let's say if it's creating different groups or work orders or onboarding customers or profiles or what, what have you, you know, the world is your oyster and what, what your application does, but providing those, those APIs and those, those functions that need to occur on a regular basis, you can expose them as APIs and those APIs can be triggered by workflows. What workflows is, is a no code or drag and drop type technology that we use that would bring your, your application not only into an SSO, but having some of those, those flows onboarding tasks that may need to happen. For example, I, I, I am bored Emily, I'm bored you today as a new hire. Not only do I need to, to say, hey, here's your email address and we're doing that Federation. Maybe there, there's an approval process for governance. Like I, you're a part of our developer team. You need to have access to, to GitHub and our access to GitHub is bound by you taking some compliance software, making sure that you're doing all this other stuff. And we can trigger that workflow to make sure that you, you onboard and you get the appropriate accreditation back, not even background checks, but more of that. Hey, did you take the training? Did you, did you follow the, the rules and fill out this form and all that stuff can be triggered on the back end, making it very seamless to you as, as that new, new resource to our pool. It's a great foundation. And from the developer perspective by exposing these workflow APIs, you can sort of sidestep a lot of really custom feature requests that if there's this one off thing that this one customer wants to do with your tool, suddenly you can say, here's how you can do that yourself. Instead of, oh no, now I have to build this thing that only one word will ever use. Absolutely. And that is, I almost put workflows into the utility bill of putty. Right. Where, like, like you said, you can make a flow that's isolated to a particular group user use case. And then you can, if you ever do need to reuse it, it's great. You've, you pull out, make a copy and pull it into, into, into a view. And then you don't have to manage the infrastructure for it either. We, we manage the workflow environment and it's, it's a great add on. Also, we have that workflow builder that you could create, you know, more consistent tiles, if you will, that you can reuse instead of just having a sub, sub functions. It's a very, very powerful platform for being able to move some, these one off custom codes or these very lightweight things that revolve around that friction, if you will. Yeah. So that's really advanced. That's kind of late in the journey as you're getting standards compliant, you're really making it easy for customers to use the tool that you provide and really enjoy it and potentially even get really locked into it. Go, no, the hassle of switching to something else that has less features that I can do less with would not be worth it. But early on in the journey, are there common reasons that you see places saying, oh, we don't, we don't really need to do standards compatibility. We should do this custom. We should build this in house instead. Absolutely. You look at that cost perspective, hey, I can build a user ID and password. I think it's one of the first things we do as a new developer, like you, yeah, you make the hello world and the next thing you know, you need to make sure that only certain people can get to hello world. So enter in a password, you know, enter some sort of identifier, are you allowed to do this and you bounce it off a database. And that gets you pretty far. I mean, you know, but then then these, there's these people that will put them bad guys are going to come along and they're going to overrun your system. They're going to try to do a bit more and maybe they use your password service, you know, user ID and password as a service to vet out passwords or they also can knock you down from a denial of service. Or you realize that people from outside of your customer zone, you know, you only have a certain region that you've sold to and next, you know, maybe overseas or some parts of the world that you want to start blocking out. And you start to think about that telemetry that you need to build and you start to build it out and all this stuff. And then another app comes along and you got to build it out again or it just becomes a force multiplier. And in that evolution, you start to realize, wait a second, if I can outsource that that sign in, I can push it off to somebody else that has that telemetry built in. It becomes policy. I can just say, hey, I only want folks in on the East Coast to access this application, whatever, for whatever reason, or you know, you only want folks that are in, you know, England or Canada because it's a Canadian app or, you know, you don't have to sit here and build all that logic into it. Then, you know, the marketing team comes along and says, oh, by the way, we heard people don't like passwords. They forget them. They want to use something that's passed with us. And again, you need to go and figure all this stuff out. So what the idea here is, if you can advocate for that externalizing that session or announcing, hey, I know this is going to come. This is where the industry is going. We're going to need to have this telemetry and we need to be able to add policies. We want to lower the friction on the users if they're logging into the same device again and again. Hey, why do we have to make it? Let's have a longer session. You know, maybe it's a new device. We challenge them for passwords. So we can start to make that really enhance that experience. Getting ahead of that with an identity provider gives you that, affords you that framework that you don't have to build. You build your app. That's what you're here to build. You're not here to build logins. You're not here to build telemetry. You're not here to build infrastructure and operational things. You're here to build your app that does these great things. Yeah. It really reminds me of the parallels of the shift from on-prem servers to cloud where why would you have a branch of your company focused entirely on running your servers for most organizations most of the time? What's in a blue moon? There will be a time where it actually does make sense to own a physical server in a rack instead of rent it from someone else. Are there similar times where it might make sense to DIY all or part of your identity solution? Those weird edge cases? Well, those weird edge cases are the reasons for it. So because you have that legacy system that's on-prem, right? You have this server that you, you know, somebody's got the arms around and they don't want it to be cut down. Usually it's a compliance reason. Usually it's an access. You don't want to pay the premium for that level of FedRAMP infrastructure because you already made the investment into your data center. So it does make sense to have it in those scenarios. But even then, having that identity provider provide you that front door, the Federation member talked about OADC and OAuth, you can still make those connections to those systems. You just need, instead of having to build a custom framework, federate with it. All the way down to the command line, you can have these people accessing the right things. Yeah, and when you do this through a product that's actually someone's full-time job instead of your side hustle trying to put out the fires in your homegrown solution, then you suddenly start getting all these neat features like auditability and telemetry that you were talking about. Absolutely, that is 100% the evolution, right? You started off, we had an app, we had 50 users, we had a user ID and password. That was great. We built it out to thousands, hundreds of thousands of users. And then the other competitors are doing the same thing and makes you know people are using your service as a test bed and your wheels are starting to fall off the metaphorical bus. Whereas you can push that front door to the walls of your identity provider. At that point, they will take the brunt of the attacks. There's people that are sitting there 24-7 waiting for the market to change and to make the appropriate adjustments. So one other thing I'd like to chat with you about is you have this really unique perspective into these customer stories. Could you tell me about some of the more extreme uses of workforce identity that you've seen out in the field? Basically, open up indoors box. What's extreme to me at this point is there's not much I haven't seen already. Everything from military submarines where identity needs to be brought into their environments and then they drop down for a month or two and they come back up. So they're completely disconnected to the identity where the company not only builds their infrastructure for their medical services as far as making sure all the patients have the connectivity for their EMRs. But also down to they built their own apps to manage the MRs that can be rolled around to the bedsides. And how do we make sure that those applications have the right level of access to the right person? And by doing so they have either smart cards around their neck or they have a biometric on their body or they have their phone being able to offer that type of service down to this offline application that can do some validation. But those are the really not hard to believe, but they're harder to implement strategies. So for the first example, we have a system that's going to essentially be air-gapped and offline for several months and people need to do their jobs while they're offline and then it comes back and needs to sync with the world. What's the architecture of the solution to that for identity going to be shaped like? I probably shouldn't have mentioned that one because it incorporates a little bit of everything as far as while you're online and connect to the centralized identity provider it needs to be able to connect and verify that everything's there. So we have all the services that will synchronize the directories down to those systems. And then while one disconnected, we have a gateway that sits there and then uses basically an offline directory that would now fail over to, you know, becomes a primary at that point. So during the duration, you know, you're offline, you're not going to be let go in the middle of the ocean, you know, a few hundred feet underwater, it's going to be hard to let you go there. So you don't have to worry about that. And when you resurface and you come back to port, it would synchronize, hey, this is, you know, password's changed. You know, a lot of times it's a lot of training, you know, while you're looking for things to do, you can play cards or learn more. And at that point, they get access and they've grown as an individual and they come back and everything will come back online. That one was a fun expedition. There's all the variations of that one as well. I can't get into, but in any case. I mean, I'm imagining applications in, for instance, space exploration, you're going to be putting folks on a ship and having a really long delay for any comms. So that that kind of architecture would probably come in handy for similar cases of that situation. And then if you were architecting something like that where you needed to handle permission changes while it was offline, would that replica then just be able to take updates from people with a sufficient level of terms and then sync those updates when they got back to connectivity? Yeah, that would be the whole premise of that. Of those orchestrations, they would be queued up to make sure they sync back up to the metaphorical mothership of the identity provider in the infrastructure. But we, in those cases, we do have appropriately matched sessions. We have the appropriately matched directories that will come down. And even like our access gateway would be able to handle some of those legacy applications. A lot of those applications that are offline are, let's just not say they're not all bound to the internet. There's also physical systems where you might need to be air gapped for some reason and yet still manage identity on it. And I take it's going to be roughly the same set of considerations for getting your updates. Absolutely. One of the interesting parts to our solution at Akta is we can consume and just use a directory service like an LDAP or an active directory. But we can also push things down into them and being able to bridge that without having to have that same level of VPN and two-way trusts and stuff. We can essentially become the catalyst for synchronizing over into those just isolated environments. Yeah. Obviously, that's what you would normally develop. You can develop those things, but why when it can become a configuration? For sure. And if you're providing an app to a customer that's in one of those really unique situations, why not offload the worst of the identity problem onto another provider? Absolutely. We deal with it day in and day out, literally far as Australia to all ends of the earth on trying to help folks get through those interesting situations. Yeah. And then for the medical scenario, when we have portable terminals and people circulating around and lots of people each needing to do very secure off because it's very private information that's stored here and possibly for some but not all medical devices, it could be life threatening if actions aren't taken in a really timely manner. What's the architecture for solving that shaped like? It actually aligns with the OADC spec, but they actually have an extension to it that has a smart on fire component. So you can, it gets down to the individual accessing the individual records. So think of the one of the old hospital rules where we had multiple beds and then there's two different doctors for that. They can look at the chart for the bed on the left and that doctor has access to that record. If they go over to the bed on the right, they can't get in or see anything because that doesn't apply to them. Same thing for the nursing and all the other staff from food and food services and such. So there's a spec that's designed that's an extension to that OADC spec. So again, hint, hint, if you were using OAuth, it's not a big jump to start using that framework to get to those other systems. Yeah, and then you have the tech with, let's say, an x-ray that comes into the room and needs to upload those files to the right patients record. So having it done to a spec that's been tested where you can test your software is going to be a huge win. Absolutely. And it's going to afford your scalability at the end of the day. You're not going to have to say, I have a custom way to upload these records and custom way to get access to it and isolate it to the right people. This stuff has been laid down. Let's leverage those frameworks. Yeah, and speaking of scale, what's the biggest scale that you've seen identity solutions pushed to? Billions, billions of users. So we have a high volume, we have customers that quite literally have very cyclical access to certain points of the year and they can actually point down to the hours and minutes that are large scale. And you're going to see influxes of hundreds to hundreds of thousands of users a minute accessing the system. And then other parts of time that you're that same customer may be down to just to the thousands, right, depending on what it is. And it goes on with various things from sporting events to times that you're shopping. There's even got to learn a lot about different cultures on the hiring and firing procedures where folks are on boarded and off boarded at exponential rates very, very quickly. And our systems are designed to handle that, you know, making sure that you're on boarded and off boarded really fast. It's like culturally assuming, oh, well, I just have a given job. I'll just take a holiday and then come back to the same job isn't necessarily an assumption that applies worldwide, is it? No, absolutely not. And we've grown over the years to learn those patterns and your application may be one of those target applications that we're helping get the right people to over time. Make sure that you align with the standards and then you can be part of that mix. And these aren't small organizations. We're talking hundreds of thousands of people that are on board and off boarded in a matter of days. So if your system is already designed to work with that federation model, it could be another component to solving those problems. Yeah, for sure. And so if I'm selling an app to some organization that's doing this super bulk onboarding and off boarding, even if that organization is already using an identity provider to handle the worst of it. What concerns should I have on the app back end to make sure that it can stand up to syncing this kind of bulk sudden identity data change? Well, part of that spec can either be handled to two ways, right? You can do a just in time provisioning. So as the users get granted access to the application, instead of you trying to synchronize in the background, you know, 10,000 or 100,000 users, it could be as they come to the front door. It's not a situation where 10,000 users log in simultaneously if they get added to your system. So maybe a just in time provisioning model may work for you. So if there is something that needs to be done where you need that back end process, part of that skim interface will essentially churn on that data. It may take a little bit of time, but you would know that somebody is going to start work in a few hours or a day or something. It's not like they show up for the job and start going. That's where the just in time comes in. I do have the hybrid approach that which I find very effective is being able to supply that just in time that that federation model and or an API model in addition to the skim. The idea here is you would get that immediate access straight away, right? You need to get in there. I think of a quick service type scenario. You get hired in the morning to hand you a t-shirt. You need to go walk into the back room and take the training. For sure, somebody needs to enter in your data just for you to log in. Yeah, you need to have enough of an account that we know, yeah, you took the training. Yeah, this person took the training. Now there's a follow up to the next day. Maybe there's some additional information we needed. Maybe the mailing address to make sure we knew where to send your paycheck to because the first check is going to come in the mail. Things like that doesn't necessarily mean for need for the day to day identity piece. But from a compliance standpoint, you need to know, hey, this person is part of this county. They need this. What have you? There's some rules and regulations about things that they need to be put into play. That process that runs in the background will update and persist that information. So now when the HR record comes along, it'll pick up, hey, I'm only started this morning. She took her training. She got her t-shirt. She's watching the folks do the work. The next day, you're going to see the rest of your profile kick in because you are a full-time employee. You have these benefits. You can go and log in and get your discounts. All those other things come along for the ride later. We don't want to add that friction at the beginning to get you going, but we want to make sure the long haul, all the data is there so you get your full package. Yeah, it's kind of a sequential stepped onboarding where you do the pieces as they're needed and break up the work that way. Yeah, absolutely. And having the identity and access management framework in place with the workflows, with the ties into the HR systems, the ties into the directories and all that, you don't need to build those. One of my favorite solutions was one where the business analyst was able to create the dashboards. Hey, here's the information. And then there's other dynamics database where all this information was held. They also used Salesforce Canvas as the framework as our customers that provided these dashboards to our customers. So the analyst was able to create these beautiful charts inside of Azure, said from Dynamics, presented through Salesforce. And Akka was able to, because, you know, if it was on a legacy monolith system, they would all have to talk to each other. But because Akka was federating with those different cloud providers, we just provided, hey, this user is coming into this report with this context, and it's presented it. So it was literally an iframe of different services, completely segmented and had no idea that each other existed. But because we were able to federate them in, they had complete interoperability across platforms, across platforms. Because when everything's integrated with a single identity provider, you can then go through that identity provider and treat the whole system like one system, instead of like a whole bunch of little parts that need to be glued together because the glue is already there. Yes, exactly. That federation and that standard will pull it all into one purview. Man, I can only imagine the value add that would be perceived by having the right graphs across an entire infrastructure. Like, here's the insight that you were looking for, boss. Absolutely. And the best part is, management is going to change our mind on our platform. We're going to evolve. We're going to start off with a homegrown learning system portal. It may move on to an open source. It may become a commercial based. Then you decide to get a better price at the next place. Instead of you trying to integrate each one of those into your platform, you can just change the federation direction. Oh, yeah. Tell me about it. I've had roles where the first half of my time there was, oh, no, we need to get off of platform A and on to platform B. And the second half was, whoopsie daisy, we need to get off of platform B and on to platform A. And I mean, there's good reasons in each direction, but which reasons are at the top will change constantly. So it's always that change. Yeah. And again, you want to get back to making a delightful user experience and you want to focus on adding value to your customers, not sitting here and necessarily tying all these systems together. By tying them together, you federate. They know they have access to that system. It is so cool when we can build on the bare bones of we need to be more secure. We need people to not get their accounts compromised and turn that into, hey, you can be more secure and have an improved experience. Yeah. Yes, especially across completely disparate platforms. Yeah. And so thank you so much for your time today. Looking ahead, just to wrap up, are there any upcoming changes in the security and identity space that you think will really surprise or strongly impact the developers that you work with? Really not a jolting change to the infrastructure. I think it's more of the expansion of more services and partnerships that you can bring together and making sure that you start to leverage those best-of-breed partners. Being able to leverage the different systems so you can make a holistic change. I'm assuming the overall direction is moving away from passwords. I'll make that one as an assumption that we're already leaning away from these things we know and move on to the things that we, who we are and how to make sure we identify it properly. I think that would probably be the brace for the impact of the change in the way people authenticate, but the frameworks and infrastructures and all that stuff. I don't think that's going to change other than what we already see going to cloud, going to those SaaS services. Yeah, for sure. I personally think that there will always be a place for some no factor to make sure that, because getting physical possession of a piece of hardware is simple enough and a no factor signifies intent to take the action in a way that an R factor might not, but definitely reducing that single-minded reliance on a no factor is just huge for humans using computers. Yeah, for sure. That definitely would be the pattern. Thank you so much for joining me. It's been delightful to chat with you. This is great. Thank you for having me. I love this. I look forward to having some more over as we see some of these future technologies unwind. And for the listeners, we'll have a comment thread on the Developer Forum if you'd like to discuss the podcast or share ideas on what you'd like to hear about in the future. And if you'd like to learn about any of these technologies that we've been chatting about, I'll provide links so that you can dive more deeply into them. So thank you for listening.