Head of Standards for Layer identityformer Burton Group analyst and technology executive at Chase Manhattan Bank (now JPMorgan Chase);
Zero-trust networking principles have permeated every area of identity and access management (IAM), particularly external authorization systems. The concept of verifying each access request to a protected resource is a common function for an authorization service, as each request is evaluated against the current access policies.
With the need for users to access any data and resources from any device and any location, it is also imperative to ensure that access control policies are implemented and enforced accurately—and this is where authorization systems excel. As a result, the acceptance of licensing systems is increasing. The market for external identity-based authorization systems will grow $19.4 billion by 2024according to Verified Purchase Reports.
Unfortunately, the products in this growing market are not interoperable with each other. A new working group at the OpenID Foundation—Authorization Exchange, or AuthZEN—has been created to support the growth of this fragmented marketplace by promoting interoperability. I was among the 11 individuals/organizations that submitted the AuthZEN map and currently serve as one of the four co-chairs.
The group was created as a result of informal discussions among vendors regarding standardization efforts in the field of authorization. In this article, I will use AuthZEN as a starting point to explore how this kind of interoperability could streamline and simplify the process of implementing authorization systems, eliminate the problem of excessive privileges, and deliver real-time authorization.
The Role of Authorization Interoperability
Almost all licensing products, whether standards-based or proprietary approaches, implement a similar architecture. Industry standards such as XACML (an OASIS standard) promote an architecture that separates access decision logic from business application code.
While XACML-based systems can be interoperable with each other, they are not interoperable Open Policy Agent (OPA) exclusive license systems or products. OPA is a CNCF curriculum that is popular for managing access to infrastructure services and implements its own policy language called Rego.
Here’s a more technical look at the problem: First, access policies are written for the authorization product through some form of management interface. Rules such as “sales managers can see reports for their region” or “design engineers can update schematics for the product line(s) they are assigned to” are loaded into the runtime evaluation engine, often called a point policy decision (PDP).
When users interact with an application, the application can generate an access request and send it to the PDP for a decision (permission or denial, typically)—this part of the application is referred to as a policy enforcement point (PEP). Using this flow, the developer can leverage an external authorization service instead of writing this access logic in the business application.
Here are three areas AuthZEN is currently focusing on related to this authorization workflow:
• The first is to define a standard for the communication flow between the enforcement point and the decision engine—between the PEP and the PDP. AuthZEN already has a draft specification in progress for this focus area.
• The second area of focus is a standard for communicating access policies to the PDP once they have been defined. This could allow a policy management function to interoperate with multiple decision engines.
• The third is broader and involves identifying and documenting common usage patterns and recommended best practices. AuthZEN wants to highlight the value of using external authorization systems and recommend this approach as the default methodology for application developers.
Overall, achieving interoperability in a market that is currently fragmented and fragmented could have many benefits. The very existence of recognized standards will convey a sense of legitimacy to all stakeholders, including vendors, potential customers, and even investors. With improved interoperability, outsourcing products could also be more easily developed and consumed by customers.
Developers could also benefit by not having to worry about who receives an authorization request. There will be a format they need to learn to call an external authorization service. All requests will be processed the same way and the response message will always be returned in the same predictable format.
What’s Next for Authorization Interoperability?
No other group or consortium has previously stepped forward to address this authorization interoperability challenge. However, there is momentum and attention in the licensing space that is more intense and focused than in previous years.
Obviously, industry-wide collaboration between third-party vendors of authorization products will be critical to advancing standardization. There will be roadblocks and disagreements along the way as participants debate the merits of different approaches. For example, here are some of the hurdles the industry will need to overcome for interoperability to be successful:
1. A sufficient number of vendors will need to implement product changes in a reasonable amount of time. What will it look like if one or two major suppliers are out of alignment?
2. It may be difficult for some suppliers to adapt their products to the new specifications. For example, AuthZEN aims to have an interoperability demo at a major conference in 2024—would enough vendors be ready by then?
That said, compromises are a natural part of any standardization process, as has been demonstrated in many industry efforts over the years (such as OpenID Connect).
The success of interoperability would be the development of specifications that a broad set of authorization vendors are willing and able to implement in their products.
Broad appeal to authorization vendors is important to avoid fragmenting the standardization process (see the early days of the federated single connection). Interoperability specifications should also be addressed to others in the industry, such as application architects, application developers, and security professionals.
Leaders in the licensing space are encouraged to bring their use cases to the table to ensure the widest possible coverage of requirements. The ultimate goal will be achieved when the majority of application developers and product managers leverage the new interoperability profiles in their products and services.