CN116405266A - 基于零信任联盟系统的信任评估方法及系统 - Google Patents

基于零信任联盟系统的信任评估方法及系统 Download PDF

Info

Publication number
CN116405266A
CN116405266A CN202310268844.3A CN202310268844A CN116405266A CN 116405266 A CN116405266 A CN 116405266A CN 202310268844 A CN202310268844 A CN 202310268844A CN 116405266 A CN116405266 A CN 116405266A
Authority
CN
China
Prior art keywords
context
user
relying party
management service
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202310268844.3A
Other languages
English (en)
Other versions
CN116405266B (zh
Inventor
马振华
杨龙雨
刘治军
宋文龙
徐涛
姬盼盼
马静
李互刚
刘宁波
冯喜
宝慧青
杨嘉鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shizuishan Power Supply Co Of State Grid Ningxia Electric Power Co ltd
Original Assignee
Shizuishan Power Supply Co Of State Grid Ningxia Electric Power Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shizuishan Power Supply Co Of State Grid Ningxia Electric Power Co ltd filed Critical Shizuishan Power Supply Co Of State Grid Ningxia Electric Power Co ltd
Priority to CN202310268844.3A priority Critical patent/CN116405266B/zh
Publication of CN116405266A publication Critical patent/CN116405266A/zh
Application granted granted Critical
Publication of CN116405266B publication Critical patent/CN116405266B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general

Abstract

本发明提供基于零信任联盟系统的信任评估方法及系统,属于网络安全数据处理技术领域。包括:所述依赖方RP接收所述用户的访问请求;所述依赖方RP向所述上下文管理服务CAP请求所述用户的联合上下文,其中,所述用户的联合上下文为所述上下文管理服务CAP从所述零信任联盟系统中各所述实体收集到的、上下文所有者为所述用户的所有上下文的集合;所述上下文管理服务CAP向所述依赖方RP提供所述用户的联合上下文;所述依赖方RP根据所述用户的联合上下文对所述用户的访问请求进行可信度评估,得出信任评估结果。

Description

基于零信任联盟系统的信任评估方法及系统
技术领域
本发明涉及网络安全数据处理技术领域,尤其涉及一种基于零信任联盟系统的信任评估方法及系统。
背景技术
ZTN(Zero Trust Networking,零信任网络)是一个访问控制模型,其核心原则是“从不信任,始终验证”。不同于传统外缘源网络那样依赖单一的隐式信任来进行访问控制,ZTN通过使用身份和上下文来验证每个访问请求。身份即实体在ZTN中的数字身份,上下文是关于发出访问请求的实体的信息,包括关于用户、用户所使用的设备、设备所连接的网络以及设备周围的物理环境等信息。此外,上下文不仅包括用户标识(ID)和设备供应商等静态信息,还包括基于过去行为的动态信息,例如最近的访问使用了什么设备,以及在何地进行访问等。
上下文只能由用户直接访问的实体和允许用户在各个设备中安装代理软件的实体收集,因此被访问的实体(如依赖方)需要自己不断地收集上下文,并使用收集的上下文以及访问者的身份来评估访问的可信度。
由于包含在访问请求中的上下文只有在访问者进行访问时才能收集到,因此一些访问量很少的实体(依赖方)有时无法收集足够的上下文,由于上下文数据量过少从而无法对访问者进行有效的信任评估。
发明内容
有鉴于此,本发明提供一种基于零信任联盟系统的信任评估方法及系统,引入零信任联盟系统中实体间共享上下文的机制,有效提高实体收集访问者上下文的数据量,以支持实体对访问者进行信任评估。
本发明实施例解决其技术问题所采用的技术方案是:
一种基于零信任联盟系统的信任评估方法,零信任联盟系统由至少一个身份联盟和独立于所述身份联盟的至少一个上下文管理服务CAP组成,所述身份联盟包括具有联盟身份的依赖方RP和用户、还包括用于提供所述联盟身份的身份提供者服务器,所述上下文管理服务CAP用于收集和管理实体的上下文、以及提供实体间共享的联合上下文,所述实体包括所述上下文管理服务CAP、所述依赖方RP、所述用户,方法步骤包括:
步骤S1,所述依赖方RP接收所述用户的访问请求;
步骤S2,所述依赖方RP向所述上下文管理服务CAP请求所述用户的联合上下文,其中,所述用户的联合上下文为所述上下文管理服务CAP从所述零信任联盟系统中各所述实体收集到的、上下文所有者为所述用户的所有上下文的集合;
步骤S3,所述上下文管理服务CAP向所述依赖方RP提供所述用户的联合上下文;
步骤S4,所述依赖方RP根据所述用户的联合上下文对所述用户的访问请求进行可信度评估,得出信任评估结果。
较优地,所述依赖方RP和所述上下文管理服务CAP之间基于连续访问评估协议实现所述用户的联合上下文的传输,所述步骤S3所述上下文管理服务CAP向所述依赖方RP提供所述用户的联合上下文包括:
所述依赖方RP创建流,并配置所述上下文管理服务CAP为流端点;
所述依赖方RP在所述流中添加对象端点,并请求所述上下文管理服务CAP批准,所述对象端点为拥有所述依赖方所要访问的上下文的上下文所有者;
所述上下文管理服务CAP批准添加所述对象端点至所述流中;
所述上下文管理服务CAP通过所述流将所述用户的联合上下文传输至所述依赖方RP。
较优地,所述零信任联盟系统还包括授权服务器,所述步骤S1所述依赖方RP接收所述用户的访问请求,所述访问请求中包含用户身份之前,还包括:
所述用户向所述上下文管理服务CAP发起上下文类型注册请求;
所述上下文管理服务CAP向所述授权服务器发起所述用户的上下文类型注册请求,所述用户的上下文类型注册请求包含所述用户身份和上下文类型ctxType;
所述授权服务器根据所述用户身份和所述上下文类型ctxType注册上下文标识ctxID,并回应所述上下文管理服务CAP;
所述上下文管理服务CAP接收到所述授权服务器的回应消息后,根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并回应所述用户;
所述用户接收到所述上下文管理服务CAP的回应消息后,注册所述上下文类型ctxType为所述上下文标识ctxID;
所述用户向所述依赖方RP发起上下文标识注册请求,所述上下文标识注册请求包含所述上下文类型ctxType;
所述依赖方RP根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并向所述用户发送注册完成消息。
较优地,所述步骤S2中所述依赖方RP向所述上下文管理服务CAP请求所述用户的联合上下文包括:
所述依赖方RP确认用于验证所述用户身份的全部所需上下文类型和所需权限范围;
所述依赖方RP获取所有所述所需上下文类型对应的所述上下文标识ctxID;
所述依赖方RP向所述上下文管理服务CAP发送联合上下文请求,所述联合上下文请求包含所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围。
较优地,所述步骤S3所述上下文管理服务CAP向所述依赖方RP提供所述用户的联合上下文包括:
所述上下文管理服务CAP接收所述联合上下文请求,并向所述授权服务器提交所述依赖方RP的所述联合上下文请求;
所述授权服务器根据所述联合上下文请求签发许可票据PT并发送给所述上下文管理服务CAP,所述许可票据PT用于描述所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围;
所述上下文管理服务CAP接收所述许可票据PT并转发给所述依赖方RP;
所述依赖方RP向所述授权服务器发送请求方令牌RPT请求消息,所述请求方令牌RPT请求消息携带所述许可票据PT、以及所述依赖方RP的信息声明,所述信息声明为对所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围的描述;
所述授权服务器验证所述许可票据PT,基于用户管理访问协议、根据所述用户的上下文访问策略和所述依赖方RP的信息声明进行授权决策,所述上下文访问策略包括允许授予上下文访问权限的依赖方身份、以及依赖方身份所对应的上下文内容访问权限的允许授予范围;
所述授权决策的结论为允许授权时,所述授权服务器向所述依赖方授予请求方令牌RPT,所述请求方令牌RPT中描述向所述依赖方授权的授权上下文标识、以及对用户上下文内容的授权访问范围;
所述依赖方RP再次向所述上下文管理服务CAP发送所述联合上下文请求,所述联合上下文请求携带所述请求方令牌RPT;
所述上下文管理服务CAP验证所述请求方令牌RPT;
所述请求方令牌RPT验证成功后,所述上下文管理服务CAP从来自于各个所述实体共享的上下文中识别出各个所述授权上下文标识所对应的所有上下文,并进一步按照所述授权访问范围选取出所述用户的联合上下文;
所述上下文管理服务CAP向所述依赖方RP发送所述用户的联合上下文。
进一步地,本发明提供一种零信任联盟系统,包括:至少一个身份联盟和独立于所述身份联盟的至少一个上下文管理服务CAP;所述身份联盟包括具有联盟身份的依赖方RP和用户、还包括用于提供所述联盟身份的身份提供者服务器;所述上下文管理服务CAP用于收集和管理实体的上下文、以及提供实体间共享的联合上下文,所述实体包括所述上下文管理服务CAP、所述依赖方RP、所述用户:
所述依赖方RP,用于接收所述用户的访问请求;还用于向所述上下文管理服务CAP请求所述用户的联合上下文,其中,所述用户的联合上下文为所述上下文管理服务CAP从所述零信任联盟系统中各所述实体收集到的、上下文所有者为所述用户的所有上下文的集合;
所述上下文管理服务CAP,用于向所述依赖方RP提供所述用户的联合上下文;
所述依赖方RP,根据所述用户的联合上下文对所述用户的访问请求进行可信度评估,得出信任评估结果。
较优地,所述依赖方RP和所述上下文管理服务CAP之间基于连续访问评估协议实现所述用户的联合上下文的传输;
所述依赖方RP,用于创建流,并配置所述上下文管理服务CAP为流端点;
所述依赖方RP,用于在所述流中添加对象端点,并请求所述上下文管理服务CAP批准,所述对象端点为拥有所述依赖方所要访问的上下文的上下文所有者;
所述上下文管理服务CAP,用于批准添加所述对象端点至所述流中;
所述上下文管理服务CAP,用于通过所述流将所述用户的联合上下文传输至所述依赖方RP。
较优地,所述零信任联盟系统还包括授权服务器:
所述用户,向所述上下文管理服务CAP发起上下文类型注册请求;
所述上下文管理服务CAP,用于向所述授权服务器发起所述用户的上下文类型注册请求,所述用户的上下文类型注册请求包含所述用户身份和上下文类型ctxType;
所述授权服务器,用于根据所述用户身份和所述上下文类型ctxType注册上下文标识ctxID,并回应所述上下文管理服务CAP;
所述上下文管理服务CAP,接收到所述授权服务器的回应消息后,根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并回应所述用户;
所述用户,接收到所述上下文管理服务CAP的回应消息后,注册所述上下文类型ctxType为所述上下文标识ctxID;
所述用户,向所述依赖方RP发起上下文标识注册请求,所述上下文标识注册请求包含所述上下文类型ctxType;
所述依赖方RP,用于根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并向所述用户发送注册完成消息。
较优地,所述依赖方RP,确认用于验证所述用户身份的全部所需上下文类型和所需权限范围;用于获取所有所述所需上下文类型对应的所述上下文标识ctxID;用于向所述上下文管理服务CAP发送联合上下文请求,所述联合上下文请求包含所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围。
较优地,所述上下文管理服务CAP,用于接收所述联合上下文请求,并向所述授权服务器提交所述依赖方RP的所述联合上下文请求;
所述授权服务器,用于根据所述联合上下文请求签发许可票据PT并发送给所述上下文管理服务CAP,所述许可票据PT用于描述所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围;
所述上下文管理服务CAP,接收所述许可票据PT并转发给所述依赖方RP;
所述依赖方RP,用于向所述授权服务器发送请求方令牌RPT请求消息,所述请求方令牌RPT请求消息携带所述许可票据PT、以及所述依赖方RP的信息声明,所述信息声明为对所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围的描述;
所述授权服务器,用于验证所述许可票据PT,基于用户管理访问协议、根据所述用户的上下文访问策略和所述依赖方RP的信息声明进行授权决策,所述上下文访问策略包括允许授予上下文访问权限的依赖方身份、以及依赖方身份所对应的上下文内容访问权限的允许授予范围;
所述授权服务器,在所述授权决策的结论为允许授权时,用于向所述依赖方授予请求方令牌RPT,所述请求方令牌RPT中描述向所述依赖方授权的授权上下文标识、以及对用户上下文内容的授权访问范围;
所述依赖方RP,用于再次向所述上下文管理服务CAP发送所述联合上下文请求,所述联合上下文请求携带所述请求方令牌RPT;
所述上下文管理服务CAP,验证所述请求方令牌RPT;
所述上下文管理服务CAP,在所述请求方令牌RPT验证成功后,用于从来自于各个所述实体共享的上下文中识别出各个所述授权上下文标识所对应的所有上下文,并进一步按照所述授权访问范围选取出所述用户的联合上下文;
所述上下文管理服务CAP,用于向所述依赖方RP发送所述用户的联合上下文。
由上述技术方案可知,本发明提供的基于零信任联盟系统的信任评估方法及零信任联盟系统,通过引入独立于身份联盟的上下文管理服务来收集和管理实体的上下文,并为实体提供实体间共享的联合上下文,由此联盟中的依赖方可以从上下文管理服务获取的联合上下文对具有联盟身份的用户的访问进行可信度评估,从而基于零信任实施访问控制,解决了现有技术中因依赖方的访问量小而无法开展有效验证的问题。
附图说明
图1是本发明实施例提供的一种基于零信任联盟系统的信任评估方法的流程图;
图2是本发明实施例提供的一种共享联合上下文的零信任联盟系统的示意图;
图3是本发明实施例提供的另一种共享联合上下文的零信任联盟系统的示意图;
图4是本发明实施例中联合上下文的传输流程;
图5是本发明实施例中的上下文管理服务代替用户向授权服务器注册上下文的流程;
图6是本发明实施例中在依赖方上进行上下文注册的流程;
图7是本发明实施例中授权服务器向依赖方授予用户权限的流程;
图8是本发明实施例中提出的一种依赖方的设计原型;
图9中示出了本发明实施例提供的零信任联盟系统实现在用户控制下共享联合上下文的示意图;
图10是基于图3所示系统所举例的一个零信任联盟的示意图;
图11中示例性地示出了在授权服务器中的管理上下文列表;
图12中示例性地示出了授权服务器中用户管理的上下文。
实施方式
以下结合本发明的附图,对本发明的技术方案以及技术效果做进一步的详细阐述。
为了安全地实施访问控制,保护系统免受老练攻击者的攻击,零信任的概念被John Kindervag提出。基于零信任概念的访问控制消除了隐式信任,通过使用上下文来评估每个访问请求的可信度。这里说的上下文是发出访问请求的实体的相关信息,包括发出访问请求的用户的信息及其所使用设备的状态信息,例如用户的IP地址、鼠标移动和击键、触屏输入、各种用户信息的指纹识别、用户的物理位置、设备周围的环境等。由于包含在访问请求中的上下文只有在访问者进行访问时才能收集到,因此一些访问量很少的实体有时无法收集足够的上下文,从而无法对访问者进行有效的评估。
身份联盟(IdF)是一类遵循信任框架规则的组织,信任框架是联盟身份管理的基础规则。IdF包括一个或多个共享用户访问权限的实体,允许用户在联盟中的一个系统完成身份认证后可登录联盟中的其他系统。
零信任架构(ZTA)由控制平面和数据平面组成,控制平面必须决定是否允许访问受保护的资源,它也被称为策略决策点(Policy Decision Point,PDP)。数据平面是用户与资源通信的地方,也是实施访问控制的地方。访问控制实施点也被称为策略实施点(PEP)。
BeyondCorp是谷歌在其内部网络中实现ZTN的实例,该项目的实施结合了PEP和PDP的接入代理以实现ZTN接入控制。这个代理也称为身份感知代理(IAP),它收集上下文,验证访问请求,并执行授权决策。通过结合PEP和PDP,策略更新可以快速一致地得到应用。然而,IAP保护身份联盟中的所有依赖方(Relying Party,RP)在访问请求中收集足够的上下文往往是难以做到的。这是因为一个IAP不可能理解和验证对每个RP发生的所有访问请求,并提供各种服务。即使IAP可以做到这一点,RP也会依赖于从IAP派生出来的隐式信任。
为了解决现有技术中所存在的上述问题,如图1所示,本发明实施例提供了一种基于零信任联盟系统的信任评估方法,该方法的实施主体为可共享联合上下文的零信任联盟系统,如图2所示,零信任联盟系统由至少一个身份联盟和独立于身份联盟的至少一个上下文管理服务CAP组成,身份联盟包括具有联盟身份的依赖方RP和用户、还包括用于提供联盟身份的身份提供者服务器,上下文管理服务CAP用于收集和管理实体的上下文、以及提供实体间共享的联合上下文,这里所提及的实体包括上下文管理服务CAP、依赖方RP、用户,这里,联盟身份是IdP发布的数字身份信息,RP使用它来识别用户。由于IdP签署发布联盟身份,因此RP得以验证联盟身份的完整性以及联盟身份是否是从RP所依赖的IdP发出的。IdP和RP加入IdF时,不仅在诸如传输协议和身份表示等技术规则上达成一致,而且还在合同上确定IdP管理身份的责任。
考虑身份联盟中零信任的场景,其中RP基于零信任概念实施访问控制,RP可以从IdP接收联盟身份从而能对用户进行身份验证。然而,身份联盟内部不能像共享身份一样共享上下文,仅依靠身份并不足以让RP评估每个访问请求的可信度;RP还应该通过使用收集的上下文来持续地评估访问的可信度,但是当用户很少访问RP的服务时,RP本身不能收集足够的上下文。
相关技术中,连续访问评估协议被提出以解决在身份联盟中共享上下文的问题。在该协议中,IdP不仅自己收集上下文,还从与IdP联合的RP收集上下文。IdP可以向想要接收上下文的RP提供联合上下文。这里,联合上下文指在多个实体之间共享的上下文。
虽然IdP可能有能力共享它收集的联合上下文(如果身份联盟有这种能力的话),但是让IdP管理联合上下文存在以下问题:
(1)上下文的生命周期与IdP相绑定,当发生实体的联盟身份切换时,将导致上下文失效;此外,当IdP没有了RP的管理权限时,它也将不再能调度这个RP所请求的上下文;假设用户使用RP1提供的服务,即使他为了登录到RP1而将IdP1更改为IdP2,并且RP1希望仅批准来自用户经常使用的网络的访问。如果IdP1向RP1提供这些上下文,则上下文被绑定到IdP1的管理身份,使得在改变到IdP2之后,RP1不再能使用曾经由IdP1提供的上下文。
由此可见,上下文的生命周期并不总是与IdP的管理身份的生命周期相同,不应把上下文绑定给身份联盟内的一个IdP管理。
(2)有些上下文并不能被IdP收集和管理:上下文由独立于IdP和RP的指定实体收集和管理,例如,端点检测和响应服务就是这种实体的一个例子,该服务收集和管理设备健康状态,例如设备是否遭到代理安装的软件带来的破坏。
因此,把上下文绑定给身份联盟内的一个IdP管理,将会导致有些上下文无法被有效收集和管理。
(3)单个IdP存在隐性信任问题:当单个IdP向RP提供上下文和身份时,RP隐式地依靠从该IdP得到的信任,通过使用相关的上下文和身份来实施访问控制。一旦该IdP受到威胁或无法正确处理凭据泄漏,攻击者就可以使用IdP颁发的联盟身份来冒充合法用户。因此,应该减少来自单个IdP的隐性信任。
综上,由于让IdP管理联合上下文存在诸多问题,因此为了解决这些问题,本发明实施例引入了一种新的实体,即CAP,它用于收集和管理实体的上下文,并为实体提供实体间共享的联合上下文。由此,IdF中的RP便可以根据用户的联盟身份以及从CAP获取的联合上下文对用户的访问进行可信度评估,以便实施零信任访问控制。此时身份联盟中不仅身份是共享的,上下文也是共享的,因此将零信任联盟定义为允许每个依赖方(RP)通过与IdP和CAP联合来实施基于零信任的访问控制的联盟,简称ZTF。在ZTF中,上下文和身份是共享的,因此RP可以基于零信任概念实施访问控制。
需要说明的是,对于任一CAP来说,它收集和管理实体的上下文,这里说的实体不仅包括依赖方和用户,还包括其他的CAP。
可以理解的是,由于CAP是独立于身份联盟之外管理上下文的,因此即便发生实体的联盟身份切换时,CAP收集的上下文仍然有效;同时CAP也可以被指定作为端点检测和响应服务这类实体来收集和管理IdP和RP无法收集的一些上下文。此外,由于CAP是独立于身份联盟之外的,因此当攻击者使用IdP颁发的联盟身份来冒充合法用户时,对于要从CAP上获取联合上下文的RP来说并不会因为与非法用户同属一个身份联盟而给予该非法用户任何隐式的信任。因此,RP通过使用来自CAP的联合上下文,能在评估访问请求的可信度时最小化对IdP的隐性信任。
参见图2所示,CAP1从RP1和RP2收集上下文,并向这些RP2提供相关的上下文;由于CAP1通过组合来自RP1的上下文和来自RP2的上下文来生成这些联合上下文,因此RP可以使用足够的上下文来做出授权决策。此外,RP2可以从CAP2接收直接从用户方收集来的上下文,并且其是独立于IdP和RP的实体。由于CAP独立于IdP,即使用户访问RP1时,将IdP1更改为IdP2,即联盟身份已被更改,用户在照常访问RP1时,仍然可以使用CAP1提供的联合上下文。此外,即使IdP3遭到攻击并且攻击者可以冒充合法用户,RP2也可以使用来自CAP1和CAP2的联合上下文来检测由已被攻击的IdP3签署联盟身份的用户发生的可疑行为。
本发明实施例提供的共享联合上下文的零信任联盟系统中,RP可以通过共享分布在RP之间的上下文,或从独立于IdP和RP的实体接收上下文来收集足够的上下文;上下文的生命周期不与特定IdP管理身份的生命周期相绑定;RP可以使用上下文来检测IdP已认证用户的异常行为。
在一个实施例中,依赖方和上下文管理服务之间基于连续访问评估协议(CAEP)实现联合上下文的传输。这里,CAEP是一种安全事件共享协议,它允许实体将收集的上下文传达给其他实体,因此,通过CAEP,RP可以向CAP共享其内部生成的用户事件,这些事件包括:正在使用的网络的变化或在正在使用的设备中发现的漏洞。也就是说,CAP可以使用此协议感知RP上发生的用户上下文更新,由此RP从CAP获取用户的上下文后,可以根据CAP收集到的用户的上下文进行连续的身份验证。CAEP目前正在OpenID Found的共享信号和事件工作组中进行标准化。
图1所示的基于零信任联盟系统的信任评估方法,步骤包括:
步骤S1,依赖方RP接收用户的访问请求;
步骤S2,依赖方RP向上下文管理服务CAP请求用户的联合上下文,其中,用户的联合上下文为上下文管理服务CAP从零信任联盟系统中各实体收集到的、上下文所有者为用户的所有上下文的集合;
步骤S3,上下文管理服务CAP向依赖方RP提供用户的联合上下文;
步骤S4,依赖方RP根据用户的联合上下文对用户的访问请求进行可信度评估,得出信任评估结果。
在这里,依赖方RP和上下文管理服务CAP之间基于连续访问评估协议实现用户的联合上下文的传输,可一并参照图4,步骤S3上下文管理服务CAP向依赖方RP提供用户的联合上下文包括:
步骤S31,依赖方RP创建流,并配置上下文管理服务CAP为流端点;
步骤S32,依赖方RP在流中添加对象端点,并请求上下文管理服务CAP批准,对象端点为拥有依赖方所要访问的上下文的上下文所有者;
步骤S33,上下文管理服务CAP批准添加对象端点至流中;
步骤S34,上下文管理服务CAP通过流将用户的联合上下文传输至依赖方RP。
在实际应用中,要在零信任联盟系统内实现共享联合上下文,需要零信任联盟系统中的各方均能够以一种统一、通用的方式正确识别上下文,本发明采用了上下文标识作为上下文的通用识别特征,令零信任联盟系统中所有参与访问和提供上下文的实体注册上下文标识,上下文标识的主要作用是能够使不同用户的不同上下文能够被零信任联盟系统内的各个主体正确识别。如图3所示,本发明实施例提供的零信任联盟系统进一步引入授权服务器AuthZSrv,授权服务器主要用于对上下文访问权限的授权、以及配合CAP完成上述的上下文标识的注册。
零信任联盟系统内所有参与访问上下文流程以及共享上下文的个体注册上下文标识的流程如下:
步骤S5,用户向上下文管理服务CAP发起上下文类型注册请求;
步骤S6,上下文管理服务CAP向授权服务器发起用户的上下文类型注册请求,用户的上下文类型注册请求包含用户身份和上下文类型ctxType;
步骤S7,授权服务器根据用户身份和上下文类型ctxType注册上下文标识ctxID,并回应上下文管理服务CAP;
步骤S8,上下文管理服务CAP接收到授权服务器的回应消息后,根据用户身份和上下文类型ctxType注册上下文标识ctxID,并回应用户;
步骤S9,用户接收到上下文管理服务CAP的回应消息后,注册上下文类型ctxType为上下文标识ctxID;
步骤S10,用户向依赖方RP发起上下文标识注册请求,上下文标识注册请求包含上下文类型ctxType;
步骤S11,依赖方RP根据用户身份和上下文类型ctxType注册上下文标识ctxID,并向用户发送注册完成消息。
具体的,CAP向AuthZSrv注册它所管理的上下文类型的过程参见图5所示,该注册流程基于UMA的联邦授权。在开始注册之前,需要用户向CAP发起“开始注册”的流程,以使CAP授权用户身份,即CAP同意为具有该用户身份的用户注册上下文类型;然后,按照下述流程CAP向AuthZSrv为用户注册上下文类型:
(1)CAP请求AuthZSrv授予用户的访问令牌(PAT),这个访问令牌称为由AuthZSrv发布的保护API(Application Program Interface,应用程序编程借口)令牌;
(2)AuthZSrv与用户交互,获得用户的同意许可;
(3)AuthZSrv用PAT作为用户许可的证明回应CAP;
(4)当CAP获得PAT后,CAP用PAT请求在AuthZsrv上为用户注册上下文类型(ctxType),请求时注明所要注册的上下文的范围(scopes);
(5)AuthZSrv验证PAT,识别谁拥有CAP所请求的上下文,然后根据上下文所有者的身份和上下文类型(ctxType)注册上下文标识(ctxID),该上下文标识在CAP中是唯一的;
(6)AuthZSrv用上下文标识符(ctxID)回应CAP,以使CAP为用户的上下文类型为ctxType的上下文完成注册上下文标识(ctxID)。
由此,通过注册上下文标识(ctxID),CAP和AuthZSrv之间便可以通过使用上下文标识来识别用户的上下文。
此外,CAP还用于配合用户向依赖方注册上下文标识,以使依赖方基于上下文标识来识别联合上下文,这样RP才能够使用上下文标识请求AuthZSrv授予相应标识的上下文的访问权限。
具体的,参见图6所示,用户将上下文标识注册到RP的流程如下:
(1)用户从CAP获取已经为ctxType注册好的ctxID;
(2)用户向RP请求注册ctxType的上下文标识ctxID;
(3)RP标识用户的身份,并注册用户拥有的上下文的ctxID;
(4)RP通知用户注册完成。
由此,RP和CAP之间、CAP和AuthZSrv之间便都可以通过使用上下文标识来识别用户的上下文。
值得注意的是,用户向RP注册上下文标识的流程超出了UMA的范围,因此本发明实施例虽是基于UMA实现上下文访问权限的管理的,但并非完全依赖UMA。
为了确保用户的隐私足够私密,本发明实施通过进一步在系统中引入授权服务器来确保在用户控制之下共享联合上下文,即在建立共享上下文时先获得用户授权。用户可以预先制定上下文访问策略,该上下文访问策略用于指定哪些依赖方能够访问用户的上下文,以及用于指定具有访问权限的依赖方能够访问用户的哪些上下文。
可一并参照图7所示的上下文提供流程,对应步骤S2和步骤S3:
第一部分:用户向RP发出访问请求,RP在没有用户授权的情况下请求上下文管理服务提供联合上下文:
步骤S21,用户向RP发出访问请求后,依赖方RP识别发出访问请求的用户的身份标识,再确认用于验证用户身份的全部所需上下文类型和所需权限范围;此步骤是RP确定在哪些范围内需要什么类型(ctxType)的上下文来做出允许访问的决定;
步骤S22,依赖方RP获取所有所需上下文类型对应的上下文标识ctxID;
步骤S23,依赖方RP向上下文管理服务CAP发送联合上下文请求,其中,联合上下文请求包含所有所需上下文类型对应的上下文标识ctxID、以及所需权限范围;此时,RP在没有用户授权的情况下请求上下文管理服务CAP提供联合上下文,这里,RP是否有用户授权取决于RP是否具有AuthZSrv授予的请求方令牌(RPT);
第二部分:CAP从AuthZSrv中获取RP的权限票据,具体的:
步骤S31,上下文管理服务CAP接收联合上下文请求,并向授权服务器提交依赖方RP的联合上下文请求;
步骤S32,授权服务器根据联合上下文请求签发许可票据PT并发送给上下文管理服务CAP,许可票据PT用于描述依赖方的所有所需上下文类型对应的上下文标识ctxID、以及所需权限范围;
步骤S33,上下文管理服务CAP接收许可票据PT并转发给依赖方RP;
第三部分:RP请求AuthZSrv授予RPT,具体的:
步骤S34,依赖方RP向授权服务器发送请求方令牌RPT请求消息,请求方令牌RPT请求消息携带许可票据PT、以及依赖方RP的信息声明,信息声明为对依赖方的所有所需上下文类型对应的上下文标识ctxID、以及所需权限范围的描述;
步骤S35,授权服务器验证许可票据PT,基于用户管理访问协议(UMA)、根据所述用户的上下文访问策略和所述依赖方RP的信息声明进行授权决策,所述上下文访问策略包括允许授予上下文访问权限的依赖方身份、以及依赖方身份所对应的上下文内容访问权限的允许授予范围;决策具体是指将RP发来的声明与用户指定的上下文访问策略作对比,以决定是否通过RP的请求;
步骤S36,授权决策的结论为允许授权时,授权服务器向依赖方授予请求方令牌RPT,请求方令牌RPT中描述向依赖方授权的授权上下文标识、以及对用户上下文内容的授权访问范围;
第四部分:RP在有RPT的情况下请求CAP提供上下文,具体的:
步骤S37,依赖方RP再次向上下文管理服务CAP发送联合上下文请求,联合上下文请求携带请求方令牌RPT;
步骤S38,上下文管理服务CAP验证请求方令牌RPT;
步骤S39,请求方令牌RPT验证成功后,上下文管理服务CAP从来自于各个实体共享的上下文中识别出各个授权上下文标识所对应的所有上下文,并进一步按照授权访问范围选取出用户的联合上下文;
步骤S310,上下文管理服务CAP向依赖方RP发送用户的联合上下文,这里提供的联合上下文是用户限定许可范围提供的、且携带有上下文标识ctxID。
由此,RP便可以将上下文标识为ctxID的上下文与用户的标识进行关联,从而感知用户的上下文,并用所感知的上下文对用户的访问请求进行可信度评估。
其中,授权服务器可以在他方请求访问用户的上下文时,由用户当下指定是否允许或访问,或者用户也可以预先向AuthZSrv指定好其上下文访问策略,而无需每次等到请求来到时再指定,这样可以减少打扰用户的次数;因为在实际的ZTF中,会有大量的CAP向大量的RP提供上下文,与此同时也会有大量的CAP从大量的RP上收集上下文,以致用户需要控制许多上下文的访问权限。
UMA是一个被称为OAuth2.0的授权委托协议的拓展,它允许拥有上下文的用户只将对上下文的访问权授予用户已经授权的实体,同时允许第三方(客户端)代表资源所有者提供有限的资源服务器访问。在资源服务器上,资源所有者调度其拥有的资源。资源由授权服务器保护,授权服务器要求资源所有者对来自客户端的资源访问请求做出授权决定。当资源所有者批准时,授权服务器会向客户端颁发一个访问令牌,该令牌代表授予的权限。资源服务器验证所提供的令牌,并确定访问的有效性。这样,资源所有者可以用OAuth2.0将授权委托给客户端。UMA从以下两点扩展了OAuth2.0:在OAuth2.0中,客户端由可以做出授权决定的资源所有者操作,但是在UMA中,客户端由一个被称为资源请求方(发出访问请求的实体)操作,该请求方并不总是资源所有者。正是这样,UMA扩展了授权服务器,根据资源所有者预先设置的策略做出授权决定。这两点扩展允许请求方在资源所有者预先设置的权限范围内访问资源服务器。
本发明实施例在ZTF中使用UMA具有以下两个优点:
(1)AuthZSrv可以集中管理RP和CAP中的联合上下文,并控制哪些RP和CAP可以访问哪些联合上下文;
(2)AuthZSrv可以基于用户已经设置的上下文访问策略自动做出授权决定,而无需每次都请求同意动作来建立上下文共享给新的RP。
在一种实现方式中,可以采用Golang、JWT(JSON Web Token)库以及HTTP(HyperText Transfer Protocol,超文本传输协议)实用程序库创建本发明实施例提供的共享联合上下文的零信任联盟系统,其中以KeyCloak作为IdP和授权服务器。源代码可在GitHub上获得。Golang是一种静态强类型、编译型语言;Keycloak是一个开源的独立的认证授权服务器;GitHub是一个面向开源及私有软件项目的托管平台。
图8中示例性地示出了本发明实施例提供的共享联合上下文的零信任联盟系统中,有关RP的一种设计概述,这种设计受到XACML(可扩展访问控制标记语言)数据流模型的启发。其中,RP通过在策略执行点(PEP)执行访问控制来保护其管理的服务。PEP要求控制器(图8中用Controller表示)做出授权决定,例如该访问请求是否被批准。策略信息点(PIP)为控制器提供身份和上下文,策略决策点(PDP)决定授权决策。RP使用认证代理(图8中用AuthN Agent表示)从IdP收集联盟身份;使用上下文接收器代理(图8中用CtxRx Agent表示)从CAP收集联合上下文;根据用户的联盟身份以及从CAP获取的联合上下文对用户的访问进行可信度评估以决定是否批准用户的访问请求;当有CAP要收集上下文时,使用上下文发送器代理(图8中用CtxTx Agent表示)向CAP提供上下文。
图9中示出了本发明实施例提供的共享联合上下文的零信任联盟系统实现在用户控制下共享联合上下文的示意图。其中,当CAP与RP共享联合上下文时,CAP使用UMA资源服务器(图9中用UMA ResSrv表示)功能注册AuthZSrv的上下文。RP请求AuthZSrv授予对上下文的访问权,如果获得批准,AuthZSrv将发出请求方令牌(RPT)作为授予访问权的证明。RP将RPT呈现给CAP,CAP使用CAEP传输功能提供联合上下文。反之亦然,当CAP从RP收集上下文时,CAP请求RP传输联合上下文。
图10中示例性地示出了一个共享联合上下文的零信任联盟系统,其中RP1、IdP1和IdP2属于一个名为IdF1的身份联盟。RP2和IdP3属于另一个名为IdF2的身份联盟。RP1、RP2、CAP1、CAP2和CAP3均属于ZTF,ZTF下的联合上下文共享由AuthZSrv控制。
其中,CAP1收集和管理关于设备定位的上下文,具体是管理关于哪些用户使用哪些设备以及用户在哪里使用这些设备的上下文。CAP1从RP收集设备标识符和网络信息。当用户批准时,CAP1向RP1和RP2提供许可范围内的联合上下文。例如,上下文包括关于在访问请求中使用的设备,是否已经被用户使用过,以及设备使用的网络位置是否已经被该设备先前使用过的信息。
CAP2收集和管理关于设备健康状态的上下文,具体是管理关于哪些用户使用哪些设备以及这些设备的版本是否是最新的上下文。CAP2从安装在每个设备中的代理收集设备标识符和设备版本信息。当用户批准时,CAP1向RP2提供许可范围内的联合上下文。
CAP3收集和管理用户周围的物理环境的上下文,它从Wi-Fi接入点收集上下文,并管理有关访问请求中使用的设备是否与列入白名单的Wi-Fi接入点相连接的上下文。CAP3向CAP1提供联合上下文,CAP1将CAP3提供的上下文与自己收集的上下文聚合在一起。
基于以上设定,该系统中共享联合上下文的情形存在多种,包括:
(1)提供从CAP2到RP2的上下文。
假设RP2希望仅批准那些使用最新版本设备的用户访问其服务,但是RP2自身无法收集这些上下文。尽管IdP3向RP2提供了联盟身份,但IdP3不能提供这些上下文以及联盟标识,因为IdP3不具有收集设备健康信息的能力。但是,CAP2可以通过安装在用户使用的设备中的代理软件来收集设备健康信息。也就是说,在该ZTF中,CAP2可以向RP2提供关于请求访问的用户所使用的设备是否是最新版本的上下文,以便RP2可以基于其策略实施访问控制。
可以理解的是,该情形(1)表明了ZTF允许RP从独立于IdP的CAP接收上下文。
(2)通过CAP1在RP1和RP2之间共享上下文。
假设RP2和RP1希望仅批准来自用户经常使用的网络的访问,但是RP1运行的是用户不经常使用的服务,例如一年几次。也许RP1可以从IdF1中的IdP1或IdP2收集这些上下文,但是IdF1中的IdP不能收集足够的用于评估的上下文,因为RP2不属于同一身份联盟。此时,由于CAP1位于ZTF中,因此CAP1可以从RP2收集许多上下文(例如用户用于访问的源网络),通过与CAP1联合,RP1便可以获取到用户经常使用的网络的联合上下文。
可以理解的是,该情形(2)表明了ZTF允许RP与身份联盟之外的CAP共享上下文。
(3)当从IdP2变为IdP1时,CAP1继续向RP1提供上下文。
假设用户使用RP1提供的服务,即使他为了登录到RP1而将IdP1更改为IdP2,并且RP1希望仅批准来自用户经常使用的网络的访问。如果IdP1向RP1提供这些上下文,则上下文被绑定到IdP1的管理身份,使得在改变到IdP2之后,RP1不再能使用曾经由IdP1提供的上下文。然而,CAP1可以独立于由IdP1管理身份的生命周期来管理上下文,使得RP1在改变到IdP2之后仍然可以使用由CAP1提供的上下文。此外,由于CAP1从RP2和RP1收集上下文,CAP1可以为RP1提供它自己不能收集的联合上下文。
可以理解的是,该情形(3)表明了ZTF允许CAP独立于IdP1管理身份的生命周期来管理上下文。
(4)最小化RP2中IdP3的信任。
假设RP2想要使用上下文来实施基于零信任的访问控制。由于RP2与CAP1和CAP2联合,RP2不仅可以使用来自IdP3的联盟身份,还可以使用来自CAP1和CAP2的反馈上下文来评估每个访问请求的可信度。此时的RP2比仅加入IdF2时更能最小化IdP3在ZTF的隐性信任。
图11中在一个Web UI(User Interface,用户界面)中示例性地示出了在授权服务器中的管理上下文列表,用户可以在其中看到授权服务器管理的上下文类型。例如,这个授权服务器管理CAP1中的(设备位置)类型的上下文。
图12在一个Web UI中示例性地示出了授权服务器中用户管理的上下文,在这个UI中,用户可以看到并管理哪些CAP和RP可以访问哪些有限的上下文。图12中示出了RP1可以访问这种上下文类型(device-location),但权限有限(仅限于IP和WIFI-ap)。图12中还示出了一个用户设置的上下文访问策略,在该策略中,RP可以使用下面的“Share withothers”(译为与他人共享)表单访问该上下文类型,并具有访问权限。从图12中可以看到,用户试图设置策略允许RP3以有限的权限(使用IP)访问该上下文类型。
进一步地,本发明提供一种零信任联盟系统,可用于实施图1、图4-图7所示的方案,包括:至少一个身份联盟和独立于身份联盟的至少一个上下文管理服务CAP;身份联盟包括具有联盟身份的依赖方RP和用户、还包括用于提供联盟身份的身份提供者服务器;上下文管理服务CAP用于收集和管理实体的上下文、以及提供实体间共享的联合上下文,实体包括上下文管理服务CAP、依赖方RP、用户:
依赖方RP,用于接收用户的访问请求;还用于向上下文管理服务CAP请求用户的联合上下文,其中,用户的联合上下文为上下文管理服务CAP从零信任联盟系统中各实体收集到的、上下文所有者为用户的所有上下文的集合;
上下文管理服务CAP,用于向依赖方RP提供用户的联合上下文;
依赖方RP,根据用户的联合上下文对用户的访问请求进行可信度评估,得出信任评估结果。
较优地,依赖方RP和上下文管理服务CAP之间基于连续访问评估协议实现用户的联合上下文的传输;
依赖方RP,用于创建流,并配置上下文管理服务CAP为流端点;
依赖方RP,用于在流中添加对象端点,并请求上下文管理服务CAP批准,对象端点为拥有依赖方所要访问的上下文的上下文所有者;
上下文管理服务CAP,用于批准添加对象端点至流中;
上下文管理服务CAP,用于通过流将用户的联合上下文传输至依赖方RP。
较优地,零信任联盟系统还包括授权服务器:
用户,向上下文管理服务CAP发起上下文类型注册请求;
上下文管理服务CAP,用于向授权服务器发起用户的上下文类型注册请求,用户的上下文类型注册请求包含用户身份和上下文类型ctxType;
授权服务器,用于根据用户身份和上下文类型ctxType注册上下文标识ctxID,并回应上下文管理服务CAP;
上下文管理服务CAP,接收到授权服务器的回应消息后,根据用户身份和上下文类型ctxType注册上下文标识ctxID,并回应用户;
用户,接收到上下文管理服务CAP的回应消息后,注册上下文类型ctxType为上下文标识ctxID;
用户,向依赖方RP发起上下文标识注册请求,上下文标识注册请求包含上下文类型ctxType;
依赖方RP,用于根据用户身份和上下文类型ctxType注册上下文标识ctxID,并向用户发送注册完成消息。
较优地,依赖方RP,确认用于验证用户身份的全部所需上下文类型和所需权限范围;用于获取所有所需上下文类型对应的上下文标识ctxID;用于向上下文管理服务CAP发送联合上下文请求,联合上下文请求包含所有所需上下文类型对应的上下文标识ctxID、以及所需权限范围。
在提供联合上下文过程中,当依赖方在没有用户授权的情况下请求上下文管理服务提供联合上下文时,授权服务器根据上下文管理服务提交的依赖方的请求内容向上下文管理服务签发许可票据,以使上下文管理服务用许可票据回应依赖方,从而使依赖方凭许可票据请求授权服务器授予访问用户的上下文的用户权限;当依赖方凭许可票据请求授权服务器授予用户权限时,授权服务器根据用户指定的上下文访问策略以及依赖方提交的关于自身信息的声明,来决策是否授予依赖方以用户权限,以使依赖方在有用户授权的情况下从上下文管理服务获取联合上下文。
相应的,上下文管理服务,还用于在依赖方凭用户权限请求获取联合上下文时,对依赖方的用户权限进行验证,以在依赖方在有用户授权的情况下向依赖方提供联合上下文。
如图6所示:
上下文管理服务CAP,用于接收联合上下文请求,并向授权服务器提交依赖方RP的联合上下文请求;
授权服务器,用于根据联合上下文请求签发许可票据PT并发送给上下文管理服务CAP,许可票据PT用于描述依赖方的所有所需上下文类型对应的上下文标识ctxID、以及所需权限范围;
上下文管理服务CAP,接收许可票据PT并转发给依赖方RP;
依赖方RP,用于向授权服务器发送请求方令牌RPT请求消息,请求方令牌RPT请求消息携带许可票据PT、以及依赖方RP的信息声明,信息声明为对依赖方的所有所需上下文类型对应的上下文标识ctxID、以及所需权限范围的描述;
授权服务器,用于验证许可票据PT,基于用户管理访问协议、根据所述用户的上下文访问策略和所述依赖方RP的信息声明进行授权决策,所述上下文访问策略包括允许授予上下文访问权限的依赖方身份、以及依赖方身份所对应的上下文内容访问权限的允许授予范围;
授权服务器,在授权决策的结论为允许授权时,用于向依赖方授予请求方令牌RPT,请求方令牌RPT中描述向依赖方授权的授权上下文标识、以及对用户上下文内容的授权访问范围;
依赖方RP,用于再次向上下文管理服务CAP发送联合上下文请求,联合上下文请求携带请求方令牌RPT;
上下文管理服务CAP,验证请求方令牌RPT;
上下文管理服务CAP,在请求方令牌RPT验证成功后,用于从来自于各个实体共享的上下文中识别出各个授权上下文标识所对应的所有上下文,并进一步按照授权访问范围选取出用户的联合上下文;
上下文管理服务CAP,用于向依赖方RP发送用户的联合上下文。
综上,本发明实施例提供的可共享联合上下文的零信任联盟系统,允许RP通过使用联合上下文和联盟身份来评估每个访问请求的可信度,从而允许RP在身份联盟下应用零信任理念基于零信任实施访问控制。本发明实施例在ZTF中引入了一个名为上下文管理服务的新实体,它独立于IdP和RP收集并提供ZTF中各实体的上下文,扩展了身份联盟收集、管理和共享联合上下文的提供者;还引入了授权服务器对依赖方从上下文管理服务获取联合上下文的权限进行授权管理。在此过程中,基于连续访问评估协议实现联合上下文的传输,基于用户管理访问协议实现在用户控制下共享联合上下文,解决了现有技术中因依赖方的访问量小而无法开展有效验证的问题,实现了在ZTF中的实体间共享上下文的机制。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。此外,本领域的技术人员可以将本说明书中描述的不同实施例或示例进行接合和组合。
尽管在此结合各实施例对本申请进行了描述,然而,在实施所要求保护的本申请过程中,本领域技术人员通过查看所述附图以及公开内容,可理解并实现所述公开实施例的其他变化。在本发明的描述中,“包括”一词不排除其他组成部分或步骤,“一”或“一个”不排除多个的情况,“多个”的含义是两个或两个以上,除非另有明确具体的限定。此外,相互不同的实施例中记载了某些措施,但这并不表示这些措施不能组合起来产生良好的效果。
以上所揭露的仅为本发明较佳实施例而已,当然不能以此来限定本发明之权利范围,本领域普通技术人员可以理解实现上述实施例的全部或部分流程,并依本发明权利要求所作的等同变化,仍属于发明所涵盖的范围。

Claims (10)

1.一种基于零信任联盟系统的信任评估方法,其特征在于,零信任联盟系统由至少一个身份联盟和独立于所述身份联盟的至少一个上下文管理服务CAP组成,所述身份联盟包括具有联盟身份的依赖方RP和用户、还包括用于提供所述联盟身份的身份提供者服务器,所述上下文管理服务CAP用于收集和管理实体的上下文、以及提供实体间共享的联合上下文,所述实体包括所述上下文管理服务CAP、所述依赖方RP、所述用户,方法步骤包括:
步骤S1,所述依赖方RP接收所述用户的访问请求;
步骤S2,所述依赖方RP向所述上下文管理服务CAP请求所述用户的联合上下文,其中,所述用户的联合上下文为所述上下文管理服务CAP从所述零信任联盟系统中各所述实体收集到的、上下文所有者为所述用户的所有上下文的集合;
步骤S3,所述上下文管理服务CAP向所述依赖方RP提供所述用户的联合上下文;
步骤S4,所述依赖方RP根据所述用户的联合上下文对所述用户的访问请求进行可信度评估,得出信任评估结果。
2.如权利要求1所述的基于零信任联盟系统的信任评估方法,其特征在于,所述依赖方RP和所述上下文管理服务CAP之间基于连续访问评估协议实现所述用户的联合上下文的传输,所述步骤S3所述上下文管理服务CAP向所述依赖方RP提供所述用户的联合上下文包括:
所述依赖方RP创建流,并配置所述上下文管理服务CAP为流端点;
所述依赖方RP在所述流中添加对象端点,并请求所述上下文管理服务CAP批准,所述对象端点为拥有所述依赖方所要访问的上下文的上下文所有者;
所述上下文管理服务CAP批准添加所述对象端点至所述流中;
所述上下文管理服务CAP通过所述流将所述用户的联合上下文传输至所述依赖方RP。
3.如权利要求1所述的基于零信任联盟系统的信任评估方法,其特征在于,所述零信任联盟系统还包括授权服务器,所述步骤S1所述依赖方RP接收所述用户的访问请求,所述访问请求中包含用户身份之前,还包括:
所述用户向所述上下文管理服务CAP发起上下文类型注册请求;
所述上下文管理服务CAP向所述授权服务器发起所述用户的上下文类型注册请求,所述用户的上下文类型注册请求包含所述用户身份和上下文类型ctxType;
所述授权服务器根据所述用户身份和所述上下文类型ctxType注册上下文标识ctxID,并回应所述上下文管理服务CAP;
所述上下文管理服务CAP接收到所述授权服务器的回应消息后,根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并回应所述用户;
所述用户接收到所述上下文管理服务CAP的回应消息后,注册所述上下文类型ctxType为所述上下文标识ctxID;
所述用户向所述依赖方RP发起上下文标识注册请求,所述上下文标识注册请求包含所述上下文类型ctxType;
所述依赖方RP根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并向所述用户发送注册完成消息。
4.如权利要求3所述的基于零信任联盟系统的信任评估方法,其特征在于,所述步骤S2中所述依赖方RP向所述上下文管理服务CAP请求所述用户的联合上下文包括:
所述依赖方RP确认用于验证所述用户身份的全部所需上下文类型和所需权限范围;
所述依赖方RP获取所有所述所需上下文类型对应的所述上下文标识ctxID;
所述依赖方RP向所述上下文管理服务CAP发送联合上下文请求,所述联合上下文请求包含所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围。
5.如权利要求4所述的基于零信任联盟系统的信任评估方法,其特征在于,所述步骤S3所述上下文管理服务CAP向所述依赖方RP提供所述用户的联合上下文包括:
所述上下文管理服务CAP接收所述联合上下文请求,并向所述授权服务器提交所述依赖方RP的所述联合上下文请求;
所述授权服务器根据所述联合上下文请求签发许可票据PT并发送给所述上下文管理服务CAP,所述许可票据PT用于描述所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围;
所述上下文管理服务CAP接收所述许可票据PT并转发给所述依赖方RP;
所述依赖方RP向所述授权服务器发送请求方令牌RPT请求消息,所述请求方令牌RPT请求消息携带所述许可票据PT、以及所述依赖方RP的信息声明,所述信息声明为对所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围的描述;
所述授权服务器验证所述许可票据PT,基于用户管理访问协议、根据所述用户的上下文访问策略和所述依赖方RP的信息声明进行授权决策,所述上下文访问策略包括允许授予上下文访问权限的依赖方身份、以及依赖方身份所对应的上下文内容访问权限的允许授予范围;
所述授权决策的结论为允许授权时,所述授权服务器向所述依赖方授予请求方令牌RPT,所述请求方令牌RPT中描述向所述依赖方授权的授权上下文标识、以及对用户上下文内容的授权访问范围;
所述依赖方RP再次向所述上下文管理服务CAP发送所述联合上下文请求,所述联合上下文请求携带所述请求方令牌RPT;
所述上下文管理服务CAP验证所述请求方令牌RPT;
所述请求方令牌RPT验证成功后,所述上下文管理服务CAP从来自于各个所述实体共享的上下文中识别出各个所述授权上下文标识所对应的所有上下文,并进一步按照所述授权访问范围选取出所述用户的联合上下文;
所述上下文管理服务CAP向所述依赖方RP发送所述用户的联合上下文。
6.一种零信任联盟系统,其特征在于,包括:至少一个身份联盟和独立于所述身份联盟的至少一个上下文管理服务CAP;所述身份联盟包括具有联盟身份的依赖方RP和用户、还包括用于提供所述联盟身份的身份提供者服务器;所述上下文管理服务CAP用于收集和管理实体的上下文、以及提供实体间共享的联合上下文,所述实体包括所述上下文管理服务CAP、所述依赖方RP、所述用户:
所述依赖方RP,用于接收所述用户的访问请求;还用于向所述上下文管理服务CAP请求所述用户的联合上下文,其中,所述用户的联合上下文为所述上下文管理服务CAP从所述零信任联盟系统中各所述实体收集到的、上下文所有者为所述用户的所有上下文的集合;
所述上下文管理服务CAP,用于向所述依赖方RP提供所述用户的联合上下文;
所述依赖方RP,根据所述用户的联合上下文对所述用户的访问请求进行可信度评估,得出信任评估结果。
7.如权利要求6所述的零信任联盟系统,其特征在于,所述依赖方RP和所述上下文管理服务CAP之间基于连续访问评估协议实现所述用户的联合上下文的传输;
所述依赖方RP,用于创建流,并配置所述上下文管理服务CAP为流端点;
所述依赖方RP,用于在所述流中添加对象端点,并请求所述上下文管理服务CAP批准,所述对象端点为拥有所述依赖方所要访问的上下文的上下文所有者;
所述上下文管理服务CAP,用于批准添加所述对象端点至所述流中;
所述上下文管理服务CAP,用于通过所述流将所述用户的联合上下文传输至所述依赖方RP。
8.如权利要求7所述的零信任联盟系统,其特征在于,所述零信任联盟系统还包括授权服务器:
所述用户,向所述上下文管理服务CAP发起上下文类型注册请求;
所述上下文管理服务CAP,用于向所述授权服务器发起所述用户的上下文类型注册请求,所述用户的上下文类型注册请求包含所述用户身份和上下文类型ctxType;
所述授权服务器,用于根据所述用户身份和所述上下文类型ctxType注册上下文标识ctxID,并回应所述上下文管理服务CAP;
所述上下文管理服务CAP,接收到所述授权服务器的回应消息后,根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并回应所述用户;
所述用户,接收到所述上下文管理服务CAP的回应消息后,注册所述上下文类型ctxType为所述上下文标识ctxID;
所述用户,向所述依赖方RP发起上下文标识注册请求,所述上下文标识注册请求包含所述上下文类型ctxType;
所述依赖方RP,用于根据所述用户身份和所述上下文类型ctxType注册所述上下文标识ctxID,并向所述用户发送注册完成消息。
9.如权利要求8所述的零信任联盟系统,其特征在于:
所述依赖方RP,确认用于验证所述用户身份的全部所需上下文类型和所需权限范围;用于获取所有所述所需上下文类型对应的所述上下文标识ctxID;用于向所述上下文管理服务CAP发送联合上下文请求,所述联合上下文请求包含所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围。
10.如权利要求9所述的零信任联盟系统,其特征在于:
所述上下文管理服务CAP,用于接收所述联合上下文请求,并向所述授权服务器提交所述依赖方RP的所述联合上下文请求;
所述授权服务器,用于根据所述联合上下文请求签发许可票据PT并发送给所述上下文管理服务CAP,所述许可票据PT用于描述所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围;
所述上下文管理服务CAP,接收所述许可票据PT并转发给所述依赖方RP;
所述依赖方RP,用于向所述授权服务器发送请求方令牌RPT请求消息,所述请求方令牌RPT请求消息携带所述许可票据PT、以及所述依赖方RP的信息声明,所述信息声明为对所述依赖方的所有所述所需上下文类型对应的所述上下文标识ctxID、以及所述所需权限范围的描述;
所述授权服务器,用于验证所述许可票据PT,基于用户管理访问协议、根据所述用户的上下文访问策略和所述依赖方RP的信息声明进行授权决策,所述上下文访问策略包括允许授予上下文访问权限的依赖方身份、以及依赖方身份所对应的上下文内容访问权限的允许授予范围;
所述授权服务器,在所述授权决策的结论为允许授权时,用于向所述依赖方授予请求方令牌RPT,所述请求方令牌RPT中描述向所述依赖方授权的授权上下文标识、以及对用户上下文内容的授权访问范围;
所述依赖方RP,用于再次向所述上下文管理服务CAP发送所述联合上下文请求,所述联合上下文请求携带所述请求方令牌RPT;
所述上下文管理服务CAP,验证所述请求方令牌RPT;
所述上下文管理服务CAP,在所述请求方令牌RPT验证成功后,用于从来自于各个所述实体共享的上下文中识别出各个所述授权上下文标识所对应的所有上下文,并进一步按照所述授权访问范围选取出所述用户的联合上下文;
所述上下文管理服务CAP,用于向所述依赖方RP发送所述用户的联合上下文。
CN202310268844.3A 2023-03-17 2023-03-17 基于零信任联盟系统的信任评估方法及系统 Active CN116405266B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310268844.3A CN116405266B (zh) 2023-03-17 2023-03-17 基于零信任联盟系统的信任评估方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310268844.3A CN116405266B (zh) 2023-03-17 2023-03-17 基于零信任联盟系统的信任评估方法及系统

Publications (2)

Publication Number Publication Date
CN116405266A true CN116405266A (zh) 2023-07-07
CN116405266B CN116405266B (zh) 2023-12-22

Family

ID=87015143

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310268844.3A Active CN116405266B (zh) 2023-03-17 2023-03-17 基于零信任联盟系统的信任评估方法及系统

Country Status (1)

Country Link
CN (1) CN116405266B (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102132286A (zh) * 2008-06-20 2011-07-20 微软公司 使用身份上下文信息,对文档进行数字签名
US20120023568A1 (en) * 2010-01-22 2012-01-26 Interdigital Patent Holdings, Inc. Method and Apparatus for Trusted Federated Identity Management and Data Access Authorization
CN114884680A (zh) * 2022-06-06 2022-08-09 四川中电启明星信息技术有限公司 一种基于上下文认证的多服务器可持续信任评估方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102132286A (zh) * 2008-06-20 2011-07-20 微软公司 使用身份上下文信息,对文档进行数字签名
US20120023568A1 (en) * 2010-01-22 2012-01-26 Interdigital Patent Holdings, Inc. Method and Apparatus for Trusted Federated Identity Management and Data Access Authorization
CN114884680A (zh) * 2022-06-06 2022-08-09 四川中电启明星信息技术有限公司 一种基于上下文认证的多服务器可持续信任评估方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
李建;管卫利;刘吉强;吴杏;: "基于信任评估的网络访问模型", 信息网络安全, no. 10 *

Also Published As

Publication number Publication date
CN116405266B (zh) 2023-12-22

Similar Documents

Publication Publication Date Title
US10185963B2 (en) Method for authentication and assuring compliance of devices accessing external services
Fett et al. A comprehensive formal security analysis of OAuth 2.0
JP5509334B2 (ja) コンピュータネットワーク内の保護リソースへのアクセスを管理するための方法と、そのための物理エンティティおよびコンピュータプログラム
US8819784B2 (en) Method for managing access to protected resources and delegating authority in a computer network
CN110138718B (zh) 信息处理系统及其控制方法
US8387136B2 (en) Role-based access control utilizing token profiles
CN109428891B (zh) 权限转移系统及其控制方法和客户端
US8387137B2 (en) Role-based access control utilizing token profiles having predefined roles
Gessner et al. Trustworthy infrastructure services for a secure and privacy-respecting internet of things
KR20180048766A (ko) 서비스 계층 동적 권한부여
JP6066647B2 (ja) デバイス装置、その制御方法、およびそのプログラム
RU2308755C2 (ru) Система и способ предоставления доступа к защищенным услугам с однократным вводом пароля
US10432609B2 (en) Device-bound certificate authentication
US9319413B2 (en) Method for establishing resource access authorization in M2M communication
JP6245949B2 (ja) 認可サーバーシステム、その制御方法、およびそのプログラム。
US20130036455A1 (en) Method for controlling acess to resources
US20140020051A1 (en) User to user delegation service in a federated identity management environment
JP2008146682A (ja) アカウント管理のための方法およびシステム
JP7096736B2 (ja) システム、及びデータ処理方法
KR102651448B1 (ko) 블록 체인 기반 탈중앙화 인가 프로토콜 방법 및 장치
Colombo et al. Access Control Enforcement in IoT: state of the art and open challenges in the Zero Trust era
EP3759629B1 (en) Method, entity and system for managing access to data through a late dynamic binding of its associated metadata
CN116405266B (zh) 基于零信任联盟系统的信任评估方法及系统
JPH0779243A (ja) ネットワーク接続装置およびネットワーク接続方法
KR100582195B1 (ko) 워크플로우 기반의 그리드 사용자 권한 위임과 인증시스템 및 그 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant