A computer implemented method for synchronizing multi-tenant single sign-on configuration. Utilizing a combination layer that is configured a single time to interact with a trust application at an identity provider. The combination layer is also configured to interact with the service provider and manages the security token and authentication state of the user. The identity provider can create a single long-lived trust application that is only responsible for redirecting to the combination layer, rather than a creating plurality of short-lived applications that redirect to a service provider every time a user login request is received. Thus, resulting in improved utilization of computing resources at the identity provider.

BACKGROUND

The invention relates generally to single sign-on methods, and more particularly to single sign-on methods of multi-tenant service providers.

Single sign-on methods allow a user to enter credentials into an identity provider one time and gain access to one or more resources located at a service provider. An identity provider is a system entity with a database containing information about users and the login credentials of the users. A service provider is a system entity that possesses a resource which a user is attempting to access.

In many cases, the service provider delegates the authentication of users to the identity provider. This is because it reduces the burden on a user because there is no need to remember numerous passwords to access the desired resources. Further, single sign-on methods are beneficial for many service providers because the service provider is not required to maintain a database with user credentials and potentially sensitive personally identifiable information.

Many cloud based systems are multi-tenant systems. A multi-tenant system allows many different tenants to have access to a single instance of software on a public cloud system. While there may be many different tenants on a single cloud, the resources and data specific to a tenant may only be accessed by the tenants and are separated by dictated permission settings. Single sign-on methods allow for one or more trusted identity providers to authenticate and provide credentials for users, which in turn allows the service provider to grant access to the resources to which the user has permission.

SUMMARY

According to one aspect of the present invention, a computer-implemented method for synchronizing multi-tenant single sign-on at an identity provider (IDP), the method comprising: requesting, by one or more processors, the creation of a trust application configured with a security protocol at the IDP, by a combination layer; and receiving, by the one or more processors, at the combination layer verification of the creation of the trust application at an IDP.

According to another aspect of the present invention, a computer-implemented method for synchronizing multi-tenant single sign-on at an IDP, the method comprising: requesting, by one or more processors, access to a tenant resource at a service provider by a user via a security protocol; creating, by the one or more processors, a user state; storing, by the one or more processors, the user state; transmitting, by the one or more processors, the user state to a combination layer; transmitting, by the one or more processors, the user state from combination layer to a trust application at an IDP; validating, by the one or more processors, the user state information at the IDP; and responsive to valid user credentials, authenticate the user by creating, by the one or more processors, a user token at the IDP; transmitting, by the one or more processors, the user token to the combination layer; transmitting, by the one or more processors, the user token and the user state to SP; validating, by the one or more processors, the user state and the user token at SP, retrieving, by the one or more processors, a user profile at SP that corresponds to the user state; and granting, by the one or more processors, access to the requested tenant resource at SP.

According to another aspect of the present invention, a computer system for synchronizing multi-tenant single sign-on at an IDP, the computer system comprising: one or more computer processors; one or more non-transitory computer readable storage media; program instructions stored on the one or more non-transitory computer readable storage media for execution by at least one of the one or more computer processors, the program instructions comprising: program instructions to request the creation of a trust application at the IDP by a combination layer program instructions to create the trust application at the IDP, configured to receive single sign-on authentication requests from the combination layer according to a security protocol; responsive to the successful creation of the trust application, program instructions to transmit confirmation of the trust application creation from the IDP to the combination layer; program instructions to create a tenant domain at a service provider, configured to accept authentication credentials according to the security protocol from the combination layer; and program instructions to configure the combination layer to redirect successfully authenticated single sign-on session from the IDP.

DETAILED DESCRIPTION

It should be noted that embodiments of the present invention are described with reference to different embodiments. In particular, some embodiments are described with reference to method-type claims. However, a person of ordinary skill in the art will gather from the above and the following description that, unless otherwise noted, in addition to any combination of features belonging to one embodiment, any combination of features relating to different embodiments, in particular, features of the method type claims, systems claims, and computer product claims are considered to be disclosed within this document.

The aspects defined above, and further aspects of embodiments of the present invention, are apparent from the examples of embodiments to be described hereinafter and are explained with reference to examples of the embodiments, but to which the invention is not limited.

