ZERO-TOUCH ALWAYS-ON USER AUTHENTICATION FROM TRUSTED MULTIMEDIA SOURCES

A method comprises: at an identity provider, upon receiving a request for authentication of a user to a target application that is hosted on a user device and into which the user has logged-in: identifying one or more biometric tests to be applied to the user to satisfy the request; selecting, from a list of application services that have trust relationships with the identity provider, an application service which has an active session with the user and supports the one or more biometric tests; requesting the application service to perform multifactor authentication that includes the one or more biometric tests; receiving, from the application service, biometric test results that indicate whether each of the one or more biometric tests passed or failed; and determining that the authentication has passed or failed based on the biometric test results.

TECHNICAL FIELD

The present disclosure relates to zero-touch user authentication using trusted multimedia sources.

BACKGROUND

Due to zero-trust authentication strategies, users of computer applications are prompted throughout their day with authentication prompts to access computer applications. Even with single sign on (SSO) to unify authentication control, and caching of authentication tokens on the client-side for a duration of time until expiry, authentication with multifactor authentication (MFA) has become burdensome to the user community. This results in context-switching away from the business tasks that the users intend to perform. Such context-switching is especially cumbersome when switching across devices (e.g., using an additional login from a mobile phone or iPad, or for embedded logins such as within a collaboration chat application for a productivity suite integration), which presents an increased challenge in a hybrid world where users are on the move across devices throughout their workday.

DETAILED DESCRIPTION

Overview

In an embodiment, a method comprises: at an identity provider, upon receiving a request for authentication of a user to a target application that is hosted on a user device and into which the user has logged-in: identifying one or more biometric tests to be applied to the user to satisfy the request; selecting, from a list of application services that have trust relationships with the identity provider, an application service which has an active session with the user and supports the one or more biometric tests; requesting the application service to perform multifactor authentication that includes the one or more biometric tests; receiving, from the application service, biometric test results that indicate whether each of the one or more biometric tests passed or failed; and determining that the authentication has passed or failed based on the biometric test results.

EXAMPLE EMBODIMENTS

Compared to conventional authentication techniques, embodiments presented herein provide a user with a less disruptive way to authenticate into a user application and protected business websites, while maintaining the additional security that is gained from multifactor authentication (MFA). The embodiments reduce the amount of re-authentication prompts to the user throughout his/her business day, reduce human context-switching away from business value-adding tasks, and minimize user fatigue. These and other features and advantages will be evident from the ensuing description of the embodiments.

FIG. 1 is a diagram of an example computer environment 100 in which zero-touch always-on MFA of a user using trusted multimedia sources may be implemented. Computer environment 100 includes a user device 102 operated by a user U and configured to host a user application 104 for the user, application services 106(1)-106(N) (collectively referred to as “application services 106”) associated with users (which may or may not be user U), and an identity provider (IDP) 108 (also referred to as an “IDP entity” or an “IDP controller”). User device 102, application services 106, and IDP 108 are connected to a network 110 and configured to communicate with each other over the network. Network 110 may include one or more wide area networks (WANs), such as the Internet, and one or more local area networks (LANs). User device 102, application services 106, and IDP 108 may exchange data packets with each over network 110 using any known or hereafter developed network protocols, including, but not limited to, the Transmission Control Protocol (TCP)/Internet Protocol (IP) (TCP/IP), for example.

By way of example, user device 102 may include a portable computer, a smartphone, a computer tablet, a laptop computer, and the like. In the example of FIG. 1, user device 102 hosts user application 104; however, the user application 104 may be hosted remotely from the user device. Whether hosted on user device 102 or remotely, user U may access user application 104 through a user interface of the computer device. Non-limiting examples of user application 104 may include any personal or business application, such as an accounting program, database programs, productivity suits (e.g., Word), and the like. User application 104 may also include any application and content accessed through browser/web pages, and the like. While only a single user device (and its associated user) is shown in the example of FIG. 1, computer environment 100 may include many such user devices operated by local users.

Application services 106 provide a variety of interactive multimedia sources and services. Examples of interactive multimedia services include meeting/collaboration services, such as video conferencing, chat, and other multimedia services. For example, application service 106(1) (e.g., a meeting service) may include a meeting server S (also referred to as a “collaboration/meeting server”) that controls an endpoint EP (also referred to as a “user endpoint device”) to provide video conferencing, chat, and other multimedia services to a user interacting with the endpoint. Application services 106 include/provide biometric sensors to capture biometric readings from users when the users interact with the application services during collaboration sessions. For example, endpoint EP of application service 106(1) may include, or have access to, one or more of a video camera to capture video of a face of a user, a microphone to capture audio (e.g., voice) from the user, a retina scanner to scan/read a retina of the user, and a fingerprint scanner to read a fingerprint of the user. Such biometric sensors may be integrated with endpoint EP, or may be connected to the endpoint through wireless or wired connections.

IDP 108 may be implemented as one or more IDP applications hosted on an IDP server, for example. IDP 108 establishes, and then maintains, trust relationships with user device 102, user application 104, and application services 106 (collectively referred to as “trusted entities” once such trust relationships have been established). IDP 108 stores in memory a trusted entity list 112 that lists/identifies the trusted user device(s) and application services 106. Trusted entity list 112 also lists types of biometric sensors provided by corresponding ones of application services 106. That is, trusted entity list 112 may include a mapping of an application service 106 (i) that is trusted to a list of biometric sensors accessible to that application service. IDP 108 also stores, in memory, user MFA profiles 114 for corresponding users. A user authentication profile includes predetermined MFA criteria for a user. The MFA criteria may include, for example, types of biometric tests that should be performed to authenticate the user, and the minimum level of confidence associated with the biometric tests required for successful authentication. The user authentication profile is mapped to an identity of the user (i.e., a user identity, such as a user name or other unique user identifier).

IDP 108 relies on trusted entity list 112, user MFA profiles 114, and biometric tests supported by application services 106 to manage/perform zero-touch MFA of user U to user application 104, after the user application has accepted an initial single sign on (SSO) action from the user. The MFA includes biometric authentication of user U. Zero-touch MFA of the user refers to performing MFA of the user in a way that is transparent to the user, without prompting the user to perform actions specific to the MFA. At a high level, the initial SSO triggers user device 102 (or user application 104) to send to IDP 108 a request to authenticate user U to the user application. Responsive to the request, IDP 108 executes the zero-touch MFA using trusted entity list 112, a user authentication profile for the user from user MFA profiles 114, and one of application services 106 (e.g., application server 106(1)) with which the user is currently engaged in a session. In an example in which user U interacts with user device 102 and application service 106(1) more or less concurrently, IDP 108 relies on the application service to assist with zero-touch biometric authentication (i.e., testing) of the user, as described below in connection with FIG. 2. In this sense, application service 106(1) serves user U as a “multimedia MFA service.”

FIG. 2 shows an example method 200 of zero-touch MFA of user U into user application 104 performed in computer environment 100. The zero-touch MFA involves zero-touch biometric testing on user U.

At 202, user U performs an SSO into user application 104 (denoted “my application” in FIG. 2) through user device 102. User application 104 is the target of authentication. Responsive to the SSO, at 204, user device 102 sends to IDP 108 a request (also referred to as a “user authentication request” or simply “authentication request”) to authenticate user U into user application 104. The request includes a user identity of user U (i.e., a user identifier, e.g., a user name), an identity of user application 104 (i.e., an application identifier, e.g., an application name), and an identity of user device 102 (e.g., a device identifier).

Upon receipt of the request, at 206, IDP 108 records a request timestamp at which the request was received, and verifies that user device 102 (through which the login attempt (e.g., the SSO) was made) is trusted. To verify the trust, IDP 108 searches trusted entity list 112 for a user device identifier and/or user application identifier that matches the user device identifier for user device 102 and/or a user application identifier for user application 104 that is/are included with the request. Assuming that user device 102/user application 104 is/are trusted, IDP 108 determines which types of biometric authentication (i.e., which types of biometric testing) should be performed on user U to satisfy the request. To do this, using the identity of user A acquired from the request, IDP 108 searches user MFA profiles 114 for a user MFA profile that matches user A. When found, the user MFA profile for user A lists MFA criteria to be satisfied to authenticate user A. The MFA criteria includes an indication of whether SSO into an application service is required, a list of one or more biometric tests to be performed on user A, and a confidence threshold to be met by passing test results reported by the biometric tests. The MFA criteria may further include a predetermined time period (also referred to as a “proximity time period”) over which biometric test results remain valid from the time when user U performed the SSO into user application 104. Example biometric tests include, but are not limited to, facial recognition, audio or voice recognition, fingerprint recognition, retina recognition, and the like.

