ES2955941T3 - Request-specific authentication to access web service resources - Google Patents

Abstract

Requests to access web service resources are evaluated based on the type of request that is received. Requests are not granted unless sufficient proof of authentication is provided to grant that request. An authentication service evaluates one or more factors to determine whether or not to authenticate the client. After being authenticated by the authentication service, proof of authentication is provided to the web service, granting access to the web service resource. (Automatic translation with Google Translate, without legal value)

Description

DESCRIPTION

Request-specific authentication to access web service resources

Background

When a user attempts to access a protected remote resource over a network, such as the Internet, the user typically conforms to policy statements issued by a server that controls that resource. Policy statements provide a set of authentication and authorization rules required to initiate communication with a resource. For example, the policy statement may require a user to provide a password before accessing a resource. If the user provides the correct password, the user's identity is authenticated and access to the resource is allowed.

While the policy statement authentication method works well in situations where one way of authentication is sufficient to initiate communication with a protected resource, policy statements do not work well in dynamic environments. In a dynamic environment, a single instance of authentication at the beginning of communications between a client and a protected resource may not be sufficient. For example, when a user attempts to access a website with protected resources, it may initially be sufficient for the user to provide authentication by entering a password. However, once the user has accessed the website, they can attempt to change their password, update a directory, access a highly protected resource, or request the privileges of an elevated access group, such as the system administrators group. In such a case, the user asks to do more than simply view information. These actions have the potential to cause tremendous damage to the protected resource.

Some authentication methods require authentication before allowing communication with a resource. However, in a dynamic environment it is difficult to determine which authentication and authorization rules to apply until an actual request is received requesting access to a protected resource.

WO 01/11451 A1 describes a login service that provides a credential level change without loss of session continuity. In particular, a security architecture is described in which a single sign-on start from multiple information resources is provided. The security architecture associates trust level requirements with information resources. Authentication schemes (for example, those based on passwords, certificates, biometric techniques, smart cards, etc.) are used depending on the trust level requirements of the information resources being accessed. Once credentials have been obtained for an entity and the entity has been authenticated to a given trust level, access is granted, without the need for additional credentials or authentication, to the information resources for which the trust level is sufficient. authenticated. The security architecture allows credentials to be updated for a given session. A user-actuated client application interacts with the security architecture through an access control and entry controller component and a login component. The access controller and entry controller components provide an entry point for external client applications that request access to applications and/or enterprise resources.

The object of the present invention is to provide an improved authentication scheme for accessing web services resources.

This object is achieved by the object of the independent claims.

The embodiments are defined by the dependent claims.

Summary

Embodiments of the present disclosure relate to systems, methods and data structures for message-specific authentication. One aspect is a computer system for controlling access to a protected web service resource. The computer system includes a communication device, a processor and memory. The communication device communicates over a communication network. The processor is communicatively connected to the communication device. Memory stores program instructions that, when executed by the processor, cause the computer system to perform a method of controlling access to a protected web service resource. The method includes receiving a first request from a client to access a protected web service resource from the communication network; determine that the client has been authenticated according to a first factor; granting the first request to access the protected web service resource based on authentication according to the first factor; receiving a second request from a client to access a protected web service resource from the communication network; deny the second request to access the protected web service resource on the basis that authentication according to the first factor is insufficient to grant the second request, determine that the client has been authenticated according to a second factor, and grant the second request to access the protected web service resource based on authentication according to the second factor.

Another aspect is a method of authenticating a client to access a web service resource. The method includes: (i) receiving a request from a client to be authenticated; (ii) send a challenge message to the client; (iii) receive a confirmation response to the client's challenge message; (iv) determine that the confirmation response meets a predetermined criterion; (v) determine that the request to authenticate requires additional authentication; (iv) repeat (ii) to (iv) with a second challenge message, a second confirmation response and a second predetermined criterion; and (v) send an authentication message to the client.

A further aspect relates to a computer-readable medium containing computer-executable instructions, which, when executed by a computer, perform a method of controlling access to a protected resource, the method comprising: receiving a request from a client that identifies the protected resource of a web service; send a response to the client requesting authentication from an authentication service; receiving an authentication token (or token) from the client after being authenticated from the authentication service; determine whether the authentication token is sufficient to grant the request; grant the request if the authentication token is sufficient; and deny the request if the authentication token is not sufficient to grant the request.

