What is AuthZEN?

AuthZEN (AuthZ ENhancement) is a crucial initiative by the OpenID Foundation that aims to standardize fine-grained authorization, much like OpenID Connect revolutionized authentication. The core idea is to create interoperability between various authorization components, primarily Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs).

The IndyKite platform is inherently designed to deliver modern, intelligent authorization, and its embrace of AuthZEN further strengthens its value proposition.

1. Interoperability and vendor neutrality:

• Problem: The current authorization landscape is highly fractured. Different vendors and internal systems often use proprietary APIs, protocols, and policy languages for authorization. This leads to vendor lock-in and significant integration challenges when trying to unify authorization across an enterprise.

• AuthZEN's Solution: AuthZEN seeks to establish a standardized communication protocol between Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs). This means an application (PEP) can query any AuthZEN-compliant PDP for an authorization decision, regardless of the underlying policy engine or vendor. This promotes interoperability, allowing organizations to mix and match authorization solutions and avoid being tied to a single vendor. By providing a universal interface, AuthZEN makes it easier to integrate diverse authorization systems, fostering a more flexible and adaptable security infrastructure.

• IndyKite is committed to open standards, and its support for AuthZEN demonstrates this. This commitment ensures that organizations are not locked into proprietary solutions and can leverage IndyKite advanced capabilities alongside other AuthZEN-compliant components.

  IndyKite provides a future-proof authorization solution. By adhering to AuthZEN, it allows enterprises to build an interoperable authorization ecosystem, reducing the risk of vendor lock-in and maximizing their existing technology investments.

2. Simplified development and reduced complexity:

• Problem: Developers often have to "reinvent the authorization wheel" for each application, leading to inconsistent implementations, security vulnerabilities, and increased development time.

• AuthZEN's solution: By standardizing the authorization request and response formats (JSON-based), AuthZEN provides a clear and consistent way for applications to interact with authorization services. It defines core entities like subject, action, resource, and context, making authorization requests predictable.

• By offering an AuthZEN-compliant Authorization API, IndyKite simplifies the integration for developers. Instead of learning IndyKite's specific API, they can use the standardized AuthZEN interface, significantly reducing the learning curve and time to market for new applications and features.

3. Externalized Fine-Grained Authorization:

• Problem: Embedding authorization logic directly into applications (coarse-grained, often role-based access control) makes it difficult to manage, update, and audit. As applications become more complex and require fine-grained access control (e.g., "Can Alice view this specific document at this time?"), this embedded logic becomes unscalable and prone to errors.

• AuthZEN's Solution: AuthZEN promotes the externalization of authorization, moving policy evaluation to dedicated PDPs. This enables dynamic, real-time, and fine-grained authorization decisions based on subject, resource, action, and context. It supports various authorization models and relationship-based authorization.

  Externalizing authorization through AuthZEN enables a centralized, consistent, and highly granular approach to access control. This reduces the burden on individual application developers, improves security by enforcing the principle of least privilege, and enhances auditability and compliance by providing a single pane of glass for policy management.

• Knowledge-Based Access Control (KBAC) and fine-grained authorization: IndyKite core strength lies in its Identity Knowledge Graph, which models identities, resources, and their relationships. This graph-based approach is perfectly suited for complex, fine-grained authorization scenarios. AuthZEN's standardized API allows IndyKite's PDP to receive requests with rich contextual data, enabling its graph-based engine to make precise, real-time access decisions that go far beyond traditional RBAC.

  Instead of rigid, pre-defined roles, IndyKite, leveraged through an AuthZEN interface, allows for dynamic policies based on relationships, attributes, and real-time context. This means access can be granted or denied not just based on "who you are," but "who you are, what you're trying to do, with what, from where, and why."

• IndyKite promotes the externalization of authorization logic from applications. Its platform acts as a centralized Policy Decision Point (PDP) and Policy Administration Point (PAP). By supporting AuthZEN, IndyKite makes it even easier for diverse applications (PEPs) to integrate with its powerful authorization engine.

  With IndyKite acting as an AuthZEN-compliant PDP, organizations can manage all their authorization policies in a single, unified location. This eliminates the need for developers to embed authorization logic in every application, speeding up development and ensuring consistency across the entire digital estate.

4. Enhanced security and compliance with real-time contextual decisions:

• Problem: Inconsistent authorization across an enterprise creates security gaps and makes it challenging to demonstrate compliance with regulations. Manual processes for access review are tedious and error-prone.

• AuthZEN's Solution: AuthZEN enables continuous authorization enforcement, dynamic separation of duties, and a clear audit trail of access decisions. The standardization facilitates consistent application of policies and makes it easier to prove compliance.

  AuthZEN directly contributes to a stronger security posture by enforcing consistent policies, enabling real-time access decisions, and improving the ability to audit and demonstrate compliance with security regulations.

• Real-time contextual decisions: The IndyKite Identity Knowledge Graph continuously updates with real-time data, enabling dynamic and adaptive access decisions. When an AuthZEN request comes in, IndyKite can leverage this rich, up-to-date context to make highly accurate authorization judgments.

  The IndyKite ability to incorporate real-time context into AuthZEN requests means authorization decisions are always relevant and up-to-date, supporting dynamic policies like "least privilege" and "zero trust."

In conclusion, the core argument for using AuthZEN is its promise to revolutionize authorization by bringing much-needed standardization and interoperability to a fragmented landscape. It aims to simplify the development of secure applications, enable truly fine-grained and dynamic access control, and improve overall security and compliance for organizations of all sizes. IndyKite, with its advanced Knowledge-Based Access Control and commitment to open standards, provides a compelling solution that not only meets the promise of AuthZEN but also elevates authorization to a truly intelligent, dynamic, and business-enabling capability.

AuthZEN Authorization Request Example (JSON Payload):

POST https://eu.api.indykite.com/access/v1/evaluation or https://us.api.indykite.com/access/v1/evaluation

{
	"subject": {
		"type": "User",
		"id": "alice@example.com",
	},
	"resource": {
		"type": "Document",
		"id": "project_alpha_specs.pdf",
	},
	"action": {
		"name": "CAN_READ",
	},
	"context": {
	 "input_params": {
			"ip_address": "192.168.1.100",
			"time_of_day": "14:30:00Z",
			"device_type": "laptop"
			}
	}
}

Explanation:

• subject: This identifies who is trying to perform the action.
  • type: "user" indicates a human user. The IndyKite Identity Knowledge Graph would hold a detailed "digital twin" of this user, including their attributes and relationships.
  • id: "alice@example.com" is the unique identifier for Alice

• resource: This identifies what is being accessed.
  • type: "document" categorizes the resource. The IndyKite graph can represent various resource types.
  • id: "project_alpha_specs.pdf" is the unique identifier for the document.

• action: This defines the intended operation on the resource.
  • name: "can_read" is a common action type. AuthZEN pre-defines some common actions, but you can use custom ones.

• context: This provides additional environmental or contextual data.
  • ip_address, time_of_day, device_type: These are examples of contextual information that can influence authorization decisions.
  • IndyKite excels at incorporating such dynamic context into policies. For instance, a policy could deny access if the ip_address is from an untrusted network or outside of business hours.

How IndyKite AuthZEN would use this:

When an AuthZEN request like the one above is received by the IndyKite PDP, it would:

1. Map Request to Graph Entities: The subject, resource, action, and context information would be used to identify corresponding nodes and relationships within the Identity Knowledge Graph. For example, "alice@example.com" maps to Alice's user node, and "project_alpha_specs.pdf" maps to the document node.

2. Evaluate Policies: The IndyKite KBAC policies are defined in terms of relationships and attributes within this graph. The PDP would traverse the graph and evaluate these policies against the real-time data provided in the AuthZEN request and the existing graph data.
   • Example Policy Logic (conceptual):
     • "Allow User to CAN_READ Document IF User IS_MEMBER_OF Team AND Document IS_ASSIGNED_TO Project AND Team IS_ASSIGNED_TO Project AND Document.sensitivity IS NOT confidential OR (Document.sensitivity IS confidential AND User IS_MANAGER_OF Team)"
     • "Deny User to CAN_READ Document IF context.ip_address is NOT trusted_network."

3. Return Decision: Based on the policy evaluation, The IndyKite PDP would return an AuthZEN-compliant response, typically containing a decision (true/false for allow/deny) and optionally a context with reasons for the decision.

AuthZEN Authorization Response Example (JSON Payload):

{
  "context": {
    "advice": [
      {
        "error": "insufficient_user_authentication",
        "error_description": "Authentication is expired",
      }
    ]
  },
  "decision": false
}

This example illustrates how AuthZEN provides a standardized format for authorization requests, and how IndyKite, with its underlying knowledge graph, can leverage this rich information to make dynamic and fine-grained authorization decisions based on complex relationships and context.

AuthZEN Authorization Request Example for evaluations:

POST https://eu.api.indykite.com/access/v1/evaluations or https://us.api.indykite.com/access/v1/evaluations

{
  "action": {
    "name": "CAN_READ"
  },
  "context": {
    "input_params": {
      "additionalProp1": {},
      "additionalProp2": {}
    },
    "policy_tags": [
      "Tag1",
      "Tag2"
    ]
  },
  "evaluations": [
    {
      "action": {
        "name": "CAN_READ"
      },
      "context": {
        "input_params": {
          "additionalProp1": {},
          "additionalProp2": {}
        },
        "policy_tags": [
          "Tag1",
          "Tag2"
        ]
      },
      "resource": {
        "id": "IdSpecifyingTheNode",
        "type": "NodeType"
      },
      "subject": {
        "id": "IdSpecifyingTheNode",
        "type": "NodeType"
      }
    }
  ],
  "resource": {
    "id": "IdSpecifyingTheNode",
    "type": "NodeType"
  },
  "subject": {
    "id": "IdSpecifyingTheNode",
    "type": "NodeType"
  }
}

Explanation:

The parameters before evaluations are default values to reduce redundancy:

JSON Field	Status	Description
subject	Optional	The default subject for all evaluations in the list. This is useful for evaluating requests made by the same user to different resources. If a specific evaluation needs a different subject, it must be defined within that evaluation's object.
resource	Optional	The default resource for all evaluations. Overridden by the resource in an evaluation object.
action	Optional	The default action for all evaluations. Overridden by the action in an evaluation object.
context	Optional	The default context for all evaluations. Overridden by the context in an evaluation object.
evaluations	Required	A list of individual evaluation objects. This is the key field for batching requests.