Authorization at Workday

Damian Schenkelman: Welcome to Authorization in Software, the podcast that explores everything you need to know about authorization. I'm your host, Damian Schenkelman. Each episode we'll dive deep into authorization with industry experts as I share their experiences and insights with you. If you're a software developer or just someone that's interested in the world of authorization in software in general, you are in the right place. Let's get started. My name is Damian Schenkelman, and today I'm chatting about how Workday approaches authorization with Jennifer Wong, director of product management at Workday. Hey, Jennifer. It's great to have you here.

Jennifer Wong: Thank you. I'm so excited to be part of this.

Damian Schenkelman: To get started, could you give our listeners a brief overview of your background?

Jennifer Wong: Sure. I've been with Workday for 10 years. Over the years, I've been leading product management across different platform solutions across Workday from business processes, organization hierarchies, and most recently security. What do I mean by platform solutions? Well, as Workday continues to grow and build new products and features, all these new products and features are built upon a common platform reusing the same organization framework, the same business process framework, the same security framework, et cetera. This allows our Workday customers to utilize a single org structure, the same set of security groups, et cetera, to customize for the new products to their needs, which reduces their time to value creation and realization. With that background, I lead product management for application security with reusability in mind. We do not offer point solutions for our application. Workday offer applications and technology that work together to accelerate interoperability and business agility.

Damian Schenkelman: That makes sense. We've had a few folks working on this platform, reusable component teams, both from an infrastructure and a security perspective on the podcast talking about how they help their companies with authorization. Let's start with the business. Why is authorization important at Workday, and what happens if it's not working properly?

Jennifer Wong: Workday stores the most important corporate data for some of the world's largest companies. This includes sensitive personal information about their former and current employees, contractors, applicants, et cetera. Additionally, Workday also stores financial information related to the company's past, current, and projected financial performance. Therefore, Workday operates with zero tolerance for stale security evaluation. If authentication authorization is not working probably in Workday, we are at risk of customer data being compromised.

Damian Schenkelman: Yeah. I guess from what you're saying, you're storing a lot of very sensitive, important data. I also know that Workday has multiple products for financial management, human capital management, HCM, Adaptive Planning. From what I've seen as a user, from what I've seen from the product, it's a very large surface area feature and use case wise. How does authorization work across these different products? Is it centralized logic? Is it per product? Is it per feature?

Jennifer Wong: Yeah. As you mentioned, Workday offers a wide suite of solutions across HCM and finance, from the flagship application to many add- on SKUs. In recent years, Workday has grown through acquisition such as what you just mentioned, Adaptive Planning, Peakon, VNDLY, et cetera, to provide solutions that complement Workday's application. Now, when Workday evaluates each application for acquisitions, one of our key criteria is to ensure that these application meets Workday security standards. This is because Workday upholds an industry- leading standard of security that has successfully earned our customers' trust over the years. We want to ensure that level of security governance and oversight is consistently maintained across our current and newly acquired application. So depending on the application use cases and the authorization requirement for that, these application then continue to utilize the original security model under the same rigorous security governance and oversight as all the Workday offerings. And we will continue to invest in our authorization capabilities across all our applications.

Damian Schenkelman: It seems that, as you're saying, there are things that Workday developed their acquisitions. I wonder how much of the evolution of these authorization capabilities was organic versus more maybe intentional planning?

Jennifer Wong: Yeah, so our intention is always the same, which is to keep customer data secure. But as the company has evolved, our product and offerings have evolved as well. The threat to the customer data has also evolved so that our approach will also be evolving as well. Right now, we are focused on building additional security products and functionalities to facilitate security authorization between Workday suite of products.

Damian Schenkelman: What are the pros and cons of that approach of having these different products and evolving them over time, and also having them use different logic depending on the application use cases?

Jennifer Wong: Yeah, the key advantage is that we can always ensure customers' data is secure. This is because, as I mentioned, when we evaluate these acquisitions, we're already assessing them with our standards. We also maintain the consistent standards that Workday upholds after they join the Workday family. In doing so, the customers continue to trust Workday and to store their most sensitive data, and extend that trust they have with Workday to all our Workday applications. So that's the most key advantage. Now in addition to that, we also leveraged the fact that Workday applications and other applied applications are under the same company. So actually we can collaborate much closer to enhance our joint customer security and experiences. For example, every week I meet with several of my counterparts in Adaptive, Peakon, et cetera to explore and roadmap joint opportunities. One I can share is last year we delivered a just- in- time provisioning feature to support single sign- on for our joint customers who bought both Workday strategic sourcing, previously known as Scout, and Workday. So there are many opportunities by leveraging what we can do together in representing Workday and the Workday acquired acquisitions. Now on the other hand, we also understand that every application may have its unique security requirements. For example, granular accessibility is required for Adaptive Planning reports down to role level. So we acknowledge that there are no cookie- cutter approach, and so we collaborate closely with our acquired application team to adapt and adjust.

