[keycloak-user] adding realm level configuration parameter

Marek Posolda mposolda at redhat.com
Tue Jan 23 03:22:07 EST 2018 

Hi Dmitry,

It's interesting idea. But I think we're going to develop any more 
advanced global writable configuration just if it's needed for some 
built-in Keycloak features. And that's not the case now at this moment 
AFAIK. Maybe in the future...

On 22/01/18 21:42, Dmitry Telegin wrote:
> Hi Marek,
>
>> Hi,
>>
>> for anyone interested, we have possibility to add:
>> - custom REST endpoints if you need control your own realm attributes
>> - custom DB entities if you want custom entities, which are possibly not
>> tightly coupled to any realm (EG. global entities).
>> - custom SPI / providers. You may configure global settings in
>> standalone(-ha).xml at subsystem level with that.
>
> Some time ago I've proposed a solution for global writable 
> (persistent) config, based on Apache Commons Configuration: 
> http://lists.jboss.org/pipermail/keycloak-dev/2017-December/010261.html
>
> The message seemingly went unnoticed; could you please share your 
> thoughts on that? This will be opensourced, but will also benefit a 
> lot from inclusion into upstream Keycloak (if it's decided it's worth 
> that).
I am not sure exactly about all the requirements you have for the 
use-case. I would (maybe) try one of the following:

- Use the global configuration at keycloak subsystem in standalone.xml 
(EG. you can see "scheduled-task-interval" or the configuration under 
"theme" element). You mentioned it's not sufficient for you, but for us 
it's ok ATM.
- You can use some custom Component configured at "master" realm level 
as a way for global storage
- You can use infinispan cache as a storage. This supports some things 
you mentioned like: events+notifications, persistent Cache stores (to 
backup data to JDBC or File if needed) etc. It's editable (if you do 
custom REST endpoint to CRUD the data) etc.

>
>> There is an example for all those functionalities. In the "providers"
>> directory of keycloak-examples distribution, there is "domain-extension"
>> . Some docs is in "Server development guide".
>
> Unfortunately, the "domain-extension" example is borked and is not 
> going to be fixed anytime soon 
> https://issues.jboss.org/browse/KEYCLOAK-5927
You reported the bug and you know where the issue is. Cool. Maybe you 
could also send PR to fix it? :)
>
> I'd rather recommend (not surprisingly ;) my own BeerCloak example, 
> which is 100% working and maintained 
> https://github.com/dteleguin/beercloak
>
> In fact, I see it not as a mere example, but a kind of unofficial 
> blueprint for real-world Keycloak extensions. Can we publicize it 
> somehow? Guys who stumble upon it find it very useful, but the only 
> way to "stumble upon it" is browsing this very mailing list :)
Yes, we can maybe have some page like "community maintained 
contributions" or something like that. The issue is, that those 
examples/extensions can become outdated when the maintainer from the 
community loses interest. There are both advantages and disadvantages of it.

Marek
>
> Cheers,
> Dmitry
>
>
>> Marek
>>
>> On 22/01/18 13:06, Ori Doolman wrote:
>>> Hi Dmitry, Thank you very much for your answer. 1) I assume that 
>>> ‘realm_attribute’ table has no control from the Web UI admin 
>>> console. Does it? 2) How did you implement the global 
>>> configurqation? Thanks, Ori From: Dmitry Telegin 
>>> [mailto:mitya at cargosoft.ru] Sent: Monday, January 22, 2018 13:03 To: 
>>> Ori Doolman <Ori.Doolman at Amdocs.com 
>>> <mailto:Ori.Doolman at Amdocs.com>>; keycloak-user at lists.jboss.org 
>>> <mailto:keycloak-user at lists.jboss.org> Subject: Re: [keycloak-user] 
>>> adding realm level configuration parameter Hi Ori, In Keycloak, 
>>> realms do have their own attributes. Starting with 2.2.0, they are 
>>> exposed as org.keycloak.models.RealmModel::{get,set}Attribute*() 
>>> methods, so I suggest that you take a look at them. Seems like 
>>> exactly what you need - just make sure your attribute names do not 
>>> clash with internal ones (examine realm_attribute table contents for 
>>> that). It will be pretty safe to prefix your attribute names with 
>>> something unique, like "com.amdocs.*" If you need truly *global* 
>>> persistent configuration (i.e. not bound to any realm), 
>>> unfortunately there's no such functionality in KC at the moment, but 
>>> I'm implementing the same for my company's needs. Let me know if 
>>> you're interested. Cheers, Dmitry Hi, Any answer on that?? Thanks, 
>>> Ori . -----Original Message----- From: 
>>> keycloak-user-bounces at lists.jboss.org 
>>> <mailto:keycloak-user-bounces at lists.jboss.org><mailto:keycloak-user-bounces at lists.jboss.org> 
>>> [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Ori 
>>> Doolman Sent: Tuesday, January 16, 2018 00:00 To: 
>>> keycloak-user at lists.jboss.org 
>>> <mailto:keycloak-user at lists.jboss.org><mailto:keycloak-user at lists.jboss.org> 
>>> Subject: [keycloak-user] adding realm level configuration parameter 
>>> Hi, I want to perform some customization to Keycloak using existing 
>>> SPIs. For that, I need to store a configuration parameter (may be 
>>> different value per realm). What is the way to achieve that? Is 
>>> there an SPI to extend the realm properties? The only solution I can 
>>> think of now is setting a custom attribute in the users group of the 
>>> realm. Thanks, Ori Doolman Lead Software Architect Amdocs Optima 
>>> +972 9 778 6914 (office) +972 50 9111442 (mobile) 
>>> [cid:image001.png at 01D2C8DE.BFF33E10 
>>> <mailto:image001.png at 01D2C8DE.BFF33E10><mailto:image001.png at 01D2C8DE.BFF33E10>] 
>>> This message and the information contained herein is proprietary and 
>>> confidential and subject to the Amdocs policy statement, you may 
>>> review at https://www.amdocs.com/about/email-disclaimer 
>>> <https://www.amdocs.com/about/email-disclaimer> This message and the 
>>> information contained herein is proprietary and confidential and 
>>> subject to the Amdocs policy statement, you may review at 
>>> https://www.amdocs.com/about/email-disclaimer 
>>> <https://www.amdocs.com/about/email-disclaimer> 
>>> _______________________________________________ keycloak-user 
>>> mailing list keycloak-user at lists.jboss.org 
>>> <mailto:keycloak-user at lists.jboss.org><mailto:keycloak-user at lists.jboss.org> 
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user This message 
>>> and the information contained herein is proprietary and confidential 
>>> and subject to the Amdocs policy statement, you may review at 
>>> https://www.amdocs.com/about/email-disclaimer 
>>> <https://www.amdocs.com/about/email-disclaimer> 
>>> _______________________________________________ keycloak-user 
>>> mailing list keycloak-user at lists.jboss.org 
>>> <mailto:keycloak-user at lists.jboss.org> 
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user 
>>
>>
>>

More information about the keycloak-user mailing list