Secure single sign-on to software applications

After an initial user sign-on with an identity provider, and in response to an intention of the user to use a third-party application executing on a client device of the user and requiring user sign-on, the identity provider provides a client script to the third-party application. The client script facilitates user and application authentication and invokes a trusted broker application that interacts with the identity provider to enable the user to use the third-party application. The use of the trusted broker application provided by the identity provider frees the authors of third-party applications from the need to modify their applications to explicitly sign in with the identify provider. For enhanced security, conformance to an organizational security policy is verified at time of sign-on, and an authenticatable link is used to invoke the third-party application to foil attempts by malicious software to substitute another application.

FIELD OF ART

The present invention generally relates to the field of software applications, and more specifically, to securely facilitating sign-on to multiple applications.

BACKGROUND

Many organizations, such as businesses or other enterprises, provide their employees or other members with access to a variety of software applications, such as e-mail applications, chat applications, payroll applications, timekeeping applications, and the like. For security reasons, the organizations may impose sign-in as a prerequisite for use of the applications. Thus, a user could potentially have a different set of sign-in credentials (e.g., username and password) for every application to which he or she has access. The necessity of separately signing in to each application (i.e., providing the user's credentials for that application) imposes considerable burden on users, who must enter the credentials for every application used, and on the organization's information technology departments, which must respond to user inquiries about forgotten credentials.

DETAILED DESCRIPTION

FIG. 1illustrates a computing environment in which users of an organization sign into and use different software applications, according to one embodiment. An organization100has a number of client devices110used by different users (e.g., employees) of the organization. The client devices110provide a number of third-party applications111, which for reasons of organizational security require user authentication before a user can use the applications. An identity provider130is responsible for user authentication with the applications111within the organization100. A trusted broker application112on the client devices110acts as an intermediary between the identity provider130and the applications111also on the client devices, shielding the applications from the need for specific details about the identity provider130or the organization100. These various components are now described in additional detail.

The organization100is an entity, such as a corporation, a school, a governmental department, or the like. Physically, the organization100is made up of a number of computing systems, including the client devices110; one or more internal networks that connects the computing systems, including routers or other networking devices that define the boundary between the organization and external networks; and the like.

The organization100has one or more device security policies105that specify conditions that client devices110must satisfy in order to be permitted to log in to the applications111, such as that the client device110uses a particular encryption scheme for encrypting communications, that the client device has a particular security application installed, or the like. In some embodiments, the device security policies105are embodied in digital certificates associated with the organization100. When a client device110is enrolled by the organization100so that it is permitted to access resources of the organization, the device security policy105is stored on the client device so that it may later be verified that the device is conforming to that security policy.

The identity provider130manages user access to applications, services, and other resources for which user authentication is required. The identity provider130may be located at a location external to the organization100, e.g., connected to the organization via network150, as illustrated inFIG. 1. Alternatively, the identity provider130may be located within the boundaries of the organization100and administered by the organization itself

The identity provider130comprises a user access rights database131, which stores (e.g., in encrypted form) the user credentials used to authenticate a user to the identity provider itself. The user access rights database131may additionally contain other information, such as a list of the applications111to which the various users have access on the organization100, the particular functionality available to the users within those applications, and the like.

The client devices110are computing devices such as smart phones, laptop computers, desktop computers, or any other device that can execute third-party applications111.

A third-party application111is a software application usable via the client device110, such as an enterprise e-mail application, an application or plug-in for accessing an enterprise file system, an enterprise database, or the like. The application111is termed a “third-party” application in that it may (though need not necessarily) be authored by an author other than the organization100. In one embodiment, the third-party application's user interface is implemented in HTML or other web-based technology and is rendered within an embedded browser of the client device110.

The third-party application111is aware of the existence of the identity provider130and has the ability to direct a client device of a user to the identity provider for authentication. (For example, an administrator of the organization100can specify the identity and network information of the identity provider130in configuration files accessed by the third-party application111.) However, the third-party application111lacks the credentials of the user and the ability to access the saved credentials, nor does the third-party application innately have the ability to follow the protocols used to communicate with the identity provider130and with the trusted broker application112. These capabilities are in effect added to the third-party application via a client script provided by the identity provider130, as is described later with respect toFIG. 2.

The trusted broker application112is an application installed on each client device110of the organization100for which single sign-on is provided. The trusted broker application112may be created by the same author as the identity provider130and serves as an intermediary between the identity provider130and the third-party applications (which do not have the specifics of the particular identity provider).

The network150may be any suitable communications network for data transmission. In an embodiment such as that illustrated inFIG. 1, in which the identity provider130is located outside of the organization100, the network150uses standard communications technologies and/or protocols and can include the Internet. In another embodiment, the entities use custom and/or dedicated data communications technologies.

FIG. 2illustrates the interactions that take place between different entities ofFIG. 1when verifying the identity of a user as part of single sign-on to applications, according to an embodiment in which the client devices110are smartphones, and the applications111are native applications executing on the smartphones. Native smartphone applications typically lack full support for cookies, which could otherwise be used to aid the authentication process. Specifically, a user201of a client device110wishes to obtain access to one or more third-party applications111on the client device, where the access requires user authentication, and the user wishes to avoid re-entering authentication information for every separate application. Accordingly, to support single sign-on, and to avoid third-party applications being obliged to conform to details of the identity provider130, the identity provider provides a client script to the trusted broker application112, and the client script handles the details of communication with the identity provider. Among the communication details are generation and use of a token with public and private portions, which are used to confirm the user identity.

Accordingly, the user201initiates205a sign-on process that identifies the user to the identity provider130, after which the identity provider130transparently handles authentication of that user with each separate third-party application111that the user uses. In a step203, at time of enrollment of the client device110for use with the organization100, the client device stores202the device security policy provided by the organization for that device, e.g., in the form of a security certificate.

In one embodiment, the initiation205of the sign-on process involves the user201launching the trusted broker application112and entering the user's credentials for the identity provider130(e.g., a username and password). Based on the entered user credentials, the trusted broker application112stores210information that will allow it to communicate with the identity provider130in the future. The information can be, for example, either the user's credentials themselves or information obtained based on the user's credentials. As an example of the latter, in some embodiments the identity provider130provides the trusted broker application112with a token that remains valid for some period of time (e.g., two hours). The trusted broker application112provides the stored information (e.g., the token) to the identity provider130as a means of authenticating itself whenever it communicates with the identity provider130.

The user201then launches215the third-party application111, and code of the third-party application requests220the identity provider130to verify the user identity. In one embodiment, the identity provider130identifies225the third-party application111in order to ensure that the application111is one for which the organization100has authorized single sign-on. The identity provider130can identify225the third-party application111by, for example, reading an application identity string or other identifier included by the third-party application111within an HTTP message embodying the identity verification request.

In some embodiments, the identity provider130further generates230a token that is later used to establish the identity of the user. The token has a public portion and a corresponding private portion, the public and private portions having been generated together, such that one portion may be matched against the other portion. For example, the public and private portions may respectively be public and private keys of a key pair of a public key cryptosystem.

The identity provider130can also optionally generate235a user interface (e.g., specified in HTML) that informs the user of the status of the actions taking place, such as noting that the trusted broker application112was detected and that the user is in the process of being automatically signed on.

Included within code for the user interface is a client script202. The client script202is code that is responsible for implementing, on behalf of the third-party application111, operations of an authentication protocol used by the identity provider130. For example, in one embodiment the authentication protocol is OAuth, and the client script202is embodied in code of a client-side scripting language such as JavaScript. In one embodiment, the same client script202is provided to each third-party application111for which single sign-in functionality is desired. In one embodiment, the client script202also performs a number of operations, such as determining whether to show a traditional login interface or a single-sign on interface.

The identity provider130then provides240the generated user interface code and client script202to the third-party application111executing on the client device110.

The client script202executes automatically after it is received by the third-party application111of the client device110, running within the script runtime engine of the embedded browser in which the application111executes. In some embodiments, the client script202requests245the token generated by the identity provider130, which the identity provider in turn provides250. The public portion of the token is used later to establish the identity of the user whose identity is being verified.

The client script202also invokes255the trusted broker application112, providing it the received public portion of the token. In one embodiment, the client script202accomplishes the invocation using an authenticatable link. An authenticatable link is a uniform resource locator (URL) having a network domain portion that is interpreted by the operating system of the client device110by querying a service running in that network domain to determine which application corresponds to that domain, and then executing that application Examples of authenticable links are Universal Links (used in the IOS™ operating system) and App Links (used in the ANDROID™ operating system). For example, if the trusted broker were provided by a company named XYZ, the application URL might be as follows:

where “trustedbroker.xyz.com” informs the operating system that it should query a service in the trustedbroker.xyz.com domain to determine which application should be invoked. The parameter “pub=f802jf22ac8921af38cd90ae72c92fa3” indicates the value of the public portion of the token.

The use of authenticable links addresses the danger inherent in other link systems, in which a malicious application can alter the operating system's mapping between the application URL's domain (e.g., trustedbroker.xyz.com) and the application that corresponds to that domain (e.g., the trusted broker application112), such as a malicious application registering itself to correspond to the domain trustedbroker.xyz.com. The use of authenticable links, in contrast, ensures that the application that is invoked for the authenticable link is the application specified by the domain indicated in the link.

The trusted broker application112verifies260that single sign-on for the third-party application111is appropriate. For example, the trusted broker application112identifies the third-party application111(e.g., based on identifiers of the third-party application provided by the identity provider130) and verifies that the application111is trusted and that the user201has permission to use it. (Unlike the identity provider130, the trusted broker application112is aware of the identity of the user201due to the sign-on at step205, and hence has the ability to verify user-specific requirements.)

The trusted broker application112verifies263that the client device110conforms to the device security policy of the organization110. That is, the trusted broker application112accesses the device security policy (e.g., embodied as a certificate) obtained in step203during enrollment of the client device110and ensures that the client device fulfills each of the requirements (e.g., uses a certain type of encryption for communications) at the present moment. Verifying conformance to security policies at time of single sign-on addresses the danger that client device110conformance was last verified at an earlier time period and that the client device110has been altered to no longer be in conformance. (Such changes would be a risk with a system that checked device conformance only at predefined intervals, such as every several minutes.)

Assuming that the verification of step260is successful, the trusted broker application112provides265back to the identity provider130an indication that the verifications260,263were successful, in some embodiments along with the public token portion. The identity provider130attempts to match the public portion of the token against the stored private portion. If the portions match, the identity provider determines that the message from the trusted broker application112is genuine, rather than spoofed, and accordingly determines that the user201was in fact authorized to use single sign-on for the third-party application111. Since the trusted broker application112verified that the user201was authorized, it is appropriate at this point to allow sign-on requests for the user201. Accordingly, the identity provider130associates270the user201with the third-party application111and with the public portion of the token and notifies275the trusted broker application112that the association is complete by sending a message over the network150. The trusted broker application112in turn invokes280the third-party application111. The invocation may be accomplished using a second application URL, such as the URL:

which causes the operating system to invoke the application named “tpa”, for example, or the authenticatable link app.tpa.com, which causes the operating system to query a service in the domain app.tpa.com to determine the correct application to invoke. “<parameters>” represents any parameters to be included, such as an identifier of a user to be signed on to the application111(e.g., “jsmith122”), or a command to run in the application (e.g., “open”).

In another embodiment, the identity provider130does not explicitly notify275the trusted broker application112that the association of the user201with the third-party application111is complete. Rather, the trusted broker application112instead periodically polls the identity provider130, passing it the private token portion to identify the user and third-party application in question.

With the identity of the user201verified, the identity provider130initiates285the actual authentication flow for the third-party application, which proceeds according to the authentication protocol used by the identity provider130(e.g., OAuth) and may use data interchange formats such as Security Assertion Markup Language (SAML). As part of the initiation, the identity provider130includes an indication of the verification of the user's identity and permission to use single sign-on for the third-party application111. For example, the identity provider130can provide the third-party application with an OAuth token (distinct from the token generated at step230) that establishes the rights of the requesting user201to use the third-party application111. With authentication of the user201having successfully completed, the third-party application111then executes.

If the user201wishes to use other third-party applications111, the operations proceed as in steps215-280. That is, after the initiation205of sign-on and the storing210of user credentials, the steps215-280can be separately repeated for each distinct application111that the user201uses, without the need to repeat steps205and210(unless the security policy of the particular third-party application111requires a more recent occurrence of steps205and210).

It is appreciated that althoughFIG. 2illustrates a number of interactions according to one embodiment, the precise interactions and/or order of interactions may vary in different embodiments. For example, in another embodiment the launching215is instead accomplished by the trusted broker112receiving a designation of the third-party application111from the user, and accordingly invoking that application111(e.g., using an application URL such as those described above).

FIG. 3is a high-level block diagram illustrating physical components of a computer300used as part or all of the client device110or identity provider130fromFIG. 1, according to one embodiment. Illustrated are at least one processor302coupled to a chipset304. Also coupled to the chipset304are a memory306, a storage device308, a graphics adapter312, and a network adapter316. A display318is coupled to the graphics adapter312. In one embodiment, the functionality of the chipset304is provided by a memory controller hub320and an I/O controller hub322. In another embodiment, the memory306is coupled directly to the processor302instead of the chipset304.

The storage device308is any non-transitory computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory306holds instructions and data used by the processor302. The graphics adapter312displays images and other information on the display318. The network adapter316couples the computer300to a local or wide area network.

As is known in the art, a computer300can have different and/or other components than those shown inFIG. 3. In addition, the computer300can lack certain illustrated components. In one embodiment, a computer300acting as a server may lack a graphics adapter312, and/or display318, as well as a keyboard or pointing device. Moreover, the storage device308can be local and/or remote from the computer300(such as embodied within a storage area network (SAN)).

As is known in the art, the computer300is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program logic utilized to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are stored on the storage device308, loaded into the memory306, and executed by the processor302.

Other Considerations