Web Service Authorization Interceptor for Dynamic Policy Enforcement
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional approaches for providing access control for web services require modifications to the business logic code and re-compilation/restart of the runtime, making it cumbersome to change authorization policies without affecting the application's functionality.
Innovation Solution
Implementing a system that intercepts web service requests using an authentication interceptor to verify SAML tokens and an authorization interceptor with XACML, interacting with a Policy Information Point (PIP) and Policy Decision Point (PDP) to authorize requests without modifying the business logic, allowing for configuration of authentication and authorization at runtime.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional access control approaches are used requiring code modification, then authorization policies can be enforced, but the system requires re-compilation and restart of runtime making policy changes cumbersome
Solution Approach 1:
The system segments authorization policies from business logic code by introducing separate policy definition files and configuration mechanisms. Policies are stored externally in XML or other configuration formats, allowing them to be modified independently without touching the compiled business logic. This segmentation enables policy changes to be deployed without re-compilation or system restart.
Solution Approach 2:
An intermediary component (access control interceptor/enforcement point) is introduced between the client and business logic. This interceptor reads policies from external configuration files and enforces them dynamically, acting as a mediator that translates policy configurations into executable access control decisions without requiring modifications to the underlying business logic code.
2Ease of manufacture
If annotations are used to simplify code modification, then authorization can be implemented easier, but re-compilation and restart are still required
Solution Approach 1:
Authorization logic is extracted from the business logic package entirely. Instead of using annotations within code that require re-compilation, the system extracts authorization functionality into separate interceptor components that read from external configuration files. This extraction allows authorization policies to be modified and updated without any re-compilation process.
Solution Approach 2:
The system introduces dynamic policy loading where authorization rules are loaded from configuration files at runtime rather than being statically compiled into the code. This dynamic approach allows policies to be changed, added, or removed simply by modifying configuration files, with changes taking effect immediately without requiring system restart.
3Reliability
If callback methods are implemented for authentication, then authentication can be performed, but policy changes still require re-compilation and restart
Solution Approach 1:
An authentication interceptor acts as an intermediary between the client and business logic, handling all authentication operations. This interceptor reads authentication policies from external configuration files and performs authentication dynamically. Policy changes can be made by updating configuration files without any impact on the compiled business logic, enabling flexible authentication policy management.
Solution Approach 2:
The authentication system uses self-service configuration files that automatically define authentication behavior without requiring code changes. The interceptor reads these configuration files and automatically adjusts authentication policies based on the configured parameters, enabling the system to adapt to policy changes without human intervention in the code compilation process.
Data Source
AI summary
Systems and methods for authorizing web service requests. In some embodiments, a computer-implemented method includes receiving a web service request having an authorization header and business code, authenticating a Security Assertion Markup Language (SAML) token included in the authorization header and constructing a security context based on attributes of the SAML token. The process also includes passing the security context to an authorization interceptor to interact with a policy information point (PIP) and a policy decision point (PDP), receiving a permit response, and then authorizing the web services request. In some implementations, the requested web service is then transmitted to the client computer that requested the web service.