From bburke at redhat.com Tue Jul 29 18:42:57 2014
Content-Type: multipart/mixed; boundary="===============3086215083050923686=="
MIME-Version: 1.0
From: Bill Burke <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: [keycloak-dev] need feedback on pluggable fed console UI
Date: Tue, 29 Jul 2014 18:42:56 -0400
Message-ID: <53D82370.2000201@redhat.com>

--===============3086215083050923686==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

I'm kind of at a block with providing an SPI to plugin federation =

provider console UIs.

I would need to:

1. Provide a way to dynamically load the javascript of the plug
- index.html could be processed with Freemarker or some other brute =

force means to add the appropriate <script> elements
- Could add <script> tags within javascript (not sure about this, see =

$routeProvider

2. $routeProvider can only be set up once it seems?  Function pointers =

need to already be established for controllers.

3. We have to worry about name clashes with other admin console angular =

components?

I'm just not sure I want to create a full-fledged "portlet" spi at this =

late juncture.  My thinking is to hard code LDAP and any other provider =

has to be configured through keycloak_server.json or via a generic =

properties page.

-- =

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

--===============3086215083050923686==--

From stian at redhat.com Wed Jul 30 07:24:42 2014
Content-Type: multipart/mixed; boundary="===============2131552673918570375=="
MIME-Version: 1.0
From: Stian Thorgersen <stian at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
Date: Wed, 30 Jul 2014 07:24:42 -0400
Message-ID: <876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
In-Reply-To: 53D82370.2000201@redhat.com

--===============2131552673918570375==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

I think it's perfectly fine to configure these through keycloak-server.json=
 for now. It's an advanced use-case after all.

Providing this feature properly is going to be quite tricky and time consum=
ing I think. A few thoughts about this:

* We should at least look at UberFire
* If we do this - bootstrapping of providers should be done by retrieving t=
he config for the console from the server (list of SPIs, providers, etc.) t=
hen 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 - cr=
eating 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 w=
hat datasources do in an app server

----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 29 July, 2014 11:42:56 PM
> Subject: [keycloak-dev] need feedback on pluggable fed console UI
> =

> I'm kind of at a block with providing an SPI to plugin federation
> provider console UIs.
> =

> I would need to:
> =

> 1. Provide a way to dynamically load the javascript of the plug
> - index.html could be processed with Freemarker or some other brute
> force means to add the appropriate <script> elements
> - Could add <script> tags within javascript (not sure about this, see
> $routeProvider
> =

> 2. $routeProvider can only be set up once it seems?  Function pointers
> need to already be established for controllers.
> =

> 3. We have to worry about name clashes with other admin console angular
> components?
> =

> I'm just not sure I want to create a full-fledged "portlet" spi at this
> late juncture.  My thinking is to hard code LDAP and any other provider
> has to be configured through keycloak_server.json or via a generic
> properties page.
> =

> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>=20

--===============2131552673918570375==--

From stian at redhat.com Wed Jul 30 07:25:39 2014
Content-Type: multipart/mixed; boundary="===============4133779946897619428=="
MIME-Version: 1.0
From: Stian Thorgersen <stian at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
Date: Wed, 30 Jul 2014 07:25:39 -0400
Message-ID: <1916430055.20327652.1406719539591.JavaMail.zimbra@redhat.com>
In-Reply-To: 876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com

--===============4133779946897619428==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

By the way I did a prototype of a very basic extendible console a while bac=
k, maybe something useful in there:

https://github.com/stianst/experiments/tree/master/console

----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Wednesday, 30 July, 2014 12:24:42 PM
> Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
> =

> I think it's perfectly fine to configure these through keycloak-server.js=
on
> for now. It's an advanced use-case after all.
> =

> 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
> * 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.) th=
en
> 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 overhe=
ad
> (and would require developers to learn a lot of new tech)
> * Resources/connections such as email servers, ldap servers, databases, e=
tc.
> should be configured globally and referenced from the realm - basically w=
hat
> datasources do in an app server
> =

> ----- Original Message -----
> > From: "Bill Burke" <bburke(a)redhat.com>
> > To: keycloak-dev(a)lists.jboss.org
> > Sent: Tuesday, 29 July, 2014 11:42:56 PM
> > Subject: [keycloak-dev] need feedback on pluggable fed console UI
> > =

> > I'm kind of at a block with providing an SPI to plugin federation
> > provider console UIs.
> > =

> > I would need to:
> > =

> > 1. Provide a way to dynamically load the javascript of the plug
> > - index.html could be processed with Freemarker or some other brute
> > force means to add the appropriate <script> elements
> > - Could add <script> tags within javascript (not sure about this, see
> > $routeProvider
> > =

> > 2. $routeProvider can only be set up once it seems?  Function pointers
> > need to already be established for controllers.
> > =

> > 3. We have to worry about name clashes with other admin console angular
> > components?
> > =

> > I'm just not sure I want to create a full-fledged "portlet" spi at this
> > late juncture.  My thinking is to hard code LDAP and any other provider
> > has to be configured through keycloak_server.json or via a generic
> > properties page.
> > =

> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > =

>=20

--===============4133779946897619428==--

From bburke at redhat.com Wed Jul 30 09:37:29 2014
Content-Type: multipart/mixed; boundary="===============3908824190079554953=="
MIME-Version: 1.0
From: Bill Burke <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
Date: Wed, 30 Jul 2014 09:37:27 -0400
Message-ID: <53D8F517.1020206@redhat.com>
In-Reply-To: 876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com

--===============3908824190079554953==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable



On 7/30/2014 7:24 AM, Stian Thorgersen wrote:
> I think it's perfectly fine to configure these through keycloak-server.js=
on 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 cons=
uming 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 th=
e 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, e=
tc. 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.


-- =

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

--===============3908824190079554953==--

From stian at redhat.com Wed Jul 30 09:55:31 2014
Content-Type: multipart/mixed; boundary="===============7616481294307439066=="
MIME-Version: 1.0
From: Stian Thorgersen <stian at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
Date: Wed, 30 Jul 2014 09:55:31 -0400
Message-ID: <16223750.20459030.1406728531747.JavaMail.zimbra@redhat.com>
In-Reply-To: 53D8F517.1020206@redhat.com

--===============7616481294307439066==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable



----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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 retrievi=
ng
> > the config for the console from the server (list of SPIs, providers, et=
c.)
> > 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 itsel=
f 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.

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.

> =

> =

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

--===============7616481294307439066==--

From bburke at redhat.com Wed Jul 30 11:18:24 2014
Content-Type: multipart/mixed; boundary="===============2741352430529935478=="
MIME-Version: 1.0
From: Bill Burke <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
Date: Wed, 30 Jul 2014 11:18:24 -0400
Message-ID: <53D90CC0.4030203@redhat.com>
In-Reply-To: 16223750.20459030.1406728531747.JavaMail.zimbra@redhat.com

--===============2741352430529935478==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable



On 7/30/2014 9:55 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)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 retrievi=
ng
>>> the config for the console from the server (list of SPIs, providers, et=
c.)
>>> 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 its=
elf should be globally IMO.
>
> You'd configure your email server globally (server address, etc.). Then y=
ou'd go to email settings for your realm, under there you'd be able to sele=
ct 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-sour=
ce 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

--===============2741352430529935478==--

From ssilvert at redhat.com Wed Jul 30 11:53:22 2014
Content-Type: multipart/mixed; boundary="===============6914966204182077485=="
MIME-Version: 1.0
From: Stan Silvert <ssilvert at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
Date: Wed, 30 Jul 2014 11:53:22 -0400
Message-ID: <53D914F2.7010104@redhat.com>
In-Reply-To: 53D90CC0.4030203@redhat.com

--===============6914966204182077485==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On 7/30/2014 11:18 AM, Bill Burke wrote:
> 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).
>
Why did they disable master realm?  Is there any reason not to use the =

master realm for single-realm deployments?

--===============6914966204182077485==--

From bburke at redhat.com Wed Jul 30 12:00:11 2014
Content-Type: multipart/mixed; boundary="===============4661610613753510978=="
MIME-Version: 1.0
From: Bill Burke <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
Date: Wed, 30 Jul 2014 12:00:10 -0400
Message-ID: <53D9168A.5090400@redhat.com>
In-Reply-To: 53D914F2.7010104@redhat.com

--===============4661610613753510978==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable



On 7/30/2014 11:53 AM, Stan Silvert wrote:
> On 7/30/2014 11:18 AM, Bill Burke wrote:
>> 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).
>>
> Why did they disable master realm?  Is there any reason not to use the
> master realm for single-realm deployments?

The did it to make aerogear look like one product.  Keycloak admin, =

Aerogear admin, and Aerogear user console are all managed under one =

realm.  The idea is to hide keycloak's multi-realm capabilities.


-- =

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

--===============4661610613753510978==--