Turning up logging for the IdP data sealer

[Cantor, Scott]

On 10/26/20, 3:27 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    By "artificially assign its own local name", no. My keytool call uses -alias to make the alias correspond with the value
> version from AWS secrets manager, and that's definitely there. In fact, the one IdP is finding a key in its data sealer store
> to use for encrypting the data sealer. The other node is also finding the key with that same alias, but it's got a different
> value. Is that what you mean by local name, or were you referring to something else?

That's what I meant. AWS needs to assign the name and then that has to be consistently used to mean the same key.

>    It then goes on to give me the -importkeystore syntax for doing that. I'm happy to try suppressing that warning and
> going with it if it'll help. But the question remains: if two different containers are both running keytool -importpass with
> the same input string and same alias, should they be able to both use the generated keystores to encrypt and decrypt one
> anothers' encrypted cookies?

The IdP utility calls the Keystore APIs directly to add new keys (setKeyEntry), it doesn't use the command line. So I have no idea whether any command line approach works or not. Since you're asking as a paying member, I can take a look at the keytool source and see if I can map the options to the code it's using.

-- Scott