CN106656942A

CN106656942A - Role token issuing method, access control method and related equipment

Info

Publication number: CN106656942A
Application number: CN201510740244.8A
Authority: CN
Inventors: 周巍
Original assignee: China Academy of Telecommunications Technology CATT
Current assignee: China Academy of Telecommunications Technology CATT
Priority date: 2015-11-03
Filing date: 2015-11-03
Publication date: 2017-05-10
Anticipated expiration: 2035-11-03
Also published as: CN106656942B

Abstract

The invention discloses a role token issuing method, an access control method and related equipment, which are used for providing role-based access control for oneM2M. The issuing process is that a CSE receives a role resource establishment request sent by a role token issuing entity, wherein the role resource establishment request carries a role identifier issued to an initiation party entity and a role token corresponding to the role identifier; and according to the role identifier and the role token, establishing role resources under resources corresponding to the initiation party entity, wherein the role resources are common resources and store the role identifier and the role token.

Description

Role token issuing method, access control method and related equipment

Technical Field

The invention relates to the technical field of communication, in particular to a role token issuing method, an access control method and related equipment.

Background

The internet of things standardization organization oneM2M is dedicated To developing technical specifications for constructing a common Machine-To-Machine communication (M2M) Service Layer (Service Layer).

oneM2M functional architecture as shown in fig. 1, three basic entities are defined:

an Application Entity (AE), located at the Application layer, may implement an M2M Application service logic. An application service logic may reside in multiple M2M nodes or there may be multiple instances of execution in a single node. Each instance of execution of the application service logic is referred to as an application entity, each identified by a unique AE identity (AE-ID).

For example, a fleet tracking application instance, a remote blood glucose monitoring application instance, a remote electricity metering instance, or a control application instance, etc., all belong to the application entities.

Two, Common Services Entity (CSE), a Common Services Entity is composed of a group of Common service functions (Common service functions) in an M2M environment. The common service function is disclosed to other entities by reference points Mca and reference points Mcc. Reference point Mcn is used to access the underlying network service entity. Each common service entity is identified by a unique CSE-ID.

Third, an Underlying Network Services Entity (NSE), one of which provides Underlying Network Services to the CSEs, for example, device management, location Services, and device triggering Services.

oneM2M enables service level resource sharing and interaction through operations on standardized resource trees. The oneM2M resource tree exists in the CSE defined by the oneM2M system.

The form of oneM2M resource tree is shown in FIG. 2, according to the definition of functional architecture in oneM2M TS-0001. Wherein CSEBase1 represents a CSE root resource < CSEBase >, CSE1 represents a resource < remoteCSE >, APP1 represents a resource < AE >, CONT1 and CONT2 respectively represent a container resource < container >, ACP1 and ACP2 respectively represent a resource < accesscontrol policy >. For oneM2M resource, operations such as Create (Create, abbreviated as C), query (Retrieve, abbreviated as R), modify (Update, abbreviated as U), Delete (Delete, abbreviated as D) and the like can be performed.

oneM2M defines a resource related to authorization as an Access Control Policy resource < accesscontrol Policy >, where an Access Control Policy (ACP) is defined, and the < accesscontrol Policy > resource is uniquely identified by a resource Identity (ID). Other resources specify the applicable access control policy via the accessControlPolicyIDs attribute in the resource. The privileges in < accessControlPolicy > resource (privilees) attribute is used to store specific access control rules, and the self-management privileges (selfpivileges) attribute is used to store access control rules that maintain < accessControlPolicy > resource.

oneM2M security resolution specification oneM2M TS-0003 gives an evaluation of authorization architecture and access control policies. In the authorization architecture shown in fig. 3, the functions of each authorization component are:

policy Enforcement Point (PEP) coexists with and is called by an application system that needs access control. The PEP generates a corresponding access control Decision request according to the access request of the user, sends the access control Decision request to a Policy Decision Point (PDP), and determines whether to execute the access request of the user according to an access control Decision response of the PDP.

The Policy Decision Point (PDP) is responsible for evaluating whether to grant the access control Decision request sent by the PEP according to the access control Policy, and returning the evaluation result to the PEP through an access control Decision response.

A Policy Retrieval Point (PRP) retrieves an applicable access control Policy according to a Policy request provided by the PDP, and returns the retrieved access control Policy to the PDP.

A Policy Information Point (PIP) acquires attributes related to a user, a resource, or an environment, such as an Internet Protocol (IP) address of an access user, a creator of the resource, a current time, etc., according to a request of the PDP, and then returns the acquired various attributes to the PDP.

The basic authorization flow for oneM2M is as follows:

1. the PEP generates an Access control decision Request (Access control decision Request) according to the Access Request of the user and sends the Access control decision Request to the PDP;

2. the PDP sends an Access Control Policy Request (Access Control Policy Request) to the PRP according to the Access Control decision Request of the PEP;

3. the PDP analyzes the Access control policy returned by the PRP and the content provided in the Access control decision Request of the PEP, and if other attributes are required, sends an Access control attribute Request (Access control attribute Request) to the PIP, otherwise, executes step 5.

4. And the PIP acquires corresponding attributes related to the access control according to the access control attribute request of the PDP and returns the corresponding attributes to the PDP.

5. The PDP returns an access control decision Response (Access control Attribute Response) to the PEP according to the determined applicable access control policy.

6. And the PEP determines whether to execute the access request of the user according to the access control strategy in the access control decision response.

oneM2M phase two (Release 2) will study and formulate the interfaces between the components of the authorization architecture and will support a wider variety of access control policies, such as role-based access control, attribute-based access control, etc. It is clear that the new feature of role-based access control will be supported in Release2, but there is no solution for how to implement role-based access control.

Disclosure of Invention

The embodiment of the invention provides a role token issuing method, an access control method and related equipment, which are used for providing role-based access control for oneM 2M.

The embodiment of the invention provides the following specific technical scheme:

in a first aspect, a role token issuance method is provided, including:

a public service entity CSE receives a role resource creating request sent by a role token issuing entity, wherein the role resource creating request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

and the CSE creates role resources under the resources corresponding to the initiator entity according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

Preferably, after the CSE creates role resources under the resource corresponding to the initiator entity according to the role identifier and the role token, the method further includes:

and the CSE returns a role resource creating response to the role token issuing entity.

the CSE receives a role resource modification request sent by the role token issuing entity, wherein the role resource modification request carries a role identifier issued to the initiator entity again and a role token corresponding to the role identifier issued again;

and the CSE modifies the role resource according to the role identification which is issued again and the role token corresponding to the role identification which is issued again.

Preferably, after the CSE modifies the role resource according to the reissued role identifier and the role token corresponding to the reissued role identifier, the method further includes:

and the CSE returns a role resource modification response to the role token issuing entity.

Preferably, the role resource has a general attribute of a common resource, and also has a common attribute specifying expiration time and a subscription sub-resource.

Preferably, the role resource has a role identification attribute, a role token issuer identification attribute, a role token valid start time attribute, a role token valid end time attribute and a token value attribute, the role identification attribute is used for storing a role identification, the role token issuer identification attribute is used for storing a role token issuer identification, the role token valid start time attribute is used for storing a role token valid start time, the role token valid end time attribute is used for storing a role token valid end time, and the token value attribute is used for storing the role token;

the role token is stored with a role token identifier, a role token owner identifier, a role token issuer identifier, a role token valid start time and a role token valid end time.

Preferably, the role resource further has any one or more of a role type attribute, a role name attribute and an application category attribute, the role type attribute is used for storing a role type, the role name attribute is used for storing a role readable name, and the application category attribute is used for storing an application category to which a role belongs;

the role token also stores any one or more of a role type, a role readable name, and an application category to which the role belongs.

Preferably, the method further comprises:

the CSE receives a resource reading request of the initiator entity to the role resource;

and the CSE returns a resource reading response to the initiator entity, wherein the resource reading response carries the role identification and/or the role token.

Preferably, before the CSE creates a role resource under a resource corresponding to the initiator entity according to the role identifier and the role token, the method further includes:

and the CSE determines to allow the role token issuing entity to create the role resource according to the access control strategy of the resource corresponding to the initiator entity.

Preferably, before the CSE modifies the role resource according to the reissued role identifier and the role token corresponding to the reissued role identifier, the method further includes:

and the CSE determines to allow the role token issuing entity to modify the role resource according to the access control strategy of the resource corresponding to the initiator entity.

In a second aspect, a role token issuance method is provided, including:

a role token issuing entity generates a role resource creating request, wherein the role resource creating request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

and the role token issuing entity sends the role resource creating request to a public service entity (CSE), and the CSE creates role resources under the resources corresponding to the initiator entity according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

Preferably, after the role token issuing entity sends the role resource creation request to the CSE, the method further includes:

and the role token issuing entity receives the role resource creation response returned by the CSE.

Preferably, after the role token issuing entity receives the role resource creation response returned by the CSE, the method further includes:

and the role token issuing entity sends the indication information of the created address information of the role resource to the initiator entity and sends the indication information of the created address information of the role resource to a Policy Decision Point (PDP) entity and/or a Policy Information Point (PIP) entity.

the role token issuing entity generates a role resource modification request, wherein the role resource modification request carries the role identification re-issued to the initiator entity and the role token corresponding to the re-issued role identification;

the role token issuing entity sends the role resource modification request to the CSE.

Preferably, after the role token issuing entity sends the role resource modification request to the CSE, the method further includes:

and the role token issuing entity receives the role resource modification response returned by the CSE.

In a third aspect, a role token issuance method is provided, including:

an initiator entity sends a resource reading request of role resources under resources corresponding to the initiator entity to a Common Service Entity (CSE), wherein the role resources are common resources and store role identifiers of the initiator entity and role tokens corresponding to the role identifiers;

and the initiator entity receives a resource reading response returned by the CSE, wherein the resource reading response carries the role token and/or the role identifier stored in the role resource.

In a fourth aspect, an access control method is provided, including:

a Policy Enforcement Point (PEP) entity acquires a resource access request sent by an initiator entity, wherein the resource access request carries a role identifier and/or a role token of the initiator entity;

the PEP entity generates an access control decision request according to the resource access request, wherein the access control decision request carries the role identification and/or the role token of the initiator entity;

the PEP entity sends the access control decision request to a Policy Decision Point (PDP) entity, and the PDP entity determines a decision result according to an access control policy and the role identifier and/or the role token;

the PEP entity obtains an access control decision response returned by the PDP entity, wherein the access control decision response carries the decision result;

and the PEP entity performs access control on the resource access request of the initiator entity according to the decision result.

In a fifth aspect, an access control method is provided, including:

a policy decision point PDP entity receives an access control decision request sent by a policy enforcement point PEP entity, wherein the access control decision request carries a role identifier of an initiator entity initiating a resource access request;

the PDP entity queries the role resource corresponding to the initiator entity according to the role identifier to obtain a role token corresponding to the role identifier, and determines a decision result according to the role token and an access control strategy, wherein the role resource is a common resource and stores the role identifier and the role token of the initiator entity;

and the PDP entity returns an access control decision response to the PEP entity, and the access control decision response carries the decision result.

Preferably, the step of querying, by the PDP entity according to the role identifier, the role resource corresponding to the initiator entity to obtain the role token corresponding to the role identifier includes:

the PDP entity sends an inquiry request for role resources of the initiator entity to a public service entity (CSE), wherein the inquiry request carries the role identifier, and acquires an inquiry response returned by the CSE, wherein the inquiry response carries a role token corresponding to the role identifier;

or,

and the PDP entity sends an access control attribute request to a Policy Information Point (PIP) entity, wherein the access control attribute request carries the role identifier, and receives an access control attribute response returned by the PIP entity, wherein the access control attribute response carries a role token corresponding to the role identifier, which is obtained by the PIP entity inquiring the role resource corresponding to the initiator entity according to the role identifier.

Preferably, the determining, by the PDP entity, a decision result according to the role token and the access control policy includes:

and if the PDP entity determines that the role token is valid, extracting role information from the role token, and determining a decision result according to the role information and the access control strategy.

Preferably, the determining, by the PDP entity, that the role token is valid includes:

and the PDP entity determines that the role issuer identification of the role token belongs to a legal token issuing organization, and determines that the role token is in a valid period according to the valid starting time of the role token and the valid ending time of the role token.

In a sixth aspect, there is provided an access control method, including:

a policy decision point PDP entity receives an access control decision request sent by a policy enforcement point PEP entity, wherein the access control decision request carries a role token of an initiator entity initiating a resource access request;

the PDP entity determines a decision result according to the role token and the access control strategy;

In a seventh aspect, an access control method is provided, including:

a Policy Information Point (PIP) entity receives an access control attribute request sent by a Policy Decision Point (PDP) entity, wherein the access control attribute request carries a role identifier of an initiator entity initiating a resource access request;

the PIP entity inquires whether a role token corresponding to the role identifier exists in a role resource corresponding to the initiator entity from a public service entity (CSE) according to the role identifier and obtains an inquiry result, wherein the role resource is a common resource and stores the role identifier and the role token of the initiator entity;

and the PIP entity returns an access control attribute response to the PDP entity, wherein the access control attribute response carries the query result.

In an eighth aspect, there is provided a common service entity, CSE, comprising:

the receiving module is used for receiving a role resource creating request sent by a role token issuing entity, wherein the role resource creating request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

and the processing module is used for creating role resources under the resources corresponding to the initiator entity according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

Preferably, the receiving module is further configured to:

receiving a resource reading request of the initiator entity for the role resource;

the system further comprises a first sending module, configured to:

and returning a resource reading response to the initiator entity, wherein the resource reading response carries the role identification and/or the role token.

Preferably, the system further comprises a second sending module, configured to:

and after the processing module creates role resources under the resources corresponding to the initiator entity according to the role identifiers and the role tokens, returning role resource creation response to the role token issuing entity.

Preferably, the receiving module is further configured to:

receiving a role resource modification request sent by the role token issuing entity, wherein the role resource modification request carries a role identifier re-issued to the initiator entity and a role token corresponding to the re-issued role identifier;

the processing module is further configured to:

and modifying the role resource according to the role identifier reissued and the role token corresponding to the role identifier reissued.

Preferably, the system further comprises a third sending module, configured to:

and after the processing module modifies the role resource according to the re-issued role identifier and the role token corresponding to the re-issued role identifier, returning a role resource modification response to the role token issuing entity.

Preferably, the processing module is further configured to:

and determining to allow the role token issuing entity to create the role resource according to the access control strategy of the resource corresponding to the initiator entity before the role resource is created under the resource corresponding to the initiator entity according to the role identifier and the role token.

Preferably, the processing module is further configured to:

and determining that the role token issuing entity is allowed to modify the role resource according to the access control strategy of the resource corresponding to the initiator entity before modifying the role resource according to the re-issued role identifier and the role token corresponding to the re-issued role identifier.

In a ninth aspect, there is provided a role token issuing entity comprising:

the processing module is used for generating a role resource creating request, wherein the role resource creating request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

and the sending module is used for sending the role resource creating request to a public service entity (CSE), and the CSE creates role resources under the resources corresponding to the initiator entity according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

Preferably, the mobile terminal further comprises a first receiving module, configured to: and receiving a role resource creation response returned by the CSE.

Preferably, the sending module is further configured to:

and sending the created indication information of the address information of the role resources to the initiator entity, and sending the created indication information of the address information of the role resources to a Policy Decision Point (PDP) entity and/or a Policy Information Point (PIP) entity.

Preferably, the processing module is further configured to:

generating a role resource modification request, wherein the role resource modification request carries the role identification reissued to the initiator entity and a role token corresponding to the reissued role identification;

the sending module is further configured to:

sending the role resource modification request to the CSE.

Preferably, the mobile terminal further comprises a second receiving module, configured to:

and receiving a role resource modification response returned by the CSE.

In a tenth aspect, there is provided an initiator entity comprising:

a sending module, configured to send a resource reading request for a role resource under a resource corresponding to an initiator entity to a common service entity CSE, where the role resource is a common resource and stores a role identifier of the initiator entity and a role token corresponding to the role identifier;

and the receiving module is used for receiving a resource reading response returned by the CSE, wherein the resource reading response carries the role token and/or the role identifier stored in the role resource.

In an eleventh aspect, there is provided a policy enforcement point PEP entity, comprising:

a first obtaining module, configured to obtain a resource access request sent by an initiator entity, where the resource access request carries a role identifier and/or a role token of the initiator entity;

a generating module, configured to generate an access control decision request according to the resource access request, where the access control decision request carries a role identifier and/or a role token of the initiator entity;

a sending module, configured to send the access control decision request to a policy decision point PDP entity, where the PDP entity determines a decision result according to an access control policy and the role identifier and/or the role token;

a second obtaining module, configured to obtain an access control decision response returned by the PDP entity, where the access control decision response carries the decision result;

and the access control module is used for performing access control on the resource access request of the initiator entity according to the decision result.

In a twelfth aspect, there is provided a policy decision point PDP entity, comprising:

the system comprises a receiving module, a Policy Enforcement Point (PEP) entity and a resource access module, wherein the receiving module is used for receiving an access control decision request sent by the PEP entity of the policy enforcement point, and the access control decision request carries a role identifier of an initiator entity initiating a resource access request;

the processing module is used for inquiring the role resource corresponding to the initiator entity according to the role identifier to obtain a role token corresponding to the role identifier, and determining a decision result according to the role token and an access control strategy, wherein the role resource is a common resource and stores the role identifier and the role token of the initiator entity;

and the sending module is used for returning an access control decision response to the PEP entity, and the access control decision response carries the decision result.

Preferably, the processing module is specifically configured to:

sending an inquiry request for role resources of the initiator entity to a public service entity (CSE) through the sending module, wherein the inquiry request carries the role identifier, and obtaining an inquiry response returned by the CSE through the receiving module, wherein the inquiry response carries a role token corresponding to the role identifier;

or,

and sending an access control attribute request to a Policy Information Point (PIP) entity through the sending module, wherein the access control attribute request carries the role identifier, and receiving an access control attribute response returned by the PIP entity through the receiving module, wherein the access control attribute response carries a role token corresponding to the role identifier, which is obtained by inquiring the role resource corresponding to the initiator entity according to the role identifier by the PIP entity.

Preferably, the processing module is specifically configured to:

and if the role token is determined to be valid, extracting role information from the role token, and determining a decision result according to the role information and the access control strategy.

Preferably, the processing module is specifically configured to:

and determining that the role issuer identification of the role token belongs to a legal token issuing organization, and determining that the role token is in a valid period according to the valid starting time of the role token and the valid ending time of the role token.

In a thirteenth aspect, there is provided a policy decision point PDP entity, comprising:

the system comprises a receiving module, a Policy Enforcement Point (PEP) entity and a resource access module, wherein the receiving module is used for receiving an access control decision request sent by the PEP entity of the policy enforcement point, and the access control decision request carries a role token of an initiator entity initiating a resource access request;

the processing module is used for determining a decision result according to the role token and the access control strategy;

Preferably, the processing module is specifically configured to:

In a fourteenth aspect, there is provided a policy information point, PIP, entity, comprising:

the access control system comprises a receiving module, a judging module and a processing module, wherein the receiving module is used for receiving an access control attribute request sent by a policy decision point PDP entity, and the access control attribute request carries a role identifier of an initiator entity initiating a resource access request;

the processing module is used for inquiring whether a role token corresponding to the role identifier exists in the role resource corresponding to the initiator entity from a public service entity (CSE) according to the role identifier and obtaining an inquiry result, wherein the role resource is a common resource and stores the role identifier and the role token of the initiator entity;

and the sending module is used for returning an access control attribute response to the PDP entity, and the access control attribute response carries the query result.

In a fifteenth aspect, a common service entity CSE is provided, which includes a processor, a memory, and a transceiver, wherein the transceiver is configured to receive and transmit data under the control of the processor, the memory stores a preset program, and the processor reads the program stored in the memory, and executes the following procedures according to the program:

receiving a role resource creation request sent by a role token issuing entity through a transceiver, wherein the role resource creation request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

and creating role resources under resources corresponding to the initiator entity according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

Preferably, the processor returns a role resource creation response to the role token issuing entity through the transceiver after creating the role resource under the resource corresponding to the initiator entity according to the role identifier and the role token.

Preferably, the processor receives a role resource modification request sent by the role token issuing entity through the transceiver, where the role resource modification request carries the role identifier reissued to the initiator entity and the role token corresponding to the reissued role identifier;

Preferably, after modifying the role resource according to the reissued role identifier and the role token corresponding to the reissued role identifier, the processor returns a role resource modification response to the role token issuing entity through the transceiver.

Preferably, the processor receives a resource reading request of the initiator entity for the role resource through the transceiver; and returning a resource reading response to the initiator entity through the transceiver, wherein the resource reading response carries the role identification and/or the role token.

Preferably, before the processor creates the role resource under the resource corresponding to the initiator entity according to the role identifier and the role token, the processor determines to allow the role token issuing entity to create the role resource according to an access control policy of the resource corresponding to the initiator entity.

Preferably, before modifying the role resource according to the reissued role identifier and the role token corresponding to the reissued role identifier, the processor determines to allow the role token issuing entity to modify the role resource according to the access control policy of the resource corresponding to the initiator entity.

In a sixteenth aspect, there is provided a character token issuing entity, including a processor, a memory, and a transceiver, where the transceiver is used to receive and send data under the control of the processor, the memory stores a preset program, and the processor reads the program stored in the memory, and executes the following processes according to the program:

generating a role resource creating request, wherein the role resource creating request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

and sending the role resource creation request to a public service entity (CSE) through a transceiver, and creating role resources under the resources corresponding to the initiator entity by the CSE according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

Preferably, the processor receives the role resource creation response returned by the CSE through the transceiver.

Preferably, the processor sends the created indication information of the address information of the role resource to the initiator entity and sends the created indication information of the address information of the role resource to a policy decision point PDP entity and/or a policy information point PIP entity through the transceiver.

Preferably, the processor generates a role resource modification request, where the role resource modification request carries the role identifier reissued to the initiator entity and the role token corresponding to the reissued role identifier; sending, by a transceiver, the role resource modification request to the CSE.

Preferably, the processor receives the role resource modification response returned by the CSE through the transceiver.

In a seventeenth aspect, there is provided an initiator entity, including a processor, a memory, and a transceiver, where the transceiver is used to receive and transmit data under the control of the processor, the memory stores a preset program, and the processor reads the program stored in the memory, and executes the following procedures according to the program:

sending a resource reading request of a role resource under a resource corresponding to an initiator entity to a public service entity (CSE) through a transceiver, wherein the role resource is a common resource and stores a role identification of the initiator entity and a role token corresponding to the role identification;

and receiving a resource reading response returned by the CSE through a transceiver, wherein the resource reading response carries the role token and/or the role identifier stored in the role resource.

In an eighteenth aspect, a policy enforcement point PEP entity is provided, which includes a processor, a memory, and a transceiver, where the transceiver is used to receive and transmit data under the control of the processor, the memory stores a preset program, and the processor reads the program stored in the memory, and executes the following processes according to the program:

acquiring a resource access request sent by an initiator entity through a transceiver, wherein the resource access request carries a role identifier and/or a role token of the initiator entity;

generating an access control decision request according to the resource access request, wherein the access control decision request carries the role identification and/or the role token of the initiator entity;

sending the access control decision request to a Policy Decision Point (PDP) entity through a transceiver, and determining a decision result by the PDP entity according to an access control policy and the role identifier and/or the role token;

obtaining an access control decision response returned by the PDP entity through a transceiver, wherein the access control decision response carries the decision result;

and performing access control on the resource access request of the initiator entity according to the decision result.

In a nineteenth aspect, a policy decision point PDP entity is provided, which includes a processor, a memory, and a transceiver, where the transceiver is used to receive and transmit data under the control of the processor, the memory stores a preset program, and the processor reads the program stored in the memory, and executes the following processes according to the program:

receiving an access control decision request sent by a Policy Enforcement Point (PEP) entity through a transceiver, wherein the access control decision request carries a role identifier of an initiator entity initiating a resource access request;

inquiring a role resource corresponding to the initiator entity according to the role identifier to obtain a role token corresponding to the role identifier, and determining a decision result according to the role token and an access control strategy, wherein the role resource is a common resource and stores the role identifier and the role token of the initiator entity;

and returning an access control decision response to the PEP entity through a transceiver, wherein the access control decision response carries the decision result.

Preferably, the processor sends an inquiry request for role resources of the initiator entity to a common service entity CSE through the transceiver, where the inquiry request carries the role identifier, and obtains an inquiry response returned by the CSE through the transceiver, where the inquiry response carries a role token corresponding to the role identifier;

or,

sending an access control attribute request to a Policy Information Point (PIP) entity through a transceiver, wherein the access control attribute request carries the role identifier, and receiving an access control attribute response returned by the PIP entity through the transceiver, wherein the access control attribute response carries a role token corresponding to the role identifier, which is obtained by inquiring a role resource corresponding to the initiator entity through the PIP entity according to the role identifier.

Preferably, the processor extracts role information from the role token if the role token is determined to be valid, and determines a decision result according to the role information and the access control policy.

Preferably, the processor determines that the role token's role issuer identification belongs to a legitimate token issuing authority, and determines that the role token is within the validity period based on the role token's valid start time and the role token's valid end time.

In a twentieth aspect, a policy decision point PDP entity is provided, including a processor, a memory, and a transceiver, where the transceiver is configured to receive and transmit data under the control of the processor, the memory stores a preset program, and the processor reads the program stored in the memory, and executes the following procedures according to the program:

receiving an access control decision request sent by a Policy Enforcement Point (PEP) entity through a transceiver, wherein the access control decision request carries a role token of an initiator entity initiating a resource access request;

determining a decision result according to the role token and an access control strategy;

In a twenty-first aspect, there is provided a policy information point, PIP, entity, comprising a processor, a memory and a transceiver, the transceiver is configured to receive and transmit data under the control of the processor, the memory stores a preset program, the processor reads the program stored in the memory, and according to the program, the following processes are performed:

receiving an access control attribute request sent by a Policy Decision Point (PDP) entity through a transceiver, wherein the access control attribute request carries a role identifier of an initiator entity initiating a resource access request;

inquiring whether a role token corresponding to the role identification exists in a role resource corresponding to the initiator entity from a public service entity (CSE) according to the role identification, and obtaining an inquiry result, wherein the role resource is a common resource and stores the role identification and the role token of the initiator entity;

and returning an access control attribute response to the PDP entity through the transceiver, wherein the access control attribute response carries the query result.

Based on the above technical solution, in the embodiment of the present invention, a role resource is created under a resource corresponding to an initiator entity, and the role resource is a common resource and is used for storing a role identifier and a role token corresponding to the role identifier, so that the role token can be obtained through an operation on the role resource, and role-based access control is implemented in oneM2M based on the obtained role token.

Drawings

Fig. 1 is a schematic diagram of oneM2M functional architecture;

FIG. 2 is a schematic structural diagram of a oneM2M resource tree;

fig. 3 is a schematic diagram of oneM2M authorization architecture;

FIG. 4 is a diagram illustrating a structure of a role token according to an embodiment of the present invention;

FIG. 5 is a diagram illustrating a basic structure of a role resource according to an embodiment of the present invention;

FIG. 6 is a diagram illustrating the structure of < AE > resource in an embodiment of the present invention;

FIG. 7 is a flow chart illustrating a method for issuing a role executed by a CSE according to an embodiment of the present invention;

FIG. 8 is a flowchart illustrating a method for issuing a role token by a role token issuing entity according to an embodiment of the present invention;

FIG. 9 is a flowchart illustrating a method for an initiator entity to obtain an issued role token according to an embodiment of the present invention;

FIG. 10 is a flowchart illustrating a method for performing access control by a PEP according to an embodiment of the present invention;

fig. 11 is a flowchart illustrating a method for performing access control by a PDP entity according to an embodiment of the present invention;

fig. 12 is a flowchart illustrating a method for performing access control by another PDP entity according to an embodiment of the present invention;

fig. 13 is a flowchart illustrating a method for access control of a PIP entity according to an embodiment of the present invention;

FIG. 14 is a diagram illustrating a process for issuing and using a character token according to an embodiment of the present invention;

FIG. 15 is a diagram illustrating entity relationships in an embodiment of the present invention;

FIG. 16 is a diagram illustrating a structure of a related resource tree in CSE1 according to an embodiment of the present invention;

FIG. 17 is a schematic diagram of another role token issuance and use process in accordance with an embodiment of the present invention;

FIG. 18 is a schematic diagram of the CSE structure in an embodiment of the present invention;

FIG. 19 is a block diagram of a role token issuing entity in an embodiment of the present invention;

FIG. 20 is a block diagram of an initiator entity in an embodiment of the present invention;

FIG. 21 is a schematic structural diagram of a PEP entity in an embodiment of the present invention;

FIG. 22 is a diagram illustrating a structure of a PDP entity according to an embodiment of the present invention;

FIG. 23 is a diagram illustrating another PDP entity according to an embodiment of the present invention;

fig. 24 is a diagram illustrating a PIP entity according to an embodiment of the present invention;

FIG. 25 is a schematic diagram of another CSE according to an embodiment of the present invention;

FIG. 26 is a block diagram of another role token issuing entity in accordance with an embodiment of the present invention;

fig. 27 is a schematic structural diagram of another initiator entity in the embodiment of the present invention;

FIG. 28 is a schematic structural diagram of another PEP entity in an embodiment of the present invention;

FIG. 29 is a diagram illustrating another PDP entity according to an embodiment of the present invention;

FIG. 30 is a diagram illustrating another PDP entity according to an embodiment of the present invention;

fig. 31 is a schematic structural diagram of another PIP entity in the embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The embodiment of the invention defines a oneM2M resource and a role token, wherein the defined resource is a role resource < role > and is used for storing role tokens and description information of the role tokens in a CSE resource tree, one role token corresponds to one role, the description information of the role tokens at least comprises role identifications corresponding to the role tokens, and the description information of the role tokens is used for managing the role tokens.

IN particular, the < role > resource may be located under the < CSEBase >, < remoteCSE >, < AE > and the like resources IN oneM2M infrastructure node IN-CSE, so that these resources can store the role token assigned to themselves and the description information of the role token using their corresponding < role > resource. There may be one or more role resource instances under < CSEBase >, < remoteCSE > or < AE > resources IN an IN-CSE, one role resource instance corresponding to one role token and its description information.

The role token defined by the present invention has a structure as shown in fig. 4, and is composed of token content and a token security mechanism, wherein the token security mechanism can provide integrity and confidentiality protection for the token, and the specific implementation of the token security mechanism is not the content concerned by the present invention.

The main contents stored in the role token are as follows:

token ID: a role token identification capable of uniquely identifying the role token.

HolderiD: role token owner identification.

roleID: and identifying roles.

An issuer: a role token issuer identification.

startTime: role token valid start time.

expiryTime: a role token valid end time.

roleType: a Role type for distinguishing whether the Role is a Service Subscription Role (Service Subscription Role) defined by oneM2M Service Provider (M2ms Service Provider) or a Role related to a specific Application defined by oneM2M Application Service Provider (M2M Application Service Provider).

roleName: the character can read the name.

appCategory: the application categories to which the roles belong, such as device management application, smart home application, smart transportation application, and the like.

Wherein, the rolType, the roleName and the appCategory are optional contents, and one role token can contain any one or more of the rolType, the roleName and the appCategory.

The basic structure of the < role > Resource is shown in fig. 5, and the Resource type is oneM2M Normal Resource (Normal Resource). The < role > resource has a Common Attribute (Common Attribute) specifying an expiration time (expirationTime) and a subscription < description > sub-resource in addition to a Common Attribute (Universal Attribute) Common to oneM2M Common resources. Each < role > resource instance is used to describe a role token, and a role token corresponds to the description information of a role. The specific use of the resource attribute of < role > resource is defined as:

role identification (role id) attribute: the user saves the role identification.

Role token issuer (issuer) identification attribute: for saving the role token issuer identification.

Role token valid start time (startTime) attribute: for saving the role token valid start time.

Role token valid end time (expiryTime) attribute: for saving the role token valid end time.

Role type (roleType) attribute: for distinguishing whether the role corresponding to the role token is a Service subscription role (Service subscription role) defined by oneM2M Service Provider (M2M Service Provider) or a role related to a specific Application defined by oneM2M Application Service Provider (M2M Application Service Provider).

Role name (roleName) attribute: for saving the readable names of the characters.

Application category (role app category) attribute: the method is used for saving application categories to which roles belong, such as equipment management application, intelligent home application, intelligent transportation application and the like.

Token value (token value) attribute: for storing the role token for that role.

The role resource may have any one or more of the roleType attribute, the roleName attribute, and the roleAppcategory attribute.

As shown in fig. 6, the < AE > resource is defined as a structure in which the < role > resource is added to the existing < AE > resource as a sub-resource, the number of < role > sub-resources under the < AE > resource may be zero or n, and n is greater than or equal to 1 and is used to indicate a role assigned to AE. Similarly, the < CSEBase > resource and the < remoteCSE > resource are defined similarly to the < AE > resource, the < role > resource is added as a sub-resource to the < CSEBase > resource, the < role > resource is added as a sub-resource to the < remoteCSE > resource, the number of the < role > sub-resources to the < CSEBase > resource or the < remoteCSE > resource may be zero or n, and n is greater than or equal to 1.

In the embodiment of the invention, entities related to the role token issuing and using process are defined as follows:

role Token issuance entity (Role Token Authority): responsible for issuing role tokens to AE or CSE;

initiator (Originator): the object is AE or CSE, is issued by a role token and is used for accessing resources by using the role token;

registration response cse (registry cse): originator registers to the CSE, namely the registered resource of the Originator is created in the CSE;

host cse (holding cse): the resource that the Originator wants to access exists in the resource tree of the CSE, and the registration CSE and the Hosting CSE can be the same CSE or different CSEs in practical application;

policy Enforcement Point (PEP): responsible for executing the access request of the user according to the access control decision, the PEP exists in the HostCSE;

policy Decision Point (PDP): the system is responsible for evaluating the access request of the user by utilizing the access control strategy and making an access control decision;

policy Information Point (PIP): the system is responsible for acquiring attributes related to access control;

in practical application, the PDP may obtain the required attributes through the PIP, or may directly obtain the required information from the resource corresponding to the initiator.

Based on the above definitions, in the embodiment of the present invention, as shown in fig. 7, a CSE storing a resource corresponding to an initiator entity is taken as an execution subject, where the CSE may be an entity storing a registered resource of the initiator entity, or an entity storing a non-registered resource of the initiator entity, and a detailed method flow for issuing a role token is as follows:

step 701: and the CSE receives a role resource creating request sent by a role token issuing entity, wherein the role resource creating request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier.

Step 702: and the CSE creates role resources under the resources corresponding to the initiator entity according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

Preferably, after the CSE creates the role resource under the resource corresponding to the initiator entity according to the role identifier and the role token, the CSE returns a role resource creation response to the role token issuing entity, where the role resource creation response is used to notify the role token issuing entity whether the role resource is created successfully.

Preferably, after the CSE creates the role resource under the resource corresponding to the initiator entity according to the role identifier and the role token, the role resource may be modified, specifically:

the CSE receives a role resource modification request sent by a role token issuing entity, wherein the role resource modification request carries a role identifier issued to the initiator entity again and a role token corresponding to the role identifier issued again; and modifying the role resource according to the role identifier reissued and the role token corresponding to the role identifier reissued.

Preferably, after the CSE modifies the role resource according to the reissued role identifier and the role token corresponding to the reissued role identifier, the CSE returns a role resource modification response to the role token issuing entity, where the role resource modification response is used to notify the role token issuing entity whether the role resource is modified successfully.

Preferably, the CSE receives a resource reading request for the role resource from the initiator entity; and returning a resource reading response to the initiator entity, wherein the resource reading response carries the role identification and/or the role token.

In implementation, if the resource corresponding to the initiator entity is the registration resource of the initiator entity, the CSE storing the registration resource is the registration response CSE. If the resource corresponding to the initiator entity is not the registration resource of the initiator entity, the CSE storing the resource may be any CSE.

Preferably, the CSE performs access control on operations related to a resource corresponding to the initiator entity according to an access control policy associated with the resource. Specifically, before the CSE creates a role resource under a resource corresponding to an initiator entity according to a role identifier and a role token, the CSE determines to allow the role token issuing entity to create the role resource according to an access control policy of the resource corresponding to the initiator entity. Specifically, before the CSE modifies the role resource according to the reissued role identifier and the role token corresponding to the reissued role identifier, the CSE determines to allow the role token issuing entity to modify the role resource according to the access control policy of the resource corresponding to the initiator entity. In an implementation, an access control policy associated with a resource corresponding to an initiator entity specifies entities that are allowed to access the resource.

Based on the above definitions, in the embodiment of the present invention, as shown in fig. 8, a detailed method flow of a role token issuing entity for issuing a role token is as follows:

step 801: and the role token issuing entity generates a role resource creating request, wherein the role resource creating request carries the role identification issued to the initiator entity and the role token corresponding to the role identification.

Specifically, the role resource creation request may carry one or more of a role token issuer identifier, a role token valid start time, a role token valid end time, a role type, a role readable name, and an application category to which the role belongs, in addition to the role identifier issued to the initiator entity and the role token corresponding to the role identifier.

Step 802: and the CSE creates role resources under the resources corresponding to the initiator entity according to the role identifiers and the role tokens, wherein the role resources are common resources and store the role identifiers and the role tokens.

The CSE is stored with resources corresponding to an initiator entity, if the resources corresponding to the initiator entity are registered resources, the CSE is a registration response CSE, and if the resources corresponding to the initiator entity are not registered resources, the CSE is any entity which is stored with the resources corresponding to the initiator entity and can create role resources under the resources.

Preferably, after the role token issuing entity sends the role resource creation request to the CSE, the role resource creation response returned by the CSE is received, where the role resource creation response is used to indicate whether the role resource is successfully created.

In implementation, if the resource corresponding to the initiator entity is not the registered resource of the initiator entity, the role token issuing entity sends the indication information of the address information of the created role resource to the initiator entity; and sending the indication information of the address information of the role resource created by the initiator entity to the PDP entity and/or the PIP entity. Specifically, the indication information of the address information of the role resource may be address information of the role resource, or address information of a resource corresponding to an initiator entity in which the role resource is located.

Preferably, after the role token issuing entity sends the role resource creation request to the CSE, the role resource may be modified, specifically: the role token issuing entity generates a role resource modification request, wherein the role resource modification request carries the role identification re-issued to the initiator entity and the role token corresponding to the re-issued role identification; the role token issuing entity sends a role resource modification request to the CSE.

Preferably, after the role token issuing entity sends the role resource modification request to the CSE, a role resource modification response returned by the CSE is received, where the role resource modification response is used to indicate whether the role resource is successfully modified.

In the above embodiment, a role resource is created under a resource corresponding to an initiator entity, and a role token corresponding to a role identifier is stored in the role resource, so that after a PEP entity obtains a resource access request carrying the role identifier of the initiator entity, a PDP entity queries the role token corresponding to the role identifier from the role resource corresponding to the initiator entity to obtain a query result, and the PDP entity issues the initiator entity according to the query result and whether the role identifier carried in the resource access request is actually issued, and if the initiator entity is actually issued, a decision result for the resource access request is determined according to an access control policy and the role token corresponding to the role identifier, thereby implementing access control based on roles.

Or, creating a role resource under a resource corresponding to an initiator entity, and storing a role identifier and a role token corresponding to the role identifier in the role resource, so that after the PEP entity obtains a resource access request carrying the role token of the initiator entity, the PDP entity determines whether the role token and the role identifier corresponding to the role token are actually issued to the initiator entity, and if the role token is actually issued to the initiator entity, a decision result of the resource access request is determined according to an access control policy and the role token, thereby implementing access control based on roles.

Based on the above definitions, in the embodiment of the present invention, as shown in fig. 9, a process of acquiring an issued role token by an initiator entity is as follows:

step 901: the initiator entity sends a resource reading request for role resources under resources corresponding to the initiator entity to the CSE, wherein the role resources are common resources and store role identifiers of the initiator entity and role tokens corresponding to the role identifiers.

Step 902: and the initiator entity receives a resource reading response returned by the CSE, wherein the resource reading response carries the role token and/or the role identifier stored in the role resource.

Specifically, the resource reading response may carry, in addition to the role token and the role identifier, a role token issuer identifier, a role token valid start time, and a role token valid end time, and optionally may further include one or more of a role type, a role readable name, and an application category to which the role belongs.

Based on the same inventive concept, in the embodiment of the present invention, as shown in fig. 10, a detailed method flow of the PEP performing access control is as follows:

step 1001: the PEP entity obtains a resource access request sent by an initiator entity, wherein the resource access request carries a role identifier and/or a role token of the initiator entity.

Specifically, the resource access request of the initiator entity carries address information of the target resource to be accessed.

Preferably, the role token of the initiator entity carried in the resource access request is determined according to the application category to which the resource access belongs and the application category to which the role belongs. For example, if the application category to which the resource access of the initiator entity belongs is the intelligent transportation application, the initiator entity searches for a role corresponding to the intelligent transportation application from a role list, and carries a role token and/or a role identifier of the role in the resource access request.

Step 1002: and the PEP entity generates an access control decision request according to the resource access request, wherein the access control decision request carries the role identification and/or the role token of the initiator entity.

Step 1003: and the PEP entity sends the access control decision request to the PDP entity, and the PDP entity determines a decision result according to the access control strategy and the role identifier and/or the role token.

Wherein the access control policy is associated with a target resource that the initiator entity needs to access.

Step 1004: and the PEP entity acquires an access control decision response returned by the PDP entity, and the access control decision response carries the decision result.

Step 1005: and the PEP entity performs access control on the resource access request of the initiator entity according to the decision result.

Based on the same inventive concept, in the embodiment of the present invention, as shown in fig. 11, a detailed method flow of performing access control by a PDP entity is as follows:

step 1101: and the PDP entity receives an access control decision request sent by the PEP entity, wherein the access control decision request carries the role identification of an initiator entity initiating the resource access request.

Step 1102: the PDP entity queries the role resource corresponding to the initiator entity according to the role identifier to obtain a role token corresponding to the role identifier, and determines a decision result according to the role token and the access control strategy, wherein the role resource is a common resource and stores the role identifier and the role token of the initiator entity.

In a specific embodiment, the PDP entity sends an inquiry request for role resources of the initiator entity to the CSE, where the inquiry request carries a role identifier, and obtains an inquiry response returned by the CSE, where the inquiry response carries a role token corresponding to the role identifier. The CSE stores resources corresponding to the initiator entity.

In another specific embodiment, the PDP entity sends an access control attribute request to the PIP entity, where the access control attribute request carries a role identifier, and receives an access control attribute response returned by the PIP entity, where the access control attribute response carries a role token corresponding to the role identifier, where the PIP entity queries, according to the role identifier, a role resource corresponding to the initiator entity to obtain the role token.

Specifically, if the PDP entity determines that the role token is valid, the PDP entity extracts role information from the role token, and determines a decision result according to the role information and the access control policy.

Preferably, the PDP entity determines that the role issuer identifier of the role token belongs to a legitimate token issuing authority, and determines that the role token is valid if the role token is within the valid period according to the valid start time of the role token and the valid end time of the role token.

Specifically, the PDP entity determines a decision result according to the role token and the access control policy, specifically: if the PDP entity determines that the role token is valid and determines that the initiating entity is allowed to perform resource access by the role corresponding to the role token according to the access control strategy, determining that the decision result is that the initiating entity is allowed to perform the resource access; and if the role token is determined to be valid and the initiating entity is determined not to be allowed to perform resource access by the role corresponding to the role token according to the access control strategy, determining that the decision result is that the initiating entity is not allowed to perform the resource access.

Specifically, if the PDP entity determines that the queried role token is invalid, the PDP entity determines that the decision result is a resource access request that is not allowed for the initiator entity according to the access control policy.

The access control policy may be that the PDP entity obtains an access control policy response returned by the PRP entity by sending an access control policy request to the PRP entity, where the access control policy response carries an access control policy for performing access control based on the role token.

Step 1103: and the PDP entity returns an access control decision response to the PEP entity, and the access control decision response carries a decision result.

Based on the same inventive concept, in the embodiment of the present invention, as shown in fig. 12, a detailed method flow of performing access control by a PDP entity is as follows:

step 1201: and the PDP entity receives an access control decision request sent by the PEP entity, wherein the access control decision request carries a role token of an initiator entity initiating the resource access request.

Step 1202: and the PDP entity determines a decision result according to the role token and the access control strategy.

Specifically, if the PDP entity determines that the role issuer identifier of the role token belongs to a legitimate token issuing authority, and determines that the role token is valid in the valid period according to the valid start time of the role token and the valid end time of the role token.

Specifically, if the PDP entity determines that the role token is invalid, the PDP entity determines that the decision result is a resource access request that is not allowed for the initiator entity according to the access control policy.

Step 1203: and the PDP entity returns an access control decision response to the PEP entity, and the access control decision response carries a decision result.

Based on the same inventive concept, in the embodiment of the present invention, as shown in fig. 13, a detailed method flow for the PIP entity to perform access control is as follows:

step 1301: the PIP entity receives an access control attribute request sent by the PDP entity, wherein the access control attribute request carries a role identifier of an initiator entity initiating the resource access request.

Step 1302: and the PIP entity inquires whether a role token corresponding to the role identification exists in role resources corresponding to the initiator entity from the CSE according to the role identification and obtains an inquiry result, wherein the role resources are common resources and store the role identification and the role token of the initiator entity.

Specifically, if a role token corresponding to the role identifier is stored in a role resource corresponding to an initiator entity in the CSE, the role token is returned to the PIP entity as a query result; and if the role token corresponding to the role identifier is not stored in the role resource corresponding to the initiator entity in the CSE, the query result returned to the PIP entity is null. The CSE respectively inquires each role resource corresponding to the initiator entity according to the role identifier, determines the role resource corresponding to the role identifier and returns the role token stored in the role resource to the PIP.

In implementation, the query result further includes description information of the role token corresponding to the role identifier.

The description information of the role token can be information of part or all of attributes of the role resource corresponding to the role token.

Step 1303: and the PIP entity returns an access control attribute response to the PDP entity, wherein the access control attribute response carries the query result.

The role token issuing and using process provided by the embodiment of the invention is described in the following two specific embodiments.

In the first embodiment, as shown in fig. 14, the detailed process of issuing and using the role token is as follows:

step 1401: the Role Token issuing (Role Token Authority) entity generates a Role Token (Role Token), and the Role Token comprises Token description information such as Token ID, hole ID, Role ID, issue, startTime, expiryTime, Role type, Role name and appCategory.

Step 1402: the role token issuing entity sends a request for creating < role > resource, namely a role resource creation request, to the registered resource of the Originator in the registry CSE, where the request includes information of all or part of the attributes of the < role > resource requested to be created, for example, values of attributes such as role id, issuer, startTime, expiryTime, role type, role name, role category, and token value. Wherein Originator is AE or CSE.

Specifically, after the < role > resource is created, the < role > resource may also be modified, specifically, the role token issuing entity sends a request for modifying the < role > resource, that is, a role resource modification request, to the registry resource of the Originator in the registry CSE, where the request includes information of all or part of the attributes of the < role > resource that is requested to be modified, for example, values of attributes such as role id, issuer, startTime, expirrytime, role type, role name, role category, and token value. Wherein Originator is AE or CSE.

Step 1403: after receiving a request for creating or maintaining a < role > resource sent by a role token issuing entity, the registry CSE performs the following processing:

the access control policy associated with the Originator's registered resource is checked to determine if the role token issuing entity is entitled to create or maintain the < role > resource, and if so, the requested < role > resource is created or maintained according to the attribute values provided by the request to create or maintain the < role > resource.

Step 1404: the registry CSE returns a response to the role token issuing entity to create or maintain the < role > resource, i.e. a role resource creation response or a role resource modification response.

Step 1405: the Originator sends a resource read request for the < role > resource in the Originator registration resource to the registry CSE to obtain the role token that has been issued to it.

Step 1406: the registry CSE sends the attribute information of the role owned by the organizer to the organizer in the form of an information list, where the attribute information of the role is the attribute information of the role resource, and specifically includes role id, issue, startTime, expiryTime, role type, role name, appCategory, and tokenValue.

Step 1407: the Originator compares the application category to which the current resource access belongs with the application category to which the role belongs, selects an applicable role, sends a resource access request for the resource which is requested to be accessed to the Hosting CSE, and attaches the relevant information of the selected role to the request, wherein the relevant information of the attached role at least comprises a role identification (role ID) or a role token (token value).

Step 1408: the PEP in the Hosting CSE generates an access control decision request according to the resource access request sent by the Originator, wherein the access control decision request contains the relevant information of the role provided by the Originator, and then the access control decision request is sent to the PDP.

Step 1409: if the PDP determines that the resource access request sent by the Originator carries the role token, step 1410 is directly executed; if the resource access request sent by the Originator is determined to carry only the role identifier, the PDP acquires the role token corresponding to the role identifier from the < role > resource in the registration resource of the Originator according to the role identifier.

In a specific implementation, the PDP generates an access control attribute request, which carries a role identifier, and sends the access control attribute request to the PIP; the PIP sends a role resource query request carrying the role identifier to the registry CSE, and receives a role resource query response returned by the registry CSE, wherein the role resource query response carries a role token obtained by the registry CSE querying < role > resource in the registry resource of the origin.

Step 1410: and the PDP verifies the validity of the role token, specifically, whether the role token is issued by a legal token issuing organization or not is verified, whether the role token owner identifier is the same as the identifier of the Originator carried in the resource access request or not is verified within the validity period, whether the role token is suitable for the accessed resource or not is verified, and the like. And if the verification is passed, extracting the role from the role token.

Step 1411: and the PDP makes an access control decision according to the access control strategy and the obtained role token to obtain a decision result.

Step 1412: and the PDP sends the decision result to the PEP through an access control decision response.

Step 1413: and after receiving the access control decision response, the PEP judges whether the resource access request of the Originator is allowed according to the decision result, and if so, executes the resource access request of the Originator.

Step 1414: the PEP will return a resource access response to the Originator, where the resource access response carries the execution result of the resource access request.

In a second embodiment, oneM2M Application Service Provider (oneM2M Application Service Provider) reads data stored in a Home Gateway (Home Gateway) through a platform provided by oneM2M Service Provider (oneM2M Service Provider). Fig. 15 is a schematic diagram of the relationship between entities involved in this embodiment, and the involved entities are described as follows:

CSE 1: is a CSE (called IN-CSE) IN an oneM2M Service Provider (oneM2M Service Provider) Infrastructure Node (Infrastructure Node).

CSE 2: is a CSE (called ASN-CSE) in oneM2M Application Service Node (Application Service Node) existing in a Home Gateway (Home Gateway).

AE 1: to register with an AE of CSE1, the role token issuing entity accesses resources in CSE1 through AE1 and has privileges to create < role > resources in CSE 1.

AE 2: to register with an AE of CSE1, oneM2M application Service Provider (oneM2 hosting Service Provider) accesses resources in CSE2 through AE 2.

In this embodiment, the related resource tree in CSE1 is shown in fig. 16, where:

< CSEBase >: is the root node of the CSE1 resource tree.

< AE2 >: is a registered resource after AE2 successfully registered with CSE 1.

< role >: for the child resource created by AE1 in < AE2>, a < role > child resource represents a role assigned to AE2, and role attribute information such as role id, issuer, startTime, expiryTime, role type, role name, appCategory, and token value are described in the < role > child resource.

In this embodiment, the pre-configuration process for issuing and using the role token includes: oneM2M is registered with oneM2M service provider IN-CSE (CSE1) using service provider AE 2. The role token issuing entity provides the PDP with security credentials through AE1 for verifying the role token it issued, e.g., a public key certificate corresponding to the private key used by the issuing token.

In this embodiment, as shown in fig. 17, the detailed process of issuing and using the role token is as follows:

step 1701: the ROLE TOKEN issuing entity generates a ROLE TOKEN, and the ROLE TOKEN includes TOKEN id — TOKEN1234, bearer id — AE2, ROLE id — ROLE1234, issuer — AE1, startTime — 2015.10.01, expiryTime — 2016.10.01, ROLE type — 0, ROLE name — Data collection ROLE, and appCategory — 12 values of the ROLE attribute.

Step 1702: the ROLE token issuing entity sends a ROLE resource creation request to the CSE1 through AE1 to create a < ROLE > resource under a < AE2> resource, in which ROLE resource creation request attribute information required to create the ROLE resource is provided, such as ROLE id — ROLE1234, issuer — AE1, startTime 2015.10.01, expiryttime 2016.10.01, ROLE type 0, ROLE name — event collection (EventCollection), appcommand 12, token value — ejief852ae5b.

Step 1703: after the CSE1 verifies the access right of AE1 and determines that AE1 is allowed to create < role > resource, the related < role > resource is created under < AE2> resource according to the attribute information of role resource provided by AE 1.

Step 1704: CSE1 returns a role resource create response to AE1 informing AE1 whether the creation was successful.

Step 1705: AE2 sends a resource read request to CSE1 for < role > resource of < AE2 >.

Step 1706: the CSE1 sends attribute information of < ROLE > resource under < AE2> resource to AE2 in the form of a list, where the list includes ROLE information of ROLE id — ROLE1234, including appCategory — 12 and ROLE token roleToken — e8f852ae5b.

Step 1707: AE2 sends a resource access request to CSE2, and the resource requested to be accessed needs to use ROLE of ROLE12, so this resource access request carries ROLE token of ROLE 1234.

Step 1708: the PEP in the CSE2 generates an access control decision request according to the resource access request sent by the AE2, the access control decision request includes a role token provided by the AE2, and the access control decision request is sent to the PDP in the CSE 2.

Step 1709: after receiving an access control decision request sent by a PEP, a PDP verifies that a ROLE token carried in the access control decision request is actually issued by AE1 according to a security credential (such as a public key certificate) provided by an AE1 by a ROLE token issuing entity, if the ROLE token is determined to be issued by AE1, verifies whether the ROLE token belongs to AE2 according to a bearer id attribute of the ROLE token, verifies whether the ROLE token is still in a valid period according to startTime and expiryTime, verifies that a ROLE carried in the ROLE token is applicable to a resource requested to be accessed by the ROLE token according to appCategory, and after the verification is passed, extracts ROLE information of ROLE id which is ROLE1234 from the ROLE token.

Step 1710: the PDP evaluates the resource access request of AE2 based on the access control policy and the role token provided by AE2, if the access control policy is described as: if ROLE of ROLE1234 has data reading right, then it is determined that the evaluation result is "grant the resource access request of AE 2".

Step 1711: and the PDP sends the evaluation result to the PEP through an access control decision response.

Step 1712: the PEP determines that the resource access request of the AE2 is allowed according to the evaluation result, and executes the resource access request of the AE 2.

Step 1713: the PEP sends the execution result to AE2 through a resource access response.

Based on the same inventive concept, an embodiment of the present invention provides a CSE, where the CSE may be any CSE that stores resources corresponding to an initiator entity, for example, may be a registration response CSE that stores registration resources of the initiator entity, and specific implementation of the CSE may refer to the description in the foregoing method embodiment, and details of repeated parts are not repeated, as shown in fig. 18, where the CSE mainly includes:

a receiving module 1801, configured to receive a role resource creation request sent by a role token issuing entity, where the role resource creation request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

a processing module 1802, configured to create a role resource under a resource corresponding to the initiator entity according to the role identifier and the role token, where the role resource is a common resource and stores the role identifier and the role token.

Preferably, the receiving module is further configured to:

also included is a first transmitting module 1803 configured to:

Preferably, a second sending module 1804 is further included for:

Preferably, the receiving module is further configured to:

the processing module is further configured to:

Preferably, a third sending module 1805 is further included, configured to:

Preferably, the processing module is further configured to:

Based on the same inventive concept, an embodiment of the present invention further provides a role token issuing entity, and specific implementation of the role token issuing entity may refer to the description of the foregoing method embodiment, and repeated details are not repeated, as shown in fig. 19, the entity mainly includes:

a processing module 1901, configured to generate a role resource creation request, where the role resource creation request carries a role identifier issued to an initiator entity and a role token corresponding to the role identifier;

a sending module 1902, configured to send the role resource creation request to a common service entity CSE, where the CSE creates a role resource under a resource corresponding to the initiator entity according to the role identifier and the role token, where the role resource is a common resource and stores the role identifier and the role token.

Preferably, a first receiving module 1903 is further included for: and receiving a role resource creation response returned by the CSE.

Preferably, the sending module is further configured to:

Preferably, the processing module is further configured to:

the sending module is further configured to:

sending the role resource modification request to the CSE.

Preferably, a second receiving module 1904 is further included for:

and receiving a role resource modification response returned by the CSE.

Based on the same inventive concept, an initiator entity is further provided in the embodiments of the present invention, and specific implementation of the initiator entity may refer to the description of the above method embodiment, and repeated parts are not described again, as shown in fig. 20, the initiator entity mainly includes:

a sending module 2001, configured to send a resource reading request for a role resource under a resource corresponding to an initiator entity to a common service entity CSE, where the role resource is a common resource and stores a role identifier of the initiator entity and a role token corresponding to the role identifier;

a receiving module 2002, configured to receive a resource reading response returned by the CSE, where the resource reading response carries the role token and/or the role identifier stored in the role resource.

Based on the same inventive concept, the embodiment of the present invention further provides a PEP entity, and the specific implementation of the PEP entity may refer to the description of the above method embodiment, and repeated parts are not described again, as shown in fig. 21, the PEP entity mainly includes:

a first obtaining module 2101, configured to obtain a resource access request sent by an initiator entity, where the resource access request carries a role identifier and/or a role token of the initiator entity;

a generating module 2102, configured to generate an access control decision request according to the resource access request, where the access control decision request carries a role identifier and/or a role token of the initiator entity;

a sending module 2103, configured to send the access control decision request to a policy decision point PDP entity, where the PDP entity determines a decision result according to an access control policy and the role identifier and/or the role token;

a second obtaining module 2104, configured to obtain an access control decision response returned by the PDP entity, where the access control decision response carries the decision result;

an access control module 2105, configured to perform access control on the resource access request of the initiator entity according to the decision result.

In implementation, the PEP entity is located in the CSE where the target resource requested to be accessed by the resource access request is located.

Based on the same inventive concept, the embodiment of the present invention further provides a PDP entity, and the specific implementation of the PDP entity may refer to the description of the above method embodiment, and repeated parts are not repeated, as shown in fig. 22, the PDP entity mainly includes:

a receiving module 2201, configured to receive an access control decision request sent by a policy enforcement point PEP entity, where the access control decision request carries a role identifier of an initiator entity that initiates a resource access request;

a processing module 2202, configured to query, according to the role identifier, a role resource corresponding to the initiator entity to obtain a role token corresponding to the role identifier, and determine a decision result according to the role token and an access control policy, where the role resource is a common resource and stores the role identifier and the role token of the initiator entity;

a sending module 2203, configured to return an access control decision response to the PEP entity, where the access control decision response carries the decision result.

Preferably, the processing module is specifically configured to:

or,

Preferably, the processing module is specifically configured to:

In implementation, the role resource has a common attribute of a common resource, and also has a common attribute specifying expiration time and a subscription sub-resource.

Preferably, the processing module is specifically configured to:

Based on the same inventive concept, another PDP entity is further provided in the embodiment of the present invention, and the specific implementation of the PDP entity may refer to the description of the above method embodiment, and repeated parts are not repeated, as shown in fig. 23, the PDP entity mainly includes:

a receiving module 2301, configured to receive an access control decision request sent by a policy enforcement point PEP entity, where the access control decision request carries a role token of an initiator entity that initiates a resource access request;

a processing module 2302 for determining a decision result according to the role token and an access control policy;

a sending module 2303, configured to return an access control decision response to the PEP entity, where the access control decision response carries the decision result.

Preferably, the processing module is specifically configured to:

Based on the same inventive concept, an embodiment of the present invention further provides a PIP entity, and the specific implementation of the PIP entity may refer to the description in the foregoing method embodiment, as shown in fig. 24, where the PIP entity mainly includes:

a receiving module 2401, configured to receive an access control attribute request sent by a policy decision point PDP entity, where the access control attribute request carries a role identifier of an initiator entity that initiates a resource access request;

a processing module 2402, configured to query, according to the role identifier, a public service entity CSE whether a role token corresponding to the role identifier exists in a role resource corresponding to the initiator entity, and obtain a query result, where the role resource is a common resource and stores the role identifier and the role token of the initiator entity;

a sending module 2403, configured to return an access control attribute response to the PDP entity, where the access control attribute response carries the query result.

Based on the same inventive concept, an embodiment of the present invention provides a CSE, where the CSE may be any CSE storing a resource corresponding to an initiator entity, for example, the CSE is a registration response CSE storing a registration resource of the initiator entity, and specific implementation of the CSE may refer to the description in the foregoing method embodiment, and details of repetition are not repeated, as shown in fig. 25, the CSE mainly includes a processor 2501, a memory 2502, and a transceiver 2503, where the transceiver 2503 is configured to receive and send data under the control of the processor 2501, the memory 2502 stores a preset program, the processor 2501 reads the program stored in the memory 2502, and according to the program, the following processes are performed:

Based on the same inventive concept, an embodiment of the present invention further provides a role token issuing entity, where specific implementation of the role token issuing entity may refer to the description of the foregoing method embodiment, and repeated parts are not repeated, as shown in fig. 26, the role token issuing entity mainly includes a processor 2601, a memory 2602, and a transceiver 2603, where the transceiver 2603 is configured to receive and transmit data under the control of the processor 2601, the memory 2602 stores a preset program, the processor 2601 reads the program stored in the memory 2602, and according to the program, the following processes are performed:

Preferably, the processor further generates a role resource modification request, where the role resource modification request carries the role identifier reissued to the initiator entity and the role token corresponding to the reissued role identifier; sending, by a transceiver, the role resource modification request to the CSE.

Based on the same inventive concept, an initiator entity is further provided in the embodiments of the present invention, and the specific implementation of the initiator entity may refer to the description of the above method embodiment, and repeated parts are not repeated, as shown in fig. 27, the initiator entity mainly includes a processor 2701, a memory 2702, and a transceiver 2703, where the transceiver 2703 is used to receive and transmit data under the control of the processor 2701, the memory 2702 stores a preset program, the processor 2701 reads the program stored in the memory 2702, and executes the following processes according to the program:

In an implementation, the initiator entity is an application entity or a common service entity.

Based on the same inventive concept, an embodiment of the present invention further provides a PEP entity, where specific implementation of the PEP entity may refer to the description of the above method embodiment, and repeated details are not repeated, as shown in fig. 28, the PEP entity mainly includes a processor 2801, a memory 2802, and a transceiver 2803, where the transceiver 2803 is used for receiving and sending data under the control of the processor 2801, a preset program is stored in the memory 2802, the processor 2801 reads the program stored in the memory 2802, and executes the following processes according to the program:

Based on the same inventive concept, an embodiment of the present invention further provides a PDP entity, and the specific implementation of the PDP entity may refer to the description of the above method embodiment, and repeated parts are not repeated, as shown in fig. 29, the PDP entity mainly includes a processor 2901, a memory 2902, and a transceiver 2903, where the transceiver 2903 is used for receiving and sending data under the control of the processor 2901, a preset program is stored in the memory 2902, the processor 2901 reads the program stored in the memory 2902, and executes the following processes according to the program:

or,

Preferably, the processor determines that the role token is in the valid period according to the valid start time of the role token and the valid end time of the role token if the role issuer identification of the role token is determined to belong to a legal token issuing organization.

Based on the same inventive concept, an embodiment of the present invention further provides a PDP entity, where specific implementation of the PDP entity may refer to the description of the foregoing method embodiment, and repeated parts are not repeated, as shown in fig. 30, the PDP entity mainly includes a processor 3001, a memory 3002, and a transceiver 3003, where the transceiver 3003 is configured to receive and transmit data under the control of the processor 3001, the memory 3002 stores a preset program, the processor 3001 reads the program stored in the memory 3002, and executes the following processes according to the program:

Based on the same inventive concept, an embodiment of the present invention further provides a PIP entity, and the specific implementation of the PIP entity may refer to the description of the foregoing method embodiment, as shown in fig. 31, the PIP entity mainly includes a processor 3101, a memory 3102 and a transceiver 3103, where the transceiver 3103 is configured to receive and transmit data under the control of the processor 3101, the memory 3102 stores a preset program, and the processor 3101 reads the program stored in the memory 3102, and according to the program, executes the following processes:

In the embodiments corresponding to fig. 25 to 31, the bus architecture may include any number of interconnected buses and bridges, and specifically, one or more processors represented by processors and various circuits of memories represented by memories are linked together. The bus architecture may also link together various other circuits such as peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further herein. The bus interface provides an interface. The transceiver may be a plurality of elements, i.e., including a transmitter and a transceiver, providing a means for communicating with various other apparatus over a transmission medium. The processor is responsible for managing the bus architecture and the usual processing, and the memory may store data used by the processor in performing operations.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method of role token issuance, comprising:

2. The method of claim 1, wherein after the CSE creates a role resource under a resource corresponding to the initiator entity according to the role identifier and the role token, the method further comprises:

3. The method of claim 1, wherein the role resource has a generic attribute of a generic resource, and further has a common attribute specifying a time to failure and a subscription sub-resource.

4. The method of claim 3, wherein the role resource has a role identification attribute for storing a role identification, a role token issuer identification attribute for storing a role token issuer identification, a role token valid start time attribute for storing a role token valid start time, a role token valid end time attribute for storing a role token valid end time, and a token value attribute for storing the role token;

5. The method of claim 4, wherein the role resource further has any one or more of a role type attribute for saving a role type, a role name attribute for saving a role readable name, and an application category attribute for saving an application category to which the role belongs;

6. The method of any one of claims 1-5, further comprising:

7. The method of any of claims 1-5, wherein prior to the CSE creating a role resource under a resource corresponding to the initiator entity based on the role identification and the role token, further comprising:

8. The method of claim 2, wherein before the CSE modifies the role resource according to the reissued role identifier and the role token corresponding to the reissued role identifier, further comprising:

9. A method of role token issuance, comprising:

10. The method of claim 9, wherein after the role token issuing entity receives the role resource creation response returned by the CSE, further comprising:

11. The method of claim 9 or 10, wherein after the role token issuing entity sends the role resource creation request to the CSE, further comprising:

12. A method according to claim 9 or 10, wherein the role resource has a generic property of a generic resource, and also a common property specifying a time to failure and a subscription sub-resource.

13. The method of claim 12, wherein the role resource has a role identification attribute for storing a role identification, a role token issuer identification attribute for storing a role token issuer identification, a role token valid start time attribute for storing a role token valid start time, a role token valid end time attribute for storing a role token valid end time, and a token value attribute for storing the role token;

14. The method of claim 13, wherein the role resource further has any one or more of a role type attribute for saving a role type, a role name attribute for saving a role readable name, and an application category attribute for saving an application category to which the role belongs;

15. A method of role token issuance, comprising:

16. The method of claim 15, wherein the role resource has a generic attribute of a generic resource, and further has a common attribute specifying a time to failure and a subscription sub-resource.

17. The method of claim 16, wherein the role resource has a role identification attribute for storing a role identification, a role token issuer identification attribute for storing a role token issuer identification, a role token valid start time attribute for storing a role token valid start time, a role token valid end time attribute for storing a role token valid end time, and a token value attribute for storing the role token;

18. The method of claim 17, wherein the role resource further has any one or more of a role type attribute for saving a role type, a role name attribute for saving a role readable name, and an application category attribute for saving an application category to which the role belongs;

19. An access control method, comprising:

20. An access control method, comprising:

21. The method of claim 20, wherein the PDP entity queries the role resource corresponding to the initiator entity according to the role identifier to obtain the role token corresponding to the role identifier, including:

or,

22. The method of claim 20, wherein the PDP entity determines a decision result according to the role token and an access control policy, comprising:

23. A method according to any of claims 20-22, wherein the role resource has a generic property of a generic resource, and also has a common property specifying an expiry time and a subscription sub-resource.

24. The method of claim 23, wherein the role resource has a role identification attribute for storing a role identification, a role token issuer identification attribute for storing a role token issuer identification, a role token valid start time attribute for storing a role token valid start time, a role token valid end time attribute for storing a role token valid end time, and a token value attribute for storing the role token;

25. The method of claim 24, wherein the role resource further has any one or more of a role type attribute for saving a role type, a role name attribute for saving a role readable name, and an application category attribute for saving an application category to which the role belongs;

26. The method of claim 24 or 25, wherein the PDP entity determining that the role token is valid comprises:

27. An access control method, comprising:

28. The method of claim 27, wherein the PDP entity determines a decision result according to the role token and an access control policy, comprising:

29. An access control method, comprising:

30. The method of claim 29, wherein the role resource has a generic attribute of a generic resource, and further has a common attribute specifying a time to failure and a subscription sub-resource.

31. The method of claim 30, wherein the role resource has a role identification attribute for storing a role identification, a role token issuer identification attribute for storing a role token issuer identification, a role token valid start time attribute for storing a role token valid start time, a role token valid end time attribute for storing a role token valid end time, and a token value attribute for storing the role token;

32. The method of claim 31, wherein the role resource further has any one or more of a role type attribute for saving a role type, a role name attribute for saving a role readable name, and an application category attribute for saving an application category to which the role belongs;

33. A common service entity, CSE, comprising:

34. The CSE of claim 33, wherein the receiving module is further to:

the processing module is further configured to:

35. The CSE of claim 33 or 34, wherein the receiving module is further to:

the system further comprises a first sending module, configured to:

36. The CSE of claim 33 or 34, wherein the processing module is further to:

37. The CSE of claim 34, wherein the processing module is further to:

38. A role token issuing entity, comprising:

39. The entity of claim 38, wherein the sending module is further configured to:

40. The entity of claim 38 or 39, wherein the processing module is further to:

the sending module is further configured to:

sending the role resource modification request to the CSE.

41. An initiator entity, comprising:

42. A policy enforcement point, PEP, entity, comprising:

43. A policy decision point, PDP, entity comprising:

44. The entity of claim 43, wherein the processing module is specifically configured to:

or,

45. The entity of claim 43, wherein the processing module is specifically configured to:

46. A policy decision point, PDP, entity comprising:

47. The entity of claim 46, wherein the processing module is specifically configured to:

48. A policy information point, PIP, entity, comprising: