ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

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

book

Article ID: 187058

calendar_today

Updated On:

Products

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

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!

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:


Environment

Release : 11.3.6

Component : CA Workload Automation AE (AutoSys)

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:  [email protected]*   (with Treat resource names as regular expression   option set to ON)


1) With the above type of setting, a user of [email protected] 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  [email protected]*   would become <$AUTOSERV>[email protected]*   (example: [email protected]*  

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:

.*[email protected]

So, effectively, we are setting AEWS to be able to match [email protected]*  and AE is also able to match [email protected]*



 

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.

Attachments