EEM and API Integration

[Richie Heaney]

​Hi there,

We have set up a new API user that will allow us to force start jobs through a new web API GUI that we have created. We have also implemented a couple of EEM policies, specifically we have added a new explicit grant on the as-group that will only allow our user to run jobs that have a group = ASI_JOBS or RISKJOBS. We had also added an explicit deny to the same user that stops any other job from running.

This was working great until we then decided to try and add in new policies to lock down owners to specific owners in our development environment. We switched off our default owner policy (under as-owner) and added in the specific owners we wanted. We did not add in our API user to this list and when we then try and run a POST command to force start our jobs, it comes back with a 403 forbidden error.

Does anyone have any ideas as to why implementing a new as-owner policy would stop the API user from running a POST command? Am I setting up the policies incorrectly or does anyone have ideas of how to set up these things.

Any help would be greatly appreciated. I have added screenshots to show the policy set up.

------------------------------
Cheers
Richie
------------------------------

Attachment(s)

API Testing Outcomes - 20200313.docx   502 KB 1 version

[Scott Fenton]

Hi Richie,

I'm not sure which version of EEM you're using but from the screenshots you've attached it looks to be a fairly recent one. I haven't caught all of the nuances of your environment but I think I can give you an idea of where to start...

In previous versions of EEM the as_owner policy did restrict use of the 'owner:' field... however a few EEMs ago a new control was added in as_owner policies to also control the use of sendevent in addition to the regular 'execute' control [which may or may not function in the way that you'd expect - there's some subtlety here].

My naive guess based on the above is that by removing the default as_owner policy you've restricted the ability to do sendevents to only the users listed in your new as_owner policy.  Have a look at the second column in the policy labeled "sendevent_jobexecute".  I think what you may be looking for is one policy that scopes on "execute" and a second policy that scopes on "sendevent_jobexecute".

All of that said I'm not 100% that the "execute" control is going to do what you're looking for.  I hope it does and good luck with your troubleshooting endeavors. Let us know what you find. I'm including below some text from the documentation explaining as_owner scope and linking to that section as well.  Hope this helps or at least point you in the right direction a bit.

Best,
Scott

The actions in the as-owner resource class controls user permissions as follows:

• EXECUTE

  Controls whether you can specify a different user as the owner of the job. Also, controls whether you can update, override, or delete any attribute of a job.

• SENDEVENT_JOBEXECUTE

  Controls whether you can execute the sendevent command.

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/intelligent-automation/workload-automation-ae-and-workload-control-center/11-3-6-SP7/securing/security-policy-customization/customize-security-policy-and-settings/customize-access-policy/ca-eem-resource-classes-for-ca-workload-automation-ae.html#concept.dita_bd97a9a5e16b37bc9caa44f5c4341472caf3fc17_asownerResourceClass

[Richie Heaney]

Hi Scott,

Thanks very much for the reply. It's certainly gave me some more things to think about with respect to the way to handle the "execute" and "sendevent_jobexecute" functions.

What we are trying to achieve here is to lock down the environment and to ensure there are only valid owners allowed in the owner attribute when inserting or updating JIL. We thought that by implementing a new as_owner policy, this would help us lock down that area. It has unfortunately had an adverse effect on our API user by not allowing it to fire off sendevent commands.

Regards
Richie​

------------------------------
Autosys Technical Lead
Aberdeen Standard Investments
------------------------------

[Richie Heaney]

Hi Scott,

Just to say that we looked into splitting out the policies as you had mentioned above and it worked brilliantly. I really appreciate the assistance as it pointed us in the right direction and resolved our issue.

Thanks
Richie​

------------------------------
Autosys Technical Lead
Aberdeen Standard Investments
------------------------------

[Scott Fenton]

Hi Richie - Glad to have helped but mostly glad that you've figure it out and have some policies that work for you.  :)

Thanks,
Scott

[Steve Carrobis]

typically the only thing with sendevent to turn off for users would be STOP_DEMON. I generally think job execute is enough. the as_owner is for what id can be in the owner field. and usually blacklisting certain IDs is enough. What i always wanted to be able to do was to say any id in this group is allowed to be in this field. I started working with eem team in another life, but then i was moved to a new client. It would still be a nice idea to be able to say the owner field can be in any id in this list (AD Group of the requestor)

[Scott Fenton]

Agreed Steve - That would be a big win.

I've personally found that as_owner doesn't quite work the way I would naively expect based on the wording in the docs. The ability to restrict root or autosys from running jobs is definitely key but from the language used I found some initial confusion around whether the policy controlled who can update the owner field or who can be put into the owner field.  Granted, this could just be my own reading and I could be entirely alone on this one.  :)

Thanks!

[Steve Carrobis]

Scott
The way i set it up is by AD group., But yes the only way as_owner works best is by blacklisting, for now.
you can limit the ids if you go with some sort of naming convention. or trust security only puts IDs on servers that need to be on them ;-)
Good luck,
stay healthy and safe..