Techniques for authentication using push notifications

The present disclosure relates to techniques for authentication of a user on a restricted website, or on an enterprise network with single sign-on, or on various other service systems with security restrictions using push notifications. One technique includes receiving an authorization request for a first application to access a resource, sending a first push notification to a second application, the first push notification requesting authentication of a user of the first application, receiving information indicating a response to the first push notification, sending a second push notification to the first application, the second push notification includes a status of the authorization request based on the response to the first push notification, receiving information indicating an outcome of the authentication request based on the response to the first push notification, and providing the first application access to the resource.

FIELD OF THE INVENTION

The present disclosure relates generally to access control, and more particularly, to techniques for authentication of a user on a restricted website, or on an enterprise network with single sign-on, or on various other service systems with security restrictions using push notifications.

BACKGROUND

A use of a single specific authentication method such as a password authentication or the digital certificate authentication at a level of authentication is known as single-factor authentication that identifies the user requesting access through only one category of credentials. Single-factor authentication for a system typically only requires a user to create an account by providing a username and associated password (e.g., a knowledge factor only authentication). Since passwords can easily end up in the wrong hands, this approach is not very secure. Therefore, enterprises and high-value web service providers such as banks often require alternative single factor authentication techniques or multi-factor authentication, e.g., at least a second factor, specifically for higher sensitive resources (e.g., higher level authentication applications). The multi-factor approach requires a user to present at least two factors of identification from a set of factors potentially including: (1) a knowledge factor; (2) a possession factor; and (3) an inherence factor. The knowledge factor refers to something the user knows, for instance a password, pin code or passphrase; the possession factor refers to something the user owns, for instance a security fob, a magnetic card, a cell phone, or a tablet computer; and the inherence factor refers to something the user is. The inherence factor could be determined using biometrics such as fingerprint, iris or voice analysis.

Single factor and multi-factor authentication techniques that include use of a username and associated password have proven to be cumbersome and bad security practice. In fact, many users and enterprises are looking at password-free technologies as their preferred method of authentication, both from a security and ease-of-use perspective. Among the most prominent password-free authentication methods are push notifications. Many enterprises have already provided push notification authentication alternatives for their consumer-facing products. Push notification authentication validates login attempts by sending access requests to an associated device (a possession factor). When a user registers their account, the user links the account to a device they possess. Afterwards, whenever the user tries to log in to their account, the user submits their username or ID. In addition to (multi-factor authentication) or instead of entering their password (single factor authentication), the user receives an access request notification on their device, which the user can approve or decline. The benefits of push notification authentication is that user does not need to memorize and manage passwords, and the notification provides a seamless and user-friendly experience. Additionally, validating an authentication request is often quicker using push notifications than entering a complex user name and password.

Conventionally, it is difficult to complete the push notification based authentication without polling notification status and without persisting notification data on the server. For example, when a user initiates an action that requires authentication (e.g., requesting access to a protected resource), the user's browser sends a request to a server to initiate the action. The server determines based on one or more authentication/authorization policies that the action requires authentication (e.g., single factor authentication or second factor authentication) and that the authentication method includes use of a push notification. The server sends a push notification to the registered user device. Until the push notification is approved, the browser keeps on polling for the status of the initiated request. As long as the request is not approved, the browser keeps on polling the server at regular intervals. These polling requests can be bulky and cause heavy load on the system. If there are a number of simultaneous authentication requests (e.g., login requests), then the server will end up serving an overwhelming number of polling requests. Accordingly, new techniques are desired for completing push notification based authentication without use of polling for the status of the initiated request.

BRIEF SUMMARY

Systems, methods and computer-readable memory for controlling access to resources accessible in a distributed environment are described. Certain techniques are described for authentication of a user on a restricted website, or on an enterprise network with single sign-on, or on various other service systems with security restrictions using push notifications.

In various embodiments, a method is provided comprising receiving, at a server, an authorization request for a first application to access a resource; sending, by the server, a first push notification to a second application, the first push notification requesting authentication of a user of the first application; receiving, at the server, information indicating a response to the first push notification; sending, by the server, a second push notification to the first application, the second push notification includes a status of the authorization request based on the response to the first push notification; receiving, at the server, information indicating an outcome of the authentication request based at least on the response to the first push notification; and providing, by the server, the first application access to the resource.

In some embodiments, the method further comprises determining, by the server, whether the user of the first application has registered the second application for push notification authentication; and when the user has registered the second application for push notification authentication, sending, by the server, an initial notification on the status of the authorization request and a transaction unique identifier to the first application. The initial notification informs the first application that the authorization request requires the push notification authentication and wait for either: (i) receipt of the second push notification, or (ii) a time-out period to have expired.

In some embodiments, the method further comprises composing, by the server, a message for the first push notification, where the message requests confirmation of an identity of the user; and preparing, by the server, notification data for the first push notification, where the notification data includes a unique identifier for the second application and contents for a call back to the first application, and where the contents for the call back include the transaction unique identifier; and generating, by the server, the first push notification using at least the message and the notification data.

Optionally, the sending the first push notification comprises sending, by the server, the first push notification to a push notification service via an application program interface, and where the server is registered with the push notification service. Optionally, the response to the first push notification confirms the identity of the user, and the response to the first push notification is signed with a digital signature.

In some embodiments, the method further comprises composing, by the server, a message for the second push notification, where the message includes the status of the authorization request based on the response to the first push notification; and preparing, by the server, notification data for the second push notification, where the notification data includes a unique identifier for the first application and the transaction unique identifier; and generating, by the server, the second push notification using at least the message and the notification data. Optionally, the outcome of the authentication request is a validation of credentials of the user, and where the credentials include at least the response to the first push notification.

In various embodiments, a system is provided comprising a distributed environment that includes a server comprising a resource, one or more processors, and non-transitory machine readable storage medium having instructions stored thereon that when executed by the one or more processors cause the one or more processors to perform the process comprising: receiving, at the server, an authorization request for a first application on a client device to access the resource; sending, by the server, a first push notification to a second application via a push notification service, the first push notification requesting authentication of a user of the first application; receiving, at the server, information indicating a response to the first push notification; sending, by the server, a second push notification to the first application via the push notification service, the second push notification includes a status of the authorization request based on the response to the first push notification; receiving, at the server, information indicating an outcome of the authentication request based at least on the response to the first push notification; and providing, by the server, the first application access to the resource.

In some embodiments, the process further comprises determining, by the server, whether the user of the first application has registered the second application for push notification authentication; and when the user has registered the second application for push notification authentication, sending, by the server, an initial notification on the status of the authorization request and a transaction unique identifier to the first application. The initial notification informs the first application that the authorization request requires the push notification authentication and wait for either: (i) receipt of the second push notification, or (ii) a time-out period to have expired.

In some embodiments, the process further comprises composing, by the server, a message for the first push notification, where the message requests confirmation of an identity of the user; and preparing, by the server, notification data for the first push notification, where the notification data includes a unique identifier for the second application and contents for a call back to the first application, and where the contents for the call back include the transaction unique identifier; and generating, by the server, the first push notification using at least the message and the notification data.

