From stian at redhat.com  Thu Jan  2 01:15:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Jan 2014 01:15:32 -0500 (EST)
Subject: [keycloak-dev] Certificate Management,
 Directory Services and Device Registration
In-Reply-To: <52B860AD.4060906@redhat.com>
References: <etPan.52b43557.2ae8944a.5c9d@tesla> <52B451A6.3070609@redhat.com>
	<52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com>
	<52B4A824.1010005@redhat.com> <52B4AB9E.4080108@redhat.com>
	<1641766950.37813169.1387790516491.JavaMail.root@redhat.com>
	<52B860AD.4060906@redhat.com>
Message-ID: <1992230721.40917711.1388643332802.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 23 December, 2013 4:11:25 PM
> Subject: Re: [keycloak-dev] Certificate Management, Directory Services and Device Registration
> 
> On 12/23/2013 03:21 AM, Stian Thorgersen wrote:
> 
> 
> 
> ----- Original Message -----
> 
> 
> 
> > From: "Bill Burke" <bburke at redhat.com> > To: keycloak-dev at lists.jboss.org >
> > Sent: Friday, 20 December, 2013 8:42:06 PM > Subject: Re: [keycloak-dev]
> > Certificate Management, Directory Services and Device Registration > > > >
> > On 12/20/2013 3:27 PM, Anil Saldhana wrote:
> 
> 
> 
> > > Some of this is what I hear from users, customers and the industry. Also
> > > > > see below: > > > > On 12/20/2013 02:23 PM, Anil Saldhana wrote:
> 
> 
> 
> > >> Bill brought out some thoughts in my mind which I want to capture here >
> > >> >> to see what your thoughts are: > >> > >> * Certificate Management >
> > >> >> - We need a good system to CRUD certificates.  The only good Java
> > >> based > >> oss I have seen is EJBCA.
> EJBCA is a no-go as it's looks like it's heavily dependent on JavaEE. For
> LiveOak we need whatever libraries we use to be non-JavaEE.
> Stian - let me take a guess here. You think maybe writing a thin REST based
> system for certificate management is better?

I haven't thought much about it, but yes I think everything should be exposed through REST. Re-utilizing existing stuff is great though, but as long as we want to embed Keycloak into the LiveOak container it can't require a JavaEE runtime.

> EJBCA is an old project. I guess they started out as EJB based services.

Had a quick look at docs and looks like it is built as a set of EJBs and deployable to JBoss AS

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > >> > >> * Directory Server/Services > >> - We have ApacheDS and OpenDS (or
> > >> > >> the ForgeRock version) as two > >> possibilities in Java based
> > >> > >> directory servers. I am unsure if we have > >> really explored
> > >> > >> building a solution for directory services.
> > > * Another important consideration is Active Directory. It is an > >
> > > ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we > >
> > > really need some type of Open Source solution to this ecosystem. The > >
> > > core starts with directory services or a facade. > >
> > > A huge part of Keycloak's value-add is it provides the UI for login, >
> > > registration, acct/credential/device/realm management.  If these AD/LDAP
> > > > services are read-only, then there's not a lot Keycloak can offer you.
> > > > > Also, for Keycloak 1.0.Final, we're focusing solely on securing Web
> > > Apps > and RESTful services.  We can't have too many tangents or feature
> > > creep.
> We can't wait to long to support mobile devices (at least Android and iOS).
> These would be required by both LiveOak and AeroGear. Not sure if that's
> before or after a 1.0.Final though. AeroGear guys can probably help us out
> here though, as they're working on OAuth2 libraries.
> Agree. Having REST based MBaaS dealing with mobile devices may be critical.
> Apache UserGrid is the new entrant in the oss space.
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Jan  2 02:40:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Jan 2014 02:40:41 -0500 (EST)
Subject: [keycloak-dev] Keycloak release
In-Reply-To: <1440795523.40941121.1388647755703.JavaMail.root@redhat.com>
Message-ID: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>

Happy New Year :)

It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:

* Documentation - what's the status of docs? I'm happy to review, and also write some as well
* Logo - Gabriel are you looking at this?
* Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
* Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?

From bburke at redhat.com  Thu Jan  2 10:12:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Jan 2014 10:12:10 -0500
Subject: [keycloak-dev] Keycloak release
In-Reply-To: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
Message-ID: <52C581CA.1070106@redhat.com>



On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
> Happy New Year :)
>
> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>

Want to do it ASAP.

> * Documentation - what's the status of docs? I'm happy to review, and also write some as well

Was going to start on docs after dist was finalized.  There's still a 
little bit of work to do there.  See below.

> * Logo - Gabriel are you looking at this?
> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?

jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we 
have no logo.  keycloak.org redirects there.  If somebody wants to put a 
site together, fine with me, but this isn't a skill set I have.

Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs. 
Pretty sure we have a keycloak directory there that is hooked up via my 
ssh key.

> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?

What's status on Openshift Quickstart?  FYI, patching AS7 is no longer 
required to run on AS7.  Please see examples/as7-eap-demo/server.  Are 
you familiar with Docbook?  Can you write up how to set up the Openshift 
Quickstart?

For dist, I was going to provide the following downloads:

Zip 1 Appliance:
* examples/as7-eap-demo
* examples/wildfly-demo
* docs/
* A pre-configured Wildfly CR1 Dist
* adapters packaged as different jboss modules zips
* lib/as7-adapter
* lib/wildfly-adapter
* exploded server WAR

Zip 2:
* examples/docs
* adapters packaged as different jboss modules zips
* lib/as7-adapter
* lib/wildfly-adapter
* exploded server WAR

We would still need the following components to build on top of a 
Wildfly minimal dist:

* Embeddable DB
* JPA
* Web
* JAX-RS

I was actually thinking of writing a utility that scanned a jboss 
module's dist to determine subsystems and their dependencies.  Its 
pretty difficult to figure out now with the current Wildfly build.



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

From Anil.Saldhana at redhat.com  Thu Jan  2 10:20:38 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 02 Jan 2014 09:20:38 -0600
Subject: [keycloak-dev] Certificate Management,
 Directory Services and Device Registration
In-Reply-To: <1992230721.40917711.1388643332802.JavaMail.root@redhat.com>
References: <etPan.52b43557.2ae8944a.5c9d@tesla> <52B451A6.3070609@redhat.com>
	<52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com>
	<52B4A824.1010005@redhat.com> <52B4AB9E.4080108@redhat.com>
	<1641766950.37813169.1387790516491.JavaMail.root@redhat.com>
	<52B860AD.4060906@redhat.com>
	<1992230721.40917711.1388643332802.JavaMail.root@redhat.com>
Message-ID: <52C583C6.8060508@redhat.com>

On 01/02/2014 12:15 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 23 December, 2013 4:11:25 PM
>> Subject: Re: [keycloak-dev] Certificate Management, Directory Services and Device Registration
>>
>> On 12/23/2013 03:21 AM, Stian Thorgersen wrote:
>>
>>
>>
>> ----- Original Message -----
>>
>>
>>
>>> From: "Bill Burke" <bburke at redhat.com> > To: keycloak-dev at lists.jboss.org >
>>> Sent: Friday, 20 December, 2013 8:42:06 PM > Subject: Re: [keycloak-dev]
>>> Certificate Management, Directory Services and Device Registration > > > >
>>> On 12/20/2013 3:27 PM, Anil Saldhana wrote:
>>
>>
>>>> Some of this is what I hear from users, customers and the industry. Also
>>>>>> see below: > > > > On 12/20/2013 02:23 PM, Anil Saldhana wrote:
>>
>>
>>>>> Bill brought out some thoughts in my mind which I want to capture here >
>>>>>>> to see what your thoughts are: > >> > >> * Certificate Management >
>>>>>>> - We need a good system to CRUD certificates.  The only good Java
>>>>> based > >> oss I have seen is EJBCA.
>> EJBCA is a no-go as it's looks like it's heavily dependent on JavaEE. For
>> LiveOak we need whatever libraries we use to be non-JavaEE.
>> Stian - let me take a guess here. You think maybe writing a thin REST based
>> system for certificate management is better?
> I haven't thought much about it, but yes I think everything should be exposed through REST. Re-utilizing existing stuff is great though, but as long as we want to embed Keycloak into the LiveOak container it can't require a JavaEE runtime.
Creating certificates is possible with Bouncycastle + JDK. I guess what 
is left are UI and storage mechanisms.

>
>> EJBCA is an old project. I guess they started out as EJB based services.
> Had a quick look at docs and looks like it is built as a set of EJBs and deployable to JBoss AS
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>>>>>> * Directory Server/Services > >> - We have ApacheDS and OpenDS (or
>>>>>>>> the ForgeRock version) as two > >> possibilities in Java based
>>>>>>>> directory servers. I am unsure if we have > >> really explored
>>>>>>>> building a solution for directory services.
>>>> * Another important consideration is Active Directory. It is an > >
>>>> ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we > >
>>>> really need some type of Open Source solution to this ecosystem. The > >
>>>> core starts with directory services or a facade. > >
>>>> A huge part of Keycloak's value-add is it provides the UI for login, >
>>>> registration, acct/credential/device/realm management.  If these AD/LDAP
>>>>> services are read-only, then there's not a lot Keycloak can offer you.
>>>>>> Also, for Keycloak 1.0.Final, we're focusing solely on securing Web
>>>> Apps > and RESTful services.  We can't have too many tangents or feature
>>>> creep.
>> We can't wait to long to support mobile devices (at least Android and iOS).
>> These would be required by both LiveOak and AeroGear. Not sure if that's
>> before or after a 1.0.Final though. AeroGear guys can probably help us out
>> here though, as they're working on OAuth2 libraries.
>> Agree. Having REST based MBaaS dealing with mobile devices may be critical.
>> Apache UserGrid is the new entrant in the oss space.
>>

From bburke at redhat.com  Thu Jan  2 10:51:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Jan 2014 10:51:59 -0500
Subject: [keycloak-dev] Certificate Management,
 Directory Services and Device Registration
In-Reply-To: <52C583C6.8060508@redhat.com>
References: <etPan.52b43557.2ae8944a.5c9d@tesla>
	<52B451A6.3070609@redhat.com>	<52B4A4FF.9020304@redhat.com>
	<52B4A72E.3060703@redhat.com>	<52B4A824.1010005@redhat.com>
	<52B4AB9E.4080108@redhat.com>	<1641766950.37813169.1387790516491.JavaMail.root@redhat.com>	<52B860AD.4060906@redhat.com>	<1992230721.40917711.1388643332802.JavaMail.root@redhat.com>
	<52C583C6.8060508@redhat.com>
Message-ID: <52C58B1F.2040705@redhat.com>



On 1/2/2014 10:20 AM, Anil Saldhana wrote:
> Creating certificates is possible with Bouncycastle + JDK. I guess what
> is left are UI and storage mechanisms.

Exactly.  We don't need EJBCA.

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

From Anil.Saldhana at redhat.com  Thu Jan  2 10:57:32 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 02 Jan 2014 09:57:32 -0600
Subject: [keycloak-dev] Certificate Management,
 Directory Services and Device Registration
In-Reply-To: <52C58B1F.2040705@redhat.com>
References: <etPan.52b43557.2ae8944a.5c9d@tesla>
	<52B451A6.3070609@redhat.com>	<52B4A4FF.9020304@redhat.com>
	<52B4A72E.3060703@redhat.com>	<52B4A824.1010005@redhat.com>
	<52B4AB9E.4080108@redhat.com>	<1641766950.37813169.1387790516491.JavaMail.root@redhat.com>	<52B860AD.4060906@redhat.com>	<1992230721.40917711.1388643332802.JavaMail.root@redhat.com>
	<52C583C6.8060508@redhat.com> <52C58B1F.2040705@redhat.com>
Message-ID: <52C58C6C.6000308@redhat.com>

On 01/02/2014 09:51 AM, Bill Burke wrote:
> On 1/2/2014 10:20 AM, Anil Saldhana wrote:
>> >Creating certificates is possible with Bouncycastle + JDK. I guess what
>> >is left are UI and storage mechanisms.
> Exactly.  We don't need EJBCA.
That is what I am saying too. Create it in KeyCloak using REST services.
Since LiveOak does not use JavaEE runtimes, are they free to use RESTEasy?

From bburke at redhat.com  Thu Jan  2 11:25:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Jan 2014 11:25:02 -0500
Subject: [keycloak-dev] Certificate Management,
 Directory Services and Device Registration
In-Reply-To: <52C58C6C.6000308@redhat.com>
References: <etPan.52b43557.2ae8944a.5c9d@tesla>	<52B451A6.3070609@redhat.com>	<52B4A4FF.9020304@redhat.com>	<52B4A72E.3060703@redhat.com>	<52B4A824.1010005@redhat.com>	<52B4AB9E.4080108@redhat.com>	<1641766950.37813169.1387790516491.JavaMail.root@redhat.com>	<52B860AD.4060906@redhat.com>	<1992230721.40917711.1388643332802.JavaMail.root@redhat.com>	<52C583C6.8060508@redhat.com>
	<52C58B1F.2040705@redhat.com> <52C58C6C.6000308@redhat.com>
Message-ID: <52C592DE.80102@redhat.com>



On 1/2/2014 10:57 AM, Anil Saldhana wrote:
> On 01/02/2014 09:51 AM, Bill Burke wrote:
>> On 1/2/2014 10:20 AM, Anil Saldhana wrote:
>>>> Creating certificates is possible with Bouncycastle + JDK. I guess what
>>>> is left are UI and storage mechanisms.
>> Exactly.  We don't need EJBCA.
> That is what I am saying too. Create it in KeyCloak using REST services.
> Since LiveOak does not use JavaEE runtimes, are they free to use RESTEasy?

LiveOak is free to use Resteasy, but they don't want to.  Stian is going 
to extract as much logic as possible into a rest-framework neutral library.

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

From ssilvert at redhat.com  Thu Jan  2 12:57:59 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 02 Jan 2014 12:57:59 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52C581CA.1070106@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
	<52C581CA.1070106@redhat.com>
Message-ID: <52C5A8A7.1010706@redhat.com>

Should the WildFly demo be working right now?  I built the latest and
deployed.  It looked like it was working.  Then I started getting this
every time I hit the customer-portal:

org.apache.jasper.JasperException: java.lang.RuntimeException:
org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
60)): expected a valid value (number, String, array, object, 'true',
'false' or 'null') at [Source:
org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)

On 1/2/2014 10:12 AM, Bill Burke wrote:
>
> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>> Happy New Year :)
>>
>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>
> Want to do it ASAP.
>
>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
> Was going to start on docs after dist was finalized.  There's still a 
> little bit of work to do there.  See below.
>
>> * Logo - Gabriel are you looking at this?
>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we 
> have no logo.  keycloak.org redirects there.  If somebody wants to put a 
> site together, fine with me, but this isn't a skill set I have.
>
> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs. 
> Pretty sure we have a keycloak directory there that is hooked up via my 
> ssh key.
>
>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer 
> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are 
> you familiar with Docbook?  Can you write up how to set up the Openshift 
> Quickstart?
>
> For dist, I was going to provide the following downloads:
>
> Zip 1 Appliance:
> * examples/as7-eap-demo
> * examples/wildfly-demo
> * docs/
> * A pre-configured Wildfly CR1 Dist
> * adapters packaged as different jboss modules zips
> * lib/as7-adapter
> * lib/wildfly-adapter
> * exploded server WAR
>
> Zip 2:
> * examples/docs
> * adapters packaged as different jboss modules zips
> * lib/as7-adapter
> * lib/wildfly-adapter
> * exploded server WAR
>
> We would still need the following components to build on top of a 
> Wildfly minimal dist:
>
> * Embeddable DB
> * JPA
> * Web
> * JAX-RS
>
> I was actually thinking of writing a utility that scanned a jboss 
> module's dist to determine subsystems and their dependencies.  Its 
> pretty difficult to figure out now with the current Wildfly build.
>
>
>


From bburke at redhat.com  Thu Jan  2 15:41:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Jan 2014 15:41:12 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52C5A8A7.1010706@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>
	<52C5A8A7.1010706@redhat.com>
Message-ID: <52C5CEE8.5030206@redhat.com>

It should be working.  I'll take a look.

On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
> Should the WildFly demo be working right now?  I built the latest and
> deployed.  It looked like it was working.  Then I started getting this
> every time I hit the customer-portal:
>
> org.apache.jasper.JasperException: java.lang.RuntimeException:
> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
> 60)): expected a valid value (number, String, array, object, 'true',
> 'false' or 'null') at [Source:
> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>
> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>
>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>> Happy New Year :)
>>>
>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>
>> Want to do it ASAP.
>>
>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>> Was going to start on docs after dist was finalized.  There's still a
>> little bit of work to do there.  See below.
>>
>>> * Logo - Gabriel are you looking at this?
>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>> site together, fine with me, but this isn't a skill set I have.
>>
>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>> Pretty sure we have a keycloak directory there that is hooked up via my
>> ssh key.
>>
>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>> you familiar with Docbook?  Can you write up how to set up the Openshift
>> Quickstart?
>>
>> For dist, I was going to provide the following downloads:
>>
>> Zip 1 Appliance:
>> * examples/as7-eap-demo
>> * examples/wildfly-demo
>> * docs/
>> * A pre-configured Wildfly CR1 Dist
>> * adapters packaged as different jboss modules zips
>> * lib/as7-adapter
>> * lib/wildfly-adapter
>> * exploded server WAR
>>
>> Zip 2:
>> * examples/docs
>> * adapters packaged as different jboss modules zips
>> * lib/as7-adapter
>> * lib/wildfly-adapter
>> * exploded server WAR
>>
>> We would still need the following components to build on top of a
>> Wildfly minimal dist:
>>
>> * Embeddable DB
>> * JPA
>> * Web
>> * JAX-RS
>>
>> I was actually thinking of writing a utility that scanned a jboss
>> module's dist to determine subsystems and their dependencies.  Its
>> pretty difficult to figure out now with the current Wildfly build.
>>
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Thu Jan  2 15:52:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Jan 2014 15:52:38 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52C5CEE8.5030206@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>
	<52C5CEE8.5030206@redhat.com>
Message-ID: <52C5D196.1090603@redhat.com>

Demo works, but admin console login doesn't.  Seems to be a classloader 
issue with Wildfly 8cr1.

On 1/2/2014 3:41 PM, Bill Burke wrote:
> It should be working.  I'll take a look.
>
> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>> Should the WildFly demo be working right now?  I built the latest and
>> deployed.  It looked like it was working.  Then I started getting this
>> every time I hit the customer-portal:
>>
>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>> 60)): expected a valid value (number, String, array, object, 'true',
>> 'false' or 'null') at [Source:
>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>
>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>
>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>> Happy New Year :)
>>>>
>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>
>>> Want to do it ASAP.
>>>
>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>> Was going to start on docs after dist was finalized.  There's still a
>>> little bit of work to do there.  See below.
>>>
>>>> * Logo - Gabriel are you looking at this?
>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>> site together, fine with me, but this isn't a skill set I have.
>>>
>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>> ssh key.
>>>
>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>> Quickstart?
>>>
>>> For dist, I was going to provide the following downloads:
>>>
>>> Zip 1 Appliance:
>>> * examples/as7-eap-demo
>>> * examples/wildfly-demo
>>> * docs/
>>> * A pre-configured Wildfly CR1 Dist
>>> * adapters packaged as different jboss modules zips
>>> * lib/as7-adapter
>>> * lib/wildfly-adapter
>>> * exploded server WAR
>>>
>>> Zip 2:
>>> * examples/docs
>>> * adapters packaged as different jboss modules zips
>>> * lib/as7-adapter
>>> * lib/wildfly-adapter
>>> * exploded server WAR
>>>
>>> We would still need the following components to build on top of a
>>> Wildfly minimal dist:
>>>
>>> * Embeddable DB
>>> * JPA
>>> * Web
>>> * JAX-RS
>>>
>>> I was actually thinking of writing a utility that scanned a jboss
>>> module's dist to determine subsystems and their dependencies.  Its
>>> pretty difficult to figure out now with the current Wildfly build.
>>>
>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From bburke at redhat.com  Thu Jan  2 16:36:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Jan 2014 16:36:21 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52C5D196.1090603@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>
	<52C5D196.1090603@redhat.com>
Message-ID: <52C5DBD5.2040801@redhat.com>

Let me know if it works now.  I was able to get it running with WF8CR1 
after modifying jboss-deployment-structure.xml



On 1/2/2014 3:52 PM, Bill Burke wrote:
> Demo works, but admin console login doesn't.  Seems to be a classloader
> issue with Wildfly 8cr1.
>
> On 1/2/2014 3:41 PM, Bill Burke wrote:
>> It should be working.  I'll take a look.
>>
>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>> Should the WildFly demo be working right now?  I built the latest and
>>> deployed.  It looked like it was working.  Then I started getting this
>>> every time I hit the customer-portal:
>>>
>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>> 60)): expected a valid value (number, String, array, object, 'true',
>>> 'false' or 'null') at [Source:
>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>
>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>
>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>> Happy New Year :)
>>>>>
>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>
>>>> Want to do it ASAP.
>>>>
>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>> Was going to start on docs after dist was finalized.  There's still a
>>>> little bit of work to do there.  See below.
>>>>
>>>>> * Logo - Gabriel are you looking at this?
>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>> site together, fine with me, but this isn't a skill set I have.
>>>>
>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>> ssh key.
>>>>
>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>> Quickstart?
>>>>
>>>> For dist, I was going to provide the following downloads:
>>>>
>>>> Zip 1 Appliance:
>>>> * examples/as7-eap-demo
>>>> * examples/wildfly-demo
>>>> * docs/
>>>> * A pre-configured Wildfly CR1 Dist
>>>> * adapters packaged as different jboss modules zips
>>>> * lib/as7-adapter
>>>> * lib/wildfly-adapter
>>>> * exploded server WAR
>>>>
>>>> Zip 2:
>>>> * examples/docs
>>>> * adapters packaged as different jboss modules zips
>>>> * lib/as7-adapter
>>>> * lib/wildfly-adapter
>>>> * exploded server WAR
>>>>
>>>> We would still need the following components to build on top of a
>>>> Wildfly minimal dist:
>>>>
>>>> * Embeddable DB
>>>> * JPA
>>>> * Web
>>>> * JAX-RS
>>>>
>>>> I was actually thinking of writing a utility that scanned a jboss
>>>> module's dist to determine subsystems and their dependencies.  Its
>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

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

From ssilvert at redhat.com  Thu Jan  2 17:44:24 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 02 Jan 2014 17:44:24 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52C5DBD5.2040801@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>	<52C5D196.1090603@redhat.com>
	<52C5DBD5.2040801@redhat.com>
Message-ID: <52C5EBC8.6030204@redhat.com>

Looks good now.

On 1/2/2014 4:36 PM, Bill Burke wrote:
> Let me know if it works now.  I was able to get it running with WF8CR1 
> after modifying jboss-deployment-structure.xml
>
>
>
> On 1/2/2014 3:52 PM, Bill Burke wrote:
>> Demo works, but admin console login doesn't.  Seems to be a classloader
>> issue with Wildfly 8cr1.
>>
>> On 1/2/2014 3:41 PM, Bill Burke wrote:
>>> It should be working.  I'll take a look.
>>>
>>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>>> Should the WildFly demo be working right now?  I built the latest and
>>>> deployed.  It looked like it was working.  Then I started getting this
>>>> every time I hit the customer-portal:
>>>>
>>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>>> 60)): expected a valid value (number, String, array, object, 'true',
>>>> 'false' or 'null') at [Source:
>>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>>
>>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>>> Happy New Year :)
>>>>>>
>>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>>
>>>>> Want to do it ASAP.
>>>>>
>>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>>> Was going to start on docs after dist was finalized.  There's still a
>>>>> little bit of work to do there.  See below.
>>>>>
>>>>>> * Logo - Gabriel are you looking at this?
>>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>>> site together, fine with me, but this isn't a skill set I have.
>>>>>
>>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>>> ssh key.
>>>>>
>>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>>> Quickstart?
>>>>>
>>>>> For dist, I was going to provide the following downloads:
>>>>>
>>>>> Zip 1 Appliance:
>>>>> * examples/as7-eap-demo
>>>>> * examples/wildfly-demo
>>>>> * docs/
>>>>> * A pre-configured Wildfly CR1 Dist
>>>>> * adapters packaged as different jboss modules zips
>>>>> * lib/as7-adapter
>>>>> * lib/wildfly-adapter
>>>>> * exploded server WAR
>>>>>
>>>>> Zip 2:
>>>>> * examples/docs
>>>>> * adapters packaged as different jboss modules zips
>>>>> * lib/as7-adapter
>>>>> * lib/wildfly-adapter
>>>>> * exploded server WAR
>>>>>
>>>>> We would still need the following components to build on top of a
>>>>> Wildfly minimal dist:
>>>>>
>>>>> * Embeddable DB
>>>>> * JPA
>>>>> * Web
>>>>> * JAX-RS
>>>>>
>>>>> I was actually thinking of writing a utility that scanned a jboss
>>>>> module's dist to determine subsystems and their dependencies.  Its
>>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>


From bburke at redhat.com  Fri Jan  3 11:40:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 03 Jan 2014 11:40:24 -0500
Subject: [keycloak-dev] full export support
Message-ID: <52C6E7F8.7070104@redhat.com>

Was thinking about full export (including credentials) of a realm. 
Maybe we could allow this through the admin console, but the export is 
dumped to a local directory on the server.  That way, only somebody with 
access to the server can obtain the dump.


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

From bburke at redhat.com  Fri Jan  3 12:02:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 03 Jan 2014 12:02:57 -0500
Subject: [keycloak-dev] pluggable templates
Message-ID: <52C6ED41.3030603@redhat.com>

Was thinking about pluggable templates for login, oauth screen, user 
acct mgmt, etc...

Why force users to use Freemarker?  Why not allow them to create a 
directory within the Keycloak Server WAR and use whatever framework they 
want to use?  Then to choose a template, you just specify the URLs for 
login, oauth, user acct mgmt, etc?

What sucks is, because we're using Freemarker and everything is bundled 
up in JARs, there's no easy way for users to copy/paste a template and 
create and play with their own on the fly.

Just food for thought for after Alpha 1 release.

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

From bburke at redhat.com  Fri Jan  3 19:42:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 03 Jan 2014 19:42:09 -0500
Subject: [keycloak-dev] require adapter modules?
Message-ID: <52C758E1.9060803@redhat.com>

Rather than have multiple options for installing a as7 or wildfly 
adapter, do you think its fine to require the installation of jboss 
modules for your desired adapter then adding a 
jboss-deployment-structure.xml to your deployment?

* This avoids any dependency conflict between a keycloak adapter and the 
application.
* The distribution becomes smaller as I don't have to include both 
jboss-modules zips and unpacked jars.
* Less options is also less confusing.  Having too many options can be 
confusing
* We can always document later how to pull in libs directly to the 
deployment.


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

From ssilvert at redhat.com  Sat Jan  4 15:42:50 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Sat, 04 Jan 2014 15:42:50 -0500
Subject: [keycloak-dev] require adapter modules?
In-Reply-To: <52C758E1.9060803@redhat.com>
References: <52C758E1.9060803@redhat.com>
Message-ID: <52C8724A.4040700@redhat.com>

+1

For the subsystem, I'm using a single module called
"org.keycloak.adapter".  It contains the three keycloak jars and lists
dependencies.  I'm attaching the modules.xml for WildFly so you can see
what I've done. 

On 1/3/2014 7:42 PM, Bill Burke wrote:
> Rather than have multiple options for installing a as7 or wildfly 
> adapter, do you think its fine to require the installation of jboss 
> modules for your desired adapter then adding a 
> jboss-deployment-structure.xml to your deployment?
>
> * This avoids any dependency conflict between a keycloak adapter and the 
> application.
> * The distribution becomes smaller as I don't have to include both 
> jboss-modules zips and unpacked jars.
> * Less options is also less confusing.  Having too many options can be 
> confusing
> * We can always document later how to pull in libs directly to the 
> deployment.
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: module.xml
Type: text/xml
Size: 919 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140104/506ff8cf/attachment-0001.xml 

From ssilvert at redhat.com  Sat Jan  4 15:48:06 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Sat, 04 Jan 2014 15:48:06 -0500
Subject: [keycloak-dev] require adapter modules?
In-Reply-To: <52C758E1.9060803@redhat.com>
References: <52C758E1.9060803@redhat.com>
Message-ID: <52C87386.4040504@redhat.com>

An update on the subsystem:

If a deployment is listed in the subsystem, it automatically adds the
org.keycloak.adapter module as a dependency of the deployment.  No
jboss-deployment-structure.xml is needed.

When we install the org.keycloak.adapter module, let's install the
subsystem at the same time.  However, while the subsystem is almost
working, it probably won't be ready for this first release.

In the future, I think keycloak modules and the subsystem will be
included in the WildFly/EAP distribution.  You won't be required to have
anything keycloak-related in your WAR.  You just add keycloak to your
deployment from the keycloak UI or from JBoss CLI.

Soon, we need to start telling people to stop putting authentication
into their applications.  Authentication is a cross-cutting concern that
should be 100% decoupled from the app.  I think that's a killer
message.  Developers don't need to worry about authentication any more.

BTW, I'm not sure if the module solution will work for EAP6.  Have you
tried using a keycloak module on EAP6?  When I tried it I ran into some
classloading problems initializing the OAuthAuthenticatorValve.  I also
tried using a global valve[1].  Global valve worked better, but I found
that JBoss Web is not calling LifecycleListener methods for global
valves.  Some more investigation needs to be done.

[1] https://community.jboss.org/wiki/AddAGlobalValveInAS772x

On 1/3/2014 7:42 PM, Bill Burke wrote:
> Rather than have multiple options for installing a as7 or wildfly 
> adapter, do you think its fine to require the installation of jboss 
> modules for your desired adapter then adding a 
> jboss-deployment-structure.xml to your deployment?
>
> * This avoids any dependency conflict between a keycloak adapter and the 
> application.
> * The distribution becomes smaller as I don't have to include both 
> jboss-modules zips and unpacked jars.
> * Less options is also less confusing.  Having too many options can be 
> confusing
> * We can always document later how to pull in libs directly to the 
> deployment.
>
>

From mposolda at redhat.com  Mon Jan  6 04:40:46 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 06 Jan 2014 10:40:46 +0100
Subject: [keycloak-dev] Feedback on examples
In-Reply-To: <52A86458.9060509@redhat.com>
References: <52A74547.2000203@redhat.com> <52A86458.9060509@redhat.com>
Message-ID: <52CA7A1E.4080008@redhat.com>

On 11.12.2013 14:10, Bill Burke wrote:
> On 12/10/2013 11:45 AM, Marek Posolda wrote:
>> >I have few points regarding example applications:
>> >
>> >- For third-party oauth client example, there is not possibility to
>> >configure stuff through JSON but everything is hardcoded in classes
>> >Bootstrap and ProductDatabaseClient. There are also some strange
>> >comments in code like "This is the worst code ever" etc:-)  This is not
>> >so ideal IMO as I expect that people will often look to the source code
>> >of these examples for inspiration. I believe that OAuth clients should
>> >also have something like ManagedResourceConfigLoader for Applications.
>> >
> Feel free to write a better example with CDI or Spring and expand out
> the oauth client framework code.
>
>> >- For the "third-party" OAuth client, I don't like the fact that when
>> >user press "Cancel" in OAuth grant page, there is exception in
>> >server.log and Tomcat error page displayed. I believe the behaviour
>> >should be more user-friendly.
>> >
> Again, feel free to expand on the third-party app to display something
> better.
>
Just a note that I've updated PR 
https://github.com/keycloak/keycloak/pull/134 and synced it with your 
latest adapter changes. Not sure if you received github notifications, 
so writing here just in case:-)
For now, I changed just third-party application in 
examples/as7-eap-demo/third-party to use CDI. I can update wildfly 
example as well if you are ok with my impl.

Marek

From gcardoso at redhat.com  Mon Jan  6 08:20:24 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 6 Jan 2014 11:20:24 -0200
Subject: [keycloak-dev] Keycloak release
In-Reply-To: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
Message-ID: <F9FA46E6-FA3B-47D6-BCD7-4FE880CD082B@redhat.com>

Happy New Year!

> * Logo - Gabriel are you looking at this?
Yes, I?m working on it. Will send proposals to you guys ASAP.

Gabriel



From stian at redhat.com  Tue Jan  7 05:48:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jan 2014 05:48:38 -0500 (EST)
Subject: [keycloak-dev] pluggable templates
In-Reply-To: <52C6ED41.3030603@redhat.com>
References: <52C6ED41.3030603@redhat.com>
Message-ID: <917927491.44738571.1389091718716.JavaMail.root@redhat.com>

The way things are at the moment is not how we want to have it in the long run.

How it's envisioned to work is that users can create themes. A theme can extend another theme and can specify:

* Config (logo, hide/display fields, etc)
* Resources (css and images)
* Templates (html)

A theme can be bundled in a JAR and should be automatically discovered if it's on KC's class-path, but it should also be possible to define it through the admin console. In the admin console at first we could just let users upload a zip/jar with all the artefacts required, but in the future we could let them edit css/templates and upload resources directly through the console.

This would make it easy for a user to for example only modify the login forms, while using the default account management. In the default theme we can also make it fairly configurable through config options and making it css-friendly so that most users should be able to do what they want without having to create templates. I would hope that at least 80% of users that want to customize the forms can do so through config and css, while less than 20% would have to create templates to make it do exactly what they want.

Providing a mechanism to do this with a web framework would require users to basically build everything from scratch, which would be a lot more work. Also, if you're talking about JavaEE web apps that's not available in LiveOak. They would still need to understand some basic Freemarker stuff as we need a template engine for emails.

I'm quite convinced that using a template engine is the way to go, and fairly confident that Freemarker is a good choice. End of the day though I think that most things in Keycloak should be pluggable, so we should have a forms SPI, with the default implementation based on Freemaker (and customizable themes) while it would be possible for someone to implement something else by just dropping in a different JAR with an implementation of the forms SPI. That could use JSF, AngularJS or whatever. We could also support both returning html directly from the forms SPI (template style) or a redirect to a url (jsf or whatever style).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 3 January, 2014 5:02:57 PM
> Subject: [keycloak-dev] pluggable templates
> 
> Was thinking about pluggable templates for login, oauth screen, user
> acct mgmt, etc...
> 
> Why force users to use Freemarker?  Why not allow them to create a
> directory within the Keycloak Server WAR and use whatever framework they
> want to use?  Then to choose a template, you just specify the URLs for
> login, oauth, user acct mgmt, etc?
> 
> What sucks is, because we're using Freemarker and everything is bundled
> up in JARs, there's no easy way for users to copy/paste a template and
> create and play with their own on the fly.
> 
> Just food for thought for after Alpha 1 release.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jan  7 06:00:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jan 2014 06:00:15 -0500 (EST)
Subject: [keycloak-dev] full export support
In-Reply-To: <52C6E7F8.7070104@redhat.com>
References: <52C6E7F8.7070104@redhat.com>
Message-ID: <1102994606.44742786.1389092415677.JavaMail.root@redhat.com>

Sounds good to me. We could also let users import this be either uploading it through the admin console (after they've retrieved it from the servers fs), or by selecting one from the "dump directory" (they can't dl it from the admin console, just make the server import it into its db).

Quite likely a full export could take a fair bit of time (5min+), so exporting to a file on the local fs would be the best approach even if not considering security.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 3 January, 2014 4:40:24 PM
> Subject: [keycloak-dev] full export support
> 
> Was thinking about full export (including credentials) of a realm.
> Maybe we could allow this through the admin console, but the export is
> dumped to a local directory on the server.  That way, only somebody with
> access to the server can obtain the dump.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bruno at abstractj.org  Tue Jan  7 07:11:39 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 7 Jan 2014 10:11:39 -0200
Subject: [keycloak-dev] pluggable templates
In-Reply-To: <917927491.44738571.1389091718716.JavaMail.root@redhat.com>
References: <52C6ED41.3030603@redhat.com>
	<917927491.44738571.1389091718716.JavaMail.root@redhat.com>
Message-ID: <etPan.52cbeefb.1190cde7.40f6@tesla>

Hi Stian, not sure if I?m following you on this, but most of the companies, developers, communities really want to create templates, let alone the fact that make it easy to create would open a new possibility to a community of web designers too.

Keep in mind that most of them are not familiar with FreeMarker or deploying a JAR, so if possible I would stick with Bill?s suggestion. Build a CSS + HTML5, or customize something already existent.?

Java developers have no clue about how to build a good web design and most of the web designers know nothing about Java, it seems like a chicken and egg situation.

--  
abstractj

On January 7, 2014 at 8:48:41 AM, Stian Thorgersen (stian at redhat.com) wrote:
>  
> The way things are at the moment is not how we want to have it in the  
> long run.
>  
> How it's envisioned to work is that users can create themes. A  
> theme can extend another theme and can specify:
>  
> * Config (logo, hide/display fields, etc)
> * Resources (css and images)
> * Templates (html)
>  
> A theme can be bundled in a JAR and should be automatically discovered  
> if it's on KC's class-path, but it should also be possible to define  
> it through the admin console. In the admin console at first we  
> could just let users upload a zip/jar with all the artefacts required,  
> but in the future we could let them edit css/templates and upload  
> resources directly through the console.
>  
> This would make it easy for a user to for example only modify the  
> login forms, while using the default account management. In  
> the default theme we can also make it fairly configurable through  
> config options and making it css-friendly so that most users  
> should be able to do what they want without having to create templates.  
> I would hope that at least 80% of users that want to customize the  
> forms can do so through config and css, while less than 20% would  
> have to create templates to make it do exactly what they want.  
>  
> Providing a mechanism to do this with a web framework would require  
> users to basically build everything from scratch, which would  
> be a lot more work. Also, if you're talking about JavaEE web apps  
> that's not available in LiveOak. They would still need to understand  
> some basic Freemarker stuff as we need a template engine for emails.  
>  
> I'm quite convinced that using a template engine is the way to  
> go, and fairly confident that Freemarker is a good choice. End  
> of the day though I think that most things in Keycloak should be  
> pluggable, so we should have a forms SPI, with the default implementation  
> based on Freemaker (and customizable themes) while it would  
> be possible for someone to implement something else by just dropping  
> in a different JAR with an implementation of the forms SPI. That  
> could use JSF, AngularJS or whatever. We could also support both  
> returning html directly from the forms SPI (template style)  
> or a redirect to a url (jsf or whatever style).
>  
> ----- Original Message -----
> > From: "Bill Burke"  
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, 3 January, 2014 5:02:57 PM
> > Subject: [keycloak-dev] pluggable templates
> >
> > Was thinking about pluggable templates for login, oauth screen,  
> user
> > acct mgmt, etc...
> >
> > Why force users to use Freemarker? Why not allow them to create  
> a
> > directory within the Keycloak Server WAR and use whatever framework  
> they
> > want to use? Then to choose a template, you just specify the URLs  
> for
> > login, oauth, user acct mgmt, etc?
> >
> > What sucks is, because we're using Freemarker and everything  
> is bundled
> > up in JARs, there's no easy way for users to copy/paste a template  
> and
> > create and play with their own on the fly.
> >
> > Just food for thought for after Alpha 1 release.
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > 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  
>  



From stian at redhat.com  Tue Jan  7 07:53:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jan 2014 07:53:31 -0500 (EST)
Subject: [keycloak-dev] pluggable templates
In-Reply-To: <etPan.52cbeefb.1190cde7.40f6@tesla>
References: <52C6ED41.3030603@redhat.com>
	<917927491.44738571.1389091718716.JavaMail.root@redhat.com>
	<etPan.52cbeefb.1190cde7.40f6@tesla>
Message-ID: <2021343316.44796042.1389099211882.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 January, 2014 12:11:39 PM
> Subject: Re: [keycloak-dev] pluggable templates
> 
> Hi Stian, not sure if I?m following you on this, but most of the companies,
> developers, communities really want to create templates, let alone the fact
> that make it easy to create would open a new possibility to a community of
> web designers too.

Most web designers are very comfortable with CSS so if they can achieve what they want with pure CSS that'll be the simplest for them (just look at zen garden to see what can be achieve with only css if the html structure is "css-friendly"). We should obviously still support changing the HTML as well if required.

> 
> Keep in mind that most of them are not familiar with FreeMarker or deploying
> a JAR, so if possible I would stick with Bill?s suggestion. Build a CSS +
> HTML5, or customize something already existent.

Whatever template engine/syntax we choose not everyone will be familiar with it. What I proposed would allow people to build a pure HTML5 (with whatever JS framework they choose) if that's what they want to.

Deploying a JAR is more if Keycloak is "embedded" within a Java project. In that case bundling the theme as a JAR will be the best approach. But as I said we need to have other options as well.

> 
> Java developers have no clue about how to build a good web design and most of
> the web designers know nothing about Java, it seems like a chicken and egg
> situation.

Hence why I think FreeMarker templates is better than any server-side framework. Same applies for HTML5 (client-side) implementations, web designers have no clue about Java or JS. For HTML5 we can create the required REST endpoints, as well as controllers/services for AngularJS and some default HTML templates. Then users can override individual HTML templates if they need to.


Just to clarify I think that we need to have multiple levels of themes:

1. CSS and config - the simplest approach as it only requires a stylesheet, a few images, and a config file
2. Templates - when there really is a need to change the HTML structure we can support this by creating a template for a specific page. For this we need a template syntax/engine, and FreeMarker is as good as any for server-side
3. Full blown - would let people rip it all out and build their own with JSF, JSP, HTML5 or whatever web framework they want

And it should be possible to package/deploy as:

1. jar - for embedding Keycloak into another project (i.e. this is how we'd do it in LiveOak)
2. zip - uploaded through admin console or copied into some directory
3. editor in admin console - create/edit css/templates through the admin console, as well as upload images

> 
> --
> abstractj
> 
> On January 7, 2014 at 8:48:41 AM, Stian Thorgersen (stian at redhat.com) wrote:
> >  
> > The way things are at the moment is not how we want to have it in the
> > long run.
> >  
> > How it's envisioned to work is that users can create themes. A
> > theme can extend another theme and can specify:
> >  
> > * Config (logo, hide/display fields, etc)
> > * Resources (css and images)
> > * Templates (html)
> >  
> > A theme can be bundled in a JAR and should be automatically discovered
> > if it's on KC's class-path, but it should also be possible to define
> > it through the admin console. In the admin console at first we
> > could just let users upload a zip/jar with all the artefacts required,
> > but in the future we could let them edit css/templates and upload
> > resources directly through the console.
> >  
> > This would make it easy for a user to for example only modify the
> > login forms, while using the default account management. In
> > the default theme we can also make it fairly configurable through
> > config options and making it css-friendly so that most users
> > should be able to do what they want without having to create templates.
> > I would hope that at least 80% of users that want to customize the
> > forms can do so through config and css, while less than 20% would
> > have to create templates to make it do exactly what they want.
> >  
> > Providing a mechanism to do this with a web framework would require
> > users to basically build everything from scratch, which would
> > be a lot more work. Also, if you're talking about JavaEE web apps
> > that's not available in LiveOak. They would still need to understand
> > some basic Freemarker stuff as we need a template engine for emails.
> >  
> > I'm quite convinced that using a template engine is the way to
> > go, and fairly confident that Freemarker is a good choice. End
> > of the day though I think that most things in Keycloak should be
> > pluggable, so we should have a forms SPI, with the default implementation
> > based on Freemaker (and customizable themes) while it would
> > be possible for someone to implement something else by just dropping
> > in a different JAR with an implementation of the forms SPI. That
> > could use JSF, AngularJS or whatever. We could also support both
> > returning html directly from the forms SPI (template style)
> > or a redirect to a url (jsf or whatever style).
> >  
> > ----- Original Message -----
> > > From: "Bill Burke"
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 3 January, 2014 5:02:57 PM
> > > Subject: [keycloak-dev] pluggable templates
> > >
> > > Was thinking about pluggable templates for login, oauth screen,
> > user
> > > acct mgmt, etc...
> > >
> > > Why force users to use Freemarker? Why not allow them to create
> > a
> > > directory within the Keycloak Server WAR and use whatever framework
> > they
> > > want to use? Then to choose a template, you just specify the URLs
> > for
> > > login, oauth, user acct mgmt, etc?
> > >
> > > What sucks is, because we're using Freemarker and everything
> > is bundled
> > > up in JARs, there's no easy way for users to copy/paste a template
> > and
> > > create and play with their own on the fly.
> > >
> > > Just food for thought for after Alpha 1 release.
> > >
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > _______________________________________________
> > > 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
> >  
> 
> 


From stian at redhat.com  Tue Jan  7 09:18:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jan 2014 09:18:03 -0500 (EST)
Subject: [keycloak-dev] Keycloak release
In-Reply-To: <52C581CA.1070106@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
	<52C581CA.1070106@redhat.com>
Message-ID: <894541323.44893989.1389104283774.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 2 January, 2014 3:12:10 PM
> Subject: Re: [keycloak-dev] Keycloak release
> 
> 
> 
> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
> > Happy New Year :)
> >
> > It would be great to release Keycloak alpha in a week or two. To get things
> > started here's remaining work I'm aware of:
> >
> 
> Want to do it ASAP.
> 
> > * Documentation - what's the status of docs? I'm happy to review, and also
> > write some as well
> 
> Was going to start on docs after dist was finalized.  There's still a
> little bit of work to do there.  See below.
> 
> > * Logo - Gabriel are you looking at this?
> > * Website - Should we update to the new JBoss community theme used by
> > WildFly, Infinispan, PicketLink, etc.?
> 
> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
> have no logo.  keycloak.org redirects there.  If somebody wants to put a
> site together, fine with me, but this isn't a skill set I have.
> 
> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
> Pretty sure we have a keycloak directory there that is hooked up via my
> ssh key.

I can start this - would be cool to have a logo and a nice website for alpha release, but definitively not a blocker

> 
> > * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced
> > a new minimal dist, maybe we could use this to reduce the dl size?
> 
> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
> you familiar with Docbook?  Can you write up how to set up the Openshift
> Quickstart?

The OpenShift Quickstart just downloads and extracts a dist from somewhere, so can be upgraded to the WildFly dist by just changing the URL it downloads. I'll need to learn Docbook in any case if we're using that for docs, so yes I can write the instructions on getting it up and running on OpenShift.

I can also write some other sections if you want some help with docs.

> 
> For dist, I was going to provide the following downloads:
> 
> Zip 1 Appliance:
> * examples/as7-eap-demo
> * examples/wildfly-demo
> * docs/
> * A pre-configured Wildfly CR1 Dist
> * adapters packaged as different jboss modules zips
> * lib/as7-adapter
> * lib/wildfly-adapter
> * exploded server WAR
> 
> Zip 2:
> * examples/docs
> * adapters packaged as different jboss modules zips
> * lib/as7-adapter
> * lib/wildfly-adapter
> * exploded server WAR

Is the lib/*-adapter needed?

What's the purpose of the exploded server WAR?

> 
> We would still need the following components to build on top of a
> Wildfly minimal dist:
> 
> * Embeddable DB
> * JPA
> * Web
> * JAX-RS
> 
> I was actually thinking of writing a utility that scanned a jboss
> module's dist to determine subsystems and their dependencies.  Its
> pretty difficult to figure out now with the current Wildfly build.

If we do provide a slimmed-down dist, we should also provide the instructions to deploy easily to a full WildFly. I imagine at least devs will want to have both their apps and Keycloak on a single server.

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

From ssilvert at redhat.com  Tue Jan  7 09:50:15 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 07 Jan 2014 09:50:15 -0500
Subject: [keycloak-dev] What is data inside keycloak.json called?
Message-ID: <52CC1427.20403@redhat.com>

Collectively, is there a name for the configuration data inside
keycloak.json?  This data is represented inside the keycloak subsystem,
but not as json.  Right now I'm calling it AuthData.  Is there already a
better name for it?

Stan

From bburke at redhat.com  Tue Jan  7 14:46:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Jan 2014 14:46:25 -0500
Subject: [keycloak-dev] Keycloak release
In-Reply-To: <894541323.44893989.1389104283774.JavaMail.root@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
	<52C581CA.1070106@redhat.com>
	<894541323.44893989.1389104283774.JavaMail.root@redhat.com>
Message-ID: <52CC5991.2090006@redhat.com>



On 1/7/2014 9:18 AM, Stian Thorgersen wrote:

> What's the purpose of the exploded server WAR?
>

To turn on CONFIDENTIAL security constraints in web.xml.  Modify 
persistence.xml settings.  Maybe in the future, a way to view/change/add 
templates for login, etc..



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

From bburke at redhat.com  Tue Jan  7 14:48:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Jan 2014 14:48:28 -0500
Subject: [keycloak-dev] What is data inside keycloak.json called?
In-Reply-To: <52CC1427.20403@redhat.com>
References: <52CC1427.20403@redhat.com>
Message-ID: <52CC5A0C.8000406@redhat.com>

Adapter config?

On 1/7/2014 9:50 AM, ssilvert at redhat.com wrote:
> Collectively, is there a name for the configuration data inside
> keycloak.json?  This data is represented inside the keycloak subsystem,
> but not as json.  Right now I'm calling it AuthData.  Is there already a
> better name for it?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Jan  7 15:12:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Jan 2014 15:12:15 -0500
Subject: [keycloak-dev] examples/distro reworked/improved/finalized PLEASE
	TRY!
Message-ID: <52CC5F9F.9070000@redhat.com>

Please build and try on the examples and distro please!  I'll be writing 
up the documentation so please get me some feedback.

* new distribution/ directory containing multiple poms
* examples now use a jboss modules import of adapter through 
jboss-deployment-structure.xml
* removed server/ project from examples/
* tested on wildfly8cr1, eap61, as711

To build the distro

$ cd keycloak/distribution
$ mvn clean install

this pom is not in the main build as it takes up a ton of space and 
downloads the wildfly distro.

There will be two distribution zips.  They are located in the build here:

distribution/war-dist/target/keycloak-war-dist.zip
distribution/appliance-dist/target/keycloak-appliance-dist.zip

Directions on how to install keycloak and run the examples are here:

https://github.com/keycloak/keycloak/tree/master/examples/wildfly-demo
https://github.com/keycloak/keycloak/tree/master/examples/as7-eap-demo

Please try it out for both and tell me what you think of the 
distro/examples, etc...


The WAR Dist:

This is for when you want to install the keycloak server on an existing 
Wildfly, EAP, or AS7 distro.

deployments/auth-server.war
deployments/auth-server.war.dodeploy
deployments/keycloak-ds.xml
examples/
adapters/keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
adapters/keycloak-eap6-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
adapters/keycloak-wildfly-adapter-dist-1.0-alpha-1-SNAPSHOT.zip

All you do is do a cp -r deployments/ to the standalone/ directory of 
your jboss/wildfly install and then just start up the server.

The adapters/* are for installing an adapter on a non-keycloak server 
instances.  You just unzip them in the jboss top level director.


The Appliance Zip:

This contains a full bootable appliance.  Right now, SSL is not set up 
by default.  I'm still not sure if it is worth it to set up a 
"localhost" self-signed cert or not.

keycloak/
examples/
adapters/keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
adapters/keycloak-eap6-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
adapters/keycloak-wildfly-adapter-dist-1.0-alpha-1-SNAPSHOT.zip

The keycloak/ directory is a wildfly distro that contains the keycloak 
server war and ds.xml file for the datasource, as well as the wildfly 
adapter jboss module all unzipped.



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

From bburke at redhat.com  Tue Jan  7 15:20:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Jan 2014 15:20:24 -0500
Subject: [keycloak-dev] Release next Monday or Tuesday
Message-ID: <52CC6188.1000608@redhat.com>

I'll bang hard on the documentation this week so we can release Alpha 1 
next Monday.  Let not commit an PRs after Thursday please!
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gcardoso at redhat.com  Tue Jan  7 15:57:26 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Tue, 7 Jan 2014 18:57:26 -0200
Subject: [keycloak-dev] Logo ideas
Message-ID: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>

Hi,

based on the concept of security and the ?key? and ?cloak? elements, I worked on some initial ideas for the logo.

After we choose one or two ideas, I?ll refine the symbol, the font and put colours. 

Which proposal do you think is more interesting for the project? 

Thanks,
Gabriel


01: I hope to have better background light effects for the final version


02: Will work more on the flying cloak


03: Maybe too ordinary

04: Will work more on the ?K? in the shield


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/88bda8c7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01.png
Type: image/png
Size: 23604 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/88bda8c7/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02.png
Type: image/png
Size: 18022 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/88bda8c7/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03.png
Type: image/png
Size: 17723 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/88bda8c7/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 04.png
Type: image/png
Size: 16662 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/88bda8c7/attachment-0007.png 

From bburke at redhat.com  Tue Jan  7 16:06:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Jan 2014 16:06:55 -0500
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
Message-ID: <52CC6C6F.2040707@redhat.com>

I like them all!  1, 3, or 4 might be the best as you can use the 
picture without the word "keycloak" for icons and stuff.

On 1/7/2014 3:57 PM, Gabriel Cardoso wrote:
> Hi,
>
> based on the concept of security and the ?key? and ?cloak? elements, I
> worked on some initial ideas for the logo.
>
> After we choose one or two ideas, I?ll refine the symbol, the font and
> put colours.
>
> *Which proposal do you think is more interesting for the project? *
>
> Thanks,
> Gabriel
>
> 01: I hope to have better background light effects for the final version
>
> 02: Will work more on the flying cloak
>
> 03: Maybe too ordinary
> 04: Will work more on the ?K? in the shield
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Tue Jan  7 17:53:16 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Tue, 07 Jan 2014 17:53:16 -0500
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
Message-ID: <52CC855C.5000402@redhat.com>

I like the super hero best (#1). 

With a little change to the key design, you could make it look like he
has a face.  Some variation on this key might work:
http://image2.cccme.org.cn/i_supply/2010/4/5/201101030953243219_123622924.jpg

On 1/7/2014 3:57 PM, Gabriel Cardoso wrote:
> Hi,
>
> based on the concept of security and the "key" and "cloak" elements, I
> worked on some initial ideas for the logo.
>
> After we choose one or two ideas, I'll refine the symbol, the font and
> put colours. 
>
> *Which proposal do you think is more interesting for the project? *
>
> Thanks,
> Gabriel
>
> 01: I hope to have better background light effects for the final version
>
> 02: Will work more on the flying cloak
>
> 03: Maybe too ordinary
> 04: Will work more on the "K" in the shield
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/59477819/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01.png
Type: image/png
Size: 23604 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/59477819/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 18022 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/59477819/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 17723 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/59477819/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 16662 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140107/59477819/attachment-0007.png 

From mposolda at redhat.com  Wed Jan  8 02:28:03 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 08 Jan 2014 08:28:03 +0100
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
Message-ID: <52CCFE03.40408@redhat.com>

Nice!
My favourites are especially 1 and 3.

Marek

On 7.1.2014 21:57, Gabriel Cardoso wrote:
> Hi,
>
> based on the concept of security and the "key" and "cloak" elements, I 
> worked on some initial ideas for the logo.
>
> After we choose one or two ideas, I'll refine the symbol, the font and 
> put colours.
>
> *Which proposal do you think is more interesting for the project? *
>
> Thanks,
> Gabriel
>
> 01: I hope to have better background light effects for the final version
>
> 02: Will work more on the flying cloak
>
> 03: Maybe too ordinary
> 04: Will work more on the "K" in the shield
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140108/bf8335d9/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01.png
Type: image/png
Size: 23604 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140108/bf8335d9/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 18022 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140108/bf8335d9/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 17723 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140108/bf8335d9/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 16662 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140108/bf8335d9/attachment-0007.png 

From stian at redhat.com  Wed Jan  8 04:05:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Jan 2014 04:05:46 -0500 (EST)
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
Message-ID: <763381465.45938737.1389171946607.JavaMail.root@redhat.com>

I really like #1 - maybe drop the star and make the key a little bit less cartoony?

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 January, 2014 8:57:26 PM
> Subject: [keycloak-dev] Logo ideas
> 
> Hi,
> 
> based on the concept of security and the ?key? and ?cloak? elements, I worked
> on some initial ideas for the logo.
> 
> After we choose one or two ideas, I?ll refine the symbol, the font and put
> colours.
> 
> Which proposal do you think is more interesting for the project?
> 
> Thanks,
> Gabriel
> 
> 01: I hope to have better background light effects for the final version
> 
> 02: Will work more on the flying cloak
> 
> 03: Maybe too ordinary
> 04: Will work more on the ?K? in the shield
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bdawidow at redhat.com  Wed Jan  8 06:11:18 2014
From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=)
Date: Wed, 08 Jan 2014 12:11:18 +0100
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <763381465.45938737.1389171946607.JavaMail.root@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>
Message-ID: <52CD3256.3030504@redhat.com>

I like 1, 3 and 4. #1 being a big ugly in current form but definitely 
with lot of potential

On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
> I really like #1 - maybe drop the star and make the key a little bit less cartoony?
>
> ----- Original Message -----
>> From: "Gabriel Cardoso" <gcardoso at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>> Subject: [keycloak-dev] Logo ideas
>>
>> Hi,
>>
>> based on the concept of security and the ?key? and ?cloak? elements, I worked
>> on some initial ideas for the logo.
>>
>> After we choose one or two ideas, I?ll refine the symbol, the font and put
>> colours.
>>
>> Which proposal do you think is more interesting for the project?
>>
>> Thanks,
>> Gabriel
>>
>> 01: I hope to have better background light effects for the final version
>>
>> 02: Will work more on the flying cloak
>>
>> 03: Maybe too ordinary
>> 04: Will work more on the ?K? in the shield
>>
>>
>>
>> _______________________________________________
>> 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
>



-- 
Boles?aw Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead

From bruno at abstractj.org  Wed Jan  8 06:25:47 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 8 Jan 2014 09:25:47 -0200
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <52CD3256.3030504@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>
	<52CD3256.3030504@redhat.com>
Message-ID: <etPan.52cd35bb.74b0dc51.65b9@tesla>

Only to be different, I would vote on #2 without the cape.

--  
abstractj

On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz (bdawidow at redhat.com) wrote:
>  
> I like 1, 3 and 4. #1 being a big ugly in current form but definitely  
> with lot of potential
>  
> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
> > I really like #1 - maybe drop the star and make the key a little  
> bit less cartoony?
> >
> > ----- Original Message -----
> >> From: "Gabriel Cardoso"  
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 7 January, 2014 8:57:26 PM
> >> Subject: [keycloak-dev] Logo ideas
> >>
> >> Hi,
> >>
> >> based on the concept of security and the ?key? and ?cloak? elements,  
> I worked
> >> on some initial ideas for the logo.
> >>
> >> After we choose one or two ideas, I?ll refine the symbol, the  
> font and put
> >> colours.
> >>
> >> Which proposal do you think is more interesting for the project?  
> >>
> >> Thanks,
> >> Gabriel
> >>
> >> 01: I hope to have better background light effects for the final  
> version
> >>
> >> 02: Will work more on the flying cloak
> >>
> >> 03: Maybe too ordinary
> >> 04: Will work more on the ?K? in the shield
> >>
> >>
> >>
> >> _______________________________________________
> >> 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  
> >
>  
>  
>  
> --
> Boles?aw Dawidowicz
> JBoss Portal Platform Architect | GateIn Portal Project Lead  
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev  



From stian at redhat.com  Thu Jan  9 10:18:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Jan 2014 10:18:23 -0500 (EST)
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE	TRY!
In-Reply-To: <52CC5F9F.9070000@redhat.com>
References: <52CC5F9F.9070000@redhat.com>
Message-ID: <2073084489.47387522.1389280703311.JavaMail.root@redhat.com>

I haven't had much time to play with this yet, but will do today/tomorrow. Although if you're not accepting PRs after today, there may not be any point? There's two outstanding PRs related to examples are you going to merge those?

Some comments on the distributions:

Instead of having these download bundles I think it would be better to have downloads for each individual thing:

keycloak-bundle-<version>.zip

- keycloak-<version>
  - bin
  - deployments/auth-server.war (exploded)
  - ..

keycloak-war.zip

- auth-server.war (exploded)
- auth-server.war.dodeploy
- keycloak-ds.xml

keycloak-wildfly-adapter.zip
keycloak-eap-adapter.zip
keycloak-as7-adapter.zip

Reason for this is that it allows devs to download what they want rather than a huge bundle. For example:

* To install the server all you want is the server
* If running Keycloak on OpenShift all you need is the one adapter for whatever application server you're using

We could move examples into a separate github project and the documentation would instruct people to get it from there. That way we can add/edit examples after a release. This is the way JDF does it, and I would think that eventually Keycloak examples would be moved into there.

It may also be good to have these zips available in Maven central as that makes it simpler for other projects to build their own distributions that includes Keycloak. I can imagine AeroGear guys may be interested in that.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 January, 2014 8:12:15 PM
> Subject: [keycloak-dev] examples/distro reworked/improved/finalized PLEASE	TRY!
> 
> Please build and try on the examples and distro please!  I'll be writing
> up the documentation so please get me some feedback.
> 
> * new distribution/ directory containing multiple poms
> * examples now use a jboss modules import of adapter through
> jboss-deployment-structure.xml
> * removed server/ project from examples/
> * tested on wildfly8cr1, eap61, as711
> 
> To build the distro
> 
> $ cd keycloak/distribution
> $ mvn clean install
> 
> this pom is not in the main build as it takes up a ton of space and
> downloads the wildfly distro.
> 
> There will be two distribution zips.  They are located in the build here:
> 
> distribution/war-dist/target/keycloak-war-dist.zip
> distribution/appliance-dist/target/keycloak-appliance-dist.zip
> 
> Directions on how to install keycloak and run the examples are here:
> 
> https://github.com/keycloak/keycloak/tree/master/examples/wildfly-demo
> https://github.com/keycloak/keycloak/tree/master/examples/as7-eap-demo
> 
> Please try it out for both and tell me what you think of the
> distro/examples, etc...
> 
> 
> The WAR Dist:
> 
> This is for when you want to install the keycloak server on an existing
> Wildfly, EAP, or AS7 distro.
> 
> deployments/auth-server.war
> deployments/auth-server.war.dodeploy
> deployments/keycloak-ds.xml
> examples/
> adapters/keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
> adapters/keycloak-eap6-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
> adapters/keycloak-wildfly-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
> 
> All you do is do a cp -r deployments/ to the standalone/ directory of
> your jboss/wildfly install and then just start up the server.
> 
> The adapters/* are for installing an adapter on a non-keycloak server
> instances.  You just unzip them in the jboss top level director.
> 
> 
> The Appliance Zip:
> 
> This contains a full bootable appliance.  Right now, SSL is not set up
> by default.  I'm still not sure if it is worth it to set up a
> "localhost" self-signed cert or not.
> 
> keycloak/
> examples/
> adapters/keycloak-as7-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
> adapters/keycloak-eap6-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
> adapters/keycloak-wildfly-adapter-dist-1.0-alpha-1-SNAPSHOT.zip
> 
> The keycloak/ directory is a wildfly distro that contains the keycloak
> server war and ds.xml file for the datasource, as well as the wildfly
> adapter jboss module all unzipped.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jan  9 10:21:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Jan 2014 10:21:48 -0500 (EST)
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <52CC6188.1000608@redhat.com>
References: <52CC6188.1000608@redhat.com>
Message-ID: <1865437390.47420291.1389280908627.JavaMail.root@redhat.com>

Would be good to have a chance to read through docs before we submit. Also there's at least a few issues outstanding that I think should be fixed prior to alpha release:

https://issues.jboss.org/browse/KEYCLOAK-180
https://issues.jboss.org/browse/KEYCLOAK-228
https://issues.jboss.org/browse/KEYCLOAK-251



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 January, 2014 8:20:24 PM
> Subject: [keycloak-dev] Release next Monday or Tuesday
> 
> I'll bang hard on the documentation this week so we can release Alpha 1
> next Monday.  Let not commit an PRs after Thursday please!
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Jan  9 11:20:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 09 Jan 2014 11:20:57 -0500
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
References: <52CC6188.1000608@redhat.com>
	<1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
Message-ID: <52CECC69.4080207@redhat.com>



On 1/9/2014 10:21 AM, Stian Thorgersen wrote:
> Would be good to have a chance to read through docs before we submit. Also there's at least a few issues outstanding that I think should be fixed prior to alpha release:
>

Working on it.

> https://issues.jboss.org/browse/KEYCLOAK-251
>

What is "Installation missing for clients"?

>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 January, 2014 8:20:24 PM
>> Subject: [keycloak-dev] Release next Monday or Tuesday
>>
>> I'll bang hard on the documentation this week so we can release Alpha 1
>> next Monday.  Let not commit an PRs after Thursday please!
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Thu Jan  9 11:23:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 09 Jan 2014 11:23:50 -0500
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <2073084489.47387522.1389280703311.JavaMail.root@redhat.com>
References: <52CC5F9F.9070000@redhat.com>
	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>
Message-ID: <52CECD16.1080500@redhat.com>



On 1/9/2014 10:18 AM, Stian Thorgersen wrote:
> I haven't had much time to play with this yet, but will do today/tomorrow. Although if you're not accepting PRs after today, there may not be any point? There's two outstanding PRs related to examples are you going to merge those?
>
> Some comments on the distributions:
>
> Instead of having these download bundles I think it would be better to have downloads for each individual thing:
>
> keycloak-bundle-<version>.zip
>
> - keycloak-<version>
>    - bin
>    - deployments/auth-server.war (exploded)
>    - ..
>
> keycloak-war.zip
>
> - auth-server.war (exploded)
> - auth-server.war.dodeploy
> - keycloak-ds.xml
>
> keycloak-wildfly-adapter.zip
> keycloak-eap-adapter.zip
> keycloak-as7-adapter.zip
>

Poms are set up to do this so not a problem.

> Reason for this is that it allows devs to download what they want rather than a huge bundle. For example:
>
> * To install the server all you want is the server
> * If running Keycloak on OpenShift all you need is the one adapter for whatever application server you're using
>
> We could move examples into a separate github project and the documentation would instruct people to get it from there. That way we can add/edit examples after a release. This is the way JDF does it, and I would think that eventually Keycloak examples would be moved into there.
>

Not everybody knows how to use Github :)  Plus, you need examples tied 
to release versions as there may be differences between them.

> It may also be good to have these zips available in Maven central as that makes it simpler for other projects to build their own distributions that includes Keycloak. I can imagine AeroGear guys may be interested in that.
>

Simple enough.


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

From stian at redhat.com  Thu Jan  9 11:26:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Jan 2014 11:26:25 -0500 (EST)
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <52CECC69.4080207@redhat.com>
References: <52CC6188.1000608@redhat.com>
	<1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
	<52CECC69.4080207@redhat.com>
Message-ID: <1176551821.47512838.1389284785183.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 9 January, 2014 4:20:57 PM
> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> 
> 
> 
> On 1/9/2014 10:21 AM, Stian Thorgersen wrote:
> > Would be good to have a chance to read through docs before we submit. Also
> > there's at least a few issues outstanding that I think should be fixed
> > prior to alpha release:
> >
> 
> Working on it.
> 
> > https://issues.jboss.org/browse/KEYCLOAK-251
> >
> 
> What is "Installation missing for clients"?

In admin console for applications you can go to installation and get the json snippet required to configure the adapter. We need the same for oauth clients.

I can probably sort out those 3 issues tomorrow. The rest of the issues in JIRA with ff M1 can be pushed back IMO.

> 
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 7 January, 2014 8:20:24 PM
> >> Subject: [keycloak-dev] Release next Monday or Tuesday
> >>
> >> I'll bang hard on the documentation this week so we can release Alpha 1
> >> next Monday.  Let not commit an PRs after Thursday please!
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu Jan  9 12:21:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Jan 2014 12:21:55 -0500 (EST)
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <52CECD16.1080500@redhat.com>
References: <52CC5F9F.9070000@redhat.com>
	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>
	<52CECD16.1080500@redhat.com>
Message-ID: <1932731294.47624970.1389288115346.JavaMail.root@redhat.com>

Is the only difference between the 3 examples the name of the adapter in jboss-deployment-structure?

If so could we not do either:

* Maven profiles to template these files with the adapter module name
* Use same module name for the adapters?

That would make it a lot easier to make sure the examples are in-sync.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 9 January, 2014 4:23:50 PM
> Subject: Re: [keycloak-dev] examples/distro reworked/improved/finalized PLEASE TRY!
> 
> 
> 
> On 1/9/2014 10:18 AM, Stian Thorgersen wrote:
> > I haven't had much time to play with this yet, but will do today/tomorrow.
> > Although if you're not accepting PRs after today, there may not be any
> > point? There's two outstanding PRs related to examples are you going to
> > merge those?
> >
> > Some comments on the distributions:
> >
> > Instead of having these download bundles I think it would be better to have
> > downloads for each individual thing:
> >
> > keycloak-bundle-<version>.zip
> >
> > - keycloak-<version>
> >    - bin
> >    - deployments/auth-server.war (exploded)
> >    - ..
> >
> > keycloak-war.zip
> >
> > - auth-server.war (exploded)
> > - auth-server.war.dodeploy
> > - keycloak-ds.xml
> >
> > keycloak-wildfly-adapter.zip
> > keycloak-eap-adapter.zip
> > keycloak-as7-adapter.zip
> >
> 
> Poms are set up to do this so not a problem.
> 
> > Reason for this is that it allows devs to download what they want rather
> > than a huge bundle. For example:
> >
> > * To install the server all you want is the server
> > * If running Keycloak on OpenShift all you need is the one adapter for
> > whatever application server you're using
> >
> > We could move examples into a separate github project and the documentation
> > would instruct people to get it from there. That way we can add/edit
> > examples after a release. This is the way JDF does it, and I would think
> > that eventually Keycloak examples would be moved into there.
> >
> 
> Not everybody knows how to use Github :)  Plus, you need examples tied
> to release versions as there may be differences between them.
> 
> > It may also be good to have these zips available in Maven central as that
> > makes it simpler for other projects to build their own distributions that
> > includes Keycloak. I can imagine AeroGear guys may be interested in that.
> >
> 
> Simple enough.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Jan  9 12:46:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 09 Jan 2014 12:46:43 -0500
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
References: <52CC5F9F.9070000@redhat.com>
	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>
	<52CECD16.1080500@redhat.com>
	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
Message-ID: <52CEE083.1090502@redhat.com>

Yes, but make it harder for users.

its jbs.xml and also web.xml

On 1/9/2014 12:21 PM, Stian Thorgersen wrote:
> Is the only difference between the 3 examples the name of the adapter in jboss-deployment-structure?
>
> If so could we not do either:
>
> * Maven profiles to template these files with the adapter module name
> * Use same module name for the adapters?
>
> That would make it a lot easier to make sure the examples are in-sync.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 9 January, 2014 4:23:50 PM
>> Subject: Re: [keycloak-dev] examples/distro reworked/improved/finalized PLEASE TRY!
>>
>>
>>
>> On 1/9/2014 10:18 AM, Stian Thorgersen wrote:
>>> I haven't had much time to play with this yet, but will do today/tomorrow.
>>> Although if you're not accepting PRs after today, there may not be any
>>> point? There's two outstanding PRs related to examples are you going to
>>> merge those?
>>>
>>> Some comments on the distributions:
>>>
>>> Instead of having these download bundles I think it would be better to have
>>> downloads for each individual thing:
>>>
>>> keycloak-bundle-<version>.zip
>>>
>>> - keycloak-<version>
>>>     - bin
>>>     - deployments/auth-server.war (exploded)
>>>     - ..
>>>
>>> keycloak-war.zip
>>>
>>> - auth-server.war (exploded)
>>> - auth-server.war.dodeploy
>>> - keycloak-ds.xml
>>>
>>> keycloak-wildfly-adapter.zip
>>> keycloak-eap-adapter.zip
>>> keycloak-as7-adapter.zip
>>>
>>
>> Poms are set up to do this so not a problem.
>>
>>> Reason for this is that it allows devs to download what they want rather
>>> than a huge bundle. For example:
>>>
>>> * To install the server all you want is the server
>>> * If running Keycloak on OpenShift all you need is the one adapter for
>>> whatever application server you're using
>>>
>>> We could move examples into a separate github project and the documentation
>>> would instruct people to get it from there. That way we can add/edit
>>> examples after a release. This is the way JDF does it, and I would think
>>> that eventually Keycloak examples would be moved into there.
>>>
>>
>> Not everybody knows how to use Github :)  Plus, you need examples tied
>> to release versions as there may be differences between them.
>>
>>> It may also be good to have these zips available in Maven central as that
>>> makes it simpler for other projects to build their own distributions that
>>> includes Keycloak. I can imagine AeroGear guys may be interested in that.
>>>
>>
>> Simple enough.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From ssilvert at redhat.com  Thu Jan  9 14:11:52 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 09 Jan 2014 14:11:52 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52C5EBC8.6030204@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>	<52C5D196.1090603@redhat.com>
	<52C5DBD5.2040801@redhat.com> <52C5EBC8.6030204@redhat.com>
Message-ID: <52CEF478.9060501@redhat.com>

I'm seeing this again with the latest build.  It doesn't happen on the
admin console but does occur whenever I try to hit a secured page of one
of the apps.

What was the secret to get past it?

On 1/2/2014 5:44 PM, ssilvert at redhat.com wrote:
> Looks good now.
>
> On 1/2/2014 4:36 PM, Bill Burke wrote:
>> Let me know if it works now.  I was able to get it running with WF8CR1 
>> after modifying jboss-deployment-structure.xml
>>
>>
>>
>> On 1/2/2014 3:52 PM, Bill Burke wrote:
>>> Demo works, but admin console login doesn't.  Seems to be a classloader
>>> issue with Wildfly 8cr1.
>>>
>>> On 1/2/2014 3:41 PM, Bill Burke wrote:
>>>> It should be working.  I'll take a look.
>>>>
>>>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>>>> Should the WildFly demo be working right now?  I built the latest and
>>>>> deployed.  It looked like it was working.  Then I started getting this
>>>>> every time I hit the customer-portal:
>>>>>
>>>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>>>> 60)): expected a valid value (number, String, array, object, 'true',
>>>>> 'false' or 'null') at [Source:
>>>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>>>
>>>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>>>> Happy New Year :)
>>>>>>>
>>>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>>>
>>>>>> Want to do it ASAP.
>>>>>>
>>>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>>>> Was going to start on docs after dist was finalized.  There's still a
>>>>>> little bit of work to do there.  See below.
>>>>>>
>>>>>>> * Logo - Gabriel are you looking at this?
>>>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>>>> site together, fine with me, but this isn't a skill set I have.
>>>>>>
>>>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>>>> ssh key.
>>>>>>
>>>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>>>> Quickstart?
>>>>>>
>>>>>> For dist, I was going to provide the following downloads:
>>>>>>
>>>>>> Zip 1 Appliance:
>>>>>> * examples/as7-eap-demo
>>>>>> * examples/wildfly-demo
>>>>>> * docs/
>>>>>> * A pre-configured Wildfly CR1 Dist
>>>>>> * adapters packaged as different jboss modules zips
>>>>>> * lib/as7-adapter
>>>>>> * lib/wildfly-adapter
>>>>>> * exploded server WAR
>>>>>>
>>>>>> Zip 2:
>>>>>> * examples/docs
>>>>>> * adapters packaged as different jboss modules zips
>>>>>> * lib/as7-adapter
>>>>>> * lib/wildfly-adapter
>>>>>> * exploded server WAR
>>>>>>
>>>>>> We would still need the following components to build on top of a
>>>>>> Wildfly minimal dist:
>>>>>>
>>>>>> * Embeddable DB
>>>>>> * JPA
>>>>>> * Web
>>>>>> * JAX-RS
>>>>>>
>>>>>> I was actually thinking of writing a utility that scanned a jboss
>>>>>> module's dist to determine subsystems and their dependencies.  Its
>>>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>


From bburke at redhat.com  Thu Jan  9 14:17:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 09 Jan 2014 14:17:55 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52CEF478.9060501@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>	<52C5D196.1090603@redhat.com>	<52C5DBD5.2040801@redhat.com>
	<52C5EBC8.6030204@redhat.com> <52CEF478.9060501@redhat.com>
Message-ID: <52CEF5E3.3040908@redhat.com>

Are you sure you've built from latest examples/code?

On 1/9/2014 2:11 PM, ssilvert at redhat.com wrote:
> I'm seeing this again with the latest build.  It doesn't happen on the
> admin console but does occur whenever I try to hit a secured page of one
> of the apps.
>
> What was the secret to get past it?
>
> On 1/2/2014 5:44 PM, ssilvert at redhat.com wrote:
>> Looks good now.
>>
>> On 1/2/2014 4:36 PM, Bill Burke wrote:
>>> Let me know if it works now.  I was able to get it running with WF8CR1
>>> after modifying jboss-deployment-structure.xml
>>>
>>>
>>>
>>> On 1/2/2014 3:52 PM, Bill Burke wrote:
>>>> Demo works, but admin console login doesn't.  Seems to be a classloader
>>>> issue with Wildfly 8cr1.
>>>>
>>>> On 1/2/2014 3:41 PM, Bill Burke wrote:
>>>>> It should be working.  I'll take a look.
>>>>>
>>>>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>>>>> Should the WildFly demo be working right now?  I built the latest and
>>>>>> deployed.  It looked like it was working.  Then I started getting this
>>>>>> every time I hit the customer-portal:
>>>>>>
>>>>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>>>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>>>>> 60)): expected a valid value (number, String, array, object, 'true',
>>>>>> 'false' or 'null') at [Source:
>>>>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>>>>
>>>>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>>>>> Happy New Year :)
>>>>>>>>
>>>>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>>>>
>>>>>>> Want to do it ASAP.
>>>>>>>
>>>>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>>>>> Was going to start on docs after dist was finalized.  There's still a
>>>>>>> little bit of work to do there.  See below.
>>>>>>>
>>>>>>>> * Logo - Gabriel are you looking at this?
>>>>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>>>>> site together, fine with me, but this isn't a skill set I have.
>>>>>>>
>>>>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>>>>> ssh key.
>>>>>>>
>>>>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>>>>> Quickstart?
>>>>>>>
>>>>>>> For dist, I was going to provide the following downloads:
>>>>>>>
>>>>>>> Zip 1 Appliance:
>>>>>>> * examples/as7-eap-demo
>>>>>>> * examples/wildfly-demo
>>>>>>> * docs/
>>>>>>> * A pre-configured Wildfly CR1 Dist
>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>> * lib/as7-adapter
>>>>>>> * lib/wildfly-adapter
>>>>>>> * exploded server WAR
>>>>>>>
>>>>>>> Zip 2:
>>>>>>> * examples/docs
>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>> * lib/as7-adapter
>>>>>>> * lib/wildfly-adapter
>>>>>>> * exploded server WAR
>>>>>>>
>>>>>>> We would still need the following components to build on top of a
>>>>>>> Wildfly minimal dist:
>>>>>>>
>>>>>>> * Embeddable DB
>>>>>>> * JPA
>>>>>>> * Web
>>>>>>> * JAX-RS
>>>>>>>
>>>>>>> I was actually thinking of writing a utility that scanned a jboss
>>>>>>> module's dist to determine subsystems and their dependencies.  Its
>>>>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>

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

From ssilvert at redhat.com  Thu Jan  9 14:24:23 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 09 Jan 2014 14:24:23 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52CEF5E3.3040908@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>	<52C5D196.1090603@redhat.com>	<52C5DBD5.2040801@redhat.com>	<52C5EBC8.6030204@redhat.com>
	<52CEF478.9060501@redhat.com> <52CEF5E3.3040908@redhat.com>
Message-ID: <52CEF767.6060309@redhat.com>

On 1/9/2014 2:17 PM, Bill Burke wrote:
> Are you sure you've built from latest examples/code?
I merged the latest.  I do have some of my own changes mixed in so it
could definitely be my fault.  Just wondering what the problem was the
last time so I can figure out how to get past it.
>
> On 1/9/2014 2:11 PM, ssilvert at redhat.com wrote:
>> I'm seeing this again with the latest build.  It doesn't happen on the
>> admin console but does occur whenever I try to hit a secured page of one
>> of the apps.
>>
>> What was the secret to get past it?
>>
>> On 1/2/2014 5:44 PM, ssilvert at redhat.com wrote:
>>> Looks good now.
>>>
>>> On 1/2/2014 4:36 PM, Bill Burke wrote:
>>>> Let me know if it works now.  I was able to get it running with WF8CR1
>>>> after modifying jboss-deployment-structure.xml
>>>>
>>>>
>>>>
>>>> On 1/2/2014 3:52 PM, Bill Burke wrote:
>>>>> Demo works, but admin console login doesn't.  Seems to be a classloader
>>>>> issue with Wildfly 8cr1.
>>>>>
>>>>> On 1/2/2014 3:41 PM, Bill Burke wrote:
>>>>>> It should be working.  I'll take a look.
>>>>>>
>>>>>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>>>>>> Should the WildFly demo be working right now?  I built the latest and
>>>>>>> deployed.  It looked like it was working.  Then I started getting this
>>>>>>> every time I hit the customer-portal:
>>>>>>>
>>>>>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>>>>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>>>>>> 60)): expected a valid value (number, String, array, object, 'true',
>>>>>>> 'false' or 'null') at [Source:
>>>>>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>>>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>>>>>
>>>>>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>>>>>> Happy New Year :)
>>>>>>>>>
>>>>>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>>>>>
>>>>>>>> Want to do it ASAP.
>>>>>>>>
>>>>>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>>>>>> Was going to start on docs after dist was finalized.  There's still a
>>>>>>>> little bit of work to do there.  See below.
>>>>>>>>
>>>>>>>>> * Logo - Gabriel are you looking at this?
>>>>>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>>>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>>>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>>>>>> site together, fine with me, but this isn't a skill set I have.
>>>>>>>>
>>>>>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>>>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>>>>>> ssh key.
>>>>>>>>
>>>>>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>>>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>>>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>>>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>>>>>> Quickstart?
>>>>>>>>
>>>>>>>> For dist, I was going to provide the following downloads:
>>>>>>>>
>>>>>>>> Zip 1 Appliance:
>>>>>>>> * examples/as7-eap-demo
>>>>>>>> * examples/wildfly-demo
>>>>>>>> * docs/
>>>>>>>> * A pre-configured Wildfly CR1 Dist
>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>> * lib/as7-adapter
>>>>>>>> * lib/wildfly-adapter
>>>>>>>> * exploded server WAR
>>>>>>>>
>>>>>>>> Zip 2:
>>>>>>>> * examples/docs
>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>> * lib/as7-adapter
>>>>>>>> * lib/wildfly-adapter
>>>>>>>> * exploded server WAR
>>>>>>>>
>>>>>>>> We would still need the following components to build on top of a
>>>>>>>> Wildfly minimal dist:
>>>>>>>>
>>>>>>>> * Embeddable DB
>>>>>>>> * JPA
>>>>>>>> * Web
>>>>>>>> * JAX-RS
>>>>>>>>
>>>>>>>> I was actually thinking of writing a utility that scanned a jboss
>>>>>>>> module's dist to determine subsystems and their dependencies.  Its
>>>>>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>


From bburke at redhat.com  Thu Jan  9 14:42:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 09 Jan 2014 14:42:23 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52CEF767.6060309@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>	<52C5D196.1090603@redhat.com>	<52C5DBD5.2040801@redhat.com>	<52C5EBC8.6030204@redhat.com>	<52CEF478.9060501@redhat.com>
	<52CEF5E3.3040908@redhat.com> <52CEF767.6060309@redhat.com>
Message-ID: <52CEFB9F.4090804@redhat.com>

It was an implicit import problem last time.  Had to muck with 
jboss-structure-deployment.xml

On 1/9/2014 2:24 PM, ssilvert at redhat.com wrote:
> On 1/9/2014 2:17 PM, Bill Burke wrote:
>> Are you sure you've built from latest examples/code?
> I merged the latest.  I do have some of my own changes mixed in so it
> could definitely be my fault.  Just wondering what the problem was the
> last time so I can figure out how to get past it.
>>
>> On 1/9/2014 2:11 PM, ssilvert at redhat.com wrote:
>>> I'm seeing this again with the latest build.  It doesn't happen on the
>>> admin console but does occur whenever I try to hit a secured page of one
>>> of the apps.
>>>
>>> What was the secret to get past it?
>>>
>>> On 1/2/2014 5:44 PM, ssilvert at redhat.com wrote:
>>>> Looks good now.
>>>>
>>>> On 1/2/2014 4:36 PM, Bill Burke wrote:
>>>>> Let me know if it works now.  I was able to get it running with WF8CR1
>>>>> after modifying jboss-deployment-structure.xml
>>>>>
>>>>>
>>>>>
>>>>> On 1/2/2014 3:52 PM, Bill Burke wrote:
>>>>>> Demo works, but admin console login doesn't.  Seems to be a classloader
>>>>>> issue with Wildfly 8cr1.
>>>>>>
>>>>>> On 1/2/2014 3:41 PM, Bill Burke wrote:
>>>>>>> It should be working.  I'll take a look.
>>>>>>>
>>>>>>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>>>>>>> Should the WildFly demo be working right now?  I built the latest and
>>>>>>>> deployed.  It looked like it was working.  Then I started getting this
>>>>>>>> every time I hit the customer-portal:
>>>>>>>>
>>>>>>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>>>>>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>>>>>>> 60)): expected a valid value (number, String, array, object, 'true',
>>>>>>>> 'false' or 'null') at [Source:
>>>>>>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>>>>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>>>>>>
>>>>>>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>>>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>>>>>>> Happy New Year :)
>>>>>>>>>>
>>>>>>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>>>>>>
>>>>>>>>> Want to do it ASAP.
>>>>>>>>>
>>>>>>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>>>>>>> Was going to start on docs after dist was finalized.  There's still a
>>>>>>>>> little bit of work to do there.  See below.
>>>>>>>>>
>>>>>>>>>> * Logo - Gabriel are you looking at this?
>>>>>>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>>>>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>>>>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>>>>>>> site together, fine with me, but this isn't a skill set I have.
>>>>>>>>>
>>>>>>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>>>>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>>>>>>> ssh key.
>>>>>>>>>
>>>>>>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>>>>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>>>>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>>>>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>>>>>>> Quickstart?
>>>>>>>>>
>>>>>>>>> For dist, I was going to provide the following downloads:
>>>>>>>>>
>>>>>>>>> Zip 1 Appliance:
>>>>>>>>> * examples/as7-eap-demo
>>>>>>>>> * examples/wildfly-demo
>>>>>>>>> * docs/
>>>>>>>>> * A pre-configured Wildfly CR1 Dist
>>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>>> * lib/as7-adapter
>>>>>>>>> * lib/wildfly-adapter
>>>>>>>>> * exploded server WAR
>>>>>>>>>
>>>>>>>>> Zip 2:
>>>>>>>>> * examples/docs
>>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>>> * lib/as7-adapter
>>>>>>>>> * lib/wildfly-adapter
>>>>>>>>> * exploded server WAR
>>>>>>>>>
>>>>>>>>> We would still need the following components to build on top of a
>>>>>>>>> Wildfly minimal dist:
>>>>>>>>>
>>>>>>>>> * Embeddable DB
>>>>>>>>> * JPA
>>>>>>>>> * Web
>>>>>>>>> * JAX-RS
>>>>>>>>>
>>>>>>>>> I was actually thinking of writing a utility that scanned a jboss
>>>>>>>>> module's dist to determine subsystems and their dependencies.  Its
>>>>>>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Thu Jan  9 14:52:25 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 09 Jan 2014 14:52:25 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52CEFB9F.4090804@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>	<52C5D196.1090603@redhat.com>	<52C5DBD5.2040801@redhat.com>	<52C5EBC8.6030204@redhat.com>	<52CEF478.9060501@redhat.com>	<52CEF5E3.3040908@redhat.com>
	<52CEF767.6060309@redhat.com> <52CEFB9F.4090804@redhat.com>
Message-ID: <52CEFDF9.1010704@redhat.com>

It's definitely my fault.  A clean build runs fine.

On 1/9/2014 2:42 PM, Bill Burke wrote:
> It was an implicit import problem last time.  Had to muck with 
> jboss-structure-deployment.xml
>
> On 1/9/2014 2:24 PM, ssilvert at redhat.com wrote:
>> On 1/9/2014 2:17 PM, Bill Burke wrote:
>>> Are you sure you've built from latest examples/code?
>> I merged the latest.  I do have some of my own changes mixed in so it
>> could definitely be my fault.  Just wondering what the problem was the
>> last time so I can figure out how to get past it.
>>> On 1/9/2014 2:11 PM, ssilvert at redhat.com wrote:
>>>> I'm seeing this again with the latest build.  It doesn't happen on the
>>>> admin console but does occur whenever I try to hit a secured page of one
>>>> of the apps.
>>>>
>>>> What was the secret to get past it?
>>>>
>>>> On 1/2/2014 5:44 PM, ssilvert at redhat.com wrote:
>>>>> Looks good now.
>>>>>
>>>>> On 1/2/2014 4:36 PM, Bill Burke wrote:
>>>>>> Let me know if it works now.  I was able to get it running with WF8CR1
>>>>>> after modifying jboss-deployment-structure.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/2/2014 3:52 PM, Bill Burke wrote:
>>>>>>> Demo works, but admin console login doesn't.  Seems to be a classloader
>>>>>>> issue with Wildfly 8cr1.
>>>>>>>
>>>>>>> On 1/2/2014 3:41 PM, Bill Burke wrote:
>>>>>>>> It should be working.  I'll take a look.
>>>>>>>>
>>>>>>>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>>>>>>>> Should the WildFly demo be working right now?  I built the latest and
>>>>>>>>> deployed.  It looked like it was working.  Then I started getting this
>>>>>>>>> every time I hit the customer-portal:
>>>>>>>>>
>>>>>>>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>>>>>>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>>>>>>>> 60)): expected a valid value (number, String, array, object, 'true',
>>>>>>>>> 'false' or 'null') at [Source:
>>>>>>>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>>>>>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>>>>>>>
>>>>>>>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>>>>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>>>>>>>> Happy New Year :)
>>>>>>>>>>>
>>>>>>>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>>>>>>>
>>>>>>>>>> Want to do it ASAP.
>>>>>>>>>>
>>>>>>>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>>>>>>>> Was going to start on docs after dist was finalized.  There's still a
>>>>>>>>>> little bit of work to do there.  See below.
>>>>>>>>>>
>>>>>>>>>>> * Logo - Gabriel are you looking at this?
>>>>>>>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>>>>>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>>>>>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>>>>>>>> site together, fine with me, but this isn't a skill set I have.
>>>>>>>>>>
>>>>>>>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>>>>>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>>>>>>>> ssh key.
>>>>>>>>>>
>>>>>>>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>>>>>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>>>>>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>>>>>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>>>>>>>> Quickstart?
>>>>>>>>>>
>>>>>>>>>> For dist, I was going to provide the following downloads:
>>>>>>>>>>
>>>>>>>>>> Zip 1 Appliance:
>>>>>>>>>> * examples/as7-eap-demo
>>>>>>>>>> * examples/wildfly-demo
>>>>>>>>>> * docs/
>>>>>>>>>> * A pre-configured Wildfly CR1 Dist
>>>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>>>> * lib/as7-adapter
>>>>>>>>>> * lib/wildfly-adapter
>>>>>>>>>> * exploded server WAR
>>>>>>>>>>
>>>>>>>>>> Zip 2:
>>>>>>>>>> * examples/docs
>>>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>>>> * lib/as7-adapter
>>>>>>>>>> * lib/wildfly-adapter
>>>>>>>>>> * exploded server WAR
>>>>>>>>>>
>>>>>>>>>> We would still need the following components to build on top of a
>>>>>>>>>> Wildfly minimal dist:
>>>>>>>>>>
>>>>>>>>>> * Embeddable DB
>>>>>>>>>> * JPA
>>>>>>>>>> * Web
>>>>>>>>>> * JAX-RS
>>>>>>>>>>
>>>>>>>>>> I was actually thinking of writing a utility that scanned a jboss
>>>>>>>>>> module's dist to determine subsystems and their dependencies.  Its
>>>>>>>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Thu Jan  9 18:23:50 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 09 Jan 2014 18:23:50 -0500
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52CEFDF9.1010704@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>	<52C581CA.1070106@redhat.com>	<52C5A8A7.1010706@redhat.com>	<52C5CEE8.5030206@redhat.com>	<52C5D196.1090603@redhat.com>	<52C5DBD5.2040801@redhat.com>	<52C5EBC8.6030204@redhat.com>	<52CEF478.9060501@redhat.com>	<52CEF5E3.3040908@redhat.com>	<52CEF767.6060309@redhat.com>
	<52CEFB9F.4090804@redhat.com> <52CEFDF9.1010704@redhat.com>
Message-ID: <52CF2F86.7060006@redhat.com>

I spoke too soon.   I can recreate the problem with a clean build.  I
think restarting the server causes the problem.

1) unzip the appliance
2) start appliance
3) log into admin and import the demo realm
4) go to wildfly-demo and run mvn jboss-as:deploy
5) hit http://localhost:8080/customer-portal/customers/view.jsp
6) login as bburke at redhat.com
7) restart the server
8) try to hit http://localhost:8080/customer-portal/customers/view.jsp again
9) See exception below:

Context Path:
/customer-portal

Servlet Path:
/customers/view.jsp

Path Info:
null

Query String:
code=eyJhbGciOiJSUzI1NiJ9.MTliMzIwODItZDJmYy00ZGEwLTljZGEtOWRjOGJiMjFlNTFmMTM4OTMwOTIwODgxNQ.RRjX2D7VFhU0u7wpEAcRV0itleFa5UmCyCIZ4ltCON44Hm9sXr9Jc6gXJj1nWZAay7ONI07Fh1oxQodKJDSP1ROo2QsUWZhhOc3sQTPpsuOfm-D1kAGjelNoIY_d-HDe7gCT9qQMACJs-e6PmGZlIm5qZeAm8guZkNWgLaCnkqY&state=0%2F98f2b694-0cd3-4cc3-b442-48b0359f972d

*Stack Trace*
org.apache.jasper.JasperException: java.lang.RuntimeException:
org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
60)): expected a valid value (number, String, array, object, 'true',
'false' or 'null') at [Source:
org.apache.http.conn.EofSensorInputStream at 601dae5e; line: 1, column: 2]
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259)
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
org.keycloak.adapters.undertow.ServletPropagateSessionHandler.handleRequest(ServletPropagateSessionHandler.java:42)
org.keycloak.adapters.undertow.AuthenticatedActionsHandler.handleRequest(AuthenticatedActionsHandler.java:46)
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
org.keycloak.adapters.undertow.ServletAdminActionsHandler.handleRequest(ServletAdminActionsHandler.java:91)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:722)

On 1/9/2014 2:52 PM, ssilvert at redhat.com wrote:
> It's definitely my fault.  A clean build runs fine.
>
> On 1/9/2014 2:42 PM, Bill Burke wrote:
>> It was an implicit import problem last time.  Had to muck with 
>> jboss-structure-deployment.xml
>>
>> On 1/9/2014 2:24 PM, ssilvert at redhat.com wrote:
>>> On 1/9/2014 2:17 PM, Bill Burke wrote:
>>>> Are you sure you've built from latest examples/code?
>>> I merged the latest.  I do have some of my own changes mixed in so it
>>> could definitely be my fault.  Just wondering what the problem was the
>>> last time so I can figure out how to get past it.
>>>> On 1/9/2014 2:11 PM, ssilvert at redhat.com wrote:
>>>>> I'm seeing this again with the latest build.  It doesn't happen on the
>>>>> admin console but does occur whenever I try to hit a secured page of one
>>>>> of the apps.
>>>>>
>>>>> What was the secret to get past it?
>>>>>
>>>>> On 1/2/2014 5:44 PM, ssilvert at redhat.com wrote:
>>>>>> Looks good now.
>>>>>>
>>>>>> On 1/2/2014 4:36 PM, Bill Burke wrote:
>>>>>>> Let me know if it works now.  I was able to get it running with WF8CR1
>>>>>>> after modifying jboss-deployment-structure.xml
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/2/2014 3:52 PM, Bill Burke wrote:
>>>>>>>> Demo works, but admin console login doesn't.  Seems to be a classloader
>>>>>>>> issue with Wildfly 8cr1.
>>>>>>>>
>>>>>>>> On 1/2/2014 3:41 PM, Bill Burke wrote:
>>>>>>>>> It should be working.  I'll take a look.
>>>>>>>>>
>>>>>>>>> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
>>>>>>>>>> Should the WildFly demo be working right now?  I built the latest and
>>>>>>>>>> deployed.  It looked like it was working.  Then I started getting this
>>>>>>>>>> every time I hit the customer-portal:
>>>>>>>>>>
>>>>>>>>>> org.apache.jasper.JasperException: java.lang.RuntimeException:
>>>>>>>>>> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
>>>>>>>>>> 60)): expected a valid value (number, String, array, object, 'true',
>>>>>>>>>> 'false' or 'null') at [Source:
>>>>>>>>>> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
>>>>>>>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
>>>>>>>>>>
>>>>>>>>>> On 1/2/2014 10:12 AM, Bill Burke wrote:
>>>>>>>>>>> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
>>>>>>>>>>>> Happy New Year :)
>>>>>>>>>>>>
>>>>>>>>>>>> It would be great to release Keycloak alpha in a week or two. To get things started here's remaining work I'm aware of:
>>>>>>>>>>>>
>>>>>>>>>>> Want to do it ASAP.
>>>>>>>>>>>
>>>>>>>>>>>> * Documentation - what's the status of docs? I'm happy to review, and also write some as well
>>>>>>>>>>> Was going to start on docs after dist was finalized.  There's still a
>>>>>>>>>>> little bit of work to do there.  See below.
>>>>>>>>>>>
>>>>>>>>>>>> * Logo - Gabriel are you looking at this?
>>>>>>>>>>>> * Website - Should we update to the new JBoss community theme used by WildFly, Infinispan, PicketLink, etc.?
>>>>>>>>>>> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
>>>>>>>>>>> have no logo.  keycloak.org redirects there.  If somebody wants to put a
>>>>>>>>>>> site together, fine with me, but this isn't a skill set I have.
>>>>>>>>>>>
>>>>>>>>>>> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
>>>>>>>>>>> Pretty sure we have a keycloak directory there that is hooked up via my
>>>>>>>>>>> ssh key.
>>>>>>>>>>>
>>>>>>>>>>>> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a new minimal dist, maybe we could use this to reduce the dl size?
>>>>>>>>>>> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
>>>>>>>>>>> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
>>>>>>>>>>> you familiar with Docbook?  Can you write up how to set up the Openshift
>>>>>>>>>>> Quickstart?
>>>>>>>>>>>
>>>>>>>>>>> For dist, I was going to provide the following downloads:
>>>>>>>>>>>
>>>>>>>>>>> Zip 1 Appliance:
>>>>>>>>>>> * examples/as7-eap-demo
>>>>>>>>>>> * examples/wildfly-demo
>>>>>>>>>>> * docs/
>>>>>>>>>>> * A pre-configured Wildfly CR1 Dist
>>>>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>>>>> * lib/as7-adapter
>>>>>>>>>>> * lib/wildfly-adapter
>>>>>>>>>>> * exploded server WAR
>>>>>>>>>>>
>>>>>>>>>>> Zip 2:
>>>>>>>>>>> * examples/docs
>>>>>>>>>>> * adapters packaged as different jboss modules zips
>>>>>>>>>>> * lib/as7-adapter
>>>>>>>>>>> * lib/wildfly-adapter
>>>>>>>>>>> * exploded server WAR
>>>>>>>>>>>
>>>>>>>>>>> We would still need the following components to build on top of a
>>>>>>>>>>> Wildfly minimal dist:
>>>>>>>>>>>
>>>>>>>>>>> * Embeddable DB
>>>>>>>>>>> * JPA
>>>>>>>>>>> * Web
>>>>>>>>>>> * JAX-RS
>>>>>>>>>>>
>>>>>>>>>>> I was actually thinking of writing a utility that scanned a jboss
>>>>>>>>>>> module's dist to determine subsystems and their dependencies.  Its
>>>>>>>>>>> pretty difficult to figure out now with the current Wildfly build.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>
>>> _______________________________________________
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140109/2204bb05/attachment-0001.html 

From stian at redhat.com  Fri Jan 10 05:43:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 05:43:41 -0500 (EST)
Subject: [keycloak-dev] WildFly demo?
In-Reply-To: <52CF2F86.7060006@redhat.com>
References: <1607290265.40942810.1388648441620.JavaMail.root@redhat.com>
	<52C5EBC8.6030204@redhat.com> <52CEF478.9060501@redhat.com>
	<52CEF5E3.3040908@redhat.com> <52CEF767.6060309@redhat.com>
	<52CEFB9F.4090804@redhat.com> <52CEFDF9.1010704@redhat.com>
	<52CF2F86.7060006@redhat.com>
Message-ID: <1734702611.48097338.1389350621505.JavaMail.root@redhat.com>

I've seen this as well: https://issues.jboss.org/browse/KEYCLOAK-256

----- Original Message -----
> From: ssilvert at redhat.com
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 9 January, 2014 11:23:50 PM
> Subject: Re: [keycloak-dev] WildFly demo?
> 
> I spoke too soon. I can recreate the problem with a clean build. I think
> restarting the server causes the problem.
> 
> 1) unzip the appliance
> 2) start appliance
> 3) log into admin and import the demo realm
> 4) go to wildfly-demo and run mvn jboss-as:deploy
> 5) hit http://localhost:8080/customer-portal/customers/view.jsp
> 6) login as bburke at redhat.com
> 7) restart the server
> 8) try to hit http://localhost:8080/customer-portal/customers/view.jsp again
> 9) See exception below:
> 
> Context Path:
> /customer-portal
> 
> Servlet Path:
> /customers/view.jsp
> 
> Path Info:
> null
> 
> Query String:
> code=eyJhbGciOiJSUzI1NiJ9.MTliMzIwODItZDJmYy00ZGEwLTljZGEtOWRjOGJiMjFlNTFmMTM4OTMwOTIwODgxNQ.RRjX2D7VFhU0u7wpEAcRV0itleFa5UmCyCIZ4ltCON44Hm9sXr9Jc6gXJj1nWZAay7ONI07Fh1oxQodKJDSP1ROo2QsUWZhhOc3sQTPpsuOfm-D1kAGjelNoIY_d-HDe7gCT9qQMACJs-e6PmGZlIm5qZeAm8guZkNWgLaCnkqY&state=0%2F98f2b694-0cd3-4cc3-b442-48b0359f972d
> 
> Stack Trace
> org.apache.jasper.JasperException: java.lang.RuntimeException:
> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
> 60)): expected a valid value (number, String, array, object, 'true', 'false'
> or 'null') at [Source: org.apache.http.conn.EofSensorInputStream at 601dae5e;
> line: 1, column: 2]
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> org.keycloak.adapters.undertow.ServletPropagateSessionHandler.handleRequest(ServletPropagateSessionHandler.java:42)
> org.keycloak.adapters.undertow.AuthenticatedActionsHandler.handleRequest(AuthenticatedActionsHandler.java:46)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> org.keycloak.adapters.undertow.ServletAdminActionsHandler.handleRequest(ServletAdminActionsHandler.java:91)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:722)
> 
> On 1/9/2014 2:52 PM, ssilvert at redhat.com wrote:
> 
> 
> 
> It's definitely my fault.  A clean build runs fine.
> 
> On 1/9/2014 2:42 PM, Bill Burke wrote:
> 
> 
> 
> It was an implicit import problem last time.  Had to muck with
> jboss-structure-deployment.xml
> 
> On 1/9/2014 2:24 PM, ssilvert at redhat.com wrote:
> 
> 
> 
> On 1/9/2014 2:17 PM, Bill Burke wrote:
> 
> 
> 
> Are you sure you've built from latest examples/code?
> I merged the latest.  I do have some of my own changes mixed in so it
> could definitely be my fault.  Just wondering what the problem was the
> last time so I can figure out how to get past it.
> 
> 
> 
> On 1/9/2014 2:11 PM, ssilvert at redhat.com wrote:
> 
> 
> 
> I'm seeing this again with the latest build.  It doesn't happen on the
> admin console but does occur whenever I try to hit a secured page of one
> of the apps.
> 
> What was the secret to get past it?
> 
> On 1/2/2014 5:44 PM, ssilvert at redhat.com wrote:
> 
> 
> 
> Looks good now.
> 
> On 1/2/2014 4:36 PM, Bill Burke wrote:
> 
> 
> 
> Let me know if it works now.  I was able to get it running with WF8CR1
> after modifying jboss-deployment-structure.xml
> 
> 
> 
> On 1/2/2014 3:52 PM, Bill Burke wrote:
> 
> 
> 
> Demo works, but admin console login doesn't.  Seems to be a classloader
> issue with Wildfly 8cr1.
> 
> On 1/2/2014 3:41 PM, Bill Burke wrote:
> 
> 
> 
> It should be working.  I'll take a look.
> 
> On 1/2/2014 12:57 PM, ssilvert at redhat.com wrote:
> 
> 
> 
> Should the WildFly demo be working right now?  I built the latest and
> deployed.  It looked like it was working.  Then I started getting this
> every time I hit the customer-portal:
> 
> org.apache.jasper.JasperException: java.lang.RuntimeException:
> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code
> 60)): expected a valid value (number, String, array, object, 'true',
> 'false' or 'null') at [Source:
> org.apache.http.conn.EofSensorInputStream at 5dbf7b27; line: 1, column: 2]
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
> 
> On 1/2/2014 10:12 AM, Bill Burke wrote:
> 
> 
> 
> On 1/2/2014 2:40 AM, Stian Thorgersen wrote:
> 
> 
> 
> Happy New Year :)
> 
> It would be great to release Keycloak alpha in a week or two. To get things
> started here's remaining work I'm aware of:
> Want to do it ASAP.
> 
> 
> 
> * Documentation - what's the status of docs? I'm happy to review, and also
> write some as well
> Was going to start on docs after dist was finalized.  There's still a
> little bit of work to do there.  See below.
> 
> 
> 
> * Logo - Gabriel are you looking at this?
> * Website - Should we update to the new JBoss community theme used by
> WildFly, Infinispan, PicketLink, etc.?
> jboss.org/keycloak is sufficient at the moment, IMO.  Especially if we
> have no logo.  keycloak.org redirects there.  If somebody wants to put a
> site together, fine with me, but this isn't a skill set I have.
> 
> Jason told me that wildfly.org is on filemgmt.jboss.org/www_htdocs.
> Pretty sure we have a keycloak directory there that is hooked up via my
> ssh key.
> 
> 
> 
> * Dist/examples - Upgrade to WildFly CR1. With WildFly CR1 they introduced a
> new minimal dist, maybe we could use this to reduce the dl size?
> What's status on Openshift Quickstart?  FYI, patching AS7 is no longer
> required to run on AS7.  Please see examples/as7-eap-demo/server.  Are
> you familiar with Docbook?  Can you write up how to set up the Openshift
> Quickstart?
> 
> For dist, I was going to provide the following downloads:
> 
> Zip 1 Appliance:
> * examples/as7-eap-demo
> * examples/wildfly-demo
> * docs/
> * A pre-configured Wildfly CR1 Dist
> * adapters packaged as different jboss modules zips
> * lib/as7-adapter
> * lib/wildfly-adapter
> * exploded server WAR
> 
> Zip 2:
> * examples/docs
> * adapters packaged as different jboss modules zips
> * lib/as7-adapter
> * lib/wildfly-adapter
> * exploded server WAR
> 
> We would still need the following components to build on top of a
> Wildfly minimal dist:
> 
> * Embeddable DB
> * JPA
> * Web
> * JAX-RS
> 
> I was actually thinking of writing a utility that scanned a jboss
> module's dist to determine subsystems and their dependencies.  Its
> pretty difficult to figure out now with the current Wildfly build.
> _______________________________________________
> 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
> _______________________________________________
> 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
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mposolda at redhat.com  Fri Jan 10 05:51:53 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Jan 2014 11:51:53 +0100
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <52CEE083.1090502@redhat.com>
References: <52CC5F9F.9070000@redhat.com>	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>	<52CECD16.1080500@redhat.com>	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
	<52CEE083.1090502@redhat.com>
Message-ID: <52CFD0C9.9080307@redhat.com>

Just a small note that there is a typo in 
https://github.com/keycloak/keycloak/blob/master/examples/as7-eap-demo/README.md 
in step1. For EAP 6.x it should be "keycloak-eap6-adapter-dist.zip" when 
currently it talks about "keycloak-as7-adapter-dist.zip" .

Another possible good thing would be to have "quickstart" appliance for 
everything bundled in single ZIP (wildfly server with auth-server, 
datasource, adapters, test-realm installed and all examples deployed). 
This will enable possibility for users to start really quickly playing 
with Keycloak without need to import realm in admin-console and 
build/deploy examples with maven. Of course, this may not be possible if 
examples will be moved to separate repo.

Marek

On 9.1.2014 18:46, Bill Burke wrote:
> Yes, but make it harder for users.
>
> its jbs.xml and also web.xml
>
> On 1/9/2014 12:21 PM, Stian Thorgersen wrote:
>> Is the only difference between the 3 examples the name of the adapter in jboss-deployment-structure?
>>
>> If so could we not do either:
>>
>> * Maven profiles to template these files with the adapter module name
>> * Use same module name for the adapters?
>>
>> That would make it a lot easier to make sure the examples are in-sync.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 9 January, 2014 4:23:50 PM
>>> Subject: Re: [keycloak-dev] examples/distro reworked/improved/finalized PLEASE TRY!
>>>
>>>
>>>
>>> On 1/9/2014 10:18 AM, Stian Thorgersen wrote:
>>>> I haven't had much time to play with this yet, but will do today/tomorrow.
>>>> Although if you're not accepting PRs after today, there may not be any
>>>> point? There's two outstanding PRs related to examples are you going to
>>>> merge those?
>>>>
>>>> Some comments on the distributions:
>>>>
>>>> Instead of having these download bundles I think it would be better to have
>>>> downloads for each individual thing:
>>>>
>>>> keycloak-bundle-<version>.zip
>>>>
>>>> - keycloak-<version>
>>>>      - bin
>>>>      - deployments/auth-server.war (exploded)
>>>>      - ..
>>>>
>>>> keycloak-war.zip
>>>>
>>>> - auth-server.war (exploded)
>>>> - auth-server.war.dodeploy
>>>> - keycloak-ds.xml
>>>>
>>>> keycloak-wildfly-adapter.zip
>>>> keycloak-eap-adapter.zip
>>>> keycloak-as7-adapter.zip
>>>>
>>> Poms are set up to do this so not a problem.
>>>
>>>> Reason for this is that it allows devs to download what they want rather
>>>> than a huge bundle. For example:
>>>>
>>>> * To install the server all you want is the server
>>>> * If running Keycloak on OpenShift all you need is the one adapter for
>>>> whatever application server you're using
>>>>
>>>> We could move examples into a separate github project and the documentation
>>>> would instruct people to get it from there. That way we can add/edit
>>>> examples after a release. This is the way JDF does it, and I would think
>>>> that eventually Keycloak examples would be moved into there.
>>>>
>>> Not everybody knows how to use Github :)  Plus, you need examples tied
>>> to release versions as there may be differences between them.
>>>
>>>> It may also be good to have these zips available in Maven central as that
>>>> makes it simpler for other projects to build their own distributions that
>>>> includes Keycloak. I can imagine AeroGear guys may be interested in that.
>>>>
>>> Simple enough.
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>


From stian at redhat.com  Fri Jan 10 09:09:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 09:09:56 -0500 (EST)
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <1176551821.47512838.1389284785183.JavaMail.root@redhat.com>
References: <52CC6188.1000608@redhat.com>
	<1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
	<52CECC69.4080207@redhat.com>
	<1176551821.47512838.1389284785183.JavaMail.root@redhat.com>
Message-ID: <683056165.48245070.1389362996437.JavaMail.root@redhat.com>

There's still some outstanding issues, and some PRs to commit

PRs:

* Marek has spent a fair amount of time to update the third-party example to JSF. I think we should at least commit this, and possibly also update the other examples to JSF (there's not many people that use JSP any more). We should also make sure the different versions of the examples are in-sync.
* There's some issues in example README's some of which are fixed in a PR by Karel Piwko
* OAuth Client installation page - to configure a "third party" app you need the same info as to configure an app, so I've added an installation page under clients
* Rename prn to sub - this has been renamed in the JWT spec a long time ago, and we should commit this before we push an alpha

Outstanding issues:

* ClassCastException (https://issues.jboss.org/browse/KEYCLOAK-256) - seems to be a Resteasy issue (this is a blocker IMO)
* /auth-server/admin/ doesn't work (https://issues.jboss.org/browse/KEYCLOAK-255) - this is a WildFly issue but we can add a simple work-around
* Style issue in realm import (https://issues.jboss.org/browse/KEYCLOAK-257)
* No warning if require SSL is enabled and not using https (https://issues.jboss.org/browse/KEYCLOAK-252) - If this option is enabled neither the admin console or account mngt works, they just redisplay the login form without any warning. I propose that we add a simple check to RealmsResource#getTokenService that returns an error page if realm requires ssl and request is not https://.....

I propose that we hold off the release a few days, so we can get the above issues resolved. Also, it would give us a bit more time to test the examples and review docs when they are ready. We can aim for "code freeze" on Monday, with a release on Wednesday?


----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 9 January, 2014 4:26:25 PM
> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 9 January, 2014 4:20:57 PM
> > Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> > 
> > 
> > 
> > On 1/9/2014 10:21 AM, Stian Thorgersen wrote:
> > > Would be good to have a chance to read through docs before we submit.
> > > Also
> > > there's at least a few issues outstanding that I think should be fixed
> > > prior to alpha release:
> > >
> > 
> > Working on it.
> > 
> > > https://issues.jboss.org/browse/KEYCLOAK-251
> > >
> > 
> > What is "Installation missing for clients"?
> 
> In admin console for applications you can go to installation and get the json
> snippet required to configure the adapter. We need the same for oauth
> clients.
> 
> I can probably sort out those 3 issues tomorrow. The rest of the issues in
> JIRA with ff M1 can be pushed back IMO.
> 
> > 
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Tuesday, 7 January, 2014 8:20:24 PM
> > >> Subject: [keycloak-dev] Release next Monday or Tuesday
> > >>
> > >> I'll bang hard on the documentation this week so we can release Alpha 1
> > >> next Monday.  Let not commit an PRs after Thursday please!
> > >> --
> > >> Bill Burke
> > >> JBoss, a division of Red Hat
> > >> http://bill.burkecentral.com
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Jan 10 09:23:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 09:23:04 -0500
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <52CFD0C9.9080307@redhat.com>
References: <52CC5F9F.9070000@redhat.com>	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>	<52CECD16.1080500@redhat.com>	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
	<52CEE083.1090502@redhat.com> <52CFD0C9.9080307@redhat.com>
Message-ID: <52D00248.70407@redhat.com>



On 1/10/2014 5:51 AM, Marek Posolda wrote:
> Just a small note that there is a typo in
> https://github.com/keycloak/keycloak/blob/master/examples/as7-eap-demo/README.md
> in step1. For EAP 6.x it should be "keycloak-eap6-adapter-dist.zip" when
> currently it talks about "keycloak-as7-adapter-dist.zip" .
>

Good catch.

> Another possible good thing would be to have "quickstart" appliance for
> everything bundled in single ZIP (wildfly server with auth-server,
> datasource, adapters, test-realm installed and all examples deployed).
> This will enable possibility for users to start really quickly playing
> with Keycloak without need to import realm in admin-console and
> build/deploy examples with maven. Of course, this may not be possible if
> examples will be moved to separate repo.
>

That's a *REALLY* good idea.  I'll do that.

BTW, not sure about your addition to CDI yet to one of the examples.  We 
will be trimming down the Wildfly distro in the near future and CDI will 
be one of the subsystems that will be removed.

Bill

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

From bburke at redhat.com  Fri Jan 10 09:30:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 09:30:47 -0500
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <683056165.48245070.1389362996437.JavaMail.root@redhat.com>
References: <52CC6188.1000608@redhat.com>
	<1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
	<52CECC69.4080207@redhat.com>
	<1176551821.47512838.1389284785183.JavaMail.root@redhat.com>
	<683056165.48245070.1389362996437.JavaMail.root@redhat.com>
Message-ID: <52D00417.4040405@redhat.com>

I'm fine with this as long as no further things pop up.  This is an 
alpha release and so long as it is functional, we're good.

I'm not sure about the JSF example addition.  I want all the examples to 
work off of the appliance (and pre-configured as marek suggested), and 
the appliance will be trimmed down to remove CDI/JSF in the future. 
People don't use JSP anymore, but so what?  The examples are very 
minimal on purpose because they focus on keycloak.  But, I've always 
wanted nice example applications in addition to these simple examples 
(like event juggler) so users can also see other technologies 
interacting with keycloak.


On 1/10/2014 9:09 AM, Stian Thorgersen wrote:
> There's still some outstanding issues, and some PRs to commit
>
> PRs:
>
> * Marek has spent a fair amount of time to update the third-party example to JSF. I think we should at least commit this, and possibly also update the other examples to JSF (there's not many people that use JSP any more). We should also make sure the different versions of the examples are in-sync.
> * There's some issues in example README's some of which are fixed in a PR by Karel Piwko
> * OAuth Client installation page - to configure a "third party" app you need the same info as to configure an app, so I've added an installation page under clients
> * Rename prn to sub - this has been renamed in the JWT spec a long time ago, and we should commit this before we push an alpha
>
> Outstanding issues:
>
> * ClassCastException (https://issues.jboss.org/browse/KEYCLOAK-256) - seems to be a Resteasy issue (this is a blocker IMO)
> * /auth-server/admin/ doesn't work (https://issues.jboss.org/browse/KEYCLOAK-255) - this is a WildFly issue but we can add a simple work-around
> * Style issue in realm import (https://issues.jboss.org/browse/KEYCLOAK-257)
> * No warning if require SSL is enabled and not using https (https://issues.jboss.org/browse/KEYCLOAK-252) - If this option is enabled neither the admin console or account mngt works, they just redisplay the login form without any warning. I propose that we add a simple check to RealmsResource#getTokenService that returns an error page if realm requires ssl and request is not https://.....
>
> I propose that we hold off the release a few days, so we can get the above issues resolved. Also, it would give us a bit more time to test the examples and review docs when they are ready. We can aim for "code freeze" on Monday, with a release on Wednesday?
>
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 9 January, 2014 4:26:25 PM
>> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
>>
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 9 January, 2014 4:20:57 PM
>>> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
>>>
>>>
>>>
>>> On 1/9/2014 10:21 AM, Stian Thorgersen wrote:
>>>> Would be good to have a chance to read through docs before we submit.
>>>> Also
>>>> there's at least a few issues outstanding that I think should be fixed
>>>> prior to alpha release:
>>>>
>>>
>>> Working on it.
>>>
>>>> https://issues.jboss.org/browse/KEYCLOAK-251
>>>>
>>>
>>> What is "Installation missing for clients"?
>>
>> In admin console for applications you can go to installation and get the json
>> snippet required to configure the adapter. We need the same for oauth
>> clients.
>>
>> I can probably sort out those 3 issues tomorrow. The rest of the issues in
>> JIRA with ff M1 can be pushed back IMO.
>>
>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Tuesday, 7 January, 2014 8:20:24 PM
>>>>> Subject: [keycloak-dev] Release next Monday or Tuesday
>>>>>
>>>>> I'll bang hard on the documentation this week so we can release Alpha 1
>>>>> next Monday.  Let not commit an PRs after Thursday please!
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Fri Jan 10 09:43:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 09:43:54 -0500 (EST)
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <52D00417.4040405@redhat.com>
References: <52CC6188.1000608@redhat.com>
	<1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
	<52CECC69.4080207@redhat.com>
	<1176551821.47512838.1389284785183.JavaMail.root@redhat.com>
	<683056165.48245070.1389362996437.JavaMail.root@redhat.com>
	<52D00417.4040405@redhat.com>
Message-ID: <189658621.48268418.1389365034850.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 January, 2014 2:30:47 PM
> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> 
> I'm fine with this as long as no further things pop up.  This is an
> alpha release and so long as it is functional, we're good.

Sure, I can sort out the issues I listed, except it would be good if you could have a look at https://issues.jboss.org/browse/KEYCLOAK-256.

> 
> I'm not sure about the JSF example addition.  I want all the examples to
> work off of the appliance (and pre-configured as marek suggested), and
> the appliance will be trimmed down to remove CDI/JSF in the future.
> People don't use JSP anymore, but so what?  The examples are very
> minimal on purpose because they focus on keycloak.  But, I've always
> wanted nice example applications in addition to these simple examples
> (like event juggler) so users can also see other technologies
> interacting with keycloak.

Makes sense. Just one question though, once the WildFly subsystem is ready, wouldn't the trimmed down appliance also not have support for JavaEE/deployments altogether? I think it makes sense to have two options for Keycloak (embedded in a fully functional WildFly/EAP, and a standalone that doesn't allow deployments of any sort).

> 
> 
> On 1/10/2014 9:09 AM, Stian Thorgersen wrote:
> > There's still some outstanding issues, and some PRs to commit
> >
> > PRs:
> >
> > * Marek has spent a fair amount of time to update the third-party example
> > to JSF. I think we should at least commit this, and possibly also update
> > the other examples to JSF (there's not many people that use JSP any more).
> > We should also make sure the different versions of the examples are
> > in-sync.
> > * There's some issues in example README's some of which are fixed in a PR
> > by Karel Piwko
> > * OAuth Client installation page - to configure a "third party" app you
> > need the same info as to configure an app, so I've added an installation
> > page under clients
> > * Rename prn to sub - this has been renamed in the JWT spec a long time
> > ago, and we should commit this before we push an alpha
> >
> > Outstanding issues:
> >
> > * ClassCastException (https://issues.jboss.org/browse/KEYCLOAK-256) - seems
> > to be a Resteasy issue (this is a blocker IMO)
> > * /auth-server/admin/ doesn't work
> > (https://issues.jboss.org/browse/KEYCLOAK-255) - this is a WildFly issue
> > but we can add a simple work-around
> > * Style issue in realm import
> > (https://issues.jboss.org/browse/KEYCLOAK-257)
> > * No warning if require SSL is enabled and not using https
> > (https://issues.jboss.org/browse/KEYCLOAK-252) - If this option is enabled
> > neither the admin console or account mngt works, they just redisplay the
> > login form without any warning. I propose that we add a simple check to
> > RealmsResource#getTokenService that returns an error page if realm
> > requires ssl and request is not https://.....
> >
> > I propose that we hold off the release a few days, so we can get the above
> > issues resolved. Also, it would give us a bit more time to test the
> > examples and review docs when they are ready. We can aim for "code freeze"
> > on Monday, with a release on Wednesday?
> >
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 9 January, 2014 4:26:25 PM
> >> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, 9 January, 2014 4:20:57 PM
> >>> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> >>>
> >>>
> >>>
> >>> On 1/9/2014 10:21 AM, Stian Thorgersen wrote:
> >>>> Would be good to have a chance to read through docs before we submit.
> >>>> Also
> >>>> there's at least a few issues outstanding that I think should be fixed
> >>>> prior to alpha release:
> >>>>
> >>>
> >>> Working on it.
> >>>
> >>>> https://issues.jboss.org/browse/KEYCLOAK-251
> >>>>
> >>>
> >>> What is "Installation missing for clients"?
> >>
> >> In admin console for applications you can go to installation and get the
> >> json
> >> snippet required to configure the adapter. We need the same for oauth
> >> clients.
> >>
> >> I can probably sort out those 3 issues tomorrow. The rest of the issues in
> >> JIRA with ff M1 can be pushed back IMO.
> >>
> >>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: keycloak-dev at lists.jboss.org
> >>>>> Sent: Tuesday, 7 January, 2014 8:20:24 PM
> >>>>> Subject: [keycloak-dev] Release next Monday or Tuesday
> >>>>>
> >>>>> I'll bang hard on the documentation this week so we can release Alpha 1
> >>>>> next Monday.  Let not commit an PRs after Thursday please!
> >>>>> --
> >>>>> Bill Burke
> >>>>> JBoss, a division of Red Hat
> >>>>> http://bill.burkecentral.com
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Fri Jan 10 10:27:42 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Jan 2014 16:27:42 +0100
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <52D00248.70407@redhat.com>
References: <52CC5F9F.9070000@redhat.com>	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>	<52CECD16.1080500@redhat.com>	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
	<52CEE083.1090502@redhat.com> <52CFD0C9.9080307@redhat.com>
	<52D00248.70407@redhat.com>
Message-ID: <52D0116E.1090402@redhat.com>

On 10.1.2014 15:23, Bill Burke wrote:
>
>
> On 1/10/2014 5:51 AM, Marek Posolda wrote:
>> Just a small note that there is a typo in
>> https://github.com/keycloak/keycloak/blob/master/examples/as7-eap-demo/README.md 
>>
>> in step1. For EAP 6.x it should be "keycloak-eap6-adapter-dist.zip" when
>> currently it talks about "keycloak-as7-adapter-dist.zip" .
>>
>
> Good catch.
>
>> Another possible good thing would be to have "quickstart" appliance for
>> everything bundled in single ZIP (wildfly server with auth-server,
>> datasource, adapters, test-realm installed and all examples deployed).
>> This will enable possibility for users to start really quickly playing
>> with Keycloak without need to import realm in admin-console and
>> build/deploy examples with maven. Of course, this may not be possible if
>> examples will be moved to separate repo.
>>
>
> That's a *REALLY* good idea.  I'll do that.
>
> BTW, not sure about your addition to CDI yet to one of the examples.  
> We will be trimming down the Wildfly distro in the near future and CDI 
> will be one of the subsystems that will be removed.
oops, I did it this way as you asked for it:-) You mentioned CDI or 
Spring in another thread.

So not sure what to do? I am seeing options like:
- Left the original "third-party" example and convert my stuff into 
something like "third-party-cdi" example. This example won't be part of 
WildFly appliance distribution, but IMO it can be just in WAR 
distribution as this is used for people, who want to add examples into 
their own AS7/Wildfly and so we can assume that it will be full 
AS7/Wildfly with support of CDI and JSF.
- Example won't be part of keycloak codebase, but it will be in separate 
repo. This assumes that we will have separate repo with 
examples/quickstarts as suggested by Stian in another mail.

So only thing to change in original "third-party" example will be the 
addition of JSON configuration, instead of hard-coded stuff in the code. 
But there will be still ServletOAuthClient kept as attribute of 
ServletContext. WDYT?

Marek

>
> Bill
>


From bburke at redhat.com  Fri Jan 10 11:05:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 11:05:07 -0500
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <52D0116E.1090402@redhat.com>
References: <52CC5F9F.9070000@redhat.com>	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>	<52CECD16.1080500@redhat.com>	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
	<52CEE083.1090502@redhat.com> <52CFD0C9.9080307@redhat.com>
	<52D00248.70407@redhat.com> <52D0116E.1090402@redhat.com>
Message-ID: <52D01A33.2060707@redhat.com>



On 1/10/2014 10:27 AM, Marek Posolda wrote:
> On 10.1.2014 15:23, Bill Burke wrote:
>>
>>
>> On 1/10/2014 5:51 AM, Marek Posolda wrote:
>>> Just a small note that there is a typo in
>>> https://github.com/keycloak/keycloak/blob/master/examples/as7-eap-demo/README.md
>>>
>>> in step1. For EAP 6.x it should be "keycloak-eap6-adapter-dist.zip" when
>>> currently it talks about "keycloak-as7-adapter-dist.zip" .
>>>
>>
>> Good catch.
>>
>>> Another possible good thing would be to have "quickstart" appliance for
>>> everything bundled in single ZIP (wildfly server with auth-server,
>>> datasource, adapters, test-realm installed and all examples deployed).
>>> This will enable possibility for users to start really quickly playing
>>> with Keycloak without need to import realm in admin-console and
>>> build/deploy examples with maven. Of course, this may not be possible if
>>> examples will be moved to separate repo.
>>>
>>
>> That's a *REALLY* good idea.  I'll do that.
>>
>> BTW, not sure about your addition to CDI yet to one of the examples.
>> We will be trimming down the Wildfly distro in the near future and CDI
>> will be one of the subsystems that will be removed.
> oops, I did it this way as you asked for it:-) You mentioned CDI or
> Spring in another thread.
>

I didn't think it all the way through, its my fault.  We can re-use the 
file configuration stuff though you did.

> So not sure what to do? I am seeing options like:
> - Left the original "third-party" example and convert my stuff into
> something like "third-party-cdi" example. This example won't be part of
> WildFly appliance distribution, but IMO it can be just in WAR
> distribution as this is used for people, who want to add examples into
> their own AS7/Wildfly and so we can assume that it will be full
> AS7/Wildfly with support of CDI and JSF.

That works.

> - Example won't be part of keycloak codebase, but it will be in separate
> repo. This assumes that we will have separate repo with
> examples/quickstarts as suggested by Stian in another mail.
>

Not sure about a separate repo for examples.  Examples tend to change 
and evolve as you do more releases so you'll want to bind them to a 
particular release of keycloak.  Also requires an extra step from the 
user to go to github and get them.  I also liked your idea of having the 
demo pre-configured into the appliance so you can just run the demo out 
of the box.

> So only thing to change in original "third-party" example will be the
> addition of JSON configuration, instead of hard-coded stuff in the code.
> But there will be still ServletOAuthClient kept as attribute of
> ServletContext. WDYT?
>

Or you could just rebuild ServletOAuthClient with every request and get 
rid of the Listener etc.

Bill

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

From bburke at redhat.com  Fri Jan 10 11:06:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 11:06:17 -0500
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
References: <52CC5F9F.9070000@redhat.com>
	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>
	<52CECD16.1080500@redhat.com>
	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
Message-ID: <52D01A79.100@redhat.com>

Maybe you meant this, but, I guess we *could* do this, but the distro 
poms would unpack the demo template poms into multiple variations.

On 1/9/2014 12:21 PM, Stian Thorgersen wrote:
> Is the only difference between the 3 examples the name of the adapter in jboss-deployment-structure?
>
> If so could we not do either:
>
> * Maven profiles to template these files with the adapter module name
> * Use same module name for the adapters?
>
> That would make it a lot easier to make sure the examples are in-sync.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 9 January, 2014 4:23:50 PM
>> Subject: Re: [keycloak-dev] examples/distro reworked/improved/finalized PLEASE TRY!
>>
>>
>>
>> On 1/9/2014 10:18 AM, Stian Thorgersen wrote:
>>> I haven't had much time to play with this yet, but will do today/tomorrow.
>>> Although if you're not accepting PRs after today, there may not be any
>>> point? There's two outstanding PRs related to examples are you going to
>>> merge those?
>>>
>>> Some comments on the distributions:
>>>
>>> Instead of having these download bundles I think it would be better to have
>>> downloads for each individual thing:
>>>
>>> keycloak-bundle-<version>.zip
>>>
>>> - keycloak-<version>
>>>     - bin
>>>     - deployments/auth-server.war (exploded)
>>>     - ..
>>>
>>> keycloak-war.zip
>>>
>>> - auth-server.war (exploded)
>>> - auth-server.war.dodeploy
>>> - keycloak-ds.xml
>>>
>>> keycloak-wildfly-adapter.zip
>>> keycloak-eap-adapter.zip
>>> keycloak-as7-adapter.zip
>>>
>>
>> Poms are set up to do this so not a problem.
>>
>>> Reason for this is that it allows devs to download what they want rather
>>> than a huge bundle. For example:
>>>
>>> * To install the server all you want is the server
>>> * If running Keycloak on OpenShift all you need is the one adapter for
>>> whatever application server you're using
>>>
>>> We could move examples into a separate github project and the documentation
>>> would instruct people to get it from there. That way we can add/edit
>>> examples after a release. This is the way JDF does it, and I would think
>>> that eventually Keycloak examples would be moved into there.
>>>
>>
>> Not everybody knows how to use Github :)  Plus, you need examples tied
>> to release versions as there may be differences between them.
>>
>>> It may also be good to have these zips available in Maven central as that
>>> makes it simpler for other projects to build their own distributions that
>>> includes Keycloak. I can imagine AeroGear guys may be interested in that.
>>>
>>
>> Simple enough.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From stian at redhat.com  Fri Jan 10 11:24:57 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 11:24:57 -0500 (EST)
Subject: [keycloak-dev] Isn't SSL required a global setting?
In-Reply-To: <2112498383.48338296.1389370536645.JavaMail.root@redhat.com>
Message-ID: <107214544.48342875.1389371097532.JavaMail.root@redhat.com>

At the moment we have a SSL required setting per-realm. I was thinking that it should be a global configuration for a Keycloak server. In production all requests to a Keycloak server should be over https, while in development it should be possible to use http for simplicity. That's not a per-realm thing IMO.

If it's ok that it's a global config, we can drop it from the realm and instead add:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>keycloak</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

To the web.xml in the distribution. In the documentation we should then have two options, first how to configure SSL on WildFly, second how to allow HTTP (with a warning that it's only for development!).

From bburke at redhat.com  Fri Jan 10 11:32:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 11:32:25 -0500
Subject: [keycloak-dev] Isn't SSL required a global setting?
In-Reply-To: <107214544.48342875.1389371097532.JavaMail.root@redhat.com>
References: <107214544.48342875.1389371097532.JavaMail.root@redhat.com>
Message-ID: <52D02099.3090403@redhat.com>

"Require SSL" is mainly used to force application/oauth redirect URLs to 
be HTTPS endpoints.  Otherwise, auth codes (not tokens) are transmitted 
in the clear back to the application.  A nice side-effect is that if the 
admin forgets to set up web.xml, the token service will barf too :)

On 1/10/2014 11:24 AM, Stian Thorgersen wrote:
> At the moment we have a SSL required setting per-realm. I was thinking that it should be a global configuration for a Keycloak server. In production all requests to a Keycloak server should be over https, while in development it should be possible to use http for simplicity. That's not a per-realm thing IMO.
>
> If it's ok that it's a global config, we can drop it from the realm and instead add:
>
> <security-constraint>
>      <web-resource-collection>
>          <web-resource-name>keycloak</web-resource-name>
>          <url-pattern>/*</url-pattern>
>      </web-resource-collection>
>      <user-data-constraint>
>          <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>      </user-data-constraint>
> </security-constraint>
>
> To the web.xml in the distribution. In the documentation we should then have two options, first how to configure SSL on WildFly, second how to allow HTTP (with a warning that it's only for development!).
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Jan 10 11:34:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 11:34:01 -0500
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <189658621.48268418.1389365034850.JavaMail.root@redhat.com>
References: <52CC6188.1000608@redhat.com>
	<1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
	<52CECC69.4080207@redhat.com>
	<1176551821.47512838.1389284785183.JavaMail.root@redhat.com>
	<683056165.48245070.1389362996437.JavaMail.root@redhat.com>
	<52D00417.4040405@redhat.com>
	<189658621.48268418.1389365034850.JavaMail.root@redhat.com>
Message-ID: <52D020F9.3050009@redhat.com>



On 1/10/2014 9:43 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: Friday, 10 January, 2014 2:30:47 PM
>> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
>>
>> I'm fine with this as long as no further things pop up.  This is an
>> alpha release and so long as it is functional, we're good.
>
> Sure, I can sort out the issues I listed, except it would be good if you could have a look at https://issues.jboss.org/browse/KEYCLOAK-256.
>
>>
>> I'm not sure about the JSF example addition.  I want all the examples to
>> work off of the appliance (and pre-configured as marek suggested), and
>> the appliance will be trimmed down to remove CDI/JSF in the future.
>> People don't use JSP anymore, but so what?  The examples are very
>> minimal on purpose because they focus on keycloak.  But, I've always
>> wanted nice example applications in addition to these simple examples
>> (like event juggler) so users can also see other technologies
>> interacting with keycloak.
>
> Makes sense. Just one question though, once the WildFly subsystem is ready, wouldn't the trimmed down appliance also not have support for JavaEE/deployments altogether? I think it makes sense to have two options for Keycloak (embedded in a fully functional WildFly/EAP, and a standalone that doesn't allow deployments of any sort).
>

We need support for:

jca/jta - jdbc connection pool
JPA
Servlet

JAX-RS/Jackson comes bundled with keycloak war.

Not sure yet how we'll deal with clustering yet,no there may be some 
other pieces we need.  I'm pretty sure there's something interesting 
things we can do with the Wildfly Domain Controller to make clustering 
really nice.

IMO, if users want something different than the appliance, then they 
have to download and install the war distribution themselves.  So, only 
one appliance download IMO.  Two many options is confusing.

Bill

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

From stian at redhat.com  Fri Jan 10 11:49:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 11:49:49 -0500 (EST)
Subject: [keycloak-dev] Isn't SSL required a global setting?
In-Reply-To: <52D02099.3090403@redhat.com>
References: <107214544.48342875.1389371097532.JavaMail.root@redhat.com>
	<52D02099.3090403@redhat.com>
Message-ID: <503926772.48355903.1389372589739.JavaMail.root@redhat.com>

Yer, but does it have to be a per-realm thing? It makes more sense to me that by default all traffic to Keycloak is required to be https, unless you explicitly disable it (for dev).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 January, 2014 4:32:25 PM
> Subject: Re: [keycloak-dev] Isn't SSL required a global setting?
> 
> "Require SSL" is mainly used to force application/oauth redirect URLs to
> be HTTPS endpoints.  Otherwise, auth codes (not tokens) are transmitted
> in the clear back to the application.  A nice side-effect is that if the
> admin forgets to set up web.xml, the token service will barf too :)
> 
> On 1/10/2014 11:24 AM, Stian Thorgersen wrote:
> > At the moment we have a SSL required setting per-realm. I was thinking that
> > it should be a global configuration for a Keycloak server. In production
> > all requests to a Keycloak server should be over https, while in
> > development it should be possible to use http for simplicity. That's not a
> > per-realm thing IMO.
> >
> > If it's ok that it's a global config, we can drop it from the realm and
> > instead add:
> >
> > <security-constraint>
> >      <web-resource-collection>
> >          <web-resource-name>keycloak</web-resource-name>
> >          <url-pattern>/*</url-pattern>
> >      </web-resource-collection>
> >      <user-data-constraint>
> >          <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> >      </user-data-constraint>
> > </security-constraint>
> >
> > To the web.xml in the distribution. In the documentation we should then
> > have two options, first how to configure SSL on WildFly, second how to
> > allow HTTP (with a warning that it's only for development!).
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Jan 10 11:52:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 11:52:50 -0500 (EST)
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <52D020F9.3050009@redhat.com>
References: <52CC6188.1000608@redhat.com>
	<1865437390.47420291.1389280908627.JavaMail.root@redhat.com>
	<52CECC69.4080207@redhat.com>
	<1176551821.47512838.1389284785183.JavaMail.root@redhat.com>
	<683056165.48245070.1389362996437.JavaMail.root@redhat.com>
	<52D00417.4040405@redhat.com>
	<189658621.48268418.1389365034850.JavaMail.root@redhat.com>
	<52D020F9.3050009@redhat.com>
Message-ID: <793049026.48357725.1389372770106.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 January, 2014 4:34:01 PM
> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> 
> 
> 
> On 1/10/2014 9:43 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: Friday, 10 January, 2014 2:30:47 PM
> >> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> >>
> >> I'm fine with this as long as no further things pop up.  This is an
> >> alpha release and so long as it is functional, we're good.
> >
> > Sure, I can sort out the issues I listed, except it would be good if you
> > could have a look at https://issues.jboss.org/browse/KEYCLOAK-256.
> >
> >>
> >> I'm not sure about the JSF example addition.  I want all the examples to
> >> work off of the appliance (and pre-configured as marek suggested), and
> >> the appliance will be trimmed down to remove CDI/JSF in the future.
> >> People don't use JSP anymore, but so what?  The examples are very
> >> minimal on purpose because they focus on keycloak.  But, I've always
> >> wanted nice example applications in addition to these simple examples
> >> (like event juggler) so users can also see other technologies
> >> interacting with keycloak.
> >
> > Makes sense. Just one question though, once the WildFly subsystem is ready,
> > wouldn't the trimmed down appliance also not have support for
> > JavaEE/deployments altogether? I think it makes sense to have two options
> > for Keycloak (embedded in a fully functional WildFly/EAP, and a standalone
> > that doesn't allow deployments of any sort).
> >
> 
> We need support for:
> 
> jca/jta - jdbc connection pool
> JPA
> Servlet
> 
> JAX-RS/Jackson comes bundled with keycloak war.
> 
> Not sure yet how we'll deal with clustering yet,no there may be some
> other pieces we need.  I'm pretty sure there's something interesting
> things we can do with the Wildfly Domain Controller to make clustering
> really nice.
> 
> IMO, if users want something different than the appliance, then they
> have to download and install the war distribution themselves.  So, only
> one appliance download IMO.  Two many options is confusing.
> 

Sure - my point was that I don't think a trimmed down standalone appliance shouldn't support JavaEE deployments (i.e. standalone/deployments and hot-deployment stuff is ripped out) so wouldn't matter if examples are JSP or JSF.

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

From bburke at redhat.com  Fri Jan 10 11:59:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 11:59:35 -0500
Subject: [keycloak-dev] Isn't SSL required a global setting?
In-Reply-To: <503926772.48355903.1389372589739.JavaMail.root@redhat.com>
References: <107214544.48342875.1389371097532.JavaMail.root@redhat.com>
	<52D02099.3090403@redhat.com>
	<503926772.48355903.1389372589739.JavaMail.root@redhat.com>
Message-ID: <52D026F7.3020402@redhat.com>

I don't know.  Maybe some applications will not be able to have HTTPS. 
A realm may want to allow an application to receive auth code redirects 
over an unsecure channel.

On 1/10/2014 11:49 AM, Stian Thorgersen wrote:
> Yer, but does it have to be a per-realm thing? It makes more sense to me that by default all traffic to Keycloak is required to be https, unless you explicitly disable it (for dev).
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 10 January, 2014 4:32:25 PM
>> Subject: Re: [keycloak-dev] Isn't SSL required a global setting?
>>
>> "Require SSL" is mainly used to force application/oauth redirect URLs to
>> be HTTPS endpoints.  Otherwise, auth codes (not tokens) are transmitted
>> in the clear back to the application.  A nice side-effect is that if the
>> admin forgets to set up web.xml, the token service will barf too :)
>>
>> On 1/10/2014 11:24 AM, Stian Thorgersen wrote:
>>> At the moment we have a SSL required setting per-realm. I was thinking that
>>> it should be a global configuration for a Keycloak server. In production
>>> all requests to a Keycloak server should be over https, while in
>>> development it should be possible to use http for simplicity. That's not a
>>> per-realm thing IMO.
>>>
>>> If it's ok that it's a global config, we can drop it from the realm and
>>> instead add:
>>>
>>> <security-constraint>
>>>       <web-resource-collection>
>>>           <web-resource-name>keycloak</web-resource-name>
>>>           <url-pattern>/*</url-pattern>
>>>       </web-resource-collection>
>>>       <user-data-constraint>
>>>           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>>       </user-data-constraint>
>>> </security-constraint>
>>>
>>> To the web.xml in the distribution. In the documentation we should then
>>> have two options, first how to configure SSL on WildFly, second how to
>>> allow HTTP (with a warning that it's only for development!).
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Fri Jan 10 12:01:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 12:01:04 -0500 (EST)
Subject: [keycloak-dev] Release next Monday or Tuesday
In-Reply-To: <793049026.48357725.1389372770106.JavaMail.root@redhat.com>
References: <52CC6188.1000608@redhat.com> <52CECC69.4080207@redhat.com>
	<1176551821.47512838.1389284785183.JavaMail.root@redhat.com>
	<683056165.48245070.1389362996437.JavaMail.root@redhat.com>
	<52D00417.4040405@redhat.com>
	<189658621.48268418.1389365034850.JavaMail.root@redhat.com>
	<52D020F9.3050009@redhat.com>
	<793049026.48357725.1389372770106.JavaMail.root@redhat.com>
Message-ID: <1852575777.48363709.1389373264919.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 January, 2014 4:52:50 PM
> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 10 January, 2014 4:34:01 PM
> > Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> > 
> > 
> > 
> > On 1/10/2014 9:43 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: Friday, 10 January, 2014 2:30:47 PM
> > >> Subject: Re: [keycloak-dev] Release next Monday or Tuesday
> > >>
> > >> I'm fine with this as long as no further things pop up.  This is an
> > >> alpha release and so long as it is functional, we're good.
> > >
> > > Sure, I can sort out the issues I listed, except it would be good if you
> > > could have a look at https://issues.jboss.org/browse/KEYCLOAK-256.
> > >
> > >>
> > >> I'm not sure about the JSF example addition.  I want all the examples to
> > >> work off of the appliance (and pre-configured as marek suggested), and
> > >> the appliance will be trimmed down to remove CDI/JSF in the future.
> > >> People don't use JSP anymore, but so what?  The examples are very
> > >> minimal on purpose because they focus on keycloak.  But, I've always
> > >> wanted nice example applications in addition to these simple examples
> > >> (like event juggler) so users can also see other technologies
> > >> interacting with keycloak.
> > >
> > > Makes sense. Just one question though, once the WildFly subsystem is
> > > ready,
> > > wouldn't the trimmed down appliance also not have support for
> > > JavaEE/deployments altogether? I think it makes sense to have two options
> > > for Keycloak (embedded in a fully functional WildFly/EAP, and a
> > > standalone
> > > that doesn't allow deployments of any sort).
> > >
> > 
> > We need support for:
> > 
> > jca/jta - jdbc connection pool
> > JPA
> > Servlet
> > 
> > JAX-RS/Jackson comes bundled with keycloak war.
> > 
> > Not sure yet how we'll deal with clustering yet,no there may be some
> > other pieces we need.  I'm pretty sure there's something interesting
> > things we can do with the Wildfly Domain Controller to make clustering
> > really nice.
> > 
> > IMO, if users want something different than the appliance, then they
> > have to download and install the war distribution themselves.  So, only
> > one appliance download IMO.  Two many options is confusing.
> > 
> 
> Sure - my point was that I don't think a trimmed down standalone appliance
> shouldn't support JavaEE deployments (i.e. standalone/deployments and
> hot-deployment stuff is ripped out) so wouldn't matter if examples are JSP
> or JSF.

Hmm... let me rewrite that! A slimmed down standalone Keycloak appliance should not support JavaEE deployments. It should be a pure auth server, not a JavaEE application server as well (if you want that deploy auth-server.war to a standard wildfly server).

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

From stian at redhat.com  Fri Jan 10 12:02:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 12:02:49 -0500 (EST)
Subject: [keycloak-dev] Isn't SSL required a global setting?
In-Reply-To: <52D026F7.3020402@redhat.com>
References: <107214544.48342875.1389371097532.JavaMail.root@redhat.com>
	<52D02099.3090403@redhat.com>
	<503926772.48355903.1389372589739.JavaMail.root@redhat.com>
	<52D026F7.3020402@redhat.com>
Message-ID: <813933837.48365786.1389373369339.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 January, 2014 4:59:35 PM
> Subject: Re: [keycloak-dev] Isn't SSL required a global setting?
> 
> I don't know.  Maybe some applications will not be able to have HTTPS.
> A realm may want to allow an application to receive auth code redirects
> over an unsecure channel.

You might be right - playing devils advocate here, but wouldn't that mean it should be a per-app config? ;)

> 
> On 1/10/2014 11:49 AM, Stian Thorgersen wrote:
> > Yer, but does it have to be a per-realm thing? It makes more sense to me
> > that by default all traffic to Keycloak is required to be https, unless
> > you explicitly disable it (for dev).
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 10 January, 2014 4:32:25 PM
> >> Subject: Re: [keycloak-dev] Isn't SSL required a global setting?
> >>
> >> "Require SSL" is mainly used to force application/oauth redirect URLs to
> >> be HTTPS endpoints.  Otherwise, auth codes (not tokens) are transmitted
> >> in the clear back to the application.  A nice side-effect is that if the
> >> admin forgets to set up web.xml, the token service will barf too :)
> >>
> >> On 1/10/2014 11:24 AM, Stian Thorgersen wrote:
> >>> At the moment we have a SSL required setting per-realm. I was thinking
> >>> that
> >>> it should be a global configuration for a Keycloak server. In production
> >>> all requests to a Keycloak server should be over https, while in
> >>> development it should be possible to use http for simplicity. That's not
> >>> a
> >>> per-realm thing IMO.
> >>>
> >>> If it's ok that it's a global config, we can drop it from the realm and
> >>> instead add:
> >>>
> >>> <security-constraint>
> >>>       <web-resource-collection>
> >>>           <web-resource-name>keycloak</web-resource-name>
> >>>           <url-pattern>/*</url-pattern>
> >>>       </web-resource-collection>
> >>>       <user-data-constraint>
> >>>           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> >>>       </user-data-constraint>
> >>> </security-constraint>
> >>>
> >>> To the web.xml in the distribution. In the documentation we should then
> >>> have two options, first how to configure SSL on WildFly, second how to
> >>> allow HTTP (with a warning that it's only for development!).
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Fri Jan 10 12:07:34 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Jan 2014 18:07:34 +0100
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <52D01A33.2060707@redhat.com>
References: <52CC5F9F.9070000@redhat.com>	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>	<52CECD16.1080500@redhat.com>	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>
	<52CEE083.1090502@redhat.com> <52CFD0C9.9080307@redhat.com>
	<52D00248.70407@redhat.com> <52D0116E.1090402@redhat.com>
	<52D01A33.2060707@redhat.com>
Message-ID: <52D028D6.3020308@redhat.com>

On 10.1.2014 17:05, Bill Burke wrote:
>
>
> On 1/10/2014 10:27 AM, Marek Posolda wrote:
>> On 10.1.2014 15:23, Bill Burke wrote:
>>>
>>>
>>> On 1/10/2014 5:51 AM, Marek Posolda wrote:
>>>> Just a small note that there is a typo in
>>>> https://github.com/keycloak/keycloak/blob/master/examples/as7-eap-demo/README.md 
>>>>
>>>>
>>>> in step1. For EAP 6.x it should be "keycloak-eap6-adapter-dist.zip" 
>>>> when
>>>> currently it talks about "keycloak-as7-adapter-dist.zip" .
>>>>
>>>
>>> Good catch.
>>>
>>>> Another possible good thing would be to have "quickstart" appliance 
>>>> for
>>>> everything bundled in single ZIP (wildfly server with auth-server,
>>>> datasource, adapters, test-realm installed and all examples deployed).
>>>> This will enable possibility for users to start really quickly playing
>>>> with Keycloak without need to import realm in admin-console and
>>>> build/deploy examples with maven. Of course, this may not be 
>>>> possible if
>>>> examples will be moved to separate repo.
>>>>
>>>
>>> That's a *REALLY* good idea.  I'll do that.
>>>
>>> BTW, not sure about your addition to CDI yet to one of the examples.
>>> We will be trimming down the Wildfly distro in the near future and CDI
>>> will be one of the subsystems that will be removed.
>> oops, I did it this way as you asked for it:-) You mentioned CDI or
>> Spring in another thread.
>>
>
> I didn't think it all the way through, its my fault.  We can re-use 
> the file configuration stuff though you did.
np, good that we clarify how to do it. So I will try to update my PR by 
Monday and will update both as7 and wildfly examples. Hope that 3rd 
attempt will be successful:-)
>
>> So not sure what to do? I am seeing options like:
>> - Left the original "third-party" example and convert my stuff into
>> something like "third-party-cdi" example. This example won't be part of
>> WildFly appliance distribution, but IMO it can be just in WAR
>> distribution as this is used for people, who want to add examples into
>> their own AS7/Wildfly and so we can assume that it will be full
>> AS7/Wildfly with support of CDI and JSF.
>
> That works.
>
>> - Example won't be part of keycloak codebase, but it will be in separate
>> repo. This assumes that we will have separate repo with
>> examples/quickstarts as suggested by Stian in another mail.
>>
>
> Not sure about a separate repo for examples.  Examples tend to change 
> and evolve as you do more releases so you'll want to bind them to a 
> particular release of keycloak.  Also requires an extra step from the 
> user to go to github and get them.  I also liked your idea of having 
> the demo pre-configured into the appliance so you can just run the 
> demo out of the box.
yup, quickstart appliance seems to be good advantage. On the other it 
has disadvantages as well. Approach with quickstarts used for some other 
projects like JBossAS/JDF/GateIn showed us that separate branch could 
work. People, who want to try examples and look at source code, won't 
need to clone whole Keycloak project but just examples. They can of 
course download ZIP distribution with examples, but still some may 
prefer to directly clone from github. It can also simplify IDE support.

In GateIn we have few very simple examples (like hello-world portlets), 
which are part of GateIn portal itself and for more "advanced" things we 
have separate repo with quickstarts. Maybe we can have something 
similar? On the other hand, Keycloak is a bit specific as there are some 
differences between AS7 and Wildfly examples, but this can be handled 
with 2 example branches (one for as7 and one for wildfly).  Which could 
simplify things in the end as you will just need to update "wildfly" 
branch and then use the same stuff for "as7" and just cherry-pick one 
commit, which will contain differences between as7 and wildfly examples 
(It seems to me that only difference is name of adapter module in 
jboss-deployment-structure.xml).

Still not sure what is best, just throwing out possible 
advantages/disadvantages...

For now, I will use "third-party-cdi" directly as part of keycloak.
>
>> So only thing to change in original "third-party" example will be the
>> addition of JSON configuration, instead of hard-coded stuff in the code.
>> But there will be still ServletOAuthClient kept as attribute of
>> ServletContext. WDYT?
>>
>
> Or you could just rebuild ServletOAuthClient with every request and 
> get rid of the Listener etc.
hmm... but isn't that expensive? As start of ServletOAuthClient would 
require reading config and bootstrap of underlying HttpClient. Probably 
not good approach to do this in every request?

Marek
>
> Bill
>


From stian at redhat.com  Fri Jan 10 12:35:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Jan 2014 12:35:33 -0500 (EST)
Subject: [keycloak-dev] Isn't SSL required a global setting?
In-Reply-To: <813933837.48365786.1389373369339.JavaMail.root@redhat.com>
References: <107214544.48342875.1389371097532.JavaMail.root@redhat.com>
	<52D02099.3090403@redhat.com>
	<503926772.48355903.1389372589739.JavaMail.root@redhat.com>
	<52D026F7.3020402@redhat.com>
	<813933837.48365786.1389373369339.JavaMail.root@redhat.com>
Message-ID: <1101058498.48382141.1389375333088.JavaMail.root@redhat.com>

Created https://issues.jboss.org/browse/KEYCLOAK-260 to track this

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 January, 2014 5:02:49 PM
> Subject: Re: [keycloak-dev] Isn't SSL required a global setting?
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 10 January, 2014 4:59:35 PM
> > Subject: Re: [keycloak-dev] Isn't SSL required a global setting?
> > 
> > I don't know.  Maybe some applications will not be able to have HTTPS.
> > A realm may want to allow an application to receive auth code redirects
> > over an unsecure channel.
> 
> You might be right - playing devils advocate here, but wouldn't that mean it
> should be a per-app config? ;)
> 
> > 
> > On 1/10/2014 11:49 AM, Stian Thorgersen wrote:
> > > Yer, but does it have to be a per-realm thing? It makes more sense to me
> > > that by default all traffic to Keycloak is required to be https, unless
> > > you explicitly disable it (for dev).
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Friday, 10 January, 2014 4:32:25 PM
> > >> Subject: Re: [keycloak-dev] Isn't SSL required a global setting?
> > >>
> > >> "Require SSL" is mainly used to force application/oauth redirect URLs to
> > >> be HTTPS endpoints.  Otherwise, auth codes (not tokens) are transmitted
> > >> in the clear back to the application.  A nice side-effect is that if the
> > >> admin forgets to set up web.xml, the token service will barf too :)
> > >>
> > >> On 1/10/2014 11:24 AM, Stian Thorgersen wrote:
> > >>> At the moment we have a SSL required setting per-realm. I was thinking
> > >>> that
> > >>> it should be a global configuration for a Keycloak server. In
> > >>> production
> > >>> all requests to a Keycloak server should be over https, while in
> > >>> development it should be possible to use http for simplicity. That's
> > >>> not
> > >>> a
> > >>> per-realm thing IMO.
> > >>>
> > >>> If it's ok that it's a global config, we can drop it from the realm and
> > >>> instead add:
> > >>>
> > >>> <security-constraint>
> > >>>       <web-resource-collection>
> > >>>           <web-resource-name>keycloak</web-resource-name>
> > >>>           <url-pattern>/*</url-pattern>
> > >>>       </web-resource-collection>
> > >>>       <user-data-constraint>
> > >>>           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> > >>>       </user-data-constraint>
> > >>> </security-constraint>
> > >>>
> > >>> To the web.xml in the distribution. In the documentation we should then
> > >>> have two options, first how to configure SSL on WildFly, second how to
> > >>> allow HTTP (with a warning that it's only for development!).
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >>
> > >> --
> > >> Bill Burke
> > >> JBoss, a division of Red Hat
> > >> http://bill.burkecentral.com
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From gcardoso at redhat.com  Fri Jan 10 14:17:39 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Fri, 10 Jan 2014 17:17:39 -0200
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <etPan.52cd35bb.74b0dc51.65b9@tesla>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>
	<52CD3256.3030504@redhat.com> <etPan.52cd35bb.74b0dc51.65b9@tesla>
Message-ID: <E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>

Considering the majority of the votes, I worked on the version 1.

Here is the proposal. What do you think?



Gabriel


On Jan 8, 2014, at 9:25 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Only to be different, I would vote on #2 without the cape.
> 
> --  
> abstractj
> 
> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz (bdawidow at redhat.com) wrote:
>> 
>> I like 1, 3 and 4. #1 being a big ugly in current form but definitely  
>> with lot of potential
>> 
>> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
>>> I really like #1 - maybe drop the star and make the key a little  
>> bit less cartoony?
>>> 
>>> ----- Original Message -----
>>>> From: "Gabriel Cardoso"  
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>>>> Subject: [keycloak-dev] Logo ideas
>>>> 
>>>> Hi,
>>>> 
>>>> based on the concept of security and the ?key? and ?cloak? elements,  
>> I worked
>>>> on some initial ideas for the logo.
>>>> 
>>>> After we choose one or two ideas, I?ll refine the symbol, the  
>> font and put
>>>> colours.
>>>> 
>>>> Which proposal do you think is more interesting for the project?  
>>>> 
>>>> Thanks,
>>>> Gabriel
>>>> 
>>>> 01: I hope to have better background light effects for the final  
>> version
>>>> 
>>>> 02: Will work more on the flying cloak
>>>> 
>>>> 03: Maybe too ordinary
>>>> 04: Will work more on the ?K? in the shield
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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  
>>> 
>> 
>> 
>> 
>> --
>> Boles?aw Dawidowicz
>> JBoss Portal Platform Architect | GateIn Portal Project Lead  
>> _______________________________________________
>> 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

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140110/c6d6494a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-01-10 at 5.15.39 PM.png
Type: image/png
Size: 98702 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140110/c6d6494a/attachment-0001.png 

From ssilvert at redhat.com  Fri Jan 10 14:31:47 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Fri, 10 Jan 2014 14:31:47 -0500
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>	<52CD3256.3030504@redhat.com>
	<etPan.52cd35bb.74b0dc51.65b9@tesla>
	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
Message-ID: <52D04AA3.7010602@redhat.com>

Ultraman with a cape.  Love it!

600 ? 450 - hsmagazine.net
<http://www.google.com/imgres?client=firefox-a&hs=LPj&sa=X&rls=org.mozilla%3Aen-US%3Aofficial&biw=1600&bih=783&tbm=isch&tbnid=qOnW97yAD-7McM%3A&imgrefurl=http%3A%2F%2Fwww.hsmagazine.net%2F2013%2F11%2Fultraman%2F&docid=erk9D4GVBvrB2M&imgurl=http%3A%2F%2Fimg.hsmagazine.net%2F2013%2F11%2Fultraman.jpg&w=600&h=450&ei=N0rQUuaQF8PiyAHOg4HoCg&zoom=1&ved=0CHYQhBwwBQ&iact=rc&dur=5801&page=1&start=0&ndsp=20>
On 1/10/2014 2:17 PM, Gabriel Cardoso wrote:
> Considering the majority of the votes, I worked on the version 1.
>
> Here is the proposal. What do you think?
>
>
> Gabriel
>
>
> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira <bruno at abstractj.org
> <mailto:bruno at abstractj.org>> wrote:
>
>> Only to be different, I would vote on #2 without the cape.
>>
>> --  
>> abstractj
>>
>> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz
>> (bdawidow at redhat.com <mailto:bdawidow at redhat.com>) wrote:
>>>
>>> I like 1, 3 and 4. #1 being a big ugly in current form but definitely  
>>> with lot of potential
>>>
>>> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
>>>> I really like #1 - maybe drop the star and make the key a little  
>>> bit less cartoony?
>>>>
>>>> ----- Original Message -----
>>>>> From: "Gabriel Cardoso"  
>>>>> To: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>>>>> Subject: [keycloak-dev] Logo ideas
>>>>>
>>>>> Hi,
>>>>>
>>>>> based on the concept of security and the "key" and "cloak" elements,  
>>> I worked
>>>>> on some initial ideas for the logo.
>>>>>
>>>>> After we choose one or two ideas, I'll refine the symbol, the  
>>> font and put
>>>>> colours.
>>>>>
>>>>> Which proposal do you think is more interesting for the project?  
>>>>>
>>>>> Thanks,
>>>>> Gabriel
>>>>>
>>>>> 01: I hope to have better background light effects for the final  
>>> version
>>>>>
>>>>> 02: Will work more on the flying cloak
>>>>>
>>>>> 03: Maybe too ordinary
>>>>> 04: Will work more on the "K" in the shield
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev  
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev  
>>>>
>>>
>>>
>>>
>>> --
>>> Boles?aw Dawidowicz
>>> JBoss Portal Platform Architect | GateIn Portal Project Lead  
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev  
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140110/7169bb61/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qOnW97yAD-7McM:
Type: image/jpeg
Size: 4803 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140110/7169bb61/attachment-0001.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 98702 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140110/7169bb61/attachment-0001.png 

From bburke at redhat.com  Fri Jan 10 18:24:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 18:24:36 -0500
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <52D04AA3.7010602@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>	<52CD3256.3030504@redhat.com>	<etPan.52cd35bb.74b0dc51.65b9@tesla>	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
	<52D04AA3.7010602@redhat.com>
Message-ID: <52D08134.3000909@redhat.com>

Very nice!

On 1/10/2014 2:31 PM, ssilvert at redhat.com wrote:
> Ultraman with a cape.  Love it!
>
> 600 ? 450 - hsmagazine.net
> <http://www.google.com/imgres?client=firefox-a&hs=LPj&sa=X&rls=org.mozilla%3Aen-US%3Aofficial&biw=1600&bih=783&tbm=isch&tbnid=qOnW97yAD-7McM%3A&imgrefurl=http%3A%2F%2Fwww.hsmagazine.net%2F2013%2F11%2Fultraman%2F&docid=erk9D4GVBvrB2M&imgurl=http%3A%2F%2Fimg.hsmagazine.net%2F2013%2F11%2Fultraman.jpg&w=600&h=450&ei=N0rQUuaQF8PiyAHOg4HoCg&zoom=1&ved=0CHYQhBwwBQ&iact=rc&dur=5801&page=1&start=0&ndsp=20>
> On 1/10/2014 2:17 PM, Gabriel Cardoso wrote:
>> Considering the majority of the votes, I worked on the version 1.
>>
>> Here is the proposal. What do you think?
>>
>>
>> Gabriel
>>
>>
>> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira <bruno at abstractj.org
>> <mailto:bruno at abstractj.org>> wrote:
>>
>>> Only to be different, I would vote on #2 without the cape.
>>>
>>> --
>>> abstractj
>>>
>>> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz
>>> (bdawidow at redhat.com <mailto:bdawidow at redhat.com>) wrote:
>>>>
>>>> I like 1, 3 and 4. #1 being a big ugly in current form but definitely
>>>> with lot of potential
>>>>
>>>> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
>>>>> I really like #1 - maybe drop the star and make the key a little
>>>> bit less cartoony?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Gabriel Cardoso"
>>>>>> To:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>>>>>> Subject: [keycloak-dev] Logo ideas
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> based on the concept of security and the ?key? and ?cloak? elements,
>>>> I worked
>>>>>> on some initial ideas for the logo.
>>>>>>
>>>>>> After we choose one or two ideas, I?ll refine the symbol, the
>>>> font and put
>>>>>> colours.
>>>>>>
>>>>>> Which proposal do you think is more interesting for the project?
>>>>>>
>>>>>> Thanks,
>>>>>> Gabriel
>>>>>>
>>>>>> 01: I hope to have better background light effects for the final
>>>> version
>>>>>>
>>>>>> 02: Will work more on the flying cloak
>>>>>>
>>>>>> 03: Maybe too ordinary
>>>>>> 04: Will work more on the ?K? in the shield
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Boles?aw Dawidowicz
>>>> JBoss Portal Platform Architect | GateIn Portal Project Lead
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>>
>>
>>
>> _______________________________________________
>> 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
>

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

From bburke at redhat.com  Fri Jan 10 18:25:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jan 2014 18:25:15 -0500
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <52D08134.3000909@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>	<52CD3256.3030504@redhat.com>	<etPan.52cd35bb.74b0dc51.65b9@tesla>	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>	<52D04AA3.7010602@redhat.com>
	<52D08134.3000909@redhat.com>
Message-ID: <52D0815B.9020008@redhat.com>

Can you create something that could fit on keycloak.org?  A banner?

On 1/10/2014 6:24 PM, Bill Burke wrote:
> Very nice!
>
> On 1/10/2014 2:31 PM, ssilvert at redhat.com wrote:
>> Ultraman with a cape.  Love it!
>>
>> 600 ? 450 - hsmagazine.net
>> <http://www.google.com/imgres?client=firefox-a&hs=LPj&sa=X&rls=org.mozilla%3Aen-US%3Aofficial&biw=1600&bih=783&tbm=isch&tbnid=qOnW97yAD-7McM%3A&imgrefurl=http%3A%2F%2Fwww.hsmagazine.net%2F2013%2F11%2Fultraman%2F&docid=erk9D4GVBvrB2M&imgurl=http%3A%2F%2Fimg.hsmagazine.net%2F2013%2F11%2Fultraman.jpg&w=600&h=450&ei=N0rQUuaQF8PiyAHOg4HoCg&zoom=1&ved=0CHYQhBwwBQ&iact=rc&dur=5801&page=1&start=0&ndsp=20>
>> On 1/10/2014 2:17 PM, Gabriel Cardoso wrote:
>>> Considering the majority of the votes, I worked on the version 1.
>>>
>>> Here is the proposal. What do you think?
>>>
>>>
>>> Gabriel
>>>
>>>
>>> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira <bruno at abstractj.org
>>> <mailto:bruno at abstractj.org>> wrote:
>>>
>>>> Only to be different, I would vote on #2 without the cape.
>>>>
>>>> --
>>>> abstractj
>>>>
>>>> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz
>>>> (bdawidow at redhat.com <mailto:bdawidow at redhat.com>) wrote:
>>>>>
>>>>> I like 1, 3 and 4. #1 being a big ugly in current form but definitely
>>>>> with lot of potential
>>>>>
>>>>> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
>>>>>> I really like #1 - maybe drop the star and make the key a little
>>>>> bit less cartoony?
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Gabriel Cardoso"
>>>>>>> To:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>>>>>>> Subject: [keycloak-dev] Logo ideas
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> based on the concept of security and the ?key? and ?cloak? elements,
>>>>> I worked
>>>>>>> on some initial ideas for the logo.
>>>>>>>
>>>>>>> After we choose one or two ideas, I?ll refine the symbol, the
>>>>> font and put
>>>>>>> colours.
>>>>>>>
>>>>>>> Which proposal do you think is more interesting for the project?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Gabriel
>>>>>>>
>>>>>>> 01: I hope to have better background light effects for the final
>>>>> version
>>>>>>>
>>>>>>> 02: Will work more on the flying cloak
>>>>>>>
>>>>>>> 03: Maybe too ordinary
>>>>>>> 04: Will work more on the ?K? in the shield
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Boles?aw Dawidowicz
>>>>> JBoss Portal Platform Architect | GateIn Portal Project Lead
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> ---
>>> Gabriel Cardoso
>>> User Experience Designer @ Red Hat
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>

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

From bburke at redhat.com  Sun Jan 12 21:05:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 12 Jan 2014 21:05:10 -0500
Subject: [keycloak-dev] a tiny bit of docs checked in
Message-ID: <52D349D6.8040609@redhat.com>

Committed a little bit of documentation under docbook/ directory.  mvn 
install to build it.  Going to work on a tutorial tomorrow that involves 
completely configuring the demo from scratch.  It will be a video 
showing the creation of each config file and working through the admin 
console to create users, roles, mappings, scopes, etc...

I didn't get much work done last week.  Too much construction going on 
at my house that I had to coordinate.  If you're interested, we're 
finishing our basement and during last week our water heater went, we 
had a foundation leak, and to top it off my heating system crapped out 
and needed service.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon Jan 13 04:11:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 04:11:18 -0500 (EST)
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>
	<52CD3256.3030504@redhat.com> <etPan.52cd35bb.74b0dc51.65b9@tesla>
	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
Message-ID: <1016329293.487557.1389604278113.JavaMail.root@redhat.com>

Really cool! 

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 January, 2014 7:17:39 PM
> Subject: Re: [keycloak-dev] Logo ideas
> 
> Considering the majority of the votes, I worked on the version 1.
> 
> Here is the proposal. What do you think?
> 
> 
> Gabriel
> 
> 
> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira < bruno at abstractj.org > wrote:
> 
> 
> 
> 
> Only to be different, I would vote on #2 without the cape.
> 
> --
> abstractj
> 
> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz ( bdawidow at redhat.com )
> wrote:
> 
> 
> 
> I like 1, 3 and 4. #1 being a big ugly in current form but definitely
> with lot of potential
> 
> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
> 
> 
> I really like #1 - maybe drop the star and make the key a little
> bit less cartoony?
> 
> 
> 
> ----- Original Message -----
> 
> 
> From: "Gabriel Cardoso"
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 January, 2014 8:57:26 PM
> Subject: [keycloak-dev] Logo ideas
> 
> Hi,
> 
> based on the concept of security and the ?key? and ?cloak? elements,
> I worked
> 
> 
> 
> 
> on some initial ideas for the logo.
> 
> After we choose one or two ideas, I?ll refine the symbol, the
> font and put
> 
> 
> 
> 
> colours.
> 
> Which proposal do you think is more interesting for the project?
> 
> Thanks,
> Gabriel
> 
> 01: I hope to have better background light effects for the final
> version
> 
> 
> 
> 
> 
> 02: Will work more on the flying cloak
> 
> 03: Maybe too ordinary
> 04: Will work more on the ?K? in the shield
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> 
> --
> Boles?aw Dawidowicz
> JBoss Portal Platform Architect | GateIn Portal Project Lead
> _______________________________________________
> 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
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Mon Jan 13 04:44:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 04:44:50 -0500 (EST)
Subject: [keycloak-dev] a tiny bit of docs checked in
In-Reply-To: <52D349D6.8040609@redhat.com>
References: <52D349D6.8040609@redhat.com>
Message-ID: <1537624839.502311.1389606290379.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 January, 2014 2:05:10 AM
> Subject: [keycloak-dev] a tiny bit of docs checked in
> 
> Committed a little bit of documentation under docbook/ directory.  mvn
> install to build it.  Going to work on a tutorial tomorrow that involves
> completely configuring the demo from scratch.  It will be a video
> showing the creation of each config file and working through the admin
> console to create users, roles, mappings, scopes, etc...

Cool - the offer still stands, if you want me to write some docs let me know

> 
> I didn't get much work done last week.  Too much construction going on
> at my house that I had to coordinate.  If you're interested, we're
> finishing our basement and during last week our water heater went, we
> had a foundation leak, and to top it off my heating system crapped out
> and needed service.

Man, that's a whole lot of shit in a week! I read your blog posts on your geothermal installation, is that what's buggered?

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

From amendonc at redhat.com  Mon Jan 13 06:50:22 2014
From: amendonc at redhat.com (=?iso-8859-1?Q?Alexandre_Mendon=E7a?=)
Date: Mon, 13 Jan 2014 11:50:22 +0000
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>
	<52CD3256.3030504@redhat.com> <etPan.52cd35bb.74b0dc51.65b9@tesla>
	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
Message-ID: <E6ED7E38-B6E4-47E7-AE13-0338CBD53B73@redhat.com>

Really nice work, Gabriel!

Maybe I'd add a couple of grooves in the key, as looking at it without context it's not immediate to figure it's a key.. but not sure, really, it's great as it is :)

Alexandre

On 10 Jan 2014, at 19:17, Gabriel Cardoso <gcardoso at redhat.com> wrote:

> Considering the majority of the votes, I worked on the version 1.
> 
> Here is the proposal. What do you think?
> 
> <Screen Shot 2014-01-10 at 5.15.39 PM.png>
> 
> Gabriel
> 
> 
> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
>> Only to be different, I would vote on #2 without the cape.
>> 
>> --  
>> abstractj
>> 
>> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz (bdawidow at redhat.com) wrote:
>>> 
>>> I like 1, 3 and 4. #1 being a big ugly in current form but definitely  
>>> with lot of potential
>>> 
>>> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
>>>> I really like #1 - maybe drop the star and make the key a little  
>>> bit less cartoony?
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Gabriel Cardoso"  
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>>>>> Subject: [keycloak-dev] Logo ideas
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> based on the concept of security and the ?key? and ?cloak? elements,  
>>> I worked
>>>>> on some initial ideas for the logo.
>>>>> 
>>>>> After we choose one or two ideas, I?ll refine the symbol, the  
>>> font and put
>>>>> colours.
>>>>> 
>>>>> Which proposal do you think is more interesting for the project?  
>>>>> 
>>>>> Thanks,
>>>>> Gabriel
>>>>> 
>>>>> 01: I hope to have better background light effects for the final  
>>> version
>>>>> 
>>>>> 02: Will work more on the flying cloak
>>>>> 
>>>>> 03: Maybe too ordinary
>>>>> 04: Will work more on the ?K? in the shield
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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  
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Boles?aw Dawidowicz
>>> JBoss Portal Platform Architect | GateIn Portal Project Lead  
>>> _______________________________________________
>>> 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
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140113/4f5dcb75/attachment-0001.html 

From stian at redhat.com  Mon Jan 13 08:06:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 08:06:12 -0500 (EST)
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <E6ED7E38-B6E4-47E7-AE13-0338CBD53B73@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>
	<52CD3256.3030504@redhat.com> <etPan.52cd35bb.74b0dc51.65b9@tesla>
	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
	<E6ED7E38-B6E4-47E7-AE13-0338CBD53B73@redhat.com>
Message-ID: <478821299.592448.1389618372423.JavaMail.root@redhat.com>

I was thinking the same. A couple of grooves would make it more obvious that it's a key. 

Also, as the logo borders are quite thin, would it look better with a less bold font?

----- Original Message -----
> From: "Alexandre Mendon?a" <amendonc at redhat.com>
> To: "Gabriel Cardoso" <gcardoso at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 January, 2014 11:50:22 AM
> Subject: Re: [keycloak-dev] Logo ideas
> 
> Really nice work, Gabriel!
> 
> Maybe I'd add a couple of grooves in the key, as looking at it without
> context it's not immediate to figure it's a key.. but not sure, really, it's
> great as it is :)
> 
> Alexandre
> 
> On 10 Jan 2014, at 19:17, Gabriel Cardoso < gcardoso at redhat.com > wrote:
> 
> 
> 
> 
> Considering the majority of the votes, I worked on the version 1.
> 
> Here is the proposal. What do you think?
> 
> <Screen Shot 2014-01-10 at 5.15.39 PM.png>
> 
> Gabriel
> 
> 
> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira < bruno at abstractj.org > wrote:
> 
> 
> 
> 
> Only to be different, I would vote on #2 without the cape.
> 
> --
> abstractj
> 
> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz ( bdawidow at redhat.com )
> wrote:
> 
> 
> 
> I like 1, 3 and 4. #1 being a big ugly in current form but definitely
> with lot of potential
> 
> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
> 
> 
> I really like #1 - maybe drop the star and make the key a little
> bit less cartoony?
> 
> 
> 
> ----- Original Message -----
> 
> 
> From: "Gabriel Cardoso"
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 January, 2014 8:57:26 PM
> Subject: [keycloak-dev] Logo ideas
> 
> Hi,
> 
> based on the concept of security and the ?key? and ?cloak? elements,
> I worked
> 
> 
> 
> 
> on some initial ideas for the logo.
> 
> After we choose one or two ideas, I?ll refine the symbol, the
> font and put
> 
> 
> 
> 
> colours.
> 
> Which proposal do you think is more interesting for the project?
> 
> Thanks,
> Gabriel
> 
> 01: I hope to have better background light effects for the final
> version
> 
> 
> 
> 
> 
> 02: Will work more on the flying cloak
> 
> 03: Maybe too ordinary
> 04: Will work more on the ?K? in the shield
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> 
> --
> Boles?aw Dawidowicz
> JBoss Portal Platform Architect | GateIn Portal Project Lead
> _______________________________________________
> 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
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> _______________________________________________
> 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


From bburke at redhat.com  Mon Jan 13 08:52:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jan 2014 08:52:32 -0500
Subject: [keycloak-dev] a tiny bit of docs checked in
In-Reply-To: <1537624839.502311.1389606290379.JavaMail.root@redhat.com>
References: <52D349D6.8040609@redhat.com>
	<1537624839.502311.1389606290379.JavaMail.root@redhat.com>
Message-ID: <52D3EFA0.80206@redhat.com>



On 1/13/2014 4:44 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 13 January, 2014 2:05:10 AM
>> Subject: [keycloak-dev] a tiny bit of docs checked in
>>
>> Committed a little bit of documentation under docbook/ directory.  mvn
>> install to build it.  Going to work on a tutorial tomorrow that involves
>> completely configuring the demo from scratch.  It will be a video
>> showing the creation of each config file and working through the admin
>> console to create users, roles, mappings, scopes, etc...
>
> Cool - the offer still stands, if you want me to write some docs let me know
>

Did you write up the Openshift Quickstart?  Maybe a section on social 
login setup?  I wanted to write that part to actually learn how to do 
it, but I'll do another screencast for that aspect instead.
>>
>> I didn't get much work done last week.  Too much construction going on
>> at my house that I had to coordinate.  If you're interested, we're
>> finishing our basement and during last week our water heater went, we
>> had a foundation leak, and to top it off my heating system crapped out
>> and needed service.
>
> Man, that's a whole lot of shit in a week! I read your blog posts on your geothermal installation, is that what's buggered?
>

Yes, the new geo system.  Well, Thursday night got some fault warnings 
and the system kept turning off.  It has an "emergency mode" which is 
pure electric heat (but expensive).  Service guy came the next day, and, 
of course when he turned it back on to normal mode to diagnose the 
problem it worked fine.  He did change the filter which had a bunch of 
construction dust in it.  But really no true idea of what happened.


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

From gcardoso at redhat.com  Mon Jan 13 09:17:08 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 13 Jan 2014 12:17:08 -0200
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <478821299.592448.1389618372423.JavaMail.root@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>
	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>
	<52CD3256.3030504@redhat.com> <etPan.52cd35bb.74b0dc51.65b9@tesla>
	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>
	<E6ED7E38-B6E4-47E7-AE13-0338CBD53B73@redhat.com>
	<478821299.592448.1389618372423.JavaMail.root@redhat.com>
Message-ID: <3A3A48FA-EC80-426C-8B48-147E78A68D32@redhat.com>

Thanks for the feedback guys!

Since we have a release today, I?ll leave the logo as it is but I?ll try some changes for a next version.

Gabriel

On Jan 13, 2014, at 11:06 AM, Stian Thorgersen <stian at redhat.com> wrote:

> I was thinking the same. A couple of grooves would make it more obvious that it's a key. 
> 
> Also, as the logo borders are quite thin, would it look better with a less bold font?
> 
> ----- Original Message -----
>> From: "Alexandre Mendon?a" <amendonc at redhat.com>
>> To: "Gabriel Cardoso" <gcardoso at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 13 January, 2014 11:50:22 AM
>> Subject: Re: [keycloak-dev] Logo ideas
>> 
>> Really nice work, Gabriel!
>> 
>> Maybe I'd add a couple of grooves in the key, as looking at it without
>> context it's not immediate to figure it's a key.. but not sure, really, it's
>> great as it is :)
>> 
>> Alexandre
>> 
>> On 10 Jan 2014, at 19:17, Gabriel Cardoso < gcardoso at redhat.com > wrote:
>> 
>> 
>> 
>> 
>> Considering the majority of the votes, I worked on the version 1.
>> 
>> Here is the proposal. What do you think?
>> 
>> <Screen Shot 2014-01-10 at 5.15.39 PM.png>
>> 
>> Gabriel
>> 
>> 
>> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira < bruno at abstractj.org > wrote:
>> 
>> 
>> 
>> 
>> Only to be different, I would vote on #2 without the cape.
>> 
>> --
>> abstractj
>> 
>> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz ( bdawidow at redhat.com )
>> wrote:
>> 
>> 
>> 
>> I like 1, 3 and 4. #1 being a big ugly in current form but definitely
>> with lot of potential
>> 
>> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
>> 
>> 
>> I really like #1 - maybe drop the star and make the key a little
>> bit less cartoony?
>> 
>> 
>> 
>> ----- Original Message -----
>> 
>> 
>> From: "Gabriel Cardoso"
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>> Subject: [keycloak-dev] Logo ideas
>> 
>> Hi,
>> 
>> based on the concept of security and the ?key? and ?cloak? elements,
>> I worked
>> 
>> 
>> 
>> 
>> on some initial ideas for the logo.
>> 
>> After we choose one or two ideas, I?ll refine the symbol, the
>> font and put
>> 
>> 
>> 
>> 
>> colours.
>> 
>> Which proposal do you think is more interesting for the project?
>> 
>> Thanks,
>> Gabriel
>> 
>> 01: I hope to have better background light effects for the final
>> version
>> 
>> 
>> 
>> 
>> 
>> 02: Will work more on the flying cloak
>> 
>> 03: Maybe too ordinary
>> 04: Will work more on the ?K? in the shield
>> 
>> 
>> 
>> _______________________________________________
>> 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
>> 
>> 
>> 
>> 
>> --
>> Boles?aw Dawidowicz
>> JBoss Portal Platform Architect | GateIn Portal Project Lead
>> _______________________________________________
>> 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
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
>> _______________________________________________
>> 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

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140113/69e4b911/attachment.html 

From stian at redhat.com  Mon Jan 13 10:23:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 10:23:08 -0500 (EST)
Subject: [keycloak-dev] a tiny bit of docs checked in
In-Reply-To: <52D3EFA0.80206@redhat.com>
References: <52D349D6.8040609@redhat.com>
	<1537624839.502311.1389606290379.JavaMail.root@redhat.com>
	<52D3EFA0.80206@redhat.com>
Message-ID: <986986231.768534.1389626588667.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 January, 2014 1:52:32 PM
> Subject: Re: [keycloak-dev] a tiny bit of docs checked in
> 
> 
> 
> On 1/13/2014 4:44 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 13 January, 2014 2:05:10 AM
> >> Subject: [keycloak-dev] a tiny bit of docs checked in
> >>
> >> Committed a little bit of documentation under docbook/ directory.  mvn
> >> install to build it.  Going to work on a tutorial tomorrow that involves
> >> completely configuring the demo from scratch.  It will be a video
> >> showing the creation of each config file and working through the admin
> >> console to create users, roles, mappings, scopes, etc...
> >
> > Cool - the offer still stands, if you want me to write some docs let me
> > know
> >
> 
> Did you write up the Openshift Quickstart?  Maybe a section on social
> login setup?  I wanted to write that part to actually learn how to do
> it, but I'll do another screencast for that aspect instead.

There's actually a WildFly OpenShift cartridge now. I'm going to try to fork that and use it as the basis for a Keycloak cartridge. Once I get it working I'll write it up.

Sure, I can write a section on social.

> >>
> >> I didn't get much work done last week.  Too much construction going on
> >> at my house that I had to coordinate.  If you're interested, we're
> >> finishing our basement and during last week our water heater went, we
> >> had a foundation leak, and to top it off my heating system crapped out
> >> and needed service.
> >
> > Man, that's a whole lot of shit in a week! I read your blog posts on your
> > geothermal installation, is that what's buggered?
> >
> 
> Yes, the new geo system.  Well, Thursday night got some fault warnings
> and the system kept turning off.  It has an "emergency mode" which is
> pure electric heat (but expensive).  Service guy came the next day, and,
> of course when he turned it back on to normal mode to diagnose the
> problem it worked fine.  He did change the filter which had a bunch of
> construction dust in it.  But really no true idea of what happened.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Mon Jan 13 10:24:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 10:24:54 -0500 (EST)
Subject: [keycloak-dev] Logo and welcome-page
In-Reply-To: <1189853233.769990.1389626653149.JavaMail.root@redhat.com>
Message-ID: <1413524573.770274.1389626694967.JavaMail.root@redhat.com>

I've added the Keycloak logo to the login and registration pages. It needs some tweaking, but it's good enough for now.

I've also added a welcome-page (/admin-server), which also replaces the WildFly welcome-page in the appliance.

From stian at redhat.com  Mon Jan 13 10:28:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 10:28:17 -0500 (EST)
Subject: [keycloak-dev] Logo and welcome-page
In-Reply-To: <1840996869.816956.1389626883996.JavaMail.root@redhat.com>
Message-ID: <496398267.817055.1389626897206.JavaMail.root@redhat.com>

I've added the Keycloak logo to the login and registration pages. It needs some tweaking, but it's good enough for now.

I've also added a welcome-page (http://localhost:8080/auth-server), which replaces the WildFly welcome-page (http://localhost:8080/) in the appliance.

From stian at redhat.com  Mon Jan 13 10:29:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 10:29:41 -0500 (EST)
Subject: [keycloak-dev] Change context-path of server from 'auth-server' to
	'auth'
Message-ID: <964271643.818084.1389626981984.JavaMail.root@redhat.com>

I was wondering if it would make sense to shorten the context-path from 'auth-server' to 'auth'? If so it would make sense to do this prior to releasing the alpha.

From ssilvert at redhat.com  Mon Jan 13 11:09:45 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Mon, 13 Jan 2014 11:09:45 -0500
Subject: [keycloak-dev] Change context-path of server from 'auth-server'
 to 'auth'
In-Reply-To: <964271643.818084.1389626981984.JavaMail.root@redhat.com>
References: <964271643.818084.1389626981984.JavaMail.root@redhat.com>
Message-ID: <52D40FC9.3030706@redhat.com>

On 1/13/2014 10:29 AM, Stian Thorgersen wrote:
> I was wondering if it would make sense to shorten the context-path from 'auth-server' to 'auth'? 
Why?
> If so it would make sense to do this prior to releasing the alpha.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Mon Jan 13 10:19:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jan 2014 10:19:21 -0500
Subject: [keycloak-dev] Logo ideas
In-Reply-To: <3A3A48FA-EC80-426C-8B48-147E78A68D32@redhat.com>
References: <B5EBAB20-C38F-4760-BAC5-4288081D8715@redhat.com>	<763381465.45938737.1389171946607.JavaMail.root@redhat.com>	<52CD3256.3030504@redhat.com>
	<etPan.52cd35bb.74b0dc51.65b9@tesla>	<E749FF4B-5A3C-4E2F-9DB4-84CCD0762838@redhat.com>	<E6ED7E38-B6E4-47E7-AE13-0338CBD53B73@redhat.com>	<478821299.592448.1389618372423.JavaMail.root@redhat.com>
	<3A3A48FA-EC80-426C-8B48-147E78A68D32@redhat.com>
Message-ID: <52D403F9.70101@redhat.com>

Few more days until release.  My fault...

On 1/13/2014 9:17 AM, Gabriel Cardoso wrote:
> Thanks for the feedback guys!
>
> Since we have a release today, I?ll leave the logo as it is but I?ll try
> some changes for a next version.
>
> Gabriel
>
> On Jan 13, 2014, at 11:06 AM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>> I was thinking the same. A couple of grooves would make it more
>> obvious that it's a key.
>>
>> Also, as the logo borders are quite thin, would it look better with a
>> less bold font?
>>
>> ----- Original Message -----
>>> From: "Alexandre Mendon?a" <amendonc at redhat.com
>>> <mailto:amendonc at redhat.com>>
>>> To: "Gabriel Cardoso" <gcardoso at redhat.com <mailto:gcardoso at redhat.com>>
>>> Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Monday, 13 January, 2014 11:50:22 AM
>>> Subject: Re: [keycloak-dev] Logo ideas
>>>
>>> Really nice work, Gabriel!
>>>
>>> Maybe I'd add a couple of grooves in the key, as looking at it without
>>> context it's not immediate to figure it's a key.. but not sure,
>>> really, it's
>>> great as it is :)
>>>
>>> Alexandre
>>>
>>> On 10 Jan 2014, at 19:17, Gabriel Cardoso < gcardoso at redhat.com
>>> <mailto:gcardoso at redhat.com> > wrote:
>>>
>>>
>>>
>>>
>>> Considering the majority of the votes, I worked on the version 1.
>>>
>>> Here is the proposal. What do you think?
>>>
>>> <Screen Shot 2014-01-10 at 5.15.39 PM.png>
>>>
>>> Gabriel
>>>
>>>
>>> On Jan 8, 2014, at 9:25 AM, Bruno Oliveira < bruno at abstractj.org
>>> <mailto:bruno at abstractj.org> > wrote:
>>>
>>>
>>>
>>>
>>> Only to be different, I would vote on #2 without the cape.
>>>
>>> --
>>> abstractj
>>>
>>> On January 8, 2014 at 9:11:45 AM, Boles?aw Dawidowicz (
>>> bdawidow at redhat.com <mailto:bdawidow at redhat.com> )
>>> wrote:
>>>
>>>
>>>
>>> I like 1, 3 and 4. #1 being a big ugly in current form but definitely
>>> with lot of potential
>>>
>>> On 01/08/2014 10:05 AM, Stian Thorgersen wrote:
>>>
>>>
>>> I really like #1 - maybe drop the star and make the key a little
>>> bit less cartoony?
>>>
>>>
>>>
>>> ----- Original Message -----
>>>
>>>
>>> From: "Gabriel Cardoso"
>>> To: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Tuesday, 7 January, 2014 8:57:26 PM
>>> Subject: [keycloak-dev] Logo ideas
>>>
>>> Hi,
>>>
>>> based on the concept of security and the ?key? and ?cloak? elements,
>>> I worked
>>>
>>>
>>>
>>>
>>> on some initial ideas for the logo.
>>>
>>> After we choose one or two ideas, I?ll refine the symbol, the
>>> font and put
>>>
>>>
>>>
>>>
>>> colours.
>>>
>>> Which proposal do you think is more interesting for the project?
>>>
>>> Thanks,
>>> Gabriel
>>>
>>> 01: I hope to have better background light effects for the final
>>> version
>>>
>>>
>>>
>>>
>>>
>>> 02: Will work more on the flying cloak
>>>
>>> 03: Maybe too ordinary
>>> 04: Will work more on the ?K? in the shield
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto: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
>>>
>>>
>>>
>>>
>>> --
>>> Boles?aw Dawidowicz
>>> JBoss Portal Platform Architect | GateIn Portal Project Lead
>>> _______________________________________________
>>> 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
>>>
>>> ---
>>> Gabriel Cardoso
>>> User Experience Designer @ Red Hat
>>>
>>> _______________________________________________
>>> 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
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Mon Jan 13 11:23:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jan 2014 11:23:45 -0500
Subject: [keycloak-dev] Change context-path of server from 'auth-server'
 to 'auth'
In-Reply-To: <964271643.818084.1389626981984.JavaMail.root@redhat.com>
References: <964271643.818084.1389626981984.JavaMail.root@redhat.com>
Message-ID: <52D41311.2000009@redhat.com>

Ya, let me do that as it affects documentation.  I forget, is there a 
way to set that in web.xml now?  Or do you have to do it still through a 
jboss/wildfly specific config?

Probably remove /saas from admin console URL and replace it with /admin. 
  Any other URLs to change?  What about changing URLs to use the realm 
name instead of the id?

On 1/13/2014 10:29 AM, Stian Thorgersen wrote:
> I was wondering if it would make sense to shorten the context-path from 'auth-server' to 'auth'? If so it would make sense to do this prior to releasing the alpha.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Mon Jan 13 11:33:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jan 2014 11:33:17 -0500
Subject: [keycloak-dev] build failure
Message-ID: <52D4154D.1080007@redhat.com>

Integration tests fail.

Bill

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

From stian at redhat.com  Mon Jan 13 11:37:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 11:37:45 -0500 (EST)
Subject: [keycloak-dev] build failure
In-Reply-To: <52D4154D.1080007@redhat.com>
References: <52D4154D.1080007@redhat.com>
Message-ID: <627307303.943460.1389631065229.JavaMail.root@redhat.com>

That'll be my fault - will fix now!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 January, 2014 4:33:17 PM
> Subject: [keycloak-dev] build failure
> 
> Integration tests fail.
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Jan 13 11:50:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 11:50:34 -0500 (EST)
Subject: [keycloak-dev] build failure
In-Reply-To: <627307303.943460.1389631065229.JavaMail.root@redhat.com>
References: <52D4154D.1080007@redhat.com>
	<627307303.943460.1389631065229.JavaMail.root@redhat.com>
Message-ID: <804539926.960478.1389631834469.JavaMail.root@redhat.com>

Fixed - I seem to be incapable of following the simple rule of always running the build/tests before pushing to main repo :/

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 January, 2014 4:37:45 PM
> Subject: Re: [keycloak-dev] build failure
> 
> That'll be my fault - will fix now!
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Monday, 13 January, 2014 4:33:17 PM
> > Subject: [keycloak-dev] build failure
> > 
> > Integration tests fail.
> > 
> > Bill
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > 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
> 

From stian at redhat.com  Mon Jan 13 12:27:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jan 2014 12:27:47 -0500 (EST)
Subject: [keycloak-dev] Change context-path of server from 'auth-server'
 to 'auth'
In-Reply-To: <52D41311.2000009@redhat.com>
References: <964271643.818084.1389626981984.JavaMail.root@redhat.com>
	<52D41311.2000009@redhat.com>
Message-ID: <1032929535.1003902.1389634067413.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 January, 2014 4:23:45 PM
> Subject: Re: [keycloak-dev] Change context-path of server from 'auth-server' to 'auth'
> 
> Ya, let me do that as it affects documentation.  I forget, is there a
> way to set that in web.xml now?  Or do you have to do it still through a
> jboss/wildfly specific config?

It's the module-name element. Already added to server.war.

> 
> Probably remove /saas from admin console URL and replace it with /admin.

+1

>   Any other URLs to change?  What about changing URLs to use the realm
> name instead of the id?

+1 

Would be good to do the same for admin console (both for realm and app).

> 
> On 1/13/2014 10:29 AM, Stian Thorgersen wrote:
> > I was wondering if it would make sense to shorten the context-path from
> > 'auth-server' to 'auth'? If so it would make sense to do this prior to
> > releasing the alpha.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Mon Jan 13 13:13:13 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 13 Jan 2014 19:13:13 +0100
Subject: [keycloak-dev] examples/distro reworked/improved/finalized
 PLEASE TRY!
In-Reply-To: <52D028D6.3020308@redhat.com>
References: <52CC5F9F.9070000@redhat.com>	<2073084489.47387522.1389280703311.JavaMail.root@redhat.com>	<52CECD16.1080500@redhat.com>	<1932731294.47624970.1389288115346.JavaMail.root@redhat.com>	<52CEE083.1090502@redhat.com>
	<52CFD0C9.9080307@redhat.com>	<52D00248.70407@redhat.com>
	<52D0116E.1090402@redhat.com>	<52D01A33.2060707@redhat.com>
	<52D028D6.3020308@redhat.com>
Message-ID: <52D42CB9.9050601@redhat.com>

On 10.1.2014 18:07, Marek Posolda wrote:
> On 10.1.2014 17:05, Bill Burke wrote:
>>
>> On 1/10/2014 10:27 AM, Marek Posolda wrote:
>>> On 10.1.2014 15:23, Bill Burke wrote:
>>>>
>>>> On 1/10/2014 5:51 AM, Marek Posolda wrote:
>>>>> Just a small note that there is a typo in
>>>>> https://github.com/keycloak/keycloak/blob/master/examples/as7-eap-demo/README.md
>>>>>
>>>>>
>>>>> in step1. For EAP 6.x it should be "keycloak-eap6-adapter-dist.zip"
>>>>> when
>>>>> currently it talks about "keycloak-as7-adapter-dist.zip" .
>>>>>
>>>> Good catch.
>>>>
>>>>> Another possible good thing would be to have "quickstart" appliance
>>>>> for
>>>>> everything bundled in single ZIP (wildfly server with auth-server,
>>>>> datasource, adapters, test-realm installed and all examples deployed).
>>>>> This will enable possibility for users to start really quickly playing
>>>>> with Keycloak without need to import realm in admin-console and
>>>>> build/deploy examples with maven. Of course, this may not be
>>>>> possible if
>>>>> examples will be moved to separate repo.
>>>>>
>>>> That's a *REALLY* good idea.  I'll do that.
>>>>
>>>> BTW, not sure about your addition to CDI yet to one of the examples.
>>>> We will be trimming down the Wildfly distro in the near future and CDI
>>>> will be one of the subsystems that will be removed.
>>> oops, I did it this way as you asked for it:-) You mentioned CDI or
>>> Spring in another thread.
>>>
>> I didn't think it all the way through, its my fault.  We can re-use
>> the file configuration stuff though you did.
> np, good that we clarify how to do it. So I will try to update my PR by
> Monday and will update both as7 and wildfly examples. Hope that 3rd
> attempt will be successful:-)
So I've refactored it as discussed. So now:
- Application "third-party" is reading configuration of 
ServletOAuthClient from JSON file. There is no other change in it
- Application "third-party-cdi" has been added with oauth-client example 
using CDI+JSF

I've added this to both as7-examples and wildfly-examples. For wildfly, 
I am seeing the ClassCastException issue described in 
https://issues.jboss.org/browse/KEYCLOAK-256 .

I didn't change anything in distribution, so for now, new application 
oauth-client-cdi is not used in any distribution.

According to latest stuff discussed in the list, it seems that URLs in 
newly added keycloak.json files would need to be changed as well. Let me 
know when refactoring of URLs is done and I will adapt again my PR (or 
you can change by yourself during merge of my PR:-) )

Marek


From gcardoso at redhat.com  Mon Jan 13 11:51:11 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 13 Jan 2014 14:51:11 -0200
Subject: [keycloak-dev] Keycloak.org
Message-ID: <3FF50FEB-7B45-407D-8A4B-317F17B52CE8@redhat.com>

I did a proposal to just update the header of Keycloak.org



Bill, can you give me access to the site so I can update it?

Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140113/d911acfa/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak-org.png
Type: image/png
Size: 271008 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140113/d911acfa/attachment-0001.png 

From bburke at redhat.com  Mon Jan 13 17:18:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jan 2014 17:18:23 -0500
Subject: [keycloak-dev] Change context-path of server from 'auth-server'
 to 'auth'
In-Reply-To: <1032929535.1003902.1389634067413.JavaMail.root@redhat.com>
References: <964271643.818084.1389626981984.JavaMail.root@redhat.com>
	<52D41311.2000009@redhat.com>
	<1032929535.1003902.1389634067413.JavaMail.root@redhat.com>
Message-ID: <52D4662F.5020602@redhat.com>



Ok, I change /auth-server /auth

and /saas to /admin

On 1/13/2014 12:27 PM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 13 January, 2014 4:23:45 PM
>> Subject: Re: [keycloak-dev] Change context-path of server from 'auth-server' to 'auth'
>>
>> Ya, let me do that as it affects documentation.  I forget, is there a
>> way to set that in web.xml now?  Or do you have to do it still through a
>> jboss/wildfly specific config?
>
> It's the module-name element. Already added to server.war.
>
>>
>> Probably remove /saas from admin console URL and replace it with /admin.
>
> +1
>
>>    Any other URLs to change?  What about changing URLs to use the realm
>> name instead of the id?
>
> +1
>
> Would be good to do the same for admin console (both for realm and app).
>
>>
>> On 1/13/2014 10:29 AM, Stian Thorgersen wrote:
>>> I was wondering if it would make sense to shorten the context-path from
>>> 'auth-server' to 'auth'? If so it would make sense to do this prior to
>>> releasing the alpha.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Tue Jan 14 11:27:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Jan 2014 11:27:34 -0500 (EST)
Subject: [keycloak-dev] Token scope
In-Reply-To: <1703077353.1834064.1389716693835.JavaMail.root@redhat.com>
Message-ID: <1565999090.1835788.1389716854047.JavaMail.root@redhat.com>

Could we use the standard scope attribute from JWT instead of the custom realm_access and resource_access?

An example scope could be:

{
  "scope": "realm-role,app-1/app-role-1,app-2/app-role-2"
}

From bburke at redhat.com  Tue Jan 14 12:05:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Jan 2014 12:05:11 -0500
Subject: [keycloak-dev] Token scope
In-Reply-To: <1565999090.1835788.1389716854047.JavaMail.root@redhat.com>
References: <1565999090.1835788.1389716854047.JavaMail.root@redhat.com>
Message-ID: <52D56E47.8080404@redhat.com>

No.  Why make the format more difficult?  We have to extend it anyways 
and will be extending it more.

On 1/14/2014 11:27 AM, Stian Thorgersen wrote:
> Could we use the standard scope attribute from JWT instead of the custom realm_access and resource_access?
>
> An example scope could be:
>
> {
>    "scope": "realm-role,app-1/app-role-1,app-2/app-role-2"
> }
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Jan 14 16:06:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Jan 2014 16:06:48 -0500
Subject: [keycloak-dev] next release: refactoring
Message-ID: <52D5A6E8.8020403@redhat.com>

After Alpha 1, I'd like to focus on refactoring and improving the 
overall code quality.  For example, it has been brutally painful to 
change URI schemes from /auth-server to /auth and also using Realm name 
instead of id to generate URLs.  This is a problem in both the admin 
console and services.  I'm sure there's other areas too.

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

From bburke at redhat.com  Tue Jan 14 16:28:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Jan 2014 16:28:50 -0500
Subject: [keycloak-dev] phase1 of url changes
Message-ID: <52D5AC12.7030001@redhat.com>

Everything now uses. I NEED PLEASE TO TEST EVERYTHING!  Something may 
have fell through the cracks.

/auth/rest/admin/realms/{realm-name}
/auth/rest/realms/{realm-name}/tokens
...

Details:
* This change was a BITCH!  64 files changed.
* ID *must* still be used in the data model for db secondary keys and 
constraints.
* Realm names are still mutable and changeable.

Phase 2 will be:

* Remove code-url and auth-url from adapter config and just go with 
"keycloak-url".  This will be the base URL of the server.
* Use application name instead of ID in application urls.

Any other URL changes?

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

From bburke at redhat.com  Tue Jan 14 16:32:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Jan 2014 16:32:53 -0500
Subject: [keycloak-dev] phase1 of url changes
In-Reply-To: <52D5AC12.7030001@redhat.com>
References: <52D5AC12.7030001@redhat.com>
Message-ID: <52D5AD05.2000607@redhat.com>



On 1/14/2014 4:28 PM, Bill Burke wrote:
> Everything now uses.

That should read "Everything now uses realm name in urls".

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

From mposolda at redhat.com  Tue Jan 14 18:02:03 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 15 Jan 2014 00:02:03 +0100
Subject: [keycloak-dev] phase1 of url changes
In-Reply-To: <52D5AC12.7030001@redhat.com>
References: <52D5AC12.7030001@redhat.com>
Message-ID: <52D5C1EB.9010105@redhat.com>

On 14.1.2014 22:28, Bill Burke wrote:
> Any other URL changes?
I vote for changing name of admin realm to something like "adminRealm" 
or "KeycloakAdministration" instead of "Keycloak Administration" . 
Similarly for changing application name from "Admin Console" tom 
something without space. It seems that it's defined in Constants.java, 
so looks like this won't be change in 64 files :-)

Maybe it's just my view, but I personally don't like spaces in names. I 
sometimes find it confusing and it may also cause some unexpected issues 
in some clients/browsers/environments. (I hate spaces in file/directory 
names on my filesystem as well. Of course, it's not a problem in 99.9% 
of cases but sometimes you can see buggy application and strange problem 
and after 1 hour of figuring it out, you find that only issue is space 
in the name...)

Marek

From stian at redhat.com  Wed Jan 15 04:18:36 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Jan 2014 04:18:36 -0500 (EST)
Subject: [keycloak-dev] next release: refactoring
In-Reply-To: <52D5A6E8.8020403@redhat.com>
References: <52D5A6E8.8020403@redhat.com>
Message-ID: <811892758.2536435.1389777516173.JavaMail.root@redhat.com>

As part of creating a non JavaEE dependent core I think we should extract code into reusable modules. All modules should have an SPI and be replaceable if needed. Without to much consideration I could imagine modules such as:

* OAuth2
* Model
* Forms (login, registration)
* Account Management
* URLs (URLs to everything)
* Admin?

For the main distribution there would also be:

* JAX-RS services
* WildFly sub-system

I think re-working things into reusable modules will solve a lot of the pain points in the code, as well as allow us to integrate Keycloak properly with LiveOak.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 14 January, 2014 9:06:48 PM
> Subject: [keycloak-dev] next release: refactoring
> 
> After Alpha 1, I'd like to focus on refactoring and improving the
> overall code quality.  For example, it has been brutally painful to
> change URI schemes from /auth-server to /auth and also using Realm name
> instead of id to generate URLs.  This is a problem in both the admin
> console and services.  I'm sure there's other areas too.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jan 15 04:24:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Jan 2014 04:24:44 -0500 (EST)
Subject: [keycloak-dev] phase1 of url changes
In-Reply-To: <52D5C1EB.9010105@redhat.com>
References: <52D5AC12.7030001@redhat.com> <52D5C1EB.9010105@redhat.com>
Message-ID: <1254820.2538860.1389777884970.JavaMail.root@redhat.com>

+1

I'd take it one step further and say all names should be URI safe

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 14 January, 2014 11:02:03 PM
> Subject: Re: [keycloak-dev] phase1 of url changes
> 
> On 14.1.2014 22:28, Bill Burke wrote:
> > Any other URL changes?
> I vote for changing name of admin realm to something like "adminRealm"
> or "KeycloakAdministration" instead of "Keycloak Administration" .
> Similarly for changing application name from "Admin Console" tom
> something without space. It seems that it's defined in Constants.java,
> so looks like this won't be change in 64 files :-)
> 
> Maybe it's just my view, but I personally don't like spaces in names. I
> sometimes find it confusing and it may also cause some unexpected issues
> in some clients/browsers/environments. (I hate spaces in file/directory
> names on my filesystem as well. Of course, it's not a problem in 99.9%
> of cases but sometimes you can see buggy application and strange problem
> and after 1 hour of figuring it out, you find that only issue is space
> in the name...)
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jan 15 07:34:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Jan 2014 07:34:49 -0500 (EST)
Subject: [keycloak-dev] phase1 of url changes
In-Reply-To: <52D5AC12.7030001@redhat.com>
References: <52D5AC12.7030001@redhat.com>
Message-ID: <1824682811.2672861.1389789289967.JavaMail.root@redhat.com>

So far everything is working here.

Would be great to do the same for applications in the admin rest endpoints and console. Don't think there's anywhere else we lookup applications based on id (only thing I can think of is client_id and that's set to the same as app name).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 14 January, 2014 9:28:50 PM
> Subject: [keycloak-dev] phase1 of url changes
> 
> Everything now uses. I NEED PLEASE TO TEST EVERYTHING!  Something may
> have fell through the cracks.
> 
> /auth/rest/admin/realms/{realm-name}
> /auth/rest/realms/{realm-name}/tokens
> ...
> 
> Details:
> * This change was a BITCH!  64 files changed.
> * ID *must* still be used in the data model for db secondary keys and
> constraints.
> * Realm names are still mutable and changeable.
> 
> Phase 2 will be:
> 
> * Remove code-url and auth-url from adapter config and just go with
> "keycloak-url".  This will be the base URL of the server.
> * Use application name instead of ID in application urls.
> 
> Any other URL changes?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jan 15 07:35:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Jan 2014 07:35:42 -0500 (EST)
Subject: [keycloak-dev] phase1 of url changes
In-Reply-To: <1824682811.2672861.1389789289967.JavaMail.root@redhat.com>
References: <52D5AC12.7030001@redhat.com>
	<1824682811.2672861.1389789289967.JavaMail.root@redhat.com>
Message-ID: <547746491.2673038.1389789342181.JavaMail.root@redhat.com>

Ignore that, just re-read your mail (app name is already planned) ;)

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 15 January, 2014 12:34:49 PM
> Subject: Re: [keycloak-dev] phase1 of url changes
> 
> So far everything is working here.
> 
> Would be great to do the same for applications in the admin rest endpoints
> and console. Don't think there's anywhere else we lookup applications based
> on id (only thing I can think of is client_id and that's set to the same as
> app name).
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 14 January, 2014 9:28:50 PM
> > Subject: [keycloak-dev] phase1 of url changes
> > 
> > Everything now uses. I NEED PLEASE TO TEST EVERYTHING!  Something may
> > have fell through the cracks.
> > 
> > /auth/rest/admin/realms/{realm-name}
> > /auth/rest/realms/{realm-name}/tokens
> > ...
> > 
> > Details:
> > * This change was a BITCH!  64 files changed.
> > * ID *must* still be used in the data model for db secondary keys and
> > constraints.
> > * Realm names are still mutable and changeable.
> > 
> > Phase 2 will be:
> > 
> > * Remove code-url and auth-url from adapter config and just go with
> > "keycloak-url".  This will be the base URL of the server.
> > * Use application name instead of ID in application urls.
> > 
> > Any other URL changes?
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From bburke at redhat.com  Wed Jan 15 09:58:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Jan 2014 09:58:26 -0500
Subject: [keycloak-dev] phase1 of url changes
In-Reply-To: <52D5C1EB.9010105@redhat.com>
References: <52D5AC12.7030001@redhat.com> <52D5C1EB.9010105@redhat.com>
Message-ID: <52D6A212.2070303@redhat.com>



On 1/14/2014 6:02 PM, Marek Posolda wrote:
> On 14.1.2014 22:28, Bill Burke wrote:
>> Any other URL changes?
> I vote for changing name of admin realm to something like "adminRealm"
> or "KeycloakAdministration" instead of "Keycloak Administration" .
> Similarly for changing application name from "Admin Console" tom
> something without space. It seems that it's defined in Constants.java,
> so looks like this won't be change in 64 files :-)
>

I'm changing:

"Keycloak Adminstration" to "keycloak-admin"
"Admin Console" to "admin-console"
"Account" to "account"

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

From bburke at redhat.com  Wed Jan 15 10:42:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Jan 2014 10:42:43 -0500
Subject: [keycloak-dev] phase1 of url changes
In-Reply-To: <52D6A212.2070303@redhat.com>
References: <52D5AC12.7030001@redhat.com> <52D5C1EB.9010105@redhat.com>
	<52D6A212.2070303@redhat.com>
Message-ID: <52D6AC73.9030603@redhat.com>



On 1/15/2014 9:58 AM, Bill Burke wrote:
>
>
> On 1/14/2014 6:02 PM, Marek Posolda wrote:
>> On 14.1.2014 22:28, Bill Burke wrote:
>>> Any other URL changes?
>> I vote for changing name of admin realm to something like "adminRealm"
>> or "KeycloakAdministration" instead of "Keycloak Administration" .
>> Similarly for changing application name from "Admin Console" tom
>> something without space. It seems that it's defined in Constants.java,
>> so looks like this won't be change in 64 files :-)
>>
>
> I'm changing:
>
> "Keycloak Adminstration" to "keycloak-admin"
> "Admin Console" to "admin-console"
> "Account" to "account"
>

BTW, the only thing I can't use names for is when creating role/scope 
mappings.  I'll have to use role.ids for that.


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

From bburke at redhat.com  Wed Jan 15 21:25:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Jan 2014 21:25:58 -0500
Subject: [keycloak-dev] url changes in
Message-ID: <52D74336.2050408@redhat.com>

realms, apps, and roles use names instead of ids now for admin ui and 
token service (where applicable).  Still need to do for oauth-clients, 
but I'll save that for next release.



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

From bburke at redhat.com  Wed Jan 15 21:37:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Jan 2014 21:37:37 -0500
Subject: [keycloak-dev] minimum doc requirements?
Message-ID: <52D745F1.90703@redhat.com>

What do we minimally need for documentation for Alpha 1?

* Install/Config Server
* Install/Config Adapters

I'm thinking that screencast tutorials would be much better than 
documentation.  IMO, its hard to document UIs.  Its better just seeing 
them in action, so for Alpha 1 I'll just do these screencast tutorials:

Tutorial #1:
* Create a realm through admin console for customer-portal demo
* Create roles, user, role mappings, scope mappings, applications etc.
* Obtain a keycloak.json file for the adapter configs.
* enable adapters for customer, product, and database portal.
Tutorial #2:
* Create an oauth-client
* configure third-party example and walk through it
* demo it.
Tutorial #3:
* Create a Google OAuth account
* Enable social login for demo
* Set up default roles
* Enable registration
Tutorial #4:
* Turning on TOTP.
* Managing users
Tutorial #5:
* Setting up SSL

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

From bburke at redhat.com  Wed Jan 15 21:40:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Jan 2014 21:40:31 -0500
Subject: [keycloak-dev] PRs allowed still, but...
Message-ID: <52D7469F.5000509@redhat.com>

If you want to send PRs please do, but PLEASE PLEASE check you don't 
break anything.  And do not do anything that will effect documentation.

Definitely doing a release Thursday 23rd.  As long as things work, that 
date is unmovable.  Whatever doco we have then is what we'll have.

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

From stian at redhat.com  Thu Jan 16 06:25:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Jan 2014 06:25:04 -0500 (EST)
Subject: [keycloak-dev] PRs allowed still, but...
In-Reply-To: <52D7469F.5000509@redhat.com>
References: <52D7469F.5000509@redhat.com>
Message-ID: <2026416133.4165610.1389871504105.JavaMail.root@redhat.com>

I'm having a few issues with social login. Both Google and Facebook have recently changed things around, and Twitter is not working either. There's also some issues with registration option on social login. I'll hopefully have these issues sorted today/tomorrow. I'll also update the documentation with instructions for configuring social login.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 16 January, 2014 2:40:31 AM
> Subject: [keycloak-dev] PRs allowed still, but...
> 
> If you want to send PRs please do, but PLEASE PLEASE check you don't
> break anything.  And do not do anything that will effect documentation.
> 
> Definitely doing a release Thursday 23rd.  As long as things work, that
> date is unmovable.  Whatever doco we have then is what we'll have.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Jan 16 08:50:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Jan 2014 08:50:45 -0500
Subject: [keycloak-dev] removed cookieLoginAllowed
Message-ID: <52D7E3B5.6060302@redhat.com>

I removed this switch.  It originally would set a identity cookie for 
the auth-server's domain/path if "true".  You can't really have SSO 
without it, so, I just removed it.  If somebody asks for the feature, 
we'll put it back in.

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

From gcardoso at redhat.com  Thu Jan 16 11:15:39 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 16 Jan 2014 14:15:39 -0200
Subject: [keycloak-dev] minimum doc requirements?
In-Reply-To: <52D745F1.90703@redhat.com>
References: <52D745F1.90703@redhat.com>
Message-ID: <73F931BD-D020-4190-9527-038BE5373673@redhat.com>

It would be good to provide a ?Documentation? link inside the console that leads to the list of tutorials.

Gabriel

On Jan 16, 2014, at 12:37 AM, Bill Burke <bburke at redhat.com> wrote:

> What do we minimally need for documentation for Alpha 1?
> 
> * Install/Config Server
> * Install/Config Adapters
> 
> I'm thinking that screencast tutorials would be much better than 
> documentation.  IMO, its hard to document UIs.  Its better just seeing 
> them in action, so for Alpha 1 I'll just do these screencast tutorials:
> 
> Tutorial #1:
> * Create a realm through admin console for customer-portal demo
> * Create roles, user, role mappings, scope mappings, applications etc.
> * Obtain a keycloak.json file for the adapter configs.
> * enable adapters for customer, product, and database portal.
> Tutorial #2:
> * Create an oauth-client
> * configure third-party example and walk through it
> * demo it.
> Tutorial #3:
> * Create a Google OAuth account
> * Enable social login for demo
> * Set up default roles
> * Enable registration
> Tutorial #4:
> * Turning on TOTP.
> * Managing users
> Tutorial #5:
> * Setting up SSL
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140116/4a10c5d8/attachment.html 

From stian at redhat.com  Thu Jan 16 11:16:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Jan 2014 11:16:17 -0500 (EST)
Subject: [keycloak-dev] PRs allowed still, but...
In-Reply-To: <2026416133.4165610.1389871504105.JavaMail.root@redhat.com>
References: <52D7469F.5000509@redhat.com>
	<2026416133.4165610.1389871504105.JavaMail.root@redhat.com>
Message-ID: <1991840681.4741724.1389888977564.JavaMail.root@redhat.com>

Pushed fixes to social:

* Google provider updated to use OpenID connect, and removed tons of dependencies from it
* On first social login there's now an option to review the profile (required user actions) instead of the social registration form

I'm going to test Facebook and Twitter tomorrow, and push changes for those if required

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 16 January, 2014 11:25:04 AM
> Subject: Re: [keycloak-dev] PRs allowed still, but...
> 
> I'm having a few issues with social login. Both Google and Facebook have
> recently changed things around, and Twitter is not working either. There's
> also some issues with registration option on social login. I'll hopefully
> have these issues sorted today/tomorrow. I'll also update the documentation
> with instructions for configuring social login.
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 16 January, 2014 2:40:31 AM
> > Subject: [keycloak-dev] PRs allowed still, but...
> > 
> > If you want to send PRs please do, but PLEASE PLEASE check you don't
> > break anything.  And do not do anything that will effect documentation.
> > 
> > Definitely doing a release Thursday 23rd.  As long as things work, that
> > date is unmovable.  Whatever doco we have then is what we'll have.
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > 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
> 

From stian at redhat.com  Thu Jan 16 11:55:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Jan 2014 11:55:13 -0500 (EST)
Subject: [keycloak-dev] Move instructions to configure social providers into
	documentation
In-Reply-To: <2084292638.4851023.1389891119543.JavaMail.root@redhat.com>
Message-ID: <1663010013.4852699.1389891313354.JavaMail.root@redhat.com>

Currently when adding a social provider there's a link (?) that opens a modal panel with instructions on how to configure the app with the social provider itself. For example when adding Google there's some instructions on how to create the application and what key/secrets should be added in the admin console.

Recently both Google and Facebook have changed their console making the way these are configured quite different. To update the instructions we're then required to update the admin console. As I see it there's two options:

a) Remove this feature and the required instructions to the Keycloak documentation - this is my prefer option
b) Make the social provider itself provide the instructions as a html snippet - this makes it possible to update the social provider jar and nothing else (for example keycloak-social-google.jar)

Thoughts?

From bburke at redhat.com  Thu Jan 16 12:00:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Jan 2014 12:00:03 -0500
Subject: [keycloak-dev] Move instructions to configure social providers
 into documentation
In-Reply-To: <1663010013.4852699.1389891313354.JavaMail.root@redhat.com>
References: <1663010013.4852699.1389891313354.JavaMail.root@redhat.com>
Message-ID: <52D81013.2060309@redhat.com>



On 1/16/2014 11:55 AM, Stian Thorgersen wrote:
> Currently when adding a social provider there's a link (?) that opens a modal panel with instructions on how to configure the app with the social provider itself. For example when adding Google there's some instructions on how to create the application and what key/secrets should be added in the admin console.
>
> Recently both Google and Facebook have changed their console making the way these are configured quite different. To update the instructions we're then required to update the admin console. As I see it there's two options:
>
> a) Remove this feature and the required instructions to the Keycloak documentation - this is my prefer option
> b) Make the social provider itself provide the instructions as a html snippet - this makes it possible to update the social provider jar and nothing else (for example keycloak-social-google.jar)
>

Do a) now, b) for next release?



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

From gcardoso at redhat.com  Thu Jan 16 14:56:39 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 16 Jan 2014 17:56:39 -0200
Subject: [keycloak-dev] Keycloak.org
In-Reply-To: <3FF50FEB-7B45-407D-8A4B-317F17B52CE8@redhat.com>
References: <3FF50FEB-7B45-407D-8A4B-317F17B52CE8@redhat.com>
Message-ID: <9BC1C4A5-1ED8-40B5-8C11-25917F2CADEF@redhat.com>

I unsuccessfully tried to update the Keycloak site.

Does anybody has experience with magnolia?

I could upload the banner, but I uploaded the logo and it did not appear in the banner. Also, the text in the banner changed to the right side. I would like to edit some css as well, but could not find the files?

Some clue?
Gabriel

On Jan 13, 2014, at 2:51 PM, Gabriel Cardoso <gcardoso at redhat.com> wrote:

> I did a proposal to just update the header of Keycloak.org
> 
> <keycloak-org.png>
> 
> Bill, can you give me access to the site so I can update it?
> 
> Gabriel
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140116/524087c3/attachment.html 

From bburke at redhat.com  Thu Jan 16 20:18:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Jan 2014 20:18:52 -0500
Subject: [keycloak-dev] more things we need
Message-ID: <52D884FC.1080702@redhat.com>

One thing I notice from doing the tutorial:

* User account management should be turned on by default
* Default roles should be visible even without registration and 
privileges should be automatic for the Account Server for all users.
* We don't need a User Account Management switch.  Admins can just 
choose to not set a default role for user account management.

I just think it will be rare to not have Acct Service turned off, so 
might as well set it up by default.

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

From bburke at redhat.com  Thu Jan 16 22:19:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Jan 2014 22:19:36 -0500
Subject: [keycloak-dev] demo-template
Message-ID: <52D8A148.6050500@redhat.com>

I removed all the examples/*-demo projecst and consolidated it into one 
project examples/demo-template. The distribution/examples-dist project 
sorts things out and creates 3 different copies in the example 
distribution with config files according to wildfy, as7, and a 3rd one, 
an unconfigured project (for screencast tutorial).


So, to run the demo now, you have have to create the distro for examples.

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

From bburke at redhat.com  Thu Jan 16 22:20:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Jan 2014 22:20:10 -0500
Subject: [keycloak-dev] Keycloak.org
In-Reply-To: <9BC1C4A5-1ED8-40B5-8C11-25917F2CADEF@redhat.com>
References: <3FF50FEB-7B45-407D-8A4B-317F17B52CE8@redhat.com>
	<9BC1C4A5-1ED8-40B5-8C11-25917F2CADEF@redhat.com>
Message-ID: <52D8A16A.2020108@redhat.com>

Email me the images offlist and I'll see if i can do it.

On 1/16/2014 2:56 PM, Gabriel Cardoso wrote:
> I unsuccessfully tried to update the Keycloak site.
>
> Does anybody has experience with magnolia?
>
> I could upload the banner, but I uploaded the logo and it did not appear
> in the banner. Also, the text in the banner changed to the right side. I
> would like to edit some css as well, but could not find the files?
>
> Some clue?
> Gabriel
>
> On Jan 13, 2014, at 2:51 PM, Gabriel Cardoso <gcardoso at redhat.com
> <mailto:gcardoso at redhat.com>> wrote:
>
>> I did a proposal to just update the header of Keycloak.org
>> <http://keycloak.org/>
>>
>> <keycloak-org.png>
>>
>> Bill, can you give me access to the site so I can update it?
>>
>> Gabriel
>>
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>>
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Jan 17 04:06:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 17 Jan 2014 04:06:48 -0500 (EST)
Subject: [keycloak-dev] more things we need
In-Reply-To: <52D884FC.1080702@redhat.com>
References: <52D884FC.1080702@redhat.com>
Message-ID: <791490306.5336528.1389949608059.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 17 January, 2014 1:18:52 AM
> Subject: [keycloak-dev] more things we need
> 
> One thing I notice from doing the tutorial:
> 
> * User account management should be turned on by default

Agreed - working on this now (also removing the option to disable it, if someone really wants that we can add it back later)

> * Default roles should be visible even without registration and
> privileges should be automatic for the Account Server for all users.

In the future this should use a default composite role, which would make the updating of users automatically. Updating users now would be very problematic for several reason, for example:

* Would need to update all users when a default role is added/removed
* If an admin explicitly removes some default roles for a set of users, we could end up adding it back if the default roles are changed

How about for the alpha we rename it from "Registration" to "Default Roles". Then we add those roles to users created through the admin console as well as self-registered users.

> * We don't need a User Account Management switch.  Admins can just
> choose to not set a default role for user account management.
> 
> I just think it will be rare to not have Acct Service turned off, so
> might as well set it up by default.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Jan 17 05:11:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 17 Jan 2014 05:11:44 -0500 (EST)
Subject: [keycloak-dev] more things we need
In-Reply-To: <791490306.5336528.1389949608059.JavaMail.root@redhat.com>
References: <52D884FC.1080702@redhat.com>
	<791490306.5336528.1389949608059.JavaMail.root@redhat.com>
Message-ID: <343831846.5388948.1389953504899.JavaMail.root@redhat.com>

User account management is now always turned on. There's no option to disable it in the realm settings, but if someone really wants to remove it they can remove the account application.

Default roles are now assigned to all new users (self-registered, created by admin, or imported from json). The Registration tab in the admin console is renamed to Default Roles and is always visible.

As I said before updating default roles for exiting users is risky, and would be best achieved with the introduction of composite roles. IMO we should hold off on this until after the alpha has been released. 

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 17 January, 2014 9:06:48 AM
> Subject: Re: [keycloak-dev] more things we need
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, 17 January, 2014 1:18:52 AM
> > Subject: [keycloak-dev] more things we need
> > 
> > One thing I notice from doing the tutorial:
> > 
> > * User account management should be turned on by default
> 
> Agreed - working on this now (also removing the option to disable it, if
> someone really wants that we can add it back later)
> 
> > * Default roles should be visible even without registration and
> > privileges should be automatic for the Account Server for all users.
> 
> In the future this should use a default composite role, which would make the
> updating of users automatically. Updating users now would be very
> problematic for several reason, for example:
> 
> * Would need to update all users when a default role is added/removed
> * If an admin explicitly removes some default roles for a set of users, we
> could end up adding it back if the default roles are changed
> 
> How about for the alpha we rename it from "Registration" to "Default Roles".
> Then we add those roles to users created through the admin console as well
> as self-registered users.
> 
> > * We don't need a User Account Management switch.  Admins can just
> > choose to not set a default role for user account management.
> > 
> > I just think it will be rare to not have Acct Service turned off, so
> > might as well set it up by default.
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > 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
> 

From bburke at redhat.com  Fri Jan 17 09:30:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Jan 2014 09:30:12 -0500
Subject: [keycloak-dev] more things we need
In-Reply-To: <791490306.5336528.1389949608059.JavaMail.root@redhat.com>
References: <52D884FC.1080702@redhat.com>
	<791490306.5336528.1389949608059.JavaMail.root@redhat.com>
Message-ID: <52D93E74.5000802@redhat.com>



On 1/17/2014 4:06 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 17 January, 2014 1:18:52 AM
>> Subject: [keycloak-dev] more things we need
>>
>> One thing I notice from doing the tutorial:
>>
>> * User account management should be turned on by default
>
> Agreed - working on this now (also removing the option to disable it, if someone really wants that we can add it back later)
>

Do you add a default role for the Acct Service?

>> * Default roles should be visible even without registration and
>> privileges should be automatic for the Account Server for all users.
>
> In the future this should use a default composite role, which would make the updating of users automatically. Updating users now would be very problematic for several reason, for example:
>

Yeah, thought we planned that already...

> * Would need to update all users when a default role is added/removed
> * If an admin explicitly removes some default roles for a set of users, we could end up adding it back if the default roles are changed
>
> How about for the alpha we rename it from "Registration" to "Default Roles". Then we add those roles to users created through the admin console as well as self-registered users.
>

+1

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

From stian at redhat.com  Fri Jan 17 09:33:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 17 Jan 2014 09:33:32 -0500 (EST)
Subject: [keycloak-dev] minimum doc requirements?
In-Reply-To: <73F931BD-D020-4190-9527-038BE5373673@redhat.com>
References: <52D745F1.90703@redhat.com>
	<73F931BD-D020-4190-9527-038BE5373673@redhat.com>
Message-ID: <799598678.5572984.1389969212759.JavaMail.root@redhat.com>

Personally I hate screencast tutorials, but I can imagine lots of people like them. 

My issues with screencast is that they take a long time to watch, and in the end you have an idea on how to do it, but you don't have the specifics. You may then have to rewind the screencast to find a particular point.

Documentation is much more straight to the point, and you can look up specific things you are wondering about directly and use it as a reference when you're trying to achieve something.

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 16 January, 2014 4:15:39 PM
> Subject: Re: [keycloak-dev] minimum doc requirements?
> 
> It would be good to provide a ?Documentation? link inside the console that
> leads to the list of tutorials.
> 
> Gabriel
> 
> On Jan 16, 2014, at 12:37 AM, Bill Burke < bburke at redhat.com > wrote:
> 
> 
> 
> What do we minimally need for documentation for Alpha 1?
> 
> * Install/Config Server
> * Install/Config Adapters
> 
> I'm thinking that screencast tutorials would be much better than
> documentation. IMO, its hard to document UIs. Its better just seeing
> them in action, so for Alpha 1 I'll just do these screencast tutorials:
> 
> Tutorial #1:
> * Create a realm through admin console for customer-portal demo
> * Create roles, user, role mappings, scope mappings, applications etc.
> * Obtain a keycloak.json file for the adapter configs.
> * enable adapters for customer, product, and database portal.
> Tutorial #2:
> * Create an oauth-client
> * configure third-party example and walk through it
> * demo it.
> Tutorial #3:
> * Create a Google OAuth account
> * Enable social login for demo
> * Set up default roles
> * Enable registration
> Tutorial #4:
> * Turning on TOTP.
> * Managing users
> Tutorial #5:
> * Setting up SSL
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jan 17 09:37:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 17 Jan 2014 09:37:22 -0500 (EST)
Subject: [keycloak-dev] more things we need
In-Reply-To: <52D93E74.5000802@redhat.com>
References: <52D884FC.1080702@redhat.com>
	<791490306.5336528.1389949608059.JavaMail.root@redhat.com>
	<52D93E74.5000802@redhat.com>
Message-ID: <653970381.5576705.1389969442967.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 17 January, 2014 2:30:12 PM
> Subject: Re: [keycloak-dev] more things we need
> 
> 
> 
> On 1/17/2014 4:06 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 17 January, 2014 1:18:52 AM
> >> Subject: [keycloak-dev] more things we need
> >>
> >> One thing I notice from doing the tutorial:
> >>
> >> * User account management should be turned on by default
> >
> > Agreed - working on this now (also removing the option to disable it, if
> > someone really wants that we can add it back later)
> >
> 
> Do you add a default role for the Acct Service?

Yes

> 
> >> * Default roles should be visible even without registration and
> >> privileges should be automatic for the Account Server for all users.
> >
> > In the future this should use a default composite role, which would make
> > the updating of users automatically. Updating users now would be very
> > problematic for several reason, for example:
> >
> 
> Yeah, thought we planned that already...

Yes, KEYCLOAK-120 for composite roles and I just added KEYCLOAK-267 to replace default roles with a single composite default role

> 
> > * Would need to update all users when a default role is added/removed
> > * If an admin explicitly removes some default roles for a set of users, we
> > could end up adding it back if the default roles are changed
> >
> > How about for the alpha we rename it from "Registration" to "Default
> > Roles". Then we add those roles to users created through the admin console
> > as well as self-registered users.
> >
> 
> +1
> 
> Yes, that too.--
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri Jan 17 09:38:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Jan 2014 09:38:44 -0500
Subject: [keycloak-dev] minimum doc requirements?
In-Reply-To: <799598678.5572984.1389969212759.JavaMail.root@redhat.com>
References: <52D745F1.90703@redhat.com>	<73F931BD-D020-4190-9527-038BE5373673@redhat.com>
	<799598678.5572984.1389969212759.JavaMail.root@redhat.com>
Message-ID: <52D94074.8030500@redhat.com>

I want documentation too, but screen casts are easier to put together, 
and this is an alpha release.  In the end, I'd like to have screen casts 
and docs that compliment each other.  Its often hard to write about 
visual things.


On 1/17/2014 9:33 AM, Stian Thorgersen wrote:
> Personally I hate screencast tutorials, but I can imagine lots of people like them.
>
> My issues with screencast is that they take a long time to watch, and in the end you have an idea on how to do it, but you don't have the specifics. You may then have to rewind the screencast to find a particular point.
>
> Documentation is much more straight to the point, and you can look up specific things you are wondering about directly and use it as a reference when you're trying to achieve something.
>
> ----- Original Message -----
>> From: "Gabriel Cardoso" <gcardoso at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 16 January, 2014 4:15:39 PM
>> Subject: Re: [keycloak-dev] minimum doc requirements?
>>
>> It would be good to provide a ?Documentation? link inside the console that
>> leads to the list of tutorials.
>>
>> Gabriel
>>
>> On Jan 16, 2014, at 12:37 AM, Bill Burke < bburke at redhat.com > wrote:
>>
>>
>>
>> What do we minimally need for documentation for Alpha 1?
>>
>> * Install/Config Server
>> * Install/Config Adapters
>>
>> I'm thinking that screencast tutorials would be much better than
>> documentation. IMO, its hard to document UIs. Its better just seeing
>> them in action, so for Alpha 1 I'll just do these screencast tutorials:
>>
>> Tutorial #1:
>> * Create a realm through admin console for customer-portal demo
>> * Create roles, user, role mappings, scope mappings, applications etc.
>> * Obtain a keycloak.json file for the adapter configs.
>> * enable adapters for customer, product, and database portal.
>> Tutorial #2:
>> * Create an oauth-client
>> * configure third-party example and walk through it
>> * demo it.
>> Tutorial #3:
>> * Create a Google OAuth account
>> * Enable social login for demo
>> * Set up default roles
>> * Enable registration
>> Tutorial #4:
>> * Turning on TOTP.
>> * Managing users
>> Tutorial #5:
>> * Setting up SSL
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>>
>>
>> _______________________________________________
>> 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
>

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

From bburke at redhat.com  Fri Jan 17 12:29:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Jan 2014 12:29:30 -0500
Subject: [keycloak-dev] minor console changes
Message-ID: <52D9687A.3080007@redhat.com>

* When creating a realm, Require SSL is set to true if the admin console 
was loaded with HTTPS, otherwise it is set to false.
* Default Roles page will show the "account" application by default.

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

From jbalunas at redhat.com  Fri Jan 17 16:09:22 2014
From: jbalunas at redhat.com (Jay Balunas)
Date: Fri, 17 Jan 2014 16:09:22 -0500
Subject: [keycloak-dev] AeroGear integration collaboration options
Message-ID: <F09DB71E-DB38-4D19-BD67-4AD8C22D2B6E@redhat.com>

Hi All,

Bill and I had a great talk earlier this week over a rather awesome couple of steaks where we talked about some possibilities of integration/collaboration between AeroGear and KeyCloak.  

I just started a thread over on the aerogear-dev list about this [1].  I wanted to make sure to share to get some discussions going :-)  

Thanks,
Jay

[1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-integration-ideas-td5820.html

From bburke at redhat.com  Fri Jan 17 21:48:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Jan 2014 21:48:04 -0500
Subject: [keycloak-dev] How to set up SMTP?
Message-ID: <52D9EB64.8090100@redhat.com>

I keep getting a validation error saying I didn't fill out the "From" 
value correctly.

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

From stian at redhat.com  Mon Jan 20 08:56:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Jan 2014 08:56:15 -0500 (EST)
Subject: [keycloak-dev] How to set up SMTP?
In-Reply-To: <52D9EB64.8090100@redhat.com>
References: <52D9EB64.8090100@redhat.com>
Message-ID: <690025382.6828652.1390226175726.JavaMail.root@redhat.com>

The From field is the sender mail address so needs to be a valid email. I've added instructions for configuring the email server to the documentation, and also done some minor improvements to the admin console to try to make it simpler

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 18 January, 2014 2:48:04 AM
> Subject: [keycloak-dev] How to set up SMTP?
> 
> I keep getting a validation error saying I didn't fill out the "From"
> value correctly.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Jan 20 10:28:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Jan 2014 10:28:13 -0500 (EST)
Subject: [keycloak-dev] Social updates and documentation
In-Reply-To: <2094308487.6963853.1390231457537.JavaMail.root@redhat.com>
Message-ID: <1100489453.6966163.1390231693161.JavaMail.root@redhat.com>

I've done some updates to social login:

* Moved instructions for configuring providers from admin console to documentation
* Updated Google provider
* Updated/fixed instructions for all providers

The reason for all these changes was the other day I tried to enable social login and neither of the providers we have worked. It turns out that Google has changed their console and apis. Facebook had changed its console. Finally, Twitter hadn't changed console or apis, but now requires all traffic to be over https (making it more difficult to test during development).

The lesson learned IMO, is:

1) Use Keycloak to enable social login - otherwise you have to muck about this yourself
2) We need to automate testing of the social providers - doing this manually is a real PITA

From stian at redhat.com  Mon Jan 20 10:33:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Jan 2014 10:33:32 -0500 (EST)
Subject: [keycloak-dev] Keycloak presenation
In-Reply-To: <1807381318.6969436.1390231925724.JavaMail.root@redhat.com>
Message-ID: <1807663669.6971027.1390232012057.JavaMail.root@redhat.com>

I recently did an introduction presentation to Keycloak including a demo of most current features. It's recorded on you Youtube if anyone is interested (fairly lengthy ~45 min!):

https://www.youtube.com/watch?v=rZGsIlQnzIs

Cheers,
Stian

From stian at redhat.com  Mon Jan 20 14:39:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Jan 2014 14:39:06 -0500 (EST)
Subject: [keycloak-dev] OpenShift cartridge ready
In-Reply-To: <1041971078.7159276.1390246419550.JavaMail.root@redhat.com>
Message-ID: <778246993.7161010.1390246746315.JavaMail.root@redhat.com>

Thanks to Corey Daley who's created a WildFly OpenShift cartridge we've now got a Keycloak OpenShift cartridge.

To try it out simply run:

# rhc app create keycloak https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml

Bill, can you get rid of the keycloak-openshift-quickstart and import the openshift-keycloak-cartridge (or give me permissions to the keycloak github organization)?

From bburke at redhat.com  Mon Jan 20 16:31:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 20 Jan 2014 16:31:26 -0500
Subject: [keycloak-dev] Keycloak presenation
In-Reply-To: <1807663669.6971027.1390232012057.JavaMail.root@redhat.com>
References: <1807663669.6971027.1390232012057.JavaMail.root@redhat.com>
Message-ID: <52DD95AE.9060708@redhat.com>

We'll add this to the list of screencasts

On 1/20/2014 10:33 AM, Stian Thorgersen wrote:
> I recently did an introduction presentation to Keycloak including a demo of most current features. It's recorded on you Youtube if anyone is interested (fairly lengthy ~45 min!):
>
> https://www.youtube.com/watch?v=rZGsIlQnzIs
>
> Cheers,
> Stian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Mon Jan 20 17:13:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 20 Jan 2014 17:13:18 -0500
Subject: [keycloak-dev] OpenShift cartridge ready
In-Reply-To: <778246993.7161010.1390246746315.JavaMail.root@redhat.com>
References: <778246993.7161010.1390246746315.JavaMail.root@redhat.com>
Message-ID: <52DD9F7E.9000604@redhat.com>

You mean add your SSH key?  Send it to me.

On 1/20/2014 2:39 PM, Stian Thorgersen wrote:
> Thanks to Corey Daley who's created a WildFly OpenShift cartridge we've now got a Keycloak OpenShift cartridge.
>
> To try it out simply run:
>
> # rhc app create keycloak https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
>
> Bill, can you get rid of the keycloak-openshift-quickstart and import the openshift-keycloak-cartridge (or give me permissions to the keycloak github organization)?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Jan 21 04:04:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 21 Jan 2014 04:04:41 -0500 (EST)
Subject: [keycloak-dev] OpenShift cartridge ready
In-Reply-To: <52DD9F7E.9000604@redhat.com>
References: <778246993.7161010.1390246746315.JavaMail.root@redhat.com>
	<52DD9F7E.9000604@redhat.com>
Message-ID: <627863141.7564842.1390295081219.JavaMail.root@redhat.com>

If you add me to the owners team I'll get permissions to add repos. If you go to https://github.com/keycloak, Edit Keycloak's profile, Owners you should be able to add me.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 20 January, 2014 10:13:18 PM
> Subject: Re: [keycloak-dev] OpenShift cartridge ready
> 
> You mean add your SSH key?  Send it to me.
> 
> On 1/20/2014 2:39 PM, Stian Thorgersen wrote:
> > Thanks to Corey Daley who's created a WildFly OpenShift cartridge we've now
> > got a Keycloak OpenShift cartridge.
> >
> > To try it out simply run:
> >
> > # rhc app create keycloak
> > https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
> >
> > Bill, can you get rid of the keycloak-openshift-quickstart and import the
> > openshift-keycloak-cartridge (or give me permissions to the keycloak
> > github organization)?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jan 21 09:15:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jan 2014 09:15:54 -0500
Subject: [keycloak-dev] OpenShift cartridge ready
In-Reply-To: <627863141.7564842.1390295081219.JavaMail.root@redhat.com>
References: <778246993.7161010.1390246746315.JavaMail.root@redhat.com>
	<52DD9F7E.9000604@redhat.com>
	<627863141.7564842.1390295081219.JavaMail.root@redhat.com>
Message-ID: <52DE811A.3000201@redhat.com>

I don't think it can be co-owned.  I'll just fork 
https://raw.github.com/stianst/openshift-keycloak-cartridge?


On 1/21/2014 4:04 AM, Stian Thorgersen wrote:
> If you add me to the owners team I'll get permissions to add repos. If you go to https://github.com/keycloak, Edit Keycloak's profile, Owners you should be able to add me.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 20 January, 2014 10:13:18 PM
>> Subject: Re: [keycloak-dev] OpenShift cartridge ready
>>
>> You mean add your SSH key?  Send it to me.
>>
>> On 1/20/2014 2:39 PM, Stian Thorgersen wrote:
>>> Thanks to Corey Daley who's created a WildFly OpenShift cartridge we've now
>>> got a Keycloak OpenShift cartridge.
>>>
>>> To try it out simply run:
>>>
>>> # rhc app create keycloak
>>> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
>>>
>>> Bill, can you get rid of the keycloak-openshift-quickstart and import the
>>> openshift-keycloak-cartridge (or give me permissions to the keycloak
>>> github organization)?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Tue Jan 21 09:31:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jan 2014 09:31:32 -0500
Subject: [keycloak-dev] Keycloak presenation
In-Reply-To: <1807663669.6971027.1390232012057.JavaMail.root@redhat.com>
References: <1807663669.6971027.1390232012057.JavaMail.root@redhat.com>
Message-ID: <52DE84C4.4010905@redhat.com>

I did 3 new screencast tutorials last week.  Just doing the demo from 
scratch.  Today going to do one for user mgmt:  acct status, totp, stuff 
like that, then a social one.  That's probably all I'll have time for. 
Then hopefully write some more doco Wed, then release on Thurs.

On 1/20/2014 10:33 AM, Stian Thorgersen wrote:
> I recently did an introduction presentation to Keycloak including a demo of most current features. It's recorded on you Youtube if anyone is interested (fairly lengthy ~45 min!):
>
> https://www.youtube.com/watch?v=rZGsIlQnzIs
>
> Cheers,
> Stian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Jan 21 10:02:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 21 Jan 2014 10:02:42 -0500 (EST)
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <1814381374.7825103.1390315714897.JavaMail.root@redhat.com>
Message-ID: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>

When writing documentation to using the admin console I realised the menus are confusing.

Most applications/websites have their main-menu at the top, with a sub-menu on the left (or right). 

Also I don't think there's any benefit to the breadcrumbs as we never navigate deep enough for it to be useful.

I propose that we move the items from the menu to the left into the same menu as the realm selector. Then we move the sub-menu items into the left menu. And also remove the breadcrumb. See attached screenshot for how this would look like.

I think this is a significant improvement, and it would be worth to get this into the alpha1 IMO. I can have this tested and committed today if there's consent for it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: menu-proposal.png
Type: image/png
Size: 45087 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140121/793ab808/attachment-0001.png 

From vrockai at redhat.com  Tue Jan 21 10:37:23 2014
From: vrockai at redhat.com (Viliam Rockai)
Date: Tue, 21 Jan 2014 16:37:23 +0100
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
References: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
Message-ID: <1390318643.2797.4.camel@vrockai-laptop>

Looks better and it's less confusing. Even if there will be any
objections from professional point of view (gabriel:) this is still
better than the current state. 

On Tue, 2014-01-21 at 10:02 -0500, Stian Thorgersen wrote:
> When writing documentation to using the admin console I realised the menus are confusing.
> 
> Most applications/websites have their main-menu at the top, with a sub-menu on the left (or right). 
> 
> Also I don't think there's any benefit to the breadcrumbs as we never navigate deep enough for it to be useful.
> 
> I propose that we move the items from the menu to the left into the same menu as the realm selector. Then we move the sub-menu items into the left menu. And also remove the breadcrumb. See attached screenshot for how this would look like.
> 
> I think this is a significant improvement, and it would be worth to get this into the alpha1 IMO. I can have this tested and committed today if there's consent for it!
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bburke at redhat.com  Tue Jan 21 10:47:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jan 2014 10:47:27 -0500
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
References: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
Message-ID: <52DE968F.3060301@redhat.com>

#1, I've used and like the breadcrumbs.
#2, I don't think this is as significant as you claim.  This is 
completely an aesthetic change.  It doesn't reduce any clicks.  At least 
as compared to Wildfly/JBoss console, *most* of interesting menu items 
are on the left side.
#3, We may run out of room on the top menu as we may be adding things 
like "devices" and "servers".  Not everybody has 1900x1200 displays and 
the admin UI already bearly fits in 1024x800 screencasts.
#4, This change wastes a week of work I did on screencasts for minimal 
gain.  I'm going to be seriously pissed if I have to redo these before 
Thursday...

So, -1 and no vote for me at least for Alpha 1.

On 1/21/2014 10:02 AM, Stian Thorgersen wrote:
> When writing documentation to using the admin console I realised the menus are confusing.
>
> Most applications/websites have their main-menu at the top, with a sub-menu on the left (or right).
>
> Also I don't think there's any benefit to the breadcrumbs as we never navigate deep enough for it to be useful.
>
> I propose that we move the items from the menu to the left into the same menu as the realm selector. Then we move the sub-menu items into the left menu. And also remove the breadcrumb. See attached screenshot for how this would look like.
>
> I think this is a significant improvement, and it would be worth to get this into the alpha1 IMO. I can have this tested and committed today if there's consent for it!
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Jan 21 10:59:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jan 2014 10:59:44 -0500
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <52DE968F.3060301@redhat.com>
References: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
	<52DE968F.3060301@redhat.com>
Message-ID: <52DE9970.4020406@redhat.com>

I think "most applications/websites have their main menu at the top" is 
a stianism.  cloud.google.com has their menu on the left.  gmail has 
their menu both on the left and top.  Github has their menus on right. 
Wordpress has their console menus on the left.
.
So I'd say that most applications/websites have completely different 
ways of organizing their menus and I find this change does nothing for 
me other than waste a week of work I did.

On 1/21/2014 10:47 AM, Bill Burke wrote:
> #1, I've used and 	like the breadcrumbs.
> #2, I don't think this is as significant as you claim.  This is
> completely an aesthetic change.  It doesn't reduce any clicks.  At least
> as compared to Wildfly/JBoss console, *most* of interesting menu items
> are on the left side.
> #3, We may run out of room on the top menu as we may be adding things
> like "devices" and "servers".  Not everybody has 1900x1200 displays and
> the admin UI already bearly fits in 1024x800 screencasts.
> #4, This change wastes a week of work I did on screencasts for minimal
> gain.  I'm going to be seriously pissed if I have to redo these before
> Thursday...
>
> So, -1 and no vote for me at least for Alpha 1.
>
> On 1/21/2014 10:02 AM, Stian Thorgersen wrote:
>> When writing documentation to using the admin console I realised the menus are confusing.
>>
>> Most applications/websites have their main-menu at the top, with a sub-menu on the left (or right).
>>
>> Also I don't think there's any benefit to the breadcrumbs as we never navigate deep enough for it to be useful.
>>
>> I propose that we move the items from the menu to the left into the same menu as the realm selector. Then we move the sub-menu items into the left menu. And also remove the breadcrumb. See attached screenshot for how this would look like.
>>
>> I think this is a significant improvement, and it would be worth to get this into the alpha1 IMO. I can have this tested and committed today if there's consent for it!
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From stian at redhat.com  Tue Jan 21 11:27:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 21 Jan 2014 11:27:41 -0500 (EST)
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <52DE9970.4020406@redhat.com>
References: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
	<52DE968F.3060301@redhat.com> <52DE9970.4020406@redhat.com>
Message-ID: <229920846.8150282.1390321661684.JavaMail.root@redhat.com>

I hadn't considered the screencasts, and it does result in this having a much bigger impact than I'd considered. So it's definitively not something to do now, probably not in the future either.

Just to clarify, I was considering sites that have a main and a sub navigation menu. So for those sites you've listed:

* cloud.google.com - has a single navigation menu, so it can be on the left that's fine
* gmail - has a single navigation menu, the bit above lists/mails are tools for the particular view
* github - has two navigation menus, the main (explore, gist, blog) is at the top, while the sub is at the right (code, pr, etc..) / github is horrible though, I always have to search around to find things
* wordpress - can't comment as I don't use it

It goes to reason that a user scans a page from top to bottom, and in a LTR language from left to right. Hence the menus should be placed according to scan-order. Talking about screen estate this would save 90px in vertical height, which is around 10% on most displays, but I appreciate that horizontal scaling is acceptable.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 21 January, 2014 3:59:44 PM
> Subject: Re: [keycloak-dev] Proposed changes to menu
> 
> I think "most applications/websites have their main menu at the top" is
> a stianism.  cloud.google.com has their menu on the left.  gmail has
> their menu both on the left and top.  Github has their menus on right.
> Wordpress has their console menus on the left.
> .
> So I'd say that most applications/websites have completely different
> ways of organizing their menus and I find this change does nothing for
> me other than waste a week of work I did.
> 
> On 1/21/2014 10:47 AM, Bill Burke wrote:
> > #1, I've used and 	like the breadcrumbs.
> > #2, I don't think this is as significant as you claim.  This is
> > completely an aesthetic change.  It doesn't reduce any clicks.  At least
> > as compared to Wildfly/JBoss console, *most* of interesting menu items
> > are on the left side.
> > #3, We may run out of room on the top menu as we may be adding things
> > like "devices" and "servers".  Not everybody has 1900x1200 displays and
> > the admin UI already bearly fits in 1024x800 screencasts.
> > #4, This change wastes a week of work I did on screencasts for minimal
> > gain.  I'm going to be seriously pissed if I have to redo these before
> > Thursday...
> >
> > So, -1 and no vote for me at least for Alpha 1.
> >
> > On 1/21/2014 10:02 AM, Stian Thorgersen wrote:
> >> When writing documentation to using the admin console I realised the menus
> >> are confusing.
> >>
> >> Most applications/websites have their main-menu at the top, with a
> >> sub-menu on the left (or right).
> >>
> >> Also I don't think there's any benefit to the breadcrumbs as we never
> >> navigate deep enough for it to be useful.
> >>
> >> I propose that we move the items from the menu to the left into the same
> >> menu as the realm selector. Then we move the sub-menu items into the left
> >> menu. And also remove the breadcrumb. See attached screenshot for how
> >> this would look like.
> >>
> >> I think this is a significant improvement, and it would be worth to get
> >> this into the alpha1 IMO. I can have this tested and committed today if
> >> there's consent for it!
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jan 21 12:37:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 21 Jan 2014 12:37:59 -0500 (EST)
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <52DEAC48.8080001@redhat.com>
References: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
	<52DE968F.3060301@redhat.com> <52DE9970.4020406@redhat.com>
	<229920846.8150282.1390321661684.JavaMail.root@redhat.com>
	<52DEAC48.8080001@redhat.com>
Message-ID: <777918473.8240612.1390325879607.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 21 January, 2014 5:20:08 PM
> Subject: Re: [keycloak-dev] Proposed changes to menu
> 
> 
> 
> On 1/21/2014 11:27 AM, Stian Thorgersen wrote:
> > I hadn't considered the screencasts, and it does result in this having a
> > much bigger impact than I'd considered. So it's definitively not something
> > to do now, probably not in the future either.
> >
> 
> I'm just being whiny and lazy and trying to find some lame reasons not
> to have to redo the screencasts, but I really don't want to delay
> another week.  If our current UI is inconsistent with Wildfly/JBoss
> admin console, we should probably change it.  I'd really like Gabriel to
> comment though...

Nah - it's a fair comment. Delaying for this is not a good idea, and redoing a bunch of screencasts is very time consuming. With that in mind I wouldn't have proposed this change.

Overall I think the usability of the admin console is really good. There probably could be improvements, but we shouldn't do anything without feedback from real users.

> 
> (BTW, I agree github is horrible...I can never figure out where things
> are and always forget).
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue Jan 21 12:20:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jan 2014 12:20:08 -0500
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <229920846.8150282.1390321661684.JavaMail.root@redhat.com>
References: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
	<52DE968F.3060301@redhat.com> <52DE9970.4020406@redhat.com>
	<229920846.8150282.1390321661684.JavaMail.root@redhat.com>
Message-ID: <52DEAC48.8080001@redhat.com>



On 1/21/2014 11:27 AM, Stian Thorgersen wrote:
> I hadn't considered the screencasts, and it does result in this having a much bigger impact than I'd considered. So it's definitively not something to do now, probably not in the future either.
>

I'm just being whiny and lazy and trying to find some lame reasons not 
to have to redo the screencasts, but I really don't want to delay 
another week.  If our current UI is inconsistent with Wildfly/JBoss 
admin console, we should probably change it.  I'd really like Gabriel to 
comment though...

(BTW, I agree github is horrible...I can never figure out where things 
are and always forget).


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

From gcardoso at redhat.com  Tue Jan 21 14:41:00 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Tue, 21 Jan 2014 17:41:00 -0200
Subject: [keycloak-dev] Proposed changes to menu
In-Reply-To: <777918473.8240612.1390325879607.JavaMail.root@redhat.com>
References: <376394460.7841029.1390316562057.JavaMail.root@redhat.com>
	<52DE968F.3060301@redhat.com> <52DE9970.4020406@redhat.com>
	<229920846.8150282.1390321661684.JavaMail.root@redhat.com>
	<52DEAC48.8080001@redhat.com>
	<777918473.8240612.1390325879607.JavaMail.root@redhat.com>
Message-ID: <65623EB6-60F8-414C-AA9F-71E595D2F97F@redhat.com>

Hi guys,

I guess the way the navigation is structured right now is a side effect of my original design proposal, where we had a top level of navigation with ?Overview?, ?Applications? and ?Realms?. I probably just replaced the top nav by the dropdown and honestly I did not consider putting the sidebar at the top.



I consider Stian?s change interesting since it optimizes the vertical space and removes one level of navigation. Usability wise, it is hard to say, probably better for the firsts accesses but with no gain after a couple of usages (since the user will get familiar with the navigation). 

I don't consider the removal of the breadcrumb something good since some people use it (Bill and I, at least) and it might reveal some level of navigation that is not displayed in the menu (e.g. My realm > Applications > My application > Roles). In this case, My application was not visible on the menus, so it helps the user to know where he is. 

I know that we won?t do anything now, but I just wanted to express my point of view ;)

Gabriel

On Jan 21, 2014, at 3:37 PM, Stian Thorgersen <stian at redhat.com> 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: Tuesday, 21 January, 2014 5:20:08 PM
>> Subject: Re: [keycloak-dev] Proposed changes to menu
>> 
>> 
>> 
>> On 1/21/2014 11:27 AM, Stian Thorgersen wrote:
>>> I hadn't considered the screencasts, and it does result in this having a
>>> much bigger impact than I'd considered. So it's definitively not something
>>> to do now, probably not in the future either.
>>> 
>> 
>> I'm just being whiny and lazy and trying to find some lame reasons not
>> to have to redo the screencasts, but I really don't want to delay
>> another week.  If our current UI is inconsistent with Wildfly/JBoss
>> admin console, we should probably change it.  I'd really like Gabriel to
>> comment though...
> 
> Nah - it's a fair comment. Delaying for this is not a good idea, and redoing a bunch of screencasts is very time consuming. With that in mind I wouldn't have proposed this change.
> 
> Overall I think the usability of the admin console is really good. There probably could be improvements, but we shouldn't do anything without feedback from real users.
> 
>> 
>> (BTW, I agree github is horrible...I can never figure out where things
>> are and always forget).
>> 
>> 
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140121/2cad41c5/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: advanced-search1.png
Type: image/png
Size: 47827 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140121/2cad41c5/attachment-0001.png 

From bburke at redhat.com  Tue Jan 21 20:01:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jan 2014 20:01:44 -0500
Subject: [keycloak-dev] downloads@sf.net?
Message-ID: <52DF1878.2000601@redhat.com>

I like to avoid rht eng-ops as much as possible.  Anybody have any 
reservations about hosting downloads at sf.net?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Tue Jan 21 21:01:02 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 22 Jan 2014 00:01:02 -0200
Subject: [keycloak-dev] downloads@sf.net?
In-Reply-To: <52DF1878.2000601@redhat.com>
References: <52DF1878.2000601@redhat.com>
Message-ID: <CAM5SUC7aWxyY3+bRLGBQST3p-=6+G6Zgn1FYEfQGJbvSo_tdOg@mail.gmail.com>

Hi Bill, we've been using https://bintray.com on AeroGear, as far as I can
tell, no problems at all.


On Tue, Jan 21, 2014 at 11:01 PM, Bill Burke <bburke at redhat.com> wrote:

> I like to avoid rht eng-ops as much as possible.  Anybody have any
> reservations about hosting downloads at sf.net?
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140122/8d9933a2/attachment.html 

From bburke at redhat.com  Tue Jan 21 22:55:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jan 2014 22:55:08 -0500
Subject: [keycloak-dev] Disabling Password Policies
Message-ID: <52DF411C.9040701@redhat.com>

I'm hiding/disabling Password Policies as they don't work:

* After adding a policy you refresh/revisit the page, the policy value 
doesn't show up (although the value is saved in storage).  This is an 
angular issue.
* password policy is not checked for "update password" when logging in 
(only for registration and Acct Service it seems).

Since we're very close to release, we can fix this after please.


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

From matzew at apache.org  Wed Jan 22 00:28:35 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 22 Jan 2014 06:28:35 +0100
Subject: [keycloak-dev] downloads@sf.net?
In-Reply-To: <CAM5SUC7aWxyY3+bRLGBQST3p-=6+G6Zgn1FYEfQGJbvSo_tdOg@mail.gmail.com>
References: <52DF1878.2000601@redhat.com>
	<CAM5SUC7aWxyY3+bRLGBQST3p-=6+G6Zgn1FYEfQGJbvSo_tdOg@mail.gmail.com>
Message-ID: <CAAg5f2Rkh-Fxpm8f5Q_TqCTSUKDjMzX7qtZs3dW2Mh3Osb9Ftg@mail.gmail.com>

On Wed, Jan 22, 2014 at 3:01 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Hi Bill, we've been using https://bintray.com on AeroGear, as far as I
> can tell, no problems at all.
>

+1 bintray works very well


>
>
> On Tue, Jan 21, 2014 at 11:01 PM, Bill Burke <bburke at redhat.com> wrote:
>
>> I like to avoid rht eng-ops as much as possible.  Anybody have any
>> reservations about hosting downloads at sf.net?
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140122/ff617f3b/attachment.html 

From bruno at abstractj.org  Wed Jan 22 07:55:46 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 22 Jan 2014 10:55:46 -0200
Subject: [keycloak-dev] Password storage and KDFs
Message-ID: <etPan.52dfbfd2.6b8b4567.205a@tesla>

Good morning guys, as a suggestion to improve the way how the passwords have been stored in nowadays I did some changes to support PBKDF2[1] (we have been doing the same thing on AeroGear for mobile devices), into this way is possible to prevent rainbow tables and brute force attacks like HashCat does for example.

I'm completely fine on adding bcrypt as long as we include some KDF, I just didn't that because I would like to hear some feedback before move forward, not sure if makes sense but my suggestion is to remove SHA-* encoders because they can be easily broken and replace by the support for PBKDF2 and bcrypt only.

What do you think? Let me know if I should move forward or that doesn't fit.

[1] - https://github.com/keycloak/keycloak/pull/171


-- 
abstractj

From bburke at redhat.com  Wed Jan 22 08:55:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 22 Jan 2014 08:55:10 -0500
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <etPan.52dfbfd2.6b8b4567.205a@tesla>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla>
Message-ID: <52DFCDBE.3050705@redhat.com>

Question:

How can they easily be broken?  If somebody gets the password database?

On 1/22/2014 7:55 AM, Bruno Oliveira wrote:
> Good morning guys, as a suggestion to improve the way how the passwords have been stored in nowadays I did some changes to support PBKDF2[1] (we have been doing the same thing on AeroGear for mobile devices), into this way is possible to prevent rainbow tables and brute force attacks like HashCat does for example.
>
> I'm completely fine on adding bcrypt as long as we include some KDF, I just didn't that because I would like to hear some feedback before move forward, not sure if makes sense but my suggestion is to remove SHA-* encoders because they can be easily broken and replace by the support for PBKDF2 and bcrypt only.
>
> What do you think? Let me know if I should move forward or that doesn't fit.
>
> [1] - https://github.com/keycloak/keycloak/pull/171
>
>

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

From bruno at abstractj.org  Wed Jan 22 09:00:26 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 22 Jan 2014 12:00:26 -0200
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <52DFCDBE.3050705@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52DFCDBE.3050705@redhat.com>
Message-ID: <etPan.52dfcefa.66334873.205a@tesla>

Yes, Bill. Off the top of my head the common use case scenario would be that, an attacker in possession of some hashed passwords, could try to break it. Two examples:

- MITM: I?m just collection the data into the network and once I know that: Bob and Alice has the same hash, if you are doing SHA-* is easy to guess that they have the same password.
- Database compromised: Like happend with LinkedIn (http://www.zdnet.com/blog/btl/6-46-million-linkedin-passwords-leaked-online/79290) and you already mentioned.

--  
abstractj

On January 22, 2014 at 11:55:12 AM, Bill Burke (bburke at redhat.com) wrote:
> > Question:
>  
> How can they easily be broken? If somebody gets the password database?  



From bburke at redhat.com  Wed Jan 22 09:24:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 22 Jan 2014 09:24:32 -0500
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <etPan.52dfcefa.66334873.205a@tesla>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52DFCDBE.3050705@redhat.com>
	<etPan.52dfcefa.66334873.205a@tesla>
Message-ID: <52DFD4A0.7020302@redhat.com>

I'll accept your PR after I release tomorrow.

On 1/22/2014 9:00 AM, Bruno Oliveira wrote:
> Yes, Bill. Off the top of my head the common use case scenario would be that, an attacker in possession of some hashed passwords, could try to break it. Two examples:
>
> - MITM: I?m just collection the data into the network and once I know that: Bob and Alice has the same hash, if you are doing SHA-* is easy to guess that they have the same password.
> - Database compromised: Like happend with LinkedIn (http://www.zdnet.com/blog/btl/6-46-million-linkedin-passwords-leaked-online/79290) and you already mentioned.
>
> --
> abstractj
>
> On January 22, 2014 at 11:55:12 AM, Bill Burke (bburke at redhat.com) wrote:
>>> Question:
>>
>> How can they easily be broken? If somebody gets the password database?
>

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

From bruno at abstractj.org  Wed Jan 22 09:25:20 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 22 Jan 2014 12:25:20 -0200
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <52DFD4A0.7020302@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla>
	<52DFCDBE.3050705@redhat.com> <etPan.52dfcefa.66334873.205a@tesla>
	<52DFD4A0.7020302@redhat.com>
Message-ID: <etPan.52dfd4d0.74b0dc51.205a@tesla>

Thank you Bill, awesome!

-- 
abstractj

On January 22, 2014 at 12:24:32 PM, Bill Burke (bburke at redhat.com) wrote:
> > I'll accept your PR after I release tomorrow.


From bburke at redhat.com  Wed Jan 22 09:31:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 22 Jan 2014 09:31:03 -0500
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <etPan.52dfd4d0.74b0dc51.205a@tesla>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52DFCDBE.3050705@redhat.com>
	<etPan.52dfcefa.66334873.205a@tesla> <52DFD4A0.7020302@redhat.com>
	<etPan.52dfd4d0.74b0dc51.205a@tesla>
Message-ID: <52DFD627.8070005@redhat.com>

BTW, we'll have to think of something similar to protect realm private 
keys.  Getting access to the private key of a realm would be 1000 times 
worse than getting the PW database as you could write a token giving any 
permission you wanted.

Any ideas?  Maybe a master boot password which is used to encrypt the 
private keys?  Which is entered on server startup?

On 1/22/2014 9:25 AM, Bruno Oliveira wrote:
> Thank you Bill, awesome!
>

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

From bruno at abstractj.org  Wed Jan 22 09:39:11 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 22 Jan 2014 12:39:11 -0200
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <52DFD627.8070005@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla>
	<52DFCDBE.3050705@redhat.com> <etPan.52dfcefa.66334873.205a@tesla>
	<52DFD4A0.7020302@redhat.com> <etPan.52dfd4d0.74b0dc51.205a@tesla>
	<52DFD627.8070005@redhat.com>
Message-ID: <etPan.52dfd810.19495cff.205a@tesla>

We did something on AeroGear with property file (not perfect), but I would like to look at Keycloak before suggest anything. Maybe is possible implement using the KeyStore from Java?


-- 
abstractj

On January 22, 2014 at 12:31:05 PM, Bill Burke (bburke at redhat.com) wrote:
> > BTW, we'll have to think of something similar to protect realm 
> private
> keys. Getting access to the private key of a realm would be 1000 
> times
> worse than getting the PW database as you could write a token giving 
> any
> permission you wanted.
> 
> Any ideas? Maybe a master boot password which is used to encrypt 
> the
> private keys? Which is entered on server startup?


From bburke at redhat.com  Wed Jan 22 09:43:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 22 Jan 2014 09:43:51 -0500
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <etPan.52dfd810.19495cff.205a@tesla>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52DFCDBE.3050705@redhat.com>
	<etPan.52dfcefa.66334873.205a@tesla> <52DFD4A0.7020302@redhat.com>
	<etPan.52dfd4d0.74b0dc51.205a@tesla> <52DFD627.8070005@redhat.com>
	<etPan.52dfd810.19495cff.205a@tesla>
Message-ID: <52DFD927.9040908@redhat.com>

Using a property file sort of defeats the purpose of encrypting the 
keys.  The password must be stored in the human brain, IMO :)  I'd like 
to store keys as text in the db.  They are already stored in PEM format.

On 1/22/2014 9:39 AM, Bruno Oliveira wrote:
> We did something on AeroGear with property file (not perfect), but I would like to look at Keycloak before suggest anything. Maybe is possible implement using the KeyStore from Java?
>
>

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

From bruno at abstractj.org  Wed Jan 22 09:46:13 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 22 Jan 2014 12:46:13 -0200
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <52DFD927.9040908@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla>
	<52DFCDBE.3050705@redhat.com> <etPan.52dfcefa.66334873.205a@tesla>
	<52DFD4A0.7020302@redhat.com> <etPan.52dfd4d0.74b0dc51.205a@tesla>
	<52DFD627.8070005@redhat.com> <etPan.52dfd810.19495cff.205a@tesla>
	<52DFD927.9040908@redhat.com>
Message-ID: <etPan.52dfd9b5.2ae8944a.205a@tesla>

Agreed with that, makes sense. Either way, I will think about it and see where is possible to help.

-- 
abstractj

On January 22, 2014 at 12:43:51 PM, Bill Burke (bburke at redhat.com) wrote:
> > Using a property file sort of defeats the purpose of encrypting 
> the
> keys. The password must be stored in the human brain, IMO :) I'd 
> like
> to store keys as text in the db. They are already stored in PEM format. 


From stian at redhat.com  Wed Jan 22 10:05:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jan 2014 10:05:43 -0500 (EST)
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <52DFD927.9040908@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52DFCDBE.3050705@redhat.com>
	<etPan.52dfcefa.66334873.205a@tesla> <52DFD4A0.7020302@redhat.com>
	<etPan.52dfd4d0.74b0dc51.205a@tesla> <52DFD627.8070005@redhat.com>
	<etPan.52dfd810.19495cff.205a@tesla> <52DFD927.9040908@redhat.com>
Message-ID: <1860698230.8955434.1390403143904.JavaMail.root@redhat.com>

I think having to enter a master password to start the server could make it quite difficult to manage, especially in clouds and provisioned environments. It should be available as an option though.

Properties file could be the default. We could create a random password and store it in a file when a realm is created. There's ways to make sure the file is secure (permissions, encrypted storage, etc.). It also means that an attacker would have to gain access to both the server and the db.

Would we store the password in memory, the unencrypted private key, or both? With a properties file you wouldn't need to store either in memory, although it would probably become very expensive to decrypt the key all the time.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 22 January, 2014 2:43:51 PM
> Subject: Re: [keycloak-dev] Password storage and KDFs
> 
> Using a property file sort of defeats the purpose of encrypting the
> keys.  The password must be stored in the human brain, IMO :)  I'd like
> to store keys as text in the db.  They are already stored in PEM format.
> 
> On 1/22/2014 9:39 AM, Bruno Oliveira wrote:
> > We did something on AeroGear with property file (not perfect), but I would
> > like to look at Keycloak before suggest anything. Maybe is possible
> > implement using the KeyStore from Java?
> >
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Jan 22 10:13:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 22 Jan 2014 10:13:52 -0500
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <1860698230.8955434.1390403143904.JavaMail.root@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52DFCDBE.3050705@redhat.com>
	<etPan.52dfcefa.66334873.205a@tesla> <52DFD4A0.7020302@redhat.com>
	<etPan.52dfd4d0.74b0dc51.205a@tesla> <52DFD627.8070005@redhat.com>
	<etPan.52dfd810.19495cff.205a@tesla> <52DFD927.9040908@redhat.com>
	<1860698230.8955434.1390403143904.JavaMail.root@redhat.com>
Message-ID: <52DFE030.9030100@redhat.com>



On 1/22/2014 10:05 AM, Stian Thorgersen wrote:
> I think having to enter a master password to start the server could make it quite difficult to manage, especially in clouds and provisioned environments. It should be available as an option though.
>

Good point.  This feature would be backburner then.

> Properties file could be the default. We could create a random password and store it in a file when a realm is created. There's ways to make sure the file is secure (permissions, encrypted storage, etc.). It also means that an attacker would have to gain access to both the server and the db.
>

Doesn't make much sense to me.  If there's ways to secure this property 
file, why wouldn't you do the same for the database?

> Would we store the password in memory, the unencrypted private key, or both? With a properties file you wouldn't need to store either in memory, although it would probably become very expensive to decrypt the key all the time.
>

private key has to be in memory unencrypted.  I'd like to load up and 
keep the whole database in memory.  Buts thats another discussion down 
the road.

> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 22 January, 2014 2:43:51 PM
>> Subject: Re: [keycloak-dev] Password storage and KDFs
>>
>> Using a property file sort of defeats the purpose of encrypting the
>> keys.  The password must be stored in the human brain, IMO :)  I'd like
>> to store keys as text in the db.  They are already stored in PEM format.
>>
>> On 1/22/2014 9:39 AM, Bruno Oliveira wrote:
>>> We did something on AeroGear with property file (not perfect), but I would
>>> like to look at Keycloak before suggest anything. Maybe is possible
>>> implement using the KeyStore from Java?
>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Wed Jan 22 10:24:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jan 2014 10:24:01 -0500 (EST)
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <52DFE030.9030100@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52DFD4A0.7020302@redhat.com>
	<etPan.52dfd4d0.74b0dc51.205a@tesla> <52DFD627.8070005@redhat.com>
	<etPan.52dfd810.19495cff.205a@tesla> <52DFD927.9040908@redhat.com>
	<1860698230.8955434.1390403143904.JavaMail.root@redhat.com>
	<52DFE030.9030100@redhat.com>
Message-ID: <865489895.8968612.1390404241216.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 22 January, 2014 3:13:52 PM
> Subject: Re: [keycloak-dev] Password storage and KDFs
> 
> 
> 
> On 1/22/2014 10:05 AM, Stian Thorgersen wrote:
> > I think having to enter a master password to start the server could make it
> > quite difficult to manage, especially in clouds and provisioned
> > environments. It should be available as an option though.
> >
> 
> Good point.  This feature would be backburner then.

IMO we should never store the key in plain-text in the db (or json exports of db). Then we can provide alternatives to how to input the master password, which would be trade-off between convenience and security, as well as environment specific.

> 
> > Properties file could be the default. We could create a random password and
> > store it in a file when a realm is created. There's ways to make sure the
> > file is secure (permissions, encrypted storage, etc.). It also means that
> > an attacker would have to gain access to both the server and the db.
> >
> 
> Doesn't make much sense to me.  If there's ways to secure this property
> file, why wouldn't you do the same for the database?

DB has sockets open and can be compromised through sql injections etc. 

You can still encrypt the drive the db is stored on, but that would only help to prevent someone that gains direct access to the machine. It would still be exploitable through sql injections etc.

Local file systems are generally more secure (this is probably a stianism ;)), can be encrypted, etc.

> 
> > Would we store the password in memory, the unencrypted private key, or
> > both? With a properties file you wouldn't need to store either in memory,
> > although it would probably become very expensive to decrypt the key all
> > the time.
> >
> 
> private key has to be in memory unencrypted.  I'd like to load up and
> keep the whole database in memory.  Buts thats another discussion down
> the road.
> 
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 22 January, 2014 2:43:51 PM
> >> Subject: Re: [keycloak-dev] Password storage and KDFs
> >>
> >> Using a property file sort of defeats the purpose of encrypting the
> >> keys.  The password must be stored in the human brain, IMO :)  I'd like
> >> to store keys as text in the db.  They are already stored in PEM format.
> >>
> >> On 1/22/2014 9:39 AM, Bruno Oliveira wrote:
> >>> We did something on AeroGear with property file (not perfect), but I
> >>> would
> >>> like to look at Keycloak before suggest anything. Maybe is possible
> >>> implement using the KeyStore from Java?
> >>>
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Jan 23 08:57:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jan 2014 08:57:40 -0500
Subject: [keycloak-dev] downloads@sf.net?
In-Reply-To: <CAAg5f2Rkh-Fxpm8f5Q_TqCTSUKDjMzX7qtZs3dW2Mh3Osb9Ftg@mail.gmail.com>
References: <52DF1878.2000601@redhat.com>	<CAM5SUC7aWxyY3+bRLGBQST3p-=6+G6Zgn1FYEfQGJbvSo_tdOg@mail.gmail.com>
	<CAAg5f2Rkh-Fxpm8f5Q_TqCTSUKDjMzX7qtZs3dW2Mh3Osb9Ftg@mail.gmail.com>
Message-ID: <52E11FD4.8030901@redhat.com>

Going to use sf.net.  Bintray seems to have a maximum of 500MB.  We will 
hit that after 3 releases.  I couldn't find anywhere to register for 
"premium" services.

On 1/22/2014 12:28 AM, Matthias Wessendorf wrote:
>
>
>
> On Wed, Jan 22, 2014 at 3:01 AM, Bruno Oliveira <bruno at abstractj.org
> <mailto:bruno at abstractj.org>> wrote:
>
>     Hi Bill, we've been using https://bintray.com on AeroGear, as far as
>     I can tell, no problems at all.
>
>
> +1 bintray works very well
>
>
>
>     On Tue, Jan 21, 2014 at 11:01 PM, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>         I like to avoid rht eng-ops as much as possible.  Anybody have any
>         reservations about hosting downloads at sf.net <http://sf.net>?
>         --
>         Bill Burke
>         JBoss, a division of Red Hat
>         http://bill.burkecentral.com
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>     --
>
>     --
>     "The measure of a man is what he does with power" - Plato
>     -
>     @abstractj
>     -
>     Volenti Nihil Difficile
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

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

From Anil.Saldhana at redhat.com  Thu Jan 23 10:14:34 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 23 Jan 2014 09:14:34 -0600
Subject: [keycloak-dev] downloads@sf.net?
In-Reply-To: <52E11FD4.8030901@redhat.com>
References: <52DF1878.2000601@redhat.com>	<CAM5SUC7aWxyY3+bRLGBQST3p-=6+G6Zgn1FYEfQGJbvSo_tdOg@mail.gmail.com>
	<CAAg5f2Rkh-Fxpm8f5Q_TqCTSUKDjMzX7qtZs3dW2Mh3Osb9Ftg@mail.gmail.com>
	<52E11FD4.8030901@redhat.com>
Message-ID: <52E131DA.3010103@redhat.com>

Bill,
   wonder if Google Drive with a public folder where the distribution 
zips are available, may also work?

Regards,
Anil

On 01/23/2014 07:57 AM, Bill Burke wrote:
> Going to use sf.net.  Bintray seems to have a maximum of 500MB.  We will
> hit that after 3 releases.  I couldn't find anywhere to register for
> "premium" services.
>
> On 1/22/2014 12:28 AM, Matthias Wessendorf wrote:
>>
>>
>> On Wed, Jan 22, 2014 at 3:01 AM, Bruno Oliveira <bruno at abstractj.org
>> <mailto:bruno at abstractj.org>> wrote:
>>
>>      Hi Bill, we've been using https://bintray.com on AeroGear, as far as
>>      I can tell, no problems at all.
>>
>>
>> +1 bintray works very well
>>
>>
>>
>>      On Tue, Jan 21, 2014 at 11:01 PM, Bill Burke <bburke at redhat.com
>>      <mailto:bburke at redhat.com>> wrote:
>>
>>          I like to avoid rht eng-ops as much as possible.  Anybody have any
>>          reservations about hosting downloads at sf.net <http://sf.net>?
>>          
>>
>>
>>      --
>>
>>      --
>>      "The measure of a man is what he does with power" - Plato
>>      -
>>      @abstractj
>>      -
>>      Volenti Nihil Difficile
>>


From bburke at redhat.com  Thu Jan 23 13:23:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jan 2014 13:23:25 -0500
Subject: [keycloak-dev] alpha 1 released
Message-ID: <52E15E1D.1080907@redhat.com>


Please view my blog for more details on features, videos, downloads, and 
documentation:

http://bill.burkecentral.com/2014/01/23/keycloak-sso-released-alpha-1/
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Jan 23 21:29:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jan 2014 21:29:26 -0500
Subject: [keycloak-dev] priorities and who is available?
Message-ID: <52E1D006.3040709@redhat.com>

I'd like to do another release in February.  Let's get an idea on 
available resources, what the priority are, and who can work on what. 
Let's see what work we can do in parallel.

Key functionality:

* Get Stan's Wildfly subsystem incorporated.
* Figure out appropriate addition to admin console for Stan's subsystem. 
  An SPI or something as well as UI.
* Composite Roles.
* Clean up Forgot Password and Reset password.  Should be possible for 
admin to send user an email with a URL that allows them to reset the 
password.  Right now requires entering in a password, telling user, and 
sending an email.
* Password Policies are broken.
* Revocation policies.
* Storage protection.  Smarter password hashes and protection of private 
keys and OTP keys.
* User session management.  Be able to show and list users logged into 
an app and be able to remotely logout one or all of them.
* More CORS options at the adapter level.
* Device mgmt and security.  Need input from Bruno.

Basically, we should have laser focus on critical features that must be 
implemented to have a functional Keycloak release, but also to support 
the needs of Red Hat projects specifically LiveOak, Wildfly, and 
Aerogear.  Having Keycloak drive security for those 3 projects will get 
us a lot more users than if we just went at it alone.

Personally, I'd like to get Stan's work incorporated as soon as possible 
and figure out a UI around it.  We should brainstorm together, but I 
think we may have to rethink some of our UI.

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

From mposolda at redhat.com  Fri Jan 24 04:49:11 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Jan 2014 10:49:11 +0100
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <etPan.52dfbfd2.6b8b4567.205a@tesla>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla>
Message-ID: <52E23717.9000003@redhat.com>

Hi Bruno,

that's great improvement. I just want to point the creation of 
SecureRandom during each password encoding/validation as it's platform 
dependent and quite expensive. We already have issues with this in 
GateIn. For example running this on my laptop:

     public static void main(String[] args) throws 
NoSuchAlgorithmException {
         SecureRandom.getInstance("SHA1PRNG").nextBytes(new byte[16]);
     }

is sometimes quick, but sometimes it took about 30 seconds to finish 
(depends on available random entropy from /dev/urandom on linux 
laptops). So IMO will be better to have it declared as static variable?

We already discussed and solved similar issue with picketlink team some 
time ago. In the end Picketlink is using SecureRandomProvider 
abstraction for retrieve SecureRandom instance. And default 
implementation of this interface is good compromise between security and 
performance.

Marek

On 22.1.2014 13:55, Bruno Oliveira wrote:
> Good morning guys, as a suggestion to improve the way how the passwords have been stored in nowadays I did some changes to support PBKDF2[1] (we have been doing the same thing on AeroGear for mobile devices), into this way is possible to prevent rainbow tables and brute force attacks like HashCat does for example.
>
> I'm completely fine on adding bcrypt as long as we include some KDF, I just didn't that because I would like to hear some feedback before move forward, not sure if makes sense but my suggestion is to remove SHA-* encoders because they can be easily broken and replace by the support for PBKDF2 and bcrypt only.
>
> What do you think? Let me know if I should move forward or that doesn't fit.
>
> [1] - https://github.com/keycloak/keycloak/pull/171
>
>


From stian at redhat.com  Fri Jan 24 05:03:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jan 2014 05:03:05 -0500 (EST)
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <52E1D006.3040709@redhat.com>
References: <52E1D006.3040709@redhat.com>
Message-ID: <396009267.11051911.1390557785497.JavaMail.root@redhat.com>

+1 To all of those, especially the WildFly sub-system

I've got some more stuff:

Features for LiveOak:

* Mongo store - this would be the default used in LiveOak
* Theme support for forms - I've got an idea how this will work and I'll send out an email about it next week

General features:

* Audit - at least audit basic events for now. Start with a basic audit spi, and a log based impl? Console, read, notifications, db, etc can come later.
* Security review - we should have a security review of code/features
* Code de-crapping - there's smelly code and duplicated code, time for some refactoring? Personally I'd like to see the code improved, but I don't want to spend weeks re-learning the code base either. A good approach would be to identify the biggest pain points, discuss a solution, refactor, then once refactored send out a summary email covering the changes
* Export/import - support dumping all data to a single json file. This will be useful for migrating db between versions, moving to a different store, backup, etc..
* Data migration plan - new releases will have new db schemas. A nice and simple approach to this is to use the export/import feature. We can have a pipeline that can converts a json export from version 1, to version 2, to version 3, etc..
* HMLT5/JS lib - we have a working JS lib in LiveOak for Keycloak, we should be able to pull this in with minimum effort
* Application/client types (service, public, mobile, ?) - there's a few things that are different depending on the client type. For example a public client (i.e. html5) are required to set a valid redirect_uri and doesn't require a password, while for a private client (i.e. rest service) redirect_uri is optional and password required
* Extend testsuite - add more tests to the testsuite, especially it would be great to see some tests for the admin console
* JPA db - test on production dbs (postgresql, mysql, do we even bother with oracle?)

Some comments in-line as well.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 January, 2014 2:29:26 AM
> Subject: [keycloak-dev] priorities and who is available?
> 
> I'd like to do another release in February.  Let's get an idea on
> available resources, what the priority are, and who can work on what.
> Let's see what work we can do in parallel.
> 
> Key functionality:
> 
> * Get Stan's Wildfly subsystem incorporated.
> * Figure out appropriate addition to admin console for Stan's subsystem.
>   An SPI or something as well as UI.
> * Composite Roles.
> * Clean up Forgot Password and Reset password.  Should be possible for
> admin to send user an email with a URL that allows them to reset the
> password.  Right now requires entering in a password, telling user, and
> sending an email.

I assume you're only talking about when an admin resets the password on-behalf of the user?

It should be simple enough to add a button to let an admin send a password reset link to a user as we already have that functionality for the user themselves. It's that what you want? We still need the option of being able to set a temp password in case the user doesn't have a email registered (or emails can't be used for whatever reason).

> * Password Policies are broken.

I'll get the ball started on the next release and fix that once I've finished writing this mail ;)

> * Revocation policies.
> * Storage protection.  Smarter password hashes and protection of private
> keys and OTP keys.
> * User session management.  Be able to show and list users logged into
> an app and be able to remotely logout one or all of them.
> * More CORS options at the adapter level.
> * Device mgmt and security.  Need input from Bruno.
> 
> Basically, we should have laser focus on critical features that must be
> implemented to have a functional Keycloak release, but also to support
> the needs of Red Hat projects specifically LiveOak, Wildfly, and
> Aerogear.  Having Keycloak drive security for those 3 projects will get
> us a lot more users than if we just went at it alone.
> 
> Personally, I'd like to get Stan's work incorporated as soon as possible
> and figure out a UI around it.  We should brainstorm together, but I
> think we may have to rethink some of our UI.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bruno at abstractj.org  Fri Jan 24 06:55:17 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jan 2014 09:55:17 -0200
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <52E23717.9000003@redhat.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52E23717.9000003@redhat.com>
Message-ID: <CAM5SUC40Q4AgXSxqyFke=QfJAcgyz3WRNUKEVx_2Tgcbj2-Mzg@mail.gmail.com>

Let me check if I'm misreading you, are you considering to make the salt
static? If the answer is yes, the salt would be predictable, no? Not sure
if I'm following you on this.


On Fri, Jan 24, 2014 at 7:49 AM, Marek Posolda <mposolda at redhat.com> wrote:

> Hi Bruno,
>
> that's great improvement. I just want to point the creation of
> SecureRandom during each password encoding/validation as it's platform
> dependent and quite expensive. We already have issues with this in GateIn.
> For example running this on my laptop:
>
>     public static void main(String[] args) throws NoSuchAlgorithmException
> {
>         SecureRandom.getInstance("SHA1PRNG").nextBytes(new byte[16]);
>     }
>
> is sometimes quick, but sometimes it took about 30 seconds to finish
> (depends on available random entropy from /dev/urandom on linux laptops).
> So IMO will be better to have it declared as static variable?
>
> We already discussed and solved similar issue with picketlink team some
> time ago. In the end Picketlink is using SecureRandomProvider abstraction
> for retrieve SecureRandom instance. And default implementation of this
> interface is good compromise between security and performance.
>
> Marek
>
>
> On 22.1.2014 13:55, Bruno Oliveira wrote:
>
>> Good morning guys, as a suggestion to improve the way how the passwords
>> have been stored in nowadays I did some changes to support PBKDF2[1] (we
>> have been doing the same thing on AeroGear for mobile devices), into this
>> way is possible to prevent rainbow tables and brute force attacks like
>> HashCat does for example.
>>
>> I'm completely fine on adding bcrypt as long as we include some KDF, I
>> just didn't that because I would like to hear some feedback before move
>> forward, not sure if makes sense but my suggestion is to remove SHA-*
>> encoders because they can be easily broken and replace by the support for
>> PBKDF2 and bcrypt only.
>>
>> What do you think? Let me know if I should move forward or that doesn't
>> fit.
>>
>> [1] - https://github.com/keycloak/keycloak/pull/171
>>
>>
>>
>


-- 

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140124/5f2195ba/attachment.html 

From bruno at abstractj.org  Fri Jan 24 07:38:21 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jan 2014 10:38:21 -0200
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <52E1D006.3040709@redhat.com>
References: <52E1D006.3040709@redhat.com>
Message-ID: <etPan.52e25ebe.238e1f29.205a@tesla>

Good morning, if nobody is planning to work on it, I can work on storage protection and help to define the device mgmt stuff, just let me know about which date or period (mid Feb, end Feb...) do you want to release it.

-- 
abstractj

On January 24, 2014 at 12:29:27 AM, Bill Burke (bburke at redhat.com) wrote:
> > * Storage protection. Smarter password hashes and protection 
> of private
> keys and OTP keys.
> * User session management. Be able to show and list users logged 
> into
> an app and be able to remotely logout one or all of them.
> * More CORS options at the adapter level.
> * Device mgmt and security. Need input from Bruno.


From bruno at abstractj.org  Fri Jan 24 07:50:35 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jan 2014 10:50:35 -0200
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <396009267.11051911.1390557785497.JavaMail.root@redhat.com>
References: <52E1D006.3040709@redhat.com>
	<396009267.11051911.1390557785497.JavaMail.root@redhat.com>
Message-ID: <etPan.52e2619b.46e87ccd.205a@tesla>

Good morning Stian, on AeroGear we had a discussion about how to properly reset passwords and we have too much to improve, but here comes my 2 cents.

--  
abstractj

On January 24, 2014 at 8:03:08 AM, Stian Thorgersen (stian at redhat.com) wrote:
> > Some comments in-line as well.
>  
> ----- Original Message -----
>  
> I assume you're only talking about when an admin resets the password  
> on-behalf of the user?
>  
> It should be simple enough to add a button to let an admin send a  
> password reset link to a user as we already have that functionality  
> for the user themselves. It's that what you want? We still need  
> the option of being able to set a temp password in case the user  
> doesn't have a email registered (or emails can't be used for whatever  
> reason).

What concerns me about this approach is the fact that once the admin account is compromised, is possible to reset everyone?s account even if you don?t have access do the database. If users doesn?t have e-mail registered, maybe we could evaluate another confirmation method? Maybe TOTP?


From stian at redhat.com  Fri Jan 24 08:38:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jan 2014 08:38:11 -0500 (EST)
Subject: [keycloak-dev] Password resetting
In-Reply-To: <1764477184.11205297.1390569846552.JavaMail.root@redhat.com>
Message-ID: <1075661049.11210086.1390570691586.JavaMail.root@redhat.com>

To prevent hijacking the thread for planning what goes into the next release, I'll start this new thread on this subject.

For clarification, at the moment what we have with password reset is :

Users:
* If realm allows it and user has registered email address they can click on the recover password option. They then insert their username and an email with a link is sent to them. This link will expire within a configurable time (default is 10 min I think). The link will open a form enabling the user to insert a new password.

Admins:
* Admins can set a new temporary password on a user account. This will add a flag that the user is required to reset the password on next login. Currently the admin could remove this required action though, as admins can add/remove required actions to an account

Improvements to this flow would be good. It's not elegant that admin has to manually create tmp password, and somehow communicate this to the user. Also, as Bruno pointed out this would mean an admin could gain access to a users account. Any other concerns?

With regards to admins being able to send recover email, I'm not sure I see the point. Users can do this themselves if they want to. Also, the link in the email expires within a relatively short timeout, so it would quite likely be expired by the time a user reads it

Stopping a compromised admin being able to access the account, I'm not sure that would be feasible. Even if an admin can't set a tmp password, they could for example change the email and get a recovery password email sent to themselves. I also think a compromised admin account would mean we're pretty screwed in any case, so is this really important? 

I don't understand how TOTP would work, can you explain.

From gcardoso at redhat.com  Fri Jan 24 08:41:34 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Fri, 24 Jan 2014 11:41:34 -0200
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <etPan.52e2619b.46e87ccd.205a@tesla>
References: <52E1D006.3040709@redhat.com>
	<396009267.11051911.1390557785497.JavaMail.root@redhat.com>
	<etPan.52e2619b.46e87ccd.205a@tesla>
Message-ID: <2194BEB5-867F-4FF2-8A8A-2527B201BCEA@redhat.com>

It would be interesting to customise the UI with new colours / logo since the current style is supposed to be used for products.

Also, please let me know if we need to improve / create new stuff for the UI.

Gabriel 

On Jan 24, 2014, at 10:50 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning Stian, on AeroGear we had a discussion about how to properly reset passwords and we have too much to improve, but here comes my 2 cents.
> 
> --  
> abstractj
> 
> On January 24, 2014 at 8:03:08 AM, Stian Thorgersen (stian at redhat.com) wrote:
>>> Some comments in-line as well.
>> 
>> ----- Original Message -----
>> 
>> I assume you're only talking about when an admin resets the password  
>> on-behalf of the user?
>> 
>> It should be simple enough to add a button to let an admin send a  
>> password reset link to a user as we already have that functionality  
>> for the user themselves. It's that what you want? We still need  
>> the option of being able to set a temp password in case the user  
>> doesn't have a email registered (or emails can't be used for whatever  
>> reason).
> 
> What concerns me about this approach is the fact that once the admin account is compromised, is possible to reset everyone?s account even if you don?t have access do the database. If users doesn?t have e-mail registered, maybe we could evaluate another confirmation method? Maybe TOTP?
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140124/87ea4336/attachment.html 

From ssilvert at redhat.com  Fri Jan 24 09:12:43 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Fri, 24 Jan 2014 09:12:43 -0500
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <52E1D006.3040709@redhat.com>
References: <52E1D006.3040709@redhat.com>
Message-ID: <52E274DB.7000305@redhat.com>

Give me until the end of next week to get the subsystem cleaned up and
ready to merge.  I want to get it fully working end to end before I turn
it over.  After that, I'll see how much time I can allocate to help.

Stan

On 1/23/2014 9:29 PM, Bill Burke wrote:
> I'd like to do another release in February.  Let's get an idea on 
> available resources, what the priority are, and who can work on what. 
> Let's see what work we can do in parallel.
>
> Key functionality:
>
> * Get Stan's Wildfly subsystem incorporated.
> * Figure out appropriate addition to admin console for Stan's subsystem. 
>   An SPI or something as well as UI.
> * Composite Roles.
> * Clean up Forgot Password and Reset password.  Should be possible for 
> admin to send user an email with a URL that allows them to reset the 
> password.  Right now requires entering in a password, telling user, and 
> sending an email.
> * Password Policies are broken.
> * Revocation policies.
> * Storage protection.  Smarter password hashes and protection of private 
> keys and OTP keys.
> * User session management.  Be able to show and list users logged into 
> an app and be able to remotely logout one or all of them.
> * More CORS options at the adapter level.
> * Device mgmt and security.  Need input from Bruno.
>
> Basically, we should have laser focus on critical features that must be 
> implemented to have a functional Keycloak release, but also to support 
> the needs of Red Hat projects specifically LiveOak, Wildfly, and 
> Aerogear.  Having Keycloak drive security for those 3 projects will get 
> us a lot more users than if we just went at it alone.
>
> Personally, I'd like to get Stan's work incorporated as soon as possible 
> and figure out a UI around it.  We should brainstorm together, but I 
> think we may have to rethink some of our UI.
>


From bburke at redhat.com  Fri Jan 24 09:16:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jan 2014 09:16:21 -0500
Subject: [keycloak-dev] Password resetting
In-Reply-To: <1075661049.11210086.1390570691586.JavaMail.root@redhat.com>
References: <1075661049.11210086.1390570691586.JavaMail.root@redhat.com>
Message-ID: <52E275B5.4000205@redhat.com>



On 1/24/2014 8:38 AM, Stian Thorgersen wrote:
> To prevent hijacking the thread for planning what goes into the next release, I'll start this new thread on this subject.
>
> For clarification, at the moment what we have with password reset is :
>
> Users:
> * If realm allows it and user has registered email address they can click on the recover password option. They then insert their username and an email with a link is sent to them. This link will expire within a configurable time (default is 10 min I think). The link will open a form enabling the user to insert a new password.
>
> Admins:
> * Admins can set a new temporary password on a user account. This will add a flag that the user is required to reset the password on next login. Currently the admin could remove this required action though, as admins can add/remove required actions to an account
>
> Improvements to this flow would be good. It's not elegant that admin has to manually create tmp password, and somehow communicate this to the user. Also, as Bruno pointed out this would mean an admin could gain access to a users account. Any other concerns?
>

The improvement I want is an email with a URL that contains a temporary 
token.  User's acct status would be set to "update password", but they 
would not have to enter in their password, just a new one.

I think you're right in that we still need the option for the admin to 
set up a temporary password.

> With regards to admins being able to send recover email, I'm not sure I see the point. Users can do this themselves if they want to. Also, the link in the email expires within a relatively short timeout, so it would quite likely be expired by the time a user reads it
>
> Stopping a compromised admin being able to access the account, I'm not sure that would be feasible. Even if an admin can't set a tmp password, they could for example change the email and get a recovery password email sent to themselves. I also think a compromised admin account would mean we're pretty screwed in any case, so is this really important?
>
> I don't understand how TOTP would work, can you explain.

TOTP could work same way as above.  Send an email, user is temporarily 
authenticated, but must reset totp key.

In the future, I'd like to have a "World of Warcraft" option.  I really 
like the way they do it as hacked user accounts were really common prior 
to 2-factor auth.  To reset a password, you get an email.  To reset TOTP 
you get a text to your phone.  So, if your email account gets hacked 
(like mine was prior to enabling 2-factor auth), you're still safe.

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

From bburke at redhat.com  Fri Jan 24 09:32:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jan 2014 09:32:41 -0500
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <396009267.11051911.1390557785497.JavaMail.root@redhat.com>
References: <52E1D006.3040709@redhat.com>
	<396009267.11051911.1390557785497.JavaMail.root@redhat.com>
Message-ID: <52E27989.70007@redhat.com>

All good stuff.  I'm thinking maybe we all pick one major feature we all 
can work on. Pick a date.  Whatever is done by that date is what gets in 
that release.

On 1/24/2014 5:03 AM, Stian Thorgersen wrote:
> +1 To all of those, especially the WildFly sub-system
>
> I've got some more stuff:
>
> Features for LiveOak:
>
> * Mongo store - this would be the default used in LiveOak

I don't understand your fascination with kiddie DBs. ;)

>
> * HMLT5/JS lib - we have a working JS lib in LiveOak for Keycloak, we should be able to pull this in with minimum effort

We can build on this for a Node.js adapter too.

> * Application/client types (service, public, mobile, ?) - there's a few things that are different depending on the client type. For example a public client (i.e. html5) are required to set a valid redirect_uri and doesn't require a password, while for a private client (i.e. rest service) redirect_uri is optional and password required

For mobile clients, I'm also thinking all they need is a refresh token.



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

From stian at redhat.com  Fri Jan 24 09:33:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jan 2014 09:33:04 -0500 (EST)
Subject: [keycloak-dev] Password resetting
In-Reply-To: <52E275B5.4000205@redhat.com>
References: <1075661049.11210086.1390570691586.JavaMail.root@redhat.com>
	<52E275B5.4000205@redhat.com>
Message-ID: <1662781828.11312061.1390573984818.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 January, 2014 2:16:21 PM
> Subject: Re: [keycloak-dev] Password resetting
> 
> 
> 
> On 1/24/2014 8:38 AM, Stian Thorgersen wrote:
> > To prevent hijacking the thread for planning what goes into the next
> > release, I'll start this new thread on this subject.
> >
> > For clarification, at the moment what we have with password reset is :
> >
> > Users:
> > * If realm allows it and user has registered email address they can click
> > on the recover password option. They then insert their username and an
> > email with a link is sent to them. This link will expire within a
> > configurable time (default is 10 min I think). The link will open a form
> > enabling the user to insert a new password.
> >
> > Admins:
> > * Admins can set a new temporary password on a user account. This will add
> > a flag that the user is required to reset the password on next login.
> > Currently the admin could remove this required action though, as admins
> > can add/remove required actions to an account
> >
> > Improvements to this flow would be good. It's not elegant that admin has to
> > manually create tmp password, and somehow communicate this to the user.
> > Also, as Bruno pointed out this would mean an admin could gain access to a
> > users account. Any other concerns?
> >
> 
> The improvement I want is an email with a URL that contains a temporary
> token.  User's acct status would be set to "update password", but they
> would not have to enter in their password, just a new one.

We have this already don't we? In the realm settings enable "Rest password", then open the login page, now there's link for "Forgot Username" and "Forgot Password".

> 
> I think you're right in that we still need the option for the admin to
> set up a temporary password.
> 
> > With regards to admins being able to send recover email, I'm not sure I see
> > the point. Users can do this themselves if they want to. Also, the link in
> > the email expires within a relatively short timeout, so it would quite
> > likely be expired by the time a user reads it
> >
> > Stopping a compromised admin being able to access the account, I'm not sure
> > that would be feasible. Even if an admin can't set a tmp password, they
> > could for example change the email and get a recovery password email sent
> > to themselves. I also think a compromised admin account would mean we're
> > pretty screwed in any case, so is this really important?
> >
> > I don't understand how TOTP would work, can you explain.
> 
> TOTP could work same way as above.  Send an email, user is temporarily
> authenticated, but must reset totp key.

We have similar feature here. If TOTP is lost the admin would disable TOTP, then add a required action to re-configure TOTP on next login.

> 
> In the future, I'd like to have a "World of Warcraft" option.  I really
> like the way they do it as hacked user accounts were really common prior
> to 2-factor auth.  To reset a password, you get an email.  To reset TOTP
> you get a text to your phone.  So, if your email account gets hacked
> (like mine was prior to enabling 2-factor auth), you're still safe.

Yes, we definitively needs more layers of defence. Would be great to have SMS/phone options. We should also have options to enable password recovery questions (What's your first car thing).

We can also enable support for OTP through email and sms

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

From ssilvert at redhat.com  Fri Jan 24 09:36:50 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Fri, 24 Jan 2014 09:36:50 -0500
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <52E274DB.7000305@redhat.com>
References: <52E1D006.3040709@redhat.com> <52E274DB.7000305@redhat.com>
Message-ID: <52E27A82.7070805@redhat.com>

There is one potential roadblock to adding UI for the KeyCloak subsystem
right now.   When you put the UI into the KeyCloak console you won't be
able to directly access the http management endpoint.  This is a
limitation that is being addressed by Darran's work on CORS support.

Darran, would it be possible to get a fork of the latest WildFly that
just allows all CORS requests.  Is that something you could do without
much effort so we would have a build that we could use for development?

Herald Pehl created a fork like that, but it is based on WildFly 8 Alpha
1, which doesn't work with KeyCloak.
http://hpehl.info/independent-jboss-admin-console.html

 On 1/24/2014 9:12 AM, ssilvert at redhat.com wrote:
> Give me until the end of next week to get the subsystem cleaned up and
> ready to merge.  I want to get it fully working end to end before I turn
> it over.  After that, I'll see how much time I can allocate to help.
>
> Stan
>
> On 1/23/2014 9:29 PM, Bill Burke wrote:
>> I'd like to do another release in February.  Let's get an idea on 
>> available resources, what the priority are, and who can work on what. 
>> Let's see what work we can do in parallel.
>>
>> Key functionality:
>>
>> * Get Stan's Wildfly subsystem incorporated.
>> * Figure out appropriate addition to admin console for Stan's subsystem. 
>>   An SPI or something as well as UI.
>> * Composite Roles.
>> * Clean up Forgot Password and Reset password.  Should be possible for 
>> admin to send user an email with a URL that allows them to reset the 
>> password.  Right now requires entering in a password, telling user, and 
>> sending an email.
>> * Password Policies are broken.
>> * Revocation policies.
>> * Storage protection.  Smarter password hashes and protection of private 
>> keys and OTP keys.
>> * User session management.  Be able to show and list users logged into 
>> an app and be able to remotely logout one or all of them.
>> * More CORS options at the adapter level.
>> * Device mgmt and security.  Need input from Bruno.
>>
>> Basically, we should have laser focus on critical features that must be 
>> implemented to have a functional Keycloak release, but also to support 
>> the needs of Red Hat projects specifically LiveOak, Wildfly, and 
>> Aerogear.  Having Keycloak drive security for those 3 projects will get 
>> us a lot more users than if we just went at it alone.
>>
>> Personally, I'd like to get Stan's work incorporated as soon as possible 
>> and figure out a UI around it.  We should brainstorm together, but I 
>> think we may have to rethink some of our UI.
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jan 24 09:38:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jan 2014 09:38:50 -0500 (EST)
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <52E27989.70007@redhat.com>
References: <52E1D006.3040709@redhat.com>
	<396009267.11051911.1390557785497.JavaMail.root@redhat.com>
	<52E27989.70007@redhat.com>
Message-ID: <1877263416.11316885.1390574330462.JavaMail.root@redhat.com>

Alpha2 released by end of Feb?

I'll do form themes. Marek can work on Mongo store.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 January, 2014 2:32:41 PM
> Subject: Re: [keycloak-dev] priorities and who is available?
> 
> All good stuff.  I'm thinking maybe we all pick one major feature we all
> can work on. Pick a date.  Whatever is done by that date is what gets in
> that release.
> 
> On 1/24/2014 5:03 AM, Stian Thorgersen wrote:
> > +1 To all of those, especially the WildFly sub-system
> >
> > I've got some more stuff:
> >
> > Features for LiveOak:
> >
> > * Mongo store - this would be the default used in LiveOak
> 
> I don't understand your fascination with kiddie DBs. ;)
> 
> >
> > * HMLT5/JS lib - we have a working JS lib in LiveOak for Keycloak, we
> > should be able to pull this in with minimum effort
> 
> We can build on this for a Node.js adapter too.
> 
> > * Application/client types (service, public, mobile, ?) - there's a few
> > things that are different depending on the client type. For example a
> > public client (i.e. html5) are required to set a valid redirect_uri and
> > doesn't require a password, while for a private client (i.e. rest service)
> > redirect_uri is optional and password required
> 
> For mobile clients, I'm also thinking all they need is a refresh token.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Fri Jan 24 09:46:19 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Jan 2014 15:46:19 +0100
Subject: [keycloak-dev] Password storage and KDFs
In-Reply-To: <CAM5SUC40Q4AgXSxqyFke=QfJAcgyz3WRNUKEVx_2Tgcbj2-Mzg@mail.gmail.com>
References: <etPan.52dfbfd2.6b8b4567.205a@tesla> <52E23717.9000003@redhat.com>
	<CAM5SUC40Q4AgXSxqyFke=QfJAcgyz3WRNUKEVx_2Tgcbj2-Mzg@mail.gmail.com>
Message-ID: <52E27CBB.2070807@redhat.com>

On 24.1.2014 12:55, Bruno Oliveira wrote:
> Let me check if I'm misreading you, are you considering to make the 
> salt static? If the answer is yes, the salt would be predictable, no? 
> Not sure if I'm following you on this.
No, not salt of course. I meant to have just SecureRandom instance 
declared to be static (or maybe not necessarilly static but shared 
somehow via something like Picketlink is doing with SecureRandomProvider 
or we are doing in GateIn). The expensive part is initial generation of 
seed for SecureRandom and if this would need to be done during each 
encoding/validation, you will likely see performance issues. Especially 
in production environments with many logins/password validations.

You can easily try to run the code snippet below couple of times on your 
machine and maybe you will see what I meant.

Marek
>
>
> On Fri, Jan 24, 2014 at 7:49 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Hi Bruno,
>
>     that's great improvement. I just want to point the creation of
>     SecureRandom during each password encoding/validation as it's
>     platform dependent and quite expensive. We already have issues
>     with this in GateIn. For example running this on my laptop:
>
>         public static void main(String[] args) throws
>     NoSuchAlgorithmException {
>             SecureRandom.getInstance("SHA1PRNG").nextBytes(new byte[16]);
>         }
>
>     is sometimes quick, but sometimes it took about 30 seconds to
>     finish (depends on available random entropy from /dev/urandom on
>     linux laptops). So IMO will be better to have it declared as
>     static variable?
>
>     We already discussed and solved similar issue with picketlink team
>     some time ago. In the end Picketlink is using SecureRandomProvider
>     abstraction for retrieve SecureRandom instance. And default
>     implementation of this interface is good compromise between
>     security and performance.
>
>     Marek
>
>
>     On 22.1.2014 13:55, Bruno Oliveira wrote:
>
>         Good morning guys, as a suggestion to improve the way how the
>         passwords have been stored in nowadays I did some changes to
>         support PBKDF2[1] (we have been doing the same thing on
>         AeroGear for mobile devices), into this way is possible to
>         prevent rainbow tables and brute force attacks like HashCat
>         does for example.
>
>         I'm completely fine on adding bcrypt as long as we include
>         some KDF, I just didn't that because I would like to hear some
>         feedback before move forward, not sure if makes sense but my
>         suggestion is to remove SHA-* encoders because they can be
>         easily broken and replace by the support for PBKDF2 and bcrypt
>         only.
>
>         What do you think? Let me know if I should move forward or
>         that doesn't fit.
>
>         [1] - https://github.com/keycloak/keycloak/pull/171
>
>
>
>
>
>
> -- 
>
> -- 
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140124/e452e0d7/attachment.html 

From darran.lofthouse at jboss.com  Fri Jan 24 09:59:05 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 24 Jan 2014 14:59:05 +0000
Subject: [keycloak-dev] priorities and who is available?
In-Reply-To: <52E27A82.7070805@redhat.com>
References: <52E1D006.3040709@redhat.com> <52E274DB.7000305@redhat.com>
	<52E27A82.7070805@redhat.com>
Message-ID: <52E27FB9.2060504@jboss.com>

I will have to see if I can get a chance next week, since we moved to 
Undertow our CORS handling is also in the wrong location!

Regards,
Darran Lofthouse.


On 24/01/14 14:36, ssilvert at redhat.com wrote:
> There is one potential roadblock to adding UI for the KeyCloak subsystem
> right now.   When you put the UI into the KeyCloak console you won't be
> able to directly access the http management endpoint.  This is a
> limitation that is being addressed by Darran's work on CORS support.
>
> Darran, would it be possible to get a fork of the latest WildFly that
> just allows all CORS requests.  Is that something you could do without
> much effort so we would have a build that we could use for development?
>
> Herald Pehl created a fork like that, but it is based on WildFly 8 Alpha
> 1, which doesn't work with KeyCloak.
> http://hpehl.info/independent-jboss-admin-console.html
>
>   On 1/24/2014 9:12 AM, ssilvert at redhat.com wrote:
>> Give me until the end of next week to get the subsystem cleaned up and
>> ready to merge.  I want to get it fully working end to end before I turn
>> it over.  After that, I'll see how much time I can allocate to help.
>>
>> Stan
>>
>> On 1/23/2014 9:29 PM, Bill Burke wrote:
>>> I'd like to do another release in February.  Let's get an idea on
>>> available resources, what the priority are, and who can work on what.
>>> Let's see what work we can do in parallel.
>>>
>>> Key functionality:
>>>
>>> * Get Stan's Wildfly subsystem incorporated.
>>> * Figure out appropriate addition to admin console for Stan's subsystem.
>>>    An SPI or something as well as UI.
>>> * Composite Roles.
>>> * Clean up Forgot Password and Reset password.  Should be possible for
>>> admin to send user an email with a URL that allows them to reset the
>>> password.  Right now requires entering in a password, telling user, and
>>> sending an email.
>>> * Password Policies are broken.
>>> * Revocation policies.
>>> * Storage protection.  Smarter password hashes and protection of private
>>> keys and OTP keys.
>>> * User session management.  Be able to show and list users logged into
>>> an app and be able to remotely logout one or all of them.
>>> * More CORS options at the adapter level.
>>> * Device mgmt and security.  Need input from Bruno.
>>>
>>> Basically, we should have laser focus on critical features that must be
>>> implemented to have a functional Keycloak release, but also to support
>>> the needs of Red Hat projects specifically LiveOak, Wildfly, and
>>> Aerogear.  Having Keycloak drive security for those 3 projects will get
>>> us a lot more users than if we just went at it alone.
>>>
>>> Personally, I'd like to get Stan's work incorporated as soon as possible
>>> and figure out a UI around it.  We should brainstorm together, but I
>>> think we may have to rethink some of our UI.
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Fri Jan 24 10:29:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jan 2014 10:29:19 -0500
Subject: [keycloak-dev] Password resetting
In-Reply-To: <1662781828.11312061.1390573984818.JavaMail.root@redhat.com>
References: <1075661049.11210086.1390570691586.JavaMail.root@redhat.com>
	<52E275B5.4000205@redhat.com>
	<1662781828.11312061.1390573984818.JavaMail.root@redhat.com>
Message-ID: <52E286CF.4060204@redhat.com>



On 1/24/2014 9:33 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 24 January, 2014 2:16:21 PM
>> Subject: Re: [keycloak-dev] Password resetting
>>
>>
>>
>> On 1/24/2014 8:38 AM, Stian Thorgersen wrote:
>>> To prevent hijacking the thread for planning what goes into the next
>>> release, I'll start this new thread on this subject.
>>>
>>> For clarification, at the moment what we have with password reset is :
>>>
>>> Users:
>>> * If realm allows it and user has registered email address they can click
>>> on the recover password option. They then insert their username and an
>>> email with a link is sent to them. This link will expire within a
>>> configurable time (default is 10 min I think). The link will open a form
>>> enabling the user to insert a new password.
>>>
>>> Admins:
>>> * Admins can set a new temporary password on a user account. This will add
>>> a flag that the user is required to reset the password on next login.
>>> Currently the admin could remove this required action though, as admins
>>> can add/remove required actions to an account
>>>
>>> Improvements to this flow would be good. It's not elegant that admin has to
>>> manually create tmp password, and somehow communicate this to the user.
>>> Also, as Bruno pointed out this would mean an admin could gain access to a
>>> users account. Any other concerns?
>>>
>>
>> The improvement I want is an email with a URL that contains a temporary
>> token.  User's acct status would be set to "update password", but they
>> would not have to enter in their password, just a new one.
>
> We have this already don't we? In the realm settings enable "Rest password", then open the login page, now there's link for "Forgot Username" and "Forgot Password".
>

I mean a button in the admin console which will change the status of the 
user acct and also send an email to the user.


>>
>> I think you're right in that we still need the option for the admin to
>> set up a temporary password.
>>
>>> With regards to admins being able to send recover email, I'm not sure I see
>>> the point. Users can do this themselves if they want to. Also, the link in
>>> the email expires within a relatively short timeout, so it would quite
>>> likely be expired by the time a user reads it
>>>
>>> Stopping a compromised admin being able to access the account, I'm not sure
>>> that would be feasible. Even if an admin can't set a tmp password, they
>>> could for example change the email and get a recovery password email sent
>>> to themselves. I also think a compromised admin account would mean we're
>>> pretty screwed in any case, so is this really important?
>>>
>>> I don't understand how TOTP would work, can you explain.
>>
>> TOTP could work same way as above.  Send an email, user is temporarily
>> authenticated, but must reset totp key.
>
> We have similar feature here. If TOTP is lost the admin would disable TOTP, then add a required action to re-configure TOTP on next login.
>
>>
>> In the future, I'd like to have a "World of Warcraft" option.  I really
>> like the way they do it as hacked user accounts were really common prior
>> to 2-factor auth.  To reset a password, you get an email.  To reset TOTP
>> you get a text to your phone.  So, if your email account gets hacked
>> (like mine was prior to enabling 2-factor auth), you're still safe.
>
> Yes, we definitively needs more layers of defence. Would be great to have SMS/phone options. We should also have options to enable password recovery questions (What's your first car thing).
>
> We can also enable support for OTP through email and sms
>

Yes.  I forgot about user questions ("What's your first car?")...that's 
something I've wanted to add too.

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

From stian at redhat.com  Fri Jan 24 11:02:09 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jan 2014 11:02:09 -0500 (EST)
Subject: [keycloak-dev] Password resetting
In-Reply-To: <52E286CF.4060204@redhat.com>
References: <1075661049.11210086.1390570691586.JavaMail.root@redhat.com>
	<52E275B5.4000205@redhat.com>
	<1662781828.11312061.1390573984818.JavaMail.root@redhat.com>
	<52E286CF.4060204@redhat.com>
Message-ID: <339382210.11385404.1390579329270.JavaMail.root@redhat.com>

How about for user / credential page we display the following buttons:

* Send password reset - visible if user has email registered, should this be only for verified email?)
* Set temporary password - opens a modal panel where admin can insert a password or have one generated
* Remove totp - if realm requires totp user will be asked to re-config on next login, otherwise user would have to go to acct mngmt to enable

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 January, 2014 3:29:19 PM
> Subject: Re: [keycloak-dev] Password resetting
> 
> 
> 
> On 1/24/2014 9:33 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 24 January, 2014 2:16:21 PM
> >> Subject: Re: [keycloak-dev] Password resetting
> >>
> >>
> >>
> >> On 1/24/2014 8:38 AM, Stian Thorgersen wrote:
> >>> To prevent hijacking the thread for planning what goes into the next
> >>> release, I'll start this new thread on this subject.
> >>>
> >>> For clarification, at the moment what we have with password reset is :
> >>>
> >>> Users:
> >>> * If realm allows it and user has registered email address they can click
> >>> on the recover password option. They then insert their username and an
> >>> email with a link is sent to them. This link will expire within a
> >>> configurable time (default is 10 min I think). The link will open a form
> >>> enabling the user to insert a new password.
> >>>
> >>> Admins:
> >>> * Admins can set a new temporary password on a user account. This will
> >>> add
> >>> a flag that the user is required to reset the password on next login.
> >>> Currently the admin could remove this required action though, as admins
> >>> can add/remove required actions to an account
> >>>
> >>> Improvements to this flow would be good. It's not elegant that admin has
> >>> to
> >>> manually create tmp password, and somehow communicate this to the user.
> >>> Also, as Bruno pointed out this would mean an admin could gain access to
> >>> a
> >>> users account. Any other concerns?
> >>>
> >>
> >> The improvement I want is an email with a URL that contains a temporary
> >> token.  User's acct status would be set to "update password", but they
> >> would not have to enter in their password, just a new one.
> >
> > We have this already don't we? In the realm settings enable "Rest
> > password", then open the login page, now there's link for "Forgot
> > Username" and "Forgot Password".
> >
> 
> I mean a button in the admin console which will change the status of the
> user acct and also send an email to the user.
> 
> 
> >>
> >> I think you're right in that we still need the option for the admin to
> >> set up a temporary password.
> >>
> >>> With regards to admins being able to send recover email, I'm not sure I
> >>> see
> >>> the point. Users can do this themselves if they want to. Also, the link
> >>> in
> >>> the email expires within a relatively short timeout, so it would quite
> >>> likely be expired by the time a user reads it
> >>>
> >>> Stopping a compromised admin being able to access the account, I'm not
> >>> sure
> >>> that would be feasible. Even if an admin can't set a tmp password, they
> >>> could for example change the email and get a recovery password email sent
> >>> to themselves. I also think a compromised admin account would mean we're
> >>> pretty screwed in any case, so is this really important?
> >>>
> >>> I don't understand how TOTP would work, can you explain.
> >>
> >> TOTP could work same way as above.  Send an email, user is temporarily
> >> authenticated, but must reset totp key.
> >
> > We have similar feature here. If TOTP is lost the admin would disable TOTP,
> > then add a required action to re-configure TOTP on next login.
> >
> >>
> >> In the future, I'd like to have a "World of Warcraft" option.  I really
> >> like the way they do it as hacked user accounts were really common prior
> >> to 2-factor auth.  To reset a password, you get an email.  To reset TOTP
> >> you get a text to your phone.  So, if your email account gets hacked
> >> (like mine was prior to enabling 2-factor auth), you're still safe.
> >
> > Yes, we definitively needs more layers of defence. Would be great to have
> > SMS/phone options. We should also have options to enable password recovery
> > questions (What's your first car thing).
> >
> > We can also enable support for OTP through email and sms
> >
> 
> Yes.  I forgot about user questions ("What's your first car?")...that's
> something I've wanted to add too.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri Jan 24 11:13:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jan 2014 11:13:02 -0500
Subject: [keycloak-dev] Password resetting
In-Reply-To: <339382210.11385404.1390579329270.JavaMail.root@redhat.com>
References: <1075661049.11210086.1390570691586.JavaMail.root@redhat.com>
	<52E275B5.4000205@redhat.com>
	<1662781828.11312061.1390573984818.JavaMail.root@redhat.com>
	<52E286CF.4060204@redhat.com>
	<339382210.11385404.1390579329270.JavaMail.root@redhat.com>
Message-ID: <52E2910E.4030907@redhat.com>

Sounds good.

On 1/24/2014 11:02 AM, Stian Thorgersen wrote:
> How about for user / credential page we display the following buttons:
>
> * Send password reset - visible if user has email registered, should this be only for verified email?)
> * Set temporary password - opens a modal panel where admin can insert a password or have one generated
> * Remove totp - if realm requires totp user will be asked to re-config on next login, otherwise user would have to go to acct mngmt to enable
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 24 January, 2014 3:29:19 PM
>> Subject: Re: [keycloak-dev] Password resetting
>>
>>
>>
>> On 1/24/2014 9:33 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 24 January, 2014 2:16:21 PM
>>>> Subject: Re: [keycloak-dev] Password resetting
>>>>
>>>>
>>>>
>>>> On 1/24/2014 8:38 AM, Stian Thorgersen wrote:
>>>>> To prevent hijacking the thread for planning what goes into the next
>>>>> release, I'll start this new thread on this subject.
>>>>>
>>>>> For clarification, at the moment what we have with password reset is :
>>>>>
>>>>> Users:
>>>>> * If realm allows it and user has registered email address they can click
>>>>> on the recover password option. They then insert their username and an
>>>>> email with a link is sent to them. This link will expire within a
>>>>> configurable time (default is 10 min I think). The link will open a form
>>>>> enabling the user to insert a new password.
>>>>>
>>>>> Admins:
>>>>> * Admins can set a new temporary password on a user account. This will
>>>>> add
>>>>> a flag that the user is required to reset the password on next login.
>>>>> Currently the admin could remove this required action though, as admins
>>>>> can add/remove required actions to an account
>>>>>
>>>>> Improvements to this flow would be good. It's not elegant that admin has
>>>>> to
>>>>> manually create tmp password, and somehow communicate this to the user.
>>>>> Also, as Bruno pointed out this would mean an admin could gain access to
>>>>> a
>>>>> users account. Any other concerns?
>>>>>
>>>>
>>>> The improvement I want is an email with a URL that contains a temporary
>>>> token.  User's acct status would be set to "update password", but they
>>>> would not have to enter in their password, just a new one.
>>>
>>> We have this already don't we? In the realm settings enable "Rest
>>> password", then open the login page, now there's link for "Forgot
>>> Username" and "Forgot Password".
>>>
>>
>> I mean a button in the admin console which will change the status of the
>> user acct and also send an email to the user.
>>
>>
>>>>
>>>> I think you're right in that we still need the option for the admin to
>>>> set up a temporary password.
>>>>
>>>>> With regards to admins being able to send recover email, I'm not sure I
>>>>> see
>>>>> the point. Users can do this themselves if they want to. Also, the link
>>>>> in
>>>>> the email expires within a relatively short timeout, so it would quite
>>>>> likely be expired by the time a user reads it
>>>>>
>>>>> Stopping a compromised admin being able to access the account, I'm not
>>>>> sure
>>>>> that would be feasible. Even if an admin can't set a tmp password, they
>>>>> could for example change the email and get a recovery password email sent
>>>>> to themselves. I also think a compromised admin account would mean we're
>>>>> pretty screwed in any case, so is this really important?
>>>>>
>>>>> I don't understand how TOTP would work, can you explain.
>>>>
>>>> TOTP could work same way as above.  Send an email, user is temporarily
>>>> authenticated, but must reset totp key.
>>>
>>> We have similar feature here. If TOTP is lost the admin would disable TOTP,
>>> then add a required action to re-configure TOTP on next login.
>>>
>>>>
>>>> In the future, I'd like to have a "World of Warcraft" option.  I really
>>>> like the way they do it as hacked user accounts were really common prior
>>>> to 2-factor auth.  To reset a password, you get an email.  To reset TOTP
>>>> you get a text to your phone.  So, if your email account gets hacked
>>>> (like mine was prior to enabling 2-factor auth), you're still safe.
>>>
>>> Yes, we definitively needs more layers of defence. Would be great to have
>>> SMS/phone options. We should also have options to enable password recovery
>>> questions (What's your first car thing).
>>>
>>> We can also enable support for OTP through email and sms
>>>
>>
>> Yes.  I forgot about user questions ("What's your first car?")...that's
>> something I've wanted to add too.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From bburke at redhat.com  Fri Jan 24 11:30:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jan 2014 11:30:52 -0500
Subject: [keycloak-dev] Device mgmt
Message-ID: <52E2953C.2010707@redhat.com>

Here's my thoughts on device mgmt, both UI and protocol:

Scenario:

An iOS device as a "Brokerage App" installed.  The app needs to do REST 
invocations to be able to trade stocks, etc.  Devices must be registered 
in order to obtain permission.  Flow would look like this:

* User installs app on iPad.
* User hits login button on app.
* User is redirected to browser with a Keycloak server URL
* User enters in credentials
* User is redirected to "Device Registration" page.  Keycloak asks user 
if it authorizes access to the device.
* Keycloak registers the device under the user and generates a device token
* User is redirected back to iPad ap
* iPad app gets auth code from redirect URL
* iPad makes REST request to obtain auth token *AND* a device token.
* iPad app stores the device token.

Next login is the same, except there is no "grant" page displayed. The 
iPad app uses the "device token" as a credential to turn an access code 
into an access token.  These are all extensions we'll need to make to 
the current OAuth protocol.

UI work:

The User Account Service will need a way to list registered devices so 
the user can see it and manage it (i.e. remove a registered device).

Admin Console should have a way to define a "Device Type".  The name, 
description and scope of the device type is defined.  "name" is used in 
the initial OAuth grant as a client_id identifier so that Keycloak knows 
what to display as a description in the


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

From stian at redhat.com  Fri Jan 24 12:06:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jan 2014 12:06:37 -0500 (EST)
Subject: [keycloak-dev] Theme support for forms
In-Reply-To: <1570195350.11409368.1390581319066.JavaMail.root@redhat.com>
Message-ID: <577107131.11428644.1390583197275.JavaMail.root@redhat.com>

As forms and the account management console are aimed at end-users it's important that it's easy for developers to customize the look and feel of these so they integrate well with their organizations and applications.

This is one of the main reasons we're using a template engine instead of a web framework. We've chosen FreeMarker as it seems to be relatively popular, is powerful and at the same time has a relatively low learning curve.

For the next release I'm going to add support for themes to the forms. As part of this I'd like to split the forms (login, registration, etc.) and account management into two separate maven modules. Initially I'll focus on adding theme support for the forms, but shouldn't be a problem to add support for both in the next release.

A theme will consist of:

* theme.properties - standard java properties file with theme name, name of theme it extends, etc. Can also contain theme specific config options
* css
* images
* messages
* pages

A theme can extend another theme, in which case it can override specific resources in the theme. For example a theme could consist of nothing but "theme.properties" and "css/styles.css". In fact this will be the recommended approach as in most cases it should be possible to do the required customization using css (anyone that doubt's this can have a look at http://www.csszengarden.com/ to see what can be achieved with css).

If needed a theme can override pages as well, this will be html pages with the addition of FreeMarker syntax. All pages can be overridden, or just individual pages.

A theme can be packaged as a ZIP, then copied into a specific directory or uploaded through the admin console. It will also be possible to package a theme as a JAR and add as a dependency, in which case we'll use ServiceLoader to discover themes on the class-path (this is how the default theme will be packaged to make sure it's easily available).

There will also be an SPI to allow replacing FreeMarker with whatever you want. We'll provide one implementation which is what's described above. This will probably be left for later though.

Finally, through the admin console it will be possible to set what theme to use for a realm. Initially this will only be setting the theme name, but in the future we may also support configuring theme properties. The default theme when creating a new realm will be the Keycloak theme.

From matzew at apache.org  Fri Jan 24 12:54:02 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 24 Jan 2014 18:54:02 +0100
Subject: [keycloak-dev] Device mgmt
In-Reply-To: <52E2953C.2010707@redhat.com>
References: <52E2953C.2010707@redhat.com>
Message-ID: <CAAg5f2QHtym6PVSvsYg48C9Sd+c9M02T=+DRMjXpRZBzrYPQpw@mail.gmail.com>

+1 on this scenario


There is a different scenario:

* the mobile app does not require an actual user (e.g. think about
something like a News-App (e.g. "ESPN Sports Ticker")), but the device
still needs to be registered w/ a server, so that the server later can use
the device metadata for sending push notifications to the iOS / Android
device. The AeroGear UnifiedPush Server is doing it (currently) via HTTP
Basic (see [1]).


Is this some scenario you are interested in supporting as well? Or is the
(current) focus more around storing 'devices' / 'device metadata' under a
real user (which is most-likely a pure enterprise use-case)?

Greetings,
Matthias

[1] http://aerogear.org/docs/specs/aerogear-push-rest/DeviceRegistration/



On Fri, Jan 24, 2014 at 5:30 PM, Bill Burke <bburke at redhat.com> wrote:

> Here's my thoughts on device mgmt, both UI and protocol:
>
> Scenario:
>
> An iOS device as a "Brokerage App" installed.  The app needs to do REST
> invocations to be able to trade stocks, etc.  Devices must be registered
> in order to obtain permission.  Flow would look like this:
>
> * User installs app on iPad.
> * User hits login button on app.
> * User is redirected to browser with a Keycloak server URL
> * User enters in credentials
> * User is redirected to "Device Registration" page.  Keycloak asks user
> if it authorizes access to the device.
> * Keycloak registers the device under the user and generates a device token
> * User is redirected back to iPad ap
> * iPad app gets auth code from redirect URL
> * iPad makes REST request to obtain auth token *AND* a device token.
> * iPad app stores the device token.
>
> Next login is the same, except there is no "grant" page displayed. The
> iPad app uses the "device token" as a credential to turn an access code
> into an access token.  These are all extensions we'll need to make to
> the current OAuth protocol.
>
> UI work:
>
> The User Account Service will need a way to list registered devices so
> the user can see it and manage it (i.e. remove a registered device).
>
> Admin Console should have a way to define a "Device Type".  The name,
> description and scope of the device type is defined.  "name" is used in
> the initial OAuth grant as a client_id identifier so that Keycloak knows
> what to display as a description in the
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140124/41aed0cb/attachment.html 

From bburke at redhat.com  Fri Jan 24 13:19:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jan 2014 13:19:51 -0500
Subject: [keycloak-dev] Device mgmt
In-Reply-To: <CAAg5f2QHtym6PVSvsYg48C9Sd+c9M02T=+DRMjXpRZBzrYPQpw@mail.gmail.com>
References: <52E2953C.2010707@redhat.com>
	<CAAg5f2QHtym6PVSvsYg48C9Sd+c9M02T=+DRMjXpRZBzrYPQpw@mail.gmail.com>
Message-ID: <52E2AEC7.6010808@redhat.com>



On 1/24/2014 12:54 PM, Matthias Wessendorf wrote:
> +1 on this scenario
>
>
> There is a different scenario:
>
> * the mobile app does not require an actual user (e.g. think about
> something like a News-App (e.g. "ESPN Sports Ticker")), but the device
> still needs to be registered w/ a server, so that the server later can
> use the device metadata for sending push notifications to the iOS /
> Android device. The AeroGear UnifiedPush Server is doing it (currently)
> via HTTP Basic (see [1]).
>

In this case, couldn't the device just use the registration API?

>
> Is this some scenario you are interested in supporting as well? Or is
> the (current) focus more around storing 'devices' / 'device metadata'
> under a real user (which is most-likely a pure enterprise use-case)?
>

IMO, its not a pure enterprise use case.  I access my brokerage acct via 
my ipad and browser via the same credentials.


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

From matzew at apache.org  Fri Jan 24 13:41:38 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 24 Jan 2014 19:41:38 +0100
Subject: [keycloak-dev] Device mgmt
In-Reply-To: <52E2AEC7.6010808@redhat.com>
References: <52E2953C.2010707@redhat.com>
	<CAAg5f2QHtym6PVSvsYg48C9Sd+c9M02T=+DRMjXpRZBzrYPQpw@mail.gmail.com>
	<52E2AEC7.6010808@redhat.com>
Message-ID: <CAAg5f2TUaiuuGkeP5aKKm2HfB6tw09y8ZfdcN4QULXGu4w+0pg@mail.gmail.com>

On Fri, Jan 24, 2014 at 7:19 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 1/24/2014 12:54 PM, Matthias Wessendorf wrote:
>
>> +1 on this scenario
>>
>>
>> There is a different scenario:
>>
>> * the mobile app does not require an actual user (e.g. think about
>> something like a News-App (e.g. "ESPN Sports Ticker")), but the device
>> still needs to be registered w/ a server, so that the server later can
>> use the device metadata for sending push notifications to the iOS /
>> Android device. The AeroGear UnifiedPush Server is doing it (currently)
>> via HTTP Basic (see [1]).
>>
>>
> In this case, couldn't the device just use the registration API?


Of the UnifiedPush Server? Sure!

I was just wondering if you guys are interested in this scenario as well.



>
>
>
>> Is this some scenario you are interested in supporting as well? Or is
>> the (current) focus more around storing 'devices' / 'device metadata'
>> under a real user (which is most-likely a pure enterprise use-case)?
>>
>>
> IMO, its not a pure enterprise use case.  I access my brokerage acct via
> my ipad and browser via the same credentials.


yep, I was more saying that requiring a user in order to use a mobile app
is a bit more enterprise-like (sure: Twitter/FB are NOT enterprise), than
have no user required at all(like the mentioned sports-news-ticker).

So the brokerage could be even done on your iPad, your Android phone, your
browser, etc ;-)

-Matthias



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



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140124/d111d02c/attachment-0001.html 

From bburke at redhat.com  Fri Jan 24 14:46:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jan 2014 14:46:23 -0500
Subject: [keycloak-dev] Device mgmt
In-Reply-To: <CAAg5f2TUaiuuGkeP5aKKm2HfB6tw09y8ZfdcN4QULXGu4w+0pg@mail.gmail.com>
References: <52E2953C.2010707@redhat.com>	<CAAg5f2QHtym6PVSvsYg48C9Sd+c9M02T=+DRMjXpRZBzrYPQpw@mail.gmail.com>	<52E2AEC7.6010808@redhat.com>
	<CAAg5f2TUaiuuGkeP5aKKm2HfB6tw09y8ZfdcN4QULXGu4w+0pg@mail.gmail.com>
Message-ID: <52E2C30F.7040205@redhat.com>



On 1/24/2014 1:41 PM, Matthias Wessendorf wrote:
>
>
>
> On Fri, Jan 24, 2014 at 7:19 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 1/24/2014 12:54 PM, Matthias Wessendorf wrote:
>
>         +1 on this scenario
>
>
>         There is a different scenario:
>
>         * the mobile app does not require an actual user (e.g. think about
>         something like a News-App (e.g. "ESPN Sports Ticker")), but the
>         device
>         still needs to be registered w/ a server, so that the server
>         later can
>         use the device metadata for sending push notifications to the iOS /
>         Android device. The AeroGear UnifiedPush Server is doing it
>         (currently)
>         via HTTP Basic (see [1]).
>
>
>     In this case, couldn't the device just use the registration API?
>
>
> Of the UnifiedPush Server? Sure!
>
> I was just wondering if you guys are interested in this scenario as well.
>

Actually, I don't know.  Does a "ESPN Sports Ticker" even come under the 
IDP umbrella?  What exactly is being managed here?

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

From matzew at apache.org  Mon Jan 27 06:44:11 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 27 Jan 2014 12:44:11 +0100
Subject: [keycloak-dev] Base64 class
Message-ID: <CAAg5f2QkuvuxOLmJ==oJpT9qvHSrJUKsREXgXoK7juSXXbbdFA@mail.gmail.com>

Hello,

I noticed that the keycloak src contains two identical Base64 java classes:

*
https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/util/Base64.java
*
https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/utils/Base64.java

Both are copied from the iharder project. I was wondering about the fact
why they were copied in (yep, that's identical to what PicketLink does).

In AeroGear we use that class as a dependency instead:
https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L57-L61

If you guys like, I am happy to provide a fix/patch for that as well

-Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140127/bb7101a5/attachment.html 

From bburke at redhat.com  Mon Jan 27 08:37:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 08:37:02 -0500
Subject: [keycloak-dev] Base64 class
In-Reply-To: <CAAg5f2QkuvuxOLmJ==oJpT9qvHSrJUKsREXgXoK7juSXXbbdFA@mail.gmail.com>
References: <CAAg5f2QkuvuxOLmJ==oJpT9qvHSrJUKsREXgXoK7juSXXbbdFA@mail.gmail.com>
Message-ID: <52E660FE.7020009@redhat.com>

I don't think it matter either way.

On 1/27/2014 6:44 AM, Matthias Wessendorf wrote:
> Hello,
>
> I noticed that the keycloak src contains two identical Base64 java classes:
>
> *
> https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/util/Base64.java
> *
> https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/utils/Base64.java
>
> Both are copied from the iharder project. I was wondering about the fact
> why they were copied in (yep, that's identical to what PicketLink does).
>
> In AeroGear we use that class as a dependency instead:
> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L57-L61
>
> If you guys like, I am happy to provide a fix/patch for that as well
>
> -Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bruno at abstractj.org  Mon Jan 27 09:43:52 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 27 Jan 2014 12:43:52 -0200
Subject: [keycloak-dev] Storage protection
Message-ID: <etPan.52e670a8.41b71efb.4fff@tesla>

Good morning, I've been thinking about how to properly protect private key in a world where HSM is not an option. Currently a key pair is generated (https://github.com/keycloak/keycloak/blob/c0a1090733975977179662dd44fc3ac75e925cf0/services/src/main/java/org/keycloak/services/managers/RealmManager.java#L90) to cryptographically sign tokens (https://github.com/keycloak/keycloak/blob/0fe9318fa414d06fc39c83d91c78effe2ba25b2a/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java#L88) and the private key is stored into the database.


Some of the possibilities to improve it:

# 1
- HSM or Java Security manager are perfect, but impractical for regular devs, that would require a lot of maintanance (a dream)
?
# 2
- Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that someone would be required to enter the password at each app startup

# 3

- Not bullet-proof solution, but store the key into a text file that only sysadmins and the web server has access, doing our best with the usage of ACLs provided by environment. ?I understand Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same time, a file could have a very restricted access while the database is more acessible to developers.
-?
# 4

Generate the keys per session, instead of use it per realm (it must be tested/implemented because that could slow down our server)

# 5

Leave it as is.

So what do you think? Ideas or tomatoes?

--  
abstractj


From Anil.Saldhana at redhat.com  Mon Jan 27 10:28:07 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 27 Jan 2014 09:28:07 -0600
Subject: [keycloak-dev] Storage protection
In-Reply-To: <etPan.52e670a8.41b71efb.4fff@tesla>
References: <etPan.52e670a8.41b71efb.4fff@tesla>
Message-ID: <52E67B07.3060204@redhat.com>

It is going to be a choice between usability and protection.

Security sensitive deployments are going to be using HSM and vaulted 
networks.

For everybody else, best is to go with usability thereby choosing an 
approach that gives good-enough security.

One of the challenges we have faced is the non-availability of a 
database for default deployments and the use of filesystem as the 
default mechanism for storage. In the case of KeyCloak, it is using the 
DB as the storage mechanism.


On 01/27/2014 08:43 AM, Bruno Oliveira wrote:
> Good morning, I've been thinking about how to properly protect private key in a world where HSM is not an option. Currently a key pair is generated (https://github.com/keycloak/keycloak/blob/c0a1090733975977179662dd44fc3ac75e925cf0/services/src/main/java/org/keycloak/services/managers/RealmManager.java#L90) to cryptographically sign tokens (https://github.com/keycloak/keycloak/blob/0fe9318fa414d06fc39c83d91c78effe2ba25b2a/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java#L88) and the private key is stored into the database.
>
>
> Some of the possibilities to improve it:
>
> # 1
> - HSM or Java Security manager are perfect, but impractical for regular devs, that would require a lot of maintanance (a dream)
>   
> # 2
> - Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that someone would be required to enter the password at each app startup
>
> # 3
>
> - Not bullet-proof solution, but store the key into a text file that only sysadmins and the web server has access, doing our best with the usage of ACLs provided by environment.  I understand Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same time, a file could have a very restricted access while the database is more acessible to developers.
> -
> # 4
>
> Generate the keys per session, instead of use it per realm (it must be tested/implemented because that could slow down our server)
>
> # 5
>
> Leave it as is.
>
> So what do you think? Ideas or tomatoes?
>
> --
> abstractj
>

From bburke at redhat.com  Mon Jan 27 10:53:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 10:53:36 -0500
Subject: [keycloak-dev] Storage protection
In-Reply-To: <52E67B07.3060204@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E67B07.3060204@redhat.com>
Message-ID: <52E68100.40501@redhat.com>



On 1/27/2014 10:28 AM, Anil Saldhana wrote:
> It is going to be a choice between usability and protection.
>
> Security sensitive deployments are going to be using HSM and vaulted
> networks.
>
> For everybody else, best is to go with usability thereby choosing an
> approach that gives good-enough security.
>
> One of the challenges we have faced is the non-availability of a
> database for default deployments and the use of filesystem as the
> default mechanism for storage. In the case of KeyCloak, it is using the
> DB as the storage mechanism.
>

I will throw out my red BS flag!...Can't see anybody seriously 
considering using a flat file for production systems.   There's no 
reason you can't have a local-only, locked down DB with either HQL, 
Mongo, or one of the other better Java databases.  But anyways, Keycloak 
only uses RDBMS by default, it has an SPI, and there's still the 
Picketlink IDM API option available to us which we're going to seriously 
consider after all major features have been implemented and we've 
planned comprehensively about federation and scalability.

More comments inline responding to Bruno's email:

>> # 1
>> - HSM or Java Security manager are perfect, but impractical for regular devs, that would require a lot of maintanance (a dream)
>>

What is HSM?  How could  the Java Security Manager protect clear text 
private keys and OTP keys?


>> # 2
>> - Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that someone would be required to enter the password at each app startup
>>
>> # 3
>>
>> - Not bullet-proof solution, but store the key into a text file that only sysadmins and the web server has access, doing our best with the usage of ACLs provided by environment.  I understand Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same time, a file could have a very restricted access while the database is more acessible to developers.
>> -


Stian suggested having an SPI for this sort of feature.  Either a 
password would be required at Keycloak server startup, or the password 
would be stored in a property file.

>> # 4
>>
>> Generate the keys per session, instead of use it per realm (it must be tested/implemented because that could slow down our server)
>>

Not sure this is feasible.  In a clustered environment, you'd need a 
trusted way of transmitting all the realm keys.  You also would need a 
way to transmit the public key of the realm to each adapter.  Each 
adapter could make an HTTPS call on bootup to retrieve all relevant 
realm metadata, but you'd still have to provide a truststore for the 
adapter so it could make a trusted HTTPS call that verified the keycloak 
server's host.  But maybe we need this truststore irregardless :) ???

But, this still doesn't protect clear text OTP keys (i.e. "What is your 
mother's maiden name?")


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

From Anil.Saldhana at redhat.com  Mon Jan 27 11:30:30 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 27 Jan 2014 10:30:30 -0600
Subject: [keycloak-dev] Storage protection
In-Reply-To: <52E68100.40501@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E67B07.3060204@redhat.com>
	<52E68100.40501@redhat.com>
Message-ID: <52E689A6.3070302@redhat.com>

On 01/27/2014 09:53 AM, Bill Burke wrote:
>
> On 1/27/2014 10:28 AM, Anil Saldhana wrote:
>> It is going to be a choice between usability and protection.
>>
>> Security sensitive deployments are going to be using HSM and vaulted
>> networks.
>>
>> For everybody else, best is to go with usability thereby choosing an
>> approach that gives good-enough security.
>>
>> One of the challenges we have faced is the non-availability of a
>> database for default deployments and the use of filesystem as the
>> default mechanism for storage. In the case of KeyCloak, it is using the
>> DB as the storage mechanism.
>>
> I will throw out my red BS flag!...Can't see anybody seriously
> considering using a flat file for production systems.   There's no
> reason you can't have a local-only, locked down DB with either HQL,
> Mongo, or one of the other better Java databases.  But anyways, Keycloak
> only uses RDBMS by default, it has an SPI, and there's still the
> Picketlink IDM API option available to us which we're going to seriously
> consider after all major features have been implemented and we've
> planned comprehensively about federation and scalability.
Typically in production systems, the choice of storage is DB or LDAP. 
That is when a stronger strategy such as HSM (Hardware Security Module) 
is used.
http://en.wikipedia.org/wiki/Hardware_security_module

But for development purposes, a DB may not be available as the default 
mechanism.  In the case of WildFly AS, I am unsure if they ship with a 
default DB
anymore.

>
> More comments inline responding to Bruno's email:
>
>>> # 1
>>> - HSM or Java Security manager are perfect, but impractical for regular devs, that would require a lot of maintanance (a dream)
>>>
> What is HSM?  How could  the Java Security Manager protect clear text
> private keys and OTP keys?
>
>
>>> # 2
>>> - Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that someone would be required to enter the password at each app startup
>>>
>>> # 3
>>>
>>> - Not bullet-proof solution, but store the key into a text file that only sysadmins and the web server has access, doing our best with the usage of ACLs provided by environment.  I understand Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same time, a file could have a very restricted access while the database is more acessible to developers.
>>> -
>
> Stian suggested having an SPI for this sort of feature.  Either a
> password would be required at Keycloak server startup, or the password
> would be stored in a property file.
>
>>> # 4
>>>
>>> Generate the keys per session, instead of use it per realm (it must be tested/implemented because that could slow down our server)
>>>
> Not sure this is feasible.  In a clustered environment, you'd need a
> trusted way of transmitting all the realm keys.  You also would need a
> way to transmit the public key of the realm to each adapter.  Each
> adapter could make an HTTPS call on bootup to retrieve all relevant
> realm metadata, but you'd still have to provide a truststore for the
> adapter so it could make a trusted HTTPS call that verified the keycloak
> server's host.  But maybe we need this truststore irregardless :) ???
>
> But, this still doesn't protect clear text OTP keys (i.e. "What is your
> mother's maiden name?")
>
>


From bruno at abstractj.org  Mon Jan 27 11:47:24 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 27 Jan 2014 14:47:24 -0200
Subject: [keycloak-dev] Storage protection
In-Reply-To: <52E68100.40501@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla>
	<52E67B07.3060204@redhat.com> <52E68100.40501@redhat.com>
Message-ID: <etPan.52e68d9c.7545e146.4fff@tesla>

Hi Bill, some answers inline. I forgot to add references.

--  
abstractj

On January 27, 2014 at 1:53:39 PM, Bill Burke (bburke at redhat.com) wrote:
> > More comments inline responding to Bruno's email:
>  
> >> # 1
> >> - HSM or Java Security manager are perfect, but impractical  
> for regular devs, that would require a lot of maintanance (a dream)  
> >>
>  
> What is HSM? How could the Java Security Manager protect clear?

http://en.wikipedia.org/wiki/Hardware_security_module

> text
> private keys and OTP keys?

With Java Security Manager is possible to restrict code privileges to the resource specified (https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/5/html/Security_Guide/chap-Java_EE_Security_Manager.html). ?

>  
>  
> >> # 2
> >> - Entering a password for a PKCS#8/PBKDF2-derived key, also  
> impractical assuming that someone would be required to enter  
> the password at each app startup
> >>
> >> # 3
> >>
> >> - Not bullet-proof solution, but store the key into a text file  
> that only sysadmins and the web server has access, doing our best  
> with the usage of ACLs provided by environment. I understand  
> Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html)  
> but at the same time, a file could have a very restricted access  
> while the database is more acessible to developers.
> >> -
>  
>  
> Stian suggested having an SPI for this sort of feature. Either  
> a
> password would be required at Keycloak server startup, or the  
> password
> would be stored in a property file.

Is not the same thing, but do you mean something like Maven does? (http://maven.apache.org/guides/mini/guide-encryption.html). Maybe a ?master password? and have some sorta of keychain? For example:

1. Master password generates the symmetric key
2. Encrypt the key pairs
3. Decrypt the key pairs on the fly for digital signatures for example.

That?s what do you mean??

>  
> >> # 4
> >>
> >> Generate the keys per session, instead of use it per realm (it  
> must be tested/implemented because that could slow down our  
> server)
> >>
>  
> Not sure this is feasible. In a clustered environment, you'd  
> need a
> trusted way of transmitting all the realm keys. You also would  
> need a
> way to transmit the public key of the realm to each adapter. Each  
> adapter could make an HTTPS call on bootup to retrieve all relevant  
> realm metadata, but you'd still have to provide a truststore  
> for the
> adapter so it could make a trusted HTTPS call that verified the  
> keycloak
> server's host. But maybe we need this truststore irregardless  
> :) ???
>  
> But, this still doesn't protect clear text OTP keys (i.e. "What  
> is your
> mother's maiden name??)

Option 4 must be tested/elaborated better, if you guys think that some of the other options worth to try, just let me know. Other than that, I will try to help in whatever you guys think is the best.


From bburke at redhat.com  Mon Jan 27 11:53:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 11:53:59 -0500
Subject: [keycloak-dev] authenticating applications
Message-ID: <52E68F27.1010803@redhat.com>

If SSL is a realm requirement, can't you use two-way SSL using between 
Keycloak and the application's server using the certificates of each of 
those servers?  There would be no need to set up client certs.  For 
self-signed certs you could even do what the browser does and have the 
admin console ask to trust the cert from the host of the application's 
server  (vice versa too!).
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon Jan 27 11:59:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 11:59:03 -0500
Subject: [keycloak-dev] Storage protection
In-Reply-To: <etPan.52e68d9c.7545e146.4fff@tesla>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E67B07.3060204@redhat.com>
	<52E68100.40501@redhat.com> <etPan.52e68d9c.7545e146.4fff@tesla>
Message-ID: <52E69057.7060508@redhat.com>



On 1/27/2014 11:47 AM, Bruno Oliveira wrote:
> Hi Bill, some answers inline. I forgot to add references.
>
> --
> abstractj
>
> On January 27, 2014 at 1:53:39 PM, Bill Burke (bburke at redhat.com) wrote:
>>> More comments inline responding to Bruno's email:
>>
>>>> # 1
>>>> - HSM or Java Security manager are perfect, but impractical
>> for regular devs, that would require a lot of maintanance (a dream)
>>>>
>>
>> What is HSM? How could the Java Security Manager protect clear
>
> http://en.wikipedia.org/wiki/Hardware_security_module
>
>> text
>> private keys and OTP keys?
>
> With Java Security Manager is possible to restrict code privileges to the resource specified (https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/5/html/Security_Guide/chap-Java_EE_Security_Manager.html).
>

For the security manager, this is a compliment to other storage 
protection mechanisms and not a replacement, correct?

>>
>>
>>>> # 2
>>>> - Entering a password for a PKCS#8/PBKDF2-derived key, also
>> impractical assuming that someone would be required to enter
>> the password at each app startup
>>>>
>>>> # 3
>>>>
>>>> - Not bullet-proof solution, but store the key into a text file
>> that only sysadmins and the web server has access, doing our best
>> with the usage of ACLs provided by environment. I understand
>> Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html)
>> but at the same time, a file could have a very restricted access
>> while the database is more acessible to developers.
>>>> -
>>
>>
>> Stian suggested having an SPI for this sort of feature. Either
>> a
>> password would be required at Keycloak server startup, or the
>> password
>> would be stored in a property file.
>
> Is not the same thing, but do you mean something like Maven does? (http://maven.apache.org/guides/mini/guide-encryption.html). Maybe a ?master password? and have some sorta of keychain? For example:
>

Each realm needs it's own key-pair.

> 1. Master password generates the symmetric key
> 2. Encrypt the key pairs
> 3. Decrypt the key pairs on the fly for digital signatures for example.
>
> That?s what do you mean?
>

There would be a master password (or key) that is used to encrypt clear 
text items in the database.  password would be entered from command line 
at startup, or grabbed from a secure property file.

I think that's the approach we should take.  Unless you can argue for a 
better solution?

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

From bruno at abstractj.org  Mon Jan 27 12:03:19 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 27 Jan 2014 15:03:19 -0200
Subject: [keycloak-dev] Storage protection
In-Reply-To: <52E69057.7060508@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla>
	<52E67B07.3060204@redhat.com> <52E68100.40501@redhat.com>
	<etPan.52e68d9c.7545e146.4fff@tesla> <52E69057.7060508@redhat.com>
Message-ID: <etPan.52e69157.515f007c.4fff@tesla>



> For the security manager, this is a compliment to other storage  
> protection mechanisms and not a replacement, correct?
>?

Correct

>  
> There would be a master password (or key) that is used to encrypt  
> clear
> text items in the database. password would be entered from command  
> line
> at startup, or grabbed from a secure property file.
>  
> I think that's the approach we should take. Unless you can argue  
> for a
> better solution?

Not really, this is a tricky problem to solve.


From bburke at redhat.com  Mon Jan 27 12:08:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 12:08:54 -0500
Subject: [keycloak-dev] new client type:  "server"
Message-ID: <52E692A6.4000807@redhat.com>

Stan's work on the Wildfly subsystem got me thinking about how we might 
want to reorganize keycloak.  Since multiple applications may often be 
deployed on the same server, what if we split the notion of Application 
and client?  Application would be a place to define application roles 
and application scope only.  A server can be associated with multiple 
applications.

For config/bootstrapping, the user would specify a server in the admin 
console and set up trust between the two.  Then the user could import 
deployments from a server and associate them with a realm and even 
download the the roles of each of these deployments and create 
Applications from them.  For OAuth tokens, server would specify the 
server's client_id as well as a scope.  The scope would be the 
Application the server is asking a token for.

So, a server would have:

* a client_id
* credentials
* admin URL
* be associated with one or more Applications

Application would have:
* roles
* valid redirect urls  (which are associated with a server)
* scope
* sessions (view who's logged in where into what server)

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

From bburke at redhat.com  Mon Jan 27 12:12:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 12:12:48 -0500
Subject: [keycloak-dev] can we get away with federating user/cred only?
Message-ID: <52E69390.6010102@redhat.com>

Can we get away with federating user and credentials only?  Only store 
those in LDAP/AD?  Would sure make our lives a lot easier and this may 
cover 80% of deployments that need it?

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

From bburke at redhat.com  Mon Jan 27 11:34:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 11:34:45 -0500
Subject: [keycloak-dev] Storage protection
In-Reply-To: <52E689A6.3070302@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla>
	<52E67B07.3060204@redhat.com>	<52E68100.40501@redhat.com>
	<52E689A6.3070302@redhat.com>
Message-ID: <52E68AA5.3000608@redhat.com>



On 1/27/2014 11:30 AM, Anil Saldhana wrote:
> But for development purposes, a DB may not be available as the default
> mechanism.  In the case of WildFly AS, I am unsure if they ship with a
> default DB
> anymore.

Wildfly still has a DB, and we use it by default.


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

From Clifton.Lee at uftwf.org  Mon Jan 27 17:44:25 2014
From: Clifton.Lee at uftwf.org (Clifton Lee)
Date: Mon, 27 Jan 2014 17:44:25 -0500
Subject: [keycloak-dev] Quick Question Regarding the WildFly Demo
Message-ID: <082EF95A390E8547BB06D806F9F7D60F034757BF@uftwfexchsvr01.UFTMASTERAD.ORG>

Hello, I'd post this on the users list but there didn't seem to any
activity there.

 

After downloading the keycloak-appliance-dist-all-1.0-alpha-1.zip file,
configuring the portal & customer portals, I received the following
error when trying to authenticate:  failed to turn code into token.

 

I used a different password from the demo but I made sure to keep the
password consistent with the KeyCloak server and the portal servlets.
Has anyone come across this?  Thanks.

 


*******************************************************************************
The views, opinions, and judgments expressed in this message are solely those of the author. The message contents have not been reviewed or approved by the UFT Welfare Fund.
*******************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140127/c57275d8/attachment.html 

From bburke at redhat.com  Mon Jan 27 17:50:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jan 2014 17:50:54 -0500
Subject: [keycloak-dev] Quick Question Regarding the WildFly Demo
In-Reply-To: <082EF95A390E8547BB06D806F9F7D60F034757BF@uftwfexchsvr01.UFTMASTERAD.ORG>
References: <082EF95A390E8547BB06D806F9F7D60F034757BF@uftwfexchsvr01.UFTMASTERAD.ORG>
Message-ID: <52E6E2CE.9070309@redhat.com>

Ugh, looking at the code, I didn't provide a good way to debug this problem.

What passwords did you change?  How did you change them?  Prolems could be:

* wildfly adapter is not authenticating with the realm when, you screwed 
up the passwords somehow.  Maybe you didn't modify keycloak.json to put 
in the new credential?
* You don't have the right URL of the server.

Is there any other log messages available beyond "failed to turn code 
into token"?

On 1/27/2014 5:44 PM, Clifton Lee wrote:
> Hello, I?d post this on the users list but there didn?t seem to any
> activity there.
>
> After downloading the keycloak-appliance-dist-all-1.0-alpha-1.zip file,
> configuring the portal & customer portals, I received the following
> error when trying to authenticate:  failed to turn code into token.
>
> I used a different password from the demo but I made sure to keep the
> password consistent with the KeyCloak server and the portal servlets.
> Has anyone come across this?  Thanks.
>
> *******************************************************************************
>
>
> The views, opinions, and judgments expressed in this message are solely
> those of the author. The message contents have not been reviewed or
> approved by the UFT Welfare Fund.
>
> *******************************************************************************
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From Clifton.Lee at uftwf.org  Tue Jan 28 09:57:32 2014
From: Clifton.Lee at uftwf.org (Clifton Lee)
Date: Tue, 28 Jan 2014 09:57:32 -0500
Subject: [keycloak-dev] Quick Question Regarding the WildFly Demo
In-Reply-To: <52E6E2CE.9070309@redhat.com>
References: <082EF95A390E8547BB06D806F9F7D60F034757BF@uftwfexchsvr01.UFTMASTERAD.ORG>
	<52E6E2CE.9070309@redhat.com>
Message-ID: <082EF95A390E8547BB06D806F9F7D60F034757EB@uftwfexchsvr01.UFTMASTERAD.ORG>

Hi, good news.  I originally changed the application credential password
but  after starting over and simply using 'password' as in the tutorial,
the demo was working fine (I used the examples in the wildfly-demo
folder).

As you said, I definitely screwed up either the password in the
keycloak.json file(s) or simply didn't copy the installation-json file
properly from the Keycloak interface to the applications' keycloak.json
files.

Thanks for your help!

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org
[mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: Monday, January 27, 2014 5:51 PM
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Quick Question Regarding the WildFly Demo

Ugh, looking at the code, I didn't provide a good way to debug this
problem.

What passwords did you change?  How did you change them?  Prolems could
be:

* wildfly adapter is not authenticating with the realm when, you screwed

up the passwords somehow.  Maybe you didn't modify keycloak.json to put 
in the new credential?
* You don't have the right URL of the server.

Is there any other log messages available beyond "failed to turn code 
into token"?

On 1/27/2014 5:44 PM, Clifton Lee wrote:
> Hello, I'd post this on the users list but there didn't seem to any
> activity there.
>
> After downloading the keycloak-appliance-dist-all-1.0-alpha-1.zip
file,
> configuring the portal & customer portals, I received the following
> error when trying to authenticate:  failed to turn code into token.
>
> I used a different password from the demo but I made sure to keep the
> password consistent with the KeyCloak server and the portal servlets.
> Has anyone come across this?  Thanks.
>
>
************************************************************************
*******
>
>
> The views, opinions, and judgments expressed in this message are
solely
> those of the author. The message contents have not been reviewed or
> approved by the UFT Welfare Fund.
>
>
************************************************************************
*******
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

*******************************************************************************
The views, opinions, and judgments expressed in this message are solely those of the author. The message contents have not been reviewed or approved by the UFT Welfare Fund.
*******************************************************************************


From gcardoso at redhat.com  Wed Jan 29 05:31:12 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 29 Jan 2014 08:31:12 -0200
Subject: [keycloak-dev] Customization for Keycloak
Message-ID: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>

Hi,

I?m working on the customization of Keycloak based on the new logo and colors.

Here is my proposal for the console:



What do you think?

Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/75a7d709/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customization.png
Type: image/png
Size: 46390 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/75a7d709/attachment-0001.png 

From stian at redhat.com  Wed Jan 29 05:41:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Jan 2014 05:41:59 -0500 (EST)
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
Message-ID: <1416737156.15331870.1390992119877.JavaMail.root@redhat.com>

Looks decent enough, but what we have currently looks way better + it looks a lot like FaceBook

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 January, 2014 10:31:12 AM
> Subject: [keycloak-dev] Customization for Keycloak
> 
> Hi,
> 
> I?m working on the customization of Keycloak based on the new logo and
> colors.
> 
> Here is my proposal for the console:
> 
> 
> What do you think?
> 
> Gabriel
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Wed Jan 29 08:48:57 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Jan 2014 08:48:57 -0500 (EST)
Subject: [keycloak-dev] authenticating applications
In-Reply-To: <52E68F27.1010803@redhat.com>
References: <52E68F27.1010803@redhat.com>
Message-ID: <860906501.15426211.1391003337309.JavaMail.root@redhat.com>

Sounds like a good way to do it to me.

Had a quick search for two-way SSL, and IBM Identity Manager Express does both:

http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/index.jsp?topic=%2Fcom.ibm.itim.infocenter.doc%2Fcpt%2Fcpt_ic_security_ssl_authent1way.html
http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/index.jsp?topic=%2Fcom.ibm.itim.infocenter.doc%2Fcpt%2Fcpt_ic_security_ssl_authent2way.html

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 27 January, 2014 4:53:59 PM
> Subject: [keycloak-dev] authenticating applications
> 
> If SSL is a realm requirement, can't you use two-way SSL using between
> Keycloak and the application's server using the certificates of each of
> those servers?  There would be no need to set up client certs.  For
> self-signed certs you could even do what the browser does and have the
> admin console ask to trust the cert from the host of the application's
> server  (vice versa too!).
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jan 29 08:51:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Jan 2014 08:51:03 -0500 (EST)
Subject: [keycloak-dev] can we get away with federating user/cred only?
In-Reply-To: <52E69390.6010102@redhat.com>
References: <52E69390.6010102@redhat.com>
Message-ID: <1280868395.15426987.1391003463622.JavaMail.root@redhat.com>

When it comes to enterprises I think having multiple options to best integrate into whatever ecosystem they already have in place.

With that in mind, when possible I think syncing to/from LDAP would be great. Keycloak store would in most cases provide more information than the LDAP store in those cases. For example role mappings.

If we design a sync SPI that would allow users to do their own to integrate with whatever they currently have. Be it LDAP, a relational database, or any other solutions. The SPI could have a read only, as well as a read/write option.

Also I think it makes sense to add support auth brokering. Again through an auth SPI. I imagine this would work by letting a realm use a different source to validate credentials. A very crude auth SPI could look like:

  public boolean isAuthenticated(String username, Credential... credentials) {
  }

Some auth providers could only work for some credentials. For example an LDAP could be used to verify the username/password, then Keycloak to verify TOTP, while roles and other user profile data retrieve from the Keycloak store.

The same auth SPI could be used to add support for additional OTP mechanisms (email, smtp, yubikey, you name it).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 27 January, 2014 5:12:48 PM
> Subject: [keycloak-dev] can we get away with federating user/cred only?
> 
> Can we get away with federating user and credentials only?  Only store
> those in LDAP/AD?  Would sure make our lives a lot easier and this may
> cover 80% of deployments that need it?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From gcardoso at redhat.com  Wed Jan 29 09:18:22 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 29 Jan 2014 12:18:22 -0200
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
Message-ID: <181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>

Login page:



Maybe this minimizes the Facebook effect, Stian?

On Jan 29, 2014, at 8:41 AM, Stian Thorgersen <stian at redhat.com> wrote:

> Looks decent enough, but what we have currently looks way better + it looks a lot like FaceBook
> 
> ----- Original Message -----
>> From: "Gabriel Cardoso" <gcardoso at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 29 January, 2014 10:31:12 AM
>> Subject: [keycloak-dev] Customization for Keycloak
>> 
>> Hi,
>> 
>> I?m working on the customization of Keycloak based on the new logo and
>> colors.
>> 
>> Here is my proposal for the console:
>> 
>> 
>> What do you think?
>> 
>> Gabriel
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/4205bd5b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: login-customization.png
Type: image/png
Size: 56053 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/4205bd5b/attachment-0001.png 

From bburke at redhat.com  Wed Jan 29 09:24:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Jan 2014 09:24:32 -0500
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
Message-ID: <52E90F20.50100@redhat.com>

I'm up for anything that looks professional.  Both look good to me. 
Should we follow color schemes/styles of the Wildfly admin console though?

On 1/29/2014 5:31 AM, Gabriel Cardoso wrote:
> Hi,
>
> I?m working on the customization of Keycloak based on the new logo and
> colors.
>
> Here is my proposal for the console:
>
>
> What do you think?
>
> Gabriel
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Wed Jan 29 09:32:47 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Wed, 29 Jan 2014 09:32:47 -0500
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <52E90F20.50100@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<52E90F20.50100@redhat.com>
Message-ID: <52E9110F.8060601@redhat.com>

On 1/29/2014 9:24 AM, Bill Burke wrote:
> I'm up for anything that looks professional.  Both look good to me. 
> Should we follow color schemes/styles of the Wildfly admin console though?
I think that's a question for Cathrine.
>
> On 1/29/2014 5:31 AM, Gabriel Cardoso wrote:
>> Hi,
>>
>> I?m working on the customization of Keycloak based on the new logo and
>> colors.
>>
>> Here is my proposal for the console:
>>
>>
>> What do you think?
>>
>> Gabriel
>>
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From gcardoso at redhat.com  Wed Jan 29 09:34:12 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 29 Jan 2014 12:34:12 -0200
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <52E9110F.8060601@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<52E90F20.50100@redhat.com> <52E9110F.8060601@redhat.com>
Message-ID: <DDB6AAC1-EF83-4319-B9E3-D8AFFD14A829@redhat.com>

We don?t need to follow their color scheme.

I?ve sent the proposal for the console to her and she said it was fine.

Gabriel

On Jan 29, 2014, at 12:32 PM, ssilvert at redhat.com wrote:

> On 1/29/2014 9:24 AM, Bill Burke wrote:
>> I'm up for anything that looks professional.  Both look good to me. 
>> Should we follow color schemes/styles of the Wildfly admin console though?
> I think that's a question for Cathrine.
>> 
>> On 1/29/2014 5:31 AM, Gabriel Cardoso wrote:
>>> Hi,
>>> 
>>> I?m working on the customization of Keycloak based on the new logo and
>>> colors.
>>> 
>>> Here is my proposal for the console:
>>> 
>>> 
>>> What do you think?
>>> 
>>> Gabriel
>>> 
>>> ---
>>> Gabriel Cardoso
>>> User Experience Designer @ Red Hat
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/3c6476f4/attachment.html 

From stian at redhat.com  Wed Jan 29 09:34:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Jan 2014 09:34:40 -0500 (EST)
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
Message-ID: <1472847138.15469641.1391006080989.JavaMail.root@redhat.com>

The login form looks really good!

I'm not convinced about the admin console though. The bright blue isn't very nice. Also I was wondering if there's some way we could not have a separate "bar" for the realm drop-down and add realm button. Could we move this to the left-hand menu, or merge it with the logo / user selection bar (and also make it slightly bigger at the same time)?


----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 January, 2014 2:18:22 PM
> Subject: Re: [keycloak-dev] Customization for Keycloak
> 
> Login page:
> 
> 
> 
> Maybe this minimizes the Facebook effect, Stian?
> 
> On Jan 29, 2014, at 8:41 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > Looks decent enough, but what we have currently looks way better + it looks
> > a lot like FaceBook
> > 
> > ----- Original Message -----
> >> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 29 January, 2014 10:31:12 AM
> >> Subject: [keycloak-dev] Customization for Keycloak
> >> 
> >> Hi,
> >> 
> >> I?m working on the customization of Keycloak based on the new logo and
> >> colors.
> >> 
> >> Here is my proposal for the console:
> >> 
> >> 
> >> What do you think?
> >> 
> >> Gabriel
> >> 
> >> ---
> >> Gabriel Cardoso
> >> User Experience Designer @ Red Hat
> >> 
> >> 
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 


From gcardoso at redhat.com  Wed Jan 29 09:44:12 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 29 Jan 2014 12:44:12 -0200
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
Message-ID: <28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>


On Jan 29, 2014, at 12:34 PM, Stian Thorgersen <stian at redhat.com> wrote:

> The login form looks really good!
Thanks

> I'm not convinced about the admin console though. The bright blue isn't very nice. Also I was wondering if there's some way we could not have a separate "bar" for the realm drop-down and add realm button. Could we move this to the left-hand menu, or merge it with the logo / user selection bar (and also make it slightly bigger at the same time)?
Well, it is a matter of taste. But I can try to make it more attractive.

Why you don?t want to have that nav bar? We have plenty of space and it is clear that this is the highter level of navigation.

However, it doesn?t hurt trying to incorporate the dropdown and button into the sidebar. I?m just afraid this will make the navigation more confusing, but we can give a shot. 

Here is an example of something they did for EAP.



I needed to think a bit to understand the hierarchy.

Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/3cbb8559/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UI-Style-Minimal-Breadcrumb.png
Type: image/png
Size: 122883 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/3cbb8559/attachment-0001.png 

From bburke at redhat.com  Wed Jan 29 09:56:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Jan 2014 09:56:08 -0500
Subject: [keycloak-dev] can we get away with federating user/cred only?
In-Reply-To: <1280868395.15426987.1391003463622.JavaMail.root@redhat.com>
References: <52E69390.6010102@redhat.com>
	<1280868395.15426987.1391003463622.JavaMail.root@redhat.com>
Message-ID: <52E91688.3050806@redhat.com>

interface AuthenticatorDelegate {

    boolean isAuthenticated(UserModel user, Credential... credentials) 
throws UnsupportedCredentialType;

    void updateCredential(UserModel user, Credential oldCred, Credential 
newcred) throws UnsupportedCredentialType;

}


I was thinking we'd offer a Picketlink IDM API one.  THe admin console 
would allow you to upload a PL config file through this SPI interface:

interface AuthenticatorDelegateFactory {

    Set<String> getSupportedCredentialTypes();
    AuthenticatorDelegate create(MediaType mediaType, byte[] configBytes);

}

Or, alternatively we could put a nice UI on top of PL to configure LDAP.





On 1/29/2014 8:51 AM, Stian Thorgersen wrote:
> When it comes to enterprises I think having multiple options to best integrate into whatever ecosystem they already have in place.
>
> With that in mind, when possible I think syncing to/from LDAP would be great. Keycloak store would in most cases provide more information than the LDAP store in those cases. For example role mappings.
>
> If we design a sync SPI that would allow users to do their own to integrate with whatever they currently have. Be it LDAP, a relational database, or any other solutions. The SPI could have a read only, as well as a read/write option.
>
> Also I think it makes sense to add support auth brokering. Again through an auth SPI. I imagine this would work by letting a realm use a different source to validate credentials. A very crude auth SPI could look like:
>
>    public boolean isAuthenticated(String username, Credential... credentials) {
>    }
>
> Some auth providers could only work for some credentials. For example an LDAP could be used to verify the username/password, then Keycloak to verify TOTP, while roles and other user profile data retrieve from the Keycloak store.
>
> The same auth SPI could be used to add support for additional OTP mechanisms (email, smtp, yubikey, you name it).
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 27 January, 2014 5:12:48 PM
>> Subject: [keycloak-dev] can we get away with federating user/cred only?
>>
>> Can we get away with federating user and credentials only?  Only store
>> those in LDAP/AD?  Would sure make our lives a lot easier and this may
>> cover 80% of deployments that need it?
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Wed Jan 29 09:57:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Jan 2014 09:57:36 -0500
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
Message-ID: <52E916E0.5030504@redhat.com>

Honestly, I'd prefer to follow the same look and feel as EAP instead of 
creating our own.  We may eventually have to provide keycloak "portlets" 
that can plug into different mgmt consoles.

On 1/29/2014 9:44 AM, Gabriel Cardoso wrote:
>
> On Jan 29, 2014, at 12:34 PM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>> The login form looks really good!
> Thanks
>
>> I'm not convinced about the admin console though. The bright blue
>> isn't very nice. Also I was wondering if there's some way we could not
>> have a separate "bar" for the realm drop-down and add realm button.
>> Could we move this to the left-hand menu, or merge it with the logo /
>> user selection bar (and also make it slightly bigger at the same time)?
> Well, it is a matter of taste. But I can try to make it more attractive.
>
> Why you don?t want to have that nav bar? We have plenty of space and it
> is clear that this is the highter level of navigation.
>
> However, it doesn?t hurt trying to incorporate the dropdown and button
> into the sidebar. I?m just afraid this will make the navigation more
> confusing, but we can give a shot.
>
> Here is an example of something they did for EAP.
>
>
> I needed to think a bit to understand the hierarchy.
>
> Gabriel
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From crobson at redhat.com  Wed Jan 29 09:53:30 2014
From: crobson at redhat.com (Catherine Robson)
Date: Wed, 29 Jan 2014 09:53:30 -0500
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <DDB6AAC1-EF83-4319-B9E3-D8AFFD14A829@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<52E90F20.50100@redhat.com> <52E9110F.8060601@redhat.com>
	<DDB6AAC1-EF83-4319-B9E3-D8AFFD14A829@redhat.com>
Message-ID: <52E915EA.4000102@redhat.com>



Gabriel Cardoso wrote:
> We don?t need to follow their color scheme.
>
> I?ve sent the proposal for the console to her and she said it was fine.
+1

We encourage community projects to customize the colors to their project 
for the community version.
>
> Gabriel
>
> On Jan 29, 2014, at 12:32 PM, ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com> wrote:
>
>> On 1/29/2014 9:24 AM, Bill Burke wrote:
>>> I'm up for anything that looks professional.  Both look good to me.
>>> Should we follow color schemes/styles of the Wildfly admin console 
>>> though?
>> I think that's a question for Cathrine.
>>>
>>> On 1/29/2014 5:31 AM, Gabriel Cardoso wrote:
>>>> Hi,
>>>>
>>>> I?m working on the customization of Keycloak based on the new logo and
>>>> colors.
>>>>
>>>> Here is my proposal for the console:
>>>>
>>>>
>>>> What do you think?
>>>>
>>>> Gabriel
>>>>
>>>> ---
>>>> Gabriel Cardoso
>>>> User Experience Designer @ Red Hat
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/e1129df3/attachment.html 

From stian at redhat.com  Wed Jan 29 10:11:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Jan 2014 10:11:49 -0500 (EST)
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <52E916E0.5030504@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
	<52E916E0.5030504@redhat.com>
Message-ID: <448983909.15499874.1391008309824.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 January, 2014 2:57:36 PM
> Subject: Re: [keycloak-dev] Customization for Keycloak
> 
> Honestly, I'd prefer to follow the same look and feel as EAP instead of
> creating our own.  We may eventually have to provide keycloak "portlets"
> that can plug into different mgmt consoles.

We need to move to the official RCUE styles at some point. This will probably require some changes to html structure. Once we've done that it's easy to change the L&F from the Keycloak theme, to the WildFly theme and finally to the EAP theme.

Gabriel do you know where we can get RCUE from?

> 
> On 1/29/2014 9:44 AM, Gabriel Cardoso wrote:
> >
> > On Jan 29, 2014, at 12:34 PM, Stian Thorgersen <stian at redhat.com
> > <mailto:stian at redhat.com>> wrote:
> >
> >> The login form looks really good!
> > Thanks
> >
> >> I'm not convinced about the admin console though. The bright blue
> >> isn't very nice. Also I was wondering if there's some way we could not
> >> have a separate "bar" for the realm drop-down and add realm button.
> >> Could we move this to the left-hand menu, or merge it with the logo /
> >> user selection bar (and also make it slightly bigger at the same time)?
> > Well, it is a matter of taste. But I can try to make it more attractive.
> >
> > Why you don?t want to have that nav bar? We have plenty of space and it
> > is clear that this is the highter level of navigation.
> >
> > However, it doesn?t hurt trying to incorporate the dropdown and button
> > into the sidebar. I?m just afraid this will make the navigation more
> > confusing, but we can give a shot.
> >
> > Here is an example of something they did for EAP.
> >
> >
> > I needed to think a bit to understand the hierarchy.
> >
> > Gabriel
> >
> > ---
> > Gabriel Cardoso
> > User Experience Designer @ Red Hat
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From bburke at redhat.com  Wed Jan 29 11:03:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Jan 2014 11:03:54 -0500
Subject: [keycloak-dev] The Keycloak Vision/Core Values
Message-ID: <52E9266A.5070505@redhat.com>

Keycloak aims to provide the entire User Interface experience for your 
security needs so your applications don't have to.  UIs like "Forgot 
Password", "Lost Authenticator", registration pages, social login, 
update/reset password, and user account management can all be handled 
and customly styled by Keycloak so you don't have to implement these 
screens and features for each one of your web applications.

How's that sound?

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

From matzew at apache.org  Wed Jan 29 11:28:12 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 29 Jan 2014 17:28:12 +0100
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <52E9266A.5070505@redhat.com>
References: <52E9266A.5070505@redhat.com>
Message-ID: <CAAg5f2T7JWJ5jEq1tr6j7XV4mKWKo2ZF6Rr8wU3tnnR0kB9_Sg@mail.gmail.com>

On Wed, Jan 29, 2014 at 5:03 PM, Bill Burke <bburke at redhat.com> wrote:

> Keycloak aims to provide the entire User Interface experience for your
> security needs so your applications don't have to.  UIs like "Forgot
> Password", "Lost Authenticator", registration pages, social login,
> update/reset password, and user account management can all be handled
> and customly styled by Keycloak so you don't have to implement these
> screens and features for each one of your web applications.
>
> How's that sound?
>

+1 sounds good


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



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140129/d835d0d7/attachment.html 

From kpiwko at redhat.com  Thu Jan 30 03:53:45 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 30 Jan 2014 09:53:45 +0100
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
Message-ID: <20140130095345.2f02b639@kapy-ntb-x220>

Hi,

I've noticed that Keycloak Maven artifacts are not synced to Maven Central,
they are only on JBoss Nexus. Do you plan to sync them to Central?

Let me know if so, I can help with that.

Karel

From stian at redhat.com  Thu Jan 30 04:20:28 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 04:20:28 -0500 (EST)
Subject: [keycloak-dev] can we get away with federating user/cred only?
In-Reply-To: <52E91688.3050806@redhat.com>
References: <52E69390.6010102@redhat.com>
	<1280868395.15426987.1391003463622.JavaMail.root@redhat.com>
	<52E91688.3050806@redhat.com>
Message-ID: <1504352497.16224860.1391073628185.JavaMail.root@redhat.com>

If we could create a plugin mechanism to add UI bits specific to a SPI providers that'd be great.

Haven't thought about this to much, but something like:

* Social providers can provide instructions for configuration
* Authenticator providers can provide they're own UI screens for configuring
* TOTP providers can provide configuration instructions for account mngtm and login screens
* ...

All it needs is that an SPI can return a html fragment, and some way of making the UI pluggable. This is definitively something I'd be keen on looking at if I could find the time. Or maybe, just maybe, this could be another reason to move to UberFire (including the need to integrate into WildFly console some day)?

----- 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, 29 January, 2014 2:56:08 PM
> Subject: Re: [keycloak-dev] can we get away with federating user/cred only?
> 
> interface AuthenticatorDelegate {
> 
>     boolean isAuthenticated(UserModel user, Credential... credentials)
> throws UnsupportedCredentialType;
> 
>     void updateCredential(UserModel user, Credential oldCred, Credential
> newcred) throws UnsupportedCredentialType;
> 
> }
> 
> 
> I was thinking we'd offer a Picketlink IDM API one.  THe admin console
> would allow you to upload a PL config file through this SPI interface:
> 
> interface AuthenticatorDelegateFactory {
> 
>     Set<String> getSupportedCredentialTypes();
>     AuthenticatorDelegate create(MediaType mediaType, byte[] configBytes);
> 
> }
> 
> Or, alternatively we could put a nice UI on top of PL to configure LDAP.
> 
> 
> 
> 
> 
> On 1/29/2014 8:51 AM, Stian Thorgersen wrote:
> > When it comes to enterprises I think having multiple options to best
> > integrate into whatever ecosystem they already have in place.
> >
> > With that in mind, when possible I think syncing to/from LDAP would be
> > great. Keycloak store would in most cases provide more information than
> > the LDAP store in those cases. For example role mappings.
> >
> > If we design a sync SPI that would allow users to do their own to integrate
> > with whatever they currently have. Be it LDAP, a relational database, or
> > any other solutions. The SPI could have a read only, as well as a
> > read/write option.
> >
> > Also I think it makes sense to add support auth brokering. Again through an
> > auth SPI. I imagine this would work by letting a realm use a different
> > source to validate credentials. A very crude auth SPI could look like:
> >
> >    public boolean isAuthenticated(String username, Credential...
> >    credentials) {
> >    }
> >
> > Some auth providers could only work for some credentials. For example an
> > LDAP could be used to verify the username/password, then Keycloak to
> > verify TOTP, while roles and other user profile data retrieve from the
> > Keycloak store.
> >
> > The same auth SPI could be used to add support for additional OTP
> > mechanisms (email, smtp, yubikey, you name it).
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 27 January, 2014 5:12:48 PM
> >> Subject: [keycloak-dev] can we get away with federating user/cred only?
> >>
> >> Can we get away with federating user and credentials only?  Only store
> >> those in LDAP/AD?  Would sure make our lives a lot easier and this may
> >> cover 80% of deployments that need it?
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu Jan 30 04:32:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 04:32:34 -0500 (EST)
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <52E9266A.5070505@redhat.com>
References: <52E9266A.5070505@redhat.com>
Message-ID: <1535576528.16255880.1391074354778.JavaMail.root@redhat.com>

Sounds good. 

Theme support for login screens coming along nicely, just needs a bit of polish. Attached picture of a custom theme in action ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 January, 2014 4:03:54 PM
> Subject: [keycloak-dev] The Keycloak Vision/Core Values
> 
> Keycloak aims to provide the entire User Interface experience for your
> security needs so your applications don't have to.  UIs like "Forgot
> Password", "Lost Authenticator", registration pages, social login,
> update/reset password, and user account management can all be handled
> and customly styled by Keycloak so you don't have to implement these
> screens and features for each one of your web applications.
> 
> How's that sound?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: login-themes.jpg
Type: image/jpeg
Size: 112393 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/5488608b/attachment-0001.jpg 

From stian at redhat.com  Thu Jan 30 04:52:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 04:52:30 -0500 (EST)
Subject: [keycloak-dev] Device mgmt
In-Reply-To: <52E2953C.2010707@redhat.com>
References: <52E2953C.2010707@redhat.com>
Message-ID: <379955969.16262439.1391075550257.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 January, 2014 4:30:52 PM
> Subject: [keycloak-dev] Device mgmt
> 
> Here's my thoughts on device mgmt, both UI and protocol:
> 
> Scenario:
> 
> An iOS device as a "Brokerage App" installed.  The app needs to do REST
> invocations to be able to trade stocks, etc.  Devices must be registered
> in order to obtain permission.  Flow would look like this:
> 
> * User installs app on iPad.
> * User hits login button on app.
> * User is redirected to browser with a Keycloak server URL

Matt raised some issues around using a browser for OAuth2 and that Android may prevent it in the future. I wonder if we could somehow provide a more integrated experience than needing to use a browser. I don't really know much about app development on neither iOS or Android so don't know how feasible that is. 

> * User enters in credentials
> * User is redirected to "Device Registration" page.  Keycloak asks user
> if it authorizes access to the device.

Would it make sense to have this as an optional step? We could for example allow a device to automatically register when user logs in with his credentials, but the user would still be able to manage the device through account management later.

We could probably also the same mechanism for html5 applications. This would work the same way and the "device" (browser) would get a device token which is stored in localStorage (or cookie for older browsers if we're bothered about supporting them). This can also be used to provide https://issues.jboss.org/browse/KEYCLOAK-242 (Add remember machine option for two factor authentication).

> * Keycloak registers the device under the user and generates a device token
> * User is redirected back to iPad ap
> * iPad app gets auth code from redirect URL
> * iPad makes REST request to obtain auth token *AND* a device token.
> * iPad app stores the device token.
> 
> Next login is the same, except there is no "grant" page displayed. The
> iPad app uses the "device token" as a credential to turn an access code
> into an access token.  These are all extensions we'll need to make to
> the current OAuth protocol.
> 
> UI work:
> 
> The User Account Service will need a way to list registered devices so
> the user can see it and manage it (i.e. remove a registered device).
> 
> Admin Console should have a way to define a "Device Type".  The name,
> description and scope of the device type is defined.  "name" is used in
> the initial OAuth grant as a client_id identifier so that Keycloak knows
> what to display as a description in the
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jan 30 05:12:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 05:12:42 -0500 (EST)
Subject: [keycloak-dev] Storage protection
In-Reply-To: <52E68AA5.3000608@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E67B07.3060204@redhat.com>
	<52E68100.40501@redhat.com> <52E689A6.3070302@redhat.com>
	<52E68AA5.3000608@redhat.com>
Message-ID: <1261296816.16271260.1391076762034.JavaMail.root@redhat.com>

We should do it as an SPI to make it extensible. This would allow admins to integrate it best into how they manage sensitive data. I don't know what common practices are, but I imagine there are many ways to do it.

As I said before I think our options OOTB are either to just store in clear-text, or generate a master password and write to a known location (<keycloak>/standalone/data/realm.secret?). Anything more than that would make it hard to use for development.

I believe it is safer store a master password in a file (and an additional layer of defence to storing in clear-text to RDBMS, which can be compromised through SQL-injection attacks that non-shared file systems are not prone to).

The master password location can be configurable through a system property. Admins can place this file on an encrypted location, this would be recommended. I don't think its any better to provide the master password as a argument or system property at startup than it is to store it in a file on an encrypted drive. The reason being is that if someone gains admin access to the server, they will be able to read the file, sure, but they can also get the arguments used to start the server just as easily. If the server is turned of neither properties or an encrypted drive will help them. Admins already have mechanisms in place to manage encrypted drives on servers, so we'd rely on them to know how to do that themselves.

For future and more improved solutions we can add whatever mechanisms users are asking for through the SPI. Enterprises can also implement their own.

The SPI could be something as simple as:

public interface PrivateKeyProvider {
  public PEM getPrivateKey(RealmModel realm);
}

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 27 January, 2014 4:34:45 PM
> Subject: Re: [keycloak-dev] Storage protection
> 
> 
> 
> On 1/27/2014 11:30 AM, Anil Saldhana wrote:
> > But for development purposes, a DB may not be available as the default
> > mechanism.  In the case of WildFly AS, I am unsure if they ship with a
> > default DB
> > anymore.
> 
> Wildfly still has a DB, and we use it by default.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jan 30 05:20:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 05:20:55 -0500 (EST)
Subject: [keycloak-dev] new client type:  "server"
In-Reply-To: <52E692A6.4000807@redhat.com>
References: <52E692A6.4000807@redhat.com>
Message-ID: <1833740953.16275407.1391077255151.JavaMail.root@redhat.com>

I think it's a good idea to split the notion of client and application/service. Not sure I quite understand exactly what you are proposing would look like though.

We should gather requirements around "re-structuring" the model, and try to cover all basis. Some things to consider:

* WildFly (JavaEE deployments specifically) - how to best integrate with WildFly and JavaEE deployments
* non-JavaEE containers - can we provide a similar experience on non-JavaEE containers (LiveOak, Vert.x, etc.)
* Client types - service, html5, mobile, desktop
* Devices - phones, browsers, servers, computers
* Applications - resources that are accessed, so they don't need credentials. They don't have redirect uris, these should be associated with a client I think

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 27 January, 2014 5:08:54 PM
> Subject: [keycloak-dev] new client type:  "server"
> 
> Stan's work on the Wildfly subsystem got me thinking about how we might
> want to reorganize keycloak.  Since multiple applications may often be
> deployed on the same server, what if we split the notion of Application
> and client?  Application would be a place to define application roles
> and application scope only.  A server can be associated with multiple
> applications.
> 
> For config/bootstrapping, the user would specify a server in the admin
> console and set up trust between the two.  Then the user could import
> deployments from a server and associate them with a realm and even
> download the the roles of each of these deployments and create
> Applications from them.  For OAuth tokens, server would specify the
> server's client_id as well as a scope.  The scope would be the
> Application the server is asking a token for.
> 
> So, a server would have:
> 
> * a client_id
> * credentials
> * admin URL
> * be associated with one or more Applications
> 
> Application would have:
> * roles
> * valid redirect urls  (which are associated with a server)
> * scope
> * sessions (view who's logged in where into what server)
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jan 30 05:22:07 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 05:22:07 -0500 (EST)
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <20140130095345.2f02b639@kapy-ntb-x220>
References: <20140130095345.2f02b639@kapy-ntb-x220>
Message-ID: <716351205.16276132.1391077327802.JavaMail.root@redhat.com>

That'd be great

----- Original Message -----
> From: "Karel Piwko" <kpiwko at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 8:53:45 AM
> Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
> 
> Hi,
> 
> I've noticed that Keycloak Maven artifacts are not synced to Maven Central,
> they are only on JBoss Nexus. Do you plan to sync them to Central?
> 
> Let me know if so, I can help with that.
> 
> Karel
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From kpiwko at redhat.com  Thu Jan 30 08:13:57 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 30 Jan 2014 14:13:57 +0100
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <716351205.16276132.1391077327802.JavaMail.root@redhat.com>
References: <20140130095345.2f02b639@kapy-ntb-x220>
	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
Message-ID: <20140130141357.4b609bf8@kapy-ntb-x220>

I did some checks and there is some work needed:

1/ According to Maven Central rules, there should not be any <repository>
elements in pom.xml files
2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
available no Maven Central

So, following steps are needed:

* figure out whether jbossweb dependency could be replaced by something else,
  if not - it has to undergo same checks as keycloak and be synced to Maven
  Central or, which I prefer, to release it relocated to org.keycloak groupId.
  Given that 7.0.17.Final has do external dependencies at all -
  seems much easier then trying to convince sonatype to pick a single version
  of jbossweb tree
* remove all <repositories> from pom.xml files

Then, 1.0-alpha-2 and further releases can be synced to Maven Central. Sonatype
might apply more rules but project looks in good shape Maven-wise IMO.

Karel

On Thu, 30 Jan 2014 05:22:07 -0500 (EST)
Stian Thorgersen <stian at redhat.com> wrote:

> That'd be great
> 
> ----- Original Message -----
> > From: "Karel Piwko" <kpiwko at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 30 January, 2014 8:53:45 AM
> > Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
> > 
> > Hi,
> > 
> > I've noticed that Keycloak Maven artifacts are not synced to Maven Central,
> > they are only on JBoss Nexus. Do you plan to sync them to Central?
> > 
> > Let me know if so, I can help with that.
> > 
> > Karel
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 


From bburke at redhat.com  Thu Jan 30 08:20:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 08:20:15 -0500
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <20140130095345.2f02b639@kapy-ntb-x220>
References: <20140130095345.2f02b639@kapy-ntb-x220>
Message-ID: <52EA518F.9000003@redhat.com>

I don't know how to do that actually...I thought it was something Nexus 
did automatically.

On 1/30/2014 3:53 AM, Karel Piwko wrote:
> Hi,
>
> I've noticed that Keycloak Maven artifacts are not synced to Maven Central,
> they are only on JBoss Nexus. Do you plan to sync them to Central?
>
> Let me know if so, I can help with that.
>
> Karel
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bruno at abstractj.org  Thu Jan 30 08:22:35 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 30 Jan 2014 11:22:35 -0200
Subject: [keycloak-dev] Storage protection
In-Reply-To: <1261296816.16271260.1391076762034.JavaMail.root@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla>
	<52E67B07.3060204@redhat.com> <52E68100.40501@redhat.com>
	<52E689A6.3070302@redhat.com> <52E68AA5.3000608@redhat.com>
	<1261296816.16271260.1391076762034.JavaMail.root@redhat.com>
Message-ID: <etPan.52ea521b.41b71efb.a5ca@tesla>

I think that?s just fine, where developers will store their private keys is their decision: db, text file or fancy hardwares.

My only suggestion is to generate these keys with some KDF function, maybe during the first application setup? What do you have in mind Stian? command line, web interface, integrate with jboss-cli?

--  
abstractj

On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian at redhat.com) wrote:
> > We should do it as an SPI to make it extensible. This would allow  
> admins to integrate it best into how they manage sensitive data.  
> I don't know what common practices are, but I imagine there are  
> many ways to do it.
>  
> As I said before I think our options OOTB are either to just store  
> in clear-text, or generate a master password and write to a known  
> location (/standalone/data/realm.secret?).  
> Anything more than that would make it hard to use for development.  
>  
> I believe it is safer store a master password in a file (and an additional  
> layer of defence to storing in clear-text to RDBMS, which can  
> be compromised through SQL-injection attacks that non-shared  
> file systems are not prone to).
>  
> The master password location can be configurable through a system  
> property. Admins can place this file on an encrypted location,  
> this would be recommended. I don't think its any better to provide  
> the master password as a argument or system property at startup  
> than it is to store it in a file on an encrypted drive. The reason  
> being is that if someone gains admin access to the server, they  
> will be able to read the file, sure, but they can also get the arguments  
> used to start the server just as easily. If the server is turned  
> of neither properties or an encrypted drive will help them. Admins  
> already have mechanisms in place to manage encrypted drives  
> on servers, so we'd rely on them to know how to do that themselves.  
>  
> For future and more improved solutions we can add whatever mechanisms  
> users are asking for through the SPI. Enterprises can also implement  
> their own.
>  
> The SPI could be something as simple as:
>  
> public interface PrivateKeyProvider {
> public PEM getPrivateKey(RealmModel realm);
> }



From matzew at apache.org  Thu Jan 30 08:30:24 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 30 Jan 2014 14:30:24 +0100
Subject: [keycloak-dev] Keycloak Integration Options (with UnifiedPush
	Server)
Message-ID: <CAAg5f2SaRUsosMdO8aPS4pX9nHJ2DpoKTjoPN2CrYkLCtEyzEA@mail.gmail.com>

Hello there!


For the AeroGear UnifiedPush Server Bruno and I started looking at Keycloak
([1]). On this branch, we basically include the adapater jar and a
keycloak.json file and simply rely on Keycloak as an external service (e.g.
as different WAR inside of the same containter). That works very well so
far!!
However, here I have to create a realm in the server (either via
Admin-Console or by including it via something like 'myRealm.json') and
afterwards I have to 'hard-code' the public key into my own WAR file
(keycloak.jso):

https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/keycloak.json#L3

So this would be a little bit of a negative effect;



Another option would be embedding the Keycloak JARs into my own WAR file,
by adding all the dependent JARs, similiar to what the 'keycloak-server'
does ([2]). At the end I'd have an uber WAR file, containing UPS and
Keycloak facilities. However, I think the 'problem' w/ the 'hard-code' key
inside of the keycloak.json would be there as well, right ?



On the IRC channel Stian mentioned that there will be a WildFly subsystem
soon. I think, from what I hear, the real benefit of this subsystem are the
following items:

* configuring realms through standalone.xml
* automatically sets up security for wars (using the wildfly adapter)

So, this option seems to let us avoid the above described keycloak.json
'issue', right ?

For a future integration w/ the Keycloak SSO server, I could leverage the
Subsystem deliverables and bundle them w/ our own UnifiedPush Server
distribution, to ensure things are running out of the box; Or is the
subsystem not the best option for a Push/Keycloak integration ?



-Matthias


[1] https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak
[2] https://github.com/keycloak/keycloak/blob/master/server/pom.xml

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/e42927b7/attachment-0001.html 

From bburke at redhat.com  Thu Jan 30 08:37:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 08:37:47 -0500
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <20140130141357.4b609bf8@kapy-ntb-x220>
References: <20140130095345.2f02b639@kapy-ntb-x220>	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
	<20140130141357.4b609bf8@kapy-ntb-x220>
Message-ID: <52EA55AB.1030707@redhat.com>



On 1/30/2014 8:13 AM, Karel Piwko wrote:
> I did some checks and there is some work needed:
>
> 1/ According to Maven Central rules, there should not be any <repository>
> elements in pom.xml files


> 2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
> available no Maven Central
>
> So, following steps are needed:
>
> * figure out whether jbossweb dependency could be replaced by something else,
>    if not - it has to undergo same checks as keycloak and be synced to Maven
>    Central or, which I prefer, to release it relocated to org.keycloak groupId.
>    Given that 7.0.17.Final has do external dependencies at all -
>    seems much easier then trying to convince sonatype to pick a single version
>    of jbossweb tree
> * remove all <repositories> from pom.xml files
>

Would hosting at Maven Central require developers to configure their 
settings.xml, or can the build still run OOTB?  A build running OOTB is 
more important than hosting at Maven Central.

Also, what is the performance of Maven Central compared to 
repository.jboss.org?  I've often had slow as balls connections to Maven 
Central and never any problems with repository.jboss.org.  Finally, 
nobody has ever complained that Resteasy is not at Maven central. 
People have no problems using repository.jboss.org so I don't see what 
the big deal is.


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

From stian at redhat.com  Thu Jan 30 08:45:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 08:45:20 -0500 (EST)
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <52EA55AB.1030707@redhat.com>
References: <20140130095345.2f02b639@kapy-ntb-x220>
	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
	<20140130141357.4b609bf8@kapy-ntb-x220>
	<52EA55AB.1030707@redhat.com>
Message-ID: <1148398873.16398621.1391089520382.JavaMail.root@redhat.com>

Hosting on Maven Central means that folks can use Keycloak artifaces without having to add JBoss Nexus to their poms. So IMO it makes it slightly simpler to add Keycloak deps.

RestEasy is on Maven Central (http://search.maven.org/#search%7Cga%7C1%7Cresteasy) ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 1:37:47 PM
> Subject: Re: [keycloak-dev] Keycloak artifacts not in Maven Central
> 
> 
> 
> On 1/30/2014 8:13 AM, Karel Piwko wrote:
> > I did some checks and there is some work needed:
> >
> > 1/ According to Maven Central rules, there should not be any <repository>
> > elements in pom.xml files
> 
> 
> > 2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
> > available no Maven Central
> >
> > So, following steps are needed:
> >
> > * figure out whether jbossweb dependency could be replaced by something
> > else,
> >    if not - it has to undergo same checks as keycloak and be synced to
> >    Maven
> >    Central or, which I prefer, to release it relocated to org.keycloak
> >    groupId.
> >    Given that 7.0.17.Final has do external dependencies at all -
> >    seems much easier then trying to convince sonatype to pick a single
> >    version
> >    of jbossweb tree
> > * remove all <repositories> from pom.xml files
> >
> 
> Would hosting at Maven Central require developers to configure their
> settings.xml, or can the build still run OOTB?  A build running OOTB is
> more important than hosting at Maven Central.
> 
> Also, what is the performance of Maven Central compared to
> repository.jboss.org?  I've often had slow as balls connections to Maven
> Central and never any problems with repository.jboss.org.  Finally,
> nobody has ever complained that Resteasy is not at Maven central.
> People have no problems using repository.jboss.org so I don't see what
> the big deal is.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Jan 30 08:45:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 08:45:35 -0500
Subject: [keycloak-dev] Keycloak Integration Options (with UnifiedPush
 Server)
In-Reply-To: <CAAg5f2SaRUsosMdO8aPS4pX9nHJ2DpoKTjoPN2CrYkLCtEyzEA@mail.gmail.com>
References: <CAAg5f2SaRUsosMdO8aPS4pX9nHJ2DpoKTjoPN2CrYkLCtEyzEA@mail.gmail.com>
Message-ID: <52EA577F.2000705@redhat.com>

The admin console has a REST API that you can use directly to configure 
your realm and applications if you need.

Without a Wildfly subsystem, keycloak.json is required to get the public 
key and your client credentials.

The wildfly subsystem will remove the need for cracking open a WAR.  The 
initial implementation may be a little clumsy at first, but I think 
there's a huge amount we can do to make it real easy to use.



On 1/30/2014 8:30 AM, Matthias Wessendorf wrote:
> Hello there!
>
>
> For the AeroGear UnifiedPush Server Bruno and I started looking at
> Keycloak ([1]). On this branch, we basically include the adapater jar
> and a keycloak.json file and simply rely on Keycloak as an external
> service (e.g. as different WAR inside of the same containter). That
> works very well so far!!
> However, here I have to create a realm in the server (either via
> Admin-Console or by including it via something like 'myRealm.json') and
> afterwards I have to 'hard-code' the public key into my own WAR file
> (keycloak.jso):
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/keycloak.json#L3
>
> So this would be a little bit of a negative effect;
>
>
>
> Another option would be embedding the Keycloak JARs into my own WAR
> file, by adding all the dependent JARs, similiar to what the
> 'keycloak-server' does ([2]). At the end I'd have an uber WAR file,
> containing UPS and Keycloak facilities. However, I think the 'problem'
> w/ the 'hard-code' key inside of the keycloak.json would be there as
> well, right ?
>
>
>
> On the IRC channel Stian mentioned that there will be a WildFly
> subsystem soon. I think, from what I hear, the real benefit of this
> subsystem are the following items:
>
> * configuring realms through standalone.xml
> * automatically sets up security for wars (using the wildfly adapter)
>
> So, this option seems to let us avoid the above described keycloak.json
> 'issue', right ?
>
> For a future integration w/ the Keycloak SSO server, I could leverage
> the Subsystem deliverables and bundle them w/ our own UnifiedPush Server
> distribution, to ensure things are running out of the box; Or is the
> subsystem not the best option for a Push/Keycloak integration ?
>
>
>
> -Matthias
>
>
> [1] https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak
> [2] https://github.com/keycloak/keycloak/blob/master/server/pom.xml
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Thu Jan 30 08:47:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 08:47:36 -0500
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <1148398873.16398621.1391089520382.JavaMail.root@redhat.com>
References: <20140130095345.2f02b639@kapy-ntb-x220>
	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
	<20140130141357.4b609bf8@kapy-ntb-x220>
	<52EA55AB.1030707@redhat.com>
	<1148398873.16398621.1391089520382.JavaMail.root@redhat.com>
Message-ID: <52EA57F8.6070705@redhat.com>



On 1/30/2014 8:45 AM, Stian Thorgersen wrote:
> Hosting on Maven Central means that folks can use Keycloak artifaces without having to add JBoss Nexus to their poms. So IMO it makes it slightly simpler to add Keycloak deps.
>
> RestEasy is on Maven Central (http://search.maven.org/#search%7Cga%7C1%7Cresteasy) ;)
>

???  It has the same pom and dependency issues as keycloak!

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

From matzew at apache.org  Thu Jan 30 08:49:42 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 30 Jan 2014 14:49:42 +0100
Subject: [keycloak-dev] Keycloak Integration Options (with UnifiedPush
	Server)
In-Reply-To: <52EA577F.2000705@redhat.com>
References: <CAAg5f2SaRUsosMdO8aPS4pX9nHJ2DpoKTjoPN2CrYkLCtEyzEA@mail.gmail.com>
	<52EA577F.2000705@redhat.com>
Message-ID: <CAAg5f2R0E+oUJe1=RnBBWmSbNOOiWXbBuXraiseLvMaiuSRB3w@mail.gmail.com>

On Thu, Jan 30, 2014 at 2:45 PM, Bill Burke <bburke at redhat.com> wrote:

> The admin console has a REST API that you can use directly to configure
> your realm and applications if you need.
>
> Without a Wildfly subsystem, keycloak.json is required to get the public
> key and your client credentials.
>
> The wildfly subsystem will remove the need for cracking open a WAR.  The
> initial implementation may be a little clumsy at first, but I think
> there's a huge amount we can do to make it real easy to use.
>

that (wildfly subsystem) pretty much sounds like what we would want to use
for an integration of the UnifiedPush Server and Keycloak.

I don't care that much if it is a bit clumsy at first, since we can always
improve it later; Most benefit of using the subsystem, for us, will be
getting rid of the keycloak.json requirement

-Matthias



>
>
>
> On 1/30/2014 8:30 AM, Matthias Wessendorf wrote:
> > Hello there!
> >
> >
> > For the AeroGear UnifiedPush Server Bruno and I started looking at
> > Keycloak ([1]). On this branch, we basically include the adapater jar
> > and a keycloak.json file and simply rely on Keycloak as an external
> > service (e.g. as different WAR inside of the same containter). That
> > works very well so far!!
> > However, here I have to create a realm in the server (either via
> > Admin-Console or by including it via something like 'myRealm.json') and
> > afterwards I have to 'hard-code' the public key into my own WAR file
> > (keycloak.jso):
> >
> >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/keycloak.json#L3
> >
> > So this would be a little bit of a negative effect;
> >
> >
> >
> > Another option would be embedding the Keycloak JARs into my own WAR
> > file, by adding all the dependent JARs, similiar to what the
> > 'keycloak-server' does ([2]). At the end I'd have an uber WAR file,
> > containing UPS and Keycloak facilities. However, I think the 'problem'
> > w/ the 'hard-code' key inside of the keycloak.json would be there as
> > well, right ?
> >
> >
> >
> > On the IRC channel Stian mentioned that there will be a WildFly
> > subsystem soon. I think, from what I hear, the real benefit of this
> > subsystem are the following items:
> >
> > * configuring realms through standalone.xml
> > * automatically sets up security for wars (using the wildfly adapter)
> >
> > So, this option seems to let us avoid the above described keycloak.json
> > 'issue', right ?
> >
> > For a future integration w/ the Keycloak SSO server, I could leverage
> > the Subsystem deliverables and bundle them w/ our own UnifiedPush Server
> > distribution, to ensure things are running out of the box; Or is the
> > subsystem not the best option for a Push/Keycloak integration ?
> >
> >
> >
> > -Matthias
> >
> >
> > [1]
> https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak
> > [2] https://github.com/keycloak/keycloak/blob/master/server/pom.xml
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/4c08db40/attachment.html 

From stian at redhat.com  Thu Jan 30 08:51:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 08:51:08 -0500 (EST)
Subject: [keycloak-dev] Storage protection
In-Reply-To: <etPan.52ea521b.41b71efb.a5ca@tesla>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E67B07.3060204@redhat.com>
	<52E68100.40501@redhat.com> <52E689A6.3070302@redhat.com>
	<52E68AA5.3000608@redhat.com>
	<1261296816.16271260.1391076762034.JavaMail.root@redhat.com>
	<etPan.52ea521b.41b71efb.a5ca@tesla>
Message-ID: <50838457.16401730.1391089868237.JavaMail.root@redhat.com>

BTW the interface I proposed wouldn't work with a HSM, they do the encryption/decryption on board don't they? So it would be something like:

public EncryptionProvider {

  public void generateKeys(RealmModel realm);

  public byte[] encrypt(byte[] b);

  public byte[] decrypt(byte[] b);

  public byte[] sign(byte[] b);

}

or something along those lines ;)

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 1:22:35 PM
> Subject: Re: [keycloak-dev] Storage protection
> 
> I think that?s just fine, where developers will store their private keys is
> their decision: db, text file or fancy hardwares.
> 
> My only suggestion is to generate these keys with some KDF function, maybe
> during the first application setup? What do you have in mind Stian? command
> line, web interface, integrate with jboss-cli?

First app startup I'd say. OOTB experience should be as simple as possible. Probably just bootstrap it in: https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java

and set the location to ${jboss.config.dir}/keycloak.secret or something?

> 
> --
> abstractj
> 
> On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian at redhat.com) wrote:
> > > We should do it as an SPI to make it extensible. This would allow
> > admins to integrate it best into how they manage sensitive data.
> > I don't know what common practices are, but I imagine there are
> > many ways to do it.
> >  
> > As I said before I think our options OOTB are either to just store
> > in clear-text, or generate a master password and write to a known
> > location (/standalone/data/realm.secret?).
> > Anything more than that would make it hard to use for development.
> >  
> > I believe it is safer store a master password in a file (and an additional
> > layer of defence to storing in clear-text to RDBMS, which can
> > be compromised through SQL-injection attacks that non-shared
> > file systems are not prone to).
> >  
> > The master password location can be configurable through a system
> > property. Admins can place this file on an encrypted location,
> > this would be recommended. I don't think its any better to provide
> > the master password as a argument or system property at startup
> > than it is to store it in a file on an encrypted drive. The reason
> > being is that if someone gains admin access to the server, they
> > will be able to read the file, sure, but they can also get the arguments
> > used to start the server just as easily. If the server is turned
> > of neither properties or an encrypted drive will help them. Admins
> > already have mechanisms in place to manage encrypted drives
> > on servers, so we'd rely on them to know how to do that themselves.
> >  
> > For future and more improved solutions we can add whatever mechanisms
> > users are asking for through the SPI. Enterprises can also implement
> > their own.
> >  
> > The SPI could be something as simple as:
> >  
> > public interface PrivateKeyProvider {
> > public PEM getPrivateKey(RealmModel realm);
> > }
> 
>


From bburke at redhat.com  Thu Jan 30 09:00:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 09:00:33 -0500
Subject: [keycloak-dev] Storage protection
In-Reply-To: <50838457.16401730.1391089868237.JavaMail.root@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E67B07.3060204@redhat.com>
	<52E68100.40501@redhat.com> <52E689A6.3070302@redhat.com>
	<52E68AA5.3000608@redhat.com>
	<1261296816.16271260.1391076762034.JavaMail.root@redhat.com>
	<etPan.52ea521b.41b71efb.a5ca@tesla>
	<50838457.16401730.1391089868237.JavaMail.root@redhat.com>
Message-ID: <52EA5B01.2090207@redhat.com>

I don't think this relates, but just in case...tokens need to be signed 
by a known algorithm so clients are able to verify them.

On 1/30/2014 8:51 AM, Stian Thorgersen wrote:
> BTW the interface I proposed wouldn't work with a HSM, they do the encryption/decryption on board don't they? So it would be something like:
>
> public EncryptionProvider {
>
>    public void generateKeys(RealmModel realm);
>
>    public byte[] encrypt(byte[] b);
>
>    public byte[] decrypt(byte[] b);
>
>    public byte[] sign(byte[] b);
>
> }
>
> or something along those lines ;)
>
> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno at abstractj.org>
>> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 30 January, 2014 1:22:35 PM
>> Subject: Re: [keycloak-dev] Storage protection
>>
>> I think that?s just fine, where developers will store their private keys is
>> their decision: db, text file or fancy hardwares.
>>
>> My only suggestion is to generate these keys with some KDF function, maybe
>> during the first application setup? What do you have in mind Stian? command
>> line, web interface, integrate with jboss-cli?
>
> First app startup I'd say. OOTB experience should be as simple as possible. Probably just bootstrap it in: https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java
>
> and set the location to ${jboss.config.dir}/keycloak.secret or something?
>
>>
>> --
>> abstractj
>>
>> On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian at redhat.com) wrote:
>>>> We should do it as an SPI to make it extensible. This would allow
>>> admins to integrate it best into how they manage sensitive data.
>>> I don't know what common practices are, but I imagine there are
>>> many ways to do it.
>>>
>>> As I said before I think our options OOTB are either to just store
>>> in clear-text, or generate a master password and write to a known
>>> location (/standalone/data/realm.secret?).
>>> Anything more than that would make it hard to use for development.
>>>
>>> I believe it is safer store a master password in a file (and an additional
>>> layer of defence to storing in clear-text to RDBMS, which can
>>> be compromised through SQL-injection attacks that non-shared
>>> file systems are not prone to).
>>>
>>> The master password location can be configurable through a system
>>> property. Admins can place this file on an encrypted location,
>>> this would be recommended. I don't think its any better to provide
>>> the master password as a argument or system property at startup
>>> than it is to store it in a file on an encrypted drive. The reason
>>> being is that if someone gains admin access to the server, they
>>> will be able to read the file, sure, but they can also get the arguments
>>> used to start the server just as easily. If the server is turned
>>> of neither properties or an encrypted drive will help them. Admins
>>> already have mechanisms in place to manage encrypted drives
>>> on servers, so we'd rely on them to know how to do that themselves.
>>>
>>> For future and more improved solutions we can add whatever mechanisms
>>> users are asking for through the SPI. Enterprises can also implement
>>> their own.
>>>
>>> The SPI could be something as simple as:
>>>
>>> public interface PrivateKeyProvider {
>>> public PEM getPrivateKey(RealmModel realm);
>>> }
>>
>>

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

From bruno at abstractj.org  Thu Jan 30 09:01:45 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 30 Jan 2014 12:01:45 -0200
Subject: [keycloak-dev] Storage protection
In-Reply-To: <50838457.16401730.1391089868237.JavaMail.root@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E67B07.3060204@redhat.com>
	<52E68100.40501@redhat.com> <52E689A6.3070302@redhat.com>
	<52E68AA5.3000608@redhat.com>
	<1261296816.16271260.1391076762034.JavaMail.root@redhat.com>
	<etPan.52ea521b.41b71efb.a5ca@tesla>
	<50838457.16401730.1391089868237.JavaMail.root@redhat.com>
Message-ID: <CAM5SUC7_k9Y1pR00b443+xKrOh9vksKcqk7DaDt6nxO0FuQmqA@mail.gmail.com>

Sorry if my e-mail gave to you a wrong impression. I was just asking about
the interface to generate the secret.


On Thu, Jan 30, 2014 at 11:51 AM, Stian Thorgersen <stian at redhat.com> wrote:

> BTW the interface I proposed wouldn't work with a HSM, they do the
> encryption/decryption on board don't they? So it would be something like:
>
> public EncryptionProvider {
>
>   public void generateKeys(RealmModel realm);
>
>   public byte[] encrypt(byte[] b);
>
>   public byte[] decrypt(byte[] b);
>
>   public byte[] sign(byte[] b);
>
> }
>
> or something along those lines ;)
>
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org>
> > To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <
> stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 30 January, 2014 1:22:35 PM
> > Subject: Re: [keycloak-dev] Storage protection
> >
> > I think that's just fine, where developers will store their private keys
> is
> > their decision: db, text file or fancy hardwares.
> >
> > My only suggestion is to generate these keys with some KDF function,
> maybe
> > during the first application setup? What do you have in mind Stian?
> command
> > line, web interface, integrate with jboss-cli?
>
> First app startup I'd say. OOTB experience should be as simple as
> possible. Probably just bootstrap it in:
> https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java
>
> and set the location to ${jboss.config.dir}/keycloak.secret or something?
>
> >
> > --
> > abstractj
> >
> > On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian at redhat.com)
> wrote:
> > > > We should do it as an SPI to make it extensible. This would allow
> > > admins to integrate it best into how they manage sensitive data.
> > > I don't know what common practices are, but I imagine there are
> > > many ways to do it.
> > >
> > > As I said before I think our options OOTB are either to just store
> > > in clear-text, or generate a master password and write to a known
> > > location (/standalone/data/realm.secret?).
> > > Anything more than that would make it hard to use for development.
> > >
> > > I believe it is safer store a master password in a file (and an
> additional
> > > layer of defence to storing in clear-text to RDBMS, which can
> > > be compromised through SQL-injection attacks that non-shared
> > > file systems are not prone to).
> > >
> > > The master password location can be configurable through a system
> > > property. Admins can place this file on an encrypted location,
> > > this would be recommended. I don't think its any better to provide
> > > the master password as a argument or system property at startup
> > > than it is to store it in a file on an encrypted drive. The reason
> > > being is that if someone gains admin access to the server, they
> > > will be able to read the file, sure, but they can also get the
> arguments
> > > used to start the server just as easily. If the server is turned
> > > of neither properties or an encrypted drive will help them. Admins
> > > already have mechanisms in place to manage encrypted drives
> > > on servers, so we'd rely on them to know how to do that themselves.
> > >
> > > For future and more improved solutions we can add whatever mechanisms
> > > users are asking for through the SPI. Enterprises can also implement
> > > their own.
> > >
> > > The SPI could be something as simple as:
> > >
> > > public interface PrivateKeyProvider {
> > > public PEM getPrivateKey(RealmModel realm);
> > > }
> >
> >
>



-- 

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/6c022941/attachment.html 

From kpiwko at redhat.com  Thu Jan 30 09:30:30 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 30 Jan 2014 15:30:30 +0100
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <1148398873.16398621.1391089520382.JavaMail.root@redhat.com>
References: <20140130095345.2f02b639@kapy-ntb-x220>
	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
	<20140130141357.4b609bf8@kapy-ntb-x220>
	<52EA55AB.1030707@redhat.com>
	<1148398873.16398621.1391089520382.JavaMail.root@redhat.com>
Message-ID: <20140130153030.27288681@kapy-ntb-x220>

Correct, Maven Central is even simpler to use. Works ootb, no mangling with
settings.xml is required at all.

I asked for pushing RESTEasy to Maven Central in Nov 2011, needed for EAP6/WFK2.
There was the same clean up of pom.xml(s) back then.

Performance wise, I have no idea. I'm not experiencing any difference at all. If
you experience connection lags, you can always mirror Maven Central to a
different repo, such as JBoss Nexus -
http://maven.apache.org/guides/mini/guide-mirror-settings.html.

Karel

On Thu, 30 Jan 2014 08:45:20 -0500 (EST)
Stian Thorgersen <stian at redhat.com> wrote:

> Hosting on Maven Central means that folks can use Keycloak artifaces without
> having to add JBoss Nexus to their poms. So IMO it makes it slightly simpler
> to add Keycloak deps.
> 
> RestEasy is on Maven Central
> (http://search.maven.org/#search%7Cga%7C1%7Cresteasy) ;)
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 30 January, 2014 1:37:47 PM
> > Subject: Re: [keycloak-dev] Keycloak artifacts not in Maven Central
> > 
> > 
> > 
> > On 1/30/2014 8:13 AM, Karel Piwko wrote:
> > > I did some checks and there is some work needed:
> > >
> > > 1/ According to Maven Central rules, there should not be any <repository>
> > > elements in pom.xml files
> > 
> > 
> > > 2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
> > > available no Maven Central
> > >
> > > So, following steps are needed:
> > >
> > > * figure out whether jbossweb dependency could be replaced by something
> > > else,
> > >    if not - it has to undergo same checks as keycloak and be synced to
> > >    Maven
> > >    Central or, which I prefer, to release it relocated to org.keycloak
> > >    groupId.
> > >    Given that 7.0.17.Final has do external dependencies at all -
> > >    seems much easier then trying to convince sonatype to pick a single
> > >    version
> > >    of jbossweb tree
> > > * remove all <repositories> from pom.xml files
> > >
> > 
> > Would hosting at Maven Central require developers to configure their
> > settings.xml, or can the build still run OOTB?  A build running OOTB is
> > more important than hosting at Maven Central.
> > 
> > Also, what is the performance of Maven Central compared to
> > repository.jboss.org?  I've often had slow as balls connections to Maven
> > Central and never any problems with repository.jboss.org.  Finally,
> > nobody has ever complained that Resteasy is not at Maven central.
> > People have no problems using repository.jboss.org so I don't see what
> > the big deal is.
> > 
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > 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


From gcardoso at redhat.com  Thu Jan 30 09:37:33 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 12:37:33 -0200
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <448983909.15499874.1391008309824.JavaMail.root@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
	<52E916E0.5030504@redhat.com>
	<448983909.15499874.1391008309824.JavaMail.root@redhat.com>
Message-ID: <4005C334-5123-4768-A655-93B05B16AE63@redhat.com>

Bill, RCUE is for projects, so we need some customization to differentiate the project. Viliam could make the changes to use the new design. Let?s go for it?

Stian, they have some material at http://rcue-uxd.itos.redhat.com

Gabriel

On Jan 29, 2014, at 1:11 PM, Stian Thorgersen <stian at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 29 January, 2014 2:57:36 PM
>> Subject: Re: [keycloak-dev] Customization for Keycloak
>> 
>> Honestly, I'd prefer to follow the same look and feel as EAP instead of
>> creating our own.  We may eventually have to provide keycloak "portlets"
>> that can plug into different mgmt consoles.
> 
> We need to move to the official RCUE styles at some point. This will probably require some changes to html structure. Once we've done that it's easy to change the L&F from the Keycloak theme, to the WildFly theme and finally to the EAP theme.
> 
> Gabriel do you know where we can get RCUE from?
> 
>> 
>> On 1/29/2014 9:44 AM, Gabriel Cardoso wrote:
>>> 
>>> On Jan 29, 2014, at 12:34 PM, Stian Thorgersen <stian at redhat.com
>>> <mailto:stian at redhat.com>> wrote:
>>> 
>>>> The login form looks really good!
>>> Thanks
>>> 
>>>> I'm not convinced about the admin console though. The bright blue
>>>> isn't very nice. Also I was wondering if there's some way we could not
>>>> have a separate "bar" for the realm drop-down and add realm button.
>>>> Could we move this to the left-hand menu, or merge it with the logo /
>>>> user selection bar (and also make it slightly bigger at the same time)?
>>> Well, it is a matter of taste. But I can try to make it more attractive.
>>> 
>>> Why you don?t want to have that nav bar? We have plenty of space and it
>>> is clear that this is the highter level of navigation.
>>> 
>>> However, it doesn?t hurt trying to incorporate the dropdown and button
>>> into the sidebar. I?m just afraid this will make the navigation more
>>> confusing, but we can give a shot.
>>> 
>>> Here is an example of something they did for EAP.
>>> 
>>> 
>>> I needed to think a bit to understand the hierarchy.
>>> 
>>> Gabriel
>>> 
>>> ---
>>> Gabriel Cardoso
>>> User Experience Designer @ Red Hat
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> 
>> 
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> 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

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/2bac05df/attachment-0001.html 

From stian at redhat.com  Thu Jan 30 04:30:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 04:30:54 -0500 (EST)
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <52E9266A.5070505@redhat.com>
References: <52E9266A.5070505@redhat.com>
Message-ID: <1885862109.16255352.1391074254067.JavaMail.root@redhat.com>

Sounds good. 

Theme support for login screens coming along nicely, just needs a bit of polish. Attached picture of a custom theme in action ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 January, 2014 4:03:54 PM
> Subject: [keycloak-dev] The Keycloak Vision/Core Values
> 
> Keycloak aims to provide the entire User Interface experience for your
> security needs so your applications don't have to.  UIs like "Forgot
> Password", "Lost Authenticator", registration pages, social login,
> update/reset password, and user account management can all be handled
> and customly styled by Keycloak so you don't have to implement these
> screens and features for each one of your web applications.
> 
> How's that sound?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: login-themes.png
Type: image/png
Size: 1054845 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/de8d59d3/attachment-0001.png 

From bburke at redhat.com  Thu Jan 30 09:59:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 09:59:12 -0500
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <4005C334-5123-4768-A655-93B05B16AE63@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
	<52E916E0.5030504@redhat.com>
	<448983909.15499874.1391008309824.JavaMail.root@redhat.com>
	<4005C334-5123-4768-A655-93B05B16AE63@redhat.com>
Message-ID: <52EA68C0.3060101@redhat.com>

How hard is it to have admin console themes that match both product and 
project?  Pluggable an everything?

On 1/30/2014 9:37 AM, Gabriel Cardoso wrote:
> Bill, RCUE is for projects, so we need some customization to
> differentiate the project. Viliam could make the changes to use the new
> design. Let?s go for it?
>
> Stian, they have some material at http://rcue-uxd.itos.redhat.com
>
> Gabriel
>
> On Jan 29, 2014, at 1:11 PM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>> To:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Wednesday, 29 January, 2014 2:57:36 PM
>>> Subject: Re: [keycloak-dev] Customization for Keycloak
>>>
>>> Honestly, I'd prefer to follow the same look and feel as EAP instead of
>>> creating our own.  We may eventually have to provide keycloak "portlets"
>>> that can plug into different mgmt consoles.
>>
>> We need to move to the official RCUE styles at some point. This will
>> probably require some changes to html structure. Once we've done that
>> it's easy to change the L&F from the Keycloak theme, to the WildFly
>> theme and finally to the EAP theme.
>>
>> Gabriel do you know where we can get RCUE from?
>>
>>>
>>> On 1/29/2014 9:44 AM, Gabriel Cardoso wrote:
>>>>
>>>> On Jan 29, 2014, at 12:34 PM, Stian Thorgersen <stian at redhat.com
>>>> <mailto:stian at redhat.com>
>>>> <mailto:stian at redhat.com>> wrote:
>>>>
>>>>> The login form looks really good!
>>>> Thanks
>>>>
>>>>> I'm not convinced about the admin console though. The bright blue
>>>>> isn't very nice. Also I was wondering if there's some way we could not
>>>>> have a separate "bar" for the realm drop-down and add realm button.
>>>>> Could we move this to the left-hand menu, or merge it with the logo /
>>>>> user selection bar (and also make it slightly bigger at the same time)?
>>>> Well, it is a matter of taste. But I can try to make it more attractive.
>>>>
>>>> Why you don?t want to have that nav bar? We have plenty of space and it
>>>> is clear that this is the highter level of navigation.
>>>>
>>>> However, it doesn?t hurt trying to incorporate the dropdown and button
>>>> into the sidebar. I?m just afraid this will make the navigation more
>>>> confusing, but we can give a shot.
>>>>
>>>> Here is an example of something they did for EAP.
>>>>
>>>>
>>>> I needed to think a bit to understand the hierarchy.
>>>>
>>>> Gabriel
>>>>
>>>> ---
>>>> Gabriel Cardoso
>>>> User Experience Designer @ Red Hat
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> 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 <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>

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

From ssilvert at redhat.com  Thu Jan 30 09:59:22 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 30 Jan 2014 09:59:22 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
Message-ID: <52EA68CA.800@redhat.com>

I've done the initial pull request for the Keycloak subsystem.  After
starting fresh with the latest build I was finally able to verify  that
it really does work end to end!

I probably won't have much more time to work on Keycloak for the next
4-5 weeks.  So I'll try to put everything I know about it into these
notes in case someone wants to take it over.  I happy to answer
questions though.

Directions to try the subsystem on your own:
* Build the new subsystem module.
* Rebuild the undertow adapter.  The EAP6 adapter has not been updated
to use the subsystem, so you will need to use WildFly.
* Update standalone.xml.  I've attached a version of standalone.xml that
I used with the Keycloak appliance.  It shows adding the Keycloak
extension near the top of the file and adding the subsystem definition
near the bottom.
* Copy
keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
<WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
* Copy
keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
to
<WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
* Edit module.xml and add the subsystem jar as a resource-root. 
Alternatively, you can just use the module.xml attached to this email.
* Copy
keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
to
<WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main

Now if you reboot WildFly you can view and manipulate the subsystem
using CLI or CLI GUI.  All operations such as add/remove/write-attribute
should be working.  I recommend CLI GUI so you can see everything in
context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface

To test the subsystem with a live application, I did the following:
* Copy the customer-portal.war to customer-portal-subsys.war.
* Remove keycloak.json and jboss-deployment-structure.xml from the WAR. 
The subsystem makes those files redundant.
* Edit the web.xml inside the WAR and change the <module-name> to
customer-portal-subsys.  I'm not sure if this is really needed.  If we
need to manipulate web.xml settings at deploy time then the subsystem
can be modified to do that too.
* Define the customer-portal-subsys application in Keycloak Admin.  It
should have the same settings as customer-portal.
* Deploy customer-portal-subsys.war to WildFly and test it out.

Future tasks for the Keycloak Subsystem:
* Integration with the Keycloak Admin
* Review the attributes of realm and secure-deployment to make sure they
align with keycloak.json.
* Fill in help text in
keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
* See comments in KeycloakAdapterConfigService.java.  This class may
work better as a plain Singleton instead of a service.
* It probably wouldn't hurt to ask Brian Stansberry to give the
subsystem a quick review.
* More tests
* Package the subsystem with the distribution
* Documentation


-------------- next part --------------
A non-text attachment was scrubbed...
Name: standalone.xml
Type: text/xml
Size: 21954 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/675aa1f6/attachment-0002.xml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: module.xml
Type: text/xml
Size: 1794 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/675aa1f6/attachment-0003.xml 

From bburke at redhat.com  Thu Jan 30 10:17:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 10:17:09 -0500
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <20140130153030.27288681@kapy-ntb-x220>
References: <20140130095345.2f02b639@kapy-ntb-x220>	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>	<20140130141357.4b609bf8@kapy-ntb-x220>	<52EA55AB.1030707@redhat.com>	<1148398873.16398621.1391089520382.JavaMail.root@redhat.com>
	<20140130153030.27288681@kapy-ntb-x220>
Message-ID: <52EA6CF5.2010202@redhat.com>

Resteasy 3.0.6 master pom (downloaded from maven central) has 
repository.jboss.org as a repository and also has a jboss-web dependency 
so I don't understand why Keycloak can't be pushed to maven central.

On 1/30/2014 9:30 AM, Karel Piwko wrote:
> Correct, Maven Central is even simpler to use. Works ootb, no mangling with
> settings.xml is required at all.
>
> I asked for pushing RESTEasy to Maven Central in Nov 2011, needed for EAP6/WFK2.
> There was the same clean up of pom.xml(s) back then.
>
> Performance wise, I have no idea. I'm not experiencing any difference at all. If
> you experience connection lags, you can always mirror Maven Central to a
> different repo, such as JBoss Nexus -
> http://maven.apache.org/guides/mini/guide-mirror-settings.html.
>
> Karel
>
> On Thu, 30 Jan 2014 08:45:20 -0500 (EST)
> Stian Thorgersen <stian at redhat.com> wrote:
>
>> Hosting on Maven Central means that folks can use Keycloak artifaces without
>> having to add JBoss Nexus to their poms. So IMO it makes it slightly simpler
>> to add Keycloak deps.
>>
>> RestEasy is on Maven Central
>> (http://search.maven.org/#search%7Cga%7C1%7Cresteasy) ;)
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 30 January, 2014 1:37:47 PM
>>> Subject: Re: [keycloak-dev] Keycloak artifacts not in Maven Central
>>>
>>>
>>>
>>> On 1/30/2014 8:13 AM, Karel Piwko wrote:
>>>> I did some checks and there is some work needed:
>>>>
>>>> 1/ According to Maven Central rules, there should not be any <repository>
>>>> elements in pom.xml files
>>>
>>>
>>>> 2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
>>>> available no Maven Central
>>>>
>>>> So, following steps are needed:
>>>>
>>>> * figure out whether jbossweb dependency could be replaced by something
>>>> else,
>>>>     if not - it has to undergo same checks as keycloak and be synced to
>>>>     Maven
>>>>     Central or, which I prefer, to release it relocated to org.keycloak
>>>>     groupId.
>>>>     Given that 7.0.17.Final has do external dependencies at all -
>>>>     seems much easier then trying to convince sonatype to pick a single
>>>>     version
>>>>     of jbossweb tree
>>>> * remove all <repositories> from pom.xml files
>>>>
>>>
>>> Would hosting at Maven Central require developers to configure their
>>> settings.xml, or can the build still run OOTB?  A build running OOTB is
>>> more important than hosting at Maven Central.
>>>
>>> Also, what is the performance of Maven Central compared to
>>> repository.jboss.org?  I've often had slow as balls connections to Maven
>>> Central and never any problems with repository.jboss.org.  Finally,
>>> nobody has ever complained that Resteasy is not at Maven central.
>>> People have no problems using repository.jboss.org so I don't see what
>>> the big deal is.
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> 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
>

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

From gcardoso at redhat.com  Thu Jan 30 10:18:00 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 13:18:00 -0200
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <52EA68C0.3060101@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
	<52E916E0.5030504@redhat.com>
	<448983909.15499874.1391008309824.JavaMail.root@redhat.com>
	<4005C334-5123-4768-A655-93B05B16AE63@redhat.com>
	<52EA68C0.3060101@redhat.com>
Message-ID: <30B03408-EE0E-492B-B66F-6CB81AEA3952@redhat.com>

A good approach for that is to have one CSS for each theme: RCUE and project. This CSS only specify styles that are different for the themes, aka the login page background / colours, console header colours, links and buttons colours etc. We will use this CSS file with other CSS files that specify the layout, font-sizes, margins, alignments etc. These styles are the same for project / product. In this sense it will be relatively simple.

I?m not sure what you mean by ?pluggable and everything?.

On Jan 30, 2014, at 12:59 PM, Bill Burke <bburke at redhat.com> wrote:

> How hard is it to have admin console themes that match both product and project?  Pluggable an everything?
> 
> On 1/30/2014 9:37 AM, Gabriel Cardoso wrote:
>> Bill, RCUE is for projects, so we need some customization to
>> differentiate the project. Viliam could make the changes to use the new
>> design. Let?s go for it?
>> 
>> Stian, they have some material at http://rcue-uxd.itos.redhat.com
>> 
>> Gabriel
>> 
>> On Jan 29, 2014, at 1:11 PM, Stian Thorgersen <stian at redhat.com
>> <mailto:stian at redhat.com>> wrote:
>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>> To:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> Sent: Wednesday, 29 January, 2014 2:57:36 PM
>>>> Subject: Re: [keycloak-dev] Customization for Keycloak
>>>> 
>>>> Honestly, I'd prefer to follow the same look and feel as EAP instead of
>>>> creating our own.  We may eventually have to provide keycloak "portlets"
>>>> that can plug into different mgmt consoles.
>>> 
>>> We need to move to the official RCUE styles at some point. This will
>>> probably require some changes to html structure. Once we've done that
>>> it's easy to change the L&F from the Keycloak theme, to the WildFly
>>> theme and finally to the EAP theme.
>>> 
>>> Gabriel do you know where we can get RCUE from?
>>> 
>>>> 
>>>> On 1/29/2014 9:44 AM, Gabriel Cardoso wrote:
>>>>> 
>>>>> On Jan 29, 2014, at 12:34 PM, Stian Thorgersen <stian at redhat.com
>>>>> <mailto:stian at redhat.com>
>>>>> <mailto:stian at redhat.com>> wrote:
>>>>> 
>>>>>> The login form looks really good!
>>>>> Thanks
>>>>> 
>>>>>> I'm not convinced about the admin console though. The bright blue
>>>>>> isn't very nice. Also I was wondering if there's some way we could not
>>>>>> have a separate "bar" for the realm drop-down and add realm button.
>>>>>> Could we move this to the left-hand menu, or merge it with the logo /
>>>>>> user selection bar (and also make it slightly bigger at the same time)?
>>>>> Well, it is a matter of taste. But I can try to make it more attractive.
>>>>> 
>>>>> Why you don?t want to have that nav bar? We have plenty of space and it
>>>>> is clear that this is the highter level of navigation.
>>>>> 
>>>>> However, it doesn?t hurt trying to incorporate the dropdown and button
>>>>> into the sidebar. I?m just afraid this will make the navigation more
>>>>> confusing, but we can give a shot.
>>>>> 
>>>>> Here is an example of something they did for EAP.
>>>>> 
>>>>> 
>>>>> I needed to think a bit to understand the hierarchy.
>>>>> 
>>>>> Gabriel
>>>>> 
>>>>> ---
>>>>> Gabriel Cardoso
>>>>> User Experience Designer @ Red Hat
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> 
>>>> 
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> 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 <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/18615b65/attachment.html 

From bburke at redhat.com  Thu Jan 30 10:18:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 10:18:23 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52EA68CA.800@redhat.com>
References: <52EA68CA.800@redhat.com>
Message-ID: <52EA6D3F.1010708@redhat.com>

Awesome stan!  After I get composite roles in, I'll take a look and make 
improvements where I can.

BTW, do you know if the remote admin REST api is only authenticated via 
DIGEST?  Can it be configured to use other options?

On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
> I've done the initial pull request for the Keycloak subsystem.  After
> starting fresh with the latest build I was finally able to verify  that
> it really does work end to end!
>
> I probably won't have much more time to work on Keycloak for the next
> 4-5 weeks.  So I'll try to put everything I know about it into these
> notes in case someone wants to take it over.  I happy to answer
> questions though.
>
> Directions to try the subsystem on your own:
> * Build the new subsystem module.
> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
> to use the subsystem, so you will need to use WildFly.
> * Update standalone.xml.  I've attached a version of standalone.xml that
> I used with the Keycloak appliance.  It shows adding the Keycloak
> extension near the top of the file and adding the subsystem definition
> near the bottom.
> * Copy
> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
> * Copy
> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
> to
> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
> * Edit module.xml and add the subsystem jar as a resource-root.
> Alternatively, you can just use the module.xml attached to this email.
> * Copy
> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
> to
> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>
> Now if you reboot WildFly you can view and manipulate the subsystem
> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
> should be working.  I recommend CLI GUI so you can see everything in
> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>
> To test the subsystem with a live application, I did the following:
> * Copy the customer-portal.war to customer-portal-subsys.war.
> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
> The subsystem makes those files redundant.
> * Edit the web.xml inside the WAR and change the <module-name> to
> customer-portal-subsys.  I'm not sure if this is really needed.  If we
> need to manipulate web.xml settings at deploy time then the subsystem
> can be modified to do that too.
> * Define the customer-portal-subsys application in Keycloak Admin.  It
> should have the same settings as customer-portal.
> * Deploy customer-portal-subsys.war to WildFly and test it out.
>
> Future tasks for the Keycloak Subsystem:
> * Integration with the Keycloak Admin
> * Review the attributes of realm and secure-deployment to make sure they
> align with keycloak.json.
> * Fill in help text in
> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
> * See comments in KeycloakAdapterConfigService.java.  This class may
> work better as a plain Singleton instead of a service.
> * It probably wouldn't hurt to ask Brian Stansberry to give the
> subsystem a quick review.
> * More tests
> * Package the subsystem with the distribution
> * Documentation
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Thu Jan 30 10:19:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 10:19:25 -0500
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <30B03408-EE0E-492B-B66F-6CB81AEA3952@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
	<52E916E0.5030504@redhat.com>
	<448983909.15499874.1391008309824.JavaMail.root@redhat.com>
	<4005C334-5123-4768-A655-93B05B16AE63@redhat.com>
	<52EA68C0.3060101@redhat.com>
	<30B03408-EE0E-492B-B66F-6CB81AEA3952@redhat.com>
Message-ID: <52EA6D7D.3080204@redhat.com>



On 1/30/2014 10:18 AM, Gabriel Cardoso wrote:
>
> I?m not sure what you mean by ?pluggable and everything?.
>

I mean, we can easily switch to between themes if we need to.

Bill

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

From gcardoso at redhat.com  Thu Jan 30 10:23:01 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 13:23:01 -0200
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <52EA6D7D.3080204@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
	<52E916E0.5030504@redhat.com>
	<448983909.15499874.1391008309824.JavaMail.root@redhat.com>
	<4005C334-5123-4768-A655-93B05B16AE63@redhat.com>
	<52EA68C0.3060101@redhat.com>
	<30B03408-EE0E-492B-B66F-6CB81AEA3952@redhat.com>
	<52EA6D7D.3080204@redhat.com>
Message-ID: <C99B4148-297E-4018-959A-D4152457A0CE@redhat.com>

I?ve done this before and all we needed to do was to change one line of code to choose rcue.css instead of keycloak.css in the <head>.

On Jan 30, 2014, at 1:19 PM, Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 1/30/2014 10:18 AM, Gabriel Cardoso wrote:
>> 
>> I?m not sure what you mean by ?pluggable and everything?.
>> 
> 
> I mean, we can easily switch to between themes if we need to.
> 
> Bill
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/5da94775/attachment-0001.html 

From darran.lofthouse at jboss.com  Thu Jan 30 10:23:05 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 30 Jan 2014 15:23:05 +0000
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52EA6D3F.1010708@redhat.com>
References: <52EA68CA.800@redhat.com> <52EA6D3F.1010708@redhat.com>
Message-ID: <52EA6E59.3030602@jboss.com>

No at the moment it is not possible to override the mechanism unless you 
switch to LDAP or JAAS for authentication.

We could add a config option to force it to BASIC but with the ongoing 
changes planned it is probably not worth it.

On 30/01/14 15:18, Bill Burke wrote:
> Awesome stan!  After I get composite roles in, I'll take a look and make
> improvements where I can.
>
> BTW, do you know if the remote admin REST api is only authenticated via
> DIGEST?  Can it be configured to use other options?
>
> On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
>> I've done the initial pull request for the Keycloak subsystem.  After
>> starting fresh with the latest build I was finally able to verify  that
>> it really does work end to end!
>>
>> I probably won't have much more time to work on Keycloak for the next
>> 4-5 weeks.  So I'll try to put everything I know about it into these
>> notes in case someone wants to take it over.  I happy to answer
>> questions though.
>>
>> Directions to try the subsystem on your own:
>> * Build the new subsystem module.
>> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
>> to use the subsystem, so you will need to use WildFly.
>> * Update standalone.xml.  I've attached a version of standalone.xml that
>> I used with the Keycloak appliance.  It shows adding the Keycloak
>> extension near the top of the file and adding the subsystem definition
>> near the bottom.
>> * Copy
>> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>> * Copy
>> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
>> to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>> * Edit module.xml and add the subsystem jar as a resource-root.
>> Alternatively, you can just use the module.xml attached to this email.
>> * Copy
>> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
>> to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>>
>> Now if you reboot WildFly you can view and manipulate the subsystem
>> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
>> should be working.  I recommend CLI GUI so you can see everything in
>> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>>
>> To test the subsystem with a live application, I did the following:
>> * Copy the customer-portal.war to customer-portal-subsys.war.
>> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
>> The subsystem makes those files redundant.
>> * Edit the web.xml inside the WAR and change the <module-name> to
>> customer-portal-subsys.  I'm not sure if this is really needed.  If we
>> need to manipulate web.xml settings at deploy time then the subsystem
>> can be modified to do that too.
>> * Define the customer-portal-subsys application in Keycloak Admin.  It
>> should have the same settings as customer-portal.
>> * Deploy customer-portal-subsys.war to WildFly and test it out.
>>
>> Future tasks for the Keycloak Subsystem:
>> * Integration with the Keycloak Admin
>> * Review the attributes of realm and secure-deployment to make sure they
>> align with keycloak.json.
>> * Fill in help text in
>> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
>> * See comments in KeycloakAdapterConfigService.java.  This class may
>> work better as a plain Singleton instead of a service.
>> * It probably wouldn't hurt to ask Brian Stansberry to give the
>> subsystem a quick review.
>> * More tests
>> * Package the subsystem with the distribution
>> * Documentation
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From ssilvert at redhat.com  Thu Jan 30 10:23:53 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 30 Jan 2014 10:23:53 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52EA6D3F.1010708@redhat.com>
References: <52EA68CA.800@redhat.com> <52EA6D3F.1010708@redhat.com>
Message-ID: <52EA6E89.5000601@redhat.com>

On 1/30/2014 10:18 AM, Bill Burke wrote:
> Awesome stan!  After I get composite roles in, I'll take a look and make 
> improvements where I can.
>
> BTW, do you know if the remote admin REST api is only authenticated via 
> DIGEST?  Can it be configured to use other options?
Right now it is only authenticated via DIGEST.  And, because it rejects
all CORS requests, it can only be used by the EAP web console.  Both of
these issues are being addressed in WildFly 9.
>
> On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
>> I've done the initial pull request for the Keycloak subsystem.  After
>> starting fresh with the latest build I was finally able to verify  that
>> it really does work end to end!
>>
>> I probably won't have much more time to work on Keycloak for the next
>> 4-5 weeks.  So I'll try to put everything I know about it into these
>> notes in case someone wants to take it over.  I happy to answer
>> questions though.
>>
>> Directions to try the subsystem on your own:
>> * Build the new subsystem module.
>> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
>> to use the subsystem, so you will need to use WildFly.
>> * Update standalone.xml.  I've attached a version of standalone.xml that
>> I used with the Keycloak appliance.  It shows adding the Keycloak
>> extension near the top of the file and adding the subsystem definition
>> near the bottom.
>> * Copy
>> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>> * Copy
>> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
>> to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>> * Edit module.xml and add the subsystem jar as a resource-root.
>> Alternatively, you can just use the module.xml attached to this email.
>> * Copy
>> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
>> to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>>
>> Now if you reboot WildFly you can view and manipulate the subsystem
>> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
>> should be working.  I recommend CLI GUI so you can see everything in
>> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>>
>> To test the subsystem with a live application, I did the following:
>> * Copy the customer-portal.war to customer-portal-subsys.war.
>> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
>> The subsystem makes those files redundant.
>> * Edit the web.xml inside the WAR and change the <module-name> to
>> customer-portal-subsys.  I'm not sure if this is really needed.  If we
>> need to manipulate web.xml settings at deploy time then the subsystem
>> can be modified to do that too.
>> * Define the customer-portal-subsys application in Keycloak Admin.  It
>> should have the same settings as customer-portal.
>> * Deploy customer-portal-subsys.war to WildFly and test it out.
>>
>> Future tasks for the Keycloak Subsystem:
>> * Integration with the Keycloak Admin
>> * Review the attributes of realm and secure-deployment to make sure they
>> align with keycloak.json.
>> * Fill in help text in
>> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
>> * See comments in KeycloakAdapterConfigService.java.  This class may
>> work better as a plain Singleton instead of a service.
>> * It probably wouldn't hurt to ask Brian Stansberry to give the
>> subsystem a quick review.
>> * More tests
>> * Package the subsystem with the distribution
>> * Documentation
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From gcardoso at redhat.com  Thu Jan 30 10:28:08 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 13:28:08 -0200
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <52E9266A.5070505@redhat.com>
References: <52E9266A.5070505@redhat.com>
Message-ID: <7F37BCB3-2490-4A7E-8E2D-50376DD8CAC3@redhat.com>

The text is very explicative. I?ve just found the term ?User Interface experience? a bit weird, probably because everybody is talking about ?User Experience?, so putting the ?interface? in the middle sounded that way to me.

I guess ?User Interface solution? would sound better.

Will this be public?

On Jan 29, 2014, at 2:03 PM, Bill Burke <bburke at redhat.com> wrote:

> Keycloak aims to provide the entire User Interface experience for your 
> security needs so your applications don't have to.  UIs like "Forgot 
> Password", "Lost Authenticator", registration pages, social login, 
> update/reset password, and user account management can all be handled 
> and customly styled by Keycloak so you don't have to implement these 
> screens and features for each one of your web applications.
> 
> How's that sound?
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/6a92a293/attachment.html 

From kpiwko at redhat.com  Thu Jan 30 10:31:17 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 30 Jan 2014 16:31:17 +0100
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <52EA6CF5.2010202@redhat.com>
References: <20140130095345.2f02b639@kapy-ntb-x220>
	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
	<20140130141357.4b609bf8@kapy-ntb-x220>
	<52EA55AB.1030707@redhat.com>
	<1148398873.16398621.1391089520382.JavaMail.root@redhat.com>
	<20140130153030.27288681@kapy-ntb-x220>
	<52EA6CF5.2010202@redhat.com>
Message-ID: <20140130163117.3dd8f4bc@kapy-ntb-x220>

Quoting
http://maven.apache.org/guides/mini/guide-central-repository-upload.html - 

Q: I have other repositories or pluginRepositories listed in my POM, is that a
problem? 
A: At present, this won't preclude your project from being included,
but we do strongly encourage making sure all your dependencies are included in
Central.

I believe its worth removing. Having *all* artifacts in two repo managers is
always better then relying on single one.


On Thu, 30 Jan 2014 10:17:09 -0500
Bill Burke <bburke at redhat.com> wrote:

> Resteasy 3.0.6 master pom (downloaded from maven central) has 
> repository.jboss.org as a repository and also has a jboss-web dependency 
> so I don't understand why Keycloak can't be pushed to maven central.
> 
> On 1/30/2014 9:30 AM, Karel Piwko wrote:
> > Correct, Maven Central is even simpler to use. Works ootb, no mangling with
> > settings.xml is required at all.
> >
> > I asked for pushing RESTEasy to Maven Central in Nov 2011, needed for
> > EAP6/WFK2. There was the same clean up of pom.xml(s) back then.
> >
> > Performance wise, I have no idea. I'm not experiencing any difference at
> > all. If you experience connection lags, you can always mirror Maven Central
> > to a different repo, such as JBoss Nexus -
> > http://maven.apache.org/guides/mini/guide-mirror-settings.html.
> >
> > Karel
> >
> > On Thu, 30 Jan 2014 08:45:20 -0500 (EST)
> > Stian Thorgersen <stian at redhat.com> wrote:
> >
> >> Hosting on Maven Central means that folks can use Keycloak artifaces
> >> without having to add JBoss Nexus to their poms. So IMO it makes it
> >> slightly simpler to add Keycloak deps.
> >>
> >> RestEasy is on Maven Central
> >> (http://search.maven.org/#search%7Cga%7C1%7Cresteasy) ;)
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, 30 January, 2014 1:37:47 PM
> >>> Subject: Re: [keycloak-dev] Keycloak artifacts not in Maven Central
> >>>
> >>>
> >>>
> >>> On 1/30/2014 8:13 AM, Karel Piwko wrote:
> >>>> I did some checks and there is some work needed:
> >>>>
> >>>> 1/ According to Maven Central rules, there should not be any <repository>
> >>>> elements in pom.xml files
> >>>
> >>>
> >>>> 2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
> >>>> available no Maven Central
> >>>>
> >>>> So, following steps are needed:
> >>>>
> >>>> * figure out whether jbossweb dependency could be replaced by something
> >>>> else,
> >>>>     if not - it has to undergo same checks as keycloak and be synced to
> >>>>     Maven
> >>>>     Central or, which I prefer, to release it relocated to org.keycloak
> >>>>     groupId.
> >>>>     Given that 7.0.17.Final has do external dependencies at all -
> >>>>     seems much easier then trying to convince sonatype to pick a single
> >>>>     version
> >>>>     of jbossweb tree
> >>>> * remove all <repositories> from pom.xml files
> >>>>
> >>>
> >>> Would hosting at Maven Central require developers to configure their
> >>> settings.xml, or can the build still run OOTB?  A build running OOTB is
> >>> more important than hosting at Maven Central.
> >>>
> >>> Also, what is the performance of Maven Central compared to
> >>> repository.jboss.org?  I've often had slow as balls connections to Maven
> >>> Central and never any problems with repository.jboss.org.  Finally,
> >>> nobody has ever complained that Resteasy is not at Maven central.
> >>> People have no problems using repository.jboss.org so I don't see what
> >>> the big deal is.
> >>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> 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
> >
> 


From bburke at redhat.com  Thu Jan 30 10:31:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 10:31:38 -0500
Subject: [keycloak-dev] when next release
Message-ID: <52EA705A.1090303@redhat.com>

IMO, next release should be ASAP and include:

* Composite roles (almost done implementing)
* Wildfly Subsystem
* Themes (how far away are you stian?)

When we are done with these 3 things (and documented) we will release. 
Any other features that sneak in in that timeframe we will consider a bonus.

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

From bburke at redhat.com  Thu Jan 30 10:34:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 10:34:47 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52EA6E59.3030602@jboss.com>
References: <52EA68CA.800@redhat.com> <52EA6D3F.1010708@redhat.com>
	<52EA6E59.3030602@jboss.com>
Message-ID: <52EA7117.40601@redhat.com>

I wasn't asking to change it, just figuring out the scope of work.  For 
integration, I want the keycloak admin console to remotely manipulate 
the Keycloak subsystem.  If it is always DIGEST (or something that 
Apache Client can handle automatically via a challenge), then I don't 
have to worry about things.

On 1/30/2014 10:23 AM, Darran Lofthouse wrote:
> No at the moment it is not possible to override the mechanism unless you
> switch to LDAP or JAAS for authentication.
>
> We could add a config option to force it to BASIC but with the ongoing
> changes planned it is probably not worth it.
>
> On 30/01/14 15:18, Bill Burke wrote:
>> Awesome stan!  After I get composite roles in, I'll take a look and make
>> improvements where I can.
>>
>> BTW, do you know if the remote admin REST api is only authenticated via
>> DIGEST?  Can it be configured to use other options?
>>
>> On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
>>> I've done the initial pull request for the Keycloak subsystem.  After
>>> starting fresh with the latest build I was finally able to verify  that
>>> it really does work end to end!
>>>
>>> I probably won't have much more time to work on Keycloak for the next
>>> 4-5 weeks.  So I'll try to put everything I know about it into these
>>> notes in case someone wants to take it over.  I happy to answer
>>> questions though.
>>>
>>> Directions to try the subsystem on your own:
>>> * Build the new subsystem module.
>>> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
>>> to use the subsystem, so you will need to use WildFly.
>>> * Update standalone.xml.  I've attached a version of standalone.xml that
>>> I used with the Keycloak appliance.  It shows adding the Keycloak
>>> extension near the top of the file and adding the subsystem definition
>>> near the bottom.
>>> * Copy
>>> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>>> * Copy
>>> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
>>> to
>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>>> * Edit module.xml and add the subsystem jar as a resource-root.
>>> Alternatively, you can just use the module.xml attached to this email.
>>> * Copy
>>> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
>>> to
>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>>>
>>> Now if you reboot WildFly you can view and manipulate the subsystem
>>> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
>>> should be working.  I recommend CLI GUI so you can see everything in
>>> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>>>
>>> To test the subsystem with a live application, I did the following:
>>> * Copy the customer-portal.war to customer-portal-subsys.war.
>>> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
>>> The subsystem makes those files redundant.
>>> * Edit the web.xml inside the WAR and change the <module-name> to
>>> customer-portal-subsys.  I'm not sure if this is really needed.  If we
>>> need to manipulate web.xml settings at deploy time then the subsystem
>>> can be modified to do that too.
>>> * Define the customer-portal-subsys application in Keycloak Admin.  It
>>> should have the same settings as customer-portal.
>>> * Deploy customer-portal-subsys.war to WildFly and test it out.
>>>
>>> Future tasks for the Keycloak Subsystem:
>>> * Integration with the Keycloak Admin
>>> * Review the attributes of realm and secure-deployment to make sure they
>>> align with keycloak.json.
>>> * Fill in help text in
>>> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
>>> * See comments in KeycloakAdapterConfigService.java.  This class may
>>> work better as a plain Singleton instead of a service.
>>> * It probably wouldn't hurt to ask Brian Stansberry to give the
>>> subsystem a quick review.
>>> * More tests
>>> * Package the subsystem with the distribution
>>> * Documentation
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>

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

From bburke at redhat.com  Thu Jan 30 10:36:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 10:36:34 -0500
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <7F37BCB3-2490-4A7E-8E2D-50376DD8CAC3@redhat.com>
References: <52E9266A.5070505@redhat.com>
	<7F37BCB3-2490-4A7E-8E2D-50376DD8CAC3@redhat.com>
Message-ID: <52EA7182.5070100@redhat.com>

Maybe public.  But, I continually have to explain in a few sentences 
what Keycloak is and what it is for.  Its good to nail it down, plus, 
IMO, it helps to keep us focused.

On 1/30/2014 10:28 AM, Gabriel Cardoso wrote:
> The text is very explicative. I?ve just found the term ?User Interface
> experience? a bit weird, probably because everybody is talking about
> ?User Experience?, so putting the ?interface? in the middle sounded that
> way to me.
>
> I guess ?User Interface solution? would sound better.
>
> Will this be public?
>
> On Jan 29, 2014, at 2:03 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>> Keycloak aims to provide the entire User Interface experience for your
>> security needs so your applications don't have to.  UIs like "Forgot
>> Password", "Lost Authenticator", registration pages, social login,
>> update/reset password, and user account management can all be handled
>> and customly styled by Keycloak so you don't have to implement these
>> screens and features for each one of your web applications.
>>
>> How's that sound?
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>

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

From gcardoso at redhat.com  Thu Jan 30 10:38:38 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 13:38:38 -0200
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <1885862109.16255352.1391074254067.JavaMail.root@redhat.com>
References: <52E9266A.5070505@redhat.com>
	<1885862109.16255352.1391074254067.JavaMail.root@redhat.com>
Message-ID: <169959B6-05F2-4830-99C9-73307C09B4F2@redhat.com>

Nice Stian!

Will we provide themes and the customer can upload only a different background color / logo and change colours or he can customise everything?

On Jan 30, 2014, at 7:30 AM, Stian Thorgersen <stian at redhat.com> wrote:

> Sounds good. 
> 
> Theme support for login screens coming along nicely, just needs a bit of polish. Attached picture of a custom theme in action ;)
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 29 January, 2014 4:03:54 PM
>> Subject: [keycloak-dev] The Keycloak Vision/Core Values
>> 
>> Keycloak aims to provide the entire User Interface experience for your
>> security needs so your applications don't have to.  UIs like "Forgot
>> Password", "Lost Authenticator", registration pages, social login,
>> update/reset password, and user account management can all be handled
>> and customly styled by Keycloak so you don't have to implement these
>> screens and features for each one of your web applications.
>> 
>> How's that sound?
>> 
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
> <login-themes.png>_______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/e7a2a5c4/attachment.html 

From gcardoso at redhat.com  Thu Jan 30 10:40:57 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 13:40:57 -0200
Subject: [keycloak-dev] when next release
In-Reply-To: <52EA705A.1090303@redhat.com>
References: <52EA705A.1090303@redhat.com>
Message-ID: <DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>

Viliam is ready to make the changes to have the new visual design if you agree. Low effort and big impact, IMO.

Gabriel

On Jan 30, 2014, at 1:31 PM, Bill Burke <bburke at redhat.com> wrote:

> IMO, next release should be ASAP and include:
> 
> * Composite roles (almost done implementing)
> * Wildfly Subsystem
> * Themes (how far away are you stian?)
> 
> When we are done with these 3 things (and documented) we will release. 
> Any other features that sneak in in that timeframe we will consider a bonus.
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/2301cf2d/attachment.html 

From bburke at redhat.com  Thu Jan 30 10:44:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 10:44:17 -0500
Subject: [keycloak-dev] when next release
In-Reply-To: <DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
Message-ID: <52EA7351.5020708@redhat.com>

Yeah sure!  From my side of things, visual design is your domain 
Gabriel.  Anything you think should be done you probably won't have much 
argument from me.

On 1/30/2014 10:40 AM, Gabriel Cardoso wrote:
> Viliam is ready to make the changes to have the new visual design if you
> agree. Low effort and big impact, IMO.
>
> Gabriel
>
> On Jan 30, 2014, at 1:31 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>> IMO, next release should be ASAP and include:
>>
>> * Composite roles (almost done implementing)
>> * Wildfly Subsystem
>> * Themes (how far away are you stian?)
>>
>> When we are done with these 3 things (and documented) we will release.
>> Any other features that sneak in in that timeframe we will consider a
>> bonus.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From gcardoso at redhat.com  Thu Jan 30 10:51:41 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 13:51:41 -0200
Subject: [keycloak-dev] when next release
In-Reply-To: <52EA7351.5020708@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
	<52EA7351.5020708@redhat.com>
Message-ID: <088A0A84-1310-4E1D-8266-5F58D2CAD01E@redhat.com>

Cool, thanks!

On Jan 30, 2014, at 1:44 PM, Bill Burke <bburke at redhat.com> wrote:

> Yeah sure!  From my side of things, visual design is your domain 
> Gabriel.  Anything you think should be done you probably won't have much 
> argument from me.
> 
> On 1/30/2014 10:40 AM, Gabriel Cardoso wrote:
>> Viliam is ready to make the changes to have the new visual design if you
>> agree. Low effort and big impact, IMO.
>> 
>> Gabriel
>> 
>> On Jan 30, 2014, at 1:31 PM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>> 
>>> IMO, next release should be ASAP and include:
>>> 
>>> * Composite roles (almost done implementing)
>>> * Wildfly Subsystem
>>> * Themes (how far away are you stian?)
>>> 
>>> When we are done with these 3 things (and documented) we will release.
>>> Any other features that sneak in in that timeframe we will consider a
>>> bonus.
>>> 
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
>> 
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/751194e9/attachment.html 

From darran.lofthouse at jboss.com  Thu Jan 30 10:51:44 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 30 Jan 2014 15:51:44 +0000
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52EA7117.40601@redhat.com>
References: <52EA68CA.800@redhat.com>
	<52EA6D3F.1010708@redhat.com>	<52EA6E59.3030602@jboss.com>
	<52EA7117.40601@redhat.com>
Message-ID: <52EA7510.8090506@jboss.com>

Ah Ok, I misunderstood - often when people ask to change it it is 
because they are trying to eliminate the challenge and force it down to 
BASIC auth ;-)

At this stage the management interface on WildFly supports Basic 
authentication, Digest authentication, or Client Cert authentication - 
the motivation here being use standard mechanisms and standard libraries 
will be able to use them.  We may also add SPNEGO to this list.

Longer term whatever happens with new capabilities e.g. enabling SSO the 
/management context will always be able to have these mechanisms enabled 
and a new context /management2 (Name TBC) will be added for the new 
mechanism(s).

Regards,
Darran Lofthouse.


On 30/01/14 15:34, Bill Burke wrote:
> I wasn't asking to change it, just figuring out the scope of work.  For
> integration, I want the keycloak admin console to remotely manipulate
> the Keycloak subsystem.  If it is always DIGEST (or something that
> Apache Client can handle automatically via a challenge), then I don't
> have to worry about things.
>
> On 1/30/2014 10:23 AM, Darran Lofthouse wrote:
>> No at the moment it is not possible to override the mechanism unless you
>> switch to LDAP or JAAS for authentication.
>>
>> We could add a config option to force it to BASIC but with the ongoing
>> changes planned it is probably not worth it.
>>
>> On 30/01/14 15:18, Bill Burke wrote:
>>> Awesome stan!  After I get composite roles in, I'll take a look and make
>>> improvements where I can.
>>>
>>> BTW, do you know if the remote admin REST api is only authenticated via
>>> DIGEST?  Can it be configured to use other options?
>>>
>>> On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
>>>> I've done the initial pull request for the Keycloak subsystem.  After
>>>> starting fresh with the latest build I was finally able to verify  that
>>>> it really does work end to end!
>>>>
>>>> I probably won't have much more time to work on Keycloak for the next
>>>> 4-5 weeks.  So I'll try to put everything I know about it into these
>>>> notes in case someone wants to take it over.  I happy to answer
>>>> questions though.
>>>>
>>>> Directions to try the subsystem on your own:
>>>> * Build the new subsystem module.
>>>> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
>>>> to use the subsystem, so you will need to use WildFly.
>>>> * Update standalone.xml.  I've attached a version of standalone.xml that
>>>> I used with the Keycloak appliance.  It shows adding the Keycloak
>>>> extension near the top of the file and adding the subsystem definition
>>>> near the bottom.
>>>> * Copy
>>>> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
>>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>>>> * Copy
>>>> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
>>>> to
>>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>>>> * Edit module.xml and add the subsystem jar as a resource-root.
>>>> Alternatively, you can just use the module.xml attached to this email.
>>>> * Copy
>>>> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
>>>> to
>>>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>>>>
>>>> Now if you reboot WildFly you can view and manipulate the subsystem
>>>> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
>>>> should be working.  I recommend CLI GUI so you can see everything in
>>>> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>>>>
>>>> To test the subsystem with a live application, I did the following:
>>>> * Copy the customer-portal.war to customer-portal-subsys.war.
>>>> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
>>>> The subsystem makes those files redundant.
>>>> * Edit the web.xml inside the WAR and change the <module-name> to
>>>> customer-portal-subsys.  I'm not sure if this is really needed.  If we
>>>> need to manipulate web.xml settings at deploy time then the subsystem
>>>> can be modified to do that too.
>>>> * Define the customer-portal-subsys application in Keycloak Admin.  It
>>>> should have the same settings as customer-portal.
>>>> * Deploy customer-portal-subsys.war to WildFly and test it out.
>>>>
>>>> Future tasks for the Keycloak Subsystem:
>>>> * Integration with the Keycloak Admin
>>>> * Review the attributes of realm and secure-deployment to make sure they
>>>> align with keycloak.json.
>>>> * Fill in help text in
>>>> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
>>>> * See comments in KeycloakAdapterConfigService.java.  This class may
>>>> work better as a plain Singleton instead of a service.
>>>> * It probably wouldn't hurt to ask Brian Stansberry to give the
>>>> subsystem a quick review.
>>>> * More tests
>>>> * Package the subsystem with the distribution
>>>> * Documentation
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>

From stian at redhat.com  Thu Jan 30 11:16:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 11:16:59 -0500 (EST)
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <169959B6-05F2-4830-99C9-73307C09B4F2@redhat.com>
References: <52E9266A.5070505@redhat.com>
	<1885862109.16255352.1391074254067.JavaMail.root@redhat.com>
	<169959B6-05F2-4830-99C9-73307C09B4F2@redhat.com>
Message-ID: <923471979.16531924.1391098619049.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 3:38:38 PM
> Subject: Re: [keycloak-dev] The Keycloak Vision/Core Values
> 
> Nice Stian!
> 
> Will we provide themes and the customer can upload only a different
> background color / logo and change colours or he can customise everything?

As much as they want :)

> 
> On Jan 30, 2014, at 7:30 AM, Stian Thorgersen < stian at redhat.com > wrote:
> 
> 
> 
> Sounds good.
> 
> Theme support for login screens coming along nicely, just needs a bit of
> polish. Attached picture of a custom theme in action ;)
> 
> ----- Original Message -----
> 
> 
> From: "Bill Burke" < bburke at redhat.com >
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 January, 2014 4:03:54 PM
> Subject: [keycloak-dev] The Keycloak Vision/Core Values
> 
> Keycloak aims to provide the entire User Interface experience for your
> security needs so your applications don't have to. UIs like "Forgot
> Password", "Lost Authenticator", registration pages, social login,
> update/reset password, and user account management can all be handled
> and customly styled by Keycloak so you don't have to implement these
> screens and features for each one of your web applications.
> 
> How's that sound?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> <login-themes.png> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Jan 30 11:17:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 11:17:58 -0500 (EST)
Subject: [keycloak-dev] The Keycloak Vision/Core Values
In-Reply-To: <52EA7182.5070100@redhat.com>
References: <52E9266A.5070505@redhat.com>
	<7F37BCB3-2490-4A7E-8E2D-50376DD8CAC3@redhat.com>
	<52EA7182.5070100@redhat.com>
Message-ID: <273777985.16532439.1391098678428.JavaMail.root@redhat.com>

It would be cool to have 5-10 key points that KC is about. With a title and a summary, as well as a graphic. This would go well on the frontpage of our website ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Gabriel Cardoso" <gcardoso at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 3:36:34 PM
> Subject: Re: [keycloak-dev] The Keycloak Vision/Core Values
> 
> Maybe public.  But, I continually have to explain in a few sentences
> what Keycloak is and what it is for.  Its good to nail it down, plus,
> IMO, it helps to keep us focused.
> 
> On 1/30/2014 10:28 AM, Gabriel Cardoso wrote:
> > The text is very explicative. I?ve just found the term ?User Interface
> > experience? a bit weird, probably because everybody is talking about
> > ?User Experience?, so putting the ?interface? in the middle sounded that
> > way to me.
> >
> > I guess ?User Interface solution? would sound better.
> >
> > Will this be public?
> >
> > On Jan 29, 2014, at 2:03 PM, Bill Burke <bburke at redhat.com
> > <mailto:bburke at redhat.com>> wrote:
> >
> >> Keycloak aims to provide the entire User Interface experience for your
> >> security needs so your applications don't have to.  UIs like "Forgot
> >> Password", "Lost Authenticator", registration pages, social login,
> >> update/reset password, and user account management can all be handled
> >> and customly styled by Keycloak so you don't have to implement these
> >> screens and features for each one of your web applications.
> >>
> >> How's that sound?
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > ---
> > Gabriel Cardoso
> > User Experience Designer @ Red Hat
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From stian at redhat.com  Thu Jan 30 11:30:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 11:30:44 -0500 (EST)
Subject: [keycloak-dev] when next release
In-Reply-To: <52EA705A.1090303@redhat.com>
References: <52EA705A.1090303@redhat.com>
Message-ID: <2029406788.16541542.1391099444496.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 3:31:38 PM
> Subject: [keycloak-dev] when next release
> 
> IMO, next release should be ASAP and include:
> 
> * Composite roles (almost done implementing)

Are you doing this?

> * Wildfly Subsystem
> * Themes (how far away are you stian?)

A few days, should be ready by end of next week.

> 
> When we are done with these 3 things (and documented) we will release.
> Any other features that sneak in in that timeframe we will consider a bonus.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jan 30 11:32:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 11:32:49 -0500 (EST)
Subject: [keycloak-dev] when next release
In-Reply-To: <DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
Message-ID: <724709703.16542392.1391099569069.JavaMail.root@redhat.com>

Please don't touch forms at the moment! There's a lot of changes going on with themes.

With regards to changes I think we should move to RCUE styles first, and apply the changes in the way they recommend changing it. As I've said I'm not happy with the new design for it either.

The login forms looks excellent, but it would make sense to apply both login forms and admin console at the same time so they're uniform.

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 3:40:57 PM
> Subject: Re: [keycloak-dev] when next release
> 
> Viliam is ready to make the changes to have the new visual design if you
> agree. Low effort and big impact, IMO.
> 
> Gabriel
> 
> On Jan 30, 2014, at 1:31 PM, Bill Burke < bburke at redhat.com > wrote:
> 
> 
> 
> IMO, next release should be ASAP and include:
> 
> * Composite roles (almost done implementing)
> * Wildfly Subsystem
> * Themes (how far away are you stian?)
> 
> When we are done with these 3 things (and documented) we will release.
> Any other features that sneak in in that timeframe we will consider a bonus.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Jan 30 11:45:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 11:45:32 -0500 (EST)
Subject: [keycloak-dev] Storage protection
In-Reply-To: <CAM5SUC7_k9Y1pR00b443+xKrOh9vksKcqk7DaDt6nxO0FuQmqA@mail.gmail.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E68100.40501@redhat.com>
	<52E689A6.3070302@redhat.com> <52E68AA5.3000608@redhat.com>
	<1261296816.16271260.1391076762034.JavaMail.root@redhat.com>
	<etPan.52ea521b.41b71efb.a5ca@tesla>
	<50838457.16401730.1391089868237.JavaMail.root@redhat.com>
	<CAM5SUC7_k9Y1pR00b443+xKrOh9vksKcqk7DaDt6nxO0FuQmqA@mail.gmail.com>
Message-ID: <3497415.16553141.1391100332846.JavaMail.root@redhat.com>

Just to clarify, the interface was just a mock-up to explain things, and not a proposal ;)

I'd imagine that'd it'd be up to the provider of the EncryptionProvider to generate (and store the key). So again mock-up code:


public MasterFileEncryptionProvider implements EncryptionProvider {

  public void generateKeys(RealmModel realm) {
    KeyPair keyPair = generateKeyPair();
    
    String pass = getOrCreateMasterPass(System.getProperty("keycloak.secret.file"));

    String encryptedPrivateKey = encryptKey(keyPair.getPrivate());

    realm.setPrivateKey(encryptedPrivateKey);
    realm.setPublicKey(keyPair.getPublic());
  }

  ...

}


Does that make sense?


----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 2:01:45 PM
> Subject: Re: [keycloak-dev] Storage protection
> 
> Sorry if my e-mail gave to you a wrong impression. I was just asking about
> the interface to generate the secret.
> 
> 
> On Thu, Jan 30, 2014 at 11:51 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > BTW the interface I proposed wouldn't work with a HSM, they do the
> > encryption/decryption on board don't they? So it would be something like:
> >
> > public EncryptionProvider {
> >
> >   public void generateKeys(RealmModel realm);
> >
> >   public byte[] encrypt(byte[] b);
> >
> >   public byte[] decrypt(byte[] b);
> >
> >   public byte[] sign(byte[] b);
> >
> > }
> >
> > or something along those lines ;)
> >
> > ----- Original Message -----
> > > From: "Bruno Oliveira" <bruno at abstractj.org>
> > > To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <
> > stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, 30 January, 2014 1:22:35 PM
> > > Subject: Re: [keycloak-dev] Storage protection
> > >
> > > I think that's just fine, where developers will store their private keys
> > is
> > > their decision: db, text file or fancy hardwares.
> > >
> > > My only suggestion is to generate these keys with some KDF function,
> > maybe
> > > during the first application setup? What do you have in mind Stian?
> > command
> > > line, web interface, integrate with jboss-cli?
> >
> > First app startup I'd say. OOTB experience should be as simple as
> > possible. Probably just bootstrap it in:
> > https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java
> >
> > and set the location to ${jboss.config.dir}/keycloak.secret or something?
> >
> > >
> > > --
> > > abstractj
> > >
> > > On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian at redhat.com)
> > wrote:
> > > > > We should do it as an SPI to make it extensible. This would allow
> > > > admins to integrate it best into how they manage sensitive data.
> > > > I don't know what common practices are, but I imagine there are
> > > > many ways to do it.
> > > >
> > > > As I said before I think our options OOTB are either to just store
> > > > in clear-text, or generate a master password and write to a known
> > > > location (/standalone/data/realm.secret?).
> > > > Anything more than that would make it hard to use for development.
> > > >
> > > > I believe it is safer store a master password in a file (and an
> > additional
> > > > layer of defence to storing in clear-text to RDBMS, which can
> > > > be compromised through SQL-injection attacks that non-shared
> > > > file systems are not prone to).
> > > >
> > > > The master password location can be configurable through a system
> > > > property. Admins can place this file on an encrypted location,
> > > > this would be recommended. I don't think its any better to provide
> > > > the master password as a argument or system property at startup
> > > > than it is to store it in a file on an encrypted drive. The reason
> > > > being is that if someone gains admin access to the server, they
> > > > will be able to read the file, sure, but they can also get the
> > arguments
> > > > used to start the server just as easily. If the server is turned
> > > > of neither properties or an encrypted drive will help them. Admins
> > > > already have mechanisms in place to manage encrypted drives
> > > > on servers, so we'd rely on them to know how to do that themselves.
> > > >
> > > > For future and more improved solutions we can add whatever mechanisms
> > > > users are asking for through the SPI. Enterprises can also implement
> > > > their own.
> > > >
> > > > The SPI could be something as simple as:
> > > >
> > > > public interface PrivateKeyProvider {
> > > > public PEM getPrivateKey(RealmModel realm);
> > > > }
> > >
> > >
> >
> 
> 
> 
> --
> 
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
> 

From stian at redhat.com  Thu Jan 30 11:47:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jan 2014 11:47:00 -0500 (EST)
Subject: [keycloak-dev] Storage protection
In-Reply-To: <52EA5B01.2090207@redhat.com>
References: <etPan.52e670a8.41b71efb.4fff@tesla> <52E68100.40501@redhat.com>
	<52E689A6.3070302@redhat.com> <52E68AA5.3000608@redhat.com>
	<1261296816.16271260.1391076762034.JavaMail.root@redhat.com>
	<etPan.52ea521b.41b71efb.a5ca@tesla>
	<50838457.16401730.1391089868237.JavaMail.root@redhat.com>
	<52EA5B01.2090207@redhat.com>
Message-ID: <436334739.16553939.1391100420336.JavaMail.root@redhat.com>

I think it does doesn't it?

If using a HSM you'd have to pass the algorithm to use as well so that it can sign it using the expected algorithm. So it would be:

  public byte[] sign(byte[] b, String algorithm);

The interface definitively needs more thinking about ;)
 
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 2:00:33 PM
> Subject: Re: [keycloak-dev] Storage protection
> 
> I don't think this relates, but just in case...tokens need to be signed
> by a known algorithm so clients are able to verify them.
> 
> On 1/30/2014 8:51 AM, Stian Thorgersen wrote:
> > BTW the interface I proposed wouldn't work with a HSM, they do the
> > encryption/decryption on board don't they? So it would be something like:
> >
> > public EncryptionProvider {
> >
> >    public void generateKeys(RealmModel realm);
> >
> >    public byte[] encrypt(byte[] b);
> >
> >    public byte[] decrypt(byte[] b);
> >
> >    public byte[] sign(byte[] b);
> >
> > }
> >
> > or something along those lines ;)
> >
> > ----- Original Message -----
> >> From: "Bruno Oliveira" <bruno at abstractj.org>
> >> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen"
> >> <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 30 January, 2014 1:22:35 PM
> >> Subject: Re: [keycloak-dev] Storage protection
> >>
> >> I think that?s just fine, where developers will store their private keys
> >> is
> >> their decision: db, text file or fancy hardwares.
> >>
> >> My only suggestion is to generate these keys with some KDF function, maybe
> >> during the first application setup? What do you have in mind Stian?
> >> command
> >> line, web interface, integrate with jboss-cli?
> >
> > First app startup I'd say. OOTB experience should be as simple as possible.
> > Probably just bootstrap it in:
> > https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org/keycloak/server/KeycloakServerApplication.java
> >
> > and set the location to ${jboss.config.dir}/keycloak.secret or something?
> >
> >>
> >> --
> >> abstractj
> >>
> >> On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian at redhat.com)
> >> wrote:
> >>>> We should do it as an SPI to make it extensible. This would allow
> >>> admins to integrate it best into how they manage sensitive data.
> >>> I don't know what common practices are, but I imagine there are
> >>> many ways to do it.
> >>>
> >>> As I said before I think our options OOTB are either to just store
> >>> in clear-text, or generate a master password and write to a known
> >>> location (/standalone/data/realm.secret?).
> >>> Anything more than that would make it hard to use for development.
> >>>
> >>> I believe it is safer store a master password in a file (and an
> >>> additional
> >>> layer of defence to storing in clear-text to RDBMS, which can
> >>> be compromised through SQL-injection attacks that non-shared
> >>> file systems are not prone to).
> >>>
> >>> The master password location can be configurable through a system
> >>> property. Admins can place this file on an encrypted location,
> >>> this would be recommended. I don't think its any better to provide
> >>> the master password as a argument or system property at startup
> >>> than it is to store it in a file on an encrypted drive. The reason
> >>> being is that if someone gains admin access to the server, they
> >>> will be able to read the file, sure, but they can also get the arguments
> >>> used to start the server just as easily. If the server is turned
> >>> of neither properties or an encrypted drive will help them. Admins
> >>> already have mechanisms in place to manage encrypted drives
> >>> on servers, so we'd rely on them to know how to do that themselves.
> >>>
> >>> For future and more improved solutions we can add whatever mechanisms
> >>> users are asking for through the SPI. Enterprises can also implement
> >>> their own.
> >>>
> >>> The SPI could be something as simple as:
> >>>
> >>> public interface PrivateKeyProvider {
> >>> public PEM getPrivateKey(RealmModel realm);
> >>> }
> >>
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>


From bburke at redhat.com  Thu Jan 30 11:58:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Jan 2014 11:58:34 -0500
Subject: [keycloak-dev] when next release
In-Reply-To: <2029406788.16541542.1391099444496.JavaMail.root@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<2029406788.16541542.1391099444496.JavaMail.root@redhat.com>
Message-ID: <52EA84BA.8040809@redhat.com>



On 1/30/2014 11:30 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 30 January, 2014 3:31:38 PM
>> Subject: [keycloak-dev] when next release
>>
>> IMO, next release should be ASAP and include:
>>
>> * Composite roles (almost done implementing)
>
> Are you doing this?
>

Yes, just have to do the UI work.  Backend is done.


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

From gcardoso at redhat.com  Thu Jan 30 14:14:07 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 30 Jan 2014 17:14:07 -0200
Subject: [keycloak-dev] when next release
In-Reply-To: <724709703.16542392.1391099569069.JavaMail.root@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
	<724709703.16542392.1391099569069.JavaMail.root@redhat.com>
Message-ID: <6B6B493F-1AB7-48D6-9A4C-BD4D38EE6DB6@redhat.com>

> With regards to changes I think we should move to RCUE styles first, and apply the changes in the way they recommend changing it. As I've said I'm not happy with the new design for it either.

What exactly do you mean by ?move to RCUE styles first?? Changing the markup according to the widgets provided in this page? http://rcue-uxd.itos.redhat.com/widgets/

The visual design is following RCUE. I just see two details that should be changed:
- Align the labels to the right and make it bold (see ?forms? section in widgets)
- Change the realm selector (dropdown) to their context selector (below)



With regards to the design, I updated the colour of the lighter bar. 



And make a version with the RCUE recommended selector:



What do you think?

Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/1c18e82a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-01-30 at 5.02.20 PM.png
Type: image/png
Size: 21176 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/1c18e82a/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customization_1-old-selector.png
Type: image/png
Size: 46422 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/1c18e82a/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customization_1-new-selector.png
Type: image/png
Size: 45799 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140130/1c18e82a/attachment-0005.png 

From stian at redhat.com  Fri Jan 31 03:52:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Jan 2014 03:52:45 -0500 (EST)
Subject: [keycloak-dev] when next release
In-Reply-To: <6B6B493F-1AB7-48D6-9A4C-BD4D38EE6DB6@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
	<724709703.16542392.1391099569069.JavaMail.root@redhat.com>
	<6B6B493F-1AB7-48D6-9A4C-BD4D38EE6DB6@redhat.com>
Message-ID: <1098440394.16892910.1391158365974.JavaMail.root@redhat.com>

The RCUE recommended selector looks better

Why not use the color scheme from the login page in the border? Attached a quick mock-up. IMO that looks better.

"move to RCUE styles first" - We should use the widgets provided on that page, as well as the css from https://github.com/rhamilto/rcue. That way we don't have to maintain the css ourselves + we know for sure it's compatible.

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 January, 2014 7:14:07 PM
> Subject: Re: [keycloak-dev] when next release
> 
> 
> 
> With regards to changes I think we should move to RCUE styles first, and
> apply the changes in the way they recommend changing it. As I've said I'm
> not happy with the new design for it either.
> 
> What exactly do you mean by ?move to RCUE styles first?? Changing the markup
> according to the widgets provided in this page?
> http://rcue-uxd.itos.redhat.com/widgets/
> 
> The visual design is following RCUE. I just see two details that should be
> changed:
> - Align the labels to the right and make it bold (see ?forms? section in
> widgets)
> - Change the realm selector (dropdown) to their context selector (below)
> 
> 
> With regards to the design, I updated the colour of the lighter bar.
> 
> 
> And make a version with the RCUE recommended selector:
> 
> 
> What do you think?
> 
> Gabriel
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customization.jpg
Type: image/jpeg
Size: 54726 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140131/fd25805c/attachment-0001.jpg 

From kpiwko at redhat.com  Fri Jan 31 04:03:21 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Fri, 31 Jan 2014 10:03:21 +0100
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <52EA6CF5.2010202@redhat.com>
References: <20140130095345.2f02b639@kapy-ntb-x220>
	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
	<20140130141357.4b609bf8@kapy-ntb-x220>
	<52EA55AB.1030707@redhat.com>
	<1148398873.16398621.1391089520382.JavaMail.root@redhat.com>
	<20140130153030.27288681@kapy-ntb-x220>
	<52EA6CF5.2010202@redhat.com>
Message-ID: <20140131100321.58250ad7@kapy-ntb-x220>

Bill, I'm researching what happened that not all AS7 artifacts are synced to
Maven Central, as this not a problem of Keycloak nor Resteasy.

Once solved, I'll send a PR to remove <repository> elements from keycloak
and ask Sonatype guys to sync it to Central.

On Thu, 30 Jan 2014 10:17:09 -0500
Bill Burke <bburke at redhat.com> wrote:

> Resteasy 3.0.6 master pom (downloaded from maven central) has 
> repository.jboss.org as a repository and also has a jboss-web dependency 
> so I don't understand why Keycloak can't be pushed to maven central.
> 
> On 1/30/2014 9:30 AM, Karel Piwko wrote:
> > Correct, Maven Central is even simpler to use. Works ootb, no mangling with
> > settings.xml is required at all.
> >
> > I asked for pushing RESTEasy to Maven Central in Nov 2011, needed for
> > EAP6/WFK2. There was the same clean up of pom.xml(s) back then.
> >
> > Performance wise, I have no idea. I'm not experiencing any difference at
> > all. If you experience connection lags, you can always mirror Maven Central
> > to a different repo, such as JBoss Nexus -
> > http://maven.apache.org/guides/mini/guide-mirror-settings.html.
> >
> > Karel
> >
> > On Thu, 30 Jan 2014 08:45:20 -0500 (EST)
> > Stian Thorgersen <stian at redhat.com> wrote:
> >
> >> Hosting on Maven Central means that folks can use Keycloak artifaces
> >> without having to add JBoss Nexus to their poms. So IMO it makes it
> >> slightly simpler to add Keycloak deps.
> >>
> >> RestEasy is on Maven Central
> >> (http://search.maven.org/#search%7Cga%7C1%7Cresteasy) ;)
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, 30 January, 2014 1:37:47 PM
> >>> Subject: Re: [keycloak-dev] Keycloak artifacts not in Maven Central
> >>>
> >>>
> >>>
> >>> On 1/30/2014 8:13 AM, Karel Piwko wrote:
> >>>> I did some checks and there is some work needed:
> >>>>
> >>>> 1/ According to Maven Central rules, there should not be any <repository>
> >>>> elements in pom.xml files
> >>>
> >>>
> >>>> 2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
> >>>> available no Maven Central
> >>>>
> >>>> So, following steps are needed:
> >>>>
> >>>> * figure out whether jbossweb dependency could be replaced by something
> >>>> else,
> >>>>     if not - it has to undergo same checks as keycloak and be synced to
> >>>>     Maven
> >>>>     Central or, which I prefer, to release it relocated to org.keycloak
> >>>>     groupId.
> >>>>     Given that 7.0.17.Final has do external dependencies at all -
> >>>>     seems much easier then trying to convince sonatype to pick a single
> >>>>     version
> >>>>     of jbossweb tree
> >>>> * remove all <repositories> from pom.xml files
> >>>>
> >>>
> >>> Would hosting at Maven Central require developers to configure their
> >>> settings.xml, or can the build still run OOTB?  A build running OOTB is
> >>> more important than hosting at Maven Central.
> >>>
> >>> Also, what is the performance of Maven Central compared to
> >>> repository.jboss.org?  I've often had slow as balls connections to Maven
> >>> Central and never any problems with repository.jboss.org.  Finally,
> >>> nobody has ever complained that Resteasy is not at Maven central.
> >>> People have no problems using repository.jboss.org so I don't see what
> >>> the big deal is.
> >>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> 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
> >
> 


From vrockai at redhat.com  Fri Jan 31 05:25:45 2014
From: vrockai at redhat.com (Viliam Rockai)
Date: Fri, 31 Jan 2014 11:25:45 +0100
Subject: [keycloak-dev] Customization for Keycloak
In-Reply-To: <4005C334-5123-4768-A655-93B05B16AE63@redhat.com>
References: <5C7BE3C7-FD30-4373-8838-A9773808FAB8@redhat.com>
	<1416737156.15331870.1390992119877.JavaMail.root@redhat.com>
	<181D5C8B-4784-42F9-B00F-B72E8EA4E62C@redhat.com>
	<1472847138.15469641.1391006080989.JavaMail.root@redhat.com>
	<28C436A3-7AD6-4DFB-8DEC-2D03BFBE2DED@redhat.com>
	<52E916E0.5030504@redhat.com>
	<448983909.15499874.1391008309824.JavaMail.root@redhat.com>
	<4005C334-5123-4768-A655-93B05B16AE63@redhat.com>
Message-ID: <1391163945.1973.0.camel@vrockai-laptop>

Yeah, I can do at least a PR for the new login form l&f if there are no
objections.

On Thu, 2014-01-30 at 12:37 -0200, Gabriel Cardoso wrote:
> Bill, RCUE is for projects, so we need some customization to
> differentiate the project. Viliam could make the changes to use the
> new design. Let?s go for it?
> 
> 
> Stian, they have some material at http://rcue-uxd.itos.redhat.com
> 
> 
> Gabriel
> 
> On Jan 29, 2014, at 1:11 PM, Stian Thorgersen <stian at redhat.com>
> wrote:
> 
> > 
> > 
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 29 January, 2014 2:57:36 PM
> > > Subject: Re: [keycloak-dev] Customization for Keycloak
> > > 
> > > Honestly, I'd prefer to follow the same look and feel as EAP
> > > instead of
> > > creating our own.  We may eventually have to provide keycloak
> > > "portlets"
> > > that can plug into different mgmt consoles.
> > 
> > We need to move to the official RCUE styles at some point. This will
> > probably require some changes to html structure. Once we've done
> > that it's easy to change the L&F from the Keycloak theme, to the
> > WildFly theme and finally to the EAP theme.
> > 
> > Gabriel do you know where we can get RCUE from?
> > 
> > > 
> > > On 1/29/2014 9:44 AM, Gabriel Cardoso wrote:
> > > > 
> > > > On Jan 29, 2014, at 12:34 PM, Stian Thorgersen <stian at redhat.com
> > > > <mailto:stian at redhat.com>> wrote:
> > > > 
> > > > > The login form looks really good!
> > > > Thanks
> > > > 
> > > > > I'm not convinced about the admin console though. The bright
> > > > > blue
> > > > > isn't very nice. Also I was wondering if there's some way we
> > > > > could not
> > > > > have a separate "bar" for the realm drop-down and add realm
> > > > > button.
> > > > > Could we move this to the left-hand menu, or merge it with the
> > > > > logo /
> > > > > user selection bar (and also make it slightly bigger at the
> > > > > same time)?
> > > > Well, it is a matter of taste. But I can try to make it more
> > > > attractive.
> > > > 
> > > > Why you don?t want to have that nav bar? We have plenty of space
> > > > and it
> > > > is clear that this is the highter level of navigation.
> > > > 
> > > > However, it doesn?t hurt trying to incorporate the dropdown and
> > > > button
> > > > into the sidebar. I?m just afraid this will make the navigation
> > > > more
> > > > confusing, but we can give a shot.
> > > > 
> > > > Here is an example of something they did for EAP.
> > > > 
> > > > 
> > > > I needed to think a bit to understand the hierarchy.
> > > > 
> > > > Gabriel
> > > > 
> > > > ---
> > > > Gabriel Cardoso
> > > > User Experience Designer @ Red Hat
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > 
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > _______________________________________________
> > > 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
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From darran.lofthouse at jboss.com  Fri Jan 31 07:26:15 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 31 Jan 2014 12:26:15 +0000
Subject: [keycloak-dev] Brining KeyCloak to WildFly Management /
	Subsystemless Integration
Message-ID: <52EB9667.7020706@jboss.com>

Hi all,

Just finishing off some WildFly 8 tasks and have a few things to work on 
for EAP after that but as soon as that is done I need to get on with the 
next steps for WildFly 9.

For the future SSO within domain management we have a few different 
issues to content with: -
  - CORS
  - Switching to a new identity provider
  - Integrating with existing authentication mechanisms
  - Enabling OAuth

What I wanted to check with you guys before I start raising some 
tracking issues is if we can consider these points independently or if 
we are going to need an all at once approach?

As an example we had a discussion the other day where it was identified 
there may already be a CORS implementation in KeyCloak we can use, that 
is also one of our number one requirements in WildFly - would it be an 
option to integrate that portion first and then start looking to the rest?

Regards,
Darran Lofthouse.


From bburke at redhat.com  Fri Jan 31 09:51:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 31 Jan 2014 09:51:33 -0500
Subject: [keycloak-dev] Brining KeyCloak to WildFly Management /
 Subsystemless Integration
In-Reply-To: <52EB9667.7020706@jboss.com>
References: <52EB9667.7020706@jboss.com>
Message-ID: <52EBB875.8000900@redhat.com>

What I think needs to be done is figure out how exactly you want 
bootstrapping and configuration to look like.  What are the user facing 
interactions?  What GUI or CLI commands need to be done?  What can we do 
to provide an integrated, simple, easy to use, nice SSO solution for 
Wildfly?

As for Keycloak: CORS, switching IPs, Integrating with existing auth 
mechs, and OAuth are all things we do or want to do.  You have to 
remember though that Keycloak is a solution.  A user-facing solution. 
If you're only interested in adapters to integrate Wildfly with some 
third-party SAML, oauth, openid, or whatever solution, then Keycloak is 
not for you.  We're not an third-party adapter provider.  I'm really not 
interested in Keycloak becoming another Picketlink where we provide a 
set of libraries to help you build your own security solution.

But, if you're interested in focusing on providing an OOTB SSO solution 
for Wildfly, then we can talk:

For a CORS solution, we only have "validated CORS" where the allowed 
origins are stuffed in the signed token you get from the auth server. 
There will probably be a few cases where users want unauthenticated CORS 
invocations.  Implementation wise, much of the CORS stuff is broken out 
into different Undertow handlers.  I also think Undertow has some of 
this too (all the preflight stuff).

Using different IPs (i.e. LDAP/AD) is on the back burner for at least a 
few months as we focus on Wildfly integration, themes, and other 
critical features.

What do you mean by Enabling OAuth?  If this means just having Wildfly 
participate as an OAuth client, then again Keycloak is not for you.  If 
you want Wildfly to be the OAuth provider, then, you would need 
something like keycloak in order to provide login screens and grant pages.

For Keycloak integrating with other auth mechanisms, I see this as a 
Keycloak problem in that we need to be able to work with clients that we 
cannot install an adapter on, but yet support a protocol like SAML.

On 1/31/2014 7:26 AM, Darran Lofthouse wrote:
> Hi all,
>
> Just finishing off some WildFly 8 tasks and have a few things to work on
> for EAP after that but as soon as that is done I need to get on with the
> next steps for WildFly 9.
>
> For the future SSO within domain management we have a few different
> issues to content with: -
>    - CORS
>    - Switching to a new identity provider
>    - Integrating with existing authentication mechanisms
>    - Enabling OAuth
>
> What I wanted to check with you guys before I start raising some
> tracking issues is if we can consider these points independently or if
> we are going to need an all at once approach?
>
> As an example we had a discussion the other day where it was identified
> there may already be a CORS implementation in KeyCloak we can use, that
> is also one of our number one requirements in WildFly - would it be an
> option to integrate that portion first and then start looking to the rest?
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Fri Jan 31 10:21:10 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Fri, 31 Jan 2014 10:21:10 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52EA68CA.800@redhat.com>
References: <52EA68CA.800@redhat.com>
Message-ID: <52EBBF66.7040202@redhat.com>

A couple of other things I failed to mention.

On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
> Future tasks for the Keycloak Subsystem:
> * Integration with the Keycloak Admin
> * Review the attributes of realm and secure-deployment to make sure they
> align with keycloak.json.
And also make sure that default boolean values are correct.  Make sure
required fields are correctly marked as such.  Etc.
> * Fill in help text in
> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
> * See comments in KeycloakAdapterConfigService.java.  This class may
> work better as a plain Singleton instead of a service.
And also this class is not currently thread-safe.  We could probably get
by with just making all the public methods synchronized.  The rare case
where thread safety matters is when two administrators are editing the
subsystem at the same time.  At startup, the initialization of all the
data is single-threaded.
> * It probably wouldn't hurt to ask Brian Stansberry to give the
> subsystem a quick review.
> * More tests
> * Package the subsystem with the distribution
> * Documentation
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140131/30e4d5b2/attachment.html 

From gcardoso at redhat.com  Fri Jan 31 12:43:13 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Fri, 31 Jan 2014 15:43:13 -0200
Subject: [keycloak-dev] when next release
In-Reply-To: <1098440394.16892910.1391158365974.JavaMail.root@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
	<724709703.16542392.1391099569069.JavaMail.root@redhat.com>
	<6B6B493F-1AB7-48D6-9A4C-BD4D38EE6DB6@redhat.com>
	<1098440394.16892910.1391158365974.JavaMail.root@redhat.com>
Message-ID: <E6BD6063-2510-4240-B46D-E2F5E4F358F8@redhat.com>

I?ve refined your quick mockup and it really looks better.

IMO we can go with this version.

Gabriel




On Jan 31, 2014, at 6:52 AM, Stian Thorgersen <stian at redhat.com> wrote:

> The RCUE recommended selector looks better
> 
> Why not use the color scheme from the login page in the border? Attached a quick mock-up. IMO that looks better.
> 
> "move to RCUE styles first" - We should use the widgets provided on that page, as well as the css from https://github.com/rhamilto/rcue. That way we don't have to maintain the css ourselves + we know for sure it's compatible.
> 
> ----- Original Message -----
>> From: "Gabriel Cardoso" <gcardoso at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 30 January, 2014 7:14:07 PM
>> Subject: Re: [keycloak-dev] when next release
>> 
>> 
>> 
>> With regards to changes I think we should move to RCUE styles first, and
>> apply the changes in the way they recommend changing it. As I've said I'm
>> not happy with the new design for it either.
>> 
>> What exactly do you mean by ?move to RCUE styles first?? Changing the markup
>> according to the widgets provided in this page?
>> http://rcue-uxd.itos.redhat.com/widgets/
>> 
>> The visual design is following RCUE. I just see two details that should be
>> changed:
>> - Align the labels to the right and make it bold (see ?forms? section in
>> widgets)
>> - Change the realm selector (dropdown) to their context selector (below)
>> 
>> 
>> With regards to the design, I updated the colour of the lighter bar.
>> 
>> 
>> And make a version with the RCUE recommended selector:
>> 
>> 
>> What do you think?
>> 
>> Gabriel
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <customization.jpg>

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140131/91f46685/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customization_4.png
Type: image/png
Size: 48329 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140131/91f46685/attachment-0001.png