Managing session access across multiple data centers

The disclosure relates to techniques for enforcing a limit on single sign-on (SSO) sessions for users across multiple data centers in a multi data center deployment. Users may request access to resources that are governed by an access manager deployed across multiple data centers, with each data center being associated with its own identifier. Each user may be associated with an identity attribute preserved in identity stores across the multiple data centers. The prerequisite for session creation at a data center may be to update the identity attribute of the user to that data center's identifier. If the identity attribute can be updated successfully, the access manager can create a new SSO session at that data center. Updates to the identity attribute may be synchronized across all of the data centers, with each data center aware of any existing sessions based on the current value of the identity attribute.

BACKGROUND

Generally, the present application relates to data processing. More specifically, the application is related to techniques for enforcing a global, single session limit for a user across multiple data centers in different locations.

Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application.

Earlier, less-sophisticated applications incorporated access management logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions. Furthermore, when a user is authenticated by one of these applications (e.g., a first application), this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control.

To remedy this, authentication and access control can be more efficiently implemented and managed as a shared resource, known as an access management system. Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to a client (e.g., client application at a device) of the requestor. This token is like a key that can be used to open a door that guards restricted data (e.g., a secure resource).

For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser at a client generates a request to access the database, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser at the client receives a token that may be used to access the human resources application.

In an enterprise, users typically may have access to one or more different systems and applications. Each of these systems and applications may utilize different access control policies and require different credentials (e.g., user names and passwords). A user wanting to access multiple resources protected by an access management system may need to be authenticated through user credentials provided to the access management system. A successful authentication gives the user authorization to access the protected resources, based on their assigned access privileges. Upon authentication of the user, the access management system may establish a session (“user session”) to provide the access granted to the protected resource(s). For a user session, the access management system may maintain session information at a computing system (e.g., server computer) for the user session. The session information maintained by access management system may be referred to as a server-side session. The access management system may store session information for the server-side session that defines the access granted to the user and the constraints of the session. The session information for a server-side session may be mapped to a client which is provided with a token.

If a user wants to access multiple resources protected by the access management system, the access management system may determine whether the user is authenticated to access the multiple resources requested by a user. In some instances, authentication of a user for one resource may suffice for accessing other resources, otherwise the access management system may request additional credentials from the user. In other instances, upon authentication to access multiple resources, the user may not need to re-authenticate to access additional resources. In such instances, the access management system may establish and maintain a single session for the user, such as a single sign-on session (SSO), that provides a user with access to multiple resources after authentication. In the instance where a SSO session is established, the access management system enforces access for the SSO based on the token.

In many cases, enterprise computer networks (e.g., for implementing the access management system) are spread over different data centers that are geographically collocated or dispersed, but belong to the same multi data center deployment. For redundancy and load balancing purposes, each of the data centers of the multiple data centers may be running an instance of the access management system, and a client's request may be handled by a single instance of the access management system being run on a data center (e.g., for instance, the geographically nearest data center to the client). Using single sign-on (SSO), a user can log into one data center and then access other data centers without logging in. For example, SSO allows a user to enter a username/password once in order to gain access to protected resources stored across the multiple data centers.

As a security requirement, many organizations restrict the maximum concurrent SSO sessions per user to one, which means at any given point in time a valid user can have only single SSO session. However, this policy may be difficult to enforce when the access management system is deployed across multiple data centers. In particular, each data center of the multiple data centers will be capable of servicing user access requests, and thus each data center may have the capability to create a SSO session for a user. If the appropriate care is not taken, this can result in the creation of multiple SSO sessions associated with a given user. For example, the user could submit an access request to one data center and be granted a SSO session by that data center, while at the same time the user could submit another access request to another data center and receive a second SSO session.

One way of implementing max session enforcement is by restricting the user's authentication requests to a single data center based on geographic affinity. For example, if the user is located in California and sends an access request to to a local data center, that data center can ignore other access requests coming from California that are associated with the user. However, users can bypass restrictions based on geographic affinity by accessing the protected resources from devices across multiple geography, or a set of malicious users can access the resources from multiple geographic locations by sharing the same valid user ID. For example, one person could create a SSO session at a first data center using a set of user credentials, while at the same time, another person could create another SSO session at a different data center using the same set of user credentials. The resulting single session contract violation may cause security threats for any downstream applications which depend on the access manager for enforcing a single SSO session contract.

BRIEF SUMMARY

The present application relates to authentication. More specifically, the application is related to techniques for enforcing a maximum limit on single sign-on (SSO) sessions for each user across multiple data centers in a multi data center deployment. For example, a user may be restricted to one SSO session when accessing resources stored across multiple data centers in different locations, such that no other SSO sessions can be established for the user while the initial SSO session is active.

In some embodiments, there may be an access manager deployed across multiple data centers. In some embodiments, a limit on SSO sessions is enforced across the multiple data centers by having each data center store session information and security data associated with each user, and all of that data can be synchronized across the data centers. In some embodiments, each data center may store security data for each user that includes an identity attribute associated with each user. In particular, each user may be associated with their own identity attribute, ‘lockedBy’, which serves the role of a session lock across the multiple data centers by dictating whether an access request can be serviced to create a brand new SSO session.

In some embodiments, each data center of the multiple data centers may be associated with its own identifier (e.g., a data center identifier), such as a ClusterID. In some embodiments, these data center identifiers may be used as values for the ‘lockedBy’ identity attribute that is associated with each user and preserved in identity stores across the multiple data centers. The identity stores across the data centers may be in sync, with the specific ‘lockedBy’ attribute excluded from any replication rules associated with the identity stores, such that the original values for the ‘lockedBy’ attribute set by each data center will be preserved.

In some embodiments, the prerequisite for session creation at a data center may be to update the ‘lockedBy’ attribute of the user (preserved in the current data center's identity store) to the current data center's ClusterID in order to acquire the lock. If the lockedBy attribute in the identity store can be updated successfully to the current data center's ClusterID (e.g., the lockedBy attribute has no value or the value is already equivalent to the current data center's ClusterID), it means that the access manager can proceed to create a new SSO Session in that specific data center. In some embodiments, updating the ‘lockedBy’ attribute associated with a user may entail a synchronous call to all the participating data centers of the multiple data centers, such that the ‘lockedBy’ attribute for the user is updated at all of the identity stores with the current data center's ClusterID. However, in some cases the lockedBy attribute in the identity store will not be modifiable (e.g., it has a value that does not match the ClusterID of the current data center servicing the user's access request), which means that lock cannot be acquired and the session creation request will be rejected in order to enforce the single session per user constraint. Since the ‘lockedBy’ attribute for each user will be synchronized across the multiple data centers, the single session per user constraint is effectively evaluated across all of the data centers prior to the creation of any new SSO sessions.

As an example, a user may issue a first access request to a first data center of the multiple data centers. This access request is evaluated by the access manager and authenticated using the appropriate authentication scheme. Upon validating the user credentials from the access request, the access manager will check the identity store for the first data center to determine the ‘lockedBy’ attribute for the user. If the ‘lockedBy’ attribute is empty or equal to the ClusterID of the first data center, the ‘lockedBy’ attribute for the user will be updated with the ClusterID of the first data center and the access manager will create a new SSO session for the user at the first data center. In some embodiments, the ‘lockedBy’ attribute for the user will be updated with the ClusterID of the first data center prior to the creation of a SSO session for the user at the first data center. In other embodiments, the SSO session for the user at the first data center will be created prior to (or at the same time as) the ‘lockedBy’ attribute for the user being updated with the ClusterID of the first data center. As part of the synchronization process, the updated ‘lockedBy’ attribute for the user will be pushed out to other data centers in the multi data center deployment in order to update all of the identity stores.

