[keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 27 May, 2015 1:18:11 PM
> Subject: Re: [keycloak-dev] Dynamically compute LIST values in	ProviderConfigProperty
> 
> On 27.5.2015 13:07, Marek Posolda wrote:
> > UserFederationMapper is using ConfiguredProvider like other mappers.
> > In Role LDAP Mapper, I want to display combobox with the list of all
> > the realm clients, so user can choose, which client roles will be
> > mapped to LDAP roles. I need RealmModel instance for this. Currently I
> > can see those possible solutions:
> >
> > 1) Make admin requests to have RealmModel (and possibly ClientModel)
> > available in KeycloakContext (currently is null). As I mentioned in
> > other mail yesterday, we can possibly set RealmModel in
> > RealmsAdminResource.getRealmAdmin . Similarly ClientModel can be set
> > later before ClientResource is instantiated.
> >
> > 2) Add RealmModel as argument on
> > "ConfiguredProvider.getConfigProperties" method
> >
> > 3) Use method "getConfigProperties(RealmModel realm)" just in my
> > provider and ignore the "getConfigProperties()" from ConfiguredProvider.
> >
> > Currently I have it already working with (3), but I don't like it very
> > much... It seems to me that (1) is best. Solution (2) is also not very
> > good IMO (also because protocolMappers are tight to the client and not
> > to the realm)

+1 To option 1 - we should get rid of passing the realm around and instead rely on KeycloakContext

> >
> > It looks to me that IdentityProviderMapper may also need realm to
> > retrieve the roles dynamically. The current solution where user
> > manually needs to fill "clientName.roleName" is likely not very good
> > (not user friendly and it won't work for realm role with dot in the
> > name like "my.cool.realm.role" ).

+1000

> >
> > Also I wonder if ProviderConfigProperty should support MAP type in
> > addition to the list? Then we can use key/value pairs instead of just
> > flat values. That will allow that users will see client/role names in
> > the combobox in the UI, but chosen value will be client/role ID.
> I meant "chosen key", which will be used as the configuration value in
> the backend will be client/role ID.
> 
> > WDYT?
> > Marek
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>