Embodiments may be implemented as a computer process, as a computer system, or as an article of manufacture such as a computer program product or computer-readable medium. The computer program product may be a computer storage medium readable by a computer system and encoding a computer program of instructions to execute a computer process. The computer program product may also be a signal propagated on a medium readable by a computer system and encoding a computer program of instructions to execute a computer process.

This summary is provided to present a selection of concepts in a simplified manner and is described in more detail below in the detailed description. This summary is not intended to identify key or essential characteristics of the claimed subject matter, nor is it intended to be used in any way to limit the scope of the claimed subject matter.

Brief description of the drawings

Figure 1 is a block diagram of an example system configured to perform dynamic authentication. Figure 2 is a flowchart illustrating an example method for dynamically determining whether authentication is required.

Figure 3 is a flowchart illustrating an example method for authenticating a client.

Figure 4 is a flowchart illustrating an example method for dynamically controlling access to a protected resource.

Figure 5 is a flowchart illustrating an example method for controlling access to a protected resource.

Figure 6 is a block diagram of an exemplary computer system for implementing aspects of the present disclosure.

Detailed description

This disclosure will now describe exemplary embodiments in more detail with reference to the accompanying drawings, in which specific embodiments are shown. However, other aspects may be incorporated in many different ways, and the inclusion of specific embodiments in the disclosure should not be construed as limiting such aspects to the embodiments set forth herein. Rather, the embodiments depicted in the drawings are included to provide a disclosure that is thorough and complete and that fully conveys their intended scope to one skilled in the art. When referring to the figures, similar structures and elements shown throughout are indicated by similar reference numerals. Some embodiments of the present disclosure relate to systems and methods for message-specific authentication. One aspect is a method of determining whether authentication is required before a client is allowed to access a protected resource.

In general, authentication is a process of verifying the veracity of identity claims made by something, such as a computer system, a client, a system, or a person. Authenticating a computer system typically includes confirming its origin or source. Confirmation of origin or source is typically carried out by comparing information about the computer system that claims a specific identity, such as place and time of manufacturing, location on a network, physical location, identification number and the like, to learn information about that specific identity.

However, the act of authenticating a person involves, for example, confirming the person's identity. There are many different identification characteristics that can be used for authentication. One method of identifying a person involves detecting biometric identifiers. This authentication method requires the person claiming an identity to provide verification in the form of characteristics unique to the person claiming the identity, such as ID, fingerprint patterns, retina patterns, etc. Another way to verify a person's identity is through something the person knows. This authentication method requires the person claiming an identity to provide verification in the form of personal information such as a password, PIN number, etc. Yet another way to verify a person's identity is through something they have. This authentication method requires the person claiming an identity to provide verification in the form of an object, such as a key, security card, security token, credit card, etc. These authentication methods can be used individually or together in a process known as multi-factor authentication.

Generally, when authenticating a client, the process includes authenticating a client or authenticating the identity of the person using the client. In one embodiment, the client may be a web browser. In another embodiment, the client may be a program configured to make remote procedure calls, or any other application or program that communicates with a protected resource.

In a dynamic environment, the types of authentication and the rules for authenticating a client vary depending on the types of requests made to access a protected resource. For example, a message that asks to view a protected resource may require less stringent authentication than a message that asks to modify the protected resource. In one embodiment, a protected resource is a private website that only specific users have access to. In another embodiment, a protected resource may be a private email group, protected data, protected methods, protected procedures, protected actions, or any other type of protected information or functionality that must be limited to specific users or clients.

Figure 1 is a block diagram of an example system 100 configured to perform request-specific dynamic authentication. In the illustrated embodiment, system 100 includes client 102, web service 104, and authentication service 108. The web service 104 includes the protected resource 106. In this embodiment, the client 102 wants to access the protected resource 106. However, the protected resource 106 is protected from access by unauthenticated clients. The client 102, the web service 104, and the authentication service 108 are configured to communicate over the network 110. The network 110 is a data communication path. In one embodiment, network 110 is the Internet. In other embodiments, network 110 is a local area network, intranet, wireless network, or any other communication path configured to communicate data from one computer system to another computer system.

In one embodiment, client 102 is a computer system. In other embodiments, client 102 is any computer system configured to communicate data over network 110. An example of client 102 is computer system 600, shown in Figure 6. Client 102 is communicatively connected to web service 104. and with the authentication service 108 over the network 110. In some embodiments, the client 102 can access the protected resource 106 by sending messages to the web service 104. In another embodiment, the client 102 sends messages directly to the protected resource 106.

In one embodiment, the web service 104 is a computer system (e.g., computer system 600, shown in Figure 6), such as a web server, that acts as a web service. In general, web service 104 provides useful functionality that can be accessed over network 110, using a data communication protocol. Web services can be used to provide an infinite variety of useful functions. In one embodiment, the web service 104 is a server. In another embodiment, the web service 104 is a computer system application that acts on a computer system communicatively connected to the network 110. In some embodiments, the web service 104 is an entity, processor or reference resource to which messages can be directed. of web service.

Generally, some embodiments of the web service 104 monitor the network 110 for messages sent from the client 102 related to the protected resource 106. When a message is received, the web service 104 determines whether the message contains a request that requires authentication of the client. client 102. Authentication of client 102 is sometimes required before allowing client 102 to access protected resource 106, to control access to protected resource 106. If web service 104 determines that authentication is needed, web service 104 directs to client 102 to authentication service 108.

In the illustrated embodiment, web service 104 includes protected resource 106. Protected resources include, for example, functions performed by a web service 104 and data stored by web service 104 that can only be accessed, used, or modified by a client. authenticated. For example, if web service 104 provides the service of maintaining a group distribution list, the group distribution list is a protected resource. which can only be accessed, used or modified by an authenticated client. As another example, protected resource 106 is an entry in a directory. In another embodiment, the protected resource 106 is a record in a database. In another embodiment, the protected resource 106 is a file or part of a file stored on a memory storage device. Other embodiments use other forms of protected resources 106.

In one embodiment, the authentication service 108 is a computer system (e.g., computer system 600, shown in Figure 6), such as a server communicatively connected to the network 110. In another embodiment, the authentication service 108 is a computer system that runs a software application located on a network. Authentication service 108 is configured to authenticate client 102. An example of authentication service 108 is a security token service endpoint. Although the illustrated embodiment shows an example of authentication service 108 separate and distinct from web service 104, in other embodiments, authentication service 108 and web service 104 operate on the same server.

If the client 102 authenticates to perform the request contained in its message on the protected resource 106, the web service 104 communicates the results of the requested action to the client 102. However, in other possible embodiments, the authentication service 108 communicates directly with the web service 104, over the network 110, such as to receive an authentication request from the web service 104, or to send an authentication proof to the web service 104.

In addition to authentication, it is sometimes advisable to control access to protected resources by requiring that the client be not only authenticated, but also authorized. The authorization is described in US patent application no. 12/024,896, entitled “Authorization for Access to Web Service Resources”, filed on February 1, 2008 by Craig V. McMurtry, Alexander T. Weinert, Vadim Meleshuk and Mark E. Gabarra, the entire disclosure of which is incorporated herein. by reference.

Figure 2 is a flowchart illustrating an example method 200 for dynamically determining whether authentication is required. Method 200 includes actions 202, 204, 206, 208, and 210. Method 200 begins with action 202 during which a resource request is made. In one embodiment, action 202 involves communicating a message from client 102 to web service 104 that includes a request to access protected resource 106. In some embodiments, the message is a remote procedure call. In another embodiment, the request may take the form of an email or any other type of electrical communication between the client and a resource. In another embodiment, action 202 involves client 102 sending the create, get, put, delete, or list request to web service 104, as commonly used in web service communications.

After the resource request has been made, action 204 is performed to evaluate the request and determine whether authentication is necessary. In one embodiment, the web service analyzes the message sent from the client to the protected resource to determine whether the message contains a request that requires the client to provide authentication. In one embodiment, a client attempting to access a protected resource will not have to provide authentication if the client has previously provided the authentication required for the request. In another embodiment, the client will not have to provide authentication if the resource is a public resource that is available to anyone who requests it. In another embodiment, although a resource may be protected, no authentication is required if the message contains a request that does not require authentication, such as if the message is of a type that cannot harm the protected resource. If the web service 104 determines in action 204 that authentication is not required, action 206 is then performed. If authentication is required, action 208 is then performed.

In one example, web service 104 determines whether authentication is required by evaluating a series of considerations. These considerations include the medium by which the request is transmitted (such as a local area network as opposed to remote access), the type of object to which the request belongs, the properties of the object to which the request belongs, and the quality of the credentials already included with the request. Regarding the quality of the credentials, for example, if the credentials are for a user from another organization, then depending on the resource the user is trying to access, additional credentials may be required.

If authentication is not required, action 206 is performed to grant access to the requested resource. The web service grants access to the protected resource, for example, by sending a representation of the resource to the client, performing the requested action on the protected resource, or sending the result of the requested action to the client.

However, if authentication is required, action 208 is performed to perform the authentication. Client authentication will be discussed in more detail in relation to Figure 3. Examples of situations that require the client to provide authentication include cases where the client attempts to access or modify private websites, private email groups, protected data, protected methods, protected procedures, protected actions or any other type of protected information or functionality. In some embodiments, web service 104 challenges client 102 to provide authentication. Alternatively, web service 104 directs the client to an authentication service (such as authentication service 108). The authentication service 108 may be located in the web service 104, located elsewhere in the web service, or both, as in the case of a distributed network. An example method of authenticating a client is illustrated and described with reference to Figure 3.

After authenticating the client, action 206 is performed to grant the client access to the protected resource of the web service. In one embodiment, access is granted after the client provides an authentication token from the authentication service to the web service. The web service grants access to the protected resource, for example, by sending the resource to the client, performing a requested action on the protected resource, instructing the protected resource to perform a requested action, or sending the result of a requested action to the client.

If it is determined that the client should not be authenticated, action 210 is performed, during which access to the protected resource is denied. In one example, access is denied because the authentication service 108 does not provide the authentication token necessary in order to gain access to the protected resource.

Figure 3 is a flowchart illustrating an example method 300 for authenticating a client. In one embodiment, method 300 corresponds to action 208 shown in Figure 2. Method 300 begins with action 302, during which an authentication request is made. In one embodiment, action 302 involves sending a message from client 102 to authentication service 108, and authentication service 108 receiving the authentication request.

In the illustrated embodiment, after receiving the authentication request, action 304 is performed to communicate an authentication challenge. In one embodiment, the authentication service 108 communicates a challenge to the client 102 to test the veracity of the identity of the client or user. In some embodiments, the challenge takes the form of requesting a password, requesting an answer to a security question, requesting a DNA sample, fingerprint patterns, retinal patterns, other forms of biometric identifiers, other unique identifiers of the person using the customer, request verification in the form of an object such as a key, security card, security token, credit card, or some other object unique to the person using the customer customer, to request customer-specific information such as place and time of manufacture, location on a network, physical location, identification number, or to request any other type of information that may be used for authentication purposes.

In the illustrated embodiment, once the challenge has been communicated, action 306 is performed to receive a confirmation response to the challenge. Action 306 involves providing the information, sample, identifier, or similar, that was requested in action 304, and communicating it to the authentication service 108. In one embodiment, an input device (e.g., input device 614, shown in Figure 6) is used by client user 102 to provide identification information to client 102, which then communicates the information to service 108. authentication. In some embodiments, a sensor (which is also a form of input device) is used. For example, a user places a finger on a fingerprint scanner, which scans the fingerprint. The fingerprint data is then transmitted to the authentication service 108. Various types of input devices can be used, including a keyboard, a mouse, a touchpad, a microphone, a pen, a biometric sensor, a scanner, a card reader, a chemical detector, and the like. In other embodiments, data is entered into client 102, which then communicates it to authentication service 108.

In the illustrated embodiment, once the confirmation has been communicated, action 308 is performed to verify the confirmation response. In one embodiment, the authentication service compares the confirmation response it received from client 102 with known information about the claimed identity. For example, the authentication service 108 retrieves data stored in a database and compares it with the confirmation response data. The authentication service 108 then determines whether the confirmation response matches the previously stored data. If so, the confirmation response is verified and action 312 is performed. Otherwise, the confirmation response is not verified and action 310 is performed.

If the confirmation response received does not match the known information, action 310 is carried out in which access to the requested resource is denied. In another embodiment, the authentication service 108 returns to the action 304 to retry the authentication. In such an embodiment, multiple retries may be allowed, such as three retries. If retries are unsuccessful, action 310 is taken to deny access to the protected resource.

If the confirmation response received matches the known information, action 312 is then performed to determine if additional authentication is necessary. In one embodiment, the authentication service 108 determines whether stronger forms of authentication are required, i.e., multi-factor authentication that requires the client to provide multiple forms of authentication. If multi-factor authentication is necessary, method 300 returns to action 304 to communicate a second challenge. Actions 304, 306, 308 and 310 or 312 are then repeated as many times as desired. However, when repeated, the authentication challenge will take a different form than the challenge previously issued by the authentication service. For example, if the authentication service originally required the client to provide a password, it can require the customer to use a smart card or biometric scanner during the second or subsequent rounds of verification. In some embodiments, any manner of authentication may be used as long as the manner of authentication differs in some way from the manner previously used, such that the authentication service 108 does not simply ask for the same information over and over again. In most situations, repeatedly asking for the same information would not provide any additional authentication value. However, in some situations, repeated requests can be used, such as if a significant amount of time has passed since the previous challenge.

If no additional authentication is required, action 314 is then performed to issue an authentication token. The authentication service 108 returns a security token to the client, which the client uses as proof that it has been authenticated. The authentication token is sent from the client 102 to the web service 104, and the web service 104 then grants the client 102 access to the originally requested protected resource.

Figure 4 is a flow chart illustrating an example method 400 for dynamically controlling access to a protected resource. In one embodiment, method 400 is performed by web service 104, in response to messages received from client 102, such as in an attempt to gain access to protected resource 106. Method 400 begins with action 404, during which a request message. In one embodiment, the web service 104 receives a request from the client 102 related to the protected resource 106. As some examples, the request is a request to view the protected resource, to access the protected resource, or to modify the protected resource.

In the illustrated embodiment, step 406 is then performed to determine whether the request message contains a request that requires authentication. In one embodiment, the web service 104 analyzes the request to determine whether the request contained in the request requires client authentication. In some embodiments, a client attempting to access a protected resource will not have to provide authentication, for example, if the client has previously provided the authentication required for the request, if the resource is public and available to everyone, if the type of request is one that contains a request that does not require authentication, or if the request type and its associated request cannot harm the protected resource. If authentication is not required, action 414 is then performed to perform the requested action.

In the illustrated embodiment, if the request contained in the message requires authentication, action 408 is then performed to communicate that authentication is required. In one embodiment, action 408 involves sending a message from web service 104 to client 102 informing client 102 that authentication is required to perform the requested action. In one embodiment, web service 104 directs client 102 to authentication service 108 for authentication, as described with reference to Figure 3. For example, the message contains an address of an authentication provider. The client uses the address to locate the authentication provider and attempt to receive authentication. In another embodiment, method 300 is performed by web service 104, such that the message contains a challenge to client 102 requesting that client 102 provide authentication information.

In the illustrated embodiment, if the client is successfully authenticated, action 410 is then performed, in which the authentication token is received. As described with reference to Figure 3, the result of successful authentication is the receipt of an authentication token. That token is passed to web service 104 to provide proof of authentication. The web service 104 evaluates the token and verifies that the token is valid.

In some embodiments, evaluation of the witness involves two steps. The first step involves public key cryptography. If the web service 104 can decrypt the token using the public key of the authentication service 108, then the web service 104 determines that the token must have been issued by the authentication service 108. The second step includes deciding whether the claims made by the authentication service 108 on the client 102 satisfy one or more access conditions.

For example, in order to access a particular protected resource 106, the web service 104 could require three particular authentication processes to be performed to authenticate the client 102 to the authentication service 108. As a result, web service 104 would evaluate the token received from client 102 to verify that it contains the three claims coming from authentication service 108, asserting that client 102 has completed all three authentication processes. In other embodiments, any number of authentication processes are required. In some embodiments, the number and type of authentication processes required are related to the type of request being made. For example, requests that involve higher risk will often require stricter authentication processes.

In some embodiments, a series of authentication processes that are successfully completed are called authentication levels. In some embodiments, a low-risk performance involving protected resource 106 requires only a low level of authentication, such as one or two levels of authentication. In some embodiments, a high-risk performance requires a high level of authentication, such as between three and five levels of authentication. A single protected resource can be associated with various levels of authentication, depending on the request made. For example, a request to retrieve information from a protected resource may require only a low level of authentication in some situations, while a request to delete information from a protected resource may require a moderate or high level of authentication. In other situations, a request to retrieve information from a protected resource might require a high level of authentication if the information is sensitive or confidential.

In the illustrated embodiment, if valid proof of authentication is not provided, or if the provided authentication is evaluated and determined to be insufficient, action 411 is taken to deny access to the protected resource. In some embodiments, a message is sent to client 102 to inform client 102 of the denial. In some embodiments, the message also includes information on how to obtain proper authentication, such as directing client 102 to authentication service 108.

In the illustrated embodiment, if proof of authentication is provided and verified as valid, the requested action is performed at action 412. In other words, access to the protected resource is granted. In some embodiments, action 414 is then performed to inform the requester that the request was processed. For example, web service 104 sends a message informing client 102 that the request was processed in relation to the protected resource. In other examples, the web service 104 grants access to the protected resource by sending a representation of the ^resource 106 ^{to the client 102, performing a requested action on the protected resource 106, or sending the result of} a requested action to the client 102.

In the illustrated embodiment, action 416 is then performed to monitor the receipt of additional messages. For example, web service 104 monitors additional communications from client 102 related to resource 106. If client 102 sends additional messages to resource 106, method 400 returns to action 404 to evaluate whether the new message requires additional authentication via actions 404, 406, and 408. Although the client may already have authenticated at this point itself, in a dynamic environment the client may need to provide stronger forms of authentication, i.e., multi-factor authentication. , depending on the types of messages and requests you send. If no more messages are received, then method 400 ends.

Figure 5 is a flow chart illustrating an example method 500 for controlling access to a protected resource. The method 500 involves the client 102, the web service 104, the authentication service 108, and the protected resource 106. Although the authentication service 108 is illustrated as a separate and distinct entity from the web service 104, in some embodiments the authentication service 108 authentication and the web service 104 operate on the same computer system. In one embodiment, the protected resource 106 is located on the web service 104. In yet another embodiment, the protected resource 106 is located on another web service, server, computer, or other computer system. In communication 512, client 102 sends a request for protected resource 106. Web service 104 receives this request. In communication 514, web service 104 determines that authentication is necessary and responds with a failure, indicating that at least one authentication process must be completed for the request to be processed. In possible embodiments, the failure may take the form of a Simple Object Access Protocol (SOAP) failure, as defined in the SOAP 1.2 specification. In other embodiments, the fault may take the form of any other type of data communication protocol. In further embodiments, the web service failure 104 will contain an address to an authentication service 108, such as a security token service endpoint.

In communication 516, client 102 sends a request for a security token to authentication service 108, claiming that the necessary authentication processes have been completed. In one embodiment, this request takes the form of a Web Services Trust Request Security Token (WS-Trust) response message as defined in the WS-Trust specification. In other embodiments, the request may take the form of other protocols. In communication 518, authentication service 108 responds to client 102 with a challenge for identity confirmation. In some embodiments, the challenge takes the form of the challenges described with respect to Figure 3. In communication 520, client 102 responds with an identity confirmation. In some embodiments, the identity confirmation takes the form of the confirmation described with respect to Figure 3. In communication 522, the authentication service 108 responds to the client 102 with an additional challenge for the identity confirmation. In one embodiment, this challenge is in response to a failed identity confirmation. In yet another embodiment, this challenge is necessary to perform multi-factor authentication. In communication 524, client 102 responds to authentication service 108 with additional confirmation of identity. This process may be repeated one more time with a challenge communication 526 and challenge confirmation 528. Although it is illustrated that the set of challenges and confirmations is performed three times, in other embodiments such challenge and response communications are repeated any number of times. times. After the authentication service 108 confirms the identity of the client 102, the authentication service 108 issues the requested security token to the client 102 in communication 530.

In communication 532, client 102 resends the original request for a protected resource along with the security token. The web service 104 examines the request to ensure that it is the same as the original request and validates the security token to ensure that it is valid. In communication 534, the web service 104 processes the request made by the client 102. In some embodiments, this processing involves searching and/or updating the protected resource 106. In communication 536, the result of the search is returned and/or update of the protected resource 106. to the web service 104. In communication 538, the web service 104 responds to the request made by the client 102.

Referring now to Table 1: Authentication Challenge Scheme, a data structure is provided to indicate that a message-specific authentication process is required to process a request. In some embodiments, the communications described in connection with Figure 5 are communicated in the form of the data structure defined in Table 1, such as when a web service, such as web service 104, determines that a specific process is required. message to authenticate the user who initiated a request. In one embodiment, the service will return a SOAP fault, as defined in the SOAP 1.2 specification. In some embodiments, unlike traditional SOAP faults, the SOAP fault used to indicate that a message-specific authentication protocol is required will contain a context header containing an identifier by which the details of the original request are displayed, and Any authentication processes found to be associated with the request can be recovered by the web service. In another embodiment, the returned SOAP fault will also contain a Detail element indicating the identity of the user on whose behalf the request is made. This is the identity that will be further authenticated. In yet another embodiment, the Detail element will also provide or alternatively provide the address of an authentication service, such as authentication service 108, that can issue a security token to the user confirming that the user has successfully completed each of the authentication processes associated with the request. In some embodiments, the address of the authentication service is the same as the address of the web service. In other embodiments, the address of the authentication service is different from the address of the web service.

Table 1: Authentication challenge scheme

The scheme shown in Table 1 includes a Challenge element and an AuthenticationChallenge element. The Challenge element is used to transfer to the client the information necessary to challenge the user to provide the required authentication data. In some embodiments, the client may be a web browser that will display the challenge data to the user, to prompt the user to provide data in response to the challenge. For example, the challenge element may instruct the client 102 to display a text box prompting the user to enter a password. Other embodiments will prompt the user to provide authentication by requesting an answer to a security question, requesting a DNA sample, fingerprint patterns, retinal patterns or some other unique identifier of the person using the client, requesting verification in the form of an object such as a key, security card, security token, credit card or some other object unique to the person used by the customer, as described with reference to Figure 3. In possible embodiments, the authentication challenge scheme will include an AuthenticationChallenge element that serves as a wrapper for the scheme.

Referring now to Table 2: Authentication Challenge Response Scheme, a data structure for responding to an authentication challenge is provided. The authentication service, such as authentication service 108, issues challenges to the user to authenticate information. In some embodiments, challenges are made in accordance with the challenge framework defined in section 10 of the WS-Trust specification. If the authentication service requires additional information to authenticate a user's identity, it will respond to a request for a security token message with a response defined by the WS-Trust specification.

Table 2: Authentication challenge response scheme

The authentication challenge response scheme includes a response element and an AuthenticationChallengeResponse element. The response element identifies to the authentication service the authentication information that is required from the client. The authentication service uses this information, for example, to determine which challenges should be sent to the client to authenticate it. The AuthenticationChallengeResponse element serves as a wrapper for the schema.

Figure 6 is a block diagram of an exemplary computer system 600 for implementing aspects of the present disclosure. In one embodiment, the computer system 600 is the client 102. In another embodiment, the computer system 600 is the web service 104. In another possible embodiment, the computer system 600 is the authentication service 108. In its most basic configuration, computer system 600 typically includes at least one processing unit 602 and memory 604. Depending on the exact configuration and type of computer system, memory 604 can be volatile (such as RAM), non-volatile ( such as ROM, flash memory, etc.) or some combination of both. This most basic configuration is illustrated in Figure 6 with the dashed line 606. Additionally, the computer system 600 may also have additional features/functionalities. For example, computer system 600 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tapes. Such additional storage is illustrated in Figure 6 with removable storage 608 and non-removable storage 610. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as such as computer-readable instructions, data structures, program modules or other data. Memory 604, removable storage 608, and non-removable storage 610 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computer system 600. Any such computer storage media may be part of the computer system 600.