In the following, additional embodiments, applicable to the method, computer program product as well as to the related system, will be described.

In an embodiment of the present invention, there can be a combination layer (CL) configured to reduce the number of single sign-on (SSO) applications at an identity provider (IDP). A service provider (SP) can direct a user login request to the combination layer, which can be configured to accept the login credentials of the user and redirect the credentials to the IDP. The IDP can authenticate the user's credentials with a trust application which, if successfully authenticated, redirects an authentication state and security token to the CL. A trust application can be a long-lived SSO instance that redirects successful authentication requests to the CL. The CL can forward an authentication state and a security token to the SP. Once authenticated, the SP can grant the user access to the resources for which permissions have been granted. Further, the CL is only required to be created one-time and initialized for an IDP, thus enabling the synchronous multi-tenant sign-on at an IDP.

Embodiments of the present invention can be implemented together with virtually any type of computer, regardless of the platform, being suitable for storing and/or executing program code.

FIG. 1shows, as an example, a computing system100suitable for executing program code related to the proposed embodiments.

As shown in theFIG. 1, computer system/server100is shown in the form of a general-purpose computing device. The components of computer system/server100may include, but are not limited to, one or more processors or processing units102, a system memory104, and a bus106that couple various system components including system memory104to the processor102. Bus106represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limiting, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus. Computer system/server100typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server100, and it includes both, volatile and non-volatile media, removable and non-removable media.

The system memory104may include computer system readable media in the form of volatile memory, such as random-access memory (RAM)108and/or cache memory110. Computer system/server100may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, a storage system112may be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a ‘hard drive’). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a ‘floppy disk’), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as, but not limited to, a CD-ROM, DVD-ROM or other optical media may be provided. In such instances, each can be connected to bus106by one or more data media interfaces. As will be further depicted and described below, memory104may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

The program/utility, having a set (at least one) of program modules116, may be stored in memory104by way of example, and not limiting, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules116generally carry out the functions and/or methodologies of embodiments of the invention, as described herein.

The computer system/server100may also communicate with one or more external devices118such as a keyboard, a pointing device, a display120, etc.; one or more devices that enable a user to interact with computer system/server100; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server100to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces114. Still yet, computer system/server100may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter122. As depicted, network adapter122may communicate with the other components of the computer system/server100via bus106. It should be understood that, although not shown, other hardware and/or software components could be used in conjunction with computer system/server100. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

FIG. 2is an exemplary environment200suitable for an embodiment for synchronizing multi-tenant single sign-on configuration. The synchronous multi-tenant single sign-on configuration environment200comprises a server computer202which operates the m IDP204, a server computer206which operates the SP208, a server computer210which operates the combination layer CL212, a network214, and client computers216,218, and220. It should be noted, an embodiment can utilize at least one or a plurality of client computers, i.e. 1+n, where n can be any number of client computers.

In one embodiment, server computers202,206, and210can be a standalone computing device, management server, a web server, a mobile computing device, or any other electronic device or computing system capable of receiving, sending, and processing data. In other embodiments, server computers202,206, and210can represent a server computing system utilizing multiple computers as a server system. In another embodiment, server computers202,206and210can be a laptop computer, a tablet computer, a netbook computer, a personal computer, a desktop computer, or any programmable electronic device capable of communicating with other computing devices (not shown).

In another embodiment, server computers202,206, and210represent a computing system utilizing clustered computers and components (e.g., database server computers, application server computers, etc.) that act as a single pool of seamless resources when accessed within the multi-tenant single sign-on synchronous configuration environment200. It should be noted that server computers can include internal and external hardware components, as depicted inFIG. 1.

Server computer202further comprises IDP204. IDP204can possess functionality that can authenticate users. IDP204may operate on a server computer202or any other suitable electronic device that is connected to network214. IDPs may include but are not limited to Google Authenticator, Facebook Authenticator, Amazon Web Service SSO, or Salesforce Authenticator. The authentication of users can be accomplished with a single sign-on (“SSO”) mechanism or any other mechanism that is suitable to authenticate a user including but not limited to, two-factor authentication or biometric authentication. In an embodiment of the invention, IDP204can have a database (not shown) which contains various information about users associated with a tenant. IDP204database may also contain information about users not associated with a specific tenant. The information in IDP204database may include, but is not limited to, name, employer, address, and login credentials. Further, the information stored in IDP204database may include information about a two-factor authentication method and how to utilize it. IDP204may include trust application220, i.e. a SSO mechanism, that can be configured to operate in conjunction with CL212and redirect all successful authentication requests from CL212back to CL212, rather than redirecting authenticated users back to different SPs. IDP204SSO mechanism can redirect the user back to the CL212after authentication. In order to show that a user has been authenticated, IDP204may transmit a user token and authentication state to CL212. A user token may be a token, certificate, or any other suitable security measure capable of showing that a user has been authenticated. IDP204may operate on an SSO security protocol, including, but not limited to, Security Assertion Markup Language 2.0, OAuth 2.0, Open IDconnect, etc.

SP208can provide functionality a resource a user might want to utilize i.e., a tenant domain. A tenant domain can be an instance running on a cloud, however, the domain is partitioned off from any other tenants, so users of one tenant cannot access the data or features of other tenants. Examples of SPs can include but are not limited to, Salesforce, Workday, Sumo Logic. The single software application may be an application, database, or any service a user could access by network214. Once a user accesses SP208, SP208creates a user state and the user state is directed to CL212. In some embodiments the user state can be the user's login information which can include but is not limited to, password, username, and IP address. It should be noted that SP208does not have the login credentials of the user and delegates the authentication to another entity, namely IDP204.

CL212can provide functionality that accepts user login requests from multiple SPs208and direct the requests to IDP204. CL212can be configured to operate in conjunction with trust application220at an IDP204. A trust application is an SSO instance at IDP204, where the instance is configured to trust authentication requests from CL212. The trust application220can receive the authentication request from CL212and attempt to authenticate the user. If the authentication is successful, the trust application220can redirect the security token to CL212which can consist of a set of XML, data records which can identify the identity and group membership of the user requesting authentication, and authenticated state back to CL212. Additionally, if IDP204operates under certain SSO security protocol, for example but not limited to, OAuth 2.0, OpenID, and Native Application Profile. CL212can provide the capability to transmit application programming interface instructions, as well as including access tokens and session keys from IDP204to SP208.

Further, it should be noted that inFIG. 2multiple servers202,206, and210are shown, each with different modules, IDP204, SP208, and CL212, the modules can all be located on the same server or in any combination on different servers.

Client computer216,218, and220can be a standalone computing device, management server, a web server, a mobile computing device, or any other electronic device or computing system capable of receiving, sending, and processing data. In other embodiments, client computers216,218, and220can represent a server computing system utilizing multiple computers as a server system. In another embodiment, server computers202,206and210can be a laptop computer, a tablet computer, a netbook computer, a personal computer, a desktop computer, or any programmable electronic device capable of communicating with other computing devices (not shown) within the multi-tenant single sign-on synchronous configuration environment200via network214. Client computer216,218, and220possess the capability to access the SP208via a web browser (not shown), which then commences the login process.

FIG. 3is a flow chart diagram depicting the operational steps of an embodiment of a computer-implemented method for synchronous multi-tenant single sign-on configuration300. At step302, CL212requests the creation of trust application220at IDP204. Next at step304, IDP204transmits confirmation of the creation of trust application220to CL212via network214.

FIG. 4is a flow chart diagram depicting the operational steps of an embodiment of a computer-implemented method for utilizing a multi-tenant single sign-on configuration400. At step402, a user requests access to tenant resources at SP208. Next at step404, a user state is created at SP208. Next at step406, store the user state at SP208. Next at step408, transmit the user state to CL212. Next, at step410transmit the user state to trust application220at IDP204. Next, at step412determine at trust application220if the user's credentials are valid. If the credentials are not valid deny access. If the credentials are valid, go to step414. At step414, create a user token at trust application220. Next at step416, transmit the user token to CL212. Next at step418, transmit the user token to the CL212. Next at step420, verify the user state against the user token. Next at step422, retrieve the user profile that corresponds to the user token. Next at step424, grant the user access to the requested tenant resources.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows: