3:15 p.m.
I've implemented a new generic component storage, api, REST API, and
admin console support. Classes/interfaces are in server-spi
org.keycloak.component package and created via methods in RealmModel.
It is basically a more generic form of mapper models,
UserFederationModel, etc. Components describe themselves and can be
generically rendered by the admin console. The storage model is meant
to support nested subcomponents (i.e. UserFederationModel and
UserFederationMappers). Config now supports a MultivaluedHashmap
instead of a flat Map to support list storage. There is a common REST
API under the realm that should be usable for all component types. The
UserStorage SPI uses this new SPI from top to bottom.
We should consider whether we want to migrate other component types to
this new model.
When you create components to store, you specify a parentId (i.e. Realm,
Client, a parent component), a provider type, a provider id, and
config. For export, the json model will contain components under Realm
and Client where the perspective parentId is Realm and Client. I still
want to make this as human consumable as possible so that these
components can be defined by humans in json.
Bill
4:57 p.m.
One thing partially related to this:
- Can we have the possibility in admin console, so the particular
provider can "override" the default template for particular provider
type? The generic configuration based on kc-provider-config directive
works fine, but in some cases, people may want something more specific
for their provider.
As an example, we currently have custom template "federated-ldap.html"
just for LDAP Federation provider and for all the others, we have
"federated-generic.html" . People don't have possibility to easily add
their own templates for custom FederationProvider implementation. What I
mean is, that if there is FooFederationProviderFactory with ID "foo" and
there is template "federated-foo.html", then Keycloak will use this one
template instead of "federated-generic.html" . This should work just
when people provide their own HTML template and copy into theme, but
they won't need to change any builtin Keycloak templates ( app.js and
others).
Marek
On 09/08/16 15:15, Bill Burke wrote:
I've implemented a new generic component storage, api, REST API,
and
admin console support. Classes/interfaces are in server-spi
org.keycloak.component package and created via methods in RealmModel.
It is basically a more generic form of mapper models,
UserFederationModel, etc. Components describe themselves and can be
generically rendered by the admin console. The storage model is meant
to support nested subcomponents (i.e. UserFederationModel and
UserFederationMappers). Config now supports a MultivaluedHashmap
instead of a flat Map to support list storage. There is a common REST
API under the realm that should be usable for all component types. The
UserStorage SPI uses this new SPI from top to bottom.
We should consider whether we want to migrate other component types to
this new model.
When you create components to store, you specify a parentId (i.e. Realm,
Client, a parent component), a provider type, a provider id, and
config. For export, the json model will contain components under Realm
and Client where the perspective parentId is Realm and Client. I still
want to make this as human consumable as possible so that these
components can be defined by humans in json.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:40 p.m.
On 8/11/16 10:57 AM, Marek Posolda wrote:
One thing partially related to this:
- Can we have the possibility in admin console, so the particular
provider can "override" the default template for particular provider
type? The generic configuration based on kc-provider-config directive
works fine, but in some cases, people may want something more specific
for their provider.
I think its just a matter of making sure you order your $routeProvider's
appropriately. Break $routeProvider registrations into their own file
(routeprovider.js) and you just make sure you include your javascript
file before the routeprovider.js.
Bill
10:10 a.m.
Sounds great. Do you have an example on how to use it? Or do we need to dig
into the code in details?
On 9 August 2016 at 15:15, Bill Burke <bburke(a)redhat.com> wrote:
I've implemented a new generic component storage, api, REST API,
and
admin console support. Classes/interfaces are in server-spi
org.keycloak.component package and created via methods in RealmModel.
It is basically a more generic form of mapper models,
UserFederationModel, etc. Components describe themselves and can be
generically rendered by the admin console. The storage model is meant
to support nested subcomponents (i.e. UserFederationModel and
UserFederationMappers). Config now supports a MultivaluedHashmap
instead of a flat Map to support list storage. There is a common REST
API under the realm that should be usable for all component types. The
UserStorage SPI uses this new SPI from top to bottom.
We should consider whether we want to migrate other component types to
this new model.
When you create components to store, you specify a parentId (i.e. Realm,
Client, a parent component), a provider type, a provider id, and
config. For export, the json model will contain components under Realm
and Client where the perspective parentId is Realm and Client. I still
want to make this as human consumable as possible so that these
components can be defined by humans in json.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:44 p.m.
You'd have to look at how UserStorageProvider, specifically
UserStorageManager. Its not complete yet. Still need to add validation
callbacks which is on my todo list.
On 8/18/16 4:10 AM, Stian Thorgersen wrote:
Sounds great. Do you have an example on how to use it? Or do we need
to dig into the code in details?
On 9 August 2016 at 15:15, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
I've implemented a new generic component storage, api, REST API, and
admin console support. Classes/interfaces are in server-spi
org.keycloak.component package and created via methods in RealmModel.
It is basically a more generic form of mapper models,
UserFederationModel, etc. Components describe themselves and can be
generically rendered by the admin console. The storage model is meant
to support nested subcomponents (i.e. UserFederationModel and
UserFederationMappers). Config now supports a MultivaluedHashmap
instead of a flat Map to support list storage. There is a common REST
API under the realm that should be usable for all component
types. The
UserStorage SPI uses this new SPI from top to bottom.
We should consider whether we want to migrate other component types to
this new model.
When you create components to store, you specify a parentId (i.e.
Realm,
Client, a parent component), a provider type, a provider id, and
config. For export, the json model will contain components under
Realm
and Client where the perspective parentId is Realm and Client. I
still
want to make this as human consumable as possible so that these
components can be defined by humans in json.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
9 a.m.
Hi Bill,
There's a discussion going on here: https://github.com/keycloak/keycloa
k/pull/3153
The question is, whether the new component storage mechanism will
replace/supersede what we currently know as realm attributes. Could you
please leave a comment?
Thanks! Dmitry
I've implemented a new generic component storage, api, REST API,
and
admin console support. Classes/interfaces are in server-spi
> org.keycloak.component package and created via methods in
RealmModel.
It is basically a more generic form of mapper models,
UserFederationModel, etc. Components describe themselves and can be
> generically rendered by the admin console. The storage model is
meant
to support nested subcomponents (i.e. UserFederationModel and
UserFederationMappers). Config now supports a MultivaluedHashmap
> instead of a flat Map to support list storage. There is a common
REST
> API under the realm that should be usable for all component
types. The
UserStorage SPI uses this new SPI from top to bottom.
> We should consider whether we want to migrate other component types
to
this new model.
> When you create components to store, you specify a parentId (i.e.
Realm,
Client, a parent component), a provider type, a provider id, and
> config. For export, the json model will contain components under
Realm
> and Client where the perspective parentId is Realm and
Client. I
still
want to make this as human consumable as possible so that these
components can be defined by humans in json.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3072
days inactive
3094
days old
5 comments
4 participants
participants (4)
-
Bill Burke -
Dmitry Telegin -
Marek Posolda -
Stian Thorgersen