difference between authorization field content *, ' ' und blank

[Former Member]

Hello everyone,

I'm at the beginning with authorization topics of the in SAP R/3-System. Out of a system trace I received the same authorisation fields with different content. In this context can anyone tell me the difference between *, ' ' and blank-content of an authorization field?

Thank everyone for helping ...

Marcus

[Former Member]

Hi Marcus,

my understanding would be

• means all

'' (dummy) means the authorizations check passes if the user has any value that can fulfil the condition

Example:

In the program If you have a " for the plant ( werks ) and if the user has in his authorizations a value XXXX or YYYY the check is fulfilled and it passes to show data related to XXXX or YYYY as might be the case

[Former Member]

Hi,

• means all access

' ' means If you do not have the subtype for an infotype sytem will not given any error

Best Regards

Vikas

[former_member275658]

To Add,

The concept of ' ' value is mostly used in the Master and Derived roles. Suppose, there are org levels in the roles which you want to restrict then we can use ' ' in the master role and other values in the org level of the derived role.

Where as * means full authorization to the user.

Thanks!

[Former Member]

Marcus,

• is full authorization

Eg: Let us in xyx company, plant location are 1000 to 5000, now for plant you have given * ( means user will be able to see complete plant reletead data) ie fromm 1000 to 5000

dummy : means you don't want to check/include this field for authorization check ...(you are not restricting on that particular field)

http://sap.ittoolbox.com/groups/technical-functional/sap-security/difference-between-dummy-and-for-a...

Thanks,

Sri

[Former Member]

It also depends on how the developer coded the authority-check.

Wrong is:

AUTHORITY-CHECK object_name
    ID id1 FIELD DUMMY.

Correct is:

AUTHORITY-CHECK object_name
    ID id1 DUMMY.

' ' comes from use of the ABAP statement "SPACE". It has it's uses in security (for example DESTINATION SPACE) but as an authorization field value searched for in the user's auth buffer it is like a dead tree stump in your garden...

Using the SUIM Info System is however the other side of the coin... as you here are not searching for the values which satisfy the AUTHORITY-CHECK, but rather the DB field values which would do it in the program.

Wrong is:

> Search for '' for find the value '', as it is anything

Correct is:

> '#' to find the explicit '' value.

> '*' will return anything which can fullfill a correctly coded DUMMY check.

> For those who use ranges and click on everything, use '#**'.

To fullfill a really badly coded authority-check, you can also try 2 spaces between the ' ' but it is more advisable to correct the code.

Cheers,

Julius

[Former Member]

To fullfill a really badly coded authority-check, you can also try 2 spaces between the ' ' but it is more advisable to correct the code.

You are referring to a [text field literal|http://help.sap.com/abapdocu_70/en/ABENLITERAL.htm] (enclosed by single quotes <b>'</b>) for which trailing blanks are irrelevant in comparisons for (non-)equality. To ensure that one space doesn't match two spaces one normally would have to use string literals (enclosed by backtick quotes <b>`</b>).

E.g. the following program would print all conditions are true:

if SPACE = '' and SPACE = ' ' and SPACE = '  ' and
    '' = ' ' and '' = '  ' and '' = '   ' and
    `` <> ` ` and `` <> `  ` and `` <> `   ` and
    `` = ' ' and `` = '  ' and `` = '   '.
  write / 'all conditions are true'.
endif.

Now here's what the ABAP help says about [trailing blanks in character string processing|http://help.sap.com/abapdocu_70/en/ABENSTRING_PROCESSING_TRAIL_BLANKS.htm]:

Statements for character string processing generally keep leading blanks for operands of data types with fixed lengths (c, d, n, and t or character-like structures) and cut off trailing blanks. Exceptions to this rule are explained in the affected statements. All blanks are generally kept for operands of the data type string.

A quick peek at the help for statement [authority-check|http://help.sap.com/abapdocu_70/en/ABAPAUTHORITY-CHECK.htm] doesn't show any exception to the rule. Due to lack of access to a SAP system I'm therefore assuming at the moment that it shouldn't matter whether you say '&nbsp;' or '&nbsp;&nbsp;' when using authorization checks.

I apologize for derailing this thread with some pretty irrelevant comment, but I've seen too many people being confused with ABAP literals. It's time for me to find out if I'm one of them...

Cheers, harald

[Former Member]

What I meant is that developers can code a lot of nonsense if they want to and turn the syntax checks off if they don't get their way

For example if you want to concatenate fields using strings in the stead of coding dependent authority-checks on sy-subrc values in a "base check" routine" which can be re-used. At first this might be tempting so that you can use conventions and wildcards in PFCG, but it toasts you when the field is blank...

My understanding is that the value checked for FIELD in field1 includes work area typing based on the ID. It certainly truncates the field to max 40 characters anyway and depending on the field type can align it to the left or the right and truncate further as well even if you send it longer strings.

But the use-case of SPACE (one character as blank field) is what I find suspect in any coding.

- You do not have to check all fields of the object in the authority-check, so you can ignore a field if no value is expected.

- If no value is found for the check to be performed against, then we can assume that the field selected must be optional - so the authority-check should be as well to optionally activate it. BEGRU is an example of this.

- If it is mandatory somewhere, but not yet known in the program flow then a DUMMY is the correct approach to take a look into the user's authorizations with a crystal ball to see whether there is something.

- If an empty field in the select is to be interpreted as "no access unless all access to SPACE" then it is best to replace the SPACE with a real string (like S_TABU_DIS does with '&NC&') and then check that value as a symbolic representative.

Hardcoding SPACE(s) is suspect and personally I do not see the use-case either for hardcoding SPACE in authority-check statements if their location is correct, let alone stringed SPACE's as an extention of such a workaround.

I have observed this in the HR area before, but it had a data model and coding technique of it's own back in 46C. They seemed to have cleaned up a lot now though and also use DUMMY constructs without the FIELD extention in the coding.

Cheers,

Julius

Edited by: Julius Bussche on Jun 12, 2010 9:20 PM

Syntax corrected and explanation tuned

[Former Member]

First of all: thanx all of you for your answers.

But my problem isn't solved yet. I said I'm at the beginning with the authorisation topics not an expert :). I'm not a developer and don't know how to develop an authority check only how it's generally built up ...

My Probem is:

I recorded a system trace (with SAP all user, return code always 0) and get some values that I don't know how to handle. For example (out of the trace):

object field

S_BTCH_JOB JOBGROUP=' ';JOBACTION=RELE;

F_KKKO_BUK ACTVT=03;BUKRS=*;

F_KKPY BEGRU= ;FBTCH=03;

S_DEVELOP DEVCLASS= ;OBJTYPE=DEBUG;OBJNAME= ;P_GROUP= ;ACTVT=03;

S_DEVELOP DEVCLASS=ZCD_MAHNUNG_DRUCKSTRASSE;OBJTYPE=SSFO;

OBJNAME=ZCD_DUNNING_0009;P_GROUP= ;ACTVT=03;

What I know is that the trace is used to record actions in transactions to create a authorisation profile. The trace records the values used by the actions and this is used to fill the values in the authorisation fields by transaction pfcg.

My problem is that I do not know what I shall fill in authorisation field JOBGROUP, because the trace says ''. Also I do not know how I shall handle Bield BUKRS=* (ok, that means all access, but the trace should concrete the value doesn't it?). Then BEGRU= . This is a blank field. What's the difference between ' '. And last: the first authorisation object S_DEVELOP has some blank fields recorded, the second specifies the field values. What does that mean?

I know you tried to explain, but the level was too high for me. Maybe you would try it again like you explain to a child :)?

Thanx to all,

Marcus

[sreekanth_sunkara]

Julius,

instead of ' ' value in roles can we also use other symbols like "?". currently i am using "?" in parent roles instead of "*" since i dont want any one to access anything with Parent role if they get access by mistake.

i think "?" wont give them any authorization, is that correct?

Thanks in Advance,

SS

Edited by: sun on Jun 15, 2010 5:18 PM

[Former Member]

Hi Julius,

As you said if we want to find explicit * value in field, we can do so by filtering out roles with object values as #* but what if I want roles which has access to a particular feild value only.

For example, I want to find roles which has got access to ONLY SU01 TCODE and not any other tcode, then how should I filter that in suim?

Regards,

Ritesh

[Former Member]

S_BTCH_JOB JOBGROUP=' ';  etc 

Field job_group is incorrect. The field is not used and expects a *.

See the documentation on S_BTCH_JOB in SU21.

Cheers,

Julius

[Former Member]

' ' stands for No Authorization.

If you want to test, create a test role and add object S_ADMI_FCD, this object has got one field as S_ADMI_FC, if you check for values for this field you can see the very first option as ' ' (No Authorization)