Armed with the MFA criteria for user A, IDP 108 determines/identifies an application service among application services 106 that is (i) trusted, and (ii) capable of performing the biometric tests listed in the MFA criteria for user U. To do this, IDP 108 searches trusted entity list 112 for one (or possibly more) of application services 106 that is configured with biometric sensors that match the biometric tests listed in the MFA criteria for user U. For example, when the MFA criteria for user U include one or more of facial recognition, voice recognition, fingerprint recognition, and retina recognition, IDP 108 searches for an application service equipped with one or more of a video camera, a microphone, a fingerprint reader, and a retina scanner, respectively. In the example of FIG. 2, IDP 108 identifies application service 106(1) with meeting server S and endpoint EP to satisfy the MFA criteria. In an example, application service 106(1) may support/manage Webex meetings, Webex Teams, Zoom meetings, and so on.

Upon performing the above-mentioned verifications and identifying application service 106(1), at 208, IDP 108 creates an IDP request for authentication (i.e., an IDP authentication request) that lists the MFA criteria for user U, and sends the same to meeting server S of the application service. Ideally, the time at which IDP 108 sends the IDP authentication request to meeting server S is contemporaneous with when user U performed the SSO into user application 104. In the example of FIG. 2, the IDP authentication request includes MFA criteria A that specify that an SSO into application service 106(1) by user U is required, the application service should be trusted, facial recognition is required, voice recognition is optional, and the predetermined time period is 5 minutes.

Upon receiving the IDP authentication request, at 210, meeting server S determines/verifies that user U is an active user in a multimedia session associated with the application service and identifies endpoint EP with which the user is interacting in the multimedia session. For example, user U may be logged into an online meeting session or logged into a chat/messaging session via endpoint EP. Meeting server S also verifies that user U is authenticated to the meeting server S via SSO. Assuming the aforementioned verifications hold true, meeting server S verifies that resources under control of the meeting server, e.g., endpoint EP, have their biometric sensors enabled and are therefore equipped to perform the biometric tests prescribed by the IDP authentication request. For example, meeting server S verifies that one or more of the following biometric capabilities are enabled: a video camera for capturing video of the user; a microphone for capturing voice/audio of the user; a fingerprint reader to read a fingerprint of the user; and a retina scanner to scan a retina of the user.

At 212, meeting server S dispatches to the resources identified above (e.g., to endpoint EP) meeting-server-originated MFA requests to perform the biometric tests. This can be thought of as dispatching to various multimedia channels of application service 106(1) (e.g., to a video channel, an audio channel, and so on) various MFA requests to perform corresponding ones of the biometric tests (e.g., facial recognition, voice recognition, and so on).

Responsive to the meeting-server-originated MFA requests, at 214, the resources (e.g., endpoint EP) assess the meeting-server-originated MFA requests and perform, or assist meeting server S with performing, the biometric tests. The aforementioned assessment may employ machine learning (ML) techniques, and the like. Generally, each biometric test includes capturing biometric information of a user using a biometric sensor, comparing the biometric information to a predetermined/expected biometric print for the user and, based on comparing, returning a biometric test result that the biometric test either passed or failed. When the captured biometric information matches the predetermined biometric print within a tolerance, the biometric test result indicates that the biometric test passed (i.e., a “passing” test result). The biometric test result may also include a timestamp that indicates when the biometric test was performed. A passing test result may further include a confidence level that the passing test result is true. The confidence level represents a probability score that the biometric test result returned a true positive (i.e., pass). On the other hand, when the captured biometric information does not match the predetermined biometric print within the tolerance, the biometric test result indicates that the biometric test failed (i.e., a “failing” test result). Specific types of biometric tests (also referred to as “biometric recognition”) are described below.

Facial recognition includes capturing video of a face of the user, comparing the video or photographic snapshot of the face to a predetermined faceprint for the user, and returning a timestamped test result that indicates that the facial recognition passed (i.e., the face matches the faceprint and is therefore recognized) or failed (i.e., the face does not match the faceprint and is therefore not recognized). The passing test result may include a confidence level that the passing test result is true.

Voice recognition includes capturing a voice of the user, comparing the voice to a predetermined voiceprint for the user, and returning a timestamped test result that indicates that the voice recognition passed (i.e., the voice matches the voiceprint) or failed (i.e., the voice does not match the voiceprint). The passing test result may include a confidence level that the pass is true.

Fingerprint recognition includes reading a fingerprint of the user, comparing the fingerprint reading to a known fingerprint for the user, and returning a timestamped test result that indicates that the fingerprint recognition passed (i.e., the fingerprint reading matches the known fingerprint) or failed (i.e., the fingerprint reading does not match the known fingerprint). The passing test result may include a confidence level that the pass is true.

Retina recognition includes scanning a retina of the user, comparing the retina scan to a predetermined retina print for the user, and returning a timestamped test result that indicates that the retina recognition passed (i.e., the retina scan matches the retina print) or failed (i.e., the retina scan does not match the retina print). The passing test result may include a confidence level that the pass is true.

As mentioned above, the application service resources (e.g., endpoint EP and its associated biometric sensors) used to perform the biometric tests return to meeting server S biometric test results for the biometric tests that mirror those requested by the server. The biometric test results list pass/fail results/status for the biometric tests, may include confidence levels for passing indications, and may include timestamps. In an example, a timestamp included with a biometric test result for facial recognition may be used to ensure that the user is actively near a camera used for the facial recognition, to prevent a situation where the user has walked away from the camera, and also to prevent an attacker from capturing a prior authentication message and replaying it at a later time for malicious authentication.

Upon receiving the biometric test results, meeting server S compiles the same into a results report. Meeting server S appends to the results report a report timestamp and digitally signs the results reports (i.e., appends a digital signature), which prevents tampering or modification of the results report. At 216, IDP 108 sends the results report to IDP 108. In the example of FIG. 2, a results report R includes the following status: SSO: pass; trusted device: pass; facial recognition: pass; voice recognition: pass; timestamp 1698082002; and a hash result.

Upon receiving the results report from meeting server S, at 218, IDP 108 examines/parses the biometric test results in the results report. IDP 108 determines whether the report timestamp and the request timestamp from 206 both fall within the predetermined time period to ensure that the request received at 204 and the biometric tests received by IDP 108 at 216 are more or less contemporaneous (which indicates that user U is accessing user application 104 and endpoint EP more or less at the same time). When the two timestamps fall within the predetermined time period, IDP 108 proceeds with authentication based on the biometric test results, otherwise the IDP does not perform authentication based on the biometric test results.

Assuming that the two timestamps both fall within the predetermined time period, IDP 108 determines whether the user passed or failed authentication based on the biometric test results. Generally, IDP 108 determines that authentication has passed (i.e., is successful) when the biometric test results indicate that the biometric tests have passed and, in some examples, when the associated confidence levels exceed the confidence threshold. For example, IDP 108 may use a confidence level to only offer successful user authentication when the confidence level of a true positive (i.e., a pass) is above a discrete value of probability (e.g. the confidence threshold). For example, IDP 108 may only authenticate the user when facial recognition is at least a 99.9% confident match. When authentication has passed, IDP 108 considers user U authenticated and bypasses presenting any additional authentication methods to the user. Upon successful authentication, at 220, IDP 108 sends to user application 104/user device 102 an authenticated session token. Overall, the process offers a zero-touch seamless, non-intrusive authentication for the user into his/her target application.

On the other hand, IDP 108 determines that the authentication has failed (i.e., is unsuccessful) when the biometric test results indicate that one or more of the biometric tests have failed and, in some examples, when the associated confidence levels do not exceed the confidence threshold. When the authentication fails, or does not meet the level of multifactor required (e.g., the report indicates the wrong biometric types from what was requested), then IDP 108 simply falls back to prompting the user (through user device 102) for a username/password and for MFA using the normal means as if there were no zero-touch MFA authentication.

The techniques described above rely on pre-established (i.e., a priori) trust relationships across the entities shown in FIG. 1. For example, prior to executing the zero-touch MFA described in connection with FIG. 2, IDP 108 establishes trust relationships with the user applications (e.g., user application 104) and with the user devices (e.g., user device 102). Similarly, IDP 108 establishes trust relationships with application services 106 (e.g., with meeting server S and with endpoint(s) EP). FIG. 3 is an illustration of an example method 300 by which IDP 108 establishes trust relationships with user application 104 and meeting server S.

At 302, IDP 108 and user application 104 exchange messages to establish mutual trust. For example, user application 104 sends an authentication request to IDP 108 (which is not to be confused with the initial request for authentication that is sent by user application 104 to the IDP at 204, as described above in connection with FIG. 2). Upon receiving the authentication request, IDP 108 generates a trust result and sends the same to user application 104. In an example, the two entities share their public key infrastructure (PKI) certificates with each other, and thereby establish an encrypted transport layer security (TLS) and trusted relationship between themselves. IDP 108 adds user application 104 to trusted entity list 112 for access during a subsequent authentication, as described above.

At 304, IDP 108 and meeting server S exchange messages to establish trust between the IDP and the meeting server. For example, meeting server S sends an authentication request to IDP 108. Upon receiving the authentication request, IDP 108 generates a trust result and sends the same to meeting server S. In an example, the two entities share their PKI certificates with each other, and thereby establish an encrypted TLS and trusted relationship between themselves. IDP 108 adds meeting server S to trusted entity list 112 for access during a subsequent authentication, as described above.

In addition, user devices (e.g., user device 102) and the endpoint devices (e.g., endpoint EP) establish trust relationships with IDP 108. To do this, the devices enroll in IDP 108 as trusted devices. This may include pushing to the devices device management profiles (such as mobile device management (MDM) for iOS) to ensure that the devices are “hardened” and have password/passcode time-based locks before establishing the trust. There may be an ability to revoke trust from IDP 108 or an MDM console, in the event a known device is stolen. One technique may establish trust across a physical connection, such as universal serial bus (USB) or High-Definition Multimedia Interface (HDMI) connectivity, between an endpoint and a user device (e.g., a personal computer). Another technique may allow a user to trust a user device, upon first login to the user device to enroll it into a trusted device group. For example, the user may be presented with a prompt: “a new login has been detected from device JSMITH-LAPTOP on Jan. 2, 2023, at 15:00:23 from Raleigh, North Carolina. Would you like to enroll and trust this device for future MFA logins?”

FIG. 4 is an illustration of example devices 400 associated with user U that have established a priori trust relationships with IDP 108 according to the above-described techniques, e.g., using device management enrollment through IDP 108 and/or direct connection from the IDP to the devices. Devices 400 include a smartphone 402 and a desktop or laptop computer 404, which are both examples of user device 102. Devices 400 further endpoint EP. Identities of all of the devices are entered into trusted entity list 112.

FIG. 5 is a flowchart of an example method 500 of zero-touch MFA of a user into an initially unauthenticated target application performed primarily at an IDP (e.g., IDP 108). Operations of method 500 are described above. Method 500 assumes execution of a prior operations in which the IDP has established trust relationships with various user devices, target applications, and application services by exchanging PKI certificates with the aforementioned non-IDP entities, and recording them in a trusted entities list. That is, the a priori operations include establishing trust relationships with the user devices/target applications and application services.

At 502, the IDP receives a request for authentication of the user to the (unauthenticated) target application. The target application is hosted on a user device and the user has logged into the target application using SSO. Upon receiving the request, the IDP records a request timestamp (e.g., a first timestamp), and executes an authentication process including next operations 504-512. The IDP verifies that the user device and/or the target application have trusted relationships with the IDP.

At 504, the IDP identifies one or more biometric tests to be applied to the user to satisfy the request. For example, the IDP searches MFA user profiles that include mappings of biometric tests to user identities based on a user identity received with the request. A found MFA user profile for the user may list biometric tests that include one or more of facial recognition, voice recognition, finger print recognition, retina recognition, and so on.

At 506, the IDP selects, from a list of application services that have trust relationships with the identity provider (e.g., that are listed in a trusted entity list), an application service which has an active session with the user (at the same time at which the user is interacting with the user device) and supports the one or more biometric tests. The application service may be a meeting/conference service that includes a meeting server and an endpoint that includes biometric sensors that support the biometric tests. For example, the user may have performed the SSO into the unauthenticated target application during the user's active session on the application service (e.g., while the user is logged into the active session).

At 508, the IDP sends MFA requests to the application service (e.g., to the meeting server) to perform MFA that includes one or more biometric tests. The application service performs the biometric tests and, at 510, reports to the IDP biometric test results that indicate whether each of the one or more biometric tests passed or failed. The biometric tests results also include a report timestamp (e.g., a second timestamp) that indicates a time when the biometric tests were performed.

Upon receiving the biometric test results, and upon determining that the report timestamp and the request timestamp both fall within a predetermined time period, at 512, the IDP determines whether the (user) authentication into the target application has passed or failed based on the biometric test results. The IDP determines that the authentication has passed when the biometric test results indicate that each biometric test has passed and the user device/target application and application service are all trusted. In an example in which each biometric test result indicates a pass confidence, the IDP determines that the authentication has passed when each pass confidence exceeds a predetermined confidence threshold. When authentication has passed, the IDP sends to the user device/target application, an authentication token.

The IDP determines that the authentication has failed when the biometric test results indicate that the one or more biometric tests have failed, or the user device/target application and application service are not all trusted. In that case, in lieu of the authentication token, the IDP sends to the user device a device request to perform multifactor authentication of the user that is to be satisfied through the user device (not an application service).

In summary, zero-touch user MFA is performed. In an example, if a user is active on a video meeting session, live video and audio streams may be used to authenticate the user via multifactor means such as facial recognition, instead of prompting the user to login via a classic sense (e.g., using username/password and dual-pin entry). This allows for a non-disruptive authentication means, for situations when the user is logging into target applications while on an active video meeting. Other biometrics beyond facial recognition (e.g., voice fingerprinting, acoustic authentication in earbuds, etc.) can also be used for additional validation to improve confidence, or as optional means when video may not be available.

For example, for a user who is actively participating in an authenticated meeting and has video enabled, the embodiments leverage authentication (SSO/IDP) from a meeting server's session plus additional biometrics from the meeting's media streams (such as facial recognition from video, or voice fingerprinting from audio) to offer a hands-free and interruption-free trusted MFA authentication source back to the IDP. With that capability, when that user is logging into an unauthenticated application during the meeting, the embodiments allow for the IDP to receive a real-time validated authentication request and response from the meeting server, and prevent the user from having to re-authenticate via another MFA request. The security strength of authentication is not diluted with the embodiments, because the embodiments confirm that the user is authenticated via multiple means in real-time while they are on the meeting, by time stamping and signing authentication tokens, and by only leveraging trusted devices associated to the authenticating user for the authentication process.

Referring to FIG. 6, FIG. 6 illustrates a hardware block diagram of a computing device 600 that may perform functions associated with operations discussed herein in connection with the techniques depicted in FIGS. 1-5. In various embodiments, a computing device or apparatus, such as computing device 600 or any combination of computing devices 600, may be configured as any entity/entities as discussed for the techniques depicted in connection with FIGS. 1-5 in order to perform operations of the various techniques discussed herein. For example, computing device may represent or be used to implement any of IDP 108, user device 102, endpoint EP, application services 106, and so on.

In at least one embodiment, the computing device 600 may be any apparatus that may include one or more processor(s) 602, one or more memory element(s) 604, storage 606, a bus 608, one or more network processor unit(s) 610 interconnected with one or more network input/output (I/O) interface(s) 612, one or more I/O interface(s) 614, and control logic 620. In various embodiments, instructions associated with logic for computing device 600 can overlap in any manner and are not limited to the specific allocation of instructions and/or operations described herein.

In at least one embodiment, processor(s) 602 is/are at least one hardware processor configured to execute various tasks, operations and/or functions for computing device 600 as described herein according to software and/or instructions configured for computing device 600. Processor(s) 602 (e.g., a hardware processor) can execute any type of instructions associated with data to achieve the operations detailed herein. In one example, processor(s) 602 can transform an element or an article (e.g., data, information) from one state or thing to another state or thing. Any of potential processing elements, microprocessors, digital signal processor, baseband signal processor, modem, PHY, controllers, systems, managers, logic, and/or machines described herein can be construed as being encompassed within the broad term ‘processor’.

In at least one embodiment, memory element(s) 604 and/or storage 606 is/are configured to store data, information, software, and/or instructions associated with computing device 600, and/or logic configured for memory element(s) 604 and/or storage 606. For example, any logic described herein (e.g., control logic 620) can, in various embodiments, be stored for computing device 600 using any combination of memory element(s) 604 and/or storage 606. Note that in some embodiments, storage 606 can be consolidated with memory element(s) 604 (or vice versa), or can overlap/exist in any other suitable manner.

In at least one embodiment, bus 608 can be configured as an interface that enables one or more elements of computing device 600 to communicate in order to exchange information and/or data. Bus 608 can be implemented with any architecture designed for passing control, data and/or information between processors, memory elements/storage, peripheral devices, and/or any other hardware and/or software components that may be configured for computing device 600. In at least one embodiment, bus 608 may be implemented as a fast kernel-hosted interconnect, potentially using shared memory between processes (e.g., logic), which can enable efficient communication paths between the processes.

