WO2012009877A1

WO2012009877A1 - Access method based on computable credibility in distributed multi-trust domain environment

Info

Publication number: WO2012009877A1
Application number: PCT/CN2010/077303
Authority: WO
Inventors: 李斓; 黄恺; 李建华; 蔡伟; 范磊
Original assignee: 上海交通大学
Priority date: 2010-07-20
Filing date: 2010-09-26
Publication date: 2012-01-26
Also published as: CN101888341B; CN101888341A

Abstract

An access method based on computable credibility in distributed multi-trust domain environment in the field of network technology is provided. Said method includes: when a user logs on to a target trust domain, the target domain gives the user a role set by role mapping and role conversion. Said target domain receives access request from the user, queries authorization strategy database and then processes the request accordingly. Said target domain also updates the value of user behavior variables in accumulation behavior database, updates the number of times for performing the user behavior in behavior assessment database, performs role conversion based on behavior, generates behavior assessment vector, calculates the prestige value of the role, and adjusts the role mapping strategy associated with the role. The present invention enables the dynamic trust management of role mapping, role conversion and prestige feedback, improves the interaction ability between trust domain and user, enhances the flexibility, security, and reliability of the access control in trust domain, and effectively solves the problems of user authorization and resource management in network system services.

Description

Access control method based on computable credit degree in distributed multi-trust domain environment

Technical field

The invention relates to an access control method in the field of network technology, in particular to an access control method based on computable credit degree in a distributed multi-trust domain environment.

Background technique

With the widespread adoption and application of network systems and resource sharing, the security of service providers is experiencing increasing challenges. Sites such as the currently popular blogging system, forum community, online reading and e-shopping are all independent service providers. Each service provider can independently implement different access control policies for different user groups to form a trust domain entity. The traditional attribute-based access control method obviously cannot cope with the huge number of users and complex operations across domains. Trust has its unique nature. Applying trust to computers and network technologies is an effective way to deal with such uncertainties. Flexibly manage service resources and user authorization within the trust domain through trust acquisition, quantification, statistics, and updates.

There are two strategies for establishing credibility within a domain entity, the first being based on the user's role and the second being based on the user's behavior over a period of time. A role-based trust policy can facilitate distributed system batch authorization for the trust domain or other trust domain users, but cannot flexibly adjust the authorization policy according to the behavior of a certain user. A behavior-based trust strategy allows users to gain more credibility by accumulating credibility through legitimate behavior in the system. Both strategies have their own advantages and disadvantages. They are suitable for different types of distributed systems. For example, role-based trust policies are suitable for distributed Web services environments, and behavior-based trust policies are more suitable for P2P network environments. However, in order to implement a more flexible and secure authorization policy, two trust policies should be combined. Authorization can be performed through trust in the user role, and the authorization policy should be adjusted in time according to the user's behavior.

After searching the literature of the prior art, the Chinese patent application number: CN200810019667.0, the announcement number is: CN101257377, and the patent name is: "A dynamic access control method based on community authorization service", which proposes a community-based Authorized service CAS dynamic access control scheme. The method is based on the community authorization service, mainly for the dynamic characteristics of the grid environment. By adding the resource control module, the resource layering, monitoring, dynamic access control is implemented, and the community authorization server and database are modified to enable the user to be implemented according to the user. The context of the user dynamically changes the user role and interacts with the resource control module to achieve dynamic, transparent access and seamless integration of resources in the grid environment. Although this method can A good description of the dynamic trust parameters of the context, but the disadvantage is that the user who performs the good behavior holds the same role as other users, but cannot obtain high trust, and thus cannot dynamically adjust the trust according to the cumulative behavior of the user. And authorization.

Chinese patent application number: CN200810118258.6, the announcement number is: CN101345627, and the patent name is: "A method of collusion identification based on behavior similarity in P2P networks", which assigns a trust management node to each node in the network. It is used to monitor the scoring behavior of other nodes on the node, and a behavior record node is used to record the scoring behavior of the node to other nodes. By further analyzing the similarity of the scoring behavior between the abnormal nodes, it is judged whether there is a conspiracy group, and finally the global trust value of the node is updated according to the detection result. Although this method can identify most of the group collusion behaviors, the disadvantage is that there is no concept of roles in the model, and there is no classification and statistics on the trust of different behaviors. The score of each node is composed of good behavior and bad behavior. Co-accumulated, so its behavioral similarity cannot reflect the comprehensive trust performance of a certain user group in a fine-grained manner.

In addition, whether it is the method in the above cited documents or the trust management mechanism in most P2P, it is either focused on role-based static methods or biased on behavior-based dynamic methods. The former lacks the necessary trust feedback mechanism to flexibly adjust the authorization strategy: The latter is too fine-grained because the amount of storage and computation based on the trust of a single individual is very large.

Summary of the invention

The object of the present invention is to overcome the deficiencies in the prior art and provide an access control method based on a computable credit degree in a distributed multi-trust domain environment. The control method proposed by the present invention has better flexibility, and can According to the user's volume authorization, the authorization policy can also be adjusted according to the user's behavior, and can be applied in the fields of portal, shared community, information management, and the like.

The present invention is achieved by the following technical solutions, and the present invention includes the following steps:

Step 1: The user logs in to the target trust domain, and through the role mapping and role conversion, the target domain gives the user a set of roles.

The set of roles defines the operational rights of the current user in the context of the trusted domain.

Step 2: The user sends an access request to the target domain, and attempts to obtain resource information in the target domain.

The administrator of the target domain may define an access period of a specific role to a resource, an amount of resources accessible, a load limit, an access type, and the like.

Step 3: The target trust domain queries the authorization policy database according to the role set and access request granted and converted by the user: If the user's role set has the permission to execute the request, the user is given the corresponding local resource: Otherwise, the user is rejected. Request.

Regardless of the form, the user behavior will ultimately be generated based on the user's access request, either a successful access request or a failed request. Because of the large number of users and the behaviors they perform, it is impossible for the trust domain to perform trust and reputation calculations for each specific behavior. Therefore, local trust domains need to be properly screened, merged, and classified for behavior. The purpose of screening is to record and calculate only those behaviors that have a greater impact on local resources or other users, and to exclude those that are not important: the merging of behaviors is that the multiple executions of the user are interrelated and not separate. The operations that produce direct results are combined to form a chain of behavior, and a new definition of behavior is assigned to it: The classification of behaviors is to consider different behaviors and the resulting gains and losses to set trust on meaningful behaviors. The quantified standard value is the source of data for subsequent role reputation calculations.

Step 4: Calculate the updated value of the user's behavior variable according to the execution result of the user behavior, and update the user behavior variable value in the cumulative behavior library: According to the execution result, the behavior is merged into the behavior of a certain trust criterion, and the behavior is updated. Evaluate the number of user behavior executions corresponding to the foreign domain role in the library.

Step 5: Perform a behavior-based role transition.

The role transformation is based on the user's initial character set as the source node set of the conversion, and the query role conversion strategy library, for each strategy, there is a corresponding establishment condition, these conditions are expressions composed of multiple behavior variables : According to the behavior ID and the user/D query, the behavior variable value corresponding to the current user in the cumulative behavior library, if and only if the user's behavior variable value satisfies the discriminant expression, the conversion strategy can be established, and the user obtains the conversion character of.

From the set of converted roles that the set of source nodes can reach, select the target role with the highest priority as the final converted role, and update the set of roles held by the user as the initialization local when the next user requests. The set of characters.

Step 6: According to the role /o, all users corresponding to the role are obtained, the user is classified according to the behavior /o, and the evaluation value and the number of executions of each behavior are counted, and the behavior evaluation vector is generated, and finally the execution times of different behaviors are used as The weight, with the evaluation value as the weight, calculates the reputation value of the character.

Step 7: According to the change of the role reputation value, use the reputation expression as a judgment condition to adjust the role mapping strategy associated with the role. The role mapping relationship can be established if and only if the role reputation value reaches the discriminant expression. Therefore, the dynamic adjustment of the trust relationship between roles is realized through the reputation feedback mechanism based on behavior statistics.

In step 5, the behavior-based role transition is specifically an optimal path discovery in the role transition directed graph. It involves role conversion strategies, role conversion directed graphs, and so on. The role conversion strategy includes three elements: a source role expression, a target role, and a transition condition, where: the source role expression is an input of the role conversion strategy, and has two forms, a single role or multiple A group of roles that are connected by roles. Each role in a role expression can be a role granted by a trust domain, or a target role after multiple conversions within a trust domain:

The target role is the output of the role transition strategy, which can only be in the form of a single role, and sets the priority and variable threshold for each target role. Each target role has a priority. The higher the priority, the greater the authority of the role: Each target role contains multidimensional variables, each of which is used to describe the cumulative initial of a specific behavior for that role. Value:

The conversion condition is a set of comparison relations quantified based on the cumulative behavior of the user. The historical behavior of the user is quantitatively evaluated by limiting the accumulated value of each behavior to determine whether the user has good or bad in the trust domain. Performance records that drive role transitions.

The character transformation directed graph is a visual representation of a set of role transformation strategies, and is described by a set of vertex sets, a set of directed edges, and a set of transition conditions, wherein:

Each element in the vertex set is a role defined by the trust domain: When a vertex is used as the target node, the role transition comes from the set of input directed edges corresponding to the vertex: When a vertex is used as the source node, the role The transformation comes from the set of output directed edges corresponding to the vertex:

The directed edge set consists of the role conversion strategy: Each edge contains the source node, that is, the role before the conversion, the target node, that is, the converted role: each directed edge corresponds to the conversion condition and the group attribute, and the conversion condition is The judgment of the directed edge path, the group attribute identifies whether the source node of the directed edge belongs to an element in the group role: if the group attribute is null, it indicates that the directed edge corresponds to a role conversion strategy: If the group attribute is a non-null value, it indicates that the directed edge and the remaining directed edges with the same group attribute together constitute a role conversion strategy.

The role conversion process of the directed graph combines two processes of forward search and backward search: the forward search uses the initial set of characters held by the user as the source node set, and the output edge of each node is passed. The behavior-based transition condition is judged to obtain the target role node, and the source node set is updated: The backward search starts from the highest priority role in the local trust domain, and obtains the source by determining the input side based on the behavior-based transition condition. The end role node, and update the target node set, each backward search starts from a certain role by priority, so each target node set is derived from a starting role of the backward search. The target role is the starting node of the backward search if and only if the target character set currently being searched for and the target character set of the backward search contains the same role expression element. The reputation value of the character described in step 6 is obtained by the following method:

Find the user group corresponding to the foreign domain role AT?, any of the users performed different behaviors in a certain period of time, based on the pre-set trust quantization standard value and cumulative execution number 3⁄4, formula (1) Calculate the behavior evaluation value r _Ai of a certain user corresponding to the character, where "represents the trust gene, indicating the increment factor. As the 3⁄4 increases, r _Ai will gradually tend to the ideal value.

7 , =" + (1- " H "- ¹ (1), grouping different behaviors with behavior /o as the primary key. Each behavior corresponds to "a different performer. Formula (2) calculates a certain The average value of the behavior k corresponding to each character is 7; and the formula (3) calculates the total number of executions of the behavior k 3⁄4, thereby generating an evaluation vector of the behavior corresponding to the character W: B ^→ E _k = (R, T _k , Q _k ) , where: T _k = (∑T _ki )/n (2) ,

'■=1 α = (3),

;=1 According to different behaviors /0, the total number of executions of each behavior is 3⁄4 as the weight, and the overall evaluation value of the behavior 7 is used as the weight, and the comprehensive evaluation value of the statistical behavior is weighted to obtain the role reputation. Equation (4) calculates the reputation of the character D.R

Rep (D.R).

R^(D.R) = (3⁄4r, *3⁄4)/ ; ft (4). The dynamic adjustment of the trust relationship between the roles described in step 7 is as follows:

Each trust relationship Z corresponds to a reputation expression as a condition for its establishment. If RepExpr is true, then Z is valid, otherwise Z is invalid, and if there is another trust relationship in the Z-linked role mapping policy set, if it is not established, it indicates the total user group corresponding to the role in a certain period of time in the past. Poor behavior, resulting in lower reputation, the local trust domain temporarily revoked the trust relationship from the foreign domain role to the local domain.

The trust domain described in the above seven steps is an entity or a service site that implements an access control method for a user through a role and behavior evaluation policy. The static roles and dynamic behaviors of combining users within a trust domain include: The behavior variable is a behavior variable corresponding to the user's access request, and the variable value represents a cumulative evaluation of the user performing the behavior.

The role is converted into role conversion based on the cumulative behavior of the user, so that the user who performs well can obtain more rights, thereby enhancing the role of the user: enabling the user who performs poorly to obtain less rights, thereby reducing the role of the user.

The behavior evaluation vector sets different trust quantization standards for different types of behaviors, and calculates an evaluation value and an execution number of a certain behavior corresponding to a certain role according to the cumulative behavior of the user, as a behavior evaluation vector. To describe the overall performance of a certain behavior of the user group.

The role reputation described is a comprehensive representation of all cumulative behaviors of a user group over a period of time. Reflects the trust of a local trust domain for a role.

The role expressions, behavior variables, role conversion strategies, and role mapping strategies described in the above seven steps follow a unified XML Schema file definition format. The use of hierarchical extension structure packaging effectively simplifies the system design, improves the flexibility of data analysis, and improves the system's ability to process data: using behavior variable quantized values, behavior evaluation values, etc., to ensure access control methods within the trust domain. Sensitivity, safety, reliability.

According to the set of roles held by the user and the implemented behavior, according to the trust delegation between the trust domains and the role conversion strategy based on the directed graph, the most suitable role of the user is determined, and the access rights of the user are adjusted in real time. And according to the cumulative behavior of the user group, the trust value of the statistical behavior is classified and the reputation of the role is calculated, thereby dynamically adjusting the trust relationship between the roles. The present invention describes a role with variables, a role conversion policy, and a role mapping strategy by defining corresponding XML Schema documents and a valid XML structure. As a powerful language, the XML format facilitates the preservation and exchange of data. Compared with the prior art, the present invention has the following beneficial effects:

1. The prior art method only provides a single role-based access control, and the definition and description of trust is too singular to effectively solve the trust and authorization problems in the trust domain. The invention combines the user's static role and dynamic behavior to evaluate the user's behavior in two aspects. First, the behavior variable is used to judge the role conversion to enhance the user's authority, and the second is to calculate the role reputation through the behavior statistics, thereby improving the trust management. mechanism.

2. The prior art does not consider the behavior of the user, and there is no good feedback evaluation mechanism to adjust the security policy in the trust domain. In the present invention, the role relationship based trust relationship adjustment can effectively calculate the overall reputation value according to the user's behavior. , thus affecting the trust relationship between domains. Helps better control access to local domain resources.

3. Use XML Schema format to describe roles with variables, role conversion strategies, and trust relationships to form a set of interoperable access control protocols. DRAWINGS

1 is a structural diagram of a behavior-aware trust and authorization model in an embodiment of the present invention.

2 is a behavior-based role transition directed graph in an embodiment of the present invention.

detailed description

The embodiments of the present invention are described in detail below with reference to the accompanying drawings. The present embodiment is implemented on the premise of the technical solution of the present invention, and the detailed implementation manner and the specific operation process are given, but the protection scope of the present invention is not limited to the following. An embodiment.

This example includes the following steps:

Step 1: The user logs in to the target trust domain, obtains the local role set through role mapping and role conversion, and the local role set is based on the behavior because each role transformation may generate a new target role and delete the old source role. Dynamic change collection.

As shown in FIG. 1 , in this embodiment, the target role is connected to the local role set, and there is a process of feedback update. A local role set can contain multiple roles, but each time a user action is performed, only one of the highest priority target roles can be generated as the converted optimal target role.

Step 2: The user sends an access request to the target domain, and the request processing module of the target trust domain queries the authorization policy library according to the local role obtained by the user after mapping and conversion, so as to determine whether the user has the corresponding permission to obtain some Resource information.

Step 3: If there is access right, grant the user the corresponding resource, otherwise reject the user's request. Regardless of the form, the user behavior will ultimately be generated based on the user's access request, either a successful access request or a denied access request.

Step 4: Store user behavior, as shown in Figure 1, the trust-related behaviors performed are recorded in the user cumulative behavior library and user behavior evaluation database. The User Cumulative Behavior Library provides behavior variable values for behavior-based role transitions: The User Behavior Evaluation Library provides behavior evaluation vectors for role mapping of reputation feedback.

The user cumulative behavior library includes: a user ID, a behavior variable name, and a behavior variable value. among them:

The user ID is used as the primary key, and the local trust domain assigns each user a unique ID as the identifier.

The behavior variable name is used to distinguish the different behaviors performed by the user. Each behavior variable corresponds to a formula to calculate the incremental value of the user performing the behavior, and is added to the original value of the behavior variable. Therefore, the value of the behavior variable is a cumulative value, which serves as the basis for the comprehensive performance of the user's cumulative behavior. The user behavior evaluation library includes: a role ID, a user ID, a behavior ID, a behavior cumulative execution count, and a behavior evaluation value.

The behavior ID is used as the primary key. The quantified value is used to set the trust criterion for each behavior. The better the performance, the higher the trust value of the behavior definition.

The cumulative number of behaviors records the number of times a user performs the behavior, so that the total number of times a character performs the behavior can be counted as the weight of the reputation statistics based on the behavioral evaluation.

The behavioral evaluation value reflects the overall performance of the user's behavior over a certain period of time. It is calculated by the cumulative number of executions of behavior and the value of the trust quantization standard defined by the behavior.

Step 5: Behavior-based role transition. Import the role conversion policy file to generate a directed graph of the role transition, as shown in Figure 2. Each role conversion strategy belongs to a directed edge in the directed graph. The initial local character set held by the user is used as the source node set of the conversion, and the conversion condition is determined by querying the value of the corresponding behavior variable in the user cumulative behavior library.

As shown in Figure 1, the ultimate goal of the conversion is the optimal target role, the local role with the highest priority. During the role transition, the local role set is dynamically changed. If a role transition policy is established, the role represented by the source node of the policy is removed, and the role represented by the target node of the policy is added.

The role conversion policy file includes: an identifier of a conversion policy, a source role expression, a target role, a role priority, a behavior variable expression, a conversion condition, and the like, where:

The source role expression is the input of the role conversion strategy. There are two forms, a single role or a role group connected by multiple roles. Each role in the role expression can be a local role granted by the trust domain, or a target role after multiple conversions within the trust domain.

The target role is the output of the role transition strategy. It can only be in the form of a single role. The target role is set by priority. Each target role has a priority, and a higher priority indicates a greater authority for that role.

A behavior variable expression is a set of comparison relations that determine the user's cumulative behavior value, which is defined as follows:

(1) Atomic expression 0 i<wnBV3⁄4»: w)

AtomBVExpr := BV.V = C I BV.V > C I BV.V < C

Where, represents the value of the specific behavior variable, and C is the discriminant constant.

(2) Recursive expression BVExpr := AtomBVExpr I AtomBVExpr Λ BVExpr

I AtomBVExpr v BVExpr I -^AtomBVExpr

Each time a user performs a certain behavior, the cumulative value of the behavior variable changes accordingly, which may trigger a true or false change in the associated behavior variable expression.

The conversion condition is based on the expression of the behavior variable, and the basis for determining the role conversion strategy is established. The user can obtain the converted target role if and only if the user holds all the roles in the source role expression in the role conversion policy and the behavior variable expression in the conversion condition is true.

The above information is described in XML format. The specific Schema definition is as follows:

<xs: schema xmlns:xs= ^M http://www. w3.org/200 l/XMLSchema ^M >

<!—Atomic Expression Definition>

<xs: complexType name: ' 'AtomBVExprType , , >

<xs:complexContent>

<xs: extension base= ' 'AtomExprType ">

<xs: attribute name= ^M id ^M type= ^M B VidType ¹¹ use= ^M required ^M /></xs:extension>

</xs:complexContent>

</xs: complexTypo

<!»Recursive expression definition >

<xs: complexType name= ^M BVExprType ">

<xs:sequence>

<!»Atomic expressions >

<xs: element name= ^M AtomBVExpr ^M type= ^M AtomB VExprType ¹ V><! - Reflexive relationship -->

<xs: element name= ¹¹ self relation" type= ¹¹ onelogicType ¹ V>

<! "Binary relationship"

<xs: element name= ¹¹ nextrelation" type= ^M twologicType ¹ V>

<xs: element name= ¹¹ BVExpr" type= ^M BVExprType ^M

minOccurs="0"/> </xs:sequence>

</xs: complexTypo

<!--role conversion strategy->

<xs: complexType name="TransformType">

<xs:sequence>

<!»Source Role Expressions >

<xs:element nanie= ^M SourceRoleExpr" t pe= "PRidType ¹ V><!"Targetrole"

<xs: element name:" Targe tRole" type= ^M PRidType ^M /><! -Conversion condition~>

<xs: element name= ^M BVExpr" type= ^M BVExprType ^M /><xs:sequence>

<xs: attribute name= ^M id ^M type= ¹¹ RTidType ¹ V>

