RBAC role permission design ideas, rbac role design ideas_PHP tutorial

RBAC role permissions design ideas, rbac role design ideas

1 Design ideas

In order to design a set of user authentication management with strong scalability, it is necessary to establish database tables such as users, roles and permissions, and establish relationships between them. The specific implementation is as follows. 1.1 User Users are just pure users, used to record user-related information, such as user names, passwords, etc., and the permissions are separated. To have permissions for a certain resource, a user must be associated with a role. Users typically have the following attributes: ü Number, unique in the system. ü Name, unique in the system. ü User password. ü Comments, information describing the user or role. 1.2 Characters A role is the basic unit of permissions. It has a certain number of permissions. User permissions are granted through roles. They usually have the following attributes: ü Number, unique in the system. ü Name, unique in the system. ü Comments, describing character information 1.3 Permissions Permissions refer to the user’s access to certain functions of the program based on their role, such as the ability to read, write, modify, and delete files. They usually have the following attributes: ü Number, unique in the system. ü Name, unique in the system. ü Comments describing permission information 1.4 The relationship between users and roles A user (User) can belong to multiple roles (Role), and a role group can also have multiple users. User roles are objects used to describe the affiliation relationships between them.A user has permissions on a certain resource associated with a role, such as l User (User): UserID UserName UserPwd 1 Zhang San xxxxxx 2 Li Si xxxxxx …… l Role: RoleID                                                                                                                                                                               01 System Administrator Monitoring System Maintenance Administrator 02 Monitoring personnel Online monitoring personnel 03 Scheduling staff Scheduling staff 04 General staff Staff  … l   User_Role: UserRoleID UserID RoleID UserRoleNote 1 1 1 01 The user "Zhang San" is assigned to the role "System Administrator" 2 2 2 02 The user “李思” is assigned to the role “Monitoring Personnel” 3 2 2 03 The user "李思" is assigned to the role "Scheduler" …… It can be seen from this relationship table that specific resources owned by users can be associated through user roles. 1.5 The relationship between permissions and roles A role can have multiple permissions, and the same permission can be assigned to multiple roles.For example: l Role: RoleID                                                                                                                                                                               01 System Administrator Monitoring System Maintenance Administrator 02 Monitoring personnel Online monitoring personnel 03 Scheduling staff Scheduling staff 04 General staff Staff  … l Permission: PermissionID PermissionName PermissionNote 0001 Add monitoring Allow to add monitoring objects 0002 Modify monitoring Allow modification of monitoring objects 0003 Delete monitoring Allow deletion of monitoring objects 0004 View monitoring information Allow viewing of monitored objects …… l Role permission (Role_Permission): RolePermissionID RoleID PermissionID RolePermissionNote 1 The role "System Administrator" has the permission "Add Monitoring" 2 The role "System Administrator" has the permission "Modify Monitoring" 3 The role "System Administrator" has the permission "Delete Monitoring" 4 The role "System Administrator" has the permission "View Monitoring" 5 02 0001 role "monitoring personnel" with permissions "increase monitoring" 6 02 0004 The role "Monitor" has the permission to "View Monitoring" …… It can be seen from the role permission relationship in the above example that role permissions can establish the corresponding relationship between roles and permissions. 1.6 Establish user permissions The core of the user permission system consists of the following three parts: creating permissions, assigning permissions and using permissions. The first step is for the Creator to create permissions (Permission), which will be divided when the Creator designs and implements the system. Use the stored procedure CreatePermissionInfo (@PermissionName, @PermissionNote) to create permission information and specify what permissions the system module has. The second step is for the system administrator (Administrator) to create users and roles, and specify the relationship between user roles (User-Role) and role permissions (Role-Permission).

1) It has the functions of creating users, modifying users and deleting users: Administrator

l The stored procedure CreateUserInfo (@UserName, @UserPwd) creates user information; l The stored procedure ModifyUserInfo (@UserName, @UserPwd) modifies user information; l The stored procedure DeleteUserInfo (@UserID) deletes user information;

2) Has the function of creating and deleting roles: Administrator

l The stored procedure CreateRoleInfo (@RoleName, @RoleNote) creates role information; l The stored procedure DeleteRoleInfo(@RoleID) deletes role information; 3) Administrator has the function of establishing relationships between users and roles, roles and permissions: l The stored procedure GrantUserRole (@UserID, @RoleID, @UserRoleNote) establishes the relationship between users and roles; l The stored procedure DeleteUserRole(@UserRoleID) deletes the association between users and roles; l The stored procedure GrantRolePermission(@RoleID,@PermissionID,@RolePermissionNote) establishes the relationship between roles and permissions; l The stored procedure DeleteRolePermission(@RolePermissionID) deletes the association between roles and permissions; The third step is that the user (User) uses the permissions assigned by Administrator to use each system module. Use the stored procedures GetUserRole (@UserID, @UserRoleID output), GetRolePermission (@RoleID, @Role- -PermissinID output) to obtain the user's permission to use the module. 1.7 User Authentication Implementation When the user passes the verification, the system automatically generates a 128-bit TicketID and saves it in the user database table, and establishes the stored process Login (@UserID, @UserPwd, @TicketID output) for user authentication. After passing the authentication, a TicketID is obtained. Otherwise TicketID is null. The flow chart is as follows: <span> </span> Figure 1 Login flow chart After getting the TicketID, the client passes the TicketID when calling the server method, determines the permissions of the user corresponding to the TicketID through the stored procedure JudgeTicketPermission (@TicketID, @PermissionID), and makes method calls based on its permissions. When the user exits the system, create a stored procedure Logout (@UserID) to exit the system. When a user exits the system abnormally, the user's TicketID is determined based on the last login time (LastSignTime), and a stored procedure ExceptionLogout (@UserID, @LastSignTime) is established to handle the user's abnormal exit. <span> </span> Figure 2 Logout flow chart WebService can use the SoapHeader to write the TicketID to pass the TicketID from the client to the server. .Net Remoting can use the CallContext class to pass TicketID from the client to the server. 2 Database Design 2.1 Database table <span> </span> Figure 3 Database relationship diagram 2.2 Database table description 2.2.1 User table (Static_User) <span> </span> Static_User

<span> </span>

Static_User field name	Detailed explanation	Type	Remarks
UserID	Route number	varchar(20)	PK
UserName	User Name	varchar(20)	<span> </span> <span> </span>
UserPwd	User password	varchar(20)	<span> </span> <span> </span>
LastSignTime	Last login time	datatime	<span> </span> <span> </span>
SignState	User login status mark	int	<span> </span> <span> </span>
TickeID	Verification ticket record number	varchar(128)	<span> </span> <span> </span>
<span> </span> <span> </span>	<span> </span> <span> </span>	<span> </span> <span> </span>	<span> </span> <span> </span>

<span> </span>

<span> </span>

<span> </span>

2.2.2 Role table (Static_Role) <span> </span> Static_Role

<span> </span>

Static_User字段名	详细解释	类型	备注
RoleID	角色编号	varchar(20)	PK
RoleName	角色名称	varchar(20)
RoleNote	角色信息描述	varchar(20)

Static_User field name

Detailed explanation

Type

Static_User字段名	详细解释	类型	备注
UserRoleID	用户角色编号	varchar(20)	PK
UserID	用户编号	varchar(20)	FK
RoleID	角色编号	varchar(20)	FK
UserRoleNote	用户角色信息描述	varchar(20)

Remarks RoleID Character number varchar(20) PK RoleName Character name varchar(20) RoleNote Character information description varchar(20) 2.2.3 User-Role Table (Static_User_Role) Static_User_Role Static_User field name Detailed explanation Type Remarks UserRoleID User role number varchar(20) PK UserID User ID varchar(20) FK RoleID Character number varchar(20) FK UserRoleNote User role information description varchar(20)

<span> </span>

<span> </span>

2.2.4 Permission table (Static_Permission) <span> </span> Static_Permission

<span> </span>

Static_User字段名	详细解释	类型	备注
PermissionID	编号	varchar(20)	PK
PermissionName	权限名称	varchar(20)
PermissionNote	全息信息描述	varchar(20)

Static_User field name

Detailed explanation

Type

Remarks

PermissionID

Static_User字段名	详细解释	类型	备注
RolePermissionID	角色权限编号	varchar(20)	PK
RoleID	角色编号	varchar(20)	FK
PermissionID	权限编号	varchar(20)	FK
RolePermissionNote	角色权限信息描述	varchar(20)

Number

varchar(20)

PK

PermissionName

Permission name

varchar(20)

PermissionNote

Holographic information description

varchar(20)

2.2.5 Role-Permission Table (Static_Role_Permission) Static_Role_Permission

Static_User field name	Detailed explanation	Type	Remarks
RolePermissionID	Role permission number	varchar(20)	PK
RoleID	Character number	varchar(20)	FK
PermissionID	Permission number	varchar(20)	FK
RolePermissionNote	Role permission information description	varchar(20)

<span> </span>

3 .net technology overview 3.1 WebService SoapHeader Perform custom authentication and authorization against SQL databases. In this case, you should pass custom credentials (such as username and password) to the service and let the service handle authentication and authorization itself. An easy way to pass additional information along with the request to an XML Web service is through SOAP headers. To do this, define a class derived from SOAPHeader in the service and declare the service's public fields to that type. This is exposed in the service's public contract and is available to clients when creating a proxy from WebServiceUtil.exe, as shown in the following example:

<span> </span>

<span> </span>

<span> </span>

<span> </span>

<span> </span>

using System.Web.Services;

using System.Web.Services.Protocols;

<span> </span>

// AuthHeader class extends from SoapHeader

public class AuthHeader : SoapHeader {

public string Username;

public string Password;

}

<span> </span>

public class HeaderService : WebService {

public AuthHeader sHeader;

...

} Each WebMethod in a service can define an associated set of headers using the SoapHeader custom property. By default, the header is required, but optional headers can be defined. The SoapHeader property specifies the name of a public field or property of the Client or Server class (called the Headers property in this title). The WebService sets the value of the Headers property before calling the method for input headers; the WebService retrieves the value when the method returns for output headers.

[WebMethod(Description="This method requires a custom soap header set by the caller")]

[SoapHeader("sHeader")]

public string SecureMethod() {

<span> </span>

if (sHeader == null)

return "ERROR: Please supply credentials";

else

return "USER: " sHeader.Username;

<span> </span>

}

The client then sets the header directly on the proxy class before calling a method that requires the header, as shown in the following example:

HeaderService h = new HeaderService();

AuthHeader myHeader = new AuthHeader();

myHeader.Username = "username";

myHeader.Password = "password";

h.AuthHeader = myHeader;

String result = h.SecureMethod();

3.2 Security authentication method of .Net Remoting CallContext provides a set of properties that are passed along with the execution code path. CallContext is a dedicated collection object similar to the thread local storage of method calls and provides a data slot that is unique to each logical execution thread. Data slots are not shared between calling contexts on other logical threads. Objects can be added to the CallContext as it propagates back and forth along the execution code path and is inspected by various objects in that path. When a remote method call is made to an object in another AppDomain, the CallContext class generates a LogicalCallContext instance that is propagated with the remote call. Only objects that expose the ILogicalThreadAffinative interface and are stored in the CallContext are propagated outside the AppDomain in the LogicalCallContext. Objects that do not support this interface are not transferred with remote method calls in LogicalCallContext instances. The CallContext.SetData method stores the given object and associates it with the specified name, and the CallContext.GetData method retrieves the object with the specified name from the CallContext. The following code example shows how to use the SetData method to transfer a body and identity object to a remote location for identification.

public class ClientClass {

public static void Main() {

GenericIdentity ident = new GenericIdentity("Bob");

GenericPrincipal prpal = new GenericPrincipal(ident,

                                                                                                                              

LogicalCallContextData data =

new LogicalCallContextData(prpal);

//Enter data into the CallContext

CallContext.SetData("test data", data);

     

      Console.WriteLine(data.numOfAccesses);

      ChannelServices.RegisterChannel(new TcpChannel());

      RemotingConfiguration.RegisterActivatedClientType(

typeof(HelloServiceClass), "tcp://localhost:8082");

      HelloServiceClass service = new HelloServiceClass();

      if(service == null) {

          Console.WriteLine("Could not locate server.");

          return;

      }

 

      // call remote method

      Console.WriteLine();

      Console.WriteLine("Calling remote object");

      Console.WriteLine(service.HelloMethod("Caveman"));

      Console.WriteLine(service.HelloMethod("Spaceman"));

      Console.WriteLine(service.HelloMethod("Bob"));

      Console.WriteLine("Finished remote object call");

      Console.WriteLine();

 

      //Extract the returned data from the call context

      LogicalCallContextData returnedData =

         (LogicalCallContextData)CallContext.GetData("test data");

 

      Console.WriteLine(data.numOfAccesses);

      Console.WriteLine(returnedData.numOfAccesses);

   }

}

下面的代码示例说明如何使用 GetData 方法将主体和标识对象传输到远程位置以进行标识。

using System;

using System.Text;

using System.Runtime.Remoting.Messaging;

using System.Security.Principal;

 

public class HelloServiceClass : MarshalByRefObject {

   static int n_instances;

   int instanceNum;

 

   public HelloServiceClass() {

      n_instances ;

      instanceNum = n_instances;

      Console.WriteLine(this.GetType().Name " has been created.

             Instance # = {0}", instanceNum);

   }

 

  ~HelloServiceClass() {

      Console.WriteLine("Destroyed instance {0} of

HelloServiceClass.", instanceNum);     

   }

 

   public String HelloMethod(String name) {

 

      //Extract the call context data

      LogicalCallContextData data =

          (LogicalCallContextData)CallContext.GetData("test data");     

      IPrincipal myPrincipal = data.Principal;

     

      //Check the user identity

      if(myPrincipal.Identity.Name == "Bob") {

         Console.WriteLine("nHello {0}, you are identified!",

myPrincipal.Identity.Name);

         Console.WriteLine(data.numOfAccesses);

      }

      else {

         Console.WriteLine("Go away! You are not identified!");

return String.Empty;

}

<span> </span>

// calculate and return result to client

return "Hi there " name ".";

}

}

4 Detailed code design 4.1 WebService code design The WebService side code mainly operates the database and establishes the methods required by the Client to operate the database for the Client to call.

1) class UserInfoMng() User information management class, which includes methods:

l CreateUserInfo(string UserName string UserPwd) Create user information and call the stored procedure CreateUserInfo(@UserName,@UserPwd)

l ModifyUserInfo(string UserName string UserPwd) Modify user information and call the stored procedure ModifyUserInfo(@UserName,@UserPwd)

l DeleteUserInfo() Delete user information and call the stored procedure DeleteUserInfo

(@UserID)

2) class UserAuthentication() User authentication class, used to set user roles and permissions, including methods:

l CreatePermissionInfo(string PermissionName string Permissi-

-onNote) Create permission information and call the stored procedure CreatePermissionInfo

(@PermissionName,@PermissionNote)

l CreateRoleInfo(string RoleName string RoleNote) Create role information and call the stored procedure CreateRoleInfo(@RoleName,@RoleNote)

l DeleteRoleInfo() Delete role information and call the stored procedure DeleteRoleInfo

(@RoleID)

l GrantUserRole(string UserID string RoleID string UserRoleNote) Grants the user role and calls the stored procedure GrantUserRole(@UserID,@RoleID,

@UserRoleNote)

l DeleteUserRole() Delete the user role and call the stored procedure DeleteUserRole

(@UserRoleID)

l GrantRolePermission(string RoleID string PermissionID string RolePermissionNote) Grants role permissions and calls the stored procedure GrantRolePermission(@RoleID,@PermissionID,@RolePermissionNote)

l DeleteRolePermission() Delete the granted role permissions and call the stored procedure

DeleteRolePermission(@RolePermissionID)

4.2 User Authentication Code Design (Client) The client calls the WebService method to access the database. The client code design mainly implements the functions of the interface, including: permission setting, user management, user authorization management and user authentication management

1) Permission settings

class PermissionInfoMng() User permission information management class, including methods:

l CreatePermissionInfo() Create permission information

2) User Management

class UserInfoMng() User information management class, including methods:

l CreateUserInfo() Create user information

l ModifyUserInfo() Modify user information

l DeleteUserInfo() Delete user information

3) User authorization management

class RoleInfoMng() role information management class, including methods:

l CreateRoleInfo() Create role information

l DeleteRoleInfo() Delete role information

class UserRoleMng() User role management class, including methods:

l    GrantUserRole() Grants user role

l DeleteUserRole() Delete user role

class RolePermissionMng() Role permission management class, including methods

l    GrantRolePermission() Grants role permissions

l DeleteRolePermission() Delete role permissions

4) User authentication management

class Authentication() User authentication class, including methods:

l Login(string UserName string UserPwd) User login authentication. After user authentication, a TicketID is assigned to the user, otherwise the TicketID is null

l Logout() The user logs out normally

l ExceptionLogout() User exits abnormally

http://www.bkjia.com/PHPjc/1115256.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/1115256.htmlTechArticleRBAC role permissions design ideas, rbac role design ideas 1 design ideas in order to design a set of highly scalable User authentication management requires the establishment of databases such as users, roles and permissions...