Continuing the example, assume that at a later time, a second user issues a second access request to a second data center of the multiple data centers. However, this second access request involves the user credentials for the original user (e.g., that were used in the first access request). Upon validating the user credentials from this second access request, the access manager will check the identity store for the second data center to determine the ‘lockedBy’ attribute associated with the original user (since the original user's credentials were used). If the original user has an existing SSO session (e.g., established at the first data center), then the ‘lockedBy’ attribute at the identity store of the second data center will be equal to the ClusterID of the first data center. This means that the lock cannot be acquired and the second user's access request will be rejected in order to enforce the single session per user constraint. As a result, the single max session policy is enforced across the multiple data centers and geographic affinity violations are avoided (e.g., the second user is unable to start another session even if the second user is geographically located far away from the original user and using a different data center).

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments of the disclosure. However, it will be apparent that various embodiments may be practiced without these specific details. For example, circuits, systems, algorithms, structures, techniques, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. The figures and description are not intended to be restrictive.

The term “machine-readable medium” includes, but is not limited to, portable or non-portable storage devices, optical storage devices, wireless channels, and various other mediums capable of storing, containing or carrying instruction(s) and/or data. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

Enterprise computer networks may be used to meet the computing needs of one or more organizations, such as businesses, universities, government organizations, or the like. The enterprise computer network infrastructure may be spread over different data centers that may be dispersed over different geographic locations. Various resources included within an enterprise computer network may be managed and/or stored by the different data centers. For example, a first resource may be stored and managed by a first data center and a second resource may be stored and managed by a second data center. Resources may include any item managed and/or stored by the data centers and available for access by one or more users, such as an application, a document, a file, and/or the like. A user may have to be authenticated and authorized by the first data center in order to access the first resource and may have to be authenticated and authorized by the second data center in order to access the second resource. The enterprise computer network may offer a single sign-on (SSO) functionality that allows a user to log into one data center and then access other data centers using the same authentication session without re-logging in each time a different data center is accessed. For example, SSO allows a user to enter a username/password once in order to gain access to multiple resources located across different data centers.

A single SSO session may be created for a user at a data center when the user is authenticated and/or authorized by the data center. The user's sessions are coordinated among the various data centers as the user accesses different resources dispersed among the data centers. A unique session identifier (ID) may be created for each session for each user. For example, a user may have access to two different resources stored and/or managed in two different data centers. Thus, a first data center may create a session at the first data center for a user with a unique session ID (e.g., session ID1), and the second data center may adopt that session (e.g., by creating a session at the second data center for the user with the same session ID1). Thus, even though there are ‘separate’ sessions created for the user in each of the data centers, each of those sessions may belong to the same, single SSO session that is tracked using the unique session ID. A user request for one or more resources may hop across data centers within a single SSO session, and each data center may generate a session with the same unique session identifier for servicing the user request.

All sessions for the user should be synchronized so that all of the session information is consistent across the data centers. Further, when the user is logged out of a session at one data center and/or a session for the user at the data center is terminated, all other sessions should be terminated as well so that the user's sessions are logged out or terminated globally.

In some embodiments, a user may be limited to a certain number of SSO sessions (not to be confused with the individual sessions established at each data center). For instance, a user may be limited to a single SSO session, that when established, creates a separate session for the user at each of the data centers that the user can hop between. Thus, another person (e.g., looking to pass off as the user) may not be able to establish another SSO session for the user if the user has already established a SSO session. In order to maintain a limited number of SSO sessions, each data center must be aware of the existing SSO sessions for a user and the SSO session limit for that user, otherwise the other person may easily be able to establish an additional SSO session at a different data center than the data center the user has a SSO session with. Thus, in some embodiments, each data center may store security data associated with each user, which can include a “lockedBy” identity attribute for that user. The “lockedBy” attribute may be set to have a value of an identifier of a data center at which the current SSO session has been established for the user. This security data can be shared and synchronized between the data centers, so that each data center can determine whether an active SSO session exists for any particular user (along with information about which data centers) in order to enforce SSO session limits for the user (e.g., by preventing the creation of another SSO session).

A web gate may provide employee access control and may operate to protect the data center and any resources within the data center against external and internal web-based threats.

For example, a web gate may include an agent component and a server side component. Each resource is protected through an agent of the web gate. Each agent may be associated with a particular data center with which the resource is stored and/or managed. The associated data center for an agent may be referred to as the web gate agent's end point. The web gate agent may intercept user requests for one or more resources protected by it and check for user credentials in order to authenticate the user. The agent may then contact an access manager server to verify whether the resource is a protected resource that requires credentials for access. If the access manager indicates that the resource is not protected, the agent will grant access to the user. If the resource is protected, the agent will challenge the user for credentials.

An access manager server enables SSO functionality within the data center and may perform various session related functions for managing access to the corresponding data center. For example, the access manager server may perform authentication and/or authorization of the client device when a user attempts to access one or more resources within the data center. Authentication is the process of proving that a user is who the user claims to be. To authenticate a user, the access manager server (e.g., using a web gate) may present a user with a request for authentication credentials in the form of a challenge (e.g., via the user's web browser). Authentication policies may specify the authentication methodology 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).

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.

An access manager server may receive and analyze cookies from client devices and/or session information from one or more data centers. An access manager may also manage session policies, which may include policies relating to re-authentication, session invalidation, and/or session retrievals. As used herein, “re-authentication” refers to a situation in which a user must re-enter credentials in order to be authenticated anew. “Session invalidation” may refer to the invalidation of sessions that may exist for a user in data centers other than the data center with which the user is currently interacting. In some embodiments, invalidation of a user session may include terminating the remote user session through a front-channel or back-channel operation. For example, front-channel communications may use a hypertext transfer protocol secure (HTTPS) protocol while a back-channel operation communication may use an open access protocol (OAP), or vice versa. In some embodiments, only back-channel invalidation of a user session are supported. As used herein, “session retrieval” or “on-demand session retrieval” may refer to the retrieval of session information from a remote data center before the creation of a local user session in a servicing data center. Session retrieval may be needed to ensure that dynamic session information is not lost when a user moves across data centers. Session retrieval may also ensure timeout information is tracked consistently across data centers so that a user is properly timed-out of a session when appropriate. Retrieval of session information may be done using a front-channel or back-channel operation.

In some embodiments, multiple access manager servers can be deployed as an access manager cluster in a data center, which allows for scalability and high availability. Multiple such geographically dispersed data centers with access manager clusters can be connected (wired or wirelessly) to constitute an access manager Multi Data Center (MDC) deployment. An access manager MDC satisfies high availability, load distribution, and disaster recovery requirements of access servers within an enterprise computer network. The MDC may act as a single logical access server and provides single sign on (SSO) functionality for all of the resources registered in the MDC. In order to achieve SSO across the data centers, back end user sessions need to be migrated from the originating data center to the data center that is servicing the user. However, synchronization of the databases among the data centers may not be practical due to latencies involved in transmitting data between the geographically dispersed databases. Accordingly, migration of user sessions may be accomplished using on demand session migration or session retrieval from each data center.

In the MDC deployment, data centers can be geographically located around the world (e.g., one on each continent). A user request to access a resource can hop across multiple data centers. The user request may be received by a web gate agent or load balancer, which will direct the user's request to the appropriate data center (e.g., to the nearest data center or to a data center that will load balance the requests across different data centers). The request may be handled by one of the data centers (e.g., a first data center), and in some cases, once a session for the user is established at that data center that session may also be adopted by the other data centers (e.g., a second data center). For example, the first data center will create for the user a session with a unique session identifier. If the user is sending a request to another data center (e.g., the second data center) through the same application or browser used to establish the session, then the user may provide the second data center a cookie/token that was received from the first data center. The second data center may read the cookie/token data and extract the server side session information, which can include session identifier information and other details. For instance, the second data center may determine from the information that the session was originally initiated by the first data center. In order to provide SSO, the second data center may adopt that session (e.g., by creating a session at the second data center) while preserving the same session identifier, allowing the user to access resources (e.g., resources governed by the second data center). It should be noted that this session adoption by the second data center only applies if the request is coming from the same application or browser associated with the established session.

In some cases, the user may be restricted to a maximum of one SSO session across the data centers (e.g., based on policies set by an organization associated with the user). Each of the data centers may be configured to enforce the maximum session limit locally (e.g., each data center will make sure that there is only one active session for the user at that data center). However, there may be issues associated with enforcing the maximum of one concurrent SSO session across the data centers and syncronizing the enforcement. Failure to do so can lead to a scenario, in which a first access request will go to a first data center while a second access request goes to a second data center (e.g., due to load balancing or geographical affinity). If the data centers do not communicate and coordinate with each other, then the second data center (which only has local session management) will not be able to coordinate the enforcement of a single SSO session across the data centers. The second data center may end up establishing a second SSO session (e.g., having a different unique session ID) for a user, which is a result that can be maliciously exploited (e.g., a malicious user can bypass the load balancer and use stolen user credentials for a valid user to be awarded with a session). Thus, to prevent this from happening, the data centers have to coordinate and synchronize enforcement of the maximum session limit across all of the data centers.

Accordingly, the present disclosure relates generally to maintaining and enforcing a maximum single sign-on (SSO) session limit across multiple data centers of a multi data center (MDC) deployment. In some cases, a user with a SSO session may be able to access one or more resources governed by the data centers, which may include any item managed and/or stored by a computing system, such as an application, a document, a file, electronic content, and/or the like. In some cases, a resource may be identified by a uniform resource locator (URL) or other data indicating a source of the resource.

In some embodiments, the enforcement of a maximum SSO session limit across multiple data centers is performed through the use of a centralized data store (e.g., an identity store or identity data store) accessed by the data centers. The centralized data store may contain the identity attributes associated with each user, including the ‘lockedBy’ attribute for each user, which may provide the data center identifier for any data center that has established an ongoing SSO session for the user. However, in other embodiments, the enforcement of a maximum session limit across multiple data centers is preferably performed through the use of a data store (e.g., an identity store or identity data store) at each of the data centers. The use of multiple data stores across the data centers may be preferable for high availability and disaster recovery (HA/DR), since each data center would have all the information it needs locally. In some embodiments, the enforcement of a maximum session limit across multiple data centers is performed through the use of multiple centralized data stores accessed by the data centers, which may provide for HA/DR. For example, there may be two centralized data stores that are in sync and maintained separately from the multiple data centers, which contain the identity attributes associated with each user.

In some embodiments, each data center would store user identities in a data store (which can be outside of the access management system). Each data store may store the identity of any given user, along with security data associated with that user. In some embodiments, the security data for a user may be a term that is used interchangeably with the identity of the user. In some embodiments, the security data may include any identity attributes associated with the user. In some embodiments, each user may be associated with the identity attribute, ‘lockedBy’, which serves the role of a session lock across the multiple data centers by dictating whether an access request can be serviced to create a brand new SSO session.

In some embodiments, there may be an access manager deployed across multiple data centers. Each data center of the multiple data centers may be associated with its own identifier, such as a ClusterID. Each user may be associated with their own identity attribute, ‘lockedBy’, that is preserved in the identity stores across each the multiple data centers. The identity stores across the data centers may be in sync, with the specific ‘lockedBy’ attribute excluded from any replication rules associated with the identity stores, such that the original values for the ‘lockedBy’ attribute set by each data center will be preserved. The synchronization between different identity stores of the data centers may depend on the configuration, but it may be performed quickly (e.g., in the order of minutes) in order to keep the identity stores identical.

In some embodiments, once a change to the ‘lockedBy’ attribute is made at one identity store, the access management system of that data center may propagate and push the change out to the other data centers. In some embodiments, this may be performed by the data center executing a synchronous call to the other data centers. In some embodiments, an access management system of a data center may, during the evaluation of session creation, pull values for the ‘lockedBy’ attribute from the identity store of other data centers in order to determine changes. The time needed for an access management system to check each identity store may result in a few milliseconds of delay, which may be a desirable tradeoff versus a central database, which provides no redundancies for disaster recovery.

In some embodiments, the prerequisite for session creation at a data center may be to update the ‘lockedBy’ attribute of the user (preserved in that data center's identity store) to the current data center's ClusterID in order to acquire the lock. If the lockedBy attribute in the identity store can be updated successfully to the current data center's ClusterID (e.g., it has no value or the value is equivalent to the current data center's ClusterID), it means that the access manager can proceed to create a new SSO Session in that specific data center. In some embodiments, updating the ‘lockedBy’ attribute associated with a user may entail a synchronous call to all the participating data centers of the multiple data centers, such that the ‘lockedBy’ attribute for the user is updated at all of the identity stores with the current data center's ClusterID. However, in some cases the lockedBy attribute in the identity store will not be modifiable (e.g., it has a value that does not match the ClusterID of the current data center servicing the user's access request), which means that lock cannot be acquired and the session creation request will be rejected in order to enforce the single session per user constraint. Since the ‘lockedBy’ attribute for each user will be synched across the multiple data centers, the single session per user constraint is effectively evaluated across all of the data centers prior to the creation of any new SSO sessions.

As an example, a user may issue a first access request to a first data center of the multiple data centers. This access request is evaluated by the access manager and authenticated using the appropriate authentication scheme. Upon validating the user credentials from the access request, the access manager will check the identity store for the first data center (and in some embodiments, all the other data centers) to determine the ‘lockedBy’ attribute for the user. If the ‘lockedBy’ attribute is empty or equal to the ClusterID of the first data center, the access manager will determine there is no active session for the user and will create a new SSO session for the user at the first data center. At the same time, the ‘lockedBy’ attribute for the user will be updated with the ClusterID of the first data center. This new value for the ‘lockedBy’ attribute will be pushed out to the other data centers. For instance, the ‘lockedBy’ attribute for the user at the identity store for a second data center will be updated with the ClusterID of the first data center. If, at a later time, a second access request is sent to the second data center with the user credentials for the original user (e.g., that were used in the first access request), and the access manager will check the identity store for the second data center to determine the ‘lockedBy’ attribute associated with the original user (since the original user's credentials were used).

If the original user has an existing SSO session (e.g., at the first data center), then the ‘lockedBy’ attribute at the identity store of the second data center will be equal to the ClusterID of the first data center. Since the ‘lockedBy’ attribute is not equal to the identifier of the current data center, this means that the lock cannot be acquired and the second access request will be rejected by the second data center in order to enforce the single session per user constraint.

Some embodiments, such as systems, methods, and machine-readable media are disclosed for enforcing single sign-on (SSO) limits.FIG. 1illustrates a system100in which users may be restricted to one single sign-on (SSO) session while accessing resources stored across multiple data centers, thereby maintaining the security of those resources by enforcing a single SSO session for each user across the multiple data centers that cannot be bypassed through the use of multiple clients (e.g., applications and devices).

More specifically,FIG. 1illustrates a system100in which a user (e.g., user102) may operate one or more clients (e.g., an application on a device or a device) to access an enterprise computer network with infrastructure distributed across various geographically dispersed data centers, such as the data centers135and180. The device may be any workstation, personal computer (PC), laptop computer, smart phone, wearable computer, or other networked electronic device. The data centers135and/or180may include applications, web gates, and one or more access manager servers, along with other infrastructure, such as identity stores, databases, or the like. A data center may provide a user access to various resources stored and/or managed by the data center cluster. For instance, the user102may utilize device114to interact with the data center135to gain access to a resource, such as one of the applications120. In some cases, the data center135would grant access only upon the user102being successfully authenticated and/or authorized to access the requested resource. This may involve checking user-supplied credentials against user IDs stored in an identity store (e.g., data store150). For instance, the user102may supply credentials that correspond to a user identity in the data store150.

For instance, the user102may operate a first client (e.g., device104or application106executing on device104) to request access to resources. In some embodiments, the resources may be accessible through the set of applications120accessible to the user based on authentication of credential information, or the resources may be accessible through the set of applications120. A user (e.g., the user103) may also operate a second client (e.g., device114or application116executing on device114). It should be noted that user102and user103may be the same user (e.g., the same person using two different devices) or user102may be a different user from user103(e.g., two different people using two different devices). Accordingly, any description herein in connection to user102may be applicable to either user102and/or user103shown inFIG. 1.

Each of device104and device114may include a computing device. The computing device may include a computing system such as one or more computers and/or servers (e.g., one or more access manager servers), which may be general purpose computers, specialized server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, distributed servers, or any other appropriate arrangement and/or combination thereof. Device104and device114may run any of operating systems or a variety of additional server applications and/or mid-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include without limitation those commercially available from Oracle, Microsoft, and the like. Devices104,114may be implemented using hardware, firmware, software, or combinations thereof.

Each of devices104,114may include at least one memory, one or more processing units (or processor(s)), and storage. The processing unit(s) may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. In some embodiments, access management system140may include several subsystems and/or modules. Devices104,114may be implemented to operate using in hardware, software (e.g., program code, instructions executable by a processor) executing on hardware, or combinations thereof. In some embodiments, the software may be stored in a memory (e.g., a non-transitory computer-readable medium), on a memory device, or some other physical memory and may be executed by one or more processing units (e.g., one or more processors, one or more processor cores, one or more GPUs, etc.). Computer-executable instructions or firmware implementations of the processing unit(s) may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various operations, functions, methods, and/or processes described herein. The memory may store program instructions that are loadable and executable on the processing unit(s), as well as data generated during the execution of these programs. The memory may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). The memory may be implemented using any type of persistent storage device, such as computer-readable storage media. In some embodiments, computer-readable storage media may be configured to protect a computer from an electronic communication containing malicious code. The computer-readable storage media may include instructions stored thereon, that when executed on a processor, perform the operations described herein.

A user102operating a client device, e.g., device104or device114, may present one or more interfaces that accept input to enable a user to interact with an access management system (e.g., access management system140or access management system170). The interfaces may be accessible using an application (e.g., application106or application116) executing on a device. The application and/or interfaces may be provided by access management system140or access management system170as part of a service. In some embodiments, which access management system the user102interacts with may depend on the geographic location of the client device and its proximity to a data center. For instance, as shown in the figure, the device114may be in proximity with the data center135implementing the access management system140, and thus the operation of the device114may result in the user102interacting with the access management system140. Similarly, device104may be in proximity with the data center180implementing the access management system170, and thus the operation of the device104may result in the user102interacting with the access management system170. However, other methods for determining which data center services a particular access request (e.g., such as based on data center load) may be employed.

The access management system140(and similarly, access management system170) may be implemented by a computing system. The computing system may include one or more computers and/or servers (e.g., one or more access manager servers), which may be general purpose computers, specialized server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, distributed servers, or any other appropriate arrangement and/or combination thereof. The access management system140may run any of operating systems or a variety of additional server applications and/or mid-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include without limitation those commercially available from Oracle, Microsoft, and the like. The access management system140may be implemented using hardware, firmware, software, or combinations thereof.

In some embodiments, both access management system140and access management system170may each be implemented by multiple computing devices (e.g., server computers) deployed as a cluster. Each of the server computers in the cluster may be a different computing node, which may communicate with one or more clients. Each computing node may handle authentication and authorization for session management. The cluster may be deployed as part of a data center, which allows for scalability and high availability. For instance, the access management system140may be implemented by the cluster of data center135, and the access management system170may be implemented by a cluster of data center180. Multiple geographically-dispersed data centers with access manager server clusters (e.g., data center135and data center180) can be connected (wired or wirelessly) to constitute a multi-data center (MDC) system. A MDC system may satisfy high availability, load distribution, and disaster recovery requirements of access servers within an enterprise computer network. A MDC system may act as a single logical access server to support SSO services for the access management system, including any instances of the access management system (e.g., access management system140and access management system170).

Access management system140(and similarly, access management system170) may include at least one memory, one or more processing units (or processor(s)), and storage. The processing unit(s) may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. In some embodiments, access management system140may include several subsystems and/or modules. For example, access management system140may include session engine142and authorization engine144, each of which may be implemented in hardware, software (e.g., program code, instructions executable by a processor) executing on hardware, or combinations thereof In some embodiments, the software may be stored in a memory (e.g., a non-transitory computer-readable medium), on a memory device, or some other physical memory and may be executed by one or more processing units (e.g., one or more processors, one or more processor cores, one or more GPUs, etc.). Computer-executable instructions or firmware implementations of the processing unit(s) may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various operations, functions, methods, and/or processes described herein. The memory may store program instructions that are loadable and executable on the processing unit(s), as well as data generated during the execution of these programs. The memory may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). The memory may be implemented using any type of persistent storage device, such as computer-readable storage media. In some embodiments, computer-readable storage media may be configured to protect a computer from an electronic communication containing malicious code. The computer-readable storage media may include instructions stored thereon, that when executed on a processor, perform the operations described herein.

As shown inFIG. 1, a user102using device114may engage in communication with access management system140to access resources, such as any application in the set of applications120or the resources accessible through the set of applications120. Similarly, a user102using device104is depicted as engaging in communication with access management system170to access resources, such as any application in the set of applications120or the resources accessible through the set of applications120. However, the embodiments disclosed herein are for illustrative purposes only. For instance, device114may be used to communicate with access management system170, and device104may be used to communicate with access management system140. In some embodiments, the device used by the user102may engage in communication with an access management system at a data center best equipped to handle the user's request (e.g., for load balancing purposes). In other embodiments, the device used by the user102may engage in communication with an access management system at a data center that is closest in geographic proximity to the device. For instance, when using device114, the user102may engage in communication with the access management system140rather than access management system170due to the geographical proximity between the device114and the data center135hosting the access management system140. As depicted in the figure, and for the purpose of facilitating understanding in the ensuing description, device114is used to communicate with the access management system140due to geographic proximity, whereas device104is used to communicate with the access management system170due to geographic proximity.

The set of applications120may be accessible to user102upon successful authentication of credential information for user102. Before one of applications120is accessible to user102at device114, user102may be authenticated for a session that provides user102with access to applications120. The device114may initiate an authentication process by requesting access from access management system140. The authentication process may include device114displaying one or more GUIs to receive credential information of a user and submitting a request for authentication to access management system140. Authentication may be established based on verifying credential information of the user102.

In attempting to access a resource through the device114, the user102may operate an application (e.g., application116) that manages access to a user's account via access management system140. For example, application116may be an access management application that may present GUIs. Using application116, user102may request access to one or more resources, engage in authentication, and request modification of an authentication level.

Device114may communicate with access management system140via communication network130. Examples of communication networks may include a mobile network, a wireless network, a cellular network, a local area network (LAN), a wide area network (WAN), other wireless communication networks, or combinations thereof.

Communications between device114and access management system140can be received through a gateway system. The gateway system may support access management services. For example, a single sign-on (SSO) gateway may implement one or more access agents, e.g., a web gate agent, to balance and/or handle requests from clients and access management system140.

In some embodiments, the authentication of a user (e.g., user102) and the authorization of the user to access specific resources may be managed by a web gate and/or one or more access management systems implemented at one or more data centers. For instance, a user may be authenticated and authorized by an access management system140implemented at a data center135, or a user may be authenticated and authorized by an access management system170implemented at a data center180. In some embodiments, the access management system170and the access management system140may both be instances of the same access management system that are implemented at different data centers; accordingly, any discussion of the access management system140may be applicable to the access management system170.

To perform the authentication and/or authorization, the access management system (e.g., access management system140) of a data center may present the user (e.g., user102) a request for authentication credentials (e.g., user name/password, or the like). In some embodiments, some resources within the data center135may not protected, in which case the access manager system140may first determine if the requested resource is protected. If a web gate is used, the web gate may forward the user credentials to the access manager system140. The access manager system140authenticates the user102upon receiving the proper credentials by validating the credentials against those stored in a user directory. As a result, the user102is logged into the data center135and a session is created for the user in the data center135. For the purposes of illustration, a “session” as described herein includes an SSO session. However, a session may include other types of sessions enabling access to a user. The access management system140and the access management system170may each provide access to one or more resources. The access management system140and the access management system170may both implement a single sign-on system, e.g., a SSO system, which can establish an SSO session to provide SSO access to one or more resources.

Once the user102is logged in to the session, the user102may access resources for which the user is authorized to access, such as running different applications, accessing cloud storage, or the like. The user102may communicate using the client device, which communicates with the data center using a particular protocol (e.g., hypertext transfer protocol (HTTP) or hypertext transfer protocol secure (HTTPS)). The protocol may be determined based on the type of resource. For example, an HTTPS request may be required to request sensitive or confidential resources.

In some embodiments, the access management system140may include a session engine142that further manages authentication of a user and the one or more sessions created to enable access for the user. Upon receiving the credential information, session engine142may verify whether a requested resource, e.g., one of the applications120, is a protected resource that requires credentials for access. Session engine142may request authorization engine144to determine whether access to a resource is protected. Upon determining that access determines that the resource is not protected, session engine142may grant access to a resource. Upon determining that access to a resource is protected, session engine142may determine authentication of user102based on the credential information.

The access management system140may also include an authorization engine144to determine authorization of a user to access particular resources. Upon determining authentication of user102, authorization engine144may determine whether user102is authorized to access a resource based on access permitted to user102. Session engine142may send a communication to device114to indicate whether access to a resource is permitted by user102. The requested resource may be enabled to user102based on whether access is permitted.

The access management system140may store session information for each session created to enable a user with access. Session information may include, without restriction, 1) authenticated user subject information such as user identity information (e.g., user identifier, user domain name, user group user identification (GUID), and group membership for user); 2) list of partners accessed in session; 3) Internet protocol (IP) address of a client; 4) authentication level; 5) authentication scheme; 6) authentication timestamp; and 7) application domain information for one or more resources that are accessed. In some embodiments, the access management system140may store the session information in a session data store160. Similarly, the access management system170may also store similar session information in a session data store172.

Resources (e.g., applications120) may be accessible to user102based on successful authentication of credential information. Resources may also include, without restriction, a file, a web page, a document, web content, a computing resource, or an application. For example, system100may include resources such as applications120and/or content accessible through those applications120. A resource may be requested and accessed using an application. For example, an application may request access to a web page from a resource server based on a URL identifying a requested resource. Resources may be provided by one or more computing systems, e.g., a resource computer server that provides access to one or more resources upon authentication of the user102in a SSO system. Although a user may be authenticated with access, each user may have different rights to access different resources. As such, authorization may be determined for each resource. Authorization may be determined for each resource server that provides a resource.

The access management system140may provide many SSO services including management of access (e.g., granting/denying access) to resources, automatic sign-on, application password change and reset, session management, application credential provisioning, as well as authentication of a session. In some embodiments, access management system140can provide automatic single sign-on functionality for applications120, such as Windows® applications, Web application, Java® applications, and mainframe/terminal-based applications running or being accessed from client devices.

In some embodiments, access management system140may use one or more policies stored in a data store162(“policies”) to control access to resources. Policies162may include an authentication policy that specifies the authentication methodology to be used for authenticating the user for whom the access must be provided on a given resource. Policies162may include an access policy that defines the way in which the resource access is to be protected (e.g., type of encryption, or the like). Policies162may include an authorization policy that specifies 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.

In some embodiments, policies162may include an authorization policy that specifies a maximum number of single sign-on (SSO) sessions permitted for a user across the multi-data center (MDC) system. For instance, there may be a policy that specifies that any particular user may only have a single SSO session across the MDC system (e.g., between the data center135and the data center180). Prior to establishing a SSO session for a user, the data center may check the authorization policy for the user against the number of existing SSO sessions for the user to determine if additional sessions can be established.

The access management system140may also include or be coupled to additional storage, which may be implemented using any type of persistent storage device, such as a memory storage device or other non-transitory computer-readable storage medium. In some embodiments, local storage may include or implement one or more databases (e.g., a document database, a relational database, or other type of database), one or more file stores, one or more file systems, or combinations thereof. For example, access management system140is coupled to, or includes, one or more data stores for storing data such as a data store150(in some embodiments, an “identity data store”), session data store160, and policies162. The memory and the additional storage are all examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.

Session engine142may handle processing to determine whether a valid session exists for user102to access a resource. Access management system140may store session data in session data store160. In some embodiments, any rarely-changing information (e.g., subject information) may be stored in session data store160. The subject information may be obtained from a data store150. Session information that changes frequently may be sent to a client device for storage and received in communication from the client device. Session engine142checks for a valid session for user102to access a requested resource that is protected. Session engine142may assess validity of a session for user102based on consideration of one or more access policies applicable to user102. Based on determining that a valid session does not exist for user102, session engine102may request credential information (which may be referred to as “credentials”) from user102. Successful authentication of the credential information may provide the user with access to one or more resources, which may include a requested resource.

Requests may be communicated to device114via communication network130. A request may prompt user102for user credentials to determine authentication of a session. Request may include information (e.g., a URL) to a web page or a user interface (e.g., a web page, portal, or dashboard) to receive credential information.

Session engine142may perform operations to authenticate credential information for user102. In some embodiments, session engine142may store information about sessions established upon successful authentication of a user. For a SSO session (e.g., SSO authenticated sessions), the SSO session may be managed as a SSO session enabling access to all resources accessible to user based upon successful authentication of credential information for a user.

In some embodiments, session engine142may communicate with authorization engine144regarding the scope of authentication. Session engine142can send the scope information received from device114to authorization engine144. Authorization engine144can determine resources that are protected and, based on authentication sessions, can determine resources that are permitted and/or restricted for a session.

In some embodiments, access management system140may be implemented in system100according to an agent-server model for communication between device114and any one of access manager servers implemented for access management system140. The agent-server model may include an agent component (e.g., a gateway system) and a server component. The agent component may be deployed on a host system and the server component may be deployed on a server, e.g., an access manager system. The user102operating device114may communicate with access management system140via the agent using an enterprise computer network. In some embodiments, the agent may be an application or embedded in an application on a device. The device may be a workstation, personal computer (PC), laptop computer, smart phone, wearable computer, or other networked electronic device.

The Agent may provide access control and may operate to protect access management system140and any resources accessible through access management system140against external and internal web-based threats. Access management system140may communicate with one or more resource computing systems (e.g., resource servers) that provide access to one or more resources, e.g., applications120. Agent may implement or operate as the agent component access management system140and may include a server that operates as the server component. Each resource accessible by access management system140may be protected through an agent, e.g., agent. Agent may intercept user requests for one or more resources protected by it and check for user credentials in order to authenticate the user. The agent may then contact a server, e.g., an access manager server at access management system140. The access management server may verify whether a resource is a protected resource that requires credentials for access. If the access management server determines that the resource is not protected, agent may grant access to user102. If the resource is protected, agent may request user102to provide authentication credentials.

In some embodiments, communication between the agent and access management system140may be split into two different channels of communication. For example, communication via a front-channel may use a hypertext transfer protocol secure (HTTPS) protocol. Front-channel communications may include less frequent communications, such as communications for credential collection operations for authentication. Communication via a back-channel may use an open access protocol (OAP). Back-channel communications may include more frequent communications, such as agent-server interactions including requests for access to a resource managed by access management system140. Each channel may communicate using an access token designed for the type of communication over the channel. The access flow may generate two types of browser tokens. A first token is an access management ID token (e.g., OAM_ID token), which serves the SSO requests that are being propagated over HTTP. A second token may be an authorization token (e.g., OAMAuthn Token) that may be used to service the SSO requests that are being propagated over OAP. The browser tokens may be stored as host cookies at device114.

