BIG DISCLAIMER: The connectors provided on this page are only for educational purposes, and are not supported by RSA.
It's all about Privileged Accounts. Identify the Privileged Accounts, make sure they are not exposed to the bad guys.
Where are they? Some of them are hiding hardcoded in source code or configuration files. That is the first target to zap in all organizations.
What is the next step? Databases? Are there any databases(or directories which are also databases) in the organization that contains one or more Privileged Accounts? Well, how about that Identity Management/Provisioning product? Isn't it the biggest nest of such Privileged Accounts in the corporate jungle? Sounds like a big ball of risk, right?
What can be done about Privileged Accounts stored in the IdM/IAM product? A first step would be at a minimum to rotate the passwords, so people who have left the organization cannot successfully guess the passwords one or 2 years from now. How about we zap the passwords like we did for source code and config files? What would be required?
CyberArk and other Privileged Account Management vendors have introduced the concept of password vaulting, initially to eliminate those passwords in source code and config files. Basically, an application that needs to connect to another application using a Privileged Account will fetch the password in memory from Password Vault and use it to establish the connection, without ever committing the password to its database or configuration. Each connection may be established using a different password. The application will be authenticated using various factors(machine ID, OS login, certificate, etc) in order to be able to retrieve password at runtime.
Now if we apply this strategy to an Identity Management solution, here is how it looks:
Two approaches can be considered:
1- Modify the Identity Management solution to provide a global framework for all connectors to be able to consume either the local database or a common module that calls the Password Vault to obtain credentials;
2- Modify each individual connector so they can either use the local database or fetch credentials from Password Vault.
While the first approach may sound like the best approach, it would force existing Identity Management products to be re-designed, which may take some time for most vendors to deliver.
The 2nd approach sounds like a good tactical approach, and offers a quick solution with redesign limited to individual connectors. Higher risk connectors could be targeted first.
Now comes AFX. AFX provides a few things that actually makes it very easy to adapt to meet the bill:
1- A somewhat easy to use SDK for building new connectors, Java Code Based connector;
2- Capabilities, which are readily consumable by other components(Business Sources, Workflows).
So the idea is to enable each capability that we need in a new connector, using Java Code Based, unit test the capabilities, and then turn the connector to active and follow the typical configuration steps.
So I decided to take a shot at it, even if I am not a real developer. Once we have enough examples for each type of capabilities and target applications(LDAP, Database, SOAP/REST, Java API, etc) copy and paste becomes the name of the game. Building a demo environment with multiple connectors allow for articulating the Use Case and Value, while also providing a way to evaluate the effort involved, which is less than what I thought it would be originally, thanks to the Java Code Based connector and AFX Capabilities.
Of course, the connectors we can build with Java Code Based are not standard connectors, so from a supportability perspective, we need a different strategy, but they do look a lot like standard connectors once they work, and one can export/import them between environments like standard connectors.
The following is work in progress, but within a few days I was able to come up with a good list of working connectors, some of which already features most capabilities we would need in a real deployment, and others can be easily extended with Copy & Paste.
First, we need a working CyberArk vault and a Safe where we can manage AFX Passwords.
I will not get into the details for the CyberArk installation and configuration, but that is the first step. You also need to install and configure Credential Provider and the client must be installed and configured on the AFX server. See CyberArk document: Credential Provider and ASCP Implementation Guide.pdf
Then we can take a quick look at the connectors I have working so far.
Active Directory connector, password is replaced by Safe and Object information.
N.B. I initially tried to use JNDI but ran into some limitations and switched to unboundid.
Capabilities already included are createAccount, deleteAccount, resetPassword, addAccountToGroup, removeAccountFromGroup, enableAccount, disableAccount, updateAccount and moveAccount.
Oracle connector is based on sample connector included with Java Code Based sample connector.
Capabilities right now are limited to one for testing but Oracle application specific SQL can be added to source code easily for each capability. I will investigate other options to make it more generic.
Test capability in source code:
@Override
public JCBCStatus disableAccount(Map<String, String> settings, Map<String, Object> params) throws Exception {
String username = (String) params.get("UserName");
String query = String.format("INSERT INTO AVUSER.A_TEST_TABLE(USERNAME) values('Username = "+username+"')");
executeQuery(settings, query);
return JCBCStatus.success();
}
-----------
For the database connectors, you may run into an issue when you try to upload the jar files. I had to copy them under the AFX app on the server and touch mule-config.xml to restart the connector(without redeploying the files, which deletes the app folder).
For the SAP connector, like the Active Directory, it includes most needed capabilities. I basically just vault enable my earlier SAP connector: https://community.rsa.com/community/products/governance-and-lifecycle/blog/2016/06/15/new-sap-afx-connector-javacodebased-tutorial
The ServiceNow connector is more an example of a Web Services(REST, SOAP) connector that can be used for both on-prem and cloud apps. For now, it is configured to create Request Items for manual provisioning.
ServiceNow capabilities for remote provisioning: createAccount, deleteAccount, enableAccount, disableAccount.
The IMG connector is pointing back to L&G and illustrates how curl can be used to quickly build a Web Services based connector by scripting curl script in capability. It is actually going through 3 steps:
1- Retrieve password from vault using command line CyberArk SDK client;
2- Use credentials to obtain a session token from L&G;
3- Pass session token to REST call to add account to application role.
While this type of connector is less secure, potentially exposing the password in log files, it offers a quick a dirty approach, which could be considered secure if the password rotation frequency is high enough, etc. I wanted to include it as an alternative to the java based httpclient example.
A few things to keep in mind:
1- Java Code Based connector does not allow for uploading files that are not jar. You may need to copy to app folder and touch mule-config.xml to restart connector(without a re-deploy). E.g. for SAP, you need to copy libsapjco3.so everytime you redeploy the connector;
2- A jar is a renamed zip. If you modify the source and re-compile, you will need to upload new jar, then delete the original one. If the editor is showing a Java error after the delete, just click ok and ignore;
3- jar files created with Java Code Based include source code (.java) and a script for compiling. I typically use notepad to edit source code and I compile on L&G server so I have the right java version for the connectors;
4- I will be updating this blog with more connectors, but I wanted to provide an example of each(LDAP, Web Services, Database, JAVA API, command line) to get those who want to explore started.
