基于http的认证的制作方法

专利名称：基于http的认证的制作方法
技术领域：
本发明一般涉及网络技术，更具体而言，涉及使用HTTP来认证联网环境中的请求。
背景技术：
计算机网络遭受各种安全违背。当用户或计算机系统为了访问它不被授权访问的资源，或以别的方式避免被正确地与请求相关联而虚假地标识其本身时，产生一种这样的类型的违背。为有助于请求认证，发往提供资源或服务的某一方(下文称为“依赖方”)的对服务的请求以这样的一种方式来包括请求方的身份，以使得依赖方可以验证该身份的真实性。请求认证是验证请求的发送方的身份的过程。认证提供每一方的标识都是准确的某种级别的安全性。请求方的身份形成由依赖方作出的访问控制决策的基础。一种类型的请求认证包括使用用户名和口令。一种更强的类型的认证涉及使用安全令牌。某些类型的安全令牌是由受信任的身份提供方所发出的。拥有安全令牌用于提供对于拥有方的身份证明。某些安全令牌嵌入了加密密钥，以便实现更强的安全性。在一种类型的交互中，请求方从身份提供方获取安全令牌。然后，请求方将安全令牌与服务请求一起呈现给提供资源或服务的某一方。资源提供方与身份提供方具有信任关系，该身份提供方充当安全令牌的真实性的保证。代表性状态传输(REST)是一种用于诸如万维网之类的分布式系统的软件体系结构的样式。REST —般是指通过HTTP传输域特定的数据而无需诸如SOAP之类的额外的消息传递层的接口。HTTP提供包括符合“赋有REST性质的”体系结构的诸如GET(获得)、 POST (传递),UPDATE (更新)和DELETE (删除)之类的方法的接口。REST体系结构的一个方面是对无状态服务器的支持，其中，每一个消息都包括理解消息所需的信息，使得服务器不必记住消息之间的通信状态。这有助于诸如服务器场中的服务器的缩放。在http://www. ietf. org/rfc/rfc2617. txt 处可用的 RFC 2617，描述了其中可以在HTTP头部字段中传递用户名和口令的BASIC (基本)认证方案。RFC将此方案描述为“不被视为安全的用户认证方法，因为用户名和口令以未加密的形式通过网络传递。” RFC还描述了 “摘要访问认证”方案，其中，使用用户名、口令、现时值、HTTP方法，以及被请求的URI 的散列。RFC声明，摘要方案“……受许多已知限制的困扰”。

发明内容
提供本发明内容以便以简化的形式介绍将在以下具体实施方式
中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。简单来说，系统、方法以及组件操作以提供允许应用认证HTTP请求的HTTP消息认证框架。该框架利用HTTP栈实现，向应用提供了一种实现各种请求认证方案的机制。一示例实施例包括带有一组HTTP头部以及相关联的语义的协议。描述了生成和处理HTTP消息的方法，以及请求方和依赖方之间的交互的各种变体。在一示例实施例中，请求方从服务器接收包括具有认证说明的一个或多个HTTP 头部的服务器消息。作为响应，请求方可以生成符合认证说明的请求消息。在一个实施例中，请求消息包括消息正文、安全令牌(ST)、指定安全令牌的位置的HTTP头部。请求消息可包括HTTP头部，该HTTP头部包括消息的摘要。安全令牌可以被置于一个或多个HTTP头部中或消息正文中。如果安全令牌被置于多个HTTP头部中，则它可以跨多个头部被分段。如果安全令牌被置于消息正文中，则它可以是整个正文，HTML表单字段或在XML元素中。在一个实施例中，摘要包括消息正文和至少一个HTTP头部或其某些部分的加密表示。在一个实施例中，请求方基于安全令牌的大小来确定安全令牌的位置。如果它太长而难以容纳在一个HTTP头部中，则它可以跨多个头部被分段。如果太长而难以容纳在多个HTTP头部中，则它可以被置于消息正文中。在一个实施例中，接收请求消息的服务器可以基于令牌位置头部说明来提取安全令牌。安全令牌可以在一个HTTP头部中，跨多个HTTP头部被分段，或在消息正文中。在一个实施例中，服务器向请求方发送签名说明，而请求方将符合签名说明的数字签名包括在安全头部中。在一个实施例中，服务器用包括上下文令牌的消息对请求方作出响应。在随后的请求中，请求方可在HTTP头部中包括上下文令牌，代替包括安全令牌。为了实现前述及相关目的，在这里结合以下描述及附图来描述系统的某些说明性方面。然而，这些方面仅指示了可采用本发明的原理的各种方法中的少数几种，且本发明旨在包括所有这样的方面及其等效方面。通过结合附图考虑本发明的以下详细描述，本发明的其它优点以及新颖的特征将变得显而易见。


参考以下附图来描述本发明的非限制性且非穷尽性实施方式。在各附图中，除非另外指明，否则在全部附图中相同的附图标记指代相同的部分。为了帮助理解本发明，将参考以下与附图相关联地阅读的具体实施方式
，附图中图1是其中可以实施各实施例的示例环境的框图；图2是示出了可以用于实现依赖方的计算系统的示例实施例的框图；图3示出了其中可以实施各实施例的示例环境；图4是示出了使用HTTP头部来认证请求方的过程的示例实施例的流程图；图5是更详细地示出了图4的一些动作的流程图；图6是示出了根据一示例实施例的将安全令牌插入到HTTP消息中的过程的流程图；图7是示出了根据一示例实施例的从HTTP消息中提取安全令牌的过程的流程图； 以及图8是示出了一示例实施例中的生成HTTP消息的过程的流程图。
具体实施方式
下文中将参考附图来更全面地描述本发明的各示例实施方式，附图构成实施方式的一部分且在其中作为示例示出了可在其中实践本发明的各特定示例实施方式。然而，本发明可被实现为许多不同的形式并且不应被解释为被限于此处描述的各实施方式；相反， 提供这些实施方式以使得本公开变得透彻和完整，并且将本发明的范围完全传达给本领域技术人员。特别地，本发明可被实现为方法或设备。因此，本发明可采用完全硬件实施方式、 完全软件实施方式或者结合软件和硬件方面实施方式的形式。因此，以下详细描述并非是局限性的。贯穿说明书和权利要求书，下列术语采用此处显式相关联的含义，除非该上下文在其他地方另有清楚指示。如此处所使用的，短语“在一个实施方式中”尽管它可以但不一定指前一实施方式。此外，如此处所使用的，短语“在另一个实施方式中”尽管它可以但不一定指一不同的实施方式。因此，可以容易地组合本发明的各实施方式而不背离本发明的范围或精神。类似地，如此处所使用的，短语“在一个实现中”尽管它可以但不一定指相同的实现，并且可以组合各种实现的技术。另外，如此处所使用的，术语“或”是包括性“或”运算符，并且等价于术语“和/ 或”，除非上下文清楚地另外指明。术语“基于”并非穷尽性的并且允许基于未描述的其他因素，除非上下文清楚地另外指明。另外，在本说明书全文中，“一”、“一种”和“所述”的含义包括复数引用。“在......中”的含义包括“在......中”和“在......上”。如此处所使用的，术语“认证”指的是确认事实或声明在可以接受的肯定度内是真实的。认证用户或用户的身份适用于确认所声明的用户的身份是充分且准确的。认证来自用户的请求可包括确认包括与请求一起包括的身份信息是准确的，请求是所标识的用户始发的或其授权的，请求没有被不适当地修改，或者请求中的其他信息是准确的。认证具有相关联的肯定度，从而允许存在信息已经被认证但可能不准确的情况。此处所描述的组件可以从其上具有数据结构的各种计算机可读介质来执行。组件可通过本地或远程过程诸如按照具有一或多个数据分组(例如，来自一个通过信号与本地系统、分布式系统中的另一组件交互或跨诸如因特网的网络与其它系统交互的组件的数据)的信号来通信。例如，根据本发明的各实施方式，软件组件可被存储在计算机可读存储介质上，包括但不限于专用集成电路(ASIC)、紧致盘(⑶)、数字多功能盘(DVD)、随机存取存储器(RAM)、只读存储器(ROM)、软盘、硬盘、电可擦除可编程只读存储器(EEPROM)、闪存或记忆棒。如此处所用的术语“计算机可读介质”既包括存储介质又包括通信介质。通信介质一般用诸如载波或其他传输机制等已调制数据信号来体现计算机可读指令、数据结构、 程序模块或其他数据，并且包括任何信息传递介质。作为示例而非限制，通信介质包括诸如有线网络和直接线连接等有线介质，以及诸如声学、无线电、红外线和其他无线介质等无线介质。图1是其中可以实施各实施例的环境100的框图。图1提供了对示例环境的基本理解，尽管可以使用许多配置，且许多细节未在图1中示出。如图1所示，示例环境100包括请求方102。请求方102可以是向远程服务提供商请求资源或服务的客户机计算设备、进程或任何组件。在示例实施例中，请求方102包括HTTP栈104。HTTP栈可以根据HTTP标准并以及此处所描述的至少一些机制来接收、处理、生成或发送超文本协议(HTTP)消息。
示例环境100包括依赖方106。依赖方106可以是计算设备、服务器或包括多个服务器的服务器场。图2示出了依赖方106的示例实现。在所示示例实施例中，依赖方包括HTTP栈108。HTTP栈108执行如对于HTTP栈 104所描述的动作，尽管HTTP栈108和HTTP堆栈104的实现可以不同，并且由各自所提供的功能也会不同。在一个实施例中，请求方102向依赖方106发送一个或多个请求。请求可包括某一类型的标识信息。请求可以是对资源或服务的请求。如此处所使用的，对服务的请求被视为对资源的请求。依赖方106可以处理该请求，并确定该请求是否包括充分地认证请求方102的请求或用户的信息。信息可以采用特定的格式，并被称为安全凭证。如果安全凭证没有被包括或不充分，则依赖方106可以拒绝该请求并指示请求方102提供充分的安全凭证。此处更详细地讨论此过程。示例环境100包括身份提供方110。身份提供方可以是向请求方102发出安全凭证的网络实体。安全凭证可以表示关于可以被依赖方106信任的请求方102的声明。由此， 身份提供方110被视为是被依赖方106信任的一方。在一个实施例中，安全凭证包括安全令牌(ST)，而身份提供方110包括提供安全令牌的安全令牌服务(STS)。一种类型的安全令牌包括表示关于诸如请求方102的用户之类的实体的一个或多个声明的集合的数据。声明可以被视为与声明方相关联的信息是准确的断言。这可包括， 例如，名称、标识符、键、组成员、特权、能力等等。这种类型的安全令牌此处被称为“直接安全令牌”。第二种类型的安全令牌包括对直接安全令牌的引用，该引用标识或允许对直接安全令牌的访问。这种类型的对直接安全令牌的引用此处被称为间接安全令牌。统一资源标识符(URI)是间接安全令牌的示例，如果它引用直接安全令牌的话。如此处所使用的，术语 “安全令牌”可以指直接安全令牌或间接安全令牌，除非上下文明确地指示一种特定类型。请求方102可以通过网络120与依赖方106或身份提供方110进行通信。网络120 可包括局域网、广域网或其组合。在一个实施例中，网络120包括因特网，因特网是网络的网络。网络120可包括有线通信机制、无线通信机制或其组合。请求方102、依赖方106或身份提供方110彼此之间或与其他计算设备之间的通信可以使用各种有线或无线通信协议中的一个或多个，如 IP、TCP/IP、UDP、HTTP、SSL、TLS, FTP、SMTP、WAP、蓝牙或 WLAN。图1只是合适的环境的示例，并不旨在就本发明的使用范围或功能提出任何限制。由此，在不偏离本发明的范围或精神的情况下，可以使用各种系统配置。例如，依赖方 106或身份提供方110的功能中的任何一个功能可以被合并到一个或多个计算设备中，以各种方式在多个计算设备之间分布或复制。类似地，可以以各种方式在一个或多个计算设备之间配置请求方102的功能。在一个实施例中，可以将依赖方106和身份提供方110的功能组合在一个或多个计算设备中。在一个实施例中，由一个或多个计算设备来实现请求方102、依赖方106以及身份提供方110中的每一个。计算设备可以是专用或通用计算设备。简而言之，可以使用的计算设备的一个实施例包括一个或多个处理单元、存储器、显示器、键盘以及定点设备以及通信接口。一个或多个处理单元可包括一个或多个多核处理器。示例计算设备包括大型机、 服务器、刀片式服务器、个人计算机、便携式计算机、通信设备、消费电子产品等等。计算设
8备可包括通用或专用的操作系统。由华盛顿州雷德蒙市微软公司出品的Windows 操作系统系列是可以在开发系统的计算设备上执行的操作系统的示例。图2是示出了可以被用来实现依赖方106或其一些部分的计算系统200的示例实施例的框图。在各实施例中，可以利用以各种方式配置的一个或多个服务器或其他计算设备来实现系统200。如图所示，计算系统200包括执行动作以执行各种计算机程序的指令的一个或多个处理器202。在一种配置中，处理器202可包括一个或多个中央处理单元、一个或多个处理器核、ASIC或其他硬件处理组件和相关的程序逻辑。在所示出的实施例中，计算系统200 包括可以包括易失性或非易失性存储器的存储器204。计算系统200也可以包括执行跨网络将消息或信号发送到远程设备或接收消息或信号的动作的网络通信单元。在所示出的实施例中，计算系统200包括存储在存储器204内的HTTP栈206和一个或多个应用210。HTTP栈206可以是HTTP栈108(图1)。在一个实施例中，HTTP栈206 包括执行认证接收到的请求的动作的认证模块208。在某些实施例中，HTTP栈206不包括认证模块208。在一个实施例中，计算系统200包括应用210。应用210可以执行各种服务，提供对一个或多个资源的访问，或响应于请求而执行其他动作。应用210的示例包括Web服务器、FTP服务器以及邮件服务器。应用210可包括应用认证模块212。应用认证模块212执行认证接收到的请求的动作，尽管不一定与认证模块208相同的动作。图3示出了其中可以实施各实施例的示例环境300。环境300可以结合图1的环境100或其变体而存在。如图所示，环境300包括请求方102、依赖方106以及身份提供方 110。请求方102与依赖方106和身份提供方110中的每一个进行直接或间接通信。通信可以是直接的或通过诸如网络120(图1)之类的网络。图3中的箭头表示在所示出的组件之间交换的消息。此外，在一个实施例中，消息的参考编号对应于附图中从顶部到底部的方向的时间顺序，尽管在各实施例中，顺序不同。在一个实施例中，所示出的消息中的每一个都是HTTP消息，在下文中更详细地描述其内容。结合图4来讨论图3的消息。图4是示出了使用HTTP头部来认证请求方的过程 400的示例实施例的流程图。过程400的一些动作由请求方102执行(图1)，并在图4的左列中在标题“请求方”下被表示。过程400的其他动作由依赖方106执行，并在图4的右列中在标题“依赖方”下被表示。过程400的一些动作涉及发送或接收图3中所示出的消息。下面的讨论引用了图3的消息。过程400的所示出的部分可以在框402被发起，在这里，请求方102向依赖方106 发送请求消息(请求消息310)。在一个实施例中，请求消息310是对资源的请求，通过认证过程保护了对该资源的访问。该过程可以从框402流向框404，在这里，依赖方106接收请求消息310。过程400可以从框404流向判断框406，在这里，就请求是否被充分地认证作出确定。在一个实施例中，这包括确定请求是否包括有效并且充分的安全凭证。对充分性的确定可以基于依赖方106的配置。在一个实施例中，框406的确定包括确定请求是否包括安全令牌并遵循已配置的方案。确定还可基于被请求的资源的价值，请求方的位置或配置，一天中的时间，或其他因素。此处讨论框406的动作的进一步的细节。
如果在判断框406确定请求被充分地认证，则过程可以流向框408，在这里，依赖方106可以向请求方102发送响应消息320。在一些配置中，响应消息320可以指示成功的响应。它可包括资源，资源可用的指示，已经提供或将提供的服务的指示，有助于获取资源的数据，或根据请求的另一个响应。在一些配置中，响应消息320可以指示由于除认证以外的理由而被拒绝的请求。例如，请求可以被正常认证，但是，用户可能不被授权访问资源。 资源可以由于其他理由而不可用。过程可以从框408流向程序出口或返回到进行调用的程序。如果在判断框406确定没有与请求消息一起包括充分的安全凭证，则过程400可以流向框410，在这里，可以生成HTTP错误响应消息，并将其从依赖方106发送到请求方 102。在一个实施例中，HTTP错误响应消息是HTTP “未经授权”消息312。这可以是包括 "ffffff-Authenticate (WWW-真实)，，响应头部的HTTP 401错误消息。消息可包括指示所要求的安全凭证的说明的数据，或当发送一个或多个安全凭证时要遵循的协议。协议被称为 “方案”，在使用一个或多个HTTP头部的方案的特定情况下，它被称为“HTTP方案”。过程400可以从框410流向框412，在这里，请求方102接收“未经授权”消息312。 尽管在某些环境中请求方102可以拥有充分的安全凭证或能够生成它们，在所示出的环境中，响应于接收到“未经授权”消息312，过程流向框414，在这里，请求方102可以试图获取充分的安全凭证，符合由依赖方106在“未经授权”消息312中所标识的方案。在一个实施例中，在框414，请求方102可以向诸如身份提供方110之类的受信任的身份提供方请求安全令牌。请求可以采用发送到身份提供方110的请求ST消息314的形式。请求ST消息 314可包括安全凭证或可以被用来认证请求方102的用户的其他数据。在某些环境中，响应于接收到请求ST消息314，身份提供方110可以确定请求方 102没有提供充分的标识数据，或者以别的方式不被授权接收安全令牌。此动作没有在图4 中示出。示例过程400示出了其中身份提供方110向请求方102返回被请求的安全令牌的环境。如图所示，过程400流向框416，在这里，请求方102接收包括安全令牌325的ST响应消息316。在某些实施例中，安全令牌包括一个或多个加密密钥。承载密钥的安全令牌的示例包括带有会话密钥的Kerberos v5权证和带有密钥持有人对象确认的SAML vl. 1或 v2. 0令牌。在一个实施例中，请求ST消息314和ST响应消息316符合此处所描述的至少一些消息协议。例如，请求方可以向ST请求消息314插入如此处所描述的令牌位置头部和令牌头部。消息还可以包括摘要头部和数字签名。此处提供这样的消息的示例。响应于在框416接收到安全令牌，过程可以流向框418，在这里，请求方102可以生成请求消息318并将其发送到依赖方106。请求消息318可包括类似于请求消息310的请求的请求。然而，请求消息318可包括从身份提供方110接收到的安全令牌325。在一个实施例中，请求消息318类似于带有额外的HTTP头部的提供认证数据的请求消息310。该过程可以从框418流向框404，在这里，依赖方106接收请求消息318。在框404，响应于接收到请求消息318，依赖方106可以处理该消息，以确定请求是否包括充分的标识凭证并符合已配置的认证方案，如参考请求消息310所讨论的。如果标识凭证被视为是不充分的，则过程可以流向框410，在这里，回复方可以发送另一个未经授权的消息312。如果在判断框406确定安全凭证是充分的，则过程可以流向框408，在这里，
10如上文所讨论的，发送响应。图3示出了消息的示例序列，其中，第一请求消息是不充分的， 而第二请求消息是充分的。示例消息序列示出了下面的消息序列。请求消息310。未经授权的消息312。请求ST消息314。ST响应消息316。请求消息318 (带有安全令牌)。响应消息320。在一个实施例中，环境可以得到如下的消息序列。请求ST消息314。ST响应消息316。请求消息318 (带有安全令牌)。响应消息320。在上面的示例序列中，请求方102可以在框414发送请求ST消息314 ；在框416， 请求方102可以接收安全ST响应消息316 ；在响应中，在框418，请求方102可以生成和发送请求消息318。然后，依赖方106可以在框408发送响应消息320。此序列可以，例如，在下列环境中产生其中请求方102响应于前面的请求先前已经接收到未经授权的消息312 或以别的方式被配置成获取适当的安全令牌并将其在请求消息中与适当方案一起发送。可以产生过程400的变体，包括按其他顺序发送所示出的消息，或其一部分。图5是示出了图4的判断框406的示例实现的流程图。判断框406的一些动作可以由依赖方106(图1)的HTTP栈206(图2)来执行，并在图5的左列中在标题“HTTP栈” 下被表示。判断框406的其他动作可以由应用210的认证模块212来执行，并在右列中在标题“应用”下被表示。出于上下文，图5用虚线包括图4的框404、410以及408 ；尽管在所示出的实施例中它们没有被包括在判断框406的动作中。图5中所示出的判断框406的动作此处被称为过程500。如图5所示，处理可以从框404流向框504，在这里，可以从HTTP消息的HTTP头部中提取认证方案的说明。请求消息318是这样的HTTP消息的一个示例。在一个实施例中， 说明可以是在依赖方106中配置的任何方案名称。过程500可以从框504流向判断框506，在这里，就HTTP栈206是否配置有对应于所指定的认证方案的处理程序作出确定。此处所描述的框架允许过程500在依赖方中利用对应于所指定的认证方案的HTTP栈处理程序或利用不是如此配置的HTTP栈来执行。如果在判断框506确定HTTP栈206被配置有对应的处理程序，则该过程可以流向框508，在这里，可以从接收到的消息中提取安全令牌。如此处所描述的，此处所描述的框架允许安全令牌被置于一个或多个HTTP头部中或请求消息的正文中。框506的动作包括确定安全令牌的位置，提取安全令牌，以及如果安全令牌有一个以上的段，则组装这些段。图 7更详细地示出框508的一些动作。过程可以从框508流向框510，在这里，可以执行对安全令牌的验证。在一个实施例中，框510的动作包括验证安全令牌正常地与它在其中被接收到的请求相关联。在一个实施例中，消息可包括请求消息的摘要，或其一部分。这可包括消息正文、安全令牌，以及HTTP头部的选定部分。摘要可包括消息的指定的部分的散列。框510的动作可包括验证摘要准确地表示消息正文以及HTTP头部的选定部分。验证安全令牌可包括生成摘要并验证它匹配与安全令牌一起包括的摘要。在一个实施例中，框510的动作包括验证涵盖了至少摘要的数字签名。签名可以使用嵌入在安全令牌中的加密密钥。这用于将安全令牌与消息强相关联。对安全令牌的验证可包括验证安全令牌是由诸如图1的身份提供方110之类的受信任的身份提供方所发出的。框510的动作可包括基于依赖方的配置来验证由安全令牌表示的任何声明是充分的，或包括如配置的对安全令牌数据的额外的验证。这可包括可被配置的几乎任何类型的验证。该过程可以流向判断框512，在这里，就安全令牌以及相关联的数据是否被正确地验证作出确定。如果验证失败，则过程可以流向过程400的框410，并如此处所描述的继续。 如果验证成功，则过程可以流向框514，在这里，向应用210传递请求消息或其一些部分。应用210可以以各种方式处理消息，包括过程400的框408的动作，在这里，它如此处所描述的继续。在一个实施例中，HTTP栈可以不被配置成根据指定的认证方案来提取和验证安全令牌。在判断框506，如果确定HTTP栈没有被配置有用于指定的认证方案的处理程序，则过程可以流向框526，在这里，向应用210传递请求消息，或其一些部分。这给应用程序210 提供了一种用于执行对接收到的消息的认证的机制。该过程可以从框516流向框518，在这里，可以从接收到的消息中提取安全令牌。 在一个实施例中，应用210可以被配置成执行相对于对请求消息的认证的HTTP栈206的至少一些动作。具体而言，框518和520以及判断框522的动作可分别包括对应的框508、510 以及512的动作，如此处所描述的。由此，过程可以从框518流向框520到框522，然后，到框410或框408，如上文对于对应的框所描述的。在一个实施例中，在判断框522处的失败的认证可以导致注入HTTP错误，如此处所描述的。此处所描述的至少一些机制允许依赖方106具有关于接收到的请求消息的各种配置。在一种配置中，HTTP栈206的认证模块208可以被配置成对接收到的请求的执行认证。在一种配置中，认证模块208可以不如此配置，并向应用210传递消息，在这里，应用认证模块212执行认证。在一种配置中，认证模块208可以执行认证动作的一部分，而认证模块212可以执行另一部分。由此，应用210可以被安装在各种计算系统200上，并可以用于各种HTTP栈配置。图6是示出了一示例实施例中的将安全令牌插入到HTTP消息中的过程600的流程图。过程600示出了如上文所讨论的框418的至少一些动作。过程600的所示出的部分可以在框602被发起，在这里，可以确定安全令牌的一个或多个位置。在一种实现中，安全令牌可以被配置成被置于一个或多个HTTP头部中或消息正文中的三个位置中的一个位置中。在判断框604，过程可以分叉到四个框中的一个框中，以处理相应的位置选项。一个这样的位置是在一个或多个HTTP头部中。如果确定这就是位置所在，则过程可以流向判断框 606，在这里，就是否要分段安全令牌作出确定。在一个实施例中，基于安全令牌的大小来作出此确定。如果在判断框606中确定可以将安全令牌插入到一个头部中，则过程可以流向框608，在这里，安全令牌被插入到一个HTTP头部中。过程可以流向框620。在一个实施例中，在框620，利用安全令牌位置的说明来生成HTTP令牌位置头部。然后，过程可以流向完成框622，并退出或返回到诸如框418之类的进行调用的程序。如果在判断框606确定将执行分段，则该过程可以流向框610，在这里，执行对安全令牌的分段，生成多个HTTP令牌头部，并将安全令牌的一段插入到每一个头部中。然后，该过程可以流向框620，在这里，可以生成令牌位置头部。在框620，如果安全令牌被分段，则令牌位置头部可以指定段的数量和每一个段的大小。过程可以流向完成框622。在判断框604，可以确定HTTP消息的整个正文将包含安全令牌。如果这被确定，则过程可以流向框612，在这里，将安全令牌插入到正文中。然后，该过程可以在框620继续， 在这里，可以生成令牌位置头部。在判断框604，可以确定安全令牌将被置于接收到的消息的HTML表单字段中。如果这被确定，则过程可以流向框614，在这里，可以生成指定的表单字段，并将安全令牌插入到其中。然后，该过程可以在框620继续，在这里，可以生成令牌位置头部。 在判断框604，可以确定安全令牌将被置于消息正文内的指定的XML元素中。如果这被确定，则过程可以流向框616，在这里，可以生成指定的XML元素，并将安全令牌插入到其中。然后，该过程可以在框620继续，在这里，可以生成令牌位置头部。图7是示出了一示例实施例中的从HTTP消息中提取安全令牌的过程700的流程图。过程700示出了如上文所讨论的框508和518的至少一些动作。过程700的所示出的部分可以在框702被发起，在这里，可以确定安全令牌的一个或多个位置。这可包括指定令牌的位置的令牌位置头部，如果它是分段的，还包括段的数量。在一种实现中，可以在四个位置中的任何一个位置配置安全令牌。在判断框704，过程可以分叉到四个框中的一个框中，以处理相应的位置选项。一个这样的位置是在一个或多个HTTP头部中。如果确定这就是位置所在，则过程可以流向框706，在这里，从每一个头部中提取安全令牌的一段。如果在一个以上的对应的头部中有一个以上的段，则将它们组装以形成安全令牌。然后，过程可以在图5的框510或520继续。在判断框704，可以确定HTTP消息的整个正文将包含安全令牌。如果这被确定，则过程可以流向框708，在这里，从正文中提取安全令牌。然后，过程可以在框510或520继续。在判断框704，可以确定安全令牌被置于接收到的消息的指定的HTML表单字段中。如果这被确定，则过程可以流向框710，在这里，从指定的表单字段中提取安全令牌。然后，过程可以在框510或520继续。在判断框704，可以确定安全令牌被置于消息正文内的指定的XML元素中。如果这被确定，则过程可以流向框712，在这里，从XML元素中提取安全令牌。在一个实施例中，通过使用在令牌位置头部字段中指定的查询来执行提取XML元素。然后，过程可以在框510 或520继续。过程600和700允许用于安全令牌的位置的若干个选项。例如，如果基于指定的 HTTP头部大小限制，安全令牌太长而难以放入单个HTTP头部，则它可以被置于多个HTTP头部中。如果基于对总的头部大小的HTTP约束，安全令牌太长而难以放入多个HTTP头部中， 则它可以被置于消息正文中。过程进一步容纳不同的协议的消息正文，包括HTML或XML。 例如，请求可以采用HTTP POST消息的形式。
示例消息本节描述了可以被用来实现环境300中所描述的消息或其他消息的消息内容的示例。这些描述将被理解为一组示例。在各实施例中，可以整体地或以其子集的形式使用这些示例来形成认证方案或协议。在各种实施例中，关键字或参数可以不同，并仍被用来执行此处所描述的至少一些机制。在一个实施例中，不使用这些示例中的任何一个。在一个实施例中，如此处所描述的消息被用来形成一个协议，该协议是对RFC 沈17的认证协议的扩展。这里使用了名称“WSSEC”作为此协议的标记(moniker)。此处所描述的协议有助于用于认证HTTP请求的各种方案。它还定义了一组新HTTP扩展头部以及它们的语义，供与WSSEC协议一起使用，以使得该协议可以在栈中的HTTP层或在HTTP层上方的应用中实现。如此处所讨论的，此处所描述的各种动作可以由应用210的应用认证模块212(图 2)或HTTP栈206的认证模块208来执行。在一个实施例中，消息和消息头部被设计成通过应用210或HTTP栈206容纳实现，以使得应用可以在其中HTTP栈不识别或处理至少一些头部或参数的环境中实现至少一些机制。例如，某些Web服务器被配置成剥去标准的HTTP 认证头部，如果它们不识别指定的认证方案的话。在这样的环境中，此处所定义的自定义头部仍对应用可用以执行认证协议。在某些环境中，HTTP栈可以被配置成识别和处理此处所描述的认证方案，使应用程序不必执行这些任务。由此，请求方可以以同样的方式与各种依赖方进行交互，不管依赖方是否具有识别或实现此处所描述的头部的HTTP栈。类似地，依赖方可以与各种请求方进行交互，不考虑每一个请求方的HTTP栈是否实现此处所描述的HTTP头部。另外，可以将应用部署在其中HTTP栈不处理认证方案的环境中。如果HTTP栈被更新以处理认证方案，则应用可以继续起作用，允许HTTP栈执行认证动作。表1示出了可以在所描述的消息中的每一个中使用的HTTP头部。在每一个消息中，可以包括未描述的额外的HTTP头部。表 权利要求
1.一种包括用于处理在请求方(10 和服务器(106)之间交换的消息的计算机程序指令的计算机可读存储介质004)，所述程序指令可由处理器(20 执行以执行包括下列各项的动作a)向所述请求方发送(410)包括一个或多个HTTP头部的服务器消息(312)，所述一个或多个HTTP头部包括一个或多个认证说明；b)从所述请求方接收(504)包括消息正文和多个HTTP头部的请求消息(318)，所述多个HTTP头部包括i)标识安全令牌(325)的位置的安全令牌位置说明(70 ；以及ii)包括所述消息正文的至少一部分和所述多个HTTP头部的至少一部分的加密表示的摘要(510，520)；c)如果所述安全令牌位置说明指示所述安全令牌在所述多个HTTP头部中，则从所述多个HTTP头部中提取(706)所述安全令牌；d)如果所述安全令牌位置说明指示所述安全令牌在所述消息正文中，则从所述消息正文中提取(708)所述安全令牌；e)从所述多个HTTP头部中提取(510，520)所述摘要；f)验证(510，520)所述摘要准确地表示所述消息正文和所述HTTP头部的至少一部分；以及g)基于所述安全令牌，生成G08)响应消息。
2.如权利要求1所述的计算机可读存储介质，其特征在于，所述动作还包括a)如果所述安全令牌位置说明指示所述安全令牌跨所述多个HTTP头部中的至少两个被分段，则提取所述安全令牌的每一个段并组装各段；以及b)如果所述安全令牌位置说明指示所述安全令牌正好在所述多个HTTP头部中的一个 HTTP令牌头部中，则从所述HTTP令牌头部中提取所述安全令牌。
3.如权利要求1所述的计算机可读存储介质，其特征在于，所述动作还包括a)向所述认证说明插入安全令牌格式的说明；以及b)验证所述安全令牌采用指定的安全令牌格式且所述安全令牌是由受信任的身份提供方所发出的。
4.如权利要求1所述的计算机可读存储介质，其特征在于，所述服务器消息是HTTP错误消息，所述动作还包括在所述一个或多个认证说明中插入对所述服务器通过处理一组 HTTP认证头部中的每一个接收到的HTTP认证头部来认证接收到的消息的指示，所述一组 HTTP认证头部包括a)指定所述安全令牌的位置的HTTP令牌位置头部，所述位置指示所述安全令牌在一个HTTP头部中，在多个HTTP头部中，或在所述消息正文中；b)包括所述安全令牌的至少一段的一个或多个HTTP安全令牌头部；c)包括所述消息正文的至少一部分和所述多个HTTP头部的至少一部分的加密表示的摘要令牌；以及d)包括表示所述接收到的消息的至少一部分的数字签名的安全令牌。
5.如权利要求1所述的计算机可读存储介质，其特征在于，在将每一个消息传递到应用之前，所述计算机程序指令被HTTP栈用来认证每一个消息。
6.如权利要求1所述的计算机可读存储介质，其特征在于，在从服务器侧HTTP栈接收到每一个消息之后，所述计算机程序指令被应用用来认证每一个消息。
7.如权利要求1所述的计算机可读存储介质，其特征在于，所述一个或多个认证说明包括数字签名说明，所述动作还包括验证从所述请求方接收到的所述多个HTTP头部包括符合所述数字签名说明的数字签名。
8.如权利要求1所述的计算机可读存储介质，其特征在于，所述动作还包括a)向所述响应消息插入上下文令牌；b)从所述请求方接收第二请求消息，所述第二请求消息不包括安全令牌；c)验证所述第二请求消息包括所述上下文令牌；以及d)基于验证所述第二请求消息包括所述上下文令牌，生成第二响应消息。
9.一种用于处理在请求方(102)和服务器(106)之间交换的消息的基于计算机的系统 (100)，包括被配置成执行包括下列各项的动作的消息处理器a)响应于服务器消息包括一个或多个HTTP头部，所述一个或多个HTTP头部包括认证说明，生成符合所述认证说明的请求消息；b)向所述请求消息(318)插入(802)符合所述认证说明中的安全令牌说明的安全令牌 (325)；c)向所述请求消息插入(804)指定所述安全令牌的位置的HTTP令牌位置头部；d)向所述请求消息插入(810)包括摘要的HTTP摘要头部，所述摘要包括至少一个 HTTP头部的加密表示；以及e)向所述请求消息插入(806)包括所述请求消息的至少一部分的数字签名的安全头部。
10.如权利要求9所述的基于计算机的系统，其特征在于，所述动作还包括，基于所述安全令牌的大小，确定所述安全令牌的位置，确定所述位置包括确定所述安全令牌是要被置于一个或多个HTTP头部中还是被置于消息正文中。
11.如权利要求9所述的基于计算机的系统，其特征在于，所述请求消息是HTTPPOST 消息，所述动作还包括将所述安全令牌插入到所述消息正文中的HTML表单字段中。
12.如权利要求9所述的基于计算机的系统，其特征在于，所述动作还包括，基于所述安全令牌的大小，确定所述安全令牌的位置，确定所述位置包括确定所述安全令牌是正好在一个HTTP头部中，还是在多个HTTP头部中，或是在消息正文中。
13.如权利要求9所述的基于计算机的系统，其特征在于，还包括第二消息处理器，所述第二消息处理器接收所述请求消息，基于所述HTTP令牌位置头部，从消息正文中有选择地提取所述安全令牌，基于所述HTTP令牌位置头部，从正好一个HTTP头部中有选择地提取所述安全令牌，以及基于所述HTTP令牌位置头部，从多个HTTP头部中有选择地提取所述安全令牌的多个段。
14.如权利要求9所述的基于计算机的系统，其特征在于，生成所述请求消息包括通过使用HTTP头部名称来生成所述一个或多个HTTP头部，所述HTTP头部名称允许所述服务器的HTTP栈通过提取和验证所述安全令牌来认证所述消息，而如果所述服务器的HTTP栈没有被配置成提取和验证所述安全令牌，则允许所述服务器的应用通过提取并验证所述安全令牌来认证所述消息。
15.如权利要求9所述的基于计算机的系统，其特征在于，所述动作还包括将所述安全令牌插入到消息正文中，所述HTTP令牌位置头部指定整个消息正文包含所述安全令牌。
全文摘要
一种用于认证HTTP消息的系统和方法。依赖方可以通过向请求方发送带有认证说明的HTTP消息，对来自请求方的请求作出响应。请求方用遵循由依赖方所指定的方案的新请求作出响应。一种框架允许将安全令牌置于HTTP头部中或消息正文中，存在诸如将令牌分段之类的各种选项可用。一个选项允许用密码将安全令牌绑定到消息的正文。一种认证框架提供了通过HTTP栈或通过应用的实现。
文档编号H04L9/32GK102422593SQ201080021484
公开日2012年4月18日 申请日期2010年5月11日 优先权日2009年5月14日
发明者A·K·纳恩达, H·威尔逊 申请人:微软公司