1:36 p.m.
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>
To: "Stian Thorgersen" <stian(a)redhat.com>
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>
>> To: "Marek Posolda" <mposolda(a)redhat.com>
>> 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>
>>> 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
>>