Turning up logging for the IdP data sealer

[Wessel, Keith]

I was kind of afraid that this might be the issue.

I'm quite confident that the key alias is the same in both running IdP instances, and I'm quite sure that the string being passed in (the actual key) is the same. So, your comments about the value being salted and resulting in different output seems to be a logical conclusion.

Amazon does have some code in beta for a new data sealer key retrieval strategy that will do this cleanly and will eliminate the need for my cron job or loading anything into a keystore. The problem is it's distributed as source all under part of an AWS-specific IdP deployment that uses some AWS technologyes that we're not using, and I haven't had time to pick through their code yet to pull out the pieces I need and build a jar to add to the IdP. But that seems like the next logical step if I want to do this right.

While a command-line option to supply the new key on the command-line might be useful to some, it would just be used by me short term. So, I see no reason for you to do that work for me.

My other option is to write my own small Java utility that would take the string passed in on the command line and add it as a keyentry. Between the code in the IdP for your utility and the samples on the net, this is doable. I'll just have to decide if this is worth it or if I want to focus my energy on implementing Amazon's solution.

Thanks for confirming my suspicions, Scott.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Monday, October 26, 2020 3:40 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Turning up logging for the IdP data sealer

So, --importpass appears to me to be doing PBE, password-based encryption. It's treating the input as a password. If I were to guess, that might be salting, probably randomly. Pulling that back out as a byte array might give you different salted bytes on different servers if it's randomly salting.

The input here is certainly not a password and I doubt that doing that is really the right thing to do.

I don't think there is a way to import a key from the command line using keytool.

If you're going to indirect things, I think you really have to do what I said needed to be done from day one, this has to be a different KeyStrategy that isn't using a keystore.

I don't personally think all this is warranted, but I don't see any sort of middle ground. I think probably if you were to try to make me solve this, I would do it by adding an option to support encoded input to the existing command line program I created and use that to allow importing a known key rather than it generating the key like it does now.

-- Scott


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net