User Personification / Authorization in a Token-based Authentication System

Abstract

A method operable in a trusted service that enables access to an application executing in a computing device, comprising: - Establishing a trust relationship with an identity provider; - Requesting a token for a user or user group from the identity provider; - Receiving the token from the identity provider after the token has been generated by the identity provider without requiring any user credentials, whereby the token is specific to the user or restricted to the user group; - on behalf of the user, using the token and a user credential to establish the trusted service as an authenticated user for the application; and - upon setting up the trusted service as an authenticated user, accessing the application.

Description

Background of the inventionField of the invention

[0001] This disclosure generally relates to techniques for enabling non-interactive-based networking between applications that share a common token-based authentication system, without necessarily requiring a user to be present. Background of the invention

[0002] In a traditional client-server authentication model, a client uses its credentials to access resources provided by a server. With the increasing use of distributed web services and cloud computing, third-party applications often require access to these server-provided resources. OAuth is an open protocol (Intern Request for Comment (RFC) 5849) that allows users to share their private data with various websites along with their credentials, while the data is only exposed on the original website that withholds that data. In particular, the OAuth protocol allows users to share private resources stored on a website with other websites without exposing the user's credentials—for example, usernames and passwords—to websites other than those that possess the user's data.A website that uses OAuth as one of its authentication protocols increases user privacy and security. To achieve this functionality, OAuth adds a third function, a resource owner, to the traditional client-server authentication model. In the OAuth model, the client (who is not the resource owner but acts on their behalf) requests access to resources controlled by the resource owner but provided by the server. Furthermore, OAuth allows the server to verify not only the authentication of the resource owner but also the identity of the client making the request.

[0003] An emerging information technology (IT) delivery model is cloud computing, in which shared resources, software, and information from the internet are made available on-demand to computers and other devices. Cloud computing can significantly reduce IT costs and complexity while improving workload optimization and service delivery. Using this approach, an application instance can be provisioned and exposes internet-based resources accessible through a conventional web browser over HTTP. An example application might be one that provides a common set of messaging features, such as email, calendar management, contact data management, and instant messaging. A user would then access the service directly over the internet.With this service, an organization would place its email, calendar, and / or collaboration infrastructure in the cloud, and an end user would use a suitable client to retrieve his or her email or perform a calendar operation.

[0004] Although the solutions described above offer many advantages, it has not been possible to integrate locally non-interactive services with cloud-based authentication systems that require the end user's presence. For example, suppose a cloud customer locally handles a Customer Relationship Management (CRM) request and a first user within it requires an action (e.g., identifying a new sales opportunity); this action would normally be expected to generate the desired result in the cloud service, triggering a new "to do" activity that creates a service for a second user—but only if the second user's credentials are valid when requested.If the cloud service uses a schema that requires a request to present the user's credentials (or, as in OAuth, an authorized token is required upon request), this task cannot be performed automatically. While it is possible to achieve this requirement by storing all user credentials for the cloud service, this is insecure and undesirable.

[0005] Thus, a need remains to provide a technique in which a trusted service retrieves a provisioned service on behalf of a user in that user's absence. This disclosure addresses this need.

[0006] US 2005 / 0 044 377 A1 describes a method for authenticating a user's access to network stations. Users of the authentication system do not need to enter passwords to access the network stations for online transactions, as the authentication task is handled by the authentication server and the Net Entry device via a host computer. A token is dynamically generated and sent to the application server to which the user wishes to access, and the verification process is then activated between the authentication server and the application server, which then retrieves a symmetric copy of the token to compare it with the token passed by the application server. If both tokens match, the user ID has passed the security check.Users no longer need to remember different user IDs and passwords to operate many network accounts, and there is no risk of losing network account numbers and passwords. Short summary

[0007] A trusted service establishes a trust relationship with an identity provider and interacts with the identity provider through a trusted connection. Because the trusted service is trusted, it can acquire a token from the identity provider for a specific user (or number of users) without requiring the user's credentials to be presented. The trusted service then uses this token (e.g., directly, by calling an API, by obtaining another token, or the like) to access and procure a provided service (e.g., a cloud-based service) on behalf of the user—even in the user's absence.This approach enables non-interactive (e.g., background services) services to perform workflows within a provided session (e.g., via OAuth-based APIs) without presenting the user's credentials or without the user being present.

[0008] A method for user impersonation by a trusted service begins with establishing a trust relationship between the service and the identity provider, where the service becomes a "trusted service." The trusted service then requests a token from the identity provider. The token is then obtained from the identity provider. In one embodiment, the trusted service, acting on behalf of the user, requests a session from an application (for example, a cloud service) by executing a request that includes the token. In an alternative embodiment, the trusted service directly calls an API to reach the service, or it could use a token to obtain another token to do so.After successful authentication (e.g., by an associated service provider), the trusted service receives authorized session information (e.g., a second token) indicating that the trusted service is an authenticated user. The trusted service then performs one or more actions in the session as the authenticated user.

[0009] In one aspect, the invention relates to a method operable in a trusted service enabling access to an application executing in a computing device, comprising: establishing a trust relationship with an identity provider; requesting a token from the identity provider; receiving the token from the identity provider after the token has been generated by the identity provider without requiring user credentials; on behalf of a user, using the token and credentials to create a trusted service for an authenticated user for an application; and upon establishing a trusted service as an authenticated user, accessing an application.

[0010] According to one embodiment of the invention, the token is used to establish the trusted services for an authenticated user by forwarding the token to a service provider associated with the identity provider and, upon validation, receiving an authentication session token, wherein the authentication session token indicates that the trusted service is an authenticated user for a session.

[0011] According to a further embodiment, the token represents a specific token for an authorized user.

[0012] According to another embodiment, the validation identifies the username associated with the specific token and verifies that the username matches the user's credentials.

[0013] According to a further embodiment, the validation is performed at least partially by the identity provider.

