Getting HTTP 403 and CAUAJM_W_71021 errors when issuing a force start event in AEWS using POST

Products

• CA Workload Automation AE - Business Agents (AutoSys)
• CA Workload Automation AE - System Agent (AutoSys)
• CA Workload Automation AE - Scheduler (AutoSys)
• Workload Automation Agent
• Autosys Workload Automation

Issue/Introduction

When trying to issue a force start event to AE Web Services using the POST method, it fails with HTTP code 403.

Example:

# curl -X POST -H "Content-Type: application/json" -d @body.json  https://fqdn:9443/AEWS/event/force-start-job -k --user "<username>:<password>" -i
HTTP/1.1 403 
Content-Length: 0
Date: Thu, 19 Mar 2020 15:57:47 GMT

The $AUTOUSER/out/waae_webservices.log file also contains the following error:

2020-03-19 15:57:47,338 [https-jsse-nio-9443-exec-3] ERROR com.ca.waae.ws.EventResource - !CAUAJM_W_71021!
com.ca.waae.wsquery.WsQueryNotAuthorizedException: !CAUAJM_W_71021!

Environment

Release : 11.3.6

Component : CA Workload Automation AE (AutoSys)

Cause

The CAUAJM_W_71021 error in full is as follows:

CAUAJM_W_71021 "CAUAJM_W_71021 Sendevent Job Execute Access Denied!"
CAUAJM_W_71021 "Security policy denied access to resource."
CAUAJM_W_71021 "Contact security policy administrator."

This means the user that is executing the POST to AEWS does not have the following permissions in EEM under the WorkloadAutomationAE policies:

Resolution

Ensure the user, or a group the user is a member of, is granted permission to the as-owner policy as per this example:



A permission check should result in an allow as follows:



Once you'd done this, the user will be able to perform sendevents to AEWS using POST.

Additional Information

AEWS and AE are slightly different when it comes to treating as-owner policies.  Say, in the Access Policy Configuration section of this as-owner policy, the Resources listed are using wild card/regex , example:  root@hostname.*   (with Treat resource names as regular expression   option set to ON)

1) With the above type of setting, a user of root@hostname is able to do a send event to start/icejob etc,  fine via command line.
2) The same userid is used when a GET call is sent to AEWS, works.
3) The same userid is used when a POST call is sent to AEWS, does not work, 403 permission denied error (as described in this document)

If you do a permission check, that shows that everything is being Granted successfully too, using the same policy defined here.

This is because, AEWS prepends your autosys instance name in front of the resource name, as part of its as-owner  resource  value string, when its comparing for permissions in EEM.

So a resource name  root@hostname.*   would become <$AUTOSERV>.root@hostname.*   (example: ACE.root@hostname.*  

This can also be verified by checking EEM server's audit.log file for this, search for as-owner in that file around the times when you are doing your above tests

Regular autosys is not doing the permission check in the same way.  It does not prepend the $AUTOSERV in front. 

To get around this in AEWS, as well as not lose your existing permission policies in AE,  you need to change the resource name to:

.*root@hostname.* 

So, effectively, we are setting AEWS to be able to match $AUTOSERV.root@hostname.*  and AE is also able to match root@hostname.*

 

NOTE: also keep in mind that the resource names listed here are the names from the owner field of a given job.  those values are not the resources sending the GET/POST commands via AEWS, but the job owner.