Question:
Table driven authorization is NEVER recommended and is far more maintenance than using SAP PFCG nor is it as secure. Further the SAP functionality will NOT use it directly and you will have to change miles of code to get it to work.
The Kernel takes the reference to the authorizations out of the user buffer and retreives the authorizaiton values from the database to perform the check. IT knows not of your table nor cares.
Create the roles and assign them, you will be further ahead. But first ask WHY segregate them? is there something you are tryinf to hide? what is the risk you are protecting? what is the potential of occurance? what is the cost? Are you using security instead of training? Are you allowing the Cost center stewards to abdicate their responsibility of monitoring their Cost centers?
THe answer should be abandon the task and move on to something more fruitful.
Answer:
Hello John,
I agree with your comments, however, I am looking for this solution to achieve other objectives, where approvals for a number of different items are based on cost centre owners as determined in the HR org structure. We can already do this in PS, timesheets and expenses as there is a standard mechanism that allows us to implement this.
What I am looking for is to see the options of replicating this to controlling in general.
As mentioned I am aware of a client that implemented such a solution, which did not involve tons of coding. What I am not aware of is how they achieved the solution, and unfortunatly I don't have a contact there.
I had a look at role personalisation, which may be able to provide a solution, but there is no documentation on this feature.
Any additional ideas would be appreciated.
Answer:
If it is on the FI side you there are many user exits or Business partner funtion to do this, the question still is, Should you?
Table driven access is NEVER appropriate.
If you are relying on SAP to contorl your "apprval" based on Cost Center then your invoice Business process if backwards. When An invoice is received it should be stamped as received, sent to the person that can verify the services where performed, code the charges correctly to the appropriate Cost centers and send the "approved" invoice to accounting for entry. Your Cost center steward is then responsible for reviewing costs and ensure they are correct. TO have SAP do this you are allowing the cost center steward to abdicate their responsibility and "blame it on SAP" if it is wrong.
To create a table driven access you are recreating SAP security on a unsound easily manipulated basis.
Yes someone might have achieved this, but should they? are you sure there is not tons of coding? Will it out-live the person who created it? , is it supportable long term? then answers are generally NO.
Answer:
Hi All,
Lets ignore the specific business process at the moment, I used it as an example to provide context.
Currently we have implemented org level segregation of responsibility in a number of areas such as PS, time sheets and expenses. The difference in this case is that the segregation is driven off of the HR org structure and the responsible cost centre that an employee (user) is either directly responsible for, or is assigned responsibility for, is used in managing the access rights.
This works well in the areas we have implemented it.
This concept is not strange, SAP themselves put forward such a structure of splitting roles and responsibilities in their document titled 'Business User Administration - User Management strategy for mySAP.com', and a similiar concept already applies in EBP.
Using this approach will allow us to publish responsibliity information, relatively easily, to an LDAP and make it available to other applications, which in itsef will simplify security management across different applications SAP and NON SAP.
Even if an LDAP is not used the org structure can be replicated across different SAP components to achieve a consistent definition of responsibility
In the areas we have achieved this it was relatively easy, however, I am looking at the broader options and chose controlling as an example because I am aware that a client had done this, using a table. Once I understand how they did it, I can easily substitute the responsibilities from a table with those defined in the org structure.
Essentially I want to investigate the how the mechanics might work rather than is the segregation example I used a valid business rule. It might just as easily have been company code or sales area.
Role personalisation seems to provide some options to deliver specific access rights, by enabling a function module to be related to the role, however, there is no worthwhile documentation that I can find to determine if this would be a viable solution.
Any thoughts and assistance on the concept are appreciated.
Answer:
Let me answer it simply.... It does not exist for FI.
Currently we have implemented org level segregation of responsibility in a number of areas such as PS, time sheets and expenses. The difference in this case is that the segregation is driven off of the HR org structure and the responsible cost centre that an employee (user) is either directly responsible for, or is assigned responsibility for, is used in managing the access rights. HR and the rest of SAP are entirely differnt and the two do nto mix, what you can do in HR is not transferable to the rest of SAP, except for a few places in SD and Project systems, but ith has more to do with Personel the to non-personal entities like Cost center. While you think you are limiting on reponsible cost center in HR you are controlling on the org structure that happens to have a cost center tied to it.
This concept is not strange, SAP themselves put forward such a structure of splitting roles and responsibilities in their document titled 'Business User Administration - User Management strategy for mySAP.com', and a similiar concept already applies in EBP. A lot of what SAP proposes is possible, just not practicle or best practices ( composit roles for one) but cures to symptoms not root cause analysis and correction.
Using this approach will allow us to publish responsibliity information, relatively easily, to an LDAP and make it available to other applications, which in itsef will simplify security management across different applications SAP and NON SAP.
Even if an LDAP is not used the org structure can be replicated across different SAP components to achieve a consistent definition of responsibility It still all rolles down to a SAP r/3 ID with a SAP r/3 role attached regardless of the cleaver reporting. management, etc. front end you tie to it. THe SAP kernel will look at the authorization tied to the user and could care less about all the rest....
Role personalisation seems to provide some options to deliver specific access rights, by enabling a function module to be related to the role, however, there is no worthwhile documentation that I can find to determine if this would be a viable solution. Role personalization is to control the pretty front end not access....
The Standard SAP access does not have a function module to majically ascertain access like the PD profiles do that only filter the standard access after the fact. THere is no Variable to fill the values at runtime as it would require direct table maintenance and would open all users to the access at the second you hit the commit work. Standard SAP access control is not "dynamic" like PD profiles and contigent on the persons location in the HR hierarchy, it cannot be as not all installation have HR or intend to use it.
Answer:
Hello,
Thanks for the reponse. I am quite aware of what is possible, practical and as for best practice, that is a matter of opinion depending on a number of different factors, and how many security people are in a room
For example best practice for a role design in pharmaceutical environment with FDA regulation and GMP rules is likely to be different to a hi tech environment.
As for role personalisation there are options to control access, for example ABAP query can be controlled via SQ03 or transaction code mapping within a role or via role personalisation. In theory then this could be extended to other areas, how far and where, well that is why I am asking.
To answer your specific question on why cost centre segregation. We have a number of commercial enterprises running on one SAP client, however, there is an element of commercial sensitivity between these units that needs to be managed, hence the segregation requirement which we currently enforce using derived roles. However, as you would expect, maintenance is higher than we wish, and we are looking for other solutions.
I need to manage an environment with different SAP and non SAP applications, and ensure a consistent responsibliy defintion. The solution document SAP presented does provide a degree of value / oppurtunity.
As no one else has replied I guess there has not been a lot cross application concern for security management across applications accessed via EP (netweaver solutions) and ensuring consistent role responsibility definition, any other ideas?
Perhaps the solution I am investigating could be the start of a homogenous systems management best practice, you never know
Cheers
Peter