[keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty

[Marek Posolda]

On 27.5.2015 16:23, Bill Burke wrote:
> I was thinking that we'd just add new types beyond STRING, BOOLEAN, LIST
> etc.  Just add a ROLE_LIST and CLIENT_LIST ProviderConfigProperty type,
> the admin console would see that type, and just display an appropriate
> UI for selecting that type.  Down the line we couldadd types like
> CERTIFICATE_LIST, USER_SEARCH, etc...
>
> I don't think a getConfigProperties(RealmModel) is needed.  The admin
> console already knows the current realm and it can itself query for the
> ROLE/Client list to display to choose from.
>
> Following me?
Yes, looks like even better option. I've added CLIENT_LIST for now as 
that's needed in Role LDAP mapper.

Marek
>
> Another approach would be to allow the Provider to specify a partial
> html page and javascript to import.
>
> On 5/27/2015 9:17 AM, 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
>>
>>>> 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
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>