[keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty

[Marek Posolda]

On 27.5.2015 15:17, Stian Thorgersen wrote:
>
> ----- 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
Great, thanks. I've added realm and client to admin requests (created 
https://issues.jboss.org/browse/KEYCLOAK-1355 for it) and removed 
getConfigProperties(realm) from Federation Mapper and change it to use 
realm from the context instead.

Marek
>
>>> 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
>>