Patterns in analysis authorization

Question

Dear experts,
We are on SAP BW 7.31 SP 8 using analysis authorization (AA).
First of all: I know of the limitations using patterns like * and + (Note 1053989).
Before we went to  AA we used complex patterns of * in an authorization infobject that was build by  4 subpatterns separated by an _.
ABC_*_DE_*. This was used as an authorization value in the form of "I CP  ABC_*_DE_*."
We used this in a customer exit fed to  a query by selecting the pattern above and expanding the string with the pattern to single strings filling up the subpatterns:
Example
ABC_*_DE_*   became:
ABC_01_DE_XYZ
ABC_09_DE_VGF
ABC_A1_DE_001
After migration, well, this was obvousily not working anymore (see Note above). So we have an explanantion but were STILL unsatisfied.
Why SAP allowed this BEFORE AA and went to a more restricted authorization checking now the allowed pattern (wich was not done before AA)?
I mean I something like *123 SHOULD be rejected , but the derived single strings (see example) by a customer logic should be allowed, because he KNOWS this  the valid authorization.
Know, dear experts, do you have an idea how this can be solved under AA?

Answer 1

Hi,
for my understanding you can implement an OR operation with assigning different roles to the user.
You define an authorization object for users who have to get auth value ABC_01_DE_XYZ.
You assign this auth object to a role "ABC_01_DE_XYZ". You define another role containing a new auth object with auth value "ABC_09_DE_VGF".
You assign this role alos to the user. So he is no authorized for "01_DE" or "09_DE".
I did  similar things with authorization exit variables. They have to take care that they return the correct pattern or authorized values.
In your case the authorization exit variable (which are normal Bex variables of type auth) have to return e.g. ABC_01_DE_XYZ and so on.
The new AA concept works for me much better and can be more finetuned than the old could ever be.
With authorization exit variables you can keep the concept even dynamically and reduce the number of roles. But this depends in detail on your exact requirements.
Regards,
Jürgen Noe