Page
1
(This page has no text content)
Page
2
MEAP Edition Manning Early Access Program Dynamic Authorization Adaptive access control Version 4 Copyright 2026 Manning Publications For more information on this and other Manning titles go to manning.com. © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
3
welcome Thank you for purchasing the MEAP edition of Dynamic Authorization. I’m excited to share this journey with you as we explore one of the most important and fastest growing areas in digital identity. This book is written for identity architects, application developers, product managers, and IT professionals who already have some experience with authentication and access control but want to explore the design and implementation of dynamic authorization more deeply. You don’t need to be an expert in policy languages or authorization engines, but a working knowledge of identity systems and basic software architecture will help you maximize the benefits of this book. Dynamic authorization based on policies enables organizations to make access decisions in real-time, leveraging live data about people, devices, resources, and their connections. This approach moves beyond static roles and permissions, enabling fine-grained, just-in- time access that adapts as business needs evolve. It’s a major change, and it’s reshaping how systems are designed and managed. Throughout the book, we’ll use the fictional but realistic ACME Corp case study to ground our discussions. You’ll see how different models—role-based, attribute-based, and relationship-based access control—work together, how to design effective policies, and how to incorporate them into your architecture. You’ll also learn about governance structures, team roles, and architectural patterns that support sustainable dynamic authorization in the real world. And yes, we’ll get hands-on with Cedar, a modern policy language, so you can put these concepts into practice right away. Since you’re reading the MEAP edition, you’ll receive chapters as they are finished and your feedback will influence the final book. If something isn’t clear, or you believe there’s a better example or explanation, please share it in the liveBook discussion forum. Your input will help make this a stronger, more helpful resource for everyone. I’m glad you’re here. I hope that by the end, you’ll see authorization not just as a safeguard, but as an enabler of better, more resilient digital systems. —Phil Windley © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
4
brief contents 1 Why authorization matters: Securing access in a digital world 2 Understanding digital identity 3 Authentication: Who are you? 4 Authorization: What can you do? 5 Static authorization models 6 Dynamic authorization models 7 The building blocks of policy 8 Policy languages and frameworks 9 Implementing policies with Cedar 10 Policy as code: Eective authorization policies 11 Authorization for APIs 12 Authorization context 13 Using policy engines with existing systems 14 Policy governance 15 Security, zero trust, and authorization 16 Using veriable credentials for authorization 17 AI in policy practice 18 Authorization in agentic AI 19 Conclusion Appendix A. End-to-end example with Amazon Veried Permissions Appendix B. Step-by-step AI-assisted policy authoring © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
5
1 Why authorization matters: Securing access in a digital world This chapter covers The importance of digital identity in modern applications Challenges with traditional access control Why authorization matters The rise of dynamic, policy-driven access Business benefits of policy-based access control In 2013, poor access control practices led to one of the largest data breaches in history. Over a three-week period, hackers stole 40 million credit and debit card accounts from retail giant Target by exploiting the account of an Heating Ventilation and Air Conditioning (HVAC) contractor. The attack began with a phishing email that tricked an employee at the HVAC company into revealing their credentials. As a vendor, the HVAC company had legitimate access to Target’s systems for tasks like billing and project tracking, but not to payment infrastructure. Using the stolen credentials, the attackers infiltrated Target’s internal network and ultimately installed malware on point-of-sale systems to harvest customer data. The breach resulted in direct costs to Target of nearly $300 million, along with reputational damage that’s difficult to quantify. 1 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
6
What makes the story especially instructive is not just the breach itself, but the broader failure in access governance and response. Target’s security monitoring systems generated alerts during the breach, but the company failed to act in time. The incident was analyzed in “Inside Target Corp., Days After 2013 Breach” (https://krebsonsecurity. com/2015/ 09/inside- target-corp- days-after- 2013-breach/). The incident offers a cautionary example of how weak authorization boundaries and a lack of visibility into who-can-access-what— combined with organizational inaction—can turn a minor compromise into a catastrophic failure. The Target breach underscores the critical importance of not only knowing who is accessing your systems (authentication) but also controlling what they can access (authorization). The HVAC vendor had access to Target’s systems for electronic billing, contract submission, and project management. However, the hackers were able to extend this access beyond those legitimate uses to reach systems used to update point-of-sale devices. Target’s failure to properly restrict access to critical systems created a significant vulnerability that the hackers exploited. But I don’t want you to get the idea that authorization is just about securing IT systems —it’s also fundamental to how modern cloud applications function, enabling features that wouldn’t be possible otherwise. For example, services like Google Docs and Dropbox rely on authorization to allow users to share documents with specific people while restricting access to others. Without this capability, these applications would not be possible. Another example is Amazon Web Services (AWS), where authorization enables Amazon to securely provide hundreds of cloud services to millions of customers at scale in a cost- effective manner. As a globally distributed system taking advantage of multi-tenancy to service millions of customers, AWS uses a sophisticated policy-based authorization system to help their customers control access by employees and others to the services running inside their accounts. 1.1 Digital identity Ever since the first timeshare systems were invented, developers and systems engineers have been looking for ways to restrict access to various components of computer software systems for different people. The move to the web and then cloud-based applications magnified that problem as more and more people, organizations, and services have gone online. Getting resources and data into the right hands is a significant strategic advantage, as is keeping them out of the wrong ones. Even so, for many years, Identity and Access Management (IAM) has been more focused on the “I” than the “AM.” But advances in access control based on policy and the emphasis on “zero trust” in security have brought access management to the fore. Successful access management requires a holistic approach to digital identity, carefully considering the goals and needs of the systems it will serve. 2 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
7
As the example in the previous section points out, digital identity is foundational not just in securing computer systems but also in enabling features that make them usable. People often think of things like user IDs, passwords, accounts, and so on when the subject of digital identity comes up. But let’s start with why we build digital identity systems: relationships. Every digital identity system is built to manage relationships of some kind. The system is controlled by some entity that uses it to manage the relationships they care about. (I’ll often use the word entity in this book to refer generically to subjects or principles that could be a person, an organization, a service, a thing, or an AI agent.) Managing relationships requires that the controller recognize, remember, and relate to other entities. In the physical world, we effortlessly recognize, remember, and relate to everyone and everything around us. As human beings, we have identity systems embedded deep within us that allow us to create relationships with the world around us. Online, it’s not so easy. One of the fundamental features of the online world is that we interact with others at a distance. This is called the proximity problem and is the first problem any online system must solve. That’s why digital identity is a core part of every system we build. Every digital identity system has ways to recognize, remember, and relate to the entities using it. Authenticating is how the system recognizes. Authentication (sometimes abbreviated as authn) is the process of determining whether the entity making a request is really the one it claims to be. The process of authentication can be complicated, and many security problems stem from failures in authentication. The Target story at the beginning of this chapter, for example, started with a failure of authentication. The hackers were able to impersonate the contractor, fooling the system into recognizing them as legitimate users. Accounts are where identity systems remember. Every identity system has a database or directory that keeps track of information about the entities it has formed relationships with. This information includes functional items, like user IDs, passwords, and keys, as well as other attributes the system might need, like names, addresses, credit card numbers, preferences, and so on. Authorizing actions is one of the primary ways identity systems react to requests. Authorization (sometimes abbreviated as authz) is the process by which we control access to computer systems and is the natural complement to authentication, where authentication determines “who,” authorization determines “what.” Every application, whether it runs in the cloud or is connected to it, has access management challenges. As multi-tenanted applications have become the norm, authentication is rarely sufficient to establish which actions a user can perform on which resources. Traditionally, applications have dealt with these issues using tools like access control lists (ACLs) or user and group permissions. But most applications need more fine- grained access control than ACLs or groups can provide. Often, what access control logic exists beyond these lists is embedded in the code or, worse, in stored procedures in the database. 3 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
8
This book will focus on policy-based access control (PBAC), which decouples access logic from application code, allowing for flexible, fine-grained, and auditable access decisions that are easier to author, maintain, and enforce consistently at scale. PBAC uses a policy engine to evaluate policies and determine whether a specific access request should be allowed or denied. PBAC has been around for some time, but has only recently started to be more widely used as new, easier-to-use policy languages and better, general-purpose policy engines have been developed. 1.2 Challenges with traditional approaches to authorization Robust authorization practices are crucial to how the modern internet works. But authorization has been used in computing for decades. For example, Unix file permissions allow files and directories to be owned by an account and shared with groups of users or everyone on the system. Later, access control lists (ACLs) expanded on file permissions to allow more flexible control of actions, while role-based access control (RBAC) made groups more flexible and easier to manage. All these access control methods have one thing in common: they are static. They use static stores of explicit permissions, groups, and roles to control access to computing resources. Static authorization has several significant limitations that dynamic authorization systems overcome. 1.2.1 Scalability As the number of principals, actions, and resources increases, managing static lists becomes increasingly difficult. (We will use the word principal rather than user to refer to the entities that are taking an action since many of these entities are machines or processes rather than humans.) Each addition requires that lists be updated, either manually or through some rule. Typically, there is a list for each resource or group of resources. Putting thousands, even millions, of customers and employees on multiple lists is unwieldy. For example, I once worked at a large organization that used groups as its primary means of controlling access. Over the years, the number of groups had expanded until there were tens of thousands. The organization had various workarounds in place to automatically keep the groups up to date, but administrators frequently had to make manual updates to add or delete access to something or for someone. 1.2.2 Flexibility Static lists can’t easily adapt to changing request context, organizational structure, or compliance requirements. Request context is a particularly tricky problem. Request context includes things like the time of the request, the location of the requester, whether she’s on a company-managed device, and so on. Should Alice from Finance have after-hours access to transfer funds? Static lists don’t know. Solving the problem requires building special-purpose code in the finance system to augment the static authorization system. 4 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
9
Alternatively, consider scenarios involving elevated or sensitive access—commonly managed through Privileged Access Management (PAM). Access to production systems, for example, might be granted only to developers who are currently on call, based on just-in- time information. In some cases, access may require additional approval from a peer or manager, or be constrained by time-bound policies. These types of dynamic situations require flexible authorization systems that can dynamically respond to requests. Policies can take context (like time or location) into account and respond appropriately or require manager or team-member approval, dynamically granting access when the specified conditions are met. 1.2.3 Maintainability Resources, roles, and architectures are constantly changing. Having humans or rule-based systems manage and maintain these constantly changing lists leads to over-permissioning which has security implications or under-permissioning, which impacts productivity. For example, imagine a SaaS project management platform that allows customers to create projects and gives employees different levels of access to tasks, files, and reports. We might allow project owners to manage everything, team members to view and modify tasks assigned to them, external contractors to view only tasks assigned to them, and finance team members to access billing reports but not project details. Whenever a new task is created, a project changes owners or team membership changes, ACLs must be updated. If a contractor’s role changes multiple lists might be affected. If a contractor needs temporary edit access, you might have to create a new role called Contractor-Editor. Cross-team access results in role proliferation creating numerous special-purpose roles for unique issues. Role proliferation complicates management and can obscure the impact of any single role assignment, making it difficult to predict or audit authorization decisions—especially when principals belong to dozens or even hundreds of overlapping roles. In contrast, dynamic authorization accounts for these kinds of changes and exceptions by evaluating access permission at runtime. When roles or assignments change, access adjusts automatically. 1.2.4 Inefficiency Multi-tenanted, distributed systems, especially those used across different organizations, face unique authorization challenges. Static access control methods were developed before distributed and cloud computing was prevalent. Consider an electronic health record (EHR) system used by doctors, nurses, patients, administrators, and insurance processors. Doctors are allowed to update patient records, nurses can view and edit vitals and medications, and administrators can only view billing details. Doctors and nurses should only be allowed to work on records of patients in their department. Time is also a factor. We may restrict nurses from having access unless they’re on shift, while doctors should have access anytime. And the entire system must consider patient consent to comply with regulations. 5 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
10
ACLs and groups are inefficient in this scenario in terms of both resources and time. ACLs require one list per patient record or set of patient records, depending on the system. Groups grow combinatorially as doctors, nurses, and administrators need to be in multiple departments or roles. This is even more of a problem when role assignments are transient. Patient consent further compounds this, requiring separate role-based mappings for unique consent scenarios. Managing these and dealing with exceptions takes time. Coordinating list sharing across systems and organizations, or involving multiple stakeholders in list membership decisions, is a time-consuming process. 1.2.5 Auditability Static systems are hard to audit to determine policy and regulatory compliance. As we’ve discussed, most organizations are subject to numerous, sometimes overlapping regulations that inform access control decisions. Take, for instance, a bank that must comply with both the Sarbanes-Oxley Act (SOX) (https://www. investopedia. com/terms/ s/sarbanesoxleyact. asp) and the European Union’s General Data Protection Regulation (GDPR) (https://commission. europa.eu/ law/law-topic/ data-protection/ legal-framework- eu-data-protection_ en). To do so, they must ensure that only authorized employees can access sensitive financial records, access is logged, reviewable, and revocable, and temporary access is granted only when justified and expires automatically. As we’ve seen, when using ACLs or groups, employees are assigned static roles like Finance Manager or Auditor. Over time, as people change roles, they tend to accumulate excess permissions because removing people from groups (a process called baselining) is easy to overlook or miss. Consequently, auditors can’t easily answer the question “who has access to what?” leading to problems showing compliance with regulations. Similarly, using ACLs for individual customer records leads to thousands or even millions of lists that must be scanned to audit access to comply with GDPR. Automatically removing temporary access requires bespoke systems that are costly to build and hard to maintain. Static authorization makes regulatory compliance impractical. In contrast, dynamic authorization allows auditors to review policies to check for compliance and use system logs to ensure the policies are working as they should. 1.2.6 Security The security challenges of static authorization are mostly fallout from the other problems we’ve discussed. We count on authorization systems to protect our most valuable and sensitive assets, ensure customer data is safe, and make it difficult for hackers to harm the organization. Static lists are notorious for leaving principals with permissions they no longer require. Stories of employees who still have access to critical systems long after they’ve left the company are common. As discussed earlier, more organizations are turning to Zero Trust architectures to protect themselves. Zero Trust requires checking each access request. With static authorization tools, we can implement only some of the best practices for Zero Trust. 6 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
11
An insurance company hoping to institute zero trust using static authorization faces several problems. Employees should only have access to the data and services they need to do their jobs. With near superhuman effort and lots of bespoke programming, the company’s IT staff may be able to reduce the scope of employee access. They might have to settle for ensuring employees are logging in from a managed device by checking device status at the firewall, since retrofitting every system would be expensive. Protecting access to things like high-risk claims with just-in-time permissions escalation will require custom programming on only a few high-risk systems. In short, trying to increase an organization’s security posture using only static authorization tools will be time-consuming, expensive, and still fall short. 1.2.7 Consistency and transparency Access control is usually governed by the business side of an organization since things like product features, regulatory compliance, and employee roles are business decisions. Governance decisions are communicated to the technical staff, who add their own access control decisions on things like IT security. Then these decisions are translated into static lists and embedded in applications or databases. This leads to situations where the business leaders charged with making policy have very little visibility into whether their policy choices are being implemented correctly. On top of that, because of the way static authorization is implemented and maintained, it’s difficult to know if policy is being consistently applied. Without a central view of policies, it’s hard for business leaders to know who has access to what and harder still for technical staff to answer the question. Consider a multi-national retail company that operates in several regions. A customer support agent in the United States might accidentally be able to access customer payment details for a German customer, violating GDPR data residency rules. There’s no easy way to detect this problem because the rules are not explicit and figuring out how to fix it could be costly. This lack of consistency is frustrating for employees and customers since no one understands why the system allows access for one agent but not another. Access control lists and group-based permissions may seem straightforward, but they become increasingly opaque in large, distributed organizations. In our multi-national retailer example, the U.S. support agent’s access to German customer data might result from layered group memberships—perhaps the agent is in a general Support group that inherits permissions through nested regional or functional roles. These types of configurations are challenging to analyze or simulate. Answering basic questions like “Who has access to European customer data?” or “What would happen if we removed this group?” requires untangling group hierarchies or manually inspecting ACLs scattered across multiple systems. Consequently, policy drift is frequent, changes are risky, and even well- meaning updates can violate regulatory or business requirements without anyone noticing it. 7 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
12
1.2.8 Dynamic authorization addresses these challenges The answer to these challenges is dynamic authorization using policies written in a machine-readable policy language. Policies can provide the scalability, flexibility, and other factors that modern applications and services need to meet the dynamic nature of today’s digital landscape, ensuring secure and efficient access management across diverse environments. 1.3 Authorization matters Most developers, product managers, technical managers, and business leaders are still largely unfamiliar with PBAC and its role in dynamic authorization, but this is rapidly changing. Several trends make dynamic authorization a more important topic than it has been. 1.3.1 Software as a Service More and more software is being delivered as a service (so-called Software as a Service, or SaaS). This is especially true in certain categories like customer relationship management (CRM) and human resource management (HRM) where market penetration is estimated to be as high as 80%. Businesses, large and small, enjoy the ease of deployment, cost efficiency, scalability, and flexibility of letting someone else build, maintain, and manage essential services. SaaS applications are, necessarily, multi-tenanted, meaning many customers are using the same instance of the service. Multi-tenancy requires that each customer’s data be visible to only that customer. But it’s even more complicated than that because each business customer will have multiple employees whose access to the system will have to be controlled. SaaS vendors can’t provide the needed levels of functionality and security without strong, flexible authorization systems. Using a policy-based authorization system lets them externalize the logic of access control from the functional aspects of the system. In some cases, like AWS, the policies are visible to the customers, but in most cases, the policies are generated from the SaaS system’s UI. Regardless, the use of dynamic authorization allows SaaS vendors to provide the access control needed for their product features and security guarantees while maintaining the flexibility and scalability their services need to compete. 1.3.2 Zero trust security models Traditionally, companies secured their computer systems using a firewall. The firewall, like a castle wall, is meant to keep attackers out. The firewall carefully controls access to the network and computers inside to ensure only authorized people and systems are granted access. 8 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
13
But perimeter-based security architectures like firewalls are becoming less and less effective. First, mobile devices and remote work mean employees frequently work outside the firewall, necessitating the administrative overhead of virtual private networks (VPNs). Second, the rising use of SaaS-based services means that employees who are inside the firewall are often using systems outside of it. Third, access control needs to be more fine- grained than the coarse-grained “inside or outside the wall” protection that a firewall provides. As a result, perimeter-based security is being augmented with zero-trust security models. Rather than assuming everyone inside the perimeter is trusted, zero-trust models assume breach and authorize every access. Assuming breach reverses the assumption: everyone is untrusted until the system says they are. Authorizing every access doesn’t mean just the initial access to a particular system, but every request, even in the same session. This puts an incredible load on the authorization system, requiring speed and flexibility. PBAC systems offer performant fine-grained access control based on the context of each request, making zero trust possible. 1.3.3 The Internet of Things More and more devices are smart, connecting to the cloud to provide functionality that their dumb counterparts can’t. The rise of the Internet of Things (IoT) means that more aspects of our daily lives—and even entire industries—are now managed by interconnected systems that can communicate and act on our behalf. I have a smart lock, for example. The access control system that controls it literally controls physical access to my house. However, these devices can also become entry points for cyberattacks. If compromised, smart devices can serve as conduits for hackers to infiltrate more critical systems. Restricting their access to other systems based on their real access needs protects them and prevents them from becoming a vector that hackers can exploit to break into other sensitive systems. Since many smart devices operate at the edge, they may operate autonomously, working without direct oversight. Dynamic authorization can allow devices to respond to events in a secure, flexible manner, even without a network connection. This need is especially critical in large, heterogeneous smart device deployments, like in factories or large buildings, where diverse IoT systems must coordinate securely. Here, access control requires real-time decision-making based on device attributes, policies, fluctuating risk levels, and other environmental factors. Traditional static models like ACLs or RBAC struggle to provide the necessary flexibility, making policy-based access control a more effective approach to securing modern IoT environments. 1.3.4 Heightened regulatory environment Regulatory compliance is yet another reason why authorization is increasingly important. Most organizations are subject to numerous regulations that dictate the access requirements for many kinds of data. 9 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
14
Some regulations require that employee access be sensitive to context. For example, the Health Insurance Portability and Accountability Act (HIPAA) mandates that access to patient data be limited to those who need it for purposes of treatment, payment, or facility operations. For example, a nurse’s access to patient records might be limited to those patients under her care while she’s on duty. Some regulations require that employees have the minimal access needed to do their jobs—the principle of least privilege. For example, to comply with the provisions of SOX, a company may need to ensure that a financial analyst has access only to financial reports and not the raw data that underlies them. Dynamic authorization based on policy can make fine-grained access control decisions based on the analyst’s role or other attributes. Compliance with regulations might depend on attributes of the person making the request as well as the attributes of the data. For example, the General Data Protection Regulation (GDPR) requires that access to personal information depend on the person’s consent. Policies can be written to use both the attributes of the data and those of the person making the request. Compounding the problems of compliance, regulations change frequently, requiring updates to the access control systems that enforce them. Dynamic authorization through policy allows organizations to more easily update access protections in response to changing regulations. Finally, most regulations require auditing to ensure compliance. Dynamic authorization systems have provisions for access logging that make conducting audits easier. In contrast, homegrown systems must build logging into the system. 1.3.5 Artificial intelligence The advent of GenAI, and particularly AI agents that can act on a person’s behalf, pours gasoline on the smoldering interest in authorization by organizations. Am I talking to a human? Does this agent have the authority to make a doctor's appointment on the patient's behalf? These and other questions mean that making good authorization decisions, knowing what decisions were made, and easily incorporating authorization infrastructure into your apps and infrastructure is vital. AI applications are often built by augmenting the foundational capabilities of the large language model (LLM) with other data for a specific application. For example, an AI application built to aid financial analysts asking about an organization’s finances may need to add information specific to the organization’s financial records. The underlying model is augmented with the financial records it needs, an approach called Retrieval Augmented Generation (RAG). This presents an authorization challenge: different users of the application should only see answers consistent with the financial records that they’re entitled to see. RAG architectures can be built with dynamic authorization in place to prevent unauthorized access to data by people using the application. We’ll discuss this topic in detail in chapter 17. GenAI is still in the early stages of being commercialized, but underpinning it with strong, fine-grained access control can give it the capabilities to properly protect sensitive information. 10 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
15
1.4 Dynamic authorization: Policy as Code and Policy as Data Dynamic authorization depends on making real-time, context-aware access control decisions by evaluating policies are runtime instead of relying on static, pre-configured permissions or special-purpose code. A key distinction from earlier approaches is that policies are represented so that a common, general-purpose engine can use them to make access decisions. There are two different, complementary methods of representing policy: Policy as Code—where policy is represented as machine-readable, version-controlled text using languages built to encode authorization policy. Policy as Data—where policy is represented and stored as structured data that represents relationships or other attributes needed to make an access decision. These two paradigms allow organizations to flexibly and efficiently manage access but each addresses different needs. 1.4.1 Policy as Code: Defining access logic in a programmable way Policy as Code treats access control rules as software. All the tools used for developing, testing, and deploying software can also be used to manage policies. By storing policies in a version control system, they can be versioned, rolled back, and audited. Policies can be tested using the same testing frameworks that developers already employ or custom frameworks that provide special features. Organizations can use the same tools they already use for continuous integration and deployment (CI/CD) to enforce integration testing and security reviews before policy changes go live. Product managers, developers, or security teams can write policies that are treated as code. A general-purpose policy engine evaluates the policies to enforce access whenever a request is received. Policy as Code is useful for situations where broad, reusable rules can be applied to the problem. For example, in a zero trust architecture, a policy might say, “Only employees on managed devices can access critical resources.” In a financial services application, a policy might say, “Only employees in the finance department whose training is up to date can issue purchase orders.” These kinds of rules are broadly applicable and can be combined to handle more complex scenarios. Policy as Code use policies are written in a policy language. We’ll use the Cedar policy language for examples in this book. Cedar is discussed in detail in chapter 8. Here’s an example of a Cedar policy that forbids any action by anyone on resources in the category CriticalResources unless the device posture signal indicates they are using a device that is judged Secure with an overall security assessment greater than or equal to 80. 11 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
16
This policy uses code to clearly state the policy writer's intentions. This is a forbid policy, meaning that if the requirements of the policy are not met, access will be denied. Assuming critical resources have been correctly categorized, this policy requires people to use properly functioning managed devices when accessing them. 1.4.2 Policy as Data: Storing and managing access rules dynamically In contrast to Policy as Code, which focuses on general rules that can be evaluated to determine access, Policy as Data uses a store of information about specific attributes, permissions, or relationships that a general-purpose engine can use to determine access at runtime. The data is structured and usually stored in some kind of database. End-users, administrators, or business systems define the rules dynamically using a user interface or an API. For example, when a customer chooses to share a Google document with members of their same organization, that permission is stored in the relationship the customer has with their organization. Figure 1.1 shows the relationship graph for a Google document. This could be stored in a graph database for use by the authorization engine. While this may seem like an ACL, it’s much richer, and the additional information allows general- purpose relationships to be expressed. forbid( principal, action, resource in Category::"CriticalResources" ) unless { context.device.security.risk == "Secure" && context.device.security.assessment.overall >= 80 12 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
17
Figure 1.1 A relationship graph representing access to a Google document. Rather than use static ACLs, this model captures roles (like Owner, Editor, Viewer) as first-class relationships between users and resources. The graph also models hierarchical relationships (such as parent folders), enabling more flexible, general-purpose authorization logic that can be queried and evaluated dynamically. Policy as Data is good for unstructured rules that can’t be easily enumerated in a few policies. To use Google Docs again as an example, each document has a different owner, editors, and contributors. These relationships can be easily recorded in a graph database, for example, and queried at run time to make an access decision. 1.4.3 Dynamic authorization needs both Policy as Code or Policy as Data is not an either-or decision for many organizations. Both have their strengths and can be used together to provide the best outcomes for a specific situation. Here are some areas where they complement each other: Scalability—Policy as code is useful for creating broad, complex rules that apply to many users. Policy as Data can store many fine-grained rules that can be accessed dynamically. These rules are typically created by users themselves as they interact with the software rather than by security administrators or developers. Flexibility—Policy as Code changes access decisions based on request context. Policy as data makes them based on ever-evolving relationships, roles, and permissions. 13 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
18
Security and Compliance—Policy as Code enforces strict policies based on best practices. Policy as Data allows real-time adjustments without changing policy. Auditability—Policy as Code offers version control to show how policies have changed. Both can log access decisions to create a historical record. Policy as Code platforms that can use attributes from data sources can sometimes offer the best of both worlds by writing policies that use attributes from a data store that can be updated over time. For example, a policy that checks the principal’s department using the organization’s identity store can dynamically adjust to changes in where an employee is assigned even if that changes day by day. Here’s a Cedar policy that encodes that idea: The principal’s department is retrieved in real time using the HR system as the data store. The resource’s allowed department is stored in a database of resource metadata. If an employee moves from Finance to HR, the policy uses the data to determine if resources the employee is accessing are allowable for an HR employee. Both Policy as Code and Policy as Data offer unique advantages. As organizations adopt zero-trust security models, deploy AI agents, use decentralized credentials, and are required to employ real-time risk assessment, these unique advantages will become even more important. By separating concerns with different dynamic authorization methodologies, organizations can scale authorization decisions efficiently without sacrificing flexibility or security. 1.5 The business case for dynamic authorization Many leaders see access management as primarily a means of protecting and securing computer systems—important, but of secondary importance to the organization. But since computer systems have come to intermediate almost every interaction the organization has with employees, contractors, partners, and customers, they should also consider dynamic authorization a strategic business enabler. Investing in a robust, flexible, and pervasive authorization infrastructure can drive revenue growth, operational efficiency, regulatory compliance, and competitive differentiation. forbid ( principal, action, resource in Category::”CriticalResource” ) unless { resource has allowed_department && principal has department && principal.department == resource.allowed_department 14 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
19
1.5.1 Reducing operational costs As we’ve discussed, manually managing access using rigid, static authorization models like ACLs and groups is labor-intensive and prone to errors. Organizations that rely on static methods often have employees who are dedicated to managing permissions for employees and others. These employees also perform manual audits, track down problems, and manage groups. As the organization grows, these processes become more complex, scaling superlinearly due to interactions in the system, as shown in figure 1.2. Figure 1.2 As an organization grows, the number of access policies tends to increase faster than linearly. Though a small organization might manage with a simple, flat set of policies, larger organizations face compounding complexity due to team structures, regional compliance, and overlapping responsibilities, leading to superlinear policy growth. Dynamic authorization automates many of these access control decisions, reducing the need for manual intervention. This has several benefits: Lower administrative overhead—eliminating the need for manually managing permissions and groups reduces administrative costs. Reduced risk of over-permissioning—accounts with permissions they no longer need are the source of many costly security breaches. 15 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page
20
Reduced security insurance premiums—many organizations buy costly insurance to protect against security breaches and ransomware. Better authorization practices can reduce premiums. Fewer support tickets for access problems—tickets that require IT to drop what they’re doing to sort out a permissions problem take these critical employees away from work that advances the organization’s products and services. Improved onboarding and offboarding efficiency—dynamic authorization can ensure that new employees or contractors have all the access they need on day one and lose it as soon as they leave. Improved operational efficiency gives the organization the freedom to explore and grow instead of constantly battling access management problems. 1.5.2 Enabling business agility and innovation As more business is conducted online, organizations are finding that it’s vital to react quickly to changing business needs. Whether an organization is launching a new product, expanding into new markets, reacting to new regulatory requirements, or enabling new partnerships, flexibly adapting to emerging requirements and supporting innovation is table stakes for successful organizations. As we’ve discussed, static authorization methods require manual changes to lists and groups to increase or decrease access to systems. For example, a financial services firm that is employing external auditors for compliance reviews must grant access for the duration of the engagement. A dynamic authorization system makes this as easy as a policy change. Even that might not be required if authorization policies have been written to anticipate this kind of need. New products often require custom code to support authorization requirements for customers and administrators. For example, a workforce management SaaS provider launching a new employee onboarding product must ensure that customers can properly authorize different access levels for their employees to administer and manage the service securely. The company can integrate a dynamic authorization system with the new product, allowing developers to build the right authorization controls without writing custom authorization software. 1.5.3 Improving customer experience The compelling features of modern SaaS applications, marketplaces, and collaborative services rely on carefully managing access. In these platforms, dynamic authorization isn’t just about security—it enhances personalized user experiences by speeding up service provisioning, providing the right access at the right time, and enabling features like delegated access, team sharing, or tiered functionality. It also creates new revenue opportunities by facilitating the enforcement of subscription levels, usage-based pricing, or pay-per-feature models without hardcoding access logic. 16 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>