用于在m2m通信系统中进行订阅和通知的方法及其设备的制造方法_4

文档序号:9932982阅读:来源:国知局
并且可以与读/写(RW)、只读(R0)、只写或写一次(W0)中的一个相对应。表1仅是示例。订 阅资源的属性可以按照与表1不同的方式来配置。
[0147][表 1]
[0149]
[0150] 在表1的示例中,过滤属性(例如not if i cat ionCr iter ia)与用于修改/改变订阅目 标资源的条件的列表相对应,并且所述条件中的每一个可以按照逻辑"与"关系。例如,当过 滤属性(例如,notificationCriteria)包括两个条件时,如果订阅目标资源的修改/改变满 足所有两个条件,则可以发送通知。通知消息的量可以通过配置订阅资源的过滤属性来进 行调节。如果通知被配置为仅在满足所配置的过滤属性时被发送至通知目标实体,则可以 防止过多的通知消息的问题。表2示出了可以包括在过滤属性中的条件的示例。
[0151] [表 2]
[0153]
[0154] 参照图12,实体1 1210可以执行在图12中示出的过程以订阅实体2 1220的特定资 源。实体1 1210可以根据订阅目标资源的变化与接收通知的目标对应或不对应。在图12的 示例中,特定资源可以与订阅目标资源相对应,并且由于实体2 1220包括订阅目标资源,因 此实体2 1220可以与托管设备(或实体)相对应。
[0155] 在步骤S1202中,实体1 1210可以向实体2 1220发送用于订阅资源的请求以订阅 特定资源。例如,用于订阅资源的请求可以与订阅资源的创建请求、订阅资源的获取请求、 订阅资源的删除请求或订阅资源的更新请求中的一种相对应。每一种请求可以根据参照图 6描述的请求-响应方案而具有请求消息的形式。例如,如果步骤S1202中的请求与创建请求 相对应,则针对订阅资源的请求可以包括包含C(Create)的op信息、包含订阅资源的属性信 息(例如,11〇1:1;1^;[0&1:;[0111]1?1、;1^;[]^61'0;^61'1&、(^6&1:01'等)的01信息、包含实体11210的识 别信息的fr信息和/或包含目标资源的识别信息的信息。在另一个示例中,如果步骤S1202 中的请求与删除请求或更新请求相对应,则用于订阅资源的请求可以包括参照图6描述的 信息的所有或部分。在本说明书中,针对订阅资源的创建请求可以被称为订阅创建请求,针 对订阅资源的获取请求可以被称为订阅获取请求,针对订阅资源的删除请求可以被称为订 阅删除请求,并且针对订阅资源的更新请求可以被称为订阅更新请求。与订阅资源相关的 请求可以被共同称为订阅请求。
[0156] 在步骤S1204中,实体2 1220验证针对订阅资源的请求是否能够被处理,并且如果 该请求能够被处理,则处理该请求。例如,如果设备2 920接收创建请求,则实体2 1220验证 在to信息中指定的订阅目标资源是否可订阅,请求的发起方(例如,实体1)是否具有针对订 阅目标资源的获取许可。如果上述条件都满足,则实体2 1220可以在由to信息指定的订阅 目标资源(或所订阅资源)下创建订阅资源。
[0157] 在另一个示例中,如果实体2 1220接收到删除请求,则实体2 1220验证请求的发 起方(例如,1310)是否具有删除许可。如果上述条件都满足,则设备2 920删除订阅资源。
[0158] 在步骤S1206中,在针对订阅资源的请求被处理之后,实体2 1220可以向实体 11210发送响应消息。步骤S1206的响应消息可以具有参照图6描述的响应消息相同/相似的 形式。并且,在获取请求的情况下,响应消息可以包括要返回的信息。
[0159] 图13例示了通知过程的示例。在用于通知的过程中,发起方可以与托管订阅资源 的设备或实体(例如,实体2)相对应。并且,接收方可以与在订阅资源中配置的地址信息(例 如,notificationURI)所指示的设备(或实体)相对应。具体的策略信息可以针对通知的过 程而配置。发起方可以被配置为在满足策略信息时发送通知消息(例如,NOTIFY)。通知消息 可以指的是〇P被设置为NOTIFY的请求消息。
[0160] 可以在通知事件(例如,订阅目标资源的状态改变)时生成通知消息(例如, NOTIFY)。通知事件可以由订阅资源触发。例如,如果包括订阅资源作为其子资源的订阅目 标资源的改变满足在订阅资源中配置的过滤属性(例如,11〇1:1;1^〇31:;[0110;^61^3),则通知 消息可以被发送至由在订阅资源中配置的地址信息(例如,notificationURI)指示的接收 方。通知消息的接收方可以与创建/配置订阅资源的设备或实体对应或不对应。例如,实体1 1210可以与实体3 1230相同或者可以与实体3 1230不同。通知消息可以包括下文中描述的 fg息。
[0161 ] -f r:发起方(例如,实体2)的识别信息或ID。
[0162] -to:在订阅资源中配置的地址信息(例如,notif icationURI)。
[0163] -cn:代表订阅目标资源和/或已经创建通知消息和/或其它附加信息的订阅参照 信息(例如,订阅资源的URI)的修改内容的数据。
[0164] 参照图13,在步骤S1302中,发起方(例如,实体2)可以检测/感测订阅目标资源的 变化。订阅目标资源与订阅资源的父资源相对应。如果与订阅目标资源下的订阅资源位于 相同级别的资源或属性被修改/改变,则发起方(例如,实体2)(例如,SUB CSF或CSE,参照图 3)可以将其识别为订阅目标资源的改变。如果检测/感测到订阅目标资源的改变,则可以生 成通知事件。
[0165] 如果检测到订阅目标资源的改变,则在步骤S1304中发起方(例如,实体2)检查该 改变是否与在订阅资源中配置的特定属性(例如,not if icationCr iter ia)相匹配。例如,特 定属性可以包括在表2的示例中示出的属性当中的至少一个属性。如果订阅目标资源的改 变不满足在过滤属性中包括的任何条件,则发起方(例如,实体2)可以忽略该改变。
[0166] 如果订阅目标资源的改变满足在过滤属性中包括的所有条件,则在步骤S1306中 发起方(例如,实体2)可以向由在订阅资源中配置的地址信息(例如,no t i f i cat i onURI)指 示的实体3 (1230)发送通知消息。例如,步骤S1306中的通知消息可以包括发起者(例如,实 体2)的识别信息,代表订阅目标资源的修改内容的数据和/或已经创建通知消息的订阅参 照信息。如果订阅目标资源的改变不满足在过滤属性中包括的任何条件,则发起方(例如, 实体2)可以不发送生成的通知消息。
[0167] 图14示出了与订阅-通知过程相关的问题的示例。
[0168] 如上所述,请求接收方(例如,实体2)可以响应于订阅请求来验证请求发起方(例 如,实体1)是否具有对订阅资源或订阅目标资源的权限(或访问权限)。如果请求发起方(例 如,实体1)不具有对订阅资源或订阅目标资源的权限(或访问权限),则订阅请求被拒绝并 且响应消息可以包括失败结果。然而,虽然进行了验证,但是可以存在与订阅验证相关的问 题。在本说明书中,订阅验证可以被称为验证订阅请求的权限(或访问权限)的操作。并且, 在本说明书中,订阅请求方可以被称为请求发起方并且订阅主机可以被称为托管实体。
[0169] 参照图14,在步骤S1202中,请求发起方(例如,实体1)可以配置至托管实体(例如, 实体2)的订阅资源,使得通知接收方(例如,实体3)是订阅方。在这种情况下,在步骤S1204 中,托管实体(例如,实体2)可以检查请求发起方(例如,实体1)是否具有对订阅目标资源或 订阅资源的权限。例如,托管实体(例如,实体2)可以检查请求发起方(例如,实体1)是否具 有对属于托管实体的订阅目标资源的获取访问权限限。如果在步骤S1206中成功执行了访 问权限的检查,则用于允许订阅请求的响应消息可以被发送至请求发起方(例如,实体1)。
[0170] 根据传统订阅/通知机制,如果请求发起方(例如,实体1)具有对托管实体(例如, 实体2)的访问权限,则能够配置订阅资源以向通知接收方(例如,实体3)发送通知消息。在 这种情况下,如果请求发起方(例如,实体1)恶意配置订阅资源,则通知接收方(例如,实体 3)接收不期望的通知消息,由此增加了通知接收方(例如,实体3)的负荷。具体地,如果请求 发起方(例如,实体1)旨在进行诸如DDoS攻击的恶意攻击,则不仅通知接收方(例如,实体3) 中的系统负荷可能增加,而且托管实体(例如,实体2)中的系统负荷也可能增加。因此,整个 系统可能崩溃。
[0171]并且,虽然请求发起方(实体1)不具有恶意,但是如果托管实体(例如,实体2)有权 限向通知接收方(例如,实体3)发送通知消息,则托管实体可能被其它不同实体滥用。例如, 如果假设托管实体(例如,实体2)有权限向通知接收方(例如,实体3)发送通知消息,则具有 对托管实体(例如,实体2)的访问权限的另一实体(例如,实体4)可以配置至托管实体(例 如,实体2)的单独的订阅资源。在这种情况下,由于托管实体(例如,实体2)具有向通知接收 方(例如,实体3)发送通知消息的权限,所以由实体4配置的订阅资源所生成的通知消息在 没有许可的情况下通过占用托管实体(例如,实体2)的访问权限可以被发送至通知接收方 (例如,实体3)。因此,在这种情况下,托管实体(例如,实体2)和通知接收方(例如,实体3)可 能暴露于恶意攻击。
[0172] 为了防止发生上述问题,本发明提出了用于订阅和通知的特权检查方法。本发明 提出了下文中描述的两种附加的特权检查。
[0173] -托管设备或实体(例如,实体2)是否具有能够向指定至订阅资源的地址信息(例 如,notificationURI)的实体或设备(例如,实体3)发送通知的特权(或访问权限)。
[0174]-请求发起方(例如,实体1)是否具有能够将以通知消息接收方(例如,实体3)作为 目标的订阅资源配置为通知目标的特权(或访问权限)。或者,请求发起方(例如,实体1)是 否具有能够通过将通知消息接收方(例如,实体3)的地址信息指定成订阅资源的地址信息 (例如,notif icationURI)而配置订阅资源的特权(或访问权限)。或者,请求发起方(例如, 实体1)是否具有能够向通过订阅资源的地址信息(例如,notificationURI)指定的实体或 设备(例如,实体3)发送通知的特权(或访问权限)。
[0175] 可以在请求发起方(例如,实体1)和通知接收方(例如,实体3)彼此不同时,执行根 据本发明的特权检查方法。例如,可以在订阅资源的地址信息(例如,noti f i cationURI)不 指示请求发起方(例如,实体1)时,执行所述方法。
[0176] 在本说明书中,能够发送通知的特权或者能够配置订阅资源的特权可以表示为通 知/订阅准许/特权,并且这些特权可以彼此可交换地使用。例如,请求发起方(例如,实体1) 的能够将以通知接收方(例如,实体3)作为目标的订阅资源配置为通知目标的特权以及请 求发起方(例如,实体1)的能够向通知接收方(例如,实体3)发送通知消息的特权可以作为 相同的含义来使用。或者,例如,请求发起方(例如,实体1)的能够配置用于向通知接收方 (例如,实体3)发送通知的订阅的特权以及请求发起方(例如,实体1)的能够向通知接收方 (例如,实体3)发送通知消息的特权可以作为相同的含义来使用。可以在请求发起方(例如, 实体1)请求托管实体(例如,实体2)创建订阅资源之前配置相对应的特权。因此,请求发起 方(例如,实体1)可以具有针对通知接收方(例如,实体3)的足够的特权。
[0177]因此,如果请求发起方(例如,实体1)在从托管实体(例如,实体2)请求订阅的同时 将通知接收方(例如,实体3)配置为通知目标,则托管实体(例如,实体2)可以检查请求发起 方(例如,实体1)的特权和托管实体(例如,实体2)相对于通知接收方(例如,实体3)的特权。 托管实体(例如,实体2)可以仅在根据本发明的特权检查成功时准许请求发起方(例如,实 体1)的订阅请求。
[0178] 在本说明书中,设备或实体的识别信息可以包括指示设备或实体的地址信息(例 如,URI)。或者,设备或实体的识别信息可以包括指示包括在设备或实体中的资源的地址信 息(例如,URI)。
[0179] 当托管实体(例如,实体2)能够检查通知目标的特权时,可以执行根据本发明的订 阅验证。例如,如果不能检查通知目标的特权,则不执行验证。可以按照各种方式检查通知 目标的特权。例如,请求发起方(例如,实体1)可以告知托管实体(例如,实体2)关于通知目 标的特权以及订阅请求的信息。或者,虽然请求发起方(例如,实体1)不给托管实体提供关 于通知目标的特权的信息,但是能够以确定托管实体(例如,实体2)是否能够检查通知目标 的特权的方式来执行与验证相关的操作。作为不同的示例,能够独立于托管实体(例如,实 体2)是否能够检查通知目标的特权来尝试验证请求和实际操作。如果能够检查通知目标的 特权,则能够成功地执行验证并且识别结果。相反,如果不能检查通知目标的特权,则能够 识别没有成功地执行验证并且能够传送一般的错误响应或不传送响应。
[0180] 方法1 (订阅主机执行验证)
[0181 ]在根据本发明的方法1中,与传统技术相比,增加了验证托管实体(例如,实体2)是 否具有针对向通知接收方(例如,实体3)发送通知的访问权限的过程。如果请求发起方(例 如,实体1)不具有恶意,并且具有针对通知接收方(例如,实体3)的适当的特权,则可以在请 求订阅配置之前预先配置托管实体(实体2)的能够向通知接收方(例如,实体3)发送通知的 特权。因此,接收到订阅请求之后,托管实体(例如,实体2)检查托管实体是否具有能够向通 知接收方(例如,实体3)发送通知的权限。如果托管实体不具有该权限,则托管实体可以认 为请求发起方(例如,实体1)不具有针对通知接收方(例如,实体3)的权限,并且托管实体可 以拒绝订阅请求。
[0182] 图15示出了根据本发明的订阅和通知过程的示例。图15示出了应用根据本发明的 方法1的示例。
[0183] 参照图15,为了解决上述订阅/通知过程(例如,参见图14)的问题,能够附加地验 证托管实体(例如,实体2)是否具有能够向通知接收方(例如,实体3)发送通知的权限 [S1506 ]。因此,当托管实体(例如,实体2)从请求发起方(例如,实体1)接收订阅请求时,托 管实体(例如,实体2)不仅检查请求发起方(例如,实体1)是否具有能够订阅托管实体(例 如,实体2)的权限,而且还检查托管实体(例如,实体2)是否具有能够向通知接收方(例如, 实体3)发送通知的权限[S1506]。在图15的示例中,虽然描述了以S1504和S1506的顺序执行 的步骤,但是这仅是示例。执行每一个步骤的顺序不限于该顺序。因此,如果必要,可以按照 与所描述的顺序不同的顺序来执行步骤S1504和步骤S1506。步骤S1502、S1508、S151(^P S1512可以分别与步骤S1202、S1206、S1302和S1306相对应。因此,通过引用并入与图12和图 13相关的说明。
[0184] 虽然请求发起方(例如,实体1)具有恶意,但是如果托管实体(例如,实体2)不具有 能够向通知接收方(例如,实体3)发送通知的权限,则不能准许订阅请求。因此,如果应用根 据本发明的方法1,则能够避免由于恶意攻击托管实体(例如,实体2)和通知接收方(例如, 实体3)的请求发起方(例如,实体1)的攻击而造成的诸如网络负荷增加和系统容量下降的 问题。
[0185] 方法2 (订阅主机执行验证)
[0186] 如果应用根据本发明的方法1,则能够防止请求发起方(例如,实体1)与不具有能 够改变通知接收方(例如,实体3)的配置的权限的恶意实体相对应的情况。然而,托管实体
...
当前第4页1 2 3 4 5 6 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1