From alecl at alecl.com Wed May 2 13:54:35 2018 From: alecl at alecl.com (Alec Lazarescu) Date: Wed, 2 May 2018 13:54:35 -0400 Subject: [keycloak-dev] Better supported methods for active/active relational db clusters? Message-ID: I was hoping to start a conversation on what's the best path forward to get maintainable support for active/active db's that have schema restrictions that are not upheld historically by Keycloak's schema and Liquibase based setup. How best can we make often minor schema adjustments in a maintainable fashion going forward? Perhaps a method to choose on install/upgrade between fully backwards compatible migrations vs the migration style that supports active/active? The Keycloak docs mention Oracle RAC and MySQL Galera for example https://www.keycloak.org/docs/latest/server_installation/index.html#database and I saw a PR for Postgres-BDR that was rejected due to understandable migration concerns for existing installs: https://issues.jboss.org/browse/KEYCLOAK-5769 For Reference: MariaDB Galera limitations Postres-BDR limitations Thanks! Alec From sthorger at redhat.com Wed May 2 13:56:21 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 May 2018 19:56:21 +0200 Subject: [keycloak-dev] Keycloak 4.0.0.Beta2 released Message-ID: To download the release go to the Keycloak homepage . Highlights Pushed Claims With pushed claims it is now possible for clients to push additional claims to have them used by policies when evaluating permissions. Resource Attributes It is now possible to define attributes on resources in order to have them used by policies when evaluating permissions. Spring Boot 2 support We now have support for Spring Boot 2. Instagram identity provider Thanks to hguerrero it is now easy to enable login with Instagram. Slovak translation Thanks to Joe32 we now have Slovak translations. More... The full list of resolved issues is available in JIRA . Upgrading Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed. From eivind at jotta.no Thu May 3 07:29:45 2018 From: eivind at jotta.no (Eivind Larsen) Date: Thu, 3 May 2018 07:29:45 -0400 Subject: [keycloak-dev] Client Registration and performance Message-ID: Hi Keycloak Devs! Posted this on keycloak-user but didn?t get any response, so trying here. We are planning on using the Client Registration flow for setting up clients on login. This is mainly to more clearly identify each individual device a user has logged in with. Are there anyone using this feature in production with a large number of clients? With our current stats, we would probably end up with a million clients by the end of the year. 1. Will this scale well with the way Keycloak works? 2. If a user loses their device, how should a full revoke & logout be performed? ? ?I could not find an easy way to find all users? sessions via the API, nor all clients. 3. Is there an alternative approach to give each user more control over their device and session? Thanks, Eivind Larsen From gambol99 at gmail.com Thu May 3 09:17:03 2018 From: gambol99 at gmail.com (gambol) Date: Thu, 3 May 2018 14:17:03 +0100 Subject: [keycloak-dev] Availability During Upgrades Message-ID: Hiya I was wondering if anyone has any recommendation in regard to high-availability during upgrades? or how people are handling service availability during a service update? Where as before we had leeway for the occasional midnight 30 downtime, as more projects on-aboard this is soon reaching the point where scheduled downtime unless an absolute emergency isn't acceptable. Rohith From bburke at redhat.com Thu May 3 09:42:43 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 3 May 2018 09:42:43 -0400 Subject: [keycloak-dev] Availability During Upgrades In-Reply-To: References: Message-ID: We had a recent Sprint to investigate rolling upgrades. This was investigation only. I believe we have some plans for this down the road, but it isn't something we support at the moment. From what I remember, I believe that its more a matter of process and testing. Process being to make sure that db schema changes and user session serialization is backward compatible. Testing to ensure and verify the process. Marek and Hynek might be able to give you more info. On Thu, May 3, 2018 at 9:17 AM, gambol wrote: > Hiya > > I was wondering if anyone has any recommendation in regard to > high-availability during upgrades? or how people are handling service > availability during a service update? Where as before we had leeway for > the occasional midnight 30 downtime, as more projects on-aboard this is > soon reaching the point where scheduled downtime unless an absolute > emergency isn't acceptable. > > Rohith > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From quynhnhat.nguyen at gmail.com Thu May 3 18:19:46 2018 From: quynhnhat.nguyen at gmail.com (Quynh Nhat Nguyen) Date: Thu, 3 May 2018 15:19:46 -0700 Subject: [keycloak-dev] Keycloak Admin API createUser/updateUser improvement Message-ID: Hi, I notice that the Keycloak Admin API createUser/updateUser does not consider the 'realmRoles' and 'groups' in the payload. Is there any reason for ignoring these data or simply a feature missing? Is it possible to request an improvement for this, and/or submit a PR on this? Best regards, From adesbiaux at vente-privee.com Fri May 4 04:11:18 2018 From: adesbiaux at vente-privee.com (Adrien DESBIAUX) Date: Fri, 4 May 2018 08:11:18 +0000 Subject: [keycloak-dev] Redis cluster instead of Infinispan Message-ID: Hello all! What would be the effort required in order to add a Redis connector in place of the classic Infinispan? Wildfly would have to be updated as well as Keycloak? Indeed we found out Infinispan extremely difficult to setup and the documentation very complex to digest. Also being able to plug a Redis cluster would speed up the Keycloak adoption. What is your opinion on this topic? Thank you in advance for sharing your thoughts. Cheers, From Thomas.Dupont at UGent.be Fri May 4 08:20:14 2018 From: Thomas.Dupont at UGent.be (Thomas Dupont (UGent-imec)) Date: Fri, 4 May 2018 12:20:14 +0000 Subject: [keycloak-dev] Adding a custom protocolmapper Message-ID: Hi, Is it at all possible to implement a custom protocolmapper that is deployable via /opt/jboss/keycloak/standalone/deployements ? If my class only implements ProtocolMapper, it works, but if it extends AbstractOIDCProtocolMapper (which in itself implements ProtocolMapper), my keycloak throws NoClassDefFound errors. This happens on both 4.0.0-beta1 and 4.0.0-beta2. Thanks, Thomas -- ir. Thomas Dupont Ghent University - imec IDLab, Office 200.010, 10th floor iGent Tower - Department of Information Technology Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium T: +32 9 33 14900 E: thomas.dupont at ugent.be W: idlab.ugent.be From adesbiaux at vente-privee.com Mon May 7 07:47:03 2018 From: adesbiaux at vente-privee.com (Adrien DESBIAUX) Date: Mon, 7 May 2018 11:47:03 +0000 Subject: [keycloak-dev] Error loading KeycloakHotRodMarshallerFactory Message-ID: Hello, I am facing an issue in regards to launching Keycloak 3.4 in Domain mode with an external Infinispan cluster. I following error is thrown: Caused by: java.lang.ClassNotFoundException: org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory from [Module "org.wildfly.clustering.service" from local module loader @7a0ac6e3 (finder: local module finder @71be98f5 (roots: /opt/jboss/keycloak-3.4.3.Final/modules,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/keycloak,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/base))] I don't get this error when using the standalone-ha mode. Did you test the Multi datacenter configurationh with the domain mode already? https://www.keycloak.org/docs/latest/server_installation/index.html#_domain-mode Guide Overview - Keycloak www.keycloak.org The purpose of this guide is to walk through the steps that need to be completed prior to booting up the Keycloak server for the first time. If you just want to test drive Keycloak, it pretty much runs out of the box with its own embedded and local-only database. Why would be the class KeycloakHotRodMarshallerFactory not correctly loaded in domain mode? I will keep searching but would be happy if some of you would have time to share their opinion on this. Thank you in advance for your direction. From mposolda at redhat.com Mon May 7 12:29:12 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 May 2018 18:29:12 +0200 Subject: [keycloak-dev] Error loading KeycloakHotRodMarshallerFactory In-Reply-To: References: Message-ID: <39419bd0-3d55-bd3e-0ae2-68d1f1d87ca5@redhat.com> Hi, did you added |module="org.keycloak.keycloak-model-infinispan" to the cache-container element? Thanks, Marek| Dne 7.5.2018 v 13:47 Adrien DESBIAUX napsal(a): > Hello, > > > I am facing an issue in regards to launching Keycloak 3.4 in Domain mode with an external Infinispan cluster. > > > I following error is thrown: > > > Caused by: java.lang.ClassNotFoundException: > org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory from > [Module "org.wildfly.clustering.service" from local module loader @7a0ac6e3 > (finder: local module finder @71be98f5 (roots: > /opt/jboss/keycloak-3.4.3.Final/modules,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/keycloak,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/base))] > > > > I don't get this error when using the standalone-ha mode. > > > Did you test the Multi datacenter configurationh with the domain mode already? > > https://www.keycloak.org/docs/latest/server_installation/index.html#_domain-mode > > Guide Overview - Keycloak > www.keycloak.org > The purpose of this guide is to walk through the steps that need to be completed prior to booting up the Keycloak server for the first time. If you just want to test drive Keycloak, it pretty much runs out of the box with its own embedded and local-only database. > > > Why would be the class KeycloakHotRodMarshallerFactory not correctly loaded in domain mode? > > I will keep searching but would be happy if some of you would have time to share their opinion on this. > > > > Thank you in advance for your direction. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon May 7 12:34:50 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 May 2018 18:34:50 +0200 Subject: [keycloak-dev] Redis cluster instead of Infinispan In-Reply-To: References: Message-ID: Hi, in theory you can do it, but you will need to override some providers (user session provider, caching providers) to use redis instead of infinispan. It may be fair amount of work. I don't think we have a plan to replace infinispan with the Redis and support it OOTB. One thing is to develop the Redis support, but another is maintenance, which is even more difficult. Especially considering that we need to care about backwards compatibility and support for rolling-upgrades in the future... What kinds of issues you had in infinispan? Are there some concrete issues you saw? Marek Dne 4.5.2018 v 10:11 Adrien DESBIAUX napsal(a): > Hello all! > > > What would be the effort required in order to add a Redis connector in place of the classic Infinispan? > > Wildfly would have to be updated as well as Keycloak? > > > > Indeed we found out Infinispan extremely difficult to setup and the documentation very complex to digest. > > > Also being able to plug a Redis cluster would speed up the Keycloak adoption. > > > What is your opinion on this topic? > > > Thank you in advance for sharing your thoughts. > > > Cheers, > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon May 7 12:34:56 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 May 2018 18:34:56 +0200 Subject: [keycloak-dev] Redis cluster instead of Infinispan In-Reply-To: References: Message-ID: <71f5bfed-cff9-b95a-81ac-357c744de7a2@redhat.com> Hi, in theory you can do it, but you will need to override some providers (user session provider, caching providers) to use redis instead of infinispan. It may be fair amount of work. I don't think we have a plan to replace infinispan with the Redis and support it OOTB. One thing is to develop the Redis support, but another is maintenance, which is even more difficult. Especially considering that we need to care about backwards compatibility and support for rolling-upgrades in the future... What kinds of issues you had in infinispan? Are there some concrete issues you saw? Marek Dne 4.5.2018 v 10:11 Adrien DESBIAUX napsal(a): > Hello all! > > > What would be the effort required in order to add a Redis connector in place of the classic Infinispan? > > Wildfly would have to be updated as well as Keycloak? > > > > Indeed we found out Infinispan extremely difficult to setup and the documentation very complex to digest. > > > Also being able to plug a Redis cluster would speed up the Keycloak adoption. > > > What is your opinion on this topic? > > > Thank you in advance for sharing your thoughts. > > > Cheers, > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From adesbiaux at vente-privee.com Mon May 7 15:45:56 2018 From: adesbiaux at vente-privee.com (Adrien DESBIAUX) Date: Mon, 7 May 2018 19:45:56 +0000 Subject: [keycloak-dev] Error loading KeycloakHotRodMarshallerFactory In-Reply-To: <39419bd0-3d55-bd3e-0ae2-68d1f1d87ca5@redhat.com> References: , <39419bd0-3d55-bd3e-0ae2-68d1f1d87ca5@redhat.com> Message-ID: Hi Marek, Many thanks for your reply. Yes, I did add it. I followed the documentation. The HA mode looks like not throwing the error. However Domain mode does not go through successfully. Cheers, ________________________________ From: Marek Posolda Sent: Monday, May 7, 2018 6:29:12 PM To: Adrien DESBIAUX; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Error loading KeycloakHotRodMarshallerFactory Hi, did you added module="org.keycloak.keycloak-model-infinispan" to the cache-container element? Thanks, Marek Dne 7.5.2018 v 13:47 Adrien DESBIAUX napsal(a): Hello, I am facing an issue in regards to launching Keycloak 3.4 in Domain mode with an external Infinispan cluster. I following error is thrown: Caused by: java.lang.ClassNotFoundException: org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory from [Module "org.wildfly.clustering.service" from local module loader @7a0ac6e3 (finder: local module finder @71be98f5 (roots: /opt/jboss/keycloak-3.4.3.Final/modules,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/keycloak,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/base))] I don't get this error when using the standalone-ha mode. Did you test the Multi datacenter configurationh with the domain mode already? https://www.keycloak.org/docs/latest/server_installation/index.html#_domain-mode Guide Overview - Keycloak www.keycloak.org The purpose of this guide is to walk through the steps that need to be completed prior to booting up the Keycloak server for the first time. If you just want to test drive Keycloak, it pretty much runs out of the box with its own embedded and local-only database. Why would be the class KeycloakHotRodMarshallerFactory not correctly loaded in domain mode? I will keep searching but would be happy if some of you would have time to share their opinion on this. Thank you in advance for your direction. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From adesbiaux at vente-privee.com Mon May 7 15:59:10 2018 From: adesbiaux at vente-privee.com (Adrien DESBIAUX) Date: Mon, 7 May 2018 19:59:10 +0000 Subject: [keycloak-dev] Redis cluster instead of Infinispan In-Reply-To: <71f5bfed-cff9-b95a-81ac-357c744de7a2@redhat.com> References: , <71f5bfed-cff9-b95a-81ac-357c744de7a2@redhat.com> Message-ID: Hi Marek, Thanks for your feedback on this. In regards to maintenance I think Infinispan is as hard as Redis. What I find difficult is related to the little amount of content the one can find on the web when facing an Infinispan related issue. There is not that much Stack Overflow threads about Infinispan and "case studies". I do understand that from a strategy point of view it may not be in the interest of RedHat to support another solution outside of the "JBoss set of tools". However from a developer/devOps point of view it would be, I believe, way more enjoyable to setup a Redis rather than an Infinispan, especially when it comes to have some clues about how to tweak and scale the solution. It would also potentially increase the range of adoption. Cheers! ________________________________ From: Marek Posolda Sent: Monday, May 7, 2018 6:34:56 PM To: Adrien DESBIAUX; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Redis cluster instead of Infinispan Hi, in theory you can do it, but you will need to override some providers (user session provider, caching providers) to use redis instead of infinispan. It may be fair amount of work. I don't think we have a plan to replace infinispan with the Redis and support it OOTB. One thing is to develop the Redis support, but another is maintenance, which is even more difficult. Especially considering that we need to care about backwards compatibility and support for rolling-upgrades in the future... What kinds of issues you had in infinispan? Are there some concrete issues you saw? Marek Dne 4.5.2018 v 10:11 Adrien DESBIAUX napsal(a): > Hello all! > > > What would be the effort required in order to add a Redis connector in place of the classic Infinispan? > > Wildfly would have to be updated as well as Keycloak? > > > > Indeed we found out Infinispan extremely difficult to setup and the documentation very complex to digest. > > > Also being able to plug a Redis cluster would speed up the Keycloak adoption. > > > What is your opinion on this topic? > > > Thank you in advance for sharing your thoughts. > > > Cheers, > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Ddev&d=DwICBA&c=8G9fL-FODW3I-fESjFvsaw&r=BhQIS0sALperhBRJRNzxM3Ax9g4k8rNIuzNmM35TMgE&m=BawETuB5tx_R5j7UxcgqAWEzI25TLAYCkmsqqOJHCco&s=hSU7ExTWtYmZFQT9e4EDpZUM3Q3-f5Rn9FraW_pvSLw&e= From jim.groffen at gmail.com Tue May 8 05:04:25 2018 From: jim.groffen at gmail.com (Jim Groffen) Date: Tue, 8 May 2018 18:34:25 +0930 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback Message-ID: Hello folks, I am using Keycloak with multiple Kerberos user federations, and am affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the first user federation will attempt Kerberos auth. I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this works great for me. Ricardo's suggestion is to change SPNEGO authenticators in LDAP and Kerberos user federations to return null instead of 'failed' or 'continue'. A null return value causes the UserCredentialStoreManager to continue to the next auth provider instead of failing the Kerberos auth attempt for all providers if the first provider fails. I have tested these changes in my deploy and would like to provide a pull request, but I need some review and maybe a suggestion on how to add a test. The following commit has the changes I've made so far: https://github.com/jgroffen/keycloak/commit/634854748ba40ba20432540ac27f79a3c37874e2 Note I've reduced log noise as authentication attempts are expected to fail when the Kerberos provider and user realm don't match. Ricardo had further problems with a false-positive replay attack - my situation is not affected by this problem so I'd like to push ahead with this intermediary fix if possible. I'm unaffected because I have separate realms with no trust, and separate keytab files per federation that contain only the relevant keytab entry. Thanks in advance! From wadahiro at gmail.com Tue May 8 05:40:58 2018 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Tue, 8 May 2018 18:40:58 +0900 Subject: [keycloak-dev] keycloak-documentation translation In-Reply-To: References: Message-ID: Hello, Recently, we completed translating all 7 guides for version 3.4.3.Final into Japanese! You can see them from the following site. http://keycloak-documentation.openstandia.jp We'll continue to translate the version 4.x documents. P.S. I'll attend Red Hat Summit 2018 from tomorrow and I look forward to meeting many keycloak users and developers! Best Regards, -- Hiroyuki Wada, Nomura Research Institute, Ltd. On Thu, Sep 28, 2017 at 11:25 PM, Hiroyuki Wada wrote: > Hello, > > On Fri, Sep 8, 2017 at 2:25 AM, Bill Burke wrote: >> That's great! Thank you. We can certainly link to it on our website. >> We don't have the resources to translate it, even in product. > > Today, we just published Japanese keycloak-documentation site! > > http://keycloak-documentation.openstandia.jp > > Currently we finished translating 'Getting Started' guide only. > We'll translate other documents as soon as possible. > > I would be grateful if you could link to this site from official site. > > > Best Regards, > > -- > Hiroyuki Wada, > Nomura Research Institute, Ltd. > >> >> On Thu, Sep 7, 2017 at 11:19 AM, Hiroyuki Wada wrote: >>> Hello, >>> >>> We have a plan to translate keycloak-documentation to Japanese for the >>> community at our company. >>> Because there is no place to manage the translation resources in >>> keycloak-documentation repository, >>> we are planning to put the resources into own repository and publish >>> the built documents to our corporate site. >>> Do you have any concerns? >>> Of course, we can contribute it if there are any plans to translate it >>> officially. >>> >>> Best Regards, >>> >>> -- >>> Hiroyuki Wada, >>> Nomura Research Institute, Ltd. >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> Bill Burke >> Red Hat From mhelmke at redhat.com Tue May 8 06:53:12 2018 From: mhelmke at redhat.com (Matthew Helmke) Date: Tue, 8 May 2018 05:53:12 -0500 Subject: [keycloak-dev] keycloak-documentation translation In-Reply-To: References: Message-ID: Wow! That is wonderful news. On Tue, May 8, 2018 at 4:40 AM, Hiroyuki Wada wrote: > Hello, > > Recently, we completed translating all 7 guides for version > 3.4.3.Final into Japanese! > You can see them from the following site. > > http://keycloak-documentation.openstandia.jp > > We'll continue to translate the version 4.x documents. > > P.S. I'll attend Red Hat Summit 2018 from tomorrow and I look forward > to meeting many keycloak users and developers! > > > Best Regards, > > -- > Hiroyuki Wada, > Nomura Research Institute, Ltd. > > On Thu, Sep 28, 2017 at 11:25 PM, Hiroyuki Wada > wrote: > > Hello, > > > > On Fri, Sep 8, 2017 at 2:25 AM, Bill Burke wrote: > >> That's great! Thank you. We can certainly link to it on our website. > >> We don't have the resources to translate it, even in product. > > > > Today, we just published Japanese keycloak-documentation site! > > > > http://keycloak-documentation.openstandia.jp > > > > Currently we finished translating 'Getting Started' guide only. > > We'll translate other documents as soon as possible. > > > > I would be grateful if you could link to this site from official site. > > > > > > Best Regards, > > > > -- > > Hiroyuki Wada, > > Nomura Research Institute, Ltd. > > > >> > >> On Thu, Sep 7, 2017 at 11:19 AM, Hiroyuki Wada > wrote: > >>> Hello, > >>> > >>> We have a plan to translate keycloak-documentation to Japanese for the > >>> community at our company. > >>> Because there is no place to manage the translation resources in > >>> keycloak-documentation repository, > >>> we are planning to put the resources into own repository and publish > >>> the built documents to our corporate site. > >>> Do you have any concerns? > >>> Of course, we can contribute it if there are any plans to translate it > >>> officially. > >>> > >>> Best Regards, > >>> > >>> -- > >>> Hiroyuki Wada, > >>> Nomura Research Institute, Ltd. > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> -- > >> Bill Burke > >> Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- matthew helmke technical writer, product documentation CUSTOMER content services mhelmke at redhat.com T: +1-319-333-9638 irc:: mhelmke TRIED. TESTED. TRUSTED. From bburke at redhat.com Tue May 8 07:48:22 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 8 May 2018 07:48:22 -0400 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback In-Reply-To: References: Message-ID: At first glance, this doesn't look like the correct fix. Looks like the Kerberos Provider is looking for the user in local storage only. See line 233 of KerberosFederationProvider. findOrCreateAuthenticatedUser() UserModel user = session.userLocalStorage().getUserByUsername(username, realm); I think you need to change this to session.users().getUserByUsername(). This might have fallen through the cracks when we ported to the new user storage SPI. On Tue, May 8, 2018 at 5:04 AM, Jim Groffen wrote: > Hello folks, > > I am using Keycloak with multiple Kerberos user federations, and am > affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the > first user federation will attempt Kerberos auth. > > I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this > works great for me. > > Ricardo's suggestion is to change SPNEGO authenticators in LDAP and > Kerberos user federations to return null instead of 'failed' or 'continue'. > A null return value causes the UserCredentialStoreManager to continue to > the next auth provider instead of failing the Kerberos auth attempt for all > providers if the first provider fails. > > I have tested these changes in my deploy and would like to provide a pull > request, but I need some review and maybe a suggestion on how to add a > test. The following commit has the changes I've made so far: > > https://github.com/jgroffen/keycloak/commit/634854748ba40ba20432540ac27f79a3c37874e2 > > Note I've reduced log noise as authentication attempts are expected to fail > when the Kerberos provider and user realm don't match. > > Ricardo had further problems with a false-positive replay attack - my > situation is not affected by this problem so I'd like to push ahead with > this intermediary fix if possible. I'm unaffected because I have separate > realms with no trust, and separate keytab files per federation that contain > only the relevant keytab entry. > > Thanks in advance! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From bburke at redhat.com Tue May 8 07:59:10 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 8 May 2018 07:59:10 -0400 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback In-Reply-To: References: Message-ID: But maybe I'm not understanding the problem. JIRA seems to state that it is one Kerberos realm, and multiple LDAP servers. That's your situation too, right? On Tue, May 8, 2018 at 7:48 AM, Bill Burke wrote: > At first glance, this doesn't look like the correct fix. Looks like > the Kerberos Provider is looking for the user in local storage only. > See line 233 of KerberosFederationProvider. > > findOrCreateAuthenticatedUser() > > UserModel user = > session.userLocalStorage().getUserByUsername(username, realm); > > I think you need to change this to > session.users().getUserByUsername(). This might have fallen through > the cracks when we ported to the new user storage SPI. > > On Tue, May 8, 2018 at 5:04 AM, Jim Groffen wrote: >> Hello folks, >> >> I am using Keycloak with multiple Kerberos user federations, and am >> affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the >> first user federation will attempt Kerberos auth. >> >> I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this >> works great for me. >> >> Ricardo's suggestion is to change SPNEGO authenticators in LDAP and >> Kerberos user federations to return null instead of 'failed' or 'continue'. >> A null return value causes the UserCredentialStoreManager to continue to >> the next auth provider instead of failing the Kerberos auth attempt for all >> providers if the first provider fails. >> >> I have tested these changes in my deploy and would like to provide a pull >> request, but I need some review and maybe a suggestion on how to add a >> test. The following commit has the changes I've made so far: >> >> https://github.com/jgroffen/keycloak/commit/634854748ba40ba20432540ac27f79a3c37874e2 >> >> Note I've reduced log noise as authentication attempts are expected to fail >> when the Kerberos provider and user realm don't match. >> >> Ricardo had further problems with a false-positive replay attack - my >> situation is not affected by this problem so I'd like to push ahead with >> this intermediary fix if possible. I'm unaffected because I have separate >> realms with no trust, and separate keytab files per federation that contain >> only the relevant keytab entry. >> >> Thanks in advance! >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > Red Hat -- Bill Burke Red Hat From bburke at redhat.com Tue May 8 08:07:18 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 8 May 2018 08:07:18 -0400 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback In-Reply-To: References: Message-ID: Ugh, sorry...that's not it...Sorry, I haven't looked at this code in a long time and I'm not the original author either.... If you are using Kerberos backed by LDAP, then you should not be using the KerberosFederationProvider. You should be enabling kerberos auth on your LDAP provider. See this: https://www.keycloak.org/docs/latest/server_admin/index.html#_kerberos On Tue, May 8, 2018 at 7:59 AM, Bill Burke wrote: > But maybe I'm not understanding the problem. JIRA seems to state that > it is one Kerberos realm, and multiple LDAP servers. That's your > situation too, right? > > On Tue, May 8, 2018 at 7:48 AM, Bill Burke wrote: >> At first glance, this doesn't look like the correct fix. Looks like >> the Kerberos Provider is looking for the user in local storage only. >> See line 233 of KerberosFederationProvider. >> >> findOrCreateAuthenticatedUser() >> >> UserModel user = >> session.userLocalStorage().getUserByUsername(username, realm); >> >> I think you need to change this to >> session.users().getUserByUsername(). This might have fallen through >> the cracks when we ported to the new user storage SPI. >> >> On Tue, May 8, 2018 at 5:04 AM, Jim Groffen wrote: >>> Hello folks, >>> >>> I am using Keycloak with multiple Kerberos user federations, and am >>> affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the >>> first user federation will attempt Kerberos auth. >>> >>> I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this >>> works great for me. >>> >>> Ricardo's suggestion is to change SPNEGO authenticators in LDAP and >>> Kerberos user federations to return null instead of 'failed' or 'continue'. >>> A null return value causes the UserCredentialStoreManager to continue to >>> the next auth provider instead of failing the Kerberos auth attempt for all >>> providers if the first provider fails. >>> >>> I have tested these changes in my deploy and would like to provide a pull >>> request, but I need some review and maybe a suggestion on how to add a >>> test. The following commit has the changes I've made so far: >>> >>> https://github.com/jgroffen/keycloak/commit/634854748ba40ba20432540ac27f79a3c37874e2 >>> >>> Note I've reduced log noise as authentication attempts are expected to fail >>> when the Kerberos provider and user realm don't match. >>> >>> Ricardo had further problems with a false-positive replay attack - my >>> situation is not affected by this problem so I'd like to push ahead with >>> this intermediary fix if possible. I'm unaffected because I have separate >>> realms with no trust, and separate keytab files per federation that contain >>> only the relevant keytab entry. >>> >>> Thanks in advance! >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> Bill Burke >> Red Hat > > > > -- > Bill Burke > Red Hat -- Bill Burke Red Hat From bburke at redhat.com Tue May 8 08:22:31 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 8 May 2018 08:22:31 -0400 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback In-Reply-To: References: Message-ID: The null return should be line 689 in LDAPStorageProvider. Logger should probably be debug instead of warn too. UserModel user = findOrCreateAuthenticatedUser(realm, username); if (user == null) { logger.warnf("Kerberos/SPNEGO authentication succeeded with username [%s], but couldn't find or create user with federation provider [%s]", username, model.getName()); return null;// OLD CODE IS ----> CredentialValidationOutput.failed(); The authenticate method should return null too I believe. I have to talk to Marek though about this. Kerberos token validation would be redone for each LDAP provider. I don't know if this is an expensive operation or not and wonder if it should be optimized On Tue, May 8, 2018 at 8:07 AM, Bill Burke wrote: > Ugh, sorry...that's not it...Sorry, I haven't looked at this code in a > long time and I'm not the original author either.... > > If you are using Kerberos backed by LDAP, then you should not be using > the KerberosFederationProvider. You should be enabling kerberos auth > on your LDAP provider. See this: > > https://www.keycloak.org/docs/latest/server_admin/index.html#_kerberos > > > On Tue, May 8, 2018 at 7:59 AM, Bill Burke wrote: >> But maybe I'm not understanding the problem. JIRA seems to state that >> it is one Kerberos realm, and multiple LDAP servers. That's your >> situation too, right? >> >> On Tue, May 8, 2018 at 7:48 AM, Bill Burke wrote: >>> At first glance, this doesn't look like the correct fix. Looks like >>> the Kerberos Provider is looking for the user in local storage only. >>> See line 233 of KerberosFederationProvider. >>> >>> findOrCreateAuthenticatedUser() >>> >>> UserModel user = >>> session.userLocalStorage().getUserByUsername(username, realm); >>> >>> I think you need to change this to >>> session.users().getUserByUsername(). This might have fallen through >>> the cracks when we ported to the new user storage SPI. >>> >>> On Tue, May 8, 2018 at 5:04 AM, Jim Groffen wrote: >>>> Hello folks, >>>> >>>> I am using Keycloak with multiple Kerberos user federations, and am >>>> affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the >>>> first user federation will attempt Kerberos auth. >>>> >>>> I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this >>>> works great for me. >>>> >>>> Ricardo's suggestion is to change SPNEGO authenticators in LDAP and >>>> Kerberos user federations to return null instead of 'failed' or 'continue'. >>>> A null return value causes the UserCredentialStoreManager to continue to >>>> the next auth provider instead of failing the Kerberos auth attempt for all >>>> providers if the first provider fails. >>>> >>>> I have tested these changes in my deploy and would like to provide a pull >>>> request, but I need some review and maybe a suggestion on how to add a >>>> test. The following commit has the changes I've made so far: >>>> >>>> https://github.com/jgroffen/keycloak/commit/634854748ba40ba20432540ac27f79a3c37874e2 >>>> >>>> Note I've reduced log noise as authentication attempts are expected to fail >>>> when the Kerberos provider and user realm don't match. >>>> >>>> Ricardo had further problems with a false-positive replay attack - my >>>> situation is not affected by this problem so I'd like to push ahead with >>>> this intermediary fix if possible. I'm unaffected because I have separate >>>> realms with no trust, and separate keytab files per federation that contain >>>> only the relevant keytab entry. >>>> >>>> Thanks in advance! >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> -- >>> Bill Burke >>> Red Hat >> >> >> >> -- >> Bill Burke >> Red Hat > > > > -- > Bill Burke > Red Hat -- Bill Burke Red Hat From josh.cummings at gmail.com Tue May 8 16:26:19 2018 From: josh.cummings at gmail.com (Josh Cummings) Date: Tue, 8 May 2018 14:26:19 -0600 Subject: [keycloak-dev] Spring Security 5.1 - Resource Server support Message-ID: Hi, I'm not sure if you already know, but the Spring Security Team is re-writing its support for OAuth2. We are planning on releasing initial Resource Server support in 5.1 this September. I'd love to collaborate with you guys, especially while you are in beta, to see if what we are writing is complementary to your goals. Perhaps we can help remove some of your boilerplate, etc., say from your Spring Security adapter. https://github.com/jzheaux/spring-security-oauth2-resource-server This is sort of a sandbox repo for Spring Security's new Resource Server support. Would love your feedback. I'll be updating the repo with some integrated Keycloak samples in the next few days. Thanks, Josh -- Josh Cummings Software Engineer | Teacher | Pi Fanatic | https://www.linkedin.com/in/jzheaux | http://tech.joshuacummings.com From sblanc at redhat.com Tue May 8 18:53:21 2018 From: sblanc at redhat.com (Sebastien Blanc) Date: Tue, 08 May 2018 22:53:21 +0000 Subject: [keycloak-dev] Spring Security 5.1 - Resource Server support In-Reply-To: References: Message-ID: Hi Josh ! Thanks for pinging us about this ! We really appreciate your offer to collaborate. I will try ASAP playing with the new Spring Sec and share my findings with you. Seb Le mar. 8 mai 2018 ? 13:28, Josh Cummings a ?crit : > Hi, > > I'm not sure if you already know, but the Spring Security Team is > re-writing its support for OAuth2. We are planning on releasing initial > Resource Server support in 5.1 this September. > > I'd love to collaborate with you guys, especially while you are in beta, to > see if what we are writing is complementary to your goals. Perhaps we can > help remove some of your boilerplate, etc., say from your Spring Security > adapter. > > https://github.com/jzheaux/spring-security-oauth2-resource-server > > This is sort of a sandbox repo for Spring Security's new Resource Server > support. > > Would love your feedback. I'll be updating the repo with some integrated > Keycloak samples in the next few days. > > Thanks, > Josh > > -- > Josh Cummings > > Software Engineer | Teacher | Pi Fanatic | > https://www.linkedin.com/in/jzheaux | http://tech.joshuacummings.com > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From jim.groffen at gmail.com Tue May 8 20:33:05 2018 From: jim.groffen at gmail.com (Jim Groffen) Date: Wed, 9 May 2018 10:03:05 +0930 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback In-Reply-To: References: Message-ID: Hello Bill, Thanks for the prompt responses, apologies for delayed response, I'm down-under! The original issue is as you said, one Kerberos realm, and multiple LDAP servers. My situation is different though, I have multiple Kerberos realms, realm A as first priority and realm B as second. I get a checksum fails exception when validating a service ticket from realm B against the keytab for realm A. This currently stops Kerberos authentication from falling through to the next auth provider - realm B. We are actually looking at N kerberos realms, potentially adding and removing realms over time, so managing keytabs separately is preferred for us, but optimising service ticket validation is a good point. I'm also more likely to use the Kerberos federation provider than the LDAP federation provider with Kerberos enabled, but both providers are affected by this issue, so I'm suggesting a fix for both. I'll incorporate your changes and let you know how I go. Thanks again Bill, On 8 May 2018 at 21:52, Bill Burke wrote: > The null return should be line 689 in LDAPStorageProvider. Logger > should probably be debug instead of warn too. > > UserModel user = > findOrCreateAuthenticatedUser(realm, username); > > if (user == null) { > logger.warnf("Kerberos/SPNEGO authentication > succeeded with username [%s], but couldn't find or create user with > federation provider [%s]", username, model.getName()); > return null;// OLD CODE IS ----> > CredentialValidationOutput.failed(); > > The authenticate method should return null too I believe. I have to > talk to Marek though about this. Kerberos token validation would be > redone for each LDAP provider. I don't know if this is an expensive > operation or not and wonder if it should be optimized > > > On Tue, May 8, 2018 at 8:07 AM, Bill Burke wrote: > > Ugh, sorry...that's not it...Sorry, I haven't looked at this code in a > > long time and I'm not the original author either.... > > > > If you are using Kerberos backed by LDAP, then you should not be using > > the KerberosFederationProvider. You should be enabling kerberos auth > > on your LDAP provider. See this: > > > > https://www.keycloak.org/docs/latest/server_admin/index.html#_kerberos > > > > > > On Tue, May 8, 2018 at 7:59 AM, Bill Burke wrote: > >> But maybe I'm not understanding the problem. JIRA seems to state that > >> it is one Kerberos realm, and multiple LDAP servers. That's your > >> situation too, right? > >> > >> On Tue, May 8, 2018 at 7:48 AM, Bill Burke wrote: > >>> At first glance, this doesn't look like the correct fix. Looks like > >>> the Kerberos Provider is looking for the user in local storage only. > >>> See line 233 of KerberosFederationProvider. > >>> > >>> findOrCreateAuthenticatedUser() > >>> > >>> UserModel user = > >>> session.userLocalStorage().getUserByUsername(username, realm); > >>> > >>> I think you need to change this to > >>> session.users().getUserByUsername(). This might have fallen through > >>> the cracks when we ported to the new user storage SPI. > >>> > >>> On Tue, May 8, 2018 at 5:04 AM, Jim Groffen > wrote: > >>>> Hello folks, > >>>> > >>>> I am using Keycloak with multiple Kerberos user federations, and am > >>>> affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only > the > >>>> first user federation will attempt Kerberos auth. > >>>> > >>>> I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, > this > >>>> works great for me. > >>>> > >>>> Ricardo's suggestion is to change SPNEGO authenticators in LDAP and > >>>> Kerberos user federations to return null instead of 'failed' or > 'continue'. > >>>> A null return value causes the UserCredentialStoreManager to continue > to > >>>> the next auth provider instead of failing the Kerberos auth attempt > for all > >>>> providers if the first provider fails. > >>>> > >>>> I have tested these changes in my deploy and would like to provide a > pull > >>>> request, but I need some review and maybe a suggestion on how to add a > >>>> test. The following commit has the changes I've made so far: > >>>> > >>>> https://github.com/jgroffen/keycloak/commit/ > 634854748ba40ba20432540ac27f79a3c37874e2 > >>>> > >>>> Note I've reduced log noise as authentication attempts are expected > to fail > >>>> when the Kerberos provider and user realm don't match. > >>>> > >>>> Ricardo had further problems with a false-positive replay attack - my > >>>> situation is not affected by this problem so I'd like to push ahead > with > >>>> this intermediary fix if possible. I'm unaffected because I have > separate > >>>> realms with no trust, and separate keytab files per federation that > contain > >>>> only the relevant keytab entry. > >>>> > >>>> Thanks in advance! > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >>> > >>> > >>> -- > >>> Bill Burke > >>> Red Hat > >> > >> > >> > >> -- > >> Bill Burke > >> Red Hat > > > > > > > > -- > > Bill Burke > > Red Hat > > > > -- > Bill Burke > Red Hat > From jim.groffen at gmail.com Wed May 9 04:41:22 2018 From: jim.groffen at gmail.com (Jim Groffen) Date: Wed, 9 May 2018 18:11:22 +0930 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback In-Reply-To: References: Message-ID: Hello again Bill, My problem is not related to KEYCLOAK-6225 although the solution is very similar. Apologies for the confusion, I'll start a new thread relating to my issue. I am happy to help with KEYCLOAK-6225, and concur that your fix looks right for that issue, barring the replay detection issue. I don't have an easy way to test it unfortunately. Cheers, On 9 May 2018 at 10:03, Jim Groffen wrote: > Hello Bill, > > Thanks for the prompt responses, apologies for delayed response, I'm > down-under! > > The original issue is as you said, one Kerberos realm, and multiple LDAP > servers. > > My situation is different though, I have multiple Kerberos realms, realm A > as first priority and realm B as second. I get a checksum fails exception > when validating a service ticket from realm B against the keytab for realm > A. This currently stops Kerberos authentication from falling through to the > next auth provider - realm B. > > We are actually looking at N kerberos realms, potentially adding and > removing realms over time, so managing keytabs separately is preferred for > us, but optimising service ticket validation is a good point. > > I'm also more likely to use the Kerberos federation provider than the LDAP > federation provider with Kerberos enabled, but both providers are affected > by this issue, so I'm suggesting a fix for both. > > I'll incorporate your changes and let you know how I go. > > Thanks again Bill, > > On 8 May 2018 at 21:52, Bill Burke wrote: > >> The null return should be line 689 in LDAPStorageProvider. Logger >> should probably be debug instead of warn too. >> >> UserModel user = >> findOrCreateAuthenticatedUser(realm, username); >> >> if (user == null) { >> logger.warnf("Kerberos/SPNEGO authentication >> succeeded with username [%s], but couldn't find or create user with >> federation provider [%s]", username, model.getName()); >> return null;// OLD CODE IS ----> >> CredentialValidationOutput.failed(); >> >> The authenticate method should return null too I believe. I have to >> talk to Marek though about this. Kerberos token validation would be >> redone for each LDAP provider. I don't know if this is an expensive >> operation or not and wonder if it should be optimized >> >> >> On Tue, May 8, 2018 at 8:07 AM, Bill Burke wrote: >> > Ugh, sorry...that's not it...Sorry, I haven't looked at this code in a >> > long time and I'm not the original author either.... >> > >> > If you are using Kerberos backed by LDAP, then you should not be using >> > the KerberosFederationProvider. You should be enabling kerberos auth >> > on your LDAP provider. See this: >> > >> > https://www.keycloak.org/docs/latest/server_admin/index.html#_kerberos >> > >> > >> > On Tue, May 8, 2018 at 7:59 AM, Bill Burke wrote: >> >> But maybe I'm not understanding the problem. JIRA seems to state that >> >> it is one Kerberos realm, and multiple LDAP servers. That's your >> >> situation too, right? >> >> >> >> On Tue, May 8, 2018 at 7:48 AM, Bill Burke wrote: >> >>> At first glance, this doesn't look like the correct fix. Looks like >> >>> the Kerberos Provider is looking for the user in local storage only. >> >>> See line 233 of KerberosFederationProvider. >> >>> >> >>> findOrCreateAuthenticatedUser() >> >>> >> >>> UserModel user = >> >>> session.userLocalStorage().getUserByUsername(username, realm); >> >>> >> >>> I think you need to change this to >> >>> session.users().getUserByUsername(). This might have fallen through >> >>> the cracks when we ported to the new user storage SPI. >> >>> >> >>> On Tue, May 8, 2018 at 5:04 AM, Jim Groffen >> wrote: >> >>>> Hello folks, >> >>>> >> >>>> I am using Keycloak with multiple Kerberos user federations, and am >> >>>> affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where >> only the >> >>>> first user federation will attempt Kerberos auth. >> >>>> >> >>>> I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, >> this >> >>>> works great for me. >> >>>> >> >>>> Ricardo's suggestion is to change SPNEGO authenticators in LDAP and >> >>>> Kerberos user federations to return null instead of 'failed' or >> 'continue'. >> >>>> A null return value causes the UserCredentialStoreManager to >> continue to >> >>>> the next auth provider instead of failing the Kerberos auth attempt >> for all >> >>>> providers if the first provider fails. >> >>>> >> >>>> I have tested these changes in my deploy and would like to provide a >> pull >> >>>> request, but I need some review and maybe a suggestion on how to add >> a >> >>>> test. The following commit has the changes I've made so far: >> >>>> >> >>>> https://github.com/jgroffen/keycloak/commit/634854748ba40ba2 >> 0432540ac27f79a3c37874e2 >> >>>> >> >>>> Note I've reduced log noise as authentication attempts are expected >> to fail >> >>>> when the Kerberos provider and user realm don't match. >> >>>> >> >>>> Ricardo had further problems with a false-positive replay attack - my >> >>>> situation is not affected by this problem so I'd like to push ahead >> with >> >>>> this intermediary fix if possible. I'm unaffected because I have >> separate >> >>>> realms with no trust, and separate keytab files per federation that >> contain >> >>>> only the relevant keytab entry. >> >>>> >> >>>> Thanks in advance! >> >>>> _______________________________________________ >> >>>> keycloak-dev mailing list >> >>>> keycloak-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> >>> >> >>> >> >>> -- >> >>> Bill Burke >> >>> Red Hat >> >> >> >> >> >> >> >> -- >> >> Bill Burke >> >> Red Hat >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> >> >> >> -- >> Bill Burke >> Red Hat >> > > From jim.groffen at gmail.com Wed May 9 05:13:09 2018 From: jim.groffen at gmail.com (Jim Groffen) Date: Wed, 9 May 2018 18:43:09 +0930 Subject: [keycloak-dev] Only first of multiple Kerberos federations can authenticate Message-ID: Hello again, I have a need to define two (or more) Kerberos federations to support Kerberos service tickets from either realm. I have a different keytab file for each realm. Lets say I create a federation for REALM A with priority 1, and a second federation for REALM B with priority 2. When I attempt authentication as a user from REALM A I have no problem, but a user from REALM B fails. Checking the logs I can see that KeyCloak attempts to decrypt the REALM B service ticket with the REALM A keytab and fails. Instead of moving on to the lower priority REALM B federation, the Kerberos step of the auth flow fails and moves on to the next step. Should I raise a new JIRA issue for this problem? I have successfully fixed this problem in my environment, but I am unsure as to which approach is best, and want to make sure I'm fixing the issue for everyone not just myself. Here are two options: 1: Only allow lower priority federations to attempt auth in certain situations This solution detects why authentication failed and will only let other federations attempt authentication if the ticket couldn't be decrypted - indicating the ticket received was likely encrypted with a different key: https://github.com/jgroffen/keycloak/commit/9860189b7075c8f5a55f542cc68d5926584b2f65 2: Let all Kerberos federations attempt auth in priority order until one succeeds or all fail. https://github.com/jgroffen/keycloak/commit/5fa98dd429acb220ce06186639540e5d74252c8b Are either of these solutions viable? I found both Kerberos and LDAP federations with Kerberos enabled affected, so I'm looking at fixing both. Cheers, From ssilvert at redhat.com Wed May 9 16:09:42 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 9 May 2018 16:09:42 -0400 Subject: [keycloak-dev] Review Request: New Account Management Console Message-ID: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> Anyone who would like to review the latest wireframe from the "New Account Management Console" project, keep reading. The UXD team has created a wireframe for the "responsive" version of the Applications screen.? This is the screen you will eventually see on a smartphone. Please leave comments directly on the wireframe.? You will need a free InVision account.? Your feedback is greatly appreciated. https://redhat.invisionapp.com/share/JVIAWNPDPGN#/screens/295807051 Stan From tkyjovsk at redhat.com Thu May 10 08:30:21 2018 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Thu, 10 May 2018 08:30:21 -0400 (EDT) Subject: [keycloak-dev] Review Request: New Account Management Console In-Reply-To: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> References: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> Message-ID: <703979380.5656722.1525955421269.JavaMail.zimbra@redhat.com> Hi Stan, thanks for sharing. I've put some comments in. Please take them more as my personal observations/opinions as I'm not a UI/usability expert. Regards, Tomas ----- Original Message ----- > Anyone who would like to review the latest wireframe from the "New > Account Management Console" project, keep reading. > > The UXD team has created a wireframe for the "responsive" version of the > Applications screen.? This is the screen you will eventually see on a > smartphone. > > Please leave comments directly on the wireframe.? You will need a free > InVision account.? Your feedback is greatly appreciated. > > https://redhat.invisionapp.com/share/JVIAWNPDPGN#/screens/295807051 > > Stan > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu May 10 09:51:30 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 10 May 2018 09:51:30 -0400 Subject: [keycloak-dev] Review Request: New Account Management Console In-Reply-To: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> References: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> Message-ID: Authenticator setup probably needs rework, IMO. For instance, since you are already on your mobile device, I don't think you'll be able to scan the barcode? You might be able to redirect to the authenticator app to set up the authenticator. On Wed, May 9, 2018 at 4:09 PM, Stan Silvert wrote: > Anyone who would like to review the latest wireframe from the "New > Account Management Console" project, keep reading. > > The UXD team has created a wireframe for the "responsive" version of the > Applications screen. This is the screen you will eventually see on a > smartphone. > > Please leave comments directly on the wireframe. You will need a free > InVision account. Your feedback is greatly appreciated. > > https://redhat.invisionapp.com/share/JVIAWNPDPGN#/screens/295807051 > > Stan > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From ssilvert at redhat.com Thu May 10 10:30:44 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 10 May 2018 10:30:44 -0400 Subject: [keycloak-dev] Review Request: New Account Management Console In-Reply-To: <703979380.5656722.1525955421269.JavaMail.zimbra@redhat.com> References: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> <703979380.5656722.1525955421269.JavaMail.zimbra@redhat.com> Message-ID: <92d1914a-5392-572d-b370-946ee3add475@redhat.com> Thanks Tomas.? Your feedback was very helpful. On 5/10/2018 8:30 AM, Tomas Kyjovsky wrote: > Hi Stan, thanks for sharing. > > I've put some comments in. Please take them more as my personal observations/opinions as I'm not a UI/usability expert. > > > Regards, > Tomas > > ----- Original Message ----- >> Anyone who would like to review the latest wireframe from the "New >> Account Management Console" project, keep reading. >> >> The UXD team has created a wireframe for the "responsive" version of the >> Applications screen.? This is the screen you will eventually see on a >> smartphone. >> >> Please leave comments directly on the wireframe.? You will need a free >> InVision account.? Your feedback is greatly appreciated. >> >> https://redhat.invisionapp.com/share/JVIAWNPDPGN#/screens/295807051 >> >> Stan >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev From csnyder at iland.com Thu May 10 12:06:07 2018 From: csnyder at iland.com (Cory Snyder) Date: Thu, 10 May 2018 12:06:07 -0400 Subject: [keycloak-dev] Event details JSON JPA length limit Message-ID: Hello, We?re running Keycloak 1.9.8 and have been getting intermittent exception stack traces in the logs with the following cause: Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(2550). After tracing through the Keycloak source code, I believe that I?ve found the culprit to be the event details JSON field: https://github.com/keycloak/keycloak/blob/27d8afe4a75b2c0a8b48b32876a2495bc028401f/model/jpa/src/main/java/org/keycloak/events/jpa/EventEntity.java#L60 It seems that this could still be an issue with the latest master branch (or at least you still have the same character limit). Would you like me to create an issue in JIRA? I?m not sure if it would be acceptable to just increase the character limit of the field or remove the limit? If you have a specific idea for how this should be addressed, I?d be willing to contribute a PR. Thanks, Cory Snyder From ssilvert at redhat.com Thu May 10 18:04:27 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 10 May 2018 18:04:27 -0400 Subject: [keycloak-dev] Review Request #2: New Account Management Console In-Reply-To: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> References: <23be7e31-21af-7803-8949-83cb8858cb6d@redhat.com> Message-ID: <6f5464f7-e3ce-2da7-81d2-3f5c1137185b@redhat.com> Review Request #2: Responsive Design for Authenticator https://redhat.invisionapp.com/share/AXIE29KMPCG Anyone who would like to review the latest wireframe from the "New Account Management Console" project, keep reading. The UXD team has created a wireframe for the "responsive" version of the Authenticator screens.? These are screens you will eventually see on a smartphone. Please leave comments directly on the wireframe.? You will need a free InVision account.? Your feedback is greatly appreciated. Stan From federico.facca at martel-innovate.com Fri May 11 07:30:48 2018 From: federico.facca at martel-innovate.com (Federico Michele Facca) Date: Fri, 11 May 2018 13:30:48 +0200 Subject: [keycloak-dev] How to share a resource with a user via UMA 2.0 API Message-ID: Hi, We are looking into integrating keycloak UMA 2.0 APIs in our platform to allow users to share resources, ask access to resources, approve sharing, exactly how it is possible via the Keycloak Account UI. It looks like the Account UI is currently using directly keycloak java APIs to do so. Looking at the current REST API implementation it seems not possible that: 1. A owner shares directly a resource (without the user requesting that). 2. Lists the permissions related to resources of an owner, including also the information on who requested that. In our understanding, to obtain 2. we should some how retrieve the Requester from the TicketStore and attach the information to the response (but this would "break" the UMA standard, as anyhow parameters as "returnNames=true" do, so maybe when the request is using "returnNames=true" we could attach as well the requester name and it). For 1, we have no clear ideas, if not adding "requester" as well in the ticket creation. Any hint would be highly appreciated, so that we can work up some implementation to provide both features. Thanks, Federico -- *Dr. FEDERICO MICHELE FACCA* *Head of Martel Lab* 0041 78 807 58 38 *Martel Innovate* - Professional support for innovation projects Click to download our innovators' insights! Follow Us on Twitter From psilva at redhat.com Fri May 11 07:52:51 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 11 May 2018 08:52:51 -0300 Subject: [keycloak-dev] How to share a resource with a user via UMA 2.0 API In-Reply-To: References: Message-ID: On Fri, May 11, 2018 at 8:30 AM, Federico Michele Facca < federico.facca at martel-innovate.com> wrote: > Hi, > We are looking into integrating keycloak UMA 2.0 APIs in our platform to > allow users to share resources, ask access to resources, approve sharing, > exactly how it is possible via the Keycloak Account UI. > It looks like the Account UI is currently using directly keycloak java APIs > to do so. > > Looking at the current REST API implementation it seems not possible that: > 1. A owner shares directly a resource (without the user requesting that). > 2. Lists the permissions related to resources of an owner, including also > the information on who requested that. > We don't have API documented, something we should improve in the future. We have a quickstart that can help you to achieve what you want. See https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-uma-photoz . If you look this method: https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-restful-api/src/main/java/org/keycloak/example/photoz/album/AlbumService.java#L100 You will see that we are using the Permission Endpoint (the endpoint responsible for managing permission tickets) to obtain all resources *shared* with a specific user. In our AuthZ Java Client we have this method: https://github.com/keycloak/keycloak/blob/master/authz/client/src/main/java/org/keycloak/authorization/client/resource/PermissionResource.java#L162 Which allows you to query for permission tickets using different filters. The type PermissionResource also provides methods for CRUD permission tickets. Note that this API is targeted for resource servers and part of the Protection API. > > In our understanding, to obtain 2. we should some how retrieve the > Requester from the TicketStore and attach the information to the response > (but this would "break" the UMA standard, as anyhow parameters as > "returnNames=true" do, so maybe when the request is using > "returnNames=true" > we could attach as well the requester name and it). > > For 1, we have no clear ideas, if not adding "requester" as well in the > ticket creation. > > Any hint would be highly appreciated, so that we can work up some > implementation to provide both features. > > Thanks, > Federico > > -- > *Dr. FEDERICO MICHELE FACCA* > *Head of Martel Lab* > 0041 78 807 58 38 > *Martel Innovate* - Professional > support for innovation projects > Click to download our innovators' insights! > > Follow Us on Twitter > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From thomas.darimont at googlemail.com Fri May 11 09:02:24 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 11 May 2018 14:02:24 +0100 Subject: [keycloak-dev] Spring Security 5.1 - Resource Server support In-Reply-To: References: Message-ID: Hi Josh, Hi Sebi, having proper support for OAuth2 @EnableResourceServer in Spring Security 5 would be very useful. It would also be great if an application could use SSO and Enable ResourceServer at the same time. I tried this with Spring Boot 2 and Spring Security 5 but I couldn't get it to work. I build a demo application that uses SSO based on the OpenID Connect from the latest Spring Security 5 in a Spring Boot 2 app without the need for a Keycloak-adapter library with very little custom code for making the integration work. Perhaps the example can help you to identify some gaps in the current Spring Security OAuth2 / OIDC APIs. The sources can be found here: https://github.com/thomasdarimont /spring-boot-2-keycloak-oauth-example Here are some things that I either had to add or that are currently not possible without more infrastructure plumbing: - Extracting and mapping of Keycloak roles to Spring Security roles. Would be great to have a dedicated API for this - needed to do some plumbing here. See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth -example/blob/master/src/main/java/demo/SpringBoot2App.java#L155 - Propagating logout to Keycloak Could use the standardized OIDC "end_session_endpoint" from the .well-known/ openid-configuration endpoint. See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth -example/blob/master/src/main/java/demo/SpringBoot2App.java#L205 - Explicit configuration for oauth/oidc provider endpoints. Would be great to just use the wellknon endpoint (http://localhost:8080/auth /realms/${realm}/.well-known/openid-configuration) This would ease configuration quite significantly. See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth -example/blob/master/src/main/resources/application.yml#L23 - Handling of access / refresh token for service calls (currently missing) Currently spring security (tested with 5.0.4.RELEASE) does only extracts the IDToken / AccessToken from the OidcUserRequest but not the refresh token. This would be necessary to retrieve new AccessTokens for prolonged service interactions. Another topic is multi-tenancy support. For the example app mentioned above I have a special branch called feature/multi-tenancy that demonstrates a PoC of a hostname based approach for supporting multiple realms / tenants. Some of this is keycloak specific but I think this could be generalized to a degree where the Keycloak specific parts could be reduced to just a few lines of code / configuration. - Configuration See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth -example/blob/feature/mulit-tenancy/src/main/resources/application.yml#L29 - Tenant selection See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth -example/blob/feature/mulit-tenancy/src /main/java/demo/SpringBoot2App.java#L127 Cheers, Thomas Am Di., 8. Mai 2018 um 23:54 Uhr schrieb Sebastien Blanc : > Hi Josh ! > > Thanks for pinging us about this ! We really appreciate your offer to > collaborate. I will try ASAP playing with the new Spring Sec and share my > findings with you. > > Seb > > > Le mar. 8 mai 2018 ? 13:28, Josh Cummings a > ?crit : > > > Hi, > > > > I'm not sure if you already know, but the Spring Security Team is > > re-writing its support for OAuth2. We are planning on releasing initial > > Resource Server support in 5.1 this September. > > > > I'd love to collaborate with you guys, especially while you are in beta, > to > > see if what we are writing is complementary to your goals. Perhaps we can > > help remove some of your boilerplate, etc., say from your Spring Security > > adapter. > > > > https://github.com/jzheaux/spring-security-oauth2-resource-server > > > > This is sort of a sandbox repo for Spring Security's new Resource Server > > support. > > > > Would love your feedback. I'll be updating the repo with some integrated > > Keycloak samples in the next few days. > > > > Thanks, > > Josh > > > > -- > > Josh Cummings > > > > Software Engineer | Teacher | Pi Fanatic | > > https://www.linkedin.com/in/jzheaux | http://tech.joshuacummings.com > > > > _______________________________________________ > > 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 From federico.facca at martel-innovate.com Fri May 11 09:19:42 2018 From: federico.facca at martel-innovate.com (Federico Michele Facca) Date: Fri, 11 May 2018 15:19:42 +0200 Subject: [keycloak-dev] How to share a resource with a user via UMA 2.0 API In-Reply-To: References: Message-ID: Hi Pedro, Thanks a lot for your quick reply. > On 11 May 2018, at 13:52, Pedro Igor Silva wrote: > > > We don't have API documented, something we should improve in the future. > > We have a quickstart that can help you to achieve what you want. See https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-uma-photoz . > > If you look this method: > > https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-restful-api/src/main/java/org/keycloak/example/photoz/album/AlbumService.java#L100 I have been looking at the methods, and actually learned from the exact example you refer to. > > You will see that we are using the Permission Endpoint (the endpoint responsible for managing permission tickets) to obtain all resources *shared* with a specific user. In our AuthZ Java Client we have this method: > > https://github.com/keycloak/keycloak/blob/master/authz/client/src/main/java/org/keycloak/authorization/client/resource/PermissionResource.java#L162 > > Which allows you to query for permission tickets using different filters. Maybe my examples were not clear enough. For question 2: Suppose that user "test" owns resource A and he want to see (like in the my account interface) a table with all the active and pending permissions including the identifier of the user that made the request. Shared resources-> Resource A user B scope read, write Pending requests-> Resource A user C scope read With the following query: curl --request GET \ --url 'http://127.0.0.1:8080/auth/realms/master/authz/protection/permission?returnNames=true&owner=test' \ --header 'authorization: Bearer xxx' I get a list of the permissions (where granted = true are the authorised ones and granted = false the pending ones): [ { "id": "08dccaed-6dbb-47aa-a87c-55b35a6f2523", "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", "resource": "218091a8-e5fc-460c-a306-a3a76775c784", "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", "granted": true, "scopeName": "read", "resourceName": "8910" }, { "id": ?xxxx", "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", "resource": "218091a8-e5fc-460c-a306-a3a76775c784", "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", "granted": false, "scopeName": "read", "resourceName": "8910" } ] so the result does not allow me to know who was the ?requester? (which I don?t know apriori since the query is about all potential requesters) so my idea was that when you use returnNames=true parameter you could add as well the requester, e.g.: { "id": "08dccaed-6dbb-47aa-a87c-55b35a6f2523", "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", "resource": "218091a8-e5fc-460c-a306-a3a76775c784", "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", "granted": true, "scopeName": "read", "resourceName": ?8910?, ?requester?:?xxxxx?, ?requesterName?:?test? }, > > The type PermissionResource also provides methods for CRUD permission tickets. > > Note that this API is targeted for resource servers and part of the Protection API. We realised that by trying to create resources and seeing that using user authentication you get 500 error while using client authentication it works (even though UMA specs is not limiting the access to that). We found out by testing also that the permission endpoint works also with user access tokens. Now the first question was how to ?share? directly a resource with a user. Currently using the API, supposing I am user A and I want to access a resource Z from user B, we proceed as follow (i hope is the correct way? any correction or guidance will be appreciated): 1. We create a permission request on the API (to get the ticket). E.g. read resource x 2. We use the ticket to ask for a rtp token using a user token. curl --request POST \ --url http://127.0.0.1:8080/auth/realms/master/protocol/openid-connect/token \ --header 'Authorization: Bearer xxx' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&ticket=xxxx' If the user has already access, then he gets the rtp, if not he gets: { "error": "access_denied", "error_description": "request_submitted" } Only in this moment the permission ticket i created at step 1 appears in the list of permissions. (I am not sure this is the intended behaviour though). Then is up to the owner to authorise access (via API we can do that by updating the permission and set granted to true) Now let?s suppose that I am the owner of the resource A, and I want to authorise directly (without the user asking access to the resource A) the user Z to access it. How can I do that? At the time being I could not figure it out. Also, out of curiosity is there are a way i can list all resources i can access thanks either to UMA permission or policies? That would be very handful. Suppose that you have an API that with GET /resources list you all the resources, there should be a way to filter the returned resources only based on the one you can access. This could be done easily if you could get a list of the resources you can access. Otherwise, you would need for each resource returned in the list to generate a query asking if the user x can access the specific resource. Not very scalable. Thanks! Federico > > > In our understanding, to obtain 2. we should some how retrieve the > Requester from the TicketStore and attach the information to the response > (but this would "break" the UMA standard, as anyhow parameters as > "returnNames=true" do, so maybe when the request is using "returnNames=true" > we could attach as well the requester name and it). > > For 1, we have no clear ideas, if not adding "requester" as well in the > ticket creation. > > Any hint would be highly appreciated, so that we can work up some > implementation to provide both features. > > Thanks, > Federico > > -- > *Dr. FEDERICO MICHELE FACCA* > *Head of Martel Lab* > 0041 78 807 58 38 > *Martel Innovate* > - Professional > support for innovation projects > Click to download our innovators' insights! > > > Follow Us on Twitter > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev Dr. FEDERICO MICHELE FACCA Head of Martel Lab 0041 78 807 58 38 Martel Innovate - Professional support for innovation projects Click to download our innovators' insights! Follow Us on Twitter From psilva at redhat.com Fri May 11 12:04:06 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 11 May 2018 13:04:06 -0300 Subject: [keycloak-dev] How to share a resource with a user via UMA 2.0 API In-Reply-To: References: Message-ID: On Fri, May 11, 2018 at 10:19 AM, Federico Michele Facca < federico.facca at martel-innovate.com> wrote: > Hi Pedro, > > Thanks a lot for your quick reply. > > On 11 May 2018, at 13:52, Pedro Igor Silva wrote: > >> >> > We don't have API documented, something we should improve in the future. > > We have a quickstart that can help you to achieve what you want. See > https://github.com/keycloak/keycloak-quickstarts/ > tree/latest/app-authz-uma-photoz. > > If you look this method: > > https://github.com/keycloak/keycloak-quickstarts/blob/ > latest/app-authz-uma-photoz/photoz-restful-api/src/main/ > java/org/keycloak/example/photoz/album/AlbumService.java#L100 > > > I have been looking at the methods, and actually learned from the exact > example you refer to. > > > You will see that we are using the Permission Endpoint (the endpoint > responsible for managing permission tickets) to obtain all resources > *shared* with a specific user. In our AuthZ Java Client we have this method: > > https://github.com/keycloak/keycloak/blob/master/authz/ > client/src/main/java/org/keycloak/authorization/client/ > resource/PermissionResource.java#L162 > > Which allows you to query for permission tickets using different filters. > > > Maybe my examples were not clear enough. For question 2: > > > Suppose that user "test" owns resource A and he want to see (like in the > my account interface) a table with all the active and pending permissions > including the identifier of the user that made the request. > > Shared resources-> > > Resource A user B scope read, write > > Pending requests-> > > Resource A user C scope read > > > With the following query: > > curl --request GET \ > --url 'http://127.0.0.1:8080/auth/realms/master/authz/ > protection/permission?returnNames=true&owner=test' \ > --header 'authorization: Bearer xxx' > > I get a list of the permissions (where granted = true are the authorised > ones and granted = false the pending ones): > > [ > { > "id": "08dccaed-6dbb-47aa-a87c-55b35a6f2523", > "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", > "resource": "218091a8-e5fc-460c-a306-a3a76775c784", > "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", > "granted": true, > "scopeName": "read", > "resourceName": "8910" > }, > { > "id": ?xxxx", > "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", > "resource": "218091a8-e5fc-460c-a306-a3a76775c784", > "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", > "granted": false, > "scopeName": "read", > "resourceName": "8910" > } > ] > > so the result does not allow me to know who was the ?requester? (which I > don?t know apriori since the query is about all potential requesters) > > > so my idea was that when you use returnNames=true parameter you could add > as well the requester, e.g.: > > { > "id": "08dccaed-6dbb-47aa-a87c-55b35a6f2523", > "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", > "resource": "218091a8-e5fc-460c-a306-a3a76775c784", > "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", > "granted": true, > "scopeName": "read", > "resourceName": ?8910?, > ?requester?:?xxxxx?, > ?requesterName?:?test? > }, > I see now. We are really missing *requester* in the response. Not sure why it is not there already .... Created https://issues.jboss.org/browse/KEYCLOAK-7337. > > > > > The type PermissionResource also provides methods for CRUD permission > tickets. > > Note that this API is targeted for resource servers and part of the > Protection API. > > > > We realised that by trying to create resources and seeing that using user > authentication you get 500 error while using client authentication it works > (even though UMA specs is not limiting the access to that). > We found out by testing also that the permission endpoint works also with > user access tokens. > Yeah, as long as the access token is granted with uma_protection scope. > > Now the first question was how to ?share? directly a resource with a user. > > Currently using the API, supposing I am user A and I want to access a > resource Z from user B, we proceed as follow (i hope is the correct way? > any correction or guidance will be appreciated): > > 1. We create a permission request on the API (to get the ticket). E.g. > read resource x > > 2. We use the ticket to ask for a rtp token using a user token. > > curl --request POST \ > --url http://127.0.0.1:8080/auth/realms/master/protocol/openid- > connect/token \ > --header 'Authorization: Bearer xxx' \ > --header 'Content-Type: application/x-www-form-urlencoded' \ > --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type% > 3Auma-ticket&ticket=xxxx' > > If the user has already access, then he gets the rtp, if not he gets: > > { > "error": "access_denied", > "error_description": "request_submitted" > } > > Only in this moment the permission ticket i created at step 1 appears in > the list of permissions. (I am not sure this is the intended behaviour > though). > Yeah, that is the expected behavior. But you can also use a request parameter to tell to the token endpoint that you don't want to submit an authorization request. See https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_authorization_aat . > > Then is up to the owner to authorise access (via API we can do that by > updating the permission and set granted to true) > > Now let?s suppose that I am the owner of the resource A, and I want to > authorise directly (without the user asking access to the resource A) > the user Z to access it. How can I do that? At the time being I could not > figure it out. > Similar to the update method, you can use the create method to create permissions. Is that what you are looking for ? See org.keycloak.testsuite.authz.PermissionManagementTest#testCreatePermissionTicketWithResourceName. > > Also, out of curiosity is there are a way i can list all resources i can > access thanks either to UMA permission or policies? > That would be very handful. > You can do that by asking all permissions. See https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_obtaining_permissions . There is an cURL example there similar to this: curl -X POST \ http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \ -H "Authorization: Bearer ${access_token}" \ --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" In the example above you are basically, saying that you want a RPT for any resource/scope granted to the user as a result of evaluating permissions associated with resources which the either the user or resource server is the owner. But yeah, depending on how many resources you will get a huge RPT which can take some time to be issued. > > Suppose that you have an API that with GET /resources list you all the > resources, there should be a way to filter the returned resources > only based on the one you can access. This could be done easily if you > could get a list of the resources you can access. Otherwise, > you would need for each resource returned in the list to generate a query > asking if the user x can access the specific resource. Not very > scalable. > We don't have anything for data protection. You are not the first with this requirement but I did not spend time thinking about this capability yet. If you want to open a JIRA and start some discussion there I'm glad to move this forward. > > Thanks! > Federico > > > >> >> In our understanding, to obtain 2. we should some how retrieve the >> Requester from the TicketStore and attach the information to the response >> (but this would "break" the UMA standard, as anyhow parameters as >> "returnNames=true" do, so maybe when the request is using >> "returnNames=true" >> we could attach as well the requester name and it). >> >> For 1, we have no clear ideas, if not adding "requester" as well in the >> ticket creation. >> >> Any hint would be highly appreciated, so that we can work up some >> implementation to provide both features. >> >> Thanks, >> Federico >> >> -- >> *Dr. FEDERICO MICHELE FACCA* >> *Head of Martel Lab* >> 0041 78 807 58 38 >> *Martel Innovate* - Professional >> support for innovation projects >> Click to download our innovators' insights! >> >> Follow Us on Twitter >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > *Dr. FEDERICO MICHELE FACCA* > *Head of Martel Lab* > 0041 78 807 58 38 > *Martel Innovate* - Professional > support for innovation projects > Click to download our innovators' insights! > > Follow Us on Twitter > > From psilva at redhat.com Fri May 11 12:05:45 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 11 May 2018 13:05:45 -0300 Subject: [keycloak-dev] How to share a resource with a user via UMA 2.0 API In-Reply-To: References: Message-ID: Btw, just noticed we are discussing this in keycloak-dev. Could you please move discussion to keycloak-user mailing list ? On Fri, May 11, 2018 at 1:04 PM, Pedro Igor Silva wrote: > > > On Fri, May 11, 2018 at 10:19 AM, Federico Michele Facca < > federico.facca at martel-innovate.com> wrote: > >> Hi Pedro, >> >> Thanks a lot for your quick reply. >> >> On 11 May 2018, at 13:52, Pedro Igor Silva wrote: >> >>> >>> >> We don't have API documented, something we should improve in the future. >> >> We have a quickstart that can help you to achieve what you want. See >> https://github.com/keycloak/keycloak-quickstarts/tree/ >> latest/app-authz-uma-photoz. >> >> If you look this method: >> >> https://github.com/keycloak/keycloak-quickstarts/blob/late >> st/app-authz-uma-photoz/photoz-restful-api/src/main/java/ >> org/keycloak/example/photoz/album/AlbumService.java#L100 >> >> >> I have been looking at the methods, and actually learned from the exact >> example you refer to. >> >> >> You will see that we are using the Permission Endpoint (the endpoint >> responsible for managing permission tickets) to obtain all resources >> *shared* with a specific user. In our AuthZ Java Client we have this method: >> >> https://github.com/keycloak/keycloak/blob/master/authz/cli >> ent/src/main/java/org/keycloak/authorization/client/resource >> /PermissionResource.java#L162 >> >> Which allows you to query for permission tickets using different filters. >> >> >> Maybe my examples were not clear enough. For question 2: >> >> >> Suppose that user "test" owns resource A and he want to see (like in the >> my account interface) a table with all the active and pending permissions >> including the identifier of the user that made the request. >> >> Shared resources-> >> >> Resource A user B scope read, write >> >> Pending requests-> >> >> Resource A user C scope read >> >> >> With the following query: >> >> curl --request GET \ >> --url 'http://127.0.0.1:8080/auth/realms/master/authz/protection/ >> permission?returnNames=true&owner=test' \ >> --header 'authorization: Bearer xxx' >> >> I get a list of the permissions (where granted = true are the authorised >> ones and granted = false the pending ones): >> >> [ >> { >> "id": "08dccaed-6dbb-47aa-a87c-55b35a6f2523", >> "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", >> "resource": "218091a8-e5fc-460c-a306-a3a76775c784", >> "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", >> "granted": true, >> "scopeName": "read", >> "resourceName": "8910" >> }, >> { >> "id": ?xxxx", >> "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", >> "resource": "218091a8-e5fc-460c-a306-a3a76775c784", >> "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", >> "granted": false, >> "scopeName": "read", >> "resourceName": "8910" >> } >> ] >> >> so the result does not allow me to know who was the ?requester? (which I >> don?t know apriori since the query is about all potential requesters) >> > >> >> so my idea was that when you use returnNames=true parameter you could add >> as well the requester, e.g.: >> >> { >> "id": "08dccaed-6dbb-47aa-a87c-55b35a6f2523", >> "owner": "567c20ad-7d42-4908-bb53-af26c64534e7", >> "resource": "218091a8-e5fc-460c-a306-a3a76775c784", >> "scope": "65e40351-bce4-4e3f-825d-7bca9d78d12e", >> "granted": true, >> "scopeName": "read", >> "resourceName": ?8910?, >> ?requester?:?xxxxx?, >> ?requesterName?:?test? >> }, >> > > I see now. We are really missing *requester* in the response. Not sure why > it is not there already .... > > Created https://issues.jboss.org/browse/KEYCLOAK-7337. > > >> >> >> >> >> The type PermissionResource also provides methods for CRUD permission >> tickets. >> >> Note that this API is targeted for resource servers and part of the >> Protection API. >> >> >> >> We realised that by trying to create resources and seeing that using user >> authentication you get 500 error while using client authentication it works >> (even though UMA specs is not limiting the access to that). >> We found out by testing also that the permission endpoint works also with >> user access tokens. >> > > Yeah, as long as the access token is granted with uma_protection scope. > > >> >> Now the first question was how to ?share? directly a resource with a user. >> >> Currently using the API, supposing I am user A and I want to access a >> resource Z from user B, we proceed as follow (i hope is the correct way? >> any correction or guidance will be appreciated): >> >> 1. We create a permission request on the API (to get the ticket). E.g. >> read resource x >> >> 2. We use the ticket to ask for a rtp token using a user token. >> >> curl --request POST \ >> --url http://127.0.0.1:8080/auth/realms/master/protocol/openid-con >> nect/token \ >> --header 'Authorization: Bearer xxx' \ >> --header 'Content-Type: application/x-www-form-urlencoded' \ >> --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma- >> ticket&ticket=xxxx' >> >> If the user has already access, then he gets the rtp, if not he gets: >> >> { >> "error": "access_denied", >> "error_description": "request_submitted" >> } >> >> Only in this moment the permission ticket i created at step 1 appears in >> the list of permissions. (I am not sure this is the intended behaviour >> though). >> > > Yeah, that is the expected behavior. But you can also use a request > parameter to tell to the token endpoint that you don't want to submit an > authorization request. See https://www.keycloak.org/ > docs/latest/authorization_services/index.html#_service_authorization_aat. > > >> >> Then is up to the owner to authorise access (via API we can do that by >> updating the permission and set granted to true) >> >> Now let?s suppose that I am the owner of the resource A, and I want to >> authorise directly (without the user asking access to the resource A) >> the user Z to access it. How can I do that? At the time being I could not >> figure it out. >> > > Similar to the update method, you can use the create method to create > permissions. Is that what you are looking for ? See org.keycloak.testsuite. > authz.PermissionManagementTest#testCreatePermissionTicketWithResourceName. > > >> >> Also, out of curiosity is there are a way i can list all resources i can >> access thanks either to UMA permission or policies? >> That would be very handful. >> > > You can do that by asking all permissions. See https://www.keycloak.org/ > docs/latest/authorization_services/index.html#_service_ > obtaining_permissions. > > There is an cURL example there similar to this: > > curl -X POST \ > http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \ > -H "Authorization: Bearer ${access_token}" \ > --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" > > > In the example above you are basically, saying that you want a RPT for any > resource/scope granted to the user as a result of evaluating permissions > associated with resources which the either the user or resource server is > the owner. But yeah, depending on how many resources you will get a huge > RPT which can take some time to be issued. > > >> >> Suppose that you have an API that with GET /resources list you all the >> resources, there should be a way to filter the returned resources >> only based on the one you can access. This could be done easily if you >> could get a list of the resources you can access. Otherwise, >> you would need for each resource returned in the list to generate a query >> asking if the user x can access the specific resource. Not very >> scalable. >> > > We don't have anything for data protection. You are not the first with > this requirement but I did not spend time thinking about this capability > yet. If you want to open a JIRA and start some discussion there I'm glad to > move this forward. > > >> >> Thanks! >> Federico >> >> >> >>> >>> In our understanding, to obtain 2. we should some how retrieve the >>> Requester from the TicketStore and attach the information to the response >>> (but this would "break" the UMA standard, as anyhow parameters as >>> "returnNames=true" do, so maybe when the request is using >>> "returnNames=true" >>> we could attach as well the requester name and it). >>> >>> For 1, we have no clear ideas, if not adding "requester" as well in the >>> ticket creation. >>> >>> Any hint would be highly appreciated, so that we can work up some >>> implementation to provide both features. >>> >>> Thanks, >>> Federico >>> >>> -- >>> *Dr. FEDERICO MICHELE FACCA* >>> *Head of Martel Lab* >>> 0041 78 807 58 38 >>> *Martel Innovate* - Professional >>> support for innovation projects >>> Click to download our innovators' insights! >>> >>> Follow Us on Twitter >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> *Dr. FEDERICO MICHELE FACCA* >> *Head of Martel Lab* >> 0041 78 807 58 38 >> *Martel Innovate* - Professional >> support for innovation projects >> Click to download our innovators' insights! >> >> Follow Us on Twitter >> >> > From ckl86 at hotmail.com Sat May 12 22:03:41 2018 From: ckl86 at hotmail.com (Cristian Camilo Lopez Vidal) Date: Sun, 13 May 2018 02:03:41 +0000 Subject: [keycloak-dev] Support for MySQL 8 In-Reply-To: References: Message-ID: Greetings, I am migrating an app to MySQL 8 and I found some issues while migrating Keycloak (I?d like to have it in the same DB version, it's optional though). In order to do fix the issues with Keycloak I forked the keycloak docker images repo and I upgraded the JDBC driver dependency to 5.1.46 and I was able to connect to MySQL 8 but I got some issues because of the strict row size limits. The concrete error messages is " Error: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs [Failed SQL: ALTER TABLE keycloak.REALM MODIFY CERTIFICATE VARCHAR(4000)]: ? The MySQL documentation reference to this issue is https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html Then I forked the main Keycloak repo and I changed the liquibase migrations to use TEXT types instead of multiple big VARCHAR types for example VARCHAR(4000). I ran the test suite against the MySQL 8 database as stated here https://github.com/keycloak/keycloak/blob/master/misc/DatabaseTesting.md and everything worked fine. I posted two pull requests in GitHub to propose this change, is there anything else I should do to promote this change. Docker Image PR: https://github.com/jboss-dockerfiles/keycloak/pull/115 Keycloak Source PR: https://github.com/keycloak/keycloak/pull/5201 Looking forward to include this before the version 4 release is done. Thanks, Cristhian From isindir at users.sourceforge.net Mon May 14 14:39:32 2018 From: isindir at users.sourceforge.net (Eriks) Date: Mon, 14 May 2018 19:39:32 +0100 Subject: [keycloak-dev] OpenID role mappings from federated Realm Message-ID: Hello, We?re running Keycloak 3.4.3.Final and trying to configure OpenID role mappings from federated Realm down, like follows: <--- User federation <--- , where following role is created in : main_jenkins_admin and following role is created in federated realm : group_jenkins_admin We are trying to pass role "main_jenkins_admin" via "bearer" client in bearer token when user is defined in federated realm - and is granted "group_jenkins_admin" role. To achieve this we created a mapping in :"bearer" to map: :main_jenkins_admin to :group_jenkins_admin Following some tests, I found that if new user is created in and gets role assignment, like follows: in - group_jenkins_admin After first login, this user gets correct role assigned in : in - main_jenkins_admin If user existed before role mapping has been done on client level; and his account exists in both - and , than this role mapping is not working for this user. I think that this behaviour can be found in following code: * New user mappings creation: https://github.com/keycloak/keycloak/blob/master/services/sr c/main/java/org/keycloak/broker/oidc/mappers/ExternalKeycloa kRoleToRoleMapper.java#L94 * Update of existing user (which should happen on missing role only, hence not tested): https://github.com/keycloak/keycloak/blob/master/services/sr c/main/java/org/keycloak/broker/oidc/mappers/ExternalKeycloa kRoleToRoleMapper.java#L123 Can I create an issue in JIRA and may be start work on implementation for this or change to this code is not desired ? Thanks, Eriks From andreas.taube at collect.ai Tue May 15 08:56:10 2018 From: andreas.taube at collect.ai (Andreas Taube) Date: Tue, 15 May 2018 14:56:10 +0200 Subject: [keycloak-dev] Identity Provider / First Broker Login Flow Hooks Message-ID: Hey together, I would like to integrate with an external Identity Provider and I wonder about the best way to hook into this process? As soon as the external IP authorizes the user with a valid token I would like to do some internal setup calls and link metadata to the user (attributes) being created by Keycloak. I know it is possible to extend Keycloak with custom IdentityProviderMapper extensions but I would like to validate 1) if they are also meant to execute async http requests? 2) what happens if the request fails? 3) are there any other options better suited for this use case? Thanks for feedback Andreas From jcain at redhat.com Tue May 15 10:06:31 2018 From: jcain at redhat.com (Josh Cain) Date: Tue, 15 May 2018 09:06:31 -0500 Subject: [keycloak-dev] Adding a custom protocolmapper In-Reply-To: References: Message-ID: <1eff7e6e-b9bf-2a89-c365-d576b9803197@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Certainly possible, we've got 'em up and running. I'd make sure you've declared the appropriate keycloak modules in your jboss-web.xml. Sounds like something is missing on your classpath. Josh Cain Senior Software Applications Engineer, RHCE Red Hat North America jcain at redhat.com IRC: jcain On 05/04/2018 07:20 AM, Thomas Dupont (UGent-imec) wrote: > Hi, > > Is it at all possible to implement a custom protocolmapper that is > deployable via /opt/jboss/keycloak/standalone/deployements ? If my > class only implements ProtocolMapper, it works, but if it extends > AbstractOIDCProtocolMapper (which in itself implements > ProtocolMapper), my keycloak throws NoClassDefFound errors. > > This happens on both 4.0.0-beta1 and 4.0.0-beta2. > > Thanks, Thomas > > -- ir. Thomas Dupont Ghent University - imec IDLab, Office 200.010, > 10th floor iGent Tower - Department of Information Technology > Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium T: +32 9 33 > 14900 E: thomas.dupont at ugent.be W: idlab.ugent.be > > _______________________________________________ keycloak-dev > mailing list keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyXW6Vl+0L9r9LpVurGNtyYPQwPgFAlr66WYACgkQrGNtyYPQ wPjZTg/8CGx+/pEYn88bkBLfufIuzoQ0enoAmypztPEkKOKzJXuhGA1MlzXuDixE sHVfHrmU2f2Zl1unMZMMIvkwVq5HYZcXlWf1v66RruBh5483rl4i+m2Xll9ASQQR iTPhoD0P6/Y/lkeRL0Me4yHGY+UgWljbBuJV8W8OtNziQldpr7vImaM9y7sLDibW /gTQZMUY7NpIKMJV4WQL1Q+Vh4VFGOBtmOwr9W+z3ahu/3wVWlYJLp0StSljaFqq AGwhGooX9Pd8l/sJu5n7ZyQg8CcYis+bZ9oQulKrBvXPe9v9t5rPLyfTAssY4M2A XvdhaOaAqDTODRDorozPC0KrZS3ZLdebkLZ8nLbsjAd5u8uwn64ip3h2XSbS9ySi zpzt4NRvtr7tybu+YmUkJdDkFXbyGtI+zPvPdICh78Vm0UrdwClR251SCwJN2md1 x1vNMj9fuhFOTwdlDtW5zUK2qZZ9aC2grRGtxEiThjJ9JpRB3AI0WTNQrZMWGHdY 8g/oBmtjc+NCyztALzXgsyLit7XmuFIL6hbUlsQUx5uuuoV75jHajkRlvUlDQM7a 8ftEmWpPpYtmh3Pf1t/6LEpNz7SbLg1lAUX3mGskj8vA2qlZVsNmmi0hRSoPO8iO JIbSmAvC0Fw/YIOy/ic8BWjd+hqL1I7kEWdxBBrMrRyOKWDeuGE= =JFHt -----END PGP SIGNATURE----- From bruno at abstractj.org Tue May 15 10:58:34 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 15 May 2018 11:58:34 -0300 Subject: [keycloak-dev] Build on master broken? Message-ID: <20180515145834.GA21071@abstractj.org> Good morning, it's just me or the build on master is broken? I'm trying to do something really simple, build Keycloak on Linux in new machine and I'm getting: [10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : bin/go get github.com/inconshreveable/mousetrap [ERROR] [ERROR] ---------Exec.Err--------- [ERROR] package github.com/inconshreveable/mousetrap [ERROR]???????? imports runtime [ERROR]???????? imports runtime/internal/sys: cannot find package "runtime/internal/sys" in any of: [ERROR]???????? /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys (vendor tree) [ERROR]???????? /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys (from $GOROOT) [ERROR]???????? /home/abstractj/github/keycloak/testsuite/integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys (from $GOPATH) [ERROR]???????? /home/abstractj/github/keycloak/testsuite/integration-arquillian/tests/base/src/main/java/src/runtime/internal/sys [ERROR] It looks like mousetrap is a Windows specific dependency, so I believe we don't need this to be installed on Linux machines. Steps to reproduce: 1. rm -rf ~/.m2/repository/ or just mv :) 2. git clone git at github.com:keycloak/keycloak.git 3. mvn clean install -DskipTests=true Also looks like the following commit introduced the issue: https://github.com/keycloak/keycloak/commit/681e3d751e003b563f26b4105313eb69cdbda2ea Am I doing something wrong or missing some step? -- abstractj From jcain at redhat.com Tue May 15 11:47:39 2018 From: jcain at redhat.com (Josh Cain) Date: Tue, 15 May 2018 10:47:39 -0500 Subject: [keycloak-dev] Availability During Upgrades In-Reply-To: References: Message-ID: <6b50d3e9-c52a-f0ea-9d88-bdfba134e54b@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Yeah... until we get rolling updates, we just: - re-route traffic to secondary datacenter - kill all nodes in primary, run db scripts, and bring nodes back up - validate primary DC - switch traffic back to primary DC - Do the same for secondary DC Be careful here though - atm we don't have cross-datacenter replication turned on (we have an external source of truth for user information). If you have that, you're going to have to break the link and deal with potential data loss/sync issues in order to get this to work. Another +1 for "we'd really like this going forward!" Josh Cain Senior Software Applications Engineer, RHCE Red Hat North America jcain at redhat.com IRC: jcain On 05/03/2018 08:42 AM, Bill Burke wrote: > We had a recent Sprint to investigate rolling upgrades. This was > investigation only. I believe we have some plans for this down > the road, but it isn't something we support at the moment. From > what I remember, I believe that its more a matter of process and > testing. Process being to make sure that db schema changes and user > session serialization is backward compatible. Testing to ensure > and verify the process. Marek and Hynek might be able to give you > more info. > > On Thu, May 3, 2018 at 9:17 AM, gambol wrote: >> Hiya >> >> I was wondering if anyone has any recommendation in regard to >> high-availability during upgrades? or how people are handling >> service availability during a service update? Where as before we >> had leeway for the occasional midnight 30 downtime, as more >> projects on-aboard this is soon reaching the point where >> scheduled downtime unless an absolute emergency isn't >> acceptable. >> >> Rohith _______________________________________________ >> keycloak-dev mailing list keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyXW6Vl+0L9r9LpVurGNtyYPQwPgFAlr7ARsACgkQrGNtyYPQ wPhCFRAAimYxaao0o1bM6I8k9zPZKdjNG4uFqdnXe868sBHwlcdNSlZoXPl8+DmU 72SiYbjIG5XGoVRxxIFVWFWh9IdXsrLEztMXP9vx7wksXd8dDytaXAey1n0Si2+F mbwjasGV17dd3c/toDpoR+4CRVZLPQXgzYEXColj/8sEbpLlnGUbFs/JWK5wMrPD 28bmLL9p3BRwbD1B/exOcgatjJ06iqT+pu3RTbgvFdldXc0WfOzkzgt+kJzOCdm5 cbpXqB1oxxneH6vvwfKtZq8e6cOcQyxdTwd6Yb8hhPmtBXOgyVxsKptSKMlRQ04B zuZC/BniJCTlGs1S7s+IuEU/uNoP4NkE0Kz0/APYm/XWlNuLIHpMPmqoAcg+eTgg qwPxwOovr1dXXid83q0BlAFwH8LDZRAXumqeUumCAwfn+X94YYRkhS/mROE7gWjP wWrPoHi5cpA7sWcz01PRD4RR5SdVq3dOyOOc7+t6MY/LUeP+k6Mhrd18xQ4sYn3H 9NUOFih9mGYds404JOmPDCJYc9Bm+GQp3gRJHfFfsc633EHpGA8gY+KowVUpOAsm cS6ipKgH3AtW08ce+mOXi+ZT8TNvo31yXiKYhBI3/+3C3t/GX6R9EZ1tR29Fx9wf 22z/ysWJphRhJlWbB4sz8GeXeWk28pkTYPa5360AX04nBL7Ur+o= =oIkN -----END PGP SIGNATURE----- From josh.cummings at gmail.com Tue May 15 12:04:17 2018 From: josh.cummings at gmail.com (Josh Cummings) Date: Tue, 15 May 2018 10:04:17 -0600 Subject: [keycloak-dev] Spring Security 5.1 - Resource Server support In-Reply-To: References: Message-ID: Thomas, Sebi - Thanks for the feedback. I took your sample, Thomas, and was able to get it to work with our new resource server code (which is not yet integrated with @EnableResourceServer), though I will still check and see what might be the problem with the existing support. I've got a partially-working sample here, if you'd like to take a look: https://github.com/jzheaux/spring-security-oauth2-resource-server/blob/master/samples/boot/oauth2/resource-server/keycloak-with-client - Role extraction: Right now, you are already following the recommended approach listed here in the documentation: https://docs.spring.io/spring-security/site/docs/5.0.5.RELEASE/reference/htmlsingle/#oauth2login-advanced-map-authorities-oauth2userservice It sounds like you might be looking for something more targeted at extracting authorities from an OidcUserRequest? I've just added a ticket with some of my thoughts: https://github.com/spring-projects/spring-security/issues/5349 Since I think that the use case might be a little different on the resource server side, I added a separate ticket for that: https://github.com/jzheaux/spring-security-oauth2-resource-server/issues/37 (If it's not too confusing, you can add tickets specifically related to Resource Server to that dedicated repo) - Propagating logout to Keycloak: Thanks, added: https://github.com/spring-projects/spring-security/issues/5350 - Explicit configuration and Handling of access: You can track progress on these two here: https://github.com/spring-projects/spring-security/issues/4413 https://github.com/spring-projects/spring-security/issues/4371 Regarding multi-tenancy, we don't have specific plans, though I did look through your TenantAwareJwtDecoder and will continue thinking about this. I've added a ticket to get the discussion started: https://github.com/spring-projects/spring-security/issues/5351 Josh On Fri, May 11, 2018 at 7:02 AM, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hi Josh, Hi Sebi, > > having proper support for OAuth2 @EnableResourceServer in Spring Security > 5 would be very useful. > It would also be great if an application could use SSO and Enable > ResourceServer at the same time. > > I tried this with Spring Boot 2 and Spring Security 5 but I couldn't get > it to work. > > I build a demo application that uses SSO based on the OpenID Connect from > the latest > Spring Security 5 in a Spring Boot 2 app without the need for a Keycloak-adapter > library > with very little custom code for making the integration work. > Perhaps the example can help you to identify some gaps in the current > Spring Security OAuth2 / OIDC APIs. > The sources can be found here: https://github.com/thomasdarimont > /spring-boot-2-keycloak-oauth-example > > Here are some things that I either had to add or that are currently not > possible without more infrastructure plumbing: > > - Extracting and mapping of Keycloak roles to Spring Security roles. > Would be great to have a dedicated API for this - needed to do some > plumbing here. > See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth > -example/blob/master/src/main/java/demo/SpringBoot2App.java#L155 > > - Propagating logout to Keycloak > Could use the standardized OIDC "end_session_endpoint" from the > .well-known/openid-configuration endpoint. > See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth > -example/blob/master/src/main/java/demo/SpringBoot2App.java#L205 > > - Explicit configuration for oauth/oidc provider endpoints. > Would be great to just use the wellknon endpoint (http://localhost:8080/ > auth/realms/${realm}/.well-known/openid-configuration) > This would ease configuration quite significantly. > See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth > -example/blob/master/src/main/resources/application.yml#L23 > > - Handling of access / refresh token for service calls (currently missing) > Currently spring security (tested with 5.0.4.RELEASE) does only extracts > the IDToken / AccessToken from the OidcUserRequest > but not the refresh token. This would be necessary to retrieve new > AccessTokens for prolonged service interactions. > > Another topic is multi-tenancy support. For the example app mentioned > above I have a special branch called feature/multi-tenancy > that demonstrates a PoC of a hostname based approach for supporting > multiple realms / tenants. > Some of this is keycloak specific but I think this could be generalized > to a degree where the Keycloak specific parts could be reduced > to just a few lines of code / configuration. > > - Configuration > See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth > -example/blob/feature/mulit-tenancy/src/main/resources/application.yml#L29 > - Tenant selection > See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth > -example/blob/feature/mulit-tenancy/src/main/java/demo/ > SpringBoot2App.java#L127 > > Cheers, > Thomas > > Am Di., 8. Mai 2018 um 23:54 Uhr schrieb Sebastien Blanc < > sblanc at redhat.com>: > >> Hi Josh ! >> >> Thanks for pinging us about this ! We really appreciate your offer to >> collaborate. I will try ASAP playing with the new Spring Sec and share my >> findings with you. >> >> Seb >> >> >> Le mar. 8 mai 2018 ? 13:28, Josh Cummings a >> ?crit : >> >> > Hi, >> > >> > I'm not sure if you already know, but the Spring Security Team is >> > re-writing its support for OAuth2. We are planning on releasing initial >> > Resource Server support in 5.1 this September. >> > >> > I'd love to collaborate with you guys, especially while you are in >> beta, to >> > see if what we are writing is complementary to your goals. Perhaps we >> can >> > help remove some of your boilerplate, etc., say from your Spring >> Security >> > adapter. >> > >> > https://github.com/jzheaux/spring-security-oauth2-resource-server >> > >> > This is sort of a sandbox repo for Spring Security's new Resource Server >> > support. >> > >> > Would love your feedback. I'll be updating the repo with some integrated >> > Keycloak samples in the next few days. >> > >> > Thanks, >> > Josh >> > >> > -- >> > Josh Cummings >> > >> > Software Engineer | Teacher | Pi Fanatic | >> > https://www.linkedin.com/in/jzheaux | http://tech.joshuacummings.com >> > >> > _______________________________________________ >> > 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 > > -- Josh Cummings Software Engineer | Teacher | Pi Fanatic | https://www.linkedin.com/in/jzheaux | http://tech.joshuacummings.com | @jzheaux From federico.facca at martel-innovate.com Tue May 15 13:48:53 2018 From: federico.facca at martel-innovate.com (Federico Michele Facca) Date: Tue, 15 May 2018 19:48:53 +0200 Subject: [keycloak-dev] Build on master broken? In-Reply-To: <20180515145834.GA21071@abstractj.org> References: <20180515145834.GA21071@abstractj.org> Message-ID: not sure how to help, but i am not having the issue on MacOs x. On 15 May 2018 at 16:58, Bruno Oliveira wrote: > Good morning, it's just me or the build on master is broken? I'm trying > to do something really simple, build Keycloak on Linux in new machine > and I'm getting: > > [10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : bin/go > get github.com/inconshreveable/mousetrap > [ERROR] > [ERROR] ---------Exec.Err--------- > [ERROR] package github.com/inconshreveable/mousetrap > [ERROR] imports runtime > [ERROR] imports runtime/internal/sys: cannot find package > "runtime/internal/sys" in any of: > [ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys > (vendor tree) > [ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys > (from $GOROOT) > [ERROR] /home/abstractj/github/keycloak/testsuite/ > integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys > (from $GOPATH) > [ERROR] /home/abstractj/github/keycloak/testsuite/ > integration-arquillian/tests/base/src/main/java/src/runtime/internal/sys > [ERROR] > > It looks like mousetrap is a Windows specific dependency, so I believe > we don't need this to be installed on Linux machines. > > Steps to reproduce: > > 1. rm -rf ~/.m2/repository/ or just mv :) > 2. git clone git at github.com:keycloak/keycloak.git > 3. mvn clean install -DskipTests=true > > Also looks like the following commit introduced the issue: > https://github.com/keycloak/keycloak/commit/681e3d751e003b563f26b4105313eb > 69cdbda2ea > > Am I doing something wrong or missing some step? > > -- > > abstractj > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- *Dr. FEDERICO MICHELE FACCA* *Head of Martel Lab* 0041 78 807 58 38 *Martel Innovate* - Professional support for innovation projects Click to download our innovators' insights! Follow Us on Twitter From bburke at redhat.com Tue May 15 16:17:34 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 May 2018 16:17:34 -0400 Subject: [keycloak-dev] Build on master broken? In-Reply-To: References: <20180515145834.GA21071@abstractj.org> Message-ID: Its my stuff commit. I build on Fedora. And the CI is Linux too. This commit was a long time about like 6 weeks ago. I'll try and reproduce. Mousetrap is a windows dependency yes, but it should build on Linux. If you remove the mousetrap dependency in maven does it build? I think you can remove this now as mousetrap should be in vendor/ directory for kcinit. On Tue, May 15, 2018 at 1:48 PM, Federico Michele Facca wrote: > not sure how to help, but i am not having the issue on MacOs x. > > On 15 May 2018 at 16:58, Bruno Oliveira wrote: > >> Good morning, it's just me or the build on master is broken? I'm trying >> to do something really simple, build Keycloak on Linux in new machine >> and I'm getting: >> >> [10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : bin/go >> get github.com/inconshreveable/mousetrap >> [ERROR] >> [ERROR] ---------Exec.Err--------- >> [ERROR] package github.com/inconshreveable/mousetrap >> [ERROR] imports runtime >> [ERROR] imports runtime/internal/sys: cannot find package >> "runtime/internal/sys" in any of: >> [ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys >> (vendor tree) >> [ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys >> (from $GOROOT) >> [ERROR] /home/abstractj/github/keycloak/testsuite/ >> integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys >> (from $GOPATH) >> [ERROR] /home/abstractj/github/keycloak/testsuite/ >> integration-arquillian/tests/base/src/main/java/src/runtime/internal/sys >> [ERROR] >> >> It looks like mousetrap is a Windows specific dependency, so I believe >> we don't need this to be installed on Linux machines. >> >> Steps to reproduce: >> >> 1. rm -rf ~/.m2/repository/ or just mv :) >> 2. git clone git at github.com:keycloak/keycloak.git >> 3. mvn clean install -DskipTests=true >> >> Also looks like the following commit introduced the issue: >> https://github.com/keycloak/keycloak/commit/681e3d751e003b563f26b4105313eb >> 69cdbda2ea >> >> Am I doing something wrong or missing some step? >> >> -- >> >> abstractj >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > *Dr. FEDERICO MICHELE FACCA* > *Head of Martel Lab* > 0041 78 807 58 38 > *Martel Innovate* - Professional > support for innovation projects > Click to download our innovators' insights! > > Follow Us on Twitter > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From bburke at redhat.com Tue May 15 17:00:02 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 May 2018 17:00:02 -0400 Subject: [keycloak-dev] Build on master broken? In-Reply-To: References: <20180515145834.GA21071@abstractj.org> Message-ID: Master built for me fine. I did this: $ rm -rf .m2 $ rm -rf .mvnGoLang $ mvn clean install -DskipTests=true On Tue, May 15, 2018 at 4:17 PM, Bill Burke wrote: > Its my stuff commit. I build on Fedora. And the CI is Linux too. > This commit was a long time about like 6 weeks ago. I'll try and > reproduce. > > Mousetrap is a windows dependency yes, but it should build on Linux. > If you remove the mousetrap dependency in maven does it build? I > think you can remove this now as mousetrap should be in vendor/ > directory for kcinit. > > On Tue, May 15, 2018 at 1:48 PM, Federico Michele Facca > wrote: >> not sure how to help, but i am not having the issue on MacOs x. >> >> On 15 May 2018 at 16:58, Bruno Oliveira wrote: >> >>> Good morning, it's just me or the build on master is broken? I'm trying >>> to do something really simple, build Keycloak on Linux in new machine >>> and I'm getting: >>> >>> [10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : bin/go >>> get github.com/inconshreveable/mousetrap >>> [ERROR] >>> [ERROR] ---------Exec.Err--------- >>> [ERROR] package github.com/inconshreveable/mousetrap >>> [ERROR] imports runtime >>> [ERROR] imports runtime/internal/sys: cannot find package >>> "runtime/internal/sys" in any of: >>> [ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys >>> (vendor tree) >>> [ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys >>> (from $GOROOT) >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ >>> integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys >>> (from $GOPATH) >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ >>> integration-arquillian/tests/base/src/main/java/src/runtime/internal/sys >>> [ERROR] >>> >>> It looks like mousetrap is a Windows specific dependency, so I believe >>> we don't need this to be installed on Linux machines. >>> >>> Steps to reproduce: >>> >>> 1. rm -rf ~/.m2/repository/ or just mv :) >>> 2. git clone git at github.com:keycloak/keycloak.git >>> 3. mvn clean install -DskipTests=true >>> >>> Also looks like the following commit introduced the issue: >>> https://github.com/keycloak/keycloak/commit/681e3d751e003b563f26b4105313eb >>> 69cdbda2ea >>> >>> Am I doing something wrong or missing some step? >>> >>> -- >>> >>> abstractj >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> -- >> *Dr. FEDERICO MICHELE FACCA* >> *Head of Martel Lab* >> 0041 78 807 58 38 >> *Martel Innovate* - Professional >> support for innovation projects >> Click to download our innovators' insights! >> >> Follow Us on Twitter >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > Red Hat -- Bill Burke Red Hat From bruno at abstractj.org Wed May 16 10:26:12 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 May 2018 11:26:12 -0300 Subject: [keycloak-dev] Build on master broken? In-Reply-To: References: <20180515145834.GA21071@abstractj.org> Message-ID: Bingo! "rm -rf .mvnGoLang" did the trick for me. Nothing else was necessary to be changed. Thanks Bill On Tue, May 15, 2018 at 6:00 PM Bill Burke wrote: > Master built for me fine. I did this: > > $ rm -rf .m2 > $ rm -rf .mvnGoLang > $ mvn clean install -DskipTests=true > > > > On Tue, May 15, 2018 at 4:17 PM, Bill Burke wrote: > > Its my stuff commit. I build on Fedora. And the CI is Linux too. > > This commit was a long time about like 6 weeks ago. I'll try and > > reproduce. > > > > Mousetrap is a windows dependency yes, but it should build on Linux. > > If you remove the mousetrap dependency in maven does it build? I > > think you can remove this now as mousetrap should be in vendor/ > > directory for kcinit. > > > > On Tue, May 15, 2018 at 1:48 PM, Federico Michele Facca > > wrote: > >> not sure how to help, but i am not having the issue on MacOs x. > >> > >> On 15 May 2018 at 16:58, Bruno Oliveira wrote: > >> > >>> Good morning, it's just me or the build on master is broken? I'm trying > >>> to do something really simple, build Keycloak on Linux in new machine > >>> and I'm getting: > >>> > >>> [10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : > bin/go > >>> get github.com/inconshreveable/mousetrap > >>> [ERROR] > >>> [ERROR] ---------Exec.Err--------- > >>> [ERROR] package github.com/inconshreveable/mousetrap > >>> [ERROR] imports runtime > >>> [ERROR] imports runtime/internal/sys: cannot find package > >>> "runtime/internal/sys" in any of: > >>> [ERROR] > /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys > >>> (vendor tree) > >>> [ERROR] > /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys > >>> (from $GOROOT) > >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ > >>> > integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys > >>> (from $GOPATH) > >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ > >>> > integration-arquillian/tests/base/src/main/java/src/runtime/internal/sys > >>> [ERROR] > >>> > >>> It looks like mousetrap is a Windows specific dependency, so I believe > >>> we don't need this to be installed on Linux machines. > >>> > >>> Steps to reproduce: > >>> > >>> 1. rm -rf ~/.m2/repository/ or just mv :) > >>> 2. git clone git at github.com:keycloak/keycloak.git > >>> 3. mvn clean install -DskipTests=true > >>> > >>> Also looks like the following commit introduced the issue: > >>> > https://github.com/keycloak/keycloak/commit/681e3d751e003b563f26b4105313eb > >>> 69cdbda2ea > >>> > >>> Am I doing something wrong or missing some step? > >>> > >>> -- > >>> > >>> abstractj > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> > >> -- > >> *Dr. FEDERICO MICHELE FACCA* > >> *Head of Martel Lab* > >> 0041 78 807 58 38 > >> *Martel Innovate* - Professional > >> support for innovation projects > >> Click to download our innovators' insights! > >> > >> Follow Us on Twitter > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > > Bill Burke > > Red Hat > > > > -- > Bill Burke > Red Hat > From bburke at redhat.com Wed May 16 11:04:20 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 16 May 2018 11:04:20 -0400 Subject: [keycloak-dev] Build on master broken? In-Reply-To: References: <20180515145834.GA21071@abstractj.org> Message-ID: Weird, not sure what was wrong with .mvnGoLang for you. On Wed, May 16, 2018 at 10:26 AM, Bruno Oliveira wrote: > Bingo! "rm -rf .mvnGoLang" did the trick for me. Nothing else was necessary > to be changed. > > Thanks Bill > > On Tue, May 15, 2018 at 6:00 PM Bill Burke wrote: >> >> Master built for me fine. I did this: >> >> $ rm -rf .m2 >> $ rm -rf .mvnGoLang >> $ mvn clean install -DskipTests=true >> >> >> >> On Tue, May 15, 2018 at 4:17 PM, Bill Burke wrote: >> > Its my stuff commit. I build on Fedora. And the CI is Linux too. >> > This commit was a long time about like 6 weeks ago. I'll try and >> > reproduce. >> > >> > Mousetrap is a windows dependency yes, but it should build on Linux. >> > If you remove the mousetrap dependency in maven does it build? I >> > think you can remove this now as mousetrap should be in vendor/ >> > directory for kcinit. >> > >> > On Tue, May 15, 2018 at 1:48 PM, Federico Michele Facca >> > wrote: >> >> not sure how to help, but i am not having the issue on MacOs x. >> >> >> >> On 15 May 2018 at 16:58, Bruno Oliveira wrote: >> >> >> >>> Good morning, it's just me or the build on master is broken? I'm >> >>> trying >> >>> to do something really simple, build Keycloak on Linux in new machine >> >>> and I'm getting: >> >>> >> >>> [10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : >> >>> bin/go >> >>> get github.com/inconshreveable/mousetrap >> >>> [ERROR] >> >>> [ERROR] ---------Exec.Err--------- >> >>> [ERROR] package github.com/inconshreveable/mousetrap >> >>> [ERROR] imports runtime >> >>> [ERROR] imports runtime/internal/sys: cannot find package >> >>> "runtime/internal/sys" in any of: >> >>> [ERROR] >> >>> /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys >> >>> (vendor tree) >> >>> [ERROR] >> >>> /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys >> >>> (from $GOROOT) >> >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ >> >>> >> >>> integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys >> >>> (from $GOPATH) >> >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ >> >>> >> >>> integration-arquillian/tests/base/src/main/java/src/runtime/internal/sys >> >>> [ERROR] >> >>> >> >>> It looks like mousetrap is a Windows specific dependency, so I believe >> >>> we don't need this to be installed on Linux machines. >> >>> >> >>> Steps to reproduce: >> >>> >> >>> 1. rm -rf ~/.m2/repository/ or just mv :) >> >>> 2. git clone git at github.com:keycloak/keycloak.git >> >>> 3. mvn clean install -DskipTests=true >> >>> >> >>> Also looks like the following commit introduced the issue: >> >>> >> >>> https://github.com/keycloak/keycloak/commit/681e3d751e003b563f26b4105313eb >> >>> 69cdbda2ea >> >>> >> >>> Am I doing something wrong or missing some step? >> >>> >> >>> -- >> >>> >> >>> abstractj >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> >> >> >> >> >> -- >> >> *Dr. FEDERICO MICHELE FACCA* >> >> *Head of Martel Lab* >> >> 0041 78 807 58 38 >> >> *Martel Innovate* - Professional >> >> support for innovation projects >> >> Click to download our innovators' insights! >> >> >> >> Follow Us on Twitter >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> >> >> >> -- >> Bill Burke >> Red Hat -- Bill Burke Red Hat From bruno at abstractj.org Wed May 16 11:28:09 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 May 2018 12:28:09 -0300 Subject: [keycloak-dev] Build on master broken? In-Reply-To: References: <20180515145834.GA21071@abstractj.org> Message-ID: There are some corner cases which you have to recompile the runtime package from Go to get it working (https://github.com/golang/go/issues/14816). So here's my theory: I had the backups from my previous machine running Fedora 27. I restored then in the new machine with Fedora 28, including $HOME/.mvnGoLang. When I ran our build, certainly the mvn Go plugin identified that the existent path and tried to reuse the libs compiled to the previous architecture. For our CI this will never happen, because the environment will always be fresh. So thankfully, we don't have to worry about it. On Wed, May 16, 2018 at 12:04 PM Bill Burke wrote: > Weird, not sure what was wrong with .mvnGoLang for you. > > On Wed, May 16, 2018 at 10:26 AM, Bruno Oliveira > wrote: > > Bingo! "rm -rf .mvnGoLang" did the trick for me. Nothing else was > necessary > > to be changed. > > > > Thanks Bill > > > > On Tue, May 15, 2018 at 6:00 PM Bill Burke wrote: > >> > >> Master built for me fine. I did this: > >> > >> $ rm -rf .m2 > >> $ rm -rf .mvnGoLang > >> $ mvn clean install -DskipTests=true > >> > >> > >> > >> On Tue, May 15, 2018 at 4:17 PM, Bill Burke wrote: > >> > Its my stuff commit. I build on Fedora. And the CI is Linux too. > >> > This commit was a long time about like 6 weeks ago. I'll try and > >> > reproduce. > >> > > >> > Mousetrap is a windows dependency yes, but it should build on Linux. > >> > If you remove the mousetrap dependency in maven does it build? I > >> > think you can remove this now as mousetrap should be in vendor/ > >> > directory for kcinit. > >> > > >> > On Tue, May 15, 2018 at 1:48 PM, Federico Michele Facca > >> > wrote: > >> >> not sure how to help, but i am not having the issue on MacOs x. > >> >> > >> >> On 15 May 2018 at 16:58, Bruno Oliveira wrote: > >> >> > >> >>> Good morning, it's just me or the build on master is broken? I'm > >> >>> trying > >> >>> to do something really simple, build Keycloak on Linux in new > machine > >> >>> and I'm getting: > >> >>> > >> >>> [10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : > >> >>> bin/go > >> >>> get github.com/inconshreveable/mousetrap > >> >>> [ERROR] > >> >>> [ERROR] ---------Exec.Err--------- > >> >>> [ERROR] package github.com/inconshreveable/mousetrap > >> >>> [ERROR] imports runtime > >> >>> [ERROR] imports runtime/internal/sys: cannot find package > >> >>> "runtime/internal/sys" in any of: > >> >>> [ERROR] > >> >>> > /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys > >> >>> (vendor tree) > >> >>> [ERROR] > >> >>> > /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys > >> >>> (from $GOROOT) > >> >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ > >> >>> > >> >>> > integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys > >> >>> (from $GOPATH) > >> >>> [ERROR] /home/abstractj/github/keycloak/testsuite/ > >> >>> > >> >>> > integration-arquillian/tests/base/src/main/java/src/runtime/internal/sys > >> >>> [ERROR] > >> >>> > >> >>> It looks like mousetrap is a Windows specific dependency, so I > believe > >> >>> we don't need this to be installed on Linux machines. > >> >>> > >> >>> Steps to reproduce: > >> >>> > >> >>> 1. rm -rf ~/.m2/repository/ or just mv :) > >> >>> 2. git clone git at github.com:keycloak/keycloak.git > >> >>> 3. mvn clean install -DskipTests=true > >> >>> > >> >>> Also looks like the following commit introduced the issue: > >> >>> > >> >>> > https://github.com/keycloak/keycloak/commit/681e3d751e003b563f26b4105313eb > >> >>> 69cdbda2ea > >> >>> > >> >>> Am I doing something wrong or missing some step? > >> >>> > >> >>> -- > >> >>> > >> >>> abstractj > >> >>> _______________________________________________ > >> >>> keycloak-dev mailing list > >> >>> keycloak-dev at lists.jboss.org > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> *Dr. FEDERICO MICHELE FACCA* > >> >> *Head of Martel Lab* > >> >> 0041 78 807 58 38 > >> >> *Martel Innovate* - > Professional > >> >> support for innovation projects > >> >> Click to download our innovators' insights! > >> >> > >> >> Follow Us on Twitter > >> >> _______________________________________________ > >> >> keycloak-dev mailing list > >> >> keycloak-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > >> > > >> > > >> > -- > >> > Bill Burke > >> > Red Hat > >> > >> > >> > >> -- > >> Bill Burke > >> Red Hat > > > > -- > Bill Burke > Red Hat > From aszczucz at redhat.com Wed May 16 19:09:52 2018 From: aszczucz at redhat.com (Alex Szczuczko) Date: Wed, 16 May 2018 17:09:52 -0600 Subject: [keycloak-dev] Current usage of mvn-golang-wrapper not compatible with product builds Message-ID: <152651219231.5791.16820338549746578469@tyrfing> Hi, I found a productization issue that was introduced to master after 7.2.x was split off, so it's an issue for 7.3 and continuous prod. Specifically, mvn-golang-wrapper depends on storage.googleapis.com and github.com. See KEYCLOAK-7362 for more details [1]. Bill, I'm CC'ing you, since you introduced this plugin in commit 681e3d. Fortunately we don't actually run the test suite as part of the product build itself, so I've filed a PR to skip this plugin in the product build. This should be good enough for now, but we'll need a better solution, as I elaborate on in this[3] comment on JIRA. Alex [1] https://issues.jboss.org/browse/KEYCLOAK-7362 [2] https://github.com/keycloak/keycloak/pull/5208 [3] https://issues.jboss.org/browse/KEYCLOAK-7362?focusedCommentId=13577836#comment-13577836 From shmuein+keycloak-dev at gmail.com Wed May 16 19:13:50 2018 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Wed, 16 May 2018 18:13:50 -0500 Subject: [keycloak-dev] POST method for OIDC Authorization End Point Message-ID: Hi all, I have a quick question, does Keycloak support POST method for OIDC Authorization Request? I was trying to integration Keycloak with an SP, which is using POST for Auth request and Keycloak rejects the request with "405 Method Not Allowed" Error. I looked at the OIDC Specs and accordingly, to that both GET and POST should be supported for Authorization Request. Maybe I am missing something, can someone please shed some light on this. This also makes me wonder, is the Keycloak fully compliant with OIDC Specs? did we run any compliance tests to confirm this? Best regards, Muein From mposolda at redhat.com Thu May 17 04:54:49 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 17 May 2018 10:54:49 +0200 Subject: [keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback In-Reply-To: References: Message-ID: <6ad0dd1b-eb07-f4ec-87ef-23a9de946da1@redhat.com> +1 for the fix like this. I think the performance won't be big issue as SPNEGO authenticator on Keycloak side calls "gssContext.acceptSecContext" which itself is offline validation and doesn't need to talk to Kerberos server. I will need to doublecheck this. There will be some minor performance penalty as more providers will need to be tried, but that's always the case when you have more providers (EG. when you have 5 userStorage providers and you call "getUserByEmail", you can fail 4 providers until user is found in 5th provider). Also we may finally need performance tests for SPNEGO (and LDAP) scenarios, but that's another topic. IMO the fix itself won't be hard, but biggest effort would be automated test. We may need to add test with multiple Kerberos servers. Also make sure that it works not just with default ApacheDS, but with MSAD etc. But maybe it's sufficient as the 2nd server to always use ApacheDS? Will be good to test also the scenario with same Kerberos server and multiple LDAP providers to check the replay issue. Also to check that it works for both LDAP provider and Kerberos provider. Marek Dne 8.5.2018 v 14:22 Bill Burke napsal(a): > The null return should be line 689 in LDAPStorageProvider. Logger > should probably be debug instead of warn too. > > UserModel user = > findOrCreateAuthenticatedUser(realm, username); > > if (user == null) { > logger.warnf("Kerberos/SPNEGO authentication > succeeded with username [%s], but couldn't find or create user with > federation provider [%s]", username, model.getName()); > return null;// OLD CODE IS ----> > CredentialValidationOutput.failed(); > > The authenticate method should return null too I believe. I have to > talk to Marek though about this. Kerberos token validation would be > redone for each LDAP provider. I don't know if this is an expensive > operation or not and wonder if it should be optimized > > > On Tue, May 8, 2018 at 8:07 AM, Bill Burke wrote: >> Ugh, sorry...that's not it...Sorry, I haven't looked at this code in a >> long time and I'm not the original author either.... >> >> If you are using Kerberos backed by LDAP, then you should not be using >> the KerberosFederationProvider. You should be enabling kerberos auth >> on your LDAP provider. See this: >> >> https://www.keycloak.org/docs/latest/server_admin/index.html#_kerberos >> >> >> On Tue, May 8, 2018 at 7:59 AM, Bill Burke wrote: >>> But maybe I'm not understanding the problem. JIRA seems to state that >>> it is one Kerberos realm, and multiple LDAP servers. That's your >>> situation too, right? >>> >>> On Tue, May 8, 2018 at 7:48 AM, Bill Burke wrote: >>>> At first glance, this doesn't look like the correct fix. Looks like >>>> the Kerberos Provider is looking for the user in local storage only. >>>> See line 233 of KerberosFederationProvider. >>>> >>>> findOrCreateAuthenticatedUser() >>>> >>>> UserModel user = >>>> session.userLocalStorage().getUserByUsername(username, realm); >>>> >>>> I think you need to change this to >>>> session.users().getUserByUsername(). This might have fallen through >>>> the cracks when we ported to the new user storage SPI. >>>> >>>> On Tue, May 8, 2018 at 5:04 AM, Jim Groffen wrote: >>>>> Hello folks, >>>>> >>>>> I am using Keycloak with multiple Kerberos user federations, and am >>>>> affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the >>>>> first user federation will attempt Kerberos auth. >>>>> >>>>> I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this >>>>> works great for me. >>>>> >>>>> Ricardo's suggestion is to change SPNEGO authenticators in LDAP and >>>>> Kerberos user federations to return null instead of 'failed' or 'continue'. >>>>> A null return value causes the UserCredentialStoreManager to continue to >>>>> the next auth provider instead of failing the Kerberos auth attempt for all >>>>> providers if the first provider fails. >>>>> >>>>> I have tested these changes in my deploy and would like to provide a pull >>>>> request, but I need some review and maybe a suggestion on how to add a >>>>> test. The following commit has the changes I've made so far: >>>>> >>>>> https://github.com/jgroffen/keycloak/commit/634854748ba40ba20432540ac27f79a3c37874e2 >>>>> >>>>> Note I've reduced log noise as authentication attempts are expected to fail >>>>> when the Kerberos provider and user realm don't match. >>>>> >>>>> Ricardo had further problems with a false-positive replay attack - my >>>>> situation is not affected by this problem so I'd like to push ahead with >>>>> this intermediary fix if possible. I'm unaffected because I have separate >>>>> realms with no trust, and separate keytab files per federation that contain >>>>> only the relevant keytab entry. >>>>> >>>>> Thanks in advance! >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>> >>> >>> -- >>> Bill Burke >>> Red Hat >> >> >> -- >> Bill Burke >> Red Hat > > From mposolda at redhat.com Thu May 17 04:56:53 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 17 May 2018 10:56:53 +0200 Subject: [keycloak-dev] Error loading KeycloakHotRodMarshallerFactory In-Reply-To: References: <39419bd0-3d55-bd3e-0ae2-68d1f1d87ca5@redhat.com> Message-ID: <21e32057-8e4f-cb59-1c61-2753b5abe5cf@redhat.com> Could you please create JIRA for this? With steps to reproduce and how exactly you configure domain.xml? We didn't yet try setup with domain, so will be good to try and document what is needed here. Marek Dne 7.5.2018 v 21:45 Adrien DESBIAUX napsal(a): > > Hi Marek, > > > Many thanks for your reply. > > > Yes, I did add it. I followed the documentation. The HA mode looks > like not throwing the error. However?Domain mode does not go through > successfully. > > > Cheers, > > > ------------------------------------------------------------------------ > *From:* Marek Posolda > *Sent:* Monday, May 7, 2018 6:29:12 PM > *To:* Adrien DESBIAUX; keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Error loading > KeycloakHotRodMarshallerFactory > Hi, > > did you added |module="org.keycloak.keycloak-model-infinispan" to the > cache-container element? > > Thanks, > Marek| > > Dne 7.5.2018 v 13:47 Adrien DESBIAUX napsal(a): >> Hello, >> >> >> I am facing an issue in regards to launching Keycloak 3.4 in Domain mode with an external Infinispan cluster. >> >> >> I following error is thrown: >> >> >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory from >> [Module "org.wildfly.clustering.service" from local module loader @7a0ac6e3 >> (finder: local module finder @71be98f5 (roots: >> /opt/jboss/keycloak-3.4.3.Final/modules,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/keycloak,/opt/jboss/keycloak-3.4.3.Final/modules/system/layers/base))] >> >> >> >> I don't get this error when using the standalone-ha mode. >> >> >> Did you test the Multi datacenter configurationh with the domain mode already? >> >> https://www.keycloak.org/docs/latest/server_installation/index.html#_domain-mode >> >> >> Guide Overview - Keycloak >> >> www.keycloak.org >> >> The purpose of this guide is to walk through the steps that need to be completed prior to booting up the Keycloak server for the first time. If you just want to test drive Keycloak, it pretty much runs out of the box with its own embedded and local-only database. >> >> >> Why would be the class KeycloakHotRodMarshallerFactory not correctly loaded in domain mode? >> >> I will keep searching but would be happy if some of you would have time to share their opinion on this. >> >> >> >> Thank you in advance for your direction. >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From sergey at shimkiv.com Thu May 17 06:02:40 2018 From: sergey at shimkiv.com (Serhii Shymkiv) Date: Thu, 17 May 2018 13:02:40 +0300 Subject: [keycloak-dev] Fwd: An ability to evaluate/transform the template variables during the SAML/OpenID protocol mappers processing In-Reply-To: References: Message-ID: No luck with Users list, trying the Devs one ... ---------- Forwarded message ---------- From: Serhii Shymkiv Date: Sat, Apr 21, 2018 at 9:11 PM Subject: An ability to evaluate/transform the template variables during the SAML/OpenID protocol mappers processing To: keycloak-user at lists.jboss.org Hello Guys, current email thread is inspired by the https://github.com/keycloak/ keycloak/pull/5042 and the question for the community is: - what do you think if the Keycloak will have an ability to evaluate/transform the template variables during the SAML/OpenID protocol mappers processing ? Examples (please refer to the attached "snapshot-1.png" and "snapshot-2.png"): 1. "snapshot-1.png": ${firstName} ${lastName} => the simplest expression, the template variables will be evaluated into the real values of the user (in this case) properties => e.g.: "Serhii Shymkiv" (without quotes, of course) 2. "snapshot-2.png": Welcome back, #(${firstName} ${lastName}) ?: ${email} => almost the same expression but with additional logic which means that the value of the #(...) block will be used only if it is not blank (null or space symbols only) otherwise the expression to the right of the ?: operator will be evaluated => e.g.: "Welcome back, Serhii Shymkiv" e.g.: "Welcome back, sergey at shimkiv.com" Thank you for you time. -- Best regards, Serhii Shymkiv. -- Best regards, Serhii Shymkiv. -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot-1.png Type: image/png Size: 32632 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20180517/6e0a5c26/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot-2.png Type: image/png Size: 36018 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20180517/6e0a5c26/attachment-0003.png From hartror at gmail.com Thu May 17 07:16:34 2018 From: hartror at gmail.com (Rory Hart) Date: Thu, 17 May 2018 21:16:34 +1000 Subject: [keycloak-dev] Configuring session timeouts on the Keycloak Security Proxy Message-ID: Hi folks I'd like to be able to control how long a session takes to timeout in the keycloak security proxy, the default 30 minutes (via the Undertow InMemorySessionManager) isn't enough for our usage. I am happy to put a PR together for this if it is a feature that will be accepted? Thanks Rory Hart From thomas.darimont at googlemail.com Thu May 17 08:35:30 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 17 May 2018 13:35:30 +0100 Subject: [keycloak-dev] Fwd: An ability to evaluate/transform the template variables during the SAML/OpenID protocol mappers processing In-Reply-To: References: Message-ID: Hi Sergey, for OIDC you can already do something like this via the Script Protocol Mapper which allows to compute the result value via JavaScript. See: - https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/mappers/ScriptBasedOIDCProtocolMapper.java - https://github.com/keycloak/keycloak/pull/4495 I didn't have the time yet to implement the same for the SAML protocol mapper, but there is a JIRA issue: https://issues.jboss.org/browse/KEYCLOAK-5520 Support for template interpolation via a dedicated protocol mapper would be nicer though, since it would allow for more concise mapper definitions. Cheers, Thomas Am Do., 17. Mai 2018 um 11:04 Uhr schrieb Serhii Shymkiv : > No luck with Users list, trying the Devs one ... > > > ---------- Forwarded message ---------- > From: Serhii Shymkiv > Date: Sat, Apr 21, 2018 at 9:11 PM > Subject: An ability to evaluate/transform the template variables during the > SAML/OpenID protocol mappers processing > To: keycloak-user at lists.jboss.org > > > Hello Guys, > current email thread is inspired by the https://github.com/keycloak/ > keycloak/pull/5042 > and the question for the community is: > - what do you think if the Keycloak will have an ability to > evaluate/transform the template variables during the SAML/OpenID protocol > mappers processing ? > > Examples (please refer to the attached "snapshot-1.png" and > "snapshot-2.png"): > 1. "snapshot-1.png": > ${firstName} ${lastName} > => > the simplest expression, the template variables will be evaluated into > the real values of the user (in this case) properties > => > e.g.: "Serhii Shymkiv" (without quotes, of course) > 2. "snapshot-2.png": > Welcome back, #(${firstName} ${lastName}) ?: ${email} > => > almost the same expression but with additional logic which means that > the value of the #(...) block will be used only if it is not blank (null or > space symbols only) otherwise the expression to the right of the ?: > operator will be evaluated > => > e.g.: "Welcome back, Serhii Shymkiv" > e.g.: "Welcome back, sergey at shimkiv.com" > > Thank you for you time. > > > > > -- > Best regards, > Serhii Shymkiv. > > > > -- > Best regards, > Serhii Shymkiv. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu May 17 08:30:39 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 May 2018 08:30:39 -0400 Subject: [keycloak-dev] Current usage of mvn-golang-wrapper not compatible with product builds In-Reply-To: <152651219231.5791.16820338549746578469@tyrfing> References: <152651219231.5791.16820338549746578469@tyrfing> Message-ID: Ok, thanks for fixing. I'd hate for us to have to have to go beyond maven and create a build script. The big benefit of the plugin is that it builds the binary targeted to the platform the testsuite is running in (i.e. Windows or Linux or MacOSX). If product doesn't run the testsuite, do we really need a better solution? On Wed, May 16, 2018 at 7:09 PM, Alex Szczuczko wrote: > Hi, > > I found a productization issue that was introduced to master after 7.2.x > was split off, so it's an issue for 7.3 and continuous prod. > Specifically, mvn-golang-wrapper depends on storage.googleapis.com and > github.com. See KEYCLOAK-7362 for more details [1]. > > Bill, I'm CC'ing you, since you introduced this plugin in commit 681e3d. > > Fortunately we don't actually run the test suite as part of the product > build itself, so I've filed a PR to skip this plugin in the product > build. This should be good enough for now, but we'll need a better > solution, as I elaborate on in this[3] comment on JIRA. > > Alex > > [1] https://issues.jboss.org/browse/KEYCLOAK-7362 > [2] https://github.com/keycloak/keycloak/pull/5208 > [3] https://issues.jboss.org/browse/KEYCLOAK-7362?focusedCommentId=13577836#comment-13577836 -- Bill Burke Red Hat From bburke at redhat.com Thu May 17 10:04:47 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 May 2018 10:04:47 -0400 Subject: [keycloak-dev] POST method for OIDC Authorization End Point In-Reply-To: References: Message-ID: Marek will have to elaborate, but we passed oidc certification. On Wed, May 16, 2018 at 7:13 PM, Muein Muzamil wrote: > Hi all, > > I have a quick question, does Keycloak support POST method for OIDC > Authorization Request? I was trying to integration Keycloak with an SP, > which is using POST for Auth request and Keycloak rejects the request with > "405 Method Not Allowed" Error. > > I looked at the OIDC Specs and accordingly, to that both GET and POST > should be supported for Authorization Request. Maybe I am missing > something, can someone please shed some light on this. > > This also makes me wonder, is the Keycloak fully compliant with OIDC Specs? > did we run any compliance tests to confirm this? > > Best regards, > Muein > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From aszczucz at redhat.com Thu May 17 13:59:59 2018 From: aszczucz at redhat.com (Alex Szczuczko) Date: Thu, 17 May 2018 11:59:59 -0600 Subject: [keycloak-dev] Current usage of mvn-golang-wrapper not compatible with product builds In-Reply-To: References: <152651219231.5791.16820338549746578469@tyrfing> Message-ID: <152657999904.22072.1343679601898237365@tyrfing> As long as it's confined to the testsuite, I suppose a better solution won't be needed. Would you happen to have the time to review and merge my PR? Thanks, Alex Quoting Bill Burke (2018-05-17 06:30:39) > Ok, thanks for fixing. I'd hate for us to have to have to go beyond > maven and create a build script. The big benefit of the plugin is > that it builds the binary targeted to the platform the testsuite is > running in (i.e. Windows or Linux or MacOSX). > > If product doesn't run the testsuite, do we really need a better solution? > > On Wed, May 16, 2018 at 7:09 PM, Alex Szczuczko wrote: > > Hi, > > > > I found a productization issue that was introduced to master after 7.2.x > > was split off, so it's an issue for 7.3 and continuous prod. > > Specifically, mvn-golang-wrapper depends on storage.googleapis.com and > > github.com. See KEYCLOAK-7362 for more details [1]. > > > > Bill, I'm CC'ing you, since you introduced this plugin in commit 681e3d. > > > > Fortunately we don't actually run the test suite as part of the product > > build itself, so I've filed a PR to skip this plugin in the product > > build. This should be good enough for now, but we'll need a better > > solution, as I elaborate on in this[3] comment on JIRA. > > > > Alex > > > > [1] https://issues.jboss.org/browse/KEYCLOAK-7362 > > [2] https://github.com/keycloak/keycloak/pull/5208 > > [3] https://issues.jboss.org/browse/KEYCLOAK-7362?focusedCommentId=13577836#comment-13577836 From bburke at redhat.com Thu May 17 14:45:39 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 May 2018 14:45:39 -0400 Subject: [keycloak-dev] Current usage of mvn-golang-wrapper not compatible with product builds In-Reply-To: <152657999904.22072.1343679601898237365@tyrfing> References: <152651219231.5791.16820338549746578469@tyrfing> <152657999904.22072.1343679601898237365@tyrfing> Message-ID: Approved. I didn't merge though. On Thu, May 17, 2018 at 1:59 PM, Alex Szczuczko wrote: > As long as it's confined to the testsuite, I suppose a better solution > won't be needed. > > Would you happen to have the time to review and merge my PR? > > Thanks, > Alex > > Quoting Bill Burke (2018-05-17 06:30:39) >> Ok, thanks for fixing. I'd hate for us to have to have to go beyond >> maven and create a build script. The big benefit of the plugin is >> that it builds the binary targeted to the platform the testsuite is >> running in (i.e. Windows or Linux or MacOSX). >> >> If product doesn't run the testsuite, do we really need a better solution? >> >> On Wed, May 16, 2018 at 7:09 PM, Alex Szczuczko wrote: >> > Hi, >> > >> > I found a productization issue that was introduced to master after 7.2.x >> > was split off, so it's an issue for 7.3 and continuous prod. >> > Specifically, mvn-golang-wrapper depends on storage.googleapis.com and >> > github.com. See KEYCLOAK-7362 for more details [1]. >> > >> > Bill, I'm CC'ing you, since you introduced this plugin in commit 681e3d. >> > >> > Fortunately we don't actually run the test suite as part of the product >> > build itself, so I've filed a PR to skip this plugin in the product >> > build. This should be good enough for now, but we'll need a better >> > solution, as I elaborate on in this[3] comment on JIRA. >> > >> > Alex >> > >> > [1] https://issues.jboss.org/browse/KEYCLOAK-7362 >> > [2] https://github.com/keycloak/keycloak/pull/5208 >> > [3] https://issues.jboss.org/browse/KEYCLOAK-7362?focusedCommentId=13577836#comment-13577836 -- Bill Burke Red Hat From aszczucz at redhat.com Thu May 17 15:19:50 2018 From: aszczucz at redhat.com (Alex Szczuczko) Date: Thu, 17 May 2018 13:19:50 -0600 Subject: [keycloak-dev] Current usage of mvn-golang-wrapper not compatible with product builds In-Reply-To: References: <152651219231.5791.16820338549746578469@tyrfing> <152657999904.22072.1343679601898237365@tyrfing> Message-ID: <152658479064.22072.7671606374067989459@tyrfing> Thanks. The reason I asked for a merge too is that I don't have permission to do so myself, and we don't have an automerge bot yet. Quoting Bill Burke (2018-05-17 12:45:39) > Approved. I didn't merge though. From mposolda at redhat.com Thu May 17 15:39:37 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 17 May 2018 21:39:37 +0200 Subject: [keycloak-dev] POST method for OIDC Authorization End Point In-Reply-To: References: Message-ID: Yes, the AuthorizationEndpoint currently supports just GET. This is not correct according to specs, we should add POST too. Could you please create JIRA? It seems that certification didn't have a test for this :) Marek Dne 17.5.2018 v 16:04 Bill Burke napsal(a): > Marek will have to elaborate, but we passed oidc certification. > > On Wed, May 16, 2018 at 7:13 PM, Muein Muzamil > wrote: >> Hi all, >> >> I have a quick question, does Keycloak support POST method for OIDC >> Authorization Request? I was trying to integration Keycloak with an SP, >> which is using POST for Auth request and Keycloak rejects the request with >> "405 Method Not Allowed" Error. >> >> I looked at the OIDC Specs and accordingly, to that both GET and POST >> should be supported for Authorization Request. Maybe I am missing >> something, can someone please shed some light on this. >> >> This also makes me wonder, is the Keycloak fully compliant with OIDC Specs? >> did we run any compliance tests to confirm this? >> >> Best regards, >> Muein >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From bburke at redhat.com Thu May 17 15:44:47 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 May 2018 15:44:47 -0400 Subject: [keycloak-dev] Current usage of mvn-golang-wrapper not compatible with product builds In-Reply-To: <152658479064.22072.7671606374067989459@tyrfing> References: <152651219231.5791.16820338549746578469@tyrfing> <152657999904.22072.1343679601898237365@tyrfing> <152658479064.22072.7671606374067989459@tyrfing> Message-ID: Would an automerge bot automatically remove my dev branch too? On Thu, May 17, 2018 at 3:19 PM, Alex Szczuczko wrote: > Thanks. The reason I asked for a merge too is that I don't have > permission to do so myself, and we don't have an automerge bot yet. > > Quoting Bill Burke (2018-05-17 12:45:39) >> Approved. I didn't merge though. -- Bill Burke Red Hat From aszczucz at redhat.com Thu May 17 16:06:51 2018 From: aszczucz at redhat.com (Alex Szczuczko) Date: Thu, 17 May 2018 14:06:51 -0600 Subject: [keycloak-dev] Current usage of mvn-golang-wrapper not compatible with product builds In-Reply-To: References: <152651219231.5791.16820338549746578469@tyrfing> <152657999904.22072.1343679601898237365@tyrfing> <152658479064.22072.7671606374067989459@tyrfing> Message-ID: <152658760558.22072.11901520789057482056@tyrfing> I don't know exactly what your dev branch looks like, but I would think it would be left alone. The last time I talked with Stian about this idea, the automerge criteria would be: PR + all tests pass + n approvals on PR from core developers. Quoting Bill Burke (2018-05-17 13:44:47) > Would an automerge bot automatically remove my dev branch too? > > On Thu, May 17, 2018 at 3:19 PM, Alex Szczuczko wrote: > > Thanks. The reason I asked for a merge too is that I don't have > > permission to do so myself, and we don't have an automerge bot yet. > > > > Quoting Bill Burke (2018-05-17 12:45:39) > >> Approved. I didn't merge though. From shmuein+keycloak-dev at gmail.com Thu May 17 17:38:47 2018 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Thu, 17 May 2018 16:38:47 -0500 Subject: [keycloak-dev] POST method for OIDC Authorization End Point In-Reply-To: References: Message-ID: Thanks for confirming this. I have created the following ticket in JIRA. https://issues.jboss.org/browse/KEYCLOAK-7371 Regards, Muein On Thu, May 17, 2018 at 2:39 PM, Marek Posolda wrote: > Yes, the AuthorizationEndpoint currently supports just GET. This is not > correct according to specs, we should add POST too. Could you please create > JIRA? > > It seems that certification didn't have a test for this :) > > Marek > > Dne 17.5.2018 v 16:04 Bill Burke napsal(a): > > Marek will have to elaborate, but we passed oidc certification. >> >> On Wed, May 16, 2018 at 7:13 PM, Muein Muzamil >> wrote: >> >>> Hi all, >>> >>> I have a quick question, does Keycloak support POST method for OIDC >>> Authorization Request? I was trying to integration Keycloak with an SP, >>> which is using POST for Auth request and Keycloak rejects the request >>> with >>> "405 Method Not Allowed" Error. >>> >>> I looked at the OIDC Specs and accordingly, to that both GET and POST >>> should be supported for Authorization Request. Maybe I am missing >>> something, can someone please shed some light on this. >>> >>> This also makes me wonder, is the Keycloak fully compliant with OIDC >>> Specs? >>> did we run any compliance tests to confirm this? >>> >>> Best regards, >>> Muein >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > From sergey at shimkiv.com Fri May 18 02:14:46 2018 From: sergey at shimkiv.com (Serhii Shymkiv) Date: Fri, 18 May 2018 09:14:46 +0300 Subject: [keycloak-dev] Fwd: An ability to evaluate/transform the template variables during the SAML/OpenID protocol mappers processing In-Reply-To: References: Message-ID: Hey Thomas, thank you for reply and the info provided. Not sure what to do next, though. Should we discuss the implementation details of the protocol mapper tpl interpolation ? -- Best regards, Serhii Shymkiv. On Thu, May 17, 2018, 14:35 Thomas Darimont wrote: > Hi Sergey, > > for OIDC you can already do something like this via the Script Protocol > Mapper which allows > to compute the result value via JavaScript. > > See: > - > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/mappers/ScriptBasedOIDCProtocolMapper.java > - https://github.com/keycloak/keycloak/pull/4495 > > I didn't have the time yet to implement the same for the SAML protocol > mapper, but > there is a JIRA issue: https://issues.jboss.org/browse/KEYCLOAK-5520 > > Support for template interpolation via a dedicated protocol mapper would > be nicer though, > since it would allow for more concise mapper definitions. > > Cheers, > Thomas > > Am Do., 17. Mai 2018 um 11:04 Uhr schrieb Serhii Shymkiv < > sergey at shimkiv.com>: > >> No luck with Users list, trying the Devs one ... >> >> >> ---------- Forwarded message ---------- >> From: Serhii Shymkiv >> Date: Sat, Apr 21, 2018 at 9:11 PM >> Subject: An ability to evaluate/transform the template variables during >> the >> SAML/OpenID protocol mappers processing >> To: keycloak-user at lists.jboss.org >> >> >> Hello Guys, >> current email thread is inspired by the https://github.com/keycloak/ >> keycloak/pull/5042 >> and the question for the community is: >> - what do you think if the Keycloak will have an ability to >> evaluate/transform the template variables during the SAML/OpenID protocol >> mappers processing ? >> >> Examples (please refer to the attached "snapshot-1.png" and >> "snapshot-2.png"): >> 1. "snapshot-1.png": >> ${firstName} ${lastName} >> => >> the simplest expression, the template variables will be evaluated into >> the real values of the user (in this case) properties >> => >> e.g.: "Serhii Shymkiv" (without quotes, of course) >> 2. "snapshot-2.png": >> Welcome back, #(${firstName} ${lastName}) ?: ${email} >> => >> almost the same expression but with additional logic which means that >> the value of the #(...) block will be used only if it is not blank (null >> or >> space symbols only) otherwise the expression to the right of the ?: >> operator will be evaluated >> => >> e.g.: "Welcome back, Serhii Shymkiv" >> e.g.: "Welcome back, sergey at shimkiv.com" >> >> Thank you for you time. >> >> >> >> >> -- >> Best regards, >> Serhii Shymkiv. >> >> >> >> -- >> Best regards, >> Serhii Shymkiv. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From s.kreutz at yieldlab.de Fri May 18 17:57:40 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Fri, 18 May 2018 23:57:40 +0200 Subject: [keycloak-dev] Hosted domain for Google logins Message-ID: <0C91AD97-E639-4EB0-A166-5C476950E3C3@yieldlab.de> Hey Keycloak Devs, we would like to restrict access to accounts that are managed by our company and therefore need to send the ?hd? to Google?s auth endpoint. I saw that there is already a JIRA issue for that topic under https://issues.jboss.org/browse/KEYCLOAK-5289 . If you agree, I would like to take over it because I already implemented the change in our fork. You can find the changes under https://github.com/yieldlab/keycloak/tree/hosted-domain-parameter-for-google-identity-provider . Unfortunately the existing tests fail on my machine and therefore I don?t want to create a PR yet. I think this is because my system?s locale is German. The summary of the failing test is Failed tests: SAMLParserTest.testInvalidEndElement Expected: (an instance of org.keycloak.saml.common.exceptions.ParsingException and exception with message a string containing "The element type \"NameIDFormat\" must be terminated by the matching end-tag \"\".") but: exception with message a string containing "The element type \"NameIDFormat\" must be terminated by the matching end-tag \"\"." message was "javax.xml.stream.XMLStreamException: ParseError at [row,col]:[31,11] Message: Elementtyp "NameIDFormat" muss mit dem entsprechenden Endtag "" beendet werden." This comes because the exception?s message is translated to German but the test matches only the english version. Do you know about this? And what can I do (without changing my system?s locale) to pass the test? I already tried to pass '-Duser.country=DE -Duser.language=de? to Maven and the Maven Surefire Plugin but it didn?t help. Best regards, Steffen Kreutz From thomas.darimont at googlemail.com Sat May 19 04:45:48 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Sat, 19 May 2018 09:45:48 +0100 Subject: [keycloak-dev] Hosted domain for Google logins In-Reply-To: <0C91AD97-E639-4EB0-A166-5C476950E3C3@yieldlab.de> References: <0C91AD97-E639-4EB0-A166-5C476950E3C3@yieldlab.de> Message-ID: Hello Steffen, maven forks a new jvm for tests, so you have to explicitly pass the jvm arguments / system properties in the configuration of the surefire test plugin, see: http://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html Would probably be a good idea to add the -Duser.country=EN -Duser.language=en to the surefire plugin config in the Keycloak build for more stable tests. E.g: org.apache.maven.plugins maven-surefire-plugin -Duser.country=EN -Duser.language=en Cheers, Thomas Am Fr., 18. Mai 2018 um 22:58 Uhr schrieb Steffen Kreutz < s.kreutz at yieldlab.de>: > Hey Keycloak Devs, > > we would like to restrict access to accounts that are managed by our > company and therefore need to send the ?hd? to Google?s auth endpoint. I > saw that there is already a JIRA issue for that topic under > https://issues.jboss.org/browse/KEYCLOAK-5289 < > https://issues.jboss.org/browse/KEYCLOAK-5289>. If you agree, I would > like to take over it because I already implemented the change in our fork. > You can find the changes under > https://github.com/yieldlab/keycloak/tree/hosted-domain-parameter-for-google-identity-provider > < > https://github.com/yieldlab/keycloak/tree/hosted-domain-parameter-for-google-identity-provider > >. > > Unfortunately the existing tests fail on my machine and therefore I don?t > want to create a PR yet. I think this is because my system?s locale is > German. The summary of the failing test is > > Failed tests: > SAMLParserTest.testInvalidEndElement > Expected: (an instance of > org.keycloak.saml.common.exceptions.ParsingException and exception with > message a string containing "The element type \"NameIDFormat\" must be > terminated by the matching end-tag \"\".") > but: exception with message a string containing "The element type > \"NameIDFormat\" must be terminated by the matching end-tag > \"\"." message was "javax.xml.stream.XMLStreamException: > ParseError at [row,col]:[31,11] > Message: Elementtyp "NameIDFormat" muss mit dem entsprechenden Endtag > "" beendet werden." > > This comes because the exception?s message is translated to German but the > test matches only the english version. Do you know about this? And what can > I do (without changing my system?s locale) to pass the test? I already > tried to pass '-Duser.country=DE -Duser.language=de? to Maven and the Maven > Surefire Plugin but it didn?t help. > > Best regards, > > Steffen Kreutz > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From s.kreutz at yieldlab.de Sat May 19 05:02:04 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Sat, 19 May 2018 11:02:04 +0200 Subject: [keycloak-dev] Hosted domain for Google logins In-Reply-To: References: <0C91AD97-E639-4EB0-A166-5C476950E3C3@yieldlab.de> Message-ID: <2F976BA2-6E9F-44A7-AF17-49A3F3AD5A81@yieldlab.de> Hi Thomas, unfortunately this didn?t work for me so I filed a bug report at https://issues.jboss.org/browse/KEYCLOAK-7377 . I added 'Locale.setDefault(Locale.ENGLISH);' to the ?initParser? method of the test. Best, Steffen > Am 19.05.2018 um 10:45 schrieb Thomas Darimont : > > Hello Steffen, > > maven forks a new jvm for tests, so you have to explicitly pass the jvm arguments / system properties > in the configuration of the surefire test plugin, see: > http://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html > > Would probably be a good idea to add the -Duser.country=EN -Duser.language=en > to the surefire plugin config in the Keycloak build for more stable tests. > > E.g: > > > > org.apache.maven.plugins > maven-surefire-plugin > > -Duser.country=EN -Duser.language=en > > > > > > Cheers, > Thomas > > Am Fr., 18. Mai 2018 um 22:58 Uhr schrieb Steffen Kreutz >: > Hey Keycloak Devs, > > we would like to restrict access to accounts that are managed by our company and therefore need to send the ?hd? to Google?s auth endpoint. I saw that there is already a JIRA issue for that topic under https://issues.jboss.org/browse/KEYCLOAK-5289 >. If you agree, I would like to take over it because I already implemented the change in our fork. You can find the changes under https://github.com/yieldlab/keycloak/tree/hosted-domain-parameter-for-google-identity-provider >. > > Unfortunately the existing tests fail on my machine and therefore I don?t want to create a PR yet. I think this is because my system?s locale is German. The summary of the failing test is > > Failed tests: > SAMLParserTest.testInvalidEndElement > Expected: (an instance of org.keycloak.saml.common.exceptions.ParsingException and exception with message a string containing "The element type \"NameIDFormat\" must be terminated by the matching end-tag \"\".") > but: exception with message a string containing "The element type \"NameIDFormat\" must be terminated by the matching end-tag \"\"." message was "javax.xml.stream.XMLStreamException: ParseError at [row,col]:[31,11] > Message: Elementtyp "NameIDFormat" muss mit dem entsprechenden Endtag "" beendet werden." > > This comes because the exception?s message is translated to German but the test matches only the english version. Do you know about this? And what can I do (without changing my system?s locale) to pass the test? I already tried to pass '-Duser.country=DE -Duser.language=de? to Maven and the Maven Surefire Plugin but it didn?t help. > > Best regards, > > Steffen Kreutz > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From gambol99 at gmail.com Mon May 21 09:00:01 2018 From: gambol99 at gmail.com (gambol) Date: Mon, 21 May 2018 14:00:01 +0100 Subject: [keycloak-dev] Few Questions on usage Message-ID: Hiya Apologizes for the wide range questions .. but figured a number for be useful for the user base. - Using the current scripted authentication in Authentication Flows would it possible to use script to say if clientid == x and user have role x, permitted else not. Also do you have a repo with some examples of scripts? similar to https://github.com/auth0/rules - Will the scripting always be global level, or is there any plan to make it per client? or perhaps a better question would be will authentication flow always be at the realm level. - Assuming a realm with multiple identity providers, is there any means by which a client and enforce that a use came in via a specific identity provider? or if i come in via provider x they need to use MFA (would this be done with a Post Login Flow on the provider perhaps?). - Is the any plans to make Groups per client and under the client ui? as for realms which have many disassociated applications but common user bases it makes it easier for them to manage. - Are the any plans to expose metrics (or perhaps they are already exposed)? via jmx, stats, prometheus etc .. around logins, successful, failed etc, any latency measures on identity providers, infinispan / database operations etc - Is there any way to turn off the internal passwords and force via identity provider? .. i guess this is where scripting becomes useful .. i.e if client = y get the provider name and deny if not y etc Rohith From bburke at redhat.com Mon May 21 09:21:12 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 21 May 2018 09:21:12 -0400 Subject: [keycloak-dev] Few Questions on usage In-Reply-To: References: Message-ID: On Mon, May 21, 2018 at 9:00 AM, gambol wrote: > Hiya > > Apologizes for the wide range questions .. but figured a number for be > useful for the user base. > > - Using the current scripted authentication in Authentication Flows would > it possible to use script to say if clientid == x and user have role x, > permitted else not. Also do you have a repo with some examples of scripts? > similar to https://github.com/auth0/rules > Yes, you could do that. No repo, sorry. This was a community contribution and we don't have much more than basic docs. > - Will the scripting always be global level, or is there any plan to make > it per client? or perhaps a better question would be will authentication > flow always be at the realm level. > You can assign a specific authentiction flow to a specific client, but we do not have anything like "step up" authentication yet. > - Assuming a realm with multiple identity providers, is there any means by > which a client and enforce that a use came in via a specific identity > provider? or if i come in via provider x they need to use MFA (would this > be done with a Post Login Flow on the provider perhaps?). > That might work, but post login flow was implemented mainly to resolve import from external provider. > - Is the any plans to make Groups per client and under the client ui? as > for realms which have many disassociated applications but common user bases > it makes it easier for them to manage. > You are the first to ask, but we should do something similar to what was done for roles. > - Are the any plans to expose metrics (or perhaps they are already > exposed)? via jmx, stats, prometheus etc .. around logins, successful, > failed etc, any latency measures on identity providers, infinispan / > database operations etc > Something that should be scheduled. We have audit logs for all different types of events, but I'm pretty sure we don't tabulate any of it. We have basic generic metrics that any "application server" would provide through Wildfly. > - Is there any way to turn off the internal passwords and force via > identity provider? .. i guess this is where scripting becomes useful .. i.e > if client = y get the provider name and deny if not y etc > Elaborate? Not sure what you mean.Not understanding this one. -- Bill Burke Red Hat From asaldanha1947 at gmail.com Mon May 21 09:35:02 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Mon, 21 May 2018 08:35:02 -0500 Subject: [keycloak-dev] Few Questions on usage In-Reply-To: References: Message-ID: Bill - while I see the benefits of dynamic scripting in authentication flows, I wonder if it opens a can of worms in terms of security holes. How do you sandbox scripts? What do you think ? > On May 21, 2018, at 8:21 AM, Bill Burke wrote: > >> On Mon, May 21, 2018 at 9:00 AM, gambol wrote: >> Hiya >> >> Apologizes for the wide range questions .. but figured a number for be >> useful for the user base. >> >> - Using the current scripted authentication in Authentication Flows would >> it possible to use script to say if clientid == x and user have role x, >> permitted else not. Also do you have a repo with some examples of scripts? >> similar to https://github.com/auth0/rules >> > > Yes, you could do that. No repo, sorry. This was a community > contribution and we don't have much more than basic docs. > >> - Will the scripting always be global level, or is there any plan to make >> it per client? or perhaps a better question would be will authentication >> flow always be at the realm level. >> > > You can assign a specific authentiction flow to a specific client, but > we do not have anything like "step up" authentication yet. > >> - Assuming a realm with multiple identity providers, is there any means by >> which a client and enforce that a use came in via a specific identity >> provider? or if i come in via provider x they need to use MFA (would this >> be done with a Post Login Flow on the provider perhaps?). >> > > That might work, but post login flow was implemented mainly to resolve > import from external provider. > >> - Is the any plans to make Groups per client and under the client ui? as >> for realms which have many disassociated applications but common user bases >> it makes it easier for them to manage. >> > > You are the first to ask, but we should do something similar to what > was done for roles. > >> - Are the any plans to expose metrics (or perhaps they are already >> exposed)? via jmx, stats, prometheus etc .. around logins, successful, >> failed etc, any latency measures on identity providers, infinispan / >> database operations etc >> > > Something that should be scheduled. We have audit logs for all > different types of events, but I'm pretty sure we don't tabulate any > of it. We have basic generic metrics that any "application server" > would provide through Wildfly. > >> - Is there any way to turn off the internal passwords and force via >> identity provider? .. i guess this is where scripting becomes useful .. i.e >> if client = y get the provider name and deny if not y etc >> > > Elaborate? Not sure what you mean.Not understanding this one. > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From gambol99 at gmail.com Mon May 21 09:54:07 2018 From: gambol99 at gmail.com (gambol) Date: Mon, 21 May 2018 14:54:07 +0100 Subject: [keycloak-dev] Few Questions on usage In-Reply-To: References: Message-ID: Hi Bill > - Will the scripting always be global level, or is there any plan to make > it per client? or perhaps a better question would be will authentication > flow always be at the realm level. > > You can assign a specific authentiction flow to a specific client, but > we do not have anything like "step up" authentication yet. Ar cool!! .. I can't see to find where to do this though .. Assuming i had client x where do to associate the browser flow to a specific client? > - Is there any way to turn off the internal passwords and force via > identity provider? .. i guess this is where scripting becomes useful .. i.e > if client = y get the provider name and deny if not y etc > > Elaborate? Not sure what you mean.Not understanding this one. So essentially we have two upstream identity providers, we want to switch off the user setting a local password and logging in via that, forcing them to go via a identity provider. Though if a script can just do if (client == "x") { providerId = something.getProviderId() if (providerId != "y" && providerId != "z") { context.failure("some message") } } On Mon, May 21, 2018 at 2:21 PM, Bill Burke wrote: > On Mon, May 21, 2018 at 9:00 AM, gambol wrote: > > Hiya > > > > Apologizes for the wide range questions .. but figured a number for be > > useful for the user base. > > > > - Using the current scripted authentication in Authentication Flows would > > it possible to use script to say if clientid == x and user have role x, > > permitted else not. Also do you have a repo with some examples of > scripts? > > similar to https://github.com/auth0/rules > > > > Yes, you could do that. No repo, sorry. This was a community > contribution and we don't have much more than basic docs. > > > - Will the scripting always be global level, or is there any plan to make > > it per client? or perhaps a better question would be will authentication > > flow always be at the realm level. > > > > You can assign a specific authentiction flow to a specific client, but > we do not have anything like "step up" authentication yet. > > > - Assuming a realm with multiple identity providers, is there any means > by > > which a client and enforce that a use came in via a specific identity > > provider? or if i come in via provider x they need to use MFA (would this > > be done with a Post Login Flow on the provider perhaps?). > > > > That might work, but post login flow was implemented mainly to resolve > import from external provider. > > > - Is the any plans to make Groups per client and under the client ui? as > > for realms which have many disassociated applications but common user > bases > > it makes it easier for them to manage. > > > > You are the first to ask, but we should do something similar to what > was done for roles. > > > - Are the any plans to expose metrics (or perhaps they are already > > exposed)? via jmx, stats, prometheus etc .. around logins, successful, > > failed etc, any latency measures on identity providers, infinispan / > > database operations etc > > > > Something that should be scheduled. We have audit logs for all > different types of events, but I'm pretty sure we don't tabulate any > of it. We have basic generic metrics that any "application server" > would provide through Wildfly. > > > - Is there any way to turn off the internal passwords and force via > > identity provider? .. i guess this is where scripting becomes useful .. > i.e > > if client = y get the provider name and deny if not y etc > > > > Elaborate? Not sure what you mean.Not understanding this one. > > > -- > Bill Burke > Red Hat > From bburke at redhat.com Mon May 21 09:56:51 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 21 May 2018 09:56:51 -0400 Subject: [keycloak-dev] Few Questions on usage In-Reply-To: References: Message-ID: keycloak really isn't designed as a SaaS where different companies share the same instance and datastore. We almost went that route, but decided that with docker and openshift and containers and all, much better to "sandbox" the whole server. On Mon, May 21, 2018 at 9:35 AM, Anil Saldanha wrote: > Bill - while I see the benefits of dynamic scripting in authentication flows, I wonder if it opens a can of worms in terms of security holes. How do you sandbox scripts? > > What do you think ? > >> On May 21, 2018, at 8:21 AM, Bill Burke wrote: >> >>> On Mon, May 21, 2018 at 9:00 AM, gambol wrote: >>> Hiya >>> >>> Apologizes for the wide range questions .. but figured a number for be >>> useful for the user base. >>> >>> - Using the current scripted authentication in Authentication Flows would >>> it possible to use script to say if clientid == x and user have role x, >>> permitted else not. Also do you have a repo with some examples of scripts? >>> similar to https://github.com/auth0/rules >>> >> >> Yes, you could do that. No repo, sorry. This was a community >> contribution and we don't have much more than basic docs. >> >>> - Will the scripting always be global level, or is there any plan to make >>> it per client? or perhaps a better question would be will authentication >>> flow always be at the realm level. >>> >> >> You can assign a specific authentiction flow to a specific client, but >> we do not have anything like "step up" authentication yet. >> >>> - Assuming a realm with multiple identity providers, is there any means by >>> which a client and enforce that a use came in via a specific identity >>> provider? or if i come in via provider x they need to use MFA (would this >>> be done with a Post Login Flow on the provider perhaps?). >>> >> >> That might work, but post login flow was implemented mainly to resolve >> import from external provider. >> >>> - Is the any plans to make Groups per client and under the client ui? as >>> for realms which have many disassociated applications but common user bases >>> it makes it easier for them to manage. >>> >> >> You are the first to ask, but we should do something similar to what >> was done for roles. >> >>> - Are the any plans to expose metrics (or perhaps they are already >>> exposed)? via jmx, stats, prometheus etc .. around logins, successful, >>> failed etc, any latency measures on identity providers, infinispan / >>> database operations etc >>> >> >> Something that should be scheduled. We have audit logs for all >> different types of events, but I'm pretty sure we don't tabulate any >> of it. We have basic generic metrics that any "application server" >> would provide through Wildfly. >> >>> - Is there any way to turn off the internal passwords and force via >>> identity provider? .. i guess this is where scripting becomes useful .. i.e >>> if client = y get the provider name and deny if not y etc >>> >> >> Elaborate? Not sure what you mean.Not understanding this one. >> >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From thomas.darimont at googlemail.com Mon May 21 13:17:36 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 21 May 2018 19:17:36 +0200 Subject: [keycloak-dev] Few Questions on usage In-Reply-To: References: Message-ID: The scripting support can be disabled for the whole server with a feature toggle. Cheers, Thomas Anil Saldanha schrieb am Mo., 21. Mai 2018, 15:40: > Bill - while I see the benefits of dynamic scripting in authentication > flows, I wonder if it opens a can of worms in terms of security holes. How > do you sandbox scripts? > > What do you think ? > > > On May 21, 2018, at 8:21 AM, Bill Burke wrote: > > > >> On Mon, May 21, 2018 at 9:00 AM, gambol wrote: > >> Hiya > >> > >> Apologizes for the wide range questions .. but figured a number for be > >> useful for the user base. > >> > >> - Using the current scripted authentication in Authentication Flows > would > >> it possible to use script to say if clientid == x and user have role x, > >> permitted else not. Also do you have a repo with some examples of > scripts? > >> similar to https://github.com/auth0/rules > >> > > > > Yes, you could do that. No repo, sorry. This was a community > > contribution and we don't have much more than basic docs. > > > >> - Will the scripting always be global level, or is there any plan to > make > >> it per client? or perhaps a better question would be will authentication > >> flow always be at the realm level. > >> > > > > You can assign a specific authentiction flow to a specific client, but > > we do not have anything like "step up" authentication yet. > > > >> - Assuming a realm with multiple identity providers, is there any means > by > >> which a client and enforce that a use came in via a specific identity > >> provider? or if i come in via provider x they need to use MFA (would > this > >> be done with a Post Login Flow on the provider perhaps?). > >> > > > > That might work, but post login flow was implemented mainly to resolve > > import from external provider. > > > >> - Is the any plans to make Groups per client and under the client ui? as > >> for realms which have many disassociated applications but common user > bases > >> it makes it easier for them to manage. > >> > > > > You are the first to ask, but we should do something similar to what > > was done for roles. > > > >> - Are the any plans to expose metrics (or perhaps they are already > >> exposed)? via jmx, stats, prometheus etc .. around logins, successful, > >> failed etc, any latency measures on identity providers, infinispan / > >> database operations etc > >> > > > > Something that should be scheduled. We have audit logs for all > > different types of events, but I'm pretty sure we don't tabulate any > > of it. We have basic generic metrics that any "application server" > > would provide through Wildfly. > > > >> - Is there any way to turn off the internal passwords and force via > >> identity provider? .. i guess this is where scripting becomes useful .. > i.e > >> if client = y get the provider name and deny if not y etc > >> > > > > Elaborate? Not sure what you mean.Not understanding this one. > > > > > > -- > > Bill Burke > > Red Hat > > _______________________________________________ > > 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 > From sthorger at redhat.com Thu May 24 13:17:05 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 24 May 2018 19:17:05 +0200 Subject: [keycloak-dev] Keycloak 4.0.0.Final released Message-ID: To download the release go to the Keycloak homepage . Highlights Fuse 7 Adapter There's now support for Fuse 7. Cordova options in JavaScript adapter It's now possible to pass Cordova specific options to login and other methods in the JavaScript adapter. Thanks to loorent for the contribution. Search by user id on admin console If you wanted to search by a user by id in the admin console you had to edit the URL. It's now possible to do it directly in the user search field. More... The full list of resolved issues is available in JIRA . Upgrading Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed. From thomas.darimont at googlemail.com Thu May 24 13:24:12 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 24 May 2018 19:24:12 +0200 Subject: [keycloak-dev] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: Congrats! The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? Cheers, Thomas Stian Thorgersen schrieb am Do., 24. Mai 2018, 19:18: > To download the release go to the Keycloak homepage > . > Highlights > Fuse 7 Adapter > > There's now support for Fuse 7. > Cordova options in JavaScript adapter > > It's now possible to pass Cordova specific options to login and other > methods in the JavaScript adapter. Thanks to loorent > for the contribution. > Search by user id on admin console > > If you wanted to search by a user by id in the admin console you had to > edit the URL. It's now possible to do it directly in the user search field. > More... > > The full list of resolved issues is available in JIRA > < > https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3 > > > . > Upgrading > > Before you upgrade remember to backup your database and check the upgrade > guide for > anything that may have changed. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Thu May 24 13:27:47 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 24 May 2018 19:27:47 +0200 Subject: [keycloak-dev] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: It's indeed Beta3 that was released and not Final. Final will be next though! On 24 May 2018 at 19:24, Thomas Darimont wrote: > Congrats! > > The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? > > Cheers, > Thomas > > Stian Thorgersen schrieb am Do., 24. Mai 2018, > 19:18: > >> To download the release go to the Keycloak homepage >> . >> Highlights >> Fuse 7 Adapter >> >> There's now support for Fuse 7. >> Cordova options in JavaScript adapter >> >> It's now possible to pass Cordova specific options to login and other >> methods in the JavaScript adapter. Thanks to loorent >> for the contribution. >> Search by user id on admin console >> >> If you wanted to search by a user by id in the admin console you had to >> edit the URL. It's now possible to do it directly in the user search >> field. >> More... >> >> The full list of resolved issues is available in JIRA >> > 20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3> >> . >> Upgrading >> >> Before you upgrade remember to backup your database and check the upgrade >> guide for >> anything that may have changed. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From subodhcjoshi82 at gmail.com Thu May 24 23:18:20 2018 From: subodhcjoshi82 at gmail.com (Subodh Joshi) Date: Fri, 25 May 2018 08:48:20 +0530 Subject: [keycloak-dev] [keycloak-user] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: Any idea when Final release will happen? On Fri, May 25, 2018 at 8:38 AM Subodh Joshi wrote: > Any idea when Final release will happen? > > On Thu, May 24, 2018 at 11:06 PM Stian Thorgersen > wrote: > >> It's indeed Beta3 that was released and not Final. Final will be next >> though! >> >> On 24 May 2018 at 19:24, Thomas Darimont >> wrote: >> >> > Congrats! >> > >> > The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? >> > >> > Cheers, >> > Thomas >> > >> > Stian Thorgersen schrieb am Do., 24. Mai 2018, >> > 19:18: >> > >> >> To download the release go to the Keycloak homepage >> >> . >> >> Highlights >> >> Fuse 7 Adapter >> >> >> >> There's now support for Fuse 7. >> >> Cordova options in JavaScript adapter >> >> >> >> It's now possible to pass Cordova specific options to login and other >> >> methods in the JavaScript adapter. Thanks to loorent >> >> for the contribution. >> >> Search by user id on admin console >> >> >> >> If you wanted to search by a user by id in the admin console you had to >> >> edit the URL. It's now possible to do it directly in the user search >> >> field. >> >> More... >> >> >> >> The full list of resolved issues is available in JIRA >> >> > >> 20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3> >> >> . >> >> Upgrading >> >> >> >> Before you upgrade remember to backup your database and check the >> upgrade >> >> guide for >> >> anything that may have changed. >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > -- > Subodh Chandra Joshi > subodh1_joshi82 at yahoo.co.in > http://www.trendsinnews.com > -- Subodh Chandra Joshi subodh1_joshi82 at yahoo.co.in http://www.trendsinnews.com From takashi.norimatsu.ws at hitachi.com Thu May 24 23:26:07 2018 From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=) Date: Fri, 25 May 2018 03:26:07 +0000 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing Message-ID: I'd like to use more secure JWS signature algorithm in the environment where the high security level is required such as the financial industry. According to the following RFCs, RSASSA-PSS to which PS256 follows is recommended on behalf of RSASSA-PKCS1-v1_5 to which RS256 follows. https://tools.ietf.org/html/rfc3447#section-8 However, according to the following RFC, ES256 is "Recommended+" while PS256 is "Optional". https://tools.ietf.org/html/rfc7518#section-3.1 Moreover, it is said that Elliptic Curve based algorithms have an advantage against RSA base algorithms in volume of its computation. Therefore, I've tried to make keycloak support ES256 JWS signature along with existing RS256 one. I've found that it seemed to be relatively easy to implement software components for ES256 JWS signature such as Signature Provider and Key Provider. However, it seemed to be difficult to implement codes actually calling these providers. The reasons is as follows. * a lot of places have called these singing and verifying providers. * such the places have been hard-coded in RSA algorithm specific. To deal with them, the following ideas have hit on me 1. replace RSA algorithm specific codes with signature algorithm independent codes. 2. re-design JWS signing and verifying scheme on high level. I'm not familiar with keycloak internals, so I've implemented ES256 JWS signature support on #1 basis experimentally. I'm not sure whether this way is appropriate or not. I'm very happy if keycloak specialists consider #2 or review my implementation based on #1. I've issued PR as WIP. Please refer to the following in detail. https://github.com/keycloak/keycloak/pull/5225 Best regards, Takashi Norimatsu Hitachi Ltd., From sthorger at redhat.com Fri May 25 02:34:05 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 25 May 2018 08:34:05 +0200 Subject: [keycloak-dev] [keycloak-user] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: It should be around 3 weeks after Beta3 On 25 May 2018 at 05:08, Subodh Joshi wrote: > Any idea when Final release will happen? > > On Thu, May 24, 2018 at 11:06 PM Stian Thorgersen > wrote: > >> It's indeed Beta3 that was released and not Final. Final will be next >> though! >> >> On 24 May 2018 at 19:24, Thomas Darimont >> wrote: >> >> > Congrats! >> > >> > The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? >> > >> > Cheers, >> > Thomas >> > >> > Stian Thorgersen schrieb am Do., 24. Mai 2018, >> > 19:18: >> > >> >> To download the release go to the Keycloak homepage >> >> . >> >> Highlights >> >> Fuse 7 Adapter >> >> >> >> There's now support for Fuse 7. >> >> Cordova options in JavaScript adapter >> >> >> >> It's now possible to pass Cordova specific options to login and other >> >> methods in the JavaScript adapter. Thanks to loorent >> >> for the contribution. >> >> Search by user id on admin console >> >> >> >> If you wanted to search by a user by id in the admin console you had to >> >> edit the URL. It's now possible to do it directly in the user search >> >> field. >> >> More... >> >> >> >> The full list of resolved issues is available in JIRA >> >> > >> 20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3> >> >> . >> >> Upgrading >> >> >> >> Before you upgrade remember to backup your database and check the >> upgrade >> >> guide for >> >> anything that may have changed. >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > -- > Subodh Chandra Joshi > subodh1_joshi82 at yahoo.co.in > http://www.trendsinnews.com > From subodhcjoshi82 at gmail.com Fri May 25 02:34:31 2018 From: subodhcjoshi82 at gmail.com (Subodh Joshi) Date: Fri, 25 May 2018 12:04:31 +0530 Subject: [keycloak-dev] [keycloak-user] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: Great, thanks for the update. On Fri, May 25, 2018 at 12:04 PM Stian Thorgersen wrote: > It should be around 3 weeks after Beta3 > > On 25 May 2018 at 05:08, Subodh Joshi wrote: > >> Any idea when Final release will happen? >> >> On Thu, May 24, 2018 at 11:06 PM Stian Thorgersen >> wrote: >> >>> It's indeed Beta3 that was released and not Final. Final will be next >>> though! >>> >>> On 24 May 2018 at 19:24, Thomas Darimont >> > >>> wrote: >>> >>> > Congrats! >>> > >>> > The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? >>> > >>> > Cheers, >>> > Thomas >>> > >>> > Stian Thorgersen schrieb am Do., 24. Mai 2018, >>> > 19:18: >>> > >>> >> To download the release go to the Keycloak homepage >>> >> . >>> >> Highlights >>> >> Fuse 7 Adapter >>> >> >>> >> There's now support for Fuse 7. >>> >> Cordova options in JavaScript adapter >>> >> >>> >> It's now possible to pass Cordova specific options to login and other >>> >> methods in the JavaScript adapter. Thanks to loorent >>> >> for the contribution. >>> >> Search by user id on admin console >>> >> >>> >> If you wanted to search by a user by id in the admin console you had >>> to >>> >> edit the URL. It's now possible to do it directly in the user search >>> >> field. >>> >> More... >>> >> >>> >> The full list of resolved issues is available in JIRA >>> >> >> >> 20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3> >>> >> . >>> >> Upgrading >>> >> >>> >> Before you upgrade remember to backup your database and check the >>> upgrade >>> >> guide for >>> >> anything that may have changed. >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> > >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> -- >> Subodh Chandra Joshi >> subodh1_joshi82 at yahoo.co.in >> http://www.trendsinnews.com >> > > -- Subodh Chandra Joshi subodh1_joshi82 at yahoo.co.in http://www.trendsinnews.com From sergey at shimkiv.com Fri May 25 08:19:58 2018 From: sergey at shimkiv.com (Serhii Shymkiv) Date: Fri, 25 May 2018 15:19:58 +0300 Subject: [keycloak-dev] [keycloak-user] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: Hey Guys, something wrong has happened with the dist binaries ? https://downloads.jboss.org/keycloak/4.0.0.Beta3/keycloak-4.0.0.Beta3.zip => HTTP 404 On Fri, May 25, 2018 at 9:34 AM, Subodh Joshi wrote: > Great, thanks for the update. > > On Fri, May 25, 2018 at 12:04 PM Stian Thorgersen > wrote: > > > It should be around 3 weeks after Beta3 > > > > On 25 May 2018 at 05:08, Subodh Joshi wrote: > > > >> Any idea when Final release will happen? > >> > >> On Thu, May 24, 2018 at 11:06 PM Stian Thorgersen > >> wrote: > >> > >>> It's indeed Beta3 that was released and not Final. Final will be next > >>> though! > >>> > >>> On 24 May 2018 at 19:24, Thomas Darimont com > >>> > > >>> wrote: > >>> > >>> > Congrats! > >>> > > >>> > The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? > >>> > > >>> > Cheers, > >>> > Thomas > >>> > > >>> > Stian Thorgersen schrieb am Do., 24. Mai 2018, > >>> > 19:18: > >>> > > >>> >> To download the release go to the Keycloak homepage > >>> >> . > >>> >> Highlights > >>> >> Fuse 7 Adapter > >>> >> > >>> >> There's now support for Fuse 7. > >>> >> Cordova options in JavaScript adapter > >>> >> > >>> >> It's now possible to pass Cordova specific options to login and > other > >>> >> methods in the JavaScript adapter. Thanks to loorent > >>> >> for the contribution. > >>> >> Search by user id on admin console > >>> >> > >>> >> If you wanted to search by a user by id in the admin console you had > >>> to > >>> >> edit the URL. It's now possible to do it directly in the user search > >>> >> field. > >>> >> More... > >>> >> > >>> >> The full list of resolved issues is available in JIRA > >>> >> >>> >> 20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3> > >>> >> . > >>> >> Upgrading > >>> >> > >>> >> Before you upgrade remember to backup your database and check the > >>> upgrade > >>> >> guide > for > >>> >> anything that may have changed. > >>> >> _______________________________________________ > >>> >> keycloak-dev mailing list > >>> >> keycloak-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> >> > >>> > > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >> > >> > >> -- > >> Subodh Chandra Joshi > >> subodh1_joshi82 at yahoo.co.in > >> http://www.trendsinnews.com > >> > > > > > > -- > Subodh Chandra Joshi > subodh1_joshi82 at yahoo.co.in > http://www.trendsinnews.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Best regards, Serhii Shymkiv. From sthorger at redhat.com Fri May 25 09:10:53 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 25 May 2018 15:10:53 +0200 Subject: [keycloak-dev] [keycloak-user] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: Thanks for letting me know. I had to rework the release jobs a bit and the upload part wasn't done properly. Fixed now and the bits are being uploaded right now. Everything should be there in ~30 min. On 25 May 2018 at 14:19, Serhii Shymkiv wrote: > Hey Guys, > something wrong has happened with the dist binaries ? > > https://downloads.jboss.org/keycloak/4.0.0.Beta3/keycloak-4.0.0.Beta3.zip > => HTTP 404 > > On Fri, May 25, 2018 at 9:34 AM, Subodh Joshi > wrote: > >> Great, thanks for the update. >> >> On Fri, May 25, 2018 at 12:04 PM Stian Thorgersen >> wrote: >> >> > It should be around 3 weeks after Beta3 >> > >> > On 25 May 2018 at 05:08, Subodh Joshi wrote: >> > >> >> Any idea when Final release will happen? >> >> >> >> On Thu, May 24, 2018 at 11:06 PM Stian Thorgersen > > >> >> wrote: >> >> >> >>> It's indeed Beta3 that was released and not Final. Final will be next >> >>> though! >> >>> >> >>> On 24 May 2018 at 19:24, Thomas Darimont < >> thomas.darimont at googlemail.com >> >>> > >> >>> wrote: >> >>> >> >>> > Congrats! >> >>> > >> >>> > The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? >> >>> > >> >>> > Cheers, >> >>> > Thomas >> >>> > >> >>> > Stian Thorgersen schrieb am Do., 24. Mai >> 2018, >> >>> > 19:18: >> >>> > >> >>> >> To download the release go to the Keycloak homepage >> >>> >> . >> >>> >> Highlights >> >>> >> Fuse 7 Adapter >> >>> >> >> >>> >> There's now support for Fuse 7. >> >>> >> Cordova options in JavaScript adapter >> >>> >> >> >>> >> It's now possible to pass Cordova specific options to login and >> other >> >>> >> methods in the JavaScript adapter. Thanks to loorent >> >>> >> for the contribution. >> >>> >> Search by user id on admin console >> >>> >> >> >>> >> If you wanted to search by a user by id in the admin console you >> had >> >>> to >> >>> >> edit the URL. It's now possible to do it directly in the user >> search >> >>> >> field. >> >>> >> More... >> >>> >> >> >>> >> The full list of resolved issues is available in JIRA >> >>> >> > >>> >> 20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3> >> >>> >> . >> >>> >> Upgrading >> >>> >> >> >>> >> Before you upgrade remember to backup your database and check the >> >>> upgrade >> >>> >> guide >> for >> >>> >> anything that may have changed. >> >>> >> _______________________________________________ >> >>> >> keycloak-dev mailing list >> >>> >> keycloak-dev at lists.jboss.org >> >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> >> >>> > >> >>> _______________________________________________ >> >>> keycloak-user mailing list >> >>> keycloak-user at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >>> >> >> >> >> >> >> -- >> >> Subodh Chandra Joshi >> >> subodh1_joshi82 at yahoo.co.in >> >> http://www.trendsinnews.com >> >> >> > >> > >> >> -- >> Subodh Chandra Joshi >> subodh1_joshi82 at yahoo.co.in >> http://www.trendsinnews.com >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > > -- > Best regards, > Serhii Shymkiv. > From sergey at shimkiv.com Fri May 25 09:22:23 2018 From: sergey at shimkiv.com (Serhii Shymkiv) Date: Fri, 25 May 2018 16:22:23 +0300 Subject: [keycloak-dev] [keycloak-user] Keycloak 4.0.0.Final released In-Reply-To: References: Message-ID: Thanks a lot! -- Best regards, Sergey Shimkiv. On Fri, May 25, 2018, 16:10 Stian Thorgersen wrote: > Thanks for letting me know. I had to rework the release jobs a bit and the > upload part wasn't done properly. Fixed now and the bits are being uploaded > right now. Everything should be there in ~30 min. > > On 25 May 2018 at 14:19, Serhii Shymkiv wrote: > >> Hey Guys, >> something wrong has happened with the dist binaries ? >> >> https://downloads.jboss.org/keycloak/4.0.0.Beta3/keycloak-4.0.0.Beta3.zip >> => HTTP 404 >> >> On Fri, May 25, 2018 at 9:34 AM, Subodh Joshi >> wrote: >> >>> Great, thanks for the update. >>> >>> On Fri, May 25, 2018 at 12:04 PM Stian Thorgersen >>> wrote: >>> >>> > It should be around 3 weeks after Beta3 >>> > >>> > On 25 May 2018 at 05:08, Subodh Joshi >>> wrote: >>> > >>> >> Any idea when Final release will happen? >>> >> >>> >> On Thu, May 24, 2018 at 11:06 PM Stian Thorgersen < >>> sthorger at redhat.com> >>> >> wrote: >>> >> >>> >>> It's indeed Beta3 that was released and not Final. Final will be next >>> >>> though! >>> >>> >>> >>> On 24 May 2018 at 19:24, Thomas Darimont < >>> thomas.darimont at googlemail.com >>> >>> > >>> >>> wrote: >>> >>> >>> >>> > Congrats! >>> >>> > >>> >>> > The blog says 4.0.0.Beta3 is this now the final 4.0.0 version? >>> >>> > >>> >>> > Cheers, >>> >>> > Thomas >>> >>> > >>> >>> > Stian Thorgersen schrieb am Do., 24. Mai >>> 2018, >>> >>> > 19:18: >>> >>> > >>> >>> >> To download the release go to the Keycloak homepage >>> >>> >> . >>> >>> >> Highlights >>> >>> >> Fuse 7 Adapter >>> >>> >> >>> >>> >> There's now support for Fuse 7. >>> >>> >> Cordova options in JavaScript adapter >>> >>> >> >>> >>> >> It's now possible to pass Cordova specific options to login and >>> other >>> >>> >> methods in the JavaScript adapter. Thanks to loorent >>> >>> >> for the contribution. >>> >>> >> Search by user id on admin console >>> >>> >> >>> >>> >> If you wanted to search by a user by id in the admin console you >>> had >>> >>> to >>> >>> >> edit the URL. It's now possible to do it directly in the user >>> search >>> >>> >> field. >>> >>> >> More... >>> >>> >> >>> >>> >> The full list of resolved issues is available in JIRA >>> >>> >> >> >>> >> 20keycloak%20and%20fixVersion%20%3D%204.0.0.Beta3> >>> >>> >> . >>> >>> >> Upgrading >>> >>> >> >>> >>> >> Before you upgrade remember to backup your database and check the >>> >>> upgrade >>> >>> >> guide >>> for >>> >>> >> anything that may have changed. >>> >>> >> _______________________________________________ >>> >>> >> keycloak-dev mailing list >>> >>> >> keycloak-dev at lists.jboss.org >>> >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >> >>> >>> > >>> >>> _______________________________________________ >>> >>> keycloak-user mailing list >>> >>> keycloak-user at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >> >>> >> >>> >> -- >>> >> Subodh Chandra Joshi >>> >> subodh1_joshi82 at yahoo.co.in >>> >> http://www.trendsinnews.com >>> >> >>> > >>> > >>> >>> -- >>> Subodh Chandra Joshi >>> subodh1_joshi82 at yahoo.co.in >>> http://www.trendsinnews.com >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> >> -- >> Best regards, >> Serhii Shymkiv. >> > > From Gregor.Tudan at cofinpro.de Mon May 28 10:34:51 2018 From: Gregor.Tudan at cofinpro.de (Gregor Tudan) Date: Mon, 28 May 2018 14:34:51 +0000 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova Message-ID: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Hi there, I would like to pick up an old issue: KEYCLOAK-2606 Our current app uses Keycloak with the Cordova In-App-Browser. Technically this works fine, but the user experience is ? uhmm ? awful. The page renders quiet slow and has focus issues. I?d love to help getting some support for the browser-tab. I started porting the ionic sample app to browertabs, but would like to check back with you before doing something stupid. The idea is: 1. In Keycloak.js Cordova Adapter check if browertab is supported, else fall back to in-app-browser 2. Open the login-page with the In-App-Browser (leaving the app) 3. Register a custom-url-scheme and configure it as redirect url (i.e. keycloakapp://). We?ll need another Cordova plugin for this (i.e. deep links). The Cordova-Adapter needs to get extended for this, since ?localost? seems to be hardcoded as redirect-url) 4. The Keycloak-server will redirect to the app after login succeeded. The App will need to reinitialize the Keycloak-Adapter with the code given in the url - I?m not sure if this will work out of the box. Does this sound reasonable? Thanks, Gregor! From velias at redhat.com Tue May 29 03:16:12 2018 From: velias at redhat.com (Vlastimil Elias) Date: Tue, 29 May 2018 09:16:12 +0200 Subject: [keycloak-dev] Any plans to support Web Authentication API? Message-ID: <8ac473ae-dc9f-ec66-c848-76f0a740c196@redhat.com> Hi, it looks like that Web Authentication API [1] is going to be a new standard widely adopted by browsers to improve web authentication security. It helps to prevent phishing attacks (as it automatically validates domain of the login page) and allows to use device's auth hardware (eg biometrics HW) to login into websites. Any plans to support it in Keycloak? More info in Google IO 2018 session and related blogpost [2] Thanks Vlastimil [1] https://www.w3.org/TR/webauthn/ [2] https://developers.google.com/web/updates/2018/05/webauthn -- Vlastimil Elias Principal Software Engineer, Middleware Engineering Services Red Hat From sthorger at redhat.com Tue May 29 03:31:22 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 29 May 2018 09:31:22 +0200 Subject: [keycloak-dev] Any plans to support Web Authentication API? In-Reply-To: <8ac473ae-dc9f-ec66-c848-76f0a740c196@redhat.com> References: <8ac473ae-dc9f-ec66-c848-76f0a740c196@redhat.com> Message-ID: Yes, we are planning to add support for web authentication, but not sure if it will be this year or next. On 29 May 2018 at 09:16, Vlastimil Elias wrote: > Hi, > > it looks like that Web Authentication API [1] is going to be a new > standard widely adopted by browsers to improve web authentication security. > > It helps to prevent phishing attacks (as it automatically validates > domain of the login page) and allows to use device's auth hardware (eg > biometrics HW) to login into websites. > > Any plans to support it in Keycloak? > > More info in Google IO 2018 session and related blogpost [2] > > Thanks > > Vlastimil > > [1] https://www.w3.org/TR/webauthn/ > > [2] https://developers.google.com/web/updates/2018/05/webauthn > > -- > Vlastimil Elias > Principal Software Engineer, Middleware Engineering Services > Red Hat > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue May 29 03:33:35 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 29 May 2018 09:33:35 +0200 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova In-Reply-To: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> References: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Message-ID: Sounds reasonable. I recommend looking at the following first though before you start implementation AppAuth [1] and OAuth 2.0 for Native Apps [2] [1] https://appauth.io/ [2] https://tools.ietf.org/html/rfc8252 On 28 May 2018 at 16:34, Gregor Tudan wrote: > Hi there, > > I would like to pick up an old issue: KEYCLOAK-2606 jboss.org/browse/KEYCLOAK-2606> > Our current app uses Keycloak with the Cordova In-App-Browser. Technically > this works fine, but the user experience is ? uhmm ? awful. The page > renders quiet slow and has focus issues. > > I?d love to help getting some support for the browser-tab. I started > porting the ionic sample app to browertabs, but would like to check back > with you before doing something stupid. > > The idea is: > 1. In Keycloak.js Cordova Adapter check if browertab is supported, else > fall back to in-app-browser > 2. Open the login-page with the In-App-Browser (leaving the app) > 3. Register a custom-url-scheme and configure it as redirect url (i.e. > keycloakapp://). We?ll need another Cordova plugin for this (i.e. deep > links). The Cordova-Adapter needs to get extended for this, since > ?localost? seems to be hardcoded as redirect-url) > 4. The Keycloak-server will redirect to the app after login succeeded. The > App will need to reinitialize the Keycloak-Adapter with the code given in > the url - I?m not sure if this will work out of the box. > > Does this sound reasonable? > > Thanks, > Gregor! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Tue May 29 03:39:31 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 29 May 2018 09:39:31 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: References: Message-ID: Hi, I haven't had time to look at your PR in detail yet, but the way it should work is: * We need to add a Token Signature SPI that can sign and validate token signatures * RSA signing should be refactored into a Token Signature provider * Realm should have a default signing algorithm. Admin console should allow admins to select from any supported algorithm by listing TokenSignatureSPI providers * Clients should be able to override the signing algorithm * When verifying signatures in the Keycloak server we should check what the method is for the client (or realm if client doesn't override) and only allow that specific algorithm and nothing else * We may want to consider adding an option to client adapters to specify the expected signing algorithm as well * We also need additional key providers. It looks like you've already added this * We need to make sure that keys are only used for the correct purpose (correct algorithm and if it's for signing or encrypting). I think this is already covered though On 25 May 2018 at 05:26, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > I'd like to use more secure JWS signature algorithm in the environment > where the high security level is required such as the financial industry. > > According to the following RFCs, RSASSA-PSS to which PS256 follows is > recommended on behalf of RSASSA-PKCS1-v1_5 to which RS256 follows. > https://tools.ietf.org/html/rfc3447#section-8 > > However, according to the following RFC, ES256 is "Recommended+" while > PS256 is "Optional". > https://tools.ietf.org/html/rfc7518#section-3.1 > > Moreover, it is said that Elliptic Curve based algorithms have an > advantage against RSA base algorithms in volume of its computation. > > Therefore, I've tried to make keycloak support ES256 JWS signature along > with existing RS256 one. > > I've found that it seemed to be relatively easy to implement software > components for ES256 JWS signature such as Signature Provider and Key > Provider. > However, it seemed to be difficult to implement codes actually calling > these providers. The reasons is as follows. > > * a lot of places have called these singing and verifying providers. > * such the places have been hard-coded in RSA algorithm specific. > > To deal with them, the following ideas have hit on me > > 1. replace RSA algorithm specific codes with signature algorithm > independent codes. > 2. re-design JWS signing and verifying scheme on high level. > > I'm not familiar with keycloak internals, so I've implemented ES256 JWS > signature support on #1 basis experimentally. > I'm not sure whether this way is appropriate or not. I'm very happy if > keycloak specialists consider #2 or review my implementation based on #1. > > I've issued PR as WIP. Please refer to the following in detail. > https://github.com/keycloak/keycloak/pull/5225 > > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From velias at redhat.com Tue May 29 05:16:47 2018 From: velias at redhat.com (Vlastimil Elias) Date: Tue, 29 May 2018 11:16:47 +0200 Subject: [keycloak-dev] Any plans to support Web Authentication API? In-Reply-To: References: <8ac473ae-dc9f-ec66-c848-76f0a740c196@redhat.com> Message-ID: Great news, hopefully it will be sooner rather than later to keep Keycloak at the edge of security and modern technologies ;-) Thanks Vl. On 29.5.2018 09:31, Stian Thorgersen wrote: > Yes, we are planning to add support for web authentication, but not > sure if it will be this year or next. > > On 29 May 2018 at 09:16, Vlastimil Elias > wrote: > > Hi, > > it looks like that Web Authentication API [1] is going to be a new > standard widely adopted by browsers to improve web authentication > security. > > It helps to prevent phishing attacks (as it automatically validates > domain of the login page) and allows to use device's auth hardware > (eg > biometrics HW) to login into websites. > > Any plans to support it in Keycloak? > > More info in Google IO 2018 session and related blogpost [2] > > Thanks > > Vlastimil > > [1] https://www.w3.org/TR/webauthn/ > > [2] https://developers.google.com/web/updates/2018/05/webauthn > > > -- > Vlastimil Elias > Principal Software Engineer, Middleware Engineering Services > Red Hat > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- Vlastimil Elias Principal Software Engineer, Middleware Engineering Services Red Hat From thomas.darimont at googlemail.com Tue May 29 06:08:03 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 29 May 2018 12:08:03 +0200 Subject: [keycloak-dev] Any plans to support Web Authentication API? In-Reply-To: References: <8ac473ae-dc9f-ec66-c848-76f0a740c196@redhat.com> Message-ID: There was an interesting talk about that at Google i/o 2018 https://youtu.be/kGGMgEfSzMw Cheers, Thomas Vlastimil Elias schrieb am Di., 29. Mai 2018, 11:24: > Great news, hopefully it will be sooner rather than later to keep > Keycloak at the edge of security and modern technologies ;-) > > Thanks > > Vl. > > > On 29.5.2018 09:31, Stian Thorgersen wrote: > > Yes, we are planning to add support for web authentication, but not > > sure if it will be this year or next. > > > > On 29 May 2018 at 09:16, Vlastimil Elias > > wrote: > > > > Hi, > > > > it looks like that Web Authentication API [1] is going to be a new > > standard widely adopted by browsers to improve web authentication > > security. > > > > It helps to prevent phishing attacks (as it automatically validates > > domain of the login page) and allows to use device's auth hardware > > (eg > > biometrics HW) to login into websites. > > > > Any plans to support it in Keycloak? > > > > More info in Google IO 2018 session and related blogpost [2] > > > > Thanks > > > > Vlastimil > > > > [1] https://www.w3.org/TR/webauthn/ > > > > > [2] https://developers.google.com/web/updates/2018/05/webauthn > > > > > > -- > > Vlastimil Elias > > Principal Software Engineer, Middleware Engineering Services > > Red Hat > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > Vlastimil Elias > Principal Software Engineer, Middleware Engineering Services > Red Hat > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From Gregor.Tudan at cofinpro.de Tue May 29 07:57:11 2018 From: Gregor.Tudan at cofinpro.de (Gregor Tudan) Date: Tue, 29 May 2018 11:57:11 +0000 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova In-Reply-To: References: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Message-ID: Hey Stian, Thanks, I took a good look at most of the libraries out there - but I still would love to continue using Keycloak.js. I got quiet far pretty fast by implementing a second Cordova adapter ("Cordova-native?) and falling back to the old one it the required plugin is missing. Or would you prefer extending the existing Cordova adapter? That would make the code a little messy, since we would need a huge if in every method. Figuring out the callback wasn?t to hard either - now the last missing piece is parsing the callback. Here we have the option of registering a universal link inside the Keycloak adapter which opens the app, or leaving this to the developer and provide a public method for it (like processCallback). I?m not quiet sure on these options, what are your thoughts on this? - Gregor Am 29.05.2018 um 09:33 schrieb Stian Thorgersen >: Sounds reasonable. I recommend looking at the following first though before you start implementation AppAuth [1] and OAuth 2.0 for Native Apps [2] [1] https://appauth.io/ [2] https://tools.ietf.org/html/rfc8252 On 28 May 2018 at 16:34, Gregor Tudan > wrote: Hi there, I would like to pick up an old issue: KEYCLOAK-2606 Our current app uses Keycloak with the Cordova In-App-Browser. Technically this works fine, but the user experience is ? uhmm ? awful. The page renders quiet slow and has focus issues. I?d love to help getting some support for the browser-tab. I started porting the ionic sample app to browertabs, but would like to check back with you before doing something stupid. The idea is: 1. In Keycloak.js Cordova Adapter check if browertab is supported, else fall back to in-app-browser 2. Open the login-page with the In-App-Browser (leaving the app) 3. Register a custom-url-scheme and configure it as redirect url (i.e. keycloakapp://). We?ll need another Cordova plugin for this (i.e. deep links). The Cordova-Adapter needs to get extended for this, since ?localost? seems to be hardcoded as redirect-url) 4. The Keycloak-server will redirect to the app after login succeeded. The App will need to reinitialize the Keycloak-Adapter with the code given in the url - I?m not sure if this will work out of the box. Does this sound reasonable? Thanks, Gregor! _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From thomas.darimont at googlemail.com Tue May 29 20:01:50 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 30 May 2018 01:01:50 +0100 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) Message-ID: Hi there, I was recently playing with the PKCE support in Keycloak (server) which worked quite well. However the support for client / adapters seems to be quite limited at the moment... I think support for PKCE to all? java adapters could be added quite easily - I could provide a PR but I'm currently stuck with finding a generic way to store the codeVerifier generated for the login redirect for later retrival for the code2token exchange. Do you have any recommendations for this? I created the following JIRA issue (with some comments) to track this: https://issues.jboss.org/browse/KEYCLOAK-7467 Cheers, Thomas From takashi.norimatsu.ws at hitachi.com Wed May 30 01:47:38 2018 From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=) Date: Wed, 30 May 2018 05:47:38 +0000 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) Message-ID: Hello, I've encountered the same problem and gave up. At that time, the naive idea had hit on me. * prepare some concurrently accessible singleton (line KeycloakDeployment) from OAuthRequestAuthenticator * store generated codeVerifier on it with state parameter value as its key. But, considering the nature of codeVerifier, the followings are required for such the store * codeVerifier should be treated the same secure levels as client credentials * codeVerifier should be short-lived and deleted after its life the same as Authorization Code Therefore, It might be better to create an tentative instance whose lifetime is between issuing Authorization Code Request and issuing Token Request. And, it should be identified and only accessible from the session instance who issued Authorization Code Request. However, I'm afraid it might be difficult to accomplish it in generic fashion. We need to implement the above each type of client adapter. Best regards, Takashi Norimatsu Hitachi Ltd., -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org On Behalf Of Thomas Darimont Sent: Wednesday, May 30, 2018 9:02 AM To: keycloak-dev Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) Hi there, I was recently playing with the PKCE support in Keycloak (server) which worked quite well. However the support for client / adapters seems to be quite limited at the moment... I think support for PKCE to all? java adapters could be added quite easily - I could provide a PR but I'm currently stuck with finding a generic way to store the codeVerifier generated for the login redirect for later retrival for the code2token exchange. Do you have any recommendations for this? I created the following JIRA issue (with some comments) to track this: https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 Cheers, Thomas _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev From takashi.norimatsu.ws at hitachi.com Wed May 30 01:49:16 2018 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Wed, 30 May 2018 05:49:16 +0000 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing Message-ID: Hello, Thank you for your comments. I think it might be better to determine which kind of Token Signature Provider be used by not parsing JWS, for example, looking up Client or Realm settings. This PR might have impacts on keycloak's performance because it has parsed JWS to determine it every time keycloak receives JWS Token. As for existing Key Provider, I've already implemented ECDSA Key Provider (for only signing) in this PR. Therefore, I could contribute it. As for Token Signature SPI, I agree with you. I hope I would like to implement this SPI's provider for ES256 at first and PS256 in the future. I think it is the best way that keycloak's core committers design and implement this Token Signature SPI. However, if they do not have yet such a plan to do that at this time and in the future, I would like to give some ideas on Token Signature SPI. How do you think about that? Best regards, Takashi Norimatsu Hitachi Ltd., From: Stian Thorgersen Sent: Tuesday, May 29, 2018 4:40 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing Hi, I haven't had time to look at your PR in detail yet, but the way it should work is: * We need to add a Token Signature SPI that can sign and validate token signatures * RSA signing should be refactored into a?Token Signature provider * Realm should have a default signing algorithm. Admin console should allow admins to select from any supported algorithm by listing?TokenSignatureSPI providers * Clients should be able to override the signing algorithm * When verifying signatures in the Keycloak server we should check what the method is for the client (or realm if client doesn't override) and only allow that specific algorithm and nothing else * We may want to consider adding an option to client adapters to specify the expected signing algorithm as well * We also need additional key providers. It looks like you've already added this * We need to make sure that keys are only used for the correct purpose (correct algorithm and if it's for signing or encrypting). I think this is already covered though On 25 May 2018 at 05:26, ???? / NORIMATSU?TAKASHI wrote: I'd like to use more secure JWS signature algorithm in the environment where the high security level is required such as the financial industry. According to the following RFCs, RSASSA-PSS to which PS256 follows is recommended on behalf of RSASSA-PKCS1-v1_5 to which RS256 follows. https://clicktime.symantec.com/a/1/fIIShrle28DIlWvWduZOOVGDLk3xC_-rnn6V7E4iCwU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3447%23section-8 However, according to the following RFC, ES256 is "Recommended+" while PS256 is "Optional". https://clicktime.symantec.com/a/1/s_2w8zdHH2DoCkMCU7h9NMxUrcVZyNjiGxV6Meq8vTM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7518%23section-3.1 Moreover, it is said that Elliptic Curve based algorithms have an advantage against RSA base algorithms in volume of its computation. Therefore, I've tried to make keycloak support ES256 JWS signature along with existing RS256 one. I've found that it seemed to be relatively easy to implement software components for ES256 JWS signature such as Signature Provider and Key Provider. However, it seemed to be difficult to implement codes actually calling these providers. The reasons is as follows. * a lot of places have called these singing and verifying providers. * such the places have been hard-coded in RSA algorithm specific. To deal with them, the following ideas have hit on me 1. replace RSA algorithm specific codes with signature algorithm independent codes. 2. re-design JWS signing and verifying scheme on high level. I'm not familiar with keycloak internals, so I've implemented ES256 JWS signature support on #1 basis experimentally. I'm not sure whether this way is appropriate or not. I'm very happy if keycloak specialists consider #2 or review my implementation based on #1. I've issued PR as WIP. Please refer to the following in detail. https://clicktime.symantec.com/a/1/G-XuERmswRIcQ_MQA72oK1EJuT0Y48iac1LbbsWkrOU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5225 Best regards, Takashi Norimatsu Hitachi Ltd., _______________________________________________ keycloak-dev mailing list mailto:keycloak-dev at lists.jboss.org https://clicktime.symantec.com/a/1/LBlgE63-JxZCbiegUCPqUTy7Oeq2A8tzZfOiWvp-KfM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev From sthorger at redhat.com Wed May 30 03:19:23 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 May 2018 09:19:23 +0200 Subject: [keycloak-dev] Testing with mocking libraries? Message-ID: At the moment our testing strategy is only with functional or integration level tests. Both with the full server up and running and primarily testing through public APIs. Now here comes the question should we also allow testing through a mocking library like Mockito? In general I'm against mocking libraries. At best you end up with something that may work, but you're not guaranteed that it actually works. They also have a very big maintenance cost when any changes are made to the codebase. However, take a look at https://github.com/keycloak/keycloak/pull/5215 for example. It is a contribution to add support for the hd param to the Google login. Not sure how else we could test this without a mocking library. From sthorger at redhat.com Wed May 30 03:27:04 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 May 2018 09:27:04 +0200 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova In-Reply-To: References: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Message-ID: On 29 May 2018 at 13:57, Gregor Tudan wrote: > Hey Stian, > > Thanks, I took a good look at most of the libraries out there - but I > still would love to continue using Keycloak.js. > Great, would love to see this added to keycloak.js. Was primarily pointing to AppAuth as a source of inspiration rather than suggesting you use that instead. > > I got quiet far pretty fast by implementing a second Cordova adapter > ("Cordova-native?) and falling back to the old one it the required plugin > is missing. Or would you prefer extending the existing Cordova adapter? > That would make the code a little messy, since we would need a huge if in > every method. > Adding a second adapter is a nice and clean way to do it. > > Figuring out the callback wasn?t to hard either - now the last missing > piece is parsing the callback. Here we have the option of registering a > universal link inside the Keycloak adapter which opens the app, or leaving > this to the developer and provide a public method for it (like > processCallback). > > I?m not quiet sure on these options, what are your thoughts on this? > Could you elaborate a bit on this please? > > - Gregor > > > Am 29.05.2018 um 09:33 schrieb Stian Thorgersen : > > Sounds reasonable. I recommend looking at the following first though > before you start implementation AppAuth [1] and OAuth 2.0 for Native Apps > [2] > > [1] https://appauth.io/ > [2] https://tools.ietf.org/html/rfc8252 > > On 28 May 2018 at 16:34, Gregor Tudan wrote: > >> Hi there, >> >> I would like to pick up an old issue: KEYCLOAK-2606> boss.org/browse/KEYCLOAK-2606> >> Our current app uses Keycloak with the Cordova In-App-Browser. >> Technically this works fine, but the user experience is ? uhmm ? awful. The >> page renders quiet slow and has focus issues. >> >> I?d love to help getting some support for the browser-tab. I started >> porting the ionic sample app to browertabs, but would like to check back >> with you before doing something stupid. >> >> The idea is: >> 1. In Keycloak.js Cordova Adapter check if browertab is supported, else >> fall back to in-app-browser >> 2. Open the login-page with the In-App-Browser (leaving the app) >> 3. Register a custom-url-scheme and configure it as redirect url (i.e. >> keycloakapp://). We?ll need another Cordova plugin for this (i.e. deep >> links). The Cordova-Adapter needs to get extended for this, since >> ?localost? seems to be hardcoded as redirect-url) >> 4. The Keycloak-server will redirect to the app after login succeeded. >> The App will need to reinitialize the Keycloak-Adapter with the code given >> in the url - I?m not sure if this will work out of the box. >> >> Does this sound reasonable? >> >> Thanks, >> Gregor! >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From sthorger at redhat.com Wed May 30 03:30:18 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 May 2018 09:30:18 +0200 Subject: [keycloak-dev] Any plans to support Web Authentication API? In-Reply-To: References: <8ac473ae-dc9f-ec66-c848-76f0a740c196@redhat.com> Message-ID: The challenges here is to find decent open source libraries that support web authentication as well as figuring out how we can test it. We also need to extend Keycloak to properly support multiple types of two factor authenticators and not be so hard-coded to just OTP like it is today. On 29 May 2018 at 12:08, Thomas Darimont wrote: > There was an interesting talk about that at Google i/o 2018 > https://youtu.be/kGGMgEfSzMw > > Cheers, > Thomas > > Vlastimil Elias schrieb am Di., 29. Mai 2018, 11:24: > >> Great news, hopefully it will be sooner rather than later to keep >> Keycloak at the edge of security and modern technologies ;-) >> >> Thanks >> >> Vl. >> >> >> On 29.5.2018 09:31, Stian Thorgersen wrote: >> > Yes, we are planning to add support for web authentication, but not >> > sure if it will be this year or next. >> > >> > On 29 May 2018 at 09:16, Vlastimil Elias > > > wrote: >> > >> > Hi, >> > >> > it looks like that Web Authentication API [1] is going to be a new >> > standard widely adopted by browsers to improve web authentication >> > security. >> > >> > It helps to prevent phishing attacks (as it automatically validates >> > domain of the login page) and allows to use device's auth hardware >> > (eg >> > biometrics HW) to login into websites. >> > >> > Any plans to support it in Keycloak? >> > >> > More info in Google IO 2018 session and related blogpost [2] >> > >> > Thanks >> > >> > Vlastimil >> > >> > [1] https://www.w3.org/TR/webauthn/ > webauthn/> >> > >> > [2] https://developers.google.com/web/updates/2018/05/webauthn >> > >> > >> > -- >> > Vlastimil Elias >> > Principal Software Engineer, Middleware Engineering Services >> > Red Hat >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> >> -- >> Vlastimil Elias >> Principal Software Engineer, Middleware Engineering Services >> Red Hat >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From sthorger at redhat.com Wed May 30 03:35:23 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 May 2018 09:35:23 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: References: Message-ID: On 30 May 2018 at 07:49, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > Hello, > > Thank you for your comments. > > I think it might be better to determine which kind of Token Signature > Provider be used by not parsing JWS, for example, looking up Client or > Realm settings. > This PR might have impacts on keycloak's performance because it has parsed > JWS to determine it every time keycloak receives JWS Token. > On the server-side that is easy. On the adapter side that would probably require adding a property to keycloak.json to set the algorithm. In either case it should probably default to RSA for existing realms at least, but we could consider setting it to ES256 for new realms. > > As for existing Key Provider, I've already implemented ECDSA Key Provider > (for only signing) in this PR. Therefore, I could contribute it. > > As for Token Signature SPI, I agree with you. I hope I would like to > implement this SPI's provider for ES256 at first and PS256 in the future. > > I think it is the best way that keycloak's core committers design and > implement this Token Signature SPI. > However, if they do not have yet such a plan to do that at this time and > in the future, I would like to give some ideas on Token Signature SPI. How > do you think about that? > We don't currently have any plans on implementing this SPI and where holding off on it until we started work on adding ES256. The ideal here may be that someone from the core team work on the SPI and refactoring of RSA provider, then you can update the PR for ES256. Unless you feel that you may be able to contribute that as well? If so I would prefer a separate PR for the SPI and refactoring. > > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > From: Stian Thorgersen > Sent: Tuesday, May 29, 2018 4:40 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] JWS signatures using PS256 or ES256 > algorithms for signing > > Hi, > > I haven't had time to look at your PR in detail yet, but the way it should > work is: > > * We need to add a Token Signature SPI that can sign and validate token > signatures > * RSA signing should be refactored into a Token Signature provider > * Realm should have a default signing algorithm. Admin console should > allow admins to select from any supported algorithm by > listing TokenSignatureSPI providers > * Clients should be able to override the signing algorithm > * When verifying signatures in the Keycloak server we should check what > the method is for the client (or realm if client doesn't override) and only > allow that specific algorithm and nothing else > * We may want to consider adding an option to client adapters to specify > the expected signing algorithm as well > * We also need additional key providers. It looks like you've already > added this > * We need to make sure that keys are only used for the correct purpose > (correct algorithm and if it's for signing or encrypting). I think this is > already covered though > > > On 25 May 2018 at 05:26, ???? / NORIMATSU?TAKASHI takashi.norimatsu.ws at hitachi.com> wrote: > I'd like to use more secure JWS signature algorithm in the environment > where the high security level is required such as the financial industry. > > According to the following RFCs, RSASSA-PSS to which PS256 follows is > recommended on behalf of RSASSA-PKCS1-v1_5 to which RS256 follows. > https://clicktime.symantec.com/a/1/fIIShrle28DIlWvWduZOOVGDLk3xC_ > -rnn6V7E4iCwU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH > m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L > qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu > Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- > ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq > TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 > 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ > uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= > https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3447%23section-8 > > However, according to the following RFC, ES256 is "Recommended+" while > PS256 is "Optional". > https://clicktime.symantec.com/a/1/s_2w8zdHH2DoCkMCU7h9NMxUrcVZyNji > GxV6Meq8vTM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH > m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L > qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu > Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- > ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq > TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 > 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ > uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= > https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7518%23section-3.1 > > Moreover, it is said that Elliptic Curve based algorithms have an > advantage against RSA base algorithms in volume of its computation. > > Therefore, I've tried to make keycloak support ES256 JWS signature along > with existing RS256 one. > > I've found that it seemed to be relatively easy to implement software > components for ES256 JWS signature such as Signature Provider and Key > Provider. > However, it seemed to be difficult to implement codes actually calling > these providers. The reasons is as follows. > > * a lot of places have called these singing and verifying providers. > * such the places have been hard-coded in RSA algorithm specific. > > To deal with them, the following ideas have hit on me > > 1. replace RSA algorithm specific codes with signature algorithm > independent codes. > 2. re-design JWS signing and verifying scheme on high level. > > I'm not familiar with keycloak internals, so I've implemented ES256 JWS > signature support on #1 basis experimentally. > I'm not sure whether this way is appropriate or not. I'm very happy if > keycloak specialists consider #2 or review my implementation based on #1. > > I've issued PR as WIP. Please refer to the following in detail. > https://clicktime.symantec.com/a/1/G-XuERmswRIcQ_ > MQA72oK1EJuT0Y48iac1LbbsWkrOU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH > m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L > qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu > Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- > ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq > TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 > 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ > uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= > https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5225 > > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > _______________________________________________ > keycloak-dev mailing list > mailto:keycloak-dev at lists.jboss.org > https://clicktime.symantec.com/a/1/LBlgE63-JxZCbiegUCPqUTy7Oeq2A8tzZfOiWv > p-KfM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYH > m1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1L > qudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7Tu > Rlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj- > ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimq > TmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL24 > 8j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_ > uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u= > https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev > > From sthorger at redhat.com Wed May 30 03:38:17 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 May 2018 09:38:17 +0200 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: As PKCE is aimed at public clients why is there a need to add support for this to the Java adapters? Makes more sense to add this to the JavaScript adapter and CLI/desktop adapter. On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > Hello, > > I've encountered the same problem and gave up. > > At that time, the naive idea had hit on me. > * prepare some concurrently accessible singleton (line KeycloakDeployment) > from OAuthRequestAuthenticator > * store generated codeVerifier on it with state parameter value as its > key. > > But, considering the nature of codeVerifier, the followings are required > for such the store > * codeVerifier should be treated the same secure levels as client > credentials > * codeVerifier should be short-lived and deleted after its life the same > as Authorization Code > > Therefore, It might be better to create an tentative instance whose > lifetime is between issuing Authorization Code Request and issuing Token > Request. And, it should be identified and only accessible from the session > instance who issued Authorization Code Request. > > However, I'm afraid it might be difficult to accomplish it in generic > fashion. We need to implement the above each type of client adapter. > > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org jboss.org> On Behalf Of Thomas Darimont > Sent: Wednesday, May 30, 2018 9:02 AM > To: keycloak-dev > Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters > (OAuthRequestAuthenticator) > > Hi there, > > I was recently playing with the PKCE support in Keycloak (server) which > worked quite well. > However the support for client / adapters seems to be quite limited at the > moment... > > I think support for PKCE to all? java adapters could be added quite easily > - I could provide a > PR but I'm currently stuck with finding a generic way to store the > codeVerifier generated for the login redirect for later retrival for the > code2token exchange. > > Do you have any recommendations for this? > > I created the following JIRA issue (with some comments) to track this: > https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabix > m_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA- > PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78 > dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_ > 98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudB > wcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z- > FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_ > dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr- > byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w- > uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues. > jboss.org%2Fbrowse%2FKEYCLOAK-7467 > > Cheers, > Thomas > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_ > cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA- > PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78 > dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_ > 98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudB > wcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z- > FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_ > dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr- > byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w- > uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman% > 2Flistinfo%2Fkeycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From Gregor.Tudan at cofinpro.de Wed May 30 04:26:59 2018 From: Gregor.Tudan at cofinpro.de (Gregor Tudan) Date: Wed, 30 May 2018 08:26:59 +0000 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova In-Reply-To: References: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Message-ID: Figuring out the callback wasn?t to hard either - now the last missing piece is parsing the callback. Here we have the option of registering a universal link inside the Keycloak adapter which opens the app, or leaving this to the developer and provide a public method for it (like processCallback). I?m not quiet sure on these options, what are your thoughts on this? Could you elaborate a bit on this please? Sure - The way those native browser tabs work is that the app requests to open a site, but has no access to what happens inside the browser. After the login is done, the browser redirects back into the app by using universal links. These URLs have be registered in the app, so the browser knows that it should pass those requests back. From there, we can get the oauth params (state and code) and fetch the token. The question is: should we implement this kind of callback logic inside the adapter, or should we provide the user a method for completing the login process upon redirecting? If we do this in the adapter, we would need to make some assumptions on the Cordova-Plugin being used and how the link is set up. I don?t think that?s a bad thing, but we would need to document how to setup the app so that the redirect works. This would also fit nicely in the current API of the adapter. The other option would be to leave it up to the user to handle the redirect and offer a callback for finishing the authorization. This would basically boil down to a method that takes the code and the state params (like processCallback in the current adapter). This would kind of break the API of the adapter, as the login method will behave differently for this native adapter. To summarize: doing more stuff in the adapter would simplify things for the developer, but might not work for existing apps - i.e. if they use a different plugin for handling universal links. I suggest starting with first option (handling redirects in the adapter) to get started - universal links don?t seem to be to widely used, so most apps shouldn?t run into problems with us picking a plugin for them. Maybe we can add another option to the adapter for manual redirect-handling later on. From thomas.darimont at googlemail.com Wed May 30 18:57:14 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 30 May 2018 23:57:14 +0100 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: Good point. Yes the main use case for PKCE are public clients / native apps. However the recently published OAuth 2.0 Security Best Current Practice (Draft 06 2018) [1] states: " 2.1. Protecting redirect-based flows ... Clients shall use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts to inject (replay) authorization codes into the authorization response. The PKCE challenges must be transaction-specific and securely bound to the user agent, in which the transaction was started. OpenID Connect clients may use the "nonce" parameter of the OpenID Connect authentication request as specified in [OpenID] in conjunction with the corresponding ID Token claim for the same purpose. Note: although PKCE so far was recommended as mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications. " The last "Note" section was what inspired me to look into PKCE support for server-side adapters as well. But I generally agree that this is probably better suited for the JS / CLI/ keycloak-installed adapters. [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen wrote: > As PKCE is aimed at public clients why is there a need to add support for > this to the Java adapters? Makes more sense to add this to the JavaScript > adapter and CLI/desktop adapter. > > On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > >> Hello, >> >> I've encountered the same problem and gave up. >> >> At that time, the naive idea had hit on me. >> * prepare some concurrently accessible singleton (line >> KeycloakDeployment) from OAuthRequestAuthenticator >> * store generated codeVerifier on it with state parameter value as its >> key. >> >> But, considering the nature of codeVerifier, the followings are required >> for such the store >> * codeVerifier should be treated the same secure levels as client >> credentials >> * codeVerifier should be short-lived and deleted after its life the same >> as Authorization Code >> >> Therefore, It might be better to create an tentative instance whose >> lifetime is between issuing Authorization Code Request and issuing Token >> Request. And, it should be identified and only accessible from the session >> instance who issued Authorization Code Request. >> >> However, I'm afraid it might be difficult to accomplish it in generic >> fashion. We need to implement the above each type of client adapter. >> >> Best regards, >> Takashi Norimatsu >> Hitachi Ltd., >> >> -----Original Message----- >> From: keycloak-dev-bounces at lists.jboss.org < >> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont >> Sent: Wednesday, May 30, 2018 9:02 AM >> To: keycloak-dev >> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters >> (OAuthRequestAuthenticator) >> >> Hi there, >> >> I was recently playing with the PKCE support in Keycloak (server) which >> worked quite well. >> However the support for client / adapters seems to be quite limited at >> the moment... >> >> I think support for PKCE to all? java adapters could be added quite easily >> - I could provide a >> PR but I'm currently stuck with finding a generic way to store the >> codeVerifier generated for the login redirect for later retrival for the >> code2token exchange. >> >> Do you have any recommendations for this? >> >> I created the following JIRA issue (with some comments) to track this: >> >> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 >> >> Cheers, >> Thomas >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From mposolda at redhat.com Thu May 31 02:38:50 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 31 May 2018 08:38:50 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: Message-ID: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Not sure. I am not strongly against it, but I afraid that if we introduce some mocks support, people (especially from community) will start to test with mocks everywhere and add them to all PRs (even to those which could be easily tested properly). Not sure if it's better alternative to skip automated test at all instead of test with mocks? But for this one, I guess we can likely extend our social test with an account from hosted domain and hence test it properly? Marek On 30/05/18 09:19, Stian Thorgersen wrote: > At the moment our testing strategy is only with functional or integration > level tests. Both with the full server up and running and primarily testing > through public APIs. > > Now here comes the question should we also allow testing through a mocking > library like Mockito? > > In general I'm against mocking libraries. At best you end up with something > that may work, but you're not guaranteed that it actually works. They also > have a very big maintenance cost when any changes are made to the codebase. > > However, take a look at https://github.com/keycloak/keycloak/pull/5215 for > example. It is a contribution to add support for the hd param to the Google > login. Not sure how else we could test this without a mocking library. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From thomas.darimont at googlemail.com Thu May 31 08:09:47 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 31 May 2018 13:09:47 +0100 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: Hi folks, I've got a working PoC for PKCE support in the Keycloak JS adapter that supports `plain` and `S256` code_challenge_methods. Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final. Perhaps this could serve as a base for a real PR. I needed to use two small js libraries to have proper support for sha256 and base64 encoding for Unit8Arrays in order to produce a codeChallenge in the same way the Keycloak server does it, for details see commit. Branch: https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support Commit: https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8 Looks like this would solve the issue https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably need to be renamed). Cheers, Thomas On Wed, May 30, 2018 at 11:57 PM Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Good point. Yes the main use case for PKCE are public clients / native > apps. > > However the recently published OAuth 2.0 Security Best Current Practice > (Draft 06 2018) [1] states: > " > 2.1. Protecting redirect-based flows > ... > Clients shall use PKCE [RFC7636] in order to (with the help of the > authorization server) detect and prevent attempts to inject (replay) > authorization codes into the authorization response. The PKCE > challenges must be transaction-specific and securely bound to the > user agent, in which the transaction was started. OpenID Connect > clients may use the "nonce" parameter of the OpenID Connect > authentication request as specified in [OpenID] in conjunction with > the corresponding ID Token claim for the same purpose. > > Note: although PKCE so far was recommended as mechanism to protect > native apps, this advice applies to all kinds of OAuth clients, > including web applications. > " > The last "Note" section was what inspired me to look into PKCE support for > server-side adapters as well. > But I generally agree that this is probably better suited for the JS / > CLI/ keycloak-installed adapters. > > [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 > > On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen > wrote: > >> As PKCE is aimed at public clients why is there a need to add support >> for this to the Java adapters? Makes more sense to add this to the >> JavaScript adapter and CLI/desktop adapter. >> >> On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < >> takashi.norimatsu.ws at hitachi.com> wrote: >> >>> Hello, >>> >>> I've encountered the same problem and gave up. >>> >>> At that time, the naive idea had hit on me. >>> * prepare some concurrently accessible singleton (line >>> KeycloakDeployment) from OAuthRequestAuthenticator >>> * store generated codeVerifier on it with state parameter value as its >>> key. >>> >>> But, considering the nature of codeVerifier, the followings are required >>> for such the store >>> * codeVerifier should be treated the same secure levels as client >>> credentials >>> * codeVerifier should be short-lived and deleted after its life the same >>> as Authorization Code >>> >>> Therefore, It might be better to create an tentative instance whose >>> lifetime is between issuing Authorization Code Request and issuing Token >>> Request. And, it should be identified and only accessible from the session >>> instance who issued Authorization Code Request. >>> >>> However, I'm afraid it might be difficult to accomplish it in generic >>> fashion. We need to implement the above each type of client adapter. >>> >>> Best regards, >>> Takashi Norimatsu >>> Hitachi Ltd., >>> >>> -----Original Message----- >>> From: keycloak-dev-bounces at lists.jboss.org < >>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont >>> Sent: Wednesday, May 30, 2018 9:02 AM >>> To: keycloak-dev >>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters >>> (OAuthRequestAuthenticator) >>> >>> Hi there, >>> >>> I was recently playing with the PKCE support in Keycloak (server) which >>> worked quite well. >>> However the support for client / adapters seems to be quite limited at >>> the moment... >>> >>> I think support for PKCE to all? java adapters could be added quite >>> easily >>> - I could provide a >>> PR but I'm currently stuck with finding a generic way to store the >>> codeVerifier generated for the login redirect for later retrival for the >>> code2token exchange. >>> >>> Do you have any recommendations for this? >>> >>> I created the following JIRA issue (with some comments) to track this: >>> >>> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 >>> >>> Cheers, >>> Thomas >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> From asaldanha1947 at gmail.com Thu May 31 10:44:59 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Thu, 31 May 2018 09:44:59 -0500 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: You really have to test your core logic (with no server set up) using integration tests with mocking libraries. One way to test out all the possible preconditions to your logic. You will be doing a service to your customers and users by shielding them from those nasty exceptions (NPEs) that happen in an integration platform such as KeyCloak/RH-SSO. :-) /me wearing a user/customer hat On Thu, May 31, 2018 at 1:38 AM, Marek Posolda wrote: > Not sure. I am not strongly against it, but I afraid that if we > introduce some mocks support, people (especially from community) will > start to test with mocks everywhere and add them to all PRs (even to > those which could be easily tested properly). Not sure if it's better > alternative to skip automated test at all instead of test with mocks? > > But for this one, I guess we can likely extend our social test with an > account from hosted domain and hence test it properly? > > Marek > > > On 30/05/18 09:19, Stian Thorgersen wrote: > > At the moment our testing strategy is only with functional or integration > > level tests. Both with the full server up and running and primarily > testing > > through public APIs. > > > > Now here comes the question should we also allow testing through a > mocking > > library like Mockito? > > > > In general I'm against mocking libraries. At best you end up with > something > > that may work, but you're not guaranteed that it actually works. They > also > > have a very big maintenance cost when any changes are made to the > codebase. > > > > However, take a look at https://github.com/keycloak/keycloak/pull/5215 > for > > example. It is a contribution to add support for the hd param to the > Google > > login. Not sure how else we could test this without a mocking library. > > _______________________________________________ > > 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 > From bburke at redhat.com Thu May 31 11:17:31 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 31 May 2018 11:17:31 -0400 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: Never liked mocks either as they are just opinionated warped perceptions of reality. But there are cases where I think we need them off the top of my head: * Openshift integration * Social logins. Openshift we just won't have the infrastructure for it. Social login tests require accounts which we won't want to share the logins for in a public CI. We need something in public CI so that we can catch at least some potential problems and that we can easily try to reproduce in local IDE environments. Mocks wouldn't be a replacement for real integration testing, just a stop gap. On Thu, May 31, 2018 at 10:44 AM, Anil Saldanha wrote: > You really have to test your core logic (with no server set up) using > integration tests with mocking libraries. One way to test out all the > possible preconditions to your logic. > > You will be doing a service to your customers and users by shielding them > from those nasty exceptions (NPEs) that happen in an integration platform > such as KeyCloak/RH-SSO. :-) > > /me wearing a user/customer hat > > On Thu, May 31, 2018 at 1:38 AM, Marek Posolda wrote: > >> Not sure. I am not strongly against it, but I afraid that if we >> introduce some mocks support, people (especially from community) will >> start to test with mocks everywhere and add them to all PRs (even to >> those which could be easily tested properly). Not sure if it's better >> alternative to skip automated test at all instead of test with mocks? >> >> But for this one, I guess we can likely extend our social test with an >> account from hosted domain and hence test it properly? >> >> Marek >> >> >> On 30/05/18 09:19, Stian Thorgersen wrote: >> > At the moment our testing strategy is only with functional or integration >> > level tests. Both with the full server up and running and primarily >> testing >> > through public APIs. >> > >> > Now here comes the question should we also allow testing through a >> mocking >> > library like Mockito? >> > >> > In general I'm against mocking libraries. At best you end up with >> something >> > that may work, but you're not guaranteed that it actually works. They >> also >> > have a very big maintenance cost when any changes are made to the >> codebase. >> > >> > However, take a look at https://github.com/keycloak/keycloak/pull/5215 >> for >> > example. It is a contribution to add support for the hd param to the >> Google >> > login. Not sure how else we could test this without a mocking library. >> > _______________________________________________ >> > 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 >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From asaldanha1947 at gmail.com Thu May 31 12:08:20 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Thu, 31 May 2018 11:08:20 -0500 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: I am sorry I have not looked at your integration tests. So I may be wrong here. One area that I feel that you need lots of integration tests is in the "Identity Brokering" feature. You have way too many permutations and combinations (with authentication flows) that without proper integration tests/mocks, you will not do proper justice to the value of KC/RH-SSO. On Thu, May 31, 2018 at 10:17 AM, Bill Burke wrote: > Never liked mocks either as they are just opinionated warped > perceptions of reality. But there are cases where I think we need > them off the top of my head: > > * Openshift integration > * Social logins. > > Openshift we just won't have the infrastructure for it. Social login > tests require accounts which we won't want to share the logins for in > a public CI. We need something in public CI so that we can catch at > least some potential problems and that we can easily try to reproduce > in local IDE environments. Mocks wouldn't be a replacement for real > integration testing, just a stop gap. > > > > On Thu, May 31, 2018 at 10:44 AM, Anil Saldanha > wrote: > > You really have to test your core logic (with no server set up) using > > integration tests with mocking libraries. One way to test out all the > > possible preconditions to your logic. > > > > You will be doing a service to your customers and users by shielding them > > from those nasty exceptions (NPEs) that happen in an integration platform > > such as KeyCloak/RH-SSO. :-) > > > > /me wearing a user/customer hat > > > > On Thu, May 31, 2018 at 1:38 AM, Marek Posolda > wrote: > > > >> Not sure. I am not strongly against it, but I afraid that if we > >> introduce some mocks support, people (especially from community) will > >> start to test with mocks everywhere and add them to all PRs (even to > >> those which could be easily tested properly). Not sure if it's better > >> alternative to skip automated test at all instead of test with mocks? > >> > >> But for this one, I guess we can likely extend our social test with an > >> account from hosted domain and hence test it properly? > >> > >> Marek > >> > >> > >> On 30/05/18 09:19, Stian Thorgersen wrote: > >> > At the moment our testing strategy is only with functional or > integration > >> > level tests. Both with the full server up and running and primarily > >> testing > >> > through public APIs. > >> > > >> > Now here comes the question should we also allow testing through a > >> mocking > >> > library like Mockito? > >> > > >> > In general I'm against mocking libraries. At best you end up with > >> something > >> > that may work, but you're not guaranteed that it actually works. They > >> also > >> > have a very big maintenance cost when any changes are made to the > >> codebase. > >> > > >> > However, take a look at https://github.com/keycloak/ > keycloak/pull/5215 > >> for > >> > example. It is a contribution to add support for the hd param to the > >> Google > >> > login. Not sure how else we could test this without a mocking library. > >> > _______________________________________________ > >> > 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 > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > Red Hat > From sthorger at redhat.com Thu May 31 14:20:57 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 31 May 2018 20:20:57 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: With regards to Identity Brokering and Social Login one potentially better way to do it would be to have a mocked IdP. At least then you are testing the actual HTTP calls and it's much closer to a real scenario than doing junit tests with mocks and only testing parts of the code base. On 31 May 2018 at 18:08, Anil Saldanha wrote: > I am sorry I have not looked at your integration tests. So I may be wrong > here. > > One area that I feel that you need lots of integration tests is in the > "Identity Brokering" feature. You have way too many permutations and > combinations (with authentication flows) that without proper integration > tests/mocks, you will not do proper justice to the value of KC/RH-SSO. > > On Thu, May 31, 2018 at 10:17 AM, Bill Burke wrote: > >> Never liked mocks either as they are just opinionated warped >> perceptions of reality. But there are cases where I think we need >> them off the top of my head: >> >> * Openshift integration >> * Social logins. >> >> Openshift we just won't have the infrastructure for it. Social login >> tests require accounts which we won't want to share the logins for in >> a public CI. We need something in public CI so that we can catch at >> least some potential problems and that we can easily try to reproduce >> in local IDE environments. Mocks wouldn't be a replacement for real >> integration testing, just a stop gap. >> >> >> >> On Thu, May 31, 2018 at 10:44 AM, Anil Saldanha >> wrote: >> > You really have to test your core logic (with no server set up) using >> > integration tests with mocking libraries. One way to test out all the >> > possible preconditions to your logic. >> > >> > You will be doing a service to your customers and users by shielding >> them >> > from those nasty exceptions (NPEs) that happen in an integration >> platform >> > such as KeyCloak/RH-SSO. :-) >> > >> > /me wearing a user/customer hat >> > >> > On Thu, May 31, 2018 at 1:38 AM, Marek Posolda >> wrote: >> > >> >> Not sure. I am not strongly against it, but I afraid that if we >> >> introduce some mocks support, people (especially from community) will >> >> start to test with mocks everywhere and add them to all PRs (even to >> >> those which could be easily tested properly). Not sure if it's better >> >> alternative to skip automated test at all instead of test with mocks? >> >> >> >> But for this one, I guess we can likely extend our social test with an >> >> account from hosted domain and hence test it properly? >> >> >> >> Marek >> >> >> >> >> >> On 30/05/18 09:19, Stian Thorgersen wrote: >> >> > At the moment our testing strategy is only with functional or >> integration >> >> > level tests. Both with the full server up and running and primarily >> >> testing >> >> > through public APIs. >> >> > >> >> > Now here comes the question should we also allow testing through a >> >> mocking >> >> > library like Mockito? >> >> > >> >> > In general I'm against mocking libraries. At best you end up with >> >> something >> >> > that may work, but you're not guaranteed that it actually works. They >> >> also >> >> > have a very big maintenance cost when any changes are made to the >> >> codebase. >> >> > >> >> > However, take a look at https://github.com/keycloak/ke >> ycloak/pull/5215 >> >> for >> >> > example. It is a contribution to add support for the hd param to the >> >> Google >> >> > login. Not sure how else we could test this without a mocking >> library. >> >> > _______________________________________________ >> >> > 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 >> >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> Bill Burke >> Red Hat >> > > From asaldanha1947 at gmail.com Thu May 31 14:48:24 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Thu, 31 May 2018 13:48:24 -0500 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: You need both sets of testing to maintain the long term quality of a security project like Keycloak. :-) I agree on the mocked IDP approach being more effective. On Thu, May 31, 2018 at 1:20 PM, Stian Thorgersen wrote: > With regards to Identity Brokering and Social Login one potentially better > way to do it would be to have a mocked IdP. At least then you are testing > the actual HTTP calls and it's much closer to a real scenario than doing > junit tests with mocks and only testing parts of the code base. > > On 31 May 2018 at 18:08, Anil Saldanha wrote: > >> I am sorry I have not looked at your integration tests. So I may be >> wrong here. >> >> One area that I feel that you need lots of integration tests is in the >> "Identity Brokering" feature. You have way too many permutations and >> combinations (with authentication flows) that without proper integration >> tests/mocks, you will not do proper justice to the value of KC/RH-SSO. >> >> On Thu, May 31, 2018 at 10:17 AM, Bill Burke wrote: >> >>> Never liked mocks either as they are just opinionated warped >>> perceptions of reality. But there are cases where I think we need >>> them off the top of my head: >>> >>> * Openshift integration >>> * Social logins. >>> >>> Openshift we just won't have the infrastructure for it. Social login >>> tests require accounts which we won't want to share the logins for in >>> a public CI. We need something in public CI so that we can catch at >>> least some potential problems and that we can easily try to reproduce >>> in local IDE environments. Mocks wouldn't be a replacement for real >>> integration testing, just a stop gap. >>> >>> >>> >>> On Thu, May 31, 2018 at 10:44 AM, Anil Saldanha >>> wrote: >>> > You really have to test your core logic (with no server set up) using >>> > integration tests with mocking libraries. One way to test out all the >>> > possible preconditions to your logic. >>> > >>> > You will be doing a service to your customers and users by shielding >>> them >>> > from those nasty exceptions (NPEs) that happen in an integration >>> platform >>> > such as KeyCloak/RH-SSO. :-) >>> > >>> > /me wearing a user/customer hat >>> > >>> > On Thu, May 31, 2018 at 1:38 AM, Marek Posolda >>> wrote: >>> > >>> >> Not sure. I am not strongly against it, but I afraid that if we >>> >> introduce some mocks support, people (especially from community) will >>> >> start to test with mocks everywhere and add them to all PRs (even to >>> >> those which could be easily tested properly). Not sure if it's better >>> >> alternative to skip automated test at all instead of test with mocks? >>> >> >>> >> But for this one, I guess we can likely extend our social test with an >>> >> account from hosted domain and hence test it properly? >>> >> >>> >> Marek >>> >> >>> >> >>> >> On 30/05/18 09:19, Stian Thorgersen wrote: >>> >> > At the moment our testing strategy is only with functional or >>> integration >>> >> > level tests. Both with the full server up and running and primarily >>> >> testing >>> >> > through public APIs. >>> >> > >>> >> > Now here comes the question should we also allow testing through a >>> >> mocking >>> >> > library like Mockito? >>> >> > >>> >> > In general I'm against mocking libraries. At best you end up with >>> >> something >>> >> > that may work, but you're not guaranteed that it actually works. >>> They >>> >> also >>> >> > have a very big maintenance cost when any changes are made to the >>> >> codebase. >>> >> > >>> >> > However, take a look at https://github.com/keycloak/ke >>> ycloak/pull/5215 >>> >> for >>> >> > example. It is a contribution to add support for the hd param to the >>> >> Google >>> >> > login. Not sure how else we could test this without a mocking >>> library. >>> >> > _______________________________________________ >>> >> > 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 >>> >> >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> -- >>> Bill Burke >>> Red Hat >>> >> >> > From sthorger at redhat.com Thu May 31 15:09:54 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 31 May 2018 21:09:54 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: On 31 May 2018 at 20:48, Anil Saldanha wrote: > You need both sets of testing to maintain the long term quality of a > security project like Keycloak. :-) > By using Arquillian we are actually able to test Keycloak very extensively without the need for Mocking through functional testing. I would suggest you review how extensive coverage we already have completely without any use of mocking and almost no basic unit testing at all. The problem I see is really only down to the difficulty of writing integration testing in some cases, especially when there are many configuration options. That's where it may be useful to mock the system being integrated with, but through mocking http calls, not Java method calls. > > I agree on the mocked IDP approach being more effective. > > On Thu, May 31, 2018 at 1:20 PM, Stian Thorgersen > wrote: > >> With regards to Identity Brokering and Social Login one potentially >> better way to do it would be to have a mocked IdP. At least then you are >> testing the actual HTTP calls and it's much closer to a real scenario than >> doing junit tests with mocks and only testing parts of the code base. >> >> On 31 May 2018 at 18:08, Anil Saldanha wrote: >> >>> I am sorry I have not looked at your integration tests. So I may be >>> wrong here. >>> >>> One area that I feel that you need lots of integration tests is in the >>> "Identity Brokering" feature. You have way too many permutations and >>> combinations (with authentication flows) that without proper integration >>> tests/mocks, you will not do proper justice to the value of KC/RH-SSO. >>> >>> On Thu, May 31, 2018 at 10:17 AM, Bill Burke wrote: >>> >>>> Never liked mocks either as they are just opinionated warped >>>> perceptions of reality. But there are cases where I think we need >>>> them off the top of my head: >>>> >>>> * Openshift integration >>>> * Social logins. >>>> >>>> Openshift we just won't have the infrastructure for it. Social login >>>> tests require accounts which we won't want to share the logins for in >>>> a public CI. We need something in public CI so that we can catch at >>>> least some potential problems and that we can easily try to reproduce >>>> in local IDE environments. Mocks wouldn't be a replacement for real >>>> integration testing, just a stop gap. >>>> >>>> >>>> >>>> On Thu, May 31, 2018 at 10:44 AM, Anil Saldanha < >>>> asaldanha1947 at gmail.com> wrote: >>>> > You really have to test your core logic (with no server set up) using >>>> > integration tests with mocking libraries. One way to test out all the >>>> > possible preconditions to your logic. >>>> > >>>> > You will be doing a service to your customers and users by shielding >>>> them >>>> > from those nasty exceptions (NPEs) that happen in an integration >>>> platform >>>> > such as KeyCloak/RH-SSO. :-) >>>> > >>>> > /me wearing a user/customer hat >>>> > >>>> > On Thu, May 31, 2018 at 1:38 AM, Marek Posolda >>>> wrote: >>>> > >>>> >> Not sure. I am not strongly against it, but I afraid that if we >>>> >> introduce some mocks support, people (especially from community) will >>>> >> start to test with mocks everywhere and add them to all PRs (even to >>>> >> those which could be easily tested properly). Not sure if it's better >>>> >> alternative to skip automated test at all instead of test with mocks? >>>> >> >>>> >> But for this one, I guess we can likely extend our social test with >>>> an >>>> >> account from hosted domain and hence test it properly? >>>> >> >>>> >> Marek >>>> >> >>>> >> >>>> >> On 30/05/18 09:19, Stian Thorgersen wrote: >>>> >> > At the moment our testing strategy is only with functional or >>>> integration >>>> >> > level tests. Both with the full server up and running and primarily >>>> >> testing >>>> >> > through public APIs. >>>> >> > >>>> >> > Now here comes the question should we also allow testing through a >>>> >> mocking >>>> >> > library like Mockito? >>>> >> > >>>> >> > In general I'm against mocking libraries. At best you end up with >>>> >> something >>>> >> > that may work, but you're not guaranteed that it actually works. >>>> They >>>> >> also >>>> >> > have a very big maintenance cost when any changes are made to the >>>> >> codebase. >>>> >> > >>>> >> > However, take a look at https://github.com/keycloak/ke >>>> ycloak/pull/5215 >>>> >> for >>>> >> > example. It is a contribution to add support for the hd param to >>>> the >>>> >> Google >>>> >> > login. Not sure how else we could test this without a mocking >>>> library. >>>> >> > _______________________________________________ >>>> >> > 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 >>>> >> >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> >>> >>> >> > From asaldanha1947 at gmail.com Thu May 31 15:46:32 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Thu, 31 May 2018 14:46:32 -0500 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: Agree. I had forgotten about Arquillian. > On May 31, 2018, at 2:09 PM, Stian Thorgersen wrote: > > > >> On 31 May 2018 at 20:48, Anil Saldanha wrote: >> You need both sets of testing to maintain the long term quality of a security project like Keycloak. :-) > > By using Arquillian we are actually able to test Keycloak very extensively without the need for Mocking through functional testing. I would suggest you review how extensive coverage we already have completely without any use of mocking and almost no basic unit testing at all. > > The problem I see is really only down to the difficulty of writing integration testing in some cases, especially when there are many configuration options. That's where it may be useful to mock the system being integrated with, but through mocking http calls, not Java method calls. > >> >> I agree on the mocked IDP approach being more effective. >> >>> On Thu, May 31, 2018 at 1:20 PM, Stian Thorgersen wrote: >>> With regards to Identity Brokering and Social Login one potentially better way to do it would be to have a mocked IdP. At least then you are testing the actual HTTP calls and it's much closer to a real scenario than doing junit tests with mocks and only testing parts of the code base. >>> >>>> On 31 May 2018 at 18:08, Anil Saldanha wrote: >>>> I am sorry I have not looked at your integration tests. So I may be wrong here. >>>> >>>> One area that I feel that you need lots of integration tests is in the "Identity Brokering" feature. You have way too many permutations and combinations (with authentication flows) that without proper integration tests/mocks, you will not do proper justice to the value of KC/RH-SSO. >>>> >>>>> On Thu, May 31, 2018 at 10:17 AM, Bill Burke wrote: >>>>> Never liked mocks either as they are just opinionated warped >>>>> perceptions of reality. But there are cases where I think we need >>>>> them off the top of my head: >>>>> >>>>> * Openshift integration >>>>> * Social logins. >>>>> >>>>> Openshift we just won't have the infrastructure for it. Social login >>>>> tests require accounts which we won't want to share the logins for in >>>>> a public CI. We need something in public CI so that we can catch at >>>>> least some potential problems and that we can easily try to reproduce >>>>> in local IDE environments. Mocks wouldn't be a replacement for real >>>>> integration testing, just a stop gap. >>>>> >>>>> >>>>> >>>>> On Thu, May 31, 2018 at 10:44 AM, Anil Saldanha wrote: >>>>> > You really have to test your core logic (with no server set up) using >>>>> > integration tests with mocking libraries. One way to test out all the >>>>> > possible preconditions to your logic. >>>>> > >>>>> > You will be doing a service to your customers and users by shielding them >>>>> > from those nasty exceptions (NPEs) that happen in an integration platform >>>>> > such as KeyCloak/RH-SSO. :-) >>>>> > >>>>> > /me wearing a user/customer hat >>>>> > >>>>> > On Thu, May 31, 2018 at 1:38 AM, Marek Posolda wrote: >>>>> > >>>>> >> Not sure. I am not strongly against it, but I afraid that if we >>>>> >> introduce some mocks support, people (especially from community) will >>>>> >> start to test with mocks everywhere and add them to all PRs (even to >>>>> >> those which could be easily tested properly). Not sure if it's better >>>>> >> alternative to skip automated test at all instead of test with mocks? >>>>> >> >>>>> >> But for this one, I guess we can likely extend our social test with an >>>>> >> account from hosted domain and hence test it properly? >>>>> >> >>>>> >> Marek >>>>> >> >>>>> >> >>>>> >> On 30/05/18 09:19, Stian Thorgersen wrote: >>>>> >> > At the moment our testing strategy is only with functional or integration >>>>> >> > level tests. Both with the full server up and running and primarily >>>>> >> testing >>>>> >> > through public APIs. >>>>> >> > >>>>> >> > Now here comes the question should we also allow testing through a >>>>> >> mocking >>>>> >> > library like Mockito? >>>>> >> > >>>>> >> > In general I'm against mocking libraries. At best you end up with >>>>> >> something >>>>> >> > that may work, but you're not guaranteed that it actually works. They >>>>> >> also >>>>> >> > have a very big maintenance cost when any changes are made to the >>>>> >> codebase. >>>>> >> > >>>>> >> > However, take a look at https://github.com/keycloak/keycloak/pull/5215 >>>>> >> for >>>>> >> > example. It is a contribution to add support for the hd param to the >>>>> >> Google >>>>> >> > login. Not sure how else we could test this without a mocking library. >>>>> >> > _______________________________________________ >>>>> >> > 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 >>>>> >> >>>>> > _______________________________________________ >>>>> > keycloak-dev mailing list >>>>> > keycloak-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> Red Hat >>>> >>> >> > From Matt.Domsch at quest.com Thu May 31 17:06:10 2018 From: Matt.Domsch at quest.com (Matt Domsch (mdomsch)) Date: Thu, 31 May 2018 21:06:10 +0000 Subject: [keycloak-dev] session caching questions Message-ID: In our deployments, we have need for the individual nodes in our standalone-ha cluster to be able to be stopped and restarted at any time, without loss of user sessions. We deploy into AWS Elastic Beanstalk, and join the "new" nodes into the existing JGroups cluster of "old" nodes, switch CNAMEs, then shut down the "old" nodes. The default suggested model of using for the session and clientSession caches fails in this scenario, as sessions stored only in memory on the "old" nodes are lost. As such, we've switched to for most of the caches. Does this make sense? Are most people using Keycloak running >10 nodes per cluster such that replicated cache doesn't make sense for performance reasons? If not, can the example standalone-ha.xml be adjusted to use replicated-cache? When items are placed into the caches, it seems that they are not put() with a lifetime or expiry time associated with them. This has led us to run into out-of-memory issues as the sizes of these caches grows without bound. We've added expiration times in the XML config to adjust for maximum lifetimes based on the longest session timeouts across all realms. This seems not ideal. It would be better to put() including the current active session timeouts for the realm for the object from which it originates. We cannot evict items in the sessions and clientSessions caches as they are not persisted to disk. The Offline variants are persisted to disk, so evicting these seem OK. Should this then be an invalidation-cache rather than a replicated-cache? XML snippet: Thanks, Matt -- Matt Domsch Executive Director & Senior Distinguished Engineer Quest | Engineering Matt.Domsch at quest.com Mobile 512.981.6486 From hasebullah.ansari at syntlogo.de Thu May 31 21:57:28 2018 From: hasebullah.ansari at syntlogo.de (Ansari, Hasebullah) Date: Fri, 1 Jun 2018 01:57:28 +0000 Subject: [keycloak-dev] Keycloak Feature development: Integrate ext. IdP to keycloak (like Google, facebook) Message-ID: <404712E7-238F-464F-9D51-2D9534087736@syntlogo.de> Hello all, My name is Haseb Ansari and by profession I?m an IT Specialist / Java Developer working for a German based company called Syntlogo GmbH. For the last one a half years I?ve been playing with Keycloak right from version 1.9.8.Final to 4.0.0.Beta1. For one of our (company?s) usecase, I?ve already integrated an external IdP(IdP really famous in Germany but not globally) through Keycloak SPI. With my experience so far, I?d now like to make a small contribution to Keycloak, an integration of an external identity provider i.e. ?Login with Amazon?. Before proceeding further, I?d like to have suggestion from you guys whether I?ll have to consider some points like ?do we need permission from Amazon?? or any other data protection stuff? Let me know about any detailed points I?ll have to consider while implementing Cheers, __________________________________________________________________________________________________________________________ Besuchen Sie LOGIN MASTER ? Die L?sung f?r die Benutzerverwaltung f?r das Web. __________________________________________________________________________________________________________________________ Hasebullah A Ansari Master of Engineering in IT, Heidelberg IT Specialist / Java Entwickler Syntlogo GmbH Mercedesstra?e 1 D-71063 Sindelfingen Email: hasebullah.ansari at syntlogo.de Mobile: +49 151 168 39585 Website: www.syntlogo.de Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empf?nger sein, so bitten wir Sie h?flichst, diesen Umstand unverz?glich dem Absender mitzuteilen und die Nachricht zu l?schen. Jede nicht genehmigte Weiterverbreitung oder Vervielf?ltigung ist nicht gestattet. Da wir Echtheit und Vollst?ndigkeit des Nachrichteninhalts nicht garantieren k?nnen, sind die vorstehenden Ausf?hrungen rechtlich nicht bindend. Eine Haftung hierf?r wird daher ausgeschlossen. This message is confidential. If you are not the intended recipient, we kindly ask you to inform the sender and delete the information. Any unauthorised dissemination or copying hereof is prohibited. As we cannot guarantee the genuineness or completeness of the information contained in this message, the statements set forth above are not legally binding. Accordingly, we cannot accept liability therefore. Stuttgart HRB 245317, Gesch?ftsf?hrer Dr. G. Baruzzi, USt-ID: DE 219566705 __________________________________________________________________________________________________________________________