on 03-27-2020 5:29 PM
I want to add an authorization check prior execution of function module. I need to ensure that the user has a specific role to be able to execute the function module.
Currently, I have two possible approaches:
AUTHORITY-CHECK OBJECT 'S_TCODE'
ID 'TCD' FIELD 'TCODE'.
IF sy-subrc <> 0.
WRITE: 'Access denied'.
EXIT.
ENDIF.
Both of these approaches will do the job, but it looks like more work around rather then a best practice.
My question:
Is there any common approach to check if a user is allowed to execute specific function module?
Dear Mike
This may be helpful to you S_RFC object, assigning ACTVT to 16 will allows you to execute the RFC.
Check this link - if it gives you details of what you are looking for.
Regards,
Venkat
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Venkateswaran (Venkat) Krishnamurthy,
I already considered this approach, but I also read to not rely on S_RFC:
Don't rely on S_RFC authorizations. They only determine, *if* a function module can be invoked remotely. They are by no means related to the specific business logic of your custom code. You don't want users with S_RFC * authorizations to be able to issue purchase orders or to raise someone's salary. Auditors don't like this either…
I've already tried the following approach:
AUTHORITY-CHECK OBJECT 'S_RFC'
ID 'RFC_NAME' FIELD 'UN_EXISTIG_FUNG_GR'
ID 'RFC_TYPE' FIELD 'FUGR'
ID 'ACTVT' FIELD '16'.
IF sy-subrc <> 0.
WRITE: 'Access denied'.
EXIT.
ENDIF.
And I always get Authorization check successful, although the function group UN_EXISTIG_FUNG_GR does not exist.
Do you have any idea why?
The values of authority-check are only connected to authorisation objects in roles. They are not connected to the business or technical object to which they're associated.
S_TCODE does not check that the transaction code exists. It checks if you have a role which authorises the use of the transaction.
Thanks for the link, at the end I applied the S_RFC with check of FUGR:
AUTHORITY-CHECK OBJECT 'S_RFC'
ID 'RFC_NAME' FIELD '/COMP/DOMAIN/PROJECT_A_FUGR'
ID 'RFC_TYPE' FIELD 'FUGR'
ID 'ACTVT' FIELD '16'.
IF sy-subrc <> 0.
The problem was that I checked a permission for the specific function group, e.g. /COMP/DOMAIN/PROJECT_A_FUGR, while a test user has more general permissions, e.g. /COMP/DOMAIN/*. That's why my initial check didn't work out.
Be careful, if you use S_RFC, any external program can execute your function module. Do you really want to make your function group visible to the outside world, and so possibly subject to attacks? Make sure that the security team agrees.
@Venkateswaran (Venkat) Krishnamurthy, one more question.
In the post "Ten golden rules for ABAP authorization checks", the author strongly recommends to use SAP APIs for authorization checks, e.g. AUTHORITY_CHECK_RFC instead of plain ABAP AUTHORITY-CHECK OBJECT 'S_RFC'.
Is it really much more reliable/best practice to use such APIs?
> Be careful, if you use S_RFC, any external program can execute your function module. Do you really want to make your function group visible to the outside world, and so possibly subject to attacks? Make sure that the security team agrees.
Should I add an additional AUTHORITY-CHECK with an another authorization object to ensure that only those users, who have a role for the specific function group will be able to execute these FMs?
These FMs are called via JCo, therefore they must be exposed to RFC interface. According to your "any external program can execute your function module", any program can call my FMs via RFC, but if that's the case, what is the added value of S_RFC/FUGR check? I assumed, that the purpose of S_RFC/FUGR is to limit an execution permission only to those users/jobs, who have in their profile a role with an appropriate function group. Am I wrong?
When your function module is called by RFC, SAP will first automatically do an authorization check on S_RFC (*) for the function module name, and if there's no corresponding authorization it will do a check with the name of its function group. So you don't need to do it in your program.
So, you're right.
(*) Except if the profile parameter auth/rfc_authority_check is set to 0 but it's very rare and not recommended. See SAP documentation if you need more information: SAP Library: RFC Authorizations, Note 931252 - Security Note: Authority Check for Function Group SRFC, https://support.sap.com/en/security-whitepapers.html (concerning RFC)
I'd go for AUTHORITY-CHECK. That's the standard way to check if a user has required authorization.
Notice that the authorization can result from different roles. Your taks as a developer is not to check for role but for authorizations. Roles can be maintained and named in many different ways depending on the company security guidelines.
Best regards
Dominik Tylczynski
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That's exactly what I think, the question is which authorization object should I use? S_TCODE for transactions but which object stands for function group?
mikeb.
Definitely AUTHORITY-CHECK is the way to go. The sufficient authorization object should be determined based on the business process the function module performs. For standard processes standard authorization object should be sufficient, you can check SU21 for the complete list. Each of them is well-documented. For a custom process you can create your own object.
Mike B. There are no authorization objects for function groups, because authorization objects have usually functional meanings. Note that S_RFC authorization object is only for RFC calls, don't use it if you don't call your function module via RFC. Prefer creating a custom authorization object. Give it a functional meaning, not a technical one. If you prefer a generic authorization object which could be reused for other features, do like authorization object S_BTCH_ADM, where the unique field has several possible values defined in domain.
sandra.rossi, thanks for detailed explanation. Actually, my FM is a part of a custom API, which is called by RFC and I just want to protect this API from unauthorized calls. I already tried to use S_RFC for the API function group. To test it, I specified an un-existing function group:
AUTHORITY-CHECK OBJECT 'S_RFC'
ID 'RFC_NAME' FIELD 'UN_EXISTIG_FUNG_GR'
ID 'RFC_TYPE' FIELD 'FUGR'
ID 'ACTVT' FIELD '16'.
IF sy-subrc <> 0.
WRITE: 'Access denied'.
EXIT.
ENDIF.
And I expect to get a rejection since I try to check an authorization for un-existing function group, but surprisingly I get Authorization check successful, although the function group UN_EXISTIG_FUNG_GR does not exist. Do you have any idea, why do I get a successful outcome?
Thanks.
RFC_NAME *
RFC_TYPE *
ACTVT *
Use SU53/SU56 to see the last authorizations used by the authorization check.
sandra.rossi, I already checked for the RFC user the SU53 and there I get only "The last authorization check was successful" but no further details.
What I really can't understand, if the authority-check doesn't validate the values, why there are these parameter at all, what is reason to provide these parameters if they don't really matter?
Hi mikeb.
You should use a authorization object(s) that closely match(es) the business meaning of your function module. I'd recommend to use here SAP provided authorization object(s) if possible. E.g. if your function deals with material documents, use the authorization objects related to MIGO transaction.
If your function is about some brand new business functionality and you can't find any relevant SAP provided authorization object, just create a new one that suits your need.
BR, HTH
Dominik Tylczynski
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Please check using SUIM tcode if user is having roles or tcode access as per the requiremnt.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
80 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.