<div dir="ltr">Sorry if my e-mail gave to you a wrong impression. I was just asking about the interface to generate the secret.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 11:51 AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
public EncryptionProvider {<br>
<br>
public void generateKeys(RealmModel realm);<br>
<br>
public byte[] encrypt(byte[] b);<br>
<br>
public byte[] decrypt(byte[] b);<br>
<br>
public byte[] sign(byte[] b);<br>
<br>
}<br>
<br>
or something along those lines ;)<br>
<div class="im"><br>
----- Original Message -----<br>
> From: "Bruno Oliveira" <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>><br>
> To: "Bill Burke" <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>, "Stian Thorgersen" <<a href="mailto:stian@redhat.com">stian@redhat.com</a>><br>
> Cc: <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> Sent: Thursday, 30 January, 2014 1:22:35 PM<br>
> Subject: Re: [keycloak-dev] Storage protection<br>
><br>
</div><div class="im">> I think that’s just fine, where developers will store their private keys is<br>
> their decision: db, text file or fancy hardwares.<br>
><br>
> My only suggestion is to generate these keys with some KDF function, maybe<br>
> during the first application setup? What do you have in mind Stian? command<br>
> line, web interface, integrate with jboss-cli?<br>
<br>
</div>First app startup I'd say. OOTB experience should be as simple as possible. Probably just bootstrap it in: <a href="https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java" target="_blank">https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java</a><br>
<br>
and set the location to ${jboss.config.dir}/keycloak.secret or something?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> --<br>
> abstractj<br>
><br>
> On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (<a href="mailto:stian@redhat.com">stian@redhat.com</a>) wrote:<br>
> > > We should do it as an SPI to make it extensible. This would allow<br>
> > admins to integrate it best into how they manage sensitive data.<br>
> > I don't know what common practices are, but I imagine there are<br>
> > many ways to do it.<br>
> ><br>
> > As I said before I think our options OOTB are either to just store<br>
> > in clear-text, or generate a master password and write to a known<br>
> > location (/standalone/data/realm.secret?).<br>
> > Anything more than that would make it hard to use for development.<br>
> ><br>
> > I believe it is safer store a master password in a file (and an additional<br>
> > layer of defence to storing in clear-text to RDBMS, which can<br>
> > be compromised through SQL-injection attacks that non-shared<br>
> > file systems are not prone to).<br>
> ><br>
> > The master password location can be configurable through a system<br>
> > property. Admins can place this file on an encrypted location,<br>
> > this would be recommended. I don't think its any better to provide<br>
> > the master password as a argument or system property at startup<br>
> > than it is to store it in a file on an encrypted drive. The reason<br>
> > being is that if someone gains admin access to the server, they<br>
> > will be able to read the file, sure, but they can also get the arguments<br>
> > used to start the server just as easily. If the server is turned<br>
> > of neither properties or an encrypted drive will help them. Admins<br>
> > already have mechanisms in place to manage encrypted drives<br>
> > on servers, so we'd rely on them to know how to do that themselves.<br>
> ><br>
> > For future and more improved solutions we can add whatever mechanisms<br>
> > users are asking for through the SPI. Enterprises can also implement<br>
> > their own.<br>
> ><br>
> > The SPI could be something as simple as:<br>
> ><br>
> > public interface PrivateKeyProvider {<br>
> > public PEM getPrivateKey(RealmModel realm);<br>
> > }<br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-- <br>"The measure of a man is what he does with power" - Plato<br>-<br>@abstractj<br>-<br>Volenti Nihil Difficile
</div>