<div dir="ltr">Adding list back..<div><br></div><div>I don&#39;t see much value in a solution that doesn&#39;t also consider changes done directly through admin console and/or admin endpoints. A proper solution would use something along the lines of Liquibase/Git to have all changes versioned and applied serially. That way they can be reproduced fully.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 June 2016 at 21:03, Jesse Chahal <span dir="ltr">&lt;<a href="mailto:jessec@stytch.com" target="_blank">jessec@stytch.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve been thinking about this problem for awhile and so far the<br>
solutions that I come up with all require that keycloak keeps tracks<br>
of changes in a database table (exactly how it works for liquibase).<br>
The GUI has a partial import feature. I haven&#39;t used it too<br>
extensively but I believe it probably does some sort of JSONtoPOJO<br>
serialization in order to figure out what the partial update it needs<br>
to be doing. Maybe we could add unique id identifiers to the<br>
existing/exported JSON files and have keycloaks import features<br>
determine whether the JSON file had already been applied or not. If<br>
there is a rest api for this as well then building an external cli or<br>
GUI tool would be much more feasible. Scott&#39;s solution requires either<br>
the external app to know the state of keycloak or keycloak&#39;s state to<br>
be blank. Its the best that could have been done with keycloak as it<br>
is now. Anyone have any comments regarding this possible solution?<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, May 26, 2016 at 11:19 PM, Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>&gt; wrote:<br>
&gt; Can you give me some examples of issues around Dockerized deployments and<br>
&gt; services that are located at runtime (do you mean services that are<br>
&gt; provisioned at runtime?)?<br>
&gt;<br>
&gt; On 26 May 2016 at 19:47, Scott Rossillo &lt;<a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Stian, that’s fair, it does solve the OP&#39;s CI/CD problem when moving in<br>
&gt;&gt; the dev -&gt; stage -&gt; prod direction.<br>
&gt;&gt;<br>
&gt;&gt; Scott Rossillo<br>
&gt;&gt; Smartling | Senior Software Engineer<br>
&gt;&gt; <a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a><br>
&gt;&gt;<br>
&gt;&gt; On May 26, 2016, at 1:41 PM, Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 26 May 2016 at 19:11, Scott Rossillo &lt;<a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I guess it’s a matter of requirements, but with micro service<br>
&gt;&gt;&gt; architectures there’s usually some sort of discovery mechanism required to<br>
&gt;&gt;&gt; locale services at runtime. Netflix offers Eureka and then there’s etcd from<br>
&gt;&gt;&gt; CoreOS that’s being used by Kubernetes. My point is that even if Keycloak<br>
&gt;&gt;&gt; devs build some sort of way of picking up changes from the filesystem on<br>
&gt;&gt;&gt; startup, that doesn’t solve all use cases.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The problem is continuous integration right, and pushing changes from a<br>
&gt;&gt; test environment into production? So you need a reliable way to apply<br>
&gt;&gt; changes to both environments.<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It doesn’t solve issues with Dockerized deployments and it doesn’t solve<br>
&gt;&gt;&gt; the issue where services have to be located at runtime<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; What are the issues it doesn&#39;t solve?<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Scott Rossillo<br>
&gt;&gt;&gt; Smartling | Senior Software Engineer<br>
&gt;&gt;&gt; <a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On May 26, 2016, at 2:27 AM, Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 26 May 2016 at 02:15, Jesse Chahal &lt;<a href="mailto:jessec@stytch.com">jessec@stytch.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; @Stian<br>
&gt;&gt;&gt;&gt; The approach described sounds similar to liquibase to me but with json<br>
&gt;&gt;&gt;&gt; and specific to keycloak. I feel like a lot of possible bugs could<br>
&gt;&gt;&gt;&gt; arise from this approach or at least quite a few feature requests.<br>
&gt;&gt;&gt;&gt; Would each json file only contain a single change? Would order matter<br>
&gt;&gt;&gt;&gt; in how they get applied if you put a bunch of json files in this<br>
&gt;&gt;&gt;&gt; directory at once? Can the same file be applied multiple times? These<br>
&gt;&gt;&gt;&gt; are the kind of issues I would expect to come up with this type of<br>
&gt;&gt;&gt;&gt; change management system. When I mentioned write our own tool/script<br>
&gt;&gt;&gt;&gt; to do it I was kind of thinking of a writing a liquibase like system<br>
&gt;&gt;&gt;&gt; that calls keycloak&#39;s rest api.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; We haven&#39;t figured out all the details, but what you are proposing sounds<br>
&gt;&gt;&gt; better. A single document that lists all changes, that can also import other<br>
&gt;&gt;&gt; files, sorts out the ordering and we could add same type of ids as Liquibase<br>
&gt;&gt;&gt; does to changesets.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; You could write it to use the rest api, then use a separate db to store<br>
&gt;&gt;&gt; what changes have been applied, but would be better if Keycloak deals with<br>
&gt;&gt;&gt; loading the changes directly as it can write to the db what changes have<br>
&gt;&gt;&gt; been applied.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; One big issue is what happens if manual changes are done through the<br>
&gt;&gt;&gt; admin console. One though (although probably very tricky to get right) is<br>
&gt;&gt;&gt; that changes done through the admin console is added to the changeset.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; @ Scott<br>
&gt;&gt;&gt;&gt; If I would compare the solution you mentioned to one of the options I<br>
&gt;&gt;&gt;&gt; listed in my original question  &quot;I&#39;ve also considered writing my own<br>
&gt;&gt;&gt;&gt; updater tool using a scripting language (python/ruby) that calls<br>
&gt;&gt;&gt;&gt; keycloak&#39;s rest api.&quot; The worrying thing to me is that there is<br>
&gt;&gt;&gt;&gt; another piece of code that needs to maintained by our company and<br>
&gt;&gt;&gt;&gt; requires quite a bit of knowledge of keycloak&#39;s rest api. There would<br>
&gt;&gt;&gt;&gt; probably need to be some serious thought put into the architecture of<br>
&gt;&gt;&gt;&gt; the tool as well. Without a doubt it does provide the most control. We<br>
&gt;&gt;&gt;&gt; also live by a different methodology in regards to updating production<br>
&gt;&gt;&gt;&gt; clusters. From our perspective it is more of an issue to update<br>
&gt;&gt;&gt;&gt; manually as it becomes much easier to miss a step or in someway screw<br>
&gt;&gt;&gt;&gt; up if steps are performed manually. I&#39;m not sure what the security<br>
&gt;&gt;&gt;&gt; implications would be from it occurring automatically, especially if<br>
&gt;&gt;&gt;&gt; during each step there is thorough testing (including from a security<br>
&gt;&gt;&gt;&gt; team). For our CI/CD pipeline our goal is to have it so every commit<br>
&gt;&gt;&gt;&gt; can automagically end up on production without human intervention.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Currently we use a combination of an initial realm file to be included<br>
&gt;&gt;&gt;&gt; on startup and also use jq to modify the keycloak-server.json for new<br>
&gt;&gt;&gt;&gt; keycloak clusters. We don&#39;t need to generate realm or client keys as<br>
&gt;&gt;&gt;&gt; it is included in the initial realm file. That doesn&#39;t work for<br>
&gt;&gt;&gt;&gt; existing systems backed by a database that cannot be thrown away. That<br>
&gt;&gt;&gt;&gt; kind of leave me with the original option (and hardest) of &quot;write a<br>
&gt;&gt;&gt;&gt; proprietary liquibase like system built ontop of keycloaks rest api&quot;.<br>
&gt;&gt;&gt;&gt; This is a hard problem to solve<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Why proprietary? If we can agree on a design we&#39;ll happily accept a<br>
&gt;&gt;&gt; contribution and maintain it as well.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer &lt;<a href="mailto:anthony.fryer@gmail.com">anthony.fryer@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt; Thanks, I&#39;ll check it out.<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt; On 05:38, Tue, 24/05/2016 Scott Rossillo &lt;<a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; We use Jose4J[0] to create the keys and then jq[1] to modify the<br>
&gt;&gt;&gt;&gt; &gt;&gt; realm<br>
&gt;&gt;&gt;&gt; &gt;&gt; file.<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;  See the first line of code here for a super simple example of how to<br>
&gt;&gt;&gt;&gt; &gt;&gt; generate realm keys:<br>
&gt;&gt;&gt;&gt; &gt;&gt; <a href="https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples" rel="noreferrer" target="_blank">https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; PS - this may be doable with Keycloak but Jose4J is very lightweight<br>
&gt;&gt;&gt;&gt; &gt;&gt; for<br>
&gt;&gt;&gt;&gt; &gt;&gt; writing a simple script on a CI server.<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; [0]: <a href="https://bitbucket.org/b_c/jose4j" rel="noreferrer" target="_blank">https://bitbucket.org/b_c/jose4j</a><br>
&gt;&gt;&gt;&gt; &gt;&gt; [1]: <a href="https://stedolan.github.io/jq/" rel="noreferrer" target="_blank">https://stedolan.github.io/jq/</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; Scott Rossillo<br>
&gt;&gt;&gt;&gt; &gt;&gt; Smartling | Senior Software Engineer<br>
&gt;&gt;&gt;&gt; &gt;&gt; <a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; On May 21, 2016, at 10:20 PM, Anthony Fryer &lt;<a href="mailto:anthony.fryer@gmail.com">anthony.fryer@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; Hi Scott,<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; How do you generate the realm keys when creating the new keycloak dev<br>
&gt;&gt;&gt;&gt; &gt;&gt; instances?  Do you use a keycloak api or some other way?  I&#39;m<br>
&gt;&gt;&gt;&gt; &gt;&gt; interested in<br>
&gt;&gt;&gt;&gt; &gt;&gt; having a standard realm template that is used to create new realms<br>
&gt;&gt;&gt;&gt; &gt;&gt; but would<br>
&gt;&gt;&gt;&gt; &gt;&gt; need to change the realm keys when importing this template into<br>
&gt;&gt;&gt;&gt; &gt;&gt; keycloak.<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; Cheers,<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; Anthony<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo<br>
&gt;&gt;&gt;&gt; &gt;&gt; &lt;<a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; We’re using Keycloak on production, stage/QA, development<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; environments<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; and every developer’s workstation / laptop.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; While there will always be differing options on how to successfully<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; do<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; change management, we’ve found a very effective method for handling<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Keycloak<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; provisioning in all environments so that developers don’t need to<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; mess<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; around with. We’re a continuous integration / deployment shop using<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; micro<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; services and everything has to “just work” … I’ll give an overview<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; of our<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; process here but please keep in mind a few things:<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; 1. This approach works for us, I’m not saying it’s the best way<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; 2. We do _not_ allow production config changes to be automated due<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; to<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; security implications<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; 3. We&#39;re very opinionated in our approach to configuration<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; management and<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; we don’t ever modify 3rd party software databases directly. We<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; always use<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; APIs.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; We deploy Keycloak to all environments using Docker images. On<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; developer<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; workstations we use Docker Compose to orchestrate bringing up all<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; services a<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; developer may need, including Keycloak.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; We have 4 docker images for Keycloak:<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; - Keycloak Base<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;    \- Keycloak HA<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;    \- Keycloak Dev<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; - Keycloak config manager*<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; The base image includes all customizations necessary to bring up a<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Keycloak instance configured with our modules and themes installed.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; The HA instance builds off base and configures Keycloak to run as a<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; cluster node. This is used on stage and prod.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; The dev instance builds off base and includes our realm file. On<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; startup,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; this instance loads our realm configuration if it’s not already<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; loaded.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; All docker images are built and published by the CI server and<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Keycloak<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; HA can be deployed to stage and prod after a clean CI build.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Developers are free to add clients for testing, do whatever they<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; want,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; etc. to their running dev instance. If they want to get back to our<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; stock<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; build, they pull the latest Docker image from our private Docker<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; repo and<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; restart it.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Adding clients to stage and prod requires approval and is done by a<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; hand.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; This is for security reasons. Once a configuration change is<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; detected on<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; stage - say a client is added - our CI server exports the realm from<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; stage,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; changes the realm keys, and creates a new Keycloak Dev instance with<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; the<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; updated realm file.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; *A word about configuration management:<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Obviously, the realm file we generate knows the URLs of staging<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; services,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; not local or development environment URLs. To overcome this we<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; introduced<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; another Docker based service called the Keycloak configuration<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; manger. It<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; runs on development environments and workstations. It’s responsible<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; for<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; discovering running services and updating Keycloak via its admin<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; endpoints<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; to reflect the proper configuration for the given environment.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; That’s it. The whole process is automated with the exception of<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; configuration changes to stage and prod which require a security<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; review.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Hope this helps. Let me know if you’d like me to elaborate on<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; anything.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Best,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Scott<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Scott Rossillo<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Smartling | Senior Software Engineer<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a href="mailto:srossillo@smartling.com">srossillo@smartling.com</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; On May 20, 2016, at 1:46 AM, Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; Firstly, just wanted to highlight that core Keycloak team are devs,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; not<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; sysadmins/ops guys, so we have limited experience in continuous<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; delivery and<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; maintenance of real production systems. Hence, we&#39;d love input from<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; the<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; community on this.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; As it stands we don&#39;t really have a proper solution. I believe the<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; best<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; you can do at the moment is either using import feature, partial<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; import or<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; admin rest endpoints. Import is not going to work IMO as it requires<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; re-creating the whole realm. Partial import may work, but would work<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; best<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; for new resources rather than modifying existing resources as it<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; does a<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; delete/create operation rather than attempt to modify. With the<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; admin rest<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; endpoints you&#39;d get the best control of what&#39;s going on, but<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; obviously that<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; leaves a fair amount of the work.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; In the future we have an idea of introducing an &quot;import directory&quot;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; it<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; would be possible to drop json files in here that would add, modify<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; or<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; delete resources (realms, clients, roles, users, whatever). This<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; would allow<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; dropping json files before the server starts and the server would<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; then<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; import on startup. It would also be possible to do this at runtime<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; and new<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; files would be detected at runtime. Finally, we also had an idea of<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; an<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; offline mode to run import of this (it would basically start the<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; server<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; without http listener, import files, then stop, so it could be used<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; in a<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; script/tool). Import is probably not the best name for it, as it<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; would<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; support modify and delete as well as &quot;importing&quot; new things.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; On 19 May 2016 at 19:53, Jesse Chahal &lt;<a href="mailto:jessec@stytch.com">jessec@stytch.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; Following some of the best practices for continuous Integration and<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; continuous delivery there needs to be environments for build, test,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; and production. This would mean that following these practices<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; would<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; require you to have multiple versions of keycloak at different<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; stages<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; of development cycle. Some of these environments might not have<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; important persistent data while others might. In order to have<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; builds<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; transition from one environment to another there may be<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; configuration<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; changes required for a build to be valid. This is especially true<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; when<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; new services (openid clients) are being added or &quot;default&quot;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; accounts.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; I&#39;m trying to come up with a scripted way of updating keycloak<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; instances that are backed up by an RDMS. This may include adding<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; new<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; clients, adding new users, updating realm config, etc... Originally<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; I<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; was planning on simply exporting the realm config and importing it<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; every time keycloak starts. If I enabled the OVERWRITE option I<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; might<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; overwrite things that I do not want overridden. This is especially<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; true if there is some config that differ&#39;s based on whether it is a<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; build, test, or production instance. If I don&#39;t enable it then it<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; is<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; only useful for new/blank keycloak environments. I considered using<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; liquibase but since I do not have control of schema changes created<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; by<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; the keycloak team I might run into issues with my liquibase file<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; not<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; being valid after a migration/liquibase update by the keycloak team<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; as<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; my liquibase file would run after keycloak&#39;s does. There might also<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; be<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; some other unknown issues our liquibase changes conflicting somehow<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; with keycloak&#39;s liquibase changes. I&#39;ve also considered writing my<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; own<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; updater tool using a scripting language (python/ruby) that calls<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; keycloak&#39;s rest api. The issues with this mechanism is it feels<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; like I<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; am recreating the wheel as well as not being able to find good<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; documentation on keycloak&#39;s openid endpoints/url&#39;s used for<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; different<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; oauth2 flows. Even if I did find this documentation it would also<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; require me to find a good openid client for the scripting language.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; This doesn&#39;t matter for our normal clients as they simply use the<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; keycloak subsystems and adapters instead. I&#39;ve also looked at<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; commonly<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; used server configuration software such as chef, puppet, and<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; ansible.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; I don&#39;t see a good solution using any of those tools yet either.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; What<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; have other people done for cases like this? Please don&#39;t tell me<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; there<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; is someone who is doing this all manually because that doesn&#39;t work<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; in<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; modern software development.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; - doesn&#39;t accidentally delete users<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; - doesn&#39;t accidentally delete clients<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; - doesn&#39;t invalidate sessions (optional)<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; - works to bring up new, correctly configured, keycloak instances<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; - handles applying updates to existing keycloak instances<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; - can handle minor differences between keycloak instances (build,<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; test, production) when updating<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; - preferably can work well in rolling deployment scenario&#39;s.<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; -- I hope the keycloak team is taking these into consideration when<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; doing database migration between 1-2 releases. It would be nice if<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; they set some specific rules for rolling updates between versions<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; (aka<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; backwards breaking changes)<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; keycloak-user mailing list<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; keycloak-user mailing list<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; keycloak-user mailing list<br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>