User Access restrictions in Automic

[Shravan Shetty]

Hi All,

We are facing a issue in Automic where users can see and modify jobs through process monitoring, despite being restricted from accessing it from process assembly (Folder level).

Any solutions or insights would be greatly appreciated!

Regards,

Shravan Shetty 

[Daryl Brown]

What are the Authorizations that these users have?

I'm seeing the same basic thing from my testing -- they won't be able to navigate to the object through explorer or find it via search, but if they can "find" the object via a process monitoring screen, they will be able to open it.

Presumably if you remove the user's 'write' authorization to JOBS objects (or these particular ones, at least), they won't be able to edit them.

I don't know if there's an easy way to block access from all objects that live within a particular folder...  (You would think blocking access to the folder would achieve this, but it evidently doesn't work that way.)  

You may need to look into object-level authorizations?

[Markus Embacher]

Hi,

in Automic everything is an object. A folder is an object too. If you deny a user to read a folder he will not be able to see what is in the folder. But the permissions apply to the folder only and not to the objects in the folder (like in Windows). Please see also the following note:

https://docs.automic.com/documentation/webhelp/english/AA/24.2/DOCU/24.2/Automic%20Automation%20Guides/Content/AWA/AdministrationPerspective/AG_DefiningAuthorizationSystem.htm#link6

Regards, Markus

[Shravan Shetty]

Hi Markus,

Thank you for your response! is there a way to implement user restriction for accessing object in process monitoring? Setting restrictions for individual jobs is time consuming and impractical given the thousand of jobs we manage.

Regards,

Shravan Shetty

[Markus Embacher]

Hi Shravan,

permissions are given based on object names. We recommend having strict naming conventions, that allow you to define the permissions accordingly. 

An example:

<business_unit>.<application>.<jobname>

HR.PAYROLL.PAYMENTS

Then you can define for example an HR.OPERATIONS USRG object to allow only certain users R/W/C/S/P authorizations.

Regards, Markus

[Silent Swallow]

Hi Markus,

Thanks for the clarification! The idea of using strict naming conventions for defining permissions makes a lot of sense, especially with the example you provided. It seems like it would really help streamline the process and ensure the right access is granted to the appropriate users.

Just to confirm, when setting up these naming conventions, do you recommend including any specific identifiers or prefixes for easier management, especially in larger systems?

Thanks again for your insights! 

[Markus Embacher]

Hi,

I recommend aligning the naming conventions with the structure of your organization or your customer. You can consider

Legal entities
Departments
Business Units
Teams
Applications
etc.

I can only provide examples:

<legal entity>.<competency>.<application>.<jobname>     BROADCOM.BACKUP.ORACLE.DAILY
<legal entity>.<department>.<team>.<object type>.<name/unique ID> XY.OP.BACKUP.WF.BU000021
<business unit>.<team>.<object type>.<name> HR.PAYROLL.SCRI.BANK_TRANSFER
<object type>.<business unix>.<environment>.<application>.<name> WF.DWH.PDWH.CORE.COLLATERALS

In my opinion including the object type is not required but many prefer to have it included in the object name. 

It makes also sense to have the folder structure aligned with the naming conventions.

Regards, Markus