From sai-soma-kala.kalidindi at microfocus.com Tue Jan 2 10:20:45 2018 From: sai-soma-kala.kalidindi at microfocus.com (Kalidindi, Sai Soma Kala) Date: Tue, 2 Jan 2018 15:20:45 +0000 Subject: [keycloak-dev] Migrating Keycloak to AWS environment Message-ID: Hi, Our backup product is using Keycloak for SSO. We are migrating all our users to a new instance of keycloak in AWS environment. One of the requirement is all the existing clients which is an agent on the user box running in background which does backup, should not see any re-authentication or login window from their end after migration . User initially login when they have first installed our product and they never see any login any more(our client is non-intrusive, most users don't ever remember the login ), we just refresh every 15 minutes get new set of tokens and so on... and it works for us. We have tested locally where we have migrated the present keycloak database to our new keycloak aws instance just by using pg_dump and restore command for database of keycloak and we made sure the realm, redirect urls , client secrets are exactly same. We are assuming if everything is exactly the same refresh tokens should still workand we can avoid the login screen. Is this right assumption? In our test what we have found is, we made a DNS swap where the client initially going the old env gets routed to our new keycloak aws instance(We did CNAME change on the old env to route traffic to new environment ). The reason for this Is to make sure our redirect url does not change and the client could still talk to same old urls it is aware of. Long story short, old key cloak env and new key cloak env has exactly same of everything...What we have seen is that the client which is initalliay pointing to the old env, after the migration and after doing the DNS switch the old tokens still work on new environment. Once we remove the switch and when the clients go back to old env the tokens still work. Is this a bug or is this expected? Thanks, Sai. From sthorger at redhat.com Tue Jan 2 13:43:38 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 2 Jan 2018 19:43:38 +0100 Subject: [keycloak-dev] Migrating Keycloak to AWS environment In-Reply-To: References: Message-ID: It was posted: http://lists.jboss.org/pipermail/keycloak-dev/2018-January/010272.html Maybe you sent it twice and one copy was rejected? On 2 January 2018 at 16:20, Kalidindi, Sai Soma Kala < sai-soma-kala.kalidindi at microfocus.com> wrote: > Hi, > > Our backup product is using Keycloak for SSO. We are migrating all our > users to a new instance of keycloak in AWS environment. One of the > requirement is all the existing clients which is an agent on the user box > running in background which does backup, should not see any > re-authentication or login window from their end after migration . User > initially login when they have first installed our product and they never > see any login any more(our client is non-intrusive, most users don't ever > remember the login ), we just refresh every 15 minutes get new set of > tokens and so on... and it works for us. We have tested locally where we > have migrated the present keycloak database to our new keycloak aws > instance just by using pg_dump and restore command for database of keycloak > and we made sure the realm, redirect urls , client secrets are exactly > same. We are assuming if everything is exactly the same refresh tokens > should still workand we can avoid the login screen. Is this right a! > ssumption? > > > In our test what we have found is, we made a DNS swap where the client > initially going the old env gets routed to our new keycloak aws > instance(We did CNAME change on the old env to route traffic to new > environment ). The reason for this Is to make sure our redirect url does > not change and the client could still talk to same old urls it is aware of. > Long story short, old key cloak env and new key cloak env has exactly same > of everything...What we have seen is that the client which is initalliay > pointing to the old env, after the migration and after doing the DNS switch > the old tokens still work on new environment. Once we remove the switch and > when the clients go back to old env the tokens still work. Is this a bug or > is this expected? > > Thanks, > Sai. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From srossillo at smartling.com Tue Jan 2 18:27:58 2018 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 2 Jan 2018 18:27:58 -0500 Subject: [keycloak-dev] Migrating Keycloak to AWS environment In-Reply-To: References: Message-ID: Hi Sai, I believe this is the expected behavior because in an HA setup, Keycloak doesn?t persist user sessions to the database, they are stored in the Infinispan distributed cache. Only offline sessions are persisted to the JPA data store. A core Keycloak developer can correct me if I?m wrong, but this is what I see looking at the latest Keycloak source code and it?s the case on the version we run. ~ Scott Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Jan 2, 2018, at 10:20 AM, Kalidindi, Sai Soma Kala wrote: > > Hi, > > Our backup product is using Keycloak for SSO. We are migrating all our users to a new instance of keycloak in AWS environment. One of the requirement is all the existing clients which is an agent on the user box running in background which does backup, should not see any re-authentication or login window from their end after migration . User initially login when they have first installed our product and they never see any login any more(our client is non-intrusive, most users don't ever remember the login ), we just refresh every 15 minutes get new set of tokens and so on... and it works for us. We have tested locally where we have migrated the present keycloak database to our new keycloak aws instance just by using pg_dump and restore command for database of keycloak and we made sure the realm, redirect urls , client secrets are exactly same. We are assuming if everything is exactly the same refresh tokens should still workand we can avoid the login screen. Is this right a! > ssumption? > > > In our test what we have found is, we made a DNS swap where the client initially going the old env gets routed to our new keycloak aws instance(We did CNAME change on the old env to route traffic to new environment ). The reason for this Is to make sure our redirect url does not change and the client could still talk to same old urls it is aware of. Long story short, old key cloak env and new key cloak env has exactly same of everything...What we have seen is that the client which is initalliay pointing to the old env, after the migration and after doing the DNS switch the old tokens still work on new environment. Once we remove the switch and when the clients go back to old env the tokens still work. Is this a bug or is this expected? > > Thanks, > Sai. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sai-soma-kala.kalidindi at microfocus.com Wed Jan 3 10:01:21 2018 From: sai-soma-kala.kalidindi at microfocus.com (Kalidindi, Sai Soma Kala) Date: Wed, 3 Jan 2018 15:01:21 +0000 Subject: [keycloak-dev] Migrating Keycloak to AWS environment In-Reply-To: References: Message-ID: Hi, Thank you for your response. Just want to give few more details, the keycloak version we are running is 1.9.8, our refresh tokens expire as soon as we get new set of access token and refresh token(we have a setting in keycloak turned on for this). Right now what we observe is the refresh token we got from old env is working on new env and vice versa. Thanks, Sai. From: Scott Rossillo [mailto:srossillo at smartling.com] Sent: Tuesday, January 02, 2018 6:28 PM To: Kalidindi, Sai Soma Kala Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Migrating Keycloak to AWS environment Hi Sai, I believe this is the expected behavior because in an HA setup, Keycloak doesn?t persist user sessions to the database, they are stored in the Infinispan distributed cache. Only offline sessions are persisted to the JPA data store. A core Keycloak developer can correct me if I?m wrong, but this is what I see looking at the latest Keycloak source code and it?s the case on the version we run. ~ Scott Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com On Jan 2, 2018, at 10:20 AM, Kalidindi, Sai Soma Kala > wrote: Hi, Our backup product is using Keycloak for SSO. We are migrating all our users to a new instance of keycloak in AWS environment. One of the requirement is all the existing clients which is an agent on the user box running in background which does backup, should not see any re-authentication or login window from their end after migration . User initially login when they have first installed our product and they never see any login any more(our client is non-intrusive, most users don't ever remember the login ), we just refresh every 15 minutes get new set of tokens and so on... and it works for us. We have tested locally where we have migrated the present keycloak database to our new keycloak aws instance just by using pg_dump and restore command for database of keycloak and we made sure the realm, redirect urls , client secrets are exactly same. We are assuming if everything is exactly the same refresh tokens should still workand we can avoid the login screen. Is this right a! ssumption? In our test what we have found is, we made a DNS swap where the client initially going the old env gets routed to our new keycloak aws instance(We did CNAME change on the old env to route traffic to new environment ). The reason for this Is to make sure our redirect url does not change and the client could still talk to same old urls it is aware of. Long story short, old key cloak env and new key cloak env has exactly same of everything...What we have seen is that the client which is initalliay pointing to the old env, after the migration and after doing the DNS switch the old tokens still work on new environment. Once we remove the switch and when the clients go back to old env the tokens still work. Is this a bug or is this expected? Thanks, Sai. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From carreraariel at gmail.com Wed Jan 3 14:02:29 2018 From: carreraariel at gmail.com (Ariel Carrera) Date: Wed, 3 Jan 2018 16:02:29 -0300 Subject: [keycloak-dev] Trojan in Keycloak Javascript Adapter? Message-ID: Hi, I have downloaded Keycloak Javascript Adapter from http://www.keycloak.org/downloads.html and when it is done a Windows Defender's popup alerts about a Trojan inside. Windows Defender info: adapter file: keycloak-js-adapter-dist-3.4.2.Final.zip trojan name: Trojan:JS/Jorv.A!cl file: keycloak-js-adapter-dist-3.4.2.Final/keycloak.min.js Am I the only one with this problem? Thanks, -- Ariel Carrera From sai-soma-kala.kalidindi at microfocus.com Wed Jan 3 14:37:23 2018 From: sai-soma-kala.kalidindi at microfocus.com (Kalidindi, Sai Soma Kala) Date: Wed, 3 Jan 2018 19:37:23 +0000 Subject: [keycloak-dev] Migrating Keycloak to AWS environment In-Reply-To: References: Message-ID: Hi Scott, We are actually using offline tokens for our clients, when we login in initially we give tag ?offline? which gets us refresh and access tokens . To elaborate more: 1) We use 1.9.8 version of keycloak. We have configured our keycloak realm to set revoke refresh tokens, which means refresh tokens are revoked once used for refreshing. 2) We have 2 keycloak clusters. 3) Our client initially pointed to KC1 which is old environment . 4) Now the KC1 database and certs are migrated to KC2 our new environment . 5) Client refresh token which it got from old env works on new env, which makes sense as I have migrated the keycloak database. 6) After of couple of days, client is moved to KC1 again. But the database is not moved. KC1 still has the old database as of step 3. 7) Our logs show that client is sending a refresh token to KC1, which was issued by KC2. This refresh is successfull What we are not understanding that how KC1 is able to refresh the token which it does not know ? Thanks, Sai. From: Scott Rossillo [mailto:srossillo at smartling.com] Sent: Tuesday, January 02, 2018 6:28 PM To: Kalidindi, Sai Soma Kala Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Migrating Keycloak to AWS environment Hi Sai, I believe this is the expected behavior because in an HA setup, Keycloak doesn?t persist user sessions to the database, they are stored in the Infinispan distributed cache. Only offline sessions are persisted to the JPA data store. A core Keycloak developer can correct me if I?m wrong, but this is what I see looking at the latest Keycloak source code and it?s the case on the version we run. ~ Scott Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com On Jan 2, 2018, at 10:20 AM, Kalidindi, Sai Soma Kala > wrote: Hi, Our backup product is using Keycloak for SSO. We are migrating all our users to a new instance of keycloak in AWS environment. One of the requirement is all the existing clients which is an agent on the user box running in background which does backup, should not see any re-authentication or login window from their end after migration . User initially login when they have first installed our product and they never see any login any more(our client is non-intrusive, most users don't ever remember the login ), we just refresh every 15 minutes get new set of tokens and so on... and it works for us. We have tested locally where we have migrated the present keycloak database to our new keycloak aws instance just by using pg_dump and restore command for database of keycloak and we made sure the realm, redirect urls , client secrets are exactly same. We are assuming if everything is exactly the same refresh tokens should still workand we can avoid the login screen. Is this right a! ssumption? In our test what we have found is, we made a DNS swap where the client initially going the old env gets routed to our new keycloak aws instance(We did CNAME change on the old env to route traffic to new environment ). The reason for this Is to make sure our redirect url does not change and the client could still talk to same old urls it is aware of. Long story short, old key cloak env and new key cloak env has exactly same of everything...What we have seen is that the client which is initalliay pointing to the old env, after the migration and after doing the DNS switch the old tokens still work on new environment. Once we remove the switch and when the clients go back to old env the tokens still work. Is this a bug or is this expected? Thanks, Sai. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From ramunask at gmail.com Wed Jan 3 15:44:47 2018 From: ramunask at gmail.com (Ramunas) Date: Wed, 3 Jan 2018 22:44:47 +0200 Subject: [keycloak-dev] Trojan in Keycloak Javascript Adapter? In-Reply-To: References: Message-ID: * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder with Windows Defender on Windows 10 - no issues found * checked for Windows updates. New update "Definition Update for Windows Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found and installed. * scanned again. No issues found. Ram?nas From carreraariel at gmail.com Wed Jan 3 16:07:44 2018 From: carreraariel at gmail.com (Ariel Carrera) Date: Wed, 03 Jan 2018 21:07:44 +0000 Subject: [keycloak-dev] Trojan in Keycloak Javascript Adapter? In-Reply-To: References: Message-ID: Thanks Ramunas, I will check My Windows defender?s definition version to compare with you. I have Windows 10 (64 bit) updated on December 2017. El El mi?, 3 ene. 2018 a las 17:45, Rumanas escribi?: > * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file > * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder with > Windows Defender on Windows 10 - no issues found > * checked for Windows updates. New update "Definition Update for Windows > Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found and > installed. > * scanned again. No issues found. > > Ram?nas > -- Ariel Carrera From lennart.jorelid at gmail.com Wed Jan 3 21:30:19 2018 From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=) Date: Thu, 4 Jan 2018 03:30:19 +0100 Subject: [keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter In-Reply-To: References: Message-ID: So ... I'm unclear about what would be the best way to 1. Use a Native/JavaFX application with its own Login screen and within its own process. Bring up a browser is not the user experience I would want to force on the user. 2. Use KeyCloak for authentication 3. After authentication, use KeyCloak to communicate with a Bearer-token-secured RESTful backend service over HTTP/HTTPS or WebSockets Is the better way to: 1. Implement a local ServerSocket within the Native/JavaFX application to accept the KeyCloak Callback. This can be done with something like Undertow and a tiny handler, so not too complex. However ... I would like a code example showing how to convert the inbound HttpServletRequest (to the Undertow server on localhost) from the KeyCloak to the Keycloak AccessToken. Presumably, one would need to decorate each JaxRS Client call to the restful webservice (using Bearer token access) with the KeyCloak Access token as well. Since the JaxRS 2.x Client is the de-facto standard from the current JavaEE distribution, it would be good to see an example of how to tailor a ... KeyCloak JaxRS Client request filter, maybe? I realize, from the example and the codebase, that 99% of the use cases here are Web/JavaScript clients and maybe Smartphone apps, but it would be really nice to have an example holding the scenario above, since it is basically the way to make native applications or JavaFX clients integrate properly (i.e. not sprouting a browser, which yields an inferior user experience) with services protected by KeyCloak. Fair? 2017-07-25 9:52 GMT+02:00 Thomas Darimont : > Hi Bill, > > that's nice to hear! > Is there already a JIRA issue for that? May I open a pull request and you > take it from there? > > I think the TLS feature was a bit over ambitious - so never mind. The idea > was to optionally allow using > https for connections to 127.0.0.1 + allowing users to pass-in a custom > cert / trust store. > > Note that using 127.0.0.1 instead of localhost might cause some > compatibility problems and should be mentioned in the migration guide. > E.g. users who already use the keycloak-installed adapter probably need to > adapt the allowed redirect > uri pattern in the client configuration in Keycloak (127.0.0.1 instead of > localhost). > > Cheers, > Thomas > > 2017-07-25 0:21 GMT+02:00 Bill Burke : > > > > > > > On 7/18/17 9:42 AM, Thomas Darimont wrote: > > > - Add support for TLS (with custom certificates) for https:// with > > localhost > > > > Hey, I'm incorporating your changes, but one question I have is why do > > you need this? > > > > Bill > > _______________________________________________ > > 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 > -- -- +==============================+ | B?sta h?lsningar, | [sw. "Best regards"] | | Lennart J?relid | EAI Architect & Integrator | | jGuru Europe AB | M?lnlycke - Kista | | Email: lj at jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+ From hendrik.ebbers at me.com Thu Jan 4 01:56:22 2018 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Thu, 04 Jan 2018 07:56:22 +0100 Subject: [keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter In-Reply-To: References: Message-ID: Hi Lennart, here is a gist that does a manual login by doing a rest call to keycloak. By doing so you do not need any callback https://gist.github.com/hendrikebbers/4c14db0967ce14ce623baa1f698b230c Next to this you need to handle some other thinks like the refresh of the token on your own. This must be done in an additional request for example. Cheers, Hendrik > Am 04.01.2018 um 03:30 schrieb Lennart J?relid : > > So ... I'm unclear about what would be the best way to > > 1. Use a Native/JavaFX application with its own Login screen and within > its own process. Bring up a browser is not the user experience I would want > to force on the user. > 2. Use KeyCloak for authentication > 3. After authentication, use KeyCloak to communicate with a > Bearer-token-secured RESTful backend service over HTTP/HTTPS or WebSockets > > Is the better way to: > > 1. Implement a local ServerSocket within the Native/JavaFX application > to accept the KeyCloak Callback. This can be done with something like > Undertow and a tiny handler, so not too complex. However ... I would like a > code example showing how to convert the inbound HttpServletRequest (to the > Undertow server on localhost) from the KeyCloak to the Keycloak > AccessToken. Presumably, one would need to decorate each JaxRS Client call > to the restful webservice (using Bearer token access) with the KeyCloak > Access token as well. Since the JaxRS 2.x Client is the de-facto standard > from the current JavaEE distribution, it would be good to see an example of > how to tailor a ... KeyCloak JaxRS Client request filter, maybe? > > I realize, from the example and the codebase, that 99% of the use cases > here are Web/JavaScript clients and maybe Smartphone apps, but it would be > really nice to have an example holding the scenario above, since it is > basically the way to make native applications or JavaFX clients integrate > properly (i.e. not sprouting a browser, which yields an inferior user > experience) with services protected by KeyCloak. Fair? > > > 2017-07-25 9:52 GMT+02:00 Thomas Darimont : > >> Hi Bill, >> >> that's nice to hear! >> Is there already a JIRA issue for that? May I open a pull request and you >> take it from there? >> >> I think the TLS feature was a bit over ambitious - so never mind. The idea >> was to optionally allow using >> https for connections to 127.0.0.1 + allowing users to pass-in a custom >> cert / trust store. >> >> Note that using 127.0.0.1 instead of localhost might cause some >> compatibility problems and should be mentioned in the migration guide. >> E.g. users who already use the keycloak-installed adapter probably need to >> adapt the allowed redirect >> uri pattern in the client configuration in Keycloak (127.0.0.1 instead of >> localhost). >> >> Cheers, >> Thomas >> >> 2017-07-25 0:21 GMT+02:00 Bill Burke : >> >>> >>> >>> On 7/18/17 9:42 AM, Thomas Darimont wrote: >>>> - Add support for TLS (with custom certificates) for https:// with >>> localhost >>> >>> Hey, I'm incorporating your changes, but one question I have is why do >>> you need this? >>> >>> Bill >>> _______________________________________________ >>> 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 >> > > > > -- > > -- > +==============================+ > | B?sta h?lsningar, > | [sw. "Best regards"] > | > | Lennart J?relid > | EAI Architect & Integrator > | > | jGuru Europe AB > | M?lnlycke - Kista > | > | Email: lj at jguru.se > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==============================+ > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Thu Jan 4 07:09:36 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 4 Jan 2018 13:09:36 +0100 Subject: [keycloak-dev] Keycloak 3.4.3.Final released Message-ID: http://blog.keycloak.org/2018/01/keycloak-343final-released.html From hartror at gmail.com Thu Jan 4 15:49:06 2018 From: hartror at gmail.com (Rory Hart) Date: Fri, 5 Jan 2018 06:49:06 +1000 Subject: [keycloak-dev] Keycloak Proxy & X-FORWARDED-PROTO Message-ID: I may have found a bug (or lack of feature?) in the proxy. I'm running the proxy behind a AWS load balancer which is handling HTTPS but the redirect urls that the proxy is generating are HTTP. While this isn't blocking usage as HTTP is redirected to HTTPS it is a small security hole that I would like to close. Is this something wrong with the proxy, a feature that needs to be worked on or out of scope of the proxy all together and I should be asking another team? (undertow?) Thanks Rory Hart From lennart.jorelid at gmail.com Thu Jan 4 17:25:28 2018 From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=) Date: Thu, 4 Jan 2018 23:25:28 +0100 Subject: [keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter In-Reply-To: References: Message-ID: Hello there, So ... looking at your codebase, I assume/guess your strategy is: 1. Find the URLs required from the 2.4.1. Endpoints section of the Keycloak documentation 2. Read the ... http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint URL as linked from the Keycloak documentation to find the required parameters into each call? Or something else? 3. Synthesize your rest calls to KeyCloak manually? This could work, but ... well ... I feel that these things should really be part of a deliverable within keycloak itself, such as an artifact called keycloak-java-client-3.4.2.Final.jar, with a simple-to-use specification. (In fact, i assumed I was just missing where these deliverables were implemented). Questions regarding a Pure JavaSE Keycloak client implementation Some questions to you folks on the lists, then: 1. A JavaSE client implementation should likely start by fetching the metadata information from /realms/{realm-name}/.well-known/openid-configuration as indicated within the Keycloak documentation. 1. The JaxRS method called to serve the information seems to be getWellKnown within the class RealmResource. True? 2. The object served seems to be OIDCConfigurationRepresentation, rendered as JSON within the response from the service call. True? 3. Hence ... the entity class is OIDCConfigurationRepresentation - and entities which will be needed both at the server side and at the client side (after unmarshaller) could/should be implemented within a separate maven project which can then be included both by the Keycloak Standalone client and the Server. This would serve to minimize the unnecessary dependency bloat on the client side. 2. The JaxRS Client proxy approach, as outlined by the RestEasy documentation is a good idea to simplify creating typed and consistent clients. Essentially, if the Server provides an annotated interface for the JaxRS services all that good type information can be used in a simple manner on the client side. 1. Currently, the restful services within the Keycloak codebase do not implement an interface, which implies that the 2 latter lines of code within the code snippet below does not work (the made-up "OpenIdConfiguration" type must be an interface, implemented by the restful service). This is - however - really easy to do; simply extract the typed interface of the RealmResource. I will supply a JIRA ticket for this. 2. Adding a JaxRS 2.x Client filter to auto-inject the Http headers ("Auth: Bearer .. ") into each request to the Keycloak-protected service is simple enough. Perhaps we could/should re-use parts of the code from the Keycloak codebase here. 3. Creating an async timer which polls the refresh-token (i.e. the /realms/{realm-name}/protocol/openid-connect/token endpoint) also seems decently straightforward after getting the token as such. 1. I suggest using the standard ExecutorService and an asynchronously called Task ResteasyClient client = new ResteasyClientBuilder().build(); ResteasyWebTarget target = client.target("http://theKeycloakServer/realms/realmname/.well-known/openid-configuration"); OpenIdConfiguration typedResponse = target.proxy(OpenIdConfiguration.class); typedResponse.getWellKnown("hello world"); Question to you in the list: Is this already available within the Keycloak codebase? If so -- where? 2018-01-04 7:56 GMT+01:00 Hendrik Ebbers : > Hi Lennart, > > here is a gist that does a manual login by doing a rest call to keycloak. > By doing so you do not need any callback > > https://gist.github.com/hendrikebbers/4c14db0967ce14ce623baa1f698b230c > > Next to this you need to handle some other thinks like the refresh of the > token on your own. This must be done in an additional request for example. > > Cheers, > > Hendrik > > > > Am 04.01.2018 um 03:30 schrieb Lennart J?relid >: > > So ... I'm unclear about what would be the best way to > > 1. Use a Native/JavaFX application with its own Login screen and within > its own process. Bring up a browser is not the user experience I would > want > to force on the user. > 2. Use KeyCloak for authentication > 3. After authentication, use KeyCloak to communicate with a > Bearer-token-secured RESTful backend service over HTTP/HTTPS or > WebSockets > > Is the better way to: > > 1. Implement a local ServerSocket within the Native/JavaFX application > > to accept the KeyCloak Callback. This can be done with something like > Undertow and a tiny handler, so not too complex. However ... I would > like a > code example showing how to convert the inbound HttpServletRequest (to > the > Undertow server on localhost) from the KeyCloak to the Keycloak > AccessToken. Presumably, one would need to decorate each JaxRS Client > call > to the restful webservice (using Bearer token access) with the KeyCloak > Access token as well. Since the JaxRS 2.x Client is the de-facto standard > from the current JavaEE distribution, it would be good to see an example > of > how to tailor a ... KeyCloak JaxRS Client request filter, maybe? > > I realize, from the example and the codebase, that 99% of the use cases > here are Web/JavaScript clients and maybe Smartphone apps, but it would be > really nice to have an example holding the scenario above, since it is > basically the way to make native applications or JavaFX clients integrate > properly (i.e. not sprouting a browser, which yields an inferior user > experience) with services protected by KeyCloak. Fair? > > > 2017-07-25 9:52 GMT+02:00 Thomas Darimont >: > > Hi Bill, > > that's nice to hear! > Is there already a JIRA issue for that? May I open a pull request and you > take it from there? > > I think the TLS feature was a bit over ambitious - so never mind. The idea > was to optionally allow using > https for connections to 127.0.0.1 + allowing users to pass-in a custom > cert / trust store. > > Note that using 127.0.0.1 instead of localhost might cause some > compatibility problems and should be mentioned in the migration guide. > E.g. users who already use the keycloak-installed adapter probably need to > adapt the allowed redirect > uri pattern in the client configuration in Keycloak (127.0.0.1 instead of > localhost). > > Cheers, > Thomas > > 2017-07-25 0:21 GMT+02:00 Bill Burke : > > > > On 7/18/17 9:42 AM, Thomas Darimont wrote: > > - Add support for TLS (with custom certificates) for https:// with > > localhost > > Hey, I'm incorporating your changes, but one question I have is why do > you need this? > > Bill > _______________________________________________ > 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 > > > > > -- > > -- > +==============================+ > | B?sta h?lsningar, > | [sw. "Best regards"] > | > | Lennart J?relid > | EAI Architect & Integrator > | > | jGuru Europe AB > | M?lnlycke - Kista > | > | Email: lj at jguru.se > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==============================+ > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- -- +==============================+ | B?sta h?lsningar, | [sw. "Best regards"] | | Lennart J?relid | EAI Architect & Integrator | | jGuru Europe AB | M?lnlycke - Kista | | Email: lj at jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+ From john.d.ament at gmail.com Thu Jan 4 17:26:32 2018 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 04 Jan 2018 22:26:32 +0000 Subject: [keycloak-dev] Keycloak Proxy & X-FORWARDED-PROTO In-Reply-To: References: Message-ID: Hi Rory, If you are using a proxy, you need to enable a setting in the undertow web section of standalone.xml to ensure that proxies are supported. This is what I use in 3.2.x: I believe you can add this attribute for both http and https. Once that's in, I believe all proxying will work. John On Thu, Jan 4, 2018 at 5:19 PM Rory Hart wrote: > I may have found a bug (or lack of feature?) in the proxy. I'm running the > proxy behind a AWS load balancer which is handling HTTPS but the redirect > urls that the proxy is generating are HTTP. > > While this isn't blocking usage as HTTP is redirected to HTTPS it is a > small security hole that I would like to close. > > Is this something wrong with the proxy, a feature that needs to be worked > on or out of scope of the proxy all together and I should be asking another > team? (undertow?) > > Thanks > > Rory Hart > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From hartror at gmail.com Fri Jan 5 16:03:39 2018 From: hartror at gmail.com (Rory Hart) Date: Sat, 6 Jan 2018 07:03:39 +1000 Subject: [keycloak-dev] Keycloak Proxy & X-FORWARDED-PROTO In-Reply-To: References: Message-ID: Hi John Thanks for your response. We are using that method in our standalone.xml for keycloak and have set it up as you describel. However the keycloak security proxy package doesn't appear to come with, or use this file? The documentation for it doesn't mentioned utilising it either? http://www.keycloak.org/docs/latest/server_installation/index.html#_proxy Thanks On 5 January 2018 at 08:26, John D. Ament wrote: > Hi Rory, > > If you are using a proxy, you need to enable a setting in the undertow web > section of standalone.xml to ensure that proxies are supported. This is > what I use in 3.2.x: > > socket-binding="http" redirect-socket="https"/> > > I believe you can add this attribute for both http and https. Once that's > in, I believe all proxying will work. > > John > > On Thu, Jan 4, 2018 at 5:19 PM Rory Hart wrote: > >> I may have found a bug (or lack of feature?) in the proxy. I'm running the >> proxy behind a AWS load balancer which is handling HTTPS but the redirect >> urls that the proxy is generating are HTTP. >> >> While this isn't blocking usage as HTTP is redirected to HTTPS it is a >> small security hole that I would like to close. >> >> Is this something wrong with the proxy, a feature that needs to be worked >> on or out of scope of the proxy all together and I should be asking >> another >> team? (undertow?) >> >> Thanks >> >> Rory Hart >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From thomas.darimont at googlemail.com Sun Jan 7 17:55:34 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Sun, 7 Jan 2018 23:55:34 +0100 Subject: [keycloak-dev] Keycloak Database Table Overview Message-ID: Hello, I just needed an overview of the current Keycloak Database schema, so I quickly generated a svg diagram (1MB) with IntelliJ / DataGrip. Perhaps someone might find this useful. See: https://gist.github.com/thomasdarimont/b1c19da5e8df747b8596e6ddcda7e36f Cheers, Thomas From carreraariel at gmail.com Mon Jan 8 14:26:55 2018 From: carreraariel at gmail.com (Ariel Carrera) Date: Mon, 8 Jan 2018 16:26:55 -0300 Subject: [keycloak-dev] Trojan in Keycloak Javascript Adapter? In-Reply-To: References: Message-ID: Checked with other computer (windows 10 + windows defender). keycloak-min.js is detected as virus from version 3.4.2 to 3.4.3 2018-01-03 17:44 GMT-03:00 Ramunas : > * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file > * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder > with Windows Defender on Windows 10 - no issues found > * checked for Windows updates. New update "Definition Update for Windows > Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found and > installed. > * scanned again. No issues found. > > Ram?nas > -- Ariel Carrera From carreraariel at gmail.com Mon Jan 8 14:56:18 2018 From: carreraariel at gmail.com (Ariel Carrera) Date: Mon, 8 Jan 2018 16:56:18 -0300 Subject: [keycloak-dev] Trojan in Keycloak Javascript Adapter? In-Reply-To: References: Message-ID: Hi Stian, I checked differences in keycloak.min.js comparing version 3.4.1 to 3.4.2. I can't see a problem at first sight... but It's still a problem to see your antivirus alerting for a threat when your browser access to a page that uses "keycloak.min.js" or when your somebody get's a keycloak's distribution to be installed. Maybe this issue must to be in Jira. Last changes in javascript file can be the problem. Maybe function "processInit()" needs some changes. Regards, 2018-01-08 16:26 GMT-03:00 Ariel Carrera : > Checked with other computer (windows 10 + windows defender). > > keycloak-min.js is detected as virus from version 3.4.2 to 3.4.3 > > > 2018-01-03 17:44 GMT-03:00 Ramunas : > >> * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file >> * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder >> with Windows Defender on Windows 10 - no issues found >> * checked for Windows updates. New update "Definition Update for Windows >> Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found and >> installed. >> * scanned again. No issues found. >> >> Ram?nas >> > > > > -- > Ariel Carrera > -- Ariel Carrera From carreraariel at gmail.com Mon Jan 8 15:18:29 2018 From: carreraariel at gmail.com (Ariel Carrera) Date: Mon, 8 Jan 2018 17:18:29 -0300 Subject: [keycloak-dev] Trojan in Keycloak Javascript Adapter? In-Reply-To: References: Message-ID: "when your somebody get's a keycloak's distribution to be installed" read like: "when someone gets Keycloak to be installed" xD 2018-01-08 16:56 GMT-03:00 Ariel Carrera : > Hi Stian, I checked differences in keycloak.min.js comparing version 3.4.1 > to 3.4.2. > I can't see a problem at first sight... but It's still a problem to see > your antivirus alerting for a threat when your browser access to a page > that uses "keycloak.min.js" or when your somebody get's a keycloak's > distribution to be installed. > > Maybe this issue must to be in Jira. > > Last changes in javascript file can be the problem. > > Maybe function "processInit()" needs some changes. > > Regards, > > 2018-01-08 16:26 GMT-03:00 Ariel Carrera : > >> Checked with other computer (windows 10 + windows defender). >> >> keycloak-min.js is detected as virus from version 3.4.2 to 3.4.3 >> >> >> 2018-01-03 17:44 GMT-03:00 Ramunas : >> >>> * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file >>> * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder >>> with Windows Defender on Windows 10 - no issues found >>> * checked for Windows updates. New update "Definition Update for Windows >>> Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found and >>> installed. >>> * scanned again. No issues found. >>> >>> Ram?nas >>> >> >> >> >> -- >> Ariel Carrera >> > > > > -- > Ariel Carrera > -- Ariel Carrera From Matt.Domsch at quest.com Tue Jan 9 00:32:10 2018 From: Matt.Domsch at quest.com (Matt Domsch (mdomsch)) Date: Tue, 9 Jan 2018 05:32:10 +0000 Subject: [keycloak-dev] Hot or Rolling upgrade In-Reply-To: References: Message-ID: On Tue, Dec 19, 2017 at 8:24 PM Brian Towles wrote: > Howdy all, > > I was wondering if there is any advice on how to do a rolling upgrade > of Keycloak, or any mechanism to maintain a running instance while upgrading? It depends on what schema changes have occurred between the versions. We review the liquibase change files as part of version upgrades to determine if the changes are breaking or not. For some, the schema changes have been very small and non-breaking, such that you have (old) instances running, you start new instances with a new version, the first of which does the schema migration, they join the infinispan cluster, and then stop the old instances. When the changes are not compatible, we do stop the old instances, then start the new instances, and take a few minutes of scheduled downtime. We can get it to 5-10 minutes of downtime with our current AWS ElasticBeanstock deployment methods, which for us is "good enough" at the moment. It'd be ideal if schema changes could be spaced out stepwise through versions so to be fewer breaking changes. Some (:cough: v3.2.0 changing a primary key definition on offline_client_session) we have to catch in a pre-production staging environment. We test the upgrade against a clone of the database, to find (and purge) data that would cause an upgrade failure, even allowing for downtime. Thanks, Matt -- Matt Domsch Executive Director & Senior Distinguished Engineer Quest | Engineering Matt.Domsch at quest.com From sthorger at redhat.com Tue Jan 9 07:42:53 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 9 Jan 2018 13:42:53 +0100 Subject: [keycloak-dev] Trojan in Keycloak Javascript Adapter? In-Reply-To: References: Message-ID: Please create an issue with the details. We'll need to figure out how to reproduce the issue though. Seemed like Ramunas had tried, but that Defender wasn't reporting anything for him. On 8 January 2018 at 21:18, Ariel Carrera wrote: > "when your somebody get's a keycloak's distribution to be installed" read > like: "when someone gets Keycloak to be installed" xD > > 2018-01-08 16:56 GMT-03:00 Ariel Carrera : > >> Hi Stian, I checked differences in keycloak.min.js comparing version >> 3.4.1 to 3.4.2. >> I can't see a problem at first sight... but It's still a problem to see >> your antivirus alerting for a threat when your browser access to a page >> that uses "keycloak.min.js" or when your somebody get's a keycloak's >> distribution to be installed. >> >> Maybe this issue must to be in Jira. >> >> Last changes in javascript file can be the problem. >> >> Maybe function "processInit()" needs some changes. >> >> Regards, >> >> 2018-01-08 16:26 GMT-03:00 Ariel Carrera : >> >>> Checked with other computer (windows 10 + windows defender). >>> >>> keycloak-min.js is detected as virus from version 3.4.2 to 3.4.3 >>> >>> >>> 2018-01-03 17:44 GMT-03:00 Ramunas : >>> >>>> * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file >>>> * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder >>>> with Windows Defender on Windows 10 - no issues found >>>> * checked for Windows updates. New update "Definition Update for >>>> Windows Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found >>>> and installed. >>>> * scanned again. No issues found. >>>> >>>> Ram?nas >>>> >>> >>> >>> >>> -- >>> Ariel Carrera >>> >> >> >> >> -- >> Ariel Carrera >> > > > > -- > Ariel Carrera > From m.godlewski at gmail.com Tue Jan 9 13:44:37 2018 From: m.godlewski at gmail.com (Mariusz Godlewski) Date: Tue, 09 Jan 2018 18:44:37 +0000 Subject: [keycloak-dev] User prinicipal name with multiple backend MSAD servers Message-ID: Hello, I'm considering deployement of Keycloak serving as an OAuth2 / Open ID provider for users managed in multiple MS Active Directory and Active Directory Lightweight services. For internal desktop users Kerberos should be used to prevent credentials re-entry following log-on to domain-joined computer. The tricky part is that usernames are considered to be unique only withing single AD domain, so username 'godlewsm' can exists both in Kerberos realm ACMEPL.LOCAL AND ACMECZ.LOCAL. For LDAP storage provider ( https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main/java/org/keycloak/storage/ldap/LDAPStorageProvider.java#L684 ) there is assumption that only username part of principal name would be used further, which prevents distinguishing accounts properly. Is there plan to change this behaviour or the only way would be implement a custom UserStorageProvider based on LDAPStorageProvider ? Best regards, Mariusz Godlewski From mposolda at redhat.com Wed Jan 10 03:26:48 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 10 Jan 2018 09:26:48 +0100 Subject: [keycloak-dev] User prinicipal name with multiple backend MSAD servers In-Reply-To: References: Message-ID: <6692d6a6-95bd-09f9-3c6e-90ae9c233292@redhat.com> Yes, it's possible that we need some more flexibility here. Feel free to create JIRA for better support this, but not sure when it's fixed. For the meantime, yes. You can create your own provider. Marek On 09/01/18 19:44, Mariusz Godlewski wrote: > Hello, > > I'm considering deployement of Keycloak serving as an OAuth2 / Open ID > provider for users managed in multiple MS Active Directory and Active > Directory Lightweight services. For internal desktop users Kerberos should > be used to prevent credentials re-entry following log-on to domain-joined > computer. > > The tricky part is that usernames are considered to be unique only withing > single AD domain, so username 'godlewsm' can exists both in Kerberos realm > ACMEPL.LOCAL AND ACMECZ.LOCAL. For LDAP storage provider ( > https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main/java/org/keycloak/storage/ldap/LDAPStorageProvider.java#L684 > ) > there is assumption that only username part of principal name would be used > further, which prevents distinguishing accounts properly. > > Is there plan to change this behaviour or the only way would be implement a > custom UserStorageProvider based on LDAPStorageProvider ? > > Best regards, > Mariusz Godlewski > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Wed Jan 10 06:45:00 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 10 Jan 2018 12:45:00 +0100 Subject: [keycloak-dev] PRs for 7.2 and Keycloak 4.x In-Reply-To: References: Message-ID: Keycloak, Node.js and documentation are all forked for 7.2. It's to late to update code now unless it's a blocker for the release. In that case let me know asap. For documentation we can update, but that means PR to master and 7.2.x branch in private repo. Any docs changes to 7.2 has to be approved by Matthew and Pavel prior to merging. Master (except quickstarts, see below) is open for 4.x development. One thing to note here is that we have now started the review process so all PRs have to be reviewed. The general rule one jira, one commit and one PR applies. Also, only complete work including test and docs should be accepted. For quickstarts master is still aiming 7.2. So send changes to master. If it's only for 4.x hold off for now! Same rule applies any changes to quickstarts now need approval of me and Pavel before merging. From Michael.Olney at iress.com.au Thu Jan 11 01:52:34 2018 From: Michael.Olney at iress.com.au (Michael Olney) Date: Thu, 11 Jan 2018 06:52:34 +0000 Subject: [keycloak-dev] Returning "attempted" status inside alternative sub-flow Message-ID: <12d1808f7c0e4d48a405d60db2ff8ff3@AU03-EXCH1.devel.iress.com.au> Hi, I have two sub-flows set up as follows: Subflow 1 - Alternative Execution 1 - Required Subflow 2 - Alternative Execution 2 - Required Execution 1 is runs a custom authenticator that does the following: 1. Issues a challenge 2. Returns ATTEMPTED status The resulting behaviour is that the whole flow fails. I was expecting a jump to Subflow 2, which is what happens if the authenticator returns ATTEMPTED without first issuing a challenge. Is this a bug? I thought that perhaps REQUIRED might apply to the whole flow rather than to a particular sub-flow, but I couldn't find an explicit clarification in the documentation. However, this scenario was mentioned in passing on this list before: http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007241.html The behaviour seems to originate in `org.keycloak.authentication.DefaultAuthenticationFlow.processResult`. Regards, Michael ********************************************************************************************** Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Limited. It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system. IRESS Limited does not warrant that the information is free of a virus or any other defect or error. ********************************************************************************************** From akeating at redhat.com Sun Jan 14 15:59:22 2018 From: akeating at redhat.com (Aiden Keating) Date: Sun, 14 Jan 2018 20:59:22 +0000 Subject: [keycloak-dev] Ignoring self signed cert errors while developing Message-ID: Hello, I am configuring an OpenShift v3 identity provider on Keycloak using an Ansible playbook. I have created the identity provider successfully. After filling in my OpenShift username and password I see an "Unexpected error when authenticating with identity provider" error from Keycloak. This is due to the self signed certificates of the OpenShift development cluster I am using (using oc cluster up). I am looking for an option to ignore these errors when in a development environment. I have read about the 'disable-trust-manager' option, from what I understand this can be set in development environments to avoid these errors. However, I am not fully clear on how to use it and how to configure it. Can this option be set using the REST API? Any help would be greatly appreciated. Thanks, Aiden Keating From bburke at redhat.com Mon Jan 15 18:21:18 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Jan 2018 18:21:18 -0500 Subject: [keycloak-dev] development image? Message-ID: Do we need a development image that builds from master. A Dockerfile script that: - derives from jdk8 - installs git client - install maven - git clone https://github.com/keycloak/keycloak - mvn clean install -Pdistro -DskipTests=true - unzip distro into /opt/keycloak We have a couple of teams asking for something like this within Red Hat as I'm guessing they don't want to deal with running maven themselves. Does that sort of flow make sense? -- Bill Burke Red Hat From bruno at abstractj.org Mon Jan 15 18:55:29 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Jan 2018 23:55:29 +0000 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: Hi Bill, I think it makes sense. But there are few things that people can't avoid, like install JDK for development. On AeroGear we had a -dev image like you described[1] [1] - https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/unifiedpush-wildfly-dev/Dockerfile On Mon, Jan 15, 2018 at 9:21 PM Bill Burke wrote: > Do we need a development image that builds from master. A Dockerfile > script that: > > - derives from jdk8 > - installs git client > - install maven > - git clone https://github.com/keycloak/keycloak > - mvn clean install -Pdistro -DskipTests=true > - unzip distro into /opt/keycloak > > We have a couple of teams asking for something like this within Red > Hat as I'm guessing they don't want to deal with running maven > themselves. Does that sort of flow make sense? > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From john.d.ament at gmail.com Tue Jan 16 15:51:57 2018 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 16 Jan 2018 20:51:57 +0000 Subject: [keycloak-dev] Possible bug in Keycloak 3.4.3? Message-ID: Hi, We're working on upgrading to Keycloak 3.4.3. We hit a weird issue where it looks like some backwards compatible code isn't working right in the client adapter. We found this block which seems suspect https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L306-L314 It looks like the values for redirectUri and redirectUriParam are actually backwards. We see the session_state query param in the value of redirectUri not redirectUriParam, and this causes the next check for the values being equal to fail. John From sai-soma-kala.kalidindi at microfocus.com Tue Jan 16 16:15:23 2018 From: sai-soma-kala.kalidindi at microfocus.com (Kalidindi, Sai Soma Kala) Date: Tue, 16 Jan 2018 21:15:23 +0000 Subject: [keycloak-dev] User entity entries in database are getting deleted after Keycloak Migration and restart Message-ID: Hi, We are using offline tokens for our clients, when we login in initially we give tag "offline" which gets us refresh and access tokens . 1) We use 1.9.8 version of keycloak. We have configured our keycloak realm to set revoke refresh tokens, which means refresh tokens are revoked once used for refreshing. 2) We have 2 keycloak clusters. 3) Our client initially pointed to KC1 which is old environment . 4) Now the KC1 database and certs are migrated to KC2 our new environment . 5) Client refresh token which it got from old env works on new env, for some clients where as it does not work for others. 6) What we have found is, we initially stop the keycloka service, migrate data and start it again. Once migration is done, I check all the tables have right data, which looks good but after restart we see that it is synching user_entity table with ldap and 3 of the users are being deleted from user_entity and user_attribute table and hence any tokens associated with these 3 users are being deleted from the Offline_client_session and Offline_user_session . At this point I am not clear why it is deleting even though I see ldap has it. Any suggestions or help is greatly appreciated. Thanks, Sai. From john.d.ament at gmail.com Tue Jan 16 16:42:35 2018 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 16 Jan 2018 21:42:35 +0000 Subject: [keycloak-dev] How to remove the new interstitial list of required actions page Message-ID: Hi, I noticed that in the new version of keycloak there's a landing page that a user receives when they're not logged in (I guess?) for a list of actions to perform. This page doesn't make much sense to me as a user, I just want to see my action since I only have one to do ever. I see this commit introduced it https://github.com/keycloak/keycloak/commit/4583a45e781093d4ba10f23f563231b141903f64 but I can't see the linked JIRA ticket (i guess it's secure?). I don't see a way to turn off this page. Is that on purpose? John From hmlnarik at redhat.com Wed Jan 17 04:24:21 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 17 Jan 2018 10:24:21 +0100 Subject: [keycloak-dev] How to remove the new interstitial list of required actions page In-Reply-To: References: Message-ID: Yes, this is intentional, and only happens when user is not already logged in (e.g. in other browser). Suppose there a link to with a single action - change password in the e-mail - and your mailbox has an automated spam/antivirus filter that visits and checks contents of any link in the e-mail. Since password-change link can only be used once, if the link was consumed by the spam filter, it would expire without actual changing the password and the user would not be able to change their own password. On Tue, Jan 16, 2018 at 10:42 PM, John D. Ament wrote: > Hi, > > I noticed that in the new version of keycloak there's a landing page that a > user receives when they're not logged in (I guess?) for a list of actions > to perform. This page doesn't make much sense to me as a user, I just want > to see my action since I only have one to do ever. > > I see this commit introduced it > https://github.com/keycloak/keycloak/commit/4583a45e781093d4ba10f23f563231 > b141903f64 > but > I can't see the linked JIRA ticket (i guess it's secure?). I don't see a > way to turn off this page. Is that on purpose? > > John > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- --Hynek From mstrukel at redhat.com Wed Jan 17 09:52:51 2018 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 17 Jan 2018 15:52:51 +0100 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: The problematic part is 'mvn clean install' which will pull down the internet of dependencies as if you're building for the first time - every time. On Jan 16, 2018 00:56, "Bruno Oliveira" wrote: Hi Bill, I think it makes sense. But there are few things that people can't avoid, like install JDK for development. On AeroGear we had a -dev image like you described[1] [1] - https://github.com/jboss-dockerfiles/aerogear/blob/ master/wildfly/unifiedpush-wildfly-dev/Dockerfile On Mon, Jan 15, 2018 at 9:21 PM Bill Burke wrote: > Do we need a development image that builds from master. A Dockerfile > script that: > > - derives from jdk8 > - installs git client > - install maven > - git clone https://github.com/keycloak/keycloak > - mvn clean install -Pdistro -DskipTests=true > - unzip distro into /opt/keycloak > > We have a couple of teams asking for something like this within Red > Hat as I'm guessing they don't want to deal with running maven > themselves. Does that sort of flow make sense? > > -- > 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 bruno at abstractj.org Wed Jan 17 09:57:57 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 17 Jan 2018 14:57:57 +0000 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: Maybe we can just provide an option for people to mount $HOME/.m2/repository ? On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj wrote: > The problematic part is 'mvn clean install' which will pull down the > internet of dependencies as if you're building for the first time - every > time. > > > > On Jan 16, 2018 00:56, "Bruno Oliveira" wrote: > > Hi Bill, I think it makes sense. But there are few things that people can't > avoid, like install JDK for development. > > On AeroGear we had a -dev image like you described[1] > > [1] - > > https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/unifiedpush-wildfly-dev/Dockerfile > > On Mon, Jan 15, 2018 at 9:21 PM Bill Burke wrote: > > > Do we need a development image that builds from master. A Dockerfile > > script that: > > > > - derives from jdk8 > > - installs git client > > - install maven > > - git clone https://github.com/keycloak/keycloak > > - mvn clean install -Pdistro -DskipTests=true > > - unzip distro into /opt/keycloak > > > > We have a couple of teams asking for something like this within Red > > Hat as I'm guessing they don't want to deal with running maven > > themselves. Does that sort of flow make sense? > > > > -- > > 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 mstrukel at redhat.com Wed Jan 17 11:00:22 2018 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 17 Jan 2018 17:00:22 +0100 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: Yeah, we could also checkout code in 'development' subdirectory and provide an option to mount local dir as 'development'. We could also provide option to skip checkout and to use existing code in the mounted ~/development/keycloak - that would use your local working version of keycloak - so you can have it open in your IDE and do a rebuild iteration quickly ... On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira wrote: > Maybe we can just provide an option for people to mount > $HOME/.m2/repository ? > > On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj > wrote: > >> The problematic part is 'mvn clean install' which will pull down the >> internet of dependencies as if you're building for the first time - every >> time. >> >> >> >> On Jan 16, 2018 00:56, "Bruno Oliveira" wrote: >> >> Hi Bill, I think it makes sense. But there are few things that people >> can't >> avoid, like install JDK for development. >> >> On AeroGear we had a -dev image like you described[1] >> >> [1] - >> https://github.com/jboss-dockerfiles/aerogear/blob/ >> master/wildfly/unifiedpush-wildfly-dev/Dockerfile >> >> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke wrote: >> >> > Do we need a development image that builds from master. A Dockerfile >> > script that: >> > >> > - derives from jdk8 >> > - installs git client >> > - install maven >> > - git clone https://github.com/keycloak/keycloak >> > - mvn clean install -Pdistro -DskipTests=true >> > - unzip distro into /opt/keycloak >> > >> > We have a couple of teams asking for something like this within Red >> > Hat as I'm guessing they don't want to deal with running maven >> > themselves. Does that sort of flow make sense? >> > >> > -- >> > 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 john.d.ament at gmail.com Wed Jan 17 11:13:16 2018 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 17 Jan 2018 16:13:16 +0000 Subject: [keycloak-dev] How to remove the new interstitial list of required actions page In-Reply-To: References: Message-ID: Hynek, On Wed, Jan 17, 2018 at 4:24 AM Hynek Mlnarik wrote: > Yes, this is intentional, and only happens when user is not already logged > in (e.g. in other browser). Suppose there a link to with a single action - > change password in the e-mail - and your mailbox has an automated > spam/antivirus filter that visits and checks contents of any link in the > e-mail. Since password-change link can only be used once, if the link was > consumed by the spam filter, it would expire without actual changing the > password and the user would not be able to change their own password. > Thanks for the background. The problem is that in our case, we don't have these issues. So it would be important to be able to disable this. Is this possible in the current setup? John > > On Tue, Jan 16, 2018 at 10:42 PM, John D. Ament > wrote: > >> Hi, >> >> I noticed that in the new version of keycloak there's a landing page that >> a >> user receives when they're not logged in (I guess?) for a list of actions >> to perform. This page doesn't make much sense to me as a user, I just >> want >> to see my action since I only have one to do ever. >> >> I see this commit introduced it >> >> https://github.com/keycloak/keycloak/commit/4583a45e781093d4ba10f23f563231b141903f64 >> but >> I can't see the linked JIRA ticket (i guess it's secure?). I don't see a >> way to turn off this page. Is that on purpose? >> >> John >> > _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > -- > > --Hynek > From bburke at redhat.com Wed Jan 17 12:29:09 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 17 Jan 2018 12:29:09 -0500 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: .This image is for people that don't want to know anything about maven our our build system and want to use a distro built from master. For developers like us, we just write a 2 line Dockerfile and mount local disk to the image. This way you never have to rebuild the image as you're developing as everything is in local disk. This is how I approached things lately when I was fidling around the master + kubernetes. On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj wrote: > Yeah, we could also checkout code in 'development' subdirectory and provide > an option to mount local dir as 'development'. We could also provide option > to skip checkout and to use existing code in the mounted > ~/development/keycloak - that would use your local working version of > keycloak - so you can have it open in your IDE and do a rebuild iteration > quickly ... > > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira wrote: >> >> Maybe we can just provide an option for people to mount >> $HOME/.m2/repository ? >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj >> wrote: >>> >>> The problematic part is 'mvn clean install' which will pull down the >>> internet of dependencies as if you're building for the first time - every >>> time. >>> >>> >>> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" wrote: >>> >>> Hi Bill, I think it makes sense. But there are few things that people >>> can't >>> avoid, like install JDK for development. >>> >>> On AeroGear we had a -dev image like you described[1] >>> >>> [1] - >>> >>> https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/unifiedpush-wildfly-dev/Dockerfile >>> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke wrote: >>> >>> > Do we need a development image that builds from master. A Dockerfile >>> > script that: >>> > >>> > - derives from jdk8 >>> > - installs git client >>> > - install maven >>> > - git clone https://github.com/keycloak/keycloak >>> > - mvn clean install -Pdistro -DskipTests=true >>> > - unzip distro into /opt/keycloak >>> > >>> > We have a couple of teams asking for something like this within Red >>> > Hat as I'm guessing they don't want to deal with running maven >>> > themselves. Does that sort of flow make sense? >>> > >>> > -- >>> > 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 >>> >>> > -- Bill Burke Red Hat From bruno at abstractj.org Wed Jan 17 14:01:15 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 17 Jan 2018 19:01:15 +0000 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: I believe something like this is what you meant https://raw.githubusercontent.com/abstractj/dockerfiles/keycloak/keycloak/keycloak-latest/Dockerfile. Some considerations about this: 1. We can automate the build on Docker Hub, but it's gonna take like forever at each build. Because it's going to download the internet like Marko mentioned 2. Maybe we should consider a smarter way of caching .m2 repositories. I just can think about a manual process for this. 3. In order to keep the image fresh, might be necessary to trigger the image build from Travis remotely. I'm not sure if we want this. Another alternative which I think may solve these 3 items above, is to provide weekly builds of this docker image. On Wed, Jan 17, 2018 at 3:29 PM Bill Burke wrote: > .This image is for people that don't want to know anything about maven > our our build system and want to use a distro built from master. > > For developers like us, we just write a 2 line Dockerfile and mount > local disk to the image. This way you never have to rebuild the image > as you're developing as everything is in local disk. This is how I > approached things lately when I was fidling around the master + > kubernetes. > > > > On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj > wrote: > > Yeah, we could also checkout code in 'development' subdirectory and > provide > > an option to mount local dir as 'development'. We could also provide > option > > to skip checkout and to use existing code in the mounted > > ~/development/keycloak - that would use your local working version of > > keycloak - so you can have it open in your IDE and do a rebuild iteration > > quickly ... > > > > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira > wrote: > >> > >> Maybe we can just provide an option for people to mount > >> $HOME/.m2/repository ? > >> > >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj > >> wrote: > >>> > >>> The problematic part is 'mvn clean install' which will pull down the > >>> internet of dependencies as if you're building for the first time - > every > >>> time. > >>> > >>> > >>> > >>> On Jan 16, 2018 00:56, "Bruno Oliveira" wrote: > >>> > >>> Hi Bill, I think it makes sense. But there are few things that people > >>> can't > >>> avoid, like install JDK for development. > >>> > >>> On AeroGear we had a -dev image like you described[1] > >>> > >>> [1] - > >>> > >>> > https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/unifiedpush-wildfly-dev/Dockerfile > >>> > >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke wrote: > >>> > >>> > Do we need a development image that builds from master. A Dockerfile > >>> > script that: > >>> > > >>> > - derives from jdk8 > >>> > - installs git client > >>> > - install maven > >>> > - git clone https://github.com/keycloak/keycloak > >>> > - mvn clean install -Pdistro -DskipTests=true > >>> > - unzip distro into /opt/keycloak > >>> > > >>> > We have a couple of teams asking for something like this within Red > >>> > Hat as I'm guessing they don't want to deal with running maven > >>> > themselves. Does that sort of flow make sense? > >>> > > >>> > -- > >>> > 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 > >>> > >>> > > > > > > -- > Bill Burke > Red Hat > From bruno at abstractj.org Wed Jan 17 14:18:24 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 17 Jan 2018 19:18:24 +0000 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: Oh, I forgot about a better option. Upload snapshots from Travis to Maven repository and build the docker image based on the latest build. In this way we don't need to build everything from scratch, because Travis already does it. On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira wrote: > I believe something like this is what you meant > https://raw.githubusercontent.com/abstractj/dockerfiles/keycloak/keycloak/keycloak-latest/Dockerfile. > Some considerations about this: > > 1. We can automate the build on Docker Hub, but it's gonna take like > forever at each build. Because it's going to download the internet like > Marko mentioned > 2. Maybe we should consider a smarter way of caching .m2 repositories. I > just can think about a manual process for this. > 3. In order to keep the image fresh, might be necessary to trigger the > image build from Travis remotely. I'm not sure if we want this. > > Another alternative which I think may solve these 3 items above, is to > provide weekly builds of this docker image. > > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke wrote: > >> .This image is for people that don't want to know anything about maven >> our our build system and want to use a distro built from master. >> >> For developers like us, we just write a 2 line Dockerfile and mount >> local disk to the image. This way you never have to rebuild the image >> as you're developing as everything is in local disk. This is how I >> approached things lately when I was fidling around the master + >> kubernetes. >> >> >> >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj >> wrote: >> > Yeah, we could also checkout code in 'development' subdirectory and >> provide >> > an option to mount local dir as 'development'. We could also provide >> option >> > to skip checkout and to use existing code in the mounted >> > ~/development/keycloak - that would use your local working version of >> > keycloak - so you can have it open in your IDE and do a rebuild >> iteration >> > quickly ... >> > >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira >> wrote: >> >> >> >> Maybe we can just provide an option for people to mount >> >> $HOME/.m2/repository ? >> >> >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj >> >> wrote: >> >>> >> >>> The problematic part is 'mvn clean install' which will pull down the >> >>> internet of dependencies as if you're building for the first time - >> every >> >>> time. >> >>> >> >>> >> >>> >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" wrote: >> >>> >> >>> Hi Bill, I think it makes sense. But there are few things that people >> >>> can't >> >>> avoid, like install JDK for development. >> >>> >> >>> On AeroGear we had a -dev image like you described[1] >> >>> >> >>> [1] - >> >>> >> >>> >> https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/unifiedpush-wildfly-dev/Dockerfile >> >>> >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke wrote: >> >>> >> >>> > Do we need a development image that builds from master. A >> Dockerfile >> >>> > script that: >> >>> > >> >>> > - derives from jdk8 >> >>> > - installs git client >> >>> > - install maven >> >>> > - git clone https://github.com/keycloak/keycloak >> >>> > - mvn clean install -Pdistro -DskipTests=true >> >>> > - unzip distro into /opt/keycloak >> >>> > >> >>> > We have a couple of teams asking for something like this within Red >> >>> > Hat as I'm guessing they don't want to deal with running maven >> >>> > themselves. Does that sort of flow make sense? >> >>> > >> >>> > -- >> >>> > 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 >> >>> >> >>> >> > >> >> >> >> -- >> Bill Burke >> Red Hat >> > From bburke at redhat.com Wed Jan 17 14:37:12 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 17 Jan 2018 14:37:12 -0500 Subject: [keycloak-dev] per-client authentication flows Message-ID: TLDR; Per client authentication flows? Client can be configured to override realm authentication flows. Background: I'm specing out how we will replace OSIN (openshift oauth server) with Keycloak. One issue is that each oauth client in OSIN can specify the authentication flow they want. Non-browser clients like the 'oc' cmd line tool want a 401, challenge-based protocol...Web console, obviously wants HTML. They All OSIN clients use the OAuth auth-code-grant irregardless if they are non-brwoser or browser clients. Keycloak assumes this oauth grant type is browser based and expects non-browser clients to use Resource Credentials grant or client credential grant. OSIN does not support this and we (keycloak) have to be backward compatible. Solution: I think it would be pretty simple to add the ability to override authentication flows per client. I don't think this would be a one-off for OSIN as we could use it to implement other non-browser input protocols. For example, I wanted to be able to have a text-based auth flow for command line logins. I think this could be a way to implement that. -- Bill Burke Red Hat From sai-soma-kala.kalidindi at microfocus.com Wed Jan 17 19:00:14 2018 From: sai-soma-kala.kalidindi at microfocus.com (Kalidindi, Sai Soma Kala) Date: Thu, 18 Jan 2018 00:00:14 +0000 Subject: [keycloak-dev] Keycloak support Message-ID: Hi, We are having an issue where we see some of the entries getting deleted from user_entity table when we start our keycloak. After days of debugging we don't know why this is happening. We are planning to buy commercial support for this issue. Looks like only the Red hat versions of keycloak has commercial support. We are using open source verison 1.9.8. Can someone point me in right direction on where we can get commercial support for open source versions. Thanks, Sai. From sthorger at redhat.com Thu Jan 18 02:08:37 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Jan 2018 08:08:37 +0100 Subject: [keycloak-dev] Keycloak support In-Reply-To: References: Message-ID: http://www.keycloak.org/support.html ;) On 18 January 2018 at 01:00, Kalidindi, Sai Soma Kala < sai-soma-kala.kalidindi at microfocus.com> wrote: > Hi, > > We are having an issue where we see some of the entries getting deleted > from user_entity table when we start our keycloak. After days of debugging > we don't know why this is happening. We are planning to buy commercial > support for this issue. Looks like only the Red hat versions of keycloak > has commercial support. We are using open source verison 1.9.8. Can someone > point me in right direction on where we can get commercial support for open > source versions. > > Thanks, > Sai. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From hmlnarik at redhat.com Thu Jan 18 05:04:34 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Thu, 18 Jan 2018 11:04:34 +0100 Subject: [keycloak-dev] How to remove the new interstitial list of required actions page In-Reply-To: References: Message-ID: No. Feel free to raise an RFE to make this configurable. On Wed, Jan 17, 2018 at 5:13 PM, John D. Ament wrote: > Hynek, > > On Wed, Jan 17, 2018 at 4:24 AM Hynek Mlnarik wrote: > >> Yes, this is intentional, and only happens when user is not already >> logged in (e.g. in other browser). Suppose there a link to with a single >> action - change password in the e-mail - and your mailbox has an automated >> spam/antivirus filter that visits and checks contents of any link in the >> e-mail. Since password-change link can only be used once, if the link was >> consumed by the spam filter, it would expire without actual changing the >> password and the user would not be able to change their own password. >> > > Thanks for the background. The problem is that in our case, we don't have > these issues. So it would be important to be able to disable this. Is > this possible in the current setup? > > John > > >> >> On Tue, Jan 16, 2018 at 10:42 PM, John D. Ament >> wrote: >> >>> Hi, >>> >>> I noticed that in the new version of keycloak there's a landing page >>> that a >>> user receives when they're not logged in (I guess?) for a list of actions >>> to perform. This page doesn't make much sense to me as a user, I just >>> want >>> to see my action since I only have one to do ever. >>> >>> I see this commit introduced it >>> https://github.com/keycloak/keycloak/commit/ >>> 4583a45e781093d4ba10f23f563231b141903f64 >>> but >>> I can't see the linked JIRA ticket (i guess it's secure?). I don't see a >>> way to turn off this page. Is that on purpose? >>> >>> John >>> >> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> >> -- >> >> --Hynek >> > -- --Hynek From sthorger at redhat.com Thu Jan 18 10:02:46 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Jan 2018 16:02:46 +0100 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: Is the use-case folks that want to try out a feature available in master, but not in a Keycloak release yet? What about having daily builds instead? We could have both ZIPs and Docker images built daily. On 17 January 2018 at 20:18, Bruno Oliveira wrote: > Oh, I forgot about a better option. Upload snapshots from Travis to Maven > repository and build the docker image based on the latest build. In this > way we don't need to build everything from scratch, because Travis already > does it. > > On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira > wrote: > > > I believe something like this is what you meant > > https://raw.githubusercontent.com/abstractj/dockerfiles/ > keycloak/keycloak/keycloak-latest/Dockerfile. > > Some considerations about this: > > > > 1. We can automate the build on Docker Hub, but it's gonna take like > > forever at each build. Because it's going to download the internet like > > Marko mentioned > > 2. Maybe we should consider a smarter way of caching .m2 repositories. I > > just can think about a manual process for this. > > 3. In order to keep the image fresh, might be necessary to trigger the > > image build from Travis remotely. I'm not sure if we want this. > > > > Another alternative which I think may solve these 3 items above, is to > > provide weekly builds of this docker image. > > > > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke wrote: > > > >> .This image is for people that don't want to know anything about maven > >> our our build system and want to use a distro built from master. > >> > >> For developers like us, we just write a 2 line Dockerfile and mount > >> local disk to the image. This way you never have to rebuild the image > >> as you're developing as everything is in local disk. This is how I > >> approached things lately when I was fidling around the master + > >> kubernetes. > >> > >> > >> > >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj > >> wrote: > >> > Yeah, we could also checkout code in 'development' subdirectory and > >> provide > >> > an option to mount local dir as 'development'. We could also provide > >> option > >> > to skip checkout and to use existing code in the mounted > >> > ~/development/keycloak - that would use your local working version of > >> > keycloak - so you can have it open in your IDE and do a rebuild > >> iteration > >> > quickly ... > >> > > >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira > >> wrote: > >> >> > >> >> Maybe we can just provide an option for people to mount > >> >> $HOME/.m2/repository ? > >> >> > >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj > > >> >> wrote: > >> >>> > >> >>> The problematic part is 'mvn clean install' which will pull down the > >> >>> internet of dependencies as if you're building for the first time - > >> every > >> >>> time. > >> >>> > >> >>> > >> >>> > >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" > wrote: > >> >>> > >> >>> Hi Bill, I think it makes sense. But there are few things that > people > >> >>> can't > >> >>> avoid, like install JDK for development. > >> >>> > >> >>> On AeroGear we had a -dev image like you described[1] > >> >>> > >> >>> [1] - > >> >>> > >> >>> > >> https://github.com/jboss-dockerfiles/aerogear/blob/ > master/wildfly/unifiedpush-wildfly-dev/Dockerfile > >> >>> > >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke > wrote: > >> >>> > >> >>> > Do we need a development image that builds from master. A > >> Dockerfile > >> >>> > script that: > >> >>> > > >> >>> > - derives from jdk8 > >> >>> > - installs git client > >> >>> > - install maven > >> >>> > - git clone https://github.com/keycloak/keycloak > >> >>> > - mvn clean install -Pdistro -DskipTests=true > >> >>> > - unzip distro into /opt/keycloak > >> >>> > > >> >>> > We have a couple of teams asking for something like this within > Red > >> >>> > Hat as I'm guessing they don't want to deal with running maven > >> >>> > themselves. Does that sort of flow make sense? > >> >>> > > >> >>> > -- > >> >>> > 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 > >> >>> > >> >>> > >> > > >> > >> > >> > >> -- > >> Bill Burke > >> 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 Thu Jan 18 10:05:18 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Jan 2018 16:05:18 +0100 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: .... adding to my previous reply Once we have Jenkins instance setup it should be fairly trivial to have a nightly build of the ZIPs published somewhere. When we have that we can easily setup a build in Docker hub that would automatically build the image and make it available. So you'd run with something like: docker run jboss/keycloak:nightly 'nightly' would always be the latest build. We could also add 'nighly-', but not sure if that's necessary. On 18 January 2018 at 16:02, Stian Thorgersen wrote: > Is the use-case folks that want to try out a feature available in master, > but not in a Keycloak release yet? > > What about having daily builds instead? We could have both ZIPs and Docker > images built daily. > > On 17 January 2018 at 20:18, Bruno Oliveira wrote: > >> Oh, I forgot about a better option. Upload snapshots from Travis to Maven >> repository and build the docker image based on the latest build. In this >> way we don't need to build everything from scratch, because Travis already >> does it. >> >> On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira >> wrote: >> >> > I believe something like this is what you meant >> > https://raw.githubusercontent.com/abstractj/dockerfiles/keyc >> loak/keycloak/keycloak-latest/Dockerfile. >> > Some considerations about this: >> > >> > 1. We can automate the build on Docker Hub, but it's gonna take like >> > forever at each build. Because it's going to download the internet like >> > Marko mentioned >> > 2. Maybe we should consider a smarter way of caching .m2 repositories. I >> > just can think about a manual process for this. >> > 3. In order to keep the image fresh, might be necessary to trigger the >> > image build from Travis remotely. I'm not sure if we want this. >> > >> > Another alternative which I think may solve these 3 items above, is to >> > provide weekly builds of this docker image. >> > >> > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke wrote: >> > >> >> .This image is for people that don't want to know anything about maven >> >> our our build system and want to use a distro built from master. >> >> >> >> For developers like us, we just write a 2 line Dockerfile and mount >> >> local disk to the image. This way you never have to rebuild the image >> >> as you're developing as everything is in local disk. This is how I >> >> approached things lately when I was fidling around the master + >> >> kubernetes. >> >> >> >> >> >> >> >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj >> >> wrote: >> >> > Yeah, we could also checkout code in 'development' subdirectory and >> >> provide >> >> > an option to mount local dir as 'development'. We could also provide >> >> option >> >> > to skip checkout and to use existing code in the mounted >> >> > ~/development/keycloak - that would use your local working version of >> >> > keycloak - so you can have it open in your IDE and do a rebuild >> >> iteration >> >> > quickly ... >> >> > >> >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira > > >> >> wrote: >> >> >> >> >> >> Maybe we can just provide an option for people to mount >> >> >> $HOME/.m2/repository ? >> >> >> >> >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj < >> mstrukel at redhat.com> >> >> >> wrote: >> >> >>> >> >> >>> The problematic part is 'mvn clean install' which will pull down >> the >> >> >>> internet of dependencies as if you're building for the first time - >> >> every >> >> >>> time. >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" >> wrote: >> >> >>> >> >> >>> Hi Bill, I think it makes sense. But there are few things that >> people >> >> >>> can't >> >> >>> avoid, like install JDK for development. >> >> >>> >> >> >>> On AeroGear we had a -dev image like you described[1] >> >> >>> >> >> >>> [1] - >> >> >>> >> >> >>> >> >> https://github.com/jboss-dockerfiles/aerogear/blob/master/ >> wildfly/unifiedpush-wildfly-dev/Dockerfile >> >> >>> >> >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke >> wrote: >> >> >>> >> >> >>> > Do we need a development image that builds from master. A >> >> Dockerfile >> >> >>> > script that: >> >> >>> > >> >> >>> > - derives from jdk8 >> >> >>> > - installs git client >> >> >>> > - install maven >> >> >>> > - git clone https://github.com/keycloak/keycloak >> >> >>> > - mvn clean install -Pdistro -DskipTests=true >> >> >>> > - unzip distro into /opt/keycloak >> >> >>> > >> >> >>> > We have a couple of teams asking for something like this within >> Red >> >> >>> > Hat as I'm guessing they don't want to deal with running maven >> >> >>> > themselves. Does that sort of flow make sense? >> >> >>> > >> >> >>> > -- >> >> >>> > 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 >> >> >>> >> >> >>> >> >> > >> >> >> >> >> >> >> >> -- >> >> Bill Burke >> >> Red Hat >> >> >> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From john.d.ament at gmail.com Thu Jan 18 10:30:27 2018 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 18 Jan 2018 15:30:27 +0000 Subject: [keycloak-dev] Possible bug in Keycloak 3.4.3? In-Reply-To: References: Message-ID: Ping. Should I create a defect? I actually suspect it's related to a comment I added to KEYCLOAK-6286, but not sure. For some reason, we're resulting in a redirect URI that includes session_state but it shouldn't. This results in duplicate session_state query params being added. John On Tue, Jan 16, 2018 at 3:51 PM John D. Ament wrote: > Hi, > > We're working on upgrading to Keycloak 3.4.3. We hit a weird issue where > it looks like some backwards compatible code isn't working right in the > client adapter. We found this block which seems suspect > > > https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L306-L314 > > It looks like the values for redirectUri and redirectUriParam are actually > backwards. We see the session_state query param in the value of > redirectUri not redirectUriParam, and this causes the next check for the > values being equal to fail. > > John > From sthorger at redhat.com Thu Jan 18 10:44:51 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Jan 2018 16:44:51 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: Message-ID: Definitively makes sense for the 'Direct Grant Flow'. Did you also think about it for the 'Browser Flow'? That doesn't make sense to me as I don't think the client should have any control on the SSO flow. On 17 January 2018 at 20:37, Bill Burke wrote: > TLDR; Per client authentication flows? Client can be configured to > override realm authentication flows. > > Background: > > I'm specing out how we will replace OSIN (openshift oauth server) with > Keycloak. One issue is that each oauth client in OSIN can specify the > authentication flow they want. Non-browser clients like the 'oc' cmd > line tool want a 401, challenge-based protocol...Web console, > obviously wants HTML. They All OSIN clients use the OAuth > auth-code-grant irregardless if they are non-brwoser or browser > clients. Keycloak assumes this oauth grant type is browser based and > expects non-browser clients to use Resource Credentials grant or > client credential grant. OSIN does not support this and we (keycloak) > have to be backward compatible. > > Solution: > > I think it would be pretty simple to add the ability to override > authentication flows per client. I don't think this would be a > one-off for OSIN as we could use it to implement other non-browser > input protocols. For example, I wanted to be able to have a > text-based auth flow for command line logins. I think this could be a > way to implement that. > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Thu Jan 18 11:33:39 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jan 2018 11:33:39 -0500 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: Message-ID: Makes sense for both direct grant and browser flow. Please reread the OP. I'll try to summarize differently. In Keycoak, using OAuth authorization code grant protocol means that the 'Browser Flow" will be invoked. *All* OSIN clients use the code grant and clients are configured individually whether a challenge based protocol should be used or not. It is a Keycloak requirement to remain backward compatible so Keycloak can just be turned on with no changes. What it boils down to is cmd-line clients vs. browser clients. I would hate to add an architectural feature just to implement something OSIN specific, but I think this would be useful beyond OSIN. I'm thinking of a purely text-based authenticaiton flow for cmd line clients. Something I've been thinking about since this summer. Originally I was thinking that we'd have to trigger a flow based on the OIDC 'display' parameter, but now I'm thinking that per-client-flows is a more elegant solution. On Thu, Jan 18, 2018 at 10:44 AM, Stian Thorgersen wrote: > Definitively makes sense for the 'Direct Grant Flow'. > > Did you also think about it for the 'Browser Flow'? That doesn't make sense > to me as I don't think the client should have any control on the SSO flow. > > > On 17 January 2018 at 20:37, Bill Burke wrote: >> >> TLDR; Per client authentication flows? Client can be configured to >> override realm authentication flows. >> >> Background: >> >> I'm specing out how we will replace OSIN (openshift oauth server) with >> Keycloak. One issue is that each oauth client in OSIN can specify the >> authentication flow they want. Non-browser clients like the 'oc' cmd >> line tool want a 401, challenge-based protocol...Web console, >> obviously wants HTML. They All OSIN clients use the OAuth >> auth-code-grant irregardless if they are non-brwoser or browser >> clients. Keycloak assumes this oauth grant type is browser based and >> expects non-browser clients to use Resource Credentials grant or >> client credential grant. OSIN does not support this and we (keycloak) >> have to be backward compatible. >> >> Solution: >> >> I think it would be pretty simple to add the ability to override >> authentication flows per client. I don't think this would be a >> one-off for OSIN as we could use it to implement other non-browser >> input protocols. For example, I wanted to be able to have a >> text-based auth flow for command line logins. I think this could be a >> way to implement that. >> -- >> 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 bburke at redhat.com Thu Jan 18 11:38:49 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jan 2018 11:38:49 -0500 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: I'll ping AOS team for more info. I think they want to be able to try things out immediately when a PR happens, like let's say I merge a PR that fixes or improves OSIN integration. And/or, they want to trigger a CI job whenever a PR is merged on our side (and vice versa). On Thu, Jan 18, 2018 at 10:05 AM, Stian Thorgersen wrote: > .... adding to my previous reply > > Once we have Jenkins instance setup it should be fairly trivial to have a > nightly build of the ZIPs published somewhere. When we have that we can > easily setup a build in Docker hub that would automatically build the image > and make it available. So you'd run with something like: > > docker run jboss/keycloak:nightly > > 'nightly' would always be the latest build. We could also add > 'nighly-', but not sure if that's necessary. > > On 18 January 2018 at 16:02, Stian Thorgersen wrote: >> >> Is the use-case folks that want to try out a feature available in master, >> but not in a Keycloak release yet? >> >> What about having daily builds instead? We could have both ZIPs and Docker >> images built daily. >> >> On 17 January 2018 at 20:18, Bruno Oliveira wrote: >>> >>> Oh, I forgot about a better option. Upload snapshots from Travis to Maven >>> repository and build the docker image based on the latest build. In this >>> way we don't need to build everything from scratch, because Travis >>> already >>> does it. >>> >>> On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira >>> wrote: >>> >>> > I believe something like this is what you meant >>> > >>> > https://raw.githubusercontent.com/abstractj/dockerfiles/keycloak/keycloak/keycloak-latest/Dockerfile. >>> > Some considerations about this: >>> > >>> > 1. We can automate the build on Docker Hub, but it's gonna take like >>> > forever at each build. Because it's going to download the internet like >>> > Marko mentioned >>> > 2. Maybe we should consider a smarter way of caching .m2 repositories. >>> > I >>> > just can think about a manual process for this. >>> > 3. In order to keep the image fresh, might be necessary to trigger the >>> > image build from Travis remotely. I'm not sure if we want this. >>> > >>> > Another alternative which I think may solve these 3 items above, is to >>> > provide weekly builds of this docker image. >>> > >>> > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke wrote: >>> > >>> >> .This image is for people that don't want to know anything about maven >>> >> our our build system and want to use a distro built from master. >>> >> >>> >> For developers like us, we just write a 2 line Dockerfile and mount >>> >> local disk to the image. This way you never have to rebuild the image >>> >> as you're developing as everything is in local disk. This is how I >>> >> approached things lately when I was fidling around the master + >>> >> kubernetes. >>> >> >>> >> >>> >> >>> >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj >>> >> wrote: >>> >> > Yeah, we could also checkout code in 'development' subdirectory and >>> >> provide >>> >> > an option to mount local dir as 'development'. We could also provide >>> >> option >>> >> > to skip checkout and to use existing code in the mounted >>> >> > ~/development/keycloak - that would use your local working version >>> >> > of >>> >> > keycloak - so you can have it open in your IDE and do a rebuild >>> >> iteration >>> >> > quickly ... >>> >> > >>> >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira >>> >> > >>> >> wrote: >>> >> >> >>> >> >> Maybe we can just provide an option for people to mount >>> >> >> $HOME/.m2/repository ? >>> >> >> >>> >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj >>> >> >> >>> >> >> wrote: >>> >> >>> >>> >> >>> The problematic part is 'mvn clean install' which will pull down >>> >> >>> the >>> >> >>> internet of dependencies as if you're building for the first time >>> >> >>> - >>> >> every >>> >> >>> time. >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" >>> >> >>> wrote: >>> >> >>> >>> >> >>> Hi Bill, I think it makes sense. But there are few things that >>> >> >>> people >>> >> >>> can't >>> >> >>> avoid, like install JDK for development. >>> >> >>> >>> >> >>> On AeroGear we had a -dev image like you described[1] >>> >> >>> >>> >> >>> [1] - >>> >> >>> >>> >> >>> >>> >> >>> >> https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/unifiedpush-wildfly-dev/Dockerfile >>> >> >>> >>> >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke >>> >> >>> wrote: >>> >> >>> >>> >> >>> > Do we need a development image that builds from master. A >>> >> Dockerfile >>> >> >>> > script that: >>> >> >>> > >>> >> >>> > - derives from jdk8 >>> >> >>> > - installs git client >>> >> >>> > - install maven >>> >> >>> > - git clone https://github.com/keycloak/keycloak >>> >> >>> > - mvn clean install -Pdistro -DskipTests=true >>> >> >>> > - unzip distro into /opt/keycloak >>> >> >>> > >>> >> >>> > We have a couple of teams asking for something like this within >>> >> >>> > Red >>> >> >>> > Hat as I'm guessing they don't want to deal with running maven >>> >> >>> > themselves. Does that sort of flow make sense? >>> >> >>> > >>> >> >>> > -- >>> >> >>> > 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 >>> >> >>> >>> >> >>> >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> 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 sthorger at redhat.com Thu Jan 18 11:56:22 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Jan 2018 17:56:22 +0100 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: Perhaps they should be testing with RH-SSO images then? If so the plan is to build OpenShift images for every PR. The pipeline that does that could also trigger the AOS tests and the temporary OpenShift images would be available for the test. We could also do the same for Keycloak tests and it wouldn't be to hard to create a Jenkins job that builds Docker images for every PR. We'd just need a Docker registry to host them in. On 18 Jan 2018 5:38 pm, "Bill Burke" wrote: > I'll ping AOS team for more info. I think they want to be able to try > things out immediately when a PR happens, like let's say I merge a PR > that fixes or improves OSIN integration. And/or, they want to trigger > a CI job whenever a PR is merged on our side (and vice versa). > > On Thu, Jan 18, 2018 at 10:05 AM, Stian Thorgersen > wrote: > > .... adding to my previous reply > > > > Once we have Jenkins instance setup it should be fairly trivial to have a > > nightly build of the ZIPs published somewhere. When we have that we can > > easily setup a build in Docker hub that would automatically build the > image > > and make it available. So you'd run with something like: > > > > docker run jboss/keycloak:nightly > > > > 'nightly' would always be the latest build. We could also add > > 'nighly-', but not sure if that's necessary. > > > > On 18 January 2018 at 16:02, Stian Thorgersen > wrote: > >> > >> Is the use-case folks that want to try out a feature available in > master, > >> but not in a Keycloak release yet? > >> > >> What about having daily builds instead? We could have both ZIPs and > Docker > >> images built daily. > >> > >> On 17 January 2018 at 20:18, Bruno Oliveira > wrote: > >>> > >>> Oh, I forgot about a better option. Upload snapshots from Travis to > Maven > >>> repository and build the docker image based on the latest build. In > this > >>> way we don't need to build everything from scratch, because Travis > >>> already > >>> does it. > >>> > >>> On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira > >>> wrote: > >>> > >>> > I believe something like this is what you meant > >>> > > >>> > https://raw.githubusercontent.com/abstractj/dockerfiles/ > keycloak/keycloak/keycloak-latest/Dockerfile. > >>> > Some considerations about this: > >>> > > >>> > 1. We can automate the build on Docker Hub, but it's gonna take like > >>> > forever at each build. Because it's going to download the internet > like > >>> > Marko mentioned > >>> > 2. Maybe we should consider a smarter way of caching .m2 > repositories. > >>> > I > >>> > just can think about a manual process for this. > >>> > 3. In order to keep the image fresh, might be necessary to trigger > the > >>> > image build from Travis remotely. I'm not sure if we want this. > >>> > > >>> > Another alternative which I think may solve these 3 items above, is > to > >>> > provide weekly builds of this docker image. > >>> > > >>> > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke > wrote: > >>> > > >>> >> .This image is for people that don't want to know anything about > maven > >>> >> our our build system and want to use a distro built from master. > >>> >> > >>> >> For developers like us, we just write a 2 line Dockerfile and mount > >>> >> local disk to the image. This way you never have to rebuild the > image > >>> >> as you're developing as everything is in local disk. This is how I > >>> >> approached things lately when I was fidling around the master + > >>> >> kubernetes. > >>> >> > >>> >> > >>> >> > >>> >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj < > mstrukel at redhat.com> > >>> >> wrote: > >>> >> > Yeah, we could also checkout code in 'development' subdirectory > and > >>> >> provide > >>> >> > an option to mount local dir as 'development'. We could also > provide > >>> >> option > >>> >> > to skip checkout and to use existing code in the mounted > >>> >> > ~/development/keycloak - that would use your local working version > >>> >> > of > >>> >> > keycloak - so you can have it open in your IDE and do a rebuild > >>> >> iteration > >>> >> > quickly ... > >>> >> > > >>> >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira > >>> >> > > >>> >> wrote: > >>> >> >> > >>> >> >> Maybe we can just provide an option for people to mount > >>> >> >> $HOME/.m2/repository ? > >>> >> >> > >>> >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj > >>> >> >> > >>> >> >> wrote: > >>> >> >>> > >>> >> >>> The problematic part is 'mvn clean install' which will pull down > >>> >> >>> the > >>> >> >>> internet of dependencies as if you're building for the first > time > >>> >> >>> - > >>> >> every > >>> >> >>> time. > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" > >>> >> >>> wrote: > >>> >> >>> > >>> >> >>> Hi Bill, I think it makes sense. But there are few things that > >>> >> >>> people > >>> >> >>> can't > >>> >> >>> avoid, like install JDK for development. > >>> >> >>> > >>> >> >>> On AeroGear we had a -dev image like you described[1] > >>> >> >>> > >>> >> >>> [1] - > >>> >> >>> > >>> >> >>> > >>> >> > >>> >> https://github.com/jboss-dockerfiles/aerogear/blob/ > master/wildfly/unifiedpush-wildfly-dev/Dockerfile > >>> >> >>> > >>> >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke > >>> >> >>> wrote: > >>> >> >>> > >>> >> >>> > Do we need a development image that builds from master. A > >>> >> Dockerfile > >>> >> >>> > script that: > >>> >> >>> > > >>> >> >>> > - derives from jdk8 > >>> >> >>> > - installs git client > >>> >> >>> > - install maven > >>> >> >>> > - git clone https://github.com/keycloak/keycloak > >>> >> >>> > - mvn clean install -Pdistro -DskipTests=true > >>> >> >>> > - unzip distro into /opt/keycloak > >>> >> >>> > > >>> >> >>> > We have a couple of teams asking for something like this > within > >>> >> >>> > Red > >>> >> >>> > Hat as I'm guessing they don't want to deal with running maven > >>> >> >>> > themselves. Does that sort of flow make sense? > >>> >> >>> > > >>> >> >>> > -- > >>> >> >>> > 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 > >>> >> >>> > >>> >> >>> > >>> >> > > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> 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 bburke at redhat.com Thu Jan 18 12:25:54 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jan 2018 12:25:54 -0500 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: We're going to be working together in master. On Thu, Jan 18, 2018 at 11:56 AM, Stian Thorgersen wrote: > Perhaps they should be testing with RH-SSO images then? > > If so the plan is to build OpenShift images for every PR. The pipeline that > does that could also trigger the AOS tests and the temporary OpenShift > images would be available for the test. > > We could also do the same for Keycloak tests and it wouldn't be to hard to > create a Jenkins job that builds Docker images for every PR. We'd just need > a Docker registry to host them in. > > On 18 Jan 2018 5:38 pm, "Bill Burke" wrote: >> >> I'll ping AOS team for more info. I think they want to be able to try >> things out immediately when a PR happens, like let's say I merge a PR >> that fixes or improves OSIN integration. And/or, they want to trigger >> a CI job whenever a PR is merged on our side (and vice versa). >> >> On Thu, Jan 18, 2018 at 10:05 AM, Stian Thorgersen >> wrote: >> > .... adding to my previous reply >> > >> > Once we have Jenkins instance setup it should be fairly trivial to have >> > a >> > nightly build of the ZIPs published somewhere. When we have that we can >> > easily setup a build in Docker hub that would automatically build the >> > image >> > and make it available. So you'd run with something like: >> > >> > docker run jboss/keycloak:nightly >> > >> > 'nightly' would always be the latest build. We could also add >> > 'nighly-', but not sure if that's necessary. >> > >> > On 18 January 2018 at 16:02, Stian Thorgersen >> > wrote: >> >> >> >> Is the use-case folks that want to try out a feature available in >> >> master, >> >> but not in a Keycloak release yet? >> >> >> >> What about having daily builds instead? We could have both ZIPs and >> >> Docker >> >> images built daily. >> >> >> >> On 17 January 2018 at 20:18, Bruno Oliveira >> >> wrote: >> >>> >> >>> Oh, I forgot about a better option. Upload snapshots from Travis to >> >>> Maven >> >>> repository and build the docker image based on the latest build. In >> >>> this >> >>> way we don't need to build everything from scratch, because Travis >> >>> already >> >>> does it. >> >>> >> >>> On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira >> >>> wrote: >> >>> >> >>> > I believe something like this is what you meant >> >>> > >> >>> > >> >>> > https://raw.githubusercontent.com/abstractj/dockerfiles/keycloak/keycloak/keycloak-latest/Dockerfile. >> >>> > Some considerations about this: >> >>> > >> >>> > 1. We can automate the build on Docker Hub, but it's gonna take like >> >>> > forever at each build. Because it's going to download the internet >> >>> > like >> >>> > Marko mentioned >> >>> > 2. Maybe we should consider a smarter way of caching .m2 >> >>> > repositories. >> >>> > I >> >>> > just can think about a manual process for this. >> >>> > 3. In order to keep the image fresh, might be necessary to trigger >> >>> > the >> >>> > image build from Travis remotely. I'm not sure if we want this. >> >>> > >> >>> > Another alternative which I think may solve these 3 items above, is >> >>> > to >> >>> > provide weekly builds of this docker image. >> >>> > >> >>> > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke >> >>> > wrote: >> >>> > >> >>> >> .This image is for people that don't want to know anything about >> >>> >> maven >> >>> >> our our build system and want to use a distro built from master. >> >>> >> >> >>> >> For developers like us, we just write a 2 line Dockerfile and mount >> >>> >> local disk to the image. This way you never have to rebuild the >> >>> >> image >> >>> >> as you're developing as everything is in local disk. This is how I >> >>> >> approached things lately when I was fidling around the master + >> >>> >> kubernetes. >> >>> >> >> >>> >> >> >>> >> >> >>> >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj >> >>> >> >> >>> >> wrote: >> >>> >> > Yeah, we could also checkout code in 'development' subdirectory >> >>> >> > and >> >>> >> provide >> >>> >> > an option to mount local dir as 'development'. We could also >> >>> >> > provide >> >>> >> option >> >>> >> > to skip checkout and to use existing code in the mounted >> >>> >> > ~/development/keycloak - that would use your local working >> >>> >> > version >> >>> >> > of >> >>> >> > keycloak - so you can have it open in your IDE and do a rebuild >> >>> >> iteration >> >>> >> > quickly ... >> >>> >> > >> >>> >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira >> >>> >> > >> >>> >> wrote: >> >>> >> >> >> >>> >> >> Maybe we can just provide an option for people to mount >> >>> >> >> $HOME/.m2/repository ? >> >>> >> >> >> >>> >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj >> >>> >> >> >> >>> >> >> wrote: >> >>> >> >>> >> >>> >> >>> The problematic part is 'mvn clean install' which will pull >> >>> >> >>> down >> >>> >> >>> the >> >>> >> >>> internet of dependencies as if you're building for the first >> >>> >> >>> time >> >>> >> >>> - >> >>> >> every >> >>> >> >>> time. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" >> >>> >> >>> wrote: >> >>> >> >>> >> >>> >> >>> Hi Bill, I think it makes sense. But there are few things that >> >>> >> >>> people >> >>> >> >>> can't >> >>> >> >>> avoid, like install JDK for development. >> >>> >> >>> >> >>> >> >>> On AeroGear we had a -dev image like you described[1] >> >>> >> >>> >> >>> >> >>> [1] - >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >>> >> >> >>> >> https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/unifiedpush-wildfly-dev/Dockerfile >> >>> >> >>> >> >>> >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke >> >>> >> >>> wrote: >> >>> >> >>> >> >>> >> >>> > Do we need a development image that builds from master. A >> >>> >> Dockerfile >> >>> >> >>> > script that: >> >>> >> >>> > >> >>> >> >>> > - derives from jdk8 >> >>> >> >>> > - installs git client >> >>> >> >>> > - install maven >> >>> >> >>> > - git clone https://github.com/keycloak/keycloak >> >>> >> >>> > - mvn clean install -Pdistro -DskipTests=true >> >>> >> >>> > - unzip distro into /opt/keycloak >> >>> >> >>> > >> >>> >> >>> > We have a couple of teams asking for something like this >> >>> >> >>> > within >> >>> >> >>> > Red >> >>> >> >>> > Hat as I'm guessing they don't want to deal with running >> >>> >> >>> > maven >> >>> >> >>> > themselves. Does that sort of flow make sense? >> >>> >> >>> > >> >>> >> >>> > -- >> >>> >> >>> > 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 >> >>> >> >>> >> >>> >> >>> >> >>> >> > >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> 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 -- Bill Burke Red Hat From mposolda at redhat.com Fri Jan 19 01:08:43 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jan 2018 07:08:43 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: Message-ID: <5828aa54-90c9-5c8b-fe42-25397f278ef3@redhat.com> I wonder if it's related to support for OIDC "acr" parameter (authentication levels)? I can imagine that we map different values of "acr" parameter to different authentication flows. Then in adapter configuration keycloak.json, you can use something like "default_acr" . If it's set, client adapter will send initial OIDC request with this "acr" value and hence will use specific authentication flow corresponding to that "acr" . This has an advantage, that single client can possibly use different authentication flows. As client will have possibility to override default_acr based on the usecase. For example bank application can require just simple username+password login to see the account details, but may require stronger authentication level (OTP) for further actions like sending payment to different account. Marek On 18/01/18 17:33, Bill Burke wrote: > Makes sense for both direct grant and browser flow. Please reread the > OP. I'll try to summarize differently. In Keycoak, using OAuth > authorization code grant protocol means that the 'Browser Flow" will > be invoked. *All* OSIN clients use the code grant and clients are > configured individually whether a challenge based protocol should be > used or not. It is a Keycloak requirement to remain backward > compatible so Keycloak can just be turned on with no changes. What it > boils down to is cmd-line clients vs. browser clients. I would hate > to add an architectural feature just to implement something OSIN > specific, but I think this would be useful beyond OSIN. I'm thinking > of a purely text-based authenticaiton flow for cmd line clients. > Something I've been thinking about since this summer. Originally I was > thinking that we'd have to trigger a flow based on the OIDC 'display' > parameter, but now I'm thinking that per-client-flows is a more > elegant solution. > > On Thu, Jan 18, 2018 at 10:44 AM, Stian Thorgersen wrote: >> Definitively makes sense for the 'Direct Grant Flow'. >> >> Did you also think about it for the 'Browser Flow'? That doesn't make sense >> to me as I don't think the client should have any control on the SSO flow. >> >> >> On 17 January 2018 at 20:37, Bill Burke wrote: >>> TLDR; Per client authentication flows? Client can be configured to >>> override realm authentication flows. >>> >>> Background: >>> >>> I'm specing out how we will replace OSIN (openshift oauth server) with >>> Keycloak. One issue is that each oauth client in OSIN can specify the >>> authentication flow they want. Non-browser clients like the 'oc' cmd >>> line tool want a 401, challenge-based protocol...Web console, >>> obviously wants HTML. They All OSIN clients use the OAuth >>> auth-code-grant irregardless if they are non-brwoser or browser >>> clients. Keycloak assumes this oauth grant type is browser based and >>> expects non-browser clients to use Resource Credentials grant or >>> client credential grant. OSIN does not support this and we (keycloak) >>> have to be backward compatible. >>> >>> Solution: >>> >>> I think it would be pretty simple to add the ability to override >>> authentication flows per client. I don't think this would be a >>> one-off for OSIN as we could use it to implement other non-browser >>> input protocols. For example, I wanted to be able to have a >>> text-based auth flow for command line logins. I think this could be a >>> way to implement that. >>> -- >>> Bill Burke >>> Red Hat >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From bburke at redhat.com Fri Jan 19 08:21:17 2018 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Jan 2018 08:21:17 -0500 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: <5828aa54-90c9-5c8b-fe42-25397f278ef3@redhat.com> References: <5828aa54-90c9-5c8b-fe42-25397f278ef3@redhat.com> Message-ID: That's "step-up" authentication right? Or is acr something different. Yeah, I think per-client flow could be an alternative way to implement it. Don't know if its a better way, but it is an alternative. BTW, different topic, one thing I'm worried about though is, are auth flows now dependent on cookies? We may have to optionally allow query params to specify the auth session rather than a cookie. For non-browser grants, we'll have logins spanning multiple requests (think SPNEGO/Kerberos) and they may not support cookies. On Fri, Jan 19, 2018 at 1:08 AM, Marek Posolda wrote: > I wonder if it's related to support for OIDC "acr" parameter (authentication > levels)? I can imagine that we map different values of "acr" parameter to > different authentication flows. > > Then in adapter configuration keycloak.json, you can use something like > "default_acr" . If it's set, client adapter will send initial OIDC request > with this "acr" value and hence will use specific authentication flow > corresponding to that "acr" . > > This has an advantage, that single client can possibly use different > authentication flows. As client will have possibility to override > default_acr based on the usecase. For example bank application can require > just simple username+password login to see the account details, but may > require stronger authentication level (OTP) for further actions like sending > payment to different account. > > Marek > > > On 18/01/18 17:33, Bill Burke wrote: >> >> Makes sense for both direct grant and browser flow. Please reread the >> OP. I'll try to summarize differently. In Keycoak, using OAuth >> authorization code grant protocol means that the 'Browser Flow" will >> be invoked. *All* OSIN clients use the code grant and clients are >> configured individually whether a challenge based protocol should be >> used or not. It is a Keycloak requirement to remain backward >> compatible so Keycloak can just be turned on with no changes. What it >> boils down to is cmd-line clients vs. browser clients. I would hate >> to add an architectural feature just to implement something OSIN >> specific, but I think this would be useful beyond OSIN. I'm thinking >> of a purely text-based authenticaiton flow for cmd line clients. >> Something I've been thinking about since this summer. Originally I was >> thinking that we'd have to trigger a flow based on the OIDC 'display' >> parameter, but now I'm thinking that per-client-flows is a more >> elegant solution. >> >> On Thu, Jan 18, 2018 at 10:44 AM, Stian Thorgersen >> wrote: >>> >>> Definitively makes sense for the 'Direct Grant Flow'. >>> >>> Did you also think about it for the 'Browser Flow'? That doesn't make >>> sense >>> to me as I don't think the client should have any control on the SSO >>> flow. >>> >>> >>> On 17 January 2018 at 20:37, Bill Burke wrote: >>>> >>>> TLDR; Per client authentication flows? Client can be configured to >>>> override realm authentication flows. >>>> >>>> Background: >>>> >>>> I'm specing out how we will replace OSIN (openshift oauth server) with >>>> Keycloak. One issue is that each oauth client in OSIN can specify the >>>> authentication flow they want. Non-browser clients like the 'oc' cmd >>>> line tool want a 401, challenge-based protocol...Web console, >>>> obviously wants HTML. They All OSIN clients use the OAuth >>>> auth-code-grant irregardless if they are non-brwoser or browser >>>> clients. Keycloak assumes this oauth grant type is browser based and >>>> expects non-browser clients to use Resource Credentials grant or >>>> client credential grant. OSIN does not support this and we (keycloak) >>>> have to be backward compatible. >>>> >>>> Solution: >>>> >>>> I think it would be pretty simple to add the ability to override >>>> authentication flows per client. I don't think this would be a >>>> one-off for OSIN as we could use it to implement other non-browser >>>> input protocols. For example, I wanted to be able to have a >>>> text-based auth flow for command line logins. I think this could be a >>>> way to implement that. >>>> -- >>>> 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 john.d.ament at gmail.com Fri Jan 19 09:11:59 2018 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 19 Jan 2018 14:11:59 +0000 Subject: [keycloak-dev] Possible bug in Keycloak 3.4.3? In-Reply-To: References: Message-ID: My coworker, who has a lot more context than I, ended up reporting it as a defect - https://issues.jboss.org/browse/KEYCLOAK-6312 John On Thu, Jan 18, 2018 at 10:30 AM John D. Ament wrote: > Ping. Should I create a defect? I actually suspect it's related to a > comment I added to KEYCLOAK-6286, but not sure. For some reason, we're > resulting in a redirect URI that includes session_state but it shouldn't. > This results in duplicate session_state query params being added. > > John > > > On Tue, Jan 16, 2018 at 3:51 PM John D. Ament > wrote: > >> Hi, >> >> We're working on upgrading to Keycloak 3.4.3. We hit a weird issue where >> it looks like some backwards compatible code isn't working right in the >> client adapter. We found this block which seems suspect >> >> >> https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L306-L314 >> >> It looks like the values for redirectUri and redirectUriParam are >> actually backwards. We see the session_state query param in the value of >> redirectUri not redirectUriParam, and this causes the next check for the >> values being equal to fail. >> >> John >> > From mposolda at redhat.com Fri Jan 19 09:25:34 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jan 2018 15:25:34 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: <5828aa54-90c9-5c8b-fe42-25397f278ef3@redhat.com> Message-ID: <14561768-2fc5-41fa-b80f-7024b4751588@redhat.com> On 19/01/18 14:21, Bill Burke wrote: > That's "step-up" authentication right? Or is acr something different. > Yeah, I think per-client flow could be an alternative way to implement > it. Don't know if its a better way, but it is an alternative. Yes, it is about step-up authentication. I hope this can indirectly help with per-client flows, but not 100% sure. One possible issue with different "acr" values for different authentication flows is the fact, that with the step-up authentication you may not want to repeat some authenticators, which were already successful for this userSession. For example you have flow1 with password-only and flow2 with password+OTP. When application is already authenticated with level1 (username+pasword), but now wants level2, you don't want to type password again if you already authenticated through password before. So authentication flow should ask just for OTP in this case. But executionId of usernamePassword authenticator will be different in both authentication flows. However maybe this can be addressed with the "amr" claim, which can be saved in IDToken (This is per OIDC specs http://openid.net/specs/openid-connect-core-1_0.html#IDToken) and maybe also userSession. It contains the String representations of used authentication methods. Hopefully we can use this to track that username+password authenticator was already used in this userSession in different authentication flow and hence skip the usernamePassword authenticator when moving from level1 to level2. > > BTW, different topic, one thing I'm worried about though is, are auth > flows now dependent on cookies? We may have to optionally allow query > params to specify the auth session rather than a cookie. For > non-browser grants, we'll have logins spanning multiple requests > (think SPNEGO/Kerberos) and they may not support cookies. Yes, I see. Someone already asked on keycloak-user mailing list about the alternative of using query parameter instead of the cookie. I think it was similar usecase like Openshift. Authorization code OIDC flow was needed in some non-browser authentication scenario. Marek > > On Fri, Jan 19, 2018 at 1:08 AM, Marek Posolda wrote: >> I wonder if it's related to support for OIDC "acr" parameter (authentication >> levels)? I can imagine that we map different values of "acr" parameter to >> different authentication flows. >> >> Then in adapter configuration keycloak.json, you can use something like >> "default_acr" . If it's set, client adapter will send initial OIDC request >> with this "acr" value and hence will use specific authentication flow >> corresponding to that "acr" . >> >> This has an advantage, that single client can possibly use different >> authentication flows. As client will have possibility to override >> default_acr based on the usecase. For example bank application can require >> just simple username+password login to see the account details, but may >> require stronger authentication level (OTP) for further actions like sending >> payment to different account. >> >> Marek >> >> >> On 18/01/18 17:33, Bill Burke wrote: >>> Makes sense for both direct grant and browser flow. Please reread the >>> OP. I'll try to summarize differently. In Keycoak, using OAuth >>> authorization code grant protocol means that the 'Browser Flow" will >>> be invoked. *All* OSIN clients use the code grant and clients are >>> configured individually whether a challenge based protocol should be >>> used or not. It is a Keycloak requirement to remain backward >>> compatible so Keycloak can just be turned on with no changes. What it >>> boils down to is cmd-line clients vs. browser clients. I would hate >>> to add an architectural feature just to implement something OSIN >>> specific, but I think this would be useful beyond OSIN. I'm thinking >>> of a purely text-based authenticaiton flow for cmd line clients. >>> Something I've been thinking about since this summer. Originally I was >>> thinking that we'd have to trigger a flow based on the OIDC 'display' >>> parameter, but now I'm thinking that per-client-flows is a more >>> elegant solution. >>> >>> On Thu, Jan 18, 2018 at 10:44 AM, Stian Thorgersen >>> wrote: >>>> Definitively makes sense for the 'Direct Grant Flow'. >>>> >>>> Did you also think about it for the 'Browser Flow'? That doesn't make >>>> sense >>>> to me as I don't think the client should have any control on the SSO >>>> flow. >>>> >>>> >>>> On 17 January 2018 at 20:37, Bill Burke wrote: >>>>> TLDR; Per client authentication flows? Client can be configured to >>>>> override realm authentication flows. >>>>> >>>>> Background: >>>>> >>>>> I'm specing out how we will replace OSIN (openshift oauth server) with >>>>> Keycloak. One issue is that each oauth client in OSIN can specify the >>>>> authentication flow they want. Non-browser clients like the 'oc' cmd >>>>> line tool want a 401, challenge-based protocol...Web console, >>>>> obviously wants HTML. They All OSIN clients use the OAuth >>>>> auth-code-grant irregardless if they are non-brwoser or browser >>>>> clients. Keycloak assumes this oauth grant type is browser based and >>>>> expects non-browser clients to use Resource Credentials grant or >>>>> client credential grant. OSIN does not support this and we (keycloak) >>>>> have to be backward compatible. >>>>> >>>>> Solution: >>>>> >>>>> I think it would be pretty simple to add the ability to override >>>>> authentication flows per client. I don't think this would be a >>>>> one-off for OSIN as we could use it to implement other non-browser >>>>> input protocols. For example, I wanted to be able to have a >>>>> text-based auth flow for command line logins. I think this could be a >>>>> way to implement that. >>>>> -- >>>>> Bill Burke >>>>> Red Hat >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> > > From bburke at redhat.com Fri Jan 19 10:39:53 2018 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Jan 2018 10:39:53 -0500 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: <14561768-2fc5-41fa-b80f-7024b4751588@redhat.com> References: <5828aa54-90c9-5c8b-fe42-25397f278ef3@redhat.com> <14561768-2fc5-41fa-b80f-7024b4751588@redhat.com> Message-ID: On Fri, Jan 19, 2018 at 9:25 AM, Marek Posolda wrote: > On 19/01/18 14:21, Bill Burke wrote: >> >> That's "step-up" authentication right? Or is acr something different. >> Yeah, I think per-client flow could be an alternative way to implement >> it. Don't know if its a better way, but it is an alternative. > > Yes, it is about step-up authentication. I hope this can indirectly help > with per-client flows, but not 100% sure. > > One possible issue with different "acr" values for different authentication > flows is the fact, that with the step-up authentication you may not want to > repeat some authenticators, which were already successful for this > userSession. > > For example you have flow1 with password-only and flow2 with password+OTP. > When application is already authenticated with level1 (username+pasword), > but now wants level2, you don't want to type password again if you already > authenticated through password before. So authentication flow should ask > just for OTP in this case. But executionId of usernamePassword authenticator > will be different in both authentication flows. > > However maybe this can be addressed with the "amr" claim, which can be saved > in IDToken (This is per OIDC specs > http://openid.net/specs/openid-connect-core-1_0.html#IDToken) and maybe also > userSession. It contains the String representations of used authentication > methods. Hopefully we can use this to track that username+password > authenticator was already used in this userSession in different > authentication flow and hence skip the usernamePassword authenticator when > moving from level1 to level2. > There's a few different approaches we can take that Stian and I discussed in a F2F last year. But I think per-client flows is useful irregardless if we use them to implement step-up auth. Right? >> >> BTW, different topic, one thing I'm worried about though is, are auth >> flows now dependent on cookies? We may have to optionally allow query >> params to specify the auth session rather than a cookie. For >> non-browser grants, we'll have logins spanning multiple requests >> (think SPNEGO/Kerberos) and they may not support cookies. > > Yes, I see. Someone already asked on keycloak-user mailing list about the > alternative of using query parameter instead of the cookie. I think it was > similar usecase like Openshift. Authorization code OIDC flow was needed in > some non-browser authentication scenario. I think I remember another value of using a query param was that you could continue an auth session in a completely different browser. How do you think to implement? If a cookie is set, use that value for auth session, if not allow it to be specified as query parameter? I'll look into this and discuss more later in separate thread. -- Bill Burke Red Hat From mposolda at redhat.com Fri Jan 19 12:27:19 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jan 2018 18:27:19 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: <5828aa54-90c9-5c8b-fe42-25397f278ef3@redhat.com> <14561768-2fc5-41fa-b80f-7024b4751588@redhat.com> Message-ID: <4e598a82-60be-b00f-33c5-c3b4485dafdc@redhat.com> On 19/01/18 16:39, Bill Burke wrote: > On Fri, Jan 19, 2018 at 9:25 AM, Marek Posolda wrote: >> On 19/01/18 14:21, Bill Burke wrote: >>> That's "step-up" authentication right? Or is acr something different. >>> Yeah, I think per-client flow could be an alternative way to implement >>> it. Don't know if its a better way, but it is an alternative. >> Yes, it is about step-up authentication. I hope this can indirectly help >> with per-client flows, but not 100% sure. >> >> One possible issue with different "acr" values for different authentication >> flows is the fact, that with the step-up authentication you may not want to >> repeat some authenticators, which were already successful for this >> userSession. >> >> For example you have flow1 with password-only and flow2 with password+OTP. >> When application is already authenticated with level1 (username+pasword), >> but now wants level2, you don't want to type password again if you already >> authenticated through password before. So authentication flow should ask >> just for OTP in this case. But executionId of usernamePassword authenticator >> will be different in both authentication flows. >> >> However maybe this can be addressed with the "amr" claim, which can be saved >> in IDToken (This is per OIDC specs >> http://openid.net/specs/openid-connect-core-1_0.html#IDToken) and maybe also >> userSession. It contains the String representations of used authentication >> methods. Hopefully we can use this to track that username+password >> authenticator was already used in this userSession in different >> authentication flow and hence skip the usernamePassword authenticator when >> moving from level1 to level2. >> > There's a few different approaches we can take that Stian and I > discussed in a F2F last year. But I think per-client flows is useful > irregardless if we use them to implement step-up auth. Right? Yeah, sure. I was just thinking if it's possible to address 2 usecases by implementing 1 single feature :) But not sure if it's best approach anyway... Feel free to do whatever you think is best. > >>> BTW, different topic, one thing I'm worried about though is, are auth >>> flows now dependent on cookies? We may have to optionally allow query >>> params to specify the auth session rather than a cookie. For >>> non-browser grants, we'll have logins spanning multiple requests >>> (think SPNEGO/Kerberos) and they may not support cookies. >> Yes, I see. Someone already asked on keycloak-user mailing list about the >> alternative of using query parameter instead of the cookie. I think it was >> similar usecase like Openshift. Authorization code OIDC flow was needed in >> some non-browser authentication scenario. > I think I remember another value of using a query param was that you > could continue an auth session in a completely different browser. > > How do you think to implement? If a cookie is set, use that value for > auth session, if not allow it to be specified as query parameter? > I'll look into this and discuss more later in separate thread. > > > Yes, that should work. The most of the related code is in AuthenticationSessionManager. Maybe we can add more separate providers (cookie, query) and allow somehow to configure which one will be used? Marek From sthorger at redhat.com Mon Jan 22 02:48:04 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Jan 2018 08:48:04 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: Message-ID: I missed the part about code grant flow being used regardless. Of course the spec doesn't even mandate the user-agent is a web browser, just says it typically is. I think acr/display (or some other query parameter) vs a different flow boils down to usability. Basically is it simpler to have one "dynamic" flow or is it simpler to just have separate flows. I think in most cases you're right and it will probably be cleaner and simpler to simply have different flows. Did you think about including this new flow OOTB? Is it OSIN specific or is it a generic non-web version of the regular web based flow? Another thing is the user-agent always controlled by the client? Or could a single client have different user-agents. On 18 January 2018 at 17:33, Bill Burke wrote: > Makes sense for both direct grant and browser flow. Please reread the > OP. I'll try to summarize differently. In Keycoak, using OAuth > authorization code grant protocol means that the 'Browser Flow" will > be invoked. *All* OSIN clients use the code grant and clients are > configured individually whether a challenge based protocol should be > used or not. It is a Keycloak requirement to remain backward > compatible so Keycloak can just be turned on with no changes. What it > boils down to is cmd-line clients vs. browser clients. I would hate > to add an architectural feature just to implement something OSIN > specific, but I think this would be useful beyond OSIN. I'm thinking > of a purely text-based authenticaiton flow for cmd line clients. > Something I've been thinking about since this summer. Originally I was > thinking that we'd have to trigger a flow based on the OIDC 'display' > parameter, but now I'm thinking that per-client-flows is a more > elegant solution. > > On Thu, Jan 18, 2018 at 10:44 AM, Stian Thorgersen > wrote: > > Definitively makes sense for the 'Direct Grant Flow'. > > > > Did you also think about it for the 'Browser Flow'? That doesn't make > sense > > to me as I don't think the client should have any control on the SSO > flow. > > > > > > On 17 January 2018 at 20:37, Bill Burke wrote: > >> > >> TLDR; Per client authentication flows? Client can be configured to > >> override realm authentication flows. > >> > >> Background: > >> > >> I'm specing out how we will replace OSIN (openshift oauth server) with > >> Keycloak. One issue is that each oauth client in OSIN can specify the > >> authentication flow they want. Non-browser clients like the 'oc' cmd > >> line tool want a 401, challenge-based protocol...Web console, > >> obviously wants HTML. They All OSIN clients use the OAuth > >> auth-code-grant irregardless if they are non-brwoser or browser > >> clients. Keycloak assumes this oauth grant type is browser based and > >> expects non-browser clients to use Resource Credentials grant or > >> client credential grant. OSIN does not support this and we (keycloak) > >> have to be backward compatible. > >> > >> Solution: > >> > >> I think it would be pretty simple to add the ability to override > >> authentication flows per client. I don't think this would be a > >> one-off for OSIN as we could use it to implement other non-browser > >> input protocols. For example, I wanted to be able to have a > >> text-based auth flow for command line logins. I think this could be a > >> way to implement that. > >> -- > >> 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 sthorger at redhat.com Mon Jan 22 02:52:44 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Jan 2018 08:52:44 +0100 Subject: [keycloak-dev] development image? In-Reply-To: References: Message-ID: Short/medium term it makes sense to have something simple for them that lets you co-operate. If that's the development image you propose I don't have a problem with that (for Maven caching issue you could probably just use a volume or simple mount ~/.m2/repository from the host into the container). Would be nice to also have some options to specify the repository and branch so it can be used to build a personal fork and/or a different branch (couple environment variables should allow that). In the longer term the plan is to create pipelines that can build our ZIPs and OpenShift images on every PR. Once that's ready we should tie it together with tests for this integration so we can run the tests with the xPaaS RH-SSO images as well as the Keycloak images from Docker hub. On 18 January 2018 at 18:25, Bill Burke wrote: > We're going to be working together in master. > > On Thu, Jan 18, 2018 at 11:56 AM, Stian Thorgersen > wrote: > > Perhaps they should be testing with RH-SSO images then? > > > > If so the plan is to build OpenShift images for every PR. The pipeline > that > > does that could also trigger the AOS tests and the temporary OpenShift > > images would be available for the test. > > > > We could also do the same for Keycloak tests and it wouldn't be to hard > to > > create a Jenkins job that builds Docker images for every PR. We'd just > need > > a Docker registry to host them in. > > > > On 18 Jan 2018 5:38 pm, "Bill Burke" wrote: > >> > >> I'll ping AOS team for more info. I think they want to be able to try > >> things out immediately when a PR happens, like let's say I merge a PR > >> that fixes or improves OSIN integration. And/or, they want to trigger > >> a CI job whenever a PR is merged on our side (and vice versa). > >> > >> On Thu, Jan 18, 2018 at 10:05 AM, Stian Thorgersen > > >> wrote: > >> > .... adding to my previous reply > >> > > >> > Once we have Jenkins instance setup it should be fairly trivial to > have > >> > a > >> > nightly build of the ZIPs published somewhere. When we have that we > can > >> > easily setup a build in Docker hub that would automatically build the > >> > image > >> > and make it available. So you'd run with something like: > >> > > >> > docker run jboss/keycloak:nightly > >> > > >> > 'nightly' would always be the latest build. We could also add > >> > 'nighly-', but not sure if that's necessary. > >> > > >> > On 18 January 2018 at 16:02, Stian Thorgersen > >> > wrote: > >> >> > >> >> Is the use-case folks that want to try out a feature available in > >> >> master, > >> >> but not in a Keycloak release yet? > >> >> > >> >> What about having daily builds instead? We could have both ZIPs and > >> >> Docker > >> >> images built daily. > >> >> > >> >> On 17 January 2018 at 20:18, Bruno Oliveira > >> >> wrote: > >> >>> > >> >>> Oh, I forgot about a better option. Upload snapshots from Travis to > >> >>> Maven > >> >>> repository and build the docker image based on the latest build. In > >> >>> this > >> >>> way we don't need to build everything from scratch, because Travis > >> >>> already > >> >>> does it. > >> >>> > >> >>> On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira > > >> >>> wrote: > >> >>> > >> >>> > I believe something like this is what you meant > >> >>> > > >> >>> > > >> >>> > https://raw.githubusercontent.com/abstractj/dockerfiles/ > keycloak/keycloak/keycloak-latest/Dockerfile. > >> >>> > Some considerations about this: > >> >>> > > >> >>> > 1. We can automate the build on Docker Hub, but it's gonna take > like > >> >>> > forever at each build. Because it's going to download the internet > >> >>> > like > >> >>> > Marko mentioned > >> >>> > 2. Maybe we should consider a smarter way of caching .m2 > >> >>> > repositories. > >> >>> > I > >> >>> > just can think about a manual process for this. > >> >>> > 3. In order to keep the image fresh, might be necessary to trigger > >> >>> > the > >> >>> > image build from Travis remotely. I'm not sure if we want this. > >> >>> > > >> >>> > Another alternative which I think may solve these 3 items above, > is > >> >>> > to > >> >>> > provide weekly builds of this docker image. > >> >>> > > >> >>> > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke > >> >>> > wrote: > >> >>> > > >> >>> >> .This image is for people that don't want to know anything about > >> >>> >> maven > >> >>> >> our our build system and want to use a distro built from master. > >> >>> >> > >> >>> >> For developers like us, we just write a 2 line Dockerfile and > mount > >> >>> >> local disk to the image. This way you never have to rebuild the > >> >>> >> image > >> >>> >> as you're developing as everything is in local disk. This is > how I > >> >>> >> approached things lately when I was fidling around the master + > >> >>> >> kubernetes. > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj > >> >>> >> > >> >>> >> wrote: > >> >>> >> > Yeah, we could also checkout code in 'development' subdirectory > >> >>> >> > and > >> >>> >> provide > >> >>> >> > an option to mount local dir as 'development'. We could also > >> >>> >> > provide > >> >>> >> option > >> >>> >> > to skip checkout and to use existing code in the mounted > >> >>> >> > ~/development/keycloak - that would use your local working > >> >>> >> > version > >> >>> >> > of > >> >>> >> > keycloak - so you can have it open in your IDE and do a rebuild > >> >>> >> iteration > >> >>> >> > quickly ... > >> >>> >> > > >> >>> >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira > >> >>> >> > > >> >>> >> wrote: > >> >>> >> >> > >> >>> >> >> Maybe we can just provide an option for people to mount > >> >>> >> >> $HOME/.m2/repository ? > >> >>> >> >> > >> >>> >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj > >> >>> >> >> > >> >>> >> >> wrote: > >> >>> >> >>> > >> >>> >> >>> The problematic part is 'mvn clean install' which will pull > >> >>> >> >>> down > >> >>> >> >>> the > >> >>> >> >>> internet of dependencies as if you're building for the first > >> >>> >> >>> time > >> >>> >> >>> - > >> >>> >> every > >> >>> >> >>> time. > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" > > >> >>> >> >>> wrote: > >> >>> >> >>> > >> >>> >> >>> Hi Bill, I think it makes sense. But there are few things > that > >> >>> >> >>> people > >> >>> >> >>> can't > >> >>> >> >>> avoid, like install JDK for development. > >> >>> >> >>> > >> >>> >> >>> On AeroGear we had a -dev image like you described[1] > >> >>> >> >>> > >> >>> >> >>> [1] - > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> > >> >>> >> > >> >>> >> https://github.com/jboss-dockerfiles/aerogear/blob/ > master/wildfly/unifiedpush-wildfly-dev/Dockerfile > >> >>> >> >>> > >> >>> >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke < > bburke at redhat.com> > >> >>> >> >>> wrote: > >> >>> >> >>> > >> >>> >> >>> > Do we need a development image that builds from master. A > >> >>> >> Dockerfile > >> >>> >> >>> > script that: > >> >>> >> >>> > > >> >>> >> >>> > - derives from jdk8 > >> >>> >> >>> > - installs git client > >> >>> >> >>> > - install maven > >> >>> >> >>> > - git clone https://github.com/keycloak/keycloak > >> >>> >> >>> > - mvn clean install -Pdistro -DskipTests=true > >> >>> >> >>> > - unzip distro into /opt/keycloak > >> >>> >> >>> > > >> >>> >> >>> > We have a couple of teams asking for something like this > >> >>> >> >>> > within > >> >>> >> >>> > Red > >> >>> >> >>> > Hat as I'm guessing they don't want to deal with running > >> >>> >> >>> > maven > >> >>> >> >>> > themselves. Does that sort of flow make sense? > >> >>> >> >>> > > >> >>> >> >>> > -- > >> >>> >> >>> > 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 > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> > > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> -- > >> >>> >> 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 > > > > -- > Bill Burke > Red Hat > From sthorger at redhat.com Mon Jan 22 03:01:13 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Jan 2018 09:01:13 +0100 Subject: [keycloak-dev] Ignoring self signed cert errors while developing In-Reply-To: References: Message-ID: I don't think Keycloak server supports the 'disable-trust-manager' option. Keycloak adapters do, but that doesn't help you with the OpenShift IdP. Here's details on how to configure Keycloak server truststore: http://www.keycloak.org/docs/latest/server_installation/index.html#outgoing-http-requests You'd probably need to import your self-signed certificate to make it work. On 14 January 2018 at 21:59, Aiden Keating wrote: > Hello, > > I am configuring an OpenShift v3 identity provider on Keycloak using an > Ansible playbook. I have created the identity provider successfully. > > After filling in my OpenShift username and password I see an "Unexpected > error when authenticating with identity provider" error from Keycloak. This > is due to the self signed certificates of the OpenShift development cluster > I am using (using oc cluster up). > > I am looking for an option to ignore these errors when in a development > environment. > > I have read about the 'disable-trust-manager' option, from what I > understand this can be set in development environments to avoid these > errors. However, I am not fully clear on how to use it and how to configure > it. Can this option be set using the REST API? > > Any help would be greatly appreciated. > > Thanks, > Aiden Keating > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From akeating at redhat.com Mon Jan 22 03:38:16 2018 From: akeating at redhat.com (Aiden Keating) Date: Mon, 22 Jan 2018 08:38:16 +0000 Subject: [keycloak-dev] Ignoring self signed cert errors while developing In-Reply-To: References: Message-ID: Apologies for not following up on this thread sooner. After reading up a bit further on the topic I ended up configuring the trust store. Thanks, Aiden On Mon, Jan 22, 2018 at 8:01 AM, Stian Thorgersen wrote: > I don't think Keycloak server supports the 'disable-trust-manager' > option. Keycloak adapters do, but that doesn't help you with the OpenShift > IdP. > > Here's details on how to configure Keycloak server truststore: > http://www.keycloak.org/docs/latest/server_installation/ > index.html#outgoing-http-requests > > You'd probably need to import your self-signed certificate to make it work. > > On 14 January 2018 at 21:59, Aiden Keating wrote: > >> Hello, >> >> I am configuring an OpenShift v3 identity provider on Keycloak using an >> Ansible playbook. I have created the identity provider successfully. >> >> After filling in my OpenShift username and password I see an "Unexpected >> error when authenticating with identity provider" error from Keycloak. >> This >> is due to the self signed certificates of the OpenShift development >> cluster >> I am using (using oc cluster up). >> >> I am looking for an option to ignore these errors when in a development >> environment. >> >> I have read about the 'disable-trust-manager' option, from what I >> understand this can be set in development environments to avoid these >> errors. However, I am not fully clear on how to use it and how to >> configure >> it. Can this option be set using the REST API? >> >> Any help would be greatly appreciated. >> >> Thanks, >> Aiden Keating >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From thomas.darimont at googlemail.com Mon Jan 22 05:29:49 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 22 Jan 2018 11:29:49 +0100 Subject: [keycloak-dev] Download Link in Blog points to old download page Message-ID: Hello, I just noticed that the download link under http://blog.keycloak.org/ points to the old sourceforge download page. The download link should probably point to: http://www.keycloak.org/downloads Cheers, Thomas From pbraun at redhat.com Mon Jan 22 06:45:45 2018 From: pbraun at redhat.com (Peter Braun) Date: Mon, 22 Jan 2018 12:45:45 +0100 Subject: [keycloak-dev] Metrics Endpoint Message-ID: <99BFD460-F7DC-4970-8703-DB66343BA71B@redhat.com> Hey everybody, we (the AeroGear/Mobile team) have created a SPI that adds a metrics endpoint to KeyCloak[1]. It?s inspired by a similar project named keycloak-metrics-prometheus[2] but does not require an extra service. Metrics data is based on internal events and is exposed in Prometheus format. Just wanted to share this with you since there are a number of tickets in the KeyCloak JIRA about a such an endpoint. We?re happy about any suggestions/opinions. We?re also open to an upstream contribution if the opportunity arises and you are interested. Regards, Peter [1] https://github.com/aerogear/keycloak-metrics-spi [2] https://github.com/larscheid-schmitzhermes/keycloak-monitoring-prometheus From sthorger at redhat.com Mon Jan 22 07:43:43 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Jan 2018 13:43:43 +0100 Subject: [keycloak-dev] Download Link in Blog points to old download page In-Reply-To: References: Message-ID: Sorted On 22 January 2018 at 11:29, Thomas Darimont wrote: > Hello, > > I just noticed that the download link under http://blog.keycloak.org/ > points to the old sourceforge download page. > > The download link should probably point to: > http://www.keycloak.org/downloads > > Cheers, > Thomas > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From matzew at apache.org Mon Jan 22 07:45:08 2018 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 22 Jan 2018 13:45:08 +0100 Subject: [keycloak-dev] Metrics Endpoint In-Reply-To: <99BFD460-F7DC-4970-8703-DB66343BA71B@redhat.com> References: <99BFD460-F7DC-4970-8703-DB66343BA71B@redhat.com> Message-ID: On Mon, Jan 22, 2018 at 12:45 PM, Peter Braun wrote: > Hey everybody, > > we (the AeroGear/Mobile team) have created a SPI that adds a metrics > endpoint to KeyCloak[1]. It?s inspired by a similar project named > keycloak-metrics-prometheus[2] but does not require an extra service. > Metrics data is based on internal events and is exposed in Prometheus > format. > > Just wanted to share this with you since there are a number of tickets in > the KeyCloak JIRA about a such an endpoint. We?re happy about any > suggestions/opinions. We?re also open to an upstream contribution if the > opportunity arises and you are interested. > +1 for having this directly in Keycloak :-) > > > Regards, > Peter > > [1] https://github.com/aerogear/keycloak-metrics-spi < > https://github.com/aerogear/keycloak-metrics-spi> > [2] https://github.com/larscheid-schmitzhermes/keycloak- > monitoring-prometheus schmitzhermes/keycloak-monitoring-prometheus> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf From psilva at redhat.com Mon Jan 22 08:07:02 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 22 Jan 2018 11:07:02 -0200 Subject: [keycloak-dev] Authorization Services and UMA 2.0 changes Message-ID: Hi All, We are about to finish the initial round of changes to make Keycloak Authorization Services compliant with UMA 2.0. One of the main changes is related with a new OAuth2 Grant Type introduced by UMA 2.0 [1] and how it will be used as a replacement for both Entitlement and Authorization API. In UMA 2.0, there is no Authorization API anymore, thus it will be removed on future versions of Keycloak. Regarding Entitlement API, it will also be removed in favor of the new grant type, but in this case we are using some extensions to UMA grant type to provide the same functionality. One of the objectives of this change in particular is to have a single endpoint from where permissions can be obtained. Another important change is also related with UMA where end-users should be able now to manage their own resource and permissions via Account Management Console. Users would be able to access a "Resource" page from where they can: * See the resources they own * Check for pending permission requests (waiting for the owners approval). As well options to grant/deny the request. * Check for all "shared resources" / granted permissions. As well options to revoke permissions * Select an user they want to grant access to a resource and/or scope Other changes are related with the Policy Enforcer, Authorization Client Java API and configuration. For these areas in particular changes are minimal, specially regarding policy enforcer configuration. These changes are targeted to Keycloak v4 and we'll be updating docs accordingly, specially on how to migrate to the new version. Regards. Pedro Igor [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html From bburke at redhat.com Mon Jan 22 10:17:51 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 22 Jan 2018 10:17:51 -0500 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: Message-ID: On Mon, Jan 22, 2018 at 2:48 AM, Stian Thorgersen wrote: > I missed the part about code grant flow being used regardless. Of course the > spec doesn't even mandate the user-agent is a web browser, just says it > typically is. > > I think acr/display (or some other query parameter) vs a different flow > boils down to usability. Basically is it simpler to have one "dynamic" flow > or is it simpler to just have separate flows. I think in most cases you're > right and it will probably be cleaner and simpler to simply have different > flows. > > Did you think about including this new flow OOTB? Is it OSIN specific or is > it a generic non-web version of the regular web based flow? > I want to reorganize auth flows a bit so that we can catagorize them and provide a plugin mechanism so the admin console can dynamically show which flows can be configured (browser, direct grant, ecp, etc..). There's a lot to be done here, but probably just putting in enough at the moment to get the OSIN replacement going. > Another thing is the user-agent always controlled by the client? Or could a > single client have different user-agents. > They don't really have that concept. There's a client config variable "respondWithChallenges". When set, server responds with 401 challenges. -- Bill Burke Red Hat From sthorger at redhat.com Mon Jan 22 13:21:22 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Jan 2018 19:21:22 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: Message-ID: On 22 January 2018 at 16:17, Bill Burke wrote: > On Mon, Jan 22, 2018 at 2:48 AM, Stian Thorgersen > wrote: > > I missed the part about code grant flow being used regardless. Of course > the > > spec doesn't even mandate the user-agent is a web browser, just says it > > typically is. > > > > I think acr/display (or some other query parameter) vs a different flow > > boils down to usability. Basically is it simpler to have one "dynamic" > flow > > or is it simpler to just have separate flows. I think in most cases > you're > > right and it will probably be cleaner and simpler to simply have > different > > flows. > > > > Did you think about including this new flow OOTB? Is it OSIN specific or > is > > it a generic non-web version of the regular web based flow? > > > > I want to reorganize auth flows a bit so that we can catagorize them > and provide a plugin mechanism so the admin console can dynamically > show which flows can be configured (browser, direct grant, ecp, > etc..). There's a lot to be done here, but probably just putting in > enough at the moment to get the OSIN replacement going. > > > Another thing is the user-agent always controlled by the client? Or > could a > > single client have different user-agents. > > > > They don't really have that concept. There's a client config variable > "respondWithChallenges". When set, server responds with 401 > challenges. > I was also wondering if other (non OSIN) clients would want to use more than one flow, but probably not. > > > > > -- > Bill Burke > Red Hat > From peters at develop4edu.de Tue Jan 23 09:29:19 2018 From: peters at develop4edu.de (Felix Peters) Date: Tue, 23 Jan 2018 14:29:19 +0000 Subject: [keycloak-dev] WG: How to generate a token string in a custom keycloak extension? Message-ID: <5caec6452e0742119ecf7d51638ec2ae@DOX13BE02.hex2013.com> Hi, I'm pretty new to Keycloak development and at the moment I'm trying to develop some demo extensions to learn how SPI's an stuff like that work in Keycloak. My Question is: Is there a util- or helper-class which I can use to generate an secure token string in my extension code (pretty much the same as an oauth access or refresh token)? I was not able to find something In the Keycloak code, but maybe there is something like that. Thank you in advance, Felix Peters From thomas.darimont at googlemail.com Tue Jan 23 09:47:30 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 23 Jan 2018 15:47:30 +0100 Subject: [keycloak-dev] WG: How to generate a token string in a custom keycloak extension? In-Reply-To: <5caec6452e0742119ecf7d51638ec2ae@DOX13BE02.hex2013.com> References: <5caec6452e0742119ecf7d51638ec2ae@DOX13BE02.hex2013.com> Message-ID: Hello Felix, What's your use case? Keycloak provides action tokens that permits its bearer to perform some actions, e. g. to reset a password or validate e-mail address. Perhaps you could have a look at the action tokens SPI: http://www.keycloak.org/docs/3.3/server_development/topics/action-token-spi.html Keycloaks OIDC Tokens (AccessToken, RefreshToken, IDToken) are generated within org.keycloak.protocol.oidc.TokenManager and exposed via the org.keycloak.protocol.oidc.endpoints.TokenEndpoint. Tokens can be verified via the org.keycloak.RSATokenVerifier. Cheers, Thomas 2018-01-23 15:29 GMT+01:00 Felix Peters : > Hi, > > I'm pretty new to Keycloak development and at the moment I'm trying to > develop some demo extensions to learn how SPI's an stuff like that work in > Keycloak. > > My Question is: > Is there a util- or helper-class which I can use to generate an secure > token string in my extension code (pretty much the same as an oauth access > or refresh token)? > I was not able to find something In the Keycloak code, but maybe there is > something like that. > Thank you in advance, > Felix Peters > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From peters at develop4edu.de Tue Jan 23 10:46:44 2018 From: peters at develop4edu.de (Felix Peters) Date: Tue, 23 Jan 2018 15:46:44 +0000 Subject: [keycloak-dev] WG: How to generate a token string in a custom keycloak extension? In-Reply-To: References: <5caec6452e0742119ecf7d51638ec2ae@DOX13BE02.hex2013.com> Message-ID: Thanks for your quick response. I try to implement a prototype of a password-free authenticator like it was mentioned in this thread: http://lists.jboss.org/pipermail/keycloak-user/2015-October/003387.html My current approach is to create a token on a rest endpoint and validate this token in an custom authenticator. It?s just a POV, but I think a ActionToken can do the job. I was googleing around for an existing solution for password-free login with Keycloak, but could not found something like that. Greeting, Felix Von: Thomas Darimont [mailto:thomas.darimont at googlemail.com] Gesendet: Dienstag, 23. Januar 2018 15:48 An: Felix Peters Cc: keycloak-dev at lists.jboss.org Betreff: Re: [keycloak-dev] WG: How to generate a token string in a custom keycloak extension? Hello Felix, What's your use case? Keycloak provides action tokens that permits its bearer to perform some actions, e. g. to reset a password or validate e-mail address. Perhaps you could have a look at the action tokens SPI: http://www.keycloak.org/docs/3.3/server_development/topics/action-token-spi.html Keycloaks OIDC Tokens (AccessToken, RefreshToken, IDToken) are generated within org.keycloak.protocol.oidc.TokenManager and exposed via the org.keycloak.protocol.oidc.endpoints.TokenEndpoint. Tokens can be verified via the org.keycloak.RSATokenVerifier. Cheers, Thomas 2018-01-23 15:29 GMT+01:00 Felix Peters >: Hi, I'm pretty new to Keycloak development and at the moment I'm trying to develop some demo extensions to learn how SPI's an stuff like that work in Keycloak. My Question is: Is there a util- or helper-class which I can use to generate an secure token string in my extension code (pretty much the same as an oauth access or refresh token)? I was not able to find something In the Keycloak code, but maybe there is something like that. Thank you in advance, Felix Peters _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Wed Jan 24 06:07:20 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 24 Jan 2018 12:07:20 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: Message-ID: <4c2cedd0-d452-96f5-b848-8fd6709d8a0f@redhat.com> Bill, I've added few minor comments to your PR. Does it makes sense to support authentication flows per clientTemplate too? Or is it just unnecessary complication? I wonder if it's similar to newly added themeSelector and thinking if we can have fallback chain like: client -> clientTemplate -> realm . Marek On 22/01/18 19:21, Stian Thorgersen wrote: > On 22 January 2018 at 16:17, Bill Burke wrote: > >> On Mon, Jan 22, 2018 at 2:48 AM, Stian Thorgersen >> wrote: >>> I missed the part about code grant flow being used regardless. Of course >> the >>> spec doesn't even mandate the user-agent is a web browser, just says it >>> typically is. >>> >>> I think acr/display (or some other query parameter) vs a different flow >>> boils down to usability. Basically is it simpler to have one "dynamic" >> flow >>> or is it simpler to just have separate flows. I think in most cases >> you're >>> right and it will probably be cleaner and simpler to simply have >> different >>> flows. >>> >>> Did you think about including this new flow OOTB? Is it OSIN specific or >> is >>> it a generic non-web version of the regular web based flow? >>> >> I want to reorganize auth flows a bit so that we can catagorize them >> and provide a plugin mechanism so the admin console can dynamically >> show which flows can be configured (browser, direct grant, ecp, >> etc..). There's a lot to be done here, but probably just putting in >> enough at the moment to get the OSIN replacement going. >> >>> Another thing is the user-agent always controlled by the client? Or >> could a >>> single client have different user-agents. >>> >> They don't really have that concept. There's a client config variable >> "respondWithChallenges". When set, server responds with 401 >> challenges. >> > I was also wondering if other (non OSIN) clients would want to use more > than one flow, but probably not. > > >> >> >> >> -- >> Bill Burke >> Red Hat >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From hmlnarik at redhat.com Wed Jan 24 07:09:18 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 24 Jan 2018 13:09:18 +0100 Subject: [keycloak-dev] WG: How to generate a token string in a custom keycloak extension? In-Reply-To: References: <5caec6452e0742119ecf7d51638ec2ae@DOX13BE02.hex2013.com> Message-ID: This should be relatively straightforward by using action token SPI: REST endpoint would issue the custom action token, then action token handler would set up the authentication session accordingly. In case you want deeper integration of the action token flow with authentication flow, check [1]. [1] https://github.com/keycloak/keycloak-quickstarts/tree/latest/action-token-authenticator On Tue, Jan 23, 2018 at 4:46 PM, Felix Peters wrote: > Thanks for your quick response. > > I try to implement a prototype of a password-free authenticator like it > was mentioned in this thread: http://lists.jboss.org/ > pipermail/keycloak-user/2015-October/003387.html > > My current approach is to create a token on a rest endpoint and validate > this token in an custom authenticator. > It?s just a POV, but I think a ActionToken can do the job. > > I was googleing around for an existing solution for password-free login > with Keycloak, but could not found something like that. > > Greeting, > Felix > > Von: Thomas Darimont [mailto:thomas.darimont at googlemail.com] > Gesendet: Dienstag, 23. Januar 2018 15:48 > An: Felix Peters > Cc: keycloak-dev at lists.jboss.org > Betreff: Re: [keycloak-dev] WG: How to generate a token string in a custom > keycloak extension? > > Hello Felix, > > What's your use case? > > Keycloak provides action tokens that permits its bearer to perform some > actions, e. g. to reset a password or validate e-mail address. > > Perhaps you could have a look at the action tokens SPI: > http://www.keycloak.org/docs/3.3/server_development/topics/ > action-token-spi.html > > Keycloaks OIDC Tokens (AccessToken, RefreshToken, IDToken) are generated > within org.keycloak.protocol.oidc.TokenManager and exposed > via the org.keycloak.protocol.oidc.endpoints.TokenEndpoint. Tokens can be > verified via the org.keycloak.RSATokenVerifier. > > Cheers, > Thomas > > 2018-01-23 15:29 GMT+01:00 Felix Peters peters at develop4edu.de>>: > Hi, > > I'm pretty new to Keycloak development and at the moment I'm trying to > develop some demo extensions to learn how SPI's an stuff like that work in > Keycloak. > > My Question is: > Is there a util- or helper-class which I can use to generate an secure > token string in my extension code (pretty much the same as an oauth access > or refresh token)? > I was not able to find something In the Keycloak code, but maybe there is > something like that. > Thank you in advance, > Felix Peters > > > _______________________________________________ > 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 > -- --Hynek From bburke at redhat.com Wed Jan 24 08:33:18 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 24 Jan 2018 08:33:18 -0500 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: <4c2cedd0-d452-96f5-b848-8fd6709d8a0f@redhat.com> References: <4c2cedd0-d452-96f5-b848-8fd6709d8a0f@redhat.com> Message-ID: I'll add a jira...but there's some things to think about for it. One of the things on my plate is Client Scope support ala oauth scopes. Was hoping to retire/replace client templates with client scopes and not sure if flow overrides fit there if a client is composed of multiple scopes. On Wed, Jan 24, 2018 at 6:07 AM, Marek Posolda wrote: > Bill, I've added few minor comments to your PR. > > Does it makes sense to support authentication flows per clientTemplate too? > Or is it just unnecessary complication? I wonder if it's similar to newly > added themeSelector and thinking if we can have fallback chain like: client > -> clientTemplate -> realm . > > Marek > > > > On 22/01/18 19:21, Stian Thorgersen wrote: >> >> On 22 January 2018 at 16:17, Bill Burke wrote: >> >>> On Mon, Jan 22, 2018 at 2:48 AM, Stian Thorgersen >>> wrote: >>>> >>>> I missed the part about code grant flow being used regardless. Of course >>> >>> the >>>> >>>> spec doesn't even mandate the user-agent is a web browser, just says it >>>> typically is. >>>> >>>> I think acr/display (or some other query parameter) vs a different flow >>>> boils down to usability. Basically is it simpler to have one "dynamic" >>> >>> flow >>>> >>>> or is it simpler to just have separate flows. I think in most cases >>> >>> you're >>>> >>>> right and it will probably be cleaner and simpler to simply have >>> >>> different >>>> >>>> flows. >>>> >>>> Did you think about including this new flow OOTB? Is it OSIN specific or >>> >>> is >>>> >>>> it a generic non-web version of the regular web based flow? >>>> >>> I want to reorganize auth flows a bit so that we can catagorize them >>> and provide a plugin mechanism so the admin console can dynamically >>> show which flows can be configured (browser, direct grant, ecp, >>> etc..). There's a lot to be done here, but probably just putting in >>> enough at the moment to get the OSIN replacement going. >>> >>>> Another thing is the user-agent always controlled by the client? Or >>> >>> could a >>>> >>>> single client have different user-agents. >>>> >>> They don't really have that concept. There's a client config variable >>> "respondWithChallenges". When set, server responds with 401 >>> challenges. >>> >> I was also wondering if other (non OSIN) clients would want to use more >> than one flow, but probably not. >> >> >>> >>> >>> >>> -- >>> 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 frelibert at yahoo.com Wed Jan 24 08:38:30 2018 From: frelibert at yahoo.com (Frederik Libert) Date: Wed, 24 Jan 2018 13:38:30 +0000 (UTC) Subject: [keycloak-dev] proof-of-possession References: <1808446895.222714.1516801110640.ref@mail.yahoo.com> Message-ID: <1808446895.222714.1516801110640@mail.yahoo.com> Hi, Are there any plans to support pop accesTokens where some kind of proof-of-possession is introduced to have a higher degree of security?As far as I know, there isn't yet a final standard (RFC) for this, only expired drafts, such as:-?https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08-?https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 -?https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 Would you consider implementing any of this or would you wait until a RFC is finally accepted as standard? Kind regards, Frederik From sthorger at redhat.com Wed Jan 24 13:41:55 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 24 Jan 2018 19:41:55 +0100 Subject: [keycloak-dev] per-client authentication flows In-Reply-To: References: <4c2cedd0-d452-96f5-b848-8fd6709d8a0f@redhat.com> Message-ID: I think using client templates makes sense as a way to introduce proper support for scopes, but not sure about retire/replace. Isn't client templates a useful concept to create some defaults for a client? On 24 January 2018 at 14:33, Bill Burke wrote: > I'll add a jira...but there's some things to think about for it. One > of the things on my plate is Client Scope support ala oauth scopes. > Was hoping to retire/replace client templates with client scopes and > not sure if flow overrides fit there if a client is composed of > multiple scopes. > > On Wed, Jan 24, 2018 at 6:07 AM, Marek Posolda > wrote: > > Bill, I've added few minor comments to your PR. > > > > Does it makes sense to support authentication flows per clientTemplate > too? > > Or is it just unnecessary complication? I wonder if it's similar to newly > > added themeSelector and thinking if we can have fallback chain like: > client > > -> clientTemplate -> realm . > > > > Marek > > > > > > > > On 22/01/18 19:21, Stian Thorgersen wrote: > >> > >> On 22 January 2018 at 16:17, Bill Burke wrote: > >> > >>> On Mon, Jan 22, 2018 at 2:48 AM, Stian Thorgersen > > >>> wrote: > >>>> > >>>> I missed the part about code grant flow being used regardless. Of > course > >>> > >>> the > >>>> > >>>> spec doesn't even mandate the user-agent is a web browser, just says > it > >>>> typically is. > >>>> > >>>> I think acr/display (or some other query parameter) vs a different > flow > >>>> boils down to usability. Basically is it simpler to have one "dynamic" > >>> > >>> flow > >>>> > >>>> or is it simpler to just have separate flows. I think in most cases > >>> > >>> you're > >>>> > >>>> right and it will probably be cleaner and simpler to simply have > >>> > >>> different > >>>> > >>>> flows. > >>>> > >>>> Did you think about including this new flow OOTB? Is it OSIN specific > or > >>> > >>> is > >>>> > >>>> it a generic non-web version of the regular web based flow? > >>>> > >>> I want to reorganize auth flows a bit so that we can catagorize them > >>> and provide a plugin mechanism so the admin console can dynamically > >>> show which flows can be configured (browser, direct grant, ecp, > >>> etc..). There's a lot to be done here, but probably just putting in > >>> enough at the moment to get the OSIN replacement going. > >>> > >>>> Another thing is the user-agent always controlled by the client? Or > >>> > >>> could a > >>>> > >>>> single client have different user-agents. > >>>> > >>> They don't really have that concept. There's a client config variable > >>> "respondWithChallenges". When set, server responds with 401 > >>> challenges. > >>> > >> I was also wondering if other (non OSIN) clients would want to use more > >> than one flow, but probably not. > >> > >> > >>> > >>> > >>> > >>> -- > >>> 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 sthorger at redhat.com Wed Jan 24 13:44:11 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 24 Jan 2018 19:44:11 +0100 Subject: [keycloak-dev] proof-of-possession In-Reply-To: <1808446895.222714.1516801110640@mail.yahoo.com> References: <1808446895.222714.1516801110640.ref@mail.yahoo.com> <1808446895.222714.1516801110640@mail.yahoo.com> Message-ID: We have quite a lot on our plate already so we probably won't be looking at that anytime soon. There's a crazy amount of these specs around. Can you write a quick summary on what it's about? Also, do you know what the status on it is? If it's an expired draft has it been abandoned? On 24 January 2018 at 14:38, Frederik Libert wrote: > Hi, > Are there any plans to support pop accesTokens where some kind of > proof-of-possession is introduced to have a higher degree of security?As > far as I know, there isn't yet a final standard (RFC) for this, only > expired drafts, such as:- https://tools.ietf.org/ > html/draft-ietf-oauth-pop-architecture-08- https:// > tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 > - https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 > Would you consider implementing any of this or would you wait until a RFC > is finally accepted as standard? > Kind regards, > Frederik > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Wed Jan 24 13:50:46 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 24 Jan 2018 19:50:46 +0100 Subject: [keycloak-dev] Wireframes for new account management console Message-ID: The UXD team has started the work on creating wireframes for the new account management console. Please take a look at https://redhat. invisionapp.com/share/FMFGF7AP37B#/274688541_Frame-Structure_ and provide some feedback if you have any. From hmlnarik at redhat.com Wed Jan 24 14:28:05 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 24 Jan 2018 20:28:05 +0100 Subject: [keycloak-dev] Wireframes for new account management console In-Reply-To: References: Message-ID: Seems to be broken for me, got: "PAGE NOT FOUND. The link you clicked may be broken or the page may have been removed." when clicking the link. On Wed, Jan 24, 2018 at 7:50 PM, Stian Thorgersen wrote: > The UXD team has started the work on creating wireframes for the new > account management console. Please take a look at https://redhat. > invisionapp.com/share/FMFGF7AP37B#/274688541_Frame-Structure_ and provide > some feedback if you have any. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- --Hynek From ssilvert at redhat.com Wed Jan 24 15:36:55 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 24 Jan 2018 15:36:55 -0500 Subject: [keycloak-dev] Wireframes for new account management console In-Reply-To: References: Message-ID: <573db1d3-3130-6488-fa68-4746af2e4b8c@redhat.com> On 1/24/2018 2:28 PM, Hynek Mlnarik wrote: > Seems to be broken for me, got: "PAGE NOT FOUND. The link you clicked may > be broken or the page may have been removed." when clicking the link. Working for me. Try this: https://redhat.invisionapp.com/share/FMFGF7AP37B#/screens/274688541 > > On Wed, Jan 24, 2018 at 7:50 PM, Stian Thorgersen > wrote: > >> The UXD team has started the work on creating wireframes for the new >> account management console. Please take a look at https://redhat. >> invisionapp.com/share/FMFGF7AP37B#/274688541_Frame-Structure_ and provide >> some feedback if you have any. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From hmlnarik at redhat.com Thu Jan 25 03:39:16 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Thu, 25 Jan 2018 09:39:16 +0100 Subject: [keycloak-dev] Wireframes for new account management console In-Reply-To: <573db1d3-3130-6488-fa68-4746af2e4b8c@redhat.com> References: <573db1d3-3130-6488-fa68-4746af2e4b8c@redhat.com> Message-ID: Interesting - Stan's link works for me, Stian's does not. The common part - https://redhat.invisionapp.com/share/FMFGF7AP37B - seems to be the main entrypoint which works for me. On Wed, Jan 24, 2018 at 9:36 PM, Stan Silvert wrote: > On 1/24/2018 2:28 PM, Hynek Mlnarik wrote: > > Seems to be broken for me, got: "PAGE NOT FOUND. The link you clicked may > > be broken or the page may have been removed." when clicking the link. > Working for me. Try this: > https://redhat.invisionapp.com/share/FMFGF7AP37B#/screens/274688541 > > > > On Wed, Jan 24, 2018 at 7:50 PM, Stian Thorgersen > > wrote: > > > >> The UXD team has started the work on creating wireframes for the new > >> account management console. Please take a look at https://redhat. > >> invisionapp.com/share/FMFGF7AP37B#/274688541_Frame-Structure_ and > provide > >> some feedback if you have any. > >> _______________________________________________ > >> 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 > -- --Hynek From sthorger at redhat.com Thu Jan 25 14:11:23 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 25 Jan 2018 20:11:23 +0100 Subject: [keycloak-dev] Release cadence Message-ID: Up until now we've released Keycloak roughly every 6 weeks. We're now switching to 3 week sprints, which opens up the possibility to change how frequently we release Keycloak. We could keep it at 6 weeks (release every other sprint), do a release every 3 weeks or release less frequently (9 weeks perhaps). Thoughts? From bruno at abstractj.org Thu Jan 25 14:16:41 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 25 Jan 2018 19:16:41 +0000 Subject: [keycloak-dev] Release cadence In-Reply-To: References: Message-ID: I'd vote to keep it at each 6 weeks until we master all the roads to kingdom of Agile. On Thu, Jan 25, 2018 at 5:11 PM Stian Thorgersen wrote: > Up until now we've released Keycloak roughly every 6 weeks. We're now > switching to 3 week sprints, which opens up the possibility to change how > frequently we release Keycloak. > > We could keep it at 6 weeks (release every other sprint), do a release > every 3 weeks or release less frequently (9 weeks perhaps). > > Thoughts? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Thu Jan 25 14:53:40 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 25 Jan 2018 20:53:40 +0100 Subject: [keycloak-dev] Metrics Endpoint In-Reply-To: References: <99BFD460-F7DC-4970-8703-DB66343BA71B@redhat.com> Message-ID: Would be good to have support for Prometheus. This is also information that would be good to display in the Keycloak admin console. I don't think using an event listener is the right approach though. One issue here is that this will only work for a single node and not in a cluster. The numbers should also be per-realm, not for all realms. A better option may be to add an MetricsSPI where the default provider would get the details from Keycloak itself. Useful details could be: * Number of active sessions - we can get this from counting number of open sessions (not sure if that will be a costly query to do as user sessions are stored in a distributed cache) * Number of failed logins - we can get this from events storage when enabled and it can be made configurable to only consider events for the last X days * Number of logins - same as above We could add a new endpoint /realms//metrics/. That would allow adding whatever provider for the format you want (i.e. prometheus). I don't think this info should be available publicly though so it has to be protected somehow. I'm also not to keen on using io.prometheus.client library for this if that can be avoided. We don't like having to maintain additional libraries and prefer to use things that are already available in EAP/WilldFly. On 22 January 2018 at 13:45, Matthias Wessendorf wrote: > On Mon, Jan 22, 2018 at 12:45 PM, Peter Braun wrote: > > > Hey everybody, > > > > we (the AeroGear/Mobile team) have created a SPI that adds a metrics > > endpoint to KeyCloak[1]. It?s inspired by a similar project named > > keycloak-metrics-prometheus[2] but does not require an extra service. > > Metrics data is based on internal events and is exposed in Prometheus > > format. > > > > Just wanted to share this with you since there are a number of tickets in > > the KeyCloak JIRA about a such an endpoint. We?re happy about any > > suggestions/opinions. We?re also open to an upstream contribution if the > > opportunity arises and you are interested. > > > > +1 for having this directly in Keycloak :-) > > > > > > > > > Regards, > > Peter > > > > [1] https://github.com/aerogear/keycloak-metrics-spi < > > https://github.com/aerogear/keycloak-metrics-spi> > > [2] https://github.com/larscheid-schmitzhermes/keycloak- > > monitoring-prometheus > schmitzhermes/keycloak-monitoring-prometheus> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > Matthias Wessendorf > > github: https://github.com/matzew > twitter: http://twitter.com/mwessendorf > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Thu Jan 25 17:01:00 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 25 Jan 2018 17:01:00 -0500 Subject: [keycloak-dev] Release cadence In-Reply-To: References: Message-ID: <98d65a6d-ec50-45c8-2a6e-23f9fb64ffd2@redhat.com> My Agile is extremely outdated, but I used to be very well versed in the ways of XP, the granddaddy of Agile. So if anything I say is outdated Agile thinking, let me know. Our build should be ready for release at any time. I think that's still an Agile principle? By definition, we should release at the end of each sprint. Otherwise, you are really doing a 6 week sprint instead of 3. The reason we release is to get feedback. So a sprint should only contain something that is useful and complete. And by complete, I mean it does something useful (circular logic, I know). If it's not ready to do something useful, you don't merge it. Just save it for the next sprint. But if you do a "pretend" sprint and then do a "release" sprint, you are really just doing a longer sprint with double the planning. Any developer will start to think in terms of things that can be completed in 6 weeks instead of 3. Plus, you have a delay in getting feedback. I personally don't care if we do 3 week sprints or 6 week sprints. But we shouldn't do a sprint without a release. BTW, open source methodology just says "release early and release often". Same concept, really. One more thing: Next week I'm attending a talk about how LinkedIn releases to production three times a day. Now that's extreme! On 1/25/2018 2:11 PM, Stian Thorgersen wrote: > Up until now we've released Keycloak roughly every 6 weeks. We're now > switching to 3 week sprints, which opens up the possibility to change how > frequently we release Keycloak. > > We could keep it at 6 weeks (release every other sprint), do a release > every 3 weeks or release less frequently (9 weeks perhaps). > > Thoughts? > _______________________________________________ > 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 Jan 25 18:07:34 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 26 Jan 2018 00:07:34 +0100 Subject: [keycloak-dev] Metrics Endpoint In-Reply-To: References: <99BFD460-F7DC-4970-8703-DB66343BA71B@redhat.com> Message-ID: A while ago I did a proposal for a dashboard page for the Keycloak admin console that build on such metrics: http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007266.html See also: https://issues.jboss.org/browse/KEYCLOAK-1840 Would be great to have such a metrics API that would also work in clustered scenarios. Cheers, Thomas 2018-01-25 20:53 GMT+01:00 Stian Thorgersen : > Would be good to have support for Prometheus. This is also information that > would be good to display in the Keycloak admin console. > > I don't think using an event listener is the right approach though. One > issue here is that this will only work for a single node and not in a > cluster. The numbers should also be per-realm, not for all realms. > > A better option may be to add an MetricsSPI where the default provider > would get the details from Keycloak itself. Useful details could be: > > * Number of active sessions - we can get this from counting number of open > sessions (not sure if that will be a costly query to do as user sessions > are stored in a distributed cache) > * Number of failed logins - we can get this from events storage when > enabled and it can be made configurable to only consider events for the > last X days > * Number of logins - same as above > > We could add a new endpoint /realms//metrics/. That > would allow adding whatever provider for the format you want (i.e. > prometheus). I don't think this info should be available publicly though so > it has to be protected somehow. > > I'm also not to keen on using io.prometheus.client library for this if that > can be avoided. We don't like having to maintain additional libraries and > prefer to use things that are already available in EAP/WilldFly. > > On 22 January 2018 at 13:45, Matthias Wessendorf > wrote: > > > On Mon, Jan 22, 2018 at 12:45 PM, Peter Braun wrote: > > > > > Hey everybody, > > > > > > we (the AeroGear/Mobile team) have created a SPI that adds a metrics > > > endpoint to KeyCloak[1]. It?s inspired by a similar project named > > > keycloak-metrics-prometheus[2] but does not require an extra service. > > > Metrics data is based on internal events and is exposed in Prometheus > > > format. > > > > > > Just wanted to share this with you since there are a number of tickets > in > > > the KeyCloak JIRA about a such an endpoint. We?re happy about any > > > suggestions/opinions. We?re also open to an upstream contribution if > the > > > opportunity arises and you are interested. > > > > > > > +1 for having this directly in Keycloak :-) > > > > > > > > > > > > > > > Regards, > > > Peter > > > > > > [1] https://github.com/aerogear/keycloak-metrics-spi < > > > https://github.com/aerogear/keycloak-metrics-spi> > > > [2] https://github.com/larscheid-schmitzhermes/keycloak- > > > monitoring-prometheus > > schmitzhermes/keycloak-monitoring-prometheus> > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > -- > > Matthias Wessendorf > > > > github: https://github.com/matzew > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > 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 srossillo at smartling.com Thu Jan 25 20:51:00 2018 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 26 Jan 2018 01:51:00 +0000 Subject: [keycloak-dev] Release cadence In-Reply-To: <98d65a6d-ec50-45c8-2a6e-23f9fb64ffd2@redhat.com> References: <98d65a6d-ec50-45c8-2a6e-23f9fb64ffd2@redhat.com> Message-ID: I don?t believe agile can be mastered. ;) IMO, for something like Keycloak, I think you should do CRs at the end of a development sprint and then do a release sprint for final versions. We release to prod multiple times a day. However, liked LinkedIn we?re a SAAS product. What works for SAAS doesn?t translate into a workable plan for installed, on premises software like Keycloak. On Thu, Jan 25, 2018 at 5:02 PM Stan Silvert wrote: > My Agile is extremely outdated, but I used to be very well versed in the > ways of XP, the granddaddy of Agile. So if anything I say is outdated > Agile thinking, let me know. > > Our build should be ready for release at any time. I think that's still > an Agile principle? > > By definition, we should release at the end of each sprint. Otherwise, > you are really doing a 6 week sprint instead of 3. > > The reason we release is to get feedback. So a sprint should only > contain something that is useful and complete. And by complete, I mean > it does something useful (circular logic, I know). If it's not ready to > do something useful, you don't merge it. Just save it for the next sprint. > > But if you do a "pretend" sprint and then do a "release" sprint, you are > really just doing a longer sprint with double the planning. Any > developer will start to think in terms of things that can be completed > in 6 weeks instead of 3. Plus, you have a delay in getting feedback. > > I personally don't care if we do 3 week sprints or 6 week sprints. But > we shouldn't do a sprint without a release. > > BTW, open source methodology just says "release early and release > often". Same concept, really. > > One more thing: Next week I'm attending a talk about how LinkedIn > releases to production three times a day. Now that's extreme! > > On 1/25/2018 2:11 PM, Stian Thorgersen wrote: > > Up until now we've released Keycloak roughly every 6 weeks. We're now > > switching to 3 week sprints, which opens up the possibility to change how > > frequently we release Keycloak. > > > > We could keep it at 6 weeks (release every other sprint), do a release > > every 3 weeks or release less frequently (9 weeks perhaps). > > > > Thoughts? > > _______________________________________________ > > 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 Fri Jan 26 00:35:03 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 26 Jan 2018 06:35:03 +0100 Subject: [keycloak-dev] Metrics Endpoint In-Reply-To: References: <99BFD460-F7DC-4970-8703-DB66343BA71B@redhat.com> Message-ID: I remember that. Would be cool to have this stuff. On 26 January 2018 at 00:07, Thomas Darimont wrote: > A while ago I did a proposal for a dashboard page for the Keycloak admin > console that build on such metrics: > http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007266.html > > See also: https://issues.jboss.org/browse/KEYCLOAK-1840 > > Would be great to have such a metrics API that would also work in > clustered scenarios. > > Cheers, > Thomas > > 2018-01-25 20:53 GMT+01:00 Stian Thorgersen : > >> Would be good to have support for Prometheus. This is also information >> that >> would be good to display in the Keycloak admin console. >> >> I don't think using an event listener is the right approach though. One >> issue here is that this will only work for a single node and not in a >> cluster. The numbers should also be per-realm, not for all realms. >> >> A better option may be to add an MetricsSPI where the default provider >> would get the details from Keycloak itself. Useful details could be: >> >> * Number of active sessions - we can get this from counting number of open >> sessions (not sure if that will be a costly query to do as user sessions >> are stored in a distributed cache) >> * Number of failed logins - we can get this from events storage when >> enabled and it can be made configurable to only consider events for the >> last X days >> * Number of logins - same as above >> >> We could add a new endpoint /realms//metrics/. That >> would allow adding whatever provider for the format you want (i.e. >> prometheus). I don't think this info should be available publicly though >> so >> it has to be protected somehow. >> >> I'm also not to keen on using io.prometheus.client library for this if >> that >> can be avoided. We don't like having to maintain additional libraries and >> prefer to use things that are already available in EAP/WilldFly. >> >> On 22 January 2018 at 13:45, Matthias Wessendorf >> wrote: >> >> > On Mon, Jan 22, 2018 at 12:45 PM, Peter Braun >> wrote: >> > >> > > Hey everybody, >> > > >> > > we (the AeroGear/Mobile team) have created a SPI that adds a metrics >> > > endpoint to KeyCloak[1]. It?s inspired by a similar project named >> > > keycloak-metrics-prometheus[2] but does not require an extra service. >> > > Metrics data is based on internal events and is exposed in Prometheus >> > > format. >> > > >> > > Just wanted to share this with you since there are a number of >> tickets in >> > > the KeyCloak JIRA about a such an endpoint. We?re happy about any >> > > suggestions/opinions. We?re also open to an upstream contribution if >> the >> > > opportunity arises and you are interested. >> > > >> > >> > +1 for having this directly in Keycloak :-) >> > >> > >> > >> > > >> > > >> > > Regards, >> > > Peter >> > > >> > > [1] https://github.com/aerogear/keycloak-metrics-spi < >> > > https://github.com/aerogear/keycloak-metrics-spi> >> > > [2] https://github.com/larscheid-schmitzhermes/keycloak- >> > > monitoring-prometheus > > > schmitzhermes/keycloak-monitoring-prometheus> >> > > _______________________________________________ >> > > keycloak-dev mailing list >> > > keycloak-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > github: https://github.com/matzew >> > twitter: http://twitter.com/mwessendorf >> > _______________________________________________ >> > 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 Fri Jan 26 03:33:21 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 26 Jan 2018 09:33:21 +0100 Subject: [keycloak-dev] A lot of unneeded files in themes common Message-ID: I took a stab at cleaning up the node_modules (not for account2) by adding a new profile to themes that can download packages from NPM. Then copy/filter these to the directory used to build the server. Benefits here: * Removes unneeded files from dist * Files included when running KeycloakServer is the same as in the dist (filtered) * All files/sources still checked in for RH-SSO * Folks don't have to run this to build You can try it out here: https://github.com/stianst/keycloak/tree/KEYCLOAK-6378 cd themes mvn -Pnpm-update clean install Unless you change the package.json you shouldn't see any files to commit afterwards. If you do there may be something with line encodings on Linux vs Windows that we need to address (we should be able to tweak that by adding a custom .gitattributes file in the node_modules dir). Login, account and admin seems to work just fine with all these files removed. There's probably more we can remove, but I think this is sufficient at least for now. From ssilvert at redhat.com Fri Jan 26 10:12:03 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 26 Jan 2018 10:12:03 -0500 Subject: [keycloak-dev] A lot of unneeded files in themes common In-Reply-To: References: Message-ID: <0df90d5f-e16a-0896-2fbe-3aba56f9f3a5@redhat.com> That's all good, but didn't we agree that we would wait for project Newcastle to complete their solution? It's probably time to find out where they are as they seemed to indicate that they were close last time we spoke. On 1/26/2018 3:33 AM, Stian Thorgersen wrote: > I took a stab at cleaning up the node_modules (not for account2) by adding > a new profile to themes that can download packages from NPM. Then > copy/filter these to the directory used to build the server. > > Benefits here: > > * Removes unneeded files from dist > * Files included when running KeycloakServer is the same as in the dist > (filtered) > * All files/sources still checked in for RH-SSO > * Folks don't have to run this to build > > You can try it out here: > https://github.com/stianst/keycloak/tree/KEYCLOAK-6378 > > cd themes > mvn -Pnpm-update clean install > > Unless you change the package.json you shouldn't see any files to commit > afterwards. If you do there may be something with line encodings on Linux > vs Windows that we need to address (we should be able to tweak that by > adding a custom .gitattributes file in the node_modules dir). > > Login, account and admin seems to work just fine with all these files > removed. There's probably more we can remove, but I think this is > sufficient at least for now. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Fri Jan 26 13:30:40 2018 From: bburke at redhat.com (Bill Burke) Date: Fri, 26 Jan 2018 13:30:40 -0500 Subject: [keycloak-dev] Initial Client Storage SPI Message-ID: As part of Openshift integration, I needed to implement a Client Storage SPI. Here are my plans for it: * It is a private SPI * Only read only support. * Only lookup support to facilitate client login and grants and stuff. Listing all clients will not show up in admin conosle * There will be no admin console support. This means, no admin console support for provider config. Providers can only be configured through REST API or realm import. * Basically it will be bare bones to support Openshift integration only. My plan is that Openshift support will be distributed as an extension to our base image and/or, it will be a template realm.json import file that users can edit. I just don't want to expose an unfinished SPI. I'll probably have a PR for review early next week. -- Bill Burke Red Hat From bburke at redhat.com Fri Jan 26 14:02:26 2018 From: bburke at redhat.com (Bill Burke) Date: Fri, 26 Jan 2018 14:02:26 -0500 Subject: [keycloak-dev] Initial Client Storage SPI In-Reply-To: References: Message-ID: A few more things: * Its implemented very similarly to UserStorage SPI. * It will not support client roles * It will not support node registration. On Fri, Jan 26, 2018 at 1:30 PM, Bill Burke wrote: > As part of Openshift integration, I needed to implement a Client > Storage SPI. Here are my plans for it: > > * It is a private SPI > * Only read only support. > * Only lookup support to facilitate client login and grants and stuff. > Listing all clients will not show up in admin conosle > * There will be no admin console support. This means, no admin > console support for provider config. Providers can only be configured > through REST API or realm import. > * Basically it will be bare bones to support Openshift integration only. > > My plan is that Openshift support will be distributed as an extension > to our base image and/or, it will be a template realm.json import file > that users can edit. I just don't want to expose an unfinished SPI. > > I'll probably have a PR for review early next week. > > -- > Bill Burke > Red Hat -- Bill Burke Red Hat From sthorger at redhat.com Mon Jan 29 02:15:11 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Jan 2018 08:15:11 +0100 Subject: [keycloak-dev] A lot of unneeded files in themes common In-Reply-To: <0df90d5f-e16a-0896-2fbe-3aba56f9f3a5@redhat.com> References: <0df90d5f-e16a-0896-2fbe-3aba56f9f3a5@redhat.com> Message-ID: Project Newcastle will only deal with storing source and NPM libraries. We still need to filter what's installed from NPM. If we incorporate the changes I made here all we'd need to do after PNC has been fixed is to stop committing the full unfiltered node_modules directory. On 26 January 2018 at 16:12, Stan Silvert wrote: > That's all good, but didn't we agree that we would wait for project > Newcastle to complete their solution? It's probably time to find out > where they are as they seemed to indicate that they were close last time > we spoke. > > On 1/26/2018 3:33 AM, Stian Thorgersen wrote: > > I took a stab at cleaning up the node_modules (not for account2) by > adding > > a new profile to themes that can download packages from NPM. Then > > copy/filter these to the directory used to build the server. > > > > Benefits here: > > > > * Removes unneeded files from dist > > * Files included when running KeycloakServer is the same as in the dist > > (filtered) > > * All files/sources still checked in for RH-SSO > > * Folks don't have to run this to build > > > > You can try it out here: > > https://github.com/stianst/keycloak/tree/KEYCLOAK-6378 > > > > cd themes > > mvn -Pnpm-update clean install > > > > Unless you change the package.json you shouldn't see any files to commit > > afterwards. If you do there may be something with line encodings on Linux > > vs Windows that we need to address (we should be able to tweak that by > > adding a custom .gitattributes file in the node_modules dir). > > > > Login, account and admin seems to work just fine with all these files > > removed. There's probably more we can remove, but I think this is > > sufficient at least for now. > > _______________________________________________ > > 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 Mon Jan 29 14:57:32 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Jan 2018 20:57:32 +0100 Subject: [keycloak-dev] Initial Client Storage SPI In-Reply-To: References: Message-ID: All makes sense to me. Would probably make sense to also add a JIRA to include what would be needed to make it into a fully supported feature. FIY 3Scale was also interested in this as they currently have clients created through their UI and then have to create/manage clients through the admin endpoints in the background when users change client config in their UI. On 26 January 2018 at 20:02, Bill Burke wrote: > A few more things: > > * Its implemented very similarly to UserStorage SPI. > * It will not support client roles > * It will not support node registration. > > > On Fri, Jan 26, 2018 at 1:30 PM, Bill Burke wrote: > > As part of Openshift integration, I needed to implement a Client > > Storage SPI. Here are my plans for it: > > > > * It is a private SPI > > * Only read only support. > > * Only lookup support to facilitate client login and grants and stuff. > > Listing all clients will not show up in admin conosle > > * There will be no admin console support. This means, no admin > > console support for provider config. Providers can only be configured > > through REST API or realm import. > > * Basically it will be bare bones to support Openshift integration only. > > > > My plan is that Openshift support will be distributed as an extension > > to our base image and/or, it will be a template realm.json import file > > that users can edit. I just don't want to expose an unfinished SPI. > > > > I'll probably have a PR for review early next week. > > > > -- > > Bill Burke > > Red Hat > > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon Jan 29 15:15:21 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 29 Jan 2018 15:15:21 -0500 Subject: [keycloak-dev] Initial Client Storage SPI In-Reply-To: References: Message-ID: Maybe I can work on that next. On Mon, Jan 29, 2018 at 2:57 PM, Stian Thorgersen wrote: > All makes sense to me. Would probably make sense to also add a JIRA to > include what would be needed to make it into a fully supported feature. > > FIY 3Scale was also interested in this as they currently have clients > created through their UI and then have to create/manage clients through the > admin endpoints in the background when users change client config in their > UI. > > On 26 January 2018 at 20:02, Bill Burke wrote: >> >> A few more things: >> >> * Its implemented very similarly to UserStorage SPI. >> * It will not support client roles >> * It will not support node registration. >> >> >> On Fri, Jan 26, 2018 at 1:30 PM, Bill Burke wrote: >> > As part of Openshift integration, I needed to implement a Client >> > Storage SPI. Here are my plans for it: >> > >> > * It is a private SPI >> > * Only read only support. >> > * Only lookup support to facilitate client login and grants and stuff. >> > Listing all clients will not show up in admin conosle >> > * There will be no admin console support. This means, no admin >> > console support for provider config. Providers can only be configured >> > through REST API or realm import. >> > * Basically it will be bare bones to support Openshift integration only. >> > >> > My plan is that Openshift support will be distributed as an extension >> > to our base image and/or, it will be a template realm.json import file >> > that users can edit. I just don't want to expose an unfinished SPI. >> > >> > I'll probably have a PR for review early next week. >> > >> > -- >> > Bill Burke >> > Red Hat >> >> >> >> -- >> 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 sthorger at redhat.com Tue Jan 30 06:49:37 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 30 Jan 2018 12:49:37 +0100 Subject: [keycloak-dev] Initial Client Storage SPI In-Reply-To: References: Message-ID: Could you elaborate on what PSD2 requires in addition to what Keycloak clients provide today? It may make sense to rather extend what the clients do today than to require using a custom SPI to store clients externally. On 29 January 2018 at 22:19, Francis Pouatcha wrote: > Bill, > > in Europe we are working on implementing the PSD2 regulation (Second > European Payment Service Directive). Implementation involves a lot of > interaction between API gateways and IdP and banking systems. Correct > implementation of PSD2 requires more than what the keycloak client > functionality exposes today. Therefore: > - having a Client Storage SPI is a great idea. > - making it read-only good for now > - making it public SPI might though be very helpful > > > /Francis > > On Mon, Jan 29, 2018 at 8:57 PM, Stian Thorgersen > wrote: > >> All makes sense to me. Would probably make sense to also add a JIRA to >> include what would be needed to make it into a fully supported feature. >> >> FIY 3Scale was also interested in this as they currently have clients >> created through their UI and then have to create/manage clients through >> the >> admin endpoints in the background when users change client config in their >> UI. >> >> On 26 January 2018 at 20:02, Bill Burke wrote: >> >> > A few more things: >> > >> > * Its implemented very similarly to UserStorage SPI. >> > * It will not support client roles >> > * It will not support node registration. >> > >> > >> > On Fri, Jan 26, 2018 at 1:30 PM, Bill Burke wrote: >> > > As part of Openshift integration, I needed to implement a Client >> > > Storage SPI. Here are my plans for it: >> > > >> > > * It is a private SPI >> > > * Only read only support. >> > > * Only lookup support to facilitate client login and grants and stuff. >> > > Listing all clients will not show up in admin conosle >> > > * There will be no admin console support. This means, no admin >> > > console support for provider config. Providers can only be configured >> > > through REST API or realm import. >> > > * Basically it will be bare bones to support Openshift integration >> only. >> > > >> > > My plan is that Openshift support will be distributed as an extension >> > > to our base image and/or, it will be a template realm.json import file >> > > that users can edit. I just don't want to expose an unfinished SPI. >> > > >> > > I'll probably have a PR for review early next week. >> > > >> > > -- >> > > Bill Burke >> > > Red Hat >> > >> > >> > >> > -- >> > 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 >> > > > > -- > > Francis Pouatcha > > Co-Founder and Technical Lead > > Email: fpo at adorsys.de > Cell USA: +1 770 329 7026 <(770)%20329-7026> > Cell Germany: +49 172 18 16 074 <+49%20172%201816074> > > adorsys GmbH & Co. KG > Bartholom?usstrasse 26c > > 90489 N?rnberg > > > Tel: 0911 360698-0 > Fax: 0911 360698-10 > E-Mail: info at adorsys.de > Internet: www.adorsys.de > > Gesch?ftsf?hrer: Francis Pouatcha, Stefan Hamm > HR A 15855, AG N?rnberg > > Komplement?r: > adorsys Verwaltungs GmbH > HR B 27343, AG N?rnberg >