[0014] According to one embodiment, the computing unit is a shared pool of configurable computing resources.

[0015] According to another embodiment, the trusted service relies on the application or use of an OAuth-based Application Programming Interface (API).

[0016] In an alternative embodiment, the method described above is performed in a device comprising a processor and a computer memory containing computer program instructions which, when applied by the processor, carry out the method.

[0017] In another aspect, the invention relates to a device comprising: a processor, a computer memory containing computer program instructions that, when executed by the processor, enable a method that performs access to an application in a computing device, the method comprising: establishing a trust relationship with the identity provider; requesting a token from the identity provider; receiving the token from the identity provider after the token has been generated by the identity provider without requiring user credentials; on behalf of a user, using the token and credentials to obtain an authenticated user identity that the user can use to impersonate the application; and upon receiving the authenticated user identity, accessing the application.

[0018] According to one embodiment of the invention, the token is used by forwarding the token to a service provider associated with the identity provider and obtaining an authenticated user identity upon validation.

[0019] According to one embodiment of the invention, the token represents a specific token for an authorized user.

[0020] According to another embodiment, the validation identifies the username associated with the specific token and verifies that the username matches the user's credentials.

[0021] In another alternative embodiment, the method described above is performed by a computer program product on a computer-readable medium for use in a data processing system. The computer program product contains the computer program instructions which, when executed by the data processing system, perform the method.

[0022] In a further aspect, the invention relates to a computer program product on a computer-readable medium for use in a data processing system, the computer program product containing the program instructions which, when executed by the data processing system, performs a method for enabling access to an application executing in a computing device, the method comprising: establishing a trust relationship with the identity provider; requesting a token from the identity provider; receiving the token from the identity provider after the token has been generated by the identity provider without requiring user credentials; on behalf of a user, using the token and the credentials to obtain an authenticated user identity with which the user can impersonate the application;and upon receipt of the authenticated user identity, access to the application.;

[0023] According to one embodiment of the invention, the token is used by forwarding the token to a service provider associated with the identity provider and obtaining an authenticated user identity upon validation.

[0024] In a further aspect of the invention, the token represents a specific token for an authorized user.

[0025] According to another embodiment, the validation identifies the username associated with the specific token and verifies that the username matches the user's credentials.

[0026] In another aspect, the invention relates to an identity provider device comprising: a processor, computer memory containing computer program instructions that, when executed by the processor, enable a method comprising: establishing a trust relationship with a trusted service over a trusted connection; receiving a request from the trusted service for a token; generating the token without requiring user credentials; and returning the token to the trusted service to enable the trusted service to identify the user using the token and the user credentials to achieve an authenticated user identity.

[0027] According to one embodiment of the invention, the method further includes obtaining a token at a later time and performing validation.

[0028] According to another embodiment, the token represents a specific token for an authorized user, and the validation identifies the username associated with the specific token and verifies that the username matches the user's credentials.

[0029] The foregoing has outlined some of the pertinent characteristics of the invention. These features should be construed as illustrative only. Many other advantageous results may be obtained by practicing the disclosed invention in a different manner or by modifying the invention as described below. Short description of the drawings

[0030] For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: Fig. 1 illustrates an exemplary block diagram of a distributed computing environment in which exemplary aspects of the illustrated embodiments may be incorporated; Fig. 2 is an exemplary block diagram of a data processing system in which exemplary aspects of the illustrated embodiment may be incorporated; Fig. 3 shows abstraction model layers of a cloud computing environment (a service provider); Fig. Figure 4 shows a first embodiment according to claim 1 of this disclosure, in which a trusted service acquires a token from an identity provider for a specific group of users, which token is then useful for allowing the trusted service to access the service provider on behalf of an authorized user, even in the absence of the user; and Fig. Figure 5 illustrates a second embodiment according to claim 1 of this disclosure, in which a trusted service acquires a token from an identity provider for a specific user, which token is then useful for allowing the trusted service to access the service provider on behalf of an authorized user, even in the absence of the user. Detailed description of an embodiment

[0031] With reference to the drawings and in particular with reference to Fig. 1 - 2, exemplary diagrams of data processing environments are now provided in which the embodiments of the disclosure may be incorporated. It should be appreciated that the Fig. 1-2 are merely exemplary and are not intended to state or imply any limitations on the environments in which aspects or embodiments of the disclosed subject matter may be incorporated. Many modifications to the illustrated environments may be made without departing from the spirit and scope of the present invention. Client-server network model

[0032] Referring to the drawings, Fig. 1 is a pictorial representation of an exemplary distributed data processing system in which aspects of the illustrated embodiment may be incorporated. The distributed data processing system 100 may include a network of computers in which aspects of the illustrated embodiments may be incorporated. The distributed data processing system 100 includes at least one network 102, which is the medium used to provide communication between various devices and computers linked together in the distributed data processing system 100. The network 102 may include connections such as cables, wireless communication ports, or fiber optic cables.

[0033] In the illustrated example, servers 104 and server 106 are connected to network 102 along with storage unit 108. Furthermore, clients 110, 112, and 114 are also connected to network 102. These clients may be, for example, personal computers, network computers, or the like. In the illustrated example, server 104 delivers data such as boot files, operating system images, and applications to clients 110, 112, and 114. Clients 110, 112, and 114 are clients of server 104 in the illustrated example. Distributed data processing system 100 may include additional servers, clients, and other devices not shown.

[0034] In the illustrated example, the distributed data processing system 100 is the Internet with the network 102, which represents a worldwide collection of networks and interfaces that use the Transmission Control Protocol / Internet Protocol (TCP / IP) suite of protocols to communicate with each other. The heart of the Internet is a data transmission line of high-speed data communication lines between major nodes or host computers, which consist of thousands of commercial, government, educational, and other computer systems that send data and messages. Of course, a number of different network types, for example, an intranet, a local area network (LAN), a wide area network (WAN), or the like, may also be incorporated into the distributed data processing system 100. As mentioned above, Fig. 1 is intended as an example and not as an architectural limitation for various embodiments of the disclosed subject matter, and therefore the individual elements shown in Fig. 1 should not be construed as limiting the environments in which the embodiments of the present invention may be incorporated.

[0035] Reference may be made to Fig. 2, which shows a block diagram of an exemplary data processing system in which aspects of the embodiments may be incorporated. The data processing system 200 is an example of a computer, such as client 110 in Fig. 1 incorporating computer usable codes or instructions that may be found in processes of the illustrated embodiments of this disclosure.

[0036] Reference may be made to Fig. 2, which shows a block diagram of a data processing system into which embodiments can be incorporated. The data processing system 200 is an example of a computer, such as the server 104 or the client 110 in Fig. 1, computer-usable program code or instructions found in processes of the embodiments may be incorporated into the system. In these illustrated examples, data processing system 200 includes communication fibers 202 that establish communication between processor unit 204, memory 206, persistent storage 208, communication unit 210, input / output (I / O) unit 212, and display 214.

[0037] Processor unit 204 is configured to execute instructions for software that can be loaded into memory 206. Processor unit 204 may be a set of one or more processors or a multiprocessor core, depending on the particular implementation. Furthermore, processor unit 204 may be implemented using one or more heterogeneous processor systems, including a main processor and secondary processors, on a single chip. In another illustrative example, processor unit 204 may be a symmetric multiprocessor system with multiple processors of the same type.

[0038] Memory 206 and persistent storage 208 are examples of storage devices. A storage device is a piece of hardware suitable for storing information either temporarily and / or permanently. Memory 206, in these examples, may be, for example, random access memory or other suitable non-persistent or persistent storage device. Persistent storage 208 may take various forms depending on the particular implementation. For example, persistent storage 208 may include one or more components or devices. For example, persistent storage 208 may be a hard disk, flash memory, a rewritable optical disk, a rewritable magnetic tape, or a combination of the foregoing. The media used by persistent storage 208 may also be removable.For example, a removable hard disk can be used as permanent storage 208.

[0039] The communication unit 210, in these examples, provides communication with other data processing systems or devices. In these examples, the communication unit 210 is a network card. The communication unit 210 may provide communication using either one or both physical and wireless communication links.

[0040] Input / output unit 212 enables the input and output of data from other devices that can be connected to data processing system 200. For example, input / output unit 212 can provide a connection for user input via a keyboard and mouse. Furthermore, input / output unit 212 can send results to a printer. Display screen 214 provides a mechanism for displaying information and user input.

[0041] Instructions for the operating system and the applications or programs are located on persistent storage 208. These instructions can be loaded into memory 206 to be executed by processing unit 204. The processes of the various embodiments can be performed by a processing unit 204 utilizing computer-implemented applications located in memory, such as 206. These instructions refer to program code, computer-usable program code, or computer-readable program code that can be read and executed by a processor in processing unit 204. The program code in the various embodiments can be embodied in various physical or tangible computer-readable media, such as memory 206 or persistent storage 208.

[0042] The program code 216 is located in a functional form on a selectively removable computer-readable medium 218 and can be loaded or transferred to a data processing system 200 for execution by the processor 204. In these examples, the program code 216 and the computer-readable media 218 constitute the computer program product 220. In one example, the computer-readable medium 218 can have a tangible form, such as an optical or magnetic disk, that is inserted or placed into a drive or other device that is part of the persistent storage 208 for transfer to a storage medium, such as a hard disk, that is part of the persistent storage 208.In a specific form, the computer-readable media 218 may also be in the form of a permanent storage device, such as a hard drive, thumb drive, or flash memory, connected to the data processing system 200. The specific form of the computer-readable media 218 is also referred to as a computer-writable storage medium. In some cases, the computer-readable medium 218 may be non-removable.

[0043] Alternatively, the program code 216 may be transmitted to the data processing system 200 from a computer-readable medium 218 via a communication link to the communication unit 210 and / or through a connection to the input / output unit 212. In the examples discussed, the communication link and / or the connection may be tangible or wireless. The computer-readable media may also be in the form of intangible media, such as communication links or radio transmissions, containing the program code. The various components illustrated for the data processing system 200 are not intended to represent architectural limitations of the method in which various embodiments may be incorporated. The various embodiments may be implemented in a data processing system that includes components in addition to or in place of the data processing system 200 depicted herein.Other components used in . Fig. 2 may differ from the illustrated examples. One example is that a storage device in data processing system 200 is a hardware device capable of storing data. Memory 206, persistent storage 208, and computer-readable media 218 are examples of storage devices in tangible form.

[0044] In another example, a bus system may be used to implement the communication fibers 202 and may consist of one or more buses, such as a system bus or an input / output bus. Of course, the bus system may be implemented using any suitable design that provides for the transfer of data between various components or devices attached to the bus system. Additionally, the communication unit may include one or more devices used to send or receive data, such as a modem or a network adapter. Further, memory, such as memory 206 or a cache, as found in an interface and memory controller network nodes, may possibly be included in the communication fibers 202.

[0045] Computer program code for performing operations of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Small Talk, C++, or the like, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet service provider).

[0046] The expert in the field will recognize that the hardware in the Fig. 1 - 2, depending on the implementation, varies. Other internal hardware or remote devices, such as flash memory, corresponding persistent storage or optical disk drives and the like, may be used in addition to or instead of the Fig. 1-2. Furthermore, the processes of the embodiments may be applied to a multiprocessor data processing system, except for the previously mentioned SMP system, without departing from the spirit and scope of the disclosed subject matter.

[0047] As will be seen, the techniques described herein can be used in conjunction with the standard client-server paradigm as described in Fig. 1, in which client computers communicate with an Internet web portal running on a set of one or more machines. End users operate Internet-enabled devices (e.g., desktop computers, notebooks, Internet-enabled mobile devices, or the like) capable of accessing and interacting with the portal. Typically, each client or server is a data processing system, as in Fig. 2, which comprises hardware or software, and these units communicate with each other over a network, such as the Internet, an intranet, an extranet, a private network, or other communications medium or link. A computing system typically includes one or more processors, an operating system, one or more applications, and one or more utilities. The applications on the computing system provide native support for web services, including, without limitation, support for HTTP, SOAP, XML, WSBL, UDDI, and WSSL, among others. Information concerning SOAP, WSBL, UDDI, and WSSL is available from the World Wide Web Consortium (WCCC), which is responsible for developing and maintaining these standards; further information concerning HTTP and XML is available from the Internet Engineering Task Force (IETF). Knowledge of these standards is assumed. Cloud computing model

[0048] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, bandwidth, servers, processing, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four usage models, which are specifically described and defined in the "Draft NIST Working Definition of Cloud Computing" by Peter Mell and Tim Grance, dated October 7, 2009.

[0049] In particular, the typical characteristics are the following: On Demand Self Service: A cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, automatically on demand without human interaction with the service provider.

[0050] Broad network access: Functions are available over a network and accessed via standard mechanisms that support the use of heterogeneous thin or thick client platforms (for example, mobile phones, laptops and PDAs).

[0051] Resource Pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-talent model, with diverse physical and virtual resources dynamically allocated and reassigned as needed. Location-independent provisioning is important in that the consumer generally does not have control over or knowledge of the exact location of the provided resources, but it is possible to specify the location at a higher level of abstraction (for example, country, state, or data center).

[0052] Rapid elasticity: Features can be deployed quickly and elastically, in some cases automatically, to ensure rapid scale-out and scale-in. For the consumer, the available procurement options often seem unlimited and can be purchased in any quantity at any time.

[0053] Measured service: Cloud systems automatically control and optimize resource usage by leveraging granularity at a specific level of abstraction appropriate to the nature of the service (e.g., storage, processing, bandwidth, and enabled user accounts). Resource usage can be monitored, controlled, and reported to ensure transparency for both providers and consumers of the service used. Service models are typically the following:

[0054] Software as a Service (SaaS): The capability provided to the consumer is the use of the provider's application running on a cloud infrastructure. The applications are accessible from various client devices via a thin-client interface, such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0055] Platform as a Service (PaaS): The capability provided to the consumer is the use of cloud infrastructure created by the consumer or applications acquired, supported by user programming languages ​​and tools. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, and storage, but has control over the deployed applications and possible application hosting environment configurations.

[0056] Infrastructure as a Service (IaaS): The capability provided to the consumer is the acquisition of processing, storage, networking, and other basic computing resources, enabling the consumer to deploy and operate any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls). Usage models are typically the following:

[0057] Private cloud: The cloud infrastructure is operated exclusively for an organization. It can be managed by the organization or a third party and can be located on-site or off-site.

[0058] Community cloud: The cloud infrastructure is shared by multiple organizations and supports a specific community that shares common concerns (e.g., mission, security requirements, policies, and compliance aspects). It can be managed by the organization or a third party and can be located on-site or off-site.

[0059] Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0060] Hybrid cloud: The cloud infrastructure consists of two or more clouds (private, shared, or public) that remain unique but are interconnected by standardized or proprietary technologies, enabling data and application portability (for example, cloud bursting for load balancing between clouds).

[0061] A cloud computing environment is service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. The heart of cloud computing is an infrastructure with a network of interconnected nodes. A representative cloud computing node is shown above. Fig. 2. Specifically, within a cloud computing node, there is a computer system / server that is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computer systems, environments, and / or configurations conceivable for use with the computer system / server include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above-mentioned systems or devices, or the like.The computer system / server can be described in the general context of computer systems as executable instructions, such as program modules, that are executed by a computer system. In general, program modules can include utilities, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. The computer system / server can be used in distributed cloud computing environments where tasks are executed by central processing devices connected via a communications network. In a distributed cloud computing environment, program modules can be located in both the local and decentralized computer system storage medium, including storage devices.

[0062] Referring to Fig. 3, which shows that, through additional background, a set of functional abstraction layers is provided by a cloud computing environment. It should be clarified beforehand that the components, layers, and functions used in Fig. 3 are for illustrative purposes only, and embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided: The hardware and software layers 300 include hardware and software components. Examples of hardware components include mainframes, in one example, IBM® Set Series® systems; RISC (Reduced Instruction Set Computer) architecture-based servers, in one example, IBM pSeries® systems; IBM xSeries® systems; IBM BladeCenter® systems; storage devices, networks, and network components. Examples of software components include network application server software, in one example, IBM WebSphere® application server software; and database software, in one example, IBM DB2® database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of the International Business Machines Cooperation, registered in many jurisdictions worldwide.)

[0063] The virtualization layer 302 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers, virtual storage, virtual networks, including virtual private networks, virtual applications and operating systems, and virtual clients.

[0064] In one example, the management layer 304 may provide the functions described below. Resource procurement provides dynamic arbitration of IT resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing offers resources within the cloud computing environment to payers for fee collection and billing for use of those resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. A user portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management so that required service levels are met.A Service Level Agreement (SLA) provides planning and fulfillment for the pre-arrangement and procurement of cloud computing resources for which a future requirement for an SLA is expected.

[0065] The workload layer 306 provides examples of functions for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation; software development and lifetime management; virtual classroom training; data analytics processing; transaction processing; and OAuth-based API integration (for the purposes described below).

[0066] It should be understood at the outset that, although this disclosure contains a detailed description of cloud computing, the implementation of the teachings presented herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being used in connection with any other type of computing environment now known or later developed.

[0067] Thus, a representative cloud computing environment has several high-level functional components, including a front-end identity manager, a Business Support Services (BSS) functional component, an Operational Support Services (OSS) functional component, and a cloud computing component. The identity manager is responsible for providing the coupling between the requesting client and the identity manager, and this component can be implemented using one or more well-known systems such as Tivoli Federated Identity Manager (TFIM), available from IBM Corporation of Armonk, New York. Under appropriate circumstances, TFIM can be used to provide Federated Single Sign-On (F-SSO) on other cloud components. The Business Support Services component provides certain administrative functions, such as billing.The operational support service component is used to handle the provisioning and management of other cloud components, such as virtual machine (VM) instances. The cloud component provides the core computing resources, which are typically multiple virtual machine instances used to run a target application made available for access via the cloud. One or more databases are used to store directory, log, and other working data. All of these components (including the front-end identity manager) are located "inside" the cloud, but this is not a requirement. In an alternative embodiment, the identity manager can operate outside the cloud. The service provider can also operate externally from the cloud.

[0068] A typical cloud-based client-server application is IBM® Lotus Life, which provides a cloud-delivered suite of technologies, such as web conferencing, messaging and collaboration services, combined with social networking capabilities, in an easy-to-use web-based environment.

[0069] Of course, references to Lotus Life are for illustrative purposes only and are not intended to limit the scope of this disclosure. Authentication mechanism

[0070] Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains—that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a development of the OASIS Security Services Technical Committee. SAML implements the concepts of an identity provider (source of assertions) and a service provider (consumer of assertions). Service providers (SPs) rely on identity providers (IdPs) to authenticate their clients. SAML assumes that the client (often a user) has enrolled with at least one identity provider. This identity provider assumes that the client provides local authentication services to the client.However, SAML does not specify the implementation of these local services; in fact, SAML does not care how local authentication services are implemented (although individual service providers do). Thus, the service provider relies on the identity provider to identify the principal. At the principal's request, the identity provider issues a SAML assertion to the service provider. Based on this assertion, the service provider makes an access control decision. To enable SAML, a trusted partnership must be established that involves IdPs and SPs exchanging metadata about each other's SAML implementation, including keys to encrypt / decrypt the SAML assertion.

[0071] OAuth (Open Authorization) is an open standard that allows users to share their private resources (e.g., photos, videos, contact lists) stored on a website with another site without disclosing their usernames and passwords. OAuth allows users to distribute tokens, rather than usernames and passwords, from their data provided by a specific service provider. A token grants an entity access to a specific location (e.g., a video editing site), to specific resources (e.g., only videos from a specific album), and for a specified period of time (e.g., for the next two hours). Thus, OAuth allows a user to grant a third party access to their information stored by another service provider without disclosing their access authorization or the full scope of their data.

[0072] OAuth requires the requester to have a token (which must be authorized by a user for a targeted service provider) to be included in a request. Granting this authorization often requires the user's presence to authenticate the target service provider.

[0073] OAuth is also useful in cloud environments. For example, Lotus Life secures its application programming interface (API) functions with OAuth. The personification / authorization (“delegation”) of a user in a cloud-supported token-based authentication system

[0074] With the above as background, this disclosure provides a technique by which a trusted service can "impersonate" a user to a cloud service and thus perform operations even in the absence of the user.

[0075] It is assumed that among the services provided by the cloud service, one of them is a "service provider" that consumes an authentication system, such as token-based authentication, by tracing back to an identity provider to validate it. A representative scheme, as described above, is SAML, although the techniques are not limited to service providers that use SAML-based authentication. Other token-based authentication schemes include, without limitation, OpenID. A SAML-based service provider, such as Operative within Lotus Life in the example described above, may implement OAuth-based API queries.

[0076] An identity provider (IdP) interacts with the service provider in a familiar way. Generally speaking, according to the OASIS standard definition, an identity provider is a type of service provider that maintains, creates, and manages identity information for clients and authenticates the client to other providers within a federation. Its primary function is client authentication. As mentioned above, the identity provider can pass a SAML assertion to the service provider upon request from a client. Based on this assertion, the service provider makes an access control decision.

[0077] Referring to Fig. Figure 4 illustrates a first embodiment of the inventive technique. In this embodiment, cloud service 400 represents one or more cloud-based applications accessible to a cloud consumer, typically an enterprise, and more specifically to a user or group of users associated with the enterprise. In this embodiment, service provider 402 requires a token-based authentication system. Identity provider 404, which may be a component of the cloud service or different therefrom, authenticates users and uses tokens to send them to service provider 402. Identity provider 404 may execute a server process, such as a SAML server, using a computing engine. Service provider 402 takes the token sent to it and sends it to the identity provider for validation.The identity provider 404 also serves to verify the validity of each token from each service provider with which it is connected. As mentioned above, SAML-based authentication can enable the establishment of a trusted partnership between the identity provider 404 and the service provider 402 and the exchange of metadata about each other's SAML implementation, including keys for encrypting / decrypting the SAML assertion. In the context of . Fig. 4, it is assumed that a trusted relationship has been established between the service provider 402 and the identity provider 404.

