RFE: Define field for CyberArk AIM lookup

[DonaldKallman]

ISSUE TYPE

• Feature Idea

SUMMARY

Allow the user to define the field in the JSON response to be used for the username and password values. This is a unique scenario to object types that do not map to the standard Content and UserName fields (like a cloud service). For example, I want the value of Content for the password and the value of AWSAccessKeyID as the username from the below:

{
  "Content": "****************************************",
  "Name": "Cloud Service-svc-cyberark-np1",
  "CreationMethod": "PVWA",
  "SequenceID": "1",
  "LastTask": "VerifyTask",
  "CPMStatus": "success",
  "Folder": "Root",
  "Safe": "Ansible_Tower_Test",
  "LastSuccessVerification": "1579694399",
  "AWSAccessKeyID": "AKIA****************",
  "DeviceType": "Cloud Service",
  "RetriesCount": "-1",
  "LastSuccessChange": "1579558784",
  "UserName": "svc-cyberark",
  "PasswordChangeInProcess": "False"
}

[kylecurtis-od]

I believe this has to do with the tower config not handling two different credential types from the cyberark side.
In the scenario where the credential in the cyberark safe is, "Device Type: Operating System", making a call to the cyberkark 'password' api endpoint will work fine. However, if you make that same call to the cyberark api, and you want a cyberark stored account that is of the device type, "Cloud Service", that is different. There cyberark stores the AWS ACCESS KEY ID into the field, "AWSAccessKeyID". A an api call to that endpoint for a cred of that type, does return the json mentioned above, but tower isn't mapping it back properly so you can use it in an ansible tower AWS Credential type.

[jakemcdermott]

🤦‍♂️ Actually, I see what you mean now. You're referring to this field: https://github.com/ansible/awx/blob/devel/awx/main/credential_plugins/aim.py#L100, which we use to get the secret string.

[jakemcdermott]

@DonaldKallman @kylecurtis-od This idea sounds very reasonable and a great way to improve the plugin. Thank you for suggesting it. It could be done by adding an optional field to the plugin, like you suggest. The default value for the field would need to remain as Content (for backwards compatibility).

Such a change is unlikely to be on our schedule in the near term. That said, if you open a PR for this I'd be more than happy to review it and work with you to get it merged.

[DonaldKallman]

@jakemcdermott Apparently it's not as easy as anticipated and I am admittedly not great with Python. Changing "return res.json()['Content']" to "return res.json()['AWSAccessKeyID']" still brought the value from Content over for both username and password. I don't see anywhere else that is reading the value from the json response.

[DonaldKallman]

I actually don't see how this could work for any credentials unless the only field you want to retrieve is the password. Probably makes sense for 95% of use cases.

[infamousjoeg]

#13411