In Is Policy-Based Access Control (PBAC) an Authorization Model?, I argued that PBAC gets compared to Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) as if it belonged in the same category, when it actually answers a different question.

RBAC and ABAC describe what data a decision is based on: a role, an attribute. PBAC describes how that decision gets made: through a centralized policy engine instead of logic wired into the application. One is about the shape of the rule. The other is about where the rule lives and who evaluates it.

In my opinion, treating them as competing options is like comparing a recipe to a kitchen.

That distinction attempted to solve one specific confusion, but it left a bigger one untouched: PBAC isn’t the only term that gets misfiled this way.

Mandatory Access Control (MAC) and Discretionary Access Control (DAC) get compared to RBAC and ABAC too, even though they describe who administers the rules, not what the rules look like.

Access Control List (ACL) and Relationship-Based Access Control (ReBAC) show up in the same breath as “authorization models,” but one is arguably a special case of the other, depending on which paper you read.

The terminology around authorization has accumulated for decades across access control research, identity vendors, and standards bodies, and a lot of it answers different questions while using the language of a single one: “what model is this?“

This piece generalizes the model-versus-architecture distinction into a full taxonomy. Instead of asking “which authorization model is this system using?“, I want to ask five narrower questions about any authorization system, answer each one independently, and only then see where familiar labels like RBAC, ABAC, MAC, and PBAC actually land. If the terms stop competing once they’re placed on the right axis, that’s a sign the axes are doing real work.

The Core Problem of Authorization

Authorization answers one question: can this subject perform this action on this object? A user reading a file, a service calling an API, a process writing to a database. Every authorization decision reduces to that same triple: subject, action, object.

In the simplest possible system, there’s no decision to make because there’s no separation between the party asking and the party deciding. Picture your own diary, kept in a drawer in your own room. You want to read it, so you open the drawer and read it. Nobody has to grant you permission, because nobody else is involved: wanting and getting are the same act.

Real systems rarely stay this simple, because the thing being accessed usually belongs to more than one interested party. Put that same diary in a house with housemates, or move it into a company’s filing cabinet, and the picture changes immediately. Not everyone who wants to open the drawer should be allowed to, and somebody has to decide, case by case, who does and who doesn’t.

A resource server does exactly that job for software. A multi-tenant SaaS application, an internal API, a cloud storage bucket accessed by dozens of services: all of them need something that looks at a request and decides whether to honor it. That “something” is what the rest of this piece is about, and it turns out to have more moving parts than a single word like “RBAC” or “PBAC” can capture.

How an Authorization Request Gets Processed

Follow a single authorization request through a resource server and a consistent set of stages emerges, regardless of the specific technology involved: a request arrives, the server gathers context about the user and the resource, a policy evaluates that context against a rule. The evaluation produces an allow or deny decision, and the server enforces that decision by letting the request through or rejecting it.

The same five stages appear in essentially every authorization system:

1. Someone defines the rules. A developer hardcodes a check; a security team writes a policy; a resource owner sets sharing permissions on their own file.
2. The rules take some concrete shape. A conditional in application code; a JSON document; an XACML policy; a row in a spreadsheet someone exports into a database table.
3. Some data has to feed the decision. The user’s role; the department listed in a database; the time of day; the relationship between the requesting user and the resource’s owner.
4. A decision gets computed. The rule and the data get evaluated together, producing allow or deny.
5. The decision gets enforced. Something has to actually act on the result: block the request or redirect it.

These five stages map onto a vocabulary that’s been around in access control architecture for a while:

• Policy Administration Point (who defines the rules)
• Policy Information Point (what data feeds the decision)
• Policy Decision Point (where the decision gets computed)
• Policy Enforcement Point (where it gets enforced)

Brossard’s overview of ABAC architecture lays out this PAP/PIP/PDP/PEP breakdown in more detail, and it’s worth reading if these terms are new.

There’s a related, more academic framing worth pulling in here, from a 2022 systematic literature review of authorization and access control research by Mohamed, Auer, Hofer, and Küng. The paper draws a ladder with four levels: an authorization strategy (discretionary, mandatory, or hybrid) sits above an authorization model (the subjects, objects, and other components a system reasons about), which sits above an authorization policy (the concrete rule instance). In parallel, an access control model (the logic for deciding allow/deny) is enforced by an access control mechanism (the actual running software). It’s a rigorous way of saying the same thing this piece is arguing: strategy, model, policy, and mechanism are separate layers, and conflating them is where the terminology breaks down.

None of these five stages, by themselves, tells you whether a system “is RBAC” or “is PBAC.” Each stage is actually a separate question, with its own independent set of answers. That’s the seed of the classification below.

A Consistent Classification

Six axes cover the five stages above (Authorization Policy gets split from Authorization Model, since a model can be instantiated by more than one kind of concrete policy artifact). Each axis has a small number of common answers, and every familiar term (ACL, RBAC, ABAC, ReBAC, MAC, DAC, PBAC) is really an answer to one specific axis, not a label for the whole system.

A useful way to keep the six axes distinct is a metaphor borrowed from outside software entirely: the machinery of law. A legislature drafts rules, the rules get written down as statutes, courts weigh those statutes against the facts of a case, and police carry out the verdict. Swap “legal system” for “authorization system” and the same six jobs reappear below, one at a time.

Authorization Administration: who sets the rules?

Before a rule can be evaluated, someone has to have the authority to write it in the first place. That authority can be concentrated in one place or spread across many, and a system’s answer here is independent of what the rules actually say. Authorization administration can be:

• Centralized: a security team or administrator defines rules for everyone. This is the pattern behind MAC (Mandatory Access Control): access is determined by a central authority, not by the resource owner.
• Decentralized: the owner of a resource decides who else can access it. This is DAC (Discretionary Access Control): the classic “share this file with these people” pattern.
• Hybrid: some rules come from a central authority, others from individual resource owners, layered together.

Mohamed et al’s literature review treats strategy this way too, and their comparative analysis is instructive: when they classified access control models against this axis, RBAC, ABAC, and ReBAC families all landed in the hybrid category, not cleanly in DAC or MAC. That’s a useful data point on its own. It confirms administration strategy is genuinely independent of authorization model: a role-based system can be centrally administered, owner-administered, or both, and it’s still RBAC either way.

The legal system runs on exactly this split. A parliament, or a king under older systems, legislates for an entire population: centralized administration. Two neighbors agreeing on where a fence line runs, or a homeowner deciding who gets a key, is decentralized administration, closer to how contract law and property law actually work. Most real legal systems mix both, the same way most authorization systems do.

Authorization Model: what data type drives the decision?

Once the authority to write a rule is settled, the next question is what the rule actually reasons about: the specific kind of information a decision checks each time it runs. This is the axis most people mean when they say “authorization model,” and it’s the one my earlier PBAC article focused on. Here are a few common authorization models:

• Identity-based (ACL): the decision checks whether the specific subject appears on a list attached to the object.
• Role-based (RBAC): the decision checks whether the subject holds a role that’s been granted the requested permission.
• Attribute-based (ABAC): the decision checks attributes of the subject, object, action, or environment against a rule (department = “finance”, clearance ≥ “secret”, time between 9 AM and 5 PM).
• Relationship-based (ReBAC): the decision checks the relationship between subject and object, often by traversing a graph (is this user a member of the team that owns this document?).

It’s worth being honest about the fuzziness here. Depending on which academic source you read, ACL and RBAC can be described as special cases of ABAC, where the attribute in question happens to be identity or role membership. These four categories are the most useful cut for a working taxonomy, not a claim that the categories are mutually exclusive at the mathematical level.

The law makes the same kind of distinction between what a rule is actually about. Constitutional and administrative law usually define who may act by office, “only the president may sign this treaty“, which is role-based. Regulatory law more often reaches for attributes, “any business with revenue over ten million dollars must file this report“. Family and contract law hinge on a relationship: spouse, parent, business partner. And a law or injunction naming one specific person or company is the legal equivalent of an ACL. Different areas of law reach for different criteria for the same reason different authorization systems do: each criterion fits a different kind of decision.

Authorization Policy: what shape does the rule take?

Once a model is chosen, it still has to be written down somewhere as a concrete artifact:

• Hardcoded conditionals in application code.
• A structured document (JSON, YAML) loaded and interpreted at runtime.
• A declarative policy language purpose-built for authorization, like XACML, Rego (Open Policy Agent), or Cedar.
• A row in a database table.

This axis matters because two systems can share the same authorization model (both are RBAC) while differing completely in maintainability, auditability, and who’s allowed to change the rules, purely because of how the policy is expressed.

In the legal metaphor, this is simply the law itself: the actual text of the statute or code, independent of who passed it and independent of which area of law it belongs to.

Authorization Information: where does the decision-relevant data come from?

A rule is only as good as the data it’s evaluated against, and that data doesn’t all arrive the same way. It’s worth separating what the rule depends on from how the system actually gets its hands on it:

• Wired in: the data is already available in the application’s normal request flow, no extra lookup required.
• Token-based: the data arrives as claims in a JWT or similar credential, populated by the identity provider at issuance time.
• Looked up: the application queries a database, directory, or external service at decision time.
• Environmental: the data describes the context of the request itself rather than the subject or object: time, location, device posture, network.

This is a place where even careful academic treatments blur a real distinction. Mohamed et al’s framework folds environmental attributes into the authorization model’s component list, alongside subjects and objects, rather than treating “where does this data physically come from at runtime” as its own architectural concern. I think that’s a small version of the same mistake the PBAC article calls out: knowing that a decision depends on “time of day” is a modeling question but knowing that the request has to make a network round-trip to a directory service to get it is an architecture question, with real consequences for latency and failure modes.

A courtroom depends on the same kind of input: facts and events. Testimony, documents, timestamps, prior records. The same law applied to a different set of facts produces a different verdict, exactly the way the same policy applied to different token claims or different database lookups produces a different authorization decision. And, just as in an authorization system, where those facts come from (a witness on the stand, a document requested via subpoena, or an expert report) is its own separate concern from what the law says.

Authorization Decision: how and where is the decision computed?

Once a rule and its data are both available, something has to actually run the evaluation. That “something” can live in a few different places, and where it lives is a question about architecture, not about the rule itself:

• Wired into application code: an if statement or a framework-native permission check inline with the business logic.
• A dedicated library or module: decision logic factored out but still running inside the application process.
• A centralized policy engine: a separate service that receives context and returns a decision, often shared across many applications.

PBAC lives here, not on the “authorization model” axis. Centralizing the decision point into a policy engine is an architectural choice about where evaluation happens, and it’s compatible with any of the authorization models: a PBAC engine can evaluate role-based rules, attribute-based rules, or a mix. That’s exactly why PBAC isn’t a peer of RBAC and ABAC. It’s an answer to a different question than the one RBAC and ABAC answer.

This is where the courtroom metaphor lands squarely: a court, and specifically a judge, is the decision engine. The law and the facts go in, a verdict comes out. And a legal system’s habit of routing different kinds of cases to different, specialized courts (traffic court, family court, a supreme court) without changing what the underlying law says is a good picture of what PBAC actually is. It’s a choice about which court hears the case, not a change to the law itself.

Authorization Enforcement: how and where is the decision enforced?

A decision only matters if something acts on it, and that action doesn’t have to happen in the same place the decision was made. Authorization enforcement can live in:

• Wired into application code: the same code path that made the decision also acts on it.
• Dedicated middleware: a framework-level component intercepts the request based on the decision.
• Distributed enforcement: a gateway, sidecar, or proxy enforces decisions at the network edge, independent of the application itself.

Like the authorization decision axis, this is architecture, not model. A system enforcing ABAC decisions through an API gateway and a system enforcing ABAC decisions through inline middleware are both, unambiguously, ABAC. They just made different choices about where enforcement lives, usually driven by concerns like operational scale or the number of services that need to share one policy.

This is the police, in the metaphor: the verdict gets carried out regardless of whether that happens inside the courtroom or on a street corner miles away. The court decides; the police act. It’s the same separation between authorization decision and enforcement in an authorization system.

Putting it together

A real authorization system’s full description is a tuple across all six axes, not a single word. “RBAC” says something about the authorization model axis and nothing about the other five axes. An authorization system can have:

• Centralized administration (MAC)
• Role-based model (RBAC)
• JSON policy documents
• Token-based information
• A shared policy engine (PBAC architecture)
• Gateway-level enforcement.

That’s a coherent, common real-world setup, and every label in it is accurate simultaneously, because each one answers a different question. The confusion in most authorization discussions comes from picking one label per system and treating it as exhaustive, when it’s really just the answer to whichever axis happened to come up first in the conversation.

The legal metaphor running through this section is useful precisely because it breaks down in the same places the software terminology does. Nobody would call a law court an “administrative law” or claim the existence of a “witness-based law” because a judge renders a verdict considering the deposition of a witness. But the six jobs underneath it (who legislates, what kind of law applies, what the law actually says, what facts it’s applied to, who judges, who enforces) are as separable in a courtroom as they are in a policy engine, and confusing them causes the same kind of category error either way.

Conclusion

The terminology problem in authorization isn’t that the field lacks vocabulary. If anything, it has too much: MAC, DAC, RBAC, ABAC, ReBAC, ACL, PBAC, and more, each coined by a different paper, standard, or vendor, at a different layer of the same request lifecycle. The problem is a habit of treating all of it as one flat list of “authorization models” to choose between, when most of these terms don’t compete with each other at all.

Separating the questions helps in a very practical way when you’re actually choosing an approach for a real system: pick the authorization model based on what your access rules naturally depend on (roles, attributes, relationships). Separately, pick the architecture (where decisions get made and enforced) based on your operational constraints (how many services need to share policy, how much latency you can tolerate, who needs to audit or change rules). Those are two separate decisions with two separate sets of tradeoffs and bundling them into a single choice (“we’re doing PBAC” or “we’re doing RBAC“) tends to hide half of what actually needs deciding.

None of this makes the individual labels wrong. RBAC is a real, useful description of a model. PBAC is a real, useful description of an architecture. They’re just not describing the same thing, and a consistent classification is what lets you say precisely which thing each one is.

References

• Is Policy-Based Access Control (PBAC) an Authorization Model?
• A Taxonomy of Modern Authorization Models
• The State of the Union of Authorization
• A systematic literature review for authorization and access control: definitions, strategies and models. International Journal of Web Information Systems, 18(2/3), 156-180. https://doi.org/10.1108/IJWIS-04-2022-0077

Andrea Chiarelli is a Principal Developer Advocate at Auth0 (Okta). He has extensive experience in software development, holding various technical roles. In recent years, he has focused on Identity, developing a passion for the core concepts, which he aims to disseminate to developer communities.

The post Authorization Terminology is a Mess: Let’s Fix It appeared first on IDPro.

Background

The true beginning of scientific activity consists rather in describing phenomena and then in proceeding to group, classify and correlate them.

Sigmund Freud

Identity and Access Management (IAM) systems have become critical in ensuring the security of enterprise applications. In the good old days of the on-premise / co-located data center, an enterprise could easily implement perimeter-based security – one where you would build a castle and a moat around your prized assets and then control the ingress & egress points to provide a reasonable security posture. The majority of access was granted to humans. Every human was given the appropriate level of access according to their job role, and everybody lived happily ever after… that is, until a dark cloud of disruption rained on the perimeter-based security parade. We are, of course, referring to the advent of cloud technology.

With a cloud-first approach, enterprises now have a significant portion of their prized enterprise assets and data deployed outside of their traditional data centers. Enterprises are shrinking their on-premise footprint and running workloads in the cloud. Identity, not network, is the new perimeter. One of the interesting aspects of this seismic shift was the rise of Infrastructure As Code (IAC) and, by extension, non-human accounts that manage the infrastructure. It is also not unusual to have cloud systems with thousands (if not tens of thousands) of permissions. This led to a proliferation of roles, and it became clear very quickly that the orthodox job role-based approach to access control needed adjusting.

Another unfortunate side effect of the identity-based perimeter approach was the rise of identity-based threats. A vast majority of breaches can be traced to compromised credentials and over-privileged accounts. It is becoming abundantly clear that an access control methodology that is dynamic and can evaluate access continuously based on risk signals in real-time is the need of the hour and a cornerstone of Zero Trust Architecture. Identity professionals responded to the challenge, and a variety of authorization and access control methods and corresponding ecosystems have developed. This is our attempt to enumerate these access control methods, categorize them, explore relationships between them, and, most importantly, provide guidance on how to choose your authorization system.

How to choose your next authorization system?

As highlighted in the preceding section, organizations need to shift their focus from old/legacy authorization models and systems to new ones capable of coping with today’s problems. This is not easily done when an organization’s whole infrastructure has evolved into its current state over a period of years or even decades… One therefore faces the two following questions right away:

• What authorization model or language to even choose to face these challenges?

We will answer these questions by first providing a Taxonomy of modern authorization models and then using it to provide some answers.

What is an Authorization Model?

Authorization systems are made of several complex components. Typically, an engine that makes access decisions, along with some other systems whose roles are to execute the decisions made by the engine or to fetch the data necessary for the engine to reach its decisions.

Our goal here is not to list all possible architectures of such systems or to describe them but rather to focus solely on the Policy Engine itself, which is at the core of the Policy Decision Point (PDP). Any PDP uses at least one methodology to compute its decisions. We call these methodologies for building PDPs “Authorization Models,” and the following sections describe a taxonomy of such Authorization Models.

What is a Taxonomy?

In simple terms, it is the science of naming and classifying things. To the authors’ knowledge, this hasn’t been done yet for authorization models, even though there is a great deal of confusion throughout the industry about the various ways authorization can be implemented. Each category in a Taxonomy may have subcategories, but it is important to note that the things being classified may belong to several categories at the same time. Objects can therefore be duplicated under several branches of the Taxonomy Tree if it makes sense (for example, consider a taxonomy of fish: salmon would be present under both the “Ocean” and “River” categories…).

A Taxonomy of Authorization Models

The first question when creating a taxonomy is to choose the right categories. This may be a contentious subject, especially in the field of authorization, given the enthusiasm of the Authorization community (the #Authorati) and the fact that there could be many ways to go about it. In the end, we opted for a set of categories that met the two following criteria:

1. The categories, and the Taxonomy in general, should be helpful to all and not just serve a small community of specialists. In particular, it should help any Identity practitioner in making implementation decisions based on real-world criteria.

2. It should cover all the existing models by avoiding duplicates as much as possible, as well as be easily expandable to any new, not yet invented models.

Figure 1 below depicts our proposed Taxonomy of authorization methodologies.

Figure 1 – A Taxonomy of Authorization Models

Level 1 – Centralized vs decentralized control

All models described here involve some kind of rules, even the simplest of them. The first categorization is to distinguish between those models owned and maintained by the owners of the Resources being protected  (DAC branch) or whether these rules need to be centralized and administered by specialized administrators in a central location – see the Mandatory Access Control (MAC) branch. We find here our first authorization models

DAC branch:

• ACL: Access Control Lists, the oldest of all and the first model introduced through the Multics OS in 1969. Here, a resource owner maintains a list of all the subjects allowed to access any given resource they own, along with the type of access granted (typically read, write, or delete). Popular in operating systems such as Unix or in LDAP Directories.

• FGA/Zanzibar: Fine-Grained Access Control (FGA) solutions are all inspired by, or implementations of, the Google Zanzibar paper published in 2019. The paper describes Google’s own authorization model used throughout its various tools and offerings. Like ACLs, FGA solutions require resource owners to maintain “tuples” (text strings, essentially) that describe the type of access any subject may have to their resources. Because of the considerable amount of tuples potentially required by such a system, they are best suited for DAC applications (which is also Google’s use case).

• ReBAC: Relationship-Based Access Control (ReBAC) is an approach that uses the paths between subject and resource nodes in a data graph in order to determine access. Access is granted if such paths exist. ReBAC uses native graphs and requires a proper Graph Database store (more on this further). Note that ReBAC can be used for both DAC or Mandatory Access Control (MAC) applications.

Note: We make a distinction here between FGA systems and ReBAC: we view these as different models altogether. Although FGA tuples describe a graph, those tuples are not stored in graph databases but are rather strings stored in SQL or custom databases. On the other hand, ReBAC systems use graph databases and express policies as Graphs, not as programming languages. This means that path traversals and tooling are vastly different between those systems. A Graph-based ReBAC policy is therefore an image/diagram and not a block of code, as is the case for FGA systems.

Level 2 – MAC Models

Centralized access policy models are of two kinds: those that can be context-aware and can implement environmental or other contextual conditions and those that are ignorant of context. The contextual conditions can be based on date and time, locations, or even specific attribute values.

Level 3 – Context-Aware models

At this level, and on the context-aware branch, we find two subcategories. Here, the authorization models can be based on rule sets or instead use relationships between entities in order to compute access. Relationship-based systems are graph systems.

Graph Approach

Graphs can implement two types of context-aware models:

• Next Generation Access Control (NGAC), which is an ANSI Standard (* See: https://webstore.ansi.org/standards/incits/incits4992018 ). Look for NGAC-compliant systems that provide no-code / low-code interfaces.

• Risk and Behaviour-Based Access Control (BeBAC): a model by which subjects’ behavior is tracked as a graph, and baselines established for acceptable behavior. These systems can then apply graph pattern-matching or graph analytics techniques to find outliers and thus compute the risk of any given access request.

Another common technique here is to compute the risk score of a given user/entity (similar to a ‘FICO score’) and calibrate ‘access credit’ based on the user/entity risk score, the nature of the request (e.g., privileged v/s nonprivileged) and the type of object/resource that is being accessed. For instance, a user/entity may be denied privileged access to a resource (such as a high-risk PCI database) if their risk score passes a certain threshold (the equivalent of an ‘Excellent’ FICO score due to recent activity that falls outside of the established behavioral norms for the user/entity).

Rule-Based Approach

The non-graph approach is more traditional and, in the case of some vendors, has been available since the beginnings of ABAC and the XACML standard. In this approach, the access policies are defined by a set of programmatic rules, defined either using modern authorization languages or through solutions that provide more business-friendly front ends. The rules combine Subject and Resource attributes with environmental conditions in order to compute a logical decision.

At this level, we find:

• Authorization languages: Any specialized language that can express access policies using attributes and their values. We find some standardized languages (XACML, ALFA) and as well as some vendor-specific ones (the others). These languages let developers typically implement their own flavor of ABAC/PBAC (see below).

• ABAC / PBAC: Attribute/Policy-Based Access control systems. These systems implement ABAC without a language per se; they rather rely on tooling and/or GUI widgets to help or guide users during the creation of the policies. Note that the authors believe ABAC and PBAC are synonymous in that all ABAC systems also need to define and manage policies.

• Risk and Behaviour-Based Access Control (see definition above).

• Organization-Based Access Control (OrBAC): A model driven by the subject’s and Resource’s membership to an organization. This can be based on business units within a company or even on different organizations altogether. OrBAC uses dynamic rules and context, as well as a hierarchy of Organization, Role, Activity, and View in order to determine access to its resources.

Level 3 – Context Agnostic Models

On this side of the tree, the authorization models don’t support the use of any environmental conditions. These are easier models to use and understand, but they are also much more limited. The two sub-branches here refer to the way to group Subjects and the Resources they try to access.

On the Set-based branch, subjects and resources are grouped together by some common factors, such as users sharing the same semantic role, security level or organization. The other side is, again, relationship-based and uses graphs to determine access.

Note that the set-based approaches are all prone to rule “explosions”: over time, the number of sets increases to the point where it eventually becomes very difficult to certify with certainty the access of subjects to all resources.

Set-Based Models

We find here:

• Role-Based Access Control (RBAC): in use since its creation in 1992 by NIST researchers, this is still to this day the most popular (by far) Access Control model. Users are placed in roles; each role is granted a set of entitlements over resources.

• Lattice-Based Access Control (LBAC): Uses the mathematical concept of lattices to define the levels of security a subject may have and may be granted access to. The Subject can thus only access any given Resource if their security level is greater than or equal to that of the protected resource.

Relationship-Based Models

Here we find only ReBAC, which can also be used with centralized control. Generalizing in a graph is easily done by just adding intermediary nodes. Adding extra hops can make ReBAC less fine-grained and, hence, easier to handle and manage.

How to choose?

Figure 2 below represents a decision tree that can be used to help choose the right model. Simply answer some basic questions to follow a path in the tree to a leaf node.

Figure 2 – An Authorization Decision Tree

Conclusion

This publication is the authors’ attempt to provide a first cut of a taxonomy model for authorization. Without taxonomy, we’re explorers without a map, scientists without a method. It brings order to chaos and meaning to complexity. As the saying goes, all models are wrong, but some are useful; we hope that readers will find the taxonomy model useful in disambiguating some commonly used terms, putting them in context, and simplifying complexity. We fully expect the taxonomy and the decision tree to evolve over time to meet the needs of the changing technology, threat, and business landscape. The accompanying decision tree can be a very useful tool in the Identity professional’s toolkit to aid in the selection of an authorization model that is appropriate for the business case. So the next time you are wondering which authorization model to select for your application, go ahead and use the taxonomy and the accompanying decision tree to guide your selection.

Authors

Alex Babeanu

 Alex leads the research and development of 3Edges, which created the best and easiest to use Graph platform on the market, specifically built for graph-aware dynamic authorization. His past experience includes building pieces of the Oracle Identity Manager server as a Principal at Oracle, and over 10 years spent as a consultant in the field, architecting many solutions for public and private organizations in all verticals.  Alex holds an MSc in Knowledge Based Systems from the University of Edinburgh, UK, and is an avid Sci-Fi enthusiast.

Tariq Shaikh

Tariq is an Identity Architect, Director & Distinguished Engineer at Capital One. He has 25 years of technology experience and a passion for developing innovative technology solutions to solve cybersecurity problems. Prior to Capital One, Tariq led the Cloud Identity & Access Management (IAM) and Privileged Access Management (PAM) initiatives at CVS Health.  He started his career as a software developer before taking on cybersecurity leadership & advisory roles. He speaks and posts extensively about Identity & Access Management topics.

The post A Taxonomy of Modern Authorization Models appeared first on IDPro.

Announcing AuthZEN

AuthZEN is the OpenID Foundation’s latest working group and its purpose is to provide standard mechanisms, protocols, and formats to communicate authorization-related information between components within one organization or across organizations.

Several individuals got together at Identiverse to discuss what standardizing authorization could look like and how to achieve what we dubbed the ‘OAuth moment’, a time when adoption was inevitable and led to massive growth for OAuth. The AuthZEN WG, of which I’m a co-chair along with Allan Foster, Gerry Gebel, and Andrew Hughes, has three main goals:

1. Increase interoperability between existing standards and approaches to authorization
2. Standardize interoperable communication patterns between major authZ components
3. Establish design patterns to promote the use of externalized authorization.

Our peers, Atul Tulshibagwale (SGNL) and Omri Gazitt (Aserto) gave an excellent presentation on the goals of the AuthZEN WG prior to IIW, during the OpenID Foundation session. Check out the slides here.

Launching “403Con”

Am I even allowed to talk about this initiative? On day 1 of the conference, we all piled into “Space F” to discuss what it would look like to run a conference solely dedicated to authorization. In the vein of “Authenticate” but for everything access control. Truth be told, there are so many new ways to address authorization from NIST’s attribute-based access control (ABAC) to 3Edges’ Graph-based approach, access control lists (Zanzibar-style), and more. We want everyone to come and chime in (no pun intended) so if you can spare a few cycles, join us here or reach out in the #authorization channel on IDPro’s Slack.

Authorization-related Talks

Out of the 163 or so sessions, there were several dedicated to authorization.

• Darin McAdams of AWS gave an introduction to the Cedar Policy Language, a new open-source approach to attribute-based access control. It sits between Open Policy Agent’s Rego and Axiomatics’ ALFA in terms of expressibility. You can learn more about the language in their playground.
• Eve Maler (my XML superhero) gave a 101 talk on User Managed Access (UMA) called ‘Get to know this unique “application of OAuth.”’ This is truly fundamental as oftentimes, authorization is seen as enterprise or compliance-driven when in fact it can be user and consent-driven. UMA helps enable consent collection on top of existing OAuth flows. The purpose of the protocol specifications is to “enable a resource owner to control the authorization of data sharing and other protected-resource access made between online services on the owner’s behalf or with the owner’s authorization by an autonomous requesting party.”
• Omri Gazitt of Aserto gave a 101 introduction to Externalized Authorization, its building blocks, and its evolution over the years.
• Justin Richer (the notorious author behind Cards Against Identity) gave an introduction to GNAP 101: GNAP (Grant Negotiation and Authorization Protocol) is an in-progress effort to develop a next-generation authorization protocol. It is an identity-centric approach to authorization
• Eve Maler hosted an epic battle between Camp “PDP & PEP” vs. Camp “AS/RS” leading to a hilarious smackdown. It’s true that ABAC, XACML, and Externalized Authorization have systematically referred to PEP/PAP/PDP. The session explored how these concepts map back to OAuth’s more familiar AS/RS terminology. Conclusion? There’s definitely room for interoperability and integration.
• Gerry Gebel and Phil Hunt spoke about the state of Identity Management Policy Interoperability and in particular IDQL (Identity Query Language), a declarative access policy and set of APIs that enables the mapping of a centrally managed policy into the native format of multiple clouds and application platforms.
• Mark Berg, my colleague at Axiomatics, presented the latest on the Abbreviated Language for Authorization (ALFA), OASIS’s standard for fine-grained authorization. You can read more on ALFA’s Wikipedia page.
• The Graph Extraordinaire Alex Babeanu spoke about Identity being a… … Graph Problem.
• Lastly, Omri Gazitt gave a demo of TOPAZ, an open-source authorization framework that takes the best of Open Policy Agent with features of Zanzibar/ACLs to deliver a new approach to authorization.

There were a couple of other sessions that tie back to authorization such as:

• Pam Dingle’s Minimum Interoperability Profile for ACR (authentication context). If we can all agree on ACR values, they can become attributes in a dynamic authorization decision-making process. 
• George Fletcher’s Transaction Tokens Authorization for Multi-workload Environments. Can externalized authorization help solve the over-provisioned token use case?

I’m ever so happy to see the evolution of the IAM landscape and the growing importance of authorization. As a standards advocate, I’m keen to develop more bridges between standards to address our industry-wide challenges. Feel free to join the conversation in the #authorization channel on IDPro’s Slack.

Author

David Brossard

Chief Technology Officer, Axiomatics

In his role as CTO, David drives the technology vision and strategy for Axiomatics based on both identity and access management (IAM) market trends as well as customer feedback. He also leads the company’s strategy for standards and technology integrations in both the IAM and broader cybersecurity industries. David is a founding member of IDPro, a co-author of the OASIS XACML standard, and an expert on standards-based authorization as part of an overall IAM implementation. Most recently, David led the design and development of Salesforce’s identity offering, including customer identity and access management (CIAM) solutions.

The post Authorization at IIW37 appeared first on IDPro.