ERPNext Foundation ERPNext Cloud Chat Blog Discuss Frappé* Donate

Proposal to refactor user permission based on SAP's authorization object concept


#1

V11 refactored the user permission system, simplified the user permission doctype, which makes maintaining record level authorization control more easy. so far so good.

but the current new user permission system can not handle the below basic/typical use case elegantly

  • use case 1: grant buyer A to create/change purchase order in his own company, also allows him/her to display purchase orders from other company code
    Different action(create/change/display) on different restricted records

  • use case 2: grant sales clerk A to create/change sales order of type(non link field) Maintenance, also allows him/her to display all sales orders in the company assigned
    Restrict at record level by non-link field or any selected field(custom field)

  • use case 3: only allow project member and the project manager to change tasks assigned to this project member, while other project member can not change the task.
    Restrict by the logon user’s attribute

  • use case 4: grant stock keeper to allow him/her to post stock entries to a set of locations these locations does not necessarily to be existed in the system when creating/assigning the role to the user
    Restrict record by field value range or wildcard

  • use case 5: Grant key user A maintain Item master, exclude the sensitive accounting related fields such as price, G/L etc, at the same time allow this user to display the accounting fields
    Different actions(create/change/display) on field level

Apply user permission at role level eliminated a lot of confusion, but the If Owner check box(option) still caused a lot of confusion.

SAP’s authorization(permission) control system

  1. Define authorization object for the business object(transaction, in ERPNext the doctype),
    1.1 multi authorization objects can be defined per business object, each authorization object control the authorization by selected fields
    1.2 typically, each authorization object has at least 2 fields, one is activity(create/change/display) and the other is to be checked field from business object(doc), normally type or org field, in each SAP transaction, e.g for purchase order, these 2 fields are PO Type and purchase organization.

  2. Create role, maintain authorization detail: assign allowed values for all authorizations of the selected authorization objects
    2.1 allowed values can be single value , value range(from and to, in SQL term between), or wildcard( in SQL like)
    2.2 one authorization object can be added into one role multi times, or can be added into different roles, each authorization object with its assigned authorized values is called one authorization with assigned authorization ID

  3. Assign roles to user
    3.1 multi roles can be assigned with validity period (valid from and valid to)
    3.2 user’s final authorization is all the assigned authorizations of the roles.
    3.3 user’s authorization check is based on cached user’s authorization records, which is auto updated after role assignment or role authorization change. thus it is not needed to log out and login again to refresh the newly changed role assignment or role authorization change

  4. authority-check: when transaction start, clicking the create/change/save button in the form view, click the menu etc
    4.1 checking logic is very simple and straight forward: get the current business object(doctype)'s assigned authorization object, check the requested value against available value for each authorization field, for requested value, except the special authorization field action which is derived from the button clicked or the operation launched, the value of other fields is the field content of the current business object(doc), the available(assigned) value for the user is the authorizations derived via all assigned roles, in other word, the requested value is single value, for the available value of the authorization field, there maybe no records, or with one or more matched records, or unmatched records. the available value can be single value, a range(from and to), or wildcard(match all), all authorization field checked OK, then the authorization object check is OK, only all authorization object check OK, the final check is OK, otherwise fail.
    4.2 the user’s last authorization check failure will be logged into the table which can be retrieved by the admin for detailed analysis
    4.3 it is also possible to activate per user and transaction authority check trace which will log all authority check in detail for deeper diagnose

Here it is my ERPNext version authorization object based new permission system, thoroughly tested on my local server, to be posted as a new PR, ERPNext is a great system, it deserves a more advanced and powerful authorization system as its foundation, any idea? feedback?

image

image

image

image

any further use cases to be simulated/ covered in this new implementation? welcome feedback and comments, suggestions, as always, if there is enough interests and support on this topic, I can start the pull request then.

Here the related use cases


Ability to see all customers where their name is in the Sales person table (currently there is no way to have restrictions based on child tables)
Ability to see all transactions of customers like SO, DN and Sales Invoices (now I don’t know if this would be possible even if the child tables permissions is also added)
Ability to make new Sales Orders only for those customers who are under their command (where the Sales Person name is linked to the customer).


#2

Anyone can give me some feedback on this?


#3

Dear szufisher,

I think benchmark the SAP authorization concept is a great idea. I’m the SAP basis admin and been familiar with the SAP authorization very well.

I’m not the developer, so I can’t give much input on the coding. But anything on sap authorization may give some help.


Make Leave Approver see only leave requests that are assigned to him
[Proposal] Foundation, Way Forward for 2018-19
#4

Actually I am the SAP authorization manager 5+ years, and also responsible for external and internal audit on system security and authorization control, I know very deep the SAP’s authorization control mechanism, based on the study so far, I think SAP’s authorization control is more straight forward( easy understanding) and advanced than any other. so I am eager to promote it to be implemented in ERPNext.


#5

Your knowledge contribution is great. Do you have documents on SAP’s authorization object? Then we can study and break down to small parts which then can make continous improvements for Frappe


#6

We can extend the current User Permission System to extend to these use cases, from I see:

  1. Extend user permission to any field type
  2. Introduce wild cards
  3. Add negative permissions

#7

Hi. We can work together on this as I also have some expertise here.


#8

Relevant screen shot from SAP

  1. User role: PFCG
    image
    Role
    image
    Role Authorization
    image
    Role Authorization Detail

  2. User master: role assignment with validity period: SU01
    image

  3. User authorization in User Buffer back end table
    image

  4. authorization object assigned to transaction

  5. authorization object definition
    image

  6. authorization check failure message and last check failure log: SU53
    image


#9

@Chude_Osiegbu:
thanks for giving a helping hand.

Here my proof of concept
“”"refactor user permission system
core concept:requested authorizations(the doc) against assigned authorizations by multi auth objs
How it works

  1. define authorization objects, i.e choose authorization fields
    1.1 add the special action field which is mapped to the user operation on the doc, such as New,change, delete, cancel etc
    1.2 optionally add other to be auth checked fields, multi fields can be assigned per auth object
    1.3 multi fields can be combined using | (OR) operator,
    e.g owner|approver allows the user to check leave applications which he is owner or approver
    1.4 assign authorizaiton objects to doctype
    1.4.1 multi auth objects can be assigned
    1.4.2 whether mandatory check can be defined per auth obj and doctype
    1.5 optionally auth objects can be assigned to doctype field, only one auth object can be assigned to one doctype field

  2. define roles and main authorizations
    2.1 select auth object, select auth field, assign authorized values to the authorization field
    2.2 authorized value rules
    2.2.1 wild card *, which means full authorization on this field
    2.2.2 single fixed value
    2.2.3 single partial fixed value with wildcard
    2.2.4 single variable value link to user master field, using $user. as prefix
    2.2.5 single fixed value for field has descendants, which means it includes all its descendants
    2.2.6 fixed value with range, value from and value to
    2.3 authorization rule: same key assigned to records of authorization fields of the same auth object
    2.3.1 one auth object can be added to the same role multi times

  3. assign roles to user
    3.1 multi roles can be assigned to same user

  4. System do authorization check at following point
    4.1 bypass the auth check for globally accessed doctype, the checking is not necessary
    4.2 auth check when user trigger the operation(action) on the target document
    4.2.1 implicit check the relevant doc field by the assigned authorization object
    4.3 when user retrieves multi documents for listing view, report view, link field search, trigger the implicit read action,
    system translate user’s authorizations into matching/filering condition,add it to the SQL where clause in db_query
    4.3.1 implicit apply the matching condition of the linked doc type

use cases:

  1. user can display/edit leave applications which he/her is the owner or approver
    Solution: define owner|approver as auth field, maintain $user.name as authorization value to the role
    use_case1={‘auth_objs_fields’:{‘lap’:
    [[‘lap_owner’,‘act’ ],
    [‘lap_owner’,‘owner|leave_approver’]]},
    ‘authorizations’:[
    [16,‘lap_owner’,‘act’, ‘*’, ‘’],
    [16,‘lap_owner’,‘owner|leave_approver’,’$user.name’,’’]],
    ‘docs’:[
    {‘doctype’:‘lap’, ‘act’:‘03’,‘user’:‘admin’,‘owner’:‘admin’,‘leave_approver’:‘fisher’},
    {‘doctype’:‘lap’, ‘act’:‘03’,‘user’:‘admin’,‘owner’:‘fisher’,‘leave_approver’:‘admin’}]
    }

  2. sales user can display/edit only customers which he is the assigned sales person
    Solution: define auth obj for customer and add sales person as auth field, maintain $user.name as authorization value to the role

  3. sales user can display/change only sales transactions for customer which he is the assigned sales person
    Solution: define auth obj for customer and add sales person as auth field, maintain $user.name as authorization value to the role
    also assign the same auth object for customer to the customer field in relevant sales transaciton doctypes

  4. stock user can create/change/display stock entries of Move-In type, can display stock entries of all types
    solution: define type as auth field, create authorizations for the same auth obj,
    for 1st authorization, assign create/change to action field, Move-In to type field
    for 2nd authorization, assign display to action field, * to type field
    “”"
    testing result

For more details you can check the updated source code here


User Permission rather than grant
#10

I would also really like to see the current permission system extended… and soon hopefully

Kind regards,


#11

Hi,

I’m tempted also to adopt the SAP model too but I think that in a doctype-centric system it might not be an intuitive design.

My proposal:

Today in ERPNext, the roles are controlled like in the screenshot below.

What if we added the ability to include constraints and custom activities as shown in the screenshot below? I think we would have effectively achieved everything that SAP’s authorization model achieves while still working in a familiar framework.

Roles could then be combined in Role Profiles (or Composite Roles). The only difference with current implementation of Role profiles would be that there would be a one-to-many relationships between Users and Role Profiles and these assignments would have validity dates

New concepts added to current authorization framework are highlighted in blue. Let me know what you think.

Regards,
Chude


[V11] User Permissions Refactor
#12

@Chude_Osiegbu,
Thanks for your feedback and new idea, to be frank, I still in favor my current design so far, in my opinion, It is more simple and straight forward, involves less concept, and most importantly, IT is alrady a proven elegant solution in complicated ERP system(SAP)。

Instead I would like somebody helping me to summarize all relevant use cases, and preparing the relevant test cases, I myself can focus on refining the solution and coding。


#13

Ok. Will take some time to review it again. I think my main hangup with it is the introduction of a new Authorization Object concept. I think the doctypes already work as authorization objects.


#14

How about performance impact review of this?


#15

I have almost done the development and internally tested, anyone can join me to start a new PR?


#16

That comes later no? http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast


#17

for performance, following 3 level caching implemented

  1. user authorizations, all the authorizations assigned to user via role
  2. doctype specific authorizations, calculated based on user authorization
  3. auth check result per doc relevant field as key

here the most updated test script

and code


#18

pull request