Authorization or Role Collide

[Former Member]

I've searched Blogs, Google and the Forums but no information on Authorzation or Role Collide.

Can someone send me some information on how SAP handles Authorization Objects and how they can "collide" in the User Master?

Arguments for and against this phenom, but during Trace process not too identifiable. User's sometimes have access to certain functions and then not.

User's Master sometimes filled with up to 275 Roles, so wanted to see if Role Collide or Authorization Object Collide was happening.

Please send what SAP Defines on this subject, IF you can find it. I don't think they even know.

Thanks.

[Former Member]

This message was moderated.

[arpan_paik]

 IF you can find it. I don't think they even know. 

I will say NO on the same. SAP do know and many others I beilive.

Well here is some information for you.

1) When you generate profile for a role then in the background a profile also get generated against this role

2) A single profile can have maximum 150 authorization objects.

3) So if a role is having more than 150 profile then more than 1 profile get generated for the role

4) Now a user can have maximum 314 profile in his/her user buffer

5) Once you assign role to user then at the same time the profile against the role automatically get assigned to the user. You can find the same in profile tab

6) That's all

One more thing need to take care that even if a user can have profiles below 314 but user might not have access to the same as User buffer might not be refreshed. To avaoid the same you can do any of the below

1) Open the user in change mode and save. (User need to logoff and log-in to take this effect)

2) Compare all the roles assigned to the user in PFUD (Before run this transaction you must gather sufficient information on this one) ...relogin not required for user

3) Schedule periodic batch job (preferably daly just after midnight) for report 'PFCG_TIME_DEPENDENCY'

Ohh...quite big post !!! You must get lot of patince to read the same...

Cheers,

Arpan

[Former Member]

> I don't think they even know.

Yes they do - if you look in the FAQ sticky thread you will find two SAP notes relating to "collision" of profile names.

The most common cause of it is generating roles (and their corresponding profiles) in production systems, when your SID naming convention for PROD, DEV, TEST etc has the first and the last character of the SID identical.

Another common cause is from importing roles from other networks (or "out-of-the-box" toolkits) where an identical SID name was used for the development.

Your solutions are:

- Reset the number range.

- Extend the prefix.

- Change the process.

I do not recommend manually naming profiles. You should be able to forget about their names and your range will run out or cause collisions sooner than a well chosen number range interval will.

Cheers,

Julius

Edited by: Julius Bussche on Apr 24, 2010 10:30 PM

FAQ updated: You will now find 3 SAP Notes.

[Former Member]

Thanks Arpan and Julius...but, not sure if we connected on my issue.

The issue is when some Users execute a Transaction, certain Users have access to certain screens and functions (within same Tcode) while others do not. These same Transactions are in different Roles (assigned) with Authorizational Objects with different values. Lead Security Team members have advised that this is due to Role (or Authorization Object) "collide". The values within the same Authorization Object are "truncating" other values, which is known within our Industry as Role Collide.

To clarify my question, does this Collide happen only when a User has the same Transaction Code within different Roles that have different values, OR does this Collide happen simply because the User has the same Authorization Object with values with more access (ie and Asterix "*")?

Thanks for any further input.

Edited by: Slammer on Apr 26, 2010 6:06 PM

[Former Member]

>

>The values within the same Authorization Object are "truncating" other values, which is known within our Industry as Role Collide.
>

Hi,

I think that term might be used by your security team, but it's not an industry wide term as far as I am aware.

Anyway, onto the point. A users authorisations are buffered from the profiles assigned to their ID. At the point of an auth check, the buffer is evaluated for a "value set" (authorisation) that meets the requirements of the the check. Authorisations do not truncate or merge.

If you have users with the same t-code then differences in access will be directly related to:

- Different authorisation value sets in the roles assigned to the user

- Difference in parameter ID's

- Custom checks or additional validation being performed

This the is the standard authorisation concept and follows the principle of the transaction code being used as the entry point to accessing the functionality and auth objects further governing what a user can do once in there and what data they can perform it on.

If you are having a problem with users with identical access having different levels of access within the same transactions then this can often happen if there are lots of security related transports being imported and user compare not being performed after the import.

I hope that goes some way towards addressing your concern - if this is not what you are looking for then please clarify.

[Former Member]

This happens in SAP security when the index finger and F1 key do not collide...

[Former Member]

Thanks Julius! I think it's the F10 key....

Alex, here are 2 examples of Roles for 2 Users.

User A:

Role 1

Tcode: FB03

Auth Object: F_BKPF_BUK

ACTVT: 03

BUKRS: 1010

User A:

Role 2

Tcode: FBV3

Auth Object: F_BKPF_BUK

ACTVT: 03

BUKRS: *

User A has access to ALL Company Codes for both Transactions, we thought because of the * in Role 2, that User A's User Master is "inheriting" the * from Role 2.

Another similar example

User B:

Role 1

Tcode: FB03

Auth Object: F_BKPF_BUK

ACTVT: 03

BUKRS: *

User B:

Role 2

Tcode: MB51

Auth Object: F_BKPF_BUK

ACTVT: *

BUKRS: 1010

User B has access to ALL Company Codes for both Transactions.

BTW, we had also ensured PFUD had been executed and all Roles have been Compared, so we are all set here.

Might it have something to do with what Julius said previously, that the Profiles associated with the Roles are causing the inheritance? Because it looks like those have been maintained for some Roles and not others.

Thanks.

[Former Member]

Yes, they will display all BUKRS from any company code and pass the plausibility check (defined in SE93) at the start of the transaction

But they will not be able to post to BUKRS other than 1010, unless there is another authorization which is overriding these two.

Try it and see what happens?

Generally, if transactions make conceptually consistent checks, you will achieve consistent system behaviour for transactions of the same ilk.

The choice of transaction is also important and you have many options there...

Cheers,

Julius

[Former Member]

> User A:

> Role 1

> Tcode: FB03

> Auth Object: F_BKPF_BUK

> ACTVT: 03

> BUKRS: 1010

>

> User A:

> Role 2

> Tcode: FBV3

> Auth Object: F_BKPF_BUK

> ACTVT: 03

> BUKRS: *

>

> User A has access to ALL Company Codes for both Transactions, we thought because of the * in Role 2, that User A's >User Master is "inheriting" the * from Role 2.

>

You are right. SAP is looking for an authorisation set that satisfies the check. The 03 & * combination will satisfy all the checks as authorisations are aggregated in the user master

>

> Another similar example

>

> User B:

> Role 1

> Tcode: FB03

> Auth Object: F_BKPF_BUK

> ACTVT: 03

> BUKRS: *

>

> User B:

> Role 2

> Tcode: MB51

> Auth Object: F_BKPF_BUK

> ACTVT: *

> BUKRS: 1010

>

> User B has access to ALL Company Codes for both Transactions.

>

> BTW, we had also ensured PFUD had been executed and all Roles have been Compared, so we are all set here.

>

> Might it have something to do with what Julius said previously, that the Profiles associated with the Roles are causing the >inheritance? Because it looks like those have been maintained for some Roles and not others.

In this case the user will have display access comp codes for all transactions but will only have change for comp code 1010. The authorisation check is looking first for the transaction auth via S_TCODE and then it's looking for an auth object to satisfy the check. SAP doesn't care where it gets the auths from - if they are in the buffer then they are available. What you can't do is to use 03/* for FB03 and */1010 for MB51. There is nothing to tie those authorisations specifically to the transactions, they apply for all transactions that use them.

Basically SAP is behaving as expected and designed. The auth object value sets (the authorisations) are not limited to the transactions that are in the same role, they are shared across all transactions. As you are now seeing, it can cause problems as well as being very useful. If this is causing you problems then there are a few options available

Edited by: Alex Ayers on Apr 27, 2010 10:14 PM

[Former Member]

Thanks guys!

My Conclusion with your help: Authorization Object values can be shared across multiple Transaction Codes they are assigned to, and if assigned to a User, need to be analyzed because these values can cause functionaity not needed nor expected.

Thanks again!

Chris

[Former Member]

Yes.

As a good example, you can conclude that there is a difference between MIR* transactions and FB01 as choice of weapon..

If you choose the "wrong" one then you are sometimes forced into granting access to the other as well.

You can use the "no check" option as indicated by Alex, but please be aware that this applies globally to the transaction context so it can open other doors. You should only use this in exceptional cases, but is much better documentation than not coding the checks...

Cheers,

Julius