专利名称：单一签名安全服务访问的制作方法
介绍一般来讲，本发明涉及验证、授权和访问控制，更具体来讲，涉及允许用户只有一个电子ID用于对所有服务的安全访问、一般基于PKI(公钥基础结构)的验证的方法和系统。
背景验证、授权和访问控制对大多数(通信)服务提供商来说是不可缺少的三个领域。唯一的例外是完全开放的服务和匿名按使用付费服务。这个规范涵盖了其中指定的用户经授权可使用特定服务的正常情况。在成功验证之后，用户被授予对这些服务的访问权，然后经过访问控制过程。
当今针对ISP(因特网服务提供商)或其它基于IP(因特网协议)的通信基础设施的提供商的验证解决方案主要是基于用户名和密码。RADIUS(远程验证拨号服务)协议(以及其它协议、如TACACS+(终端接入控制器访问控制系统))提供对服务的访问，这些服务提供对验证信息以及分配到(已验证)用户名的授权的集中管理和确认。对于下一代这类协议，IETF(因特网工程特别任务组)的工作正在通过Diameter工作组进行。
通常要求用户对每个服务有独立的密码。随着提供越来越多的服务、尤其是当各服务通常要求独立的密码验证时，基于密码的验证变得复杂。为了管理这种复杂性，用户通常选择易于记忆的密码，并且反复使用同样的(用户名和)密码。
随着通过因特网提供越来越多的增值服务，重要的是为用户提供基于开放PKI(公钥基础结构)的用户验证来代替基于密码的验证的复杂度和缺陷，防止用户的服务被盗用，以及简化登录过程(一个电子ID用于对所有服务的访问)。还要求强有力的验证来保护客户和服务提供商免受欺诈。
PKI领域的发展水平尚未达到这种普遍性水平。目前，用户反而经常面对把不同的PKI解决方案(而不是不同的用户名和密码)用于对不同服务的访问的情况。而且，目前没有太多服务是“PKI启用”的，虽然这种功能性对于SSL/TLS(安全套接层/传输层安全性)客户验证过程形式的许多服务可能是潜在的。所述系统通过提供一般基于PKI的验证，改进现有技术水平。通过向其它服务提供商提供确认、可能还有授权服务，系统可提供用于一般基于PKI的验证的基础设施。
这个规范描述了通过使用证书和PKI技术、以及实现通过计算机网络提供的支付服务的机制、用于验证、授权和访问控制的改进方案。PKI解决方案的主要优点是普遍性、可缩放性和增加的功能性(加密的密钥管理、数字签名)。将来，用户会有一个密钥容器(例如智能卡)，其中包含构成用户的电子ID的私钥和证书。电子ID通常包括用于不同用途的两个或三个不同的私钥/证书对。大部分解决方案采用两对，一对用于加密(允许仅对这个特定私钥备份)，另一对用于所有其它目的。常常建议把数字签名功能归于独立的第三对，但这仍未在产品或服务中得到广泛支持。
用户应该能够自由选择电子ID的颁发者(证书服务提供商)。用户希望访问的服务应该不要求使用特定的证书颁发者。用户必须能够自由获取所需数量的电子ID。
目前，采用用户的基于PKI的验证的服务提供商通常只能接受来自一个或少数几个证书颁发者的证书。由于证书服务是不同的，因此服务提供商必须针对所有颁发者在某种程度上分别整合。当要接受来自不止少数几个颁发者的证书时，这迅速变得过于复杂而不可用。
同时，全球至少有数百个公共证书服务提供商，而且还有更多将要出现。服务提供商可能也希望接受来自各种各样公司内部证书服务的证书(这对于内联网使用是很常见的)。
所述体系结构把针对大量证书颁发者的整合的复杂度分到专用组件，从而从服务本身消除这种复杂度。用户必须注册其想使用的电子ID(即证书)。证书中的名称及其它特性、如其质量等级被链接到用户的服务简档。
在单个位置维护服务简档。某些服务可能要求优质电子ID来允许访问。
证书中的名称不需要是用户的真实姓名。根据策略，这可以是假名、作用名、机构识别码、预订名称等等。
采用电子ID，用户随后可登录网络，并获得对用户预订的所有服务的访问权。所述系统可提供针对为此而准备的服务的单一签名。对于要求其自身验证的服务，该系统的优点在于，用户的电子ID可以被再用，而不是必须为每种服务保持不同的密码。用户必须验证若干次，但始终使用同一方法。这依靠所述确认服务的可用性，以及在某种程度上还依靠授权服务。
这种系统的灵活性还允许用户自由选择操作系统。用于电子ID方案的软件常常是平台相关的。通过开放式PKI解决方案，用户可选择可由选定的操作系统支持的电子ID。
信用卡公司对于通过因特网的支付开始要求用户验证，而密码验证仅在短期内是可接受的。建立一般PKI将允许信用卡公司接受用户已经拥有的电子ID(只要它是合格的)，而不需要颁发独立的电子ID用于进行支付。
所述系统将提供一种用于增值服务、如视频点播(VOD)的安全验证、授权和访问控制的方式，以及提供一种用于保证支付安全的方式。
发明概述一般来讲，本发明涉及验证、授权和访问控制，更具体来讲，涉及允许用户只有一个电子ID用于对所有服务的安全访问、基于一般公钥基础结构的验证的方法和系统。所述系统通过提供一般基于PKI的验证，改进现有技术水平。通过向其它服务提供商提供确认、可能还有授权服务，系统可提供用于一般基于PKI的验证的基础设施。
本发明涉及如所附独立权利要求1所述的系统。此外，本发明涉及如所附独立权利要求11所述的用途。本发明还涉及如所附独立权利要求13所述的方法。在从属权利要求中描述了本发明的有利实施例。
参照附图的说明现在将参照附图来描述本发明，其中
图1表示验证和授权体系结构概况；图2表示用于检验用户证书的有效性的备选方法；图3表示验证、授权检查和服务访问过程的流程图；图4表示对增值服务的访问，以及图5表示确认服务概况。
图1表示根据本发明的系统体系结构。用户通常通过SSL/TLS客户机验证来进行验证，并且在访问服务器上通过关于所预订的一组服务的菜单得到对万维网接口的访问权。客户机与访问服务器之间的通信必须受到密码保护。SSL/TLS是优选的选择，因为这是保护万维网(HTTP)通信的常用方式，并且可结合用户验证。基于双方之间的IPSec/VPN(因特网协议安全性/虚拟专用网)的一种解决方案可以是备选方案。
所应用的验证协议(例如具有客户机和服务器验证的SSL/TLS)按照作为协议的一部分传递给访问服务器的用户证书中的名称暗中识别用户。用户还必须使用相应的私钥来签署证明拥有私钥的竞争/响应序列。
若给定用户的证书和签名，访问服务器可完成用户验证过程。但是，当采用撤销检查且以允许来自不同证书颁发者的不同证书的方式适当进行时，证书确认是在各访问服务器上运行的过于沉重的过程。在该体系结构中，独立组件、即确认服务被引入，以承担证书处理(的一部分)的责任(和负荷)。可根据需要重复确认服务。最后，访问服务器可以仅提取用户的证书，并将它传送到确认服务。返回的是对证书有效性的“是/否”回答、其质量等级(就可准许的授权而言可能是相关的)、从用户证书中的名称得到的用户名以及必要时可能更多的信息。但是，也可按照不同方式在访问服务器与确认服务之间分开负荷，例如通过在访问服务器上本地执行大部分证书处理，并且主要把撤销检查的任务(一般非常消耗资源)留给确认服务。
用户的简档应该保存在一个位置、即授权服务中。从用户的证书名称到相应用户名的映射是简档的组成部分，因此确认服务调用授权服务，以便在从证书提取名称之后获得这个映射。或者，确认服务可把证书名称返回到访问服务器，访问服务器则可通过对授权服务的独立调用来执行名称映射。在这种情况下，在确认服务与授权服务之间没有接口。
图2表示验证、授权检查和服务访问过程的流程图。若干协议可用于确认服务。如果确认服务要作为独立服务提供给服务提供商，则该协议必须是标准类型的。OCSPv1(在线证书状态协议，版本1)是一种备选方案，它使得能够检验证书的撤销状态，并返回某个附加信息、如用户名。但是，仅使用非指定的“扩展名”，无法以标准化方式向确认服务传递完整证书。OCSPv2属于高级草案RFC，并将提供发送完整证书的可能性。SCVP(简单证书确认协议)具有与OCSPv2同样的状态，并提供相同的功能性。XKMS(XML密钥管理服务)是另一个备选方案，如其它基于XML的机制一样，例如采用SOAP(简单对象访问协议)。
若给定已验证的用户身份，访问服务器则查询授权服务关于指定的用户应该被准许的访问权限。查询可通过例如用户的验证过程的质量等附加信息以及例如用户的当前位置、时刻等上下文信息来扩充。对授权服务的访问应该基于标准协议，这些协议可以是LDAP(轻型目录访问协议)、RADIUS、它的有计划的后续者DIAMETER或其它某种协议。
还能够把向授权服务的查找委托给确认服务。在这种情况下，访问服务器仅执行对确认服务的调用，并找回用户名以及与上述验证过程有关的其它信息和用户将被准许的授权。
在这个过程之后，将为用户提供正确的服务菜单。服务选择是下一个步骤，如以下所述。
图2的流程图表示在验证、授权检查和服务访问过程中采取的步骤。
下面将描述典型连接建立以及对服务的访问。用户设备或家庭网络经由某种接入点连接到网络运营商提供的基础设施，接入点通常提供在数据链路或接入层以及网络层的协议，即IP协议。接入点没有在图1中示出，因为它对于从用户到访问服务器的万维网接入只是作为路由器。接入点可以分为两个组件一个在数据链路/接入层提供服务，另一个为IP路由器。
当用户设备连接到网络基础设施时，通常为它提供了对所允许通信路径的缺省最小集合的访问权。在所示体系结构中，到访问服务器的路由必须被启用，域名服务(DNS)也将被启用。其它服务/路径可被添加到这个最小配置中。
当用户在用户设备上打开浏览器时，这必须被定向在访问服务器处的URL，以便用户获得对服务的访问权。然后用户必须通过验证过程和授权检查，并被给予对服务菜单的访问权。
基本上有三种服务可用通信服务，基于万维网的服务，以及包括多媒体的媒体服务。第三类可描述为另外两类的组合。下面描述对这些分类中的每一种所采取的动作。
通信服务当用户选择通信服务时，这个请求需要传递到用户的接入点，以便启用到所选目的地的路由。路由可在IP层被启用，为从用户的IP地址(的范围)到某个(某些)目的地(的范围)的业务开通。路由还可在数据链路层例如通过建立ATM(异步转移模式)虚电路来启用。
通信服务的一个实例可以是通过ISP的一般因特网访问。选择服务菜单中的因特网访问将启用从用户到ISP的接入节点(边界路由器)的路由，从ISP的接入节点可继续接入。
访问服务器需要把正确的命令传递到用户的接入点，以便启用所请求的通信服务。若干协议可用于这个目的，其中RADIUS作为最常用的备选方案。DIAMETER是RADIUS的有计划后续者。
对于在访问服务器上从服务菜单对基于万维网的服务的用户访问，存在三种不同的情况。
在第一种情况中，访问服务器通过向服务传递单一签名令牌，以单一签名方式传递对服务的直接访问。在最简单形式中，这是在HTTPPost操作中用于服务的用户名和密码，从而使用户透明地登录到该服务。然后，用户被重新定向到该服务，或者访问服务器继续作为HTTP代理媒介来工作。对于单一签名，有若干产品和技术可用，以及可使用来自这类技术的令牌。访问服务器也可能把cookie写入用户的浏览器，它在用户直接访问该服务时将作为单一签名令牌被识别和接受。该服务可有权访问授权服务，例如以便检查与服务使用有关的更详细特权。
在第二种情况中，服务是在所述系统的域内提供的，但要求独立验证。用户的电子ID(私钥和证书)被用于服务，即用户具有单一机制。服务有权访问确认服务，并且还可使用授权服务。
在第三种情况中，服务是在所述系统的域之外提供的。如果对于这种验证启用了服务，则使用该用户的电子ID(私钥和证书)，即用户具有单一机制。服务有权访问确认服务，但由于它不在系统的域中，因此不是经常有访问授权服务的权限。
确认服务是通用的服务，它可被提供给系统的域之内以及之外的合作方。确认服务可配置成根据调用它的服务返回不同的信息(例如不同的用户名)。这是基于PKI验证的一般性的直接结果。对于基于密码的验证，不能允许这种访问，因为密码会泄露给外部各方。
但是，授权服务通常只应该在系统的域内可访问。允许外部各方访问域内授权信息或者甚至通过相同服务管理授权信息，这在大多数情况下不是可接受的。
媒体/多媒体服务如上所述，(多)媒体服务可视为通信服务和基于万维网的服务的组合。某些媒体服务可完全实现为基于万维网或者通信，但通常的情况是提供用于服务建立的基于万维网的接口的服务以及依靠网络中功能性的服务实现。
如果访问服务器用作用户与媒体服务之间的代理，则可能截取通信并执行支持动作、例如发起它们之间的VPN或者向多播成员系统提供信息。
图3表示检验用户证书的有效性的备选方法。不是把用户的证书名称发送到授权服务，而是把它发送到访问服务器，访问服务器再从授权服务接收指定的用户身份。
图4表示对增值服务、如视频点播(VOD)的验证、授权和访问以及安全支付(根据按使用付费)的一个实例。
采用图1所示的验证体系结构对用户进行验证。内容在会话的整个持续时间中受到加密保护，以及根据按使用付费来保证支付。内容可采用电子ID所提供的用户密钥来加密。用户可选择支付方法、例如发票或信用卡，并采用用于验证的电子ID来签署交易。或者，用户可选择用于支付以及用于保证交易安全性的外部机制。
现在参照图2更详细地描述本发明。访问服务器通过验证用户以及为其提供适当的服务菜单，用作用户的服务接入点。为了在系统中执行其任务，访问服务器必须-支持HTTPS(基于SSL/TLS的HTTP)或者能够提供安全通信信道的其它方法；-能够向客户机/用户验证其自身，最好通过使用PKI技术(例如SSL/TLS服务器验证)；-支持与确认服务和授权服务进行通信所需的协议；-支持用于基于PKI的客户机/用户验证的一个或多个协议，通常为具有客户机验证的SSL/TLS；-实现向用户显示必要信息(如服务菜单)以及处理用户输入所需的功能性；-能够用作用户与服务之间的代理，即在它们之间透明地传递信息。
用户必须把浏览器定向到访问服务器提供的万维网接口，以便访问服务。通常，如上所述，将通过具有客户机验证的SSL/TLS来直接验证用户。
有两种备选方法如果采用另一种基于PKI的验证方法，则SSL/TLS会话可以仅通过服务器验证来建立，以及用户验证协议则可在该安全信道上运行。如果对于验证方法存在若干备选者，则用户可能面对用于选择方法的明文(即纯HTTP)页面。选择之后，验证例如通过建立具有客户机验证的SSL/TLS会话来继续进行。
如上所述，访问服务器依靠从用户获得用户的证书。还可实现用于获得证书的其它方法、如目录查找。
如以下部分所述，关于确认服务，尽可能多的本地证书处理应该在访问服务器中禁用，并留给确认服务来处理。访问服务器必须通过确认服务来确认用户的证书，检验用户对验证协议的竞争部分的签名，并根据这个验证的成功或失败进行动作。竞争的创建以及对竞争上签名的检验可在访问服务器外部进行。由于访问服务器易受到来自用户的攻击，因此可能希望采用受到更多保护的计算机用于这些安全性关键操作。
紧接用户验证的第一动作通常是从授权服务取出用户的服务列表，除非这已经从确认服务中获得。稍后，访问服务器按照用户输入、根据现行策略以及与用于要求针对用户简档检查的动作的授权服务配合进行动作。如图1所示，可实现单一签名机制。
对于证书处理优化了确认服务。它接收证书或者证书的标识及其颁发者，以及-读取颁发者的名称。
-从“好”密钥的预先评估列表中取出颁发者的公钥。所有交叉验证体系或层次都经过预处理，以及所有颁发者公钥是直接可信的，即不需要对证书链的处理。
-最好是通过对于由正规预取CRL(证书撤销列表)所得到的预处理撤销信息的本地调用来执行撤销检查。
-如果已收到完整证书，则分析证书，检查签名和有效性时期以及导出内容。这对于不同的证书简档需要分别处理。
-导出从证书信息映射的信息，例如从证书中的名称导出的用户名、质量等级(根据所述证书策略的分析来预先确定)等等。信息可以是通用的或者专门针对需要证书验证的实体。
这些操作可以在确认服务中被优化，提供必要的快速响应时间。具体来讲，对证书链的处理和撤销检查通常对服务器强加重负荷。为此，适当的撤销检查在当今的PKI启用服务中常常被抑制。确认服务器依靠对撤销信息的预处理以便加速该过程。
若干协议可用于确认服务。OCSP(在线证书状态协议)版本1是目前可用的，但没有传送完整证书的标准方法。作为因特网草案正在开发中的OCSP版本2增加了这种可能性。可补充或取代OCSP的备选协议是作为因特网草案协议的SCVP(简单证书确认协议)以及XKMS(XML密钥管理体系)。协议也可基于SOAP(简单对象访问协议，实质上为基于HTTP的XML)或类似技术，或者可设计某种专有协议。所有这些协议提供了向调用者返回附加信息以及对验证请求本身的“是/否/未知”回答的可能性。
OCSP主要目标是作为对来自一个认证机构的CRL颁发的替代。取代CRL或者作为对它的补充，证书颁发者提供OCSP接口，它仅回答关于这个认证机构颁发的证书的有效性的请求。在我们的上下文中，确认服务将对所支持的所有认证机构提供一个OCSP服务。
OCSPv1把撤销检查描述为OCSP服务的唯一功能性。这太窄，因此建议对它进行增强。首先，确认服务应该不仅检查证书是否已经被撤销，而且还检查它是否在其有效期之内以及颁发者在证书上的签名是否正确。此外，确认服务还应该分析证书，并通过确定质量等级和用户名以及可能还有更多的信息对内容起作用。
OCSP通过让调用者以数字方式签署请求(的部分)的可能性来提供对请求的客户机验证和完整性保护。确认服务器可相应地签署响应。这也可对其它协议备选者来实现。签署的响应可能极为重要，因为伪造或假造的响应可能构成重大威胁。签署的请求可以是必要的，以便返回调用者相关信息，除非以其它方式对调用者进行验证。
但是，由于签名处理(通常还意味着证书处理)相当费时间，因此可能更好的是确保对确认服务的调用是通过安全信道、例如通过VPN解决方案来进行。对于访问服务器与确认服务器之间的信道、也可能是从其它域内服务到确认服务的信道，这无疑应该是这样。如果向外部各方提供确认服务，则必须实现对于签署的请求和应答的规定，因为可能无法对所有这些外部各方要求VPN之类。
下面涵盖对采用确认服务的服务器的要求。具体来讲，这是访问服务器。
值得注意的是，这种服务驻留在访问服务器中。为了使用确认服务，(部分)证书处理在这些服务中应该是“短路的”。下面描述服务器中的处理的一些情况-SSL客户机验证服务器处的SSL处理必须提取客户机的证书，并且不进一步处理就把它转发到确认服务，或者在转发完整证书或从其中导出的信息之前本地执行一些处理。根据应答，SSL建立或者继续或者中止。
-数字签署消息的接收客户机(发送方)的证书可从消息中提取(或者通过其它方式获得)并被发送到确认服务。或者，一些证书处理可在证书或从其中导出的信息被发送到确认服务之前被本地执行。在成功确认之后，可本地检验在消息本身上的签名。确认服务也可被增强到在系统中处理对消息和证书的所有签名处理。
-随后将被用于到给定对应方的消息或信道的加密(的密钥管理)的证书的确认处理类似于数字签署消息中证书的接收。
-VPN的建立处理与SSL客户机验证情况大致相同。
-其它基于PKI的验证协议服务器必须获得客户机的证书，然后按照上述情况所述来调用确认服务。证书处理可完全留给确认服务来处理，或者可进行部分本地处理。
为了实现对确认服务的调用(以上列出的协议备选者)，对服务器软件的修改是必要的。可被“短路”的本地处理量取决于对特定服务器平台可能的修改。为得到最佳性能，对确认服务的调用应该与服务器中其它处理交替进行，部分或完全取代在大多数服务器平台中已经到位的功能性(本地证书处理)。这类修改通常相当复杂，取决于平台的开放性。此备选方案是额外功能性在可用的开放接口之上的添加，其中本地证书处理仅被短路到按照配置参数可能的程度。
还能够为用户(客户机)提供到确认服务的接口。在这种情况下，用户的浏览器(通常也可能是用户设备中的其它软件)中的证书处理完全或部分通过对确认服务的调用、而不是本地证书处理来代替。这类似于服务器的情况。这种接口的主要用途是对SSL服务器证书的处理，但还存在与VPN建立、数字签署消息的接收以及用于到对应方的消息/业务量的加密的证书确认等有关的用途。在这种情况下，来自确认服务的应答可被签署，以及来自用户的请求可被签署。如果确认服务代表用户检验证书的签名，则在标准浏览器中(例如在较新版本的Microsoft OS中)预先配置的(目前大约150个)证书颁发者公钥的列表可从用户设备中删除。用户对这类颁发者公钥的管理(信任)是PKI使用的主要障碍。
关于对不同证书颁发者的支持，在确认服务的引入背后存在两个基本概念-效率，通过针对证书处理优化此服务，尤其是通过避免对证书链的处理以及通过根据本地数据库查找而不是CRL处理来检查撤销。
-提供希望从一个以上证书颁发者接收证书的服务的单一整合点。
目前，采用基于PKI的验证的服务必须针对希望从其接受证书的各证书颁发者分别进行整合。具体来讲，整合复杂度与不同的证书格式、不同的命名方案、撤销信息的不同接入点以及颁发者公钥的管理有关。因此，服务只能与少数几个所选证书颁发者直接整合。确认服务从服务中消除了这种复杂度。
但是，当要支持许多证书颁发者时，甚至确认服务也面临复杂度问题。主要复杂度是确定质量等级，如下一节所述。颁发者公钥的管理必须是可靠的，且连续监测有关撤销和其它更新情况。来自不同颁发者的证书格式必须通过特定分析器来解释(虽然标准化简档在某种程度上有助于此任务，但需要确定所述简档)。从技术观点来看，确认服务不太复杂，但此服务的管理需要资源。但是，在许多上下文中，最好是使这种复杂度集中，而不是必须单独对每一个服务来应付它。
这针对希望通过此服务支持多少以及哪些证书颁发者的问题。全球存在数百个公开证书颁发者服务，还有更多将要出现。另外，人们将越来越多地发现公司(内联网)系统，它们可能基于来自例如Microsoft或IBM/Lotus的、允许任何人建立证书颁发服务的标准产品。虽然这些服务中的大部分将取得极差的质量和信任等级(例如未受到任何策略支持的颁发)，并且在公司内联网之外实际上是无用的，但可能出现希望能够接受来自合作公司或公司客户的证书的情况。
对这个问题的决定更多地属于管理而不是技术性的，只要确认服务实现的缩放属性是足够的。
一个极重要的要求在于，证书必须直接或间接地提供进一步处理所需的信息，尤其是可用于访问控制和记帐的名称。
对于证书和质量等级的分类，证书颁发服务由以下组件来定义-法律体制和协议；-证书策略，它提供对服务相关的程序的要求，并且通常涵盖法律体制和协议的多个方面(但是常常必须使之明确，从而保证独立点)；-证书实施说明，它说明这个特定证书颁发服务如何满足策略的要求-可表示内部程序文档；-证书格式，特别是命名惯例；-针对其它参与者的信任模型，尤其是针对分层结构和交叉验证体系的看法；-证书、撤销信息、策略信息和其它相关信息的信息/目录服务。
证书服务的质量方面主要从证书策略中导出。策略概述了用户必须完成以便获取证书的登记过程的要求(例如电子申请对具有物理验证的个人外貌)、颁发者同意在出错情况下承担的责任、强加到服务的操作上的安全性要求等等。幸好有几个用于编写策略的标准框架，并且大多数证书颁发者遵守其中之一。因此，证书策略可精确地进行比较。
但是，证书策略的分类是要求某种专门知识的主要人工任务。需要用于分类的分类标准和方法基础。哪种标准必须被满足以便达到某种质量等级？增加其它复杂度、例如以外语编写的策略以及引用外国的法律和法规。除非有人提出用于策略的分类/分级的独立服务，否则不得不对所有颁发者独立完成评估过程。
这意味着必须从少数重要颁发者开始，以后再根据需要扩充。
必须进行针对所支持策略的连续监测。但是，策略通常描述变化过程，而且许多颁发者将在策略大量变化的情况下支持其它各方的主动通知。
质量分类可以只是简单的数值，例如1-4，其中1作为顶层以及4作为差质量等级。没有对这些等级的标准化作太多工作。在EU内，“合格证书”等级(或多或少)已经作为优质指示符建立，以便支持正式数字签名。在美国，“联邦桥认证机构”定义了一些质量等级。向联邦部门提供服务的证书颁发者应该通过指出其本身策略与桥所定义的适当质量等级之间策略映射的桥进行交叉验证。ETSI目前正在进行“非合格策略框架”的工作，它将定义对于策略的分类应该考虑的一些指示符。
质量分类也可以比等级指示符细致得多。根据策略框架和ETSI的当前工作，一些参数可从策略中导出到可返回给调用者的结构中。例如，证书颁发者愿意承担的责任可能对可由验证根据来自颁发者的证书所支持的交易的值产生影响。策略所指出的权限是另一个重要参数。
注意，另一个问题在于，质量等级(策略及相关实施)只是证书颁发者所要求的，还是要求由第三方证明来支持。许多证书策略要求对服务的第三方审计，以便确保实际操作依据策略、实施说明和内部程序。这种审计报告可能意味着更高的质量等级，或者至少是关于等级的更大确定性。在这里，ISO9000或者ISO17799等证书也包括在内。
最后，注意，服务质量不一定意味着可信。(虚)“Mafia CA”可能实现高质量等级，但仍然不清楚其证书应被接受。
除了证书策略和质量等级之外，证书颁发服务的其它方面也必须被考虑。具体来讲，可能对证书格式提出要求，例如必须存在或者不应该存在的某些字段、属性或扩展名。命名是独立的问题，对于当今定义的系统，必须能够从证书中的名称转换成有效的用户名。在某些情况下可能出现的另一个要求是，名称必须是“真实的”，而不是假名。
图5表示确认服务的所建议体系结构。
它由以下部分构成-OCSP服务器，处理与此协议相关的语法和语义。其它协议的其它前端可在稍后添加，如虚线所示。
-确认引擎，处理证书、检查有效性以及导出信息。
-从确认服务管理的所有认证机构中预取及处理CRL的独立过程。
-可能需要OCSP客户机访问来自不支持CRL的证书颁发者的撤销信息。
-保存关于证书颁发者、其公钥、策略及相关质量等级的信息、通过上述过程更新的撤销信息以及可从证书中导出的附加信息的数据库。
-针对授权服务的接口(可能为LDAP)，以便得出从证书中的名称到系统域的有效用户名以及可能其它域的其它名称形式的转换。如上所述，这个接口可以来自访问服务器而不是确认服务。
-服务几乎肯定需要加密硬件(图5中未示出)。
关于操作、请求和应答，OCSP服务器和其它前端执行与确认服务有关的协议相关处理。这包括确认和产生对数字签署请求及应答的签名。
前端具有到确认引擎的API。确认引擎必须在包含证书时对它分析，或者以其它方式对所提交的证书信息起作用。
然后再对证书进行确认检查签名“正确”，证书格式“正确”，在有效期内，没有被撤销或挂起。这些检查的一部分依靠完整证书，并且在仅提交证书摘要时无法进行。根据证书中所指明的策略来取出质量等级(或者在颁发者没有在其证书中包括所建议的策略标识符扩展名的异常情况下从预先配置的知识中提取)。然后，从数据库中取出所导出的信息，并且将它们都通过API、以API所指定的形式返回给OCSP服务器(或其它前端)。
撤销检查通常只是本地数据库查找，因为CRL预取组件将收集必要信息(如以下所述)。但是，如果证书颁发者只对撤销检查提供OCSP接口，并且没有CRL颁发服务，则确认引擎实际上必须调用颁发者的OCSP服务。
也可想象确认服务可能被链接、并且调用是采用远程确认服务的前端所支持的协议(不一定为OCSP)来进行的情况。
据我们所知，当今大部分认证机构采用签署的CRL来通知证书的撤销和挂起。CRL通常被定期颁发，其中每个CRL包括下一版本的颁发的计划时间。但是，CRL可在必要时提前颁发。完整CRL是通常情况，即CRL包含所有撤销的证书的序列号。当下一个CRL的颁发时间是在证书的正常到期时间之后时，从将来的CRL中删除证书。可采用Δ-CRL、又称作增量CRL，其中CRL仅包含自前一个CRL以来的新条目。通过Δ-CRL，完整CRL被定期颁发，但比仅采用完整CRL的情况的次数少得多。
因此，CRL预取组件的正常情况是对所支持的各证书颁发者运行守护(deamon)进程，以及在计划颁发时间之后的极短时间提取并处理颁发者的完整CRL。处理结果存储在数据库中。但是，有一些需要支持的变量，以及确认服务需要知道不同证书颁发者的CRL策略，如其策略中所说明的那样。确认服务当然还需要知道CRL的分布点，以及需要有权访问这些点。CRL应该是公开可用的，但某些颁发者可能希望对提取收费，在该情况中，费用必须被传递给调用者或者以其它某种方式来记帐。
如果颁发者支持Δ-CRL，则这应该由CRL预取组件来使用，因为需要对每个取操作下载的数据量远小于对完整CRL所需的量。
如果颁发者已经指定CRL之间的长间隔，则这还可能意味着“在需要时颁发CRL”策略。在这种情况下，CRL预取组件应该定期轮询新的CRL，而不是等待下一个计划颁发。确认服务在CRL之间愿意接受的间隔是调谐参数，它影响确认服务的质量。这个间隔应该等于轮询时间，以及具有高于此间隔的CRL频率的所有颁发者都应该被轮询。
对于大规模的国际运营，一个可能从所有颁发者中取极大CRL的集中化安装显然是低效的。在挪威，每小时需要从全球数百个颁发者处取许多兆字节信息的安装可以工作，但它将是低效的，并且撤销信息的传播将会很慢。因此，分布式体系结构更适合CRL预取组件，但对它的进一步描述则超出本文的范围。
可能最终有一些颁发者根本不使用CRL，但对于撤销检查只依靠OCSP接口。在这种情况下，CRL预取组件无计可施，以及确认引擎必须在需要时调用适当的OCSP接口(或者另一个确认服务，如上所述)。
CRL预取组件所用的策略必须更详细地调整，因为比上述参数更多的参数将影响这些结果。主要要求是对于撤销信息的传播容许引入的延迟量。它一定是CRL的颁发与该CRL已经由CRL预取组件处理的时间之间的“间隙”。在这个间隙中到达确认服务的请求必须接收延迟响应-如果确认服务等待CRL预取组件完成其工作-或者在确认服务根据旧撤销信息立即应答时有错误回答的风险。
还存在每次颁发计划CRL时、颁发者的CRL分发服务因请求引起过载的风险，因为许多方同时尝试把新的CRL下载到本地高速缓存中。为了应付这种情况，一些颁发者实现“过颁发”策略。CRL比策略所述更频繁地被颁发。CRL预取组件必须考虑这类情况。
数据库存储关于各证书颁发者及其策略的信息以及撤销信息。还可能存储用户相关的信息，但在所述系统上下文中最好是把用户信息的存储和管理留给授权服务来处理。
颁发者信息将包括颁发者名称(在证书的“颁发者名称”字段中指定)、所述策略的标识(策略的OID(对象标识符)(几乎)总是包含在证书中)、必须用于确认证书的公钥或公钥列表(具有有效性间隔和密钥标识符/散列值)、以及与策略和颁发者有关的质量属性，如前面所述。
颁发者公钥的管理在当今是麻烦的，因为这始终为信任证书颁发者及其密钥的本地列表的形式，通常为自签署证书的形式(它提供完整性保护，但没有验证)。在所述系统中，颁发者密钥管理最好是集中于确认服务中。如果完整证书被传递到确认服务，以及颁发者对证书的签名的本地检查可在调用系统上被短路，这才是可行的。
颁发者密钥在部分手动(用于质量保证)以及部分自动的过程中被验证，并存储在数据库中。颁发者密钥的撤销是极罕见的事件，但这也是极为严重的事件。信息信道必须被监测，以便确保捕捉到这类撤销。在某些情况下，撤销将在分层结构的高层从颁发者通过CRL进行。在其它情况下，所述证书颁发者不是任何可信结构的成员，并且必须独立安排撤销。但是，撤销通知始终在策略中进行描述。
部分颁发者始终只有一个密钥对在使用，只是颁发者的密钥滚动通常意味着重叠，其中，旧公钥对于证书确认仍然有效，而私钥对于签署新证书无效。其它颁发者可能对频繁的密钥变化采用一种策略，在这种情况下，许多密钥可能同时有效(至少对于证书确认)。可能需要手动过程使颁发者公钥的数据库保持更新。
撤销信息的管理由CRL预取组件来进行。撤销检查通过数据库搜索本地进行，以便检查所述证书的序列号是否被列为已撤销。撤销信息必须加时标当前信息的取操作的时间，以及下一次取的计划时间。
授权服务的主要动机是单一位置中的用户相关信息的管理和保护。对于每个服务或者至少对于各服务平台，具有单独的验证和授权系统是当今的惯例。因此，预订/用户信息的管理-输入新信息、变更或删除信息-变得麻烦且易于出错。
授权服务把有关各用户的信息保存在一个数据库中。服务和数据库可以被复制。“用户”通常为个人，但它也可以是订户身份、组名或其它某个指定实体。信息与验证和授权相关。记帐信息可方便地添加到系统中，但在本文中没有描述。该信息对保密性和完整性敏感，以及授权服务和数据库必须得到充分保护。
目前，两个标准协议应该得到授权服务的支持LDAP和RADIUS。当规范准备就绪时，DIAMETER协议应该被支持。可支持其它协议。由于授权服务处理敏感信息，因此必须在信息被返回之前针对调用它的实体执行验证和访问控制。这可以是所用协议的一部分，基于基础协议(如SSL、TLS、IPSec或其它VPN技术)，或者依靠到对方的专用通信信道(物理的或逻辑的)。由于使用不同的协议，因此需要协议特定的前端，其方式与对于确认服务所述相同。
授权服务执行验证和服务访问的名称映射。所使用的基于PKI的验证协议将验证证书中的名称。这个名称可传递到授权服务，授权服务将返回相应的用户名。需要用户名的服务的名称应该是调用的参数，因为用户可能具有针对不同服务的不同用户名。在需要以及被请求时，密码可与用户名一起被返回。
在会话的稍后阶段，可调用授权服务，以便在需要时获得更多用户名。可向授权服务传递用户名/服务对，并要求它将此转换成另一个用户名/服务对，用于访问另一个服务。授权服务必须记录上次用于指定用户的验证机制的强度，并在通过返回或不返回信息来允许或拒绝对服务的访问时相应地动作。
系统中授权的第一层是这样用于对服务的访问。授权可链接到某些条件，例如足够质量的验证机制的使用、所允许的位置、只使用某种设备、时刻等等。另一个条件是记帐和保证支付，它到这时一直是独立服务，但可在以后被添加到授权服务中。所有这些条件必须被满足，以便允许进行访问。
另外，服务相关授权可存储在数据库中。在这种情况下，授权服务可在对特定对象(如某段内容)的访问尝试时从服务本身被调用，从而决定是否应该允许访问请求。
对授权服务的其它扩展是-颁发密码保护的“令牌”，作为授权的证明。这可基于签署特权(属性)证书、Kerberos凭单或类似的技术。
-处理授权从一个用户/参与者到另一个的委派。
-从用于访问决定的若干用户/参与者组成授权。
-在本文中不再描述这些问题。
所述系统使验证基于市场上可找到的(或非商业的)证书服务。所有证书管理、如登记、命名、颁发和撤销将由证书服务提供商维护。
授权服务需要维护用户名及相关特权的数据库。
证书中的名称在此上下文中不是直接可用的。因此，需要在用户名与用户希望用来验证的证书中名称之间建立映射。这可通过针对其它服务的更多用户名、以及可能还通过密码或其它验证信息来进一步扩展，以便使访问服务器能够让用户透明地登录到仅支持用户名/密码作为验证机制的服务。除证书之外，该系统可扩展到适合其它验证机制、如用户名/密码。
可能存在特定证书颁发者采用的命名格式可以被自动地转换成用户名的情况。但是，在大部分情况下，从证书名称到用户名的映射必须在数据库中明确地配置。为了避免管理开销，这对主要部分来讲应该作为用户的自助接口来实现。但是，还需要具有对数据库的扩展访问权的运营者的管理接口和定义。
用户必须有权访问自助接口，其中他们可提交证书及其预订的详细情况，以便使证书名称登记并链接到用户名。两个名称形式之间的链接无疑必须以安全方式建立。一种可能性是，为新用户提供两种备选方案第一个是为帐户签约，同时从系统所有者的优选伙伴处或者从备选证书颁发者的列表中预订电子ID。根据证书颁发者的策略，电子ID可以是可立即使用的，或者可能需要在稍后阶段被激活(例如，如果用户需要获取智能卡)。但是，对于授权服务，重要的信息是将出现在证书中的名称。
第二个是为帐户签约，以及指定用于验证用户的现有证书。证书的适用性必须针对(安全性)要求来检查，以及必须检验该证书的确属于新用户。它将足以登记一个证书，并且让用户稍后添加更多证书。
必须允许现有的用户登记附加证书或者替换已经登记的证书。这可以是作为基于万维网的服务可用的自行管理过程。注意，需要与将登记的新方法(新证书)相关的可接受的验证方法的规则。例如，不能首先引入低质量证书，然后再用它来登记高质量证书作为新验证方法。在这种情况下，高质量证书将有效地提供与根据低质量证书的验证相同的安全性，但给定配置对于低质量方法可能限制访问，而对于(在本例中好像)高质量验证允许访问。因此，验证方法仅可用来在相同或更低的安全性等级上引入新方法。
为了升级到更强的验证方法，必须应用沿着对于新用户所遵循的线路的过程。某个自行管理是可行的，但可能刚好是在某种程度上必须涉及手动过程的情况。
必须允许管理员添加、删除或改变其它用户的信息。可在运行授权服务的机构内部、相对可经由该系统到达的服务(的提供商)或者相对例如需要管理若干用户的预订的公司客户来定义管理员。管理员可使用与普通用户同样的接口或者在更适合的情况下采用另一种接口。批处理信息、例如在一个操作中添加关于许多用户的信息的可能性是必要的。
在大部分情况下，让预订的管理(即对服务的授权)留给各用户处理，是节省成本的。因此，对于验证信息的管理所述的自助服务还必须包括关于用户的其它信息(实际上，这种使用对于验证信息的管理可能是普遍的)。
授权的第一层将以这种方式提供服务-预订服务或终止预订。在更细分层，如果从各个服务委派到授权服务，则可管理与各个服务的特性有关的授权。一个实例可能是通信服务的预订带宽的变化。
当用户执行这类管理过程时，必须服从授权和其它限制。例如，用户无法预订要求强验证过程的服务，除非已经为该用户登记了足够质量的证书。另一个实例涉及服务中的内容预订，它可被限制到某个年龄以上的人员。
还需要管理员以便管理授权。例如，策略可规定，只有所定义的人员才可管理对公司用户的某些服务的访问权限。面向批处理的接口是必要的，以便在单一操作中管理关于许多用户的信息。
权利要求
1.用于为用户提供对来自服务提供商的至少一个服务的安全服务访问的系统，其中所述用户和所述服务提供商配备了用于连接到公共计算机网络的装置，所述系统包括-一个或多个确认服务单元，设置成用于执行以下步骤从访问服务器接收用户证书中的名称，控制所述用户证书的有效性，如果所述用户的证书是有效的，则或者把所述用户的证书名称发送到授权服务单元以便转换为用户名，并且把从所述授权服务单元返回的所述用户名传递到所述访问服务器，或者把所述用户的证书名称传递到所述访问服务器，如果所述用户的证书不是有效的，则拒绝所述用户对所述服务的访问；-一个或多个授权服务单元，设置成用于执行以下步骤从确认服务单元或访问服务器接收用户的证书名称，把所述用户的证书名称发送到数据库，从所述数据库接收用户名和简档，把所述指定用户身份码传递到所述确认服务单元或所述访问服务器，从访问服务器接收对访问权限的查询，从所述数据库查询预订信息，从所述数据库接收预订信息，根据所述预订信息确定访问权限，把访问权限传递到所述访问服务器；以及-一个或多个授权功能单元和相连的数据库，设置成用于执行以下步骤从授权服务单元接收用户的证书，在所述数据库中定位所述用户的名称和简档，把用户的名称和简档发送到所述授权服务单元，从授权服务单元接收对预定信息的查询，把预定信息发送到所述授权服务单元。
2.如权利要求1所述的系统，其特征在于还包括至少一个访问服务器，设置成用于执行以下步骤从所述用户接收请求，对用户进行验证并要求客户机授权，执行竞争/响应序列，向所述用户请求证书和拥有私钥的证明，把所述证书中的名称传递到确认服务单元，若是有效的用户证书，则从授权服务单元接收指定用户身份码，就访问权限查询授权服务单元，从所述授权服务单元接收访问权限，定位适当的服务菜单，向所述用户提供所述服务菜单，以及在所述用户与所述服务提供商之间传递信息。
3.如权利要求1或2所述的系统，其特征在于，所述访问服务器包括用于以下步骤的装置支持HTTPS，或者用于保护通信信道安全的其它装置，向客户机/用户验证所述访问服务器，最好通过使用PKI技术来进行，支持与所述确认服务和所述授权服务单元进行通信所需的协议，支持用于基于PKI的客户机/用户验证的一个或多个协议，实现向所述用户显示信息以及处理用户输入所需的功能性，用作所述用户与服务之间的代理服务器。
4.如权利要求1或2所述的系统，其特征在于，向所述用户请求证书和私钥可通过利用目录查找来执行。
5.如权利要求1或2所述的系统，其特征在于，所述访问服务器适合以单一签名方式传递对所述服务的直接访问。
6.如权利要求1或2所述的系统，其特征在于，存储所述用户名和简档的所述数据库还存储其它用户相关信息。
7.如权利要求3所述的系统，其特征在于，所述访问服务器在使用保护所述通信信道安全的其它装置时，建立仅与所述服务器验证的SLL/TLS会话，以及在所述建立的安全信道上运行所述用户验证协议。
8.如权利要求3所述的系统，其特征在于，若验证方法有若干备选者，则为所述用户提供选择，以及所述访问服务器建立与所选的客户机验证方法的SSL/TLS会话。
9.如权利要求5所述的系统，其特征在于，所述服务提供商包含在所述系统中，以及适合访问信息并与所述授权服务单元交换信息。
10.如权利要求1-9其中之一所述的系统，其特征在于，所述确认服务单元、所述授权服务单元以及所述授权功能单元是计算机实现的。
11.如权利要求1或2所述的系统的用途，用于提供对增值服务、如视频点播的验证、授权和访问。
12.如权利要求10所述的用途，其特征在于，所述信息通过加密来保护。
13.用于为用户提供对来自服务提供商的至少一个服务的安全服务访问的方法，其中所述客户和所述服务提供商配备了用于连接到公共计算机网络的装置，所述方法包括以下步骤借助于一个或多个确认服务单元；从访问服务器接收用户证书中的名称，控制所述用户证书的有效性，如果用户的证书是有效的，则或者把所述用户的证书名称发送到授权服务单元以便转换为用户名，并且把从所述授权服务单元返回的所述用户名传递到所述访问服务器，或者把所述用户的证书名称传递到所述访问服务器，以及如果所述用户的证书不是有效的，则拒绝所述用户对所述服务的访问；-借助于一个或多个授权服务单元从确认服务单元或访问服务器接收用户的证书名称，把所述用户的证书名称发送到数据库，从所述数据库接收用户名和简档，把所述指定用户身份码传递到所述确认服务单元或所述访问服务器，从访问服务器接收对访问权限的查询，从所述数据库查询预订信息，从所述数据库接收预订信息，根据所述预订信息确定访问权限，以及把访问权限传递到所述访问服务器；以及-借助于一个或多个授权功能单元及相连的数据库从授权服务单元接收用户的证书，在所述数据库中定位所述用户的名称和简档，把用户的名称和简档发送到所述授权服务单元，从授权服务单元接收对预定信息的查询，把预定信息发送到所述授权服务单元。
14.如权利要求13所述的方法，其特征在于还包括由至少一个访问服务器执行的以下步骤从所述用户接收请求，对用户进行验证以及要求客户机授权，执行竞争/响应序列，向所述用户请求证书和拥有私钥的证明，把所述证书中的名称传递到确认服务单元，若是有效的用户证书，则从授权服务单元接收指定用户身份码，就访问权限查询授权服务单元，从所述授权服务单元接收访问权限，定位适当的服务菜单，向所述用户提供所述服务菜单，以及在所述用户与所述服务提供商之间传递信息。
全文摘要
一般来讲，本发明涉及验证、授权和访问控制，更具体来讲，涉及允许用户只有一个电子ID用于对所有服务的安全访问、一般基于公钥基础结构的验证的方法和系统。所述系统通过提供一般基于PKI的验证改进现有技术水平。通过向其它服务提供商提供确认、可能还有授权服务，系统可提供用于一般基于PKI的验证的基础设施，处理来自基本上任何这类颁发者的电子ID。
文档编号G06F21/41GK1745356SQ03810810
公开日2006年3月8日 申请日期2003年3月18日 优先权日2002年3月18日
发明者J·罗塞博, J·奥尔内斯 申请人:特伦诺有限公司