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

Stian Thorgersen stian at redhat.com
Mon Oct 13 03:59:26 EDT 2014


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
> 


More information about the keycloak-dev mailing list