[0078] According to this disclosure, the "trusted service" 406 impersonates a user (or group of users) to the other entities (namely, the identity provider, the service provider, and the cloud service of interest). A "trusted service" is generally a computing entity (a computer-based system, a program, a process, a thread of execution, or the like) that has the ability to establish a trust relationship with the identity provider 404 and interacts with the identity provider via a trusted connection. When a "trusted service" is associated and connected to the identity provider in this manner, the identity provider will not necessarily verify the user's credentials, but will only create and return the requested token representing the user (or user groups).In particular, the identity provider verifies that the requested credentials from the trusted service fall within the identity provider's permitted domain (which may be known to a subset of a larger group of users of the identity provider). The "impersonation" (provided by the trusted service) is sometimes referred to here as "authorization" because, according to the technique, a user or group of users (or, more generally, an IdP administrator or other authorized entities, with or without the user's awareness) with valid authority grants the trusted service the ability to interact with other entities on behalf of the user or group of users.It is advantageous if the trusted service 406 obtains a token (or, more generally, a unique data string) from the identity provider 404 for a specific user (or group of users) without presenting the user's credentials. As will be seen, this enables the trusted service 406 to access the cloud service 400 on behalf of the user, even in the user's absence.

[0079] Fig. 4 shows the first embodiment according to this disclosure, by which the trusted service 406 acquires a token from the identity provider 404 for a certain number of users. This token is then useful for enabling the trusted service 406 to reliably access the service provider 402 on behalf of the user, even in the user's absence. The technique begins at step 408, in which the trusted service 406 establishes trust with the identity provider 404 using conventional techniques (e.g., via a pre-shared token or key, by making a request from a specific IP address, or the like). Step 408 may also involve the mutual exchange and authentication of SSL certificates, SSH key-based authentication, and the like.In this example, the trusted service 406 (or a component thereof) is linked to a local application, for example, a Customer Relationship Management (CRM) application. A trusted service, in this alternative, can be a stand-alone service, a cloud-based service, or the like. Generally, the service (that is, the "trusted service") is a process / service / application that has access to the data in order to be integrated. In step 410, the trusted service 406 connects to the identity provider 404 via a connection that is trusted by the IdP and the requested generic token. This connection can be a secure connection (for example, a secured connection via SSL, TLS, or the like), or even a non-secure connection (in any case, security by the IdP is still provided).A connection secured by the identity provider is sometimes referred to herein as a "trusted connection." Because the trusted service is trusted, as mentioned above, and is connected over a trusted connection, the identity provider is not required to verify the user's credentials before responding to the request for the generic token. While the identity provider is not required to verify such credentials, it can optionally verify whether the requesting user is authorized by the trusted service within the group of users to use the trusted service. In this particular embodiment, the token is referred to as "generic" because it is restricted to a specific group of users (for example, every person in the "Sales" group) or, alternatively, to "all" users.Any token that is unique to a specific user can be called "generic." The generic token can be based on one or more attributes, such as time, location, responsibility (task), or the like. Thus, a generic token might be requested for "Rochester Sales employees" or something similar.

[0080] Further details on how a generic token can be restricted are provided below. In one approach, a set of target users is identified. Multiple criteria can be used or evaluated for this purpose. For example, a set of target users can be an existing group of users in a user data store (for example, an LDAP group), a set of users with a specific attribute value (for example, user country = "OH" status = "Employee" status = "Sales"), these users are assigned a specific role in a source application, these users are assigned a specific role in the target application, etc. The target users can then be selected by defining one or more configurable rules or policies.For example, the rule / policy at the trusted connection level can be defined, for example, for a given secured connection, the generic token is always generated for a given number of target users. The rule / policy at the trusted connection level can be provided with further configuration options to define the trusted service, for example, for a specific trusted connection, which always configures tokens for a subset of a set of target users for a trusted service. A rule / policy could also be defined by trusted connection attributes, for example, a connection over a secure link sets a generic token for a first set of defined target users, over a non-secure connection sets a generic token for a second set of defined target users, etc.A rule / policy can be defined to have global effect, for example, by requiring one or all trusted connections to use an identified number of target users, etc. Furthermore, user participation in the configuration of a given rule / policy can be enforced / allowed by an administrator assigned to the trusted service. The trusted service can also enforce an explicit opt-in to the user policy, an explicit opt-out to the user policy, or similar. The above is merely exemplary.

[0081] Returning to Fig. 4, in step 412, the identity provider 404 constructs the requested generic token, and in step 414, returns the numeric token to the trusted service 406. This token generation process can occur offline, or at a time when desired to initiate a "session" (or transaction) with the cloud service (in this example scenario). In other words, token generation can occur asynchronously or synchronously. In either case, and since the application is from the trusted service or over a trusted connection, the SAML server will not verify user credentials (although, as mentioned above, the server may verify that the group falls within the permitted domain to use the trusted service), but rather, the SAML server creates the token describing a group of users and returns it.

[0082] At step 416, the trusted service requests a new session, for example, by adding the generic token to an OAuth API request as an authentication method, and makes a call to the cloud service. In one embodiment where Lotus Life is the cloud service, the requested session is authenticated with the generic token via SAML at step 416 and receives an OAuth token (authenticated by Lotus Life for specific users), which is then applied to API calls. At step 416, the request also includes the username (or other user identifiers) for the user to be personified by the trusted service. This request is sent from the trusted service 406 to the service provider 402, which validates the request before allowing the session to be initiated. At step 418, the service provider 402 extracts the token and username from the request.In step 420, the service provider 402 sends the token and username to the identity provider 404 for validation. In step 422, the identity provider 404 checks this to determine that the presented user is in the set of users to which the token is restricted (i.e., that the user is within the scope of the generic token). If the result of the check is positive (i.e., if the username is in the generic token authentication domain), the identity provider 404 returns a response to the service provider 402 that {token + username} are valid. This is step 424. After that, the service provider interacts with the "requester" (the trusted service) in the usual way.Specifically, in step 426, the service provider 402 returns session ID information (e.g., another token, the generic token itself, or similar data) indicating that a session (with the cloud service in this example) is valid. Continuing with the above example (an OAuth API request), the trusted service 406 then requests a service (e.g., makes an API request) as an authenticated user, namely if the user was authenticated in step 424. This is step 428. The API request is then executed by the cloud service 400, as shown in step 430, to complete the process.

[0083] Fig. Figure 5 shows an alternative embodiment according to this disclosure, by which the trusted service obtains a token from an identity provider for a specific user. This token is then useful for enabling the trusted service to access a service provider on behalf of that user, even in the user's absence. The operations are similar to those described above with respect to the Fig. 4.

[0084] The technique begins at step 508, where service 508 establishes trust with identity provider 504 and becomes a trusted service, as previously described. At step 510, trusted service 506 connects to identity provider 504 over a trusted connection and, in this embodiment, requests a token for a specific user. As described above, because the trusted service is trusted and connected over a trusted connection, the identity provider does not need to verify the user's credentials before responding to the request for a specific token (although, optionally, it may verify that the user is within the group of permitted users using the trusted service).In step 512, the identity provider 504 builds the requested specific token (without the need to verify the user's credentials), and in step 514, the token is returned to the trusted service 506. As with the first embodiment, token generation can be asynchronous or synchronous.

[0085] In step 516, the trusted service requests a new session, for example, by adding the user-specific token to an OAuth API request as an authentication method, by authenticating via SAML to acquire an OAuth token, or the like, and then invoking the cloud service. A username is also sent with this request, as in the previous embodiment. This request is sent from the trusted service 506 to the service provider 502, which, as mentioned above, must validate the request before allowing the session to be initiated. In step 518, the service provider 502 extracts the token from the request. In step 520, the service provider 502 sends the token plus username to the identity provider 504 for "validation." In step 522, the identity provider 504 checks this to ensure that the username matches what was issued by the token.The identity provider 504 then returns an affirmative response to the service provider 502, which includes the username associated with the user. This is step 524. In step 526, the service provider 502 checks for a positive response (if the response is negative, the procedure may be terminated, the user is given an opportunity to resolve the issue, or the like). The service provider 502 then returns the session ID information (e.g., another token, the user-specific token, or similar data) indicating that a session with the cloud service is permitted in this example. This is step 528. Continuing with the above example (an OAuth API request), the trusted service 506 then requests a service (e.g., makes an API request) as the authenticated user. This is step 530. The API request is then processed by the cloud service 500, as shown in step 532, to complete the process.

[0086] The “request” made by the trusted service (506, in Fig. 4 or Fig. 506 in Fig. 5) can be of any type. As mentioned in the examples above, a preferred type of request is an OAuth-based request, and in particular, an OAuth-based API request. Thus, in this way, any service that uses OAuth-based APIs can gain access and procure services on behalf of the absent users. More generally, those skilled in the art will recognize that the technique is advantageous for enabling the integration of any non-interactive service (e.g., any background service) with an authentication system (including, without limitation, any token-based authentication mechanism) that expects (or requires) the user's presence.

[0087] The service provider-identity provider interactions described above are merely exemplary and are not intended to limit the scope of the disclosed technique, as any suitable token interaction is contemplated.

[0088] Preferably, the described technique is implemented by providing an identity provider that has been modified to interact with a trusted service in the described manner. The scheme does not require any modification of the service provider.

[0089] The techniques described here offer significant advantages. This disclosure describes an advantageous method for a trusted service to acquire a token from an identity provider for a specific user or group of users without requiring the user's credentials to be presented. This then allows the trusted service to access a cloud service on behalf of the user, even in the user's absence. Preferably, the method is implemented in conjunction with an identity provider that is under the control of a user, an administrator, or an entity associated with the user, and the approach does not require any changes to the service provider. The solution enables non-interactive services to interface with authentication and authorization systems that expect the user's presence.As described, the approach allows such a service to perform business (for example, synchronization of data outside business hours) and in the background when the user is not available.

[0090] Further advantages are that in order to be personalized, the user does not need to submit their credentials (to the service provider), they do not need to be present for the transaction, they do not need to approve the transaction, and / or they do not even need to be aware of the transaction.

[0091] As used herein, and in a preferred embodiment, the “generic” token ( Fig. 4) or the “user-specific” token ( Fig. 5) contain a component of a SAML assertion.

[0092] In a representative, but not limiting, implementation, a representative cloud service is Lotus Life, and the identity provider (IdP) is implemented in Tivoli Federated Identity Manager (TFIM). These products and services are available from IBM Corporation of Armonk, New York.

[0093] The functionality described above may be implemented as a standalone application, for example, a software-based function executed by a processor, or it may be available as a managed service (including as a web service via a SOAP / XML interface). The specific hardware and software implementations of the details described herein are for illustrative purposes only and are not intended to limit the scope of the described subject matter.

[0094] The techniques described here are not limited to use with a cloud service. The technique described above can also be implemented to enable user identification from a trusted service to other services, such as a web application, an operating system application programming interface (API) call, or the like.

[0095] In general, computing devices within the scope of the described invention are each a data processing system (as in Fig.2), consisting of hardware and software, and these units communicate with each other over a network, such as the Internet, an intranet, an extranet, a private network, or other communication medium or link. The applications from the data processing system provide native support for web and other well-known services and protocols, including, without limitation, support for HTTP, FTP, SMTP, SOAP, XML, WSBL, SAML, WS-Trust, UDDI, and WSFL, among others. Information concerning SOAP, WSBL, UDDI, and WSFL is available from the World Wide Consortium (W3C), which is responsible for developing and maintaining these standards; further information concerning HTTP, FTP, SMTP, and XML is available from the Internet Engineering Task Force (IETF). Knowledge of these standards and technologies is assumed.

[0096] The scheme described here can be implemented in conjunction with various server-side architectures other than cloud-based infrastructures. This includes, without limitation, simple N-tier architectures, web portals, federated systems, or the like.

[0097] More generally, the subject matter described herein may be in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that includes both hardware and software elements. In a preferred embodiment, and as noted above, the identity provider and the described "impersonation" function are embodied in software, including, but not limited to, firmware, resident software, microcode, and the like. The "token" may be any generic data source or structure that can be transported over a link and / or stored in a data store, such as computer memory.

[0098] Furthermore, the impersonation / authorization functionality described herein may take the form of a computer program product accessible from a computer-usable or computer-readable medium and providing program code for use in connection with a computer or other instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium may be a device containing or storing a program for use by or in connection with the instruction execution system, device, or apparatus. The medium may be electronic, magnetic, optical, electromagnetic, infrared, or a semiconductor system (or device or apparatus).Examples of computer-readable media include semiconductors or semiconductor memory, magnetic tape, a removable computer diskette, random-access memory (RAM), read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disc read-only memory (CD-ROM), compact disc read-only memory (CD-R / W), and DVD. A computer-readable medium is a tangible item.

[0099] The computer program product may be a product with program instructions (or program code) to perform one or more of the described functions. These instructions or code may be stored in a computer-readable storage medium in a data processing system after being downloaded over a network from a remote data processing system. Without these instructions or code, the computer-readable storage medium may be stored in a server data processing system and are adapted to be loaded over a network from a remote data processing system for use in a computer-readable storage medium in the remote system. In a representative embodiment, the components of the identity provider are implemented in a dedicated computer, preferably in software executing with one or more processors.The software is also supported by one or more data stores or memories associated with one or more processors, and the software may be implemented as one or more computer programs.

[0100] The user impersonation / authorization function can be implemented as a supplement or extension to an existing security (authentication) service or access management solution. The technique can also be implemented in an automated manner, as described above.

[0101] Although the above description sets forth a particular order of operations of certain embodiments of the invention, it should be understood that this order is exemplary; as alternative embodiments, the operations may be performed in a different order, certain operations may be combined, certain operations may overlap, or the like. References in the specification to a particular embodiment indicate that the described embodiment includes a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic.

[0102] Finally, although certain components of the system have been described separately, one skilled in the art would recognize that some of the functions may be combined or shared in instructions, program flows, sections of code, or the like.

[0103] As used herein, the term "client-side" should be broadly interpreted to refer to an application, a page of this application, or any other resource or functionality requested by a client-side application to the application. A "browser," as used herein, should not refer to a specific browser (e.g., Internet Explorer, Safari, Firefox, or the like), but should be broadly interpreted to refer to any client-side rendering engine that provides access to and display of Internet-accessible resources. A "rich" client typically refers to a non-HTTP-based client-side application. Further, while client-server interactions typically occur over HTTP, this is not a limitation.The client-server interaction may be formatted to use Simple Object Access Protocol (SOAP) and travel over HTTP (over the public Internet), FTP, REST, or other reliable transport mechanisms (such as IBM® MQ Series® technologies and CORBA, for transfer over a corporate intranet). Any application or functionality described herein may be implemented as native code, by creating data in another application, by enabling the use of that mechanism as a plug-in, by linking to the mechanism, and the like.

[0104] After describing our invention, what we claim is the following:

Claims

[1] A method operable in a trusted service that enables access to an application running on a computing device, comprising: - Establishing a trust relationship with an identity provider; - Requesting a token for a user or user group from the identity provider; - Receiving the token from the identity provider after the token has been generated by the identity provider without requiring any user credentials, whereby the token is specific to the user or restricted to the user group; - on behalf of the user, using the token and a user credential to establish the trusted service as an authenticated user for the application; and - upon setting up the trusted service as an authenticated user, accessing the application. [2] The method of claim 1, wherein the token is used to establish the trusted service as an authenticated user by forwarding the token to a service provider associated with the identity provider and, upon validation, obtaining an authentication session token, the authentication session token indicating that the trusted service is an authenticated user for a session. [3] The method of claim 2, wherein the token represents a generic token for a group of authorized users. [4] The method of claim 3, wherein the validation checks to determine whether the user credential is associated with the generic token. [5] Device which includes: - a processor, - Computer memory containing computer program instructions which, when executed by the processor, perform a method enabling access to an application executing in a computing unit, the method comprising: ◯ Establishing a trust relationship with an identity provider; ◯ Requesting a token for a user or user group from the identity provider; ◯ Receiving the token from the identity provider after the token has been generated by the identity provider without requiring user credentials, whereby the token is specific to the user or restricted to the user group; ◯ on behalf of the user, using the token and a user credential to obtain an authenticated user identity with which the user can impersonate the application; and ◯ upon receipt of the authenticated user identity, access to the application. [6] The device of claim 5, wherein the token is used by forwarding the token to a service provider associated with the identity provider and obtaining the authenticated user identity upon validation. [7] The device of claim 6, wherein the token is a generic token for a group of authorized users. [8] The device of claim 7, wherein the validation checks to determine whether the user credential is associated with the generic token. [9] A computer program product on a computer-readable medium for use in a data processing system, the computer program product including computer program instructions which, when executed by the data processing system, perform a method for enabling access to an application executing in a computing device, the method comprising: - Establishing a trust relationship with an identity provider; - Requesting a token for a user or user group from the identity provider; - Receiving the token from the identity provider after the token has been generated by the identity provider without requiring any user credentials, whereby the token is specific to the user or restricted to the user group; - on behalf of the user, using the token and a user credential to obtain an authenticated user identity with which the user can impersonate the application; and - upon receipt of the authenticated user identity, access to the application. [10] The computer program product of claim 9, wherein the token is used by forwarding the token to a service provider associated with the identity provider and obtaining the authenticated user identity upon validation. [11] The computer program product of claim 10, wherein the token represents a generic token for a group of authorized users. [12] The computer program product of claim 11, wherein the validation checks to determine whether the user credential is associated with the generic token. [13] An identity provider device comprising: - a processor, - Computer memory containing computer program instructions which, when executed by the processor, perform a method according to any one of claims 1-4. [14] The identity provider device of claim 13, wherein the method further includes obtaining a token and performing validation at a later time. [15] The identity provider device of claim 14, wherein the token represents a generic token for a group of authorized users and checks the validation to determine whether the user credential is associated with the generic token.

Images