How is your security table configured?

[tberry6433]

We are having an internal debate. To date we have had a single security table in production covering PD, PY and DV. When new objects are promoted to PY we add security so users can test. When the object is promoted to PD security is already in place. Our CNC is proposing a separate security table for PY, adding a step to promote security with the object. He thinks this is a safer method. What do you do?

 

[Sebastian Sajaroff]

Hi,

I have a couple of accounts which separated security per
environment (one F00950 for DV, another for PY and
another for PD). It works pretty good.
We usually leave DV wide open (everyone can do everything),
while PY F00950 is regularly copied from PD to emulate
user environment as much as possible.

 

[Jeff_MontAssoc]

Most of my clients use different roles for PD. I have PYDEV access in lower environments, PDDEV in production with different security on each role. As I am sure you know, roles can be set by environment.

 

[rgreensl]

Hi Jim,
To clarify we have 2 x security tables and assoc LF's. We run a qmqry to update the security on live with the tested security on PY. We put the PY f00950 in the OL library and then we OCM map it to PY.
It has proven reliable for us over the past 8 years and we plan to do something similar on 8.12. The problem with the standard installation is you have just one security table and therefore can't test security changes before making them live.
hope this helps,
Rich

 

[JakeR]

One table - security is complex enough. I use a test account and assign the updated test Roles to that account to test in Production. Then we get one volunteer from a division to test using the test account. Has worked extremely well for me.

 

[altquark]

I would tend to agree. Manage a single table with all security across environments - but create alternate "testing" user ID's for analysts so they can test with the correct security /roles without providing access to production.

 

[jjanowski]

If you have a dedicated security administrator (Segregated out from CNC administrator) AND you have specific SOX requirements, 2 (or more) tables can be effective control/mitigation. Caution is advised when managing/maintaining a complex security configuration.

my 2 cents…