[keycloak-dev] need feedback on pluggable fed console UI

[Bill Burke]

On 7/30/2014 9:55 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 30 July, 2014 2:37:27 PM
>> Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
>>
>>
>>
>> On 7/30/2014 7:24 AM, Stian Thorgersen wrote:
>>> I think it's perfectly fine to configure these through keycloak-server.json
>>> for now. It's an advanced use-case after all.
>>>
>>
>> If somebody wants to integrate something (highly unlikely), our
>> javascript files are provided by the theme.  They can edit index.html
>> and app.js to add their <script> entries and their $routes.
>>
>>> Providing this feature properly is going to be quite tricky and time
>>> consuming I think. A few thoughts about this:
>>>
>>> * We should at least look at UberFire
>>
>> Or Hawt.io.  Which is why I didn't really want to do anything crazy here.
>>
>>> * If we do this - bootstrapping of providers should be done by retrieving
>>> the config for the console from the server (list of SPIs, providers, etc.)
>>> then this should be used to load scripts (through js) and add config to
>>> the routeprovider
>>> * I'm still not convinced that this can't be achieved in a generic way -
>>> creating jax-rs, js scripts and html files for a provider is a big
>>> overhead (and would require developers to learn a lot of new tech)
>>> * Resources/connections such as email servers, ldap servers, databases,
>>> etc. should be configured globally and referenced from the realm -
>>> basically what datasources do in an app server
>>>
>>
>> I don't agree that ldap servers and email servers would be or should be
>> configured globally.
>>
>> LDAP will be an often used feature.  It should have a nice UI and
>> integrate real nice with the admin console.  Haven't you seen the
>> numerous inquiries on federating multiple ldap stores too?  I just don't
>> see ldap ever being configured globally.
>>
>> For email, while the same email server might be used for different
>> realms, there is a high probability that the settings will be different
>> per realm  i.e.:
>>
>> Subject header, email username/password, From, reply-to, email template,
>> etc.
>
> We'd still need realm specific config, but configuring the connection itself should be globally IMO.
>
> You'd configure your email server globally (server address, etc.). Then you'd go to email settings for your realm, under there you'd be able to select an email server, then you'd set from/reply-to and that stuff there.
>

How is that user friendly?

* You have to go to and have permission to edit a global settings file 
or global admin non-realm (or master realm) specific UI screen.
* You then finish configuring the LDAP or EMAIL server in a separate 
realm-specific UI screen.

All this so that you might be able to share an EMAIL server's ip 
address/port.  And when you probably won't be sharing any LDAP config 
between realms?

As it is, I don't think we're going to have many multi-realm deployments 
and the master realm might end up being disabled (like in Aerogear).

> The data-source comparison is a pretty good comparison. For the data-source you configure url, pool-size, etc. you don't configure tables, etc.
>

Data-source is different than email.  Email can be set up at runtime as 
you don't need it to boot up the server.  A datasource has to be 
configured prior to boot time because you can't run Keycloak without it. 
  Changing datasource config will usually require a server restart.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com