Re: Installing running applications as QSECOFR

[David Gibbs <david@xxxxxxxxxxxx>]

Joe Pluta wrote:
> (That is, when managing non-QSECOFR objects.  You would need to log on 
> with QSECOFR or a QSECOFR surrogate to manage QSECOFR-owned objects.  
> But for application objects, you wouldn't need QSECOFR rights.)

One last comment and then I'm going to let the thread die.

The issue is, if you're managing dozens (if not hundreds) of target 
environments (possibly on dozens of systems), all with (possibly) wildly 
differing authority models, the practicality of having to grant the user 
running the Implementer promotion process (or the user that Implementer 
adopts) the necessary authority to actually manage the authorities is 
just not there.

Letting the SCM product have, under secure & controlled conditions, the 
necessary authority to completely manage the security model is the most 
practical solution.

Again, we're talking about separation of duties (security managers vs. 
application managers, developers vs. QA vs. managers, etc).  I honestly 
don't think ANYONE could manage ALL the various authorities in a 
reasonable way.

This will be my last comment on the topic ... I've got to get a bite to 
eat before the iSocial / CUDS.

If anyone would like to pursue this topic further ... contact me 
privately and I'll be happy to.  I suspect I could even get a copy of 
our white  paper that describes Implementer's use of QSECOFR adopting 
programs.

david