Abstract This article introduces an application to
The design framework of the enterprise application universal user rights system, its design ideas and main documents
SUNWU Software Studio
IsecurityManager® products. This guide is suitable for architectural designers and developers.
table of Contents
Introduction User and Role Action Defining Application Module Authorized Summary Link Resources
Introduction
Safety is always a trusted corporate application of the cornerstone.
In enterprise applications, it is often necessary to control user permissions management and control of business operations. Take a little analysis is not difficult to find out that this will involve these three objects:
User / role,
Action / operation,
Authorized status, further analysis, we can find "Action / Operation" is usually for a particular object, such as the "new" action can correspond to the "purchase application order" or corresponding to "sales outline bill", etc. Objects corresponding to the action We call it "
Application module.
At this point, the basic logic in the user permission system is visible:
Who (user / role) does (application module) have an authorization (authorization status: grant-Grant, reject -deny, inherit -Revoke).
The basic unit of the user and the role use permission, the role is a intersection with a set of identical authorized users. There is no relationship between users and users, it can only be part of the role, and the role can be partially affiliated with another role and can have multiple relationships.
User or roles typically have the following properties:
Number, unique in the system. Name, unique in the system. User Password (Role No This Properties) Of course, in actual business applications, more properties may also be needed to describe specific business needs. In
The information of users and roles in IsecurityManager® is as follows:
Figure 1: Role information
Figure 2: User information has user and role objects, but also have an object that describes the affiliated relationship between them, this object we call "Member", usually it may have the following properties:
User Number Role Number This "User Number" and "Role Numbe" combination unique constraints, "User Number" here may be the number of a user object, or it may be the number of a role object, and "Role Number" is always only Corresponding to a number of characters. A member relationship object represents a user or role belonging to another role. in
IsecurityManager® may have the following interface representation:
Figure 3: User / role member relationship
ISecurityManager® is used to set the role belonging to any user or role (except for system fixed users and roles) by "Member Settings" window.
Role Properties window to set direct subordinate members belonging to the current role.
Action definitions In applications involving database operations, four basic operations are "Select", "Delete", "Insert" and "Update". Of course, there will be more other operations in a business application, although these operations may eventually be based on these four basic operations, or other non-data operations, and we have never fully fixed these possibilities at the beginning. Operation, for this, the system developers must be able to make the system developers according to each specific
Application module to define specific specific
Action / operation.
Action / Operation usually has the following properties:
Name, unique in the system. Remarks, describe the action / operation. In
The information of "Action Definition" in ISecurityManager® is as follows:
Figure 4: Action definition in fact, some actions are required for specific data instances, such as "View", "Delete", and "Update", etc., this control ratio of the data instance level is controlled for the "Application Module" level. It is more fine. For example, a user can perform the operations of [Purchase Application Form], and he should be able to view the documents he just filled in and make some appropriate modifications, but he should not see the data filled in with others. Then, this coarse granular permission setting is clearly unable to control the data level, in IsecurityManager®, specifically using the "Process Control" and techniques to achieve more granularity of data instance level access and control.
Application module
The application module usually refers to some type of business document corresponding to enterprise applications, such as
[Purchase Application Form], [Sales Outlet], [Customer Basic Information], etc. in the ERP system, these business documents may correspond to one or more database tables. If you are from object-oriented
Viewing the perspective of Object Oriented), it seems that these concepts described herein will be understood: "
Application module "is class,"
Action / Operation, is a method of class, and the database table (table structure) corresponding to the "Application Module" is the properties of the class, and the data / records in the table are the instance of the class.
When defining the "Application Module" in the planning system, it is often necessary to specify a "action / operation" that a "application module" may have, and these "action / operation" is defined by the "Action Definition".
Note: The application module is a logical organization unit in the system.
Application modules typically have the following properties:
Name, unique in the system. Title, describe the action / operation. A list of action indicates all the operations that the application module may have. In
The information "Application Module" in ISecurityManager® is as follows:
Figure 5: Application module definition
Authorized as the name,
Authorization means
Which user / role can be
Some of the application module
Whether the operation (action) has permission to perform. "Whether to perform permission" is actually the three states of authorization:
Award-GRANT,
Reject-Deny,
Inherit -Revoke.
Grant: The user / role has the power to perform on an operation of an application module. Reject: The user / role does not perform the power to perform an action of an application module. Inheritance: The power of the user / role for an operation of an application module has executed to depends on the authorization definition of its parent role. If a role is granted a certain power, the user or role of the subordinates can overwrite the authorization definition. By default, the principles are adopted to reject priority.
in
The information "Authorized Settings" in ISecurityManager® is as follows:
Figure 6: Permission settings
Summary usually "
Application module "and"
The action definition is defined by the system developer in the system design and development phase. It will no longer change this after the system is delivered to the user (of course, this is not absolute, isn't it?).
At this point, the settings for the user privilege are completed. In fact, this does not immediately bring any security to your application, this is just a bunch of setting data about the user and authorization definition, must also Use these settings data in the application system and control the business data according to its defined control logic. How to use these user authorization data to control access to business data, there are many different solutions, but I think I have to build a middle data storage layer to unify all clients to store data sources is a good idea, and This data access layer applies security settings to authorize verification and control of various access to business data, so that you can unify the security applications of various clients (in fact IsecurityManager® is so processing this problem) .
Popeye Zhong is currently an architectural designer of Shenzhen Hengtaifeng Technology Company. He used C language to do graphical programming, engaged in the development and design of COM / COM components during a considerable period of time, and the development of Lotus / Notes and Dialogic voice card, starting from 2003 .NET This is full of fun and challenge development platform. In addition to enterprise application architecture design, component development, security, image processing, there is a strong interest in automobiles and firearms models. If you want to contact him, you can visit
Http://blog.9cbs.net/sw515 or email
SW515@21cn.com.
Related Articles: "Safety Way: Encryption and Digital Signature"
[1] Enterprise Applications: Enterprise applications include payroll, patient records, delivery tracking, cost analysis, credibility assessment, insurance, supply chain, production management, accounting, customer service, and foreign currency transactions. Enterprise applications do not include vehicles, text processing, elevator control, telephone exchange, operating system, compiler, and video games. [Reference to "Enterprise Application Schema Mode" Martin Fowler