Optionally, the sending the first push notification comprises sending, by the server, the first push notification to a push notification service via an application program interface, and where the server is registered with the push notification service. Optionally, the response to the first push notification confirms the identity of the user, and the response to the first push notification is signed with a digital signature.

In some embodiments, the process further comprises composing, by the server, a message for the second push notification, where the message includes the status of the authorization request based on the response to the first push notification; and preparing, by the server, notification data for the second push notification, where the notification data includes a unique identifier for the first application and the transaction unique identifier; and generating, by the server, the second push notification using at least the message and the notification data. Optionally, the outcome of the authentication request is a validation of credentials of the user, and where the credentials include at least the response to the first push notification.

In various embodiments, a non-transitory machine readable storage medium is provided having instructions stored thereon that when executed by one or more processors cause the one or more processors to perform the method comprising: receiving an authorization request for a first application to access a resource; sending a first push notification to a second application, the first push notification requesting authentication of a user of the first application; receiving information indicating a response to the first push notification; sending a second push notification to the first application, the second push notification includes a status of the authorization request based on the response to the first push notification; receiving information indicating an outcome of the authentication request based at least on the response to the first push notification; and providing the first application access to the resource.

In some embodiments, the method performed further comprises determining whether the user of the first application has registered the second application for push notification authentication; and when the user has registered the second application for push notification authentication, sending an initial notification on the status of the authorization request and a transaction unique identifier to the first application. The initial notification informs the first application that the authorization request requires the push notification authentication and wait for either: (i) receipt of the second push notification, or (ii) a time-out period to have expired.

In some embodiments, the method performed further comprises composing a message for the first push notification, where the message requests confirmation of an identity of the user; and preparing notification data for the first push notification, where the notification data includes a unique identifier for the second application and contents for a call back to the first application, and where the contents for the call back include the transaction unique identifier; and generating the first push notification using at least the message and the notification data.

Optionally, the sending the first push notification comprises sending the first push notification to a push notification service via an application program interface, and where the server is registered with the push notification service. Optionally, the response to the first push notification confirms the identity of the user, and the response to the first push notification is signed with a digital signature.

In some embodiments, the method performed further comprises composing a message for the second push notification, where the message includes the status of the authorization request based on the response to the first push notification; and preparing notification data for the second push notification, where the notification data includes a unique identifier for the first application and the transaction unique identifier; and generating the second push notification using at least the message and the notification data. Optionally, the outcome of the authentication request is a validation of credentials of the user, and where the credentials include at least the response to the first push notification.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of various embodiments described herein. However, it will be apparent that the various embodiments may be practiced without these specific details. The figures and description are not intended to be restrictive.

INTRODUCTION

The present disclosure relates generally to access control, and more particularly, to techniques (e.g., systems, methods, computer program products storing code or instructions executable by one or more processors) for authentication of a user on a restricted website, or on an enterprise network with single sign-on, or on various other service systems with security restrictions using push notifications. In various embodiments, a method is provided for that includes receiving, at a server, an authentication request for an application (e.g., a web application or web app) to access a resource; sending, by the server, a push notification to an authentication application, the push notification requesting authentication for the application; receiving, at the server, information indicating a response to the push notification; and providing, by the server, access to the application to access the resource based on the received information.

Conventionally, until information indicating a response to the push notification is received at the server, the application (e.g., the web application or web app) keeps polling the server for the status of the initiated request for access to the resource. As long as the push notification is not approved or declined (e.g., the user is busy doing other things and has not completed the authentication process by approving or declining the push notification on the authentication application), the application keeps polling the server. In order to avoid the heavy load on the systems caused by the polling, most of the systems today either: (i) poll the request for notification status at regular intervals, and if the request has not been approved or denied, then sleep the polling for some time and poll for status again after some predetermined time; or (ii) when a request is made to the server for authentication, the server keeps the http request thread blocked synchronously until a response with approved or denied is received or request timeout is elapsed and request fails with timeout exception.

Both of these methods have their own advantages and disadvantages. For polling to be successful, the notification records must be persisted either in cache or persistence database. This adds more database records as the number of authentication transactions increase. Polling the server, every time consumes server computation power, and the higher the frequency of polling, the higher the consumption of server resources, database, central processing units, and network bandwidth. This polling nature not only introduces unnecessary computational resources, but also, reduces server capacity to allow more transactions. In addition, if there is no action by the client application on the notification or the browser is closed, then the server needs to perform an additional job to clean up the database records. In the second approach of blocking a thread, the system blocks incoming requests for a certain time duration. The push notification should be either approved or denied within the time duration. If not, the push notification will timeout. However, blocking an http request for the time duration may have severe disadvantages especially, when proxies are involved. There is a possibility of proxies terminating connection during the time duration. Thus, the system must ensure that all the proxies involved in the middle will support the allowed time duration before the push notification is approved, denied, or timed out. Additionally, blocking an http request at the server limits the number of supported http requests allowed, and there could be possibly server issues due to the number of allowed threads.

To address these problems and provide an improved system to complete push notification, a method is provided comprising receiving, at a server, an authorization request for a first application to access a resource, sending, by the server, a first push notification to a second application, the first push notification requesting authentication of a user of the first application, receiving, at the server, information indicating a response to the first push notification, sending, by the server, a second push notification to the first application, the second push notification includes a status of the authorization request based on the response to the first push notification, receiving, at the server, information indicating an outcome of the authentication request based on the response to the first push notification; and providing, by the server, the first application access to the resource. As used herein, when an action is “triggered by” or “based on” something, this means the action is triggered or based at least in part on at least a part of the something. The proposed solution completes push notification based authentication without any hassle and avoids all the aforementioned disadvantages of prior solutions. Advantageously, the proposed solution does not store notification content (e.g., no storage in the database or cache), and the system is able to manage communication between two parallel processes. Additionally, if required, the prior solutions can be implemented in conjunction with the proposed solution to make authentication system more robust.

Control Access System

The various embodiments described herein may be used in an assortment of different domains and contexts. Certain embodiments are particularly applicable to enterprise application software provided in cloud computing technology. However, the systems and methods described herein may be used to provide access control functionality for any system or application framework that relies on an access manager server for controlling access to resources in a distributed environment.

In some embodiments, systems, methods, and computer-readable media are disclosed for controlling access to resources accessible in a distributed environment.FIG. 1Aillustrates a system100for managing access to resources in accordance with an exemplary embodiment. Specifically, system100provides access among different resources provided within a distributed environment. For example, a user operating a client device105may access a network108such as an enterprise computer network that includes a distributed computing system110. The distributed computing system110may be implemented using a cloud computing infrastructure. In some embodiments, the distributed computing system110may include a distributed environment server115(e.g., a cloud server) that delivers computing power and storage capacity as a service to user via a network. Resource120(e.g., application and data) is stored on the distributed environment server115in an instance that is accessible by the client device105via the network. Client device105may be a workstation, personal computer (PC), laptop computer, smart phone, wearable computer, or other networked electronic device.

Resource120may include, without restriction, a file, a web page, a document, web content, services, a computing resource, or an application. For example, system100may include resource120such as application125and/or content accessible through the application125. A resource120may be requested and accessed using an application130(e.g., a first application) on client device105. For example, the application130may request access to a web page from a resource server based on a URL identifying a requested resource. Resource120may be provided by one or more computing systems, e.g., a resource server such as distributed environment server115that provides access to one or more resources upon authentication of a user in the system100. In some embodiments, the application130is a web application or web app, which is a client-server computer program that the client105(including the user interface and client-side logic) runs in a web browser132. In other embodiments, the application130is a desktop or mobile application such as an enterprise application, which is a client side computer program that the client105(including the user interface and client-side logic) runs on an operating system134, and may interface with external networks or servers via the browser132or other well-known interfaces.

An access management system may be implemented in system100according to an agent-server model for enabling communication between client device105and the distributed environment server110to provide access control functionality over resource120. The agent-server model may include an agent component (e.g., security agent135also known as a single sign-on agent or policy-enforcement agent) and a server component (e.g., access manager server140also known as a single sign-on server or policy server). The security agent135may be deployed with the resource120as a plugin or as a portion of the resource120, or the security agent130may be provisioned separate from the resource120, for example, running on a web server in front of the resource120. The access manager server140may be deployed as a part of an identity management system145. The identity management system may further comprise agent service150, authentication service155, identity store160, and authorization service165.

The security agent135and the access manager server140may work in combination to provide user access control and protect resources within the enterprise computer network against external and internal web-based threats. For example, the access manager server140may serve as the decision component for controlling access to the resource120, and the security agent135may implement or operate as the enforcement component for controlling access to the resource120. In some embodiments, the security agent135may be application language binding specific, and thus, the security agent135could be used for protecting multiple applications written in the same language and sharing the same endpoints (e.g., uniform resource identifier (URI)).

The access management system enables authentication/authorization (e.g., single sign-on (SSO)) functionality within a distributed environment, and may perform various access control related functions for managing access to resources within the distributed environment. For example, security agent135and access manager server140may perform authentication (e.g., single level, single factor, multi-level, and/or multi-factor authentication) of a user operating the client device105. Authentication is the process by which a user is verified to determine that he/she is who he/she claims to be. In some embodiments, the access management system receives a request from a user in response to the user sending the request to access management system from a client device. In other embodiments, the access management system receives a request from users in response to the access management system intercepting the request. To authenticate a user, the access management system (e.g., using security agent135and access manager server140) may present a user with a request for authentication credentials in the form of a challenge (e.g., via the user's web browser or via another application). Authentication policies may specify the authentication methodology (e.g., level and/or factors) to be used for authenticating the user for whom the access must be provided on a given resource. The policies define the way in which the resource access is to be protected (e.g., type of encryption, or the like). For example, the rules of a policy may dictate that single or multi-factor authentication be performed that includes a possession factor authentication via a push notification. The access management system may further determine authorization of a user to access a resource. Authorization is the process of determining if a user has a right to access a requested resource. Authorization policies may be defined that specify the conditions under which a user or group of users has access to a resource. For example, an administrator may only authorize certain users within a group to access particular resources.

FIG. 1Afurther illustrates an example of a SSO session managed within a distributed environment implementing an access management system comprising security agent135and access manager server140. For example, a user may operate client device105to request access to resource120controlled by distributed environment server115. The request may be routed to or intercepted by security agent135, which controls access to resource120. In some embodiments, some resources managed by the security agent135are not protected, in which case security agent135will query the access manager server140to determine if the requested resource is protected. The access manager server140checks relevant authentication policies for the resource120to determine whether authentication is required for access to the resource120. If the requested resource120is protected and requires authentication for use, the access manager server140may determine whether any session exists for the user. Upon determining that no session has been established for the user, the user may be forwarded by the access manager server140to a login service (e.g., authentication service155) of the identity management system145. The authentication service155may request authentication credentials (e.g., user name/password, accept or decline a push notification, or the like) from the user. The authentication service155may authenticate the user upon receiving the proper authentication credentials by validating the credentials against those stored in a user directory or identity store160.

Based on receiving the proper authentication credentials for the user, the access manager server140may forward the user back to the security agent135, the security agent135may check the authentication, and establish a first session for user upon authentication of the user. As a result, the user is logged into the distributed environment server115for the session. Once logged in, the user may access resources to which the user is authorized to access, such as running different applications, accessing cloud storage, or the like. Once the user is logged into the distributed environment server115, the access manager server140creates a cookie that tracks session activity for the user. The cookie may include a length of time that the user has been active on a session. The cookie may be stored as session activity data within the identity management system145.

Upon determining that the user is authenticated for a SSO session, security agent135may process the original request for resource120by directing an authorization query to the access manager server140. The access manager server140checks relevant authorization policies for the resource120to determine whether the user is authorized to access to the resource. The access manager server140responds to the security agent135with an allow or deny message based on the authorization policies. Upon determining that the user is allowed access to the resource120, the security agent135allows the request from the client device105for access to the resource120to go through and the user can access the resource120on the distributed environment server115via client device105. Upon determining that the user is denied access to the resource120, the security agent135notifies the client105that access to the resource120for the user is not permitted.

Push Notification Framework

In various embodiments, systems, methods, and computer-readable media are disclosed for authentication of a user on a restricted website, or on an enterprise network with single sign-on, or on various other service systems with security restrictions using push notifications.FIG. 1Billustrates a framework for push notification authentication in accordance with an exemplary embodiment using system100as described with respect toFIG. 1A. Specifically, system100may be configured to provide push notification authentication for different resources provided within a distributed environment using a first application130, a push notification service170, and authentication application180(e.g., a second application). In various embodiments, the push notification service170is a platform notification service that enables the access management system (e.g., the authentication service155) or the distributed environment server115to send notification data to applications installed on client devices. The authentication service155or the distributed environment server115may comprise a notification publisher185that is registered with the push notification service170and has an application programming interface190(API) to the push notification service170in order for the notification publisher185to communicate with the push notification service170. The notification publisher185may be configured to compose push notifications and send the push notifications to client devices via the API190.

In some embodiments, the first application130is a web application, desktop application, or mobile application on the client device105. The first application130may be configured to determine whether it may receive push notifications. For example, the first application130may communicate with a browser132of the client device105and check whether it can receive push notifications. In other embodiments, the first application130is self-aware (e.g., an enterprise application) that it can receive push notifications. If the first application130can receive push notifications, then the first application130registers itself to receive push notifications. For example, unique identifiers (IDs) for the first application130and/or the client device105, are registered with the push notification service170. The unique identifiers may be passed back to the first application130from the push notification service170. The unique identifiers may also be sent to the notification publisher185, which receives and stores the registration details including the unique identifiers. This browser132may provide APIs for the first application130to register for incoming push notifications, or the first application130may have the APIs for the registration. As a result of the registration, the first application130may receive information such as a registration token from the notification service170and configure a listener of the first application130with the token to receive incoming notifications from notification publisher185via the notification service170.

In some embodiments, the second application180is a web application, desktop application, or mobile application on a client device configured to receive incoming push notifications and display the notification to a user. The second application180may be implemented on the client device105, or the second application180may be remote from client device105and implemented on another client device (e.g., a user's mobile device). The another client device may be a workstation, personal computer (PC), laptop computer, smart phone, wearable computer, or other networked electronic device. In some embodiments, the user registers the second application180to receive push notifications for authentication on the access management system. In other embodiments, the second application180registers itself to receive push notifications for authentication on the access management system. For example, unique identifiers for the second application180and/or the client device105or another client device, are registered with the push notification service170. The unique identifiers may be passed back to the second application180from the push notification service170. The unique identifiers may also be sent to the notification publisher185, which receives and stores the registration details including the unique identifiers. As a result of the registration, the second application180may receive information such as a registration token from the notification service170and configure a listener of the second application180with the token to receive incoming notifications from notification publisher185via the notification service170.

FIG. 1Bfurther illustrates an example of a push notification authentication session managed within a distributed environment implementing an access management system and push notification service170. For example, a user may operate client device105to request access to resource120controlled by a distributed environment server115. At step171, the first application130(e.g., a web application) may be used by a user of the client device105to make an authentication request to a resource server such as the distributed environment server115for access to the resource120. The distributed environment server115may call a login service (e.g., authentication service155) of the identity management system145to evaluate an authentication policy for the requested resource120. The login service returns the authentication policy based on the type of resource requested by the user. The policy indicates the resource requested and the level of authentication required for accessing the resource. In various embodiments, the level of authentication required includes use of a push notification as a part of a single or multi-factor authentication, and thus the authentication service155and the distributed environment server115realize that a push notification needs to be sent to a registered authentication application (e.g., the second application180) for approval.

At step172, the distributed environment server115determines whether the user has registered an authentication application and/or client device with the access management system (e.g., the authentication service155) or the distributed environment server115for push notification authentication. In the instance that the user has registered, then the distributed environment server115replies to the browser132or the first application130with a notification on the status of the request for access and a transaction unique identifier (ID). The notification allows for the first application130to know it should wait for either (i) receipt of a second push notification (a status message) concerning whether a first push notification (the authentication message) has been accepted or denied via the second application180, or (ii) a time-out period to have expired. The transaction unique identifier allows the access management system to uniquely identify this transaction or request for access from the client105to the resource120. In the instance that the user has not registered, then the distributed environment server115replies to the browser132or the first application130with a request to register an authentication application and/or client device with the access management system for push notification authentication.

At step173, the notification publisher185composes a message for the first push notification, for example, an automatic message composed through a message composer, based on the authentication policy for the requested resource120and prepares notification data to be sent with the message. In some embodiments, the message is composed as a notification that a user is trying to access a resource and the server needs confirmation that the user is who they say they are; thus, prompting the user to accept or deny confirmation. In other embodiments, the message is a code or question prompted by the user trying to access a resource and the server needs the user to respond with the code or answer to confirm that the user is who they say they are; thus, prompting the user to provide the code or answer. The notification publisher185defines the audience such as the client device105or another client device to whom the first push notification will be sent. In certain embodiments, the notification publisher185may determine whether the first push notification should be sent immediately or in accordance with a schedule. In various embodiments, the notification data includes the unique identifiers for the second application180and/or the client device105or another client device and contents for a call back to the first application130. The contents for the call back may include the unique identifiers for the first application130and/or the client device105and the transaction unique identifier. Thereafter, the notification publisher185sends the first push notification (message and notification data) to the push notification service170via the API190, and the push notification service170receives the first push notification from the publisher185.

At step174, the push notification service170forwards the first push notification to the second application180on the client device105or another client device based on the unique identifiers for the second application180and/or the client device105or another client device. In various embodiments, the push notification service170unpacks the notification data from the first push notification and uses the unique identifiers for the second application180and/or the client device105or another client device to look up registration data for the client device105or another client device. The registration data includes information on how to contact the client device105or another client device such as an IP address. Thereafter, the second application180receives the first push notification, and parses the first push notification to obtain the notification data and the message. One of the benefits of push notifications is that they can be interactive and users can take action on messages in the notification by responding to the push notification. For example, the push notification may include a code or question that the user of the client device105or another client device can read, interpret and respond to via the second application180and/or the client device105or another client device. In its simplest form, the reply by the user may be acceptance or denial that the user did generate the request for access to resource120on the first application130. In more complex forms, the reply may include a code embedded in the message or an answer to a question within the message that confirms the user did generate the request for access to resource120on the first application130. In some embodiments, the user uses the second application180to prepare or compose the reply manually through a message composer user interface. It is to be understood that the reply may be generated immediately upon receipt of the first push notification, or if the user is distracted or busy, the reply may not be prepared or composed for some period of time.

At step175, the second application180sends the reply along with the some or all of the notification data obtained from the first push notification to the notification publisher185of the authentication service155or the distributed environment server115. In some embodiments, the notification data includes the contents for the call back, for example, the unique identifiers for the first application130and/or the client device105and the transaction unique identifier. In certain embodiments, the reply and the notification data are sent back in a signed format to the notification publisher185. For example, the reply and the notification data are signed with a digital signature. The digital signature is a mathematical scheme for presenting the authenticity of digital messages and the notification data. A valid digital signature gives the notification publisher185reason to believe that a known sender created the message (authentication), that the sender cannot deny having sent the message (non-repudiation), and that the message was not altered in transit (integrity).

At step176, the notification publisher185of the authentication service155or the distributed environment server115, receives the signed reply and notification data. The notification publisher185recognizes the response based on the contents for the call back (e.g., the unique identifiers for the first application130and/or the client device105and the transaction unique identifier) and prepares a second push notification for the browser132or first application130. The notification publisher185composes a message for the second push notification, for example, an automatic message composed through a message composer, based on the reply and the notification data received from the second application180, and prepares notification data to be sent with the message to the push notification service170via the API190. In some embodiments, the message is the status of the first push notification (e.g., accepted or denied) such that the first application130is aware of the status of the request for access to the resource. The notification publisher185defines the audience such as the client device105to whom the second push notification will be sent. In certain embodiments, the notification publisher185may determine whether the second push notification should be sent immediately or in accordance with a schedule. In various embodiments, the notification data includes the unique identifiers for the first application130and/or the client device105and the transaction unique identifier. Thereafter, the notification publisher185sends the second push notification (message and notification data) to the push notification service170via the API190, and the push notification service170receives the second push notification from the publisher185.

At step177, the push notification service170forwards the second push notification to the first application130on the client device105based on the unique identifiers for the first application130and/or the client device105. In various embodiments, the push notification service170unpacks the notification data from the second push notification and uses the unique identifiers for the first application130and/or the client device105to look up registration data for the client device105. The registration data includes information on how to contact the client device105such as an IP address. Thereafter, in some embodiments, the browser132receives the second push notification and sends the second push notification as a browser notification to a listener of the first application130for processing. In some embodiments, the listener of the first application130directly receives the second push notification for processing.

At step178, the listener of the of the first application130processes the second push notification. In some embodiments, the processing comprises parsing the second push notification to obtain the notification data and the message. The notification data lets the first application know which request the second push notification is referring to via the transaction unique identifier and the message tells the first application130the status of the request for access to the resource. Thereafter, the first application sends a notification to the authentication service155or the distributed environment server115to indicate the status of the request for access to the resource has been received and the first application is ready to access the resource. Accordingly, the use of the initial status notification in step172, the transaction unique identifier, and the second push notification replaces the polling and request for status from the first application and/or browser in conventional systems.

At step179, the authentication service155or the distributed environment server115received the notification. In various embodiments, the authentication service155validates all credentials of the user comprising, consisting, or consisting essentially of the response to the push notification. In the instance where the credentials are valid (e.g., the push notification was accepted), the authentication server155allows for the browser132and/or application130to access the resource130on the distributed environment server115. In the instance where the credentials are not valid (e.g., the push notification was denied), the authentication server155denies access of the browser132and/or application130to the resource130on the distributed environment server115.

Push Notification Processes

The processes and/or operations depicted by inFIG. 2may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors cores), hardware, or combinations thereof. The software may be stored in a memory (e.g., on a memory device, on a non-transitory computer-readable storage medium). The particular series of processing steps inFIG. 2is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, in alternative embodiments the steps outlined above may be performed in a different order. Moreover, the individual steps illustrated inFIG. 2may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

FIG. 2shows a flowchart200that illustrates a process for push notification authentication according to various embodiments. In some embodiments, the processes depicted in flowchart200may be implemented by the system ofFIG. 1Aand framework ofFIG. 1B. At step205, an authorization request is received at a server (e.g., the resource or distributed environment server115as described with respect toFIG. 1A) for a first application (e.g., a web application) to access a resource. At step210, a determination is made by the server as to whether the user of the first application has registered the second application for push notification authentication. When the user has registered the second application for push notification authentication, the server sends an initial notification on the status of the authorization request and a transaction unique identifier to the first application. In some embodiments, the initial notification informs the first application that the authorization request requires the push notification authentication and wait for either: (i) receipt of the second push notification, or (ii) a time-out period to have expired. When the user has not registered the second application for push notification authentication, the server sends a notification to the first application letting the user know that they must first register a second application for push notification authentication.

At step215, a first push notification is sent by the server to a second application (e.g., an authentication application). The first push notification requests authentication of a user of the first application. In some embodiments, the first application is on a first client device and the second application is on a second client device, and the first client device and the second client device are different devices. For example, the first client device may be a laptop or desktop computing device being used by the user to access the resource, and the second client device may be a mobile device registered by the user for second factor authentication such as push notifications. In other embodiments, the first application and the second application are on a same client device. In various embodiments, prior to sending the first push notification, the server composes a message for the first push notification. The message requests confirmation of an identity of the user. Additionally, the server may prepare notification data for the first push notification. The notification data includes a unique identifier for the second application and contents for a call back to the first application, and the contents for the call back include the transaction unique identifier. The server generates the first push notification using at least the message and the notification data. In some embodiments, the sending the first push notification comprises sending the first push notification to a push notification service via an application program interface, and the server is registered with the push notification service.

At step220, information indicating a response to the first push notification is received at the server from the second application. In some embodiments, the response to the first push notification confirms the identity of the user, and the response to the first push notification is signed with a digital signature. At step225, a second push notification is sent by the server to the first application. The second push notification includes a status of the authorization request based on the response to the first push notification. In various embodiments, prior to sending the second push notification, the server composes a message for the second push notification. The message includes the status of the authorization request based on the response to the first push notification. Additionally, the server may prepare notification data for the second push notification. The notification data includes a unique identifier for the first application and the transaction unique identifier. The server generates the second push notification using at least the message and the notification data. In some embodiments, the sending the second push notification comprises sending the second push notification to the push notification service via the application program interface, and the server is registered with the push notification service.

At step230, information indicating an outcome of the authentication request is received at the server. The outcome is based at least on the response to the first push notification. In some embodiments, the outcome of the authentication request is a validation of credentials of the user, and the credentials include at least the response to the first push notification. At step235, the first application is provided access to the resource by the server.

The processes and/or operations depicted by inFIG. 3may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors cores), hardware, or combinations thereof. The software may be stored in a memory (e.g., on a memory device, on a non-transitory computer-readable storage medium). The particular series of processing steps inFIG. 3is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, in alternative embodiments the steps outlined above may be performed in a different order. Moreover, the individual steps illustrated inFIG. 3may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

