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

[Stian Thorgersen]

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 at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> >> To: "Marek Posolda" <mposolda at redhat.com>
> >> Cc: keycloak-dev at 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 at redhat.com>
> >>> To: keycloak-dev at 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 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
> >>
> 
>