GSSAPI Security Token Extension for Third-Party Authorization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Generic Security Service Application Program Interface (GSSAPI) does not allow processes to add non-OS authorization data to the security token exchanged between client and server processes, preventing third-party authorization features like role-defining processes from functioning correctly across security contexts.
Innovation Solution
A detection and alteration layer, or 'hook', is added within the GSSAPI interface to intercept and modify security tokens, allowing non-OS authorization data to be added to the security token on the client computer and removed on the server computer, making this data available to third-party processes for extending user authorization.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the GSSAPI security token is used to transmit authorization data between client and server processes, then user authentication and authorization are extended across computers, but processes cannot add their own non-OS authorization data to the security token
Solution Approach 1:
The security token is segmented into distinct components: OS authorization data and non-OS authorization data. The patent creates separate data structures within the token to hold different types of authorization information, allowing processes to add their own authorization data without interfering with the existing OS authorization mechanism. This segmentation enables multiple authorization sources to coexist within the same security context.
Solution Approach 2:
The patent nests non-OS authorization data within the existing GSSAPI security token structure. Rather than creating a separate communication channel or modifying the core GSSAPI protocol, the solution embeds additional authorization data structures inside the token itself, similar to nested dolls. This allows the token to carry both OS and non-OS authorization data through the existing security infrastructure.
2Ease of operation
If processes negotiate their own connection to transmit non-OS authorization data, then authorization data can be transmitted, but the extended user session cannot always facilitate this connection
Solution Approach 1:
The patent merges the transmission of non-OS authorization data with the existing GSSAPI security context establishment process. Instead of requiring processes to negotiate separate connections, the solution combines authorization data transmission with the security token exchange that already occurs during normal GSSAPI operation. This merging ensures reliable delivery since the token exchange is already guaranteed by the security infrastructure.
Solution Approach 2:
The GSSAPI security token acts as an intermediary carrier for non-OS authorization data. Rather than processes directly exchanging authorization information through separate connections, the token mediates the transmission by encapsulating non-OS authorization data within its structure. This intermediary approach leverages the existing reliable security infrastructure to ensure data delivery.
3Reliability
If the GSSAPI security protocol is used to extend user authentication, then secure communication is established between computers, but third-party authorization processes cannot function correctly
Solution Approach 1:
The patent adds another dimension to the security token structure by introducing a new layer for non-OS authorization data. Rather than modifying the fundamental GSSAPI protocol or compromising security, the solution extends the token into a new dimensional space where third-party authorization data can reside. This allows the existing security mechanism to remain intact while accommodating additional authorization sources.
Solution Approach 2:
The security token is made universal by enabling it to carry multiple types of authorization data simultaneously - both OS authorization data and non-OS authorization data from third-party processes. This multi-functionality allows the same security infrastructure to support diverse authorization sources without requiring separate mechanisms for each type of authorization.
Data Source
AI summary
A system and method for using a GSSAPI security token to transport additional non-GSSAPI data that includes authorization data used by third-party software. The system includes a hook that intercepts a client process's interactions with the GSSAPI. When a client process requests a security context from the GSSAPI, the hook intercepts the security token the GSSAPI provides for the client process. The hook checks to see if there is additional authorization data to transport, adds the additional data to the security token, then gives the token to the client process. The client process sends the security token to the server process, which submits the token to the GSSAPI for evaluation. A hook on this computer intercepts the security token, removes additional data added earlier, gives the added authorization data to a version of the third-party authorization software, then passes the now-unaltered security token to the server process which uses the security token to finish establishing a security context with the client process.