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

[Marek Posolda]

I've created JIRA with some additional details about this: 
https://issues.jboss.org/browse/KEYCLOAK-759 and I am working on it. 
Feel free to add more thoughts.

Marek

On 15.10.2014 13:36, Stian Thorgersen wrote:
> 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
>>>>
>>