[keycloak-dev] Storage protection

[Stian Thorgersen]

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 at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>
> Cc: keycloak-dev at 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 at abstractj.org>
> >> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen"
> >> <stian at redhat.com>
> >> Cc: keycloak-dev at 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/keycloak/server/KeycloakServerApplication.java
> >
> > 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 at 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
>