Patent Description:
Further, computing system functionality can be enhanced by a computing system's ability to be interconnected to other computing systems via network connections. Network connections may include, but are not limited to, connections via wired or wireless Ethernet, cellular connections, or even computer to computer connections through serial, parallel, USB, or other connections. The connections allow a computing system to access services at other computing systems and to quickly and efficiently receive application data from other computing systems. For example, an entity may be configured to access resources from a resource provider where the resource provider is a remote computing system. To obtain access to these resources, the entity will typically authenticate with an identity provider to receive an access token and a refresh token, where the access token can be presented to the resource provider in a request for resources. If the access token is valid, an authenticated session is created between the resource provider and the entity to provide the resources.

In particular, IT Administrative policies for an organization are often configured centrally on the identity provider used by the organization. The policies are then enforced by the identity provider when issuing authentication artifacts (e.g., access tokens) that are used to confirm a user's identity. Before issuing an access token to the user, the identity provider evaluates administrative policies to ensure the user's compliance. If the user complies with the policies, the access token is issued to the user. The access token is then passed to a resource provider that grants resource access based on the information in the access token. After the access token is issued and until it reaches its expiration the identity provider has no means to update resource providers on changes in the user's security state. For example, if the user's employment has been terminated, the user will continue to have access to the resources until the user's access tokens expire.

For example, access tokens will often be issued by an identity provider where the access tokens are valid for one hour. Thus, there could be a one-hour time frame when an entity should not have access to resources at a resource provider when the entity could obtain access to the resources.

Some solutions to this have been to reduce the access token validity time. However, this only shortens the length of time which an unauthorized entity can have access to resources. Additionally, this has the negative drawback of resulting in dramatically increased network traffic. For example, if the validity period were reduced to <NUM> minutes instead of one hour, there would be a corresponding <NUM>% increase in network traffic for authentication between the aunt entity and the identity provider.

<CIT> discloses revoking sessions using signaling. A signal indicating that a login session is no longer trusted and that the user is to be re-directed to an identity platform to re-authenticate and renew a session is generated.

<CIT> discloses event related communications.

<CIT> discloses a system for efficient management of invalid access tokens.

It is therefore the object of the present invention to provide an improved method of managing an authenticated user session.

One embodiment illustrated herein includes a method that includes acts for managing an authenticated user session. The method includes a resource provider computer system subscribing to a conditional access termination service for an entity configured to obtain resources from the resource provider computer system through a user session. The resource provider computer system receives an event, related to resource requests, for the entity from the conditional access termination service. The resource provider computer system receives a request for resources from the entity. The resource provider computer system evaluates the request with respect to the event. The resource provider computer system responds to the request based on evaluating the request with respect to the event.

Embodiments illustrated herein are able to implement so called `instant enforcement' of IT Policies. That is, there exists a technical problem whereby systems are vulnerable to unauthorized access due to unauthorized entities using unexpired access tokens to access resources to which they should no longer have access. Further, there exists a technical problem of increased traffic when systems attempt to shorten access token validity times. Typically it is not feasible to configure resource providers to enforce policy as doing so affects the scalability of enterprise systems. In particular, it is expensive in terms of computational resources and administrator resources to reconfigure resource providers any time there is a policy change or any time there is a change that would necessitate revoking a user session. As the number of resource providers increases in such systems, cost in terms of computational resources and administrator resources increases proportionally. Thus, a system that requires each resource provider computer system to be reconfigured would necessarily need to be limited in the number of resource provider computer systems that could be implemented. Further, requiring each resource provider to be reconfigured would require a system that was able to track and manage all resource providers in a fashion that allowed them to be reconfigured. Further, requiring each resource provider to be reconfigured could actually take more time than simply allowing a token to expire, thus negating any benefit achieved by reconfiguring the resource provider computer systems. Thus, there is a need for systems which allow for highly scalable numbers of resource providers to be added to the enterprise system while still being able to address the need to invalidate unexpired tokens. This can be particularly important in cloud-based systems where resource providers can be quickly added, except when external constraints such as those illustrated above are placed on the systems.

Embodiments illustrated herein can implement a technical solution which instantly (or at least very quickly) notifies resource providers of potential access issues by an entity to the resources. This is implemented in some embodiments by the technical means of a conditional access termination service. In particular, the technical means includes allowing a resource provider to receive events relevant to entities that attempt to receive resources from the resource provider. In some embodiments, this can occur as a result of the resource providers subscribing to the conditional access termination service to receive events. The events can be evaluated at the resource provider against requests for resources to determine actions that should be taken with respect to the requests for resources from the entities. This allows for policy related information to be provided to resource providers in a fashion that still allows for a scalable system with respect to the resource providers. In particular, there is no need to track and reconfigure individual servers, rather each of the resource providers can subscribe to receive events according to policy considerations in those events.

For example, embodiments may include a system that can communicate policy signals to resource providers who can then make decisions on revoking existing sessions and redirecting users back to identity provider for policy re-evaluation.

For example, some embodiments can detect changes that affect security of a user's account. These changes can include but are not limited to:.

On detection of such changes, the conditional access termination service (which in some embodiments may be included as part of the identity provider) will publish events to the subscribers. Interested resource providers will subscribe to the events. On receiving events for the user resource providers will revoke the existing session for the users and redirect the user back to the identity provider.

In some cases, resource providers need to redirect on a condition: for example, if a user's device has virus on it, only sessions initiated from the infected device should be affected. Thus, a condition included in an event may be a device-based condition. If an entity requests resources using a device indicated in an event to the resource provider, the entity will be redirected to an identity provider. In some embodiments, the identity provider will re-evaluate the user's policy and will either re-issue an access token after re-validating user's identity, display remediation steps to the user (e.g. remove the virus from the device) or block the user entirely.

Referring now to <FIG>, an example is illustrated. <FIG> illustrates an entity <NUM>. In the illustrated example, the entity <NUM> may include a user as well as the device and associated clients used by the user. The entity <NUM> may have need to access resources from a resource provider <NUM>. To obtain access to the resources, the entity will first authenticate with an identity provider <NUM>. The entity <NUM> can authenticate to the identity provider <NUM> through any one of a number of different well-known authentication and access token issuance schemes, other less well-known authentication schemes, or even future authentication schemes yet to be developed. Suffice it to say, in the particular example shown in <FIG>, the entity <NUM> receives from the identity provider <NUM> an access token <NUM> and a refresh token <NUM>.

The access token <NUM> typically includes a timestamp indicating when the access token was issued. The access token <NUM> may alternatively or additionally include information indicating when the access token <NUM> expires. In some embodiments, the access token <NUM> may include information about authentication procedures used by the entity <NUM> to authenticate to the identity provider <NUM>. For example, the access token <NUM> may indicate that the access token <NUM> was obtained by the entity <NUM> authenticating to the identity provider using a simple user identity and secret authentication protocol. One such common protocol is the password authentication protocol, where the identity is a username and the secret is a password. Alternatively or additionally, if the entity <NUM> is authenticated to the identity provider <NUM> using double factor authentication, this can be indicated in the access token <NUM>. Alternatively or additionally, if the entity <NUM> is authenticated to the identity provider using a certain strength of password, this sort of information can be indicated in the access token <NUM> itself. For example, the access token may indicate the minimum length of password used to authenticate to the identity provider, use of special characters in the password used to authenticate to the identity provider, use of both upper and lowercase letters in the password used to authenticate to the identity provider, absence of common passwords or other words in the password used to authenticate to the identity provider, etc..

In some embodiments, the access token <NUM> will be for a particular user as well as for a client used by the particular user. Thus, in this example, the entity <NUM> includes both the user and the client used by the user. For example, the user may use a laptop computer with a corresponding laptop computer client to perform the authentication and resource requests. Thus, the access token <NUM> may include information about the laptop computer client of the entity <NUM>. Alternatively, the user may use a smart phone to perform the authentication, in which case a corresponding smart phone client is used to perform the authentication and to perform resource requests, meaning that the access token <NUM> will be for an entity <NUM> including a user using a smart phone client. As will be illustrated in more detail below, this additional information can be used by the resource provider <NUM> to evaluate certain conditions indicated in events provided by a conditional access termination service.

Returning once again to the example illustrated in <FIG>, the entity <NUM> can provide the access token <NUM> to the resource provider <NUM> in a request for resources from the resource provider <NUM>. The resource provider <NUM> can evaluate the access token to determine that the entity <NUM> has been properly authenticated to the identity provider <NUM> and that the access token <NUM> is otherwise valid. In particular, the access token <NUM> may have an expiration and the resource provider <NUM> can determine that the access token <NUM> has not expired. Ordinarily, so long as this evaluation of the access token <NUM> passes the various checks, then the resources <NUM> will be provided to the entity <NUM>. However, embodiments illustrated herein can implement additional checks with respect to the request <NUM> by the entity <NUM> to the resource provider <NUM>.

In particular, <FIG> illustrates that the resource provider <NUM> can subscribe to a conditional access termination service <NUM>. In some embodiments, the conditional access termination service <NUM> may be included in the identity provider <NUM>. For example, embodiments may be implemented where policy is configured and administered at the same central location. Thus, embodiments may include an identity provider <NUM> that includes as part of the identity provider <NUM> the conditional access termination service <NUM>.

In alternative embodiments, the conditional access termination service <NUM> may be implemented independent of the identity provider <NUM>. For example, embodiments may still be able to implement a centralized conditional access termination service but that is separate from the identity provider <NUM>. In some embodiments, the conditional access termination service <NUM> may be associated with a policy server including both set policies and the ability to enforce the set policies. In the example illustrated, the resource provider <NUM> sends a subscription request <NUM> to the conditional access termination service <NUM>. The resource provider subscribes to events related to the entity <NUM>. As illustrated in <FIG>, events <NUM> can be published from the conditional access termination service <NUM> to the resource provider <NUM> regarding the entity <NUM>.

As discussed previously, events may be triggered due to account state changes, device state changes, client state changes, session state changes, etc. For example, a policy service can detect changes related to policy at the policy service.

Typically, an event will include one or more of the following: entity information, condition, timestamp, or action.

Entity information included in an event may include information identifying a particular user of an entity <NUM>, device information for the entity <NUM>, client information for the entity <NUM>, user role information for the entity <NUM> (e.g., is the user acting as an administrator, or other special authoritative user), membership information for the entity <NUM>, etc..

Condition information included in an event may include one or more conditions that should be evaluated to determine if a particular action should be taken.

A timestamp included in an event may indicate a time when the event was issued (or some other significant time). Alternatively or additionally, an event may include a timestamp identifying a time that should be conditionally evaluated.

An action included in an event indicates an action that should be taken with respect to the event. Notably, in some embodiments, actions are conditional meaning that certain actions should only be taken only when certain conditions are met.

As discussed above, in some embodiments events <NUM> may be issued from the conditional access termination service <NUM> to the resource provider <NUM> based on device state changes. In particular, the conditional access termination service <NUM> may be informed of changes to the device of the entity <NUM>. This can be facilitated by the entity <NUM> being registered with a particular administrative service, periodic messages by the entity <NUM>, general knowledge that devices of the type employed by the entity <NUM> have been changed generally, or in other ways. Thus, it should be noted that the conditional access termination service <NUM> may be connected by various interconnections to other systems that can provide information about the device state changes of the entity <NUM> such that appropriate events <NUM> can be issued.

The following illustrates a particular scenario illustrating one example of a device state change. In this example, an administrator has configured a policy to require a compliant (in that it complies with system policy) and healthy (in that it is functioning within some predefined functional standards) device as a condition for data access. The identity provider <NUM> extends ability to correlate app session with the device ID to resource providers. The conditional access termination service <NUM>, which in this case is a policy server, learns that a device for the user has fallen out of compliance, has a virus, or has otherwise failed to meet policy. The policy server publishes events <NUM> to the subscribers (e.g., the resource provider <NUM>) for this user as a result. The event contains a conditional action that the subscribers need to perform to comply with the policy. The condition, in this example, is a Device ID for an out of compliant device.

As discussed above, in some embodiments events <NUM> may be issued from the conditional access termination service <NUM> to the resource provider <NUM> based on a change to a client application. In particular, a change to a client application can be detected by a policy server, such as the conditional access termination <NUM>, and one or more events can be sent to resource providers, such as resource provider <NUM>, as a result. Such changes to the client application may include updates to the client application (e.g., new versions), configuration changes to the client application, revocation by an administrator, etc..

The following illustrates a detailed example of a client application change scenario. In this scenario, an administrator has removed a certain client application from the list of trusted apps for a tenant (where in this example, the tenant is the entity <NUM>). A policy server (such as a policy server implemented as or with the conditional access termination service <NUM>) publishes one or more events <NUM> to the subscribers (e.g., the resource provider <NUM>) for this entity <NUM>. At least one of the events <NUM> contains the action that the subscribers need to perform to comply with the policy and the client ID for the removed application.

As discussed above, in some embodiments events <NUM> may be issued from the conditional access termination service <NUM> to the resource provider <NUM> based on user state changes. For example, such changes may be based on changes to user attributes. For example, one or more events <NUM> may be emitted if a password is reset or changed. Alternatively or additionally, one or more events <NUM> may be emitted if a user account is disabled or deleted. Alternatively or additionally, one or more events <NUM> may be emitted if a compromised user is detected, etc..

As discussed above, in some embodiments events <NUM> may be issued from the conditional access termination service <NUM> to the resource provider <NUM> based on session state changes. For example, an administrator may revoke a user session. Alternatively or additionally, a policy server may detect an increase in a session's risk level. Such increased risk may be detected, for example, as a result of detecting that a device is on a certain network, located in a certain location, unusual input is being input at a device, or simply that risk conditions have generally increased, or based on other detected occurrences.

As discussed above, in some embodiments events <NUM> may be issued from the conditional access termination service <NUM> to the resource provider <NUM> based on policy state changes. For example, an administrator may change memberships or roles for a user, resulting in one or more events <NUM> being issued.

When events are to be issued (as illustrated in the examples above, or for other reasons), a policy server (such as is illustrated by the conditional access termination service <NUM>) publishes one or more events <NUM> to the subscribers (e.g., resource provider <NUM>) for this user. Note that while a single resource provider subscriber is illustrated in <FIG>, it should be appreciated that multiple subscribers can subscribe to relevant events for a particular entity. Note that event can be emitted by the subscription publication service in a selective fashion to multiple subscribes. That is, in some embodiments, subscribers will only receive events relevant to them. Thus, some events will be sent to all subscribers for an entity, while other events will be sent only to relevant subscribers. In other embodiments, all events are sent to all subscribers for an entity, and the burden for determining if an event is relevant for a resource provider is pushed to the resource provider.

The events <NUM> contains the action(s) that the subscribers need to perform to comply with a particular policy. For example, an action specified in an event may include revoking the session and redirecting the user back to the identity provider <NUM>. Alternatively or additionally, an action specified in an event may include blocking access to certain resources (or types of resources) or providing limited access (e.g., read only) to certain resources (or types of resources). Alternatively or additionally, conditions may be included in the event, such that the action included in the event may include revoking the session and redirecting the user back to the identity provider <NUM> if a condition is met, etc..

In some embodiments, the events <NUM> contain timestamps. In some embodiments, a condition, either included in an event itself or implemented on all events due to programmatic event handing protocols, causes the action in the events <NUM> to be performed only if the access token was issued prior to a particular event being evaluated. For example, in one embodiment, the resource provider <NUM> compares the timestamps in one or more the events <NUM> with when the access token <NUM> was issued and applies the actions in the events <NUM> only if the access token was issued prior to the timestamps in the events.

On redirection the identity provider <NUM> can perform various actions depending on the policy setting, such as displaying a suitable message to the user, prompting the user for stronger authorization, issuing a new access token to the user with the 'limited access' claim that can be used by resource provider <NUM> to restrict access to sensitive data, or combinations thereof.

Referring now to <FIG>, a method <NUM> is illustrated. The method <NUM> includes acts for managing an authenticated user session. The method includes a resource provider computer system subscribing to a conditional access termination service for an entity configured to obtain resources from the resource provider through a user session (act <NUM>). For example, <FIG> illustrate the resource provider <NUM> subscribing to the conditional access termination service <NUM>.

The resource provider computer system receives an event for the entity from the conditional access termination service (act <NUM>). For example, <FIG> illustrates the events <NUM>.

The resource provider computer system receives a request for resources from the entity (act <NUM>). For example, <FIG> illustrates the request <NUM> which includes, or is at least associated with the access token <NUM>.

The resource provider computer system evaluates the request with respect to the event (act <NUM>).

The resource provider computer system responds to the request based on evaluating the request with respect to the event (act <NUM>).

The method <NUM> may be practiced where the event comprises at least one of user information, a condition, a timestamp, or an action.

The method <NUM> may be practiced where the event comprises an action indicating an action that should be performed by the resource provider with respect to the entity. For example, such actions may include revoking the user session and redirecting the entity to an identity provider for reauthentication. Alternatively, the action may include limiting the entity's access to resources. For example, the resource provider may be directed to block access to all files, block access to certain files, only allow only certain files, etc..

In some embodiments, the event identifies one or more conditions to be evaluated for the resource provider computer system to perform an action. For example, the one or more conditions may be based on an authentication level. For example, an event may indicate that an action should occur if an access token is presented with a certain authentication level, or not having a certain authentication level. For example, the event may specify that if the entity presents an access token obtained using a simple identity and secret authentication procedure, then the user session should be revoked and the entity should be redirected to an identity provider to reauthenticate. Alternatively or additionally, the event may indicate any authentication procedure used to obtain the access token other than (or less secure than) double factor authentication should cause the resource provider to revoke the user session and redirect the entity to the identity provider to reauthenticate. Similar conditions can be indicated for length of password, reuse of passwords, or for other reasons.

Alternatively or additionally, the one or more conditions may be based on a timestamp. For example, in one embodiment, the resource provider compares the timestamps in one or more the events with when the access token was issued and applies the actions in the events only if the access token was issued prior to the timestamps in the events. This allows for policy to be implemented at an identity provider at a particular time where access tokens issued after the particular time will not need to be refreshed as a result of an event.

Alternatively or additionally, the one or more conditions may be based on a client used by the entity. For example, if a policy server determines that a user's desktop client has been compromised, the condition may specify that if a token is for a desktop client, then the action should be taken. However, if the user uses a token for a mobile client, the action will not be taken. In some embodiments, the event may specify a specific device ID, which can be used as a condition for evaluation.

The method <NUM> may be practiced where the resource provider subscribing to the conditional access termination service for the entity is performed based on the entity consenting to the resource provider subscribing to the conditional access termination service for the entity. As illustrated in <FIG>, in some embodiments consent may be provided directly by the entity <NUM> providing consent <NUM> directly to the conditional access termination service <NUM>. For example, the entity <NUM> could send a message to the conditional access termination service <NUM> indicating which service providers have consent to subscribe to the conditional access termination service <NUM> with respect to the entity <NUM>.

Alternatively or additionally, As illustrated in <FIG>, the entity may provide consent <NUM> to an application <NUM>, and the application <NUM> may notify the conditional access termination service <NUM> that the consent is provided. For example, in some embodiments, the application <NUM> may include a user interface that allows a user to provide the consent as part of the configuration of the application <NUM>.

Alternatively or additionally, as illustrated in <FIG>, the consent <NUM> may be provided by the entity <NUM> consenting to a first-party application <NUM> for a different third-party application <NUM>. For example, a user may use their Contoso (a fictional company used for illustration herein) credentials, in a single sign-on scenario, which can be used to authenticate to a third-party application not directly controlled by Contoso. The entity will consent to a first-party Contoso application for the third-party application, thus allowing subscriptions for the entity for the third-party application. For example, <FIG> illustrates that the consent <NUM> can be provided to the first-party application <NUM>. The first-party application can notify the third-party application <NUM> of the consent (which can then notify the conditional access termination service <NUM> of the consent <NUM>) or can notify the conditional access termination service <NUM> directly of the consent <NUM>.

In some embodiments, as illustrated in <FIG>, consent may be provided by an administrator for a group of entities including the entity. In the example illustrated in <FIG>, the administrator <NUM> provides consent <NUM>' to the conditional access termination service <NUM> on behalf of a set <NUM>' of entities over which the administrator has control. While the example illustrated in <FIG> shows consent provided directly to the conditional access termination service <NUM>, it should be appreciated that in other embodiments, the consent may be provided to applications such as is illustrated in <FIG>, or other entities.

Referring now to <FIG> method of managing an authenticated user session is illustrated. The method includes, at a conditional access termination service, receiving a subscription request from a resource provider computer system computer system subscribing to the conditional access termination service for an entity configured to obtain resources from the resource provider computer system through a user session (act <NUM>).

The method <NUM> further includes, as a result, sending an event for the entity, related to resource requests, to the resource provider computer system that can be used by the resource provider computer system to evaluate requests for resources from the entity with respect to the event to respond to the requests for resources by the entity as a result of evaluating the requests (act <NUM>).

The method <NUM> may be practiced where the event comprises an action indicating an action that should be performed by the resource provider computer system with respect to the entity. For example, the action may include revoking the user session and redirecting the entity to an identity provider for reauthentication. Alternatively or additionally, the action may include limiting the entity's access to resources.

The method <NUM> may be practiced where the event identifies one or more conditions to be evaluated for the resource provider computer system to perform the action. In some embodiments, the one or more conditions may be based on an authentication level. Alternatively or additionally, the one or more conditions may be based on a timestamp. the one or more conditions may be based on a client used by the entity.

The method <NUM> may further include the conditional access termination service permitting subscriptions based on consent being provided for the entity for the resource provider to subscribe to the conditional access termination service for the entity. In some embodiments, consent is provided by an administrator for a group of entities including the entity.

Having just described the various features and functionalities of some of the disclosed embodiments, attention is now directed to <FIG>, which illustrates an example computer system <NUM> that may be used to facilitate the operations described herein. Computer systems, such as system <NUM> may be used to implement any of the computer systems described above.

The methods may be practiced by a computer system <NUM> including one or more processors <NUM> and computer-readable storage <NUM> such as computer memory. In particular, the computer memory may store computer-executable instructions that when executed by one or more processors <NUM> cause various functions to be performed, such as the acts recited in the embodiments.

Embodiments within the scope of the present invention also include physical and other computer-readable media, such as the storage <NUM>, for carrying or storing computer-executable instructions, data structures, or combinations thereof.

A "network" (e.g., network <NUM>) is defined as one or more data links that enable the transport of electronic data between computer systems, modules, other electronic devices, or combinations thereof. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer (e.g., remote system <NUM>), the computer properly views the connection as a transmission medium. Transmissions media can include a network, or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM, to less volatile computer-readable physical storage media at a computer system, or combinations thereof.

Although the subject matter has been described in language specific to structural features, methodological acts, or combinations thereof, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above.

Claim 1:
A method (<NUM>) of managing an authenticated user session, the method comprising:
at a conditional access termination service (<NUM>), receiving (<NUM>) a subscription request (<NUM>) from a resource provider computer system (<NUM>) subscribing to the conditional access termination service for an entity (<NUM>) configured to obtain resources (<NUM>) from the resource provider computer system through a user session; and
in response to the receiving, sending (<NUM>) an event (<NUM>) for the entity to the resource provider computer system,
the event comprising an action, the action comprising at least one of revoking the user session and redirecting the entity to an identity provider (<NUM>) for reauthentication or limiting the entity's access to resources (<NUM>),
wherein the event identifies one or more conditions to be evaluated for the resource provider computer system to perform the action, and
wherein the resource provider computer system is adapted to evaluate and respond to requests for resources with respect to the event.