Re: [keycloak-dev] [IAM] Cross-datacenter configuration issues

From: "Brian Atkisson" <batkisso(a)redhat.com&gt; To: "Marek Posolda" <mposolda(a)redhat.com&gt; Cc: "William Burns" <wburns(a)redhat.com&gt;, "Pedro Zapata Fernandez" <pzapataf(a)redhat.com&gt;, "iam-list" <iam-list(a)redhat.com&gt;, "keycloak-dev" <keycloak-dev(a)lists.jboss.org&gt;, "Hynek Mlnarik" <hmlnarik(a)redhat.com&gt;, "Tristan Tarrant" <ttarrant(a)redhat.com&gt;, "Boleslaw Dawidowicz" <bdawidow(a)redhat.com&gt;, mmccomas(a)redhat.com Sent: Friday, March 2, 2018 6:52:19 PM Subject: Re: [IAM] [keycloak-dev] Cross-datacenter configuration issues +Mike > On Mar 2, 2018, at 12:20 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > >> On 02/03/18 15:24, William Burns wrote: >>> (3) Use the approach, which works for me and which I put in JIRA. So >>> have 2 hotrod endpoints on JDG side (unsecured and secured). RemoteStore >>> access the unsecured endpoint. Just some sources, which deals with >>> __script cache, access the secured hotrod endpoint. This requires to >>> "patch" module keycloak-model-infinispan on RHSSO side and also require >>> some smaller changes in the configuration (some new configuration >>> properties are added on RHSSO side to allow configuration of hotrod >>> endpoint security, username ,password etc). >>> >>> (4) Bypass JDG security entirely with some picketbox "anonymous access" >>> JAAS login modules. I didn't manage to have it working and it completely >>> bypass security. On the other hand, it seems to be the only solution, >>> which won't require changes on Keycloak/RHSSO side. But we don't know >>> yet if it works... >> Actually there is another way to bypass security that Tristan brought up >> that we were was discussing. For JDG 7.2.CR1 we can relax access to >> protected caches, such as scriptcache, so that there is no global >> authorization check (removing a single if block). This way the cache >> just uses the normal authorization checks if it is even enabled for that >> cache. Unfortunately CR1 is not going to be available for another 3 weeks >> though. In the mean time Jared and I discussed just testing with >> community server version 8.2.8 for the standalone install until we can >> get JDG 7.2.CR1 installed there. He may even want to test with something >> a little newer. > Thanks for the update. > > If Jared is fine to temporarily test with Infinispan server 8.2.8, it's > cool. We will try to see if we can bypass security even for JDG 7.1 (Hynek > is looking into picketbox "anonymous" modules) and there is this patch > from me to secure access to "_script" cache, which works with 7.1, but > will require to patch Keycloak/RHSSO. > > I afraid we can officially update to JDG 7.2 at the moment, when 7.2.GA is > released. However it may be good to test early with 7.2, so we can find > earlier if some fixes are needed on JDG side and notify you before GA. > Hopefully we have time for trying that... :) > > > BTV. Will JDG 7.2 have better "pagination" support for RemoteCaches, so I > can do something like: > > remoteCache.keySet().stream().skip(100).limit(10).collect(Collectors.toList());

> > to ensure that just 10 items from 100 to 110 are sent over the network? And > will it have Server tasks support? If yes, we will be hopefully able to

> get rid of remote scripting entirely :) > > But problem is also "client" (Keycloak) side as we rely on the infinispan > version provided by Wildfly/EAP. In other words, we are always few months > (or years?) behind all the cool features and fixes, which you are > currently developing in infinispan master :(

> > Marek >> >> Unfortunately that means that this version of keycloak would only work >> with JDG 7.2.0.CR1 or ISPN 9.0.3 [1] and newer. Either way I will be >> creating a PR for this on the JDG 7.2 branch today. >> >> [1] https://issues.jboss.org/browse/ISPN-7814 >> >