FIG. 3shows a flowchart300that illustrates a process provisioning and utilizing an access management system for push notification authentication within a distributed environment according to various embodiments. In some embodiments, the processes depicted in flowchart300may be implemented by the system ofFIG. 1Aand framework ofFIG. 1B. At step302, a first application (e.g., a web application) may be registered with a push notification service to receive push notifications for authentication on the access management system. In some embodiments, the user registers the first application with the push notification service. In other embodiments, the first application registers itself with the push notification service. The registration process includes providing the push notification service with a unique identifier for the first application and/or a client device running the first application. At step303, the second application (e.g., an authentication application) may be registered with the push notification service to receive push notifications for authentication on the access management system. In some embodiments, the user registers the second application with the push notification service. In other embodiments, the second application registers itself with the push notification service. The registration process includes providing the push notification service with a unique identifier for the second application and/or the client device running the second application. At step305, the push notification service may register the first application and the second application. In some embodiments, the registration includes storing the unique identifiers for the first applications, the second application, associated client device(s), and/or information on how to contact the client device(s) such as an IP address. In certain embodiments, the push notification service shares the unique identifiers for the first applications, the second application, and/or associated client device(s) with a resource server (e.g., a distributed environment server), which has a publisher for providing push notifications to the first application and the second application.

At step310, a user may operate the first application on the client device to request access to a resource controlled by the resource server. At step312, the request may be routed to or intercepted by a security agent, which controls access to resource, and the security agent will query the access manager server to determine if the requested resource is protected. At step315, the access manager server checks relevant authentication policies for the resource to determine whether authentication is required for access to the resource. If the requested resource is protected and requires authentication for use, the access manager server may determine whether any session exists for the user. Upon determining that no session has been established for the user, the user may be forwarded by the access manager server to a login service (e.g., authentication service) of the identity management system. At step320, the authentication service may request authentication credentials (e.g., user name/password, accept or decline a push notification, or the like) from the user. At step322, the resource server may determine that a push notification is required for the authentication credentials.

At step325, the resource server may determine whether the user has registered an authentication application and/or client device with the access management system or the resource server for push notification authentication. In the instance that the user has registered, then at step330the resource server replies to the browser or the first application with a notification on the status of the request for access and a transaction unique identifier (ID). In the instance that the user has not registered, then the resource server replies to the browser or the first application with a request to register an authentication application and/or client device with the access management system for push notification authentication (as described with respect to steps302-305). At step332, the first application receives the notification. The notification allows for the first application to know it should wait for either (i) receipt of a second push notification (a status message) concerning whether a first push notification (the authentication message) has been accepted or denied via the second application, or (ii) a time-out period to have expired. The transaction unique identifier allows the access management system to uniquely identify this transaction or request for access from the client to the resource.

At step335, the notification publisher of the resource server may compose a message for the first push notification based on the authentication policy for the requested resource and prepares notification data to be sent with the message. In some embodiments, the message is composed as a notification that a user is trying to access a resource and the server needs confirmation that the user is who they say they are; thus, prompting the user to accept or deny confirmation. In other embodiments, the message is a code or question prompted by the user trying to access a resource and the server needs the user to respond with the code or answer to confirm that the user is who they say they are; thus, prompting the user to provide the code or answer. In various embodiments, the notification data includes the unique identifiers for the second application and/or the client device running the second application and contents for a call back to the first application. The contents for the call back may include the unique identifiers for the first application and/or the client device and the transaction unique identifier. Thereafter, the notification publisher sends the first push notification (message and notification data) to the push notification service.

At step340, the push notification service may receive the first push notification from the publisher, unpacks the notification data from the first push notification, and utilizes the unique identifiers for the second application and/or the client device or another client device to look up registration data for the client device or another client device. In some embodiments, the push notification service forwards the first push notification to the second application based on the unique identifiers for the second application and/or the client device or another client device. At step345, the second application receives the first push notification, and parses the first push notification to obtain the notification data and the message. At step350, the user may reply to the first push notification. In some embodiments, the user uses the second application to prepare or compose the reply manually through a message composer user interface. In its simplest form, the reply by the user may be acceptance or denial that the user did generate the request for access to resource on the first application. In more complex forms, the reply may include a code embedded in the message or an answer to a question within the message that confirms the user did generate the request for access to resource on the first application. In certain embodiments, the reply includes the contents for the call back, for example, the unique identifiers for the first application and/or the client device and the transaction unique identifier.

At step355, the resource server may receive the reply to the first push notification. At step360, the resource server may forward the reply to the authentication service for processing (e.g., validation of the credentials). At step362, the authentication service may authenticate the user upon receiving the proper authentication credentials by validating the credentials against those stored in a user directory or identity store. At step365, based on receiving the proper authentication credentials for the user, the access manager server may forward the user back to the security agent with credential validation. At step370, the resource server prepares a second push notification for the browser or first application. In some embodiments, the notification publisher composes a message for the second push notification based on the reply and notification data received from the second application, and prepares notification data to be sent with the message to the push notification service. In some embodiments, the message is the status of the first push notification (e.g., accepted or denied) such that the first application is aware of the status of the request for access to the resource. In certain embodiments, the notification data includes the unique identifiers for the first application and/or the client device and the transaction unique identifier. Thereafter, the notification publisher sends the second push notification (message and notification data) to the push notification service.

At step375, the push notification service may receive the second push notification from the publisher, unpacks the notification data from the second push notification, and utilizes the unique identifiers for the first application and/or the client device to look up registration data for the client device or another client device. In some embodiments, the push notification service forwards the second push notification to the first application based on the unique identifiers for the first application and/or the client device. At step380, the first application receives the second push notification, and parses the second push notification to obtain the notification data and the message. The notification data lets the first application know which request the second push notification is referring to via the transaction unique identifier and the message tells the first application the status of the request for access to the resource. Thereafter, the first application sends a notification to the authentication service or the resource server to indicate the status of the request for access to the resource has been received and the first application is ready to access the resource. Accordingly, the use of the initial status notification, the transaction unique identifier, and the second push notification replaces the polling and request for status from the first application and/or browser in conventional systems.

At step382, the security agent may check the authentication, and at step385, establish a first session for user upon authentication of the user. As a result, the user is logged into the resource server for the session. Once logged in at step390, the user may access the resource at and other resources to which the user is authorized to access, such as running different applications, accessing cloud storage, or the like. In some embodiments, once the user is logged into the resource server, the access manager server creates a cookie that tracks session activity for the user. The cookie may include a length of time that the user has been active on a session. The cookie may be stored as session activity data within the identity management system.

Illustrative Systems

FIG. 4depicts a simplified diagram of a distributed system400for implementing an embodiment. In the illustrated embodiment, distributed system400includes one or more client computing devices402,404,406, and408, which are configured to execute and operate a client application such as a web browser, proprietary client (e.g., Oracle Forms), or the like over one or more network(s)410. Server412may be communicatively coupled with remote client computing devices402,404,406, and408via network410.

In various embodiments, server412may be adapted to run one or more services or software applications such as services and applications that may manage session activity of SSO access in a distributed environment. In certain embodiments, server412may also provide other services or software applications can include non-virtual and virtual environments. In some embodiments, these services may be offered as web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices402,404,406, and/or408. Users operating client computing devices402,404,406, and/or408may in turn utilize one or more client applications to interact with server412to utilize the services provided by these components.

In the configuration depicted inFIG. 4, software components418,420and422of system400are shown as being implemented on server412. In other embodiments, one or more of the components of system400and/or the services provided by these components may also be implemented by one or more of the client computing devices402,404,406, and/or408. Users operating the client computing devices may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or combinations thereof. It should be appreciated that various different system configurations are possible, which may be different from distributed system400. The embodiment shown inFIG. 4is thus one example of a distributed system for implementing an embodiment system and is not intended to be limiting.

Client computing devices402,404,406, and/or408may include various types of computing systems. For example, a client computing device may include portable handheld devices (e.g., an iPhone®, cellular telephone, an iPad®, computing tablet, a personal digital assistant (PDA)) or wearable devices (e.g., a Google Glass® head mounted display), running software such as Microsoft Windows Mobile®, and/or a variety of mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, and the like. The devices may support various applications such as various Internet-related apps, e-mail, short message service (SMS) applications, and may use various other communication protocols. The client computing devices may also include general purpose personal computers including, by way of example, personal computers and/or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and/or Linux operating systems. The client computing devices can be workstation computers running any of a variety of commercially-available UNIX® or UNIX-like operating systems, including without limitation the variety of GNU/Linux operating systems, such as for example, Google Chrome OS. Client computing devices may also include electronic devices such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and/or a personal messaging device, capable of communicating over network(s)410.

Although distributed system400inFIG. 4is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, etc., may interact with server412.

