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: 

Org criteria constraint in PFCG?

Former Member
0 Kudos

Gentlemen,

Please help to dispel my doubts as you know the score..

We have found that line-oriented authorization mechanism does not work as expected in our system in case when authorizatins/profiles for different org. criteria are merged into single profile in role in PFCG. Say, we have custom transaction Z1 which provides maintenance view ZV1 and have org. criteria ZORG1 with defined fields for that. And have another transaction Z2 for ZV2 and org. criteria ZORG2. Provided S_TABU_LIN object has proposal values for Z1 and Z2 transactions in SU24, when adding these transactions into menu of a role PFCG would merge authorizations into single profile under S_TABU_LIN (irrelevant of type of fields defined for org. criteria).

S_TABU_LIN

ACTVT *

ORG_CRIT ZORG1, ZORG2

ORG_FIELD1 <some value>

...

ORG_FIELD8

In this case it will not protect the ZV1 and ZV2 views based on field values in S_TABU_LIN, but will allow to change/display all possible data of a table. When authorizations for ZORG1 and ZORG2 are in separate profiles under S_TABU_LIN of the same role it does work as expected limiting the data in the maintenance view:

S_TABU_LIN

ACTVT *

ORG_CRIT ZORG1

ORG_FIELD1 <some value>

...

ORG_FIELD8

ACTVT *

ORG_CRIT ZORG2

ORG_FIELD1 <value1>

...

ORG_FIELD8

I could not find a note for this and was told by SAP AGS briefly this is a contraint and you can only assign one org. criteria into a profile. Could you confirm the same based on your experience so I am 100% sure we now have security issue in our production.

Igor

Edited by: Igor Kustov on Jun 3, 2011 1:20 PM

9 REPLIES 9

Former Member
0 Kudos

Hi,

In SAP we deal with something like a three step table protection for maintenance view.

A) First step:

1) The first step is the general protection of tables that is covered by the

authorization object S_TABU_DIS.

2) This S_TABU_DIS consists of two fields.

The field ACTVT [activity], and the field DICBERCLS [authorization group].

3) alues for the field ACTVT are 02, 03 ect.

4) Concerning the values for the field DICBERCLS, protected by so-called authorization groups, the defined groups are listed in the table TBRG and the assignment of tables to authorization groups is listed in the table TDDAT.

B) Second step:

1) The second step in the table access control is based on the object S_TABU_CLI.

2) This object protects the client-independent, means the cross-client tables.

3) The value for this object is X [indicator for cross-client maintenance].

4) The indicator X does not automatically allow maintenance, the access scope is still limited through the field values in ACTVT of the object S_TABU_DIS.

C) Third step:

1) S_TABU_LIN allows an access granularity down to the line level of the tables.

2) This is connected to special customizing adjustments, the definition and activation of so-called organizational criteria.

3) The predefinition of organizational criteria like e.g. a plant or a country,

access to tables can then be limited to the lines of the organizational criteria only.

Regards,

VInod.

0 Kudos

Hi Vlnod

Your answer has helped me understand better the S_TABU* objects - thank you.

I understand that there may be another new object - S_TABU_NAM (I think that is the one) which can be set to allow access to specific tables. Not had a chance to use this yet - have you got access to try it please?

Regards

David

0 Kudos

S_TABU_NAM is an alternative to S_TABU_DIS. It is not an additional check.

If you have many S_TABU_LIN fields activated for tables and maintain them in Su24, then it can happen that the merge function will combine them. But then you have maintained Su24 excessively of have transactions in the same role which are mergable, so you should reconsider these options.

The F1 documentation in transaction ABAPDOCU on statement "authority-check" explains this restraint very well - otherwise it would not be possible to display more than you can change, etc.

ps: Try change the proposals for ACTVT to the correct values you intend. Then they are unique and will not be merged, but still be in the same role as different authorization instances.

Cheers,

Julius

Edited by: Julius Bussche on Jun 3, 2011 9:54 PM

0 Kudos

Hi

ps: Try change the proposals for ACTVT to the correct values you intend. Then they are unique and will not be merged, but still be in the same role as different authorization instances.

I like 'clean' ways of doing things so this fits nicely for me..the S_TABU_NAM sounds interesting.

Regards

David

0 Kudos

Thank you for your replies, but my problem is a bit different, I guess the explanation I provided could be misleading..

Say, if I maintain SU24 proposal for transactions with some values for different org.criteria, and then add these transactions into menu of a role, PFCG would merge them into single profile under S_TABU_LIN. As a result, the set of data to change/display would be limited according to the fields of org. criteria defined. That is ok and is how it should be working. But it is NOT working for me that way: it does not restrict data by any means rather allows to change/display whole view. If the authorizations for different org criteria are in different profiles (not merged) under same role then it will work.

Example:

S_TABU_LIN

ACTVT *

ORG_CRIT ZA, ZB

ORG_FIELD1 ABC

...

ORG_FIELD8

In theory above authorization should provide change/display access for views defined in Org. criteria ZA and ZB limited by "ABC" in certain column.

In my situation it provides change/display access for whole views in both transactions.

If authorizations are separated:

S_TABU_LIN

ACTVT *

ORG_CRIT ZA

ORG_FIELD1 ABC

...

ORG_FIELD8

S_TABU_LIN

ACTVT *

ORG_CRIT ZB

ORG_FIELD1 ABC

...

ORG_FIELD8

It works as expected, allowing change/display for views for "ABC" records only.

Thanks,

Igor

0 Kudos
ACTVT *

???

That is what you give it, so it merges it and that is what you get.

I don't see the problem.

Cheers,

Julius

0 Kudos

The problem is not with the permitted activity (which in case of * would mean 02 and 03 explicitly for the reduced data) but with the set of records available for maintenance. It just does not work if merged..

0 Kudos

Yes, this can be a pain sometimes for objects with many fields - but then your choice of field has a semantic mismatch in it.

What is 'ABC'? If these are Z-tables then please see SAP note # 7 ...

As a workaround you can drop the * in actvt and add 'BD' to one of them. This will prevent the merge, but you will still have the same problem if '02' and '03' are in both authorizations - from the perspective of 'ABC'.

I think you need to read the documentation on S_TABU_LIN in SU21 again, to be that it is optional and you must have activated the table in SPRO.

Anyway.... drop the ACTVT * and see what happens...

Cheers,

Julius

0 Kudos

The problem was with the following.

If a single role consisted of a several values for one org. criterion in a single authorization for S_TABU_LIN, i.e.

S_TABU_LIN

ACTVT *

ORG_CRIT ZORG_CRIT_WERKS

ORG_FIELD1 GE, UK

..

ORG_FIELD8 *

then S_TABU_LIN would not limit the view by specified ORG_FIELD1 (Plant it is).

Another issue was that if there were several single roles in a composite one with each one having different value for ORG_FIELD1 for the same ORG_CRIT, i.e.

single role1:

S_TABU_LIN

ACTVT *

ORG_CRIT ZORG_CRIT_WERKS

ORG_FIELD1 US*

..

ORG_FIELD8 *

single role2:

S_TABU_LIN

ACTVT *

ORG_CRIT ZORG_CRIT_WERKS

ORG_FIELD1 AM*

..

ORG_FIELD8 *

then it would not work as expected - view would be limited by either one or another ORG_FIELD1. Could be fixed by deletion & regeneration of the profile for the predecessor role.

There was a long correspondence with SAP and finally we fixed this by applying note 1265050.

Thank you for your attention,

Igor