In various embodiments, network processor unit(s) 610 may enable communication between computing device 600 and other systems, entities, etc., via network I/O interface(s) 612 (wired and/or wireless) to facilitate operations discussed for various embodiments described herein. In various embodiments, network processor unit(s) 610 can be configured as a combination of hardware and/or software, such as one or more Ethernet driver(s) and/or controller(s) or interface cards, Fibre Channel (e.g., optical) driver(s) and/or controller(s), wireless receivers/transmitters/transceivers, baseband processor(s)/modem(s), and/or other similar network interface driver(s) and/or controller(s) now known or hereafter developed to enable communications between computing device 600 and other systems, entities, etc. to facilitate operations for various embodiments described herein. In various embodiments, network I/O interface(s) 612 can be configured as one or more Ethernet port(s), Fibre Channel ports, any other I/O port(s), and/or antenna(s)/antenna array(s) now known or hereafter developed. Thus, the network processor unit(s) 610 and/or network I/O interface(s) 612 may include suitable interfaces for receiving, transmitting, and/or otherwise communicating data and/or information in a network environment.

I/O interface(s) 614 allow for input and output of data and/or information with other entities that may be connected to computing device 600. For example, I/O interface(s) 614 may provide a connection to external devices such as a keyboard (which may be biometric), keypad (which may be biometric), a touch screen, and/or any other suitable input and/or output device now known or hereafter developed. In some instances, external devices can also include portable computer readable (non-transitory) storage media such as database systems, thumb drives, portable optical or magnetic disks, and memory cards. In still some instances, external devices can be a mechanism to display data to a user, such as, for example, a computer monitor, a display screen, or the like.

In various embodiments, control logic 620 can include instructions that, when executed, cause processor(s) 602 to perform operations, which can include, but not be limited to, providing overall control operations of computing device; interacting with other entities, systems, etc. described herein; maintaining and/or interacting with stored data, information, parameters, etc. (e.g., memory element(s), storage, data structures, databases, tables, etc.); combinations thereof; and/or the like to facilitate various operations for embodiments described herein.

Note that in certain example implementations, operations as set forth herein may be implemented by logic encoded in one or more tangible media that is capable of storing instructions and/or digital information and may be inclusive of non-transitory tangible media and/or non-transitory computer readable storage media (e.g., embedded logic provided in: an ASIC, digital signal processing (DSP) instructions, software [potentially inclusive of object code and source code], etc.) for execution by one or more processor(s), and/or other similar machine, etc. Generally, memory element(s) 604 and/or storage 606 can store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, and/or the like used for operations described herein. This includes memory element(s) 604 and/or storage 606 being able to store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, or the like that are executed to carry out operations (including generating GUIs for display and interacting with the GUIs) in accordance with teachings of the present disclosure.

Variations and Implementations

In summary, in some aspects, the techniques described herein relate to a method including: at an identity provider, upon receiving a request for authentication of a user to a target application that is hosted on a user device and into which the user has logged-in: identifying one or more biometric tests to be applied to the user to satisfy the request; selecting, from a list of application services that have trust relationships with the identity provider, an application service which has an active session with the user and supports the one or more biometric tests; requesting the application service to perform multifactor authentication that includes the one or more biometric tests; receiving, from the application service, biometric test results that indicate whether each of the one or more biometric tests passed or failed; and determining that the authentication has passed or failed based on the biometric test results.

In some aspects, the techniques described herein relate to a method, wherein: determining that the authentication has passed or failed includes determining that the authentication has passed when the biometric test results indicate that each biometric test has passed; and the method further includes: when the authentication has passed, sending an authentication token to the user device.

In some aspects, the techniques described herein relate to a method, further including: verifying that the identity provider has a trust relationship with the target application, wherein determining that the authentication has passed further includes determining that the authentication has passed when the application service and the target application have the trust relationship and the trust relationships with the identity provider and each biometric test has passed.

In some aspects, the techniques described herein relate to a method, wherein: determining that the authentication has passed or failed includes determining that the authentication has failed when the biometric test results indicate that the one or more biometric tests have failed; and the method further includes: when the authentication has failed, sending to the user device a device request to perform the multifactor authentication of the user that is to be satisfied through the user device.

In some aspects, the techniques described herein relate to a method, wherein: receiving the request includes receiving the request to include a user identity of the user; and identifying the one or more biometric tests includes searching multifactor authentication user profiles that include mappings of biometric tests to user identities based on the user identity.

In some aspects, the techniques described herein relate to a method, wherein: identifying includes identifying, as the one or more biometric tests, facial recognition that includes capturing video of the user and comparing the video to a faceprint of the user, voice recognition that includes capturing voice of the user and comparing the voice to a voiceprint of the user, or fingerprint recognition that includes capturing a fingerprint reading from the user and comparing the fingerprint reading to a known fingerprint of the user; and requesting includes requesting the application service to perform the facial recognition, the voice recognition, or the fingerprint recognition.

In some aspects, the techniques described herein relate to a method, wherein: the request includes a first timestamp; the biometric test results include a second timestamp; and the method further includes: upon determining that the first timestamp and the second timestamp both fall within a predetermine time period, performing determining that the authentication has passed or failed.

In some aspects, the techniques described herein relate to a method, further including: upon determining that the first timestamp and the second timestamp do not both fall within the predetermine time period, not performing determining that the authentication has passed or failed.

In some aspects, the techniques described herein relate to a method, wherein: the biometric test results further include digital signatures appended by the application service.

In some aspects, the techniques described herein relate to a method, wherein: each biometric test result that indicates that a biometric test has passed further includes a confidence that the biometric test has passed; and determining that the authentication has passed or failed includes determining that the authentication has passed when each confidence exceeds a predetermined confidence threshold.

In some aspects, the techniques described herein relate to a method, further including, by the identity provider: establishing the trust relationships with the application service; and establishing a trust relationship with the target application.

In some aspects, the techniques described herein relate to a method, wherein: the application service includes a collaboration service supported by a meeting server and an endpoint device that operates under control of the meeting server and supports the one or more biometric tests.

In some aspects, the techniques described herein relate to an apparatus including: a network interface to communicate with a network; and a processor of an identity provider, wherein the processor is coupled to the network interface and is configured to perform, upon receiving a request for authentication of a user to a target application that is hosted on a user device and into which the user has logged-in: identifying one or more biometric tests to be applied to the user to satisfy the request; selecting, from a list of application services that have trust relationships with the identity provider, an application service which has an active session with the user and supports the one or more biometric tests; requesting the application service to perform multifactor authentication that includes the one or more biometric tests; receiving, from the application service, biometric test results that indicate whether each of the one or more biometric tests passed or failed; and determining that the authentication has passed or failed based on the biometric test results.

In some aspects, the techniques described herein relate to an apparatus, wherein: the processor is configured to perform determining that the authentication has passed or failed by determining that the authentication has passed when the biometric test results indicate that each biometric test has passed; and the processor is further configured to perform: when the authentication has passed, sending an authentication token to the user device.

In some aspects, the techniques described herein relate to an apparatus, wherein the processor is further configured to perform: verifying that the identity provider has a trust relationship with the target application, wherein the processor is configured to perform determining that the authentication has passed by determining that the authentication has passed when the application service and the target application have the trust relationship and the trust relationships with the identity provider and each biometric test has passed.

In some aspects, the techniques described herein relate to an apparatus, wherein: the processor is configured to perform determining that the authentication has passed or failed includes determining that the authentication has failed when the biometric test results indicate that the one or more biometric tests have failed; and the apparatus further includes: when the authentication has failed, sending to the user device a device request to perform the multifactor authentication of the user that is to be satisfied through the user device.

In some aspects, the techniques described herein relate to an apparatus, wherein: the processor is configured to perform receiving the request by receiving the request to include a user identity of the user; and the processor is configured to perform identifying the one or more biometric tests by searching multifactor authentication user profiles that include mappings of biometric tests to user identities based on the user identity.

In some aspects, the techniques described herein relate to a non-transitory computer readable medium encoded with instructions that, when executed by a processor of an identity provider, cause the processor to perform: upon receiving a request for authentication of a user to a target application that is hosted on a user device and into which the user has logged-in: identifying one or more biometric tests to be applied to the user to satisfy the request; selecting, from a list of application services that have trust relationships with the identity provider, an application service which has an active session with the user and supports the one or more biometric tests; requesting the application service to perform multifactor authentication that includes the one or more biometric tests; receiving, from the application service, biometric test results that indicate whether each of the one or more biometric tests passed or failed; and determining that the authentication has passed or failed based on the biometric test results.

In some aspects, the techniques described herein relate to a non-transitory computer readable medium, wherein: the instructions to cause the processor to perform determining that the authentication has passed or failed include instructions to cause the processor to perform determining that the authentication has passed when the biometric test results indicate that each biometric test has passed; and the instructions further include instructions to cause the processor to perform: when the authentication has passed, sending an authentication token to the user device.

In some aspects, the techniques described herein relate to a non-transitory computer readable medium, further including instructions to cause the processor to perform: verifying that the identity provider has a trust relationship with the target application, wherein the instructions to cause the processor to perform determining that the authentication has passed further include instructions to cause the processor to perform determining that the authentication has passed when the application service and the target application have the trust relationship and the trust relationships with the identity provider and each biometric test has passed.