Server412may be composed of one or more general purpose computers, specialized server computers (including, by way of example, PC (personal computer) servers, UNIX® servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. Server412can include one or more virtual machines running virtual operating systems, or other computing architectures involving virtualization. One or more flexible pools of logical storage devices can be virtualized to maintain virtual storage devices for the server. Virtual networks can be controlled by server412using software defined networking. In various embodiments, server412may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server412may correspond to a server for performing processing as described above according to an embodiment of the present disclosure.

Distributed system400may also include one or more databases414and416. These databases may provide a mechanism for storing information such as user profile information, authentication policies, authorization policies, authentication factors, and other information used in various embodiments described herein. Databases414and716may reside in a variety of locations. By way of example, one or more of databases414and416may reside on a non-transitory storage medium local to (and/or resident in) server412. Alternatively, databases414and416may be remote from server412and in communication with server412via a network-based or dedicated connection. In one set of embodiments, databases414and416may reside in a storage-area network (SAN). Similarly, any necessary files for performing the functions attributed to server412may be stored locally on server412and/or remotely, as appropriate. In one set of embodiments, databases414and416may include relational databases, such as databases provided by Oracle that are adapted to store, update, and retrieve data in response to SQL-formatted commands.

In some embodiments, a cloud environment may provide one or more services for managing session activity of SSO access in a distributed environment.FIG. 5is a simplified block diagram of one or more components of a system environment500in which services may be offered as cloud services, in accordance with an embodiment of the present disclosure. In the illustrated embodiment inFIG. 5, system environment500includes one or more client computing devices504,506, and508that may be used by users to interact with a cloud infrastructure system502that provides cloud services, including services for managing session activity of SSO access in a distributed environment. Cloud infrastructure system502may comprise one or more computers and/or servers that may include those described above for server412.

It should be appreciated that cloud infrastructure system502depicted inFIG. 5may have other components than those depicted. Further, the embodiment shown inFIG. 5is only one example of a cloud infrastructure system. In some other embodiments, cloud infrastructure system502may have more or fewer components than shown in the figure, may combine two or more components, or may have a different configuration or arrangement of components.

Client computing devices504,506, and508may be devices similar to those described above for client computing devices402,404,406, and408. Client computing devices504,506, and508may be configured to operate a client application such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application, which may be used by a user of the client computing device to interact with cloud infrastructure system502to use services provided by cloud infrastructure system502. Although exemplary system environment500is shown with three client computing devices, any number of client computing devices may be supported. Other devices such as devices with sensors, etc. may interact with cloud infrastructure system502.

Network(s)510may facilitate communications and exchange of data between client computing devices504,506, and508and cloud infrastructure system502. Each network may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including those described above for network(s)410.

In certain embodiments, services provided by cloud infrastructure system502may include a host of services that are made available to users of the cloud infrastructure system on demand. In addition to services related to managing session activity of SSO access, various other services may also be offered including without limitation online data storage and backup solutions, Web-based e-mail services, hosted office suites and document collaboration services, database processing, managed technical support services, and the like. Services provided by the cloud infrastructure system can dynamically scale to meet the needs of its users.

In certain embodiments, a specific instantiation of a service provided by cloud infrastructure system502may be referred to herein as a “service instance.” In general, any service made available to a user via a communication network, such as the Internet, from a cloud service provider's system is referred to as a “cloud service.” Typically, in a public cloud environment, servers and systems that make up the cloud service provider's system are different from the customer's own on-premises servers and systems. For example, a cloud service provider's system may host an application, and a user may, via a communication network such as the Internet, on demand, order and use the application.

Cloud infrastructure system502may also provide “big data” related computation and analysis services. The term “big data” is generally used to refer to extremely large data sets that can be stored and manipulated by analysts and researchers to visualize large amounts of data, detect trends, and/or otherwise interact with the data. This big data and related applications can be hosted and/or manipulated by an infrastructure system on many levels and at different scales. Tens, hundreds, or thousands of processors linked in parallel can act upon such data in order to present it or simulate external forces on the data or what it represents. These data sets can involve structured data, such as that organized in a database or otherwise according to a structured model, and/or unstructured data (e.g., emails, images, data blobs (binary large objects), web pages, complex event processing). By leveraging an ability of an embodiment to relatively quickly focus more (or fewer) computing resources upon an objective, the cloud infrastructure system may be better available to carry out tasks on large data sets based on demand from a business, government agency, research organization, private individual, group of like-minded individuals or organizations, or other entity.

In various embodiments, cloud infrastructure system502may be adapted to automatically provision, manage and track a customer's subscription to services offered by cloud infrastructure system502. Cloud infrastructure system502may provide the cloud services via different deployment models. For example, services may be provided under a public cloud model in which cloud infrastructure system502is owned by an organization selling cloud services (e.g., owned by Oracle Corporation) and the services are made available to the general public or different industry enterprises. As another example, services may be provided under a private cloud model in which cloud infrastructure system502is operated solely for a single organization and may provide services for one or more entities within the organization. The cloud services may also be provided under a community cloud model in which cloud infrastructure system502and the services provided by cloud infrastructure system502are shared by several organizations in a related community. The cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

In some embodiments, the services provided by cloud infrastructure system502may include one or more services provided under Software as a Service (SaaS) category, Platform as a Service (PaaS) category, Infrastructure as a Service (IaaS) category, or other categories of services including hybrid services. A customer, via a subscription order, may order one or more services provided by cloud infrastructure system502. Cloud infrastructure system502then performs processing to provide the services in the customer's subscription order.

In certain embodiments, cloud infrastructure system502may also include infrastructure resources530for providing the resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources530may include pre-integrated and optimized combinations of hardware, such as servers, storage, and networking resources to execute the services provided by the PaaS platform and the SaaS platform, and other resources.

In certain embodiments, a number of internal shared services532may be provided that are shared by different components or modules of cloud infrastructure system502to enable provision of services by cloud infrastructure system502. These internal shared services may include, without limitation, a security and identity service, an integration service, an enterprise repository service, an enterprise manager service, a virus scanning and white list service, a high availability, backup and recovery service, service for enabling cloud support, an email service, a notification service, a file transfer service, and the like.

In certain embodiments, cloud infrastructure system502may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functionality may include capabilities for provisioning, managing and tracking a customer's subscription received by cloud infrastructure system502, and the like.

In one embodiment, as depicted inFIG. 5, cloud management functionality may be provided by one or more modules, such as an order management module520, an order orchestration module522, an order provisioning module524, an order management and monitoring module526, and an identity management module528. These modules may include or be provided using one or more computers and/or servers, which may be general purpose computers, specialized server computers, server farms, server clusters, or any other appropriate arrangement and/or combination.

In an exemplary operation, at step534, a customer using a client device, such as client computing devices804,806or808, may interact with cloud infrastructure system502by requesting one or more services provided by cloud infrastructure system502and placing an order for a subscription for one or more services offered by cloud infrastructure system502. In certain embodiments, the customer may access a cloud User Interface (UI) such as cloud UI512, cloud UI514and/or cloud UI516and place a subscription order via these UIs. The order information received by cloud infrastructure system502in response to the customer placing an order may include information identifying the customer and one or more services offered by the cloud infrastructure system802that the customer intends to subscribe to.

At step536, the order information received from the customer may be stored in an order database518. If this is a new order, a new record may be created for the order. In one embodiment, order database518can be one of several databases operated by cloud infrastructure system518and operated in conjunction with other system elements.

At step538, the order information may be forwarded to an order management module520that may be configured to perform billing and accounting functions related to the order, such as verifying the order, and upon verification, booking the order.

At step540, information regarding the order may be communicated to an order orchestration module522that is configured to orchestrate the provisioning of services and resources for the order placed by the customer. In some instances, order orchestration module522may use the services of order provisioning module524for the provisioning. In certain embodiments, order orchestration module522enables the management of business processes associated with each order and applies business logic to determine whether an order should proceed to provisioning.

As shown in the embodiment depicted inFIG. 5, at step542, upon receiving an order for a new subscription, order orchestration module522sends a request to order provisioning module524to allocate resources and configure resources needed to fulfill the subscription order. Order provisioning module524enables the allocation of resources for the services ordered by the customer. Order provisioning module524provides a level of abstraction between the cloud services provided by cloud infrastructure system500and the physical implementation layer that is used to provision the resources for providing the requested services. This enables order orchestration module522to be isolated from implementation details, such as whether or not services and resources are actually provisioned on the fly or pre-provisioned and only allocated/assigned upon request.

At step544, once the services and resources are provisioned, a notification may be sent to the subscribing customers indicating that the requested service is now ready for use. In some instance, information (e.g. a link) may be sent to the customer that enables the customer to start using the requested services.

At step546, a customer's subscription order may be managed and tracked by an order management and monitoring module526. In some instances, order management and monitoring module526may be configured to collect usage statistics regarding a customer use of subscribed services. For example, statistics may be collected for the amount of storage used, the amount data transferred, the number of users, and the amount of system up time and system down time, and the like.

In certain embodiments, cloud infrastructure system500may include an identity management module528that is configured to provide identity services, such as access management and authorization services in cloud infrastructure system500. In some embodiments, identity management module528may control information about customers who wish to utilize the services provided by cloud infrastructure system502. Such information can include information that authenticates the identities of such customers and information that describes which actions those customers are authorized to perform relative to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.) Identity management module528may also include the management of descriptive information about each customer and about how and by whom that descriptive information can be accessed and modified.

