4 Replies Latest reply on Jul 27, 2013 4:49 AM by Paul Seager-Smith

    Possible to connect custom approval system with BSA?

    Magnus Ruschpler

      Is is possible to use approval system in BSA without Remedy? What I need is a lock built in BSA that can prevent execution of not approved jobs. Similar like property SERVER.IS_DEPLOYABLE which prevents execution of BLPackage Deploy Jobs for any target where this property is set to false. Or can the approval system in BSA be enabled and used with Remedy only and nothing else?


      I just tested to set "APPROVAL_STATUS" to "Not approved" for a BLPackage Deploy Job but this alone did not prevent to job from being executed against a target. It would be ok for me to manage the required properties or commands in a script.

        • 2. Re: Possible to connect custom approval system with BSA?
          Paul Seager-Smith

          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.





          1 of 1 people found this helpful
          • 3. Re: Possible to connect custom approval system with BSA?
            Magnus Ruschpler

            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".

            • 4. Re: Possible to connect custom approval system with BSA?
              Paul Seager-Smith

              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.