Encrypt Akamai API credentials so they are not stored in plain text

@Cameron Tod,
can we move the password storage to the settings.php instead of configuration ?
That way we can access it via Settings final class.
can we also show a warning on the status page i.e. hook_requirements if site is on http protocol.

It seems rather heavy handed to mandate the use of Field Encrypt (especially since their D8 is beta and their D7 is largely unsupported). What's the approach you have in mind for this?

When the issue has come up previously (see #2569845: Store akamai password encrypted for example), there have been some efforts at it but the consensus of users was that we needed Akamai to implement an API-key style authentication rather than username and password structures.

I am glad to see Akamai finally being active in regards to the module, though.

The credentials for the new OPEN versions of the API (including the one that you need to use for the fast invalidate) use the OPEN authentication mechanism, not a user/password. As with OAuth there are 4 pieces of information needed to make a successful call:
1) Hostname (different for each credential set)
2) Client token
3) Client secret
4) Access token

On a standard server setup, these are stored in an INI configuration file in the ~/.edgerc directory.

The edgegrid-php library uses these credentials appropriately. Davey Shafik is working on a similar Wordpress plugin which will do the same thing.

Thanks,
Kirsten

Given the difficulty of securing encryption keys for encrypted data, I think the best option is to allow the following mechanisms (which is my goal for WordPress also):

1. Point to local .edgerc file and INI section
2. Upload .edgerc file and store locally, and specify INI section. Require TLS.
3. Use environment variables, specifically the following four elements:
   • AKAMAI_EDGEGRID_HOST
   • AKAMAI_EDGEGRID_CLIENT_TOKEN
   • AKAMAI_EDGEGRID_CLIENT_SECRET
   • AKAMAI_EDGEGRID_ACCESS_TOKEN
   • These environment variables should be set by whatever deployment tools are being used, as is common practice these days.

I think standardizing on this mechanism across multiple projects will be great for everyone.

@Cameron Tod

The API credentials should be treated the same as login credentials, see my previous comment on my recommendations for handling this.

Thanks,

I feel like the solution should be to provide the ability to use the drupal.org/project/key module that is built to do exactly this type of thing. It is built so users can choose what storage method they'd like to store key, including the ability to store offsite using HSM etc.

At the very least this needs to be rerolled, but I'd be interested in testing out the Key module integration here as well.

Here is a proof of concept using the key module. Still need to figure out what to do from a testing perspective, but it at least shows what it would take to use the key module.

It is worth noting this issue with the key module: #2980072: Encrypt key value

We should probably help push that issue along as well.

Here is an updated patch that helps facilitate some of the optional dependency injection.

I haven't started to address any of the test failures yet.

This patch takes the test out for the database method as we've removed it. I haven't added tests for the key integration yet. That probably should exist as either a Functional or Kernel test.

Wow ignore that last patch. I had a rebase glitch there. Let's try that again.

I believe this will resolve the remaining test errors. It required a bit of reworking of the AkamaiAuthentication class to inject the messenger and key repository services into them.

Based on feedback during ContributionWeekend2019:

1. +++ b/src/AkamaiAuthentication.php
   @@ -36,18 +41,37 @@ class AkamaiAuthentication extends Authentication {
   +      }
   

   What about else here?

2. +++ b/src/Form/ConfigForm.php
   @@ -55,11 +63,19 @@ class ConfigForm extends ConfigFormBase {
   +    }
   

   Instead of doing all this, let's create a custom service that can handle the optional service and the variety of options (e.g. edgerc or key module)

This patch contains a new akamai.key_provider service which acts as a wrapper around the key module's key.repository service. It's not exactly what was suggested in #29.2, as the .edgerc handling is handled by the external akamai libraries, so I limited the scope of what I focused on to just creating a wrapper around the key.repository. In regard to #29.1, we don't actually need to worry about this case as $auth is just empty, but all the functionality fails gracefully already.

Consolidating multiple commits from #30

Switching to composer-based test dependencies instead of info file.

Reviewed and discussed at 2019 Austin Contribution Weekend. Removing the built-in config store and allowing users to instead use they key module to protect API keys seems like a good compromise approach. Latest patch LGTM.