I think it does doesn't it?
If using a HSM you'd have to pass the algorithm to use as well so that it can sign it
using the expected algorithm. So it would be:
public byte[] sign(byte[] b, String algorithm);
The interface definitively needs more thinking about ;)
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "Bruno Oliveira"
<bruno(a)abstractj.org>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 30 January, 2014 2:00:33 PM
Subject: Re: [keycloak-dev] Storage protection
I don't think this relates, but just in case...tokens need to be signed
by a known algorithm so clients are able to verify them.
On 1/30/2014 8:51 AM, Stian Thorgersen wrote:
> BTW the interface I proposed wouldn't work with a HSM, they do the
> encryption/decryption on board don't they? So it would be something like:
>
> public EncryptionProvider {
>
> public void generateKeys(RealmModel realm);
>
> public byte[] encrypt(byte[] b);
>
> public byte[] decrypt(byte[] b);
>
> public byte[] sign(byte[] b);
>
> }
>
> or something along those lines ;)
>
> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno(a)abstractj.org>
>> To: "Bill Burke" <bburke(a)redhat.com>, "Stian
Thorgersen"
>> <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Thursday, 30 January, 2014 1:22:35 PM
>> Subject: Re: [keycloak-dev] Storage protection
>>
>> I think that’s just fine, where developers will store their private keys
>> is
>> their decision: db, text file or fancy hardwares.
>>
>> My only suggestion is to generate these keys with some KDF function, maybe
>> during the first application setup? What do you have in mind Stian?
>> command
>> line, web interface, integrate with jboss-cli?
>
> First app startup I'd say. OOTB experience should be as simple as possible.
> Probably just bootstrap it in:
>
https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org...
>
> and set the location to ${jboss.config.dir}/keycloak.secret or something?
>
>>
>> --
>> abstractj
>>
>> On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian(a)redhat.com)
>> wrote:
>>>> We should do it as an SPI to make it extensible. This would allow
>>> admins to integrate it best into how they manage sensitive data.
>>> I don't know what common practices are, but I imagine there are
>>> many ways to do it.
>>>
>>> As I said before I think our options OOTB are either to just store
>>> in clear-text, or generate a master password and write to a known
>>> location (/standalone/data/realm.secret?).
>>> Anything more than that would make it hard to use for development.
>>>
>>> I believe it is safer store a master password in a file (and an
>>> additional
>>> layer of defence to storing in clear-text to RDBMS, which can
>>> be compromised through SQL-injection attacks that non-shared
>>> file systems are not prone to).
>>>
>>> The master password location can be configurable through a system
>>> property. Admins can place this file on an encrypted location,
>>> this would be recommended. I don't think its any better to provide
>>> the master password as a argument or system property at startup
>>> than it is to store it in a file on an encrypted drive. The reason
>>> being is that if someone gains admin access to the server, they
>>> will be able to read the file, sure, but they can also get the arguments
>>> used to start the server just as easily. If the server is turned
>>> of neither properties or an encrypted drive will help them. Admins
>>> already have mechanisms in place to manage encrypted drives
>>> on servers, so we'd rely on them to know how to do that themselves.
>>>
>>> For future and more improved solutions we can add whatever mechanisms
>>> users are asking for through the SPI. Enterprises can also implement
>>> their own.
>>>
>>> The SPI could be something as simple as:
>>>
>>> public interface PrivateKeyProvider {
>>> public PEM getPrivateKey(RealmModel realm);
>>> }
>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com