Minimize the number of roles using the Bolt-onu2019s

Question

I read a artical from SDN it discribes the process of maintating Orgnization Authorization in saperate Role. This helps to reduce the no of roles been created. Below is the discribtion. And I tolly agree with the concept . Read below .
>According to Artical
>You can make use of the Bolt-on concept to reduce the total number of profiles that need to be built in an implementation. An example will clarify the benefits of its implementation.
>Letu2019s consider the purchase requisitions. There are two business rules exist for approving the purchase requisitions. One is the plant code, and the other is the Release code. Assume that you company has 10 different Release codes, for various approval ranges. Now, on the other hand, if you have 20 plants, you need to have 20 X 10 = 200 roles. That is 10 roles per plant.
>By using the Bolt-on concept, this can be achieved by removing the authorization objects which control user status (these objects contain no organizational value component) from the transactional role and placing them within their own unique global role with the plant code. This way, you will end up with creating 10 transaction roles without the plant code and 20 global roles, which will have only the plant code in it.
>Further, the appropriate combinations can be determined by the business requirements.
>This approach reduces exponentially the number of roles that need to be built. The end result is that 30 roles are required to achieve the same objective.
>The same Bolt-on process can be implemented when the authorization check is done on an organization level. However, this process will be viable only when the number of roles that needs to be created are more.
As of my understanding we need to isolate all Auth objects from a role and make a saperate role specially only for Org structure. And then give combination of those Org Roles to provide access for those Org Units.
My Question is
1) how do we Identify all Auth obejcts that give access to a Org unit from a given role.
2)How to make a role that gives Authorization for a perticular Org Unit only. (And that role should not have any authorization for Tx or activities)
3)What is recemmended to maintain Org unit Authorization ? Is Bolt-onu2019s mehod suitable to maintain all Org Unit Authorizations?
Edited by: Hussain Sehorewala on Jul 2, 2008 4:11 PM

Answer 1

>
Jurjen Heeck wrote:
> It is non SAP-standard and I generally advise against them for just that reason. It requires a lot of documentation and checks to make sure no-one destroys the concept just by following SAP guidelines. Also upgrades can cause a lot of problems with bolt-ons.
>
> Jurjen
I agree 100% with Jurjen.  It can work well but in the vast majority of times I have seen them, they have led to reduced control, reduced auditability and basically been a mess.  SecureInfo have a tool which builds roles in this way but it also has appropriate controls in place too.
If you look at the following scenario:
You have a functional role and an org role.
If you have org roles for each func role then you are in the same situation as you are with derived roles.
If you start to combine auth objects to build a bigger org role then you are assigning additional auth objects over and above what the transactions in the func role require.  We all know that to properly secure something, you need to control by auth object so in this case you are already potentially opening yourself up to giving excess access.
6 months later you want to remove a tcode from the func role.  If you maintain std SAP method properly then the auth objects will also be removed too if it not shared.   With lots of these objects in the org role then you will need to cross check every single tx in the func role with every object in the org role.  Most people don't bother & that's one of the reasons why this build method can get very, very messy as you lose the link between t-code and object that SU24 provides.
I've used this method in BW a few times & it works really well, but for R/3 it usually ends up with more trouble than it solves.   There are situations where is can make things easier but I would only use it as a supplement to a standard method role build.