Splitting security by environment

[bwr2006]

We would like to split our security between environments. Right now we are either thinking about making a second copy of the security table or creating separate roles for environments. I was wondering what the pros and cons would be for either one.

 

[jjanowski]

Hands down best way…
2 F00950 tables. 1 for Production and 1 for Non-Production(every other nonprod environment points to this data source) in your landscape.

Pros - Way too many to list…
Cons - Security needs to be maintained twice unless you build a custom promotion set of objects. (you then start looking like SAP)

 

[bwr2006]

Thanks for the reply!

 

[TheDruid]

Dont forget to change the OCM's once you have copied the tables.

 

[Luke Phillips]

This is a big question and depends what you want to do - I wouldnt necessarily agree 2 tables always make sense.

The main pro of 2 tables is that you can change *PUBLIC. So, if your objective is to close your system than this is easier with 2 tables unless you have a tool like ALLOut in which case 2 tables is optional.

From a maintenace point of view obviously having security in 2 environments is extra work - however the fact that you can sychronise security abd finecut is an added bonus.

I would suggest that you view our products via a webinar or trial which help support 2 tables. If you prefer a purely technical chat - avoding all the sales - then feel free to contact me directly.

 

[jjanowski]

PS don’t try to change other security tables F95921, F0092, etc. Bootstrap tables CANNOT be OCM mapped. Keep it simple.

 

[peterbruce]

Have a look at Thread 160117.