REST Client Domain Redirection via Intermediary Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing mechanisms for transitioning non-Web browser clients between different authentication domains are ineffective, particularly for Representational State Transfer (REST)-compliant clients that lack HTML processing capabilities and are redirected to servers requiring forms-based authentication.
Innovation Solution
A system that generates a redirection object with session and forms-based authentication information, allowing non-Web browser clients to authenticate using a separate HTML parser and obtain an authentication cookie for successful domain redirection.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a REST-compliant client is redirected to a server requiring forms-based authentication, then the client can access resources in a different authentication domain, but the client fails because it lacks HTML processing capability to handle forms-based authentication
Solution Approach 1:
The patent introduces a redirect server as an intermediary between the REST-compliant client and the target server requiring forms-based authentication. The redirect server receives the client's request, performs the forms-based authentication on behalf of the client by handling HTML forms, and then redirects the authenticated request to the target server. This intermediary approach allows the non-HTML-capable client to access resources in different authentication domains without needing native HTML processing capability.
2Ease of operation
If a Web browser is used to handle forms-based authentication, then HTML processing capability is available, but the solution is not applicable to non-Web browser REST clients
Solution Approach 1:
The redirect server provides universal authentication support that serves multiple types of clients. It can handle requests from both traditional Web browsers and REST-compliant non-browser clients, performing forms-based authentication for both. The server universally applies the same authentication mechanism (handling HTML forms) regardless of the client type, making the solution adaptable to different client architectures while maintaining ease of operation through centralized authentication handling.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An initial server responds to a request with a redirection object describing the a different server to which the request should be redirected, and providing additional information about authenticating to the other server. The redirection object includes a session check variable indicating whether a forms-based authentication process may need to be performed, a session URI through which the client may determine whether the client was previously authenticated to the other server, and optionally a forms URI through which the client may initiate a forms-based authentication process. If the session check variable indicates that the other server may require forms based authentication, and an authenticated session does not exist between the client and the other server, and the client has a forms URI for the other server, then the client opens a Web browser, and directs the Web browser to the forms URI to complete a forms-based authentication process.