</xs: complexTypo

<! - Role Conversion Policy Collection ->

<xs: complexT pe nanie="RTType ^u >

<xs:sequence>

<xs: element name= ¹¹ Transform ¹¹ type= ¹¹ Transf ormType ¹¹ maxOccurs= ', unbounded, 7>

</xs:sequence>

<xs: attribute name= ^M id ^M type= xs : string ¹ V>

</xs: complexTypo

<!--Generated role conversion prototype structure ->

<xs: element name="RT" type="RTType"/>

</xs:schema> Step 6: Reputation calculation based on behavioral statistics. As shown in Figure 1, other domain roles mapped to the target domain role correspond to a group of users, each of which performs different behaviors in the target domain. In the user behavior evaluation library, the user ID and the behavior ID are used as the primary key for classification calculation, and the overall evaluation value of the behavior of a certain role and the total number of executions of the behavior are obtained. The final calculated character reputation value is a statistical value based on user behavior.

Step 7: Adjust the trust delegation relationship based on the role reputation. As shown in Figure 1, after a certain period of time, the calculated role reputation value will change and be fed back to the role mapping strategy. The higher the role reputation value, the more performance the corresponding user group performs. The role mapping policy file describing the trust delegation relationship contains the mapping relationship between all other domain roles and the local domain roles. The reputation expression is used to determine whether a certain policy is valid, that is, whether another domain role is allowed to be mapped to the domain. A role that gives the role access. If the role reputation value reaches a certain trigger value, so that the reputation expression judges to be true, the role mapping strategy is valid.

The role mapping policy file includes: an identifier of a trust relationship, an external domain role expression, a local domain role, a reputation expression, a constraint, a policy validity identifier, and the like, where:

The role expression is in the same form as the source role expression in the role conversion policy, and includes a single role or a group role. A reputation expression is similar to a behavior variable expression in a role conversion strategy, and is a comparison relation group recursively derived from an atomic expression. Among them, each comparison relation is an atomic expression, which is triggered according to the role reputation value to judge true and false.

The constraint is the basis for judging the role mapping strategy. Limitations on access time, amount of resources accessible, time validity of certificates, type of access, etc.

The policy validity identifier is a state in which the mapping policy is in an active state. If the identifier is true, the policy is the basis for determining the local character set obtained after the user logs in the trust domain.

<xs: schema xmlns:xs="http:〃 www.w3.org 2001/XMLSchema">

<xs: complexType name= ' 'AtomRepExprType ' ' >

<xs: complexContent>

<xs: extension base= "AtomExprType ' ' >

<xs: attribute name="id" type="RepidType" use="required"/> </xs:extension>

</xs: complexContent> <xs:complexType>

<!--Definition of unary logic -- >

<xs:simpleType nanie= ¹¹ onelogicType ^M >

<xs: restriction base= ^M xs : string">

<xs:enumeration value="yes ^l V>

<xs:enumeration value= ^M not ^M />

</xs:restriction>

</xs:simpleType>

<! - definition of binary logic -- >

<xs:simpleType nanie="twologicType ^M >

<xs: restriction base="xs:string">

<xs:enumeration value= ^M none ^tf />

<xs:enumeration value= ^M and ^M />

<xs: enumeration value= ^M or ^M />

</xs:restriction>

</xs:simpleType>

<! Reputation recursive expression definition >

<xs:complexType name= "RepExprType ¹¹ >

<xs:sequence>

<! "Atomic expressions >

<xs:element name= ¹¹ AtomRepExpr ¹¹ ty pe= " AtomRepExprTy pe ¹ 7><!" Define Reflexive Relationships >

<xs:element name= ^M selfrelation ty pe= ^ff onelogicType ¹ V>

<! Define a recursive binary relationship with the next level of expression >

<xs: element name= ^M nextrelation ^M type= ^M twologicType ¹ V>

<! "Recursive part"

<xs:element nanie= ^M RepExpr ^u ty pe= ¹¹ RepExprType ¹¹ min Occurs = ¹¹ 0 ¹ V> </xs:sequence>

< xs:complexType>

<! - Define the basic structure of the role mapping strategy >

<xs:complexType name= ^M BasicCredentialType ^M >

<xs:sequence>

<! "Outside domain role expressions >

<xs: element name= ^M ExternalRoleExpression ^M

Type= ^M ExRoleExprType , Ί>

<! - mapped local domain roles ->

<xs: element name= ^M MappedRole ¹¹ type= ^M prType ^M />

<! - constraints ->

<xs: element name= ¹¹ Constraints ¹¹ type= ^M ConstraintsType ^M /></xs:sequence>

</xs:complexType>

<! A role mapping strategy >

<xs:complexType name= ¹¹ CredentialType ^M >

<xs: complexContent>

<xs: extension base= ^M BasicCredentialType ^M >

<xs:sequence>

<! — Reputation expression — >

<xs: element name= ^M RepExpr ^M type= ¹¹ RepExprType ¹ V><! - Identification of the effectiveness of the strategy ->

<xs: element name= ^M Active ^M type= ^M xs : boolean ¹ V></xs:sequence>

<xs: attribute name= ^M id ^M type="CRidType" use= ^M required ^M /></xs:extension>

</xs: complexContent> <xs:complexType>

<!—Role mapping policy collection -->

<xs:complexType name= ¹¹ CredentialsType ¹¹ >

<xs:sequence>

<xs: element name= ¹¹ Credential ¹¹ type="CredentialType"

maxOccurs= ^M unbounded ^M />

</xs:sequence>

<xs: attribute name= ^M id ^M ty e = ^M xs : string ¹ V>

</xs:complexType>

<! - Generated role mapping strategy prototype structure -- >

<xs: element name:"Credentials" type= ¹¹ CredentialsType ¹ V>

</xs:schema>

This embodiment implements a dynamic trust and authorization method, and introduces a behavior-based role transition and a reputation-based trust relationship feedback evaluation mechanism in combination with the expression of roles and behaviors, thereby enhancing access control in a distributed multi-trust domain environment. Flexibility, security, and reliability have effectively solved user authorization and resource management issues in network system services.

Claims

Claim

A method for access control based on a computable reputation in a distributed multi-trust domain environment, comprising the steps of:

Step 1: The user logs in to the target trust domain, and through the role mapping and role conversion, the target domain gives the user a set of roles:

Step 3: The target trust domain queries the authorization policy database according to the role set and access request granted and converted by the user: If the user's role set has the permission to execute the request, the user is given the corresponding local resource: Otherwise, the user is rejected. Request:

Step 4: Calculate the updated value of the user's behavior variable according to the execution result of the user behavior, and update the user behavior variable value in the cumulative behavior library: According to the execution result, the behavior is merged into the behavior of a certain trust criterion, and the behavior is updated. Evaluate the number of user behavior executions corresponding to the foreign domain role in the library:

Step 5: Perform a behavior-based role transition;

Step 6: According to the role H?, all the users corresponding to the role are obtained, the users are classified according to the behavior ///, and the evaluation value and the number of executions of each behavior are counted, a behavior evaluation vector is generated, and finally the number of executions of different behaviors is performed. As the weight, the reputation value of the character is calculated by using the evaluation value as the weight:

Step 7: According to the change of the role reputation value, the reputation mapping is used as a judgment condition to adjust the role mapping strategy associated with the role, and the role mapping relationship can be established only when the role reputation value reaches the discriminant expression.

2. The method according to claim 1, wherein the set of roles described in step one defines the context of the current user in the trust domain. Operational permissions in the environment.

3. The method according to claim 1, wherein the administrator of the target domain in the second step defines access to the resource by the specific role in the distributed multi-trust domain environment. Time period, amount of resources accessible, load limit, access type.

4. The method according to claim 1, wherein the role conversion described in step 5 is based on a user's initial character set as a conversion control method according to claim 1 in a distributed multi-trust domain environment. The source node set, the query role conversion strategy library, for each policy, there will be corresponding conditions for the establishment, these conditions are expressions composed of multiple behavior variables: According to the behavior H? and user H? query cumulative behavior library The value of the behavior variable corresponding to the current user, if and only if the value of the behavior variable of the user satisfies the discriminant expression, the conversion strategy can be established, and the user obtains the converted role.

5. The access control method based on the computable credit degree in a distributed multi-trust domain environment according to claim 1 or ⁴ , characterized in that, after the conversion can be achieved from the source node set described in step five In the role set, select the target role with the highest priority as the final converted role, and update the role set held by the user as the initial local character set when the next user requests.

The method according to claim 1, wherein the behavior-based role conversion in the fifth step is specifically directed to role conversion. The optimal path discovery in the figure involves a role transformation strategy and a role transformation directed graph.

7. The method according to claim 6, wherein the role conversion strategy comprises a source role expression, a target role, and a conversion in a distributed multi-trust domain environment. Condition these three elements, where:

The source role expression is the input of the role conversion strategy. There are two forms, a single role or a role group connected by multiple roles. Each role in the role expression can be a role granted by the trust domain, or Target roles after multiple conversions within the trust domain:

The target role is the output of the role conversion strategy. It can only be in the form of a single role. Each target role is assigned a priority and variable threshold. Each target role has a priority. The higher the priority, the higher the priority. The greater the permissions: Each target role contains multidimensional variables, each of which is used to describe the cumulative initial value of a specific behavior for that role:

8. The method according to claim 6, wherein the role transition directed graph is a visual representation of a set of role transition strategies in a distributed multi-trust domain environment. The form, described by a set of vertices, a set of directed edges, and a set of transformation conditions, where:

Each element in the vertex set is a role defined by the trust domain: When a vertex is used as the target node, the role transition comes from the input directed edge set corresponding to the vertex: When a vertex is used as the source node, the role The transformation comes from the set of output directed edges corresponding to the vertex:

The directed edge set consists of the role conversion strategy: Each edge contains the source node, that is, the role before the conversion, the target node, that is, the converted role: each directed edge corresponds to the conversion condition and the group attribute, and the conversion condition is The judgment of the directed edge path, the group attribute identifies whether the source node of the directed edge belongs to an element in the group role: if the group attribute is null, it indicates that the directed edge corresponds to a role conversion strategy: If the group attribute is a non-null value, it indicates that the directed edge and the remaining directed edges with the same group attribute together constitute a role conversion strategy:

The role conversion process of the directed graph combines two processes of forward search and backward search: the forward search uses the initial set of characters held by the user as the source node set, and the output edge of each node is passed. The behavior-based transition condition is judged to obtain the target role node, and the source node set is updated: The backward search starts from the highest priority role in the local trust domain, and obtains the source by determining the input side based on the behavior-based transition condition. End the role node, and update the target node set. Each backward search starts with a priority according to the priority, so each target node set is derived from a starting role of the backward search:

The target role is the starting node of the backward search if and only the target character set currently being searched for and the target character set of the backward search contains the same character expression element.

The access control method based on the computable credit degree in the distributed multi-trust domain environment according to claim 1, wherein the reputation value of the role described in step 6 is obtained by the following method:

Looking for a foreign domain role? Corresponding user group, any of the users i performed different behaviors in a certain period of time, based on the pre-set confidence quantization standard value and cumulative execution number formula 7 , = « + (1- «) * (1 - Production - ¹ calculates the behavior evaluation value of a user corresponding to the character 7L, where "represents the trust gene, indicating the increment factor. As the /3⁄4· increases, 7L will gradually tend to the ideal value. :

7 , = « + (1— «) * (1 production - ¹ , Different behaviors are grouped by behavior H?

Where: Each action corresponds to /2 different performers:

T _k =(∑T _kl )/n calculates the evaluation mean 7 of the behavior k corresponding to a character;

'■=1

Q _k =(∑ _{Pk l} ) The total number of executions of the calculation behavior ft:

;=1 to generate the evaluation vector of the behavior A corresponding to the character: B ^→ E _k = (R, T _k , Q _k ); According to different behavior IDs, the total number of executions of each behavior is used as the weight, and the overall behavior The evaluation value 7 is used as the weight value, and the comprehensive evaluation value of a behavior is weighted and statistically calculated to obtain the role reputation. The following formula calculates the reputation of the role Ζ ?

R^(D.R) = (3⁄4r, .

10. The access control method based on the computable reputation in the distributed multi-trust domain environment according to claim 1, wherein the dynamic adjustment of the trust relationship between the roles described in step 7 is: Relationship 1, both correspond to a reputation expression as a condition for its establishment. If it is judged to be true, then 7 is valid, otherwise 7 is invalid, and it is found whether there is another trust relationship in the 7-linked role mapping policy set. If not, It indicates that the overall behavior of the user group corresponding to the role in the past period is not good, resulting in a decrease in the reputation value. The local trust domain temporarily revokes the trust relationship from the foreign domain role to the local domain.