Source: https://patents.google.com/patent/EP2430792B1/en
Timestamp: 2020-01-25 20:11:23
Document Index: 498366590

Matched Legal Cases: ['arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106']

EP2430792B1 - Http-based authentication - Google Patents
Http-based authentication Download PDF
EP2430792B1
EP2430792B1 EP10775411.1A EP10775411A EP2430792B1 EP 2430792 B1 EP2430792 B1 EP 2430792B1 EP 10775411 A EP10775411 A EP 10775411A EP 2430792 B1 EP2430792 B1 EP 2430792B1
EP10775411.1A
EP2430792A2 (en
EP2430792A4 (en
2009-05-14 Priority to US12/465,725 priority Critical patent/US8078870B2/en
2010-05-11 Priority to PCT/US2010/034402 priority patent/WO2010132462A2/en
2012-03-21 Publication of EP2430792A2 publication Critical patent/EP2430792A2/en
2016-09-28 Publication of EP2430792A4 publication Critical patent/EP2430792A4/en
2017-04-19 Publication of EP2430792B1 publication Critical patent/EP2430792B1/en
Computer networks are subject to a variety of security breaches. One such type of breach occurs when a user or computer system falsely identifies itself, in order to access resources that it is not authorized to access, or to otherwise avoid being correctly associated with a request. To facilitate request authentication, a request for service to a party providing a resource or service, hereinafter referred to as a "relying party," includes the identity of the requester in a manner such that the relying party can verify the authenticity of the identity. Request authentication is the process of verifying the identity of the sender of a request. Authentication provides some level of security that each party's identification is accurate. The identity of the requester forms the basis for access control decisions made by the relying party.
Representational state transfer (REST) is a style of software architecture for distributed systems such as the World Wide Web. REST generally refers to an interface that transmits domain-specific data over HTTP without an additional messaging layer such as SOAP. HTTP provides an interface including methods, such as GET, POST, UPDATE, and DELETE, that conform to a "RESTful" architecture. One aspect of the REST architecture is the support of stateless servers, in which each message includes the information necessary to understand the message, freeing a server from needing to remember communication state between messages. This facilitates scaling of servers, such as in a server farm.
RFC 2617, available at http://www.ietf.org/rfc/rfc2617.txt, describes a BASIC authentication scheme in which a username and password may be passed in an HTTP header field. The RFC describes this scheme as "not considered to be a secure method of user authentication, as the user name and password are passed over the network in an unencrypted form." The RFC also describes a "Digest Access Authentication" scheme, in which a hash of a username, password, a nonce value, the HTTP method, and the requested URI is used. The RFC states that the digest scheme "... suffers from many known limitations." RFC 4559 builds on the authentication mechanisms defined in RFC 2617, and teaches the insertion of a security token into authentication request messages.
FIGURE 1 is a block diagram of an example environment in which embodiments may be practiced;
FIGURE 2 is a block diagram illustrating an example embodiment of a computing system that may be employed to implement a relying party;
FIGURE 3 illustrates an example environment in which embodiments may be practiced;
FIGURE 4 is a flow diagram illustrating an example embodiment of a process of employing HTTP headers to authenticate a requester;
FIGURE 5 is a flow diagram illustrating, in further detail, some of the actions of FIGURE 4;
FIGURE 6 is a flow diagram illustrating a process of inserting a security token into an HTTP message, in accordance with an example embodiment;
FIGURE 7 is a flow diagram illustrating a process of extracting a security token from an HTTP message, in accordance with an example embodiment; and
FIGURE 8 is a flow diagram illustrating a process of generating an HTTP message, in an example embodiment.
Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase "in one embodiment" as used herein does not necessarily refer to a previous embodiment, though it may. Furthermore, the phrase "in another embodiment" as used herein does not necessarily refer to a different embodiment, although it may. Thus, various embodiments of the invention may be readily combined, without departing from the scope or spirit of the invention. Similarly, the phrase "in one implementation" as used herein does not necessarily refer to the same implementation, though it may, and techniques of various implementations may be combined.
As used herein, the term "authenticate" refers to confirming that facts or claims are true, to an acceptable degree of certainty. Authenticating a user or a user's identity applies to confirming that the stated identity of the user is sufficient and accurate. Authenticating a request from a user may include confirming that the identity information included with the request is accurate, that the request originated with or is authorized by the identified user, that the request has not been improperly modified, or that other information in the request is accurate. Authentication has an associated degree of certainty, allowing for a situation in which information has been authenticated yet may be inaccurate.
FIGURE 1 is a block diagram of an environment 100 in which embodiments may be practiced. FIGURE 1 provides a basic understanding an example environment, though many configurations may be employed and many details are not illustrated in FIGURE 1. As illustrated in FIGURE 1, an example environment 100 includes a requester 102. Requester 102 may be a client computing device, process, or any component that requests resources or services from a remote service provider. In the example embodiment, requester 102 includes an HTTP stack 104. An HTTP stack may receive, process, generate, or send hypertext protocol (HTTP) messages, in accordance with HTTP standards and with at least some of the mechanisms described herein.
Example environment 100 includes relying party 106. Relying party 106 may be a computing device, server, or a server farm that includes multiple servers. FIGURE 2 illustrates an example implementation of relying party 106.
One type of security token includes data that represents a collection of one or more claims about an entity, such as user of requester 102. The claims may be considered as assertions that information associated with the claimer is accurate. This may include, for example, a name, identifier, key, group membership, a privilege, a capability, or the like. This type of security token is referred to herein as a "direct security token."
A second type of security token includes a reference to a direct security token, the reference identifying or enabling access to the direct security token. This type of reference to a direct security token is referred to herein as an indirect security token. A uniform resource identifier (URI) is an example of an indirect security token, if it references a direct security token. As used herein, the term "security token" may refer to a direct security token or an indirect security token, unless the context clearly indicates one specific type.
FIGURE 1 is only an example of a suitable environment and is not intended to suggest any limitation as to the scope of use or functionality of the present invention. Thus, a variety of system configurations may be employed without departing from the scope or spirit of the present invention. For example, any of the functions of relying party 106 or identity provider 110 may be combined into one or more computing devices, distributed, or replicated among multiple computing devices in a variety of ways. Similarly, the functions of requester 102 may be configured in a variety of ways among one or more computing devices. In one embodiment, functions of relying party 106 and identity provider 110 may be combined in one or more computing devices.
In one embodiment, each of requester 102, relying party 106, and identity provider 110 is implemented by one or more computing devices. A computing device may be a special purpose or general purpose computing device. In brief, one embodiment of a computing device that may be employed includes one or more processing units, a memory, a display, keyboard and pointing device, and a communications interface. The one or more processing units may include one or more multiple core processors. Example computing devices include mainframes, servers, blade servers, personal computers, portable computers, communication devices, consumer electronics, or the like. A computing device may include a general or special purpose operating system. The Windows® family of operating systems, by Microsoft Corporation, of Redmond, WA, are examples of operating systems that may execute on a computing device of a development system.
FIGURE 2 is a block diagram illustrating an example embodiment of a computing system 200 that may be employed to implement relying party 106, or portions thereof. In various embodiments, system 200 may be implemented with one or more servers or other computing devices configured in a variety of ways.
In the illustrated embodiment, computing system 200 includes HTTP stack 206 and one or more applications 210, stored within memory 204. HTTP stack 206 may be HTTP stack 108 (FIGURE 1). In one embodiment, HTTP stack 206 includes authentication module 208, which performs actions to authenticate a received request. In some embodiments, HTTP stack 206 does not include authentication module 208.
FIGURE 3 illustrates an example environment 300 in which embodiments may be practiced. Environment 300 may exist in conjunction with environment 100 of FIGURE 1, or a variation thereof. As illustrated, environment 300 includes requester 102, relying party 106, and identity provider 110. Requester 102 is in direct or indirect communication with each of relying party 106 and identity provider 110. The communication may be direct or over a network, such as network 120 (FIGURE 1).
Arrows in FIGURE 3 represent messages that are exchanged between the illustrated components. Moreover, in one embodiment, the reference numbers of the messages correspond to a temporal sequence in a direction from the top toward the bottom of the figure, though in various embodiments, the sequence differs. In one embodiment, each of the illustrated messages is an HTTP message, the content of which are described in more detail below.
The messages of FIGURE 3 are discussed in conjunction with FIGURE 4. FIGURE 4 is a flow diagram illustrating an example embodiment of a process 400 of employing HTTP headers to authenticate a requester. Some of the actions of process 400 are performed by requester 102 (FIGURE 1), and are represented in the left column of FIGURE 4 under the header "Requester." Other actions of process 400 are performed by relying party 106, and are represented in the right column of FIGURE 4 under the header "Relying Party." Some of the actions of process 400 relate to sending or receiving messages illustrated in FIGURE 3. The following discussion references messages of FIGURE 3.
If, at decision block 406, it is determined that there are not sufficient security credentials included with the request message, process 400 may flow to block 410, where an HTTP error response message may be generated and sent from relying party 106 to requester 102. In one embodiment, the HTTP error response message is an HTTP "unauthorized" message 312. This may be an HTTP 401 error message including a "WWW-Authenticate" response header. The message may include data indicating a specification of security credential that is required, or a protocol to be adhered to when sending one or more security credential. The protocol is referred to as a "scheme," and in the particular case of a scheme that uses one or more HTTP headers, it is referred to as an "HTTP scheme."
Process 400 may flow from block 410 to block 412, where requester 102 receives "unauthorized" message 312. Though in some environments requester 102 may possess the sufficient security credentials or be able to generate them, in the illustrated environment, in response to receiving the "unauthorized" message 312, the process flows to block 414, where requester 102 may attempt to acquire sufficient security credentials, in conformance with a scheme identified by relying party 106 in "unauthorized" message 312. In one embodiment, at block 414, requester 102 may request a security token from a trusted identity provider, such as identity provider 110. The request may be in the form of a request ST message 314 that is sent to identity provider 110. Request ST message 314 may include security credentials or other data that may be used to authenticate a user of requester 102.
In some environments, in response to receiving request ST message 314, identity provider 110 may determine that requester 102 has not provided sufficient identification data, or is otherwise not authorized to receive a security token. This action is not illustrated in FIGURE 4. Example process 400 illustrates an environment in which identity provider 110 returns the requested security token to requester 102. As shown, process 400 flows to block 416, where requester 102 receives ST response message 316, which includes security token 325. In some embodiments, a security token includes one or more cryptographic keys. Examples of key-bearing security tokens include Kerberos v5 tickets with session keys and SAML v1.1 or v2.0 tokens with holder-of-key subject confirmation.
At block 404, in response to receiving the request message 318, relying party 106 may process the message to determine whether the request includes sufficient identification credentials and conforms to the configured authentication scheme, as discussed with regard to request message 310. If the identification credentials are considered to be insufficient, process 400 may flow to block 410, where replying party may send another unauthorized message 312. If, at decision block 406, it is determined that the security credentials are sufficient, the process may flow to block 408, where a response is sent, as discussed above. FIGURE 3 illustrates an example sequence of messages, in which a first request message is insufficient, and a second request message is sufficient. The example sequence of messages illustrates the following sequence of messages.
Request message 310.
Unauthorized message 312.
Request ST message 314.
ST response message 316.
Request message 318 (with security token).
Response message 320.
In one embodiment, an environment may result in a sequence of messages as follows.
In the above example sequence, requester 102 may, at block 414, send request ST message 314; at block 416, requester 102 may receive security ST response message 316; in response, at block 418, requester 102 may generate and send request message 318. Relying party 106 may then send response message 320 at block 408. This sequence may occur, for example, in an environment in which requester 102 has previously received unauthorized message 312 in response to a prior request, or has otherwise been configured to obtain an appropriate security token and send it with an appropriate scheme in a request message. Variations of process 400 may occur that include sending the illustrated messages, or a portion thereof, in yet other sequences.
FIGURE 5 is a flow diagram illustrating an example implementation of decision block 406 of FIGURE 4. Some of the actions of decision block 406 may be performed by HTTP stack 206 (FIGURE 2) of relying party 106 (FIGURE 1), and are represented in the left column of FIGURE 5 under the header "HTTP Stack." Other actions of decision block 406 may be performed by authentication module 212 of application 210, and are represented in the right column under the header "Application." FIGURE 5 includes blocks 404, 410, and 408 of FIGURE 4 in dashed lines for context; though they are not included in the actions of decision block 406 in the illustrated embodiment. The actions of decision block 406 illustrated in FIGURE 5 are referred to herein as process 500.
As illustrated in FIGURE 5, processing may flow from block 404 to block 504, where a specification of an authentication scheme may be extracted from an HTTP header of an HTTP message. Request message 318 is one example of such an HTTP message. In one embodiment, the specification may be any scheme name configured in relying party 106.
If, at decision block 506, it is determined that HTTP stack 206 is configured with a corresponding handler, the process may flow to block 508, where a security token may be extracted from the received message. As described herein, the framework described herein allows a security token to be located in one or more HTTP headers or in a body of the request message. The actions of block 506 include determining a location of the security token, extracting the security token, and assembling fragments of the security token if there is more than one. FIGURE 7 illustrates, in further detail, some of the actions of block 508.
Verification of the security token may include verifying that the security token was issued by a trusted identity provider, such as identity provider 110 of FIGURE 1. The actions of block 510 may include verifying that any claims represented by the security token are sufficient, based on a configuration of the relying party, or additional verification of security token data, as configured. This may include virtually any type of verification that may be configured.
FIGURE 6 is a flow diagram illustrating a process 600 of inserting a security token into an HTTP message, in an example embodiment. Process 600 illustrates at least some of the actions of blocks 418, as discussed above. The illustrated portions of process 600 may be initiated at block 602, where one or more locations of the security token may be determined. In one implementation, a security token may be configured to be in one or more HTTP headers or one of three locations in the message body. At decision block 604, the process may branch to one of four blocks to handle respective location options. One such location is in one or more HTTP headers. If it is determined that this is the location, the process may flow to decision block 606, where a determination is made of whether to fragment the security token. In one embodiment, this determination is made based on the size of the security token. If it is determined at decision block 606 that the security token may be inserted into one header, the process may flow to block 608, where the security token is inserted into one HTTP header. The process may flow to a block 620. In one embodiment, at block 620, an HTTP token location header is generated with a specification of the security token location. The process may then flow to done block 622 and exit or return to a calling program, such as block 418. If, at decision block 606, it is determined that fragmentation is to be performed, the process may flow to block 610, where fragmentation of the security token is performed, multiple HTTP token headers are generated, and a fragment of the security token is inserted into each header. The process may then flow to block 620, where a token location header may be generated. At block 620, if the security token is fragmented, a token location header may specify the number of fragments and the size of each fragment. The process may flow to done block 622.
FIGURE 7 is a flow diagram illustrating a process 700 of extracting a security token from an HTTP message, in an example embodiment. Process 700 illustrates at least some of the actions of blocks 508 and 518, as discussed above. The illustrated portions of process 700 may be initiated at block 702, where one or more locations of the security token may be determined. This may include examining a token location header that specifies the location of the token and, if it is fragmented, the number of fragments. In one implementation, a security token may be configured in any of four locations. At decision block 704, the process may branch to one of four blocks to handle respective location options. One such location is in one or more HTTP headers. If it is determined that this is the location, the process may flow to block 706, where a fragment of the security token is extracted from each header. If there is more than one fragment in more than one corresponding header, they are assembled to form the security token. The process may then continue at block 510 or 520 of FIGURE 5.
In one embodiment, the messages as described herein are used to form a protocol that is an extension to the authentication protocol of RFC 2617. The name "WSSEC" is used herein as a moniker for this protocol. The protocol herein described facilitates a variety of schemes for authenticating HTTP requests. It also defines a set of new HTTP extension headers and their semantics for use with the WSSEC protocol in a way such that the protocol may be implemented at the HTTP layer in the stack or in the application above the HTTP layer.
As discussed herein, various actions described herein may be performed by application authentication module 212 (FIGURE 2) of application 210 or authentication module 208 of HTTP stack 206. In one embodiment, the messages and message headers are designed to accommodate implementations by application 210 or HTTP stack 206, such that an application may implement at least some of the mechanisms in an environment in which the HTTP stack does not recognize or process at least some of the headers or parameters. For example, some Web servers are configured to strip off standard HTTP authentication headers if they do not recognize the authentication scheme specified. In such an environment, the custom headers defined herein are still available to the application to enact the authentication protocol.
Table 1 illustrates HTTP headers that may be used in each of the described messages. In each message, additional HTTP headers not described may be included. TABLE 1 Authentication Headers Unauthorized Message 312 WWW-Authenticate X-WSS-Authenticate Request Message 318 Authorization X-WSS-Security X-WSS-TokenLoc X-WSS-Token X-WSS-Digest Response Message 320 X-WSS-AuthInfo
Table 2 illustrates, for each HTTP header of Table 1, a set of parameters that may be included in the header. In the illustrated embodiment, many of the parameters are in a "name=value" format in which a keyword representing the parameter name is followed by a value for the parameter. In one embodiment, the parameters listed within brackets are considered optional, though in various embodiments, the protocol may differ.
In the discussion that follows, headers are used to aid in identifying header descriptions, though the use of a header does not suggest that the associated text is limited to the header, or that description of the header is limited to the associated text. TABLE 2 Header Parameters WWW-Authenticate: WSSEC [realm="realm-spec",] [profile="token-profile"] X-WSS-Authenticate: [nonce="nonce-value", [sigmethod="signature-method", ] [sigusage="signature-usage",] [version="protocol-version"] Authorization: WSSEC [realm="realm-spec",] [profile="token-profile"] X-WSS-Security: "token-profile" timestamp="timestamp-value", nonce="nonce-value" [sigmethod="signature-method",] [sigusage="signature-usage", ] [signature="signature-value",] [version="protocol-version"] X-WSS-TokenLoc: "location-type" [frags="fragment-count",][fragsize="fragment-size"] fieldname="form-field-name" | [querytype="query-type", ]query="query-string" X-WSS-Token< n >: "token-fragment-content" X-WSS-Digest: [method="digest-method",] digest="content-digest" X-WSS-AuthInfo: [nextnonce="nonce-value",] [ctxtoken="context-token", ctxtokensecret="context-token-secret"]
In one embodiment, use of the WWW-Authenticate header with the keyword "WSSEC" in unauthorized message 312 indicates support for at least some of the mechanisms described herein.
The WWW-Authenticate header includes one or more authentication specifications. In this HTTP header, "realm-spec" may specify a protection realm. The parameter "token-profile" may specify a name of a security token profile. A security token profile identifies a format and corresponding algorithm for generating a direct security token. Examples of token profiles include specification Kerberos v. 5 service ticket profile, x.509v3 certificate profile, SAML v1.1 assertion, SAML v2.0 assertion, or a security context token issued by the relying party.
In one embodiment, the Authorization header is included by the requester in request message 318 to indicate compliance with the WSSEC protocol for authentication. The "realm-spec" and "token-profile" parameters may each be optional. In one embodiment, each of these fields, if included, match the corresponding fields in the WWW-Authenticate header received from the relying party in unauthorized message 312.
"timestamp-value." This specifies an integer timestamp value.
"nonce-value": This may be a base64 encoded nonce value.
"signature-method." This optionally specifies a signature algorithm used to sign the request.
"signature-usage." This is an optional specification of the semantic usage or purpose that the requester wishes to convey through the signature in the request.
"signature-value." This is an optional value of a digital signature of the request.
"protocol-version." This is an optional specification of a protocol version.
"location-type." This specifies the location of the token. It may be one of the keywords "header," "body," "body-form," or "body-xml."
"fragment-count" and "fragment-size." These parameters are used in conjunction with the "header" location and specify the number of fragments and the size of each fragment, respectively.
"form-field-name." This is used in conjunction with the "body-form" location. It specifies the field name in an HTML form.
"query-type" and "query-string." These parameters are used in conjunction with the "body-xml" location, and may specify a query to extract an xml element.
In one embodiment, the X-WSS-Token header is used to communicate a security token if the value of the "location-type" parameter of the X-WSS-TokenLoc header is specified as "header", as discussed herein. The specification of the direct security token may be specified by the "token-profile" parameter in the Authorization header, and may comply with authentication specifications received from the relying party.
A security token may be in one fragment or divided into multiple fragments, each fragment carried by a different X-WSS-Token header field. The number of fragments may be indicated by the "fragment-count" field of the X-WSS-TokenLoc header.
In one embodiment, the name of each X-WSS-Token header is formed by concatenating the base "X-WSS-Token" with an integer-valued suffix N=1, ... , frags, where frags is the number of fragments into which the token is divided, as specified by the fragment-count" field of the X-WSS-TokenLoc header. For example, the header named "X-WSS-Token1" may carry the first token fragment; the header named "X-WSS-Token2" may carry the second token fragment, and so on. In one embodiment, the recipient of a token sent through this header collects all headers with the "X-WSS-Token" base name and concatenate their content in sequence to reconstitute the content of the whole token.
In one embodiment, the X-WSS-Digest header may be used to communicate a digest of the body carried in the message. Portions of at least some HTTP headers may be included in the digest. In particular, at least some of the HTTP headers related to authentication may be included. This may include the "X-WSS" headers listed in Table 2. Prior to computing a digest, the content that is to be processed may be translated into a canonical form. Canonicalization of the content may include transformations such as putting all characters into lower case, removing whitespace, sorting headers or parameters alphabetically, normalizing URLs, or the like. The digest provides integrity protection and facilitates verification of the message body or headers. In one embodiment, this header is used in conjunction with the X-WSS-Security header with a signature that covers the message body, as indicated by the "sigusage" parameter. In one embodiment, the parameters of this message are used as follows:
"digest-method." This string specifies a hash algorithm used to compute the digest of the body.
"content-digest." This is a binary-valued parameter specifies the base64-encoded digest value.
X-WSS-Digest: method="shal" digest="3F679YHluax2dc"
"nonce-value." This specifies a new nonce value to be used for the next request authentication. If this parameter is present, it instructs the requester to use this value in the X-WSS-Security header of the next request message to that relying party.
"context-token." This parameter contains a security context token, such as an encrypted cookie, that represents the security context established for the requester by the relying party. This parameter instructs the requester that this security context token is to be used in future requests. The cryptographic key to be used to provide proof of possession of the security context is specified in the "context-token" parameter.
"context-token-secret." This parameter is used in conjunction with the "context-token" parameter. It specifies a secret symmetric cryptographic key that may be used by the requester to prove ownership of the security context represented by the "context-token" parameter.
A relying party may send the "nonce-value" parameter as a means of implementing one-time nonces. A relying party may use the "context-token" and "context-token-secret" parameter combination to establish a security context for the requester so that future authentications within that context do not have to include the security tokens (for example, if the token size is large) that were submitted with the initial request. In one embodiment, a requester and a relying party use transport-layer security such as SSL or TLS to protect the confidentiality of this exchange.
X-WSS-AuthInfo: ctxtoken="fg75kVB890Uwstm...", ctxtokensecret="gU59cJH..."
FIGURE 8 is a flow diagram illustrating a process 800 of generating an HTTP message, in an example embodiment. Process 800 illustrates at least some of the actions of block 418, as discussed above. The illustrated portions of process 800 may be initiated at block 802, where a security token is inserted into the message body or one or more HTTP headers. Actions of block 802 are discussed in FIGURE 6.
At block 804, a token location header may be generated, including a specification of the location of the security token. Actions of block 804 are discussed in FIGURE 6. Table 2 and associated discussion describe one embodiment of a token location header.
In one embodiment, the actions of block 810 are not performed, and a digest header is not generated. In various embodiments, other headers described herein may be excluded from a request header. The sequence of the blocks and associated actions of FIGURE 8 may be in any of a variety of orderings, and the process is not limited to the illustrated sequence.
Authorization: WSSEC profile=samlv1.1"
X-WSS-Security: nonce="uV3F3YluFJaxlc", timestamp="1288542340",
sigmethod="hmac-sha1", sigusage="auth-int",
signature="gU53F679YH1uax2dcJH...", version="1.0"
X-WSS-Digest: method="sha1" digest="3F679YHluax2dc"
X-WSS-Token1: w87xzV6F1m53K1uDJay3d...
sigmethod="hmac-shal", sigusage="auth-int",
X-WSS-Tokenl: w87xzV6F1m53K1uDJay3d...
It will be understood that each block of the flowchart illustrations of FIGURES 4-8, and combinations of blocks in the flowchart illustrations, can be implemented by software instructions. These program instructions may be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified in the flowchart block or blocks. The software instructions may be executed by a processor to provide steps for implementing the actions specified in the flowchart block or blocks. In addition, one or more blocks or combinations of blocks in the flowchart illustrations may also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the invention.
The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the scope of the invention, the invention resides in the claims hereinafter appended.
A computer-readable storage medium (204) comprising computer program instructions for processing messages exchanged between a requester (102) and a server (106), the program instructions executable by a processor (202) to perform actions including:
a) sending (410), to the requester, a server message (312) comprising one or more HTTP headers, the one or more HTTP headers including one or more authentication specifications;
b) receiving (504), from the requester, a request message (318) comprising a message body and a plurality of HTTP headers, the plurality of HTTP headers including:
i) a security token location specification (702) identifying a location of a security token (325); and
ii) a digest (510, 520) comprising a cryptographic representation of at least a portion of the message body and at least a portion of the plurality of HTTP headers;
c) if the security token location specification indicates that the security token is in the plurality of HTTP headers, extracting (706) the security token from the plurality of HTTP headers;
d) if the security token location specification indicates that the security token is in the message body, extracting (708) the security token from the message body;
e) extracting (510, 520) the digest from the plurality of HTTP headers;
f) verifying (510, 520) that the digest accurately represents the message body and the at least a portion of the HTTP headers; and
g) generating (408) a response message based on the security token.
The computer-readable storage medium of Claim 1, the actions further including:
The computer-readable storage medium of Claim 1 wherein , the server message is an HTTP error message, the actions further including inserting in the one or more authentication specifications an indication that the server authenticates received messages by processing each received HTTP authentication header of a set of HTTP authentication headers, the set of HTTP authentication headers including:
The computer-readable storage medium of Claim 1, the computer program instructions employed by an HTTP stack to authenticate each of the messages prior to passing each message to an application.
The computer-readable storage medium of Claim 1, the computer program instructions employed by an application to authenticate each of the messages after receiving each message from a server-side HTTP stack.
The computer-readable storage medium of Claim 1, the one or more authentication specifications including a digital signature specification, the actions further including verifying that the plurality of HTTP headers received from the requester include a digital signature that complies with the digital signature specification.
The computer-readable storage medium of Claim 1, the actions further comprising:
A computer-based system (100) for processing messages exchanged between a requester (102) and a server (106), comprising a message processor configured to perform actions including:
b) inserting (802), into the request message (318), a security token (325) conforming to a security token specification in the authentication specifications;
c) inserting (804), into the request message, an HTTP token location header that specifies a location of the security token, the security token location specification indicating that the security token is in the plurality of HTTP headers or in the message body of the request message;
d) inserting (810), into the request message, an HTTP digest header that includes a digest comprising a cryptographic representation of at least one HTTP header; and
e) inserting (806), into the request message, a security header that includes a digital signature of at least a portion of the request message.
The computer-based system of Claim 9, the actions further comprising determining a location of the security token based on a size of the security token, determining the location including determining whether the security token is to be in one or more HTTP headers or a message body.
The computer-based system of Claim 9, wherein the request message is an HTTP POST message, the actions further comprising inserting the security token in an HTML form field in the message body.
The computer-based system of Claim 9, the actions further comprising determining a location of the security token based on a size of the security token, determining the location including determining whether the security token is to be in exactly one HTTP header, a plurality of HTTP headers, or a message body.
The computer-based system of Claim 9, further comprising a second message processor that receives the request message, selectively extracts the security token from a message body based on the HTTP token location header, selectively extracts the security token from exactly one HTTP header based on the HTTP token location header, and selectively extracts a plurality of fragments of the security token from a plurality of HTTP headers based on the HTTP token location header.
The computer-based system of Claim 9, generating the request message comprising generating the one or more HTTP headers by employing HTTP header names that enable an HTTP stack of the server to authenticate the message by extracting and verifying the security token, and enable an application of the server to authenticate the message by extracting and verifying the security token if the HTTP stack of the server is not configured to extract and verify the security token.
The computer-based system of Claim 9, the actions further comprising inserting the security token into a message body, the HTTP token location header specifying that the entire message body contains the security token.
EP10775411.1A 2009-05-14 2010-05-11 Http-based authentication Active EP2430792B1 (en)
US12/465,725 US8078870B2 (en) 2009-05-14 2009-05-14 HTTP-based authentication
PCT/US2010/034402 WO2010132462A2 (en) 2009-05-14 2010-05-11 Http-based authentication
EP2430792A2 EP2430792A2 (en) 2012-03-21
EP2430792A4 EP2430792A4 (en) 2016-09-28
EP2430792B1 true EP2430792B1 (en) 2017-04-19
ID=43069462
EP10775411.1A Active EP2430792B1 (en) 2009-05-14 2010-05-11 Http-based authentication
US (1) US8078870B2 (en)
EP (1) EP2430792B1 (en)
JP (2) JP5658745B2 (en)
CN (1) CN102422593B (en)
WO (1) WO2010132462A2 (en)
US8447857B2 (en) * 2011-03-25 2013-05-21 International Business Machines Corporation Transforming HTTP requests into web services trust messages for security processing
JP6190106B2 (en) * 2012-11-19 2017-08-30 キヤノン株式会社 Authentication system, authentication apparatus, authentication method, and program
US10223550B2 (en) * 2013-11-06 2019-03-05 Vmware, Inc. Generating canonical representations of JSON documents
JP6418966B2 (en) * 2015-01-29 2018-11-07 キヤノン株式会社 Image forming system, image forming apparatus, control method for the system, and program
CN105407102B (en) * 2015-12-10 2019-05-17 四川长虹电器股份有限公司 Http request data reliability verifying method
WO2017130292A1 (en) * 2016-01-26 2017-08-03 株式会社ソラコム Server, mobile terminal, and program
JP6130941B2 (en) * 2016-02-03 2017-05-17 キヤノン株式会社 Authentication apparatus, method, and program
EP1627319A4 (en) * 2003-05-01 2009-11-11 Samsung Electronics Co Ltd Authenticating method and apparatus
CN101060519B (en) * 2006-04-19 2011-08-17 上海贝尔阿尔卡特股份有限公司 A control method and its device for the user to dial with the specified dialing program
JP2008276724A (en) * 2007-03-30 2008-11-13 Terumo Corp Web server, program for function as web server, and information provision method
AT429119T (en) 2007-05-18 2009-05-15 Sap Ag Method and system for protecting a message from an xml attack when exchanged in a distributed and decentralized network system
CN101350820A (en) * 2008-08-29 2009-01-21 中兴通讯股份有限公司 Safety authentication method for service-feeding proxy gateway to service-feeding initiator
2009-05-14 US US12/465,725 patent/US8078870B2/en active Active
2010-05-11 JP JP2012510942A patent/JP5658745B2/en active Active
2010-05-11 EP EP10775411.1A patent/EP2430792B1/en active Active
2010-05-11 CN CN2010800214848A patent/CN102422593B/en active IP Right Grant
2010-05-11 WO PCT/US2010/034402 patent/WO2010132462A2/en active Application Filing
2014-10-07 JP JP2014206285A patent/JP5889988B2/en active Active
JP2015026391A (en) 2015-02-05
US8078870B2 (en) 2011-12-13
WO2010132462A2 (en) 2010-11-18
WO2010132462A3 (en) 2011-02-24
EP2430792A2 (en) 2012-03-21
CN102422593B (en) 2013-03-13
US20100293385A1 (en) 2010-11-18
JP2012527179A (en) 2012-11-01
CN102422593A (en) 2012-04-18
JP5889988B2 (en) 2016-03-22
EP2430792A4 (en) 2016-09-28
JP5658745B2 (en) 2015-01-28
Santesson et al. 2013 X. 509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP.
Hammer-Lahav 2010 The oauth 1.0 protocol
Ipc: H04L 29/06 20060101ALI20160823BHEP
Ipc: H04L 9/32 20060101AFI20160823BHEP
Ipc: H04L 29/08 20060101ALI20161031BHEP
Ipc: H04L 9/32 20060101AFI20161031BHEP
Ipc: H04L 29/06 20060101ALI20161031BHEP
Ref document number: 886869
Ref document number: 602010041697