From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Thursday, 17 July, 2014 2:14:21 PM Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final On 7/17/2014 8:55 AM, 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. > -1. I don't think learning a new configuration format for persistence.xml is user friendly. Users would have to translate the Hibernate documentation to our json format.

> > 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). > +1 > > 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. > +1. Do we have cycles to include in 1.0? > 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). +1. Do we have cycles to include in 1.0? \ -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Bruno Oliveira" <bruno(a)abstractj.org&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Thursday, 17 July, 2014 2:25:34 PM Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final Good morning Stian, Is the revocation of the refresh token[1][2] also planned? [1] - http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001950.html [2] - http://tools.ietf.org/html/rfc7009 On 2014-07-17, 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 -- abstractj

Good morning Stian, Is the revocation of the refresh token[1][2] also planned? [1] - http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001950.html [2] - http://tools.ietf.org/html/rfc7009

We would need peristence.xml just to list the entity-classes. Everything else would be configured through keycloak-server.json, and we could support both Hibernate property names and simpler Keycloak names. The nice thing about having a persistence.xml with just the entity-classes is that if someone is a Hibernate wizard they can just not specify anything in keycloak-server.json, and just configure it all through the persistence.xml BTW if we did this, do we even have to explode the auth-server.war in the dist? Templates are extracted to standalone/configuration/templates and configuration is done through standalone/configuration/keycloak-server.json. ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 17 July, 2014 2:30:18 PM > Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final > > > > On 7/17/2014 9:20 AM, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Thursday, 17 July, 2014 2:14:21 PM >>> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final >>> >>> >>> >>> On 7/17/2014 8:55 AM, 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. >>>> >>> -1. I don't think learning a new configuration format for >>> persistence.xml is user friendly. Users would have to translate the >>> Hibernate documentation to our json format. >> It would support both, configuration can either be done through >> persistence.xml or keycloak-server.json. We could use the same property >> names, so it would just be a matter of putting it in keycloak-server >> instead of properties in persistence.xml. >> >> Also, why do our users need to understand Hibernate/JPA just to be able to >> configure what data-source to use for Keycloak? >> > Actually, you're right. We wouldn't even need a persistence.xml file. > We wouldn't need even any JPA specific settings in keycloak-server.json > by default too, right? > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > 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 >

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > 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(a)redhat.com&gt; > >> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "keycloak dev" > >> <keycloak-dev(a)lists.jboss.org&gt; > >> 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 > >> > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev