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?
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev