OpenID Offloading Proxy

Abstract

To provide a method, a non-transitory computer readable medium, and a computer system for accessing protected resources.SOLUTION: A method includes: receiving, by a processor, a request from an OpenID-unaware application for access to a protected resource; authenticating, by the processor, the OpenID-unaware application; establishing, by the processor, an OpenID connection with an OpenID relying party upon authentication of the OpenID-unaware application; and receiving, by the processor, an access token issued by an OpenID identity provider for the OpenID-unaware application for access to the protected resource.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present disclosure generally relates to an OpenID offloading proxy, and more particularly, to a method and system for accessing a protected resource from an OpenID non-compliant application by establishing an OpenID connection with an OpenID relying party by an OpenID offloading proxy that communicates with the OpenID non-compliant application.

Background Art

[0002] OpenID is a technical standard that provides a framework for communication that occurs in a variety of different ways involving software applications, users, identity providers, and OpenID acceptors (or relying parties). The OpenID framework standardizes various different tokens for application programming interface (API) access control. The API-based security portion of OpenID is inherited from OAuth 2.0.

[0003] API security is a critically important component for an application, but it also introduces additional design and implementation complexity to each application. Thus, traditional and classical ways of OpenID integration may not be considered ideal for applications being developed today. For example, regardless of the protocols and OpenID flow requirements involved, each application needs to be OpenID compliant, i.e., each application needs to have software code (or code) that performs the network operations necessary to satisfy the OpenID protocol.

[0004] A complex software system comprises a variety of distributed applications that securely exchange data using an OpenID-based API security mechanism. An application programming interface access permission token is obtained by requesting it from an application, and the service / application that permits access can be another application within the same system or a third-party application by a different vendor. The conventional OpenID approach with secure API access requires each application to be OpenID-compliant. Since each application needs to have a portion of software code (or code) that performs the network operations necessary to satisfy the OpenID protocol, this requirement can add development costs and delay the release of the application to the market.

Summary of the Invention

Problems to be Solved by the Invention

[0005] In view of the above problems, it is desirable to have a solution that provides a unique centralized OpenID offloader, which can be an OpenID offloading proxy that reduces the burden of the OpenID semantics from the application and, in particular, eliminates the abstraction of the specific design and implementation burden (otherwise required), and the application does not need to be OpenID-compliant (i.e., the application is non-OpenID-compliant). Furthermore, it may be desirable for the solution to provide an HTTP handshake by an OpenID offloading proxy that can be implemented to assist in authentication through API calls.

Means for Solving the Problems

[0006] According to one aspect, a method for accessing a protected resource is disclosed. The method includes receiving, by a processor, a request from an OpenID-incompatible application for access to the protected resource; authenticating, by the processor, the OpenID-incompatible application; establishing, by the processor, an OpenID connection with an OpenID relying party upon authentication of the OpenID-incompatible application; and receiving, by the processor, an access token issued by an OpenID identity provider for the OpenID-incompatible application for access to the protected resource.

[0007] According to another aspect, a computer program product for accessing a protected resource With comprises a non-transitory computer-readable storage medium having program instructions embodied therewith, the program instructions being executable by a computer to perform a process comprising receiving, by the computer, a request from an OpenID-incompatible application seeking access to the protected resource; authenticating the OpenID-incompatible application; establishing an OpenID connection with an OpenID relying party upon authentication of the OpenID-incompatible application; and receiving, for the OpenID-incompatible application for access to the protected resource, an access token issued by an OpenID identity provider.

[0008] According to a further aspect, a computer system comprises a memory and a processor, the processor being configured to receive a request from an OpenID-incompatible application for access to a protected resource, authenticate the OpenID-incompatible application, establish an OpenID connection with an OpenID relying party upon authentication of the OpenID-incompatible application, and receive an access token issued by an OpenID identity provider for the OpenID-incompatible application for access to the protected resource.

[0009] The accompanying drawings are included to provide a further understanding of the invention, are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the invention and together with the general description serve to explain the principles of the invention.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Modes for Carrying Out the Invention

[0011] Next, presently preferred embodiments of the invention are referred to in detail, examples of which are shown in the accompanying drawings. Wherever possible, the same or similar parts are referred to by the same reference numerals in the drawings and in the description.

[0012] FIG. 1 is a diagram of a current OpenID-based ecosystem 100. As shown in FIG. 1, the current OpenID-based ecosystem 100 can include one or more protected resources 110 and an on-premises system 120. The one or more protected resources 110 can be configured to be accessed through one or more resource application programming interfaces (APIs) 111, 112, 113, an OpenID relying party (RP) 114, an OpenID provider (or OpenID identity provider) 116, and one or more OpenID-compliant client applications 122, 124. The one or more resource application programming interfaces (APIs) 111, 112, 113 (or end users) can be, for example, software development kits (SDKs) / application programming interfaces (APIs) that interact with an OpenID relying party (RP) 114. The one or more protected resources 110 can also be hosted on one or more cloud servers 115 having an OpenID relying party 114. Alternatively, the one or more protected resources 110, the OpenID relying party 114, and the OpenID provider 116 can be hosted on one or more cloud servers 115, 117.

[0013] One or more resource application programming interfaces (APIs) 111, 112, 113 are entities for which identification information is requested. For example, in OAuth 2.0, this can be called the resource owner. The OpenID relying party 114 is a client application that supports OAuth 2.0 and depends on the OpenID provider 116 to authenticate the user (or end-user) 130 and the requested information or credentials about that user 130. The OpenID provider 116 can be, for example, an OAuth 2.0 authorization server that provides user authentication, user consent, and token issuance as services. The OpenID provider 116 helps ensure that the user 130 is authenticated and brings information or credentials about the user 130 and the authentication event to the OpenID relying party 114.

[0014] The OpenID provider 116 can provide information about the user 130 to the OpenID relying party 114 OIDC through a token or identity information token. Different types of tokens can be exchanged between one or more resource application programming interfaces (APIs) 111, 112, 113, the OpenID relying party (RP) 114, the OpenID provider (or OpenID identity provider) 116, and one or more OpenID-compliant client applications 122, 124 to confirm the identity information or provide access authorization. Tokens establish the user's identity information during transactions between one or more resource application programming interfaces (APIs) 111, 112, 113, the OpenID relying party (RP) 114, the OpenID provider (or OpenID identity provider) 116, and one or more OpenID-compliant client applications 122, 124.

[0015] The token type may include one or more of an identifier (ID) token and an access token. The ID token may be similar to an ID card or a passport and includes many necessary attributes or credentials for user 130. The ID token may be a JSON (JavaScript Object Notation) Web Token (JWT) that is digitally signed using JSON Web Signature for relatively high-level security. The access token authorizes the OpenID relying party 114 to obtain end-user-owned resources from a resource server associated with one or more resource application programming interfaces (APIs) 111, 112, 113. The access token may be an opaque token that is verified by fetching information or credentials of user 130 from an endpoint, for example, the "UserInfo endpoint". The UserInfo endpoint is an OAuth 2.0 protected resource of the Connect2id server where a client application can retrieve agreed-upon credentials or assertions about the logged-in end-user. The credentials can be packaged within a JSON object, and the sub-member may represent a subject or user (end-user) identifier.

[0016] As shown in FIG. 1, user 130 may request protected resource 110 through one or more OpenID-compliant client applications 122, 124, through OpenID relying party (RP) 114 (104), and through one or more resource application programming interfaces (APIs) 111, 112, 113. OpenID relying party 114 may communicate with OpenID provider 116 through one or more modes (105) that may include a checkid_immediate mode (104) and a checkid_setup mode (102). In the checkid_immediate mode (104), OpenID relying party (RP) 114 requests that OpenID provider 116 not interact with one or more OpenID-compliant client applications 122, 124 such that all communications are relayed through the user agent for one or more OpenID-compliant client applications 122, 124 without being explicitly notified to one or more OpenID-compliant client applications 122, 124. In checkid_setup (102), one or more OpenID-compliant client applications 122, 124 communicate with OpenID provider 116 through the same user agent used by one or more OpenID-compliant client applications 122, 124 to access OpenID relying party (RP) 114. OpenID relying party (RP) 114 and OpenID provider 116 may optionally establish a shared secret that is referenced by a related handle that OpenID relying party (RP) 114 then stores. When using the checkid_setup mode, OpenID relying party (RP) 114 redirects the user agent of one or more OpenID-compliant client applications 122, 124 to OpenID provider 116 such that one or more OpenID-compliant client applications 122, 124 can be directly authenticated by OpenID provider 116.The authentication method can be various, but usually, the OpenID provider 116 prompts one or more OpenID-compliant client applications 122, 124 for a password or some cryptographic token, and the OpenID provider 116 is the OpenID relying party (RP) for one or more OpenID-compliant client applications 122, 124 to receive the required identification information details. 114 asks whether to trust.

[0017] If one or more OpenID-compliant client applications 122, 124 reject the OpenID provider's request that they trust the OpenID relying party (RP) 114, the user agent of one or more OpenID-compliant client applications 122, 124 is redirected back to the OpenID relying party 114 with a message indicating that the authentication has been rejected, and instead the relying party rejects authenticating one or more OpenID-compliant client applications 122, 124.

[0018] When one or more OpenID-compliant client applications 122, 124 accept a request from an OpenID provider 116 to trust an OpenID relying party (RP) 114, the user agents of the one or more OpenID-compliant client applications 122, 124 are redirected back to the OpenID relying party (RP) 114 along with the end user's credentials. The OpenID relying party 114 must then verify that the credentials actually came from the OpenID provider 116. If the OpenID relying party (RP) 114 and the OpenID provider 116 had previously established a shared secret, the OpenID relying party (RP) 114 can verify the identity information of the OpenID provider 116 by comparing a copy of its shared secret with what was received along with the credentials of the one or more OpenID-compliant client applications 122, 124. The OpenID relying party (RP) 114 is called "stateful" because it remembers the shared secret during the session. In contrast, a "stateless" or "processingless" relying party must perform a background request (check_authentication) again to ensure that the data actually came from the OpenID provider 116.

[0019] After the OpenID is confirmed, the authentication is considered successful, and the OpenID-compliant client applications 122, 124 are considered logged in to the OpenID relying party (RP) 114 under the identity information specified by the given OpenID. The OpenID relying party (RP) 114 then typically stores the OpenID of the OpenID-compliant client applications 122, 124 along with other session information of the OpenID-compliant client applications 122, 124.

[0020] As shown in FIG. 1, the OpenID provider 116 authenticates the user 130 through one or more OpenID-compliant client applications 122, 124, and the qualification, or set of qualifications, for identifying the information required for the authentication of the user 130 can be satisfied, and for the user 130, an OIDC token can be issued to one or more OpenID-compliant client applications 122, 124.

[0021] After the OIDC token is issued by the OpenID provider 116, one or more OpenID-compliant client applications 122, 124 submit the OIDC token to the OpenID relying party (RP) 114. The OpenID relying party (RP) 114 verifies the OpenID token and permits the user 130, through one or more OpenID-compliant client applications 122, 124, to access one or more protected resources through one or more resource application programming interfaces (APIs) 111, 112, 113.

[0022] Next, one or more OpenID-compliant client applications 122, 124 can securely access one or more protected resources 110 (106) through one or more resource application programming interfaces (APIs) 111, 112, 113, for example, through a software development kit (SDK) / application programming interface (API).

[0023] Figure 2 is a diagram of the OpenID ecosystem 200 by the OpenID offloading proxy 210 according to an exemplary embodiment. As shown in FIG. 2, the OpenID-based ecosystem 200 may include one or more protected resources 110 accessible through one or more resource application programming interfaces (APIs) 111, 112, 113. The OpenID-based ecosystem 200 may also include an OpenID relying party (RP) 114, an OpenID provider (or OpenID identity provider), for example, an OpenID provider having role-based access control (RBAC) 216, an OpenID offloading proxy 210, and one or more OpenID-incompatible client applications 220, 222. The one or more resource application programming interfaces (APIs) 111, 112, 113 may include, for example, a software development kit (SDK) / application programming interface (API) that interacts with the OpenID relying party (RP) 114. The one or more protected resources 110 accessible through the one or more resource application programming interfaces (APIs) 111, 112, 113 and the one or more resource application programming interfaces (APIs) 111, 112, 113 may also be hosted on one or more cloud servers 115, 117 having an OpenID relying party 114, and role-based access control (RBAC) 216 may be hosted on an OpenID provider having. According to one embodiment, the OpenID provider having RBAC 216 may be configured to restrict access, for example, to authorized users 130, which may be implemented, for example, through a mandatory access control (MAC) or discretionary access control (DAC) protocol.

[0024] The OpenID offloading proxy 210 and one or more OpenID-incompatible client applications 220, 222 can be on-premises, i.e., installed on one or more computers 221, 223 on the premises of a user 130 or an organization using software and operating on the on-premises software. Alternatively, one or more OpenID-incompatible client applications 220, 222 can be software installed and operating in a remote facility of an edge computing system or a cloud computing system such as a server farm or cloud 225.

[0025] According to one embodiment, one or more OpenID-incompatible client applications 220, 222 may require an initial handshake and passage through the application OpenID lifecycle (finite state machine) by the OpenID offloading proxy 210. The OpenID offloading proxy 210 and one or more OpenID-incompatible client applications 220, 222 may communicate with each other, for example, through a PKI-based application authentication method. For example, the PKI-based application authentication method may use certificates to verify data sent from one point to another. Each of the OpenID offloading proxy 210 and one or more OpenID-incompatible client applications 220, 222 has a public key and a private key. Under PKI certificate-based authentication, the public key is shared and used to verify the identification information between the user 130 and the corresponding one or more OpenID-incompatible client applications 220, 222 by sending and decrypting data.

[0026] According to one embodiment, one or more OpenID-incompatible client applications 220, 222 may interact with the OpenID offloading proxy 210 by connecting, for example, using standard Secure Hypertext Transfer Protocol (HTTPS) means. The OpenID offloading proxy 210 terminates the incoming HTTPS connections from each of the one or more OpenID-incompatible client applications 220, 222 and maps the details onto a new connection with the OpenID relying party (RP) 114 in order to access the protected resource 110 through one or more resource application programming interfaces (APIs) 111, 112, 113 (mediate and conform).

[0027] As shown in FIG. 2, the OpenID offloading proxy 210 may request the protected resource 110 through one or more resource application programming interfaces (APIs) 111, 112, 113 on behalf of the one or more OpenID-incompatible client applications 220, 222 (204). According to one embodiment, during the authentication phase of each of the one or more OpenID-incompatible client applications 220, 222, the OpenID offloading proxy 210 establishes an OpenID connection with the OpenID relying party (RP) 114 and initiates a flow towards the OpenID provider having RBAC 216. The OpenID provider 216 authenticates the user 130 through the one or more OpenID-incompatible client applications 220, 222, and the qualifications, or set of qualifications, identifying the information requested for the authentication of the user 130 may be met, and an OIDC token may be issued to the OpenID offloading proxy 210 on behalf of the user 130 and the one or more OpenID-incompatible client applications 220, 222.

[0028] After an OIDC token is issued by an OpenID provider having RBAC216, the OpenID offloading proxy 220 may establish an OpenID connection with the OpenID relying party (RP) 114 by presenting the OIDC token to the OpenID relying party (RP) 114 (204). The OpenID relying party (RP) 114 verifies the OpenID token and permits the user 130, through one or more OpenID non-compliant client applications 220, 222, to access one or more protected resources 110 through one or more resource application programming interfaces (APIs) 111, 112, 113 (206).

[0029] According to one embodiment, one or more OpenID non-compliant applications 220, 222 may be hosted on a computer system or client device 221. The computer system or client device 221 may be, for example, a multifunction peripheral or multifunction printer (MFP), a computer system, a personal computer, a mobile device, a smartphone, a smart tablet, or a smartwatch. Further, the authenticator 240 may be, for example, a biometric band used for authenticating the user 130 on one or more OpenID non-compliant applications 220, 222. The computer system or client device 221 may alternatively be, for example, a medical device or medical apparatus, which may be used, for example, for diagnostic and / or treatment purposes. Examples of medical devices or medical apparatuses may include medical imaging devices, which may acquire, for example, radiographic images, angiographic images, ultrasonic images, and / or tomographic images.

[0030] According to one embodiment, one or more OpenID-incompatible applications 220, 222 may be for accessing a protected resource 110 that may be a secure software application. For example, one or more OpenID-incompatible applications 220, 222 may be applications that access a secure software application that manages printing services associated with a multifunction peripheral or a multifunction printer (MFP). The printing services may include, for example, one or more of user authentication, monitoring and reporting, user and cost management, cost accounting and budget management, printer queue management, and workflow management. For example, user authentication may include controlling the identification information of user 130, and the control of the identification information may help ensure that user 130 is authenticated on the device before a print job is released and / or printed. The monitoring and reporting function may enable an administrator to track and monitor usage in real time through periodic reporting, scheduled reporting, and on-demand reporting. The user and cost management function may help manage and charge back costs by allowing the assignment of users to cost centers or the selection of associated cost centers, billing, or project codes by the user before printing a document. Further, the user and cost management function may be used to create print rules or policies, and the print rules or policies may help ensure more stringent cost management by allowing different user roles to access different devices and features. For example, the user and cost management function may control duplex printing and / or color printing for individuals and / or groups, for example. Further, cost accounting and budget management may provide cost control and flexibility, and the cost control and flexibility may be used as a print management solution that allows an administrator to allocate a printing budget to users, along with options for replenishing the users' accounts. For example, in an environment such as a university, this may enable an administrator to give students a free printing allowance that they can add to as needed.Furthermore, print queue management can be used for the management of individual products in addition to, for example, an office print queue within an office.

[0031] According to one embodiment, an OpenID-based ecosystem 200 can include one or more protected resources 110, one or more resource application programming interfaces (APIs) 111, 112, 113, an OpenID relying party (RP) 114, an OpenID provider (or OpenID identity provider) having role-based access control (RBAC) 216, an OpenID offloading proxy 210, and one or more OpenID-incompatible client applications 220, 222, which can be connected through one or more communication networks 230. The communication network 230 can include, for example, a wired or wireless legacy network and can have any number of configurations such as a star configuration, token ring configuration, or other known configurations. The communication network 230 can include one or more local area networks (“LANs”), wide area networks (“WANs”) (e.g., the Internet), virtual private networks (“VPNs”), peer-to-peer networks, short-range field networks (e.g., Bluetooth (R)), cellular networks (e.g., 3G, 4G, 5G, other generations), and / or any other interconnected data path through which multiple computing nodes can communicate.

[0032] According to one embodiment, user 130 may present authenticator 240 to one or more OpenID-incompatible applications 220, 222 for authentication. The authenticator 240 may be, for example, a biometric identifier, which is a unique measurable characteristic used to label, describe, or identify an individual that includes a metric related to a human characteristic. For example, the biometric identifier may include, without limitation, physiological characteristics of an individual such as fingerprints, palm veins, face recognition, DNA (i.e., deoxyribonucleic acid), palm prints, palm shapes, iris recognition, retina, and / or odor / aroma.

[0033] FIG. 3 is a diagram of an OpenID offloading proxy 210 according to an exemplary embodiment. As shown in FIG. 3, the OpenID offloading proxy 210 communicates with an OpenID-protected resource 310, and the OpenID-protected resource 310 may include services and applications accessible through one or more resource application programming interfaces (APIs) 111, 112, 113 and an OpenID-incompatible application 320. The OpenID-incompatible application 320 may include one or more OpenID-incompatible client applications 220, 222 as shown in FIG. 2. According to one embodiment, the OpenID-incompatible application 320 does not include code to perform network operations necessary to satisfy the OpenID protocol. The OpenID offloading proxy 210 may include an application lifecycle manager 330, an OpenID token database (DB) 332, an HTTPS server and client 334, a certificate issuance service 336, and an application authentication certificate database (DB) 338.

[0034] According to one embodiment, the application lifecycle manager 330 can communicate with the HTTPS server and client 334 to, for example, assist in installing an application on an edge computing system, supply and / or specify resources of the edge computing system, and manage (e.g., start, stop, reset) the lifecycle of a virtual machine.

[0035] The OpenID token database 332 is preferably a database for storing and managing tokens received from the OpenID provider 116 with RBAC as disclosed herein. The HTTPS server and client 334 can communicate with the OpenID-incompatible application 320 through, for example, an HTTPS connection and communicate with the OpenID-protected resource 310 through an OpenID connection. The certificate issuance service 336 is configured to manage the issuance of certificates according to the OpenID protocol for one or more resource application programming interfaces (APIs) 111, 112, 113 and the OpenID-incompatible application 320 which may include one or more OpenID-incompatible client applications 220, 222 as disclosed herein. Further, the OpenID offloading proxy 210 may include, for example, an application authentication certificate database 338 configured to authenticate certificates issued by an OpenID provider having RBAC 216.

[0036] According to one embodiment, the OpenID offloading proxy 210 can be configured to support one or more flow variants supported by OpenID, and thus the OpenID offloading proxy 210 can be fully compliant with the OpenID standard. For example, the OpenID offloading proxy can be configured to support the authorization code flow, implicit flow, or hybrid flow.

[0037] Furthermore, the OpenID offloading proxy can be configured to support one or more operating modes, including a full proxy mode and an OpenID dedicated proxy mode. For example, in the full proxy mode, every packet from each application passes through the OpenID offloading proxy 210, not only for OpenID communication. Therefore, after an OpenID connection is established, the corresponding protected resources 110, including one or more application programming interfaces (APIs) 111, 112, 113 and accessible services and / or applications, also undergo proxy processing. For example, the OpenID offloading proxy 210 can mediate all communications from the protected resources 110, including services and / or applications, through one or more resource application programming interfaces (APIs) 111, 112, 113 to one or more OpenID-incompatible client applications 220, 222. In the full proxy mode, one or more OpenID-compatible client applications 122, 124 do not need to store, for example, the OpenID tokens issued by the OpenID provider 216. Therefore, one or more OpenID-incompatible client applications 220, 222 can access the protected resources 110 through one or more resource application programming interfaces (APIs) 111, 112, 113 in a relatively transparent manner, and the OpenID offloading proxy 210 can manage the burden imposed by mediating the communications.

[0038] Alternatively, in one embodiment, the OpenID offloading proxy 210 may include an OpenID-only proxy mode that only mediates while the OpenID offloading proxy 210 obtains an OpenID access token for the requesting OpenID-incompatible applications 220, 222. After the token is obtained by the OpenID offloading proxy 210, the OpenID offloading proxy 210 supplies the access token to the requesting OpenID-incompatible applications 220, 222, and the requesting OpenID-incompatible applications 220, 222 222 stores the access token so that it can be placed in the HTTP header during communication with one or more resource application programming interfaces (APIs) 111, 112, 113. In the OpenID-only proxy mode, the OpenID offloading proxy 210 does not maintain storage of the access token, so the OpenID token DB 332 is not used. Further, another trigger for processing by the OpenID offloading proxy 210 may be when the OpenID-incompatible applications 220, 222 request, for example, to refresh an expired access token.

[0039] According to one embodiment, the OpenID offloading proxy 210 complies with the OpenID standard in terms of the format of access tokens including, for example, JSON (JavaScript Object Notation) Web Tokens (JWTs), signed JWTs, and encrypted JWTs.

[0040] According to one embodiment, the OpenID offloading proxy 210 may also support application priorities for profiling purposes. For example, when the OpenID offloading proxy 210 supports multiple OpenID-incompatible applications 220, 222 developed by multiple vendors within the ecosystem 200, application priorities may be required. For example, the application lifecycle manager 330 can maintain the state of each of the multiple OpenID-incompatible applications 220, 222 by a finite state machine. When two or more OpenID-incompatible applications 220, 222 have the same name, profiling helps the OpenID offloading proxy 210 determine which of the two or more OpenID-incompatible applications 220, 222, and the corresponding resource application programming interfaces (APIs) 111, 112, 113, to call and accept.

[0041] Figure 4 is a flowchart of a method 400 for accessing a protected resource according to one embodiment. The method includes receiving, by a processor, a request from an OpenID-incompatible application for access to a protected resource (410), authenticating, by the processor, the OpenID-incompatible application (420), establishing, by the processor, an OpenID connection with an OpenID relying party upon authentication of the OpenID-incompatible application (430), and receiving, by the processor, an access token issued by an OpenID identity provider for the OpenID-incompatible application for access to the protected resource.

[0042] According to one embodiment, the method includes authenticating, by a processor, a user associated with an OpenID-incompatible application, and establishing, by the processor, an OpenID connection with an OpenID relying party upon authentication of the user associated with the OpenID-incompatible application. The method further includes assisting, by the processor, a user associated with an OpenID-incompatible application through an application OpenID lifecycle via an HTTPS handshake by an application programming interface (API) call.

[0043] According to one embodiment, the method , A The application OpenID lifecycle includes public key infrastructure (PKI) authentication.

[0044] According to one embodiment, the method further includes establishing, by the processor, an OpenID connection with an OpenID relying party upon authentication of an OpenID-incompatible application to initiate a flow towards an OpenID provider. According to one embodiment, the method includes terminating, by the processor, an incoming HTTPS connection from an OpenID-incompatible application in a request from the OpenID-incompatible application for access to a protected resource, and mapping, by the processor, details of the incoming HTTPS connection from the OpenID-incompatible application to a new connection with the OpenID relying party for accessing the protected resource for the OpenID-incompatible application. Further, the method may include mediating, by the processor, communication for the OpenID-incompatible application for access to the protected resource. The method may also further include mediating, by the processor, only an access token for the OpenID-incompatible application for access to the protected resource.

[0045] According to one embodiment, the access token can be formatted as a JSON (JavaScript Object Notation) web token, a signed JSON web token, or an encrypted JSON web token.

[0046] According to one embodiment, the method further includes maintaining, by a processor, the states of a plurality of OpenID-incompatible applications by a finite state machine for profiling purposes.

[0047] According to one embodiment, an OpenID-incompatible application does not include the OpenID protocol for authentication of the OpenID-incompatible application. Further, the OpenID-incompatible application does not include the OpenID protocol for authentication of a user of the OpenID-incompatible application.

[0048] According to one embodiment, the method further includes authenticating, by a processor, a user associated with an OpenID-incompatible application by public key infrastructure (PKI)-based authentication.

[0049] According to one embodiment, the protected resource is a secure software application. The secure software application is a software application that requires authentication of a user or an end user to access the application through one or more resource application programming interfaces (APIs) 111, 112, 113. For example, the secure software application can be an application that manages a printing service associated with a multifunction peripheral or a multifunction printer (MFP), a financial management software application that processes and manages the income, expenses, and assets of an individual or a group, or a medical software application that manages medical records, appointments, billing, and other related medical operations within a clinic or a healthcare management system.

[0050] FIG. 5 shows a representative computer system 500 in which embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code executed on hardware. For example, one or more computer systems, servers, or client devices 115, 117, 121, 221, 223, 225 related to the methods and systems disclosed herein may be implemented, in whole or in part, by a computer system 500 using hardware, software executed on the hardware, firmware, a non-transitory computer-readable medium storing instructions, or a combination thereof, and may be implemented on one or more computer systems or other processing systems. Hardware, software executed on the hardware, or any combination thereof may implement the modules and components used to implement the methods and steps of the methods and systems presently described.

[0051] When programmable logic is used, such logic may be executed on a commercially available processing platform configured by executable software code to be a dedicated computer or a dedicated device (e.g., a programmable logic array, an application specific integrated circuit, etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be implemented in a variety of computer system configurations including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and pervasive or miniature computers that may be virtually incorporated within almost any device. For example, at least one processor device and memory may be used to implement the foregoing embodiments.

[0052] The processor units or devices discussed in this specification can be a single processor, multiple processors, or a combination thereof. A processor device can have one or more processor "cores". The terms "computer program medium", "non-transitory computer-readable medium", and "computer-usable medium" discussed in this specification are used to generally refer to tangible media such as removable storage unit 518, removable storage unit 522, and the hard disk installed in hard disk drive 512.

[0053] Various embodiments of the present disclosure are described from the perspective of this representative computer system 500. After reading this description, it will be apparent to those skilled in the art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations may be described as sequential processes, some of the operations may actually be implemented in parallel, simultaneously, and / or in a distributed environment, and the program code may be stored locally or remotely for access by a single processor or a multiprocessor machine. Further, in some embodiments, the order of operations can be reconfigured without departing from the spirit of the disclosed subject matter.

[0054] The processor device (or processor) 504 can be a processor device specifically configured to implement the functions discussed herein. The processor device 504 can be connected to a communication infrastructure 506 such as a bus, message queue, network, multi-core message passing scheme, etc. The network can be any network suitable for implementing the functions disclosed herein, and can include a local area network ("LAN"), wide area network ("WAN"), wireless network (e.g., "Wi-Fi"), mobile communication network, satellite network, Internet, optical fiber, coaxial cable, infrared, radio frequency ("RF"), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 500 can also include a main memory 508 (e.g., random access memory, read-only memory, etc.) and can also include a secondary memory 510. The secondary memory 510 can include a hard disk drive 512 and a removable storage drive 514 such as a floppy disk drive, magnetic tape drive, optical disk drive, flash memory, etc.

[0055] The removable storage drive 514 can read from and / or write to a removable storage unit 518 in a well-known manner. The removable storage unit 518 can include a removable storage medium that can be read from and written to by the removable storage drive 514. For example, if the removable storage drive 514 is a floppy disk drive or a universal serial bus port, the removable storage unit 518 can be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 518 can be a non-transitory computer-readable recording medium.

[0056] In some embodiments, the secondary memory 510 may include alternative means for enabling a computer program or other instructions to be loaded into the computer system 500, such as a removable storage unit 522 and an interface 520. Examples of such means include program cartridges and cartridge interfaces (such as those found in video game systems), removable memory chips (such as EEPROM, PROM, etc.) and associated sockets, and other removable storage units 522 and interfaces 520 that will be apparent to those skilled in the art.

[0057] Data stored within the computer system 500 (such as main memory 508 and / or secondary memory 510) may be stored on any suitable type of computer-readable medium, such as optical storage (such as compact discs, digital versatile discs, Blu-ray discs, etc.) or magnetic storage (such as hard disk drives). The data may be structured in any suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc. Suitable configurations and storage types will be apparent to those skilled in the art.

[0058] Computer system 500 may also include a communication interface 524. The communication interface 524 may be configured to enable transfer of software and data between the computer system 500 and external devices. Exemplary communication interfaces 524 may include modems, network interfaces (e.g., Ethernet cards), communication ports, PCMCIA slots and cards, and the like. The software and data transferred via the communication interface 524 may be in the form of signals, and as will be apparent to those skilled in the art, the signals may be electronic, electromagnetic, optical, or other signals. The signals may travel via a communication path 526, which may be configured to carry the signals and may be implemented using wires, cables, fiber optics, telephone lines, cellular phone links, radio frequency links, and the like.

[0059] The computer system 500 may further include a display interface 502. The display interface 502 may be configured to transfer data between the computer system 500 and an external display 530. Exemplary display interfaces 502 may include a High-Definition Multimedia Interface (HDMI), a Digital Visual Interface (DVI), a Video Graphics Array (VGA), and the like. The display 530 may be any type of display suitable for displaying data transmitted via the display interface 502 of the computer system 500, such as a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, and the like. Computer program media and computer-usable media may refer to memories such as main memory 508 and secondary memory 510, which may be memory semiconductors (such as DRAM). These computer program products may be means for providing software to the computer system 500. A computer program (e.g., computer control logic) may be stored in main memory 508 and / or secondary memory 510. The computer program may also be received via communication interface 524. When such a computer program is executed, the computer system 500 may be enabled to execute the current methods as described herein. In particular, when the computer program is executed, the processor device 504 may be enabled to execute the methods shown in FIGS. 1 to 4 described herein. Accordingly, such a computer program represents the control device of the computer system 500. If the present disclosure is implemented using software executed on hardware, the software is stored in a computer program product and loaded into the computer system 500 using a removable storage drive 514, an interface 520, and a hard disk drive 512, or a communication interface 524.

[0060] The processor device 504 may be composed of one or more modules or engines configured to execute the functions of the computer system 500. Each module or engine can be executed using hardware and, in some cases, can also utilize software that is executed on the hardware, such as corresponding to program code stored in the main memory 508 or the secondary memory 510. In such a case, the program code may be compiled by the processor device 504 (e.g., by a compilation module or engine) before being executed by the hardware of the computer system 500. For example, the program code can be source code written in a programming language that has been translated into a lower-level language such as assembly language or machine code so as to be executed by the processor device 504 and / or additional hardware components of the computer system 500. The compilation process can include lexical analysis, preprocessing, syntax analysis, semantic analysis, syntax-directed translation, code generation, code optimization, and the use of other techniques suitable for translating the program code into a low-level language suitable for controlling the computer system 500 to execute the functions disclosed herein. It will be apparent to those skilled in the relevant art that the computer system 500 becomes a computer system 500 that is specifically programmed to execute the functions described above.

[0061] According to an exemplary embodiment, a method and a process as disclosed may be implemented on a non-transitory computer-readable medium. The non-transitory computer-readable medium may be a magnetic recording medium, a magneto-optical recording medium, or any other recording medium to be developed in the future, all of which may be considered equally applicable to the present invention. Duplication of such media, including primary and secondary replicated products, is undoubtedly considered equivalent to the above media. Further, even if an embodiment of the present invention is a combination of software and hardware, it is not at all outside the concept of the present invention. The present disclosure may be implemented such that the software part of the present disclosure is written in advance on a recording medium and is to be read as needed during operation.

[0062] As used herein, an element or step described in the singular and preceded by the word "a" or "an" should be understood not to exclude a plurality of elements or steps unless explicitly stated otherwise. Further, what is referred to herein as an "exemplary embodiment" or "an embodiment" is not intended to be construed as excluding the existence of additional examples that also incorporate the described features.

[0063] The claims at the end of this document are not to be construed under 35 U.S.C. § 112(f) of the United States Patent Law, unless a conventional means-plus-function phrase, such as the phrase "means for" or "step for" is explicitly recited in the claim.

[0064] It will be apparent to those skilled in the art that various modifications and variations can be made to the configuration of the present invention without departing from the scope or spirit of the present invention. In view of the above, if the modifications and variations of the present invention are included within the scope of the appended "claims" and their equivalents, the present invention includes them.

Claims

1. A method for accessing a protected resource, comprising: receiving, by a processor, a request from an OpenID-incompatible application requesting access to the protected resource; authenticating, by the processor, the OpenID-incompatible application; establishing, by the processor, an OpenID connection with an OpenID relaying party upon authentication of the OpenID-incompatible application; receiving, by the processor, an access token issued by an OpenID identity provider for the OpenID-incompatible application for access to the protected resource The method includes.

2. authenticating, by the processor, a user associated with the OpenID-incompatible application; establishing, by the processor, the OpenID connection with the OpenID relaying party upon authentication of the user associated with the OpenID-incompatible application The method according to claim 1, further comprising:

3. assisting, by the processor, a user associated with the OpenID-incompatible application through an application OpenID lifecycle via an HTTPS handshake by an application programming interface (API) call The method according to claim 1 or 2, further comprising:

4. The method according to claim 3, wherein the application OpenID lifecycle includes public key infrastructure (PKI) authentication.

5. establishing, by the processor, the OpenID connection with the OpenID relaying party upon authentication of the OpenID-incompatible application to initiate a flow towards the OpenID identity provider The method according to claim 1 or 2, further comprising:

6. terminating, by the processor, an incoming HTTPS connection from the OpenID-incompatible application in a request from the OpenID-incompatible application requesting access to the protected resource mapping, by the processor, details of an incoming HTTPS connection from the OpenID non-compliant application to a new connection with the OpenID relaying party to access the protected resource for the OpenID non-compliant application The method according to claim 1 or 2, further comprising this.

7. mediating, by the processor, communication to the OpenID non-compliant application for access to the protected resource The method according to claim 6, further comprising this.

8. mediating, by the processor, only the access token to the OpenID non-compliant application for access to the protected resource The method according to claim 6, further comprising this.

9. The method according to claim 1 or 2, wherein the access token is formatted as a JSON (JavaScript Object Notation) web token, a signed JSON web token, or an encrypted JSON web token.

10. maintaining, by the processor, the states of a plurality of OpenID non-compliant applications by a finite state machine for profiling purposes The method according to claim 1 or 2, further comprising this.

11. The method according to claim 1 or 2, wherein the OpenID non-compliant application does not include an OpenID protocol for authentication of the OpenID non-compliant application.

12. The method according to claim 11, wherein the OpenID non-compliant application does not include the OpenID protocol for authentication of a user of the OpenID non-compliant application.

13. authenticating, by the processor, a user associated with the OpenID non-compliant application by public key infrastructure (PKI)-based authentication The method according to claim 1 or 2, further comprising this.

14. The method according to claim 1 or 2, wherein the protected resource is a secure software application.

15. A computer program for accessing a protected resource, A non-transitory computer-readable storage medium having program instructions to be executed therein, the program instructions being executable by a computer, the computer to receive a request from an OpenID-incompatible application seeking access to a protected resource; authenticate the OpenID-incompatible application; establish an OpenID connection with an OpenID relaying party upon authentication of the OpenID-incompatible application; receive an access token issued by an OpenID identity provider for the OpenID-incompatible application for access to the protected resource; A computer program that causes a computer to execute a process comprising the above. **Claim 16** Authenticate a user associated with the OpenID-incompatible application; Establish the OpenID connection with the OpenID relaying party upon authentication of the user associated with the OpenID-incompatible application The computer program according to claim 15, further comprising the above. **Claim 17** Assisting a user associated with the OpenID-incompatible application through an application OpenID lifecycle via an HTTPS handshake by an application programming interface (API) call The computer program according to claim 15 or 16, further comprising the above. **Claim 18** The computer program according to claim 17, wherein the application OpenID lifecycle includes public key infrastructure (PKI) authentication. **Claim 19** A computer system comprising a memory and a processor, the processor receives a request from an OpenID-incompatible application for access to a protected resource, authenticates the OpenID-incompatible application, establishes an OpenID connection with an OpenID relaying party upon authentication of the OpenID-incompatible application, receives an access token issued by an OpenID identity provider for the OpenID-incompatible application for access to the protected resource configured to be like this. A computer system. Claim 20 The processor authenticates a user associated with the OpenID-incompatible application, and establishes the OpenID connection with the OpenID relaying party at the time of authenticating the user associated with the OpenID-incompatible application The computer system according to claim 19, further configured as such.

Images