3:25 a.m.
Last we didn't do it because of the potential headache for admins to deal with it,
especially in a cloud environment.
I wonder if it would make sense to always encrypt in the database with a master key for
the server. The master key could then be specified in keycloak-server.json. If users need
the additional security they could make sure keycloak-server.json (as well as
standalone.xml which has the ssl certificate keys) are stored on an encrypted drive. If
not stored in keycloak-server.json the user would have to specify it when starting the
server, which would have to be done by a prompt I think. Specifying it as an environment
variable or system properties is not very safe as that can just as easily be read by an
intruder as a file. This would make life a bit harder in a cluster though.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "keycloak dev"
<keycloak-dev(a)lists.jboss.org>
Sent: Thursday, 17 July, 2014 6:42:13 PM
Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
One thing, which we discussed before was encoding of privateKey before
saving to DB? As currently if someone "steal" database record with
privateKey, he is able to create encoded accessTokens and send requests
to bearer-only applications.
Or is this still planned for August?
Marek
On 17.7.2014 14:55, Stian Thorgersen wrote:
> As we didn't have enough things to do last minute I come up with more
> things which I think we should do for 1.0.final:
>
> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>
> This would be super simple to do, and would let us have a single
> persistence.xml for everything (testsuite, server, project-integrations).
> Everything worthy of configuring in persistence.xml (including datasource)
> can be passed in the Map overrides when creating the EntityManagerFactory.
>
>
> 2. Introduce server-dependencies-min and server-dependencies-all poms
>
> We have a few places that includes all the dependencies required (server,
> testsuite/integration and testsuite/) as well as other project such as
> AeroGear and LiveOak. Instead of everyone having to list all the
> dependencies they could have a single dependency on either
> server-dependencies-min or server-dependencies-all. Min would exclude most
> if not all provider implementations (such as PicketLink/LDAP, social
> providers, etc).
>
>
> 3. TOTP SPI
>
> At the moment we only support Google Authenticator, I don't think that's
> sufficient. We should at the very least add support for one more, and have
> an SPI so users can add their own. I think this would be related to the
> UserProvider sync work, as some UserProvider implementations may require
> both a password and totp to verify a users credentials, while others would
> only be able to verify the password and then have Keycloak verify the
> totp.
>
> Also, do we need to support users with more than one totp? Personally I
> have two for work (one I use daily and another for backup).
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev