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: 

Minimize the number of roles using the Bolt-onu2019s

Former Member
0 Kudos

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

1 ACCEPTED SOLUTION

jurjen_heeck
Active Contributor
0 Kudos

> My Question is

> 1) how do we Identify all Auth obejcts that give access to a Org unit from a given role.

Search table AGR_1251 for all field values (only to be found in "LOW") that start with a $

> 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)

You cannot, as many of the objects containing an organizational field will also contain an activity field.

If you accept the activity in your bolt on role you can create it by manually entering all required objects.

> 3)What is recemmended to maintain Org unit Authorization ? Is Bolt-onu2019s mehod suitable to maintain all Org Unit Authorizations?

I do not understand this part of your question.

Jurjen

6 REPLIES 6

jurjen_heeck
Active Contributor
0 Kudos

> My Question is

> 1) how do we Identify all Auth obejcts that give access to a Org unit from a given role.

Search table AGR_1251 for all field values (only to be found in "LOW") that start with a $

> 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)

You cannot, as many of the objects containing an organizational field will also contain an activity field.

If you accept the activity in your bolt on role you can create it by manually entering all required objects.

> 3)What is recemmended to maintain Org unit Authorization ? Is Bolt-onu2019s mehod suitable to maintain all Org Unit Authorizations?

I do not understand this part of your question.

Jurjen

0 Kudos

Can you explain the significance of Table AGR_1251 . And how to use it in connection with a pericular role?

-


(Questin 3 Again)

3) How to use Bolt-onu2019s ? Can anyone explain how to implement technically ?

Cause the above abstrac only refrers to concept. Can anyone elucidate Bolt-onu2019s method to maintain roles ?

Edited by: Hussain Sehorewala on Jul 2, 2008 5:21 PM

0 Kudos

> Can you explain the significance of Table AGR_1251 . And how to use it in connection with a pericular role?

Table AGR_1251 holds all field values for objects in a role, except the organizational fields, which are in AGR_1252. The rolename is in the field AGR_NAME. To browse tables use transaction SE16.

> -


> (Questin 3 Again)

>

> 3) How to use Bolt-onu2019s ? Can anyone explain how to implement technically ?

>

> Cause the above abstrac only refrers to concept. Can anyone elucidate Bolt-onu2019s method to maintain roles ?

They're just like all other single roles. It's just the content that makes them different, no menu and only manually entered objects instead of the profile being populated by the PFCG proposals based on TR's in the menu. In general, the objects maintained in the bolt-on role are disabled in the transaction/activity role.

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

0 Kudos

>

> 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.

0 Kudos

I made a role for SAP_all.

In that I checked out all Org Unit object. I observered that there are some Org Unit that are maintained in several diffrent Auth objects.

Company Code

Business Area

I belive it makes no sense to make Seperate Roles for such Org Units.Cause Auth for such Org Units are diff for diffrent Tx.

While there are some Org Units Whcih are maintained in few Auth Objects.

Purchasing Organization

Sales Organizations

Distribution Channel

Operating Concern

What we can do Is make Org roles for Such Org Units.

While others can be maintained in funtinal Roles.

The only problem would be while adding new Tx or Deleting New Tx In funtional roles.

Dose any one has solution for this? WHat is the normal approch followed while using Bolt-ons method ?

0 Kudos

Hi,

To add something to the discussion. I have seen this before and it can give big big problems. It does not explain it self when someone new has to maintain roles etc. It is not SAP standard following the two layer concept. You also have to be alert of activities in the authorization object. You have to decide if such an organizational role must be created per composite role. It is possible that there will be a difference in activities in an other composite role. It gives you extra complicity. If you use the derived role method and make your changes in the template role and use the button to generate all derived roles it is not much work. Yes it gives more records, but in the total off the application it will be peanuts.

I have seen this method with organizational roles and the effects, please don't do it.

have fun

Bye Jan