My BSA version: 8.2 SP4
1 of 1 people found this helpful
You could use an RBAC-style promotion to handle this kind of approval mechanism. Whilst this is most often used with Depot objects, there is no reason that you cannot set the default ACL profile for a user to create jobs without the Execute permission.
The Approval user would then have the rights to promote the job and add the Execute permission.
You would need to do this with all the required job types, but it is certainly manageable if you have a structured RBAC management policy.
Thanks Paul, RBAC could be a solution. There is only one problem in the promote/demote model (version 8.2 SP4 and older): You cannot enforce users to use ACL Templates or ACL Policies only. They always have the option to add individual permissions ignoring any template or policy because there is no way to hide individual authorizations and show only policies or templates to the user. Even worse: They can add any authorization for any role to any object they have "ModifyACL" permission, e.g. they can add "Everyone <Object>.*"! I saw many objects in our environment having mixed up authorizations because of such "creative" users. The only known workaround to prevent this is to revoke *.ModifyACL from their role and do it for them using another role (e.g. script job with execution override), but this adds complexity for the end users (and the chance of more user mistakes) so we did not implement it. I created an RFE for that about about 7 months ago, but it's still in status "under consideration".
I tend to be a proponent of the somewhat more draconian RBAC model and would push for removing the modifyACL permission, especially if people treat it as an adhoc facility like this.
Keeping RBAC under control is always a challenge in more complex environments with many roles. In my opinion, it needs to be tightly controlled to ensure that you can replicate the RBAC model across environments as well. One of the most common problems I have seen is where the RBAC models in Dev / QA / Prod doe not match and suddenly something that worked fine in Dev and QA fails in Prod even though all the package and job content is the same. To keep it tightly controlled, RBAC changes should only be made through specific roles and/or on specific objects per role. I do like the idea of enforcing only ACL templates and policies though as this would definitely help to ensure a more controlled RBAC model.
Sorry, something of a digression to your original question, but an important point in my view!
I do still think RBAC is the best way to go. Otherwise, you might have to provide certain users with another UI and this UI would manage the approvers before using the BSA web services or command line to actually perform the deployments. This is not really an ideal solution though.