[keycloak-dev] Storage protection

[Stian Thorgersen]

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 (<keycloak>/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);
}

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 27 January, 2014 4:34:45 PM
> Subject: Re: [keycloak-dev] Storage protection
> 
> 
> 
> On 1/27/2014 11:30 AM, Anil Saldhana wrote:
> > But for development purposes, a DB may not be available as the default
> > mechanism.  In the case of WildFly AS, I am unsure if they ship with a
> > default DB
> > anymore.
> 
> Wildfly still has a DB, and we use it by default.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>