[keycloak-dev] Additional things to consider for 1.0.final

[Bruno Oliveira]

Late for the discussion, but +1 about the SPI. What if the key on
keycloak-server was a public key for encryption? And the private key for
decryption stays on protected hard drive, TPM or whatever? Is that the
idea?

On 2014-07-18, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, 18 July, 2014 10:03:38 AM
> > Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> >
> > On 18.7.2014 10:25, Stian Thorgersen wrote:
> > > 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.
> > Not sure about prompt, but master key in keycloak-server.json should
> > work well and won't be a pain in cluster as long as all cluster nodes
> > have same value in keycloak-server.json? Only thing is that if we add
> > some default value into keycloak-server.json, then probably 99% of
> > people won't change it:-)
>
> We'd have to generate it on the first startup. I guess in a cluster people would have to sync keycloak-server.json between all nodes in either case.
>
> >
> > But it's better than nothing IMO as people at least have possibility to
> > change the master key if they want better security .
> >
> > Maybe best is to have SPI with encrypt/decrypt methods, which adds best
> > flexibility for people (default implementation will just encrypt/decrypt
> > with master key from keycloak-server.json)?
>
> Yep, we may even want to support hardware security modules, which would require some form of an SPI for encryption/decryption. IMO that's not for this round though.
>
> >
> > Marek
> > >
> > > ----- Original Message -----
> > >> From: "Marek Posolda" <mposolda at redhat.com>
> > >> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> > >> <keycloak-dev at 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 at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914