Shulou(Shulou.com)06/03 Report--

Data address: http://down.51cto.com/data/2459472

Rbac specification solves the problem of non-specification and uncertainty 3. Term {one of the four RBAC feature sets of component component (core RBAC level RBAC static separation of duties dynamic separation of duties) object object system resource operations that require access control operation an executable image of a program Certain functions performed for the user when called GET permission permission to perform an operation on one or more objects protected by RBAC A license role in the context of a work function user user to access resources or services implementation principal session session user to their activated role set a mapping responsibility separation separation of duty restricts the user to obtain a permission set with a conflict of interest} 4. Acronym {1.RBAC role-based access control 2.SSD 3.DSD 4.USERS 5.ROLES 6.OBJS7.OPS8.SESSIONS 9.PRMS 10.ACL access control list} 5. The consistency core RBAC is a required component. Role hierarchy, static constraints and dynamic constraints are the definitions of each model component of the optional component 6.RBAC reference model: some basic element sets, some RBAC relationships based on the above basic element sets, some mapping functions (some instance elements of another element set are given under the instance elements of another element set) {1. Core RBAC {five basic data elements: users roles objs ops prms permissions assigned roles to users session set session is a mapping from a user to an active role subset of that user's role set a session can only be associated with one user and a user can have multiple session sessions to save a subset of the roles activated by the user, including the available permissions for the roles activated by the user Permissions include related operation permissions, including relevant object specifications 1.users, roles, ops, objs. two。 User / role many-to-many mapping 3. Give the user assigned to role r 4. Permission set 5. Permission / role many-to-many mapping 6. The permissions assigned to role r are given 7. Mapping of permissions to operations 8. Mapping of permissions to objects 9. Session set 10. Mapping of session s to corresponding user 11. Mapping of session s to its active role set 12. Session s to the mapping of its permission set} 2. Hierarchical RBAC {A structure that effectively reflects authority and responsibility within an organization R1 inherits R2, then R1 has all R2 permissions and its own permissions in some distributed RBAC implementations, there are two types of role hierarchies: general role hierarchy and restricted role hierarchy (a role can have one or more direct ancestors, but only one direct descendant. A tree) the specification for the extension of general role hierarchy: 1. The partial order relationship between inherited roles R1 > = R2 R1 has all permissions of R2 and the user of R1 will be user 2 of R2. If the role hierarchy exists, the mapping of the role to the authorized user of the role 3. The mapping of roles to authorized permissions under the role level} 3. RBAC with constraints {static separation of duties without role hierarchy (rs,n) users cannot be assigned by n or more roles in rs at the same time static separation of duties with role hierarchy (rs,n) role-based authorized users Instead of directly assigning the user to the role to redefine the dynamic separation of responsibilities}} 7.RBAC system and management function specification functional specification describes the management operations to create and maintain the set of RBAC elements and RBAC relationships to manage queries management view functions to create and maintain RBAC attributes of user sessions and system functions to make access control decisions {core RBAC { Management function 1.AddUser when the newly created user does not already exist The command is available. After the command is executed, users updates 2.DeleteUser if and only if the deleted user is available in users. After execution, the users dataset ua dataset assigned_users function is updated. A user who is in session is deleted without definition. You can force or wait for the session to end 3.AddRole if and only if the role to be created does not have an available post-execution roles dataset, the assigned_users assigned_permissions function is updated 4.DeleteRole if and only if the deleted role exists, how to handle the undefined roles dataset in the executed session, The assigned_users assigned_permissions function is updated 5.AssignUser assigns roles to the user if and only if the user belongs to the users role belongs to the roles available post-execution UA dataset, the assigned_users is updated the 6.DeassignUser user removes the role if and only if the user belongs to the users role belongs to the roles and user has been assigned to the role available post-execution UA dataset, Assigned_users is updated 7.GrantPermission assigns the role permission to perform an operation on an object if and only if the operation, the object represents a permission, and the role is in the roles. In the actual implementation, it may be implemented to grant the corresponding permissions to the group of the role. That is, after the ACL of the modified object is executed, the PA dataset assigned_permissions function is updated and 8.RevokePermission revokes a permission in the permission set assigned to the role if and only if the operation represents a permission and has been assigned to the role, the ACL table of the modified object may be executed after the PA dataset assigned_permissions function is updated by the system function 1.CreateSession} hierarchical RBAC {} static separation of duties Department {} dynamic responsibility separation relationship {} chapter 6 from the element set, From the point of view of relationship and management query, the RBAC reference model is defined as four model components attachment 1 discusses the abstract model 1 from the point of view of the functional specification of management operation, session management and management view. Core RBAC functional specification {three types of functional specification function 1. Management function core RBAC basic elements: users, roles, ops, objs. Ops and objs are defined by the underlying system that deploys RBAC. Administrators can create and delete members of users and roles, and create relationships between roles, actions and objects, AddUser DeleteUser user AddRole DeleteRole role AssignUser DeassignUser UA user-role GrantPermission RevokePermission PA perm-role 2. 0. Support system functions session management, access control decision CreateSession to create a session and assign a set of default activation roles to the session AddActiveRole add a role to the active role set of the session DropActiveRole delete a role CheckAccess from the active role set of the session to determine whether the conversation subject can perform an operation on an object. Check that after the function PA UA instance is established You should be able to view their content from the perspective of users and roles. Optional function O UserPermission O returns the user's available permissions SessionRoles O returns the active role set of the session SessionPermissions O returns the permissions available for the session RoleOperationsOnObject O returns the actions that can be performed by a given role on a given object UserOperationsOnObject O returns a mandatory function that the user can perform on a given object M AssignedUsers M returns the user assigned a given role AssignedRoles M returns the role assigned to the given user} 2. Hierarchical RBAC functional specification {1. The hierarchical management function contains all the management functions of the core RBAC And the semantics of DeassignUser need to be redefined (only directly authorized roles can be deleted or any authorized roles can be deleted without stipulation) hierarchical RBAC requires additional management functions: creating and deleting direct inheritance relationships between existing roles, Add a newly created role to an existing role hierarchy AddInHeritance creates a direct inheritance relationship between two existing roles DeleteInheritance deletes the direct inheritance relationship between two existing roles there is no requirement whether the implied inheritance relationship is broken Self-defined AddAsendant to create a new role and designate it as a direct ancestor of an existing role AddDescendant to create a role, and specify it as a direct descendant of an existing role-support general role hierarchy (allows multiple inheritance) and the first role hierarchy (a tree, each role has only one direct descendant) 2. Support system function CreateSession AddActiveRole due to the existence of role hierarchy, the active role set created by CreateSession contains roles assigned directly to users and roles inherited by these roles. AddActiveRole users can activate directly assigned roles and inherited roles. Whether the inherited role is automatically activated or must be displayed does not explicitly require 3. The view function contains the core RBAC and the following function AuthorizedUser returns the user assigned to the given role or the role inherited by the role (authorized user of the given role) AuthorizedRoles returns the role assigned by the given user and the role that inherits these roles (the authorized role of the given user) the optional function RolePermissions returns the permissions directly or inherited from the given role UserPermissions returns the corner directly assigned by the given user Color or permissions inherited from other roles RoleOperationsOnObject returns actions (direct or inherited) owned by a given role on a given object (direct or inherited) UserOperationsOnObject returns actions that a given user can perform on a given object (through directly assigned roles or roles inherited by these roles)} 3. Static responsibility separation relationship functional specification {1. The administrative function SSD limits the roles that can be assigned by a user's colleagues AssignUser should not violate any SSD constraints A SSD relationship consists of three tuples: SSD_Set_Name role_set SSD_CardSSD_Set_Name specifies the name of a transaction or business process that restricts user / role assignment to implement the conflict of interest strategy role_set is the role set corresponding to SSD_Set_Name SSD_Card gives a threshold non-role hierarchical SSD RBAC management function CreateSSDSet to create a named SSD relationship DeleteSSDSet deletes an existing SSD relationship AddSSDRoleMember adds a role to a given SSD character set DeleteSSDRoleMember removes a character from a given SSD character set SertSSDCardinality sets a threshold for a given SSD character set-- role hierarchy SSD only needs combined constraints and SSD constraints for role hierarchy should satisfy 2. Support system functions and core RBAC has been 3. 5. Look at the core function RBAC and the following function: SSDRoleSets returns the named SSD relationship in SSD RBAC SSDRoleSetRoles returns the role SSDRoleSetCardinality associated with a given named role set returns the threshold associated with a given named character set} 4. Functional specification of dynamic separation of responsibilities {1. Management function CreateDSDSetDeleteDSDSetAddDSDRoleMember DeleteDSDRoleMemberSetDSDCardinality2. Support system function CreateSession AddActiveRole DropActiveRole cannot violate DSD constraint 3. View the function DSDRoleSetsDSDRoleSetRolesDSDRoleSetCardinality} 4. The functional specification package RBAC is a technology that provides many access control management features. Chapter 6 defines a functional component family: core RBAC level RBAC static responsibility separation relationship dynamic responsibility separation relationship each functional component consists of three parts: management operations for creating and maintaining RBAC element sets and relationships, management view functions, System-level user session management and access control policy functions {(advanced view is optional) (required) core RBAC-> (optional) role hierarchy RBAC (limited / generic choose one of the two)-> (optional) SSD relationship (following dependency with / without role hierarchy corresponds to the previous choice)-> (optional) DSD relationship-> requirements package}- -component principle 1. Core RBAC {users / roles many to many roles / permissions many to many} 2. Hierarchical RBAC {role hierarchy is a mathematical partial order relation. Roles can have coincident permissions} 3. Static separation of duties constrains the assignment of users / roles and implements the conflict of interest policy (role_set,n) pair. N or more roles that users cannot be assigned to the role_set role set often impose restrictions on management operations that may violate the separation of responsibilities of high-level organizations. 4. Dynamic separation of duties is different from SSD in that context DSD limits the availability of user permissions by limiting the roles that can be activated in the never session. A user is assigned two separate roles. But these two roles cannot exercise permissions at the same time-- Z language: basic unit: pattern: description part + predicate part: define some state or pattern variable predicate part: define general predicate formula-- -https://casbin.org/docs/zh-CN/rbac1. Plug-in {1. Policy storage plug-in https://github.com/search?q=org%3Acasbin+adapter&unscoped_q=adapterfile gorm xorm mongodb redis protobuf redis json awss32. Policy synchronization plug-in https://github.com/casbin/etcd-watcherhttps://github.com/billcobbler/casbin-redis-watcherredis etcd 3. Role Management plug-in.}

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.