WO2017024791A1 - 一种处理授权的方法和设备 - Google Patents

一种处理授权的方法和设备 Download PDF

Info

Publication number
WO2017024791A1
WO2017024791A1 PCT/CN2016/075488 CN2016075488W WO2017024791A1 WO 2017024791 A1 WO2017024791 A1 WO 2017024791A1 CN 2016075488 W CN2016075488 W CN 2016075488W WO 2017024791 A1 WO2017024791 A1 WO 2017024791A1
Authority
WO
WIPO (PCT)
Prior art keywords
authorization
identifier
resource
signature
request
Prior art date
Application number
PCT/CN2016/075488
Other languages
English (en)
French (fr)
Inventor
张尧烨
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to KR1020187003384A priority Critical patent/KR101962156B1/ko
Priority to JP2018500769A priority patent/JP6494149B2/ja
Priority to EP16834417.4A priority patent/EP3310083A4/en
Publication of WO2017024791A1 publication Critical patent/WO2017024791A1/zh
Priority to US15/892,686 priority patent/US10666661B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the present invention relates to the field of machine communication technologies, and in particular, to a method and device for processing authorization.
  • Machine-to-Machine Communications is a networked application and service centered on machine intelligence interaction. It embeds wireless or wired communication modules and application processing logic inside the machine to realize user informationization requirements for monitoring, command and dispatch, data acquisition and measurement.
  • various M2M devices such as various sensors, directly access the M2M service platform through the M2M gateway to implement various M2M services. For example, power meter reading, smart home, etc.
  • M2M service platform Through the service capabilities provided by the M2M service platform, data collected by the M2M device can be acquired, or the M2M device can be controlled and managed.
  • any M2M device, M2M gateway or M2M service platform and the service capabilities they provide can be abstracted into resources and have unique resource identifiers, ie URI (Uniform Resource Identifier).
  • URI Uniform Resource Identifier
  • Each accessed resource can be set with corresponding access rights, and an access control policy resource, such as an ACP (accessControlPolicy) resource, is used to implement the access control function of the accessed resource in the system.
  • ACP accessControlPolicy
  • the access control policy identifies the access control policy resource according to the access control policy identifier of the accessed resource, and each access control rule in the access control policy resource can be used.
  • accessControlOriginator represents the access device ID (possibly a CSE-ID, AE-ID, or serviceProvider domain, or All) with operational privileges; accessControlOperations
  • the permission allowed by this rule may include one or more of Retrieve, Create, Update, Delete, Discovery, and Notify); accessControlContexts is optional and defines the accessControlOriginator with the permissions specified in accessControlOperations, such as Within a certain time frame, within each geographic area, and so on.
  • the value of accessControlContexts can be empty, that is, the conditions of the operation permission are not limited and described.
  • the device to which the accessed resource belongs is based on Whether the access device identifier is included in the access controlOriginator attribute of the obtained access control policy resource, and whether the access controlOperations attribute contains an access device request for the accessed resource to determine whether the access device has the access right to the accessed resource. Only when both conditions are met indicates that the access device passed the access control permission check.
  • the access device identifier is used to identify the identity of the access device.
  • the access device may be an Application Entity (AE) or a Common Service Entity (CSE).
  • the access device identifier is assigned by the public service entity registered by the access device, that is, the Registrar CSE (hereinafter collectively referred to as the registration server).
  • the registration server the public service entity registered by the access device.
  • AE when an AE registers a local ID on CSE1, it is assigned AE-ID1; when the AE is offline and then registered on CSE2, AE-ID2 is assigned. Obviously, the identity of the AE in the M2M system has changed at this time.
  • the original authorization relationship (such as ACP) associated with AE-ID1 cannot be applied to the new AE-ID2. It needs to be reset by the administrator for AE-ID2.
  • Set or add ACP which greatly affects the business continuity and user experience of M2M devices.
  • the ACP resources corresponding to a resource X are as follows:
  • the access device corresponding to the access device identifier AE-ID1 has access rights to Retrieve or Create for the resource X.
  • the access device is changed to AE-ID2 by the M2M system for some reason, such as registration on another registration server, the access device cannot apply the ACP resource, and the resource cannot be obtained.
  • X's Retrieve or Create access when the access device is changed to AE-ID2 by the M2M system for some reason, such as registration on another registration server, the access device cannot apply the ACP resource, and the resource cannot be obtained.
  • the present invention provides a method and a device for processing an authorization to solve the technical problem that the access device cannot use the original authorization relationship when the identity of the access device changes.
  • the present invention provides a method for processing an authorization in a machine communication, comprising: receiving a first authorization update request sent by an access device, where the first authorization update request includes the access device a first identifier; sending a first authorization update response to the access device, the first authorization update response includes signature request information, the signature request information instructing the access device to sign the verification information; and receiving the access device to send a signature verification request, the signature verification request including the first identifier, the verification information, and the signature of the verification information; wherein the signature of the verification information is the access device using a key pair to the verification And generating, according to the verification information, acquiring the saved first authorization relationship; determining, according to the signature of the verification information in the received signature verification request and the signature of the verification information saved in the first authorization relationship, The signature of the verification information in the signature verification request is legal; according to the first identifier, the first authorization relationship is updated.
  • the method before the receiving the first authorization update request sent by the access device, the method further includes: the resource server receiving the access device to send the resource access The request, the resource access request includes the first identifier and the accessed resource identifier; the resource server determines, according to the first identifier and the accessed resource identifier, that the access device does not access the accessed resource identifier The resource server rejects the access request of the access device to the resource corresponding to the accessed resource identifier, and sends a resource access response including the redirect address to the access device, where the weight is The directed address is an authorized update port address of the authorization server, so that the access device sends the first authorization update request to the authorization server according to the authorized update port address.
  • the updating, by the first identifier, the first authorization relationship specifically :
  • the method further includes: performing initial authorization on the access device to access the resource corresponding to the accessed resource identifier.
  • the verification information is the second identifier saved by the access device, where the signature verification request is Further including a signature of the first identifier, wherein the signature of the first identifier is the access And generating, by the device, the first identifier by using the key; after determining that the signature of the verification information in the signature verification request is legal, the method further includes: in the first authorization relationship The signature of the saved verification information is changed to the signature of the first identification.
  • the accessing, by the access device, the resource corresponding to the accessed resource identifier is initially authorized, specifically Sending a resource creation request to the resource server, where the resource creation request includes a preset access control policy and the accessed resource identifier, where the preset access control policy includes the second identifier; receiving the resource a resource creation response sent by the server, the resource creation response instructing the resource server to successfully create the access control policy resource and binding the access control policy resource to a resource corresponding to the accessed resource identifier;
  • the access device sends a signature request, the signature request instructing the access device to sign the second identifier, receiving a signature response sent by the access device, the signature response including a signature of the second identifier, and saving the a first authorization relationship, where the first authorization relationship includes a signature of the second identifier and the second identifier
  • the visited resource identifier in a correspondence relationship.
  • the updating is performed according to the first identifier
  • the method further includes: sending a second authorization update request to the resource server, where the second authorization update request includes the first identifier, the second identifier, and the accessed resource identifier.
  • the verification information is an authorization credential
  • the first authorization update request further includes the authorization credential
  • the method further includes: determining, according to the authorization credential, that the first authorization relationship includes the authorization credential, and the first authorization relationship is The bound access device identifier is not the first identifier.
  • the accessing, by the access device, the resource corresponding to the accessed resource identifier is initially authorized, specifically Receiving an authorization request of the access device, where the authorization request includes the second identifier, the accessed resource identifier, and authentication information that the user agrees to access the resource by the access device; when determining, according to the authentication information, When the user has the right to access the resource corresponding to the accessed resource identifier, the authorization credential is generated; and the resource server corresponding to the resource corresponding to the accessed resource identifier is located Sending an authorization binding request, where the authorization binding request includes the second identifier, the authorization credential, and the accessed resource identifier; receiving an authorization binding response sent by the resource server, where the authorization binding response includes And indicating, by the access device, an authorization response, where the authorization response includes the authorization credential, the accessed resource identifier, and indication information for signing the authorization credential; a signature binding request, the signature binding request
  • the method further includes transmitting a second authorization update request to the resource server, the second authorization update request including the first identifier, the authorization credential, and the accessed resource identifier.
  • a second aspect provides a method for processing an authorization in a machine communication, including: receiving a first resource access request sent by an access device, where the first resource access request includes a first identifier of the access device, and a accessed resource identifier. And the authorization credential; determining, according to the authorization credential, that there is a second authorization relationship that includes the authorization credential and the accessed resource identifier, and the access device identifier bound in the second authorization relationship is not the first identifier
  • the method further includes: sending a second resource access response to the access device, where the second resource access response includes a resource corresponding to the accessed resource identifier.
  • the method before the receiving the first resource access request sent by the access device, the method further includes: The authorization server receives the access request from the access device, where the authorization request includes the second identifier, the accessed resource identifier, and authentication information that the user agrees to access the resource by the access device; the authorization server is configured according to the authentication And determining, by the user, the right to access the resource corresponding to the accessed resource identifier, generating the authorization credential, and sending an authorization binding request to the resource server where the resource corresponding to the accessed resource identifier is located, where the authorization is performed.
  • the binding request includes the second identifier, the authorization credential, and the accessed resource identifier; the resource server saves the correspondence between the second identifier, the authorization credential, and the accessed resource identifier as An authorization relationship, and an authorization binding response sent to the authorization server, the authorization binding response includes binding And the authorization server sends an authorization response to the access device, where the authorization response includes the authorization credential, the accessed resource identifier, and indication information for signing the authorization credential; the authorization server receives a signature binding request sent by the access device, where the signature binding request includes the second identifier, the authorization credential, a signature of the authorization credential, and the accessed resource identifier, where the authorization credential The signature is generated by the access device using the key to sign the authorization credential; the authorization server identifies the second identifier, the authorization credential, the signature of the authorization credential, and the accessed resource identifier The correspondence is saved as the first authorization relationship.
  • the method further includes: sending a third authorization update request to the authorization server, where the third authorization update request includes the authorization credential and the first identifier; Receiving a third authorization update response sent by the authorization server, the third authorization update The response includes indication information that the authorization server authorizes the update to be successful.
  • the third aspect further provides an authorization server in the machine communication, comprising: a receiving module, configured to receive a first authorization update request sent by the access device, where the first authorization update request includes the first identifier of the access device a sending module, configured to send a first authorization update response to the access device, where the first authorization update response includes signature request information, where the signature request information indicates that the access device signs the verification information; the receiving module And a signature verification request sent by the access device, where the signature verification request includes the first identifier, the verification information, and a signature of the verification information; wherein the signature of the verification information is And the obtaining module is configured to generate the saved first authorization relationship according to the verification information in the signature verification request received by the receiving module, and the determining module is configured to: And verifying the signature of the verification information in the received signature verification request and the first authorization relationship Reduction signature, signature verification is determined that the signature verification information request is legal; updating module, according to the first identifier, the first update authorization relationship.
  • a receiving module configured to receive a first authorization update request
  • the updating module is configured to update the first authorization relationship according to the first identifier, specifically: the first authorization relationship
  • the second identifier in the change is changed to the first identifier, wherein the second identifier is an identifier used by the access device.
  • the authorization server further includes: an initial authorization module, configured to access the access device The resource corresponding to the accessed resource identifier is initially authorized.
  • the verification information is the second identifier saved by the access device, where the signature verification request is Further including a signature of the first identifier, where the signature of the first identifier is generated by the access device using the key to sign the first identifier; the update module is further configured to The signature of the verification information saved in the first authorization relationship is changed to the signature of the first identifier.
  • the initial authorization module is configured to access, by the access device, the resource corresponding to the accessed resource identifier
  • the initial authorization is performed, specifically: sending a resource creation request to the resource server, where the resource creation request includes a preset access control policy and the accessed resource identifier, where the preset The access control policy includes the second identifier, and receives a resource creation response sent by the resource server, where the resource creation response indicates that the resource server successfully creates the access control policy resource and the access control policy resource Binding the resource corresponding to the accessed resource identifier to the access device, sending a signature request to the access device, the signature request instructing the access device to sign the second identifier, and receiving a signature response sent by the access device,
  • the signature response includes a signature of the second identifier
  • the first authorization relationship is saved, where the first authorization relationship includes a correspondence between the second identifier, a signature of the second identifier, and the accessed
  • the sending module is further configured to An identifier, after updating the first authorization relationship, sending a second authorization update request to the resource server, where the second authorization update request includes the first identifier and the accessed resource identifier.
  • the verification information is an authorization credential
  • the first authorization update request further includes the authorization credential
  • the determining module is further configured to: before the sending the first authorization update response to the access device, determine, according to the authorization credential, that the first authorization relationship includes the authorization credential, and the first authorization The device identifier bound in the relationship is not the first identifier.
  • the initial authorization module is configured to access, by the access device, the resource corresponding to the accessed resource identifier Performing an initial authorization, specifically: receiving an authorization request of the access device, where the authorization request includes the second identifier, the accessed resource identifier, and authentication information that the user agrees to access the resource by the access device; The authentication information is generated, and the authorization certificate is generated when the user has the right to access the resource corresponding to the accessed resource identifier, and the authorization binding request is sent to the resource server where the resource corresponding to the accessed resource identifier is located, where The authorization binding request includes the second identifier, the authorization credential, and the accessed resource identifier; receiving an authorization binding response sent by the resource server, where the authorization binding response includes indication information that the binding is successful; The access device sends an authorization response, the authorization response including the authorization credential, the accessed resource identifier, and a pair And the indication information that the authorization credential is signed
  • the sending module is further configured to: update, according to the first identifier, After the first authorization relationship, the second authorization update request is sent to the resource server, where the second authorization update request includes the first identifier, the authorization credential, and the accessed resource identifier.
  • the fourth aspect further provides a resource server in a machine communication, comprising: a receiving module, configured to receive a first resource access request sent by the access device, where the first resource access request includes a first identifier of the access device And a determining module, configured to determine, according to the authorization credential, a second authorization relationship that includes the authorization credential and the accessed resource identifier, and the second authorization relationship is bound
  • the device identifier is not the first identifier
  • the sending module is configured to send a first resource access response to the access device, where the first resource access response includes signature request information, and the signature request information indicates the access device pair
  • the receiving module is configured to receive the second resource access request sent by the access device, where the second resource access request includes the first identifier, the authorization credential, and the a signature of the authorization credential and the accessed resource identifier; wherein the signature of the authorization credential is a key used by the access device
  • the sending module is further configured to send a signature data request to the authorization server, where the signature data
  • the sending module is further configured to: after updating the second authorization relationship according to the first identifier, send the information to the access device And a second resource access response, where the second resource access response includes a resource corresponding to the accessed resource identifier.
  • the updating module configured to update the second according to the first identifier Grant
  • the weight relationship is specifically: changing the second identifier in the second authorization relationship to the first identifier, where the second identifier is an identifier used by the access device.
  • the receiving module is further configured to receive, by the authorization server, access the accessed resource identifier to the access device An authorization binding request sent by the corresponding resource after the initial authorization, where the authorization binding request includes the second identifier, the authorization credential and the accessed resource identifier, and a storage module, configured to: use the second identifier And the correspondence between the authorization credential and the accessed resource identifier is saved as a second authorization relationship.
  • the M2M system can determine whether the signature of the verification information is legal, that is, by comparing the signature of the verification information sent by the access device. Whether the authentication information signature in the first authorization relationship saved by the authorization server is the same, to identify the identity of the access device, and then update the existing authorization relationship, so that the access device can continue to use the existing authorization relationship, thereby implementing seamless resources. Access ensures business continuity of the M2M system.
  • FIG. 1 is a system block diagram of an authorization update according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a method for authorizing in machine communication according to an embodiment of the present invention
  • FIG. 3 is a flowchart of still another method for processing an authorization according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of initial authorization based on an ACP authorization architecture according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of an authorization update based on an ACP authorization architecture according to an embodiment of the present invention
  • FIG. 6 is a flowchart of initial authorization based on an Oauth authorization architecture according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of an authorization update based on an Oauth authorization architecture according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of another authorization update based on an Oauth authorization architecture according to an embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of an authorization server according to an embodiment of the present invention.
  • FIG. 10 is a schematic structural diagram of still another authorization server according to an embodiment of the present invention.
  • FIG. 11 is a schematic structural diagram of a resource server according to an embodiment of the present invention.
  • FIG. 12 is a schematic structural diagram of still another resource server according to an embodiment of the present invention.
  • authorization server and the resource server described in the embodiment of the present invention may be implemented by different functional modules of the same device, or may be implemented by different devices, which is not limited by the present invention.
  • the system includes a plurality of communication devices that communicate with one another via a wired or wireless communication network. among them,
  • the access device 102 can be an Application Entity (AE) or a Common Service Entity (CSE).
  • AE Application Entity
  • CSE Common Service Entity
  • the registration server 104 can access the M2M system and can access resources managed by other entities in the M2M system.
  • Registration server 104 a public service that provides registration services for access devices 102 in an M2M system
  • the Registrar CSE (R-CSE) is responsible for providing the access device 102 with a registration and assigning an entity identifier (Application Entity-Identifier, AE-ID/Common Service Entity-Identifier, CSE-ID) as an access device.
  • entity identifier Application Entity-Identifier, AE-ID/Common Service Entity-Identifier, CSE-ID
  • Authorization server 106 may be a public service principal (Infrastructure Node–CSE, IN-CSE) residing in an Infrastructure Node (IN), or an authorization server (Authorization) running separately and connected to IN-CSE Server, AS), responsible for preserving the authorization relationship in the M2M system, maintaining the correspondence between the access device, the authentication information of the access device, the signature of the authentication information, and the identifier of the accessed resource.
  • IN-CSE Infrastructure Node
  • AS authorization server
  • the resource server 108 is generally a public service subject (Hosting CSE, H-CSE) of the node where the accessed resource is located, and maintains a corresponding authorization relationship of the local resource, and performs an access control decision according to the resource access request sent by the access device 102, according to the decision result. Returns a resource access response to the access device.
  • Hosting CSE H-CSE
  • H-CSE public service subject
  • the present invention relates to two authorization relationships, one of which is maintained by the authorization server, which is called the first authorization relationship, and the other is maintained by the resource server, which is called the second authorization relationship.
  • the present invention also relates to two access device identifiers, that is, a first identifier and a second identifier, wherein the second identifier is an identifier used by the access device, and the authorization associated with the second identifier is maintained on the authorization server and the resource server.
  • the second identifier is marked with AE-ID1;
  • the first identifier is the identifier obtained after the access device is re-registered, and the first identifier is marked with AE-ID2 in the following inventive embodiment.
  • the invention introduces a method for updating the second identifier in the first authorization relationship and the second authorization relationship to the first identifier, so that the access device can continue to obtain the access authority of the resource by using the original authorization relationship.
  • This method allows the user to seamlessly access the corresponding resources through the access device without re-creating the corresponding authorization relationship, which brings a lot of convenience for the access device to access the resource.
  • the token-based authorization relationship is established. Referring to the Oauth2.0 related protocol, the resource owner needs to perform online authorization. When the resource owner is offline, the M2M system cannot re-authorize the access device, thereby making the user unable to access the resource. .
  • the authorization relationship of the access device identifier, the accessed resource identifier, the access device verification information, and the signature correspondence relationship of the verification information is saved in the authorization server 106.
  • the authorization server 106 obtains from the access device 102.
  • the signature of the verification information is stored in the authorization relationship together with the corresponding access device identifier, the verification information, and the accessed resource identifier.
  • the authorization server 106 may confirm the original identity of the access device 102 after receiving the signature verification request sent by the access device 102, or may send the signature of the verification information to the resource server 108 when receiving the signature request sent by the resource server 108.
  • Server 108 confirms the original identity of access device 102.
  • the resource server 108 is a public service entity of a node where the resource is located, and the resource server 108 may reside in an intermediate node (MN), an infrastructure node (IN), or an application service node (Application Service Node) in the M2M system. , ASN).
  • MN intermediate node
  • I infrastructure node
  • APN application service node
  • the present invention adds a decision logic for authorizing the update process for performing an access control decision on the resource access request sent by the access device 102, and when the result is unlicensed, the local is started. Authorize the update or redirect the resource access request to the authorization server 106 for an authorization update.
  • the resource server 108 acquires the signature of the verification information from the authorization server 106, and acquires the signature of the corresponding verification information from the access device 102 to complete the access device original identity confirmation.
  • the authorization server 106 actively updates the local authorization relationship upon completion of the original identity confirmation of the access device 102, or updates the local authorization relationship under the direction of the authorization server 106.
  • the access device 102 may be an application entity (AE) or a public service entity (CSE) and access the M2M system through the registration server 104.
  • the present invention adds a signature module to the access device 102 for signing the corresponding information using the key when receiving the signature request of the authorization server 106 or the resource server 108, and returning the signature of the information to the authorization server 106 or Resource server 108.
  • the key used by the access device for signing may be set by the device, or may be generated by other methods. The specific form of the key is not limited by the present invention.
  • the registration server 104 may be an MN-CSE, or an IN-CSE or an ASN-CSE, responsible for assigning an identity to the access device 102.
  • the resource server 108 and the authorization server 106 can be used as two functional modules in one device, or can be used as two separately operated devices in the M2M system.
  • the resource server 108 and the authorization server 106 act as two functional modules in one device, the information interaction between the resource server 108 and the authorization server 106 acts as an interaction of the internal information of the device.
  • the present invention does not limit the specific representation of the resource server 108 and the authorization server 106.
  • the present invention places the resource server 108 and authorization in the following embodiments. Server 106 is described as two separately operating devices.
  • the authorization architecture of Figure 1 only gives an example of the change of the access device identity (AE is registered on the registration servers R-CSE1 and R-CSE2, and is assigned different AE-IDs), depending on the way the access device identity is assigned.
  • the access device ID may also change under other circumstances (such as registration on the same registration server, but the original identity of the access device has been assigned to other entities, etc.).
  • the resource server 108 and the registration server 104 may be directly connected to the IN-CSE, and may also be connected to the IN-CSE through other CSEs.
  • the specific structure of the M2M system is not limited in the present invention.
  • FIG. 2 is a flowchart of a method for authorizing in machine communication according to the present invention, including:
  • Step 202 Receive a first authorization update request sent by the access device, where the first authorization update request includes a first identifier of the access device.
  • the destination address of the first authorization update request may be an authorization update port of the authorization server, that is, the authorization server receives the first authorization update request sent by the access device by using the authorization update port.
  • the first authorization update request further includes an accessed resource identifier.
  • the signature request information may be a signature flag bit.
  • the signature flag bit takes a value of “1”, it indicates that the access device needs to sign the verification information; when the signature flag bit takes “2”, Indicates that the access device is required to sign the authentication information and the current identity of the access device.
  • Step 206 Receive a signature verification request sent by the access device, where the signature verification request includes the first identifier, the verification information, and the signature of the verification information.
  • the signature of the verification information is the access device. Generating the verification information by using a key;
  • Step 208 Acquire a saved first authorization relationship according to the verification information.
  • Step 210 Determine, according to the signature of the verification information in the received signature verification request and the signature of the verification information saved in the first authorization relationship, that the signature of the verification information in the signature verification request is legal;
  • the authorization server acquires the signature of the verification information saved in the first authorization relationship, and compares the signature of the verification information saved in the first authorization relationship with the signature of the verification information in the received signature verification request. Determining the verification in the signature verification request when the two are the same The signature of the certificate information is legal.
  • Step 212 Update the first authorization relationship according to the first identifier.
  • the authorization server determines that the identifier of the access device has been updated to the first identifier, so the authorization server needs to locally save the authorization related to the access device. The relationship is updated.
  • the first authorization relationship is updated according to the first identifier, where the second identifier in the first authorization relationship is changed to the first identifier, where the second identifier is The identifier used by the access device is deleted; or the first authorization relationship is deleted, and a new authorization relationship is created, where the new authorization relationship includes the first identifier, the verification information in the first authorization relationship, and The signature of the verification information in the first authorization relationship.
  • the method further includes: the resource server receiving the access device to send a resource access request, where the resource access request includes the first identifier and the accessed resource identifier; Determining, by the first identifier, the accessed resource identifier, that the access device does not have access to the resource corresponding to the accessed resource identifier; and the resource server rejects the resource corresponding to the accessed resource identifier of the access device Access request, and sending a resource access response including a redirect address to the access device, wherein the redirect address is an authorized update port address of the authorization server, so that the access device updates the port address according to the authorization,
  • the authorization server sends the first authorization update request.
  • the method before the receiving the first request message sent by the access device, the method further includes: the authorization server performing initial authorization on the access device to access the resource corresponding to the accessed resource identifier.
  • the verification information may be the second identifier.
  • the verification information is the second identifier
  • the second identifier, the signature of the second identifier, and the first authorization relationship corresponding to the accessed resource identifier are saved on the authorization server.
  • a second authorization relationship corresponding to the second identifier and the accessed resource identifier is saved on the resource server.
  • the signature verification request further includes a signature of the first identifier, where the signature of the first identifier is a key pair used by the access device.
  • the method further includes: verifying the verification information saved in the first authorization relationship.
  • the signature is changed to the signature of the first identity.
  • the authorization server accesses the access device to the access device Accessing the resource for initial authorization, specifically: sending a resource creation request to the resource server, where the resource creation request includes a preset access control policy and the accessed resource identifier, where the preset access control policy includes The second identifier is configured to enable the resource server to set an access control policy resource according to the preset access control policy, and bind the access control policy resource to a resource corresponding to the accessed resource identifier, where The access control policy resource includes the second identifier, and receives a resource creation response sent by the resource server, where the resource creation response indicates that the resource server successfully creates the access control policy resource and uses the access control policy resource Binding a resource corresponding to the accessed resource identifier; sending a signature request to the access device, the signature
  • one possible implementation manner for the administrator to create a preset access control policy on the authorization server is that the access device 102 registers on the registration server 104 to generate registration information, where the registration information includes a registration server allocation.
  • the identifier such as the second identifier, and information that reflects the characteristics of the access device, such as an IP address, a MAC address, or a device description information of the access device, and the administrator obtains the registration information after logging in to the authorization server, and according to
  • the registration information creates an access control policy, that is, creates a rule that allows an access device to access a resource.
  • the method further includes: updating the second authorization relationship saved on the resource server, specifically, after the updating the first authorization relationship according to the first identifier, the method The method further includes: sending a second authorization update request to the resource server, where the second authorization update request includes the first identifier, the second identifier, and the accessed resource identifier, so that the resource server is configured according to the second identifier Obtaining the saved second authorization relationship with the accessed resource identifier, and updating the second identifier in the saved second authorization relationship to the first identifier.
  • the authorization server receives the first identifier sent by the resource server.
  • the second authorization update response indicates that the authorization relationship update is successful.
  • the verification information may be sent by the authorization server to the access device by using the first authorization update response after receiving the first authorization update request of the access device, or the verification Information can also be saved on the access device.
  • the second identifier is saved as the verification information on the access device, but the invention is not limited thereto.
  • the verification information may be the authorization credentials.
  • the second identifier, the authorization credential, the signature of the authorization credential, and the first authorization relationship corresponding to the accessed resource identifier are saved on the authorization server. And storing, on the resource server, the second identifier, the authorization credential, and the second authorization relationship corresponding to the accessed resource identifier.
  • the verification information is an authorization credential
  • the first authorization update request further includes the authorization credential
  • the method further includes: The authorization credential determines that the first authorization relationship includes the authorization credential, and the device identifier bound in the first authorization relationship is not the first identifier.
  • the initial authorization for the access device to access the resource corresponding to the accessed resource identifier specifically: receiving an authorization request of the access device, where the authorization request includes the second identifier, the accessed resource identifier And the user agrees to the authentication information of the access device accessing the resource; when determining, according to the authentication information, that the user has the right to access the resource corresponding to the accessed resource identifier, generating the authorization credential;
  • the resource server where the resource corresponding to the resource identifier is sent sends an authorization binding request, where the authorization binding request includes the second identifier, the authorization credential, and the accessed resource identifier; and receiving an authorization binding sent by the resource server
  • the authorization binding response includes indication information indicating that the binding is successful; sending an authorization response to the access device, the authorization response including the authorization credential, the accessed resource identifier, and the signature of the authorization credential Instructing information; receiving a signature binding request sent by the access device, where the signature binding request includes a second identifier, the authorization credential,
  • the method further includes: updating the second authorization relationship saved on the resource server, specifically, after the updating the first authorization relationship according to the first identifier, the method The method further includes: sending a second authorization update request to the resource server, where the second authorization update request includes the first identifier, the authorization credential, and the accessed resource identifier.
  • the resource server obtains the saved second authorization relationship according to the authorization credential and the accessed resource identifier, and updates the second identifier in the second authorization relationship to the first identifier, optionally, authorizing
  • the server receives a second authorization update response sent by the resource server, and the second authorization update response indicates that the authorization relationship update is successful.
  • the access device can use the original authorization relationship to implement resource access.
  • the embodiment of the present invention provides a method for processing an authorization in a machine communication system.
  • the M2M system can determine whether the signature of the verification information is legal, that is, Comparing the signature of the authentication information sent by the access device with the signature of the authentication information in the first authorization relationship saved by the authorization server to identify the identity of the access device, thereby updating the existing authorization relationship, so that the access device can continue to use the existing
  • the authorization relationship in order to achieve seamless resource access, ensures the business continuity of the M2M system.
  • FIG. 3 is a flowchart of still another method for processing an authorization according to an embodiment of the present invention, including:
  • Step 302 Receive a first resource access request sent by the access device, where the first resource access request includes the first identifier of the access device, the accessed resource identifier, and an authorization credential;
  • Step 304 Determine, according to the authorization credential, that there is a second authorization relationship that includes the authorization credential and the accessed resource identifier, and the device identifier bound in the second authorization relationship is not the first identifier;
  • Step 306 Send a first resource access response to the access device, where the first resource access response includes signature request information, where the signature request information indicates that the access device signs the authorization credential;
  • Step 308 Receive a second resource access request sent by the access device, where the second resource access request includes the first identifier, the authorization credential, a signature of the authorization credential, and the accessed resource identifier.
  • the signature of the authorization credential is generated by the access device using a key to sign the authorization credential;
  • Step 310 Send a signature data request to an authorization server, where the signature data request includes the authorization credential;
  • Step 312 Receive a signature data response sent by the authorization server, where the signature data response includes a signature of the authorization credential saved in the first authorization relationship acquired by the authorization server according to the authorization credential;
  • Step 314 Determine, according to the signature of the authorization credential in the second resource access request and the signature of the authorization credential sent by the authorization server, that the signature of the authorization credential in the second resource access request is legal;
  • the resource server compares the signature of the authorization credential sent by the authorization server with the signature of the authorization credential in the second resource access request, and when the two are the same, the second is determined.
  • the signature of the authorization credential in the resource access request is legal.
  • Step 316 Update the second authorization relationship according to the first identifier.
  • the second authorization relationship is: changing a second identifier in the second authorization relationship to the first identifier, where the second identifier is the access The identifier used by the device, or the second authorization relationship is deleted, and a new second authorization relationship is created, where the new second authorization relationship includes the first identifier and the authorization certificate in the second authorization relationship. And the accessed resource identifier.
  • the authorization server receives the access device to send an authorization request, where the authorization request includes the second identifier, the accessed resource identifier, and the user agree to the Accessing the authentication information of the device accessing the resource; the authorization server determines, according to the authentication information, that the user has the right to access the resource corresponding to the accessed resource identifier, generates the authorization credential, and identifies the resource to the accessed resource.
  • the resource server where the corresponding resource is located sends an authorization binding request, where the authorization binding request includes the second identifier, the authorization credential, and the accessed resource identifier; the resource server uses the second identifier and the Corresponding relationship between the authorization credential and the accessed resource identifier is saved as a second authorization relationship, and an authorization binding response is sent to the authorization server, where the authorization binding response includes indication information indicating that the binding is successful; the authorization The server sends an authorization response to the access device, the authorization response including the authorization credential, the a resource identifier and indication information for signing the authorization credential; the authorization server receives a signature binding request sent by the access device, where the signature binding request includes the second identifier, the authorization credential, and the Declaring a signature of the authorization credential and the accessed resource identifier, wherein the signature of the authorization credential is generated by the access device using the key to sign the authorization credential; the authorization server will be the second The identifier, the authorization credential, the signature of the authorization credential, and the
  • step 302 after the access device sends the first resource access request to the resource server, the resource server needs to make a decision on the access request of the access device. Only when the information in the resource access request exactly matches the second authorization relationship saved by the resource server, the resource server allows the request and returns the requested resource to the access device. Specifically, the resource server determines, according to the first resource access request, that there is a second authorization relationship that includes the authorization credential and the accessed resource identifier, and the device identifier bound in the second authorization relationship is not the The first identifier is that the resource server determines that the identity of the access device changes or that the authorization credential is leaked.
  • steps 306-314 Determining, by the source server, the signature of the authorization credential from the access device and the authorization server, determining that the first identifier and the second identifier are identifiers of the access device, and then actively using the first identifier to update and save Second authorization relationship.
  • the method further includes: sending a second resource access response to the access device, where the second resource access response includes the The resource corresponding to the resource identifier being accessed. Therefore, the access device utilizes the original authorization relationship to achieve the purpose of resource access.
  • the method further includes: sending a third authorization update request to the authorization server, where the third authorization update request includes Receiving the authorization credential and the first identifier; receiving a third authorization update response sent by the authorization server, where the third authorization update response includes indication information that the authorization server authorizes the update success.
  • the embodiment of the present invention provides a method for processing an authorization in a machine communication system.
  • the M2M system can determine whether the signature of the verification information is legal, that is, Comparing the signature of the authentication information sent by the access device with the signature of the authentication information in the first authorization relationship saved by the authorization server to identify the identity of the access device, thereby updating the existing authorization relationship, so that the access device can continue to use the existing
  • the authorization relationship in order to achieve seamless resource access, ensures the business continuity of the M2M system.
  • the verification information may be the second identifier of the access device.
  • an authorization process based on the ACP authorization architecture in the M2M system including two sub-processes, an initial authorization and an authorization update, where the initial authorization refers to accessing the device.
  • the authorization server obtains the signature of the authentication information for the access device and generates an authorization relationship.
  • FIG. 4 is a flowchart of an initial authorization based on an ACP authorization architecture according to the present invention.
  • the access device is an application entity AE, but the specific form of the access device in the embodiment of the present invention is not To be limited, the method includes:
  • Step 402-Step 404 The AE sends a registration request to the registration server 1 (R-CSE1), and the registration server 1 assigns an identifier AE-ID1 to the AE;
  • Step 406 The system administrator (Admin) creates an ACP for the AE on the authorization server (AS);
  • Admin manually sets the ACP for the AE.
  • the ACP is created as a resource and bound to the corresponding resource.
  • the binding mode is to add the ACP resource identifier (ACP ID) to the access control policy identifier accessControlPolicyIDs attribute value of the corresponding resource.
  • ACP ID ACP resource identifier
  • accessControlPolicyIDs attribute value of the corresponding resource.
  • each rule of the ACP resource in the M2M system is a triple ⁇ accessControlOriginators, accessControlContexts, accessControlOperations>.
  • the Admin creates an ACP for the AE, which may be: setting the accessControlOriginators parameter to "/CSE0005/CAE0001", where /CSE0005/CAE0001 is AE-ID1.
  • the other parameters are not related to the solution of the present invention, and thus the embodiment of the present invention is not limited.
  • Step 408 The authorization server sends an ACP resource creation request to the resource server (H-CSE).
  • the ACP resource creation request includes all attribute data of the ACP created by the Admin for the AE and the resource identifier of the corresponding binding.
  • the ACP resource creation request sent by the authorization server to the resource server may be:
  • the "http://m2m.things.com/CSE0003" is the URL of the H-CSE (Uniform Resoure Locator), and is also the parent node of the AS that wants to create an ACP resource, that is, the ACP resource is created in the H-CSE.
  • the AS can also define the parent resource ID of the ACP resource to be created in the URL of the POST request.
  • the specific creation of the ACP resource has no effect on the solution of the present invention, which is not limited by the present invention.
  • the "From” section describes the initiator ID of the resource creation request, which in this embodiment is the URL address of the authorization server "http://authzserver.things.com".
  • the HTTP message body contains all the attributes of the created ACP resource.
  • the "ResourceType”: "accessControlPolicy” section indicates that the resource type created by this request is ACP, ""privileges.accessControlOriginators”: “/CSE0005/CAE0001
  • the section “” indicates that the access device to which the created ACP resource applies is “/CSE0005/CAE0001”; Other attributes of the created ACP resource should be included, but are not described in this embodiment since they are not related to the inventive scheme.
  • the "res_uri”: “/CSE0003/resource1” section indicates that the resource URI to be bound to the ACP resource is "/CSE0003/resource1", and the resource URI to be bound in the specific implementation may also be described by other means. (If it is included in the URL of the POST request as a query string), but its specific description does not affect the creation and binding process of ACP resources.
  • Step 410 The resource server creates an ACP resource, and binds the created ACP resource to the corresponding resource.
  • the H-CSE After the H-CSE receives the ACP resource creation request of the AS, the H-CSE first parses the creation location or the parent resource ID of the ACP resource from the resource creation request, and then parses the created ACP from the HTTP message body. The value of each attribute of the resource.
  • the creation location of the ACP resource is "http://m2m.things.com/CSE0003", that is, the resource is created under the root node of the H-CSE; in addition, the "" in the HTTP message body
  • the ResourceType”: "accessControlPolicy” section indicates that the type of the created resource is ACP
  • the "accessControlOriginators”: “/CSE0005/CAE0001” section indicates that the accessControlOriginators parameter of an access control rule of the ACP is "/CSE0005/CAE0001”.
  • the HTTP message body of the ACP resource creation request may also include other attribute values of the ACP resource in the specific implementation. When the ACP resource is created, the H-CSE needs to obtain the corresponding attribute value of the created ACP resource. Assignment.
  • the H-CSE allocates an ACP ID to the ACP resource and sets it as the resource identifier of the ACP resource (ie, the resourceID attribute), for example, “ACP0001”, where the ACP ID is The ACP resource is uniquely identified within the H-CSE range. Then, the H-CSE finds the corresponding resource according to the bound resource identifier in the ACP resource creation request, that is, "/CSE0003/resource1", and adds the ACP ID of the created ACP resource in the accessControlPolicyIDs attribute value list of the resource, that is, " ACP0001".
  • Step 412 The resource server returns an ACP resource creation response to the authorization server.
  • the H-CSE returns an ACP resource creation response to the AS, where the response includes an HTTP 200 response code.
  • the ACP resource created by the H-CSE to the AS creates a response as:
  • the status code of the HTTP response is 200, indicating that the H-CSE has completed the creation and binding of the corresponding ACP resource.
  • the "resourceID" in the HTTP message body: "/CSE0003/ACP0001"" indicates that the ACP ID assigned by the H-CSE to the created ACP is "/CSE0003/ACP0001", and the ACP ID is preceded by H-CSE. CSE ID to uniquely identify the ACP resource in the oneM2M system.
  • Step 414 The authorization server determines whether the signature of the verification information corresponding to the AE-ID1 exists in the saved authorization relationship mapping table.
  • the AS queries the saved authorization relationship mapping table to query the authorization relationship of the access device identifier equal to AE-ID1, and if the corresponding authorization relationship is found, and the signature of the corresponding verification information is saved in the authorization relationship, the initial is completed.
  • Authorization otherwise, proceeding to step 316, a signature request is initiated to the AE, requesting the AE to sign the corresponding verification information.
  • each authorization relationship in the authorization relationship mapping table is used to save an access device identifier, a accessed resource identifier, access device verification information, and a signature of the verification information.
  • Table 1 records the structure of a possible authorization relationship mapping table:
  • each row in the table represents an authorization relationship corresponding to an access device, including an access device identifier (subjectID), a signature (signature), and a list of accessed resource URIs (res_uris).
  • the access device identifier also serves as the verification information of the access device.
  • the "signature" column is a signature of the access device using the key to the corresponding access device identifier. From the first line of Table 1, the res_uris column has two accessed resource URIs.
  • each authorization relationship in the authorization relationship mapping table records the authorization status of an access device. Obviously, the same access device Access to multiple resources is available.
  • verification information may also be used for each access device, such as using a randomly generated string as the verification information, and storing the signature values of the verification information by each access device, as shown in Table 2:
  • the authentication relationship table structure of the randomly generated verification information (challenge) and its signature is stored for each access device. What kind of information is used as the verification information in the specific implementation does not affect the specific solution of the present invention.
  • the M2M system uses the authorization relationship mapping table structure as described in Table 1, that is, the access device identifier is used as the verification information.
  • the authorization relationship mapping table may be maintained by a general database inside the AS during the specific implementation, or may be expressed as a RESTful resource AuthzRelMapTable.
  • the AuthzRelMapTable resource can be expressed in the form shown in Table 3 below:
  • the AuthzRelMapTable is an authorization relationship mapping table resource, and the resource includes a plurality of authorization record attributes, that is, an authzRecord resource, and each authzRecord resource records an authorization relationship of the access device, and the authzRecord resource includes the following attributes:
  • subjectID corresponding to the access device identification attribute in Table 1;
  • Signature corresponds to the signature attribute in Table 1;
  • Res_uris Corresponds to the accessed resource URI list attribute in Table 1.
  • Table 1 is taken as an example. Specifically, after receiving the resource creation response of the H-CSE, the AS first searches for the authorization relationship of the access device identifier equal to AE-ID1 in the authorization relationship mapping table, that is, the value of the "subjectID” column is equal to Authorization relationship of "/CSE0005/CAE0001". If an eligible authorization relationship can be found in the authorization relationship mapping table, and the signature attribute value of the authorization relationship is not null, AS The initial authorization process is directly ended; otherwise, the AS initiates a signature request process, and step 416 is performed.
  • Step 416 The authorization server sends a signature request to the AE.
  • the signature request initiated by the AS to the AE may be:
  • the URL requested by the POST part is the URI of the AE on the R-CSE, and the R-CSE forwards the signature request to the AE after receiving the request.
  • the "SigReq": "1" part in the HTTP message body is a signature request flag indicating that the AE is required to sign the verification information.
  • the authentication information is AE-ID1. Since the AE itself saves its own identifier, it is not necessary to include the verification information parameter in the HTTP message body of the signature request at this time; when other implementations, other forms of verification information are used.
  • the corresponding verification information parameter may be included in the HTTP message body of the signature request.
  • Step 418 The AE uses the device factory key to sign the verification information.
  • the AE receives the signature request of the AS, it first detects whether the HTTP message body includes the signature request flag bit “SigReq”, and when the resource access response includes the “SigReq” parameter and the value is “1”, the AE The corresponding verification information is signed using some preset signature algorithm and the device's factory key.
  • the signature calculated for AE-ID1 is "JYUI7BZO92".
  • the AE binds the AE-ID1 and the M2M Service Provider Identifier to the local device at this time.
  • the save method may be implemented by using the access device identifier mapping table, or may be saved in other manners.
  • the storage method used in the specific implementation does not affect the solution of the present invention.
  • the AE end uses an access device identifier mapping table to store the correspondence between the AE-ID and the M2M SP ID, as shown in Table 4:
  • the AE saves the currently assigned identifier. It should be noted that the AE saves the currently assigned identifier and is not related to the access device identifier mapping table saved here. For example, for some reason, the access device re-registers with the new registration server to obtain the identification AE-ID11, and the access device saves the AE-ID11 as the current device identification. However, if the access device does not reapply with AE-ID11 Authorization, the access device ID in the access device ID mapping table is not updated.
  • Step 420 The AE returns a signature response to the AS.
  • the AE returns a signature response to the AS.
  • the signature response returned by the AE to the AS is:
  • the status code of the HTTP response is “200”, indicating that the AE has signed the verification information.
  • the "signature”: "JYUI7BZO92" section in the HTTP message body indicates that the signature of the authentication information is "JYUI7BZO92".
  • Step 422 After receiving the signature response of the AE, the authorization server parses the signature of the verification information from the signature response, and adds a corresponding authorization relationship in the authorization relationship mapping table.
  • the AS when the AS receives the signature response of the AE, the AS first parses the signature of the verification information from the HTTP message body of the signature response, that is, “JYUI7BZO92”; then the AS searches for the AE corresponding to the AE in the authorization relationship mapping table.
  • Authorization relationship that is, the value of the subjectID attribute is equal to AE-ID1, that is, the authorization relationship of "/CSE0005/CAE0001": if the authorization relationship is found, the signature attribute value of the authorization relationship is assigned to "JYUI7BZO92"; if the attribute is not found Authorization relationship, then construct a new authorization relationship and add the authorization relationship to the authorization relationship mapping table.
  • the authorization relationship corresponding to the AE does not exist in the authorization relationship mapping table of the AS, so the AS generates a new authorization relationship and updates to the authorization relationship mapping table, and the updated The authorization relationship mapping table is shown in Table 5.
  • the third row of data in the table is the newly generated authorization relationship.
  • FIG. 5 is a flowchart of an authorization update based on an ACP authorization architecture according to the present invention.
  • the new registration server R-CSE2 may assign a new identification AE to the AE. -ID2, which invalidates the existing authorization relationship in the M2M system.
  • the method provides a method for updating an authorization relationship after the access identifier changes, including:
  • Step 502-Step 504 The AE sends a registration request to the registration server 2 (R-CSE2), and the registration server 2 assigns an identifier AE-ID2 to the AE;
  • Step 506 The AE initiates a resource access request to the resource server (H-CSE), where the resource access request includes the AE-ID2 and the URI of the accessed resource.
  • H-CSE resource server
  • the AE sends a resource access request to the H-CSE.
  • the initial resource access request initiated by the AE to the H-CSE is:
  • Step 508 The resource server (H-CSE) performs an access control decision according to the information carried in the access request.
  • the H-CSE After the H-CSE receives the resource access request of the AE, the H-CSE first parses the URI of the accessed resource in the resource access request, that is, the URL address “/CSE0003/resource1” in the GET request, and searches locally. The corresponding resource resource1. Then, the H-CSE parses the AE-ID2 in the resource access request, that is, the URL query string portion "/CSE0006/CAE0003" in the GET request; finally, the binding to the resource is found in the accessControlPolicyIDs attribute value of the corresponding resource resource1. A list of ACP IDs and decisions on whether the AE has access to resources in accordance with the access control decision process described in the background.
  • the access device identifier of only AE is changed from AE-ID1 to AE-ID2 with respect to the initial authorization, and other resource access related attributes (such as operation, context, etc.) are consistent with the conditions defined by the initial authorization.
  • the value of the privileges.accessControlOriginators attribute only contains AE-ID1, ie /CSE0005/CAE0001, so during the access decision process, the H-CSE cannot find the AE-ID2, ie /CSE0006/CAE0003 ACP, so the result of access control decisions is that this resource access is not allowed.
  • the resource server will directly deny access requests to the device. As a result, the same access device fails to access the resource due to the change of the device identifier.
  • Step 510 The resource server returns a resource access response to the AE, where the response includes an HTTP 302 response code and a redirect URL, and the redirect URL points to an authorized update end of the authorization server. mouth.
  • the resource access response returned by the H-CSE to the AE is:
  • the status code of the HTTP response is “302”, indicating that the resource access request of the AE needs to be redirected to the new URL.
  • "Location: http://authzserver.things.com/authzupdate” indicates the redirect URL, which points to the authorized update port of the M2M system authorization server, for example, http://authzserver.things.com/authzupdate Authorization server authorization update port address.
  • Step 512 After receiving the resource access response of the resource server, the AE sends an authorization update request to the authorization server, where the authorization update request includes the AE-ID2 and the URI of the accessed resource.
  • the AE receives the resource access response of the H-CSE and detects the HTTP status code.
  • the AE sends an authorization update request to the AS.
  • the authorization update request sent by the AE to the AS can be:
  • Step 514 After receiving the AE authorization update request, the authorization server returns an authorization update response to the AE, where the response includes an HTTP 202 response code and a signature request flag.
  • the AS when the AS receives the AE authorization update request, the AS returns an authorization update response to the AE as:
  • the status code of the HTTP response is "202", indicating that the AS has accepted the authorization update request of the AE, but needs further information and waits for subsequent processing.
  • the "SigReq”: "2" part in the HTTP message body is a signature request flag indicating that the AE is required to sign the authentication information and the current identity of the access device.
  • the verification information that is, the access device identifier AE-ID1 of the AE at the time of initial authorization, that is, /CSE0005/CAE0001, the current identifier of the access device, that is, AE-ID2, /CSE0006/CAE0003.
  • Step 516 The AE signs the verification information by using the device factory key, and signs the current identifier AE-ID2 of the access device.
  • the AE receives the authorization update response of the H-CSE
  • the status code of the HTTP response is detected as “202” and the HTTP message body includes the “SigReq” parameter and the value is “2”
  • the AE is local.
  • the saved AE-ID1 is signed.
  • the AE-ID1 is locally saved in the form of an access device identifier mapping table.
  • the AE is based on the currently accessed M2M system identifier (that is, the M2M SP ID, which is "http" in this embodiment. ://m2m.things.com") find the corresponding access device identifier AE-ID1: /CSE0005/CAE0001 in the access device identification mapping table.
  • AE-ID1/CSE0005/CAE0001 is the corresponding verification. information.
  • the AE finds the locally saved AE-ID1, the AE signs AE-ID1 and AE-ID2.
  • the AE-ID1 is signed to obtain "JYUI7BZO92”
  • the AE-ID2 is signed to obtain "M6UI7B2OKQ”.
  • the AE-ID2 is updated to the locally saved access device identifier mapping table, instead of the original AE-ID1, that is, "/CSE0005/CAE0001" is replaced with "/CSE0006/CAE0003" in Table 4, as shown in Table 5. Updated access device identification mapping table.
  • Step 518 The AE sends a signature verification request to the authorization server.
  • the AE After the AE completes the signature, the AE initiates a signature verification request to the AS, which includes AE-ID1. Signature of AE-ID1, signature of AE-ID2, AE-ID2.
  • the signature verification request initiated by the AE to the AS is:
  • the status code of the HTTP response is “200”, indicating that the AE has signed the verification information.
  • "aeid_ori” in the HTTP message body: “/CSE0005/CAE0001”” indicates that the access device identification AE-ID1 at the initial authorization is “/CSE0005/CAE0001”
  • "sig_ori”: "JYUI7BZO92” indicates the initial authorization.
  • the signature of the access device identifier AE-ID1 is "JYUI7BZO92"; the "Aeid_now”: “/CSE0006/CAE0003” section indicates that the access device identifier AE-ID2 of the current AE is "/CSE0006/CAE0003", ""sig_now”: The "M6UI7B2OKQ”" portion indicates that the signature of the access device identifier AE-ID2 of the current AE is "M6UI7B2OKQ".
  • Step 520 The AS verifies the signature in the signature verification request, and determines whether to update the authorization relationship mapping table.
  • the AS After the AS receives the signature verification request from the AE, the AS searches the authorization relationship mapping table for the authorization relationship of the access device identifier as AE-ID1, and compares the signature of the AE-ID1 signature in the signature verification request with the signature in the authorization relationship. And further authorized update or reject authorization request for AE.
  • the AS After the AS receives the signature verification request of the AE, the AS first parses the AE-ID1, the AE-ID1 signature, the AE-ID2, and the AE-ID2 signature from the signature verification request, and then the AS is in the authorization relationship mapping table. Find the authorization relationship whose subjectID attribute value is AE-ID1 (ie, "/CSE0005/CAE0001"), and verify whether the signature attribute value in the authorization relationship is the same as the AE-ID1 signature (ie, "JYUI7BZO92").
  • the authorization server rejects the signature verification request of the AE and returns a signature verification response, for example: HTTP/1.1 403 Forbidden, the authorization update process ends; if the authorization relationship is in the corresponding relationship
  • the signature attribute value is the same as the signature of AE-ID1, which allows the AE to authorize the update and update the subjectID attribute value in the authorization relationship to AE-ID2 (ie "/CSE0006/CAE0003"), and update the signature attribute value.
  • AE-ID2 ie, "M6UI7B2OKQ”
  • the signature verification is passed, and the AS updates the authorization relationship mapping table, as shown in Table 6:
  • Step 522 The authorization server sends an authorization update request to the resource server.
  • the AS After the AS allows the authorization update of the AE, the AS initiates an authorization update request to the H-CSE, the request including the accessed resource URI, AE-ID1 and AE-ID2.
  • the authorization update request can be:
  • Step 524 The resource server updates the authorization relationship.
  • the H-CSE After the H-CSE receives the authorization update request of the AS, the H-CSE finds the corresponding resource according to the URI of the accessed resource, and updates the authorization relationship associated with the resource.
  • the H-CSE after receiving the authorization update request of the AS, the H-CSE first parses the URI of the accessed resource from the authorization update request, that is, “/CSE0003/resource1”, and finds the corresponding resource locally; secondly, the slave authorization
  • the AE-ID1 (ie, "/CSE0005/CAE0001") and AE-ID2 (ie, "/CSE0006/CAE0003”) are parsed in the HTTP message body of the update request; then, all the resources are found in the accessControlPolicyIDs attribute of the corresponding resource resource1.
  • Step 526 The resource server sends an authorization update response to the authorization server.
  • the H-CSE After the H-CSE completes the authorization update, the H-CSE returns an authorization update response to the AS. Specifically, after the H-CSE completes the authorization update, the H-CSE returns an authorization update response to the AS:
  • the status code of the HTTP response is “200”, indicating that the H-CSE has completed the update of the corresponding ACP resource.
  • Step 528 The authorization server sends a signature verification response to the AE.
  • the AS After the AS receives the H-CSE authorization update response, the AS returns a signature verification response to the AE.
  • the signature verification response returned by the AS to the AE is:
  • the status code of the HTTP response is “200”, indicating that the AS has completed the authorization update requested by the AE.
  • the AE When the AE receives the signature verification response sent by the authorization server, it indicates that the M2M system has completed the update of the authorization relationship. At this time, the AE can access the accessed resource/CSE0003/resource1 by using the access device identifier of the AE-ID2.
  • the verification information may authorize the access token generated by the server.
  • an authorization process based on the Oauth authorization architecture in the M2M system including two processes of initial authorization and authorization update, where the initial authorization refers to accessing the device.
  • the authorization server obtains the authentication information and generates an authorization relationship for the access device.
  • FIG. 6 is a flowchart of an initial authorization based on an Oauth authorization architecture according to the present invention.
  • the access device is an application entity AE, but the specific form of the access device in the embodiment of the present invention is not To be limited, the method includes:
  • Step 602-Step 604 The AE sends a registration request to the registration server 1 (R-CSE1), registering Server 1 assigns an identity AE-ID1 to the AE;
  • Step 606 The AE initiates a primary resource access request to the resource server (H-CSE), where the resource access request includes the AE-ID1 and the URI of the accessed resource.
  • H-CSE resource server
  • the AE sends an initial resource access request to the H-CSE.
  • the resource access request initiated by the AE to the H-CSE is:
  • Step 608 The resource server (H-CSE) receives the resource access request sent by the AE, and performs an access control decision.
  • the H-CSE when the H-CSE receives the resource access request, the H-CSE first searches for the corresponding resource according to the URI of the accessed resource in the resource access request. If the resource cannot be found locally, the H-CSE returns the resource access rejection to the AE. In response, for example, HTTP/1.1 404Not Found; if the accessed resource can be found locally, the H-CSE searches for the corresponding authorization relationship in the resource attribute according to the access device identifier and the access token in the resource access request.
  • the resource access request sent by the AE is the initial resource access request, as described in step 606, the request does not include the access token parameter, and the H-CSE determines that the AE is the first time to access the resource, and the H-CSE initiates the authorization process. .
  • Step 610 The resource server returns a resource access response to the AE.
  • the response includes a redirect response code and a redirect URL that points to the dynamic authorization port of the M2M system authorization server.
  • the H-CSE returns a resource access response to the AE requesting resource access.
  • the resource access response returned by H-CSE to AE can be:
  • the status code of the HTTP response is “302”, indicating that the resource access request of the AE needs to be redirected to the new URL.
  • the "Location” section represents the redirect URL, which points to the redirect URL.
  • the dynamic authorization port of the M2M system authorization server such as http://authzserver.things.com/dynamicauthz, is the dynamic authorization port address of the authorization server.
  • the attached parameter information in the example is: access
  • the device ID is "/CSE0005/CAE0001”
  • the URI of the accessed resource is "/CSE0003/resource1".
  • Step 612 The AE sends an authorization request to the resource server, where the authorization request includes an AE-ID1 and a URI of the accessed resource.
  • the AE receives the resource access response of the H-CSE and sends an authorization request to the AS, the address of the authorization request using the redirect URL provided by the Location parameter of the resource access response in step 610.
  • the AE receives the resource access response of the H-CSE and detects the HTTP status code.
  • the status code is “302”
  • the AE sends an authorization request to the AS.
  • the authorization request sent by the AE to the AS is:
  • the attached parameter information includes the AE-ID1 and the URI of the accessed resource, and the "Host" part.
  • the authorization server address is described, which is "http://authzserver.thnings.com” in this embodiment.
  • the AE may also directly use the GET request to access the redirect URL provided by the Location parameter in the resource access response when sending the authorization request to the AS, instead of using the Host parameter, for example, the authorization request may be:
  • the newline at the end of the first line is only a clear need for the document. In the specific implementation, there is no newline between the two lines.
  • Step 614 The authorization server returns an authorization response to the AE, where the authorization response includes a flag for requesting user authentication.
  • the AS after receiving the authorization request of the AE, the AS first detects whether the authorization request includes a parameter related to the user authentication. When the authorization request does not include the user authentication information, the AS returns an authorization response to the AE:
  • the status code of the HTTP response is “202”, indicating that the authorization request has been received, but further information is needed and waiting for subsequent processing.
  • the "NeedUserAuthN”: "1" parameter in the HTTP message body indicates a flag for requesting user authentication, and the parameter indicates that the AE needs to carry user authentication information in the next authorization request.
  • Step 616 The authorization response sent by the AE authorization server, when detecting that the response includes a flag for requesting user authentication, the user is allowed to input the user authentication information in the AE.
  • the AE receives the authorization response sent by the AS and detects the HTTP status code.
  • the status code is “202”
  • the AE continues to detect the HTTP message body, and when the message body is detected, the “NeedUserAuthN” parameter is included and the parameter value is “1”.
  • the user can select an appropriate input method according to the user interaction capability of the device where the AE resides.
  • the device when the device has a user interaction interface (such as a keyboard, a touch screen, etc.), the user can use the interactive interface to input the account password; When the device does not support user interaction, the user can use other interactive devices to complete input of user information; in addition, the user can complete the input of identity information through an identity card or the like that can prove its identity.
  • the specific user authentication information input mode is not within the scope of the present invention, and has no effect on the solution of the present invention.
  • the device in the present invention assumes that the device has a user interaction interface, and the user inputs the account user1 to the AE through the interaction interface. And password password1.
  • Step 618 The user inputs user authentication information.
  • Step 620 The AE sends an authorization request to the resource server, where the authorization request includes an AE-ID1, a URI of the accessed resource, and user authentication information.
  • the authorization request sent by the AE to the AS is:
  • the authorization request adds parameters related to the user authentication information as compared to the authorization request described in step 612.
  • the “user”: “user1” part indicates the user's account name
  • the “password”: “password1” part indicates the password corresponding to the user account name.
  • the authentication information of the user is included in the HTTP message body and is encoded in the JSON format.
  • the user authentication information may also be included in the URL of the GET request in the form of a query string, which is not limited by the present invention. .
  • Step 622 The authorization server determines the user identity and authority according to the user authentication information, and generates an access token (token);
  • the AS After receiving the authorization request of the AE and detecting the user authentication information, the AS obtains the user authentication information from the authorization request, and verifies the user authentication information in the user information database, and confirms whether the user has access to the resource. Permission; when the user identity and permissions are confirmed, the AS generates a token for this authorization.
  • the AS After receiving the authorization request of the AE, the AS first detects whether the authorization request includes a parameter related to the user authentication, and when the message body of the authorization request includes the “user” and “password” parameters, the AS indicates the AE. If the user wants to perform user authentication, the AS obtains the parameter values "user1" of "user” and the parameter value "password1" of "password” from the message body of the authorization request, and searches for the account name in the user information database. User of user1" and verify that its password is equal to "password1".
  • the user information database is a database for storing all user authentication information and access rights in the M2M system, and the user authentication information stored in the user information database is related to the authentication method used by the AS. In this embodiment, the AS uses the traditional The account name and password are used for user authentication. Therefore, the user authentication information stored in the user information database should at least include the user's account name and password, and may also include the user's permission to access the resource.
  • the AS finds the user record whose account name is "user1" and the password is equal to "password1" in the user information database, further determines whether the URI of the accessed resource, that is, "/CSE0003/resource1" is within the access authority of the user,
  • the specific permission representation is related to the M2M system rights management mode.
  • the user rights information is assumed to be a list of accessible resources in the user information database, and the accessible resource list includes all resources that the user has access to. URI.
  • the AS grants the current authorization request, and generates a corresponding access token (token) for the authorization request, the token The way to generate is determined by AS itself.
  • Step 624 The authorization server sends an authorization binding request to the resource server, where the authorization binding request includes an AE-ID1, a token, and a URI of the accessed resource.
  • the AS After the AS generates a token for the AE authorization request, the AS sends an authorization binding request to the H-CSE, so that the H-CSE binds the authorization information to the corresponding resource, where the authorization binding request includes AE-ID1, token, and The URI of the resource being accessed.
  • the authorization binding request sent by the AS to the H-CSE may be:
  • the URL of the PUT request indicates the URI of the accessed resource that needs to be updated, that is, "/CSE0003/resource1", and the "From” part indicates the identifier of the access device, that is, “/CSE0005/CAE0001", and "token” in the HTTP message body.
  • the "2YotnFZFEjr1zCsicMWpAA" section indicates that the specific value of the access token corresponding to the access device and the accessed resource URI is "2YotnFZFEjr1zCsicMWpAA".
  • Step 626 The resource server binds the authorization relationship according to the authorization binding request sent by the authorization server.
  • the H-CSE finds the accessed resource saved on the H-CSE according to the accessed resource URI in the authorization binding request of the AS, and then the AS obtains the access device identifier and the access token from the authorization binding request, and saves the accessed access token.
  • the resource attribute corresponding to the resource is the resource attribute corresponding to the resource.
  • the H-CSE obtains the URI of the accessed resource from the authorization binding request, for example, obtains the URI of the accessed resource from the URL of the PUT request. /CSE0003/resource1", and find the accessed resource in the resource saved locally by H-CSE.
  • the H-CSE obtains the AE-ID1 of the access device and the corresponding token from the authorization binding request, for example, obtains AE-ID1 or "/CSE0005/CAE0001" from the "From" parameter of the HTTP header field of the PUT request, And obtain the access token "2YotnFZFEjr1zCsicMWpAA" from the "token” parameter of the HTTP message body. Then, H-CSE saves the above AE-ID and token to the Access the resource attribute corresponding to the resource.
  • the attribute accessControlPolicyIDs corresponding to the access control policy (ACP) is defined only for the resource object, and the corresponding resource attribute is not defined for the token-based authorization schema.
  • Table 7 provides a possible authorization relationship binding method: adding the authorization relationship attribute authzRel to the common attribute of the resource to indicate an authorization relationship bound to the resource.
  • each resource attribute may contain several authzRel attributes, indicating several authorization relationships bound to the resource, and each authzRel resource is represented as a dual group resource, which includes the subjectID ( Access device ID) and authzProof (access token) two properties.
  • the H-CSE After the H-CSE obtains the AE-ID1 and token parameters in the authorization binding request, construct an ⁇ authzRel> resource instance authzRel1, so that the subjectID attribute value of authzRel1 is equal to "/CSE0005/CAE0001", and the authzProof attribute value is equal to "2YotnFZFEjr1zCsicMWpAA" Then, add the authzRel1 resource to the attribute of Resource1 to complete the binding of the authorization relationship.
  • Step 628 After the resource server completes the binding of the authorization relationship, the authorization binding response is returned to the AS.
  • the authorization binding response returned by the H-CSE to the AS may be:
  • the status code of the HTTP response is "200", indicating that the authorization relationship is successfully bound.
  • Step 630 After the authorization server receives the authorization binding response sent by the resource server, the authorization server returns an authorization response to the AE, where the authorization response includes a token, a URI of the accessed resource, and a signature request flag bit.
  • the AS when the AS receives the authorization binding response of the H-CSE, the AS returns the authorization to the AE. Should be able to be:
  • the status code of the HTTP response is "202", indicating that the authorization request has been granted, but further information is needed and waiting for subsequent processing.
  • the "token”: “2YotnFZFEjr1zCsicMWpAA”” part indicates the access token generated in this authorization, and the AE can use the token to access the corresponding resource next time;
  • "res_uri”: “/CSE0003/resource1”” Indicates that the current authorization response is for "/CSE0003/resource1", and the token is also used for accessing the resource.
  • the res_uri parameter is mainly for the case that the AS simultaneously processes multiple authorization requests initiated by the AE, and the res_uri parameter It is used to enable the AE to distinguish different authorization response messages;
  • the "SigReq": "1" part is a signature request flag bit, indicating that the AE is required to further provide the token signature data to save the verification information associated with the current authorization on the AS side. signature.
  • Step 632 The AE saves the access token and signs the access token by using the device factory key
  • the AE After the AE receives the authorization response of the AS, the AE first obtains the token and the URI of the accessed resource from the authorization response, and saves the binding locally; then, the AE detects that the authorization response includes the signature request flag. Bit, the token received is signed using the device factory key.
  • the AE After the AE receives the authorization response of the AS, the AE first obtains the token and the URI of the accessed resource from the authorization response, that is, obtains the access token “2YotnFZFEjr1zCsicMWpAA” from the “token” parameter of the HTTP response message body, Obtain the URI of the accessed resource from the "res_uri” parameter, which is "/CSE0003/resource1", and save the above two bindings locally.
  • the save method can be implemented using the access token mapping table, or saved in other ways.
  • the storage method used in the specific implementation does not affect the solution of the present invention.
  • the AE end uses an access token mapping table to store the correspondence between the accessed resource URI and the token, as shown in Table 8 below. Each line represents an authorization that the AE has acquired:
  • the AE detects whether the signature request flag bit "SigReq" is included in the authorization response.
  • the authorization response includes the "SigReq” parameter and its value is "1”
  • the AE uses a certain budget signature algorithm and the device's factory key.
  • the token is signed, and the signature algorithm may be a general signature algorithm such as MAC or HMAC. Which signature algorithm is used in the specific implementation has no effect on the scheme of the present invention. In this embodiment, it is assumed that the AE adopts the MAC signature algorithm, and the signature calculated for the token is "8456B1CD".
  • Step 634 After the AE completes the token signature, the AE initiates a signature binding request to the authorization server, the request including the AE-ID1, the token, the token signature, and the URI of the accessed resource.
  • the AE's signature binding request to the AS may be:
  • the URL address of the PUT request that is, "http://authzserver.things.com/dynamicauthz” is the dynamic authorization port of the AS, and the "From” part indicates the access device identifier of the signature binding request, and the HTTP message body.
  • the token” and “token_sig” parameters respectively represent the token and token signatures that need to be signed and bound.
  • Step 636 After receiving the signature binding request of the AE, the authorization server generates a corresponding authorization relationship and saves it in the authorization relationship mapping table.
  • the AS after receiving the signature binding request of the AE, the AS first generates an authorization relationship for the authorization, where the authorization relationship at least includes the access device identifier, the token, the token signature, and the accessed resource URI, and then the AS will describe the The generated authorization relationship is added to the authorization relationship mapping table.
  • Authorization The relationship mapping table structure can be as shown in Table 9:
  • Token Token signature Accessed resource URI /CSE0003/CAE0002 czZCaGRSa3F0MzpnWDFmQmF0M2JW 7432A8D9 /CSE0002/resource3 /CSE0005/CAE0001 2YotnFZFEjr1zCsicMWpAA 8456B1CD /CSE0003/resource1
  • each row in the table represents an authorization relationship.
  • the AS After the AS receives the signature binding request from the AE, the AS obtains the value of the corresponding parameter from the signature binding request of the AE and adds it to the corresponding authorization relationship.
  • the AS generates a corresponding authorization relationship and adds it to the authorization relationship mapping table, as shown in the second record in Table 9.
  • the above-mentioned authorization relationship mapping table may be maintained by a general database inside the AS or as a RESTful resource AuthzRelMapTable.
  • the AuthzRelMapTable resource can be represented as shown in the following figure:
  • the AuthzRelMapTable is an authorization relationship mapping table resource, and the resource includes a plurality of authorization relationship attributes, that is, an authzRecord resource; the authzRecord is an authorization relationship resource, and the resource includes the following attributes:
  • subjectID corresponding to the access device identifier in Table 9;
  • Token corresponds to the token attribute in Table 9;
  • Token_sig corresponds to the token signature attribute in Table 9;
  • Res_uri Corresponds to the accessed resource URI attribute in Table 9.
  • Step 538 The authorization server returns a signature binding response to the AE.
  • the signature binding response returned by the AS to the AE may be:
  • the status code of the HTTP response is "200", indicating that the signature binding request has been completed, and the AE can use the token to access the corresponding resource.
  • the resource server when the resource server determines that the resource access request is received, the resource server responds with the URI of the authorization server, and the access device requests the authorization server for the authentication and authorization. .
  • the authorization server verifies that the user authentication information is valid and generates an access token.
  • the authorization server sends the access device identifier, the accessed resource URI, and the generated access token to the resource server, so that the resource server generates a corresponding authorization relationship.
  • the authorization server sends the generated access token and the accessed resource URI to the AE, and requests the AE to sign the access token.
  • the AE saves the correspondence between the accessed resource URI and the access token.
  • the authorization server saves the correspondence between the access device identifier, the accessed resource URI, the access token, and the signature of the access token into the authorization relationship mapping table.
  • the resource server may locally exist the accessed resource URI and the authorization relationship corresponding to the access token, but the access device identifier in the authorization relationship does not match. Determines that the access device identity may change, triggering the authorization update process.
  • FIG. 7 is a flowchart of an authorization update based on an Oauth authorization architecture according to the present invention.
  • the new registration server R-CSE2 may assign a new identification AE to the AE. -ID2, which invalidates the existing authorization relationship in the M2M system.
  • the method described in FIG. 7 provides a method for updating an authorization relationship after a change in an access identifier, including:
  • Step 702 - Step 704 The AE initiates a registration request to the registration server 2 (R-CSE 2), and the registration server 2 assigns an identifier AE-ID2 to the AE.
  • Step 706 The AE locally finds the token corresponding to the resource according to the accessed resource URI, and A resource access request is sent to the resource server (H-CSE), and the resource access request includes an AE-ID2, the accessed resource URI, and a token corresponding to the accessed resource URI.
  • H-CSE resource server
  • the AE saves the correspondence between the accessed resource URI and the access token.
  • the AE first finds the corresponding token from the locally stored authorization information according to the accessed resource URI, and then the AE sends a resource access request to the H-CSE.
  • Step 708 The resource server receives the resource access request sent by the AE, and performs an access control decision.
  • the resource server stores the authorized relationship of the accessed resource URI, AE-ID1, and the corresponding access token.
  • the H-CSE parses the resource access request and acquires the accessed resource URI, AE-ID2, and token.
  • the H-CSE determines that the accessed resource exists locally, and the H-CSE searches for the authzProof attribute value in the authorized relationship attribute (authzRel) of the accessed resource is the same as the token, and the subjectID attribute value is different from the AE-ID2,
  • the resource server initiates the authorization update process.
  • Step 710 The resource server returns a resource access response to the AE, where the response includes a redirect response code and a redirect URL that points to an authorized update port of the M2M system authorization server.
  • the H-CSE returns a resource access response to the AE.
  • the resource access response returned by H-CSE to AE can be:
  • the status code of the HTTP response is “302”, indicating that the resource access request of the AE needs to be redirected to the new URL.
  • the "Location” part indicates the redirect URL, which points to the authorized update port of the M2M system authorization server, for example, http://authzserver.things.com/authzupdate is the dynamic authorization port address of the authorization server.
  • Step 712 The AE receives the resource access response of the resource server, and sends an authorization update request to the authorization server (AS), where the address of the authorization update request uses the URL provided by the location parameter of the response.
  • AS authorization server
  • the AE receives the resource access response of the H-CSE and detects the HTTP status code.
  • the status code is “302”
  • the AE sends an authorization update request to the AS.
  • the authorization update request sent by the AE to the AS is:
  • the Location parameter in the redirect response is decomposed into two parts.
  • Information, the "Host" section describes the authorization server address, in this embodiment, "http://authzserver.thnings.com”.
  • the AE may also directly use the GET request to access the redirect URL provided by the Location parameter in the redirect response when sending the authorization update request to the AS, instead of using the Host parameter, for example, the authorization update request may be:
  • Step 714 After receiving the authorization update request of the AE, the authorization server determines that the authorization relationship corresponding to the token in the authorization update request exists locally.
  • the AS first parses the URI of the token and the accessed resource from the query string of the authorization update request, for example, the token is “2YotnFZFEjr1zCsicMWpAA”, and the URI of the accessed resource is "/CSE0003/resource1".
  • the AS searches for the authorization relationship in the "Token” column whose value is “2YotnFZFEjr1zCsicMWpAA” and the value of the "Accessed Resource URI” column is "/CSE0003/resource1" in the locally saved authorization relationship mapping table; when the authorization relationship mapping table is adopted as step 536
  • the RESTful resource AuthzRelMapTable described in Table 10 is implemented, that is, in the genus of AuthzRelMapTable
  • the value of the token is equal to "2YotnFZFEjr1zCsicMWpAA" and res_uri is equal to "/CSE0003/resource1".
  • the AS rejects the AE's authorization update request and returns an authorization update failure response to the AE: HTTP/1.1 404Not Found, where the HTTP response status code is "404", indicating that the AS does not find a corresponding Authorization record; if there is an eligible authorization relationship, the AS responds to the authorization update returned by the AE, requesting the AE to sign the token.
  • Step 716 The authorization server returns an authorization update response to the AE, the response including an HTTP 202 response code, a token, and a signature request flag bit.
  • the AS sends an authorization update response to the AE as:
  • the status code of the HTTP response is "202", indicating that the AS has accepted the authorization update request of the AE, but needs further information and waits for subsequent processing.
  • the "token” in the HTTP message body: "2YotnFZFEjr1zCsicMWpAA” indicates that the authorization relationship corresponding to the token is required to be signed, and the AE needs to sign the authentication information corresponding to the authorization relationship.
  • the authentication information is the token itself.
  • Other information (such as the original AE-ID, etc.) may also be used as the verification information in the specific implementation, depending on the specific implementation manner of the AS authorization update port.
  • the "SigReq”: "1" portion in the HTTP message body is a signature request flag indicating that the AE is required to further provide token signature data to enable the AS to confirm the identity of the AE.
  • Step 718 When the AE detection includes the signature request flag bit in the received resource access response, the received token is signed using the device factory key.
  • the AE receives the resource access response of the H-CSE, when the status code of the HTTP response is detected as “202” and the HTTP message body includes the “SigReq” parameter and the value is “1”, the AE pairs the token. Sign it. .
  • Step 720 After the AE completes the token signature, the AE initiates a signature verification request to the authorization server, the request including the AE-ID2, the token, and the token signature.
  • the AE initiates a signature verification request to the AS as:
  • Step 722 The authorization server obtains the token and the token signature from the signature verification request of the AE, and then searches for the authorization relationship corresponding to the token in the authorization relationship mapping table, and verifies whether the token signature in the signature verification request is related to the token in the authorization relationship. Signature is consistent.
  • the AS when the AS receives the signature verification request of the AE, the AS first parses the token value “2YotnFZFEjr1zCsicMWpAA” and the token signature value “8456B1CD” from the signature verification request of the AE, and then the AS searches in the locally saved authorization relationship mapping table.
  • the "Token” column takes the value equal to the authorization relationship of "2YotnFZFEjr1zCsicMWpAA" and compares whether the "Token Signature" column of the authorization relationship is equal to "8456B1CD”.
  • the AS If the "Token Signature" column of the corresponding authorization record is not equal to "8456B1CD", the AS returns a signature verification failure response to the AE, the response including an HTTP 403 response code, for example: HTTP/1.1 403Forbidden; if the "Token Signature” column is equal to "8456B1CD”
  • the AS updates the authorization relationship, that is, changes the access device identifier AE-ID1 in the authorization relationship corresponding to the token to the current access device identifier AE-ID2.
  • Step 724 The authorization server sends a second authorization update request to the resource server, where the request includes the accessed resource URI, token, and AE-ID2.
  • the authorization update request initiated by the AS to the H-CSE may be:
  • the URL of the PUT request indicates the URI of the accessed resource that needs to be updated, that is, “/CSE0003/resource1”, and the “From” part indicates the new application identifier AE-ID2 of the access device, that is, "/CSE0006/CAE0003", the "token”: "2YotnFZFEjr1zCsicMWpAA" in the HTTP message body indicates that the specific value of the access token corresponding to the access device and the accessed resource URI is "2YotnFZFEjr1zCsicMWpAA".
  • Step 726 After receiving the second authorization update request of the authorization server, the resource server finds the locally saved accessed resource resource1 according to the accessed resource URI, and searches for the authorization record of the access token as a token in the authorization relationship attribute of resource1. Update the access device ID of the authorization record to AE-ID2.
  • the H-CSE After the H-CSE receives the authorization update request of the AS, the H-CSE first obtains the accessed resource URI from the URL part of the authorization update request, that is, “/CSE0003/resource1”, and finds the resource resource1 locally. . Then, the H-CSE parses the value of the token and the AE-ID2 from the "From" header field and the HTTP message body of the authorization update request, that is, the token is "2YotnFZFEjr1zCsicMWpAA" and the AE-ID2 is "/CSE0006/CAE0001", in resource1.
  • the authorization relationship attribute searches for an authorization record whose access token is a token, and updates the access device application identifier of the authorization record to AE-ID2.
  • the H-CSE searches for the authorization record whose authzProof attribute value is equal to "2YotnFZFEjr1zCsicMWpAA" in the authzRel attribute of resource1, and then changes the value of the subjectID attribute corresponding to the authorization record to "/CSE0006/CAE0003".
  • Step 728 After completing the local authorization update, the resource server returns a second authorization update response to the authorization server, the response including the HTTP 200 status code.
  • the H-CSE After the H-CSE completes the local authorization update, the H-CSE returns an authorization update response to the AS:
  • the status code of the HTTP response is “200”, indicating that the H-CSE has completed the authorization update of the corresponding resource.
  • Step 730 The authorization server returns a signature verification response to the AE, where the response includes an HTTP 200 response code.
  • the signature verification response returned by the AS to the AE is:
  • the status code of the HTTP response is "200", indicating that the AS has completed signature verification and the M2M system has completed the authorization update.
  • Step 732 After the AE determines that the M2M system has completed the authorization update, the AE may initiate a resource access request to the H-CSE according to the existing resource access procedure, and obtain the corresponding resource.
  • the resource server triggers the authorization relationship update process, and the M2M system verifies the signature of the authentication information by the access device (token)
  • the signature is used to determine the identity of the access device and update the existing authorization relationship, so that the M2M device can achieve seamless resource access and ensure the business continuity of the M2M system.
  • the authorization server stores the access device identifier, the token, the token signature, and the authorized resource URI corresponding to the authorized resource; An authorization relationship corresponding to the access device identifier, the token, and the accessed resource URI is stored on the server.
  • the resource server denies the access, and redirects the resource access request of the access device to the authorization server for authorization update, and the authorization server verifies according to the verification.
  • the signature of the information that is, the signature of the token, determines the identity of the access device and updates the authorization relationship of the M2M system.
  • the resource server can also verify the identity of the access device, thereby updating the authorization relationship of the M2M system.
  • FIG. 8 is a flowchart of another authorization update based on the Oauth authorization architecture provided by the present invention.
  • Steps 802 to 808 are the same as steps 702-708 in the embodiment of FIG. 7. For related description, refer to the related steps of the embodiment shown in FIG. 7, which will not be described in detail herein.
  • Step 810 The resource server sends a signature data request to the authorization server (AS), where the request includes a token.
  • AS authorization server
  • the signature data request sent by the H-CSE to the authorization server is:
  • Step 812 The authorization server obtains the signature data request in the local authorization relationship mapping table.
  • the token corresponds to the signature in the authorization relationship.
  • the AS after receiving the H-CSE signature data request, the AS first parses the token value from the query string requested by the signature data, for example, “2YotnFZFEjr1zCsicMWpAA”. Then, the AS searches in the locally saved authorization relationship mapping table, searches for the same authorization relationship as the token in the signature data request in the "Token” column, and obtains the "Token signature" value corresponding to the authorization relationship.
  • an authorization relationship with a value equal to "2YotnFZFEjr1zCsicMWpAA” is looked up in the "Token” column, and then the "Token signature" of the authorization relationship, that is, "8456B1CD” is extracted.
  • Step 814 The authorization server returns a signature data response to the resource server, where the signature data response includes a signature of the token;
  • the signature data returned by the AS to the H-CSE is:
  • the status code of the HTTP response is “200”, indicating that the current signature data request has been granted.
  • the "token_sig”: “8456B1CD” section indicates that the requested token signature value is "8456B1CD”.
  • Step 816 The resource server returns a resource access response to the AE, where the response includes a signature request flag bit.
  • the resource access response returned by the H-CSE to the AE may be:
  • the status code of the HTTP response is “202”, indicating that the current resource access request has been processed, but further information is needed and waiting for subsequent processing.
  • the "token”: “2YotnFZFEjr1zCsicMWpAA”” part indicates that the signature data that the AE needs to provide is corresponding to the token.
  • This parameter is mainly for the H-CSE to simultaneously process multiple resource access initiated by the AE. In the case of seeking, this parameter is used to make the AE distinguish different resource access response messages; ""SigReq": "1"” part is a signature request flag bit, indicating that the AE needs to further provide token signature data so that H-CSE can confirm the AE identity of.
  • Step 818 When the AE detects that the received resource access response includes a signature request flag, the device token is used to sign the received token.
  • step 718 This step is the same as step 718. Please refer to the related description of step 718, and details are not described herein again.
  • Step 820 After the AE completes the token signature, the AE initiates a resource access request to the H-CSE, where the request includes the AE-ID2, the token obtained by the initial authorization, the token signature, and the resource URI.
  • the resource access request initiated by the AE to the H-CSE may be:
  • the access token also carries the signature data corresponding to the access token.
  • Step 822 After receiving the resource access request of the AE, the H-CSE obtains the token signature from the resource access request, and determines whether the token signature is the same as the token signature obtained from the authorization server in step 814.
  • the H-CSE After the H-CSE receives the resource access request of the AE, the H-CSE first parses the token signature from the HTTP message body of the resource access request, that is, obtains the value “8456B1CD” corresponding to the “token_sig” parameter. Then, the token signature in the resource access request is compared with the token signature in the signature data response described in step 814. For example, in the embodiment, the values of both are "8456B1CD", and when the two are the same, they are confirmed.
  • the access device AE of the resource access request is the same access device as the AE at the time of initial authorization; if the two are different, the resource server denies access to the device, and the process ends.
  • Step 824 After the resource server confirms that the signature is legal, the H-CSE initiates an authorization update request to the AS, and the request includes a token and an AE-ID2.
  • the authorization update request initiated by the H-CSE to the AS may be:
  • the URL of the PUT request is the authorized update port address of the AS
  • the "From” part indicates the new identifier AE-ID2 of the access device that needs to be authorized to update, that is, " /CSE0006/CAE0003”
  • "token” in the HTTP message body indicates the value of the corresponding token in the authorization relationship to be updated, that is, the value of the token in the authorization relationship to be updated is "2YotnFZFEjr1zCsicMWpAA", which is used by the AS to find the required Updated authorization relationship.
  • Step 828 The authorization server updates the locally saved authorization relationship mapping table.
  • the AS after receiving the authorization update request of the H-CSE, the AS first parses the new identifier of the access device, /CSE0006/CAE0003, from the authorization update request, and the token of the authorization relationship corresponding to the current resource access request.
  • the value is "2YotnFZFEjr1zCsicMWpAA”; then, the AS searches for the authorization relationship of the "Token” column value "2YotnFZFEjr1zCsicMWpAA" in the locally saved authorization relationship mapping table, which is described in Table 9 in step 609.
  • the authorization relationship mapping table is implemented by using the RESTful resource AuthzRelMapTable as described in step 609, the authorization update searches for the authzRecord authorization relationship whose token value is equal to "2YotnFZFEjr1zCsicMWpAA" in the attribute of the AuthzRelMapTable, and updates the subject ID of the authorization record to "/CSE0006/CAE0003".
  • Step 828 After the authorization server completes the update of the authorization relationship mapping table, return an authorization update response to the resource server.
  • the authorization update response returned by the AS to the H-CSE is:
  • the status code of the HTTP response is 200, indicating that the AS has successfully updated the authorization relationship mapping table.
  • Step 830 After the resource server receives the authorization update response of the authorization server, update the authorization relationship associated with the accessed resource.
  • the H-CSE searches for the authorization relationship of the authzProof equal to the token ("2YotnFZFEjr1zCsicMWpAA") in the authzRel attribute of the accessed resource, and updates the value of the subjectID in the authorization relationship to "/CSE0006/CAE0003".
  • Step 832 After the resource server completes the authorization relationship update of the accessed resource association, the resource access response is returned to the AE according to the normal resource access procedure.
  • the resource access response returned by the H-CSE to the AE may be:
  • the status code of the application is "200", indicating that the H-CSE has granted the AE current resource access request, and the HTTP message body contains the resource content requested by the AE.
  • the content of the resource is included in the HTTP message body and is returned to the AE.
  • the specific return format and content are determined according to the type of the accessed resource, which is not limited by the present invention.
  • the resource server triggers the authorization relationship update process, and the M2M system verifies the signature of the authentication information by the access device (token)
  • the signature is used to determine the identity of the access device and update the existing authorization relationship, so that the M2M device can achieve seamless resource access and ensure the business continuity of the M2M system.
  • FIG. 9 is a schematic structural diagram of an authorization server according to an embodiment of the present invention.
  • the system includes: a receiving module 901, a sending module 902, an obtaining module 903, a determining module 904, and an updating module 905, where:
  • the receiving module 901 is configured to receive a first authorization update request sent by the access device, where the first authorization update request includes a first identifier of the access device.
  • the sending module 902 is configured to send a first authorization update response to the access device, where the first authorization update response includes signature request information, where the signature request information instructs the access device to sign the verification information;
  • the receiving module 901 is further configured to receive a signature verification request sent by the access device, where the signature verification request includes a signature of the first identifier, the verification information, and the verification information;
  • the signature of the verification information is generated by the access device using a key to sign the verification information;
  • the obtaining module 903 is configured to obtain the saved first authorization relationship according to the verification information in the signature verification request received by the receiving module.
  • the determining module 904 is configured to determine, according to the signature of the verification information in the received signature verification request and the signature of the verification information saved in the first authorization relationship, that the signature of the verification information in the signature verification request is legal;
  • the updating module 905 is configured to update the first authorization relationship according to the first identifier.
  • the update module is configured to update the first authorization relationship according to the first identifier, specifically: changing a second identifier in the first authorization relationship to the first identifier, where the The second identifier is an identifier used by the access device.
  • the authorization server further includes an initial authorization module, configured to perform initial authorization on the access device to access a resource corresponding to the accessed resource identifier.
  • the signature verification request further includes a signature of the first identifier, where the signature of the first identifier is The access device generates the signature of the first identifier by using the key; the update module 905 is further configured to change the signature of the verification information saved in the first authorization relationship to the first identifier. signature.
  • the initial authorization module is configured to perform initial authorization on the access device to access the resource corresponding to the accessed resource identifier, specifically: sending a resource creation request to the resource server, where the resource creation request includes a preset access control policy And the accessed resource identifier, where the preset access control policy includes the second identifier; receiving a resource creation response sent by the resource server, where the resource creation response indicates that the resource server successfully creates the Accessing a control policy resource and binding the access control policy resource to a resource corresponding to the accessed resource identifier; sending a signature request to the access device, the signature request instructing the access device to the second identifier And performing a signature; receiving a signature response sent by the access device, where the signature response includes a signature of the second identifier, and saving the first authorization relationship, where the first authorization relationship includes the second identifier, the first Corresponding relationship between the signature of the second identifier and the identifier of the accessed resource.
  • the sending module 902 is further configured to: after updating the first authorization relationship according to the first identifier, send a second authorization update request to the resource server, where the second authorization update request includes the a first identifier, the second identifier, and the accessed resource identifier, to facilitate the resource server according to the second identifier and the The accessed resource identifier acquires a locally saved second authorization relationship, and updates the second identifier in the second authorization relationship to the first identifier.
  • the first authorization update request further includes the authorization credential
  • the determining module 904 is further configured to send the first authorization update response to the access device. And determining, according to the authorization credential, the first authorization relationship that includes the authorization credential, and the device identifier bound in the first authorization relationship is not the first identifier.
  • the initial authorization module is configured to perform an initial authorization for the access device to access the resource corresponding to the accessed resource identifier, specifically: receiving an authorization request of the access device, where the authorization request includes the second identifier, The accessed resource identifier and the user agree to the authentication information of the access device accessing the resource; when the user is determined to have the right to access the resource corresponding to the accessed resource identifier according to the authentication information, generate the authorization credential Sending an authorization binding request to the resource server where the resource corresponding to the accessed resource identifier is located, where the authorization binding request includes the second identifier, the authorization credential, and the accessed resource identifier; and receiving the resource An authorization binding response sent by the server, the authorization binding response includes indication information indicating that the binding is successful; and sending an authorization response to the access device, where the authorization response includes the authorization credential, the accessed resource identifier, and the opposite And the indication information that the authorization credential is signed; receiving the signature binding request sent by the access device, The name binding request includes the second identifier
  • the sending module 902 is further configured to: after updating the first authorization relationship according to the first identifier, send a second authorization update request to the resource server, where the second authorization update request includes the a first identifier, the authorization credential, and the accessed resource identifier, so that the resource server acquires the second authorization relationship according to the authorization credential and the accessed resource identifier, and the second authorization relationship
  • the second identifier in the update is the first identifier.
  • FIG. 10 is a diagram showing the structure of an authorization server according to another embodiment of the present invention, for performing the authorization method implemented by the authorization server in the foregoing embodiments of FIG. 2, FIG. 4, FIG. 5, FIG. 6, and FIG. 7, including at least one A processor 1001 (eg, a CPU), at least one network interface 1002 or other communication interface, a memory 1003, and at least one communication bus 1004 for implementing the Connect communication between sets.
  • the processor 1001 is configured to execute an executable program, such as a computer program, stored in the memory 1003.
  • the memory 1003 may include a high speed random access memory (RAM), and may also include a non-volatile memory such as at least one disk memory.
  • the communication connection between the system gateway and at least one other network element is implemented by at least one network interface 1002 (which may be wired or wireless), and may use an Internet, a wide area network, a local network, a metropolitan area network, or the like.
  • the memory 1003 stores a program 10031, and the program 10031 can be executed by the processor 1001.
  • the program includes: receiving a first authorization update request sent by the access device, where the first authorization update request includes the access device a first identifier; sending a first authorization update response to the access device, the first authorization update response includes signature request information, the signature request information instructing the access device to sign the verification information; and receiving the access device to send a signature verification request, the signature verification request including the first identifier, the verification information, and the signature of the verification information; wherein the signature of the verification information is the access device using a key pair to the verification And generating, according to the verification information, acquiring the saved first authorization relationship; determining, according to the signature of the verification information in the received signature verification request and the signature of the verification information saved in the first authorization relationship, The signature of the verification information in the signature verification request is legal; according to the first identifier, The first authorization relationship.
  • FIG. 11 is a schematic structural diagram of a resource server according to an embodiment of the present invention, where the authorization server may
  • the system includes: a receiving module 1101, a determining module 1102, a sending module 1103, and an updating module 1104, where:
  • the receiving module 1101 is configured to receive a first resource access request sent by the access device, where the first resource access request includes the first identifier of the access device, the accessed resource identifier, and an authorization credential;
  • the determining module 1102 is configured to determine, according to the authorization credential, that there is a second authorization relationship that includes the authorization credential and the accessed resource identifier, and the device identifier bound in the second authorization relationship is not the first Identification
  • the sending module 1103 is configured to send a first resource access response to the access device, where the first resource access response includes signature request information, where the signature request information instructs the access device to sign the authorization credential;
  • the receiving module 1101 is further configured to receive a second resource access request sent by the access device, where the second resource access request includes the first identifier, the authorization credential, a signature and an identifier of the authorization credential The accessed resource identifier; wherein the signature of the authorization credential is generated by the access device using a key to sign the authorization credential;
  • the sending module 1103 is further configured to send a signature data request to the authorization server, where the signature data request includes the authorization credential;
  • the receiving module 1101 is further configured to receive a signature data response sent by the authorization server, where the signature data response includes a signature of an authorization credential saved in a first authorization relationship acquired by the authorization server according to the authorization credential;
  • the determining module 1102 is further configured to determine, according to the signature of the authorization credential in the second resource access request and the signature of the authorization credential sent by the authorization server, that the signature of the authorization credential in the second resource access request is legal ;
  • the updating module 1104 is configured to update the second authorization relationship according to the first identifier.
  • the updating module is configured to update the second authorization relationship according to the first identifier, specifically: changing a second identifier in the second authorization relationship to the first identifier, where The second identifier is an identifier used by the access device.
  • the sending module 1103 is further configured to: after updating the second authorization relationship according to the first identifier, send a second resource access response to the access device, where the second resource access response includes the The resource corresponding to the resource identifier being accessed.
  • the receiving module 1101 is further configured to receive an authorization binding request that is sent by the authorization server after the access device accesses the resource corresponding to the accessed resource identifier, where the authorization binding request includes the a second identifier, the authorization credential, and the accessed resource identifier; the resource server further includes a storage module, configured to save the correspondence between the second identifier, the authorization credential, and the accessed resource identifier For the second authorization relationship.
  • FIG. 12 is a diagram showing the structure of a resource server according to another embodiment of the present invention, for performing the resource server implementation authorization method in the foregoing embodiments of FIG. 3, FIG. 6, and FIG. 8, including at least one processor 1201 (for example, a CPU) At least one network interface 1202 or other communication interface, memory 1203, and at least one communication bus 1204 are used to effect connection communication between these devices.
  • the processor 1201 is configured to execute an executable program, such as a computer program, stored in the memory 1203.
  • Memory 1203 may include high speed random access memory (RAM: Random) Access Memory) may also include non-volatile memory, such as at least one disk storage.
  • the communication connection between the system gateway and at least one other network element is implemented by at least one network interface 1202 (which may be wired or wireless), and may use an Internet, a wide area network, a local network, a metropolitan area network, or the like.
  • the memory 1203 stores a program 12031, and the program 12031 can be executed by the processor 1201.
  • the program includes: receiving a first resource access request sent by the access device, where the first resource access request includes the access device a first identifier, a accessed resource identifier, and an authorization credential; determining, according to the authorization credential, a second authorization relationship including the authorization credential and the accessed resource identifier, and the binding bound in the second authorization relationship
  • the device identifier is not the first identifier;
  • the first resource access response is sent to the access device, the first resource access response includes signature request information, and the signature request information indicates that the access device signs the authorization credential
  • the signature of the authorization credential is generated by the access device using the key to sign the authorization credential Sending a signature data request to the authorization server,
  • the content is based on the same concept as the method embodiment of the present invention.
  • the description in the method embodiment of the present invention and details are not described herein again.
  • the sequence may be stored in a computer readable storage medium, which, when executed, may include the flow of an embodiment of the methods described above.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Abstract

本发明涉及一种授权方法和设备。公开了授权服务器接收包括访问设备第一标识的授权更新请求；向访问设备发送包括签名请求信息的授权更新响应，该签名请求信息指示访问设备对验证信息进行签名；接收访问设备发送的签名验证请求，签名验证请求中包括第一标识、验证信息和验证信息的签名；验证信息的签名为访问设备对验证信息进行签名生成；根据验证信息，获取保存的授权关系；确定所述签名验证请求中的验证信息的签名合法；根据第一标识，更新授权关系。通过本发明方法，当访问设备在M2M系统中的标识发生变化时，M2M系统可以通过判断验证信息的签名是否合法，来识别访问设备的身份，进而更新已有的授权关系，使得访问设备能够继续使用已有的授权关系。

Description

一种处理授权的方法和设备 技术领域
本发明涉及机器通信技术领域，尤其涉及一种处理授权的方法和设备。
背景技术
机器通信(Machine-to-Machine Communications,M2M)是一种以机器智能交互为核心的、网络化的应用与服务。它通过在机器内部嵌入无线或有线通信模块以及应用处理逻辑，实现用户对监控、指挥调度、数据采集和测量等方面的信息化需求。M2M系统中，各种M2M设备，如各种传感器，直接经过M2M网关接入到M2M业务平台，从而实现各种M2M业务。例如电力抄表、智能家居等。通过M2M业务平台所提供的业务能力，可以获取M2M设备采集的数据，或对M2M设备进行控制和管理。
在现有的M2M规范中，采用RESTful(Representational State Transfer)的架构，任何M2M设备、M2M网关或M2M业务平台以及它们所提供的业务能力，都可以被抽象为资源并且具有唯一的资源标识，即URI(Uniform Resource Identifier)。每个被访问资源都可以设置相应的访问权限，通过引用一个访问控制策略资源,如ACP(accessControlPolicy)资源等来实现系统中对被访问资源的访问控制功能。
被访问资源所属的设备收到访问设备对资源的请求消息时，根据该被访问资源的访问控制策略标识accessControlPolicyID去获取相应的访问控制策略资源，访问控制策略资源中的每一条访问控制规则都可以看作一个三元组，<accessControlOriginators、accessControlContexts、accessControlOperations>，其中accessControlOriginator表示具有操作权限的访问设备标识(可能是某个CSE-ID、AE-ID或者是serviceProvider domain，也可能是All)；accessControlOperations表示该条规则所允许的操作权限(可能包括Retrieve、Create、Update、Delete、Discovery和Notify中的一个或者多个)；accessControlContexts是可选的，定义了accessControlOriginator具有accessControlOperations中规定的操作权限的条件，例如在某个时间范围内，每个地理区域内等等。作为一种可选方式，accessControlContexts的取值可以为空，即不对操作权限的条件进行限制和描述。被访问资源所属的设备根据获 取到的访问控制策略资源中的accessControlOriginator属性中是否包含访问设备标识，以及accessControlOperations属性中是否包含访问设备对被访问资源请求的操作来判断访问设备是否具有对被访问资源的访问权限。只有两个条件都满足时才表示访问设备通过了访问控制权限检查。
在oneM2M系统中，访问设备标识用来标识访问设备的身份。具体的，访问设备可以是应用实体(Application Entity，AE)或者公共服务实体(Common Service Entity，CSE)。访问设备标识由访问设备注册的公共服务实体，即Registrar CSE(下文中统称注册服务器)，进行分配。现有技术中，当同一个访问设备在不同的注册服务器上注册或者其他原因，导致其被分配的访问设备标识发生变化时，该访问设备将无法使用M2M系统中原先为该访问设备配置的访问控制策略。以AE为例，当某AE在CSE1上注册本地ID时被分配了AE-ID1；当该AE离线后又在CSE2上注册时被分配了AE-ID2。显然此时AE在M2M系统中的标识发生了变化，原有的与AE-ID1相关联的授权关系(如ACP)都对新的AE-ID2无法适用，需要由管理员为AE-ID2重新设定或添加ACP，这极大地影响了M2M设备的业务连续性和用户体验。例如，在一个M2M系统中，某个资源X对应的ACP资源如下表所示：
accessControlOriginators accessControlContexs accessControlOperation
AE-ID1 / Retrieve/Create
由该表可知，访问设备标识AE-ID1对应的访问设备对该资源X拥有Retrieve或者Create的访问权限。但是当该访问设备由于某些原因，如在其他注册服务器上注册时，导致M2M系统分配的访问设备标识变为AE-ID2时，该访问设备将无法适用该ACP资源，进而无法获得对该资源X的Retrieve或者Create的访问权限。
发明内容
本发明提供了一种处理授权的方法和设备，以解决当访问设备的标识发生变化时，该访问设备无法使用原有授权关系的技术问题。
第一方面，本发明提供一种机器通信中处理授权的方法，包括：接收访问设备发送的第一授权更新请求，所述第一授权更新请求包括所述访问设备的 第一标识；向所述访问设备发送第一授权更新响应，所述第一授权更新响应包括签名请求信息，所述签名请求信息指示所述访问设备对验证信息进行签名；接收所述访问设备发送的签名验证请求，所述签名验证请求中包括所述第一标识、所述验证信息和所述验证信息的签名；其中，所述验证信息的签名为所述访问设备使用密钥对所述验证信息进行签名生成的；根据所述验证信息，获取保存的第一授权关系；根据接收到的签名验证请求中的验证信息的签名与所述第一授权关系中保存的验证信息的签名，确定所述签名验证请求中的验证信息的签名合法；根据所述第一标识，更新所述第一授权关系。
结合第一方面，在第一方面的第一种可能的实现方式中，在所述接收访问设备发送的第一授权更新请求之前，所述方法还包括：资源服务器接收所述访问设备发送资源访问请求，所述资源访问请求包括所述第一标识和被访问资源标识；所述资源服务器根据所述第一标识和所述被访问资源标识，确定所述访问设备没有访问所述被访问资源标识对应的资源的权限；所述资源服务器拒绝所述访问设备的对所述被访问资源标识对应的资源的访问请求，并向所述访问设备发送包括重定向地址的资源访问响应，其中所述重定向地址为授权服务器的授权更新端口地址，以便于所述访问设备根据所述授权更新端口地址，向所述授权服务器发送所述第一授权更新请求。
结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，所述根据所述第一标识，更新所述第一授权关系，具体为：
将所述第一授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
结合第一方面或第一方面的第一种可能的实现方式或第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，在所述接收访问设备发送的第一授权更新请求之前，所述方法还包括：对所述访问设备访问所述被访问资源标识对应的资源进行初始授权。
结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述验证信息为所述访问设备保存的所述第二标识，所述签名验证请求中进一步还包括所述第一标识的签名，其中所述第一标识的签名为所述访问 设备使用所述密钥对所述第一标识进行签名生成的；在所述确定所述签名验证请求中的验证信息的签名合法之后，所述方法进一步还包括：将所述第一授权关系中保存的验证信息的签名更改为所述第一标识的签名。
结合第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，所述对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：向资源服务器发送资源创建请求，所述资源创建请求包括预设的访问控制策略和所述被访问资源标识，其中，所述预设的访问控制策略包括所述第二标识；接收所述资源服务器发送的资源创建响应，所述资源创建响应指示所述资源服务器成功创建所述访问控制策略资源且将所述访问控制策略资源与所述被访问资源标识对应的资源进行绑定；向所述访问设备发送签名请求，所述签名请求指示所述访问设备对所述第二标识进行签名；接收所述访问设备发送的签名响应，所述签名响应包括所述第二标识的签名；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述第二标识的签名和所述被访问资源标识的对应关系。
结合一方面的第二种至第五种可能的实现方式中的任一种实现方式，在第一方面的第六种可能的实现方式中，在所述根据所述第一标识，更新所述第一授权关系之后，所述方法还包括：向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述第二标识和所述被访问资源标识。
结合第一方面的第三种可能的实现方式，在第一方面的第七种可能的实现方式中，所述验证信息为授权凭证，所述第一授权更新请求还包括所述授权凭证，在所述向所述访问设备发送第一授权更新响应之前，所述方法还包括：根据所述授权凭证，确定存在包含所述授权凭证的所述第一授权关系，且所述第一授权关系中绑定的访问设备标识不是所述第一标识。
结合第一方面的第七种可能的实现方式，在第一方面的第八种可能的实现方式中，所述对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：接收所述访问设备的授权请求，所述授权请求包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；当根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限时，生成所述授权凭证；向所述被访问资源标识对应的资源所在的资源服务器 发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；接收所述资源服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名为所述访问设备对所述授权凭证使用所述密钥签名生成的；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系。
结合第一方面的第七种或者第八种可能的实现方式，在第一方面的第九种可能的实现方式中，在所述根据所述第一标识，更新所述第一授权关系之后，所述方法还包括：向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述授权凭证和所述被访问资源标识。
第二方面，提供了一种机器通信中处理授权的方法，包括：接收访问设备发送的第一资源访问请求，所述第一资源访问请求包括所述访问设备的第一标识、被访问资源标识以及授权凭证；根据所述授权凭证，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的访问设备标识不是所述第一标识；向所述访问设备发送第一资源访问响应，所述第一资源访问响应包括签名请求信息，所述签名请求信息指示所述访问设备对所述授权凭证进行签名；接收所述访问设备发送的第二资源访问请求，所述第二资源访问请求中包括所述第一标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识；其中，所述授权凭证的签名为所述访问设备使用密钥对所述授权凭证进行签名生成的；向授权服务器发送签名数据请求，所述签名数据请求包含所述授权凭证；接收所述授权服务器发送的签名数据响应，所述签名数据响应包含所述授权服务器根据所述授权凭证获取的第一授权关系中保存的授权凭证的签名；根据所述第二资源访问请求中的授权凭证的签名与所述授权服务器发送的授权凭证的签名，确定所述第二资源访问请求中的授权凭证的签名合法；根据所述第一标识，更新所述第二授权关系。
结合第二方面，在第二方面的第一种可能的实现方式中，在所述根据所述 第一标识，更新所述第二授权关系之后，所述方法还包括：向所述访问设备发送第二资源访问响应，所述第二资源访问响应包括所述被访问资源标识对应的资源。
结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，所述根据所述第一标识，更新所述第二授权关系，具体为：将所述第二授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
结合第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，在所述接收访问设备发送的第一资源访问请求之前，所述方法还包括：所述授权服务器接收所述访问设备发送授权请求，所述授权请求中包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；所述授权服务器根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限，生成所述授权凭证，并向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；所述资源服务器将所述第二标识、所述授权凭证和所述被访问资源标识的对应关系保存为第二授权关系，并向所述授权服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；所述授权服务器向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；所述授权服务器接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名是所述访问设备使用所述密钥对所述授权凭证进行签名生成的；所述授权服务器将所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系保存为第一授权关系。
结合第二方面以及第二方面的第一种至第第三种可能的实现方式中的任一种可能的实现方式，在第二方面的第四种实现方式中，在所述确定所述第二资源访问请求中的授权凭证的签名合法之后，所述方法还包括：向所述授权服务器发送第三授权更新请求，所述第三授权更新请求包括所述授权凭证和所述第一标识；接收所述授权服务器发送的第三授权更新响应，所述第三授权更新 响应包括所述授权服务器授权更新成功的指示信息。
第三方面，还提供了一种机器通信中的授权服务器，包括：接收模块，用于接收访问设备发送的第一授权更新请求，所述第一授权更新请求包括所述访问设备的第一标识；发送模块，用于向所述访问设备发送第一授权更新响应，所述第一授权更新响应包括签名请求信息，所述签名请求信息指示所述访问设备对验证信息进行签名；所述接收模块，还用于接收所述访问设备发送的签名验证请求，所述签名验证请求中包括所述第一标识、所述验证信息和所述验证信息的签名；其中，所述验证信息的签名为所述访问设备使用密钥对所述验证信息进行签名生成的；获取模块，用于根据所述接收模块接收到的签名验证请求中的验证信息，获取保存的第一授权关系；确定模块，用于根据接收到的签名验证请求中的验证信息的签名与所述第一授权关系中保存的验证信息的签名，确定所述签名验证请求中的验证信息的签名合法；更新模块，用于根据所述第一标识，更新所述第一授权关系。
结合第三方面，在第三方面的第一种可能的实现方式中，所述更新模块用于根据所述第一标识，更新所述第一授权关系，具体为：将所述第一授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
结合第三方面或第三方面的第一种可能的实现方式，在第三方面的第二种可能的实现方式中，所述授权服务器还包括：初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权。
结合第三方面的第二种可能的实现方式，在第三方面的第三种可能的实现方式中，所述验证信息为所述访问设备保存的所述第二标识，所述签名验证请求中进一步还包括所述第一标识的签名，其中所述第一标识的签名为所述访问设备使用所述密钥对所述第一标识进行签名生成的；所述更新模块，还用于将所述第一授权关系中保存的验证信息的签名更改为所述第一标识的签名。
结合第三方面的第三种可能的实现方式，在第三方面的第四种可能的实现方式中，所述初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：向资源服务器发送资源创建请求，所述资源创建请求包括预设的访问控制策略和所述被访问资源标识，其中，所述预设的 访问控制策略包括所述第二标识；接收所述资源服务器发送的资源创建响应，所述资源创建响应指示所述资源服务器成功创建所述访问控制策略资源且将所述访问控制策略资源与所述被访问资源标识对应的资源进行绑定；向所述访问设备发送签名请求，所述签名请求指示所述访问设备对所述第二标识进行签名；接收所述访问设备发送的签名响应，所述签名响应包括所述第二标识的签名；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述第二标识的签名和所述被访问资源标识的对应关系。
结合三方面的第一种至第四种可能的实现方式中的任一种实现方式，在第三方面的第五种可能的实现方式中，所述发送模块，还用于在根据所述第一标识，更新所述第一授权关系之后，向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识和所述被访问资源标识。
结合第三方面的第二种可能的实现方式，在第三方面的第六种可能的实现方式中，所述验证信息为授权凭证，所述第一授权更新请求还包括所述授权凭证，所述确定模块，还用于在所述向所述访问设备发送第一授权更新响应之前，根据所述授权凭证，确定存在包含所述授权凭证的所述第一授权关系，且所述第一授权关系中绑定的设备标识不是所述第一标识。
结合第三方面的第六种可能的实现方式，在第三方面的第七种可能的实现方式中，所述初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：接收所述访问设备的授权请求，所述授权请求包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；当根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限时，生成所述授权凭证；向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；接收所述资源服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名为所述访问设备对所述授权凭证使用 所述密钥签名生成的；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系。
结合第三方面的第六种或者第七种可能的实现方式，在第三方面的第八种可能的实现方式中，所述发送模块，还用于在根据所述第一标识，更新所述第一授权关系之后，向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述授权凭证和所述被访问资源标识。
第四方面，还提供了一种机器通信中的资源服务器，包括：接收模块，用于接收访问设备发送的第一资源访问请求，所述第一资源访问请求包括所述访问设备的第一标识、被访问资源标识以及授权凭证；确定模块，用于根据所述授权凭证，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的设备标识不是所述第一标识；发送模块，用于向所述访问设备发送第一资源访问响应，所述第一资源访问响应包括签名请求信息，所述签名请求信息指示所述访问设备对所述授权凭证进行签名；所述接收模块，还用于接收所述访问设备发送的第二资源访问请求，所述第二资源访问请求中包括所述第一标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识；其中，所述授权凭证的签名为所述访问设备使用密钥对所述授权凭证进行签名生成的；所述发送模块，还用于向授权服务器发送签名数据请求，所述签名数据请求包含所述授权凭证；所述接收模块，还用于接收所述授权服务器发送的签名数据响应，所述签名数据响应包含所述授权服务器根据所述授权凭证获取的第一授权关系中保存的授权凭证的签名；所述确定模块，还用于根据所述第二资源访问请求中的授权凭证的签名与所述授权服务器发送的授权凭证的签名，确定所述第二资源访问请求中的授权凭证的签名合法；更新模块，用于根据所述第一标识，更新所述第二授权关系。
结合第四方面，在第四方面的第一种可能的实现方式中，所述发送模块还用于，在根据所述第一标识，更新所述第二授权关系之后，向所述访问设备发送第二资源访问响应，所述第二资源访问响应包括所述被访问资源标识对应的资源。
结合第四方面或第四方面的第一种可能的实现方式，在第四方面的第二种可能的实现方式中，所述更新模块，用于根据所述第一标识，更新所述第二授 权关系，具体为：将所述第二授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
结合第四方面的第二种可能的实现方式，在第四方面的第三种可能的实现方式中，所述接收模块，还用于接收授权服务器对所述访问设备访问所述被访问资源标识对应的资源进行初始授权后发送的授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；存储模块，用于将所述第二标识、所述授权凭证和所述被访问资源标识的对应关系保存为第二授权关系。
根据本发明提供的技术方案，当访问设备由于某种原因导致自身在M2M系统中的标识发生变化时，M2M系统可以通过判断验证信息的签名是否合法，即通过比较访问设备发送的验证信息的签名和授权服务器保存的第一授权关系中的验证信息签名是否相同，来识别访问设备的身份，进而更新已有的授权关系，使得访问设备能够继续使用已有的授权关系，进而实现无缝的资源访问，保证了M2M系统的业务连续性。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本本发明一实施例所提供的授权更新的系统框图；
图2为本发明一实施例所提供一种机器通信中授权方法的流程图；
图3为本发明一实施例提供的又一种处理授权的方法的流程图；
图4为本发明一实施例提供的一种基于ACP授权架构的初始授权的流程图；
图5为本发明一实施例提供的一种基于ACP授权架构的授权更新的流程图；
图6为本发明一实施例提供的一种基于Oauth授权架构的初始授权流程图；
图7为本发明一实施例提供的一种基于Oauth授权架构的授权更新流程图；
图8为本发明一实施例提供的另一种基于Oauth授权架构的授权更新流程图；
图9为本发明一实施例提供的一种授权服务器的结构示意图；
图10为本发明一实施例提供的又一种授权服务器的结构示意图；
图11为本发明一实施例提供的一种资源服务器的结构示意图；
图12为本发明一实施例提供的又一种资源服务器的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明具体实施例作进一步的详细描述。为了全面理解本发明，在以下详细描述中提到了众多具体细节。但是本领域技术人员应该理解，本发明可以无需这些具体细节实现。在其他实例中，不详细描述公知的方法、过程、组件和电路等，以免造成实施例不必要地模糊。显然，以下所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
需要说明的是在本发明实施例当中描述的授权服务器和资源服务器的相关功能可以由同一个设备的不同功能模块实现，也可以由不同的设备分别实现，本发明对此不作限定。
此外，在下文描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
图1是依据本发明一实施例所提供的授权更新的系统框图。该系统包含多个通信设备，通过有线或者无线通信网络相互通信。其中，
访问设备102：可以为应用实体(Application Entity，AE)，也可以为公共服务实体(Common Service Entity，CSE)，通过注册服务器104接入M2M系统并能访问M2M系统中其他实体所管理的资源。
注册服务器104：为M2M系统中的访问设备102提供注册服务的公共服 务实体(Registrar CSE，R-CSE)，负责为访问设备102提供注册并为其分配实体标识(Application Entity–Identifier，AE-ID/Common Service Entity–Identifier，CSE-ID)，作为对访问设备的身份标识。
授权服务器106：可以是驻留在基础设施节点(Infrastructure Node，IN)中的公共服务主体(Infrastructure Node–CSE，IN-CSE)，也可以是单独运行并与IN-CSE相连的授权服务器(Authorization Server，AS)，负责保存M2M系统中的授权关系，维护访问设备、访问设备的身份验证信息、验证信息的签名以及被访问资源标识之间的对应关系。
资源服务器108：一般为被访问资源所在节点的公共服务主体(Hosting CSE，H-CSE)，维护本地资源的对应授权关系，并根据访问设备102发送的资源访问请求执行访问控制决策，根据决策结果向访问设备返回资源访问响应。
需要说明的是，本发明中涉及两个授权关系，其中一个由授权服务器维护，称为第一授权关系，另一个由资源服务器维护，称为第二授权关系。此外，本发明还涉及两个访问设备标识，即第一标识和第二标识，其中第二标识为访问设备使用过的标识，并且在授权服务器和资源服务器上维护了与第二标识相关的授权关系，在下面的发明实施例中以AE-ID1标记第二标识；第一标识为访问设备重新注册后获取的标识，在下面的发明实施例中以AE-ID2标记第一标识。当访问设备以第一标识访问资源时，按照现有技术，访问设备的访问请求将被拒绝且访问结束。本发明介绍了一种将所述第一授权关系和第二授权关系中的第二标识更新为第一标识的方法，使得访问设备可以继续使用原有的授权关系获得资源的访问权限。这种方法使得用户通过访问设备可以无缝的访问相应的资源，而不需要重新创建相应的授权关系，这为访问设备访问资源带来很多便利。例如，基于token的授权关系建立，参考Oauth2.0相关协议可知，需要资源所有者进行在线授权，当资源所有者不在线，则M2M系统将无法对访问设备进行重新授权，进而使得用户无法访问资源。
本发明实施例中，在授权服务器106中保存访问设备标识、被访问资源标识、访问设备验证信息以及验证信息的签名对应关系的授权关系。具体的，当为访问设备102初始授权时，该授权服务器106从访问设备102处获取 验证信息的签名并与对应的访问设备标识、验证信息、被访问资源标识一起保存于授权关系中。授权服务器106可在收到访问设备102发送的签名验证请求后确认访问设备102的原身份，也可在收到资源服务器108发送的签名请求时将验证信息的签名发送给资源服务器108，由资源服务器108确认访问设备102的原身份。
资源服务器108为资源所在节点的公共服务实体，该资源服务器108可能驻留在M2M系统中的中间节点(Middle Node，MN)、基础设施节点(Infrastructure Node，IN)或者应用服务节点(Application Service Node，ASN)中。本发明在资源服务器108原有的访问控制决策模块中，新增了授权更新处理的判断逻辑，用于当对访问设备102发送的资源访问请求进行访问控制决策，结果为未许可时，启动本地授权更新或将资源访问请求重定向到授权服务器106以进行授权更新。此外，本发明一个实施例中，资源服务器108从授权服务器106获取验证信息的签名，并从访问设备102处获取对应的验证信息的签名以完成访问设备原身份确认。当完成访问设备102原身份确认后授权服务器106主动更新本地授权关系，或在授权服务器106的指令下更新本地授权关系。
访问设备102可能是应用实体(AE)也可能是公共服务实体(CSE)，并通过注册服务器104接入M2M系统。本发明在访问设备102中新增签名模块，用于在接收到授权服务器106或资源服务器108的签名请求时使用密钥对相应的信息进行签名，并将该信息的签名返回给授权服务器106或资源服务器108。需要说明的是，访问设备进行签名使用的密钥可以是设备出厂设置的，也可以是其他方式生成的，本发明对该密钥的具体形式不做限定。
注册服务器104可能为MN-CSE，也可能为IN-CSE或ASN-CSE，负责给访问设备102分配标识。
此外，需要说明的是，在M2M系统中，资源服务器108和授权服务器106可以作为一个设备中的两个功能模块，也可以作为M2M系统中两个单独运行的设备。当资源服务器108和授权服务器106作为一个设备中的两个功能模块时，资源服务器108和授权服务器106之间的信息交互则作为设备内部信息的交互。本发明对资源服务器108和授权服务器106的具体表现形式不做限定，示范性地，本发明在下面的实施例中将资源服务器108和授权 服务器106作为两个单独运行的设备进行介绍。
图1的授权架构只是给出了访问设备标识变化的一个例子(AE先后在注册服务器R-CSE1和R-CSE2上注册，被分配了不同的AE-ID)，根据访问设备标识分配方式的不同，访问设备标识在其他情况下也可能发生变化(如在同一个注册服务器上注册，但是访问设备的原标识已被分配给其他实体等)。此外，资源服务器108和注册服务器104可能直连到IN-CSE，也可能经其他CSE多跳转接到IN-CSE，本发明对M2M系统的具体结构不做限定。
以下结合附图详细说明本申请涉及的授权方法、装置及系统的实现。
图2为本发明提供的一种机器通信中授权方法的流程图，包括：
步骤202：接收访问设备发送的第一授权更新请求，所述第一授权更新请求包括所述访问设备的第一标识；
可选的，所述第一授权更新请求的目的地址可以为授权服务器的授权更新端口，即所述授权服务器通过所述授权更新端口接收所述访问设备发送的第一授权更新请求。可选的，所述第一授权更新请求还包括被访问资源标识。
步骤204：向所述访问设备发送第一授权更新响应，所述第一授权更新响应包括签名请求信息，所述签名请求信息指示所述访问设备对验证信息进行签名；
可选的，所述签名请求信息可以是一个签名标志位，当签名标志位取值“1”时，表示需要所述访问设备对验证信息进行签名；当签名标志位取值“2”时，表示需要所述访问设备对验证信息以及访问设备的当前标识进行签名。
步骤206：接收所述访问设备发送的签名验证请求，所述签名验证请求中包括所述第一标识、验证信息和所述验证信息的签名；其中，所述验证信息的签名为所述访问设备使用密钥对所述验证信息进行签名生成的；
步骤208：根据所述验证信息，获取保存的第一授权关系；
步骤210：根据接收到的签名验证请求中的验证信息的签名与所述第一授权关系中保存的验证信息的签名，确定所述签名验证请求中的验证信息的签名合法；
具体的，授权服务器获取所述第一授权关系中保存的验证信息的签名，并将所述第一授权关系中保存的验证信息的签名与接收到的签名验证请求中的验证信息的签名进行比较，当两者相同时，则确定所述签名验证请求中的验 证信息的签名合法。
步骤212：根据所述第一标识，更新所述第一授权关系。
具体的，当确定所述签名验证请求中的验证信息的签名合法后，授权服务器确定所述访问设备的标识已经更新为第一标识，所以授权服务器需要对本地保存的与该访问设备相关的授权关系进行更新。
可选的，根据所述第一标识，更新所述第一授权关系，具体为：将所述第一授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识；或者删除所述第一授权关系，并创建一个新的授权关系，所述新的授权关系包括所述第一标识、所述第一授权关系中的验证信息和所述第一授权关系中的验证信息的签名。
具体的，在步骤202之前，所述方法还包括：资源服务器接收所述访问设备发送资源访问请求，所述资源访问请求包括所述第一标识和被访问资源标识；所述资源服务器根据所述第一标识和所述被访问资源标识，确定所述访问设备没有访问所述被访问资源标识对应的资源的权限；所述资源服务器拒绝所述访问设备的对所述被访问资源标识对应的资源的访问请求，并向所述访问设备发送包括重定向地址的资源访问响应，其中所述重定向地址为授权服务器的授权更新端口地址，以便于所述访问设备根据所述授权更新端口地址，向所述授权服务器发送所述第一授权更新请求。
具体的，在所述接收访问设备发送的第一请求消息之前，所述方法还包括：授权服务器对所述访问设备访问所述被访问资源标识对应的资源进行初始授权。
当M2M系统采用ACP授权架构时，所述验证信息可以是所述第二标识。当所述验证信息系为第二标识时，在授权服务器上保存有所述第二标识、所述第二标识的签名以及被访问资源标识相对应的第一授权关系。在资源服务器上保存有所述第二标识和所述被访问资源标识相对应的第二授权关系。具体的，当所述验证信息为所述第二标识时，所述签名验证请求中进一步还包括所述第一标识的签名，其中所述第一标识的签名为所述访问设备使用密钥对所述第一标识进行签名生成的；在步骤210所述确定所述签名验证请求中的验证信息的签名合法之后，所述方法进一步还包括：将所述第一授权关系中保存的验证信息的签名更改为所述第一标识的签名。所述授权服务器对所述访问设备访问所述被 访问资源进行初始授权，具体为：向所述资源服务器发送资源创建请求，所述资源创建请求包括预设的访问控制策略和所述被访问资源标识，其中，所述预设的访问控制策略包括所述第二标识，以便于所述资源服务器根据所述预设的访问控制策略设置访问控制策略资源并将所述访问控制策略资源与所述被访问资源标识对应的资源进行绑定，其中，所述访问控制策略资源包括所述第二标识；接收所述资源服务器发送的资源创建响应，所述资源创建响应指示所述资源服务器成功创建所述访问控制策略资源且将所述访问控制策略资源与所述被访问资源标识对应的资源进行绑定；向所述访问设备发送签名请求，所述签名请求指示所述访问设备对所述第二标识进行签名；接收所述访问设备发送的签名响应，所述签名响应包括所述第二标识的签名；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述第二标识的签名和所述被访问资源标识的对应关系。需要说明的是，管理员在授权服务器上创建预设的访问控制策略的一种可能的实现方式是，访问设备102在注册服务器104上进行注册，生成注册信息，所述注册信息包括注册服务器分配的标识，如所述第二标识，和体现所述访问设备特征的信息，如访问设备的IP地址、MAC地址或者设备描述信息等内容，管理员登录授权服务器后获取所述注册信息，并根据所述注册信息创建访问控制策略，即创建一个允许某个访问设备访问某个资源的规则。进一步的，在步骤212之后，所述方法进一步还包括更新资源服务器上保存的第二授权关系，具体的，在所述根据所述第一标识，更新所述第一授权关系之后，所述方法还包括：向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述第二标识和所述被访问资源标识，以便于资源服务器根据所述第二标识和所述被访问资源标识获取保存的第二授权关系，并将保存的第二授权关系中的第二标识更新为所述第一标识，可选的，授权服务器接收所述资源服务器发送的第二授权更新响应，所述第二授权更新响应指示授权关系更新成功。
需要说明的是，在基于ACP授权架构时，所述验证信息可以由所述授权服务器在接收到访问设备的第一授权更新请求后，通过第一授权更新响应发送给访问设备，或者所述验证信息也可以是保存在访问设备上。示范性的，在本发明的一个实施例中，所述第二标识作为验证信息是保存在访问设备上的，但是本发明对此不作限定。
当M2M系统采用Oauth授权架构时，所述验证信息可以是所述授权凭证。在授权服务器上保存有所述第二标识、所述授权凭证、所述授权凭证的签名以及被访问资源标识相对应的第一授权关系。在资源服务器上保存有所述第二标识、所述授权凭证和所述被访问资源标识相对应的第二授权关系。具体的，当所述验证信息为授权凭证时，所述第一授权更新请求还包括所述授权凭证，在步骤204向所述访问设备发送第一授权更新响应之前，所述方法还包括：根据所述授权凭证，确定存在包含所述授权凭证的所述第一授权关系，且所述第一授权关系中绑定的设备标识不是所述第一标识。
所述对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：接收所述访问设备的授权请求，所述授权请求包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；当根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限时，生成所述授权凭证；向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；接收所述资源服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名为所述访问设备对所述授权凭证使用所述密钥签名生成的；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系。进一步的，在步骤212之后，所述方法进一步还包括更新资源服务器上保存的第二授权关系，具体的，在所述根据所述第一标识，更新所述第一授权关系之后，所述方法还包括：向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述授权凭证和所述被访问资源标识。以便于资源服务器根据所述授权凭证和所述被访问资源标识获取保存的第二授权关系，并将所述第二授权关系中的第二标识更新为所述第一标识，可选的，授权服务器接收所述资源服务器发送的第二授权更新响应，所述第二授权更新响应指示授权关系更新成功。
当资源服务器将保存的第二授权关系中的第二标识更新为所述第一标识 之后，所述访问设备即可使用原有的授权关系，实现资源访问。
本发明实施例提供了一种机器通信系统中处理授权的方法，当访问设备由于某种原因导致自身在M2M系统中的标识发生变化时，M2M系统可以通过判断验证信息的签名是否合法，即通过比较访问设备发送的验证信息的签名和授权服务器保存的第一授权关系中的验证信息签名是否相同，来识别访问设备的身份，进而更新已有的授权关系，使得访问设备能够继续使用已有的授权关系，进而实现无缝的资源访问，保证了M2M系统的业务连续性。
图3为本发明一实施例提供的又一种处理授权的方法的流程图，包括；
步骤302：接收访问设备发送的第一资源访问请求，所述第一资源访问请求包括所述访问设备的第一标识、被访问资源标识以及授权凭证；
步骤304：根据所述授权凭证，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的设备标识不是所述第一标识；
步骤306：向所述访问设备发送第一资源访问响应，所述第一资源访问响应包括签名请求信息，所述签名请求信息指示所述访问设备对所述授权凭证进行签名；
步骤308：接收所述访问设备发送的第二资源访问请求，所述第二资源访问请求中包括所述第一标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识；其中，所述授权凭证的签名为所述访问设备使用密钥对所述授权凭证进行签名生成的；
步骤310：向授权服务器发送签名数据请求，所述签名数据请求包含所述授权凭证；
步骤312：接收所述授权服务器发送的签名数据响应，所述签名数据响应包含所述授权服务器根据所述授权凭证获取的第一授权关系中保存的授权凭证的签名；
步骤314：根据所述第二资源访问请求中的授权凭证的签名与所述授权服务器发送的授权凭证的签名，确定所述第二资源访问请求中的授权凭证的签名合法；
具体的，所述资源服务器比较所述授权服务器发送的授权凭证的签名与所述第二资源访问请求中的授权凭证的签名，当两者相同时，则确定所述第二 资源访问请求中的授权凭证的签名合法。
步骤316：根据所述第一标识，更新所述第二授权关系。
其中，根据所述第一标识，更新所述第二授权关系具体为：将所述第二授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识；或者删除所述第二授权关系，创建一个新的第二授权关系，其中所述新的第二授权关系包括所述第一标识、所述第二授权关系中的授权凭证和所述被访问资源标识。
具体的，在步骤302之前，还存在初始授权流程：所述授权服务器接收所述访问设备发送授权请求，所述授权请求中包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；所述授权服务器根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限，生成所述授权凭证，并向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；所述资源服务器将所述第二标识、所述授权凭证和所述被访问资源标识的对应关系保存为第二授权关系，并向所述授权服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；所述授权服务器向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；所述授权服务器接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名是所述访问设备使用所述密钥对所述授权凭证进行签名生成的；所述授权服务器将所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系保存为第一授权关系。
步骤302中，访问设备向资源服务器发送第一资源访问请求后，资源服务器需要对访问设备的访问请求进行决策。只有资源访问请求中的信息与资源服务器保存的第二授权关系完全匹配时，资源服务器才会允许此次请求，并向访问设备返回请求的资源。具体的，所述资源服务器根据第一资源访问请求，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的设备标识不是所述第一标识，则资源服务器确定访问设备的标识发生变化或者是授权凭证泄露。进一步的，通过步骤306-步骤314，资 源服务器根据从访问设备和授权服务器中获取所述授权凭证的签名，确定所述第一标识和所述第二标识都是所述访问设备的标识，进而主动使用所述第一标识更新保存的第二授权关系。
进一步的，在所述根据所述第一标识，更新所述第二授权关系之后，所述方法还包括：向所述访问设备发送第二资源访问响应，所述第二资源访问响应包括所述被访问资源标识对应的资源。从而访问设备利用原有的授权关系，实现了资源访问的目的。
可选的，在所述确定所述第二资源访问请求中的授权凭证的签名合法之后，所述方法还包括：向所述授权服务器发送第三授权更新请求，所述第三授权更新请求包括所述授权凭证和所述第一标识；接收所述授权服务器发送的第三授权更新响应，所述第三授权更新响应包括所述授权服务器授权更新成功的指示信息。
本发明实施例提供了一种机器通信系统中处理授权的方法，当访问设备由于某种原因导致自身在M2M系统中的标识发生变化时，M2M系统可以通过判断验证信息的签名是否合法，即通过比较访问设备发送的验证信息的签名和授权服务器保存的第一授权关系中的验证信息签名是否相同，来识别访问设备的身份，进而更新已有的授权关系，使得访问设备能够继续使用已有的授权关系，进而实现无缝的资源访问，保证了M2M系统的业务连续性。
以下分别基于ACP授权架构和Oauth授权架构介绍图2、图3所示的授权方法的具体实现过程。
M2M系统采用ACP授权架构对访问设备访问资源进行授权时，所述验证信息可以是所述访问设备的第二标识。具体的，在图4和图5所述的实施例中，将提供一种M2M系统中基于ACP授权架构的授权流程，包括初始授权和授权更新两个子流程，其中所述初始授权是指访问设备标识变化前，授权服务器为访问设备获取验证信息的签名并生成授权关系的过程。
参阅图4，图4为本发明提供的一种基于ACP授权架构的初始授权的流程图，在本实施例中访问设备为一个应用实体AE，但是本发明实施例对访问设备的具体形式并不做限定，所述方法包括：
步骤402-步骤404：AE向注册服务器1(R-CSE1)发送注册请求，注册服务器1为AE分配标识AE-ID1；
步骤406：系统管理员(Admin)在授权服务器(AS)上为AE创建ACP；
具体的，在基于ACP授权架构下，通常Admin手动为AE设置ACP。在M2M系统中，ACP作为资源被创建并与对应的资源进行绑定。所述绑定方式为在对应资源的访问控制策略标识accessControlPolicyIDs属性值中添加该ACP资源标识(ACP ID)。正如背景技术中所介绍，在M2M系统中ACP资源的每一个规则都是一个三元组<accessControlOriginators、accessControlContexts、accessControlOperations>。在本发明实施例中，Admin为AE创建ACP，具体可以为：设置accessControlOriginators参数为“/CSE0005/CAE0001”，其中，/CSE0005/CAE0001即为AE-ID1。其他参数与本发明方案无关，因此本发明实施例不做限定。
步骤408：授权服务器向资源服务器(H-CSE)发送ACP资源创建请求；
所述ACP资源创建请求包含Admin为AE创建的ACP的所有属性数据和对应绑定的资源标识。例如，授权服务器向资源服务器发送的ACP资源创建请求可以为：
POST http://m2m.things.com/CSE0003HTTP/1.1
From：http://authzserver.things.com
Content-type:application/onem2m-resource+json
{“ResourceType”:“accessControlPolicy”,
“privileges.accessControlOriginators”:“/CSE0005/CAE0001”,
“res_uri”:“/CSE0003/resource1”}
其中，“http://m2m.things.com/CSE0003”为该H-CSE的URL(Uniform Resoure Locator)，也是AS想要创建ACP资源的父节点，即该ACP资源是创建在H-CSE的根节点下，在具体实现中AS也可在POST请求的URL中限定所需创建ACP资源的父资源ID，该ACP资源具体创建于哪个资源之下对本发明方案没有影响，本发明不做限定。“From”部分描述资源创建请求的发起者ID，在本实施例中即授权服务器的URL地址“http://authzserver.things.com”。HTTP消息体中包含所述被创建的ACP资源的所有属性，““ResourceType”:“accessControlPolicy””部分表示本次请求所创建的资源类型为ACP，““privileges.accessControlOriginators”:“/CSE0005/CAE0001””部分表示所创建ACP资源适用的访问设备为“/CSE0005/CAE0001”；HTTP消息体中还 应包含被创建ACP资源的其他属性，但由于与本发明方案无关因此在本实施例中并未描述。此外，““res_uri”:“/CSE0003/resource1””部分表示该ACP资源所需绑定的资源URI为“/CSE0003/resource1”，具体实现中所需绑定的资源URI也可以通过其他方式描述(如包含在POST请求的URL中作为查询字符串形式描述)，但其具体描述方式并不影响ACP资源的创建和绑定过程。
步骤410：资源服务器创建ACP资源，并将创建的ACP资源与对应的资源进行绑定；
具体的，在H-CSE收到AS的ACP资源创建请求后，首先从资源创建请求中解析得到该ACP资源的创建位置或父资源ID，然后从HTTP消息体中解析得到所述被创建的ACP资源的各属性取值。例如，本发明实施例中该ACP资源的创建位置是“http://m2m.things.com/CSE0003”，即在H-CSE的根节点下创建该资源；此外，HTTP消息体中的““ResourceType”:“accessControlPolicy””部分表示所创建资源的类型为ACP，““accessControlOriginators”:“/CSE0005/CAE0001””部分则表示该ACP的一个访问控制规则的accessControlOriginators参数取值为“/CSE0005/CAE0001”；在具体实现中ACP资源创建请求的HTTP消息体中可能还包含该ACP资源的其他属性值，H-CSE在创建ACP资源的时候需要一并获取并为所创建的ACP资源的对应属性值赋值。
具体的，在H-CSE完成ACP资源的创建后，H-CSE为该ACP资源分配一个ACP ID并将其设置为ACP资源的资源标识(即resourceID属性)，例如“ACP0001”，该ACP ID在H-CSE范围内唯一标识该ACP资源。然后H-CSE根据ACP资源创建请求中的被绑定资源标识找到对应的资源，即“/CSE0003/resource1”，并在该资源的accessControlPolicyIDs属性值列表中添加所创建ACP资源的ACP ID，即“ACP0001”。
步骤412：资源服务器向授权服务器返回ACP资源创建响应；
具体的，H-CSE向AS返回ACP资源创建响应，该响应包含HTTP 200响应码。例如，所述H-CSE向AS返回的ACP资源创建响应为：
HTTP/1.1 200OK
Content-type:application/onem2m-resource+json
{“resourceID”:“/CSE0003/ACP0001”}
其中，HTTP响应的状态码为“200”，表示H-CSE已完成对应ACP资源的创建和绑定。HTTP消息体中的““resourceID”:“/CSE0003/ACP0001””部分则表示H-CSE为所创建的ACP分配的ACP ID为“/CSE0003/ACP0001”，该ACP ID前添加了H-CSE的CSE ID，以在oneM2M系统中唯一标识该ACP资源。
步骤414：授权服务器确定保存的授权关系映射表中是否存在AE-ID1对应的验证信息的签名；
具体的，AS在保存的授权关系映射表中查询访问设备标识等于AE-ID1的授权关系，若能找到相应的授权关系，并且在该授权关系中保存有相应的验证信息的签名，则完成初始授权；否则进入步骤316，向AE发起签名请求，请求AE对相应的验证信息进行签名。
具体的，所述授权关系映射表中的每一条授权关系，用于保存一个访问设备标识、被访问资源标识、访问设备验证信息以及验证信息的签名。例如，表1记录了一种可能的授权关系映射表的结构：
表1 授权关系映射表
Figure PCTCN2016075488-appb-000001
如表1所示，表中的每一行都表示一个访问设备所对应的授权关系，包含访问设备标识(subjectID)、签名(signature)和被访问资源URI列表(res_uris)。需要说明是，在该授权关系映射表中，访问设备标识同时也作为访问设备的验证信息。所述“签名”栏取值为访问设备使用密钥对相应访问设备标识的签名。从表1的第一行可知，res_uris一栏有两个被访问资源URI，事实上，授权关系映射表中的每一条授权关系都记录保存了一个访问设备的授权情况，显然，同一个访问设备可以获得多个资源的访问权限。
在具体实现中也可对每个访问设备使用其他形式的验证信息，如将随机生成的字符串作为验证信息，并保存各访问设备对该验证信息的签名数值，如表2所示：
表2 授权关系映射表(另一例子)
Figure PCTCN2016075488-appb-000002
如表2所述是对每个访问设备保存随机生成的验证信息(challenge)及其签名的授权关系映射表结构。在具体实现时采用何种信息作为验证信息并不影响本发明的具体方案。在本实施例中假设M2M系统使用如表1所述的授权关系映射表结构，即将访问设备标识作为验证信息。该授权关系映射表在具体实施时，可通过AS内部的一般数据库来进行维护，或者作为一种RESTful资源AuthzRelMapTable进行表述。在基于ACP的授权架构下，该AuthzRelMapTable资源可以表示为如下表3所示的形式：
Figure PCTCN2016075488-appb-000003
表3 授权关系映射表资源及属性
其中，AuthzRelMapTable为授权关系映射表资源，该资源包含若干条授权记录属性，即authzRecord资源，每一个authzRecord资源记录一个访问设备的授权关系，authzRecord资源包含以下属性：
subjectID：对应表1中的访问设备标识属性；
signature：对应表1中的签名属性；
res_uris：对应表1中的被访问资源URI列表属性。
以表1为例，具体的，AS在收到H-CSE的资源创建响应后，首先在授权关系映射表中查找访问设备标识等于AE-ID1的授权关系，即查找“subjectID”栏取值等于“/CSE0005/CAE0001”的授权关系。如果在授权关系映射表中能够找到符合条件的授权关系，且该授权关系的signature属性值不为空，则AS 直接结束初始授权流程；否则，AS发起签名请求流程，执行步骤416。
步骤416：授权服务器向AE发送签名请求；
具体的，AS向AE发起的签名请求可以为：
POST http://m2m.things.com/CSE0005/CAE0001HTTP/1.1
Content-type:application/onem2m-resource+json
{“SigReq”:“1”}
其中，POST部分请求的URL为AE在R-CSE上的URI，R-CSE收到该请求后会将签名请求转发给AE。HTTP消息体中的““SigReq”:“1””部分为一个签名请求标志位，表示需要AE对验证信息进行签名。在本实施例中验证信息即AE-ID1，由于AE本身会保存自己的标识，所以此时不需要在上述签名请求的HTTP消息体中包含验证信息参数；当具体实现时采用其他形式的验证信息时，可在上述签名请求的HTTP消息体中包含对应的验证信息参数。
步骤418：AE使用设备出厂密钥对验证信息进行签名；
具体的，在AE收到AS的签名请求后，首先检测HTTP消息体中是否包含签名请求标志位“SigReq”，当资源访问响应中包含“SigReq”参数且其取值为“1”时，AE使用某种预设的签名算法和设备的出厂密钥对相应的验证信息进行签名。本实施例中，对AE-ID1计算所得的签名为“JYUI7BZO92”。
具体的，AE将此时的AE-ID1与M2M SP ID(M2M Service Provider Identifier)绑定保存在本地，该保存方法可以使用访问设备标识映射表实现，或使用其他的方式保存。具体实现中使用何种保存方法不影响本发明的方案，在本实施例中假设AE端使用一个访问设备标识映射表保存AE-ID和M2M SP ID的对应关系，如表4所示：
表4：访问设备标识映射表
访问设备标识 M2M SP ID
/CSE0005/CAE0001 http://m2m.things.com
SAE2002 http://m2m.example.com
在M2M系统中AE会保存当前被分配的标识，需要说明的是，AE保存当前被分配的标识与这里保存的访问设备标识映射表并不相关。例如，由于某种原因，访问设备重新在新的注册服务器注册获得标识AE-ID11，则访问设备会保存AE-ID11为当前设备标识。但是如果访问设备不以AE-ID11重新申请 授权，则访问设备标识映射表中的访问设备标识不会更新。
步骤420：AE向AS返回签名响应。
具体的，AE向AS返回签名响应。例如，AE向AS返回的签名响应为：
HTTP/1.1 200OK
Content-type:application/onem2m-resource+json
{“signature”:“JYUI7BZO92”}
其中，HTTP响应的状态码为“200”，表示AE已对验证信息进行签名。HTTP消息体中的““signature”:“JYUI7BZO92””部分表示验证信息的签名为“JYUI7BZO92”。
步骤422：授权服务器收到AE的签名响应后，从签名响应中解析得到验证信息的签名，并在授权关系映射表中添加对应的授权关系。
具体的，在AS收到AE的签名响应时，AS首先从所述签名响应的HTTP消息体中解析得到验证信息的签名，即“JYUI7BZO92”；然后AS在授权关系映射表中查找与该AE对应的授权关系，即查找subjectID属性值等于AE-ID1，即“/CSE0005/CAE0001”的授权关系：若找到该授权关系，则将该授权关系的signature属性值赋值为“JYUI7BZO92”；若未找到该授权关系，则构造新的授权关系，并将该授权关系添加到授权关系映射表中。在本发明实施例中，如表1所示，AS的授权关系映射表中不存在与该AE对应的授权关系，所以AS生成新的授权关系，并更新到授权关系映射表中，更新后的授权关系映射表如表5所示，表中第三行数据即是新生成的授权关系。
表5 授权关系映射表
subjectID signature res_uris
/CSE0003/CAE0002 94R3JDFSF0 /CSE0002/resource3,CSE0004/resource2
/CSE0005/CAE0004 FSAF9432J3 /CSE0002/resource5
/CSE0005/CAE0001 JYUI7BZO92 /CSE0003/resource1
参阅图5，图5为本发明提供的一种基于ACP授权架构的授权更新的流程图。当图4所述实施例中的AE由于更改接入地点等原因，导致在不同的注册服务器(如R-CSE2)上注册时，新的注册服务器R-CSE2可能会为AE分配新的标识AE-ID2，从而导致M2M系统中现有的授权关系失效。图5所述 的方法提供了一种当访问标识发生变化后，更新授权关系的方法，包括：
步骤502-步骤504：AE向注册服务器2(R-CSE2)发送注册请求，注册服务器2为AE分配标识AE-ID2；
步骤506：AE向资源服务器(H-CSE)发起资源访问请求，所述资源访问请求中包含AE-ID2和被访问资源的URI。
具体的，AE向H-CSE发送资源访问请求。例如，AE向H-CSE发起的初次资源访问请求为：
GET http://m2m.things.com/CSE0003/resource1？from＝/CSE0005/CAE0001HTTP/1.1
其中，“http://m2m.things.com/CSE0003/resource1”为被访问资源的URI，“from＝/CSE0006/CAE0003”表示访问设备标识，即该AE的AE-ID2。
步骤508：资源服务器(H-CSE)根据访问请求中携带的信息进行访问控制决策；
具体的，在H-CSE收到AE的资源访问请求后，H-CSE首先解析资源访问请求中的被访问资源的URI，即GET请求中的URL地址“/CSE0003/resource1”，并在本地查找对应的资源resource1。然后，H-CSE在资源访问请求中解析得到AE-ID2，即GET请求中的URL查询字符串部分“/CSE0006/CAE0003”；最后，在对应资源resource1的accessControlPolicyIDs属性值中找到与该资源绑定的ACP ID列表，并根据背景技术中所介绍的访问控制决策过程来决策AE是否具有访问资源的权限。本实施例中假设相对于初始授权情况下只有AE的访问设备标识由AE-ID1变为AE-ID2，而其他资源访问相关的属性(如操作、上下文环境等)均与初始授权限定的条件一致。由于Admin在初始授权时为AE预设的ACP中，privileges.accessControlOriginators属性值仅包含AE-ID1，即/CSE0005/CAE0001，因此在访问决策过程中，H-CSE找不到符合AE-ID2，即/CSE0006/CAE0003的ACP，因此访问控制决策的结果是不允许本次资源访问。现有技术中，资源服务器将直接拒绝访问设备的访问请求。从而导致同一个访问设备由于设备标识发生变化，而出现访问资源失败的情况。
步骤510：资源服务器向AE返回资源访问响应，该响应包含HTTP 302响应码以及一个重定向URL，所述重定向URL指向授权服务器的授权更新端 口。
具体的，当H-CSE的访问控制决策为不允许本次资源访问时，H-CSE向AE返回的资源访问响应为：
HTTP/1.1 302Move temporarily
Location:http://authzserver.things.com/authzupdate#from＝/CSE0006/CAE0003&res_uri＝/CSE0003/resource1
其中，HTTP响应的状态码为“302”，表示该AE的资源访问请求需要被重定向到新的URL。“Location:http://authzserver.things.com/authzupdate”表示重定向URL，该重定向URL指向该M2M系统授权服务器的授权更新端口，例如http://authzserver.things.com/authzupdate即为该授权服务器的授权更新端口地址。“#from＝/CSE0006/CAE0003&res_uri＝/CSE0003/resource1”为重定向后的资源访问请求所需要附带的参数信息，包括AE-ID2(即/CSE0006/CAE0003)和被访问资源的URI(即/CSE0003/resource1)，以查询字符串的形式表示。
步骤512：AE收到资源服务器的资源访问响应后，向授权服务器发送授权更新请求，该授权更新请求包括AE-ID2和被访问资源的URI。
具体的，AE收到H-CSE的资源访问响应并检测HTTP状态码，当状态码为“302”时，AE向AS发送授权更新请求。例如，AE向AS发送的授权更新请求可以为：
GET/authzupdate？from＝/CSE0006/CAE0003&res_uri＝CSE0003/resource1HTTP/1.1
Host:http://authzserver.things.com
其中，GET请求的URL地址“/authzupdate？from＝/CSE0006/CAE0003&res_uri＝CSE0003/resource1HTTP/1.1”表示授权服务器的授权更新端口地址以及附带的参数信息，该附带的参数信息包括AE-ID2(即/CSE0006/CAE0003)和被访问资源标识(即/CSE0003/resource1)，“Host”部分则描述了授权服务器地址”。
步骤514：授权服务器收到AE授权更新请求后，向AE返回授权更新响应，该响应包含HTTP 202响应码和签名请求标志位。
具体的，当AS收到AE授权更新请求后，AS向AE返回的授权更新响应为：
HTTP/1.1 202Accepted
Content-type:application/onem2m-resource+json
{“SigReq”:“2”}
其中，HTTP响应的状态码为“202”，表示AS已接受了AE的授权更新请求，但需要进一步的信息并等待后续处理。HTTP消息体中的““SigReq”:“2””部分为一个签名请求标志位，表示需要AE对验证信息和访问设备的当前标识进行签名。在本实施例中，所述验证信息即AE在初始授权时的访问设备标识AE-ID1，即/CSE0005/CAE0001，访问设备的当前标识即AE-ID2，/CSE0006/CAE0003。
步骤516：AE使用设备出厂密钥对验证信息进行签名，并对访问设备的当前标识AE-ID2进行签名；
具体的，在AE收到H-CSE的授权更新响应后，当检测得到HTTP响应的状态码为“202”和HTTP消息体中包含“SigReq”参数且取值为“2”时，AE对本地保存的AE-ID1进行签名。本实施例中，所述AE-ID1在本地以访问设备标识映射表的形式保存，如表4所述，AE根据当前接入的M2M系统标识(即M2M SP ID，本实施例中为“http://m2m.things.com”)在该访问设备标识映射表中找到对应的访问设备标识AE-ID1：/CSE0005/CAE0001，在实施例中，AE-ID1/CSE0005/CAE0001即为相应的验证信息。
具体的，在AE查找到本地保存的AE-ID1后，AE对AE-ID1和AE-ID2进行签名。本实施例中，对AE-ID1进行签名得到“JYUI7BZO92”，对AE-ID2进行签名得到“M6UI7B2OKQ”。然后，将AE-ID2更新到本地保存的访问设备标识映射表中，代替原来AE-ID1，即在表4中用“/CSE0006/CAE0003”替换“/CSE0005/CAE0001”，得到如表5所示的更新的访问设备标识映射表。
表5：访问设备标识映射表
访问设备标识 M2M SP ID
/CSE0006/CAE0003 http://m2m.things.com
SAE2002 http://m2m.example.com
步骤518：AE向授权服务器发送签名验证请求；
在AE完成签名后，AE向AS发起签名验证请求，该请求包含AE-ID1、 AE-ID1的签名、AE-ID2、AE-ID2的签名。
具体的，AE向AS发起的签名验证请求为：
PUT http://authzserver.things.com/authzupdate HTTP/1.1
Content-type:application/onem2m-resource+json
{“aeid_ori”:“/CSE0005/CAE0001”,“sig_ori”:“JYUI7BZO92”
“aeid_now”:“/CSE0006/CAE0003”,“sig_now”:“M6UI7B2OKQ”}
其中，HTTP响应的状态码为“200”，表示AE已对验证信息进行签名。HTTP消息体中的““aeid_ori”:“/CSE0005/CAE0001””表示初始授权时的访问设备标识AE-ID1为“/CSE0005/CAE0001”，““sig_ori”:“JYUI7BZO92””表示初始授权时的访问设备标识AE-ID1的签名为“JYUI7BZO92”；““aeid_now”:“/CSE0006/CAE0003””部分表示当前该AE的访问设备标识AE-ID2为“/CSE0006/CAE0003”，““sig_now”:“M6UI7B2OKQ””部分表示当前该AE的访问设备标识AE-ID2的签名为“M6UI7B2OKQ”。
步骤520：AS验证签名验证请求中的签名，确定是否更新授权关系映射表；
在AS收到AE的签名验证请求后，AS在授权关系映射表中查找访问设备标识为AE-ID1的授权关系，比较签名验证请求中的AE-ID1签名和该授权关系中的签名是否一致，并进一步为AE进行授权更新或拒绝授权更新请求。
具体的，在AS收到AE的签名验证请求后，AS首先从签名验证请求中解析得到AE-ID1、AE-ID1签名、AE-ID2和AE-ID2签名，然后，AS在授权关系映射表中查找subjectID属性值为AE-ID1(即“/CSE0005/CAE0001”)的授权关系，并验证该授权关系中的signature属性值是否与AE-ID1签名(即“JYUI7BZO92”)相同。如果对应授权关系中的signature属性值与AE-ID1的签名不相同，则授权服务器拒绝AE的签名验证请求并返回签名验证响应，例如：HTTP/1.1 403Forbidden，授权更新流程结束；如果对应授权关系中的signature属性值与AE-ID1的签名相同，则允许AE此次授权更新并将该授权关系中的subjectID属性值更新为AE-ID2(即“/CSE0006/CAE0003”)，同时将signature属性值更新为AE-ID2的签名(即“M6UI7B2OKQ”)，本发明实施中，显然签名验证通过，AS更新授权关系映射表，如表6所示：
表6 授权关系映射表
subjectID signature res_uris
/CSE0003/CAE0002 94R3JDFSF0 /CSE0002/resource3,/CSE0004/resource2
/CSE0005/CAE0004 FSAF9432J3 /CSE0002/resource5
/CSE0006/CAE0003 M6UI7B2OKQ /CSE0003/resource1
步骤522：授权服务器向资源服务器发送授权更新请求；
当AS允许AE的授权更新后，AS向H-CSE发起授权更新请求，该请求包含被访问资源URI、AE-ID1和AE-ID2。
具体的，授权更新请求可以为：
PUT http://m2m.things.com/CSE0003/resource1HTTP/1.1
From:http://authzserver.things.com
Content-type:application/onem2m-resource+json
{“aeid_ori”:“/CSE0005/CAE0001”,
“aeid_now”:“/CSE0006/CAE0001”}
其中，“/CSE0003/resource1”为被访问资源的URI，HTTP消息体中的““aeid_ori”:“/CSE0005/CAE0001””表示原访问设备标识AE-ID1为“/CSE0005/CAE0001”，““aeid_now”:“/CSE0006/CAE0001””表示访问设备的当前标识AE-ID2为“/CSE0006/CAE0003”。
步骤524：资源服务器更新授权关系；
在H-CSE收到AS的授权更新请求后，H-CSE根据被访问资源的URI找到的对应资源，并更新该资源关联的授权关系。
具体的，在H-CSE收到AS的授权更新请求后，首先从授权更新请求中解析得到被访问资源的URI，即“/CSE0003/resource1”，并在本地查找到对应资源；其次，从授权更新请求的HTTP消息体中解析得到AE-ID1(即“/CSE0005/CAE0001”)和AE-ID2(即“/CSE0006/CAE0003”)；然后，在对应资源resource1的accessControlPolicyIDs属性中找到所有与该资源关联的ACP ID列表，并在这些ACP中查找privileges.accessControlOriginators属性值包含“/CSE0005/CAE0001”的ACP资源，并将所述ACP资源中的privileges.accessControlOriginators属性值更新为“/CSE0006/CAE0003”。
步骤526：资源服务器向授权服务器发送授权更新响应；
在H-CSE完成授权更新后，H-CSE向AS返回授权更新响应。具体的，在H-CSE完成授权更新后，H-CSE向AS返回的授权更新响应为：
HTTP/1.1 200OK
其中，HTTP响应的状态码为“200”，表示H-CSE已完成对应ACP资源的更新。
步骤528：授权服务器向AE发送签名验证响应；
在AS收到H-CSE的授权更新响应后，AS向AE返回签名验证响应。
具体的，在AS收到H-CSE的授权更新响应后，AS向AE返回的签名验证响应为：
HTTP/1.1 200OK
其中，HTTP响应的状态码为“200”，表示AS已完成AE所请求的授权更新。
当AE接收到授权服务器发送的签名验证响应后，表明M2M系统已经完成授权关系的更新，此时AE可以使用AE-ID2的访问设备标识对被访问资源/CSE0003/resource1进行访问。
本实施例中，当M2M系统中的M2M设备，如AE，在标识发生变化后，访问被访问资源时，资源服务器触发授权关系更新流程，M2M系统通过验证访问设备对验证信息的签名来确定访问设备的身份，并更新已有的授权关系，使得M2M设备能够实现无缝的资源访问，保证了M2M系统的业务连续性。
M2M系统采用Oauth授权架构对访问设备访问资源进行授权时，所述验证信息可以授权服务器生成的访问令牌。具体的，在图6和图7所述的实施例中，将提供一种M2M系统中基于Oauth授权架构的授权流程，包括初始授权和授权更新两个流程，其中所述初始授权是指访问设备标识变化前，授权服务器为访问设备获取身份验证信息并生成授权关系的过程。
参阅图6，图6为本发明提供的一种基于Oauth授权架构的初始授权的流程图，在本实施例中访问设备为一个应用实体AE，但是本发明实施例对访问设备的具体形式并不做限定，所述方法包括：
步骤602-步骤604：AE向注册服务器1(R-CSE1)发送注册请求，注册 服务器1为AE分配身份标识AE-ID1；
步骤606：AE向资源服务器(H-CSE)发起初次资源访问请求，所述资源访问请求中包含AE-ID1和被访问资源的URI。
具体的，AE向H-CSE发送初次资源访问请求。例如，AE向H-CSE发起的资源访问请求为：
GET http://m2m.things.com/CSE0003/resource1？from＝/CSE0005/CAE0001HTTP/1.1
其中，“CSE0003/resource1”为被访问资源的URI，“from＝/CSE0005/CAE0001”部分表示访问设备的应用标识，即该AE的AE-ID1。由于该AE是初次访问该被访问资源，在AE本地并没有保存与该资源绑定的访问令牌，因此在初次访问请求中并不包含访问令牌参数。
步骤608：资源服务器(H-CSE)接收AE发送的资源访问请求，并进行访问控制决策。
具体的，当H-CSE接收资源访问请求时，首先根据资源访问请求中的被访问资源的URI在本地查找对应的资源，若在本地不能找到该资源，则H-CSE向AE返回资源访问拒绝响应，例如：HTTP/1.1 404Not Found；若在本地能找到被访问的资源，则H-CSE根据资源访问请求中访问设备标识和访问令牌在资源属性中查找对应的授权关系。当AE所发送的资源访问请求为初次资源访问请求时，如步骤606所述，该请求中并不包含访问令牌参数，则H-CSE确定该AE是首次访问资源，H-CSE发起授权流程。
步骤610：资源服务器向AE返回资源访问响应；
该响应包含重定向响应码和重定向URL，该重定向URL指向该M2M系统授权服务器的动态授权端口。
具体的，H-CSE向请求资源访问的AE返回资源访问响应。例如，H-CSE向AE返回的资源访问响应可以为：
HTTP/1.1 302Move temporarily
Location:http://authzserver.things.com/dynamicauthz#from＝/CSE0005/CAE0001&res_uri＝/CSE0003/resource1
其中，HTTP响应的状态码为“302”，表示该AE的资源访问请求需要被重定向到新的URL。“Location”部分表示重定向URL，该重定向URL指向该 M2M系统授权服务器的动态授权端口，例如http://authzserver.things.com/dynamicauthz即为该授权服务器的动态授权端口地址。“#from＝/CSE0005/CAE0001&res_uri＝/CSE0003/resource1”部分为重定向后的资源访问请求所需要附带的参数信息，以查询字符串的形式表示，该例子中所述附带的参数信息为：访问设备标识为“/CSE0005/CAE0001”，被访问资源的URI为“/CSE0003/resource1”。
步骤612：AE向资源服务器发送授权请求，该授权请求包括AE-ID1和被访问资源的URI；
AE收到H-CSE的资源访问响应，向AS发送授权请求，该授权请求的地址使用步骤610中资源访问响应的Location参数所提供的重定向URL。
具体的，AE收到H-CSE的资源访问响应并检测HTTP状态码，当状态码为“302”时，AE向AS发送授权请求。例如，AE向AS发送的授权请求为：
GET http://authzserver.things.com/dynamicauthz？from＝/CSE0005/CAE0001&res_uri＝CSE0003/resource1HTTP/1.1
其中，“/dynamicauthz？from＝/CSE0005/CAE0001&res_uri＝CSE0003/resource1”表示授权服务器的动态授权端口地址以及附带的参数信息，附带的参数信息包括AE-ID1和被访问资源的URI，“Host”部分则描述了授权服务器地址，本实施例中为“http://authzserver.thnings.com”。AE在向AS发送授权请求时也可以直接使用GET请求访问资源访问响应中Location参数所提供的重定向URL，而不使用Host参数，例如该授权请求可以为：
GET http://authzserver.things.com/dynamicauthz？from＝/CSE0005/CAE0001
&res_uri＝/CSE0003/resource1HTTP/1.1
其中第一行末的换行符仅为文档表述清晰的需要，具体实现时上述两行消息中间并无换行符。
步骤614：授权服务器向AE返回授权响应，该授权响应中包括请求用户认证的标志位；
具体的，AS在收到AE的授权请求后，首先检测该授权请求中是否包含用户认证相关的参数，当该授权请求中不包含用户认证信息时，AS向AE返回的授权响应为：
HTTP/1.1 202Accepted
Content-type:application/onem2m-resource+json
{“NeedUserAuthN”:“1”}
其中，HTTP响应的状态码为“202”，表示该授权请求已被接收，但需要进一步的信息并等待后续处理。HTTP消息体中的““NeedUserAuthN”:“1””参数表示一个请求用户认证的标志位，该参数指示AE在下一次授权请求中需要携带用户认证信息。
步骤616：AE授权服务器发送的授权响应，当检测到响应中包含请求用户认证的标志位时，令用户在AE中输入用户认证信息。
具体的，AE收到AS发送的授权响应并检测HTTP状态码，当状态码为“202”时，AE继续检测HTTP消息体，当检测到消息体内包含“NeedUserAuthN”参数且参数值为“1”时，令用户在AE中输入用户认证信息。此处用户可根据AE所驻留设备的用户交互能力选择合适的输入方法，例如，当该设备拥有用户交互接口(如键盘、触摸屏等)时，用户可使用该交互接口输入其账号密码；当该设备不支持用户交互操作时，用户可以利用其它交互设备完成用户信息的输入；此外，用户也可以通过身份卡等能够证明其身份的对象完成身份信息的输入。具体的用户认证信息输入方式不在本发明的讨论范围内，对本发明的方案也没有影响，为简便起见，本发明方案中假设该设备拥有用户交互接口，用户通过该交互接口向AE输入其账号user1和密码password1。
步骤618：用户输入用户认证信息；
步骤620：AE向资源服务器发送授权请求，该授权请求包括AE-ID1、被访问资源的URI和用户认证信息；
具体的，当用户在AE端输入其用户认证信息后，AE向AS发送的授权请求为：
GET
/dynamicauthz？from＝/CSE0005/CAE0001&res_uri＝/CSE0003/resource1
HTTP/1.1
Host:http://authzserver.things.com
Content-type:application/onem2m-resource+json
{“user”:“user1”,
“password”:“password1”}
该授权请求与步骤612所述授权请求相比，增加了用户认证信息相关的参数。其中，““user”:“user1””部分表示用户的账号名，““password”:“password1””部分表示用户账号名对应的密码。本实施例中，用户的认证信息包含在HTTP消息体中并采用JSON格式编码，实际实现中，该用户认证信息也可以查询字符串的形式包含在GET请求的URL中，本发明对此不作限定。
步骤622：授权服务器根据用户认证信息确定用户身份和权限，生成访问令牌(token)；
AS收到AE的授权请求并检测到用户认证信息后，AS从所述授权请求中获取用户认证信息，并在用户信息数据库中对用户认证信息进行验证，并确认该用户是否具有访问该资源的权限；当用户身份和权限得到确认后，AS为本次授权生成token。
具体的，AS在收到AE的授权请求后，首先检测该授权请求中是否包含用户认证相关的参数，当所述授权请求的消息体中包含“user”和“password”参数时，表示该AE想要进行用户认证；然后，AS从所述授权请求的消息体中获取“user”的参数值“user1”以及“password”的参数值“password1”，并在用户信息数据库中查找账号名为“user1”的用户，并验证其密码是否等于“password1”。所述用户信息数据库为保存M2M系统中所有用户认证信息和访问权限的数据库，所述用户信息数据库中保存的用户认证信息与AS所使用的认证方法相关，在本实施例中，AS使用传统的账号名和密码进行用户认证，因此用户信息数据库中保存的用户认证信息至少应包含用户的账号名和密码，此外可能还包含该用户能够访问资源的权限。
当AS在用户信息数据库中找到账号名为“user1”且密码等于“password1”的用户记录时，进一步判断被访问资源的URI，即“/CSE0003/resource1”是否在该用户的访问权限内中，具体的权限表示形式与M2M系统权限管理方式相关，本实施例中假设用户权限信息在用户信息数据库中表现为一个可访问资源列表，所述可访问资源列表包含了该用户有权限访问的所有资源的URI。当用户信息数据库中该用户记录的可访问资源列表中包含被访问资源的URI时，AS即许可本次授权请求，并为本次授权请求生成对应的访问令牌(token)，所述token的生成方式由AS自行决定。采用何种token生成方法对本发明的 方案没有影响，在本实施例中，假设所述token采用一个由AS随机生成的固定长度的字符串表示，例如“2YotnFZFEjr1zCsicMWpAA”。
步骤624：授权服务器向资源服务器发送授权绑定请求，该授权绑定请求中包含AE-ID1、token和被访问资源的URI。
在AS为AE的授权请求生成token后，AS向H-CSE发送授权绑定请求，令H-CSE将授权信息与对应资源绑定保存，所述授权绑定请求中包含AE-ID1、token和被访问资源的URI。
具体的，在AS为AE的授权请求生成token后，AS向H-CSE发送的授权绑定请求可以为：
PUT http://m2m.things.com/CSE0003/resource1HTTP/1.1
From:/CSE0005/CAE0001
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”}
其中，PUT请求的URL表示需要更新的被访问资源URI，即“/CSE0003/resource1”，“From”部分表示访问设备的标识，即“/CSE0005/CAE0001”，HTTP消息体中的““token”:“2YotnFZFEjr1zCsicMWpAA””部分表示与该访问设备和被访问资源URI对应的访问令牌具体数值为“2YotnFZFEjr1zCsicMWpAA”。
步骤626：资源服务器将根据授权服务器发送的授权绑定请求，进行授权关系的绑定；
H-CSE根据AS的授权绑定请求中被访问资源URI找到H-CSE上保存的被访问资源，然后AS从授权绑定请求中获取访问设备标识和访问令牌，并将其保存在被访问资源对应的资源属性中。
具体的，当H-CSE收到AS的授权绑定请求后，H-CSE从所述授权绑定请求中获取被访问资源的URI，例如从PUT请求的URL中获取被访问资源的URI即“/CSE0003/resource1”，并在H-CSE本地保存的资源中找到该被访问资源。然后，H-CSE从授权绑定请求中获取访问设备的AE-ID1和对应的token，例如，从PUT请求的HTTP头域的“From”参数中获取AE-ID1即“/CSE0005/CAE0001”，并从HTTP消息体的“token”参数中获取访问令牌即“2YotnFZFEjr1zCsicMWpAA”。然后，H-CSE将上述AE-ID和token保存到被 访问资源对应的资源属性中。
现有oneM2M标准中仅为资源对象定义了与访问控制策略(ACP)对应的属性accessControlPolicyIDs，而并没有为基于token的授权架构定义对应的资源属性。表7提供了一种可能的授权关系绑定方法：在资源的通用属性中增加授权关系属性authzRel，用于表示与该资源绑定的一条授权关系。
Figure PCTCN2016075488-appb-000004
表7 资源新增授权关系属性图示
如表7所示，每个资源的属性中都可能包含若干个authzRel属性，表示与该资源绑定的若干条授权关系，而每个authzRel资源又表示为一个二元组资源，其中包含subjectID(访问设备标识)和authzProof(访问令牌)两个属性。
当H-CSE获取授权绑定请求中的AE-ID1和token参数后，则构造一个<authzRel>资源实例authzRel1，令authzRel1的subjectID属性值等于“/CSE0005/CAE0001”，authzProof属性值等于“2YotnFZFEjr1zCsicMWpAA”，然后将该authzRel1资源添加到Resource1的属性中，从而完成授权关系的绑定。
步骤628：当资源服务器完成授权关系绑定后，向AS返回授权绑定响应。
具体的，当H-CSE完成授权关系绑定后，H-CSE向AS返回的授权绑定响应可以为：
HTTP/1.1 200OK
其中，HTTP响应的状态码为“200”，表示本次授权关系绑定成功。
步骤630：当授权服务器接收到资源服务器发送的授权绑定响应后，授权服务器向AE返回授权响应，所述授权响应包含token、被访问资源的URI和签名请求标志位。
具体的，当AS收到H-CSE的授权绑定响应后，AS向AE返回的授权响 应可以为：
HTTP/1.1 202Accepted
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”,
“res_uri”:“/CSE0003/resource1”,
“SigReq”:“1”}
其中，HTTP响应的状态码为“202”，表示本次授权请求已被许可，但需要进一步的信息并等待后续处理。HTTP消息体中，““token”:“2YotnFZFEjr1zCsicMWpAA””部分表示本次授权中生成的访问令牌，AE下次可使用该token访问对应资源；““res_uri”:“/CSE0003/resource1””部分表示本次授权响应是针对“/CSE0003/resource1”的，所述token也是针对该资源访问所使用的，该res_uri参数主要是针对AS同时处理多个由该AE发起的授权请求的情况，res_uri参数用于让AE能区分不同授权响应消息；““SigReq”:“1””部分为一个签名请求标志位，表示需要AE进一步提供token签名数据以在AS端保存与本次授权关联的验证信息的签名。
步骤632：AE保存访问令牌，并使用设备出厂密钥对访问令牌进行签名；
当AE收到AS的授权响应后，AE首先从所述授权响应中获取token和被访问资源的URI，并将其绑定保存在本地；然后，AE检测到所述授权响应包含了签名请求标志位，则使用设备出厂密钥对所收到的token进行签名。
具体的，当AE收到AS的授权响应后，AE首先从所述授权响应中获取token和被访问资源的URI，即从HTTP响应消息体的“token”参数中获取访问令牌“2YotnFZFEjr1zCsicMWpAA”，从“res_uri”参数中获取被访问资源的URI即“/CSE0003/resource1”，并将上述两者绑定保存在本地，该保存方法可以使用访问令牌映射表实现，或使用其他的方式保存。具体实现中使用何种保存方法不影响本发明的方案，在本实施例中假设AE端使用一个访问令牌映射表保存被访问资源URI和token的对应关系，如下表8所示，表8中每一行都表示该AE已获取的一项授权：
表8：访问令牌映射表
被访问资源的URI Token
/CSE0003/resource1 2YotnFZFEjr1zCsicMWpAA
/CSE0004/resource2 tGzv3JOkF0XG5Qx2TlKWIA
然后，AE检测授权响应中是否包含签名请求标志位“SigReq”，当授权响应中包含“SigReq”参数且其取值为“1”时，AE使用某种预算的签名算法和设备的出厂密钥对token进行签名，所述签名算法可以为MAC、HMAC等通用的签名算法。具体实现中使用何种签名算法对本发明的方案没有影响，在本实施例中假定AE采用了MAC签名算法，对上述token计算所得的签名为“8456B1CD”。
步骤634：当AE完成token签名后，AE向授权服务器发起签名绑定请求，该请求包含AE-ID1、token、token签名和被访问资源的URI。
具体的，当AE完成token签名后，AE向AS发起的签名绑定请求可以为：
PUT http://authzserver.things.com/dynamicauthz HTTP/1.1
From:/CSE0005/CAE0001
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”,
“token_sig”:“8456B1CD”,
“res_uri”:“/CSE0003/resource1”}
其中，PUT请求的URL地址，即“http://authzserver.things.com/dynamicauthz”为AS的动态授权端口，“From”部分表示发起签名绑定请求的访问设备标识，HTTP消息体中的“token”和“token_sig”参数分别表示需要进行签名绑定的token和token签名。
步骤636：当收到AE的签名绑定请求后，授权服务器生成对应的授权关系并保存在授权关系映射表中。
具体的，当AS收到AE的签名绑定请求后，首先为本次授权生成一个授权关系，该授权关系至少应包含访问设备标识、token、token签名和被访问资源URI，然后AS将所述生成的授权关系添加到授权关系映射表中。所述授权 关系映射表结构可以如表9所示：
表9 授权关系映射表
访问设备标识 Token Token签名 被访问资源URI
/CSE0003/CAE0002 czZCaGRSa3F0MzpnWDFmQmF0M2JW 7432A8D9 /CSE0002/resource3
/CSE0005/CAE0001 2YotnFZFEjr1zCsicMWpAA 8456B1CD /CSE0003/resource1
如表9所示，表中的每一行都表示一条授权关系。当AS收到AE的签名绑定请求后，AS从AE的签名绑定请求中获取对应参数的数值并添加到对应的授权关系中。在本实施例中，AS生成对应的授权关系并将其添加到授权关系映射表中，如表9中第2条记录所示。
上述授权关系映射表在具体实施时，可通过AS内部的一般数据库来进行维护，或者作为一种RESTful资源AuthzRelMapTable进行表述。在基于token的授权架构下，该AuthzRelMapTable资源可以表示为如下图所示的形式：
Figure PCTCN2016075488-appb-000005
表10 授权关系映射表资源及属性图示
其中，AuthzRelMapTable为授权关系映射表资源，该资源包含若干条授权关系属性，即authzRecord资源；authzRecord为授权关系资源，该资源包含以下的一些属性：
subjectID：对应表9中的访问设备标识；
token：对应表9中的token属性；
token_sig：对应表9中的token签名属性；
res_uri：对应表9中的被访问资源URI属性。
需要说明的是，本发明对授权关系映射表的具体表现形式不做限定。
步骤538：授权服务器向AE返回签名绑定响应；
具体的，当AS完成授权关系保存后，AS向AE返回的签名绑定响应可以为：
HTTP/1.1 200OK
其中，HTTP响应的状态码为“200”，表示本次签名绑定请求已经完成，AE可以使用token访问对应的资源。
本发明实施例中，当资源服务器确定接收到的资源访问请求中，没有访问令牌时，资源服务器向访问设备返回的资源访问响应中携带授权服务器的URI，使得访问设备向授权服务器申请认证授权。授权服务器验证用户认证信息合法，生成访问令牌。授权服务器将访问设备标识、被访问资源URI以及生成的访问令牌发送资源服务器，以便于资源服务器生成相应的授权关系。授权服务器将生成的访问令牌以及被访问资源URI发送给AE，并且请求AE对访问令牌进行签名。AE保存被访问资源URI和访问令牌的对应关系。授权服务器将访问设备标识、被访问资源URI、访问令牌以及访问令牌的签名的对应关系保存进授权关系映射表中。
后续需要访问该被访问资源时，需要在资源访问请求中携带对应的访问令牌。当后续AE访问该被访问资源时，如果访问设备标识发生变化，则资源服务器可以根据本地存在该被访问资源URI和该访问令牌对应的授权关系，但是该授权关系中的访问设备标识不符合，确定访问设备标识可能发生变化，从而触发授权更新流程。
参阅图7，图7为本发明提供的一种基于Oauth授权架构的授权更新的流程图。当图6所述实施例中的AE由于更改接入地点等原因，导致在不同的注册服务器(如R-CSE2)上注册时，新的注册服务器R-CSE2可能会为AE分配新的标识AE-ID2，从而导致M2M系统中现有的授权关系失效。图7所述的方法提供了一种当访问标识发生变化后，更新授权关系的方法，包括：
步骤702-步骤704：AE向注册服务器2(R-CSE2)发起注册请求，注册服务器2为AE分配标识AE-ID2。
步骤706：AE根据被访问资源URI在本地找到该资源对应的token，并 向资源服务器(H-CSE)发送资源访问请求，该资源访问请求中包括AE-ID2、该被访问资源URI以及与该被访问资源URI对应的token。
具体的，如图6所述方法中的步骤632所描述，AE经过初始授权后，会保存被访问资源URI和访问令牌的对应关系。AE首先从本地保存的授权信息中，根据被访问资源URI查找到对应的token，然后AE向H-CSE发送资源访问请求。
步骤708：资源服务器接收AE所发送的资源访问请求，并进行访问控制决策。
具体的，如步骤626所述资源服务器保存有被访问资源URI、AE-ID1以及相应的访问令牌的授权关系。H-CSE解析资源访问请求，获取被访问资源URI、AE-ID2和token。当H-CSE确定本地存在被访问资源，且H-CSE在该被访问资源的授权关系属性(authzRel)中查找authzProof属性值与token相同，而subjectID属性值与AE-ID2不相同的授权记录，则资源服务器启动授权更新流程。
步骤710：资源服务器向AE返回资源访问响应，该响应包含重定向响应码和一个重定向URL，该重定向URL指向该M2M系统授权服务器的授权更新端口。
具体的，H-CSE向AE返回资源访问响应。例如，H-CSE向AE返回的资源访问响应可以为：
HTTP/1.1 302Move temporarily
Location:http://authzserver.things.com/authzupdate#from＝/CSE0006/CAE0003&res_uri＝/CSE0003/resource1&token＝2YotnFZFEjr1zCsicMWpAA
其中，HTTP响应的状态码为“302”，表示该AE的资源访问请求需要被重定向到新的URL。“Location”部分表示重定向URL，该重定向URL指向该M2M系统授权服务器的授权更新端口，例如http://authzserver.things.com/authzupdate即为该授权服务器的动态授权端口地址。“#from＝/CSE0006/CAE0003&res_uri＝/CSE0003/resource1&token＝2YotnFZFEjr1zCsic MWpAA”部分为重定向后的资源访问请求所需要附带的参数信息，以查询字符串的形式表示，上述附带参数信息的具体内容参见步骤510的描述， 本发明实施例在此不再详述。
步骤712：AE收到资源服务器的资源访问响应，向授权服务器(AS)发送授权更新请求，该授权更新请求的地址使用响应的Location参数所提供的URL。
具体的，AE收到H-CSE的资源访问响应并检测HTTP状态码，当状态码为“302”时，AE向AS发送授权更新请求。例如，AE向AS发送的授权更新请求为：
GET/authzupdate？from＝/CSE0006/CAE0001&res_uri＝CSE0003/resource1
&token＝2YotnFZFEjr1zCsicMWpAA HTTP/1.1
Host:http://authzserver.things.com
其中，重定向响应中的Location参数被分解为两部分，GET请求的URL地址“/authzupdate？from＝/CSE0006/CAE0001&res_uri＝CSE0003/resource1&token＝2YotnFZFEjr1zCsicMWpAA”表示授权服务器本地的授权更新端口地址以及附带的参数信息，“Host”部分则描述了授权服务器地址，本实施例中为“http://authzserver.thnings.com”。AE在向AS发送授权更新请求时也可以直接使用GET请求访问重定向响应中Location参数所提供的重定向URL，而不使用Host参数，例如该授权更新请求可以为：
GET http://authzserver.things.com/authzupdate？from＝/CSE0006/CAE0001
&res_uri＝/CSE0003/resource1&token＝2YotnFZFEjr1zCsicMWpAA HTTP/1.1
步骤714：当收到AE的授权更新请求后，授权服务器确定本地存在与所述授权更新请求中的token对应的授权关系。
具体的，当AS收到AE的授权更新请求后，AS首先从所述授权更新请求的查询字符串中解析得到token和被访问资源的URI，例如token为“2YotnFZFEjr1zCsicMWpAA”，被访问资源的URI为“/CSE0003/resource1”。然后AS在本地保存的授权关系映射表中查找“Token”栏数值为“2YotnFZFEjr1zCsicMWpAA”且“被访问资源URI”栏数值为“/CSE0003/resource1”的授权关系；当授权关系映射表采用如步骤536中表10所述的RESTful资源AuthzRelMapTable实现时，即在AuthzRelMapTable的属 性中，查找token取值等于“2YotnFZFEjr1zCsicMWpAA”且res_uri等于“/CSE0003/resource1”的authzRecord授权关系。若不存在符合上述条件的授权记录则AS拒绝AE的授权更新请求，向AE返回授权更新失败响应：HTTP/1.1 404Not Found，其中，HTTP响应的状态码为“404”，表示AS没有找到对应的授权记录；若存在符合条件的授权关系，则AS向AE返回的授权更新响应，请求AE对该token进行签名。
步骤716：授权服务器向AE返回授权更新响应，该响应包含HTTP 202响应码、token和一个签名请求标志位。
具体的，当AS启动授权更新流程后，AS向AE返回的授权更新响应为：
HTTP/1.1 202Accepted
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”,
“SigReq”:“1”}
其中，HTTP响应的状态码为“202”，表示AS已接受了AE的授权更新请求，但需要进一步的信息并等待后续处理。HTTP消息体中的““token”:“2YotnFZFEjr1zCsicMWpAA””表示与该token对应的授权关系在请求签名，AE需要对该授权关系对应的验证信息进行签名，在本实施例中该验证信息即token本身，在具体实现时也可以使用其他信息(如原AE-ID等)作为验证信息，取决于AS授权更新端口的具体实现方式而定。HTTP消息体中的““SigReq”:“1””部分为一个签名请求标志位，表示需要AE进一步提供token签名数据以使AS能确认AE的身份。
需要说明的是，具体实现中授权更新响应中的验证信息token并不是必须的。
步骤718：当AE检测所收到资源访问响应中包含签名请求标志位时，则使用设备出厂密钥对所收到的token进行签名。
具体的，在AE收到H-CSE的资源访问响应后，当检测得到HTTP响应的状态码为“202”和HTTP消息体中包含“SigReq”参数且取值为“1”时，AE对token进行签名。。
步骤720：当AE完成token签名后，AE向授权服务器发起签名验证请求，该请求包含AE-ID2、token和token签名。
具体的，当AE完成token签名后，AE向AS发起签名验证请求为：
PUT http://authzserver.things.com/authzupdate HTTP/1.1
From:/CSE0006/CAE0001
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”,
“token_sig”:“8456B1CD”,
“res_uri”:“/CSE0003/resource1”}
其中，各参数解释可参见步骤534的描述，本发明实施例在此不再详述。
步骤722：授权服务器从AE的签名验证请求中获取token和token签名，然后在授权关系映射表中查找与token对应的授权关系，并验证签名验证请求中的token签名是否与该授权关系中的token签名一致。
具体的，当AS收到AE的签名验证请求时，AS首先从AE的签名验证请求中解析得到token数值“2YotnFZFEjr1zCsicMWpAA”和token签名数值“8456B1CD”，然后AS在本地保存的授权关系映射表中查找“Token”栏取值等于“2YotnFZFEjr1zCsicMWpAA”的授权关系，并比较该授权关系的“Token签名”栏是否等于“8456B1CD”。若对应授权记录的“Token签名”栏不等于“8456B1CD”，AS向AE返回签名验证失败响应，该响应包含HTTP 403响应码，例如：HTTP/1.1 403Forbidden；若“Token签名”栏等于“8456B1CD”，则AS对该授权关系进行更新，即将该token对应的授权关系中的访问设备标识AE-ID1更改为当前访问设备标识AE-ID2。
步骤724：授权服务器向资源服务器发送第二授权更新请求，该请求中包括被访问资源URI、token和AE-ID2。
具体的，在AS对授权记录进行更新时，AS向H-CSE发起的授权更新请求可以为：
PUT http://m2m.things.com/CSE0003/resource1HTTP/1.1
From:/CSE0006/CAE0003
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”}
其中，PUT请求的URL表示需要更新的被访问资源的URI，即“/CSE0003/resource1”，“From”部分表示访问设备的新的应用标识AE-ID2，即 “/CSE0006/CAE0003”，HTTP消息体中的““token”:“2YotnFZFEjr1zCsicMWpAA””部分表示与该访问设备和被访问资源URI对应的访问令牌具体数值为“2YotnFZFEjr1zCsicMWpAA”。
步骤726：在收到授权服务器的第二授权更新请求后，资源服务器根据被访问资源URI找到本地保存的被访问资源resource1，并在resource1的授权关系属性中查找访问令牌为token的授权记录，并将该授权记录的访问设备标识更新为AE-ID2。
具体的，在H-CSE收到AS的授权更新请求后，H-CSE首先从所述授权更新请求的URL部分获取被访问资源URI，即“/CSE0003/resource1”，并在本地找到该资源resource1。然后，H-CSE分别从授权更新请求的“From”头域和HTTP消息体中解析得到token和AE-ID2数值，即token为“2YotnFZFEjr1zCsicMWpAA”和AE-ID2为“/CSE0006/CAE0001”，在resource1的授权关系属性中查找访问令牌为token的授权记录，并将该授权记录的访问设备应用标识更新为AE-ID2。具体的，H-CSE在resource1的authzRel属性中查找authzProof属性值等于“2YotnFZFEjr1zCsicMWpAA”的授权记录，然后将该授权记录对应的subjectID属性值改为“/CSE0006/CAE0003”。
步骤728：在完成本地授权更新后，资源服务器向授权服务器返回第二授权更新响应，该响应包含HTTP 200状态码。
具体的，在H-CSE完成本地授权更新后，H-CSE向AS返回的授权更新响应为：
HTTP/1.1 200OK
其中，HTTP响应的状态码为“200”，表示H-CSE已完成对应资源的授权更新。
步骤730：授权服务器向AE返回签名验证响应，该响应中包含HTTP 200响应码。
具体的，在AS收到H-CSE的授权更新响应后，AS向AE返回的签名验证响应为：
HTTP/1.1 200OK
其中，HTTP响应的状态码为“200”，表示AS已完成签名验证并M2M系统已完成授权更新。
步骤732：在AE确定M2M系统已完成授权更新后，AE即可按照已有的资源访问流程向H-CSE发起资源访问请求，并获取到对应的资源。
本发明实施例中，当M2M系统中的M2M设备，如AE，在标识发生变化后，访问被访问资源时，资源服务器触发授权关系更新流程，M2M系统通过验证访问设备对验证信息的签名(token的签名)来确定访问设备的身份，并更新已有的授权关系，使得M2M设备能够实现无缝的资源访问，保证了M2M系统的业务连续性。
由图6所述授权方法可知，M2M系统采用Oauth授权架构对访问设备访问资源进行授权时，授权服务器上保存有访问设备标识、token、token签名和被访问资源URI相对应的授权关系；而资源服务器上保存有访问设备标识、token以及被访问资源URI相对应的授权关系。当访问设备标识发生变化后，再去资源服务器上请求访问所述被访问资源时，资源服务器拒绝访问，并将访问设备的资源访问请求重定向到授权服务器上进行授权更新，由授权服务器根据验证信息的签名，即token的签名，来确定访问设备的身份，进而更新M2M系统的授权关系。实际上，也可以由资源服务器来验证访问设备的身份，进而更新M2M系统的授权关系。
参阅图8，图8为本发明提供的另一种基于Oauth授权架构的授权更新的流程图。
步骤802-步骤808同图7所述的实施例中的步骤702-708，相关描述请参见图7所述实施例的相关步骤，这里不再详述。
步骤810：资源服务器向授权服务器(AS)发送签名数据请求，该请求中包含token。
具体的，当H-CSE发起授权更新流程时，H-CSE向授权服务器发送的签名数据请求为：
GET http://authzserver.things.com/sigquery？token＝2YotnFZFEjr1zCsicMWpAA HTTP/1.1
其中，“http://authzserver.things.com/sigquery”即为该授权服务器的签名数据请求端口地址，“？token＝2YotnFZFEjr1zCsicMWpAA”为所请求签名对应的访问令牌，以查询字符串的形式表示。
步骤812：授权服务器在本地的授权关系映射表中获取与签名数据请求中 的token对应的授权关系中的签名。
具体的，当AS收到H-CSE的签名数据请求后，首先从所述签名数据请求的查询字符串中解析得到token数值，例如“2YotnFZFEjr1zCsicMWpAA”。然后，AS在本地保存的授权关系映射表中进行查找，在“Token”栏中查找与签名数据请求中的token相同的授权关系，并获取对应授权关系的“Token签名”数值。例如在步骤636中描述的授权关系映射表(表9)中，在“Token”栏中查找数值等于“2YotnFZFEjr1zCsicMWpAA”的授权关系，然后提取该授权关系的“Token签名”，即“8456B1CD”。
步骤814：授权服务器向资源服务器返回签名数据响应，所述签名数据响应包括token的签名；
具体的，AS向H-CSE返回的签名数据响应为：
HTTP/1.1 200OK
Content-type:application/onem2m-resource+json
{“token_sig”:“8456B1CD”}
其中，HTTP响应的状态码为“200”，表示本次签名数据请求已被许可。HTTP消息体中，““token_sig”:“8456B1CD””部分表示所请求的token签名数值为“8456B1CD”。
步骤816：资源服务器向AE返回资源访问响应，该响应中包括签名请求标志位。
具体的，当H-CSE收到AS的签名数据响应后，H-CSE向AE返回的资源访问响应可以为：
HTTP/1.1 202Accepted
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”,
“SigReq”:“1”}
其中，HTTP响应的状态码为“202”，表示本次资源访问请求已被处理，但需要进一步的信息并等待后续处理。HTTP消息体中，““token”:“2YotnFZFEjr1zCsicMWpAA””部分表示AE需要提供的签名数据是与该token对应的，该参数主要是针对H-CSE同时处理多个由该AE发起的资源访问请 求的情况，该参数用于让AE区分不同资源访问响应消息；““SigReq”:“1””部分为一个签名请求标志位，表示需要AE进一步提供token签名数据以使H-CSE能确认AE的身份。
步骤818：当AE检测所收到资源访问响应中包含签名请求标志位时，则使用设备出厂密钥对所收到的token进行签名。
该步骤同步骤718，请参与步骤718的相关的描述，这里不再赘述。
步骤820：当AE完成token签名后，AE向H-CSE再次发起资源访问请求，该请求中包含AE-ID2、初始授权得到的token、token签名和资源URI。
具体的，当AE完成token签名后，AE向H-CSE发起的资源访问请求可以为：
GET http://m2m.things.com/CSE0003/resource1？from＝/CSE0006/CAE0001
&token＝2YotnFZFEjr1zCsicMWpAA&token_sig＝8456B1CD HTTP/1.1
其中，相比于步骤806中描述的资源访问请求，本步骤中资源访问请求所携带的信息增加了访问令牌签名参数，即“token_sig＝8456B1CD”，该部分表示本次资源访问请求不仅携带了访问令牌，还携带了访问令牌对应的签名数据。
步骤822：在收到AE的资源访问请求后，H-CSE从资源访问请求中获取token签名，确定该token签名与步骤814中从授权服务器获取的token签名是否相同。
具体的，在H-CSE收到AE的资源访问请求后，H-CSE首先从资源访问请求的HTTP消息体中解析得到token签名，即获取“token_sig”参数对应的取值“8456B1CD”。然后，将资源访问请求中的token签名与步骤814中所述的签名数据响应中的token签名进行比较，例如本实施例中上述两者取值均为“8456B1CD”，当两者相同时即确认该资源访问请求的访问设备AE与初始授权时的AE是同一个访问设备；如果两者不同，则资源服务器拒绝访问设备的访问，流程结束。
步骤824：在资源服务器确认签名合法后，H-CSE向AS发起授权更新请求，该请求包含token和AE-ID2。
具体的，在H-CSE确认AE与初始授权的访问设备的对应关系后，H-CSE向AS发起的授权更新请求可以为：
PUT http://authzserver.things.com/authzupdate HTTP/1.1
From:/CSE0006/CAE0001
Content-type:application/onem2m-resource+json
{“token”:“2YotnFZFEjr1zCsicMWpAA”}
其中，PUT请求的URL地址，即“http://authzserver.things.com/authzupdate”为AS的授权更新端口地址，“From”部分表示需要授权更新的访问设备的新标识AE-ID2，即“/CSE0006/CAE0003”，HTTP消息体中的“token”表示需要更新的授权关系中对应token的取值，即需要更新的授权关系中token取值为“2YotnFZFEjr1zCsicMWpAA”，该参数用于让AS找到需要更新的授权关系。
步骤828：授权服务器对本地保存的授权关系映射表进行更新。
具体的，当AS收到H-CSE的授权更新请求后，首先从授权更新请求中解析得到访问设备的新标识“/CSE0006/CAE0003”，以及与本次资源访问请求所对应授权关系的token取值“2YotnFZFEjr1zCsicMWpAA”；然后，AS在本地保存的授权关系映射表中查找“Token”栏取值为“2YotnFZFEjr1zCsicMWpAA”的授权关系，所述授权关系映射表如步骤609中表9的描述。当AS找到对应的授权关系后，即将所述授权关系的“访问设备标识”栏的原数值“/CSE0005/CAE0001”替换为授权更新请求中的新标识“/CSE0006/CAE0003”。当授权关系映射表采用如步骤609所述的RESTful资源AuthzRelMapTable实现时，该授权更新即在AuthzRelMapTable的属性中，查找token取值等于“2YotnFZFEjr1zCsicMWpAA”的authzRecord授权关系，并将该授权记录的subjectID更新为“/CSE0006/CAE0003”。
步骤828：当授权服务器完成授权关系映射表的更新后，向资源服务器返回授权更新响应。
具体的，当AS完成授权关系映射表的更新后，AS向H-CSE返回的授权更新响应为：
HTTP/1.1 200OK
其中，HTTP响应的状态码为“200”，表示AS已成功更新授权关系映射表。
步骤830：当资源服务器收到授权服务器的授权更新响应后，对被访问资源关联的授权关系进行更新。
具体的，当H-CSE收到AS的授权更新响应后，即在被访问资源的authzRel属性中查找authzProof等于token(“2YotnFZFEjr1zCsicMWpAA”)的授权关系，并将该授权关系中的subjectID取值更新为“/CSE0006/CAE0003”。
步骤832：当资源服务器完成被访问资源关联的授权关系更新后，按照正常的资源访问流程向AE返回资源访问响应。
具体的，当H-CSE完成被访问资源关联的授权关系更新后，H-CSE向AE返回的资源访问响应可以为：
HTTP/1.1 200OK
Content-type:application/onem2m-resource+json
{“content”:“xxxxxxxxxxxxx”}
应的状态码为“200”，表示H-CSE已许可AE本次资源访问请求，HTTP消息体中则包含了AE所请求的资源内容，本实施例中““content”:“xxxxxxxxxxxxx””仅示意资源内容包含在HTTP消息体中返回给AE，具体返回格式和内容根据被访问资源的类型确定，本发明不做限定。
本发明实施例中，当M2M系统中的M2M设备，如AE，在标识发生变化后，访问被访问资源时，资源服务器触发授权关系更新流程，M2M系统通过验证访问设备对验证信息的签名(token的签名)来确定访问设备的身份，并更新已有的授权关系，使得M2M设备能够实现无缝的资源访问，保证了M2M系统的业务连续性。
本发明实施例还描述了与图2所示实施例属于同一发明构思下的一种授权服务器，如图9所示，图9为本发明实施例提供的授权服务器的结构示意图，该授权服务器可以包括：接收模块901、发送模块902、获取模块903、确定模块904和更新模块905，其中：
接收模块901，用于接收访问设备发送的第一授权更新请求，所述第一授权更新请求包括所述访问设备的第一标识；
发送模块902，用于向所述访问设备发送第一授权更新响应，所述第一授权更新响应包括签名请求信息，所述签名请求信息指示所述访问设备对验证信息进行签名；
所述接收模块901，还用于接收所述访问设备发送的签名验证请求，所述签名验证请求中包括所述第一标识、所述验证信息和所述验证信息的签名；其 中，所述验证信息的签名为所述访问设备使用密钥对所述验证信息进行签名生成的；
获取模块903，用于根据所述接收模块接收到的签名验证请求中的验证信息，获取保存的第一授权关系；
确定模块904，用于根据接收到的签名验证请求中的验证信息的签名与所述第一授权关系中保存的验证信息的签名，确定所述签名验证请求中的验证信息的签名合法；
更新模块905，用于根据所述第一标识，更新所述第一授权关系。
其中，所述更新模块用于根据所述第一标识，更新所述第一授权关系，具体为：将所述第一授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
具体的，所述授权服务器还包括初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权。
可选的，当所述验证信息为所述访问设备保存的所述第二标识时，所述签名验证请求中进一步还包括所述第一标识的签名，其中所述第一标识的签名为所述访问设备使用所述密钥对所述第一标识进行签名生成的；所述更新模块905，还用于将所述第一授权关系中保存的验证信息的签名更改为所述第一标识的签名。所述初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：向资源服务器发送资源创建请求，所述资源创建请求包括预设的访问控制策略和所述被访问资源标识，其中，所述预设的访问控制策略包括所述第二标识；接收所述资源服务器发送的资源创建响应，所述资源创建响应指示所述资源服务器成功创建所述访问控制策略资源且将所述访问控制策略资源与所述被访问资源标识对应的资源进行绑定；向所述访问设备发送签名请求，所述签名请求指示所述访问设备对所述第二标识进行签名；接收所述访问设备发送的签名响应，所述签名响应包括所述第二标识的签名；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述第二标识的签名和所述被访问资源标识的对应关系。可选的，所述发送模块902，还用于在根据所述第一标识，更新所述第一授权关系之后，向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述第二标识和所述被访问资源标识，以便于所述资源服务器根据所述所述第二标识和所述 被访问资源标识获取本地保存第二授权关系，并将所述第二授权关系中的第二标识更新为所述第一标识。
可选的，当所述验证信息为授权凭证，所述第一授权更新请求还包括所述授权凭证，所述确定模块904，还用于在所述向所述访问设备发送第一授权更新响应之前，根据所述授权凭证，确定存在包含所述授权凭证的所述第一授权关系，且所述第一授权关系中绑定的设备标识不是所述第一标识。所述初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：接收所述访问设备的授权请求，所述授权请求包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；当根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限时，生成所述授权凭证；向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；接收所述资源服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名为所述访问设备对所述授权凭证使用所述密钥签名生成的；保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系。可选的，所述发送模块902，还用于在根据所述第一标识，更新所述第一授权关系之后，向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述授权凭证和所述被访问资源标识，以便于所述资源服务器根据所述授权凭证和所述被访问资源标识获取所述第二授权关系，并将所述第二授权关系中的第二标识更新为所述第一标识。
图10描述了本发明另一个实施例提供的授权服务器的结构，用于执行前述图2、图4、图5、图6和图7所述实施例的授权服务器实施的授权方法，包括至少一个处理器1001(例如CPU)，至少一个网络接口1002或者其他通信接口，存储器1003，和至少一个通信总线1004，用于实现这些装 置之间的连接通信。处理器1001用于执行存储器1003中存储的可执行程序，例如计算机程序。存储器1003可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个网络接口1002(可以是有线或者无线)实现该系统网关与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。
在一些实施方式中，存储器1003存储了程序10031，程序10031可以被处理器1001执行，这个程序包括：接收访问设备发送的第一授权更新请求，所述第一授权更新请求包括所述访问设备的第一标识；向所述访问设备发送第一授权更新响应，所述第一授权更新响应包括签名请求信息，所述签名请求信息指示所述访问设备对验证信息进行签名；接收所述访问设备发送的签名验证请求，所述签名验证请求中包括所述第一标识、所述验证信息和所述验证信息的签名；其中，所述验证信息的签名为所述访问设备使用密钥对所述验证信息进行签名生成的；根据所述验证信息，获取保存的第一授权关系；根据接收到的签名验证请求中的验证信息的签名与所述第一授权关系中保存的验证信息的签名，确定所述签名验证请求中的验证信息的签名合法；根据所述第一标识，更新所述第一授权关系。
本发明实施例还描述了与图3所示实施例属于同一发明构思下的一种资源服务器，如图11所示，图11为本发明实施例提供的资源服务器的结构示意图，该授权服务器可以包括：接收模块1101、确定模块1102、发送模块1103、和更新模块1104，其中：
接收模块1101，用于接收访问设备发送的第一资源访问请求，所述第一资源访问请求包括所述访问设备的第一标识、被访问资源标识以及授权凭证；
确定模块1102，用于根据所述授权凭证，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的设备标识不是所述第一标识；
发送模块1103，用于向所述访问设备发送第一资源访问响应，所述第一资源访问响应包括签名请求信息，所述签名请求信息指示所述访问设备对所述授权凭证进行签名；
所述接收模块1101，还用于接收所述访问设备发送的第二资源访问请求，所述第二资源访问请求中包括所述第一标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识；其中，所述授权凭证的签名为所述访问设备使用密钥对所述授权凭证进行签名生成的；
所述发送模块1103，还用于向授权服务器发送签名数据请求，所述签名数据请求包含所述授权凭证；
所述接收模块1101，还用于接收所述授权服务器发送的签名数据响应，所述签名数据响应包含所述授权服务器根据所述授权凭证获取的第一授权关系中保存的授权凭证的签名；
所述确定模块1102，还用于根据所述第二资源访问请求中的授权凭证的签名与所述授权服务器发送的授权凭证的签名，确定所述第二资源访问请求中的授权凭证的签名合法；
更新模块1104，用于根据所述第一标识，更新所述第二授权关系。
可选的，所述更新模块，用于根据所述第一标识，更新所述第二授权关系，具体为：将所述第二授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
其中，所述发送模块1103还用于，在根据所述第一标识，更新所述第二授权关系之后，向所述访问设备发送第二资源访问响应，所述第二资源访问响应包括所述被访问资源标识对应的资源。
具体的，所述接收模块1101，还用于接收授权服务器对所述访问设备访问所述被访问资源标识对应的资源进行初始授权后发送的授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；所述资源服务器进一步还包括存储模块，用于将所述第二标识、所述授权凭证和所述被访问资源标识的对应关系保存为第二授权关系。
图12描述了本发明另一个实施例提供的资源服务器的结构，用于执行前述图3、图6和图8所述实施例中资源服务器实施的授权方法，包括至少一个处理器1201(例如CPU)，至少一个网络接口1202或者其他通信接口，存储器1203，和至少一个通信总线1204，用于实现这些装置之间的连接通信。处理器1201用于执行存储器1203中存储的可执行程序，例如计算机程序。存储器1203可能包含高速随机存取存储器(RAM：Random  Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个网络接口1202(可以是有线或者无线)实现该系统网关与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。
在一些实施方式中，存储器1203存储了程序12031，程序12031可以被处理器1201执行，这个程序包括：接收访问设备发送的第一资源访问请求，所述第一资源访问请求包括所述访问设备的第一标识、被访问资源标识以及授权凭证；根据所述授权凭证，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的访问设备标识不是所述第一标识；向所述访问设备发送第一资源访问响应，所述第一资源访问响应包括签名请求信息，所述签名请求信息指示所述访问设备对所述授权凭证进行签名；接收所述访问设备发送的第二资源访问请求，所述第二资源访问请求中包括所述第一标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识；其中，所述授权凭证的签名为所述访问设备使用密钥对所述授权凭证进行签名生成的；向授权服务器发送签名数据请求，所述签名数据请求包含所述授权凭证；接收所述授权服务器发送的签名数据响应，所述签名数据响应包含所述授权服务器根据所述授权凭证获取的第一授权关系中保存的授权凭证的签名；根据所述第二资源访问请求中的授权凭证的签名与所述授权服务器发送的授权凭证的签名，确定所述第二资源访问请求中的授权凭证的签名合法；根据所述第一标识，更新所述第二授权关系。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
上述装置和系统内的各模块之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程 序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(ROM：Read-Only Memory)或随机存储记忆体(RAM：Random Access Memory)等。
本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (28)

  1. 一种机器通信中处理授权的方法，其特征在于，包括：
    授权服务器接收访问设备发送的第一授权更新请求，所述第一授权更新请求包括所述访问设备的第一标识；
    所述授权服务器向所述访问设备发送第一授权更新响应，所述第一授权更新响应包括签名请求信息，其中所述签名请求信息用于指示所述访问设备对验证信息进行签名；
    所述授权服务器接收所述访问设备发送的签名验证请求，所述签名验证请求中包括所述第一标识、所述验证信息和所述验证信息的签名；其中，所述验证信息的签名为所述访问设备使用密钥对所述验证信息进行签名生成的；
    所述授权服务器根据所述验证信息，获取保存的第一授权关系；
    所述授权服务器根据接收到的签名验证请求中的验证信息的签名与所述第一授权关系中保存的验证信息的签名，确定所述签名验证请求中的验证信息的签名合法；
    所述授权服务器根据所述第一标识，更新所述第一授权关系。
  2. 如权利要求1所述的方法，其特征在于，在所述接收访问设备发送的第一授权更新请求之前，所述方法还包括：
    资源服务器接收所述访问设备发送资源访问请求，所述资源访问请求包括所述第一标识和被访问资源标识；
    所述资源服务器根据所述第一标识和所述被访问资源标识，确定所述访问设备没有访问所述被访问资源标识对应的资源的权限；
    所述资源服务器拒绝所述访问设备的对所述被访问资源标识对应的资源的访问请求，并向所述访问设备发送包括重定向地址的资源访问响应，其中所述重定向地址为授权服务器的授权更新端口地址，以便于所述访问设备根据所述授权更新端口地址，向所述授权服务器发送所述第一授权更新请求。
  3. 如权利要求1或2所述的方法，其特征在于，所述根据所述第一标识，更新所述第一授权关系，具体为：
    所述授权服务器将所述第一授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
  4. 如权利要求1-3任一所述方法，其特征在于，在所述接收访问设备发送的第一授权更新请求之前，所述方法还包括：
    所述授权服务器对所述访问设备访问所述被访问资源标识对应的资源进行初始授权。
  5. 如权利要求4所述的方法，其特征在于，所述验证信息为所述访问设备保存的所述第二标识，所述签名验证请求中进一步还包括所述第一标识的签名，其中所述第一标识的签名为所述访问设备使用所述密钥对所述第一标识进行签名生成的；在所述确定所述签名验证请求中的验证信息的签名合法之后，所述方法进一步还包括：
    所述授权服务器将所述第一授权关系中保存的验证信息的签名更改为所述第一标识的签名。
  6. 如权利要求5所述的方法，其特征在于，所述对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：
    所述授权服务器向资源服务器发送资源创建请求，所述资源创建请求包括预设的访问控制策略和所述被访问资源标识，其中，所述预设的访问控制策略包括所述第二标识；
    所述授权服务器接收所述资源服务器发送的资源创建响应，所述资源创建响应指示所述资源服务器成功创建所述访问控制策略资源且将所述访问控制策略资源与所述被访问资源标识对应的资源进行绑定；
    所述授权服务器向所述访问设备发送签名请求，所述签名请求指示所述访问设备对所述第二标识进行签名；
    所述授权服务器接收所述访问设备发送的签名响应，所述签名响应包括所述第二标识的签名；
    所述授权服务器保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述第二标识的签名和所述被访问资源标识的对应关系。
  7. 如权利要求3-6任一所述的方法，其特征在于，在所述根据所述第一标识，更新所述第一授权关系之后，所述方法还包括：
    所述授权服务器向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述第二标识和所述被访问资源标识。
  8. 如权利要求4所述的方法，其特征在于，所述验证信息为授权凭证，所述第一授权更新请求还包括所述授权凭证，在所述向所述访问设备发送第一授权更新响应之前，所述方法还包括：
    所述授权服务器根据所述授权凭证，确定存在包含所述授权凭证的所述第一授权关系，且所述第一授权关系中绑定的访问设备标识不是所述第一标识。
  9. 如权利要求8所述的方法，其特征在于，所述对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：
    所述授权服务器接收所述访问设备的授权请求，所述授权请求包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；
    所述授权服务器当根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限时，生成所述授权凭证；
    所述授权服务器向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；
    所述授权服务器接收所述资源服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；
    所述授权服务器向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；
    所述授权服务器接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名为所述访问设备对所述授权凭证使用所述密钥签名生成的；
    所述授权服务器保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的 对应关系。
  10. 如权利要求8-9任一所述的方法，其特征在于，在所述根据所述第一标识，更新所述第一授权关系之后，所述方法还包括：
    所述授权服务器向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述授权凭证和所述被访问资源标识。
  11. 一种机器通信中处理授权的方法，其特征在于，包括：
    接收访问设备发送的第一资源访问请求，所述第一资源访问请求包括所述访问设备的第一标识、被访问资源标识以及授权凭证；
    根据所述授权凭证，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的访问设备标识不是所述第一标识；
    向所述访问设备发送第一资源访问响应，所述第一资源访问响应包括签名请求信息，所述签名请求信息指示所述访问设备对所述授权凭证进行签名；
    接收所述访问设备发送的第二资源访问请求，所述第二资源访问请求中包括所述第一标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识；其中，所述授权凭证的签名为所述访问设备使用密钥对所述授权凭证进行签名生成的；
    向授权服务器发送签名数据请求，所述签名数据请求包含所述授权凭证；
    接收所述授权服务器发送的签名数据响应，所述签名数据响应包含所述授权服务器根据所述授权凭证获取的第一授权关系中保存的授权凭证的签名；
    根据所述第二资源访问请求中的授权凭证的签名与所述授权服务器发送的授权凭证的签名，确定所述第二资源访问请求中的授权凭证的签名合法；
    根据所述第一标识，更新所述第二授权关系。
  12. 如权利要求11所述的方法，其特征在于，在所述根据所述第一标识，更新所述第二授权关系之后，所述方法还包括：
    向所述访问设备发送第二资源访问响应，所述第二资源访问响应包括所述被访问资源标识对应的资源。
  13. 如权利要求11或12所述的方法，其特征在于，所述根据所述第一标识，更新所述第二授权关系，具体为：
    将所述第二授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
  14. 如权利要求13所述的方法，其特征在于，在所述接收访问设备发送的第一资源访问请求之前，所述方法还包括：
    所述授权服务器接收所述访问设备发送授权请求，所述授权请求中包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；
    所述授权服务器根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限，生成所述授权凭证，并向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；
    所述资源服务器将所述第二标识、所述授权凭证和所述被访问资源标识的对应关系保存为第二授权关系，并向所述授权服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；
    所述授权服务器向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；
    所述授权服务器接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名是所述访问设备使用所述密钥对所述授权凭证进行签名生成的；
    所述授权服务器将所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系保存为第一授权关系。
  15. 如权利要求11-14任一所述的方法，其特征在于，在所述确定所述第二资源访问请求中的授权凭证的签名合法之后，所述方法还包括：
    向所述授权服务器发送第三授权更新请求，所述第三授权更新请求包括所述授权凭证和所述第一标识；
    接收所述授权服务器发送的第三授权更新响应，所述第三授权更新响应包括所述授权服务器授权更新成功的指示信息。
  16. 一种机器通信中的授权服务器，其特征在于，包括：
    接收模块，用于接收访问设备发送的第一授权更新请求，所述第一授权更新请求包括所述访问设备的第一标识；
    发送模块，用于向所述访问设备发送第一授权更新响应，所述第一授权更新响应包括签名请求信息，其中所述签名请求信息用于指示所述访问设备对验证信息进行签名；
    所述接收模块，还用于接收所述访问设备发送的签名验证请求，所述签名验证请求中包括所述第一标识、所述验证信息和所述验证信息的签名；其中，所述验证信息的签名为所述访问设备使用密钥对所述验证信息进行签名生成的；
    获取模块，用于根据所述接收模块接收到的签名验证请求中的验证信息，获取保存的第一授权关系；
    确定模块，用于根据接收到的签名验证请求中的验证信息的签名与所述第一授权关系中保存的验证信息的签名，确定所述签名验证请求中的验证信息的签名合法；
    更新模块，用于根据所述第一标识，更新所述第一授权关系。
  17. 如权利要求16所述的授权服务器，其特征在于，所述更新模块用于根据所述第一标识，更新所述第一授权关系，具体为：
    将所述第一授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
  18. 如权利要求16或17所述的授权服务器，其特征在于，所述授权服务器还包括：
    初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权。
  19. 如权利要求18所述的授权服务器，其特征在于，所述验证信息 为所述访问设备保存的所述第二标识，所述签名验证请求中进一步还包括所述第一标识的签名，其中所述第一标识的签名为所述访问设备使用所述密钥对所述第一标识进行签名生成的；
    所述更新模块，还用于将所述第一授权关系中保存的验证信息的签名更改为所述第一标识的签名。
  20. 如权利要求19所述的授权服务器，其特征在于，其特征在于，所述初始授权模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：向资源服务器发送资源创建请求，所述资源创建请求包括预设的访问控制策略和所述被访问资源标识，其中，所述预设的访问控制策略包括所述第二标识；
    接收所述资源服务器发送的资源创建响应，所述资源创建响应指示所述资源服务器成功创建所述访问控制策略资源且将所述访问控制策略资源与所述被访问资源标识对应的资源进行绑定；
    向所述访问设备发送签名请求，所述签名请求指示所述访问设备对所述第二标识进行签名；
    接收所述访问设备发送的签名响应，所述签名响应包括所述第二标识的签名；
    保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述第二标识的签名和所述被访问资源标识的对应关系。
  21. 如权利要求17-20所述的授权服务器，其特征在于，所述发送模块，还用于在根据所述第一标识，更新所述第一授权关系之后，向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识和所述被访问资源标识。
  22. 如权利要求18所述的授权服务器，其特征在于，所述验证信息为授权凭证，所述第一授权更新请求还包括所述授权凭证，
    所述确定模块，还用于在所述向所述访问设备发送第一授权更新响应之前，根据所述授权凭证，确定存在包含所述授权凭证的所述第一授权关系，且所述第一授权关系中绑定的设备标识不是所述第一标识。
  23. 如权利要求22所述的授权服务器，其特征在于，所述初始授权 模块，用于对所述访问设备访问所述被访问资源标识对应的资源进行初始授权，具体为：
    接收所述访问设备的授权请求，所述授权请求包括所述第二标识、所述被访问资源标识和用户同意所述访问设备访问资源的认证信息；
    当根据所述认证信息，确定所述用户具有访问所述被访问资源标识对应的资源的权限时，生成所述授权凭证；
    向所述被访问资源标识对应的资源所在的资源服务器发送授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；
    接收所述资源服务器发送的授权绑定响应，所述授权绑定响应包含绑定成功的指示信息；
    向所述访问设备发送授权响应，所述授权响应包括所述授权凭证、所述被访问资源标识和对所述授权凭证进行签名的指示信息；
    接收所述访问设备发送的签名绑定请求，所述签名绑定请求包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识，其中，所述授权凭证的签名为所述访问设备对所述授权凭证使用所述密钥签名生成的；
    保存所述第一授权关系，所述第一授权关系包括所述第二标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识的对应关系。
  24. 如权利要求22-23任一所述的授权服务器，其特征在于，所述发送模块，还用于在根据所述第一标识，更新所述第一授权关系之后，向资源服务器发送第二授权更新请求，所述第二授权更新请求包括所述第一标识、所述授权凭证和所述被访问资源标识。
  25. 一种机器通信中的资源服务器，其特征在于，包括：
    接收模块，用于接收访问设备发送的第一资源访问请求，所述第一资源访问请求包括所述访问设备的第一标识、被访问资源标识以及授权凭证；
    确定模块，用于根据所述授权凭证，确定存在包含所述授权凭证与所述被访问资源标识的第二授权关系，且所述第二授权关系中绑定的设备标 识不是所述第一标识；
    发送模块，用于向所述访问设备发送第一资源访问响应，所述第一资源访问响应包括签名请求信息，所述签名请求信息指示所述访问设备对所述授权凭证进行签名；
    所述接收模块，还用于接收所述访问设备发送的第二资源访问请求，所述第二资源访问请求中包括所述第一标识、所述授权凭证、所述授权凭证的签名和所述被访问资源标识；其中，所述授权凭证的签名为所述访问设备使用密钥对所述授权凭证进行签名生成的；
    所述发送模块，还用于向授权服务器发送签名数据请求，所述签名数据请求包含所述授权凭证；
    所述接收模块，还用于接收所述授权服务器发送的签名数据响应，所述签名数据响应包含所述授权服务器根据所述授权凭证获取的第一授权关系中保存的授权凭证的签名；
    所述确定模块，还用于根据所述第二资源访问请求中的授权凭证的签名与所述授权服务器发送的授权凭证的签名，确定所述第二资源访问请求中的授权凭证的签名合法；
    更新模块，用于根据所述第一标识，更新所述第二授权关系。
  26. 如权利要求25所述的资源服务器，其特征在于，所述发送模块还用于，在根据所述第一标识，更新所述第二授权关系之后，向所述访问设备发送第二资源访问响应，所述第二资源访问响应包括所述被访问资源标识对应的资源。
  27. 如权利要求25或26所述的资源服务器，其特征在于，所述更新模块，用于根据所述第一标识，更新所述第二授权关系，具体为：
    将所述第二授权关系中的第二标识更改为所述第一标识，其中，所述第二标识为所述访问设备使用过的标识。
  28. 如权利要求27所述的资源服务器，其特征在于，所述接收模块，还用于接收授权服务器对所述访问设备访问所述被访问资源标识对应的资源进行初始授权后发送的授权绑定请求，所述授权绑定请求包括所述第二标识、所述授权凭证和所述被访问资源标识；
    存储模块，用于将所述第二标识、所述授权凭证和所述被访问资源标识的对应关系保存为第二授权关系。
PCT/CN2016/075488 2015-08-10 2016-03-03 一种处理授权的方法和设备 WO2017024791A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020187003384A KR101962156B1 (ko) 2015-08-10 2016-03-03 권한부여 처리 방법 및 장치
JP2018500769A JP6494149B2 (ja) 2015-08-10 2016-03-03 認可処理方法およびデバイス
EP16834417.4A EP3310083A4 (en) 2015-08-10 2016-03-03 Authorization processing method and device
US15/892,686 US10666661B2 (en) 2015-08-10 2018-02-09 Authorization processing method and device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510486108.0A CN106714075B (zh) 2015-08-10 2015-08-10 一种处理授权的方法和设备
CN201510486108.0 2015-08-10

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/892,686 Continuation US10666661B2 (en) 2015-08-10 2018-02-09 Authorization processing method and device

Publications (1)

Publication Number Publication Date
WO2017024791A1 true WO2017024791A1 (zh) 2017-02-16

Family

ID=57982961

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/075488 WO2017024791A1 (zh) 2015-08-10 2016-03-03 一种处理授权的方法和设备

Country Status (6)

Country Link
US (1) US10666661B2 (zh)
EP (1) EP3310083A4 (zh)
JP (1) JP6494149B2 (zh)
KR (1) KR101962156B1 (zh)
CN (1) CN106714075B (zh)
WO (1) WO2017024791A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106411723A (zh) * 2016-12-12 2017-02-15 郑州云海信息技术有限公司 一种消息处理方法及装置
CN111666189A (zh) * 2020-06-12 2020-09-15 中信银行股份有限公司 一种声明式可视化配置Prometheus监控告警的方法和系统
CN112887099A (zh) * 2021-01-11 2021-06-01 深圳市新国都支付技术有限公司 数据签名方法、电子设备及计算机可读存储介质

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108476226B (zh) * 2016-12-22 2021-06-22 华为技术有限公司 应用程序授权方法、终端及服务器
JP2019046059A (ja) * 2017-08-31 2019-03-22 キヤノン株式会社 権限委譲システム、制御方法、およびプログラム
JP6643373B2 (ja) * 2018-02-09 2020-02-12 キヤノン株式会社 情報処理システムと、その制御方法とプログラム
CN110858833B (zh) 2018-08-22 2022-09-30 京东方科技集团股份有限公司 访问控制策略配置方法、装置和系统以及存储介质
CN111611574B (zh) * 2019-02-22 2023-11-17 阿里巴巴集团控股有限公司 信息获取方法、装置、设备和系统
US11240241B2 (en) * 2019-06-19 2022-02-01 Servicenow, Inc. Discovery and mapping of a cloud-based authentication, authorization, and user management service
JP7372527B2 (ja) * 2019-09-26 2023-11-01 富士通株式会社 通信中継プログラム、中継装置、及び通信中継方法
CN111181931B (zh) * 2019-12-18 2021-01-01 北京邮电大学 一种基于用户终端认证的授权系统及方法
CN111143827B (zh) * 2019-12-27 2023-04-28 联想(北京)有限公司 信息处理方法、装置以及系统
KR20210115452A (ko) * 2020-03-13 2021-09-27 삼성전자주식회사 적어도 하나의 장치를 관리하는 방법 및 전자 장치
CN111949959B (zh) * 2020-08-14 2023-09-15 中国工商银行股份有限公司 Oauth协议中的授权认证方法及装置
CN114598489B (zh) * 2020-11-20 2023-07-11 华为技术有限公司 一种确定信任终端的方法及相关装置
US11595451B2 (en) * 2020-12-30 2023-02-28 Zoom Video Communications, Inc. Methods and apparatus for receiving meeting controls for network conferences
US11575525B2 (en) 2020-12-30 2023-02-07 Zoom Video Communications, Inc. Methods and apparatus for providing meeting controls for network conferences
CN112511569B (zh) * 2021-02-07 2021-05-11 杭州筋斗腾云科技有限公司 网络资源访问请求的处理方法、系统及计算机设备
WO2022186606A1 (ko) * 2021-03-04 2022-09-09 주식회사 센스톤 인증용 가상코드 기반의 암호 키 업데이트 제공 장치 및 방법
CN116701006A (zh) * 2022-02-28 2023-09-05 华为技术有限公司 一种组件通信方法及计算设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102065430A (zh) * 2010-12-28 2011-05-18 上海华御信息技术有限公司 实现物联网终端安全接入的方法
EP2367371A1 (en) * 2010-03-15 2011-09-21 Research In Motion Limited Use of certificate authority to control a device's access to servies
CN102835137A (zh) * 2010-03-16 2012-12-19 高通股份有限公司 促进接入终端身份的认证
CN104184713A (zh) * 2013-05-27 2014-12-03 阿里巴巴集团控股有限公司 终端识别方法、机器识别码注册方法及相应系统、设备
US20150089593A1 (en) * 2013-09-24 2015-03-26 International Business Machines Corporation Method and system for using a vibration signature as an authentication key

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6704871B1 (en) * 1997-09-16 2004-03-09 Safenet, Inc. Cryptographic co-processor
JP4501197B2 (ja) * 2000-01-07 2010-07-14 ソニー株式会社 情報携帯処理システム、情報携帯装置のアクセス装置及び情報携帯装置
JP4153653B2 (ja) * 2000-10-31 2008-09-24 株式会社東芝 マイクロプロセッサおよびデータ保護方法
CN100428751C (zh) * 2000-12-25 2008-10-22 松下电器产业株式会社 安全通信包处理装置及其方法
JP4098478B2 (ja) * 2001-01-31 2008-06-11 株式会社東芝 マイクロプロセッサ
US6976167B2 (en) * 2001-06-26 2005-12-13 Intel Corporation Cryptography-based tamper-resistant software design mechanism
FR2834361B1 (fr) * 2001-12-28 2004-02-27 Bull Sa Module de securisation de donnees par chiffrement/dechiffrement et/ou signature/verification de signature
EP1331539B1 (en) * 2002-01-16 2016-09-28 Texas Instruments France Secure mode for processors supporting MMU and interrupts
US7840803B2 (en) * 2002-04-16 2010-11-23 Massachusetts Institute Of Technology Authentication of integrated circuits
US20040093507A1 (en) * 2002-06-26 2004-05-13 Stephan Courcambeck Verification of the integrity of a software code executed by an integrated processor
US7149862B2 (en) * 2002-11-18 2006-12-12 Arm Limited Access control in a data processing apparatus
GB2396930B (en) * 2002-11-18 2005-09-07 Advanced Risc Mach Ltd Apparatus and method for managing access to a memory
US20040199787A1 (en) * 2003-04-02 2004-10-07 Sun Microsystems, Inc., A Delaware Corporation Card device resource access control
CN101496387B (zh) 2006-03-06 2012-09-05 思科技术公司 用于移动无线网络中的接入认证的系统和方法
US20090260064A1 (en) * 2008-04-15 2009-10-15 Problem Resolution Enterprise, Llc Method and process for registering a device to verify transactions
US8893242B2 (en) * 2008-04-29 2014-11-18 Ebay Inc. System and method for pool-based identity generation and use for service access
CN103314605A (zh) * 2011-01-17 2013-09-18 瑞典爱立信有限公司 用于认证通信设备的方法和装置
CN103220670B (zh) 2012-01-19 2018-01-19 华为技术有限公司 一种设备切换方法、m2m平台和网络系统
US9077709B1 (en) * 2012-01-31 2015-07-07 Teradici Corporation Method for authenticated communications incorporating intermediary appliances
CN104618366B (zh) * 2015-01-27 2018-07-17 西安电子科技大学 一种基于属性的网络档案安全管理系统及方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2367371A1 (en) * 2010-03-15 2011-09-21 Research In Motion Limited Use of certificate authority to control a device's access to servies
CN102835137A (zh) * 2010-03-16 2012-12-19 高通股份有限公司 促进接入终端身份的认证
CN102065430A (zh) * 2010-12-28 2011-05-18 上海华御信息技术有限公司 实现物联网终端安全接入的方法
CN104184713A (zh) * 2013-05-27 2014-12-03 阿里巴巴集团控股有限公司 终端识别方法、机器识别码注册方法及相应系统、设备
US20150089593A1 (en) * 2013-09-24 2015-03-26 International Business Machines Corporation Method and system for using a vibration signature as an authentication key

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3310083A4 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106411723A (zh) * 2016-12-12 2017-02-15 郑州云海信息技术有限公司 一种消息处理方法及装置
CN111666189A (zh) * 2020-06-12 2020-09-15 中信银行股份有限公司 一种声明式可视化配置Prometheus监控告警的方法和系统
CN111666189B (zh) * 2020-06-12 2023-03-31 中信银行股份有限公司 一种声明式可视化配置Prometheus监控告警的方法和系统
CN112887099A (zh) * 2021-01-11 2021-06-01 深圳市新国都支付技术有限公司 数据签名方法、电子设备及计算机可读存储介质
CN112887099B (zh) * 2021-01-11 2023-05-16 深圳市新国都支付技术有限公司 数据签名方法、电子设备及计算机可读存储介质

Also Published As

Publication number Publication date
US20180167397A1 (en) 2018-06-14
CN106714075B (zh) 2020-06-26
KR20180022999A (ko) 2018-03-06
EP3310083A1 (en) 2018-04-18
JP2018529245A (ja) 2018-10-04
JP6494149B2 (ja) 2019-04-03
CN106714075A (zh) 2017-05-24
US10666661B2 (en) 2020-05-26
EP3310083A4 (en) 2018-11-21
KR101962156B1 (ko) 2019-03-26

Similar Documents

Publication Publication Date Title
WO2017024791A1 (zh) 一种处理授权的方法和设备
US11201778B2 (en) Authorization processing method, device, and system
JP6280641B2 (ja) アカウントログイン方法、デバイス及びシステム
US9584615B2 (en) Redirecting access requests to an authorized server system for a cloud service
WO2017016252A1 (zh) 令牌生成并认证的方法及认证服务器
US20080141333A1 (en) Method and system for object-based multi-level security in a service oriented architecture
JP2014526171A (ja) ピアツーピアオーバーレイネットワーク内のデータオブジェクトに対するグループアクセス制御の容易化
JP2005339093A (ja) 認証方法、認証システム、認証代行サーバ、ネットワークアクセス認証サーバ、プログラム、及び記録媒体
CN104104654A (zh) 一种设置Wifi访问权限、Wifi认证的方法和设备
KR20170106515A (ko) 다중 팩터 인증 기관
US11245577B2 (en) Template-based onboarding of internet-connectible devices
US9237156B2 (en) Systems and methods for administrating access in an on-demand computing environment
CN114553592A (zh) 一种设备身份验证的方法、设备及存储介质
CN112352411B (zh) 利用不同的云服务网络的相同域的注册
CN103118025B (zh) 基于入网认证的单点登录方法、装置及认证服务器
WO2015021842A1 (zh) 访问ott应用、服务器推送消息的方法及装置
CN113489695B (zh) 私有云组网方法、装置、系统、计算机设备及存储介质
US20220413885A1 (en) Virtual Machine Provisioning and Directory Service Management
CN111737758B (zh) 区块链网络的权限管理方法、装置、设备以及存储介质
US9680871B2 (en) Adopting policy objects for host-based access control
US8627505B2 (en) Technique for controlling access by a client entity to a service
CN117176415A (zh) 集群访问方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16834417

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018500769

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2016834417

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20187003384

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE