Dynamic authorizations using customer exit

[Former Member]

Hi experts,

We have a requirement where in user access level for cost centers changes very frequently. This access details are maintained in a Z table. And this Z table will be maintained by the super user/lead user.

Now users should be restricted to only those cost centers that are maintained in the table in ALL TRANSACTIONS.

Is there any customer exit/ other approach available which can be applied here.

Any inputs are highly appreciated.

Thanks,

Asrar

[Former Member]

I've done this a couple of different ways. If I was to do it again I would look at a solution which uses the standard auth concept but dynamically maps appropriate roles to users based on the input logic (in your case a custom table).

[Former Member]

Hello Alex,

It would be great if you please share the details of your solutions towards this.

Thanks,

Asrar

[Former Member]

Hi,

I'm happy to answer any specific questions but I'm not going to detail full solutions for commercial reasons.

Dynamically passing in auth values into the CO programs is tricky and you will spend a lot of time and money on it. If you go down this route then you must be very strict about which transactions are in scope and many modifications will need to be made to the supporting code.

A method which appends a role to a user is attractive as it does not require any changes to the underlying functional programs. It is not without it's limitations, especially around the number of roles which can be assigned to a user (312) but you can design around that when assessing your potential usage scenario's.

[Former Member]

A more realistic and less intrusive approach is to generate roles for all levels in the standard hierarchy and then watch for changes in a batch job which adapts and generates the new ones. If you are lucky, the hierarchy is being maintained in DEV and transported...

Then give the person whom you wanted to maintain the table access to PFCG and let them only assign these generated roles - so you will need a naming convention for them.

Works like a charm and adapts itself as the hierarchy changes. Automatically generating roles is a bit tricky but still much safer than modiying central check functions.

Cheers,

Julius

[Former Member]

I remembered you mentioned something like that before but couldn't remember any more of the details!

[Former Member]

Completely lost

Nevermind - I'll hopefully pick this up one day..

Cheers

David

[Former Member]

It sounds more complex that it is! Once you have the process worked out it's usually just a bit coding that needs to be done.

Julius' approach (automating the build of roles which represent new nodes on the standard hierarchy) is a bit more involved than a basic automated allocation tool but has significant time savings once implemented.

[Former Member]

Hi guys.. any other approach you can think of..

i think dynamic role asignment suggested by Alex makes it a break-through. Can i have some more details how to do this?

[Former Member]

Can you first tell us whether you are using the old k_repo_cca concept or the new k_cca concept via the standard hierarchy for all the actvt (now co_actions of the same object).

This makes a big difference....

Cheers,

Julius

Edited by: Julius Bussche on Jul 21, 2011 11:27 PM

[Former Member]

We have a requirement where in user access level for cost centers changes very frequently. This access details are maintained in a Z table. And this Z table will be maintained by the super user/lead user.
Now users should be restricted to only those cost centers that are maintained in the table in ALL TRANSACTIONS.

Identify the tcodes that uses cost centers and create custom transaction codes and make them read your Z table for the values.

Also, as highlighted by Julius. If the new concept is used, Cost center is a org field where it would be tough to read the values from a Z table.

Regards,

Raghu