We have what is effectively an API broker or proxy tool between our Appian instance and an API we consume. The broker/proxy requires API Authentication to properly identify our system and allow access to the API's that it brokers. It does not however leverage it's own API keys to the services it represents. As a result, we have to pass a second API key through as a header.However, I have security concerns about the storage and security of this second key.
Has anyone had experience and advice to secure this secondary key? It appears as clear text in the request headers, must be available in the integration or connected system (unlike the primary API key - which is masked and unreadable in the Connected System), and I cannot use the secure credential store to secure it. Even if I store it in a constant, I'm concerned about the potential security.
Advice greatly appreciated.
Discussion posts and replies are publicly visible
Any header in HTTP is clear text, that is why we use SSL to encrypt the transport.
The encryption functions plugin can encrypt and decrypt strings using a static key stored in the secure credential store. So, you could put the encrypted API key into a constant and decrypt it on demand using that static key. That would at least increase the effort to get the access to the API key.
That's an approach that I've hashed out with others. We've also gone back to the architects of this network configuration with some questions. My main concern here is that some escalation of privilege attack on an Appian environment could necessarily then have an escalation on another system. The advantage of encrypting the local constant based key is that it puts the vulnerable key in the admin console, which I like. It does however feel clunky. I'd rather the underlying architecture owned this problem.
Thanks for your response!