LDAP Broker Schema Abstraction for Virtualization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Virtualization systems face challenges in easily switching between different LDAP directory services due to vendor-specific schemas, query syntax, and authentication protocols, making it difficult to manage resources and communicate effectively across multiple domains.
Innovation Solution
The implementation of an LDAP broker that maintains mappings between object names, attributes, query syntax, and authentication protocols in a configuration file, allowing for schema and query abstraction, enabling seamless communication across different LDAP providers without the need for code recompilation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If vendor-specific LDAP directory services are used, then each provider can maintain its own schema and authentication protocols, but switching between different directory services becomes difficult and complex
Solution Approach 1:
The patent introduces an LDAP broker as an intermediary component that sits between the virtualization manager and multiple LDAP directory services. The broker maintains mappings between object names, attributes, query syntax, and authentication protocols for different providers. When the virtualization manager needs to access directory services, it does so through the broker, which handles the translation and communication with the appropriate LDAP provider, thereby simplifying switching between different directory services without requiring changes to the virtualization manager code.
2Adaptability or versatility
If different LDAP providers are supported, then the system can work with multiple vendors, but code recompilation is required to convert communications to appropriate schema and query syntax
Solution Approach 1:
The patent implements preliminary action by pre-configuring mapping information for multiple LDAP providers in the LDAP broker before runtime. The broker maintains a repository of mappings between object names, attributes, query syntax, and authentication protocols for different LDAP providers (e.g., Red Hat Directory Server, Microsoft Active Directory, Tivoli-DS). When a new LDAP provider needs to be used, the system can simply add the provider's mapping information to the broker's configuration, eliminating the need for code recompilation and allowing rapid adaptation to different vendors.
3Reliability
If vendor-specific schemas and query syntax are used, then each LDAP service can be optimized for its provider, but communication across multiple domains becomes error-prone
Solution Approach 1:
The LDAP broker serves as a mediator that translates between the virtualization manager's generic directory service requests and the provider-specific schemas and query syntax. The broker maintains accurate mappings between object names, attributes, and query formats for different LDAP providers. By handling all translation and adaptation through this intermediary, the system preserves provider-specific optimizations while eliminating communication errors across multiple domains, as the broker ensures proper syntax and format conversion for each target provider.
Data Source
AI summary
A lightweight directory access (LDAP) broker receives user information associated with a query for information in an LDAP repository. The query may be in an abstraction format. The LDAP broker determines a computing domain in view of the user information and retrieves a configuration file associated with the computing domain. The configuration file comprises a mapping for the query between an abstraction format and a vendor specific format. The LDAP broker converts the query to the vendor specific format in view of the mapping in the configuration file.