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: 

Organization level control on Role

Former Member
0 Kudos

Dear security gurus.

I have 2 business roles in company and 2 subsidiaries under HQ.

Each company have

- Accout clerk

- Account manager

HQ's clerk&manager: be able to check all company's data.

Subsidiary's clerk&manager: be able to check ONLY their own company's data

In this case, I have to create these 6 roles, because

company code restriction can be controled only by role, not user.

Am I correct?

1.HQ's manager(Company code: *)

2.HQ's clerk(Company code: *)

3.Subsidiary1's clerk(Company code: 1)

4.Subsidiary1's manager(Company code: 1)

5.Subsidiary2's clerk(Company code: 2)

6.Subsidiary2's manager(Company code: 2)

Yoshi

1 ACCEPTED SOLUTION

niteshgupta87
Active Participant
0 Kudos

There is another approach you can consider, Enabler Role based.

1. Create roles including only transactions and all associated authorizations. Keep org levels blank (comp code in your case). So you need to create 2 roles: CLERK and MANAEGR.

2. Create enabler roles for each company codes. These roles will not have any tcode. Only authorization objects related to org levels (company code) would be added to this role. So you need to create 2 enabler roles: COMPCODE1 and COMPCODE2.

Now you can assign appropriate combinations to any user. Ex, clerk of company 1 would be assigned CLERK and COMPCODE1 roles.

HQ managers and clerk would get their respective tcode basd role and multiple enabler roles.

This approach would be much easier to handle. As if there is any new position, you would just have to create a tcode based role. If there is a new company code, you would just need to create enabler role.

In enabler roles, you can also consider other finance related org levels apart from company code.

Regards,

Nitesh.

8 REPLIES 8

Former Member
0 Kudos

Hi, your assumption and solution is correct.  You restrict at role level and assign those roles as appropriate to grant the access.

Former Member
0 Kudos

Hi,

I'd never give business access to all companies.

My proposal:


1.HQ's manager(Company code: 1, 2)

2.HQ's clerk(Company code: 1, 2)

3.Subsidiary1's clerk(Company code: 1)

4.Subsidiary1's manager(Company code: 1)

5.Subsidiary2's clerk(Company code: 2)

6.Subsidiary2's manager(Company code: 2)

You could also assign HQ both roles of subsidiaries:

1.HQ's manager (MGR-01, MGR-02)

2.HQ's clerk (CL-01, CL-02)

3.Subsidiary1's clerk (CL-01

4.Subsidiary1's manager (MGR-01)

5.Subsidiary2's clerk (CL-02)

6.Subsidiary2's manager (MGR-02)

That way, you need only four roles

MGR-01

MGR-02

CL-01

CL-02

- more effort with assigning the roles

- saves a little effort on the roles management side

- works only if needed transactions are exactly the same (Subsidiary vs HQ).

greetings

Alexander Walkenhorst

0 Kudos

I agree. Also remember to turn SSM_CUST-DELETE_DOUBLE_TCODES to 'YES' so that the end users notices not that there are multiple role menus with duplicates being condensed into one.

Cheers,

Julius

niteshgupta87
Active Participant
0 Kudos

There is another approach you can consider, Enabler Role based.

1. Create roles including only transactions and all associated authorizations. Keep org levels blank (comp code in your case). So you need to create 2 roles: CLERK and MANAEGR.

2. Create enabler roles for each company codes. These roles will not have any tcode. Only authorization objects related to org levels (company code) would be added to this role. So you need to create 2 enabler roles: COMPCODE1 and COMPCODE2.

Now you can assign appropriate combinations to any user. Ex, clerk of company 1 would be assigned CLERK and COMPCODE1 roles.

HQ managers and clerk would get their respective tcode basd role and multiple enabler roles.

This approach would be much easier to handle. As if there is any new position, you would just have to create a tcode based role. If there is a new company code, you would just need to create enabler role.

In enabler roles, you can also consider other finance related org levels apart from company code.

Regards,

Nitesh.

0 Kudos

Hi Nitesh,

How do you deal with the challenge of COMPCODE1 role containing much more access than the user requires?

Cheers

0 Kudos

Do not do this!

Alex already raised one point. Goodluck with SU25

if you search this space you will find quite a detailed discussion on the use of theae roles.

0 Kudos

Hi Alex,

The role COMPCODE1 or 2 would provide only org level access. You can further create 2 roles: Display and Edit for each company codes.

I agree these roles would contains much more objects then required for one activity. But if you carefully create roles CLERK and MANAGER, users will have limited access only.

We have used this enabler role approach for 2 clients and both clients were 100% SOX compliant from roles perspective. Even I have seen feedback from some forums that business prefers enabler roles concept.

Regards,

Nitesh

0 Kudos

Hi Nitesh,

Herein lies the problem for me.  Putting aside technical challenges of this approach it violates one of the most basic principles of infosec which is the principle of least privilege.  Adding in a load of extra auth objects that are not required violates that.  I'll freely admit that some companies do like it, some of them even make it work but I venture that they are in a minority judging by the number of historical projects to fix the mess caused by these approaches.

It's also worth considering that typical controls for SOX 404 are subjective and are geared towards what can measured rather than providing a full coverage of risk.  Currently most organisation's ITGC's are missing some pretty important stuff!

Cheers