Access management system140(e.g., using agent) may present user102with a request for authentication credentials in the form of a challenge (e.g., via the user's web browser at device114). In some embodiments, user102can access a SSO user interface through a client executing on device114or through a web browser on device114. The SSO user interface may be implemented at access management system140. Access management system140may send, with a request, the SSO user interface or information (e.g., a URL) enabling access to the SSO user interface.

In some embodiments, an SSO user interface can include a list of the applications user102commonly utilizes. User102can manage their credentials and policies associated with applications through the SSO user interface. When user102requests to access an application, e.g., application140, through the SSO user interface, a request may be sent from device114to access management system140to determine a policy type for the application from one or more policies162applicable to user102. Access management system140may determine whether a valid session exists for the user and if so, then it can determine user's102credential information based on the policy type.

In some embodiments, the request may include an authentication cookie from a previous login that can be used to determine whether user102is authorized to retrieve the credential. If authorized, the user can be logged into the application using the credential. In some embodiments, agent can enable users to access applications120using SSO services provided by access management system. Access may be provided through a web browser directly, without first accessing the SSO user interface or using a client executing on device114. If user102is not authorized, then access management system may request credentials from user102. The SSO user interface may present an interface to receive input including credential information. The credential information may be sent to the access management system140to determine authentication of user102.

In some embodiments, credential types can be supported, such as Oracle Access Management protected resources, federated applications/resources, and form-fill applications. Examples of credential types may include a Smartcard/Proximity card, a token, a public key infrastructure (PKI), a Windows Logon, a lightweight directory access protocol (LDAP) logon, a biometric input, or the like. For OAM protected resources, user requests can be authenticated and then directed to URLs associated with the requested resources. For Federated Applications, links to federated partners and resources can be provided, including business to business (B2B) partner applications and SaaS applications. For form fill applications, templates can be used to identify fields of application web pages through which credentials can be submitted.

Similarly, a user102using device104(which is closer in proximity to data center180than data center135) may engage in communication with access management system170to access resources, such as any application in the set of applications120or the resources accessible through the set of applications120. The set of applications120may be accessible to user102upon successful authentication of credential information for user102. Before one of applications120is accessible to user102at device104, the user102would still need to be authenticated for a session that provides user102with access to applications120. The device104may initiate an authentication process by requesting access from access management system170. The authentication process may include device104displaying one or more GUIs to receive credential information of a user and submitting a request for authentication to access management system170. Authentication may be established based on verifying credential information of the user102.

In attempting to access a resource through the device104, the user102may operate an application (e.g., application106) that manages access to a user's account via access management system140. For example, application106may be an access management application that may present GUIs. Using application106, user102may request access to one or more resources, engage in authentication, and request modification of an authentication level. The device104may communicate with access management system170via communication network170. Examples of communication networks may include a mobile network, a wireless network, a cellular network, a local area network (LAN), a wide area network (WAN), other wireless communication networks, or combinations thereof.

Communications between device104and access management system170can also be received through the gateway system for supporting access management services. For example, a single sign-on (SSO) gateway may implement one or more access agents, e.g., a web gate agent, to balance and/or handle requests from clients and access management system170.

The protected resources (e.g., applications120) may be accessible to user102based on successful authentication of credential information. Upon receiving the credential information, the access management system170may (in some cases, through a session engine and/or authorization engine) verify whether a requested resource is a protected resource that requires credentials for access. Upon determining that access determines that the resource is not protected, the access management system170may grant access to a resource. Upon determining that access to a resource is protected, the access management system170may determine authentication of the user102based on the credential information. Upon determining authentication of user102, the access management system170may determine whether user102is authorized to access a resource based on access permitted to user102. The access management system170may send a communication to device104to indicate whether access to a resource is permitted by user102, and the requested resource may be enabled to user102based on whether access is permitted.

The access management system170may provide many SSO services including management of access (e.g., granting/denying access) to resources, automatic sign-on, application password change and reset, session management, application credential provisioning, as well as authentication of a session. In some embodiments, access management system170can provide automatic single sign-on functionality for applications120, such as Windows® applications, Web application, Java® applications, and mainframe/terminal-based applications running or being accessed from client devices. As explained above, access management system170may perform the authentication of a user (e.g., user102) operating a client device (e.g., device104).

In some embodiments, access management system170may also adhere to one or more policies stored in a data store174(“policies”) to control access to resources. Policies174may include an authentication policy that specifies the authentication methodology to be used for authenticating the user for whom the access must be provided on a given resource. Policies174may include an access policy that defines the way in which the resource access is to be protected (e.g., type of encryption, or the like). Policies174may include an authorization policy that specifies 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. In some embodiments, policies174may include an authorization policy that specifies a maximum number of single sign-on (SSO) sessions permitted for a user across the multi-data center (MDC) system. For instance, there may be a policy that specifies that any particular user may only have a single session across the MDC system (e.g., across the data center135and the data center180). Thus, prior to a data center (e.g., data center135) establishing a session for a user (e.g., user102), that data center may check the authorization policy for a user to determine the maximum number of sessions allowed to a user. The data center may also check (e.g., by looking at the security data or identity attribute associated with the user) to see the session status for any active sessions associated with the user and compare it against the maximum number of sessions allowed to the user. Thus, the data center may only establish additional sessions if the number of active sessions is less than the maximum allowed (e.g., if a user is allowed a maximum of a single session and there are currently no sessions associated with the user).

The access management system170may also include or be coupled to additional storage, which may be implemented using any type of persistent storage device, such as a memory storage device or other non-transitory computer-readable storage medium. In some embodiments, local storage may include or implement one or more databases (e.g., a document database, a relational database, or other type of database), one or more file stores, one or more file systems, or combinations thereof. For example, access management system170is coupled to or includes one or more data stores for storing data such as session data store172and policies174. The memory and the additional storage are all examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.

Access management system170may store session data in session data store172. In some embodiments, any rarely-changing information (e.g., subject information) may be stored in session data store172. Session information that changes frequently may be sent to a client device for storage and received in communication from the client device. The access management system170may check for a valid session for user102to access a requested resource that is protected, and the check may be based on consideration of one or more access policies applicable to user102. Based on determining that a valid session does not exist for user102, the access management system170may request credential information from user102. Successful authentication of the credential information may provide the user with access to one or more resources, which may include a requested resource.

Requests may be communicated to device104via communication network132. A request may prompt user102for user credentials to determine authentication of a session. Request may include information (e.g., a URL) to a web page or a user interface (e.g., a web page, portal, or dashboard) to receive credential information.

The access management system170may perform operations to authenticate credential information for user102. In some embodiments, the access management system170may store information about sessions established upon successful authentication of a user. For a SSO session (e.g., SSO authenticated sessions), the SSO session may be managed as a SSO session enabling access to all resources accessible to user based upon successful authentication of credential information for a user. The access management system170may also determine resources that are protected and determine resources that are permitted and/or restricted to a user for a session.

In some embodiments, access management system170may be implemented in system100according to an agent-server model for communication between device104and any one of access manager servers implemented for access management system170. The agent-server model may include an agent component (e.g., a gateway system) and a server component. The agent component may be deployed on a host system and the server component may be deployed on a server, e.g., an access manager server. User102operating device104may communicate with access management system170via agent using an enterprise computer network. In some embodiments, the agent may be an application or embedded in an application on a device. The device may be a workstation, personal computer (PC), laptop computer, smart phone, wearable computer, or other networked electronic device.

Agent may provide access control and may operate to protect access management system170and any resources accessible through access management system170against external and internal web-based threats. Access management system170may communicate with one or more resource computing systems (e.g., resource servers) that provide access to one or more resources, e.g., applications120. Agent may implement or operate as the agent component access management system170and may include a server that operates as the server component. Each resource accessible by access management system170may be protected through an agent, e.g., agent. Agent may intercept user requests for one or more resources protected by it and check for user credentials in order to authenticate the user. The agent may then contact a server, e.g., an access manager server at access management system140. The access management server may verify whether a resource is a protected resource that requires credentials for access. If the access management server determines that the resource is not protected, agent may grant access to user102. If the resource is protected, agent may request user102to provide authentication credentials.

In some embodiments, communication between the agent and access management system170may be split into two different channels of communication. For example, communication via a front-channel may use a hypertext transfer protocol secure (HTTPS) protocol. Front-channel communications may include less frequent communications, such as communications for credential collection operations for authentication. Communication via a back-channel may use an open access protocol (OAP). Back-channel communications may include more frequent communications, such as agent-server interactions including requests for access to a resource managed by access management system170. Each channel may communicate using an access token designed for the type of communication over the channel.

The access flow may generate two types of browser tokens. A first token is an access management ID token (e.g., OAM_ID token), which serves the SSO requests that are being propagated over HTTP. A second token may be an authorization token (e.g., OAMAuthn Token) that may be used to service the SSO requests that are being propagated over OAP. The browser tokens may be stored as host cookies at device104.

Access management system170(e.g., using agent) may present user102with a request for authentication credentials in the form of a challenge (e.g., via the user's web browser at device104). In some embodiments, user102can access a SSO user interface through a client executing on device104or through a web browser on device104. The SSO user interface may be implemented at access management system170. Access management system170may send, with a request, the SSO user interface or information (e.g., a URL) enabling access to the SSO user interface.

In some embodiments, an SSO user interface can include a list of the applications user102commonly utilizes. User102can manage their credentials and policies associated with applications through the SSO user interface. When user102requests to access an application through the SSO user interface, a request may be sent from device104to access management system170to determine a policy type for the application from one or more policies174applicable to user102. Access management system170may determine whether a valid session exists for the user and if so, then it can determine user's102credential information based on the policy type.

In some embodiments, the request may include an authentication cookie from a previous login that can be used to determine whether user102is authorized to retrieve the credential. If authorized, the user can be logged into the application using the credential. In some embodiments, agent can enable users to access applications120using SSO services provided by access management system. Access may be provided through a web browser directly, without first accessing the SSO user interface or using a client executing on device104. If user102is not authorized, then access management system may request credentials from user102. The SSO user interface may present an interface to receive input including credential information. The credential information may be sent to the access management system170to determine authentication of user102.

It should be noted that, for the purposes of facilitating understanding, this disclosure provides examples, figures, and description that involves the evaluation of session creation for different devices (e.g.,FIG. 1shows a device114used to try to establish a session, as well as device104being used to try to establish another session). However, a new access attempt (e.g., request by a user to access resources) does not have to come from an entirely different device, and in some cases attempting to access resources using a different application or browser on the same device may be considered a new access that will trigger session enforcement. For example, the user102may send a request to access a resource using a first application (e.g., application116) on device114and be granted a session for that first application. This session may be associated with the particular combination of the first application and the device114. Thus, if the user102attempts to access the resource using a second application or browser on device114, the access management system may consider this a new access attempt for enforcing the session limit. If the user102is permitted to have only one session, then the access management system would enforce that limit by not establishing a second session for the new access attempt (e.g., the request associated with the particular combination of the second application and the device114). In some embodiments, for which the applications are browsers, access attempts using a new private window within the same browser may be considered a separate access attempt for the purposes of session enforcement. Thus, in various embodiments, the access management system may carry out session enforcement on requests coming from different devices, requests coming from different applications or browsers on the same device, or even requests coming from the same application and device.

FIGS. 2 and 3illustrates steps associated with enforcing a single user session across multiple data centers, in accordance with an embodiment of the present disclosure. Some embodiments of the present disclosure, such as the one depicted inFIGS. 2 and 3, may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, a sequence diagram, or a block diagram. Although a sequence diagram or a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

The processes depicted herein, such as the steps described with reference toFIGS. 2-3, may 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). In some embodiments, the processes depicted in flowcharts herein can be implemented by a computing system of an access management system, e.g., the access management system140ofFIG. 1implemented by data center135or the access management system170ofFIG. 1implemented by data center180. The particular series of processing steps in this disclosure are not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present disclosure may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in the figures may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step.

While the processing depicted inFIGS. 2-3may be described with respect to enforcing a single SSO session for a user across multiple data centers, such processing may be performed for multiple users. In other words, the processing depicted inFIGS. 2-3may be described with respect to multiple sessions, each of which are associated with a different user. 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.

In an aspect of some embodiments, each step inFIGS. 2-3can be performed by one or more processing units. A processing unit may include one or more processors, including single core or multicore processors, one or more cores of processors, or combinations thereof. In some embodiments, a processing unit can 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 processing units can be implemented using customized circuits, such as application specific integrated circuits (ASICs), or field programmable gate arrays (FPGAs).

With respect toFIG. 2, at circle1, a user202operating a first device is shown supplying user credentials to a first data center212that is part of a multi data center deployment210. In some embodiments, the user202may correspond to user102inFIG. 1, the first device may correspond to device114inFIG. 1, and the first data center212may correspond to data center135inFIG. 1. In the example depicted inFIG. 2, the user202may have already engaged in communication with an access management system implemented by the first data center212by requesting to access a resource through the first device, and circle1may be occurring after user credentials have been requested from the user202(e.g., during the authentication of the user202).

If the user202is successfully authenticated, then prior to the access management system of the first data center212establishing a session for the user202, the access management system of the first data center212may check a data store214for security data associated with the user202. In some embodiments, the security data associated with the user202may be an identity attribute or include an identity attribute. In some embodiments, the identity attribute associated with user202may be referred to as a “lockedBy” identity attribute, and it may include an identifier associated with one of the data centers of the multi data center deployment210. If the security data associated with user202does not include an identifier associated with one of the data centers of the multi data center deployment210(e.g., the identity attribute has no value), then the access management system may determine that no existing session exists for the user202.

If no existing session exists for the user202, then the access management system of the first data center212may establish a session for the user202to access the requested resource using the first device. At circle2, the access management system of the first data center212may update the data store214to include an identifier (e.g., “DC1”) of the first data center212into the security data associated with the user202.

At circle3, the security data in the data store214may be copied over to the data store218of a second data center216. Thus, the identifier (e.g., “DC1”) of the first data center212that has been associated with the user202may be copied over to the security data for the user202in the data store218. At this point, both the data store214(of the first data center212) and the data store218(of the second data center216) will contain security data associated with the user202that includes a value for the identifier associated with the first data center212(e.g., “DC1”).

At circle4, a user204operating a second device may engage in communication with the access management system implemented at the second data center216of the multi data center deployment210, and as part of the authentication process the user204may supply user credentials to the second data center216.

With respect toFIG. 3, a multi data center deployment is shown that includes multiple data centers (e.g., a first data center320, a second data center330, . . . an Nth data center340), with each data center implementing an instance of the access management system. The multiple data centers may be connected by a network308(e.g., the Internet) that allows the data centers to communicate with each other and share information, such as security data associated with specific users. In some embodiments, there may be a resource management system350that hosts one or more protected resources (shown in the figure as R1, R2, R3 . . . ) that users may desire access to, while in other embodiments, the protected resources may be hosted at one or more of the data centers of the multi data center deployment. The resource management system350may also be connected to the network308, such that any client devices can access the resources of the resource management system through the network308. In some embodiments, there may also be one or more client devices (e.g., client device304and client device314, or the device104and device114inFIG. 1) that can communicate with the data centers and/or the resource management system350through the network308.

In the figure shown, a user302may use a client device304or an application306operating on the client device304to request access to a protected resource (e.g., hosted by the resource management system350), and that request may be sent to the first data center320based on the geographic proximity between the client device and the first data center320. The application306may interact with the access management system implemented by the first data center320in order to authenticate and authorize the user302based on the user credentials supplied by the user302. The access management system may check to see if an existing session exists for the user302across the multi data center deployment (e.g., by checking the security data associated with the user302that is maintained in the first data center320).

If the authentication and authorization of the user302is successful, then at circle1, a session322may be established for the user302at the first data center320. The security data324associated with the user302may be updated to include an identifier of the data center at which the session322is established (e.g., “DC1” as an identifier for the first data center320).

The security data324associated with the user302may be provided to other data centers in the multi data center deployment. For instance, at circle2, the security data324associated with the user302may be provided to the second data center330to be saved under security data334associated with the user302. At circle3, the security data324may be provided to the Nth data center340to be saved under security data344associated with the user302. Thus, each data center will have security data associated with the user302that includes the identifier (e.g., “DC1”) for the first data center320since the session322for the user302is established at the first data center320.

At circle4, once the session322is established for the user302at the first data center320, the user302may be able to use the client device304to access the requested resource of the resource management system350using the established session322. While the session322for the user302is still active, no other sessions associated with the user302can be established.

For instance, at circle5, a user312may direct a client device314or an application316of client device314to request access to a protected resource, and that request may be handled by the second data center330(e.g., if the client device314is closer to the second data center330than to the first data center320). In some cases, the user312may be the same person as the user302, but in most cases, the user312will be a different person from the user302. If the user312provides the same user credentials that the user302supplied for authentication/authorization purposes (e.g., trying to pass off as the user302), then the second data center330will look at the security data334associated with the user302which includes the identifier for the first data center320. This will signify to the second data center330that a session for the user302(e.g., session322) has been established by the first data center320and is currently active. If the authorization policy prevents any more than a single session for the user302, then in order to preserve the allowed maximum session count for the user302, the access management system as the second data center330will not create another session for the user312to use with the client device314. Accordingly, the client device314will be not be given access to any of the resources hosted by the resource management system350(in the figure, this is shown by the “X” between the client device314and the resource management system350).

FIG. 4illustrates a sequence diagram for enforcing a single user session across multiple data centers, in accordance with an embodiment of the present disclosure. For the purpose of facilitating understanding, a client inFIG. 4is a device; however, a client can be a device or an application on a device.

A first user may operate a first client410to establish a session for access to one or more protected resources. At step410, the first client410may request access to the resource for the first user and send that request to an access management system at a first data center404.

At step412, the access management system of data center404may determine whether the first user was previously authenticated for access at the client410. If access is managed according to techniques for SSO, then the access management system may determine whether the user was authenticated at any client. The access management system may communicate with the client402to request and obtain credentials to authenticate the user. Upon successful authentication of the first user, the access management system of the data center404may create a session for the user. As part of creating the session, the access management system140may update security data associated with the user, which may include a “lockedBy” attribute. In some cases, the access management system may update the security data associated with the user by changing the value of the “lockedBy” attribute to an identifier of the data center404. In some embodiments, the security data may be associated with the session data for the first user, which may include information such as the IP Address of the client402, the authentication level, the authentication scheme, the authentication timestamp, and the application domain information for accessed resources. The session data may also include specific attributes, such as access timestamp, partner information of a last accessed resource, and application domain information for one or more accessed resources, and this data may be updated each time the first user requests access.

After the session is created, at step414, the access management system of the data center404may send a response to the client402. The response may include a portion of the session information, which the client402can use to access or log in to the session. In some cases, the response may be pre-defined. In some embodiments, the signed access claim may include an identity store identifier and/or a domain name (DN) identifier of the authenticated user so the access management system can retrieve session data or security data when needed.

After the session is created, at step416, the data center404may send an update to data center406, as well as any other data centers in the multi data center deployment. The update provided to data center406may include the updated security data, which should now include the identifier of the data center404.

At step418, the access management system of the data center406will receive the security data associated with the first user, and the access management system of the data center406will update the security data within the data center406with the received security data associated with the first user. For instance, since the received security data includes the identifier of the data center404, the security data for the user at the data center406can be updated to also include the identifier of the data center404.

At step420, while the session for the first user is still active (and the security data associated with the user includes the identifier of the data center404), a second user may operate a second client408to establish a session for access to one or more protected resources. The second client408may request access to the resource for the second user and send that request to an access management system at the second data center406.

At step422, the access management system of the second data center406may determine whether the second user was previously authenticated for access at the client408. If access is managed according to techniques for SSO, then the access management system may determine whether the user was authenticated at any client. The access management system may communicate with the client408to request and obtain credentials to authenticate the user. In some cases, the second user may provide the user credentials of the first user, in which case the access management system of the second data center406will attempt to authenticate the credentials of the first user. The access management system of the second data center406may also check to see if a session is active and already exists for the first user (since the credentials of the first user are being used for authentication). The access management system may determine that a session exists for the first user if the security data associated with the first user includes an identifier of a data center within the multi data center deployment (e.g., the identifier of the first data center404).

If no session exists for the user associated with the user credentials supplied by the client408(e.g., the first user), then the access management system of the data center406may create and establish a session for the client408. The security data associated with that user would be updated within data center406. For instance, if the security data includes a “lockedBy” attribute, the value of the “lockedBy” attribute would be changed to an identifier of the data center406in order to signify that the data center406established the session. However, if a session exists, then the access management system of the data center406would deny the creation of a session for the client408.

At step424, the access management system of the data center406may send a response back to the client408. If a session for client408was created at step422, then the response may include a portion of the session information for the client408to use. If no session was created at step422, then the response may notify the client408that no session was created and access to the resource requested (at step420) is denied.

If the session for client402(that was created at step412) is still active, it may remain active until the session is terminated. In some cases, the client402may voluntarily initiate termination of the session (e.g., if the user logs out of the session), in which case, at step426, the client402will send a session termination to the data center404. However, in some embodiments, a session may be terminated without action taken by the client402(and thus, without step426). For instance, the access management system may be configured with an expiry time or maximum lifetime for a session (e.g., 4 hours), such that any session that exists for longer than the expiry time is automatically terminated. Or the access management system may have a configurable idle timeout period (e.g., 15 minutes or 1 hour), such that any session that is idle for longer than the idle period will be automatically terminated.

At step428, the access management system of the data center404will terminate the session. This may include revising the security data associated with the first user (e.g., the user of the client402), such that the security data no longer includes the value of the identifier of the data center404.

At step430, the data center404may send an update to data center406, as well as any other data centers in the multi data center deployment. The update provided to data center406may notify that the session associated with the first user has been terminated, or a notification to clear out the security data associated with the first user at data center406(e.g., by deleting the identifier of the data center404in the security data). Or, the update itself may include the revised security data, which may no longer have the value of the identifier of the data center404.

At step432, the data center406can update its own security data (associated with the first user) based on the notification or received revised security data (e.g., to delete the identifier of the data center404or any identifier of other data centers).

FIG. 5illustrates a flow chart500for enforcing a single user session across multiple data centers, in accordance with an embodiment of the present disclosure. Flow chart500may be implemented by the access management systems ofFIG. 1.

At step502, a first data center will receive (e.g., from a first device) a request for a user to access a resource.

At step504, the first data center will determine authentication and authorization of the user based on user credentials supplied by the user.

In some embodiments, authentication and authorization of the user may involve retrieving information (e.g., subject information) about the user from a data store of an access management system (e.g., implemented by the first data center). The information may include user identity information. The user identify information may include user access information such as a domain name of the user.

At step506, if the user is successfully authenticated, the first data center will determine if there is no existing session associated with that user. In some embodiments, the first data center may check a data store in the first data center for security data associated with the user. If the security data for the user is blank or does not specify an identifier for a data center, then no session exists for the user. However, if the security data includes an identifier for a data center, that means a session exists for the user.

At step508, if there is no session for the user, then the first data center will establish a session for the user to access the requested resource. The relevant session information will be provided to the user (e.g., to the first device) so that the user can access the resource through the first device.

At step510, since a new session was established for the user, the session status has to be updated across all the data centers of the multi data center deployment. At the first data center, the security data associated with the user can be changed to include an identifier for the first data center (to signify that a session has been established by the first data center). This identifier for the first data center can be sent (e.g., as part of the security data associated with the user) to all the other data centers in the multi data center deployment for those other data centers to include in their security data for the user.

At step512, a second data center will receive (e.g., from a second device) a request for the user to access a resource.

At step514, the second data center will determine authentication and authorization of the user based on user credentials supplied by the user of the second device.

At step516, if the user is successfully authenticated, the second data center will determine if there is an existing session associated with the user. In some embodiments, the second data center may check a data store in the second data center for security data associated with the user. If the security data for the user is blank or does not specify an identifier for a data center, then no session exists for the user. However, if the security data includes an identifier for a data center, that means a session exists for the user.

If a session exists for the user, then at step520, the second data center will deny the creation of a new session for the user and the user will not be granted access to the resource through the second device.

If a session does not exist for the user, then at step530, the second data center will establish a new session for the user to access the resource using the second device.

At step532, since a new session was established for the user, this session status has to be updated across all the data centers of the multi data center deployment. At the second data center, the security data associated with the user can be changed to include an identifier for the second data center (to signify that a session has been established by the second data center). This identifier for the second data center can be sent (e.g., as part of the security data associated with the user) to all the other data centers in the multi data center deployment for those other data centers to include in their security data for the user.

FIG. 6illustrates a flow chart600for enforcing a single user session at a first data center, in accordance with an embodiment of the present disclosure. Flow chart600may be implemented by one of the access management systems (e.g., access management system140) ofFIG. 1.

At step602, the data center will receive (e.g., from a client device) a request for a user to access a resource.

At step604, the data center will receive credentials for the user (e.g., the user will supply credentials by entering them into the client device, which will send the credentials to the data center).

At step606, the data center will determine authentication and authorization of the user based on user credentials supplied by the user.

At step608, once the user is successfully authenticated, the data center will check security data associated with the user (located in a data store of the data center) and determine that it has no value (e.g., it does not include an identifier for a data center). This means that there is no existing session associated with the user.

At step610, if there is no existing session for the user, then the data center will be free to establish a new session for the user to access the requested resource. The data center will change the security data associated with the user (in the data store) to include an identifier for the data center (to signify that a session has been established by the data center).

At step612, this identifier for the data center can be sent (e.g., as part of the security data associated with the user) to all the other data centers in the multi data center deployment for those other data centers to include in their security data for the user.

At step614, the data center will establish the new session for the user to access the requested resource. The relevant session information will be provided by the data center to the user (e.g., to the client device) so that the user can access the resource through the client device by logging on to the session. In some embodiments, the session information may be sent as a token.

FIG. 7illustrates a flow chart700for enforcing a single user session at a second data center, in accordance with an embodiment of the present disclosure. Flow chart700may be implemented by one of the access management systems (e.g., access management system170) ofFIG. 1.

At step702, a data center will receive an identifier of a different data center in the same multi data center deployment. This identifier may be received alongside an indication of a user identity.

At step704, the data center may update a data store containing security data associated with the user identity. The data center may locate the relevant security data for the user identity based on the received indication of the user identity. That security data can be updated to include the identifier of the different data center.

At step706, the data center will receive (e.g., from a client device) a request for the user to access a resource.

At step708, the data center will determine authentication and authorization of the user based on user credentials supplied by the user of the client device.

At step710, if the user is successfully authenticated, the data center will access the security data associated with the user in the data store.

At step712, the data center will determine whether the security data associated with the user stores the identifier of a different data center in the multi data center deployment.

At step720, if the identifier is present in the security data associated with the user, the data center will deny the user access to the resource using the device.

Alternatively, if the identifier is not present in the security data associated with the user, then at step730the data center will provide the user access to the resource using the device by establishing a session for the user and sending the session information to the user.

At step732, since a new session was established for the user, the data center will update the security data associated with the user to include an identifier of the data center (to signify that a session has been established by the data center).

At step7324, the identifier will be sent out to all the other data centers in the multi data center deployment for those other data centers to include in their security data for the user.

FIG. 8depicts a simplified diagram of a distributed system800for implementing an embodiment. In the illustrated embodiment, distributed system800includes one or more client computing devices802,804,806, and808, 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)810. Server812may be communicatively coupled with remote client computing devices802,804,806, and808via network810.

In various embodiments, server812may be adapted to run one or more services or software applications. In certain embodiments, server812may 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 devices802,804,806, and/or808. Users operating client computing devices802,804,806, and/or808may in turn utilize one or more client applications to interact with server812to utilize the services provided by these components.

In the configuration depicted inFIG. 8, software components818,820and822of system800are shown as being implemented on server812. In other embodiments, one or more of the components of system800and/or the services provided by these components may also be implemented by one or more of the client computing devices802,804,806, and/or808. 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 system800. The embodiment shown inFIG. 8is thus one example of a distributed system for implementing an embodiment system and is not intended to be limiting.

Client computing devices802,804,806, and/or808may 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)810.

Although distributed system800inFIG. 8is 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 server812.

Server812may 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. Server812can 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 server812using software defined networking. In various embodiments, server812may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server812may correspond to a server for performing processing as described above according to an embodiment of the present disclosure.

Distributed system800may also include one or more databases814and816. These databases may provide a mechanism for storing information such as user interactions information, usage patterns information, adaptation rules information, and other information used by embodiments of the present disclosure. Databases814and816may reside in a variety of locations. By way of example, one or more of databases814and816may reside on a non-transitory storage medium local to (and/or resident in) server812. Alternatively, databases814and816may be remote from server812and in communication with server812via a network-based or dedicated connection. In one set of embodiments, databases814and816may reside in a storage-area network (SAN). Similarly, any necessary files for performing the functions attributed to server812may be stored locally on server812and/or remotely, as appropriate. In one set of embodiments, databases814and816may 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.FIG. 9is a simplified block diagram of one or more components of a system environment900in which services may be offered as cloud services, in accordance with an embodiment of the present disclosure. In the illustrated embodiment inFIG. 9, system environment900includes one or more client computing devices904,906, and908that may be used by users to interact with a cloud infrastructure system902that provides cloud services. Cloud infrastructure system902may comprise one or more computers and/or servers that may include those described above for server812.

It should be appreciated that cloud infrastructure system902depicted inFIG. 9may have other components than those depicted. Further, the embodiment shown inFIG. 9is only one example of a cloud infrastructure system that may incorporate an embodiment of the disclosure. In some other embodiments, cloud infrastructure system902may 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 devices904,906, and908may be devices similar to those described above for client computing devices802,804,806, and808. Client computing devices904,906, and908may 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 system902to use services provided by cloud infrastructure system902. Although exemplary system environment900is 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 system902.

Network(s)910may facilitate communications and exchange of data between client computing devices904,906, and908and cloud infrastructure system902. 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)810.

In certain embodiments, services provided by cloud infrastructure system902may include a host of services that are made available to users of the cloud infrastructure system on demand. 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 system902may 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 system902may also provide “big data” elated 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 system902may be adapted to automatically provision, manage and track a customer's subscription to services offered by cloud infrastructure system902. Cloud infrastructure system902may provide the cloud services via different deployment models. For example, services may be provided under a public cloud model in which cloud infrastructure system902is 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 system902is 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 system902and the services provided by cloud infrastructure system902are 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 certain embodiments, cloud infrastructure system902may also include infrastructure resources930for providing the resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources930may 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 services932may be provided that are shared by different components or modules of cloud infrastructure system902to enable provision of services by cloud infrastructure system902. 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 system902may 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 system902, and the like.

In one embodiment, as depicted inFIG. 9, cloud management functionality may be provided by one or more modules, such as an order management module920, an order orchestration module922, an order provisioning module924, an order management and monitoring module926, and an identity management module928. 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 step934, a customer using a client device, such as client computing devices904,906or908, may interact with cloud infrastructure system902by requesting one or more services provided by cloud infrastructure system902and placing an order for a subscription for one or more services offered by cloud infrastructure system902. In certain embodiments, the customer may access a cloud User Interface (UI) such as cloud UI912, cloud UI914and/or cloud UI916and place a subscription order via these UIs. The order information received by cloud infrastructure system902in response to the customer placing an order may include information identifying the customer and one or more services offered by the cloud infrastructure system902that the customer intends to subscribe to.

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

At step938, the order information may be forwarded to an order management module920that 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 step940, information regarding the order may be communicated to an order orchestration module922that is configured to orchestrate the provisioning of services and resources for the order placed by the customer. In some instances, order orchestration module922may use the services of order provisioning module924for the provisioning. In certain embodiments, order orchestration module922enables 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. 9, at step942, upon receiving an order for a new subscription, order orchestration module922sends a request to order provisioning module924to allocate resources and configure resources needed to fulfill the subscription order. Order provisioning module924enables the allocation of resources for the services ordered by the customer. Order provisioning module924provides a level of abstraction between the cloud services provided by cloud infrastructure system900and the physical implementation layer that is used to provision the resources for providing the requested services. This enables order orchestration module922to 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 step944, 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 step946, a customer's subscription order may be managed and tracked by an order management and monitoring module926. In some instances, order management and monitoring module926may 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 system900may include an identity management module928that is configured to provide identity services, such as access management and authorization services in cloud infrastructure system900. In some embodiments, identity management module928may control information about customers who wish to utilize the services provided by cloud infrastructure system902. 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 module928may 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. 10illustrates an exemplary computer system1000that may be used to implement an embodiment of the present disclosure. In some embodiments, computer system1000may be used to implement any of the various servers and computer systems described above. As shown inFIG. 10, computer system1000includes various subsystems including a processing unit1004that communicates with a number of peripheral subsystems via a bus subsystem1002. These peripheral subsystems may include a processing acceleration unit1006, an I/O subsystem1008, a storage subsystem1018and a communications subsystem1024. Storage subsystem1018may include tangible computer-readable storage media1022and a system memory1010.

Processing subsystem1004controls the operation of computer system1000and may comprise one or more processing units1032,1034, 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 subsystem1004can 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 subsystem1004can 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 subsystem1004can execute instructions stored in system memory1010or on computer readable storage media1022. 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 memory1010and/or on computer-readable storage media1022including potentially on one or more storage devices. Through suitable programming, processing subsystem1004can provide various functionalities disclosed herein.

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

Storage subsystem1018provides a repository or data store for storing information that is used by computer system1000. Storage subsystem1018provides 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 subsystem1004provide the functionality described above may be stored in storage subsystem1018. The software may be executed by one or more processing units of processing subsystem1004. Storage subsystem1018may also provide a repository for storing data used in accordance with the present disclosure.

Storage subsystem1018may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. As shown inFIG. 10, storage subsystem1018includes a system memory1010and a computer-readable storage media1022. System memory1010may 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 system1000, 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 subsystem1004. In some implementations, system memory1010may 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. 10, system memory1010may store application programs1012, which may include client applications, Web browsers, mid-tier applications, relational database management systems (RDBMS), etc., program data1014, and an operating system1016. By way of example, operating system1016may 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 subsystem1000may also include a computer-readable storage media reader1020that can further be connected to computer-readable storage media1022. Together and, optionally, in combination with system memory1010, computer-readable storage media1022may comprehensively represent remote, local, fixed, and/or removable storage devices plus storage media for storing computer-readable information.

In certain embodiments, computer system1000may provide support for executing one or more virtual machines. Computer system1000may 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 system1000. Accordingly, multiple operating systems may potentially be run concurrently by computer system1000. Each virtual machine generally runs independently of the other virtual machines.

Communications subsystem1024provides an interface to other computer systems and networks. Communications subsystem1024serves as an interface for receiving data from and transmitting data to other systems from computer system1000. For example, communications subsystem1024may enable computer system1000to 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 subsystem1024may support both wired and/or wireless communication protocols. For example, in certain embodiments, communications subsystem1024may 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 subsystem1024can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

Communication subsystem1024can receive and transmit data in various forms. For example, in some embodiments, communications subsystem1024may receive input communication in the form of structured and/or unstructured data feeds1026, event streams1028, event updates1030, and the like. For example, communications subsystem1024may be configured to receive (or send) data feeds1026in 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 subsystem1024may also be configured to output the structured and/or unstructured data feeds1026, event streams1028, event updates1030, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system1000.

Due to the ever-changing nature of computers and networks, the description of computer system1000depicted inFIG. 10is intended only as a specific example. Many other configurations having more or fewer components than the system depicted inFIG. 10are 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.

Further, while embodiments of the present disclosure have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present disclosure.

Embodiments of the present disclosure may be implemented only in hardware, or only in software, or using combinations thereof. The various processes described herein can be implemented on the same processor or different processors in any combination. Accordingly, where components or modules are described as being configured to perform certain operations, such configuration can be accomplished, e.g., by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or any combination thereof. Processes can communicate using a variety of techniques including but not limited to conventional techniques for interprocess communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.