Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Structural Authorization Vs. General Authorization

Former Member
0 Kudos

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.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

If it is possible to fulfil the business requirements without structural authorisations I would do it. The evil truth normally is that you end up needing them some stage anyway; maybe not when project goes live but in the future.

If structural authorisations are needed and organisation is large it is essential to restrict the profile size to absolut minimum to avoid the performance issues. Top level managers don't need structural profile at all if that returns all objects (ALL profile for users who don't have restrictions). Using exclusion in ECC6 can also help to reduce the size of structural profile if all except one branch should be allowed.

I also do only the essential with the structurals. If requirement is to limit access to org. structure I only limit objects O, S, P and give full access to other object types without using evaluation paths: start objects and evaluation paths will just unneccessarily explode the size of the profile if there is no requirement to limit qualifications catalog or business event menu. Also using the period parameter and correct evaluation path can reduce the size if historical data is not required to be displayed.

If above measures leave you only handful of top managers with large profile I would buffer their access. I try make sure that I will never buffer HR professionals; only high-level managers.

So if your requirement allows you to implement the solution without structurals I would think that option but I wouldn't be surprised if the requirements change when HR gets used to SAP and starts redefine the requirements or want more functionality.

12 REPLIES 12

Former Member
0 Kudos

Hi

If many users has the global strucutral profile (contains all objects access) and if they logged into the system more frequently then system performance drastically go down.

Hence best practices is never assign global profile not to many userids.

Also try to build Explicit object level strucutural profiles.

Former Member
0 Kudos

Are you indexing with RHBAUS00?

Former Member
0 Kudos

If it is possible to fulfil the business requirements without structural authorisations I would do it. The evil truth normally is that you end up needing them some stage anyway; maybe not when project goes live but in the future.

If structural authorisations are needed and organisation is large it is essential to restrict the profile size to absolut minimum to avoid the performance issues. Top level managers don't need structural profile at all if that returns all objects (ALL profile for users who don't have restrictions). Using exclusion in ECC6 can also help to reduce the size of structural profile if all except one branch should be allowed.

I also do only the essential with the structurals. If requirement is to limit access to org. structure I only limit objects O, S, P and give full access to other object types without using evaluation paths: start objects and evaluation paths will just unneccessarily explode the size of the profile if there is no requirement to limit qualifications catalog or business event menu. Also using the period parameter and correct evaluation path can reduce the size if historical data is not required to be displayed.

If above measures leave you only handful of top managers with large profile I would buffer their access. I try make sure that I will never buffer HR professionals; only high-level managers.

So if your requirement allows you to implement the solution without structurals I would think that option but I wouldn't be surprised if the requirements change when HR gets used to SAP and starts redefine the requirements or want more functionality.

0 Kudos

@ Hari,

The 'big profiles' only assigned in QA to avoid unnecessary restriction to date during SIT/UAT. I'm aware of this consequences and plan to grant it to only to a few users in production clients.

@ Alex,

Yes, indexing programs are executed by sequence: RHBAUS02 > RHBAUS01 > RHBAUS00. However, other users (other than the one who creates the record) will only be able to access the data after the indexing program executed.

@ SaQ,

You really read my mind and thanks so much for your advice You gave me hope to proceed with the Structural Profiles. I'm currently working on it based on your suggestion.

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.

Best Regards

0 Kudos

Hi,

I need to build the security roles (actual technical roles) with HRCON object for date driven security.

Please help me that how could i learn and what should be the approach.

i.e. What is the requirement for learing to build the security roles (actual technical roles) with HRCON objectfor date driven security.

0 Kudos

Hi,

N.B:

Context switch INCON defined in SAP tcode OOAC will ensure if contect swith authorisation has been enabled.

Context-authorization main switch that controls whether the authorization object P_ORGINCON should be used in the authorization check.

In the standard system this switch is set to 0.If you want to activate the authorization check for P_ORGINCON set the switch to 1.

So the point that I am addressing here is once the context switch is enabled there is no need to add userId i.e PD profile assignment using OOSB. This would be addressed based on the jobs set for indexing programs are executed by sequence: RHBAUS02 > RHBAUS01 > RHBAUS00.

So effectively the cusom auth profile (e.g. ZESS/MSS). passed in P_ORGINCON will pick up HR objects based on the evaluation path and the profile defination.

Hope this helps.

Warm Regards,

Kaushik

0 Kudos

This message was moderated.

0 Kudos

> 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 Kudos

@ Kaushik/Alex,

I've executed the indexing programs by sequence (RHBAUS02 > RHBAUS01 >RHBAUS00) but due to the profile size, the system performance are still affected.

@ SaQ,

The ESS/MSS profile size are approximately 6K - yeah, it huge and required to be granted to all users. I'm not very clear on your recommendation to use exclusion tick in this case. If you're referring to exclusion tick in OOSB, does it mean that I just need to specify the restricted objects in the profiles via OOSP and use the exclusion tick in OOSB? If yes, I need to find the workaround to specify the evaluation path for Object type O for ESS/MSS respectively.

I'm currently working on BAdI as advised (brilliant idea) and appreciate if you could confirm/feedback on my understanding as mentioned above - million thanks

Best Regards

0 Kudos

> @ SaQ,

> The ESS/MSS profile size are approximately 6K - yeah, it huge and required to be granted to all users. I'm not very clear on your recommendation to use exclusion tick in this case. If you're referring to exclusion tick in OOSB, does it mean that I just need to specify the restricted objects in the profiles via OOSP and use the exclusion tick in OOSB? If yes, I need to find the workaround to specify the evaluation path for Object type O for ESS/MSS respectively.

You are correct with exclusion tick in OOSB. You need to create a structural profile which returns the "forbidden objects" and then assign that to the user using exclusion. Using exclusion means that you end up needing to assign two structural profiles normally since you still need to give access. For example if manager needs to see only his/her own team and should be able to see all qualifications except the group (QK) 50001000 it could be done something like this:

ZHR_MSS|10|01|O | |X|O-S-P|12| | |D|RH_GET_MANAGER_ASSIGNMENT

ZHR_MSS|15|01|QK| |X| | | | | | |

ZHR_MSS|20|01|Q | |X| | | | | | |

... add all other object id's required...

ZHR_QK_EXCL|10|01|QK|50001000|X|QUALCATA

Then you assign both structural profiles to managers but ZHR_QK_EXCL with exclusion tick:

TESTUSER|ZHR_MSS |01.01.2000|31.12.9999| |

TESTUSER|ZHR_QK_EXCL|01.01.2000|31.12.9999|X|

That way you limit organisational structure access to own team and give full access to other objects (in my example only QK and Q listed) using ZHR_MSS structural profile. In addition to that you have ZHR_QK_EXCL profile which returns restricted branch from Qualification Catalogue and when you use exclusion tick it will deny the access to that branch of the catalogue. I was first bit doubtful with this but my testing showed that exclusion overrides the full access given in ZHR_MSS.

This way you can reduce the size of your structural profile: normally list of forbidden objects is much shorter than the allowed objects.

's

0 Kudos

Hi SaQ,

Million thanks for the clarification - never tried this approach before but definitely will.

Best Regards

Former Member
0 Kudos

Does the indexing (ignoring for now the constraints) resolve the performance issues?