Dynamic Identity Provider Discovery via Request Mapping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In federated computing environments, service providers face challenges in determining the appropriate identity provider (IdP) for user authentication, especially when multiple IdPs are available, often requiring administrator configuration and explicit user action for correct IdP selection.
Innovation Solution
A service provider builds a mapping table of request attributes to IdP instances based on normal IdP-initiated flows, allowing it to dynamically select an IdP for new requests without administrator configuration, by learning the relationships between incoming requests and appropriate IdP instances.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If traditional WAYF or OASIS identity provider discovery services are used, then explicit user action is required to select the appropriate IdP, but this increases operational complexity and user burden
Solution Approach 1:
The service provider automatically discovers and selects the appropriate identity provider by analyzing request attributes (such as user agent, IP address, referrer URL) without requiring explicit user action or administrator configuration. The system learns from normal IdP-initiated flows and builds a mapping table to autonomously route future requests.
Solution Approach 2:
The service provider pre-builds a mapping table during normal IdP-initiated authentication flows by observing the relationship between request attributes and the originating IdP. This preliminary learning phase enables automatic IdP selection for subsequent user-initiated requests without requiring real-time configuration or user intervention.
2Extent of automation
If commercial products like IBM TFIM are used to provide automatic IdP selection, then administrator configuration and deep awareness of patterns are required, but this increases implementation complexity
Solution Approach 1:
The service provider autonomously builds and maintains the IdP mapping table by automatically observing authentication flows and extracting patterns from request attributes. No administrator configuration, rule-setting, or pattern analysis is required - the system self-configures through passive observation of normal operations.
Solution Approach 2:
The mapping table is constructed in advance through continuous observation of IdP-initiated authentication flows. The system learns the relationship between various request attributes and originating IdPs during normal operations, preparing the knowledge base before any user-initiated SSO requests require IdP selection.
3Reliability
If static rule sets are used for IdP discovery, then administrator maintenance is required, but this increases operational overhead
Solution Approach 1:
The IdP mapping table is dynamically built and updated through continuous observation of authentication flows. The system adapts to changes in the federated environment automatically, learning new IdP patterns and relationships without requiring static rule updates or administrator intervention.
Solution Approach 2:
The service provider continuously monitors IdP-initiated authentication flows and uses this feedback to refine and update the mapping table. The system learns from actual operational data, improving IdP selection accuracy over time based on real-world patterns rather than static pre-configured rules.
Data Source
AI summary
An identity provider (IdP) discovery service operative at a service provider (SP) is described. In operation, and as valid requests are received by the SP via normal IdP-initiated flows, the SP builds-up knowledge about the relationship between the IdP (that redirected the request) and the initiator of the request. The IdP instance typically is inferred from an HTTP referrer field, and information about the initiator may be ascertained from client-specific information, such as client system IP address, client DNS domain, a domain of a user e-mail address, a target URL for the incoming request, or the value associated with a particular HTTP header field. This knowledge is maintained in one or more mapping table(s) that associate request attributes-to-IdP instance data. The mappings are then used to facilitate IdP discovery for a new incoming request to the SP that has been determined to originate from other than an IdP.