Release : 11.3.6
Component : CA Workload Automation AE (AutoSys)
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:
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.