1:42 p.m.
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
1:53 p.m.
Realm attributes should be perfect for that
On 12 July 2016 at 13:42, Mitya <mitya(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:28 p.m.
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(RealmProvider.class).getRealm(realm.getId());
Realm attributes should be perfect for that
> On 12 July 2016 at 13:42, Mitya <mitya(a)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(a)lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:39 a.m.
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(a)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(RealmProvider.class).getRealm(realm.getId());
Realm attributes should be perfect for that
On 12 July 2016 at 13:42, Mitya <mitya(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:35 p.m.
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.
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.?
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.
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(a)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(RealmProvider.class).getRealm(realm.getId());
>
>
> > Realm attributes should be perfect for that
> > > > > On 12 July 2016 at 13:42, Mitya <mitya(a)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(a)lists.jboss.org
> > >
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
7:51 a.m.
On 18 July 2016 at 22:35, Dmitry Telegin <mitya(a)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(a)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(RealmProvider.class).getRealm(realm.getId());
Realm attributes should be perfect for that
On 12 July 2016 at 13:42, Mitya <mitya(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:47 p.m.
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.F
inal...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(a)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(a)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(RealmProvider.class).getRealm(realm.getId()
);
> > >
> > >
> > > > Realm attributes should be perfect for that
> > > > > > > > > On 12 July 2016 at 13:42, Mitya
<mitya(a)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(a)lists.jboss.org
> > > > >
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
>
12:51 p.m.
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(a)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(a)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(a)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(
RealmProvider.class).getRealm(realm.getId());
Realm attributes should be perfect for that
On 12 July 2016 at 13:42, Mitya <mitya(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:06 p.m.
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(a)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(a)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(a)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(RealmProvider.class).getRealm(realm.get
Id());
> > > > >
> > > > >
> > > > > > Realm attributes should be perfect for that
> > > > > > > > > > > > > > > > > >
> > On 12 July 2016 at 13:42, Mitya <mitya(a)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(a)lists.jboss.org
> > > > > > >
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
9:44 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:34 p.m.
Ah, that simple. Please take a look at the PR.
Note: in RealmTest::assertRealm, while comparing initial vs. created
realm, we have to check for inclusion of attributes, not equality (of
attribute maps). This is because the JPA realm impl adds a lot of
attributes itself, and they're now returned by the endpoint.
Dmitry
В Ср, 17/08/2016 в 09:44 +0200, Stian Thorgersen пишет:
> 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(a)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.Str
ing) at
org.keycloak.models.utils.reflection.MethodPropertyImpl.<init>(Meth
odPropertyImpl.java:53) at
org.keycloak.models.utils.reflection.Properties.createProperty(Prop
erties.java:44) at
org.keycloak.models.utils.reflection.PropertyQuery.getResultList(Pr
opertyQuery.java:168) at
org.keycloak.models.utils.reflection.PropertyQuery.getWritableResul
tList(PropertyQuery.java:140) at
org.keycloak.connections.mongo.impl.MongoStoreImpl.getEntityInfo(Mo
ngoStoreImpl.java:433) at
org.keycloak.connections.mongo.impl.MongoStoreImpl.<init>(MongoStor
eImpl.java:101) at
org.keycloak.connections.mongo.DefaultMongoConnectionFactoryProvide
r.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(a)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(a)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(a)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(RealmProvider.class).getRealm(realm
.getId());
> > > > > > >
> > > > > > >
> > > > > > > > Realm attributes should be perfect for that
> > > > > > > > > > > > > > > > > >
> > > > > > > > On 12 July 2016 at 13:42, Mitya
<mitya(a)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(a)lists.jboss.org
> > > > > > > > >
> > > > > > > > > > > > > > > > > >
> https://lists.jboss.org/mailman/listinfo/keycloak-d
ev
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
2801
days inactive
2838
days old
10 comments
3 participants
participants (3)
-
Dmitry Telegin -
Mitya
-
Stian Thorgersen