01-09-2014 04:47 AM
We use SAS 9.2 TS2M3 and DI Studio 4.2M2.
Our metadata security model does not allow the SAS developers to make direct changes to DI jobs in the Foundation repository, forcing the developers to check-in/check-out their jobs via project repositories. But a user needs write permission to the Foundation job in order to deploy the code. If the developers were granted this permission it would result in all manner of issues including deleted jobs and loss of audit trail as the project repositories could be bypassed.
Currently only the 'techincal lead' & admin users have write permission on the jobs folders in order to deploy jobs. Its a pain - has anyone found a workable way to allow jobs to be deployed from Foundation without opening a massive security hole?
01-09-2014 07:24 AM
I agree, this is a bit painful. The same goes for other object that sometimes ETL-developer needs to be involved, such as database servers, schemas, Cubes, Information Maps etc.
One way to handle this is to "open up" specific folders for write access for this user group, so that deployed jobs are stored somewhere else in the folders than the originating job.
01-09-2014 07:33 AM
True, although we have workable processes to take care of most of the other BI objects.
We also took the approach to seperate the job from the deployed job objects as you've mentioned. Yet it seems write permission is still needed on the job object itself when deploying code, which is the big security issue.
01-09-2014 08:10 AM
That is correct, forgotten that.
What we did at one site is having a separate userid for each developer for deploying jobs. This would at least preventing most incidental changes of jobs. I presume that your develeoprs are honest people and intend to follow development guidelines?
01-09-2014 08:23 AM
They are a fine bunch of SAS developers. All the same, I would prefer the security model to do the work. Thanks for the suggestion LinusH.
05-09-2017 02:53 AM