Security / Tidal / Jobs and Groups - great subject Thomas.
I don't believe Cisco pushes the subject far enough.
Our implementation originally managed the tool as a centralized piece of software, where only a limited number of staff used the tool, and they used it everyday. We're now trying to invert that model and its roles, out to the true development staff and it's been 'trying' to prove the roles out to allow this to happen.
- Security-role templates are produced (out of the box) for user-id's and that's a start.
That's as far as Cisco goes with explaining the concept, (unless you want to read thru a zillion pages of elementary Tidal feature sets and then connect all of the dots to get what you need out of it)
But more importantly, Cisco should be leading the path for those customers where this software is their meat and potatoes and not sending people to their consulting group
- But how jobs and group memberships apply to Tidal jobs is a different thing and is the crux of your need (and mine)
- As part of Tidal's product deployment, if Cisco setup a full set of working jobs, triggers and common events, this would be the bread crumbs you and I seek. But they're not there.
- It all starts with who (or what) owns jobs, events, and actions (ownership of objects).
- Then builds on the who (or what) with groups and group memberships.
- A group can own jobs and events, and if your ID is a member of a group, you can do 'things' to the job and objects that group owns. At least I get that...
- The next question deals with - what you can actually do to the job object.
- Tidal setup a few base security profile/templates to start.
- If a Tidal ID is assigned one of those roles, I've been told that's as much as you can do to the job/event/action, but when you add doing X, Y & Z to an ID in a group (in a group membership) you should do nothing more than what is assigned to you in that group.
- The problem I've found (actually three issues) is when you are assigned a lower permission level to a set of jobs in a group, you should only be able to do X & Y, but not Z.
I've found that my none-superuser ID can have a high level of security assigned to it for a group then the base set of permissions for that user ID. Aka, the user should be only able to do X & Y but not Z, they can do Z.
Secondly, they can 'see' other groups of jobs that they shouldn't be a member of, which goes back to point #2.
I can't explain this one, what so ever, except that its sounding like either I've been told something incorrectly, or the group membership has a hole in its query/filter to allow other Tidal objects be viewed where they shouldn't be. Either better QA @ Cisco for the tool, or better communications of their design intentions. IDK...
My third beef, we place credentials in Tidal variables for sending to Tidal jobs in the parameter fields of Tidal jobs.
In the definition section, the variable value just shows up as <somevalue.name.49> instead of its real content. In the Job Activity section, if the job hasn't executed, those values don't appear, but once a job executes, the Tidal variables are plain as daylight to the Tidal user in the 'Override' tab of the job for that day.*
*-An easy patch to resolve that, might be to create a job property, that would say if checked "Don't show Tidal variables in the Job Activity section". If left unchecked, continue the current manner of exposing those values in the Job Activity 'Override' tab.
Good luck, but first, make double sure that ALL the ownerships line up, then go from there.
