cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
754
Views
5
Helpful
10
Replies

Permissions to workflows in a category

STOps9487
Level 1
Level 1

Is there a way to allow permissions to all workflows in a category?

Giving permissions to a category does not seem to do this. I assume it just allows permission to modify the category itself.

           

What I would like to do is allow permission to any workflows in a category, so if new workflows are added to the category, users are automatically given access to the workflow if they have permissions on the category.

Is this possible?

1 Accepted Solution

Accepted Solutions

You are correct, it is not possible today to grant permissions to all processes in a category in an easy step.

It has been requested before, but hasn't made it into a release yet and is not currently on the roadmap.

There are 3 types of security permissions that Orchestrator has today, for creating "Roles":

- Object List is the most straigtforward one. You can explicitly add/remove processes to the list for which you want to grant permissions. It is straightforward, but also the least dynamic. So you would have to remember to add/remove to the security role as you create/delete processes

- Object Type is very dynamic, but it is also very broad. You can use it to grant permissions to **all** objects of a specific type

- Owner Security is dynamic and could give you what you want, but it still requires paying some attention how you create and manage your objects.

You could try Owner Security  to give you what you want.

- Create a security group (any group would do), let's say group A.

- Set Owner field to group A in all objects (processes, targets, categories, whatever), to which you want to grant permissions to.

- Now create a Security Role and add Owner Security Permission to that role, whose owner field is also set to group A.

Choose object types/operations that you want to give permissions over. Now you can assign this role to other people.

This role will be dynamic: meaning that as you create new objects and set their Owner field to group A, the users who are assigned to the role will automatically get the permissions over those objects.

If you decide to go that route, you can also utilize a little know option in the UI, that allows the user to set the default value for the Owner field in the newly created objects (check Security tab under Tools | Options menu item).

Also, keep in mind that the default security Roles grant full control to "owners" of objects. So if you want to avoid that, you might want to keep the security group empty or modify the default roles.

Hope this helps.

View solution in original post

10 Replies 10

Shaun Roberts
Cisco Employee
Cisco Employee

Hi! I believe that is right. I have not done a ton with the security but if I remember from a couple of cases I worked, if you want to section off "groups" in one server you need to do it an the automation pack level. Create an automation pack for each group and then only give them access to their specific automation pack object and you should be able to "block" one from another.

Now when you would create a new process I assume others could see it until it's put into the automation pack. I have never personally run a setup like this but I believe a few customers have.

Security groups are going to chance a bit in 3.0 as well so just be aware of that If you need more info, I suggest a TAC case.

--shaun

--Shaun Roberts
Principal Engineer, CX
shaurobe@cisco.com

You are correct, it is not possible today to grant permissions to all processes in a category in an easy step.

It has been requested before, but hasn't made it into a release yet and is not currently on the roadmap.

There are 3 types of security permissions that Orchestrator has today, for creating "Roles":

- Object List is the most straigtforward one. You can explicitly add/remove processes to the list for which you want to grant permissions. It is straightforward, but also the least dynamic. So you would have to remember to add/remove to the security role as you create/delete processes

- Object Type is very dynamic, but it is also very broad. You can use it to grant permissions to **all** objects of a specific type

- Owner Security is dynamic and could give you what you want, but it still requires paying some attention how you create and manage your objects.

You could try Owner Security  to give you what you want.

- Create a security group (any group would do), let's say group A.

- Set Owner field to group A in all objects (processes, targets, categories, whatever), to which you want to grant permissions to.

- Now create a Security Role and add Owner Security Permission to that role, whose owner field is also set to group A.

Choose object types/operations that you want to give permissions over. Now you can assign this role to other people.

This role will be dynamic: meaning that as you create new objects and set their Owner field to group A, the users who are assigned to the role will automatically get the permissions over those objects.

If you decide to go that route, you can also utilize a little know option in the UI, that allows the user to set the default value for the Owner field in the newly created objects (check Security tab under Tools | Options menu item).

Also, keep in mind that the default security Roles grant full control to "owners" of objects. So if you want to avoid that, you might want to keep the security group empty or modify the default roles.

Hope this helps.

Thanks - very strange that this is not on the roadmap.

I really thought this would be something that people would use often. Create a new workflow, and add it to a category. Job done.

Rather than having to set security on every workflow. It just seems like a logical way to design.

Yes, this has been advocated for several releases, but has always been nudged out by other higher priorities.

STOps9487
Level 1
Level 1

So is there anything we can do to add some more weight to this option for a future release?

To get anything added open a TAC case with the enh request and use case clearly defined. Give it a priority and how soon you'd like to see it, etc. The TAC engineer will then right up an ENH for the BU and get it on their slate. I'd mention this thread in the TAC case as well as a look back.

--Shaun Roberts
Principal Engineer, CX
shaurobe@cisco.com

Thanks Chris - I'll do that shortly.

Just seeing the word TAC depresses me. It's such a painful process to go through, and I have twice tried to submit one for the issue of CPO talking to HP iLO consoles and both seem to have gone into some kind of limbo.

      

Edit: TAC created... not so painful this time around. The new request method is much nicer.

I'm sorry you've had issues in the past! Hopefully things get better. I used to work on the TAC team so if you have specific case issues or case numbers I still have connections to that team so I can get some messages back.

On the HP iLO I know we've had some issues through the terminal adapter working with it and there was already a bug or two opened on them. (opened via internal Advanced Services people). I'm not sure of their status as the bug system is down for me, but we are aware of them.

If there is anything you would like to see improve with the TAC process (after this time and after reviewing all of your times), please shoot me an email directly and I'll pass it along.

--Shaun

shaurobe@cisco.com

--Shaun Roberts
Principal Engineer, CX
shaurobe@cisco.com

I am the TAC manager for CPO and sorry to hear that you had a bad experience with your two past TAC cases. Can you tell me what the past two TAC case numbers were so I can understand what went wrong? I am glad that opening a case this time around was an improvement. If you ever have an issue in the future please contact me at spaladug@cisco.com and I will look into how we can help you further.

--

Sri Paladugu

spaladug@cisco.com

Hi Sri,

I think I only ever had an issue with one submission. After digging further, I found the other one in closed cases, so I think it's all good.

The new TAC interface is much nicer to use.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: