We are starting to use AE Web Services (AEWS) and currently have the userid and password being passed as authentication with EEM for access to the AE information.
What we would like to know is how (or where it is documented) to create a certificate that we can place on the client system (the one making the web services request) such that they present the certificate that then is accepted by AEWS and authenticated by EEM. This means that the users of the webservices would not need to know the user or password that is being used to get the AE data via the AEWS interface.
Here is what we tried to do initially...
On the AEWS server, export the certificate information, which creates a cert.cer file containing the certificate for the AEWS Tomcat application. You will be asked for the keystore password. Enter changeit
keytool -export -alias tomcat -file /tmp/cert.cer -keystore /opt/CA/WorkloadAutomationAE/autouser.$AUTOSERV/webserver/conf/.keystore
You will need to make the applicable path changes for your environment - to the .keystore located under the AEWS
then import into the keystore on the machine running your REST Client.
but we ended up coding the REST Client to accept all requests (which is dangerous), but it is (REST Client) limited to our env and the Webservices and the client are secured so they cant be accessed from anywhere else except where we want to allow it from.
You would still need to pass the username and password to authenticate with EEM. I don't think there's a way around that, but if you know of a way, do let me know.
As we use scripts (mixture of perl & java depending on the application needing the information) we currently have to put userid/password into the script. This has been completely rejected by the latest security audit and we need to move to at least munged passwords but more properly user certificate (so that not even the recipient of the certificate needs to know even the user (let alone the password) being used for authentication.
The next step is to then centrally manage the certificates (their creation/update/revocation) via security rather than the end-user.
We have already added the AEWS hosts to our "certified" domain, ie they already have certificate chains to our root certificate (just like the WCC servers) so the AWES is trusted by the client just as the browser trusts our WCC servers. Which basically covers the server trust that you are establishing with your process.
It seems from the lack of other comments that I need to take this up directly with CA support.
did you use the https autosys jobtype? you may get it done that way ..