Rich token rejection system

Abstract

Authenticated computing entity. A method includes: at an identity provider, providing a first access token to an entity for use by the entity when obtaining a resource from a resource provider. The method further includes: at the identity provider, receiving response information from the entity. As a result of enforcing a policy at the resource provider at the resource provider, the response information from the entity is provided to the entity from the resource provider. At the identity provider, a second access token is provided to the entity. The second access token is provided based on the response information such that the second access token can be used by the entity to obtain a resource from the resource provider.

Description

Background Art

[0001] Computers and computing systems have influenced almost every aspect of modern life. Computers are generally involved in work, leisure, healthcare, transportation, entertainment, household management, etc.

[0002] Furthermore, the functionality of a computing system can be enhanced by the ability of the computing system to interconnect with other computing systems via a network connection. The network connection can include, but is not limited to, a connection via wired or wireless Ethernet, a cellular connection, or even a computer-to-computer connection via serial, parallel, USB, or other connections. These connections allow the computing system to access services at other computing systems and quickly and effectively receive application data from other computing systems.

[0003] 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 typically utilizes an identity provider for authentication 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 user session is created between the resource provider and the entity to provide the resources.

[0004] However, typically the identity provider and the resource provider do not have a communication channel for communicating with each other for each initiated user session. Instead, both the identity provider and the resource provider have their own communication with the entity when facilitating the user session, but do not have the ability to communicate with each other with respect to the user session when the user session is created or after the user session has been created.

[0005] The technical solutions claimed herein are not limited to solving any disadvantages or to embodiments that operate only in environments such as those described above. Instead, this background is provided only to illustrate an exemplary technical field in which some of the embodiments described herein may be practiced. Summary of the Invention

[0006] One embodiment illustrated herein includes a method that can be practiced in a computing environment. The method includes actions for authenticating a computing entity. The method includes: at an identity provider, providing a first access token to the entity for use by the entity when obtaining resources from a resource provider. The method further includes: at the identity provider, receiving response information from the entity. As a result of enforcing a policy at the resource provider at the resource provider, the response information from the entity is provided to the entity from the resource provider. At the identity provider, a second access token is provided to the entity. The second access token is provided based on the response information such that the second access token can be used by the entity to obtain resources from the resource provider.

[0007] The present invention is provided to introduce, in simplified form, a selection of concepts that are further described below in the detailed description. The present invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to assist in determining the scope of the claimed subject matter.

[0008] Additional features and advantages will be set forth in the following description, and in part will be obvious from the description, or may be learned by practice of the teachings herein. The features and advantages of the present invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims. The features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention set forth hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] To describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be presented by reference to specific embodiments illustrated in the accompanying drawings. It is to be understood that these drawings depict only typical embodiments and are therefore not to be considered limiting of its scope, and the embodiments will be described and explained with additional specificity and detail by use of the accompanying drawings, in which:

[0010] Figure 1 illustrates a system for enforcing system-wide policies;

[0011] Figure 2 illustrates a message flow diagram for enforcing system-wide policies;

[0012] Figure 3 illustrates a resource provider obtaining a policy for enforcement at the resource provider;

[0013] Figure 4 illustrates an administrator setting a policy at a policy portal;

[0014] Figure 5 illustrates a method for authenticating a computing entity;

[0015] Figure 6 illustrates a method for enforcing a policy; and

[0016] Figure 7 illustrates a computer system in which embodiments may be practiced. DETAILED DESCRIPTION

[0017] The embodiments illustrated herein relate to an intelligent client that can act as an intermediary to provide information from a resource provider to an identity provider. This allows and facilitates communication between the identity provider and the resource provider for a specific user session. Specifically, there is a technical problem in that the identity provider typically cannot obtain information about a user session from the resource provider and the user after the user session has been established. Generally, it is not feasible to configure the resource provider to enforce policies because doing so would affect the scalability of enterprise systems. Specifically, reconfiguring the resource provider in terms of computing resources and administrative resources is expensive whenever there is a policy change or whenever there is a change that requires revocation of a user session. As the number of resource providers in such a system increases, the cost in terms of computing resources and administrative resources also increases proportionally. Thus, a system that requires reconfiguring each resource provider computer system necessarily needs to limit the number of resource provider computer systems that can be implemented. Further, requiring reconfiguring each resource provider would require a system that can track and manage all resource providers in a way that allows them to be reconfigured. Further, requiring reconfiguring each resource provider would actually take more time compared to simply allowing a token to expire, thus negating any benefits achieved by reconfiguring the resource provider computer system. Thus, there is a need for a system that allows a highly scalable number of resource providers to be added to an enterprise system while still being able to address the need to invalidate unexpired tokens. This may be particularly important in cloud-based systems where resource providers can be added quickly, unless external constraints such as those illustrated above are placed on the system.

[0018] The embodiments illustrated herein can solve this technical problem by implementing technical means for transmitting computer messages using computer hardware, where the messages include information from the resource provider to the user during a user session, and where the information is further passed to the identity provider, thus facilitating communication from the resource provider to the identity provider during the user session. That is, in one practical application of the present invention, communication from the resource provider to the identity provider is facilitated during an active user session between the resource provider and an entity attempting to obtain a resource from the resource provider. It may be important that the identity provider that authenticates the entity and acts as a central policy agency is the same entity that receives response information from the resource provider. This allows the central policy agency to manage the policies of the entities for a specific user session in a closed-loop manner, where the identity provider receives feedback regarding policy enforcement from the resource provider. In contrast, prior systems were open-loop because the policy was enforced at the identity provider in a limited way; by determining whether to issue a token. Once the token was issued, the identity provider could not obtain any additional information regarding how the policy was being enforced.

[0019] For example, in some embodiments, this problem is solved where the resource provider can provide information to the entity indicating why an access token from the entity has been rejected. This provides response information to the identity provider indicating how the policy is being enforced. In some embodiments, the entity can use this information to understand why the token was rejected and respond accordingly. For example, if the information indicates that the entity requires a higher level of authentication, the entity can use a higher level of authentication to obtain a new access token from the identity provider. In some embodiments, as part of this process, the entity can indicate to the identity provider that the information has been received from the resource provider, which indicates that a higher level of authentication than that used in the current user session is required.

[0020] Alternatively, in some embodiments, the information can simply be provided to the entity, and the entity will not use the information but simply pass the information back to the identity provider, which can respond accordingly. For example, the identity provider can issue a new access token to the entity to correct the problem identified by the information provider. This new access token can be used by the entity to access resources at the resource provider.

[0021] Now referring to Figure 1 , an example is illustrated. Figure 1 Entity 102 is illustrated. In the example illustrated, entity 102 can include a user, a device, and an associated client used by the user on the device. Note that the user is not necessarily a human user. Entity 102 may need access to resources from resource provider 104. Resource provider 104 is a computer system configured to manage computing resources for users. The resources can be stored at resource provider 104 or can be obtained by resource provider 104 from other sources.

[0022] To obtain access to the resources, the entity will first authenticate with identity provider 106. Identity provider 106 is a computing system configured to manage policies and issue cryptographic tokens to entities to allow the entities to access resources from resource providers. Entity 102 can authenticate with identity provider 106 using any one of a variety 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. It can be said that in the Figure 1 specific example shown, entity 102 receives access token 108 and refresh token 110 from identity provider 106 as a result of identity provider 106 enforcing a system-wide token issuance policy, and the access token is issued.

[0023] The access token 108 typically includes a timestamp indicating when the access token was issued. The access token 108 may alternatively or additionally include information indicating when the access token 108 expires. In some embodiments, the access token 108 may include information about the authentication procedure used by the entity 102 to authenticate to the identity provider 106. For example, the access token 108 may indicate that the access token 108 was obtained by the entity 102 authenticating to the identity provider 106 using a simple user identification and secret authentication protocol. One such common protocol is the password authentication protocol, where the identity is the username and the secret is the password. Alternatively or additionally, if the entity 102 uses two-factor authentication to authenticate to the identity provider 106, this may be indicated in the access token 108. Alternatively or additionally, if the entity 102 uses a password of a certain strength to authenticate to the identity provider, such information may be indicated in the access token 108 itself. For example, the access token may indicate the minimum length of the password used to authenticate to the identity provider, the use of special characters in the password used to authenticate to the identity provider, the use of uppercase and lowercase letters in the password used to authenticate to the identity provider, the absence of common passwords or other words in the password used to authenticate to the identity provider, etc.

[0024] In some embodiments, the access token 108 will be for a specific user and for the client used by the specific user. Thus, in this example, the entity 102 includes both the user and the client (e.g., an application) used by the user. For example, a user may use a laptop to perform authentication and resource requests with a corresponding laptop client. Thus, the access token 108 may include information about the laptop client of the entity 102. Alternatively, a user may use a smart phone to perform authentication, in which case the corresponding smart phone client is used to perform authentication and perform resource requests, meaning the access token 108 will be for the entity 102 that includes the user using the smart phone client.

[0025] Returning again Figure 1 Referring to the example illustrated, the entity 102 may provide the access token 108 to the resource provider 104 in a request for a resource from the resource provider 104. The resource provider 104 may evaluate the access token to determine that the entity 102 has properly authenticated to the identity provider 106 and that the access token 108 is otherwise valid. Specifically, the access token 108 may have an expiration period, and the resource provider 104 may determine that the access token 108 has not expired. Generally, as long as this evaluation of the access token 108 passes various checks, then the resource 112 will be provided to the entity 102. However, the embodiments illustrated herein may implement functionality with respect to the request 111 of the entity 102 to the resource provider 104.

[0026] Specifically, Figure 1 It is illustrated that the resource provider 104 can provide response information 117 to the entity 102. Specifically, this information can be transmitted in various messages using various communication hardware at the resource provider 104 and the communication hardware at the entity 102. Generally, the response information 117 is provided as part of a request 111 for a resource.

[0027] Figure 1 It is also illustrated that the entity 102 can pass the response information 117 to the identity provider 106. In some embodiments, this can be done by an entity participating in the authentication process of authenticating the entity to the identity provider. For example, the resource provider 104 can terminate the user session of the entity 102. As part of the termination (or in some embodiments, deny the access token 108), the resource provider can provide the response information 117. In this particular example, the resource provider 104 terminates the user session with the entity 102 (or denies the attempt of the entity 102 to establish a user session) and provides the response information 117 as part of this process.

[0028] In some embodiments, the entity will then be redirected back to the identity provider 106 to obtain a different access token through the authentication process. As part of this process, the entity 102 can provide the response information 117 to the identity provider 106. The identity provider 106 can issue a subsequent access token based on the response information 117 passed by the entity 102 to the information provider 106. For example, the resource provider 104 can provide the response information 117 indicating that the entity 102 requires a higher level of authentication than that used to obtain the access token 108 to access certain resources at the resource provider 104. This response information 117 can be passed to the identity provider 106, and then the entity 102 can be authenticated using a higher level of authentication than that previously used to issue the new access token, and the new access token can be used by the entity 102 to access the resources 112 at the resource provider 104.

[0029] Now referring to Figure 2 , a more detailed example is illustrated. In Figure 2 the example illustrated, the identity provider 106, the entity 102, and the resource provider 104 are illustrated. First, the identity provider 106 and the entity 102 participate in an authentication protocol by exchanging authentication protocol messages 115. This results in the access token 108-1 being issued by the identity provider 106 to the entity 102.

[0030] Subsequently, access token 108-1 is used in request 108-1 to request resource 112. The resource provider 104 may determine for some reason that resource 112 cannot be provided. For example, as previously illustrated, for the resource type requested by entity 102, access token 108-1 may not use a strong enough authentication method to be obtained. The resource provider 104 may issue a response 116 that includes response information 117 indicating the reason why a user session cannot be created between the resource provider 104 and entity 102. For example, as illustrated above, the response information 117 may indicate that entity 102 did not use token 108-1, which has been obtained using sufficient authentication methods.

[0031] In some embodiments, entity 102 is able to access and read the response information 117 in response 116. That is, entity 102 can be made aware of the reason why the user session was rejected by the resource provider 104, even though entity 102 presented a valid access token 108-1 to the resource provider 104. This can allow entity 102 to respond to this situation in any programming manner implemented at entity 102.

[0032] Note that although Figure 2 it is illustrated that the response information 117 is provided in response 116 to the request for resource 112, the response information 117 can be provided during an existing user session if certain conditions have been met or the resource provider otherwise determines that the response information 117 should be provided to the identity provider 106 via entity 102.

[0033] Finally, the response information 117 is passed to the identity provider 106, thereby transferring information from the resource provider 104 to the identity provider 106 for a particular user session, even if the user session is an invalid user session that was never fully established or whose establishment later expired.

[0034] As Figure 2 illustrated, in some embodiments, the response information 117 is passed by entity 102 to the identity provider 104 as part of a new set of authentication protocol messages 115-2. The identity provider 106 will use the response information 117 to create a new access token 108-2. Then, as a result of the authentication protocol messages 115-2 and the response information 117, the new access token 108-2 is provided to entity 102.

[0035] Entity 102 can send request 111-2 along with access token 108-2 to the resource provider 104. The resource provider 104 can evaluate token 108-2 and determine that token 108-2 is sufficient (e.g., obtained using multi-factor authentication) to obtain resource 112. As a result, the resource provider 104 can provide resource 112 to entity 102.

[0036] Thus, in some embodiments, the resource provider 104 will need to explain to the identity provider 106 the reasons for certain actions being taken. For example, the resource provider 104 may generally require a certain level of authentication, or for accessing certain resources. For example, the entity 102 may request access to information that requires a higher level of authentication than other information. Thus, the embodiments herein can use the illustrated modality to convey such response information 117 or other information from the identity provider 106 to the resource provider 104.

[0037] In one example, the resource provider 104 can indicate certain response information 117 to the entity 102. For example, the resource provider 104 can indicate to the entity 102 that a higher level of authentication is required to access certain resources requested by the entity. In this example, the entity 102 can use the response information 117 provided by the resource provider 104 to indicate to the identity provider 106 that something from the identity provider 106 is needed. For example, the entity 102 can indicate to the identity provider 106 that the entity 102 needs multi-factor authentication to access certain resources at the resource provider 104. The identity provider 106 can then use the multi-factor authentication protocol to authenticate the entity 102 to provide the entity 102 with a token 108-2 issued as a result of the multi-factor authentication protocol.

[0038] In some embodiments, the entity 102 will not consume the information passed from the resource provider 104 to the entity 102. In fact, in some embodiments, the response information cannot be consumed by the entity 102 because the entity cannot decrypt or otherwise directly use the information. Instead, the entity 102 will simply pass the information to the identity provider 106, and the identity provider 106 can act accordingly. Thus, for example, in some embodiments, the entity 102 may not know that a higher level of authentication is required. Instead, the resource provider 104 will simply indicate to the entity 102 that it cannot provide the resources requested by the entity 102. Additionally, the resource provider 104 will provide the entity 102 with a message intended to be passed to the identity provider 106, where the message includes the response information 117 indicating that a higher level of authentication is required. In some embodiments, the resource provider 104 can simply terminate the user session with the user and direct the user, along with the message including the response information 117 (i.e., the higher level of authentication or other requirements from the identity provider 106) communicated from the resource provider 104 to the identity provider 106 by the entity 102, back to the identity provider 106. The identity provider 106 can then respond accordingly based on the response information 117 provided by the resource provider 104 to authenticate the entity 102 to allow the entity 102 to access the resources at the resource provider 104 using the token issued by the identity provider 106.

[0039] However, it should be understood that in some embodiments, entity 102 may consume response information 117 provided to entity 102 by resource provider 104. For example, in addition to passing response information 117 back to identity provider 106, entity 102 may include programming functionality to perform certain actions as a result of receiving response information 117.

[0040] Typically, identity provider 106 manages and enforces enterprise-wide policies by authenticating entities and making decisions about whether to issue access tokens to entities, and resource provider 104 does not have a communication channel to communicate with each other on a per-user-session basis for each user session initiated for an entity. However, the embodiments illustrated herein allow for such communication for each user session. Specifically, resource provider 104 may provide response information 117 to identity provider 106 for a user session, and identity provider 106 may provide information to resource provider 104 via the information included in token 108 issued to entity 102. In this way, user session information can be provided from resource provider 104 to identity provider 106 in the form of response information 117, and vice versa. Thus, the embodiments can address issues related to the absence of a direct link from resource provider 104 to identity provider 106 for a particular user session.

[0041] Now referring Figure 3 , resource provider 104 may obtain policies from multiple different locations. In some embodiments, the policy may be used in the process of generating Figure 2 the illustrated response information 117. For example, Figure 3 illustrates policy 114 being provided from identity provider 106 to resource provider 104. Then the policy 114 may be used to evaluate a request from entity 102 to determine whether the request for the resource can be honored, and if the request for the resource cannot be honored, resource provider 104 may provide response information 117 to response 116 that indicates why entity 102 was denied access to resource 112.

[0042] Figure 3 Illustrates an alternative source of policy information. In some embodiments, resource provider 104 may subscribe to a publishing service 113, which may be a centralized location where policies can be established. Thus, resource provider 104 may subscribe to publishing service 113 to obtain events 118, which may contain or identify policies to be managed by resource provider 104.

[0043] Typically, an event, policy, or combination thereof will include one or more of the following: entity information, conditions, timestamps, or actions.

[0044] The entity information included in the event may include information identifying a specific user of entity 102, device information of entity 102, client information of entity 102, user role information of entity 102 (e.g., whether the user acts as an administrator or other special authoritative user), member information of entity 102, etc.

[0045] The condition information included in the event may include one or more conditions that should be evaluated to determine whether a specific action should be taken.

[0046] The timestamp included in the event may indicate the time when the event was published (or some other important time). Alternatively or additionally, the event may include a timestamp identifying the time that should be conditionally evaluated.

[0047] The action included in the event indicates the action that should be taken with respect to the event. It should be noted that in some embodiments, the action is conditional, meaning that a specific action should be taken only when a specific condition is met.

[0048] Various examples are now illustrated.

[0049] As discussed above, in some embodiments, event 118 may be published from publishing service 113 to resource provider 104, or a policy may be published from identity provider 106 based on a device state change. Specifically, publishing service 113 may be notified of changes to the device of entity 102. This may be facilitated by entity 102 registering with a specific management service, periodic messages from entity 102, or general knowledge of the type of device used by entity 102 having been generally or otherwise changed. Thus, it should be noted that publishing service 113 may be connected to other systems through various interconnections, and these systems may provide information about changes to the device state of entity 102 such that appropriate events 118 may be published.

[0050] The following illustrates a specific scenario, showing an example of a device state change. In this example, administrator 120 (see Figure 3)The policy (in the policy portal 119 at the identity provider 106, the publishing service 113, or a combination thereof) has been configured to require compliant (since it complies with the system policy) and healthy (since it operates within some predefined functional criteria) devices as a condition for data access. The identity provider 106 extends the ability to associate application sessions with device IDs to the resource provider. In this case, the publishing service 113, which is the policy server, learns that the user's device has become non-compliant, has a virus, or fails to meet the policy. Therefore, the policy server publishes an event 118 to the user's subscribers (such as the resource provider 104). The event contains the conditional actions that the subscriber needs to perform to comply with the policy. In this example, the condition is the device ID of the non-compliant device. Therefore, the resource provider can terminate the user session and provide response information 117 for use by entities using the device, the identity provider, or a combination thereof.

[0051] As discussed above, in some embodiments, the event 118 can be published from the publishing service 113, or the policy can be published from the identity provider 106 to the resource provider 104 based on changes to the client application. Specifically, then, changes to the client application can be detected by the policy server (such as the publishing service 114 or the identity provider 106), and one or more events or policies can be sent to the resource provider (such as the resource provider 104). Such changes to the client application may include updates to the client application (such as a new version), configuration changes to the client application, administrator revocation, etc.

[0052] 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 applications for a tenant (in this example, the tenant is the entity 102). The policy server (such as the policy server implemented as or in conjunction with the publishing service 113 or the identity provider 106) publishes one or more events 118 or policies 114 to the subscribers of the entity 102 (such as the resource provider 104). At least one of the event 118 or the policy 118 contains the actions that the subscriber needs to perform to comply with the policy and the client ID of the removed application. The resource provider 104 can then terminate the user session with the entity 102 and provide response information 117 indicating that the user session has been terminated due to the client application change.

[0053] As discussed above, in some embodiments, event 118 can be published from the publishing service 113, or a policy can be published from the identity provider 106 to the resource provider 104 based on a user state change. For example, such a change can be based on a change in user attributes. For example, if the password is reset or changed, one or more events 118 or policies 114 can be issued. Alternatively or additionally, if the user account is disabled or deleted, one or more events 118 or policies can be issued. Alternatively or additionally, if a compromised user is detected, etc., one or more events 118 or policies can be issued. Again, this may cause the resource provider 104 to terminate the user session and provide the response information 117 illustrated above, indicating that the user session has been terminated due to a user state change.

[0054] As discussed above, in some embodiments, event 118 can be published from the publishing service 113, or a policy can be published from the identity provider 106 to the resource provider 104 based on a session state change. For example, an administrator can revoke a user session. Alternatively or additionally, the policy server can detect an increase in the session risk level. For example, such an increased risk can be detected, for example, due to detecting that the device is on a certain network, located at a certain location, abnormal input is entered at the device, or simply due to a general increase in risk conditions, or based on other detected events. This may cause the resource provider 104 to terminate the user session and provide the response information 117 illustrated above, indicating that the user session has been terminated due to a session state change.

[0055] As discussed above, in some embodiments, event 118 can be published from the publishing service 113, or a policy can be published from the identity provider 106 to the resource provider 104 based on a policy state change. For example, an administrator can change the membership or role of a user, resulting in the publication of one or more events 118 or policies 114. This may ultimately cause the resource provider 104 to terminate the user session and publish the response information 117 indicating that the user session has been terminated due to a policy state change.

[0056] When an event or policy is to be published (as illustrated in the above examples, or for other reasons), the policy server (such as illustrated by the publishing service 113 or the identity provider 106) publishes one or more events 118 or policies 114 to the subscribers of that user (such as the resource provider 104). Note that while a single resource provider is Figure 1Shown in the figure, but it should be understood that multiple resource providers can receive relevant events or policies for a specific entity. Note that events or policies can be sent by the publishing service 113 or the identity provider 106 to multiple resource providers in a selective manner. That is, in some embodiments, resource providers will only receive events or policies relevant to them. Therefore, some events or policies will be sent to all resource providers for an entity, while other events or policies will only be sent to the relevant resource providers. In other embodiments, all events or policies are sent to all resource providers for an entity, and the burden of determining whether an event or policy is relevant to a resource provider is pushed to the resource provider.

[0057] The event 118 or policy contains the action(s) that the resource provider needs to perform to comply with a specific policy. For example, the actions specified in an event can include revoking a session and redirecting the user back to the identity provider 106. Alternatively or additionally, the actions specified in an event can include blocking access to certain resources (or resource types) or providing limited access (e.g., read-only) to certain resources (or resource types). Alternatively or additionally, conditions can be included in the event such that the actions included in the event can include revoking a session and redirecting the user back to the identity provider 106 if the condition is met, etc. These actions can also include identifying what information should be included in the response information 117.

[0058] In some embodiments, the event 118 or policy 114 contains a timestamp. In some embodiments, conditions included in the event or policy itself or imposed on all events or policies due to a programmed event handling protocol cause the actions in the event or policy to be executed only if the access token was issued before the specific event or policy being evaluated. For example, in one embodiment, the resource provider 104 compares the timestamp in one or more events 118 or policies 114 with the time the access token 108 was issued, and applies the actions in the event 118 or policy only if the access token was issued before the timestamp in the event.

[0059] Upon redirection, the identity provider 106 can perform various actions depending on the policy settings, the response information 117, or a combination thereof, such as displaying an appropriate message to the user, prompting the user for stronger authorization, issuing a new access token to a user with a 'limited access' claim (which can be used by the resource provider 104 to restrict access to sensitive data), or a combination thereof.

[0060] Some embodiments may have location-based policies that need to be enforced. For example, an enterprise may need to implement different levels of protection when a user attempts to access a resource from within a trusted network compared to when attempting to access the resource from an untrusted network. For example, a trusted network is a regular corporate intranet used by the enterprise, so a greater level of security and a lower level of risk can be assumed. Thus, when an entity attempts to access certain resources from the corporate intranet, the enterprise may wish to allow access to those resources. For the same resources, when an entity attempts to access the resources from outside the corporate intranet, those entities may be blocked.

[0061] Alternatively, it may be desirable to obtain additional authentication to allow access to the same resources outside the corporate intranet. For example, if entity 102 attempts to access resource 112 on a system outside the corporate intranet, some embodiments may require multi-factor authentication. To achieve this, policy 114 is implemented at resource provider 104. For example, resource provider 104 can determine whether access token 108 was issued using multi-factor authentication and whether entity 102 is attempting to access resource 112 outside the corporate intranet. If entity 102 attempts to access resource 112 from outside the corporate intranet using access token 108 (issued using single-factor authentication), then resource provider 104 can invalidate the user session and cause entity 102 to re-authenticate with identity provider 106 to obtain an access token issued using multi-factor authentication. This can be indicated in response message 117.

[0062] Note that by having identity provider 106 provide policy 114 to resource provider 104, it should be understood that identity provider 106 can provide policy 114 to any resource provider associated with policy 114. This creates a scalable system that can quickly and effectively distribute policies to resource providers as needed. This eliminates the need to manually configure various resource providers and the applications running on those resource providers or the entities attempting to access resources from the resource providers. This allows the system to scale effectively.

[0063] Specifically, an administrator only needs to configure the policy in the identity provider portal.

[0064] Additionally, if an administrator attempts to configure certain policies, such as multi-factor authentication, at the resource provider, they cannot do so because the resource provider does not support certain functionality and understanding related to multi-factor authentication itself or other types of authentication. The resource provider is limited to providing access or blocking access.

[0065] Greater granularity can be achieved in policy enforcement by using an identity provider configuration policy. For example, different authentication methods may be configurable. Additionally, using the identity provider to receive administrator input to configure policies allows the administrator to globally manage policies in a central location.

[0066] Accordingly, embodiments herein are able to address this situation by allowing a resource provider to download policies from an identity provider. In other words, the identity provider can share the administrator-configured policies with the resource provider. At this point, the resource provider has the policies and can directly enforce the policies against the user when the user attempts to access resources at the resource provider.

[0067] For example, in some of the above embodiments, the resource provider can determine whether the user is attempting to access a resource from a trusted location or an untrusted location. If the user attempts to access a resource from an untrusted location, the resource provider can directly apply the policy associated with the attempt to access the resource from the untrusted location. For example, if the user attempts to access a resource from an untrusted location using an access token obtained in a manner that does not conform to accessing from the untrusted location (e.g., the token was obtained using single-factor authentication), then the resource provider can terminate the user session, thereby invalidating the token, and direct the user back to the identity provider to obtain appropriate credentials (e.g., using multi-factor authentication to obtain a token) to access the resource from the untrusted location according to the policies configured by the administrator.

[0068] In some embodiments, the policy can be based on the user's behavior pattern. For example, such behavior patterns can include typing speed, typical patterns of typing errors, intervals between various user inputs, machine usage patterns, application usage patterns, etc. The administrator 120 can configure a policy at the identity provider 106 that indicates that additional authentication is required to access a resource when the risk level is increasing due to an unexpected user behavior pattern. As illustrated above, the policy can be provided from the identity provider 106 to the resource provider such that the resource provider 104 can enforce the policy when an anomaly is detected in the user behavior pattern. Specifically, the user behavior pattern is not easily detected by the identity provider 106 because the interaction between the identity provider 106 and the entity 102 is very limited. That is, the entity 102 performs a limited interaction with the identity provider 106 to obtain the access token 110 and then uses the access token 110 at the resource provider 104 to access the resource 112 where a richer sequence of interactions is performed. In this way, the resource provider 104 is more suitable for enforcing the behavior pattern policy.

[0069] However, using the previously illustrated modality, Policy 114 can still be configured at the identity provider 106 and subsequently provided to the resource provider 104 for direct enforcement at the resource provider 104. For example, consider an example where entity 102 interacts extensively with the resource provider 104. For example, this may occur when the entity uses a web-based application. For example, if the entity is using a web-based email application, a web-based word processor, a web-based spreadsheet, or even a web-based office suite, the user behavior patterns are obvious to the resource provider 104 that provides the web-based resources. Specifically, the resource provider 104 can easily detect typing speed, typing errors, switching between applications, or other behavior patterns. These patterns can be compared with the previous patterns exhibited by entity 102 to detect significant deviations from the previous patterns. When such a significant deviation occurs, the resource provider 104 can consult the previously provided Policy 114 by the identity provider 106 to determine what action should be taken. For example, if entity 102 was previously authenticated using only single-factor authentication, as indicated in the access token 108 provided by the user, and Policy 114 indicates that when a threshold level of change in the user behavior pattern from the previous interaction has occurred, the session should be terminated, multi-factor authentication is required, or both. Note that the previous interaction can be measured as an aggregate and average pattern over all time, an aggregate and average pattern at a specific time, a sliding window of patterns, a manually configured pattern, a combination thereof, etc. The resource provider 104 can terminate the session and direct entity 102 back to the identity provider 106 to obtain multi-factor authentication to start a new session with the resource provider 104. Alternatively, the resource provider 104 may be able to determine that entity 102 has been authenticated using multi-factor authentication and can continue the session due to the current session, despite the significant change in the behavior pattern, still complying with the policy provided by the identity provider 106 to the resource provider 104.

[0070] In some embodiments, the access token 108 provided by the identity provider 106 to the entity 102 can include information indicating whether a policy 114 is configured for a particular entity 102. Specifically, not every entity will have a particular type of policy, such as a location policy or a behavior pattern policy or other policies associated with the entity. Thus, some embodiments can include functionality for issuing an access token that has extended information indicating whether the policy is configured for the particular entity bearing the token. Thus, for example, if the entity 102 has a policy configured for the entity 102 at the identity provider 106, the access token 108 for that entity 102 will indicate that there is a policy for the entity 102 at the identity provider 106. Thus, in some examples, when the access token 108 is provided to the resource provider 104 to attempt to obtain access to certain resources 112, the resource provider 104 can examine the access token 108 and determine that there is a policy for the entity 102 presenting the access token 108 at the identity provider 106. In such a case, the resource provider 104 can request the policy 114 from the identity provider 106 and then can enforce the policy 114 at the resource provider 104 for the entity 102 that provided the access token 108.

[0071] The following discussion now refers to a variety of methods and method acts that may be performed. While method acts may be discussed in a particular order or illustrated in a flowchart as occurring in a particular order, no particular order is required unless specifically stated, or required because an act depends on another act that is completed before that act is performed.

[0072] Now referring to Figure 5 , method 500 is illustrated. Method 500 may be practiced in a computing environment and includes acts for authenticating a computing entity. Method 500 includes, at an identity provider, providing a first access token to an entity for use by the entity in obtaining a resource from a resource provider (act 502).

[0073] Method 500 also includes, at the identity provider, receiving response information from the entity (act 504). As a result of enforcing a policy at the resource provider at the resource provider, the response information from the entity has been provided to the entity from the resource provider.

[0074] Method 500 also includes, at the resource provider, providing a second access token to the entity (act 506). The second access token is provided based on the response information. In this way, the second access token can be used by the entity to obtain a resource from the resource provider.

[0075] Method 500 may be practiced where the response information indicates that a higher level of authentication that was used to obtain the first access token is required for the entity to obtain a resource from the resource provider.

[0076] Method 500 may be practiced where the response information indicates that a policy regarding at least one of the following has been enforced: user state change, client state change, policy state change, conditional access, location, or behavior pattern.

[0077] Method 500 may be practiced where the response information indicates that a policy previously provided by an identity provider to a resource provider has been enforced.

[0078] Method 500 may be practiced where the response information indicates that a policy previously provided by a subscription service to a resource provider has been enforced.

[0079] Method 500 may be practiced where, in addition to information consumable by an identity provider, the response information includes information consumable by an entity.

[0080] Method 500 may be practiced where, as a result of a policy indicating that response information is required when enforcing a policy, the response information is provided.

[0081] Now referring Figure 6 , another method 600 is illustrated. Method 600 may be practiced in a computing environment and includes actions for enforcing a policy. Method 600 includes, at a resource provider, receiving a first access token in a request for a resource from an entity (action 602). The token is used by the entity when obtaining a resource from the resource provider. The token has previously been provided by an identity provider to the entity, which is configured to authenticate the entity and enforce a token issuance policy by determining whether to issue an access token to the entity according to a token issuance policy for the system.

[0082] Method 600 also includes, at the resource provider, determining that the request for the resource cannot be granted (action 604). For example, this may be the result of the resource provider enforcing a policy at the resource provider (such as a policy included in policy 114 or event 118).

[0083] Method 600 also includes, at the resource provider, sending response information to the entity (action 606). The response information provides information about why the request for the resource was not granted, such that the response information can later be provided to the identity provider.

[0084] Method 600 may also include receiving a second access token from the entity. As a result of the response information, the second access token has been issued from the identity provider to the entity.

[0085] Method 600 may be practiced where the response information indicates that obtaining a resource from the resource provider for the entity requires a higher level of authentication than that used to obtain the first access token.

[0086] Method 600 may be practiced where the response information indicates that a policy regarding at least one of: user state change, client state change, policy state change, conditional access, location, or behavior pattern has been enforced.

[0087] Method 600 may be practiced where the response information indicates that a policy previously provided by an identity provider to a resource provider has been enforced.

[0088] Method 600 may be practiced where the response information indicates that a policy previously provided by a subscription service to a resource provider has been enforced.

[0089] Method 600 may be practiced where, in addition to the information consumable by the identity provider, the response information includes information consumable by an entity.

[0090] Method 600 may be practiced where, as a result of a policy indicating that the response information is required when enforcing a policy, the response information is provided.

[0091] The various features and functionalities of some of the disclosed embodiments have just been described, and now attention turns to Figure 7 , Figure 7 illustrating an example computer system 700 that may be used to facilitate the operations described herein. A computer system such as system 700 may be used to implement any of the computer systems described above.

[0092] The method may be practiced by a computer system 700 including one or more processors 705 and a computer-readable storage device 725 (such as a computer memory). Specifically, the computer memory may store computer-executable instructions that, when executed by one or more processors 705, cause various functions to be performed, such as the actions recited in the embodiments.

[0093] Embodiments of the present invention may include or utilize a special-purpose or general-purpose computer including computer hardware, as discussed in more detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media, such as storage device 725, for carrying or storing computer-executable instructions, data structures, or combinations thereof. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. A computer-readable medium that stores computer-executable instructions is a physical storage medium. A computer-readable medium that carries computer-executable instructions is a transmission medium. Thus, by way of example and not limitation, embodiments of the present invention may include at least two distinct types of computer-readable media: physical computer-readable storage media and transmission computer-readable media.

[0094] A physical computer-readable storage medium includes RAM, ROM, EEPROM, CD-ROM, or other optical disc storage devices (such as CDs, DVDs, etc.), magnetic disk storage devices, or any other medium that can be used to store desired program code components in the form of computer-executable instructions or data structures and can be accessed by a general or special-purpose computer.

[0095] A "network" (such as network 735) is defined as one or more data links capable of transporting electronic data between computer systems, modules, other electronic devices, or combinations thereof. When information is transmitted or provided to a computer (such as remote system 740) via a network or another communication connection (wired, wireless, or a combination of wired and wireless), the computer correctly views the connection as a transmission medium. The transmission medium can include a network or a data link that can be used to carry desired program code components in the form of computer-executable instructions or data structures and can be accessed by a general or special-purpose computer. The above combinations are also included within the scope of computer-readable media.

[0096] Further, when reaching various computer system components, program code components in the form of computer-executable instructions or data structures can be automatically transferred from the transmission computer-readable medium to the physical computer-readable storage medium (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be buffered in RAM within a network interface module (such as a "NIC") and then ultimately transferred to the computer system RAM, less volatile computer-readable storage media at the computer system, or a combination thereof. Thus, computer-readable physical storage media can be included in computer system components that also (or even primarily) use the transmission medium.

[0097] For example, computer-executable instructions include instructions and data that cause a general-purpose computer, special-purpose computer, or special processing device to perform a specific function or group of functions. Computer-executable instructions can be, for example, binary, intermediate format instructions (such as assembly language), or even source code. Although the subject matter has been described in language specific to structural features, method acts, or combinations thereof, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above. Instead, the described features and acts are disclosed as example forms for implementing the claims.

[0098] Those skilled in the art will appreciate that the present invention may be practiced in network computing environments using many types of computer system configurations, including personal computers, desktop computers, laptop computers, messaging processors, handheld devices, multiprocessor systems, multiprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, and the like. The present invention may also be practiced in distributed system environments where local and remote computer systems that are linked through a network (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0099] Alternatively or additionally, the functionality described herein may be performed, at least in part, by one or more hardware logic components. By way of example, and not limitation, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system on a chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0100] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Thus, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A method for authenticating a computing entity in a computing environment, the method comprising: At an identity provider, providing a first access token to an entity for use by the entity to obtain a specific resource from a resource provider in a user session; Causing the entity to pass the first access token to the resource provider, wherein in response to rejecting the first access token, the resource provider is configured to send response information indicating the rejection of the first access token to the entity, and one of a plurality of reasons for the rejection based on an enforcement policy associated with a risk level of the user session, the plurality of reasons including at least a reason associated with a need for a higher level of authentication, the authentication being used to obtain the first access token based on the risk level of the user session; Receiving response information from the entity, the response information from the entity having been provided to the entity by the resource provider; and Providing a second access token for accessing the specific resource to the entity, the second access token being provided based on the reason for the rejection indicated in the response information to mitigate the rejection, such that the second access token is used by the entity to obtain the specific resource from the resource provider.

2. The method according to claim 1, wherein the response information indicates that a higher level of authentication is required for the entity to obtain the specific resource from the resource provider than for obtaining the first access token.

3. The method according to claim 1, wherein the response information indicates that at least one of the following policies has been enforced: user state change, client state change, policy state change, conditional access, location, or behavior pattern.

4. The method according to claim 1, wherein the response information indicates that a policy previously provided by the identity provider to the resource provider has been enforced.

5. The method according to claim 1, wherein the response information indicates that a policy previously provided by a subscription service to the resource provider has been enforced.

6. The method according to claim 1, wherein in addition to information consumable by the identity provider, the response information further includes information consumable by the entity.

7. The method according to claim 1, wherein the response information is provided as a result of the policy indicating that the response information is required when enforcing the policy.

8. A method for enforcing a policy at a resource provider in a computing environment, the method comprising: Receiving, from an entity, a first access token in a request for a specific resource for use by the entity to obtain the specific resource from the resource provider in a user session, the first access token having been previously provided to the entity by an identity provider, the identity provider being configured to authenticate the entity and issue a token based on the authentication; Determine that the request for the specific resource based on the first access token cannot be granted as a result of enforcing, at the resource provider, a policy associated with the risk level of the user session; Deny the request from the entity for the specific resource; Send response information to the entity, the response information providing one of a plurality of reasons why the request for the specific resource was not granted, such that the entity conveys the response information to the identity provider, wherein the plurality of reasons includes at least a reason associated with a need for a higher level of authentication used to obtain the first access token based on the risk level of the user session, and when the identity provider receives the response information, the identity provider is configured to re-authenticate the entity and generate a second access token for accessing the specific resource based on the reason why the request for the specific resource was not granted to mitigate the denial; And In response to receiving the second access token from the entity, grant the entity access to the specific resource, the second access token having been previously provided to the entity by the identity provider.

9. The method according to claim 8 further comprises: Receive a second access token from the entity as a result of the response information, the second access token having been issued from the identity provider to the entity.

10. The method according to claim 8, wherein the response information indicates that obtaining the resource from the resource provider for the entity requires a higher level of authentication than that used to obtain the first access token.

11. The method according to claim 8, wherein the response information indicates that at least one of the following policies has been enforced: user state change, client state change, policy state change, conditional access, location, or behavior pattern.

12. The method according to claim 8, wherein the response information indicates that a policy previously provided by the identity provider to the resource provider has been enforced.

13. The method according to claim 8, wherein the response information indicates that a policy previously provided by a subscription service to the resource provider has been enforced.

14. The method according to claim 8, wherein in addition to information consumable by the identity provider, the response information further includes information consumable by the entity.

15. The method according to claim 8, wherein the response information is provided as a result of the policy indicating that the response information is needed when enforcing the policy.

16. A system for enforcing policies in a computing environment, the system comprising: An identity provider computing system including at least one processor and at least one hardware storage device having stored thereon first computer-executable instructions that, when executed, configure the identity provider to: Provide a first access token to an entity in a user session in obtaining a specific resource from a resource provider based on the authentication of the entity; and An identity provider computing system, including at least one processor and at least one hardware storage device, on which second computer-executable instructions are stored. When the second computer-executable instructions are executed, the second computer-executable instructions configure the identity provider to: Receive, from the entity, the first access token for the specific resource requested by the entity; Determine, based on the first access token, whether the request for the specific resource can be granted, as a result of enforcing a policy at the resource provider, the policy being associated with the risk level of the user session; and In response to determining that the request corresponding to the first access token from the entity in the request cannot be granted, Deny the request from the entity; Send response information to the entity, the response information providing one of a plurality of reasons why the request for the specific resource was not granted, such that the response information can subsequently be provided to the identity provider, the plurality of reasons including at least a reason associated with the need for a higher level of authentication, the authentication being used to obtain the first access token based on the risk level of the user session; wherein the identity provider computing system is further configured to: Receive the response information from the entity; Re-authenticate the entity and generate a second access token for accessing the specific resource to mitigate the denial, based on the reason why the request for the specific resource was not granted; and Provide the second access token to the entity, causing the entity to pass the second access token to the resource provider; wherein the resource provider is further configured to: Receive the second access token from the entity; Determine that the request from the entity for the specific resource can be granted; and Grant the entity access to the specific resource.

17. The system according to claim 16, wherein the response information indicates that the entity requires a higher level of authentication to obtain the specific resource from the resource provider than was used to obtain the first access token.

18. The system according to claim 16, wherein the response information indicates that at least one of the following policies has been enforced: user state change, client state change, policy state change, conditional access, location, or behavior pattern.

19. The system according to claim 16, wherein the response information indicates that a policy previously provided by the identity provider to the resource provider has been enforced.

20. The system according to claim 16, wherein the response information indicates that a policy previously provided by a subscription service to the resource provider has been enforced.

Images