[keycloak-dev] Preferred storage mechanism for custom settings
Stian Thorgersen
sthorger at redhat.com
Wed Aug 17 03:44:43 EDT 2016
Take a look at ClientAdapter/ClientEntity. The ClientEntity for Mongo just
returns the list, while the ClientAdapter does the rest.
On 16 August 2016 at 21:06, Dmitry Telegin <mitya at cargosoft.ru> wrote:
> Hi,
>
> I've started implementing attributes for Mongo. I've begun with adding
> attribute methods to org.keycloak.models.entities.RealmEntity (base class
> for MongoRealmEntity), but ended up with the following:
>
> java.lang.IllegalArgumentException: Invalid accessor method, must have zero arguments if starts with 'get'. Method: public java.lang.String org.keycloak.models.entities.RealmEntity.getAttribute(java.lang.String)
>
> at org.keycloak.models.utils.reflection.MethodPropertyImpl.<init>(MethodPropertyImpl.java:53)
>
> at org.keycloak.models.utils.reflection.Properties.createProperty(Properties.java:44)
>
> at org.keycloak.models.utils.reflection.PropertyQuery.getResultList(PropertyQuery.java:168)
>
> at org.keycloak.models.utils.reflection.PropertyQuery.getWritableResultList(PropertyQuery.java:140)
>
> at org.keycloak.connections.mongo.impl.MongoStoreImpl.getEntityInfo(MongoStoreImpl.java:433)
>
> at org.keycloak.connections.mongo.impl.MongoStoreImpl.<init>(MongoStoreImpl.java:101)
>
> at org.keycloak.connections.mongo.DefaultMongoConnectionFactoryProvider.lazyInit(DefaultMongoConnectionFactoryProvider.java:156)
>
>
> Seems like KeyCloak's query system doesn't like entities with
> pseudo-getter methods. Any suggestions?
>
> Dmitry
>
> Sounds like you're on the right track. You'd need to implement support for
> Mongo as well though as we can't accept it otherwise.
>
> With regards to tests I'd add to org.keycloak.testsuite.admin.realm.RealmTest
> which would also make sure attributes work correctly when added through the
> admin endpoints.
>
> On 13 August 2016 at 16:47, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>
> Hi,
>
> (As Stian is on vacation now, I'd appreciate if someone other helps me
> with this feature.)
>
> Please take a look https://github.com/keycloak/keycloak/compare/2.1.0.
> Final...cargosoft:KEYCLOAK-3327
>
> (it has been branched off 2.1.0.Final for the ease of testing, I'll rebase
> it onto master if needed)
>
> o.k.models.RealmModel: added methods (borrowed signatures from
> jpa.RealmAdapter)
> o.k.models.jpa.RealmAdapter: added @Override annotations
> o.k.models.mongo.keycloak.adapters.RealmAdapter: added stubs (throwing
> UnsupportedOperationException)
> o.k.models.cache.infinispan.RealmAdapter: added attributes caching logic
> o.k.models.cache.infinispan.entities.CachedRealm: added attributes cache
> (as Map<String, String>)
>
> As for tests, I'm afraid I'll need some guidance.
> org.keycloak.testsuite.model.ModelTest seems appropriate for that; but it
> will need support for attributes in RealmRepresentation and RealmManager.
> Is this the right direction?
>
> Dmitry
>
>
>
> On 18 July 2016 at 22:35, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>
> Stian,
>
> Here we go: https://issues.jboss.org/browse/KEYCLOAK-3327
>
> If the fix is somewhat trivial (i.e. a matter of adding fields and
> getters/setters) I think I could work on a PR as well.
>
>
> As the attributes are already available in the underlying entities it's
> just a matter of exposing through RealmModel and add tests for it.
>
>
>
> BTW, does this mean that all the custom entities provided via Entity SPI
> are not by default cache-enabled (and won't be synchronized between the
> nodes in clustered environment)?
> If so, will it be easy to cache-enable them? Is this just a matter of
> providing Infinispan adapters similar to existing ones for
> Realm/User/Role/Client etc.?
>
>
> There's no caching for custom entities. I'd recommend using Hibernate 2nd
> level cache for it as it's rather tricky to create a custom one. We have
> our custom one because we need to support Mongo as well as users from
> different sources (user federation and identity brokering).
>
>
>
> Ideally, I'd like to see a current domain-extension example augmented with
> Infinispan cache functionality. I've got some ideas on a detailed
> walkthrough tutorial for building complete, full-featured KeyCloak
> extensions (it's a big topic I'll elaborate on a bit later); I think
> Infinispan-enabled entities could be covered there, too.
>
>
> No chance we're adding cache for custom entities. It's just to hard to get
> right. For custom entities you should use Hibernate 2nd level cache.
>
>
>
> Regards,
> Dmitry
>
> В Пн, 18/07/2016 в 07:39 +0200, Stian Thorgersen пишет:
>
> Forgot that attributes are not exposed through RealmModel. You can't
> access the JPA RealmAdapter directly as you'll break the cache
> functionality. You can create a JIRA to request attributes added to
> RealmModel though.
>
> On 15 July 2016 at 20:28, Mitya <mitya at cargosoft.ru> wrote:
>
> Stian,
>
> In my provider, session.getContext().getRealm() returns an instance
> of org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be
> able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter.
> What's the best way to obtain it?
>
> I've yet come up with the following:
>
> RealmModel realm = session.getContext().getRealm();
> RealmAdapter adapter = (RealmAdapter) session.getProvider(RealmProvi
> der.class).getRealm(realm.getId());
>
>
> Realm attributes should be perfect for that
>
> On 12 July 2016 at 13:42, Mitya <mitya at cargosoft.ru> wrote:
>
> Hi,
>
> I'm developing a KeyCloak extension, and I want some custom (per-realm)
> parameters to be tuned via the GUI form. Speaking of the storage mechanism
> for my settings, are realm attributes suitable for that? or should I create
> a dedicated custom entity instead?
>
> Thx,
> Mitya
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/dc6c51c7/attachment-0001.html
More information about the keycloak-dev
mailing list