Patent Application
20210099441
The present disclosure generally relates to methods and systems for one-time multiple registration chain with Public Key Infrastructure-credential (PKI-credential) anchoring and universal registration, avoidance of user re-registration, and universal roaming via captive authentication.
Single sign-on (SSO) is an authentication process that allows a user to access multiple applications with one set of login credentials. Single sign-on, for example, is a common procedure in enterprises, where a client accesses multiple resources connected to a local area network (LAN).
Variations of single sign-on authentication has been developed using mobile devices as access credentials. For example, mobile devices can be used to automatically log the user onto multiple systems, such as building-access-control systems and computer systems, through the use of authentication methods which include OpenID Connect and SAML, in conjunction, for example, with an X.509 ITU-T cryptography certificate used to identify the mobile device to an access server.
Currently, the biometric based client-server authentication systems has four flows, (1) a user registration flow, (2) a user authentication flow, (3) a user roaming authentication flow, and (4) a user de-register and/or revocation flow.
User registration process involves recording user's profile (for example, user credentials, etc.) and the associated biometric device address in the server, as the server performs user's credentials in a secure fashion. Typically, for example, username and password can be used for credential storing.
Such a process for recording a user's profile takes place in the eco-system that is hybrid in nature, because the authentication solution software integrates with the software components of various biometric-solution vendors. Software components of biometric-solutions interact with the user(s), while solution-specific software components fall into centralized system with scalable two-tier client server systems.
Due to involved hybrid-integration of bio-metric software components and solution-specific software components, currently every specific solution requires its own specific client software components to software-integrate tightly with bio-metric software components. Therefore, this current way of achieving user registration process results in every authentication solution vendor to design and develop the client software components to interoperate with biometric software components on the computing devices where their users perform user registration.
In consideration of the above issues, it would be desirable to achieve a client-less system in the user registration process, so that all solution-specific vendors will be completely relieved of writing their client software components. In accordance with an exemplary embodiment, the client-less system can achieve benefits that can include computing devices that act as registration station now requires only biometric software components installed and run and therefore much efficient with respect to central processing unit (CPU) and memory utilizations, and the registration process becomes uniform across all solution vendors for any given bio-metric solution.
In addition, it would be desirable to have a method and system for new user registration and authentication procedures to achieve avoidance of user re-registration on a pristine computing device (i.e., original computing device). In accordance with an exemplary embodiment, a pristine computing device can be any client or computing device in which the user and corresponding device tied to the user has not been authenticated via, for example, a mobile device.
Furthermore, it would be desirable to have a method and system, which applies to comprehensive network security systems offering secure authentication and service authorizations solutions for the enterprise users, and which helps solve the traditional problems faced by current industry.
A method is disclosed for client-less user registration of biometric devices for client-server authentication systems, the method comprising: embedding a registration URL address of a solution provider server on a computing device; hosting a generic registration proxy dispatcher service and a solution specific registration handler on the solution provider server, the generic registration proxy dispatcher configured to interact directly or indirectly with a biometric software application on the computing device, and wherein the solution specific registration handler is configured to handle one or more vendors of services; directing a registration of a user and a biometric device to the solution provider server via a browser on the computing device using the registration URL address; and registering the user and the biometric device in a vendor database.
A non-transitory computer readable medium storing computer readable program code executed by a processor for a process for client-less user registration of biometric devices for client-server authentication systems is disclosed, the process comprising: embedding a registration URL address of a solution provider server on a computing device; hosting a generic registration proxy dispatcher and a solution specific registration handler on the solution provider server, the generic registration proxy dispatcher configured to interact directly or indirectly with a biometric software application on the computing device, and wherein the solution specific registration handler configured to handle one or more vendors of services; directing a registration of a user and a biometric device to the solution provider server via a browser on the computing device using the registration URL address; and registering the user and the biometric device in a vendor database.
A system is disclosed for client-less user registration of biometric devices for client-server authentication systems, the system comprising: a solution provider server having a processor configured to: host a generic registration proxy dispatcher service and a solution specific registration handler on the solution provider server, the generic registration proxy dispatcher configured to interact directly or indirectly with a biometric software application on the computing device, and wherein the solution specific registration handler configured to handle one or more vendors of services; direct a registration of a user and a biometric device to the solution provider server via a browser on the computing device using a registration URL address; and register the user and the biometric device in a vendor database.
A method is disclosed for avoidance of user re-registration, the method comprising: registering a user and a biometric device on a computing device; sending a registration digital artifact for the user and the biometric device to an authentication server; registering a mobile device configured to support Public Key Infrastructure (PKI) as a roaming authenticator, the mobile device being registered or tied to information related to the user; and provisioning the user and the mobile device with roaming authentication, the roaming authentication being accessed through the mobile device and configured to provide the user and the mobile device access to computing devices in which the user and the mobile device have not previously been used for authentication.
A non-transitory computer readable medium storing computer readable program code executed by a processor for a process for avoidance of user re-registration is discloses, the process comprising: registering a user and a biometric device on a computing device; sending a registration digital artifact for the user and the biometric device to an authentication server; registering a mobile device configured to support Public Key Infrastructure (PKI) as a roaming authenticator, the mobile device being registered or tied to information related to the user; and provisioning the user and the mobile device with roaming authentication, the roaming authentication being accessed through the mobile device and configured to provide the user and the mobile device access to computing devices in which the user and the mobile device have not previously been used for authentication.
A system is disclosed for avoidance of user re-registration, the system comprising: an authentication server having a processor configured to: register a user and a biometric device; registering a mobile device configured to support Public Key Infrastructure (PKI) as a roaming authenticator, the mobile device being registered or tied to information related to the user; and provision the user and the mobile device with roaming authentication, the roaming authentication being accessed through the mobile device and configured to provide the user and the mobile device access to computing devices in which the user and the mobile device have not previously been used for authentication.
A method is disclosed for universal roaming via captive authentication, the method comprising: registering a user on a client device; sending a registration digital artifact for the user and the client device to an authentication server; provisioning the user with a registration request for captive roaming authentication service on the client device, the captive roaming authentication service configured to provide the user with access to additional computing devices; and registering the client device with the captive roaming authentication service on the authentication server with a roaming Public Key Infrastructure (PKI) credential, the PKI credential configured to provide the user with the access to the additional computing devices.
A method is disclosed of authenticating a user for services on a computing device, the method comprising; storing a roaming Public Key Infrastructure (PKI) credential in a secure container on a client device; hosting a captive roaming authentication protocol on the client device and the computing device in which the user has not been previously authenticated; authenticating the user on a computing device by placing the client device with roaming PKI credentials in proximity to the computing device to initiate a handshake between the client device and the computing device; unlocking the secure container using an authenticator to retrieve the roaming PKI credential; sending a signed assertion from the client device to the computing device with the roaming PKI credential; posting the signed assertion with the roaming PKI credential to the authenticating server; and receiving a response from the authenticating server that the roaming PKI credential of the client device has been verified.
A non-transitory computer readable medium storing computer readable program code executed by a processor for a process for universal roaming via captive authentication is disclosed, the process comprising: registering a user on a client device; sending a registration digital artifact for the user and the client device to an authentication server; provisioning the user with a registration request for captive roaming authentication service on the client device, the captive roaming authentication service configured to provide the user with access to additional computing devices; and registering the client device with the captive roaming authentication service on the authentication server with a roaming Public Key Infrastructure (PKI) credential, the PKI credential configured to provide the user with the access to the additional computing devices
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.
The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.
Reference will now be made in detail to the present preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the description to refer to the same or like parts.
In accordance with an exemplary embodiment, the communication network or network 50 can be a public telecommunication line and/or a network (for example, LAN or WAN). Examples of the communication network 50 can include any telecommunication line and/or network consistent with embodiments of the disclosure including, but are not limited to, telecommunication or telephone lines, the Internet, an intranet, a local area network (LAN) as shown, a wide area network (WAN) and/or a wireless connection using radio frequency (RF) and/or infrared (IR) transmission.
In addition, for example, an access point 40 can communicate with the communication network 50 to provide wireless or cellular data communication between the mobile computer (for example, a smart phone) 20a, and the communication network 50. In accordance with an exemplary embodiment, the access point 40 can be any networking hardware device that allows a Wi-Fi device to connect to a wired network, or a hardware device that can allow a cellular device, for example, the mobile computer (or smartphone) 20a to connect to the wired network 50.
In accordance with an exemplary embodiment, the computing device 200 can include a display unit or graphical user interface (GUI) 240, which can access, for example, a web browser (not shown) in the memory 220 of the computing device 200. The computing device 200 also includes an operating system (OS), which manages the computer hardware and provides common services for efficient execution of various software programs. In accordance with an exemplary embodiment, the OS of the CPU 210 is a Linux, Windows®, or Macintosh (Mac) based operating system. The software programs can include, for example, application software and printer driver software. For example, the printer driver software controls a multi-function printer or printer (not shown), for example connected with the computing device 200 in which the printer driver software is installed via the communication network 50. In certain embodiments, the printer driver software can produce a print job and/or document based on an image and/or document data.
In accordance with an embodiment, the computing device 200 can be an enterprise server 10, which can include a mobile device management (MDM) component configured to administer mobile client or mobile client devices 20a, for example, smartphones, tablet computer, laptops, and desktop computers. For example, the MDM component can be a combination of on-device applications and configurations, corporate policies and certificates, and backend infrastructure, for the purpose of simplifying and enhancing the information technology (IT) management of end user devices, for example, mobile clients 20a. In accordance with an exemplary embodiment, the MDM component can be designed to increase supportability, security, and corporate functionality of mobile clients 20a while maintaining some user flexibility.
In accordance with an exemplary embodiment, the MDM component can be configured to administer devices and applications using mobile device management products and services, which can include corporate data segregation, securing emails, securing corporate documents on devices, enforcing corporate policies, integrating and managing mobile devices including laptops and handhelds of various categories. In accordance with an exemplary, the mobile device management implementations may be either on-premises or cloud-based. For example, the MDM component can be configured to ensure that diverse user equipment is configured to a consistent standard/supported set of applications, functions, or corporate policies; update equipment, applications, functions, or policies in a scalable manner; ensure that users use applications in a consistent and supportable manner, ensure that equipment performs consistently, monitor and track equipment (e.g. location, status, ownership, activity), and efficiently diagnose and troubleshoot equipment remotely. For example, in accordance with an exemplary embodiment, the MDM component can be configured to handle distribution of applications, data and configuration settings for all types of mobile devices, including mobile phones, smartphones, tablet computers, mobile computers, and mobile printers.
In accordance with an exemplary embodiment, the computing device 200 in the form of the enterprise server 10 can include a document management and storage system. In accordance with an exemplary embodiment, the document management and storage system can be configured to handle enterprise content and document management, for example, for storage, retrieval, searching, archiving, tracking, management, and reporting on electronic documents and records. In accordance with an exemplary embodiment, the SPS server can be used as intranet or intranet portal to centralize access to enterprise information and applications, collaborative software, file hosting, and custom web applications. For example, the SPS server can be configured to handle various application programming interfaces, for example, application programming interfaces, (APIs: client-side, server-side, JavaScript), REST, SOAP, and OData-based interfaces, and claims-based authentication, relying on, for example, SAML tokens for security assertions and/or an open authentication plugin model
In accordance with an exemplary embodiment, the SPS server can be configured to handle authentication of mobile clients or mobile devices 20a, for example, via a single sign-on (SSO) method. Single sign-on is an authentication process that allows a user to access multiple applications with one set of login credentials. Single sign-on, for example, is a common procedure in enterprises, where a user (or client) accesses multiple resources connected to a local area network (LAN) 60. For example, the single sign-on can be performed in connection with a biometric device 22, which authenticates a user, for example, by fingerprint recognition, electrocardiogram (ECG or EKG), iris detection, and or other authentication protocols, which are currently implemented or will be implemented on mobile devices. For example, a password authentication protocol, which uses credentials, such as username and password can be used in combination with biometric component, for example, ECG or EKG can be used.
In accordance with an exemplary embodiment, the SSO method can be Security Assertion Markup Language (SAML), which is an XML standard for exchanging single sign-on (SSO) information between an SAML Federation Identity Provider (SAML-IdP) who asserts the user identity and a SAML Federation Service Provider (SAML-SP) who consumes the user identity information. SAMLv2.0 (Security Assertion Markup Language version 2) supports IDP-initiated and SP-initiated flows. In IdP-initiated SAML SSO flow, the SAML-IdP creates a SAML single sign-on assertion for the user identity, and sends the SAML single sign-on assertion to the SP (Service Provider) in an unsolicited fashion. In SP-initiated SAML SSO flow, the SP generates a SAML2.0 AuthnRequest (i.e., Authentication Request) that is sent to the SAML-IdP as the first step in the Federation process and the SAML-IdP then responds with a SAML Response, both of these interactions being asynchronous to each other.
In accordance with an exemplary embodiment, the SSO method can be OpenID Connect (OIDC), which is an identity layer on top of an OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful (Representational State Transfer), HTTP (hypertext transfer protocol), and API (application program interface), using JSON (JavaScript Objection Notation) as a data format. OpenID Connect, for example, allows a range of clients, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite can also support optional features such as encryption of identity data, discovery of OpenID Providers, and session management.
In accordance with an exemplary embodiment, the server 10 can be an enterprise server that includes a directory component, which is configured, for example, to host a database of users and/or resource parameters, which can be executed, for example, on the multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b as disclosed herein. For example, the directory component can be an Active Directory (AD) server, or a lightweight directory access protocol (LDAP) server. In accordance with an exemplary embodiment, the managing of mobile clients 20a in enterprise systems is primarily performed, for example, by a MDM component 10a. However, as more workers have bought smartphone and tablet computing devices and have sought support for using these devices in the workplace, there are additional needs to control access to resources, for example, on devices, such as multi-function printers (MFPs) and image forming apparatuses 30a, 30b with a local area network (LAN). For example, enterprise software can include computer programs with common business applications, tools for modeling how the entire organization works, and development tools for building applications unique to the organization.
In accordance with an exemplary embodiment, the server 10 can be a solution vendor authentication server 610 (
In accordance with an exemplary embodiment, the mobile client (or mobile device) 20a can include a display unit or graphical user interface (GUI) 340, which can access, for example, a web browser (not shown) in the memory 320 of the mobile client (or mobile device) 20a. The mobile client (or mobile device) 20a also includes the operating system (OS) 322, which manages the computer hardware and provides common services for efficient execution of various software programs. In accordance with an exemplary embodiment, the OS 322 of the mobile client (or mobile device) 20a is a Linux or Windows® based operating system. The software programs can include, for example, application software and printer driver software. For example, the printer driver software controls a multi-function printer or printer (not shown), for example connected with the mobile client (or mobile device) 20a in which the printer driver software is installed via the communication network 50. In certain embodiments, the printer driver software can produce a print job and/or document based on an image and/or document data
In accordance with an exemplary embodiment, the mobile client (or mobile device) 20a can also preferably include an authentication module, which authenticates a user, for example, by a single sign-on (SSO) method such as a biometric, for example, a fingerprint, palm veins, face recognition, DNA, palm print, hand geometry, iris recognition, electrocardiogram (ECG or EKG), and/or retina, or authentication, or other authentication protocol, which are currently implemented or will be implemented on mobile devices. For example, a password authentication protocol, which uses credentials, such as username and password can be used. In accordance with an exemplary embodiment, the SPS server 10b can include a single sign-on (SSO) service. In accordance with an exemplary embodiment, the authentication module can be for access to the mobile client (or mobile device 20a) and/or used in connection with a single sign-on (SSO) process as disclosed herein.
In accordance with an exemplary embodiment, the mobile application (or software component) is an interface 360, 362 on the mobile client (or mobile device) 20a in which the user is authenticated before the user can avail (or access) any services from, for example, on premises software (for example, On Premises Legacy) and/or off premises software (for example, Cloud services). In accordance with an exemplary embodiment, the authentication of the user via a single sign-on (SSO) method (or protocol) can be done, for example, via biometrics, such as finger print, facial identification or facial recognition, iris detection, and/or username and PIN (personal identification number).
As shown in
In accordance with an exemplary embodiment, the colorimeter 580 can be an inline colorimeter (ICCU) (or spectrophotometer), which measures printed color patches in order to generate color profiles. In accordance with an exemplary embodiment, for example, the colorimeter (or spectrophotometer) 580 can be one or more color sensors or colorimeters, such as an RGB scanner, a spectral scanner with a photo detector or other such sensing device known in the art, which can be embedded in the printed paper path, and an optional finishing apparatus or device (not shown). A bus 592 can connect the various components 510, 520, 530, 540, 550, 560, 570, 580, and 590 within the multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b. The multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b also includes an operating system (OS), which manages the computer hardware and provides common services for efficient execution of various software programs. In accordance with an exemplary embodiment, it can be within the scope of the disclosure for the multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b to be a copier.
For example, in accordance with an exemplary embodiment, an image processing section within the multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b can carry out various image processing under the control of a print controller or CPU 510, and sends the processed print image data to the print engine 560. The image processing section can also include a scanner section (scanner engine 550) for optically reading a document, such as an image recognition system. The scanner section receives the image from the scanner engine 550 and converts the image into a digital image. The print engine 560 forms an image on a print media (or recording sheet) based on the image data sent from the image processing section. The central processing unit (CPU) (or processor) 510 and the memory 520 can include a program for RIP processing (Raster Image Processing), which is a process for converting print data included in a print job into Raster Image data to be used in the printer or print engine 560. The CPU 510 can include a printer controller configured to process the data and job information received from the one or more servers 10, the one or more mobile clients 20a, or client computers 20b, for example, received via the network connection unit and/or input/output section (I/O section) 590.
The CPU 510 can also include an operating system (OS), which acts as an intermediary between the software programs and hardware components within the multi-function peripheral. The operating system (OS) manages the computer hardware and provides common services for efficient execution of various software applications. In accordance with an exemplary embodiment, the printer controller can process the data and job information received from the one or more mobile clients 20a, or the one or more client computers 20b to generate a print image.
In accordance with an exemplary embodiment, the network I/F 590 performs data transfer with the one or more servers 10, and the one or more client devices 20a, 20b. The printer controller can be programmed to process data and control various other components of the multi-function peripheral to carry out the various methods described herein. In accordance with an exemplary embodiment, the operation of printer section commences when the printer section receives a page description from the one or more servers 10, and the one or more client devices 20a, 20b via the network I/F 590 in the form of a print job data stream and/or fax data stream. The page description may be any kind of page description languages (PDLs), such as PostScript® (PS), Printer Control Language (PCL), Portable Document Format (PDF), and/or XML Paper Specification (XPS). Examples of the multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b consistent with exemplary embodiments of the disclosure include, but are not limited to, a multi-function peripheral (MFP), a laser beam printer (LBP), an LED printer, a multi-function laser beam printer including copy function.
In accordance with an exemplary embodiment, the multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b can also include at least one auto tray or paper tray 570, and more preferably a plurality of auto trays or paper trays. Each auto tray or paper tray 570 can include a bin or tray, which holds a stack of a print media (not shown), for example, a paper or a paper-like product. The printer engine or print engine 560 has access to a print media of various sizes and workflow for a print job, which can be, for example, stored in the input tray. A “print job” or “document” can be a set of related sheets, usually one or more collated copy sets copied from a set of original print job sheets or electronic document page images, from a particular user, or otherwise related.
In accordance with an exemplary embodiment, the print media is preferably a paper or paper-like media having one or more print media attributes. The print media attributes can include, for example, paper color, coating, grain direction, printing technology, brightness, CIE, tint, whiteness, labColor, etc. In order to maximize print quality, the print media attributes of each type of print media should be input into or hosted on the printer 30a, 30b, for example, on printer configuration settings of the multi-function printer (MFP), imaging forming apparatus, the printer or the printing device 30a, 30b to obtain the highest quality output. Most print media is provided in reams or other known quantities, which are packaged with indicia such as information on the manufacture, size, type and other attributes of the print media. In addition, most bundles or reams of paper include a UPC (Universal Product Code) or bar code, which identifies the type of print media including manufacture of the print media.
In accordance with an exemplary embodiment, the client-less registration process 700 can include one or more preconditions for ensuring operability. For example, the one or more preconditions can include the software components 630 of the biometric vendor should be installed on the computing device (client PC) 20a . . . 20n, and the software components should be running. In accordance with an exemplary embodiment, the computing device 20a . . . 20n should have Web browser 640, for example, a standard default browser, and the solution provider server 710 is configured to execute (i.e., run) the generic registration proxy dispatcher 712 and register solution specific registration handler 714 with the generic registration proxy dispatcher 712 so that any appropriate registration requests intercepted by generic registration proxy dispatcher 712 are relayed to the solution specific registration handler 714. In addition, the computing device 20a . . . 20n should have a file 642, which includes the Registration URL address of the solution provider server 710.
In step 860, the browser (on behalf of biometric vendor software) & Generic Registration Proxy Dispatcher talks to each other to communicate registration request, user credential supplying , processing the response etc.
In accordance with an exemplary embodiment, the packet communications convey registration information, for example, as follows:
Registration Request:
Registration-Initialization Response, User Credential Challenge:
Registration Credential Response, User Credential Supply:
In accordance with an exemplary embodiment, by utilizing the functionality of the generic registration proxy dispatcher 712, the generic registration proxy dispatcher 712, which is compatible with any browser used as a computing device 20a . . . 20n (i.e., client) on behalf of biometric software component, the registration process can be accomplished with the intelligence carried in the packets that are exchanged in the POST data over a transport layer security (TLS) communication. Therefore, several solution vendors can be integrated with biometric solutions without the need for the solution vendors to write their software components and the requirement that the software components be installed on each and every client device 20a . . . 20n. After intercepting the packet from the client device 20a . . . 20n, the generic registration proxy dispatcher allows the port-processed data to the registered (software registration via callback functions) runtime solution-specific user registration handler in the given deployment.
In accordance with an exemplary embodiment, it would be desirable to have a method and system for new user registration and authentication procedures to achieve avoidance of user re-registration on a pristine computing device 20b. In accordance with an exemplary embodiment, a pristine computing device 20b can be any client or computing device in which the user and corresponding device tied to the user has not been authenticated via, for example, a mobile device 20a.
As set forth above, currently the biometric based client-server authentication systems have four flows, user registration, user authentication, user roaming authentication, and a user de-register and/or revocation flow. In accordance with an exemplary embodiment, user registration processes involve recording user's profile (for example, credentials, etc.) and the address and information of the biometric device in the solution server, as the server performs user's credentials registration in a secure fashion. For example, the registration of the user's credential can include username and password for credential storing.
In accordance with an exemplary embodiment, when a user uses a platform-authenticator or secure-container (such as a trusted platform module (TPM) chip etc.) hosted by a computing engine (for example, Windows 10, etc.) during the main registration process, the user is also provisioned with a smartcard certificate whose private key can be securely contained in the security container. The authentication server can allow smartcard certificate provisioning to users because the user has been authenticated (i.e., strongly authenticated) at the end of user registration.
In accordance with an exemplary embodiment, when that user happens to roam and use another computing engine (for example, another Windows 10, etc.) the current client server authentication systems force the user and corresponding biometric device 22 to undergo a re-registration process as that computing engine and its platform-authenticator or security container has no security context for the user which was only obtained on the computing engine where the user registered using a username and password. Such a lack of security context arises from the fact that user is not presenting enough credentials to the authenticating server, as strong as the user did during the registration that took place on the previous (prior to roaming) computing engine.
In accordance with an exemplary embodiment, one typical use case for requiring re-registration on the roamed computing engine is when user wants to perform Active Directory (AD) login from this new machine, but requires a smart card certificate to be available on that computing engine which can be obtained via enrollment from the authentication server. However, the authentication server cannot provide smartcard certificate enrollment because the user cannot provide any authenticable context from the new machine. This conventional problem forces the user to re-register (for example, repeat) using user name and password, for each and every machine the user roams to and wants smartcard certificate.
In accordance with an exemplary embodiment, a method and system is disclosed to achieve secure enrolment of smart card certificate without re-registration. In accordance with an exemplary embodiment, a method and system is disclosed that can help security context on a pristine computing engine, without re-registration by user, and wherein the secure authentication or roaming-authentication occurs (i.e., happens) on the pristine machine (for example, a Windows laptop) by using two-factor authentication-secure (2FA-secure) PKI-based authentication with a roaming authenticator, which is available in the close proximity of pristine machine. In accordance with an exemplary embodiment, it would be desirable to have a client server authentication system, which can avoid the necessity of re-registration as disclosed herein.
In accordance with an exemplary embodiment, communications between the main authentication client on the computing device (for example, a personal computer (PC) and the solution specific application 1012 on the roaming authenticator 1010 can be via wireless, for example, running a regular RESTful communication. In accordance with an exemplary embodiment, the solution specific application on the mobile device 1010 can be configured to acts as companion to the main authentication client (on computing device or personal computer (PC)) to help achieve authentication on the computing device (or PC).
In accordance with an exemplary embodiment, at the end of current registration flow of any given client-server based secure authentication systems, the user can be given the choice to add a set of roaming authenticators to reduce the need to authenticate each and every computing device 20a . . . 20n. In accordance with an exemplary embodiment, roaming authenticators can be, for example, either an Android mobile device or iOS mobile device 20a. In accordance with an exemplary embodiment, the iOS mobile device can be, for example, an iPhone®.
In accordance with an exemplary embodiment, the Android mobile device should support Keystore, and iOS should support Keychain. If the user has either an Android mobile device or an iOS, which supports Keychain, in accordance with an exemplary embodiment, the user can consent to the method and systems as disclosed for authentication without re-registration. In accordance with an exemplary embodiment, during this additional registration the authentication server establishes a PKI-Credential to all of the user's main biometric registrations. For example, during the registration flow, as a first step, the server verifies the attestation of PKI credential resident (iOS or Android device). In addition, the authentication flow utilizes an new interaction between a main registration client and companion mobile application to securely send the crypto-based user assertion that is verified, for example, in 2FA fashion at the roaming authenticator 910 (
As shown in
In accordance with an exemplary embodiment, in step 1130, the user starts the solution specific application hosted on the mobile device 1010, and enters the unique code displayed on the computing device 1102, and in step 1132 sends RESTful message to the main registration client hosted on the computing device 1102. In step 1140, the received message from the mobile device 1010 is relayed to the authentication server 900 to start the registration process for the mobile device 1010 (mobile roaming authenticator). In step 1150, the authentication server creates a Public Key Infrastructure (PKI) Credential (challenge), which is sent to the computing device 1102. In step 1160, the created PKI Credential (challenge) is forwarded from the computing device 1102 to the mobile device 1010. In step 1170, the mobile device 1010, generates a Key Pair and signs the Challenge. In step 1172, the mobile device 1010 sends the Public Key and Android/iOS Attestation Certificate to the computing device 1102. In step 1180, the computing device 1102 relays the received crypto message to the authentication server, wherein the relayed message can include the Signed Challenge+Public Key+Attestation.
In accordance with an exemplary embodiment, in step 1182, the attestation is verified by the authentication registration server 910 with Android/iOS attestation certificate authority (CA), then challenge is verified against received public key, which registers the roaming authenticator. In step 1184, the Public Key (Roaming PKI Credential) credential is linked against all existing primary biometric registration database entries.
As shown in
In step 1230, the user on the mobile device 1010 starts the solution specific application and enters the unique random code displayed on the computing device 1102, which was received from the authentication registration server 910. In accordance with an exemplary embodiment, the unique random code can be numbers, letters, symbols and/or a combination of letters, numbers, and/or symbols. In step 1232, the mobile device 1010 sends RESTful message to the solution specific main registration client on the computing device 1102. In step 1240, if the supplied unique random code sent by mobile application matches the unique random code, the process continues by asking mobile app to generate crypto-based user assertion.
In step 1250, the user is prompted to unlock a secure container (for example, Android: Strong Box/Android KeyStore, or iOS: keychain) by requesting the user to enter, for example, a fingerprint, personal identification number (PIN) and/or password. The solution specific application can be configured to prepare signed (using user private key) assertion on the set of user details, for example, username, and encrypts the assertion using server's CA public key. In step 1252, an encrypted message as a response is sent to the solution specific main registration client on the computing device 1102.
In step 1260, the received crypto message is relayed to the authentication server, for example, as a message, for example, Encrypted(SignedAssertion(userpricipalName, signed-with-user privatekey),encrypted-with-server's public key)). In step 1270, the authentication server processes the message and decrypts the assertion using server's CA private key, and verifies the resultant decrypted assertion using User's Public Key (available at Registration phase) in the PKI-credential anchor chain. In step 1280, the user is authenticated, for example, user is 2FA authenticated at Solution Specific Main Registration Client as user is 2FA verified by companion mobile roaming authenticator, and smartcard certificate enrollment and all other secure privileges are now authorized by the authentication server 1280.
User registration process involves recording user's profile (for example, credentials, etc.) and the associated biometric device address information in the server, as the server performs user's credentials registration in a secure fashion. Typically, username and password can be used for storing credentials of the user.
As set forth above, currently the biometric based client-server authentication systems have four flows, a user registration flow, a user authentication flow, a user roaming authentication flow, and a user de-register/revocation flow. Out of these flows, the user roaming authentication flow can present constraints to the user, for example, during authentication, where the user is restricted to avail provisioned end services only on that computing machine hosting the authenticator. Thus, this one-to-one mapping forces the user to have multiple registrations.
For example, if the user chooses to use an Android and/or iOS device as an authenticator, the user performs user registration on that device (using fingerprint/PIN/Touch ID/Face ID, etc.) that talks to the authenticating server. After registration, the user can use that device to authenticate and avail provisioned services. However, the user cannot use another device/computing engine (for example, the device or computing has bigger display/real estate) to access services.
Thus, the user has no choice, but to use the same registered device to be used in authentication phase to receive provisioned services. For example, the user suffers constraints on which kind of computing machine the user (i.e., he/she) can avail roaming authentication. In general, these constraints are as a result of the roaming authenticators and the restrictions of the roaming authenticators can include that the roaming authenticator don't support, for example, certain operating system (OS)/platforms, or for the OS/platforms they support, each need a special driver to be installed on the computing machine where the user avails the services hosted on the OS/platform. Thus, users are limited to only certain platforms, which are supported by varying set of authenticators.
For example, a roaming biometric authenticator indicates that RA1 (i.e., roaming authenticator 1) works with authenticating server (AS), and wherein, RA1 is supported on Windows and Linux. Once the user registration is performed on any computing engine that is based on Windows or Linux, the user (i.e., he/she) can get authenticated on any compatible computing engine. For this to be successful, the authenticating machine should have all corresponding software, firmware and driver components installed. However, the user (i.e., he/she) cannot authenticate on a computing engine based on MAC OS.
For example, for ‘N’ number of roaming biometric authenticators, the users must install different software, firmware and driver components, and the users may still face a degree of incompatibility.
In addition, users can be limited to avail or access services in one mode. For example, the user registered his Android phone with a server. When the user (i.e., he/she) authenticates with the system using the registered phone, the user (i.e., he/she) can only receive the services on that device. If he wants to choose to avail services (for example, in a secure 2FA manner) on a device that has bigger display, the current technology has no solution.
Furthermore, the user may suffer poor performance (speed) of roaming authentication flow, for example, the relative high latency can be purely caused by just how several software components are designed to interact.
Accordingly, it would be desirable to have a method and system, which applies to any kind of comprehensive network security systems offering secure authentication and service authorizations solutions for the enterprise users, and which helps solve the traditional problems faced by current industry as set forth above.
In accordance with an exemplary embodiment, universal captive roaming authentication can be achieved with a one-time multiple-registration chain with PKI-credential anchoring, dual-mode feature, which can include: resident-authenticate services on resident device experience, and roaming-authenticate services on foreign devices, and wherein both dual mode features are available at the same time to a user, or alternatively, the user can select only one of dual-mode features. In addition, the universal roaming authentication can include a universal roaming experience, relatively fast roaming authentication, and interoperability.
In accordance with an exemplary embodiment, the registration flow can include at the end of current registration flow of any given client-server based secure authentication systems, the user can be given the choice to add set of captive roaming authenticators. In accordance with an exemplary embodiment, the captive roaming authenticators can be, for example, an Android mobile device or iOS mobile device. For example, an Android device should be able to support Keystore, and iOS should be able to support Keychain. If the user has either of those types of devices (i.e., an Android or iOS based mobile device) and the user consents, then the authentication server can establish an Anchor PKI-Credential chained to the user's (i.e., his/her) main registration. In accordance with an exemplary embodiment, for example, for each captive roaming authenticator user attempts to add, a PKI-Credential can be anchored to the existing per-user credential chain. For example, in accordance with an exemplary embodiment, during the registration flow the server, as a first step, verifies the attestation of PKI credential resident (iOS or Android device).
In accordance with an exemplary embodiment, in the captive roaming authentication flow, the user using a client device (for example, Android or iOS mobile device) that supports captive roaming authentication, and uses a software application running a captive roaming authentication (CRA) protocol, and places the client device, for example, a mobile device 1102a close (i.e., with a predefined distance) to any computing device (for example, a computer running Windows, MAC, or Linux) where the user wants to obtain an authenticated state, and once authenticated, the user is able to avail or access secure service access authorizations.
In accordance with an exemplary embodiment, the computing device should be running the service or application that acts as a captive roaming authentication protocol peer (i.e., CRA protocol peer). As soon as these applications running a CRA protocol execute a handshake, the user can be prompted to unlock a secure container (for example, Android: Strong Box/Android KeyStore, or iOS: keychain) using an authenticator, for example, finger print/Touch ID/Face ID/PIN.
Note that all these authenticators act as a 2nd Factor authentication (i.e., two-factor authentication (2FA)) while the 1st factor being the private key contained securely in the mobile device's secure container. In accordance with an exemplary embodiment, as soon as user performs the 2nd factor authentication, the mobile application sends the signed assertion (encrypted with user's private key) carrying, for example, the user's email identifier (ID), which is encrypted with server's public key. In accordance with an exemplary embodiment, such an assertion can be silently relayed by the CRA protocol-peer app/service on the computing engine (for example, Windows, MAC, or Linux) by launching any standard system browser (for example, Chrome, Firefox, Safari, etc.) and posting the encrypted signed assertion to the authentication server, and waiting for a server response (for example, success or failure). In accordance with an exemplary embodiment, this silent, relatively quick and seamless relay by the application or service can be called captive roaming authentication. Apart from tapping the biometric device nearby the computing engine, the use of the biometric device is not expected to perform any action other than, for example, performing a 2nd factor authentication.
In accordance with an exemplary embodiment, the authentication server can be configured to, for example, decrypt the signed assertion using server's (CA) private key, and verify the assertion using user's (whose identity is available from HTTP information) public key in the PKI-anchor chain. In accordance with an exemplary embodiment, the authentication server can assert that the user is authenticated and creates, for example, a JSON Web Token (JWT) and supplies a session cookie to the browser on the computing engine. In addition, the user can be provided with cloud based (like SAML) and on-premise based services (i.e., locally based services). Furthermore, optionally other enrollments can also be offered.
In accordance with an exemplary embodiment as shown in
In step 1350, the authentication server receives the request from the mobile device 1010 and creates a PKI User Credential(challenge), which is sent to the mobile device 1010. In step 1352, the mobile device 1010 generates a Key Pair and signs the challenge. In step 1360, the mobile device sends the signed Challenge, the Public Key, and an Android/iOS attestation certificate to the authentication server 910. In step 1370, the authentication server 910 receives the Signed Challenge+Public Key+Attestation, and performs attestation verified by server with Android/iOS attestation certificate authority (CA), the Challenge is verified against received public key, and which at this point a captive roaming authenticator is registered. In step 1380, an Anchor/Link to the Public Key (Roaming PKI Credential) credential against the primary registration artifact for the user (i.e. he/she) is established with main registration client registration flow. In accordance with an exemplary embodiment, at this point the user is FREE, i.e., the user doesn't need the same main registration client when the user (i.e., he/she) wants to be authenticated, and the user can go to any machine with an NFC reader and be authenticated.
In accordance with an exemplary embodiment, steps 1330 through 1380 repeat, for every captive roaming authentication (CRA) device the user wants to add (i.e., access), and wherein the authentication server 910 registers a credential chain of length 1 or more, per user, for example, as shown in
As shown in
In step, 1430, the mobile device starts a request, for example, “CaptiveCredentialRoaming Authentication”, and obtains authentication server 910 details, and constructs, for example, a URL, i.e., “LetMeRoamServer URL”. In accordance with an exemplary embodiment, the received NFC record will have signed content as Assertion [username]. This assertion is signed by user Credential's private key inside a secure container, for example, such as Strongbox/Android: KeyStore. The assertion can be encrypted, for example, by Server Authentication Public key, and encrypted assertion is sent to the authentication server 910. In step 1440, the authentication server 910 processes the GET request, decrypts the assertion using the server's CA private key, and verifies the resultant decrypted assertion using the User's Public Key (available at Registration phase) in the PKI-credential anchor chain. In step 1450, if the transaction is successful, the computing device 1010 (i.e., user 24) is advised that the transaction was successful.
In accordance with an exemplary embodiment, the user 24 can be two-factor authentication (2FA) roaming authenticated. For example, the user can be presented with a services page gallery, in which the user can access SAML and OpenAPI services. Optionally, the authentication server can ask the user if he/she wants to enroll for Smart Card Logon certificate for On-Premises Domain Access promotion.
In accordance with an exemplary embodiment, for example, as shown in
As shown in
In accordance with an exemplary embodiment, steps 1610, 1620, 1630 can be performed on any client device 20a, 20b, which runs (i.e., executes) the captive roaming authentication protocol, and wherein the client device 20a, 20b, can be, for example, a mobile client 20a, 1102a, a computing device 1010a, 1010b, 1010c, 1010d, 1102b, and/or a multi-function printer 30a, 30b. In accordance with an exemplary embodiment, steps 1640 can be performed on a computing device which also runs (i.e., executes) the captive roaming authentication protocol, for example, a computing device 1010a, 1010b, 1010c, 1102b, 1102c, and/or a multi-function printer 30a, 30b.
In accordance with an exemplary embodiment, the user performs the registration on his mobile device 1102 (for example, an Android phone). At this point the authentication server 910 has the user's PKI credential anchored to the existing chain that has the linked list of prior users and authenticator's credentials registration information for the prior users. If the user decides to go to an iOS device 1010d (for example, an iPad Pro) that has bigger display real estate to view his provisioned services, instead of using his mobile phone 1102a (which the user registered with the authentication server 910 during step 1610). However, if the iPad Pro does not have any security context for user to present to the server, this is where the captive authentication triggers to seamlessly attain the security context for the user.
In accordance with an exemplary embodiment, the user moves into relative close proximity (i.e., within a predefined distance) to the iPad Pro. The CRA protocol peers on both the Android mobile phone 1102a and the iPad Pro 110d communicate with each other, 2FA process on mobile phone is executed, and the authentication server 910 receives crypto-based user assertion, which the authenticating server 910 can verify and conclude that the user is authenticated. In accordance with an exemplary embodiment, since the user is authenticated, the authenticating server 910 can generate a cookie and redirect the browser session to the user with provisioned services being availed on the iPad Pro 1010d.
In accordance with an exemplary embodiment, as disclosed herein, the user can achieve universal roaming authentication without a complex set of biometric provider's and solution vendor's client side software components. Thus, the user can get high performance (speed) of roaming authentication flow. For example, using the thin service/app that runs a relatively simple CRA protocol that launches the browser, which brings the functionality provided by other complex software systems that exist today.
In accordance with an exemplary embodiment, as per the sequence diagram for roaming authentication flow as shown in
Time taken for CRA protocol packet via NFC-record message from device to computing engine+Time taken for launching browser+Time taken for sending HTTP POST message to Server+Time taken by Server to perform PKI operation [decrypt message+verify assertion]+Time taken by HTTP response back to computing engine with set of services.
In accordance with an exemplary embodiment, the disclosed CPA protocol can be theoretically faster compared with any other roaming authentication flows, which are similar client-server based security systems architectures that offer the same level of security strengths.
In accordance with an exemplary embodiment, the method and system for universal roaming has the interoperability brought by the goal of the CRA protocol. In accordance with an exemplary embodiment, the CRA protocol can allow for interworking of any set of applications and/or services on computing engines with any set of mobile devices that support secure container. In addition, the CRA protocol also provides for other means of transport/communication channels, other than NFC as long as the peers talk the CRA protocol, the captive authentication roaming can be tangible.
In accordance with an exemplary embodiment, as shown in
In accordance with an exemplary embodiment, the protocol can be as follows:
0x01: Registration Request
0x02: Registration Response
0x03: Roaming Authentication Request
0x04: Roaming Authentication Response
0x01: PKI Attestation Object (that attests resident authenticator)
0x02: Public Key Object
0x03: Challenge
0x04: Challenge Response
0x05: Signed User Assertion with No encryption
0x06: Signed User Assertion with Encryption
In accordance with an exemplary embodiment, the CRA message, for example, can be per the Registration and Authentication flows CRA message in the protocol contains cryptographic messages between Android/iOS device (CRA-compliant authenticator) and the Authentication Server, these message can be silently relayed by CRA protocol-peer on the host device (with NFC reader) upon user's intent through, for example, an NFC tap with the biometric device 22.
In accordance with an exemplary embodiment, messages are either (choice is given for interoperability):
1. Cryptographically Signed User Assertion without any Encryption. Signing is done by simply encrypting the information of user/principal who is authenticating.
2. Cryptographically Signed User Assertion and the resulted signed assertion Encrypted with server's public key.
In accordance with an exemplary embodiment, the methods and processes as disclosed can be implemented on a non-transitory computer readable medium. The non-transitory computer readable medium may be a magnetic recording medium, a magneto-optic recording medium, or any other recording medium which will be developed in future, all of which can be considered applicable to the present invention in all the same way. Duplicates of such medium including primary and secondary duplicate products and others are considered equivalent to the above medium without doubt. Furthermore, even if an embodiment of the present invention is a combination of software and hardware, it does not deviate from the concept of the invention at all. The present disclosure may be implemented such that its software part has been written onto a recording medium in advance and will be read as required in operation.
As used herein, an element or step recited in the singular and preceded by the word “a” or “an” should be understood as not excluding plural elements or steps, unless such exclusion is explicitly recited. Furthermore, references to “example embodiment” or “one embodiment” of the present disclosure are not intended to be interpreted as excluding the existence of additional examples that also incorporate the recited features.
The patent claims at the end of this document are not intended to be construed under 35 U.S.C. § 112(f) unless traditional means-plus-function language is expressly recited, such as “means for” or “step for” language being expressly recited in the claim(s).
It will be apparent to those skilled in the art that various modifications and variation can be made to the structure of the present invention without departing from the scope or spirit of the invention. In view of the foregoing, it is intended that the present invention cover modifications and variations of this invention provided they fall within the scope of the following claims and their equivalents.