The computer system 600 may also contain communications connection(s) 612 that allow the computer system to communicate with other devices. Communication connection(s) 612 are an example of communication media. Communication media typically incorporate computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and include any information delivery medium. The term "modulated data signal" means that a signal has one or more of its characteristics set or changed in such a way that it encodes information in the signal. By way of example, and without limitation, communication media includes wired media, such as a wired network or direct wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. The term computer-readable media, as used herein, includes both storage media and communication media.

The computer system 600 may also have one or more input devices 614, such as keyboard, mouse, pen, voice input device, touch input device, etc. In some embodiments, the input devices also (or alternatively) include, for example, biometric data. identifiers, sensors, detectors, card readers and the like. Output devices 616 may also be included, such as a display, speakers, printer, etc. All of these devices are well known in the art and need not be discussed in detail here.

In some embodiments, memory 604 includes one or more elements of the operating system 620, application programs 622, other program modules 624, and program data 626. In some embodiments, the global data, customer-specific data, and transformation rules may each be stored in memory 604, removable storage 608, non-removable storage 610, or any other computer storage medium. described in this document.

Although the embodiments have been described in specific language of structural features, methodological acts and computer-readable media containing such acts, it is to be understood that the possible embodiments, as defined in the appended claims, are not necessarily limited to the specific structure, acts or means described. One skilled in the art will recognize other embodiments or improvements that are within the scope of the present disclosure. Therefore, the specific structure, acts or means are disclosed only as illustrative embodiments.

Claims (4)

1. A method for controlling access to a protected web service resource (106), comprising: (i) receiving a first request from a client (102) to access the protected web service resource (106) from a communication network (110); (ii) receiving a first authentication token from the client after the client has been authenticated from an authentication service (108), and determining, based on the evaluation of the first authentication token, that the client has been authenticated in accordance with a first factor; (iii) granting the first request to access the protected web service resource (106) based on authentication according to the first factor; (iv) receiving a second request from the client (102) to access the protected web service resource (106) from the communication network (110); (v) deny the second request to access the protected web service resource (106) on the basis that authentication according to the first factor is insufficient to grant the second request, and send a message to the client directing the client to the service authentication to be authenticated according to a second factor; (vi) receive a second authentication token from the client after the client has been authenticated by the authentication service in accordance with the second factor, and determine, based on the evaluation of the second authentication token, that the client (102 ) has been authenticated according to a second factor, and (vii) granting the second request to access the protected web service resource (106) based on authentication according to the second factor, in which the client (102) communicatively connects with the web service (104) and with the authentication service (108) through the network (110), wherein the first and second authentication tokens include a claim of the authentication service related to a factor that was used to authenticate the client and wherein the authentication token is encrypted using public key cryptography, wherein the first factor is selected from the group comprising: a password, an answer to a security question, a biometric identifier, an object, and customer-specific information, in which the second factor is different from the first factor, and wherein determining, based on an authentication token, that the client has been authenticated comprises: decrypting the authentication token with a public key of the authentication service; and determining that a claim made by the authentication service on the authentication token satisfies an access condition, which comprises evaluating the authentication token to verify the number and type of authentication processes completed by the client on the authentication service. 2. The method of claim 1, wherein denying the request comprises sending a failure message in accordance with a simple object access protocol, and wherein receiving an authentication comprises receiving a web services trust request security token response message in accordance with a web services trust specification . 3. A computer system (104, 108) comprising: a communication device (612) for communicating over a communication network (110); a processor (602) communicatively connected to the communication device (612); and memory (604) that stores program instructions, which when executed by the processor (602) cause the computer system (104) to perform the method of claim 1 or 2. 4. A computer-readable storage medium (608) containing computer-executable instructions that, when executed by a computer (104), perform the method of claim 1 or 2.