Enterprise information software permission design overview

ArticleDirectory

• Release date:

 

Release date:

Applicable to: Software architects

Abstract: Through examples and concepts, this article describes the general methods of permission design in enterprise information software, helping architects quickly establish security models required by customers.

Content

Enterprise information software permission design overview

Status quo

Starting from an example

Use these concepts in ERP

Determine subject

Define available certificates

Authorization

Security check

Rejection

Shareto Functions

Summary

Permission Design for enterprise information software has always been a very difficult task, because in enterprise information software, the demand is always strange, it is difficult to have a unified solution, it not only meets complex permission requirements, but also ensuresProgramHigh Performance and maintainability.

Status quo

When designing a permission system, there are generally two kinds of orientations. One is to try to implement a "comprehensive solution". For example, you can set independent permissions for a single document, you can also design a dazzling setting interface. Another kind of tendency is to customize the permission system and establish a unique permission model based on the management ideas of different customers. For example, some enterprises want to divide permissions by jurisdiction, while others want to divide permissions by customer level of documents.

The first solution is to use abstract concepts to describe permissions, which makes user operations complicated and cumbersome, and will inevitably lead to slow program execution. The second solution is convenient for users and highly efficient for execution. However, customization is costly and cannot handle complicated permission requirements.

In this article, I will describe the design in favor of the second scheme, but I will emphasize the theory abstracted from the customization requirements and, in turn, simplify the design of the permission Model Based on this theory.

Starting from an example

First, from a simple example of life, we will learn how to design permissions from life.

A sports club can buy two types of membership cards: one is a gold card, the other is a silver card, the other is a gold card, of course, can play with advanced equipment, there is a VIP box, as for the silver card, you can only play in the hall.

Now someone bought a gold card and ran to the door of the VIP box. They said to the waiter at the door: I want to go in. The waiter checked the gold card, I thought about whether I could go to the box (one second in). Let's go in.

Now, let's start to "Theoretically" this story.

Resources: Indicates the content to be protected. In this example, the hall and the box are two types of resources. The resources contain some attributes to determine whether they can be used, for example, both the hall and the box contain a Level Attribute, which does not directly describe the permission. In ERP, orders and customers are all resources.

CertificateSome are referred to as creden, which can be recognized by the management. In this club, both the gold card and the silver card are recognized certificates. Of course, gold cards of other clubs are not recognized (unless the business is more complex). In ERP, common certificates include: roles, logon ID, department, and position can all be used as certificates.

Subject: Refers to the initiator who tries to access resources. In this example, a customer is a subject and a subject can have one or more certificates. In ERP, A logon user may have multiple role certificates.

Authorization: It refers to a group of accessible rules defined by the resource manager in advance. For example, the VIP box that the gold card can play is a rule defined by the club manager in advance. One authorization should be described:

Which certificates are required by the subject to perform actions on which resources.

In the above example, there is a word: action. In this example, action refers to use. As you can imagine, the club manager does not authorize a gold card customer to break the box. J

In ERP software, we often see the permission setting interface as a typical authorization definition process.

In the end, when a subject tries to access certain resources, the manager finally obtains accessible resources in the authorization definition based on the certificate held by the subject.

Use these concepts in ERP to determine the subject

Generally, the confirmation of the subject in ERP is very simple. They are all currently logged on users and are generally designed as an independent ERP verification process. net, You need to define the system. security. principal. iprincipal interface implementation class to describe the subject. If the program is very simple, you can directly use system. security. principal. genericprincipal.

Some ERP software integrates windows verification and also supports self-verification of ERP software. Generally, we define a mapped Windows account in our ERP account. When integrated verification is used, find the ERP account through the current Windows account, and finally take the ERP account as the subject.

Another scenario is automatic background services. For example, some large ERP systems may contain their own background services, which periodically perform operations such as report generation, such programs can define special accounts such as LocalService as the subject. You can see this example in the Windows service.

In. net, the subject contains a reference to the identity object, but does not directly contain the certificate definition.

The following is a simple example of setting the identifier object in. Net:

Console. writeline ("login ...");

Console. Write ("User name :");

String username = console. Readline ();

Genericidentity currentuser = new genericidentity (username );

Genericidentity is a simple identifier object built in. net. In. net, windowsprincipal and System. Web. Security. roleprincipal in the web are also provided.

Define available certificates

To use these concepts in ERP, you first need to summarize all the certificates available to the subject, that is, the types of certificates that can be recognized by the Administrator. For example, in the following example:

The Finance Manager can view the salaries of all employees.

In this example, the "Financial Manager" role is an accepted certificate, that is, a role is a certificate.

Each employee can view his/her salary

In this example, the employee archive is also an accepted certificate. Some software separates the login operator archive from the employee archive, the employee mapped to this operator is the certificate of this operator. Therefore, an employee is also a certificate.

The regional manager can view the sales orders of the region in charge.

When a regional manager logs on, the region defined by him will also become his certificate, which is a typical certificate linked to a specific business. Therefore, according to different business needs, more certificates except roles and employees may be defined. After a user logs on, they will be parasitic on the subject object and put into the session together.

Of course, the most common certificate is the role. As a habit, or as a good design, we will design the following special roles:

Role

Description

Everyone

Indicates that anyone, no matter whether you have an account or not, does not need to be specified to belong to this role;

Guest

Indicates that this role certificate is automatically lost to anyone not logged on;

User

It indicates a common user without any mandatory rules. It is automatically appended when a new user is created;

Administrator

Good stuff, developers understand

Backup Operator

Many designers ignore him. In fact, this role is very suitable for IT maintenance personnel.

In. net, certificates are stored in the subject. For example, the following example describes how to place the users and administrators roles in the subject.

Genericprincipal P = new genericprincipal (

Currentuser,

New String [] {"users", "Administrators "});

System. Threading. thread. currentprincipal = P;

Generally, in ERP, You need to define the subject object by yourself. It is an object that complies with the iprincipal interface, so that you can store various types of certificates in your own way.

Authorization

Authorization includes at least the following information:

L The certificate required for this authorization can be one or more certificates. Generally, the required certificate is a role certificate;

L the entities to which the authorization is granted. This is part of the security policy. For example, it can only be applied to orders, but it can also be a module. For example, it can access the entire sales system;

L The action authorized by this authorization is still part of the security policy. Actions generally include visibility, read-only, creation, update, deletion, and effectiveness.

L The last step is the specific condition of the security policy. For example, it is only your own order, indicating: Where ordersheet. sheetid = @ currentuserid;

As you can see, authorization includes two important parts: the required certificate and security policy.

The first part of authorization is the required certificate. The following interface clearly shows the relationship between authorization and certificate:

The second part of authorization includes the function security policy and data security policy. The function security policy refers to the Access Authorization to the "function" resource, data security policies are used to authorize access to the data resource.

Indicates the function security policy definition in this authorization.

The data security policy depends on the specific business entity design. For example, the Order entity supports the customer field, so it can support the customer-level security authorization method, and the employee file does not have the customer field, it is impossible to support the customer-level security authorization method.

Generally, common data authorization methods include:

L The entity contains the owner attribute. The "owner" is an employee archive (or mapped to an employee archive), indicating that the holder of the record has no direct relationship with the recorded data, refer to Microsoft CRM.

L The entity contains employee attributes, which are similar to the owner but related to actual data. For example, the payroll permission is related to the wage owner of the payroll, which is mostly seen in the HR system and office automation system;

L The entity contains the customer attributes, which are authorized by the customer's region or level. This entity can be found in CRM or invoicing systems;

L The entity contains the department attributes, which are similar to the owner concept. The difference is that an affiliated employee and a affiliated department. For example, a delivery order contains the shipping warehouse attributes, A production plan contains a workshop attribute. More common in ERP systems.

The following interface defines data authorization according to the jurisdiction.

One authorization can only be one authorization method. Generally, we have decided when creating authorization.

Tip: the best data authorization method is dynamic data authorization, rather than specific data authorization. For example, the operator has direct jurisdiction. This authorization allows the Administrator not to set authorization for each manager separately, greatly reduce the management workload.

Many authorizations can be added to a system. Many software errors define authorization to roles, which greatly limits the flexibility of authorization definitions. For this question, you can refer to the Windows design. Have you noticed it? Windows role (User Group) editing interface does not have any permission settings.

. NET provides an interface to describe a security policy: system. Security. ipermission, which defines the following behaviors of a security policy:

Method

Explanation

Copy

Create and return the same copy of the current permission

Demand

Assertion: if the security requirements are not met, securityexception will be thrown at runtime.

Intersect

Create and return a permission, which is the intersection of the current permission and the specified permission

Issubsetof

Determines whether the current permission is a subset of the specified permission.

Union

Create a permission, which is the union of the current permission and the specified permission

This interface is also derived from system. Security. isecurityencodable, which defines a method for converting the state of the permission object and the XML element representation.

It is not that easy to implement this interface, but unfortunately, we need to define different implementations based on different business needs. net self-implemented class, you will know that this is "workload.

Note: Forgive me for being blunt. I did not indicate an authorized object in. net, but only its Sub-division: security policy. So I implemented this class myself.

Security check

After doing so much, it is for the last thing: security check.

First, when logging on, we need to record all available certificates on the subject.

When a method is called, a security check must be performed inside the method. The simple security check is assertion. The result is only: pass or fail. If it fails, an exception is thrown.

This check is generally applicable:

L check the document creation permission;

L check the operations on a specific document;

The other is data filtering, which has no predefined data. For example, browsing is a typical data filtering method for security checks.

The two methods are as follows:

L filter out all available authorizations, that is, the current user has the certificate required in the authorization, that is, the available authorization;

L filter again to keep the functions and actions of the current operation within the authorization scope;

L if any security policy indicates that it is the "largest set", it is considered as the highest permission;

L The security policies in the remaining authorization are merged according to the authorization method. Each authorization method forms a union;

L if no valid authorization exists, no permission is granted;

The last steps of the two security checks are different. If they are assertion methods, then:

L pass the current resource object into the security policy and check whether the resource object is within the Security Policy range. For example, the following describes the data resource attribute of an order during reading:

Attribute name

Value

DataID

00002

Owner

User001

Target customer Region

001

If the defined security policy is described as: processing the region under your jurisdiction, and the current user is under 001, then pass.

For data filtering

L concatenates all the Union into the executed SQL statement in the OR mode.

Rejection

All the above authorization definitions are forward authorization, and there is also a type of reverse authorization, that is, the denial function. For details about this function, refer to the NTFS system permission design.

Reverse authorization is to "kick" the content of the forward authorization, which is very useful in handling some special permissions. For example, the original authorized finance can compile all the payroll of the company, but now the manager is not responsible for this, so you need to make a positive authorization: the financial role can edit the company's payroll, and then make a reverse authorization to join that manager.

Shareto Functions

As we can see, authorization is defined in an independent document, but this method has encountered challenges when encountering business requirements with extremely poor regularity.

Due to the lack of regularity, we have to create a large number of independent authorizations. Independent authorization is the authorization that is made to a single role or even a user. As the number of authorizations increases, the program becomes very slow, authorization is sensitive data, so it can only be produced by the Administrator, which will inevitably increase the workload of system management.

In addition, some systems have designed the shareto function, which features authorization being attached to a specific entry, for example, a shareto Database Design for accounts.

The first shareto record indicates that the record number in the account is 069111... Allows user1.

In fact, this design is based on unified authorization, and a separate authorization model is created for this file. It is obvious that too many independent authorizations are concentrated on several files, sacrifice yourself to free everyone.

When using the shareto function, you must keep in mind the following points:

L The shareto function brings flexibility, but it also brings about slow operation and disordered management;

L shareto must rely on a certain record, so there is no create action;

L to design the shareto function, you must consider shareto again. Generally, we will add the "re-Authorization" action to shareto.

Summary

Remember that there is no panacea in the world, and any permission design model must balance performance, flexibility, and availability.

When you choose to use the security model, the common mistake is to "exaggerate" the customer's needs and data volume, so as to always try to give the customer a large and comprehensive permission system, which is actually appropriate.