Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

Structural Authorization Vs. General Authorization

Hi Experts,

Structural Authorization has been implemented in our current project and it seems like it has affected the system performance. We're currently in TEST phase and most of the Test IDs are granted with top most structural profile which might be one of the reason. Apart from that, troubleshooting gets complicated as SU53 and trace does not give the full picture.

Thus, I'm considering to revert to General Authorization and identifying the pros and cons before propose the next course actions to resolve the performance issue. Restriction by Object ID will no longer effective and we need to look for alternatives. Hope you could share relevant experience and shed some lights in this matter.

Million thanks in advance.

Former Member
Former Member replied

> FYI, we do have requirement to restrict certain Q for ESS/MSS users and manage to restrict it by defining QK as the root with supplement of custom evaluation path (QK - QK -Q). Instead of register all ESS user ID in OOSB, I plan to replace SAP* profile assignment (originally assigned to profile ALL) to the custom profile (e.g. ZESS/MSS). Is this a good plan? Any suggestion is much appreciated.

Approximately how many objects does currently your ZESS profile currently return? Are you excluding the restricted QK branch using exclusion tick? Large ZESS profile may be the cause for your performance issues.

I remember one project where I was considering replacing OOSB SAP* | ALL entry with something else and I ended up leaving it as it is. I can't remember all reasoning for abandoning that idea but what I remember is that we would've needed to assign ALL to many users in OOSB. Luckily that lead to discussion of maintenance of structural profile assignements. We debated if HR should assign structural profile to position (infotype 1017) or if it should be done by security team. Or should we directly maintain OOSB.

The final solution came through BAdI in our case. We were already using context solution. So users had HR roles with P_ORGINCON object where infotype access was linked to structural profile using field PROFL. BAdI HRBAS00_GET_PROFL comes with example code which reads users all P_ORGINCON object fields PROFL and that is users structural profile assignment regardless of OOSB entries. You don't have to worry about maintaining OOSB when using this BAdI --> lot less maintenance! I have used only the sample code (with little improvements to clean up double entries) but in your case you could come up with another idea to assign structural profiles: you don't need to activate context solution and use the sample code to use it. Some ideas to use the BAdI might be to read if user is in manager position and then give ZMSS profile. Based on you user setup you could maybe check user group or reference user from user data to assign ZESS.

So in your case I would try to minimize the ZESS profile by using exclusion if not done already and I would also consider implementing the BAdI to reduce the OOSB maintenance mayhem.

's

0 View this answer in context
Not what you were looking for? View more on this topic or Ask a question