Re: [keycloak-dev] Is it ok to support multiple managementUrls per application?

We need to do something better than requiring users to manually register/unregister nodes with Keycloak. That's just to clunky if you ask me. What about adding an option where nodes self-register? Nodes could authenticate with the client credentials to be allowed to register. We could also require adapters to "re-register" after a certain amount of time so we don't end up with a bunch of dead nodes. There might be something already in the OpenID Connect Dynamic Registration spec for this. Worth looking at that before we do anything. ----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 15 October, 2014 12:17:08 PM > Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls per application? > > That's an option, but it would require that adapters would need to be > aware of that and have support for jgroups/jms/infinispan ? Perhaps we > can add sender/receiver SPI for that? > > I know that having more managementUrls is not ideal solution and have > many pitfalls as you mentioned:-\ However it doesn't have any further > requirements on adapters (like being capable to receive jgroups/jms > message). I think that many adapters might want to rely just on > sticky-session provided by LB and don't want to have any additional > communication among each other. So setup with more managementUrls might > be still the best option for some deployments. > > I am not sure tbh. Maybe for Beta-1 we can keep just multiple > managementUrls and add sender/receiver SPI with possibility for > jgroups/jms to Beta-2 ? > > Marek > > On 14.10.2014 19:49, Stian Thorgersen wrote: >> Would it be an idea to add more options on how admin events are delivered? >> We could for example add jgroups and jms. Either of those would be more >> efficient in a cluster and wouldn't require managing nodes. >> >> ----- Original Message ----- >>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> To: "Marek Posolda" <mposolda(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Monday, 13 October, 2014 9:59:26 AM >>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls >>> per application? >>> >>> Adding multiple management URLs to an application is going to be >>> cumbersome >>> to maintain. It would require manually registering/unregistering nodes >>> with >>> Keycloak. >>> >>> WildFly for example automatically detects cluster members, and add/removes >>> nodes to Apache. Introducing KC would then add a cumbersome manual >>> registration process. Even worse with automatic provisioning of nodes it >>> simply won't work (think cloud). >>> >>> Another issue is that we'd have to deal with making sure new nodes and >>> temporarily unavailable nodes retrieve the updates as well. We probably >>> need >>> to improve on this in either case, a single node can also be temporarily >>> unavailable (and miss notBefore or logout notifications), but doing it for >>> a >>> cluster is harder than for a single node. >>> >>> There's also the use-case when KC and applications are on different >>> subnets >>> where only the load balancer is visible to Keycloak. >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >>>> To: keycloak-dev(a)lists.jboss.org >>>> Sent: Friday, 10 October, 2014 5:08:44 PM >>>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls >>>> per >>>> application? >>>> >>>> On 10.10.2014 17:07, Marek Posolda wrote: >>>>> The problem I am looking at is sending "Push NotBefore" from keycloak >>>>> to adapters in cluster. Basically the info about push notBefore should >>>>> be propagated to all cluster nodes where application is deployed. >>>>> >>>>> ATM I am seeing 2 possibilities: >>>>> >>>>> a) More managementUrls per ApplicationModel. People would need to >>>>> configure all nodes where adapter is deployed . Then Keycloak ( >>>>> ResourceAdminManager ) will be able to send "global" events like >>>>> pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will >>>>> be sent just to single node like now . >>>>> >>>>> b) Ensure that notBefore can be replicated on adapters side. I don't >>>>> like this tbh. It requires adapters to be in replicated cluster, which >>>>> may not be an option for many deployments, who want to rely just on >>>>> sticky session. >>>>> >>>>> Any of those is not super-ideal, but I don't have better idea to >>>>> ensure cluster-safe propagation of NotBefore and global logout to all >>>>> cluster nodes. >>>>> >>>>> Better ideas? >>>>> >>>>> I have (b) already prototyped and working, but wanted to have ack from >>>>> you before go further, cleanup, start changing admin console etc. >>>> oops, sorry. I have (a) working (model change to support multiple >>>> managementUrls) >>>>> Marek >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >