Usage of SAP* user in OOSB

[Former Member]

Hi Gurus,

I'll be implementing Structural Authorization for my current project.

I received requirement to restrict ESS and MSS display access specific to Qualification/Qualification Group (by object ID).

General Authorization cannot specify the restriction by Object ID, thus I'm considering to restrict it using authorization profiles.

Restriction for MSS view has successfully tested since MSS users will be assigned with MSS Authorization Profile in OOSB. The issue that I'm facing at the moment is how to apply the same restriction to ESS without assigning ESS IDs in OOSB - approximately 40K ESS users; will it impact the system performance anyway?

If I were to use similar authorization profile defined in OOSP as per MSS, the only way to make it effective for all ESS users without assigning PD profile to each ESS ID in OOSB is by using SAP* - this is based on my understanding referring to notes that I found as attached below. I plan to customize authorization profile specific for ESS users and assign it to SAP* - still in test stage.

Here are the statement that I'm referring to from the notes mentioned above:

" What happens if the table doesnu2019t contain entries for a specific user? In that case, the authorization check uses the

entry of the SAP* user. So, the profile stored for this user is applicable if an entry has been left out."

Please correct me if I'm wrong and appreciate your advice on this matter. Million thanks

[Former Member]

Hi,

In this scenerio you can activate Context based structural authorizations where the Auth profiles are not assigned to User Ids directly but assigned via Custom roles using authorization objects P_ORGINCON (HR: Master data with Context) and P_ORGXXCON (HR: Master data- Extended Check with Context).

Authorization objects P_ORGINCON and P_ORGXXCON consists of the same fields as to P_ORGIN and P_ORGXX respectively and has been expanded to include the PROFL field. The PROFL field is used to determine which structural profile the user is authorized to access (as per table T77UA - User Authorizations = Assignment of Profile to User).

Additionally,I f you have requirements that cannot be mapped using the P_ORGINCON and P_ORGXXCON authorization objects (for example, because you want to build your authorization checks on additional fields of the Organizational Assignment infotype 0001 that are customer-specific) and if you want to implement the context solution, you can include an authorization object- P_NNNNNCON (HR Master Data: Customer-Specific Authorization Object with Context) in the authorization checks yourself.

Please note following switches have to be activated for Context based Structural authorization in table T77S0 (tcode- OOAC)

AUTSW INCON (HR Master Data (Context))- Authorization Main Switch that controls whether the P_ORGINCON authorization object should be used in the authorization check.

AUTSW XXCON (HR Master Data: Extended Check (Context))- Authorization Main Switch that controls whether the P_ORGXXCON authorization object should be used in the authorization check.

AUTSW NNCON (Customer Authorization Object (Context))- Authorization Main Switch that controls whether the P_NNNNNCON customer-specific authorization object should be used in the authorization check.

Hope this is helpful!

Thanks

Sandipan

[Former Member]

Hi,

When you add user to OOSB you start actually delimiting authorisations. If user id is not in OOSB SAP* access will be read i.e. user has access to all objects from structural point of view (profile ALL). But authorisation check is always done in combination with general authorisations so ESS users will not be able to access other employees information as long as they don't have too open P_ORGIN(CON) authorisations. So typically ESS users does not require structural profile.

Regards,

Saku

[Former Member]

Dear Saku,

While I agree with you on the fact that ESS users need not have any restriction via Auth profiles (we can also assign blank or dummy Auth profiles via OOSB which means access to the root org unit in the organization structure) ONLY if P_ORGIN(CON) is maintained very carefully.

However, this is very risky especially when the ESS access is combined with some other access ( to run PA30, etc) for users. If such an approach is implemented one has to be very careful while putting PA restrictions in object P_ORGIN(CON).

I would think putting proper restrictions via Auth profiles for ESS users and using context based structural auth (to address the concern mentioned in the initial post) would be a much safer bet.

Cheers!

Sandipan

[Former Member]

Hi Sandipan,

ESS users access to own data is controlled with P_PERNR. If ESS user is pure ESS user they don't need access to PA30. However, I have seen implementations where PA30 web transaction is assigned to ESS role in portal. It looks awful but even then if IT0105-0001 is maintained access is limited only to own data due to P_PERNR.

Of course if ESS user needs to access other users data (is this ESS user anymore?) also P_ORGIN(CON) is required. Ofcourse in this case it is important to consider structurals carefully. But my point was that plain ESS user who accesses SAP only through portal does not need structural authorisations. MSS users and HR admins are a different story.

In the original post there was already requirement to implement structurals to give access to certain QK/Q objects only so in that case of course structurals are needed. But customer requirements are always the driving force either to go ahead with structurals for ESS user or not - I have been able to avoid structurals for ESS user about two times out of three.

I tried to only answer to the question what is use of SAP* user in OOSB but ended up going side track and might have confused the original poster.. Sorry about that..

Cheerios,

Saku

[Former Member]

>

I plan to customize authorization profile specific for ESS users and assign it to SAP* - still in test stage. 
> 
> Here are the statement that I'm referring to from the notes mentioned above: 
> 
>               " What happens if the table doesnu2019t contain entries for a specific user? In that case, the authorization check uses the 
>                 entry of the SAP* user. So, the profile stored for this user is applicable if an entry has been left out." 
> 
> Please correct me if I'm wrong and appreciate your advice on this matter. Million thanks 

If you assign customized ESS profile to SAP* user make sure that all your system/communications etc users have profile maintained. If they don't have entry in OOSB they will get the ESS profile (since it is in SAP*) and it might not be sufficient. And when ever new system/comms etc user is created they should be added to OOSB.

[Former Member]

Hi All,

Million thanks for all your feedbacks which help me a lot in considering structural authorization for ESS users - which I'm not comfortable myself. However, user's requirement is a driver of the system design

Just to clarify my earlier post, restriction of certain Q/QK Object ID in ESS are restricted to their own data. Same goes with MSS; the restriction are referring to their respective subordinate data only. In other words, the general rules are still applied. However, there are certain Q/QK object IDs maintained in master data are only meant for HR personnel and must be transparent to employees in ESS/MSS.

Based on your feedbacks, I believe that structural authorization for ESS is needed in this case; and it is possible to be implemented using SAP* registered in OOSB - hope I get it right. I'm in the midst of testing it and praying hard to get the expected result; I'll update my findings once done.

Best Regards.

[Former Member]

Hi All,

Thank god; I manage to get the expected result - so happy and million thanks for your advices.

But of course I only tested on the restriction required. I need to ensure the concept applied will not affect other areas - thorough test (positive and negative) will be performed during the UAT.

Best regards and enjoy your weekend