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 Likes
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
We can extend the current User Permission System to extend to these use cases, from I see:
- Extend user permission to any field type
- Introduce wild cards
- Add negative permissions
4 Likes
Hi. We can work together on this as I also have some expertise here.
Relevant screen shot from SAP
-
User role: PFCG
Role
Role Authorization
Role Authorization Detail -
User master: role assignment with validity period: SU01
-
User authorization in User Buffer back end table
-
authorization object assigned to transaction
-
authorization object definition
-
authorization check failure message and last check failure log: SU53
1 Like
@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
-
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 -
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 -
assign roles to user
3.1 multi roles can be assigned to same user -
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:
-
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’}]
} -
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 -
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 -
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
2 Likes
I would also really like to see the current permission system extended… and soon hopefully
Kind regards,
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
1 Like
@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 already 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。
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.
How about performance impact review of this?
I have almost done the development and internally tested, anyone can join me to start a new PR?
1 Like
for performance, following 3 level caching implemented
- user authorizations, all the authorizations assigned to user via role
- doctype specific authorizations, calculated based on user authorization
- auth check result per doc relevant field as key
here the most updated test script
and code
1 Like
Check the PR and seeing the inactive. Can we make a volunteer team to make this feature come true?
actually I do need help to proceed , Also considering to build a separate App.
1 Like
I do think that a separate app will be the fastest way for everyone to benefit from the proposed changes and gain insights for improvement
What kind of your need? It’s great if you can list out and we can find a solution on that.
From my view, it takes alot of modification in Frappe permission structure for this. Seperate apps will need a lot of hooks.
1 Like
currently, I need help on the following
- fix the issue to pass the travis testing
- find a better way / more efficient way to control/disable the button/menu item which the user is not authorized per new authorization rule on doctype, the existing permission system built a lot of long list for user
- real business cases testing
- good documentation