9:23 a.m.
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?
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(a)redhat.com>
> To: keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com