Wild card "*" usage in the authorization role

[Former Member]

Hi All,

I am an ABAP consultant(not a security pro, so please put up with any incorrect wordings), and working on a requirement where i need to check if the user has access to particular values entered on a screen field. For example if the text entered on the field is ABCDEFGUS, i want to check on the last two characters to see if user has access to enter values ending with US.

So i create an authorization object...etc, and in the role i enter US as the value, but now when i run through the code using AUTHORITY-CHECK against the authority object. The authorization passes for all the values i enter, ex: ABCDEFGUK* - this should have failed as i have maintained *US.

Note: but when i maintain the value as ???????US in the role, it works as expected.

All the help and pointers, towards this would be appreciated.

Regards,

Chen

[Former Member]

Hi Chen,

You can maintain it as *US which doesn't restrict on the length of the value. However, if you enter with ? marks, it takes the specific characters. What is the issue when you give *US?

Rgds,

Raghu

[Former Member]

Hi Raghu,

When i maintain *US in the role anything that ends with US must only pass the check, i expect(or atleast think) that when a user enters HHHHHHHUK, the authority check should fail as the last two characters are not US? But it doesn't, the authority check passes.

Regards,

Chen

[Former Member]

Hi,

Then the issue is with the code. Debug it to identify the root cause. *US should work as expected. Is the authorization object which you have used is a custom object?

Rgds,

Raghu

[Former Member]

Raghu,

Yes it is a custom Authority object, and i have debugged the code the value is being passed as entered on the screen to the Authority-check statement.

Note: Should it matter if i do not have any activities defined in the Auth Object.

Regards,

Chen

[Former Member]

Hi,

I don't think it looks for the activity. Lets make a trail and error. Try including ACTVT with 03.

Rgds,

Raghu

[Former Member]

The authority-check is not the same as a search help, as the value is already known and the system needs to go looking for the first authorization field value which satifies it for that object.

Therefore, you can wildcard a prefix (e.g. US*) but you cannot mask a suffix (e.g. *US or *US*).

As the authorization field starts with a *, the check is successfull and sy-subrc is set to 0. It does not matter what you maintain after the *.

Cheers,

Julius

[martin_voros]

Hi,

as Julius wrote the authorization check is bit different and it won't work as you need. Everything after first occurrence of * is ignored. As a workaround you can always replace * with #. So you will maintain value like #US in your roles and just before authorization check you will amend string. I would suggest to write a simple function module as a wrapper and use it for authorization check.

Cheers

[Former Member]

So you will maintain value like #US in your roles and just before authorization check you will amend string.

Hi Martin,

Have you ever tried this and used it in production?

Changing the value sent to the AUTHORITY-CHECK is easy but very intrusive to the data in the program which might be used else where.

Changing the value at runtime which the AUTHORITY-CHECK expects to find is a different ball game (also in performance).

I have done some experimental stuff with this in sandboxes using STATICS in a wrapper for fixed lengths but cannot recommend it at all. I cannot see it ever flying in an AUTHORITY-CHECK statement construct.

It is also completely unauditable to any authorization analysis tool...

Hang on a second... if SPRO can do this then we can as well --> I think we have a winner here!

Cheers,

Julius

[martin_voros]

No, I haven't. It was just an idea and I didn't think too much about it. I agree that it's not compatible with any tool which is big disadvantage. I though about FM which would take value, copy it into local variable and perform some changes such as replacing * with # and then calling standard authorization object. But it has also some limitations. For example if you maintain #US and #AUS then you can just simple check for #S because authorization check will fail. Overall, workaround with too many disadvantages.

But I doubt that value pre-processing have any measurable impact on performance. Everything is memory and usually, DB is bottle neck.

Cheers

[Former Member]

or just use custom table..

maintain users and values they are authorized to.......

not good idea............ just my 2 cents