Selective Multi-Factor Authentication via Identity Provider Adapter

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Implementing multi-factor authentication in native applications is challenging due to the need for custom code or software development kit integration, making it impractical for organizations managing devices to require this enhanced security measure.

Innovation Solution

Extending single sign-on systems on managed devices with a multi-factor authentication adapter, allowing administrators to selectively enable multi-factor authentication based on device and network conditions, using an identity provider to manage authentication across various applications and services.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If multi-factor authentication is implemented in native applications using custom code or software development kit, then security is improved, but device complexity and implementation difficulty increase

Engineering Contradiction:
ImprovesecurityVSAvoidimplementation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an identity provider as an intermediary component that handles multi-factor authentication. Instead of requiring developers to implement complex MFA code directly in native applications, the identity provider serves as a mediator that manages authentication factors, tokens, and verification processes. This allows existing single sign-on infrastructure to be extended with MFA capabilities without requiring developers to write custom authentication code, thus improving security while avoiding the complexity burden.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If multi-factor authentication is required for all applications, then security is improved, but ease of operation deteriorates due to additional authentication steps

Engineering Contradiction:
ImprovesecurityVSAvoiduser convenience
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent implements selective multi-factor authentication where MFA is not required for all applications and all users, but only for specific applications, users, or authentication scenarios based on risk assessment. The system can determine when MFA is necessary and apply it selectively, rather than universally. This partial application of MFA maintains security for high-risk scenarios while preserving user convenience for low-risk scenarios, thus improving security without uniformly degrading ease of operation.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The patent introduces dynamic authentication policies that can adapt MFA requirements based on various factors such as user behavior, device status, network conditions, and application sensitivity. The system can dynamically adjust whether MFA is required, what type of MFA factors are needed, and when additional verification is necessary. This dynamic approach allows the system to optimize between security and user convenience in real-time based on actual risk conditions rather than applying static MFA rules universally.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS10432608B2Selectively enabling multi-factor authentication for managed devices
Publication Date: 2019.10.01 OMNISSA LLC
  • US10432608B2 patent drawing
  • US10432608B2 patent drawing
  • US10432608B2 patent drawing

AI summary

Disclosed are various examples of selectively enabling multi-factor authentication for applications on managed devices. An identity provider receives an authentication request for a first client application executed in a managed client device. The authentication request includes a first authentication factor corresponding to a management credential. The identity provider then determines whether one or more second authentication factors should be requested. If so, the identity provider then requests the second authentication factor(s) from a second client application. The identity provider receives the second authentication factor(s) from the second client application. The identity provider then authenticates the first client application in response to verifying the first authentication factor and the second authentication factor(s).