FIG. 6illustrates an exemplary computer system600that may be used to implement various embodiments described herein. In some embodiments, computer system600may be used to implement any of the various servers and computer systems described above. As shown inFIG. 6, computer system600includes various subsystems including a processing unit604that communicates with a number of peripheral subsystems via a bus subsystem602. These peripheral subsystems may include a processing acceleration unit606, an I/O subsystem608, a storage subsystem618and a communications subsystem624. Storage subsystem618may include tangible computer-readable storage media622and a system memory610.

Processing subsystem604controls the operation of computer system600and may comprise one or more processing units632,634, etc. A processing unit may include be one or more processors, including single core or multicore processors, one or more cores of processors, or combinations thereof. In some embodiments, processing subsystem604can include one or more special purpose co-processors such as graphics processors, digital signal processors (DSPs), or the like. In some embodiments, some or all of the processing units of processing subsystem604can be implemented using customized circuits, such as application specific integrated circuits (ASICs), or field programmable gate arrays (FPGAs).

In some embodiments, the processing units in processing subsystem604can execute instructions stored in system memory610or on computer readable storage media622. In various embodiments, the processing units can execute a variety of programs or code instructions and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in system memory610and/or on computer-readable storage media622including potentially on one or more storage devices. Through suitable programming, processing subsystem604can provide various functionalities described above for managing session activity of SSO access in a distributed environment.

In certain embodiments, a processing acceleration unit606may be provided for performing customized processing or for off-loading some of the processing performed by processing subsystem604so as to accelerate the overall processing performed by computer system600.

Storage subsystem618provides a repository or data store for storing information that is used by computer system600. Storage subsystem618provides a tangible non-transitory computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that when executed by processing subsystem604provide the functionality described above may be stored in storage subsystem618. The software may be executed by one or more processing units of processing subsystem604. Storage subsystem618may also provide a repository for storing data used.

Storage subsystem618may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. As shown inFIG. 6, storage subsystem618includes a system memory610and a computer-readable storage media622. System memory610may include a number of memories including a volatile main random access memory (RAM) for storage of instructions and data during program execution and a non-volatile read only memory (ROM) or flash memory in which fixed instructions are stored. In some implementations, a basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer system600, such as during start-up, may typically be stored in the ROM. The RAM typically contains data and/or program modules that are presently being operated and executed by processing subsystem604. In some implementations, system memory610may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

By way of example, and not limitation, as depicted inFIG. 6, system memory610may store application programs612, which may include client applications, Web browsers, mid-tier applications, relational database management systems (RDBMS), etc., program data614, and an operating system616. By way of example, operating system616may include various versions of Microsoft Windows®, Apple Macintosh®, and/or Linux operating systems, a variety of commercially-available UNIX® or UNIX-like operating systems (including without limitation the variety of GNU/Linux operating systems, the Google Chrome® OS, and the like) and/or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

In certain embodiments, storage subsystem600may also include a computer-readable storage media reader620that can further be connected to computer-readable storage media622. Together and, optionally, in combination with system memory610, computer-readable storage media622may comprehensively represent remote, local, fixed, and/or removable storage devices plus storage media for storing computer-readable information.

In certain embodiments, computer system600may provide support for executing one or more virtual machines. Computer system600may execute a program such as a hypervisor for facilitating the configuring and managing of the virtual machines. Each virtual machine may be allocated memory, compute (e.g., processors, cores), I/O, and networking resources. Each virtual machine typically runs its own operating system, which may be the same as or different from the operating systems executed by other virtual machines executed by computer system600. Accordingly, multiple operating systems may potentially be run concurrently by computer system600. Each virtual machine generally runs independently of the other virtual machines.

Communications subsystem624provides an interface to other computer systems and networks. Communications subsystem624serves as an interface for receiving data from and transmitting data to other systems from computer system600. For example, communications subsystem624may enable computer system600to establish a communication channel to one or more client computing devices via the Internet for receiving and sending information from and to the client computing devices.

Communication subsystem624may support both wired and/or wireless communication protocols. For example, in certain embodiments, communications subsystem624may include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3G, 4G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem624can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

Communication subsystem624can receive and transmit data in various forms. For example, in some embodiments, communications subsystem624may receive input communication in the form of structured and/or unstructured data feeds626, event streams628, event updates630, and the like. For example, communications subsystem624may be configured to receive (or send) data feeds626in real-time from users of social media networks and/or other communication services such as Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and/or real-time updates from one or more third party information sources.

Communications subsystem624may also be configured to output the structured and/or unstructured data feeds626, event streams628, event updates630, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system600.

Due to the ever-changing nature of computers and networks, the description of computer system600depicted inFIG. 6is intended only as a specific example. Many other configurations having more or fewer components than the system depicted inFIG. 6are possible. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.

Although specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the invention. The modifications include any relevant combination of the disclosed features. The embodiments described herein are not restricted to operation within certain specific data processing environments, but are free to operate within a plurality of data processing environments. Additionally, although certain embodiments have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of such embodiments is not limited to the described series of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly.