Support auto-loading appropriate ims context based on program id mapping

[kwin]

Currently only one Adobe IO JWT can be stored inside the aio config (because only the key jwt-auth) is used. For working with multiple accounts in parallel it would be beneficial if multiple JWT authentication configs could be stored in parallel and bound to specific Cloud Manager Program ID. Maybe supporting a key config naming scheme like jwt-auth.<program-id> would be sufficient. If no such key is found, the fallback could be the key jwt-auth.

[justinedelson]

@kwin this is an interesting idea, but it seems like the workflow is already available in the aio-cli-plugin-config/aio-lib-core-config where you have a different config per directory. Does that not work for you? In other words, you'd do

$ cd accountA
$ aio config:set --local ...
$ cd ../accountB
$ aio config:set --local ...

And then

$ cd accountA
$ aio cloudmanager:list-programs
[programs for accountA]

$ cd accountB
$ aio cloudmanager:list-programs
[programs for accountB]

[kwin]

@justinedelson Thanks for that hint, I wasn't aware of that option. I have two concerns with that option

1. It will distribute sensitive information on the hard disk as it won't encrypt the values. I opened https://github.com/adobe/aio-lib-core-config/issues/52 for this.
2. There is no recursive fallback to the local config of the parent directory (i.e. it only works in exactly that directory but not any subdirectories, https://github.com/adobe/aio-lib-core-config/blob/3d1dedc0f8d59e2d220d2d99ad298d0413595bb2/src/Config.js#L43)

In any case I think it would be good to extend the readme a bit in https://github.com/adobe/aio-cli-plugin-cloudmanager#authentication to clarify that by default only one JWT is stored and what the options are to store multiple ones.

[justinedelson]

FYI @kwin I have taken this as a sign to go ahead and update the migration to @adobe/aio-lib-ims. I've been avoiding this because it is a breaking change (in an edge case, but still...) and supporting this use case would make migration impractical. I still have a bit of manual testing of the migration process to do before merging #130. But once that is merged you will be able to create N number of non-default ims contexts (see https://github.com/adobe/aio-lib-ims#configuration) and specify one of those by passing --imsContextName=<non-default context>

[kwin]

This is a nice improvement. Still I would like to have a mapping from imsContextName to programId built int aio-cli-plugin-cloudmanager . That way you only have to establish the mapping once, and there is no need to pass the imsContextName to every command. Either one can use a naming convention for imsContextName or maintain a (persisted) mapping table.

[justinedelson]

OK. I've updated the title of this issue. I'm not fully sure I understand the workflow you are envisioning here so I would encourage you to submit a pull request.