Security Scopes and Profiles for Environment-Independent Application Deployment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional security infrastructures in computing systems lack flexibility and require developers to know the environment, leading to either all messages being secured or none, and often necessitate access to source code and sensitive information.
Innovation Solution
A security system that uses scopes to identify types of information to be secured and profiles to specify how they are secured, allowing for selective and environment-independent security configurations, with scopes defined by developers and profiles by deployers/administrators, enabling automated discovery and compliance with security policies.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional security infrastructure is implemented by developer writing application code, then security requirements can be satisfied, but developer must accurately know the environment and access source code is required
Solution Approach 1:
The patent extracts security configuration from application source code into separate security policy files. The security infrastructure is separated into: (1) security scopes defining what information needs protection, (2) security profiles defining how to protect it, and (3) bindings mapping scopes to profiles. This extraction eliminates the need for developers to embed environment-specific security logic in code, while still satisfying security requirements through external policy enforcement.
Solution Approach 2:
The security infrastructure is segmented into distinct components: scopes (identifying information types to secure), profiles (specifying security mechanisms), and bindings (mapping between them). This segmentation allows developers to define scopes independently of deployment environment, while administrators configure profiles and bindings separately, eliminating the contradiction between meeting security requirements and reducing developer burden.
2Reliability
If security infrastructure is configured to secure all messages, then comprehensive security is achieved, but flexibility and selectivity are reduced
Solution Approach 1:
The patent applies local quality by enabling different security policies for different types of information through scopes. Each scope identifies specific information types (e.g., personal data, financial information) and maps them to appropriate security profiles. This allows the system to apply comprehensive security where needed while avoiding unnecessary security overhead for other information, achieving both comprehensive coverage and selectivity.
Solution Approach 2:
The security infrastructure becomes dynamic through the scope-profile-binding model. Scopes can be selectively applied to different messages based on their content type, and profiles can be dynamically selected through bindings. This dynamic approach allows the system to adapt security application to each message's requirements, achieving comprehensive security coverage while maintaining flexibility and selectivity.
3Adaptability or versatility
If environment-specific security configurations are used, then security can be tailored to deployment context, but same application binary cannot be used across multiple environments
Solution Approach 1:
The patent achieves universality by designing scopes to be environment-independent. Scopes define what information needs protection without referencing specific deployment environments. The same application binary with embedded scopes can be deployed across multiple environments, with each environment's administrator configuring appropriate profiles and bindings locally. This allows environment-specific tailoring without requiring different application binaries.
4Adaptability or versatility
If developer defines security policies with environment knowledge, then security can be customized, but access to sensitive information about users and systems is required
Solution Approach 1:
The patent extracts sensitive security configuration information from developer code and places it in external policy files controlled by administrators. Developers define only high-level scopes (what to protect) without accessing sensitive user or system information. Administrators who do have access to sensitive information configure profiles and bindings separately, eliminating the need for developers to handle sensitive data while still enabling customized security policies.
Data Source
AI summary
A security system with a mechanism to identify types of information that need to be secured and another mechanism to specify how the types are to be secured. The system includes a sender having an application and a receiver having a security module and one or more datastores to store information related to types of information that need to be secured (e.g. “scopes”), how information is to be secured (e.g., “profiles”), and a mapping (e.g., “bindings”) between the scopes and profiles. Scopes can be implemented by application developers. Profiles can be implemented by application deployers and/or administrators. The security module determines which scope is appropriate for the message, and then determines the profile that is mapped to the scope. The security module can then make an access control decision using the profile.