Context-Sensitive Structural authorization vs OOSB

[former_member1308046]

Hi,

We are currently using standard HR Structural security (updating the table T77UA).

We would like to convert to Context-Sensitive Structural Authorization but I have one unanswered question that could impact our decision.

If we switch to CSSA, could we also be able to maintain table T77UA for exceptions?

Let me explain:

I could easily convert 95% of my HR roles to CSSA but for some of them, there are no "rule" as to how we assign security. It means that the business would still like to be able to assign any org units they want for those users.

Could I be able to use both solutions at the same time? Using CSSA for 95% of my HR roles but still be able to update the table T77UA for the users that have those 5% exception roles?

Can you also explain how the BAdi HRBAS00_GET_PROFL works? Is it completely overlooking the T77UA table? If so, I guess it would answer my question...

Thanks a lot for you advices

Sophie

[shivraj_singh2]

Sophie,

I think the solution to your scenario is possible.

What I understood about your scenario is that currently the security set up is

P_ORGIN + T77UA

With contextual structural authorization solution (CSA), without BADi, it will become

P_ORGINCON PROFL + T77UA

The important caveat about the field PROFL is that you can only enter the structural profile that has been entered in T77UA table.

So if you don't want to the access to be limited by contextual set up, please enter *, this way access will take account of all the structural profiles assigned in T77UA. However if there is no entry in T77UA, it will default to ALL profile for SAP* as usual. So you will have to be careful and ensure that there always is a proper entry in T77UA. The other restrictions like position-org relationship, functional module will still be effective as before.

I don't have a system available to test it but I am 95% sure it will work .

Regarding BADi implementation - this will simply change your security set up to

P_ORGINCON + PROFL

T77UA will not come into play anymore.

Regards,

Shivraj

[former_member1308046]

Hi Shivraj,

You understood my situation.

There's one thing I would like to clarify. When you say:

"The important caveat about the field PROFL is that you can only enter the structural profile that has been entered in T77UA table."

I guess you meant table T77PR, right?

The only problem with your solution is that I would still like to implement the BADi AND be able to maintain the table T77UA (only for exceptions). With the BADi implemented, I wouldn't have to maintain the table T77UA for 95% of my roles, which is what I want. But I still need a way to assign single orgs for some users.

I don't understand how everybody else does it. Do they create multiple copies of the same role with each possible org units they have in the enterprise? We have so many orgs that I couldn't even possibly think of doing that...

Thanks again for your help!

Sophie

[shivraj_singh2]

Sophie,

1. It is table T77UA and not T77PR. It is little misleading the way it is stated. But it simply means if structural profile A is mapped to position/user i.e. for user the entry in table T77UA is "A", then in P_ORGINCONPROFL entry should also be A.

2. With BADi, table T77UA goes out of picture. But it is essentially a program which can be altered and tailored to your need of having exceptions. Although I will strongly recommend against it, as contextual solution is already sophisticated enough to handle any scenario.

3. You mentioned two things - 5% roles for exception & maintaining copies of roles for different Orgs. Together these two left me little confused. Org relationship are not maintained in roles. That is positions and maintenance of which is not security task, it should be handled by OM person. I believe you should involve OM functional to review the scenario you have.

Regards

Shivraj

[former_member1308046]

Shivraj,

It's hard for me to explain what I need to do so here's a question.

Would it be possible to have an "open" profile in the object P_ORGINCON (PROFL)?

We have scenarios where one role (ex: ZHRSUPPORT) could have access to ANY org unit. To be able to do that using Context-Sensitive Authorizations, I would have to create multiple copies of the role ZHRSUPPORT. Ex: ZHRSUPPORT_ORG1, ZHRSUPPORT_ORG2, ZHRSUPPORT_ORG3 (where ORG1, ORG2 and ORG3 exist in T77PR).

Instead of doing that, I would like to know if it's possible to create only one ZHRSUPPORT role with an "open" value in the field PROFL? That way, I would assign the ORG1, 2 or 3 to the user's id directly in the table T77UA,

I'm sorry if it's still not clear enough. I really appreciate the effort you make in trying to help!

Thanks again!

Sophie

[shivraj_singh2]

Sophie,

HR is always hard to explain as it is client-specific customization, so frustration in expected and understandable but "open" profiles is not something that should be part of any security design.

Another confusing point is "access to ANY org unit" and "ORG1, ORG2 and ORG3 exist in T77PR". Entries in table T77PR are not org units, these are Structural Authorization Profiles or PD profiles, and these are totally different from org units. To have access to ANY org unit, access should be mapped to the top node of org structure with proper relationship at position level (Position-based security), like I said earlier org unit access is not assigned through roles, it is usually mapped to through positions. Access to all PD profiles is simple, just put (*) in PROFL field, but I am not sure how practical that will be, as org unit relationship at position has to be there and it will also depend on the functional module set up in PD profile. So I think you should involve functional person to review your requirement for ZHRSUPPORT in terms of org unit access and PD profile access and update the role & position accordingly.

Regards,

Shivraj