Damian Schenkelman: Yeah, that makes sense. It goes back I think to some of what you're saying about what you do with each of these applications and whether you end up centralizing or not depends on the use cases. So for example, again, granular accessibility is required for Adaptive Planning, maybe not for these other products. And that likely requires very different technology and a different approach. And ultimately what I heard a couple of times, it seems this is about trust, right? Authorization and trust go hand in hand.

Jennifer Wong: Definitely.

Damian Schenkelman: I want to get a bit into how the users and user roles and permissions work at Workday and where authorizations decision happen.

Jennifer Wong: Sure. Well, first and foremost, Workday follows Core Zero Trust principle in all our authorization decisions, but explicitly verify the users for every single transactions and actions. Therefore, enforcing the least inaudible Now, the system checks to see what the data elements the user is attempting to access and for whom, and then checks to see if the user has a security permission to access the requested data. So the basis of the evaluation relies upon three key things: the security domain, the security group, and the security policy. Now let me dive into each of them a little bit. The security domain is a grouping of data elements and tasks collectively known as security items. If you know Workday well, it's more about the reports and tasks you see, like request PTO or view my payroll check, et cetera. Security groups are the groupings of the users based on their roles, jobs, or attributes. We provide both standard out- of- the- box security groups and customer configurable security groups. Both of them can be applied with contextual security. And finally, security policy. For each security domain where we group all those data elements and tasks, each domain have of the policy, and the policy dictates which security group can perform what actions view or modify.

Damian Schenkelman: Yeah, that makes sense. You mentioned Zero Trust, which is I think becoming a hotter topic every year. I'm hearing that term more and more in the podcast as we talk to folks. I'd like to dig a bit deeper into some of these things. And maybe again, you mentioned if you know Workday. But if I don't know Workday? Who manages these security domains and groups and what their expertise needs to be? How do they maintain it? Are these policies or rules code? Are they UI based? How does this work?

Jennifer Wong: Sure. So Workday customers have security administrators who configure and maintain Workday authorization settings for all their tenants, including the security groups and the security policies. And one thing I'm really proud of is that the Workday provides this easy- to- use UI interface for these security administrators to set things up. We do not need them to write code, and so very intuitive UI experience for them. We also provide rigorous approvals and auditing capabilities to ensure the security setup is meeting expectations.

Damian Schenkelman: And we talked about this a bit earlier when we gave that example of granular low level access, but more general how coarse grain are these roles and provisions? More importantly, how do you make provisions around this granularity? For example, is it because customers require more or less of it? Is it a trade- off between simplicity and clarity or maybe less granular approaches versus the flexibility of fine grain authorization?

Jennifer Wong: Yeah, we actually at Workday offer a range of options from out- of- the- box customer configurable groups to Workday delivered groups. I can touch upon each of them. So out- of- the- box, we offer roles via the customer configurable security groups, which can be based on the users, the roles, the job's organization, many other things. They can be combined into new security groups that logically include or exclude other groups as well. And so combined with the predefined policies, they can grant or restrict user access. Customers can tailor these groups and policies to meet their needs, providing as fine grain access as they require to support any complex configurations they have. Now, over time customers are requesting more and more granular security controls, and they need more constrained access to certain tasks. And so to address that, in the past years we have enhanced our security groups to provide a rule- based security concept. And this security group, we allow customers to further constrain the members based on the baseline security group using condition rules. Let me illustrate it with an example so it's easier to understand. We've heard use cases where customer want to only enable part- time workers to track their work hours in Workday. So Workday already has a Workday delivered security group, we call it all users, and this security group can be used as a baseline for this rule- based security group. Now the next thing customers do is to define a security rule to say, how do you define what's a part- time worker? Well, in Workday we have these fields like time type, et cetera, to help you identify these part- time workers. So you can create a security rule that narrows down only to the part- time workers. Then you can apply this security rule to the inclusion criteria of the rule- based security groups with all user security group as basis. So this means that we grab all the users and then apply this rule so only it returns the part- time work is there. And then by adding this new rule- based security group we just created to the time tracking domain, which secures the work hours, you can then enable only part- time workers to track the work hours. Now, Workday also provides security group that automatically updated based on the business process such as hire and end contract. We have these Workday delivered groups to be used alone or in combination of other Workday delivered or custom created security groups to determine access via security policies. So you can see that we offer area of choices based on how fine grain that the customers need, to something out of the box or something where you can apply more finer rules to narrow down the scope and access.

Damian Schenkelman: Yeah. Okay. Let me see if I understood. So again, you have the premade groups, like all users, maybe you have a few other things that you know customers use a lot. But you can essentially create a new group and say, for example, who is a member of this new security group? So you take all of the users and then you say, for each of these users, check their, in this case, time type attribute. And if the time type attribute is something like part- time, then they will essentially become a member of that security group. And from that point onwards, that customer can start using the part- time security group in their authorization logic. Is that how it works?

Jennifer Wong: Yes, that's our rule- based security group.

Damian Schenkelman: Okay. How are these kind of security groups handled?

Jennifer Wong: Yeah, so at Workday we have a lot of different kinds of security groups. They all are based on core things like the users, the roles, the job, and as you point we talked about in the previous example, even attributes like time type right? Now, the most common one that we see used is a role- based security group. Now, role- based security group is tied to roles that you create and assign to members of your organization. For example, a manager security group will be tied to the manager role for supervisory organizations. Now, why is role- based security group so popular? Because it maintains a rigorous security automatically when people change roles in the organization, which happens very constantly, and it's a major pain point for security admins. For any mover, joiners, leavers, you have to edit all their security. It's a pain. So the distinct design for Workday assignable role concept is that the role is tied to a position, not the user. This means that when the user leaves the manager role for the organization, the user immediately loses the manager security group membership. And when a new person takes over the position, he or she automatically inherits the manager role and subsequently the manager's security role membership. And so this removes the need for manually assigning roles and security groups for joiners, movers, leavers.

Damian Schenkelman: Okay, there we goes. I was, again, you mentioned that there are lots of ways in which people can become members of security groups, and now we're the valuing the notion of role. But it seems like, I'm going to use a word, maybe it's not the word that you folks use, but dynamism is a big part of it, right? So rather than saying the user is assigned to a role in reality, a role exists, in this case the manager role. And then all users that happen to have an attribute, that in this case might be the manager, are assigned to it. That dynamism simplifies a lot of the management for folks that essentially have to manage the Workday account.

Jennifer Wong: Exactly. And so this is why role- based security group is so commonly used within our Workday customers.

Damian Schenkelman: Okay. Yeah, that makes sense. It seems intentional considering, again, the complexity of the domain and how roles changing and people moving and changing teams would make things simpler for an admin. I want to switch topics a bit and maybe dig deep into a concrete example. We use Workday at Okta. So let's say we pick a feature like employee compensation. How does Workday handle authorization for that case? For example, how does Workday feed out who can view my comp information in the system?

Jennifer Wong: Yeah, so in Workday, security evaluation that done at the time the transaction is executed. So say your HR partner logs into Workday and searches for you and click onto your worker profile page. Now if you remember that profile page, you see a photo up there. On the left- hand side, the blue part, you can see there's a lot of tabs, like your job, personal information, compensation. Actually, when we load that whole page up, we are already evaluating the person's security to determine which tab you have access to and to only show the tab that you do have access for. So in this case, going back to the HR partner, when the HR partner clicks and view your worker profile, we look for the security domain that secures the compensation tab and then look into the security policy for that domain. Within the policy, we can see which security groups have the view access. We determine whether the HR partner is a member of any of those authorized security groups. If he or she is, we will load the compensation tab. And if not, he or she will not see the compensation tab at all. That's how it works.

Damian Schenkelman: Okay, okay. So in this case, again, the HR partner would need to be a member of one of the security groups that has been granted, let's say, read or view access to the compensation. And that's essentially like a dynamic check that happens at runtime each time the user wants to access this information. I know it's sensitive and where the big public companies, or as much as you can share, can you give us a high- level overview of the internal components and technologies that help with these authorization decisions?

Jennifer Wong: Sure. A high- level Workday authorization architecture is in alignment with the Workday architecture and leverages our native programming language called Xpresso, and REST APIs, caching techniques where applicable. Other algorithms are used for efficient evaluation. We also use advanced techniques such as dynamic prioritization caching to make the authorization process more relevant and efficient.

