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: 

What would be following to: SAP Suggested Framework for role creation or making a new Framework which break this security pattern?

former_member599971
Discoverer
0 Kudos

When we want to propose a new Security Framework, should we change the way that SAP works? I mean, we have master role and derived ones, But I have worked in one client that doesn`t follow (at all) this manner of role design.

As per I know, we should design task roles and split into each task and grouping transactions related to those tasks as we called a position.

The composite role is the position role, and the task roles oriented to business, are master-derived.

Why is so common that we see this broken, I mean, we are not able to push the master role to derived childs, beause we are going to delete authorization that was customized inside the child role.

And what you think, are the risks linked to, having a model that doesn`t follow at all this kind of frameworks?

2 REPLIES 2

Former Member
0 Kudos

Hi,

The SAP auth concept and role mechanisms aren't perfect but they are what we are given.

The scenario you have described is one way of doing it but tasks combined in composites is not the only standard approach.  Derived roles offer some benefits but also have drawbacks and are not the default answer and as you have found, there is no point in using master & derived if the derived roles have different object values from the master.

Some of the risks I see are:

1. Reduced supportability - using standard mechanisms makes it easier for other people with standard security knowledge to support the design.

2. Less likely to get bitten by future SAP developments - It is very unlikely that SAP would intentionally break their standard concept.

3. Upgradeability - All sorts of weird and (not very) wonderful things can happen to non-standard auth concepts when upgrading.  Usually the architects of the solution are long gone at this point.

4. Reduced usability with SAP tools - there are some exotic role designs in the wild that require workarounds to work well with GRC or IdM (although IdM can adapt to these quite easily with some clever rules and/or creation of additional master data).

Cheers

0 Kudos

Thanks  a lot. This is what I expected.