Dynamic Access Ticket Network Security System

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional network security solutions are inadequate in protecting enterprise applications from security breaches, especially in zero trust environments where static tokens and information are vulnerable to compromise.

Innovation Solution

A network security system that implements dynamic access control using run-time contextual information and generates access tickets based on application context, combined with policy enforcement actions via API to block policy violations effectively.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If static tokens are used for access control, then ease of operation is improved, but security reliability deteriorates

Engineering Contradiction:
Improveaccess control operationVSAvoidsecurity reliability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent transitions from static tokens to dynamic access tickets that are generated at runtime based on contextual information. The access ticket includes dynamic elements such as transaction IDs, session information, and time-sensitive data that change with each access request, making compromised tickets useless for continuous unauthorized access while maintaining operational simplicity through automated generation and validation.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the parameters of access control from fixed static tokens to dynamic tickets with multiple changing parameters including transaction IDs, session identifiers, timestamps, and contextual attributes. These parameters are generated and validated in real-time, ensuring that even if one parameter is compromised, the access control remains secure due to the combined complexity of multiple dynamic parameters.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If contextual information is evaluated for access control, then security reliability is improved, but device complexity increases

Engineering Contradiction:
Improveaccess control securityVSAvoidaccess control system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent performs preliminary actions by pre-generating access tickets with embedded contextual information before the actual access request occurs. The ticket includes pre-evaluated security context, user attributes, and transaction details that are validated automatically during access, eliminating the need for complex real-time contextual evaluation while maintaining high security reliability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary access ticket mechanism that mediates between the user and the protected resource. The ticket encapsulates all contextual information and security evaluations, serving as a self-contained credential that simplifies the access control process while incorporating comprehensive security checks, thus reducing overall system complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If dynamic access tickets are generated using run-time information, then security reliability is improved, but loss of time increases

Engineering Contradiction:
Improveaccess control securityVSAvoidaccess ticket generation time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent performs preliminary generation of access tickets with all necessary contextual information embedded before the access request is processed. This pre-computation approach ensures that during the actual access operation, only simple validation is required, minimizing time loss while maintaining dynamic security based on runtime information.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent creates access tickets as self-contained copies of the necessary authentication and authorization data, including user context, transaction information, and security attributes. This copying mechanism allows the ticket to be validated independently without requiring repeated access to the original contextual sources, significantly reducing validation time while maintaining security.

Inventive Principle:
Principle #26Copying

4Reliability

If policy enforcement actions are implemented via API, then security reliability is improved, but device complexity increases

Engineering Contradiction:
Improvepolicy enforcementVSAvoidsystem integration complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a universal API-based policy enforcement mechanism that can handle multiple policy types and enforcement actions through a single standardized interface. The API provides multi-functional capabilities for generating, validating, and enforcing access policies across different resources and contexts, reducing system integration complexity while maintaining comprehensive security enforcement.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS12335252B2Network security dynamic access control and policy enforcement
Publication Date: 2025.06.17 IMPERVA INC
  • US12335252B2 patent drawing
  • US12335252B2 patent drawing
  • US12335252B2 patent drawing

AI summary

A network security system and method provide dynamic access control for a protected resource using a client-initiated ticket generation scheme. A client application receives, from an access control manager, a limited-use access ticket and may include the limited-use access ticket within application program interface (API) calls to a service application. The service application may forward the limited-use access ticket as a service access ticket to a ticket-based access control layer. A transaction monitor monitors run-time transaction information generated by the API calls to the service application and if the limited-use access ticket is detected in the run-time transaction information, forward the limited-use access ticket to the access control manager to perform validation of the limited-use access ticket. The ticket-based access control layer compares the service access ticket to the validated limited-use access ticket and determine whether to grant the client application access to the protected resource based on the comparison.