Damian Schenkelman: Can you give us an idea of the scale that the system manages, like the number of objects or documents, the number of authorization decisions a minute or a second? What's that like?

Jennifer Wong: You want to guess?

Damian Schenkelman: I have no idea. I don't know if I have the notion of how big this might be. It probably like hundreds of millions or something like that.

Jennifer Wong: Well, much more. Approximately just in fiscal year 2023, around 629 billion transactions were processed in Workday. So with all these transactions, every single of them requires multiple security evaluations on who can do what for whom or what. So you can imagine the scale of our authorization framework supports. It's in the order of millions per hour.

Damian Schenkelman: That's huge. And probably as you were saying, the system that handles this needs to be able to manage that scale every day consistently, right? That's very good. Where are these authorization decision made? And we typically ask guests about this because exactly what we were discussing before, right? Performance and scale characteristics typically require handling large amounts of data, and that data has to essentially be put together to make these authorization decisions in policy or an agent or software. So what data do you folks use, and what's the performance like here?

Jennifer Wong: Yeah, I think it described very well the performance is a concern, especially with the amount of data and the number of transactions we have. Well, the good thing is that with Workday is that for all the customers who uses inaudible CM, Workday is usually the source of truth, all the data that you need for authorization. So we have the five key things that we have. The user, so that we know the identity, the job, the position, everything about the user because the customer uses work, the HCM. We know the organization, the organization and hierarchy structures that controls the level of access. And the roles. We talk a lot about the roles earlier, that the roles are groupings of people with specific permissions and responsibilities. They're tied to positions, which eases the maintenance for the joiners, movers, leavers. All these roles are tied to security groups. We also have all the resources. All the Workday task and reports are part of also housed in the same as all of these users, orgs and roles. And finally, so is the policy, the security domain and security policies that secures the resources. So with all of these natively maintained system of record all inside the house, our authorization decision doesn't need to go far anywhere but within Workday ourselves. And this is the core advantage why Workday can thrive on providing real- time security evaluation.

Damian Schenkelman: And switching gears a bit, I know Workday integrates with lots of other apps inaudible apps. How does a typical third- party app use Workday? How does that integration work from an authorization perspective?

Jennifer Wong: Sure. So for customers who use Workday HCM, Workday is usually the source of truth, as I said, for the data that you need for authorization, like the user information, the organization. Therefore, Workday provides the API for downstream applications to timely update this data.

Damian Schenkelman: I see. And I understand also Workday does not do emit tokens to grant apps like permissions to access resources on behalf of users. So how will do these integrations across apps work from an authorization perspective?

Jennifer Wong: Sure. So Workday uses a propriety object- oriented, role- based security access control model, or RBAC, that provides enormous customization and control for the end users on how they provision users, teams, and functional organizations. Then the customers or implementers can translate from our user roles to security tokens and scopes for various B2E use cases. These are custom integrations. Any data sharing between Workday and external apps have to be explicitly implemented using these integration tools, connectors, et cetera.

Damian Schenkelman: Makes sense. So the concepts that we talked about earlier, like the policies and the roles and the security groups, you have this kind of proprietary machinery that allows these apps to integrate and essentially talk the word, their lingo, so that they can interact with the API and make requests?

Jennifer Wong: Yes.

Damian Schenkelman: Okay. That's awesome. Thanks for explaining that. So we're at the end of the show. I really appreciate your time and sharing all of these insights. Workday is a very interesting case. I really wanted to talk to you since we started recording the season because of the complexity, the size, that the M& A challenges. I think hopefully you also think that we've done a good job covering those.

Jennifer Wong: Definitely. Really, thank you for your interest and invitation to this. I hope I was able to answer those top questions that you have in mind, and looking forward to more conversations going forward.

Damian Schenkelman: Yeah, yeah. I think listeners will really like this episode as it helps put some things into perspective.

Jennifer Wong: Awesome, really appreciate it. Thank you so much.

Damian Schenkelman: That's it for today's episode of Authorization and Software. Thanks for tuning in and listening to us. If you enjoy the show, be sure to subscribe to the podcast on your preferred platform so you'll never miss an episode. And if you have any feedback or suggestions for future episodes, feel free to reach out to us on social media. We love hearing from our listeners. Keep building secure software, and we'll get you on the next episode of Authorization and Software.